MoCA
MoCA is a middleware architecture that supports the development and deployment of context-aware distributed applications for infra-structured wireless local networks, that is, IEEE 802.11b/g WLANs. It provides means for collecting, storing and processing context data from mobile devices (notebooks, for instance).
Essentially, MoCA consists of a set of API's that enable easier and more effective application development by providing easy access to generic services useful for a variety of applications. It does not assume any specific architecture for the application (i.e. client/server or P2P). However, it requires that the mobile devices have IEEE 802.11 interfaces, and are able to connect to IEEE 802.11 access points, i.e that the user has the proper authorization (unless, of course, for test purposes).
MoCA also comprises a set of core services that support the execution of context-aware applications. So far, it can be used only for portable devices running Windows XP. The Windows CE version is under development.
A MoCA-based application must be developed using the MoCA
ClientAPI. If the application has a client/server architecture,
it may use the MoCA ServerAPI. These APIs hide from the
programmer many of the details of using the MoCA core services.
While the MoCA client generally runs in a mobile host, the
server typically runs on the wired network. The MoCA
architecture is shown in Figure 1.
The ClientAPI, when executed, automatically starts the MoCA
Monitor, a daemon that runs on each mobile device and is
responsible for collecting data about the device's execution
state and environment, i.e. the device's context information,
which may include the wireless connection's quality, remaining
energy, CPU usage, free memory, current access point (AP), and
a list of all APs and their signal strengths that are within
the mobile device's range. All the collected data is sent to a
specific MoCA service named Context Information Service (CIS).
Figure 1: The MoCA architecture
The CIS is a distributed service where each CIS server, typically running on a node of the wired network, receives, stores and processes the context information sent by a set of monitors, each running in a particular mobile device. It also receives requests for notifications (that is, subscriptions) from application clients and servers and generates and delivers events to the subscriber applications whenever a change in a device's state is of their interest. Both the ClientAPI and ServerAPI provide means of accessing the data about any device being monitored stored by the CIS server.
The configuration service (CS) stores and manages configuration information about each mobile device so that they can use the CIS service. The CS stores this information in a persistent hash table, where each entry -- indexed by the mobile device's media access control address (MAC address) -- holds the corresponding CIS server's address (IP and port), and the periodicity according which the monitor must send the device's information to the CIS. The MAC address-specific indexing is essential for implementing a distributed CIS, where each server gets approximately the same context processing load.
The Location Inference Service (LIS) is responsible for inferring the approximate location of a mobile device from the raw context information collected by the CIS for a given device. It compares the device's current pattern of RF signals received (from all audible 802.11 access points) with the signal patterns previously measured at predefined reference points in a building or open area. Therefore, before being able to make any inference, the LIS database has to be populated with RF signal probes (device pointing at several directions) at each reference point, and inference parameters must be chosen according to the specific characteristics of the region. In fact, the number of reference points determines the reliability of the inference.
LIS allows the administrator to define logical regions of arbitrary size and rectangular shape and a hierarchical description of regions and their nested sub-regions. This functionality is implemented in the Symbolic Region Manager (SRM), which provides an interface to define (create, modify, and delete) and request information about hierarchies of symbolic regions, which are names assigned to well defined physical regions (i.e. rooms, halls, buildings) that may be of interest to location-aware applications. All symbolic regions should be based in the set of atomic regions defined by LIS Administrator.
Finally, the ServerAPI automatically registers in the Discovery
Service (DS), a server in charge of storing information, such as
name, properties, addresses, etc., of any application (i.e. its
servers and proxies) or any service registered with the MoCA
middleware, in order to have its addresses available to be found
by prospective clients.
MoCA consists of a set of APIs that comprises communication infra-structure, core services and optional services. The tables below present a short description of each API's and Figure 2 presents the dependencies between the API modules.
Figure 2: MoCA API's dependencies graph
Client and Server
| API | Description |
|---|---|
| ClientAPI | Facilitates application programming hiding from the developers some details concerning network programming and the use of MoCA architecture. Starts automatically the monitor, if desired. |
| ServerAPI | May be used to create a server application, such as a new service, based on location and context-aware MoCA architecture. Registers automatically in the DS. |
Communication Infrastructure
| API | Description |
|---|---|
| Communication Protocols (Cm) | Implements protocols for synchronous and asynchronous message exchanging between Java objects using either TCP or UDP. |
| Event Communication Interface (ECI) | Implements event-based (Publish/Subscribe) communication. |
Core components
| API | Description |
|---|---|
| Context Information Service (CIS Client) | Implements interface with CIS to place subscriptions (SQL-like interest expressions), and receive notifications whenever the device's context variables satisfy an interest expression. |
| Location Inference Service (LIS) | Supports device-specific and location-specific queries and (asynchronous) notifications. |
| Symbolic Region Manager (SRM) | Stores information about hierarchies of symbolic regions, based in the set of atomic regions defined by LIS |
| Discovery Service (DS) | Implements interface with DS to store information, or place queries about any service registered with the middleware |
Other
| API | Description |
|---|---|
| Util | Basic functionality, such as Listener and Thread pools. |
MoCA packages is a new mechanism for distributing Moca's components. Instead of downloading each component or library on demanding, MoCA's users now can download a whole set of main components (and its libraries), whose versions are compatible.
We strongly recommend you to download MoCA packages, instead of downloading individual components. This will avoid compatibility problems.
A package is a compacted file (Zip and tar.gz) that adopts the following structure:
moca-packages-<version> |_ components - installation of all MoCA services |_ jars - jars compatible to all MoCA services
Any application must point to the jar files found in jars directory, in order to avoid incompatibility problems.
Check below which package version is suitable for your purpose, and download it.
Package 1.5x implements a more flexible context model for MoCA and introduces the following new services and components:
Important note:No monitor is include in this distribution (neither ProxyFramework). You must download each component individually by yourself. Components (i.e. services) have installation procedures (see link inst) whereas libraries may have dependencies of additional libraries (see link dep). All required libraries are included in a component distribution. Before developing an application, be sure you have download all libraries dependencies.
| Package Version | CIS (inst) | LIS (inst) | SRM (inst) | ECI (dep) | Util (dep) | Comm-Protocol (dep) |
|---|---|---|---|---|---|---|
| 1.5.1-RC1 | 1.5.1 | 1.1.1-RC3 | 1.1.1-RC1 | 1.5.1 | 1.5.1 | 1.1 |
We do recommend to download MoCA main components and libraries in a MoCA package archive (see previous section).
MoCA API's and services may be installed in any computer with JVM 1.4 or later, but the Monitor will run only under Windows XP. There is not a predefined order of installation, however, to prepare a development environment where he will be able to write and execute his applications, the user must install all essential API's.
The main MoCA API's are available for download as ".jar" files. Client, server, moca-util, communication-protocol (Cm), event-service (ECI), and CIS-client API's may be found at the following addresses:
After downloading those files to a given directory (e.g. MOCA_HOME =
"C:\Program Files\MoCA"), all these ".jar" files (with their
respective locations) must be added to the CLASSPATH environment
variable, before compiling your code.
Some of the the core services are available for download as ".zip" files containing all binary files, script files and configuration files needed to run the specific service, with a pre-defined structure of directories. CIS, LIS and SRM packages can be found at:
LIS and SRM packages contain also the API (".jar") needed to interface with the services.
These files may be unpacked in the same MOCA_HOME directory
where the previous set of files was saved, and the CIS_HOME,
LIS_HOME and SRM_HOME environment variables, indicating the full
directories where they can be found, must be defined. Their
respective "bin" files must be added to the system PATH too.
The DS service and API is available as a single ".jar" file and may be downloaded at:
Also the CS service is available as a single ".jar", and is not necessary in the development platform. But if the user wants to run the service, the file may be downloaded at:
Finally, the monitor software must be downloaded and installed in the mobile device only. A zip file containing all needed files and a setup executable that will perform the installation automatically may be found at:
There is only a Windows XP version of the monitor available, and the mobile host must have a wi-fi card installed to run the daemon properly.
Alternatively, for simulating a mobile host in a static host (desktop PC), the user must download the monitor simulator (see ahead) a ".zip" file that can be found at:
Further information about how to choose between the monitor or the monitor simulator can be found ahead (Section How to Simulate Host Mobility).
After installing all APIs, and then writing and compiling a program, the user will need the core services configured and running somewhere before he can test and use his application. For instance, the server application, when executed, as soon as initiated will register itself in a DS server. The monitor, whenever started, will query the CS to get the address of the CIS server in charge of collecting its data, only if the CS is not active it will read the address in a configuration file. The client will always try to launch the monitor automatically, and so on.
It is then clear that there is a series of functional dependencies among the services and the application, and the user must be careful to fulfill each necessary condition before he can start his applications. Figure 3 shows all the tasks the user must perform to run a MoCA application. The order in which the events must occur must be equivalent to any topological order of the graph described.
Figure 3: Tasks to be performed in order to run a MoCA application
In fact, the user can either install and run MoCA's main services (CIS, LIS, CS and DS) on his system (PC or notebook), or use the MoCA Online Services (MoCA-OS). The first manner is recommended in general and only if it is not possible for the user to install and run the core services, he should use the online services.
Once all the needed files have been downloaded, running the application and the basic services is straightforward.
The CIS server is provided with a batch file to allow its automatic execution (for Windows environment only). The user must only type "cis" at the prompt line.
But before that, he must write a configuration file containing
information about the server's external IP address and ports to bind to,
in order to listen to clients' requisitions. This file, named
cis.properties, must be saved in the CIS_HOME\conf directory.
The box below shows the content of the file provided in the
package, which represents the default values:
cis.monitor.port=55010 cis.event_server.port=55000 cis.server.port=55001 cis.server.address=0.0.0.0
More detailed information about how to configure and run the CIS service may be found at the CIS Use page.
The SRM server may optionally be used, if the user wants do define a hierarchy among the areas managed by LIS, The SRM package is provided with a batch file. It will be executed (in Windows environment) by simply typing "srm" at the command line. It must be started before LIS.
More detailed information about how to run the SRM service may be found at the SRM page.
To run the LIS server the user needs only to type "lis" at the
prompt line. But before that, he must write three configuration
files, all of them to be saved in the LIS_HOME\conf directory.
The first one, is named cis.properties, and contains information
about the CIS server external IP address and ports, so that the LIS can
register to get raw data. The box below shows the content of the
file provided in the package downloaded from the site, which
represents the default values:
cis.server.host=cis.lac.inf.puc-rio.br cis.server.port=55001 cis.publisher.port=55000 cis.monitor.port=55010
The second one, named srm.properties, is necessary only if the
SRM server is used. It describes the SRM server parameters, to
allow the LIS server to connect and get information about the
symbolic area hierarchy. The box below shows the content of the
file provided in the package downloaded from the site, which
represents the default values for the SRM server:
srm.server.host=srm.lac.inf.puc-rio.br srm.query.port=55030 srm.event.port=55031
Finally, the third one, named lis.properties, describes the LIS
server parameters, such as server's external IP address and ports to bind
to in order to listen to clients' requisitions. The box below
shows the content of the default file provided in the package:
lis.server.host= lis.lac.inf.puc-rio.br lis.server.port=55021 lis.publisher.port=55020
To infer the location of devices from the raw data collected by
the monitor (provided by CIS), LIS needs specific input files.
These are XML files with information about signal pattern
from several locations, created with a tool called Mapper,
which relates the logical areas with the RF signals intensity.
When the LIS is started, all the input files in the directory
LIS_HOME\maps are automatically loaded by LIS. The user must
provide these files in order to run a location aware
application that uses LIS, but some samples can be found with
the software installed.
More detailed information about how to configure and run the LIS service may be found at the LIS page.
The CS is started with the following command line:
java -jar cs-rc2.jar
The CS is configured by a file named cs.properties that will be
read as soon as it is started and must be created in the
MOCA_HOME directory, where the CS was installed. Its content is
shown below:
cs.ip_address=xxx.xxx.xxx.xxx
where the "x's", obviously, must be substituted by the IP address of the server where the CS will be running.
After started the CS is ready to receive messages adding or
removing a device in the service database or requesting for
information about devices with a specific configuration. But the
user may insert entries in the CS also using a more convenient
graphical user interface. To start the CS GUI, first the user
must include the "cs-rc1.jar" in the CLASSPATH and enter the
command:
java moca.service.cs.gui.CSClient
After starting the CS gui, the application asks for the IP address of the host where CS is running and then shows a window where the user may set entries correlating the MAC addresses of mobile devices with the address of the CIS server to where they must send their data.
If a CS service is not running, the monitor executing in the mobile device will read the CIS address in the respective configuration file.
More detailed information about how to configure and run the CS service may be found at the CS Use page.
The DS must be started with the following command line:
java -cp ds-rc1c.jar moca.service.ds.slp.Da
A configuration file named server.properties will be read by the
user's server application in order to know the DS address where
to register and must be created in the directory where the
server is installed. The default content of the file is shown
below:
ds_ip = ds.lac.inf.puc-rio.br ds_port=55017
This content must be modified to show by the IP address of the server where the DS was installed and started by the user, and the associated port number.
More detailed information about how to configure and run the DS service may be found at the Getting Started with DS page.
The monitor, which is also installed in the mobile device, is
started automatically by the ClientAPI. It reads a configuration
file named monitor.properties that must be created in the
directory C:\Windows\MonitorXP, where the monitor is installed.
The original installation comes with the following content:
CIS_ADDRESS = cis.lac.inf.puc-rio.br CIS_PORT = 55010 CIS_PERIODICITY = 3 CS_ADDRESS = cs.lac.inf.puc-rio.br CS_PORT = 55016 DS_ADDRESS = ds.lac.inf.puc-rio.br DS_PORT = 55017 DEFAULT_CARD_QUERY_INTERVAL = 250 MONITOR_PORT = 61555
This default content, obviously, must be modified to represent the correct IP addresses and port numbers of the services chosen by the user. It brings the information necessary to access CIS, CS and DS, i.e. IP addresses, ports and time intervals. The CS address is used to query CS to get information about the CIS service, the CIS information is sused if the CS is not running, and de DS information is available to be consulted by the client running locally.
More detailed information about how to configure and run the Monitor may be found at the Monitor page.
When choosing to use the MoCA-OS the user must be aware of the fact that his application may behave erroneously if he is running the monitor simulator using the standard configuration files (see Section How to Simulate Host Mobility). This happens because other users may be running simulators simultaneously, and the online services will see the data collected from all the monitors as originated by the same device. Besides, as the user will not have the proper rights to restart the online services or debug log files, among other tasks, the online services may not be suitable for debugging an application.
Using the MoCA-OS is as simple as using the services running in the users' own host. The user only has to be concerned to set the appropriate configuration files to indicate the following addresses:
| Service | Server address | Ports |
|---|---|---|
| CS | cs.lac.inf.puc-rio.br |
server 55015 monitor 55016 |
| DS | ds.lac.inf.puc-rio.br | 457 |
| CIS | cis.lac.inf.puc-rio.br |
asynchronous server 55000 synchronous server 55001 monitor 55010 |
| LIS | lis.lac.inf.puc-rio.br |
publisher 55020 query 55021 |
| SRM | srm.lac.inf.puc-rio.br |
query 55030 asynchronous server 55031 |
More detailed information about how to use the MoCA online services may be found at the Online Services page.
If the user needs to test his application using only static hosts, but wants simulate one or many hypothetical mobile devices, he may use the Monitor Simulator (Monitor/Sim). This Monitor mimics the real Monitor on a mobile device, but instead of collecting the context data from the device, reads this data from a configuration file and behaves accordingly. Apart from this difference, Monitor/Sim, works exactly as the real Monitor, i.e. it sends the simulated mobile device's context data periodically to CIS.
The monitor simulator configuration file contains information
such as the CIS server address, scan interval and the scan file,
which is the file that contains the description of the data to
be sent to the CIS server, as if it were the context data
acquired by a mobile device. This file is named
monitor.properties and must be saved in the MONITOR_HOME\conf
directory. An example of this file may be seen below.
cis.server.host=cis.lac.inf.puc-rio.br cis.monitor.port=55010 monitor.scanInterval=1000 monitor.repeating=true file1=conf/Scan-Banco_01.txt interval1=5000 file2=conf/Scan-EspacoAberto.txt interval2=10000 file3=conf/Scan-Mesa_03.txt interval3=20000
The first two lines specify the address and port to where the simulated context data may be sent. The Monitor Simulator doesn't query the CS service to get the CIS address, differently from the Monitor XP. According to the description above, a scan will be sent to CIS each 1 second (monitor.scanInterval=1000). The information sent by the simulator is configured in the properties file through the set of pairs "fileN, intervalN". During the first 5 seconds (total of 5 scans), the scans will be read from file "Scan-Banco_01.txt". For the next 10 seconds (total of 10 scans), the scans will be read from file "Scan-Banco_02.txt", and so on. After sending all the content of the listed files, in this example the monitor will repeat everything over and over again (monitor.repeating=true).
A scan file (like scanX.txt) contains information about CPU usage, memory level, MAC address, RF signals, etc, using the following format:
CPU#Free Memory#EnergyLevel#Periodicity#IPChange#APChange#IP#MASK#MobileHost's MacAddr#Current AP's MacAddr&AP1&AP2&AP3&APn
To not have to write all these scan files, the user may configure the monitor simulator using the simulator GUI, a graphical application that offers a simpler way to describe how the simulated mobile host should behave. It may be started by typing "monitor gui" at command line. It will show the window below.
To add a scan file, click in the button "Adicionar" and select the desired file. After selecting that file, it will appear in the combo box "Arquivos", as shown in the figure below.
To start the simulator, click the button "Iniciar". To configure a scan file, select the file in the combo box e click the button "Configurar". The following window will appear.
The "Scan Configurator" window allows the user to write easily all necessary information to describe a scan file to be used by the monitor simulator. Nevertheless, it is strongly recommended that the user edit the scan files provided with the Monitor package, instead of writing totally new files when testing his applications.
More detailed information about how to run and configure the Monitor Simulator may be found at the Monitor page.