Mobile ad hoc network device for mobile teams

CA 02437926 2003-08-20

MOBILE AD HOC NETWORK DEVICE FOR MOBILE TEAMS

FIELD OF THE INVENTION;

This invention relates to network device, and more particularly, to a mobile ad hoc network device for mobile teams.

BACKGROUND OF THE INVENTION:

Creating an air-to-air/air-to-ground wireless network for airborne fire fighting operations is a very new idea that has yet to be developed. Currently, all fire fighting coordination is handled through basic voice communications, which is error prone, often ambiguous, inaccurate, slow, and is less effective for coordinating operations, which causes many safety hazards and poor operational effectiveness.

Ad hoc network has been developed. The ad hoc network is described in US2Q03/0Q602Q2, WO 03/03047, US2003/0091011. However, for applying the ad hoc network to fire fighting services, further improvements are still needed, since those services require handling time-sensitive critical information for coordinating operations such as fire fighting.

It is therefore desirable to provide a new mobile ad hoc network device for mobile teams, which ensures real-time, high speed and effective operations for mobile teams, and allows the teams to coordinate their operations in real time.

SUMMARY OF THE INVENTION:

It is an object of the invention to provide a novel method and system that obviates or mitigates at least one of the disadvantages of existing systems.

In accordance with an aspect of the present invention, there is provided a device for ad hoc wireless network. The device includes: a module for establishing wireless connection with a positioning system to obtain location information; a module for

CA 02437926 2003-08-20 performing communication with a node of the ad hoc wireless network using radio frequency, which is interchangeable, to share the information in the ad hoc wireless network in real time; a module for integrating multiple information including the location information; and a module for self-forming and maintaining the ad hoc wireless network.

In accordance with a further aspect of the present invention, there is provided a system for ad hoc wireless network. The system includes: a platform layer for managing a peer network and managing information; a device layer for performing physical interface to incoming and outgoing information, which includes wireless radio frequency data and location information provided by a positioning system, and for providing the information to the platform layer; a core engine for providing communication between the platform layer and the device layer, which includes a routing engine for self-forming and self-healing the ad hoc network, the platform layer being isolated from the core engine implementation; and an application programming interface for interfacing the platform layer and applications.

Other aspects and features of the present invention will be readily apparent to those skilled in the art from a review of the following detailed description of preferred embodiments in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS:

The invention will be further understood from the following description with reference to the drawings in which:

Figure 1 is a diagram showing a Mobile Ad Hoc Network with Multi-Hopping;

Figure 2 is a diagram showing an example of Traffic View provided by a Traffic

View User Interface in accordance with an embodiment of the present invention;

CA 02437926 2003-08-20

Figure 3 is a diagram showing an example of Operational View provided by an operational User Interface in accordance with an embodiment of the present invention;

Figure 4 is a diagram showing the Operational View of Figure 3, which is displayed with map;

Figure 5 is a diagram showing a final approach to cropping water or retardant on a fire;

Figure 6 is a diagram showing a first example of Instrument View provided by an Instrument View User Interface in accordance with an embodiment of the present invention;

Figure 7 is a diagram showing a second example of the Instrument View of Figure 6;

Figure 8 is a diagram showing a third example of the Instrument View of Figure

6;

Figure 9 is a diagram showing an example of Text View provided by a Text View User Interface in accordance with an embodiment of the present invention

Figure 10 is a block diagram showing an Air Attack Network system in accordance with an embodiment of the present invention;

Figure 11 is a diagram showing an Application platform, an Application and the core of Figure 10;

Figure 12 is a diagram showing an example of the operation of a Routing Engine shown in Figure 10;

Figure 13 is a diagram showing the operation of the Routing Engine of Figure 12 for broadcasting Hello Messages;

Figure 14 is a diagram showing the operation of the Routing Engine of Figure 12 for processing Hello Message;

Figure 15 is a diagram showing the operation of the Routing Engine of Figure for route discovery;

Figure 16 is a diagram showing the operation of the Routing Engine of Figure for processing Route Request;

CA 02437926 2003-08-20

Figure 17 is a diagram showing the operation of the Routing Engine of Figure 12 for processing Route Reply;

Figure 18 is a diagram showing the operation of the Routing Engine of Figure 12 for processing Route Error Message;

Figure 19 is a diagram showing the operation of the Routing Engine of Figure 12 for repairing Broken Route;

Figure 20 is a diagram showing an example of the operation of a Network Wrapper shown in Figure 10;

Figure 21 is a diagram showing an example of the operation of a Network Manager shown in Figure 10;

Figure 22 is a diagram showing an example of the operation of a Transport Wrapper shown in Figure 10;

Figure 23 is a diagram showing an example of the operation of a GSP support shown in Figure 10;

Figure 24 is a diagram showing an example of the operation of GPS services shown in Figure 10;

Figure 25 is a diagram showing the operation for Forestry Fire Fighting provided by the 9GAAN system 100 of Figure 10;

Figure 26 is a diagram showing the operation of Common GUI Operations of Figure 25;

Figure 27 is a diagram showing the operation of a Fire Fighting Engine of Figure 25;

Figure 28 is a diagram showing the operation of an Operational View of Figure 25;

Figure 29 is a diagram showing the operation of a Traffic View of Figure 25. Figure 30 is a diagram showing the terminal device architecture;

Figure 31 is a diagram showing relative Doppler shifts of three nodes.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS:

An Air Attack Network in accordance with an embodiment of the present invention

CA 02437926 2003-08-20 (referred to as 9GAAN) is a system and a method for assisting air and ground crew in remote forest fire fighting which uses radio frequency wireless data connections in a remote self-forming mobile ad hoc data network which does not require the existence of an access point in order to create a complete data network. The terminal device contains a processor, a radio frequency data transceiver device, a location device, a physical screen for data output, the fire fighting Application or other application software and 9GAAN platform software, and the core engine. Figure 30 shows the main components of the terminal device.

Data input is accepted from multiple sources including but not limited to discovery messages, direct connection and connectionless data between devices, positional information such as Global Positioning System (GPS) satellite data or the like, aircraft transponder data or other data such as satellite-derived data, such as weather conditions or the like. Data output includes multiple logical screens including but not limited to the Traffic view, the Operational view, and the “Instrument View” as described below.

The Traffic view shows the location, altitude, velocity and identity of other aerial or ground units.

The Operational view shows critical operational data including but not limited to location and status of the fires, location, water status, direction and speed of aircraft and ground units, and assigned drop locations for aircraft. It permits the interactive user input of instructions and other data through stylus, keyboard, voice, or other means.

The “Instrument View” shows relative bearing, distance, and time to the fire drop location, both visually and numerically, and guides the aerial firefighters to the drop location.

The software implementing network discovery and multi-hop data connection operates by sending datagram messages, which are received by other devices in the

CA 02437926 2003-08-20 vicinity. The datagram contains the network identity, capabilities and communication port and other information with which the receiver may contact the sender. Receivers of the datagram may respond directly to the sender identifying the receiver's network identity, capabilities, communication port, a list of other units' identity data and other information. This data is incorporated in an algorithm in the software creating tables of data connection information enabling the device to communicate efficiently with any device in the vicinity through direct TCP/IP connections.

The routing algorithm removes entries from the routing table if a device in the ad hoc network fails or moves out of range. The network formed by this routing engine is self-forming, self-healing, reliable, and tolerant of failure. The network formed by the routing engine component also implements multi-hopping, whereby a device in the network may forward data between other devices that may not be in range of one another. The instructions and data presented on the device permit remote mobile units to more effectively combat forest fires without the use of central access points.

1. Introduction

The 9GAAN is a Mobile Ad hoc Wireless Network that connects the entire team of aircraft and ground crew with operationally rich information can be shared in real-time at high speed, thus increasing safety, effectiveness, and communications.

The device of the 9GAAN shows the location of all aircraft and ground crew using the system through a graphical traffic view. This would also show transponder equipped aircraft. This increases air safety.

The 9GAAN permits firefighting teams to assign specific drop locations to specific bombers. Nothing improves the team’s fire fighting abilities better than being able to easily pinpoint each water bomber’s drop location with the touch of a screen, and having the bomber able to execute on that without an escort to the drop location.

CA 02437926 2003-08-20

The 9GAAN permits firefighting teams to manage water and retardant availability in real time. Birddogs, which are control aircrafts (also known as Lead Aircraft), can know the water status of all aircraft in real time, so birddogs can more effectively assign the right tankers to the right fires.

The 9GAAN provides, to the device of the 9GAAN, fire locations and status to all aircraft. This fire status is critical information for all aircraft, especially the birddog who manages the team.

The 9GAAN provides, to the 9GAAN device, instrument-like approach views for water bombers, tankers, and helicopters. The RMI-like (RMI: Radio Magnetic Indicator) display (e.g. Instrument View) needle points directly to the assigned fire. There is no need for a birddog escort, Now you can easily get a visual bearing to your drop location.

The display of the 9GAAN device shows bearing, distance, and time to drop location so there is no more guess work about where to drop load.

The display of the 9GAAN device shows a virtual final-approach middle marker just like a regular approach, the fire bomber is alerted two miles out on final approach with a visual and auditory alert.

The “Instrument View” changes color when the user of the terminal device approaches the drop location. For example, ‘‘Red” means don't drop load, indicating that the user is too far out. “Yellow” means get ready, indicating that the user has crossed the middle marker into final approach. “Green” (with auditory alert) means it’s just 10 seconds to the drop location, get ready to drop user’s load on the fire and execute the missed approach. This system helps the user on final approach, even with the user’s head up and eyes out the window.

By combining the latest Handheld Computers, Wireless, and position information

CA 02437926 2003-08-20 such as GPS, enhanced with our proprietary technology, the 9GAAN becomes a wireless computer network between aircraft, enabling the sharing of positional and other critical information in real-time between aircraft. This allows for significantly greater airborne team effectiveness in the fight against fires, thus saving money, increasing safety, and enabling the team to save more trees with fewer resources.

1.1 Key features:

• Connects to standard GPS, transponder or other location device on board • Long Range Traffic Awareness for transponder equipped aircraft • Operationally rich communication for 9GAAN equipped aircraft.

• Works with off-the-shelf Pocket PC and Tablet PC handheld computers as well as other PC devices and Wireless Fidelity (Wi-Fi) or other radio frequency transceivers.

1.2 Key Benefits:

• Increases safety, for both aircraft (through traffic awareness) and ground crew (through precision drop locations) • Increases clear communications through real-time sharing of critical operational information • Increases effectiveness of fire fighting efforts by gaining control of fires quicker thus saving more trees and houses • Increases accuracy of drop locations, while facilitating the approach.

• Lowers cost, by making more efficient use of expensive air attack time

2. Overview of the Air Attack Network

The 9GAAN in accordance with the embodiment ofthe present invention is an ad hoc network in a peer-to-peer (hereinafter referred to as P2P) computing environment connecting aircraft and ground vehicles and crew as well as any other units involved

CA 02437926 2003-08-20 in the firefight. The 9GAAN device also monitors transponder and other data from other aircraft or other vehicles or units in the area.

The intent is for each aircraft to share critical information with other aircraft in a cluster, to increase the operational effectiveness of the team.

There are three kinds of information being shared:

1. Real-time to all aircraft (such as position),

2. Occasional information to all aircraft (such as water status), and

3. Occasional information to one aircraft (such as drop location assignment).

With aircraft operating overextended distances, traveling at high speed, and joining/leaving the network quickly, the network faces several challenges.

2.1 Networking Environment • Peer-to-peer configuration • A cluster of a large number highly mobile nodes • A highly dynamic network (nodes joining/leaving quickly) • Lossy and unreliable communications • No guarantee of a continuous open connection • Extended distances

2.2 Requirements • A peer-to-peer configuration • Multi-hopping enabled to give extended range (multiple routing paths) • Point to multi-point communication to update multiple nodes at once (multi-casting)

CA 02437926 2003-08-20 ♦ Real time communication of data • Robust high-performance transport protocol.

3. Challenges in Wireless Ad-hoc P2P Networks for the 9GAAN

There are several technical challenges that are considered in the design of the 9GAAN architecture.

3.1 Networking

The physical requirements of a wireless data network are much more demanding than those of a wired network. There are limitations on power, available spectrum, network range, channel performance etc. Therefore, less bandwidth is available with more latency, less stability and less predictable availability.

When increasing bandwidth, the power consumption increases, thereby consuming more of an already limited battery life. This reliance on power availability makes it difficult for battery sensitive devices to provide high bandwidth communication. (However, in the case of aircraft installations such as the 9GAAN, there is effectively unlimited power available.)

For an ad hoc wireless link, proximity to other nodes is very important. In a dynamic environment, the distance between nodes will frequently change causing unexpected interruptions in the network. In order for the network to overcome these interruptions, the mobile peers have to be able to anticipate frequent network connection failures (if the peer they are in contact with goes out of range). In addition, there has to be a way of handling broken connections gracefully when they do happen. It may even be necessary to make provision for degraded operation so that the peer remains operational without a network connection. In this case, when a connection is re-established, there either has to be some kind of synchronization scheme or ways to let communication resume from where it stopped.

CA 02437926 2003-08-20

For P2P operation, it is required to route over multi-hop wireless paths. This allows peers to communicate through one or more intermediate peers in a cluster. This has several important advantages:

• It provides communication between cluster peers who are not directly connected.

• When considering limited range wireless communications, such a multi-hopping scheme has the potential to greatly extend the end-to-end communication distance between peers.

• It will allow inter-cluster communication and sharing of information.

• The bit error rate over a wireless channel tends to increase with the distance between nodes. Multi-hopped communication will allow peers to choose a communication path that may be more effective than direct communication.

• With multi-hop routing, any peer could potentially become a bridge to other wired and wireless networks. This peer could then extend applications and services offered by these external networks to the peers in the cluster.

However, multi-hop routing is dependent on peer availability. The topology of a mobile network can quickly change as peers move in and out of connectivity. As a result, established multi-hop routing paths are not guaranteed to exist for any period of time. This presents the following technical challenges:

• Routing paths must be updated frequently • Information regarding changes to the network topology must reach those nodes affected.

• The network must respond and recover from routes broken in mid-connection, i.e., a new route is quickly determined and the end-to-end connection is not lost.

• The network must constantly be aware of the topology to ensure that only the most efficient routes are used.

CA 02437926 2003-08-20

The 9GAAN meets the above technical challenges as described below.

3.2 Limitation on Mobile Devices

Mobile devices generally provide a limited computing environment when compared to standard desktop computers. As described below, fundamental limitations on CPU power, memory, storage, battery life, screen size, and input devices are overcome in achieving the operational performance required by the 9GAAN.

3.3 Naming

Because of the self-organizing nature of the network, a naming service has to be implemented for peer management. Standard Domain Name Services (DNSs) are assumed to be unavailable in a remote network, however edge detection system will bridge to DNS servers if available. Also, not all mobile devices support IP networking. Some may not even have IP addresses.

The traditional Dynamic Host Configuration Protocol (DHCP) service is not available in a remote ad hoc network. The 9GAAN supports a distributed DHCP algorithm which allocates unique IP addresses in a remote cluster.

3.4 Resource Discovery

The highly dynamic nature of an ad-hoc P2P network requires cluster nodes to be capable of detecting changes to peer resources. Algorithms detect the presence/absence of other peers and service information is shared as needed.

3.5 Data Sharing and Synchronization

Since we have a highly decentralized distributed system with weakly connected

CA 02437926 2003-08-20 mobile nodes, cooperation presupposes that some schemes should exist for data sharing and synchronization. Since peers may only establish pair-wise connections, we need them to have high availability, and be consistent and timely in routing data packets along the network. This can present quite a challenge when peers move in an unpredictable manner.

3.6 Session Management

At the connection level, it is required to address the issue of session management. In particular, the 9GAAB defines how precisely sessions are set up and maintained, and how precisely past collaboration sessions, which may have been incomplete, are re-established.

4. Background to the Invention

The primary technologies involved in the 9GAAN are the Wireless Local Area Networking (WLAN), the Global Positioning System (GPS) or similar location technology, handheld computing, and air-to-air data networking.

The airborne data network makes use wireless radio technology to connect multiple aircraft in a peer-to-peer fashion. The wireless interfaces used are complimented by a system of antennas, amplifiers, filters, and other technologies necessary to provide sufficient spatial distribution of the signal around the aircraft and a greatly extended communications range. This range is enhanced by the use of multi-hop routing between nodes in the network. In such a scenario, intermediate nodes are used to relay communications between nodes that are out of direct contact range.

Although still in its infancy wireless WLAN technology is mature enough to be available as an off-the-shelf product for standard in-office uses. The technology is still being defined and developed to push its abilities further; we use it in an airborne fire fighting scenario.

CA 02437926 2003-08-20

GPS has matured and is readily available. The 9GAAN system integrates the information provided by GPS, or the like.

With the introduction of the Pocket PC, handheld computing has progressed to the point where we can build enterprise level solutions on top of this hardware platform. This technology provides a distinct advantage in the area of high-performance mobile handheld computing.

Creating an air-to-air wireless network for airborne fire fighting operations is a very new idea. Currently, air-to-air fire fighting coordination is handled through basic voice communications, with little ability to share critical information in real-time that would increase safety and team effectiveness while saving money and trees.

The use of WLAN with position information such as GPS and the Pocket PC platform to create an air-to-air data network is a new technology for the airborne fire fighting industry. It introduces a new level of capabilities that were not possible before. The 9GAAN provides a technology driven fire fighting solution that will far surpass the current method of using voice communication.

The 9GAAN can use any RF interchangeably depending on the application. The initial embodiment uses 802.11b and 802.11g at 2.4GHZ for its high speed transmit rate. Although this wireless technology has been used in several short-range, indoor, inter-office applications, the 9GAAN use it in applications that push its limits. By extending the range to 5-10 miles instead of the usual 300 feet, integrating the technology into fast moving aircraft instead of stationary terminals, and using 5-20 peers that form a highly dynamic network cluster, the 9GAAN are pushing the performance limits of the specification. This creates many technical challenges as extended distance is uncommon in wireless technology between aircraft has not been documented, and the use of 2.4GHz technology is rare in small aircraft.

CA 02437926 2003-08-20

The embodiment is based on 1) FCC 15.247 that limits the power used for IEEE 802.11b operations; and 2) the aircraft airworthiness regulations that affect the ability to use 2.4 G Hz RF in aircraft. Both of these are strictly adhered to in creating this solution.

CA 02437926 2003-08-20

5. User Interfaces

Figure 1 shows Mobile Ad Hoc Network (9GAAN) with Multiple-Hopping in accordance with the embodiment of the present invention. A device 10 for the 9GAAN is disposed on each aircraft. The 9GAAN device 10 has a number of User Interfaces, which display information relevant to a particular situation or participant in firefighting.

For example, the User Interfaces includes a Traffic View User Interface, an Operational View User Interface and an Instrument View User Interface, which provide Traffic view”, “Operational View”, and “Instrument View” on the display of the 9GAAN device 10.

The Traffic view shows the location, altitude, velocity and identity of other aerial units. The Operational view, shows location and distance ofthe fire as well as other aerial and ground units, and shows other data including but not limited to water status, direction, velocity, location, drop locations, fire status and location at various fire points and in addition permits the interactive user input of directions through stylus, keyboard, voice, or other means, of instructions to various mobile and ground units.

The “Instrument View” shows relative bearing to the fire drop, and guides the aerial firefight to the drop zone. The “Text View” shows location and connectivity data in a textual format.

5.1 Traffic View User Interface

Figure 2 shows an example ofthe Traffic View provided by the Traffic View User

Interface. The Traffic View of Figure 2 shows location data of the local unit and other units in the network.

CA 02437926 2003-08-20

Local:

• Speed in Knots shown in top left corner • Magnetic course shown in center of top row • Altitude in Feet shown in top right corner

Remote:

• The remote unit is shown as green flashing dots or other visual indicators.

• Magnetic course of remote vehicle shown as a line pointing in direction of movement, originating at the dot for that vehicle.

• Speed in Knots of remote vehicle is displayed numerically just below the graphic for that vehicle.

• Relative distance in Nautical Miles from the local to the remote vehicle is displayed numerically to two decimal places just, below the speed of that remote vehicle.

• Relative altitude in Hundreds of Feet is shown just above the graphic for that vehicle (e.g. 01 = 100 feet above local vehicle, -02 = 200 feet below local vehicle)

General:

• Units are

1) Nautical Miles for distance,

2) Knots for speed,

3) Feet for altitude.

Anticipate the need for having manually adjustable units at a later iteration (e.g.

statute miles, km, etc). Two distance rings should be shown. Outer ring radius = 2 times inner ring radius. The inner ring is 1/16 of an NM. Each distance ring should show radius in text format (e.g. 2NM). The rings do not rotate. There are no tick marks

CA 02437926 2003-08-20 needed on the rings. The scale of display should be manually adjustable, and have an on-screen control in the lower right corner. Scale should be adjustable to 0.25, 0.5, 1.0, 1.5, 2.0, 3.0 nautical miles for inner ring.

· If a remote vehicle moves off the screen, “OFF SCREEN, and ADJUST

SCALE shows up in bottom left corner to alert user.

5.2 Operational View User interface

Figure 3 shows an example of the Operational View provided by the Operational View

User Interface. The Operational View of Figure 3 shows location and identity of aircraft on the network as well as fire locations encoded by intensity. This view is interactive, allowing firefighters to note new fire locations and for the birddog to direct aircraft to fire locations.

5.3 Operational View User Interface with Map

Figure 4 shows an example of the Operational View with a map. As shown in Figure 4, a map may be superposed on the Operational View to show terrain or infrared maps, topographical data or other maps or background data, which may assist in visualization.

5.4 Final Approach

Figure 5 shows a final approach to cropping water or retardant on a fire. The distance to the drop location is encoded by color or other indicators, which is used in the Instrument View described in Figures 6-8.

5.5 Instrument View User Interface - Don't Drop Zone

Figure 6 shows an example of the Instrument View provided by the Instrument View

CA 02437926 2003-08-20

User Interface. The View of Figure 6 shows location, bearing and proximity to drop as color encoding. Specific color, such as Red, is displayed at a center area, which indicates the “Don't Drop Zone”.

5.6 Instrument View User Interface - Get Ready Zone

Figure 7 shows a second example of the Instrument View provided by the Instrument View User Interface. The View of Figure 7 shows location, bearing and proximity to drop as color encoding. Specific color, such as Yellow, is displayed at the center area, which indicates the “Get Ready Zone”.

5.7 Instrument View User Interface - Drop Alert

Figure 8 shows a third example of the Instrument View provided by the Instrument View User Interface. The View of Figure 8 shows location, bearing and proximity to drop as color encoding. Specific color, such as Green is displayed at the center area, which indicates the “Drop Zone”.

5.8 Text View User Interface

Figure 9 shows an example of the Text View provided by the Text View User

Interface. The View of Figure 9 shows data for both local and remote devices in a textual format.

The references in Figure 9 are as follows:

Distance: In Nautical Miles, to two decimal points, “nm” following data Location: In degrees, minutes, and seconds, with space between degrees and minutes, and decimal place between minutes and seconds.

Velocity: In Knots, to one decimal point, with “kts” following data.

Course: In Degrees Magnetic, no decimal points. “Crs: before data, “mag” following

CA 02437926 2003-08-20 data.

Altitude: In feet, no decimal points, “ft” following data.

6. 9GAAN Architecture

The architecture of the 9GAAN of the present invention is now described in detail. The 9GAAN system 100 of Figure 10 is designed to operate within a cluster of several nodes, each of which we refer to as the peer in the 9GAAN. It is understood that the architecture is identical at each of the peers and that the peers in the 9GAAN community communicate via an ad hoc wireless network.

Figure 10 shows an embodiment of the mobile ad hoc network system (9GAAN system) 100. The 9GAAN system 100 includes a hierarchy of layers that are identified as follows (see Figure 1 and the accompanying discussions for more details).

• Device Layer 102 - The physical interface to incoming and outgoing information • Core Engine 104 - Provides communication between a Platform layer 106 and the Device layer 102 • Platform 106 - Manages the peer network and handles all aspects of information management.

• AP1108 - The interface to an application layer 110.

6.1 Architecture Overview

The architecture implements the core network-centric computing technology, which provides a set of simple lightweight and flexible protocols/services to support P2P collaboration across an ad hoc wireless network which links the mobile ad hoc network peers.

The architecture has been organized to allow for maximum versatility. The division

CA 02437926 2003-08-20 into the layers outlined above ensures that any changes made to the implementation of a particular layer will not affect the Platform 106 of the 9GAAN 100. This is particularly important when considering the bottom two layers. Within the Device Layer 102, the communication interfaces will initially be implemented as stand alone third party components. These interfaces may be replaced by other technologies. Due to the design of the 9GAAN system 100, these changes can be absorbed within the Core Engine 104, unknown to the Platform 106 or higher layers. Changes to the network and transport protocols employed within the Core Engine 104 may also be required. Again, the Platform 106 and higher layers will not be affected, as they remain isolated from the details of the Core Engine 104 implementation.

6.2 Device Layer

The Device Layer 102 includes a Link/Physical layer 112 and a GPS Receiver or similar Positioning Receiver 114.

Link/Physical 112: This is the base layer for wireless communications. It handles the physical transmission and receipt of radio signals between end users as well as offering link layer support for point to point and point to multi-point communications. This layer accesses all higher layers in the architecture model through a driver interface. This design allows the platform independence from the particular radio technology implemented at this level.

Positioning Receiver 114: Provides position information to the platform in the form of formatted sentence types. A common positioning receiver is GPS. Currently, most hand-held GPS receivers support the NMEA 0183 standard. Popular aviation receivers built by Garmin use a similar format called the Aviation Data Format.

6.3 Core Engine

The 9GAAN system 100 is an executable running as a service or daemon. It provides

CA 02437926 2003-08-20 the mobile ad hoc networking for the 9GAAN devices and P2P platform support.

The Core Engine 104 includes a Network layer 116, a Routing Engine 118, a Network Wrapping layer 120, a Transport layer 122 and a Positioning Support layer 124.

Network 116: The Network layer 116 is responsible for moving transport layer segments from one host to another. It must support point-to-point duplex communication between neighboring nodes. The Network layer 116 is easily replaced in our architecture design as all interaction with other layers takes place through predefined interfaces.

Routing Engine 118: The Routing Engine 118 is responsible for forming ad hoc networks over highly mobile notes. It discovers and maintains routes between any of the pre-defined nodes in a network.

Network Wrapper 120: The Network Wrapper layer 120 is a predefined interface between the Network and Network Manager layers. It provides a standard set of API's so that all network layer details are hidden from the Network Manager. This ensures that the platform will function independent of the network protocol implemented.

Transport 122: The transport layer 122 is responsible for passing all forms of data between the application layer and the network. This layer should offer a minimum of the following two services: a connectionless asynchronous transport service for time sensitive data transfer, and a connection-oriented service for reliable data transfer.

Positioning Support 124: The Positioning Support layer 124 parses and processes position information. It is responsible for both local position information passed from a positioning receiver such as a GPS receiver, and remote positioning information that arrives over the wireless network. The Positioning Support layer passes all processed information to the Positioning Services layer to be used by the platform.

CA 02437926 2003-08-20

6.4 Platform

The Platform 108 includes a Network Manager 126, a Transport Wrapper layer 128, a Message layer 130 and a Positioning Services layer 132

Network Manager 126: The Network Manager 126 will maintain a table of all current network information (node ID's and related IP addresses, and other information useful for management of the network). Its main duties are to discover nodes, exchange network information, oversee the addition and deletion of network nodes, handle the configuration of network settings, and update and broadcast the presence of all nodes accessible to the network. The Network Manager 126 includes the following services:

Naming/ldentity/Addressing service: Maintains a peer’s identity, uses a network management protocol to communicate with other peers and exchange network information.

Neighborhood service: Up to date information about peers within range in order to enhance the task of resolving peer identity.

Session management service: Maintain the collaborative service for initiating, terminating and restoring P2P sessions.

History: A cache of Information about the activities of a peer: how routes to a peer were established, the content of previous data communicated between peers, etc.

Transport Wrapper 128: The Transport Wrapper layer 128 is a predefined interface between the actual Transport layer and higher layers. It provides a standard set of

API's that can be accessed by an application directly, or through the Messaging layer

130. The purpose of this layer 128 is to keep all details of the Transport layer 122.

CA 02437926 2003-08-20 implementation abstract from higher layers.

Messaging 130: The Messaging layer 130 is used forexchanging system information between peers. This includes the GPS, network, and status information of peers. Since there are multiple message types, messages are encoded in XML so that they can be easily sorted and processed. The Messaging layer 130 can also provide services to the application layer, and could potentially be used to remotely invoke methods and objects.

Positioning Services 132: The Positioning Services layer 132 manages all position related information pertaining to each node in the network. The Positioning Services layer 132 is not an integral part of the network, therefore it maintains a separate information database or table from that of the Network Manager 126. This information is indexed by node ID.

6.5 API Layer

The APL layer 108 includes an API 134.

AP1134: Interacts with the application and functions as a call stub in the application address space. It will communicate with the 9GAAN system 100 via inter-process communication or some other mechanisms to protect the 9GAAN system 100.

The API layer 108 can be expanded to become Application Platform 134A of Figure 11. The Application Platform 134A of Figure 11 can serve as a staging of the solution, allowing us to begin marketing a complete solution iri a staged fashion, starting with the simple Level 1 and moving to the greater complexity of Level 4.

This Application Platform 134A sits on top of the Core Platform 140 of the 9GAAN system 100 (Core 9G Platform). The Application Platform 134A is used and/or provided as an API (134) to allow for rapid application development.

CA 02437926 2003-08-20

6.6. Routing Engine

The following is the use case diagram for the Routing Engine 118 of Figure 10. Figure 12 shows an example of the operation of the Routing Engine 118.

6.6.1 Actors

6.6.1.1 User

The User actor 200 of Figure 12 is a human user of the Routing Engine.

6.6.1.2 Transport

The Transport actor 22 of Figure 12 represents the transport system. The transport system sends and receives data through the network. It allows the 9GAAN Routing Engine 118 to send and receive control packets through the network.

6.6.2 Use Cases

6.6.2.1 Manage Route Table

This use case provides the capability to manage the route table for the Routing Engine 118. It begins when the route table needs to be accessed. The activities are:

• FIND ROUTE • ADD ROUTE • UPDATE ROUTE • DELETE ROUTE • MAINTAIN ROUTE TABLE

CA 02437926 2003-08-20

6.6.2.2 Log Routing Engine

This use case begins when the User actor 200 chooses to enable logging the routing engine. It ends when the routing engine is stopped or the User actor 200 chooses to disable logging the routing engine. The activities are:

• ENABLE/DISABLE LOGGING ROUTING ENGINE

6.6.2.3 Start/Stop Routing Engine

This use case begins when the Routing Engine 118 starts/stops. It ends when the operation is completed with or without success.

6.6.2.4 Process Routing Message

This use case begins when the Transport actor 202 receives a routing message and asks the routing engine to process it. The use case ends when the routing message is processed with or without success. The activities are:

. PROCESS ROUTING MESSAGE

PROCESS ROUTING MESSAGE

The Transport actor 202 receives a routing message on the predefined port and calls the routing engine to process the routing message. The routing engine parses the routing message and determines what to do based on the routing message type. The details of decision making are specified by the actual routing protocol and are not known at the generic routing engine abstraction level.

6.6.2.5 Maintain Local Connectivity

CA 02437926 2003-08-20

This use case begins when the Routing Engine 118 receives a hello message or it is the time to maintain connectivity status to its neighbors. The use case ends when the operation completed with or without success. The activities are:

• BROADCAST HELLO MESSAGE . PROCESS HELLO MESSAGE . MAINTAIN LOCAL CONNECTIVE • UPDATE BLACKLIST

The Routing Engine 118 maintains the connectivity to its active neighbors. If it does not receive any packets from a neighbor, it assumes that the link to the neighbor is lost. It will first try to repair the affected routes by starting the Discover Route use case. If the operation fails, it will broadcast a route error message by starting the Handle Route Error use case.

Figure 13 shows the operation of the Routing Engine 118 of Figure 12 for broadcasting Hello Message. Figure 14 shows the operation of the Routing Engine 118 of Figure 12 for processing Hello Message.

6.6.2.6 Handle Route Error

This use case begins when a route error condition arises. The use case ends when the route error is handled. The activities are:

. HANDLE BROKEN LINK • HANDLE UNREACHABLE DESTINATION . PROCESS ROUTE ERROR MESSAGE

6.6.2.7 Route Discovery

This use case begins when the Transport actor needs to find a new route to a given

CA 02437926 2003-08-20 destination or the existing route is invalid. It ends when the operation is completed with or without success. The activities are:

• DISCOVER ROUTE · REPAIR BROKEN ROUTE

DISCOVER ROUTE

Figure 15 shows the operation ofthe Routing Engine 118 for discovery Route.

The Routing Engine 118 first tries to find a valid route to the given destination from the route table. If the destination is found, the use case ends. Otherwise, the Routing Engine 118 tries to build a route request and broadcasts the request. It then waits for the corresponding route reply and uses the reply to create or update the route entry in the route table. If the Routing Engine 118 does not receive the route reply within certain period of time, it tries to re-broadcast a new route request. The Routing Engine 118 repeats the re-broadcast until it gives up.

REPAIR BROKEN ROUTE

A destination may be unreachable caused by broken link to the next hop. A special route discovery activity occurs when a broken route is being repaired.

6.6.2.8 Process Route Request

This use case begins when the routing engine receives a route request. The use case ends when the route request is processed with or without success. The activities are:

DROP ROUTE REQUEST FORWARD ROUTE REQUEST GENERATE ROUTE REPLY

CA 02437926 2003-08-20

Figure 16 shows the operation of the Routing Engine 118 of Figure 12 for processing Route Request.

6.6.2.9 Process Route Reply

This use case begins when the routing engine receives a route reply. The use case ends when the route reply is processed with or without success. The activities are:

• UPDATE ROUTE . FORWARD ROUTE REPLY

Figure 17 shows the operation of the Routing Engine 118 of Figure 12 for processing Route Reply.

6.6.2.10 Process Route Error Message

This use case begins when the routing engine receives a route error message. The use case ends when the route error is processed with or without success. The activities are:

• UPDATE ROUTE • FORWARD ROUTE REPLY

Figure 18 shows the operation of the Routing Engine 118 of Figure 12 for processing Route Error Message.

6.6.2.11 Repair Broken Route

This use case begins when a route error condition arises and the routing engine opts to repair the affected route. The use case ends when the route repair is completed

CA 02437926 2003-08-20 with or without success. The activities are:

REPAIR BROKEN ROUTE

Figure 19 shows the operation of the Routing Engine 118 of Figure 12 for repairing Broken Route.

6.6.2.12 Control Route Request Dissemination

This use case begins when the routing engine needs to broadcast a route request. It uses some algorithm to control the amount of network traffic caused by route discovery messages. The use case ends when the route request is built for broadcast. The activities are:

• CONTROL ROUTE REQUEST DISSEMINATION

6.6.2.13 Update Route to Previous Hop

In this use case, the routing engine tries to establish or update a route to the previous hop based on the received routing message.

1. Preconditions

a. The Transport receives a routing message.

b. The underlying link layer supports bidirectional communications.

2. Main Flow

This use case begins when the routing engine receives a route message. The use case ends when a route is established to the previous hop or the operation fails. The preconditions are:

CA 02437926 2003-08-20 • The Transport receives a routing message • The underlying link layer supports bidirectional communications

The activities are:

• UPDATE ROUTE TO PREVIOUS HOP

UPDATE ROUTE TO PREVIOUS HOP

The Transport actor 202 receives a routing message. It calls the routing engine to parse the routing message. Upon successful parsing, the Routing Engine 118 tries to establish a route to the previous hop where the routing message is from. The concrete route update is specific to the actual routing protocol and the details are not known at the generic routing engine abstraction level.

6.7 Network Wrapper

The following is the use case diagram for the Network Wrapper 120 of Figure 10.

As shown in Figure 20, the operation of the Network Wrapper 120 includes: Get Routes; Add Route; Update Route; Delete Route and Get Interfaces.

6.7.1 Actors

6.7.1.1 User

The User actor 200 is a human user of the 9GAAN Airborne Fire Fighting System or an external system.

6.7.2 Use Cases

CA 02437926 2003-08-20

6.7.2.1 Get Routes

This use case is started when the User actor 200 chooses to get route entries from the native route table for a given destination, gateway, and interface.

6.7.2.2 Add Route

This use case is started when the User actor 200 chooses to add a route entry to the native route table for a given destination, gateway, and interface.

6.7.2.3 Update Route

This use case is started when the User actor 200 chooses to update a route entry (gateway and interface) in the native route table.

6.7.2.4 Delete Route

This use case is started when the User actor 200 chooses to delete a route entry from the native route table.

6.7.2.5 Get Interfaces

This use case is started when the User actor 200 chooses to get all the network interfaces on the native operating system.

6.8 Network Manager

The following is the use case diagram for the Network Manager 126 of Figure 10.

As shown in Figure 21, the operation of the Network Manager includes: Add note;

Update Note; Remove note; Register Network Manager Clients; and Notify Network

Changes.

CA 02437926 2003-08-20

6.8.1 Actors

None.

6.8.2 Use Cases

6.8.2.1 Add Node

This use case is started when a new node is detected. Its IP address is assigned and broadcast across the cluster.

6.8.2.2 Update Node

This use case is started when the node receives network information from its peer. They negotiate IP addresses and broadcast the results.

6.8.2.3 Remove Node

This use case is started when a node in the cluster is found unreachable and the information is broadcasted to remove the node from the cluster.

6.8.2.4 Register Network Manager Clients

This use case is started to register/unregister Network Manager clients for receiving network info update messages.

6.8.2.5 Notify Network Changes

This use case is started to notify the registered Network Manager clients of network changes (node addition, removal, and update).

CA 02437926 2003-08-20

6.9 Transport Wrapper

The following is the use case diagram for the Transport Wrapper 128 of Figure 10. As shown in Figure 22, the operation of the Transport Wrapper 128 includes; Create passive socket; Create socket; Accept connection requests; Connect; Send/Receive datagrams; Send/Receive stream data. The transport wrapper passes the data in theses requests to the network layer for transmission over the radio data network. A socket address is a TCP/IP network address which provides addressing to particular devices on the network.

6.9.1 Actors

6.9.1.1 Application

The Application actor 204 is an application that is built on the 9GAAN platform.

6.9.2 Use Cases

6.9.2.1 Create Passive Socket

This use case is started to create a passive socket for service connection pointer.

6.9.2.2 Create Socket

This use case is started to create a generic socket for communication end point. Two types of sockets can be created - stream and datagram sockets.

6.9.2.3 Accept Connection Requests

This use case is started to accept connection requests.

CA 02437926 2003-08-20

6.9.2.4 Connect

This use case is started to connect to a well-known communication port on a specified host.

6.9.2.5 Send/Receive Datagrams

This use case is started to send and receive datagrams.

6.9.2.6 Send/Receive Stream Data

This use case is started to send or receive stream data over a TCP connection.

6.10 Positioning Support

The following is the use case diagram for the Positioning Support 124 of Figure 10. As shown in Figure 23, the operation of the Positioning Support includes: Get GPS NMEA sentences; and Parse NMEA sentences from GPS receivers.

6.10.1 Actors

6.10.1.1 Positioning Receiver

The Positioning Receiver actor 206 represents the positioning receiver system. It allows the 9GAAN system to receive positioning information from the satellite or other sources.

6.10.2 Use Cases

CA 02437926 2003-08-20

6.10.2.1 Get NMEA Sentences

This use case is started to communicate with a GPS Receiver and retrieve GPS NMEA sentences.

6.10.2.2 Parse NMEA Sentences

This use case is started to parse NMEA sentences and extract the GPS info. It is used by other use cases for GPS support.

6.11 Positioning Services

The following is the use case diagram for a Positioning Service 132 of Figure 10. As shown in Figure 24, the operation of the Positioning Services 132, from a GPS receiver for example, includes: Get GPS info; Update Network Info; Start/Stop GPS Services; register GPS Services Clients; Update Local GPS Info; Notify GPS Changes; Update Remote GPS Info; and Broadcast GPS Info.

6.11.1 Actors

6.11.1.1 Positioning Receiver

The Positioning Receiver actor 206 represents the Positioning receiver system. It allows the 9GAAN system to receive position information from a satellite, for example.

6.11.2 Use Cases

6.11.2.1 Get GPS Info

This use case begins when the client retrieves GPS information for a specified node.

CA 02437926 2003-08-20

6.11.2.2 Update Network Info

This use case is started to update network info from the Network Manager 126 of Figure 10.

6.11.2.3 Start/Stop Positioning Services

This use case begins when the administrator chooses to start/stop the Positioning Services. It ends when the operation is completed with or without success.

6.11.2.4 Register Positioning Services Clients

This use case is started to register/unregister Positioning Services clients for receiving positioning information update messages.

6.11.2.5 Update Local Position Info

This use case is started to retrieve and process local position information from the Positioning receiver such as a GPS receiver 206 periodically at a pre-configured frequency. It then notifies the registered clients of position information changes and broadcasts the local position info to all the nodes in the cluster.

6.11.2.6 Notify Position Changes

This use case is started to notify all the registered Position Services clients of position information changes. It ends when the operation is complete.

6.11.2.7 Update Remote Position Info

This use case is started to update remote Position information on the network. It

CA 02437926 2003-08-20 receives and processes position information from remote nodes. It then notifies the registered clients of position info changes.

6.11.2.8 Broadcast Position Information

This use case is started to broadcast the local position information to all the nodes in the cluster.

7. Forestry Fire Fighting

The following is the use case diagram for the Forestry Fire Fighting. Each individual package contains its own use case diagram. Figure 25 shows the operation for Forestry Fire Fighting provided by the 9GAAN system 100 of Figure 10.

7.1 Common GUI Operations

The following is the use case diagram for the Common GUI Operations of Figure 25. Figure 26 shows the operation of the Common GUI Operations shown in Figure 25.

7.1.1 Actors

7.1.1.1 User

The User actor 200 is a human user of the 9GAAN Airborne Fire Fighting System or an external system.

7.1.2 Use Cases

7.1.2.1 Zoom

This use case begins when the User actor 200 chooses to change the GUI display

CA 02437926 2003-08-20 scale. The screen adjusts to display according to the selected zoom. Or the system is configured to automatically select the zoom to display all the nodes in the cluster. This use case may apply to multiple views.

7.1.2.2 Display Terrain Info

This use case starts when the User actor 200 chooses to display the terrain information and the system displays it in the background with the correct coordinates.

7.2 Fire Fighting Engine

The following is the use case diagram for the Fire Fighting Engine of Figure 25. Figure 27 shows the operation of the Fire Fighting Engine shown in Figure 25.

7.2.1 Actors

7.2.1.1 User

The User actor 200 is a human user of the 9GAAN Airborne Fire Fighting System or an external system.

7.2.2 Use Cases

7.2.2.1 Update Aircraft Profile

This use case is started to update the aircraft profile (aircraft type). When a new (remote) aircraft enters the network or an existing one leaves, the corresponding profile in the system needs update. The other scenario is for the User actor to set the aircraft profile manually or automatically and the aircraft profile info is broadcast.

CA 02437926 2003-08-20

7.2.2.2 Update Fire Info

This use case begins when the User actor 200 updates fire information or the system receives a fire info update broadcast. Fire info includes fire location and status (fire, smoke, out). If the User adds or removes a fire spot, the fire information change gets broadcast to all the aircraft in the network. When the local aircraft receives a fire info change, it will update the fire information in the system and display the information accordingly.

7.2.2.3 Update Aircraft Status

This use case begins when status of an aircraft (water status) has changed or the update info has been received. The User actor 200 may cause aircraft status changes. The info is broadcast to all the aircraft in the network cluster. When the local aircraft receives an aircraft status update, it will update the system about the associated aircraft and carry out the display accordingly.

7.2.2.4 Update Assignment Info

This use case begins when assignment information has changed. An aircraft may have accepted a new fire fighting assignment or dropped one. It may have received fire fighting assignment info over the network. The fire fighting assignment includes information on the fire location and assignee.

7.2.2.5 Manage Assignments

This use case starts when the User actor 200 assigns a fire-fighting task to an aircraft (may be the local). The assignee either accepts or rejects the assignment. If it accepts, the assignee broadcasts the assignment information (task and aircraft). The fire fighting assignment activity involves a sequence of client/server request/response exchange between the assigner and assignee.

CA 02437926 2003-08-20

7.2.2.6 Broadcast Operational Info

This use case is started to broadcast fire fighting information to all the nodes in the network. It uses the Messaging services to create XML documents and broadcast them.

7.3 Operational View

The following is the use case diagram for the Operational View of Figure 25. Figure 28 shows the operation of the Operational View shown in Figure 25.

7.3.1 Actors

7.3.1.1 User

The User actor 200 is a human user of the 9GAAN Airborne Fire Fighting System or an external system.

7.3.2 Use Cases

7.3.2.1 Display Aircraft Operational Info

This use case begins whenever the position information, status, and profile of an aircraft have changed. This use case extends the Display Aircraft Traffic Information use case. It displays different images to show aircraft types. It uses color code to show the aircraft water status (green = full, red = empty).

7.3.2.2 Display Fire Info

This use case begins when fire information (location, status, and assignment) has

CA 02437926 2003-08-20 changed. It displays fire location relative to the local aircraft and fire status (fire = red, smoke = yellow, out = green).

7.3.2.3 Display Aircraft Assignments

This use case starts when fire fighting assignment info has changed. It displays the type of fire fighting tasks, aircraft responsible, and the status of the tasks. It uses dotted lines between aircraft and fire spots to indicate the fire fighting task assignments.

7.4 Traffic View

The following is the use case diagram for the Traffic View of Figure 25. Figure 29 shows the operation of the Traffic View shown in Figure 25.

7.4.1 Actors

7.4.1.1 User

The User actor 200 is a human user of the 9GAAN Airborne Fire Fighting System or an external system.

7.4.2 Use Cases

7.4.2.1 Display Distance Rings

This use case starts when the User actor 200 chooses to display distance rings. The screen displays distance rings to facilitate the User actor 200 to judge positions of nodes in the cluster.

CA 02437926 2003-08-20

7.4.2.2 Display Danger Level

This use case starts when the User actor 200 chooses to display danger level of other aircraft in the cluster. If another aircraft is considered in a collision course, it will be displayed differently to indicate to the User actor 200 of danger of different levels.

7.4.2.3 Display Aircraft Traffic Info

In this use case, position information of aircraft (location, altitude, speed, course, and climb) is displayed. The local aircraft image is displayed in the center ofthe screen and points to its course of motion. The position information text ofthe local aircraft is displayed in the top part ofthe screen. The remote aircraft are displayed as moving dots in the screen, with their location relative to the local aircraft. The directions of motion ofthe remote aircraft are expressed as a lines originating from the dots. The speed, distance, and altitude ofthe remote aircraft are displayed as texts moving along with the dots. The use case begins when position information of any ofthe aircraft in the cluster is updated.

8. Alternate Embodiments ofthe Invention

8.1 Emergency Response

Alternately the invention may be used for emergency response applications. In this embodiment ambulances and fire engines form a mobile ad hoc network for aiding in emergency situations. The display in this embodiment shows other emergency vehicles at the emergency scene, transmits positional and other data to coordinate rescue efforts.

8.2 Police Patrols

Alternately the invention may be used to coordinate police work such as coordinated

CA 02437926 2003-08-20 chases or the like. In this case police vehicles may communicate data between all vehicles involved, and transmit positional information. The network transmits data securely so that a criminal element may not intercept sensitive data.

8.3 Intelligent Sensor Networks

Alternately the invention may be used in intelligent sensor networks. In this case the network elements contain sensor which share data such as warehouse contents, or truck load contents, which can be shared amongst the network elements.

8.4 Transportation Tracking

Alternately the invention may be used in transportation to track vehicle, train, or etc. location and load contents. The devices in this case transmit data such as text, voice, and contents tracking information including but not limited to vehicle contents, weight, disposition, destination location, etc.

8.5 Disaster Recovery

Alternately the invention may be used to quickly set up networked communication in areas where natural disasters, physical disasters, or other have rendered existing network infrastructure inoperable. The devices would use their self-forming network capabilities to enable the exchange of data, positional information, instrument or sensor data, voice, video or other in a time critical environment.

8.6 Search and Rescue

Alternately the invention may be used in search and rescue operations to allow the sharing of information between ground stations, vehicles, or patrols, airborne vehicles, and marine vessels. The device will allow rescue teams to coordinate efforts by sharing precise positional information in real-time. The device would also allow for

CA 02437926 2003-08-20 digital marking of searched and un-searched locations, geographic and topological referencing, assignment of targets and tasks, and data logging. The device would also allow the input and sharing of user defined areas such as avalanche zones, flood regions, infrastructure collapse, etc.

8.7 Public Transit

Alternately the invention may be used by transportation systems to report positional and kinematics information. The device would allow public transit vehicles to report positional and prospective arrival times to destinations and stops. The device would also allow sharing of traffic information, road conditions, and connection information between vehicles.

8.8 Surveying and Remote Region Communications

Alternately the invention may be used in land based; air to land or air based geographical surveying or other remote location work where communication is required. The device would allow the sharing and marking of geographic location, exchange of sensor information, data and voice communication, and could be used to coordinate team positions and tasks.

8.9 Hospital Patient Tracking

Alternately the invention may be used to track the precise location of individuals within a particular institution or area. One application for the device would be the tracking of patients while in hospital. The device would relay position and patient information to hospital staff, while allowing 2 way messaging and other forms of data exchange.

8.10 Armed Forces Communications

CA 02437926 2003-08-20

Alternately the invention may be used to provide all forms of information sharing between armed forces teams in an ad hoc environment. The primary target would be supply teams, where the device would be used to exchange positional information of resources.

9. Routing Metrics

Introduction:

A routing metric is a parameter used by an operating system, network protocol or routing engine to gain knowledge about the efficiency of a particular route. In the field of ad hoc networking, the routing metric is of particular importance as often there are several possible routes between cluster nodes and the metric determines the route selection. An intelligent process for establishing route metrics ensures that the most efficient routes are consistently chosen, limiting network utilization and overhead, and providing the best end-to-end performance over the network.

We propose “The Use of Local and Remote Node Position information to Establish Route Metrics in a Wireless Ad Hoc Network”.

In this approach, position information consisting of but not limited to the precise latitude, longitude, altitude, velocity, course, time, and magnetic variation of each node in a network is circulated regularly throughout the network.

Scenario 1. Route Determination

When a node requires a route to another node in the network, or must decide between multiple routes, the 3 dimensional positions of each potential intermediate node in the network can be used to establish a metric for all possible routes between end nodes. The latitudes, longitudes, and altitudes can be used to calculate the 3 dimensional straight line distances between each hop in a route, and assign a metric

CA 02437926 2003-08-20 that reflects the reliability of the wireless link at this distance. For example, below some distance threshold where link reliability is fairly high, the routing metric for each hop might increase linearly with distance whereas above the threshold the routing metric might increase exponentially to reflect the effect of far-field signal degradation on link performance.

As a variation of the above process, the latitude and longitude could be used to calculate the 2 dimensional above ground distance between nodes, to form a coordinate set with the difference in node altitude. These coordinates could be checked against the E plane and H plane signal distributions of the transmitter/receiver pairing between nodes. Coordinates well inside the signal distribution range would generate favorable hop metrics, increasing linearly as the coordinates approach a spatial distribution threshold, and increasing exponentially outside the threshold.

In addition to node locations, node velocities might also be used stand-alone or in combination with location information to establish routing metrics. Similar to the location process above, the relative velocities of potential intermediate nodes would be calculated and a metric assigned that reflects the expected reliability. The metric could reflect the Doppler effects between nodes given their relative velocities and communication frequencies, and/or known or measured relative velocities that provide good/poor link performance.

Scenario 2. Predictive Route Changes

In mobile ad hoc networks it is not uncommon for nodes to move outside of the communication range with its neighbors. When this occurs, the node will lose communication with its neighbors as well as any nodes it was communicating with by routing through these neighbors and vice versa. Instead of waiting for this loss of communication to happen we propose a scheme where Position and Geographic Information System (GIS) information is used to predict this loss of communication

CA 02437926 2003-08-20 and take action to search for new routes and hand-off existing routes in such a way as to minimize interruptions to all network traffic. This predictive algorithm would use the precise location information, velocity, course and other position information of all relevant nodes to determine when a particular node is likely to lose a communication point in the network. As this probability increases, the routing metric for all routes involving the node of concern would increase. At some threshold, the routing engine/network protocol/operating system would react by looking for replacement routes but without halting communication. If routes with a more favorable metric are discovered, traffic will be re-routed.

CA 02437926 2003-08-20

10. Distributed Address Allocation

10.1 IP Address Resolution Algorithm

Assumptions • The MAC address is globally unique and used as the node ID.

• A public IP(v4) address space is available.

• An evenly distributed and efficient hashing algorithm is available.

• Each node periodically broadcast hello messages.

Description

A portion, A, of the public address space (e.g. IPv4 type C) is allocated for the address resolution algorithm.

A node uses the MAC address as its ID. It also keeps a monotonically increasing index in its registry. The node derives an (IPv4) address by hashing its MAC address and the index. The index is incremented by one after each address computation.

Assume that all the nodes in a cluster C have obtained unique addresses.

Scenario 1.

A standalone node comes into contact with the cluster C. It realizes that it is not part of the cluster and initiates the IP address resolution process. It derives an IP address by the above algorithm and broadcasts it. A node in C receives the IP address. It checks to ensure that the received IP address is not in conflict with existing ones in C.

The proposed IP address is not in conflict, the receiving node in C broadcasts

CA 02437926 2003-08-20 back a confirmation for the proposed IP address.

• The proposed IP address is in conflict, the receiving node in C broadcasts back a rejection message. The independent node derives a new IP address and repeats the process until a unique IP address is resolved.

After the standalone node obtains an IP, it retrieves the network info from the contact node in C. The contact node in C floods info on the new node to the cluster.

CA 02437926 2003-08-20

Scenario 2.

Two network clusters, C and D, come into contact. The contact nodes exchange network info. One of them, say the contact node in C, checks the IP addresses within its own cluster and resolve the conflicting ones. The contact node in C notifies those nodes in C that they need to resolve the conflict. The nodes derive new unique IP addresses (within C) and send them to the contact node in C, which checks to ensure that the new IP addresses do not conflict with those in D. If a new IP address is found in conflict, the contact node in C negotiates with the corresponding node in its cluster for a new one. When all the conflicting IP addresses are resolved, they are passed to the contact node in D. The change in IP address is flooded within the two individual clusters and they are merged.

Summary

The IP address is derived from the MAC address. Therefore, if the IP address space in the algorithm is large compared to the number of nodes, the likelihood of conflicting IP addresses is small. The IP address resolution overhead is expected to be small.

10.2 NAT Address Translation and Connecting to the Internet

A useful feature of the 9GAAN is its ability to merge with the Internet. To accomplish this, one or more cluster nodes must act as a bridge to an external network. The bridging node is responsible for multiplexing/demultiplexing all traffic flowing between the cluster and the Internet.

Before bridging occurs, the potential bridge node must advertise the external network to the other cluster nodes. The proposed scheme for such advertising is by sending device specific information within messages created and processed by the 9GAAN messaging layer. These messages will carry descriptive information outlining the physical characteristics of the device, its interfaces, and network connections, its

CA 02437926 2003-08-20 ability to bridge communication, and its capabilities in terms of information and application sharing. In the event that more than one cluster node advertises as a bridge, the Routing Engine will determine which bridge to use taking into account the amount of traffic flowing through each bridge.

To act as a bridge, a cluster node must provide network address translation (NAT) between the network cluster and the Internet. The node will make use of communication ports, unique identifiers, communication flags, and other to properly map incoming/outgoing traffic to the appropriate destination. As well, traditional NAT techniques may be enhanced to compliment 9GAAN’s ability to support highly dynamic environments. For example, current NAT schemes could be extended to allow seamless hand-off of a cluster node from one cluster bridge to another. This would require NAT coordination between bridges and a form of hand-off negotiation, but would offer uninterrupted Internet communication as nodes move through bridge zones.

11. Maximum Doppler Spread Between Wireless Cards

Traveling in aircraft each flying at 150mph directly towards or away from each other (worst case scenario).

V = 134.08 m/s Relative velocity in meters per second

802.11b

Center Frequency Wavelength Max Doppler Spread

<td> Channel 1</td><td> 2.412E+09</td><td> 1.243E-01</td><td> 1078.78Hz</td>

<td> Channel 6</td><td> 2.442E+09</td><td> 1.228E-01</td><td> 1092.19Hz</td>

<td> Channel 11</td><td> 2.472E+09</td><td> 1.213E-01</td><td> 1105.61Hz</td>

The Doppler spread is equal to the relative velocity of the transmitter with respect to

CA 02437926 2003-08-20 the receiver, divided by the Wavelength of the signal, multiplied by the cosine of the spatial angle between the direction of motion of the receiver and the direction of arrival of the signal. The maximum spreading will occur when the angle is zero.

This happens when the devices are moving directly towards or away from each other.

For the 9GAAN network, the relative velocities will continually change but may be considerably less than 300mph for extended periods of time (aircraft flying in the same direction towards the target is one example). Thus the spreading would be significantly less than the maximum. Also, the fact that airplanes will frequently fly at different altitudes will increase the angle between the direction of motion and the direction of the received signal which will also reduce the Doppler spreading.

For a complete analysis, we could generate a scenario between aircraft, and use their relative velocities over their Flight paths to calculate the Doppler spreading of signals sent between them. However, since we presently have no control over the receiver sensitivity, we should determine if the maximum Doppler spread can be handled by our receivers.

The 9GAAN network can use its routing algorithm to effectively ameliorate Doppler effects by setting the multi-hop path to use a third node not collinear with the other nodes to mediate communications. The third node would thus have lower Doppler shift and not be affected to the extent of two nodes directly flying towards one another Figure 31 shows 3 modes, A, B and C. The maximum Doppler shift is between Nodes A and B, approaching directly head-on. The relative velocity between A and C, and between B and C is relatively much lower and the resulting Doppler shits are much lower. Thus if A and B communicate by multi-hopping though C, then the Doppler effects are not as pronounced.

12. Aircraft Mounted IO Devices for Pocket/Tablet PC

The initial application of our device will require installation and operation in and

CA 02437926 2003-08-20 around the aircraft instrument panel. Since it may not always be convenient for the pilot/crew to use the device's standard input/output, alternate forms of input/output are proposed.

Control Mounted Toggle Switch System

A switch system would be fastened to the control column allowing the pilot/co-pilot to interact with the device. The switch system would be used to set/mark way points, assign tasks, and set status information.

Control Mounted Scroll Wheel and Trigger

Attached to the aircraft control column, the scroll wheel would allow the pilot/co-pilot to scroll through menus, screens, and select objects, while the trigger would act as an action button.

Voice Activated Interface

Connecting a standard aircraft headset to the device, this interface would interpret and input voice commands from the operator. The voice input would allow aircraft selecting and assignment by call sign or other, status updates, position marking and description, etc. Voice output or other sound would provide feedback to the operator.

According to the present invention, the mobile ad hoc network integrates multiple data sources such as position (e.g. GPS, aircraft transponder data) and other critical information into a wireless multi-hop data network. The network is self-forming and self-healing so it is applicable for use in remote mobile situations where network infrastructure is not available.

Summary

The mobile ad hoc network of the present invention provides reliable means of data

CA 02437926 2003-08-20 communication in remote locations for allowing the devices to self-form into a network, whereby the devices may dynamically enter and leave the network. It also extends the wireless range, and allows routing around physical obstacles such as mountains and buildings, by allowing multi-hop routing whereby each device in the network acts as a router/repeater. In airborne firefighting, this gives much greater reliability, range, and flexibility to data communication.

The present invention allows positional and other critical information to be shared in real time with greater accuracy, thus increasing safety and team operational effectiveness.

The invention solves the problem of communication and coordination of mobile teams in remote situations where fixed data network infrastructure is not available. It enables the coordination and tracking of aircraft, vehicles, ships, people, and other mobile things, and the sharing of critical information in real time, by the use of peer-to-peer application on a self-forming ad hoc wireless radio data network.

While particular embodiments of the present invention have been shown and described, changes and modifications may be made to such embodiments without departing from the true scope of the invention.