Wireless Network Architecture for Digital Inclusion in Rural Environments Eduardo Grampín*, Javier Baliosian+, Jorge Visca*, Martín Giachino*, Leonardo Vidal* *
Instituto de Computación, Universidad de la República, Montevideo, Uruguay E-mail: {grampin, jvisca, giachino, lvidal}@fing.edu.uy + Ericsson Ireland Research Centre, Athlone, Ireland E-mail:
[email protected]
Abstract—Rural environments of developing countries usually lack of the appropriate communications infrastructure, accentuating the geographical isolation of rural communities. A cost-efficient and service-oriented deployment of Information and Communications Technologies (ICTs) helps to reduce the socalled “digital divide”, improving the productivity and quality of life of those communities. Mobile communications have settled down a foundation for the development of new and rich network applications which are particularly attractive as digital inclusion tools for rural environments, where they can be deployed with comparative simplicity and reduced cost. In this paper we propose the Rural Ambient Network (RAN), an architecture for wireless networks specially designed for digital inclusion enabling global optimization of resource utilization using the Community Cost metric. This architecture uses a policy-based management framework for the integration of heterogeneous technologies in a common network control space. We also present a RAN prototype which uses mesh networking as a key technology; several scenarios involving policy-based decision-making have been tested on this infrastructure. Our early results show that RAN augments the native routing capabilities of the underlying technologies. Index Terms—Information and Communication Technologies for Digital Inclusion, Policy-based Network Management, Wireless Ad-hoc Networking.
T
I. INTRODUCTION
HE aim of this project is to improve connectivity of remote rural communities in Uruguay, which often depend on unreliable, expensive and/or low capacity physical links, and sometimes lack completely of networking infrastructure. The project is centered in the experience of CATFRAY artisan cooperative, mainly integrated by women, which produces garments made of wool and natural fibbers using different techniques as weaving and hand knitting, and live in the surroundings of two rural localities 70 Km away from each other: Totoral del Sauce and Fray Marcos (see Fig. 1). These women work at the cooperative premises and at Research paper. Manuscript received March 2, 2007. This work was supported in part by a Microsoft Research Digital Inclusion Grant won by the project “Deployment wireless ambient networks on heterogeneous rural environments”, with the cooperation of ANTEL, the public telecommunications company of Uruguay, and the partnership of the NGOs “Manos del Uruguay” and “Comité para la Democratización de la Informática” (CDI).
home, they raise their children, do house keeping and many other activities in the surroundings of their home place. In this context, the deployment of a mobile computing infrastructure should facilitate the solution of many everyday productionrelated problems like accounting and coordination tasks, such as processing orders, purchasing raw material or track-andtrace of their production. It can also provide voice and text communications between remote locations, and may promote cultural initiatives like community radios or news services.
Fig. 1. Map of the RAN deployment region. Circles highlight Totoral del Sauce and Fray Marcos.
These user applications would be based in a network infrastructure founded over the Ambient Networks (AN) [1] concepts, taking into account the geographical characteristics of rural areas, the economic situation of its members and the cultural profile of rural communities. The basic supporting technologies for the RAN environment are Mesh Networking, introduced by the IETF Mobile Ad-hoc Networking (MANET) Working Group [2], the IEEE 802.11 set of wireless LAN standards [3] (usually known as Wi-Fi), GSM/GPRS [4] and other evolving mobile communications standards such as 3G. Also a prospective deployment of WiMAX [5] access is foreseen. This paper is structured as follows. Section II analyzes the design aspects of RAN, Section III presents the optimization problem using the Community Cost metric, and Section IV reviews some implementation issues and proof of concept evaluation results. The last section is devoted to make some concluding remarks and to point out future work.
II. DESIGN ASPECTS OF RAN The main goal that drives the network prototype design is the universal access to RAN applications at an affordable price for the rural communities involved in the project. This means that social objectives take priority over typical performance and/or business drivers adopted by service providers for network deployment. The main aspects considered in the RAN design are the network infrastructure, the network management, and the end-user applications, under the following basic premises: • •
The RAN shall be context-aware, i.e. with knowledge of the available and accessible networks. The system shall be adaptable to network conditions. End-nodes shall take autonomic, dynamic decisions based on the context, expressed in terms of network conditions, timing, operational and/or administrative restrictions, among other aspects. Let's consider each aspect in detail.
A. Network infrastructure The rural environment and the absence of wired infrastructure dictate the usage of wireless and mobile network technologies. Wi-Fi has been chosen because its widespread availability, easy of use, affordability and the usage of unlicensed portion of the radio spectrum. Other ubiquitous technology with presence in the considered area is GSM mobile telephony, which has an incipient deployment of GPRS packet transport, suitable for RAN applications. Mobile devices such as smart-phones and PDAs usually support both technologies, facing challenges such as vertical hand-off and mobility management1. Mobile IP (MIP) concepts [6] may be applied in this context. Given the choice for Wi-Fi, the wireless distribution architecture has been considered. The first option was to implement a Layer 2 Extended Service Set (ESS) based on the deployment of Access Points in the target area. This option requires a careful cell planning based on a detailed knowledge of the coverage area, the number and geographical density of the prospective clients, together with a (potentially costly) backhaul infrastructure. Moreover, a pure Layer 2 solution in a wide area environment may not be adequate due to broadcast processing and delays. On the other hand, mesh networking, based on multi-hop routing, permits an incremental, flexible deployment. New nodes become active based on the availability of adjacent nodes, and no network-wide planning is needed in advance. Moreover, each node cooperates in the transport of the global offered traffic load. On the drawbacks side, the mesh throughput decay as n , where n is the number of nodes [7]. This problem may be tackled down by segmentation of the network; in our case we can clearly build two meshes, one around each town, with approximately 20 nodes each, which permit to sustain acceptable QoS. The 1 A couple of hand-held devices where received by the project as part of the mentioned MSR grant.
aforementioned reasons advise the adoption of a mesh approach. Regarding civil infrastructure, planning issues such as antenna type (directional, omni, other), gain and mast height, stability of power sources in each node location (people's homes), among other factors, determine network-wide stability. B. Network management A network fault in an isolated rural area may disrupt service for several hours to days, due to the lack of local network technicians, which impose long displacements from a central location; again, time and distance are important limitations in this context. Regarding service reliability, the RAN shall behave as an autonomic, self-healing system, capable of reacting to network events in an intelligent fashion, transparently solving the arisen issues without end-user intervention, under network administrators' surveillance. These requirements lead to the adoption of a policy-based management approach, which, generally speaking, defines system behavior according to high-level rules (the policies) expressed by a wise network administrator with a deep knowledge of the underlying reality. Policies impose restrictions and define reactions to network events (e.g. restrict the usage of a traffic-intensive application in the event of a network outage). RAN follows the IETF reference architecture [8]. The Policy Management Tool and the Policy Repository are centralized components, while the Policy Decision Points (PDPs) may be centralized or reside in the network devices, depending on the available computational resources. Finally, the Policy Enforcement Points (PEPs) are device-specific, responsible of local policy execution. In other words, the PEP is a deputy of the network administrator running in the enduser network device, modifying its behavior under the dynamic conditions of the network environment. As mentioned before, RAN incorporate heterogeneous technologies, and may use diverse transport networks managed by third-party service providers, notably the Internet. Managing such non-uniform infrastructure may be accomplish using the AN concept of Network Composition, which stands for the possibility of dynamic and instantaneous delivery of communication services. The AN reference architecture is composed by abstract layers and interfaces that enable generic, technology-independent network composition, using the orchestration capabilities of the Ambient Control Space (ACS), which is an entity that define control and management functionalities of the AN, such as mobility and QoS in roaming scenarios. RAN ACS is restricted to the supported technologies, following a policy-based, client-server approach. A centralized Policy Server gathers information from Clients and Gateways about link sates, traffic load, connection requirements and other relevant network parameters, and generates device-specific policies based on client-specific profiles and global RAN objectives. The client-server communication is implemented using a
common network transport abstraction, realized by IP tunnels over the supported access technologies, such as mesh, GPRS and other forms of Internet access. Such architecture is shown in Fig. 2.
Fig. 2. RAN Management Architecture. IP Tunnels are shown in the network layer, and management relationships in the Ambient Control Space.
Fig. 3. Management System Components. Note that PEP functionality is distributed among several components.
On the client side, RAN implements PEP components and a network device abstraction layer that enables the deployment of the supporting IP tunnels and manages mobility aspects. It is worth to mention that MIP is designed for LAN environments, and uses its inherent broadcast characteristics for the discovery of Foreign Agents (FA) capabilities. Mesh multi-hop networks are different in nature, comprising several broadcast domains; therefore, MIP in such media is a challenging task. After extensively discussing the existing solutions for hand-off and mobility management, we decided to implement a session layer that uses SCTP [9] as underlying technology. SCTP cooperates with lower layers managed by the local policy components. Fig. 3 shows the management components of a generic node, which may be partially implemented, depending on the device resources and function (i.e. client, server, and gateway). SCTP is embedded in the Network Device Abstraction component, which isolate the underlying complexity to legacy IP applications. In other words, applications run unmodified on the RAN-enabled device, with the aggregated functionality of the management system.
RAN basic applications fulfill the present requirements of the community. Once the prototype begin to operate and the users become familiar to the ICTs, we foreseen a growth in network demands. The RAN design space is complex, as shown by the previous analysis. The result of the design process is to deploy a policy-based Ambient Control Space, using mesh, GPRS and the Internet to transport a logical (tunnel-based) network topology, where mobility aspects are considered, using SCTP as underlying technology. Every node participating in the RAN is policy-enabled by a specific-purpose middleware developed by the project. This heterogeneous, incremental infrastructure support a basic set of user applications.
C. Applications The basic set of RAN applications are implemented over a collaborative platform, which permit to deploy new functionalities on the fly, and give native support for news posting, information sharing, and other community-related tools. A productive artisan workflow tool is one of the first to be released. Internet navigation is another basic application supported from the beginning. A non-exhaustive list of prospective applications includes: • Communications servers for local messenger and voice services. • Educative and medical-aid tools, which may also be developed over the collaborative platform.
III. COMMUNITY COST OF RAN OPERATION Optimization objectives in wireless networks usually include performance aspects such as traffic rate and node energy. However, considering the Digital Inclusion objective of RAN, we adopted a different approach. We define Community Cost (CC) as the total cost that the community has to pay for the utilization of the network for each billing period; this is the metric that RAN tries to minimize. This optimization process considers (i) a logical connectivity graph of the network, (ii) a set of applications and their required resources, and (iii) the cost of those resources. Then, this process produces a pruned version of the connectivity graph that minimizes the CC. The logical connectivity graph is conformed by the logical links between end users and “interesting” nodes of the network such as Internet gateways and application servers. Is important to remark that mesh networking is used as a transport media in the RAN; the OLSR [10] routing protocol is used to react to mesh dynamics, i.e. take the micro routing decisions, using typical "hop count" metrics, while the optimization process carried out by RAN takes global optimum routing decisions for each node in the network considering a particular set of applications that are interesting for the community. These decisions are transferred to the devices in the form of routing policies. Policies permit to embed intelligence in the end nodes,
allowing them to change configuration on the fly when changes in the network status are verified. An example routing policy for a particular node M may specify:
=
g1 from 8 A.M. to 8 P.M. g2 the rest of the time
if reach threshold th1, or are down, activate GPRS interface
This policy permit node M to take decisions based in time of the day and traffic conditions, without any further human intervention. Furthermore, in the event of a network outage, it specifies the action to be taken (activate the GPRS interface). It is important to notice that in terms of OLSR metrics, the choice of g1 or g2 may be different than the specified by the example policy. Other aspects of network behavior may be managed by policies, for example, to power-off the Wi-Fi interface of a hand-held device if connected to GPRS or vice versa. Moreover, specific start-up policies are needed when a device attach to the RAN2. A. Optimization Process As stated before, the RAN optimization process aims to minimize CC. This process is based on the expected traffic model of the network and on several cost functions associated with the utilized resources (e.g., Internet access services or hardware depreciation). The costs associated with resources can be computed without major difficulties considering the billing policy of the Internet providers or the hardware price and its life expectancy; however, the traffic model may not be easy to predict with accuracy. In this initial phase of the project, we assume that this model is known. Later, with the network already working, a proper characterization of the traffic model can be periodically carried out off-line, or online as part of a self-tuning process. The cost associated with some of the resources, such as application servers or time-based Internet access, depends on the time of utilization, and the cost of some other resources, typically traffic-based Internet access, depends on the traffic needed for the applications using it. Therefore, we represent the traffic model for a billing period (typically a month) as two functions: • •
Tna, expected traffic for node n and application a during a billing period. Hna, expected connection hours for node n and application a during a billing period.
The cost functions associated with the resources considered are: • • •
TGWg(f), traffic-based cost for using gateway g. HGWg(t), time-based cost for using gateway g. TASa(f), traffic-based service cost for application a.
•
HASa(t), time-based service cost for application a. Service cost is composed by application-related costs, which includes server(s) depreciation, licenses, energy consumption, third-party services, etc. For simplicity, we are assuming that all the application servers of a certain type have identical cost. For the purpose of the optimization process, GPRS connections are considered just another gateway, even though when this interface is used, nodes are connected directly to this service bypassing the RAN mesh infrastructure. Regarding the case of the traffic-based cost function for a gateway connected to a time-based Internet access, this function will take the value 0 for any amount of traffic. The same idea applies to the opposite situation. Fig. 4 shows an example of the type of cost functions used in this project regarding Internet access. That figure depicts the shape of a typical traffic-based cost function TGW(f). The price of using this resource is constant until an accumulated traffic threshold (Traff01) is crossed, then, the price increments linearly with the amount of data sent and received until a second threshold (Traff02) after which, the price of the service is constant again.
Fig. 4. Cost function for ADSL Internet access. Traffic-based pricing, relative to flat rate at the same speed.
Considering the set of nodes N, the set of gateways G and the set of applications A, the logical connectivity graph may be defined by a three-dimensional binary matrix C such that: Cnag = 1, if node n uses gateway g for application a. 0, otherwise. Where 0 ≤ n < N ,0 ≤ g < G ,0 ≤ a < A . A pair cannot be connected to more that one gateway at the same time (note that because we are using tunnels, it is possible to have different gateways for different applications), therefore, C has the constraint: Constraint 1)
2
We specify default routing policies to be used at power up time by network devices.
∑C
nag
=1
g∈G
Finally, the objective function of this optimization process is:
TGWg ∑ C nag × Tna + ∑ n∈N ,a∈A g∈G
CC(C)=
∑ HGWg ∑ Cnag × H na + g∈G n∈N ,a∈A ∑ (TAS a (Tna ) + HAS a (H na )) n∈N ,a∈A The expression enclosed in the first square brackets expresses the total cost after a billing period for using the gateways with traffic-based pricing policy. In an analogue manner, the second expression represents the total cost for the time-based gateways. Finally, the third expression, adds the total service costs for each application and for each node. Additionally, weights may be added to this objective function to give priority to particular nodes, gateways or applications. In the case of pricing policies that vary the price depending on the time of the day or of the week (e.g. low-cost GPRS during nights or weekends), the optimization problem must be sectioned following each of these periods of time and solved in the same manner. This simple model does not consider yet load balancing, therefore, the solution to this optimization problem may route too much traffic through some of the gateways impacting negatively on the quality of service. Further work is needed to overcome this problem. In order to solve the above optimization problem, we are currently experimenting with different techniques for minimizing CC. So far, Genetic Algorithms (GA) is the most simple strategy for this particular problem. B. Genetic Algorithms Optimization For solving the optimization problem presented before using GA, it is needed to encode the space of solutions as arrays and to give a fitness function for those solutions. Creating the arrays is straightforward considering the individuals are a binary three-dimensional matrix and the fitness function is the objective function itself. For creating the arrays, each solution (a particular matrix C) is represented as an array c such that
if C nag =1 then cn× A+ a = g In other words, the array c has a bucket (or gene in GA terminology) for each combination of node and application in the matrix C, and the value at that position is the number of the gateway selected for the application a at the node n. Detailed results can be found in [11]. C. Policy Generation and Distribution Once the optimum matrix C is computed centrally at the Policy Server, it must be translated into individual policies, which should be distributed to the correspondent nodes. This translation process is straightforward; each position Cnag in the matrix determines the following routing rule to be deployed in
node n: if application == a then route via gateway g
Following this strategy, it is possible to detach the computationally expensive global optimization process from the resource-constrained mobile nodes that only have to enforce simple policy rules. The optimization process is carried off-line in a powerful and dedicated node of the RAN infrastructure. IV. IMPLEMENTATION ASPECTS OF RAN. PROOF OF CONCEPT In this section we describe the early RAN implementation characteristics, which take into account the design aspects reviewed in Section II, and present an evaluation of RAN innovative aspects, in particular its capability to implement the social-oriented objectives introduced in Section III. A. Management System RAN policy Server is implemented in Java, using an ad-hoc Information Model loosely-based on the IETF PCIM [12][13]. Persistence is provided by Hibernate [14], which uses a database backend. Witmate Java Logic/Rule Engine [15] has been chosen for the implementation of RAN policy components, due to the inherent portability of Java, and more important, because it can be deployed both in the server side (J2SE/J2EE) and on the mobile devices (J2ME), allowing us to embed both the PDP and PEP functionality in this low resource platform. The PDP is completely build on a logically abstract and technology independent level. Therefore, the policy engine runs at a logical level, and is responsibility of the PEP components to translate the logical decisions to a technology dependent configuration for the real device. We currently support multiplatform PEP components for Windows XP, Linux and Mac OSX, implemented by the execution of a set of system scripts. We are in an early testing phase of a specific middleware for hand-held devices running Windows Mobile. B. Network prototype We built a trial test-bed in order to test the development of the system, while an incremental in-field deployment is being carried out (see subsection IV.C). Let’s consider a sample scenario, which permit to illustrate the process of functional evaluation of the system. Suppose that as a result of the optimization process, the Policy Server generate the following high-level policy: if server == S1 then route via gateway G1 = G2 from 6 A.M. to 8 P.M. G1 the rest of the time
It translates into the Witmate policy listed in Fig. 5. This policy is transferred to the end node using our own simple transport protocol. When the node detects the arrival of a new policy, it is compiled and executed in the embedded PDP and PEP.
192.168.218.0/24 dev eth0 proto kernel src 192.168.218.128 default via 192.168.0.2 dev tunnel2
scope link
Fig. 6. RAN trial scenario. The tunnels tg1 and tg2 are created at start-up time, while tunnel1 and tunnel2 are created as result of the applied policy.
Fig. 5. Example policy for the described scenario
The output of the execution is listed bellow (the bold output corresponds to the PEP): [java] [java] [java] [java] [java] [java] [java] [java] [java] [java] [java] [java] [java] [java] [java]
NEW policy :1481 characters TS: 1172776561452 ini createRuleRuntime TS: 1172776562761 end createRuleRuntime TS: 1172776562761 ini evaluatePolicy EVAL getHoursOfDay OPERATOR EVAL getHoursOfDay OPERATOR EVAL defineRoute OPERATOR EVAL defineTunnel OPERATOR EVAL defineRoute OPERATOR EVAL defineTunnel OPERATOR TS: 1172776563068 end evaluatePolicy TUN create: tunnel1 TUN create: tunnel2 ROUTE create: 164.73.32.3/32 ROUTE create: 0.0.0.0/0
Compiling time: 1309ms Evaluating time: 307ms
At this time the policy has been already enforced. The PEP components in this example are Unix shell scripts; the one that establish the routing entries follows: #!/bin/sh ip route add $1 via $2 dev $3
The resultant logical topology3 is depicted in Fig. 6, and may be verified using system tools which produce the following output:
$ ip tunnel show tunnel2: ip/ip remote 172.16.104.1 local 192.168.218.128 ttl inherit tunnel1: ip/ip remote 192.168.218.1 local 192.168.218.128 ttl inherit $ ip route show 164.73.32.3 via 192.168.0.1 dev tunnel1 3 The policy was evaluated in the 6:00 AM to 8:00 PM timeframe as shown by the timestamps “TS” of the policy execution. The resultant topology is consistent with the time of evaluation.
Note that the generated policy uses network topology information known by the Policy Server. The sample policy is evaluated in the end node when the time events are verified. Other relevant events are network interface status changes, traffic and/or signal level thresholds, among others. C. Network deployment The first stage of network in-field deployment has been completed in March 2007, comprise the following elements, as shown in Fig. 7: • • • • •
Centralized Policy Server. 2 RAN Gateways, one in each CATFRAY location (Totoral del Sauce and Fray Marcos). 2 local wireless clients (one in each location). 2 remote wireless clients (one in each location). GPRS access.
In this stage the only supported service is Internet access, with the objective of testing connectivity and physical aspects, for example antenna mast height, type and gain of antennas, stability of power sources, among others. This first deployment also permit to study the traffic profiles, and more important, to test the community reaction in terms of usability of the network infrastructure. In successive months new nodes and services will be added, biased by the community demands. V. CONCLUSION AND FUTURE WORK The RAN architecture is implementing AN concepts in a particular rural environment, using a policy-based Ambient Control Space to manage heterogeneous network technologies. Policies manage every aspect of RAN, taking advantage of the existing technologies, and enabling a progressive evolution of network deployment. This approach is adequate for remote areas without skilled personnel, and may be applied to other logistic scenarios.
REFERENCES [1]
[2] [3] [4] [5] [6] [7] [8] [9] [10] Fig. 7. RAN first stage deployment - March 2007
The main objective of RAN is to provide an affordable communication platform for the rural communities that participate in the project, applying ICTs to help reducing the so called “digital divide” and using the Community Cost as a metric for network usage optimization. Our early tests show that RAN can effectively take decisions in favor of the community, using social-oriented metrics for routing, which complement the native capabilities of the involved network protocols such as OLSR. Solving the optimization problem and refining the traffic characterization is being undertaken. The manner in which the Community Cost is thereafter distributed between the members of the community is out of the scope of this work. However, it is possible to envision that ensuring the fairness of this distribution will imply research on new monitoring, billing and policing strategies. We have also proposed an alternative, feasible solution for vertical hand-off and load sharing for mobile devices, a middleware based on SCTP, which uses a lightweight PDP/PEP for local management of behavior under dynamic network conditions. The middleware has been already prototyped, and we’re in the process of migration and testing in the target platform (the aforementioned PDAs). Finally, we decided not to consider security aspects at this stage of the project, but we’re very much aware that a tunnelbased infrastructure that uses the Internet and mesh transport may be exposed to many security threats. Access control, traffic, policy and application integrity, denial of service, among several other issues are subject of future work. ACKNOWLEDGMENT The authors would like to thank the CATFRAY community members for the encouragement in the development of this project. Javier Baliosian holds a Marie Curie fellowship given by the European Commission.
[11]
[12] [13] [14] [15]
C. Kappler, P. Mendes, C. Prehofer, P. Pöyhönen and D. Zhou, G. O. Young, “A Framework for Self-organized Network Composition,” in Proc. WAC 2004 : autonomic communication, Berlin, 18-19 October 2004, pp. 139–151. S. Corson, J. Macker, “Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations”. RFC 2501, January 1999. IEEE 802.11 Wireless Local Area Networks. [Online]. Available: http://www.ieee802.org/11/ 3GPP TS 23.060 - General Packet Radio Service (GPRS), 3rd Generation Partnership Project [Online]. Available: http://www.3gpp.org IEEE 802.16 Working Group on Broadband Wireless Access Standards. [Online]. Available: http://www.ieee802.org/16/ C. Perkins, Ed., “IP Mobility Support for IPv4”. RFC 3344, August 2002. Gupta, P.; Kumar, P.R., “The capacity of wireless networks,” IEEE Transactions on Information Theory, vol.46, no.2pp.388-404, Mar 2000. A. Westerinen et al, “Terminology for Policy-Based Management”. RFC 3198, November 2001. L. Ong, J. Yoakum, “An Introduction to the Stream Control Transmission Protocol (SCTP)”. RFC 3286, May 2002. T. Clausen, P. Jacquet et al, “Optimized Link State Routing Protocol (OLSR)”. RFC 3626, October 2003. E. Grampín, J. Baliosian, J. Visca, M. Giachino, L. Vidal, "Wireless Network Architecture for Digital Inclusion in Rural Environments", Udelar Tech Report. [Online]. Available: http://www.fing.edu.uy/inco/proyectos/wan/documentos/RAN_Commun ity_Cost_Technical_Report.pdf. B. Moore, E. Ellesson, J. Strassner, A. Westerinen, “Policy Core Information Model -- Version 1 Specification”. RFC 3060, February 2001. B. Moore, Ed., “Policy Core Information Model (PCIM) Extensions”. RFC 3460, January 2003. Relational Persistence for Java and .NET. [Online]. Available: http://www.hibernate.org/ Witmate Java Logic/Rule Engine, [Online]. Available: http://www.witmate.com/
