International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B2. Istanbul 2004 
Aeris MicroBurst is a wireless data communication system that 
utilizes the analog portion of existing cellular networks, which 
gives excellent coverage. MicroBurst is considered an ideal 
solution for applications requiring widespread availability and 
reliability but only have small data bandwidth requirements. 
Many types of MAMS fall under this category of applications. 
MicroBurst utilizes the Forward Control Channels (FOCC) and 
the Reverse Control Channels (RECC) of an analog cellular 
network. Together, they enable two-way communication and 
control with assets. 
FOCC messages are transmitted from the cellular switch to the 
MicroBurst-enabled devices. FOCC messages, otherwise 
known as Pages, are meant to trigger responses from the device 
or to get the device or asset to perform a desired operation. 
Each MicroBurst-enabled device can have up to 10 Mobile 
Identification Numbers (MIN) which can be used to trigger a 
different event or operation on the device. FOCC messages are 
initiated by the device’s owner or interested users, who send the 
page in a MicroBurst specific format to Aeris’s central hub. 
Aeris then sends out the page to the desired device. RECC 
messages are transmitted from the MicroBurst-enabled devices 
onboard assets back to the cellular switch. These RECC 
messages are then sent to the Aeris central hub, which finally 
relays the messages through the Internet back to the asset 
owners. Each message packet’s data is encoded into a number 
string. To obtain data in real-time, the asset’s owner must be 
continuously connected to the central hub via the Internet. 
Otherwise, Aeris will store the data until the owner connects 
with it. The maximum length of a number string is only 32 
digits. However, by using cach number efficiently, it is still 
possible to send useful amounts of data with a MicroBurst 
message packet. Multiple messages can also be used to increase 
the amount of unique data that can be sent from the asset. 
[Aeris.net, 2003] 
3. PLATFORM ARCHITECTURE 
The Platform is split into several components based on logical 
and physical boundaries. This follows object-oriented principles 
of grouping similar functionality together and also offers 
performance and security benefits. 
3.1 Client-Server System Architecture 
A common paradigm found in computing is the Client-Server 
(CS) architecture. The CS architecture utilizes servers that 
contain data resources and may perform some or all of the data 
processing function. The Client’s primary purpose is to present 
data and processing results from the Server to users but may 
also process data depending on the CS design used. The CS 
design is split into additional subcategories, depending on the 
fatness or thinness of the client layer. The thin client is a 
lightweight application that can only display data and 
processing results that are retrieved from the server. Being 
lightweight, the client layer application requires less memory, 
storage and processing power, therefore enabling the client 
application to run on smaller and more mobile computing 
devices, like PDAs. On the other side of the spectrum, there is 
the fat or thick client where most processing functions are 
carried out at the client side and only the data is retrieved from 
the server. Between these two extremes, there are also hybrid 
clients where the processing workload is split between the 
server and client. The hybrid scheme was utilized in the 
Platform for its advantages in performance and control of 
remote access to the asset data [Peng and Tsou, pg. 13]. 
3.2 Platform Modules 
The Platform features numerous useful functions for a MAMS 
application. These functions have been separated into data, 
application logic and presentation layers and placed into 
independent modules. These modules can be used fully, 
partially or customized depending on need. Much of the 
configuration for the modules can be done in configuration files 
or databases, thus allowing for significant customization 
without a need to change the code. While these modules are 
logically separated, they can physically operate on the same 
server or be distributed across different servers. This can realize 
improvements for scalability and performance while still 
working seamlessly with each other. 
3.2.1 Communication Module 
The Communication Module contains the functionality to make 
and maintain the connections to assets. The only configuration 
required if using Microburst-enabled Asset-Link sensors is to 
input settings regarding the IP address of the Aeris servers and 
account "settings to login to Acris’s; i servers. The 
Communication Module connects to the servers at Aeris's 
central hub using the Internet with network socket connections. 
Two connections are made; one connection is to the Aeris Data 
(DS) Server; this server relays messages sent from a remote 
Microburst-enabled sensor back to the Office. The other 
connection is with the Aeris Page (AS) Server; the AS Server 
© 
relays pages sent by users to the sensors. 
The Communication Module is also responsible for maintaining 
a continuous connection to the Aeris servers. These servers 
send regular “pings” to any connection that is made to it, to 
ensure that the connection is still valid. If no acknowledgement 
message is sent back, then the connection will be terminated. 
As well, other messages that are initiated by the Aeris server 
usually require an acknowledgment. The Communication 
Module has the necessary logic to recognize the message type 
and to return a suitable acknowledgement back to the servers to 
ensure the connection is not terminated. For messages that are 
sent from a sensor onboard an asset, the raw data is extracted 
and passed onto the Data Module for further processing. 
There are a large number of messages that are used on the Aeris 
MicroBurst service but all share a common format and binary 
encoding method. Each message has a header and limiter plus 
the actual message contents. The message contents include the 
metadata, such as the message length, message identification 
number to distinguish its message type and finally, the message 
body itself. As the messages share a similar structure, then it is 
natural to implement the different Aeris message types as 
objects in the Platform by implementing Java classes to 
represent each message type. 
3.2.2 Data Module 
The Data Module is responsible for serving data from 
geospatial sources, such as vector data in ESRI Shape form or 
raster image data, to local or remote users through the Internet. 
It features a highly optimized code base and supports 
simultaneous multi-user access. This module is also responsible 
for receiving the decoded raw asset data from the 
Communication Module, to store into databases and serve the 
asset data to users. It is designed primarily to serve requests 
from the Web Client. though any application that understands 
Internat 
the con 
connect 
configui 
rapid se 
Module 
That 1s 
expected 
technol 
handling 
one inst 
minimiz 
The D 
Commu 
from th. 
hands it 
number 
configur 
informat 
Databas: 
handle t 
the data! 
any cha 
have to 
the Mo 
public ii 
format c 
minimiz 
collectio 
Database 
occurs a 
used to 1 
product | 
with dat: 
allow di 
of Micro 
When pt 
ESRI SI 
features. 
Storage 
reducing 
works by 
area; ea 
with nc 
Furtherm 
cell size, 
greater n 
The topr 
map. As 
file, its | 
possible 
into diffc 
needs to 
thereby « 
MLSS is 
of cell p: 
to best n 
particulai 
foundatic 
threads c 
vector da 
is persist 
destroyec 
the time