WO2000079727A2 - Vehicular telemetry - Google Patents

Abstract

The present invention provides a system for reporting on-board diagnostic data from mobile vehicles to regulatory agencies whose mandate it is to ensure compliance with environmental emissions and safety standards. The system comprises three (3) principal components: (i) an enhanced Hybrid Network Radio, enabled for both IEEE 802 wireless LAN connectivity and Mobile IP; (ii) an IEEE 802 Access Point, configured as an IPv6 Router and enabled for Mobile IP to support the functionality of foreign mobility agent; and (iii) a 'cluster intelligence' module, incorporated in the same mobile device as the Hybrid Network Radio, using the Automotive Telemetry Protocol (ATP) to enable vehicles to exchange telemetry data with each other over an ad-hoc IEEE 802.11 network.

Description

^•VEHICULAR TELEMETRY' REFERENCE TO CO-PENDING APPLICATIONS

The subject matter of both provisional application seπal number 60/056.388 filed August 26. 1997 and utility patent application seπal number 09/140.759 filed August 26. 1998 (both entitled SYSTEM AND METHOD FOR PROVIDING MOBILE AUTOMOTIVE TELEMETRY) is incorporated herein by reference The subject matter of PCT Application seπal number PCT/CA98/00986 filed

October 23. 1998 entitled TELECOMMUNICATIONS SYSTEM and designating the United States is also incorporated herein by reference The subject matter of provisional application seπal number 60/139.573 filed June 17, 1999 and entitled VEHICULAR TELEMETRY is also incorporated herein by reference The subject matter of U S provisional application seπal number 60/148.2~0. filed on August 1 1 , 1999 and entitled

VEHICULAR COMPUTING DEVICE is also incorporated herein by reference The subject matter of U S provisional application seπal number 60/187,022 March 6. 2000 is also incorporated herein by reference

BACKGROUND OF THE INVENTION

FIELD OF THE INVENTION

The present invention relates to data communications systems and more particularly to the field of vehicular telemetry using RF packet networks in conjunction with Internet or similar protocols

DESCRIPTION OF THE RELATED ART

Hereinafter numeπcal reference is made to materials listed in Appendix A at the end of the disclosure w w υυ n ¹².¹ PCT/CAOO/00712

Conventionally, vehicles have been known to exchange data with a diagnostic computer system (such as in a repair garage) over a hardwired or infrared data link, or a regulatory computer system (such as an electronic toll highway) by a data link using a low power transponder

5 More sophisticated vehicular telemetry for commercial fleets has been made possible in the last several years through satellite RF packet networks In these vehicular telemetry systems, vehicle sensor data can be transported over wireless data links to a computer that is programmed to monitor and record automotive phenomena and to support database systems for vehicular maintenance, without the need for the vehicle to 0 be m a particular service bay for example However, these systems are relatively expensive to operate

A considerable amount of research is being dedicated to developing feasible Intelligent Vehicle Highway Systems (WHS) which are computer-assisted methods to manage highway infrastructures, synchronize traffic lights, measure traffic 5 flow, to alert dπvers to ongoing traffic conditions through electronic billboards and other innovations aimed at improving the quality and efficiency of road transportation systems for vehicles

The California Air Resources Board (CARB) has been a leader in establishing standards for monitoπng vehicle emissions A recent CARB initiative. 0 known as OBD-III, is the third generation of on-board diagnostic requirement, calling for an emissions regulatory agency to retrieve, remotely, diagnostic data from vehicles, thereby avoiding the need for a visit to a clean air inspection station In one pilot program, a low-power transponder was used on each vehicle, capable of transferπng data between the vehicle and a roadside receiver Of course, in order for the OBD-III

-> proposal to proceed, each vehicle must have a system capable of collecting and dispatching the requested data through the transponder CARB is actively reviewing currently available technologies and is surveying the telecommunications industry to see what future equipment is planned The operating platforms tested thus far by CARB have been relatively cumbersome and have limited capability to be used for other data exchange needs in the future There is interest in finding a platform that will be economical to operate in order to minimize the financial burden placed on the consumer to implement the proposal

Morever. it would be desirable for the chosen platform to be capable of doing more than just sending diagnostic information to a clean air agency Both the telecom and auto mdustπes are looking at ways to utilize the tremendous business opportunities of reaching urban commuters in their vehicles while they devote several hours each day to their commute

Vehicular traffic has become a major problem for urban planners With land values skyrocketing and land-use issues becoming more of a concern, planners are looking for ways of getting more vehicles through existing commuter arteπes as an alternative to expanding them It is also known that the actual volume of traffic handled by a thoroughfare plummets when traffic becomes congested Therefore, it would be desirable to have vehicles which are capable of exchanging data with themselves as a way to control such things as safe dπving distances to avoid collisions and exchanging data with traffic monitoπng systems to control such things as dπving speeds

It is therefore an object of the present invention to provide a improved platform for vehicular telemetry

It is a further object of the present invention to provide an improved vehicular telemetry system which is relatively inexpensive, yet capable of exchanging a range of useful data through a data communications system between a vehicle and a fixed location It is still a further object of the present invention to provide a vehicle communications system in which the vehicles therein are each capable of communicating both through a data communications system and with themselves

SUMMARY OF THE INVENTION

Bπefly stated, the invention involves, in one of its aspects, a method of exchanging data between a mobile node and an access point on a communication network, compnsmg the steps of

a) providing at least two data links between the mobile node and the access point.

b) measuπng impedance on each data link, and

c) transmitting said data across the data link having the lowest impedance

Preferably, the data links are wireless and a first of the data links is established on a spread spectrum radio frequency (RF) band The data links may also compπse a satellite RF packet network or a terrestπal RF packet network It is contemplated that other data links may become available in future as wireless data communications evolve

In another of its aspects, the present invention provides a communications system, compπsing

a mobile communications network having a mobile node,

a fixed communications network having an access point, a pair of alternative data links, each of which joins the mobile node with the access point, and

a switching unit for switching between the alternative data links to exchange data between the mobile node and the access point

In one embodiment, the mobile communications network includes a plurality of vehicle- mounted mobile nodes wherem at some are Internet addressable, for example under IPv6 protocol Each mobile node and selected ones of the access points operate under the IEEE 802 1 1 standard In this case, the data link joins each mobile node with at least one access point on a spread spectrum band At least some of the access points are located adjacent a roadway

Preferably, the system includes a measunng module for measuπng impedance on each of the data links In this case, the switching unit is operable to select the data link having the least impedance

In still another of its aspects, the present invention provides a communications network for exchanging data between a plurality of vehicles, compnsmg a computing unit onboard a corresponding vehicle, each computing unit being operable in a first phase to broadcast enquiry messages m a region surrounding the vehicle, a second phase to receive reply messages from other vehicles in the region, and a third phase to exchange status messages with selected ones of the other vehicles

In one embodiment, each computing unit includes an EEEE 802 1 1 node and exchanges data using an SNMP-deπved protocol Desirably, each node is Internet addressable, such as by the IPv6 standard for example

. . In still another of its aspects, the present invention provides a vehicle compπsing an onboard computing unit which is operable in a first phase to broadcast enquiry messages in a region surrounding the vehicle, a second phase to receive reply messages from computing units of other vehicles in the region, and a third phase to exchange status messages with computing units of selected other vehicles

Preferably, the vehicle is operable in a fourth phase to exchange data with a remote site in the form of a non-mobile gateway, which routes communications between a wireless mobile data link and a non-mobile network

In one embodiment, the computing unit includes an EEEE 802 1 1 node and can exchange data with other computing units using an SNMP-deπved protocol

In still another of its aspects, the present invention provides a hybπd communications system, compnsmg a wired network portion and a wireless network portion, each having a network connection node, at least two data link means between the network connection nodes, and a switch means for enabling either of the data links for data exchange between the connection nodes

Preferably, the system further compπses measurement means for measuπng impedance on the data links, the switch means being responsive to the measurement means for enabling the data link having a lower impedance

In yet another of its aspects, the present invention provides a vehicle communications system having a controller, a data pathway joining the controller with a plurality of vehicle components and means for establishing a data link with other vehicles within a given region surrounding the vehicle in order to exchange data therewith In still another of its aspects, the present invention provides an operational event-reporting system for use by a plurality of neighbonng vehicles to support INHS compnsmg a plurality of communication units, each onboard a conesponding vehicle to collect operational data from selected components thereof and to exchange data with the communication units of one or more of the neighbonng vehicles

Preferably, the system is capable of exchanging data related to the operation of the neighbonng vehicles, for example. GPS position and heading, vehicle speed, braking or the like Data of this kind can be useful for vehicle telemetry systems to provide, for example, collision avoidance

In yet another aspect of the present invention, there is provided a method of exchanging data between a vehicle and at least one remote site, compnsmg the step of providing the vehicle with a transmitter and receiver capable of transmitting and receiving messages under an SΝMP protocol Preferably, the data exchange site includes a neighbonng vehicle or an access point for a wired network, for example

In one embodiment, the method further compπses the steps of

- exchanging discovery signals with neighbonng vehicles, and

- exchanging status data with selected ones of the neighbounng vehicles

In yet another of its aspects, there is provided a system for transferπng data between a vehicle and another data exchange site, compnsmg a pair of data link means, wherein at least one of the data link means has a varying signal impedance level and switch means for switching between the data link means so that the data is transfened on the data link means having the least impedance In yet another of its aspects, the present invention provides an extension of the hybnd RF packet network compnsmg

(1) an interface to an IEEE 802 1 1 data link integrated in the Hybnd Network Radio.

(n) an EEEE 802 1 1 Access Point acting as an IPv6 router and a foreign mobility agent for mobile nodes implementing Mobile EP.

(in) an interface to a non-wireless subnetwork from which the Hybnd

ork Gateway can route mobile-terminated traffic through an IEEE 802 11 Access Point, and

(ιv) a cluster intelligence module, based on the establishment of ad-hoc networks between a vehicle and its EEEE 802 1 1 neighbors

Preferably, mobile nodes that are ATP-enabled can exchange Internet traffic with regulatory agencies over license-free wireless data links (EEEE 802 1 1 ) whenever connections are established with Mobile IP-enabled Access Points The cluster intelligence module is operable using ATP from vehicular node to acquire information about the automotive behavior of any of its discovered neighbors

In another of its aspects, the present invention provides a method of exchanging data between a mobile node and an access point on a communications network, compnsmg

a) a step for providing at least two wireless data links between the mobile node and the access point. b) a step for measunng impedance on each data link, and

c) a step for transmitting said data across the data link having the lowest impedance

In still another aspect of the present invention, there is provided a method of exchanging data between a motor vehicle and a remote station, compnsmg

a) a step for providing at least two data links between vehicle and said station.

b) a step for measunng impedance on each data link, and

c) a step for transmitting said data across the data lmk having the lowest impedance

In still another aspect of the present invention, there is provided an mter- vehicle communications network, compnsmg at least two motor vehicles, each having an on-board control system, the system including momtonng portion and a spread spectrum radio portion and which is operable to exchange useful vehicle operational data with the control system of the other vehicle

Preferably, each monitoπng portion is capable of registeπng a vehicular event and each control system may. if desired, be operable with other vehicular overnde systems to overnde a vehicle function according to a vehicular event Desirably, each control system includes a memory portion for stonng vehicle operational data of the other vehicle In one embodiment, the network includes at least one. preferably more than one. remote station is located along a road way on which the vehicles are traveling The remote station includes a spread spectrum radio portion to be capable of exchanging data with either of the vehicles and is also preferably an internet or intranet or other network access point

Conveniently, the vehicles are operable to exchange data using an SNMP- deπved protocol and each vehicle is capable of momtonng vehicular events m its own region

In still another aspect of the present invention, there is provided a motor vehicle compnsmg an onboard general purpose computer and a spread spectrum radio. the computer operable to monitor a number of predetermined operating characteπstics of the vehicle, the spread spectrum radio operable to establish a data link with a radio in at least one other neighbouπng vehicle, wherem the computer is capable of identifying at least one vehicular event from data received on the data link

In still another aspect of the present invention, there is provided a computer program product for operating a programmable computer system on board a motor \ehicle, wherem the system includes a spread spectrum radio, compnsmg a computer readable medium including the computer executable steps of

- instructing the radio to issue a signal to a region sunounding the motor vehicle,

- monitoπng the radio for reply signals from other vehicles in the region, and when a reply signal is received from another vehicle.

- establishing a data link with the other vehicle, and - exchanging operational data with the other vehicle over the data link

In yet another of its aspects, there is provided a mobile automotive telemetry system for installation on-board a vehicle, compnsmg

(1) diagnostic means for momtonng operational functions of the vehicle and generating operational information.

(π) memory for stonng the generated operational information, and

(in) a server, in communication with the diagnostic means and the memory, the server compnsmg

(a) means to receive a request from a remote client for the generated operational information.

(b) means to retπeve the generated operational information from the memory means, and

(c) means to transmit the generated operational information to the remote client

Preferably, the means to receive and the means to transmit are wireless communication means

In one embodiment, the system further compπses an Internet access means and a means to transmit generated operational information to a remote client, in absence of a request from the client, when the generated operational information satisfies predetermined cnteria Preferably, the Internet access means is compliant with IP V6 internet protocol and allows the server to act as a mobility agent Preferably, the system further comprises means to interface to a global positioning system (GPS) receiver As descπbed hereinbelow. the Applicant's pending application, serial number 09/140.759 filed August 26. 1998 entitled SYSTEM AND METHOD FOR PROVIDING MOBILE AUTOMOTIVE TELEMETRY discloses a system and method for automotive maintenance telemetry The system functions on a client-server architecture enabling a remote client to request information from an on-board diagnostic

(OBD) module in a vehicle, such as that commonly referred to as the Electronic Control Module (ECM) The OBD module performs the role of 'server' by bemg programmed to interface with the ECM, and with any other sources of diagnostic information and then communicates the data to a requesting client, such as OEM suppliers, dealers or regulatory agencies

The location of the requesting client can dictate how the data is delivered For example, in the Applicant's co-pending PCT Application PCT/CA98/00986 filed October 23. 1998 entitled TELECOMMUNICATIONS SYSTEM, the OBD module may select a path of least impedance to deliver the data to the client For example, where the client is land-based, such as, for example an emissions regulatory body, the OBD module may deliver the data either through a conventional RF packet network (such as over a cellular phone connection) or through an RF packet network using a Hybnd network as descπbed in the above mentioned PCT application However, the requesting client may in fact be another vehicle traveling along the same roadway as the server vehicle and may request data for such things as vehicle speed, braking, position and the like The

OBD module may convey the data over a wireless data link such as over the band known as the "spread spectrum band" as is descπbed m the applicant's co-pending provisional application senal number 60/139.573 filed June 17, 1999, entitled VEHICULAR TELEMETRY and as specified m the IEEE 802 1 1 standard

IEEE 802 Standards Family The IEEE 802 family of standards specifies the methods for implementation of local area networks (LAN's) using both wired and wireless media The IEEE 802 1 1 standard specifies the medium access control (MAC) layer and three separate methods for implementation of the physical layer (PHY) as a wireless medium 5 IEEE 802 1 1 is intended to ensure mter-operability between multi-vendor equipment operating in wireless networks As such, it is the basis for the interface specified herein enabling vehicular computing equipment to establish license-free data links with fixed stations

The IEEE 802 1 1 standard specifies three different physical layers, use of 0 Infrared light. Direct Sequence Spread Spectrum and Frequency Hopping Spread

Spectrum The band utilized for the Spread Spectrum technique is ISM (Industπai. Scientific and Medical) RF band, which is free of regulatory licenses in most of the world Communications in the Spread Spectrum involve a coordinated change m frequencies, either by a "Direct Sequence" or a "Frequency Hopping" format

5 The IEEE 802 2 standard, called Logical Link Control (LLC). specifies a method for addressing and control of the data link, independent of the underlying medium, and is applicable to all types of LAN's defined within the IEEE 802 family Both 802 1 1 and 802 2 are incorporated herein by reference

The IEEE 802 1 1 does not specify the handoff mechanism for a mobile node to roam from one Access Point to another When both the IEEE 802 1 1 client and Access Points incorporate IPv6 implementations, including ND (Neighbour Discovery) and RD (Router Discovery), roaming clients are able to bind to (or to establish a data link with) the Access Points, where the latter take on the role of Foreign Mobility agents as defined in [3] The Access Point acts as a mobility agent for the roaming client The

"> Mobile IP specification therefore provides a solution to the lack of an EEEE 802 1 1 mechanism for coordination of roaming (handoff) between Access Points Automotive Telemetry Protocol

In one embodiment, data is exchanged between vehicles using a protocol herein called "Automotive Telemetry Protocol" (or ATP) and is based on Simple Network Management Protocol (or SNMP) The latter is commonly used m data communication networks to monitor and control switching equipment SNMP is specified in [2], the contents of which are incorporated herein by reference ATP is intended to function according to the same client-server model as SNMP, wherem the client issues the requests for information and the server issues the responses Although the ATP makes use of the same formats of the requests and responses as SNMP, ATP implements a novel set of "object identifiers" which are required to encompass the OBD data requested, in contrast to the telecommunications equipment data exchanged m SNMP For example, the object identifiers may. in this case, correspond to nodes on the Controller Automation Network (CAN) bus in the vehicle, such as the ABS system, emission control system and the like

SNMP and its deπvative defined herein, ATP, are efficient request-response mechanisms which require less bandwidth than Web-based data exchanges between client and server The payload (I e the useful telemetry data) can be encapsulated within the maximum allowable frame sizes of the underlying data links These protocols therefore do not require the overhead associated with fragmentation at the source, and properly sequenced reassembly of large messages at the destination

IPv6 and Mobile EP Dynamic topology of the new Internet

The well known "Mobile IP" specification defines a protocol that enables IPv6 datagrams to be transparently routed to mobile nodes in the Internet This specification is provided in Internet Engineering Task Force, Perkins, C. (ed.), " IPv6 Mobility Support", March 1995 [3], the contents of which are incoφorated herein by reference

By definition, a mobile node is one that can connect to the Internet through any one of a vaπety of different access points, called mobility agents Each

5 mobile node is registered with one and only one mobility agent, called a home agent

When a mobile node attaches itself to the Internet through an access point other than its home agent, the access point is called a foreign agent The Mobile IP protocol incorporates a mechanism for mobile nodes, when they are attached to a foreign agent, to register a "care-of-address" with the home agent Thus, datagrams routed to the mobile 0 node through the home agent can be re-routed to reach the mobile node at its current network location

When a mobile vehicle is already equipped with radio-mode technology that provides a unique address on a wireless network, it is possible to assign a unique Internet address that can be reached through an EP router between the wired Internet and 5 the wireless network This is descπbed in the Applicant's co-pendmg PCT Application

PCT'CA98/00986 filed October 23. 1998 entitled TELECOMMUNICATIONS SYSTEM This represents a static Internet topology because, although the vehicle is mobile, the IP router through which it is reached never vanes The topology of the wireless network itself is dynamic and supports the roaming required for a vehicle to 0 establish contact with the network through different base stations and regional switches

However, at the EP level, this dynamic topology is not visible

In contrast, the Mobile EP extension to the IPv6 specification allows for a dynamic network topology It lends itself to the task of enabling communication from the Internet to a mobile vehicle through different foreign mobility agents In the context of

^"> vehicular mobility, the role of mobility agent can potentially be adopted by any Internet node that has the ability to dynamically create a data link with a vehicle To date, the most efficient means available by which such data links can be quickly established are defined by the IEEE 802 1 1 specification for wireless LAN's (Local Area Networks)

A data link can be established between a mobile EEEE 802 1 1 node, implemented in the vehicle, and any fixed EEEE 802 1 1 node, called an Access Point. provided that both nodes incorporate full implementation of the IPv6 protocols. specifically the Neighbor Discovery protocol, (hereinafter referred to as ND) and the Router Discovery protocol (RD) ND and RD are specified in Narten, T., Nordmark, E., and W. Simpson, " Neighbor Discovery for IP Version 6 (IPv6) ", RFC 1970, August 7996. [5], the contents of which are incorporated herein by reference For every interface to a datahnk implemented in an IPv6 node, m this instance a wireless IEEE 802 datalink,

ND is required to ensure that neighbors, defined as other nodes which are "on-link" (I e , capable of communications on the same datahnk) can be dynamically identified as they appear This is accomplished through the use of penodic broadcasts on the wireless medium, called Neighbor Solicitations, to which any recipient of the broadcast is required to respond, in such a way as to enable the broadcaster to identify the responder with a unique IPv6 address An implementation of ND typically maintains a table of neighbors that dynamically changes as each new cycle of neighbor solicitation either reveals a new respondent or loses, through lack of response, a (previously) existing neighbor RD is a specialization of ND. ensunng that on-link nodes capable of routing EP datagrams to other sub-networks, can be discovered

Thus, the vehicle communications system, according to one embodiment of the present invention, is capable of handling the Mobile EP protocols over an IEEE 802 1 1 data link and. as a consequence, is capable of delivenng vehicular diagnostic data under the requirements of OBD-III and of exchanging a wide range of data, including e- commerce transactions and the like, as well as data needed for such things as Intelligent

Vehicle Hiεhwav Svstems According to one aspect of the present invention, each vehicle has one of a number of Hybnd Network Radios (as descnbed in Applicant's PCT patent application PCT/CA98/00986) which can effectively communicate with one another using the Mobile EP protocol over one or more wireless LAN's In this particular case, then. Internet-addressable vehicles may roam between wireless LAN's and still be in the network

Ad Hoc Network

By making the vehicular computers Mobile IP-enabled as descπbed in utility patent application 09/140,759 filed August 26, 1998 (entitled SYSTEM AND METHOD FOR PROVIDING MOBILE AUTOMOTIVE TELEMETRY) as descπbed hereinbelow. each vehicular system may be connected to the Internet through the EEEE 802 1 1 data link When two or more vehicular computer systems are equipped with IEEE 802 1 1 interfaces and where each operates on the same frequency changing format, that is by using either Direct Sequence Spread Spectrum or Spread Spectrum Frequency 5 Hopping, they can then communicate amongst themselves and thereby create an "ad hoc^" network between them The so-equipped vehicular systems can now support IP Neighbor Discovery, which enables all vehicles within range to recognize each other as "on-link" IPv6 nodes, provided that the adjacent vehicular systems are also compliant with IPv6 This means that useful information may be exchanged between adjacent 0 vehicles by the use of spread spectrum frequencies Therefore, the same UDP/EP mechanism, used to permit telemetry traffic to be encapsulated m IPv6 datagrams from any vehicle to a fixed-location host, can be used to permit telemetry traffic to be exchanged between vehicles

This ad hoc network also enables mobile vehicles within range of each

' other to establish a "cluster intelligence", which is defined, within the context of the present invention, as an infrastructure for interactive vehicular control based on the same l equest response telemetry architecture descnbed in utility patent application seπal number 09/140.759 filed August 26, 1998 (entitled SYSTEM AND METHOD FOR PROVIDING MOBILE AUTOMOTIVE TELEMETRY)

In one embodiment, the system compπses the following components

( 1 ) Hybnd Network Radio, as specified in [4], supplemented by

(a) Wireless LAN interface compliant with (l) IEEE 802 2

(n) IEEE 802 1 1 interface

(b) IPv6 modules including (i) IPv6

(π) IVMPvό

(in) IP Neighbor Discovery and Router Discovery (IV) Mobile IP (2) IEEE 802 Access Point as an IPv6 Router (3) Cluster Intelligence Module

The cluster intelligence module is intended to provide a means by w hich Intelligent Vehicle Highway Systems (INHS) can be implemented without the need for electronic wiπng of the highway infrastructure Cluster intelligence is based on the establishment of an ad hoc network connecting vehicular Hybnd Network Radios Whereas the pnmary goal of the Hybnd Network Radios is to enable least-cost IPv6 communications of telemetry data required by environmental regulations, an ad hoc network among and between Hybnd Network Radios provides a platform on which vehicles can transmit real-time operational information to each other As a result, in those instances where the aim of JNHS is to control the spacing and speed of vehicles on highways, and therefore the volume of vehicular traffic flow , cluster intelligence offers a low-cost alternative to the conventional ideas proposed for highway infrastructure upgrades

Figure 1 shows the classic relationship defined in traffic engmeenng between speed and volume on a road link There is an optimum point along this curve where the \ olume is maximized The speed at this point is defined as the "free flow" speed Below this speed, traffic flow is conjested Above this speed, the spacing between vehicles required for safety results m profligate use of the roadway At any point along the curve, the volume-speed relationship represents the most efficient inter-vehicle spacing, given the braking distance required for safety, which can be achieved

In one embodiment, the peer-to-peer telemetry architecture of [ 1 ] and as descπbed below, supports the ability of vehicles to adapt their speeds m accordance with the optimal volume-speed relationship The ATP protocol used between vehicles enables each one to determine, among other things

(a) The dιstance(s) between it and the vehιcle(s) immediately ahead of it (using GPS position and heading reports)

(b) The speed(s) of the vehicles immediately ahead of it

(c) Application of brakes

This information provides the enabling technology for all vehicles to engage in a cooperative effort to maximize traffic flow on electronically enhanced highways The term "Impedance" used herein is intended to be a measure of the "costs" of sendmg a datagram across a data link This cost can include the monetary charges associated with the transmission of data across a wireless data link and are typically imposed by the operator of the wireless data network, as well as other factors such as . for example, the size of packet and the time of day, which of course will change over time As is descπbed in the PCT Application seπal number PCT/CA98/00986 filed October 23. 1998 entitled TELECOMMUNICATIONS SYSTEM, the Impedance governs the functionality of the RF path switch As impedance changes, the output of the RF path switch (I e the routing decision) can change The sections entitled Error Reporting and Airhnk Status Reporting descπbe the mechanisms whereby changes in impedance are reported to the RF path switch module

BRIEF DESCRIPTION OF THE DRAWINGS

Several prefeπed embodiments of the present invention will be provided, by way of example only, with reference to the appended drawings, wherein

Figure 1 is plot of traffic volume versus speed on a road link.

Figure 2 is a schematic view of a vehicle communications system.

Figure 2a is a schematic view of one aspect of the vehicle communications system of figure 2.

Figure 3 is another schematic view of the vehicle communications system of figure 2.

Figure 4 is a schematic view of one segment of the vehicle communications stem of figure 2. Figure 5 is a schematic view of another segment of the vehicle communications system of figure 2.

Figure 6 is a schematic view of still another segment of the vehicle communications system of figure 2.

Figure 7 is schematic representation of a system in accordance with one embodiment of the present invention.

Figures 8 a) and 8b) are schematic representations of a system accordmg to still another embodiment, and

Figures 9. 10. 1 1. 12, 13, 14 and 15 are schematic views of portions of still another embodiment

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Figure 2 illustrates a communications network for exchanging data between a plurality of vehicles, including vehicles 10 and 12 on a highway shown at H Each \ ehicle has a computing unit 10a and 12a. the latter of which is shown schematically in figure 2a Each computing unit has a processorlOc which is connected via a seπal port to a GPS receiver lOd, an IEEE 802 1 1 spread spectrum unit lOe. a cell packet data unit 1 Of capable of broadcasting and receiving data over a cell packet data neuvork and a memory unit 1 Og If desired, the components of the computing unit may be integrated on the same board using application specific integrated circuits (ASIC's), as descπbed herembelow and in U S provisional application senal number 60tl 48.270. filed on August 1 1. 1999 and entitled VEHICULAR COMPUTING DEVICE Referπng to figure 2. each computing unit 10a, 12a broadcasts ND and RD messages in a region surrounding the vehicle as shown by the circles 10b, 12b In the example shown in figure 1 three other similarly equipped vehicles labeled 14a to 14c are all within the region 10b and therefore are capable of receiving the broadcast enquiry

5 messages from the vehicle 10 The vehicles 14a to 14c issue reply messages which are received by the vehicle 10 Similarly, vehicles 14b to 14f are withm the region 12b of the vehicle 12 which in turn receives reply messages from them These messages may include such things as vehicle speed and GPS information as well as status indicators such as acceleration or braking In this manner the computing umts 10a, 12a are able to 0 determine the position and movements of neighbonng vehicles

Thus, the number of vehicles in the corresponding region for each vehicle will change over time with the traffic pattern In this case, the computing unit for each vehicle can retain status data for each target vehicle while the vehicle is in the region and then erase the data for those vehicles that have left the region The memory unit lOg can 5 have allocations for stonng data for each vehicle while the processor can manipulate the data to determine if any action needs to be taken The processor also receives data from the ECM lOh which can include such things as emissions, braking, acceleration, speed and the like, that is. any function of the vehicle which is being electronically sensed, monitored or measured Optionally, the processor may also pass off, to other vehicle 0 systems, braking or other overnde commands for controlling the vehicle if necessary

Located along the highway are a number of access points which are routers to a fixed communications network, in this case spread spectrum base stations One of the access points is shown at 16 The access point 16 issues router advertisement messages with a region shown by the circle 16a Therefore, vehicle 12, in the instant of i time represented by the figure 1. receives the advertisements In this example, the vehicle computing units 10a and 12a as well as the access point 16 are IPv6 addressable Therefore, the vehicle 12 and the access point 16 may then exchange data which may

- ~>1 include Internet email and the like The access point 16 may also convey status request data from a clean air regulatory body to the vehicle 12 which may then return the status data to the regulatory body through the access point 16 if the vehicle is still in its region

Base station 18 provides a wireless data link to a propnetary RF packet network, for example that known as the MOBITEX network, or the like This is a different data link from the spread spectrum data link operating at the access points 16 The computing units exchange data with the station 18 via the cell packet data unit lOf

The GPS information from the neighbonng vehicles may, for example, include Differential GPS (D-GPS) In the latter cases, the vehicle may more accurately measure the position of neighbonng vehicles, relative to a reference GPS position which may be broadcast, for example, from the access point 16

Global System

Figure 3 shows the overall system architecture As will be descπbed. Figure 3 illustrates how the IEEE 802 data link is incorporated into the hybnd mobile packet network and shows the path of Mobile IP communications between a mobile node shown at 10 and its home mobility agent, l e . the Hybnd Network Gateway 230 Mobile node 10 is an embedded vehicular computing device functioning both as an OBD server [ 1 ] and as a Hybnd Network Radio [2] The Hybnd Network Radio functionality is implemented through the interface 40 to the hybnd mobile packet network 250

Fixed node 16 is a wireless communications base station implemented in accordance with the definition of a "foreign (mobility) agent" contained in [3] Mobile node 10 and fixed node 16 share the same EEEE 802 wireless data link 15. which, from the perspective of the mobile node 10 and as will be descnbed further below, is integrated as a "zero-cost" data link m the interface 40 to the hybnd mobile packet network 250

. 1 1 - Fixed node 16 may be. for instance, an embedded computing device permanently installed near a roadway and connected to a data communications network 210 via a stationary (non-mobile) backbone 220

When a mobile node 10 comes sufficiently withm range of a fixed node 16 to establish an EEEE 802 data link. Internet traffic, in the form of IP datagrams, may flow from the vehicle to any address in the Internet This is called "mobile-ongmated" traffic "Mobile-terminated" traffic can only reach the vehicle once the Mobile IP "care-of address^*' registration has been completed This procedure, specified in [3], allows the mobile node to notify its "home (mobility) agent" that it can be reached through the foreign (mobility) agent embodied in the fixed node 16 As a foreign (mobility) agent, fixed node 16 is. by definition, an IPv6 router

The home mobility agent for mobile node 10 resides in the Hybnd Network Gateway 230 A Hybnd Network Gateway (HNG) is the stationary equivalent of a Hybnd Network Radio and is defined m [2] HNG 230 has an abstract interface 240 to the hybnd mobile packet network 250, through which it can route Internet traffic to a mobile node In order to ensure least-cost routing to a mobile node that has registered fixed node 16 as its care-of-address, interface 240 must also incorporate the data link associated with stationary backbone 220 This extends the hybnd mobile packet network to include a stationary data link

In other words, the system has the capacity to carry out least-cost transfer data between the Hybnd Network Gateway 230 and the mobile node 10 in one of three routes

I) Ma the data link 15, the fixed node 16. the data link 220 and the stationary non-mobile data link 210. or altemativelv n) through the hybnd mobile packet network 250. which itself can provide least cost switching between

a) a satellite Packet Network, or b) an RF Packet Network

Ipv6 Communication Protocol Stack

The IPv6-based communications software infrastructure for a telemetry system in accordance with this example is shown in Figure 4 Figure 4 is a representation of the Hybnd Network Radio incorporating interfaces to an arbitrary number of RF packet networks, including an interface to a wireless IEEE 802 data link, integrated mto a single abstract data link as specified in [4] Figure 4 also shows the relationship between the Hybnd Network Radio and an EEEE 802 1 1 Access Point incorporating an IPv6 router implementation In this scenaπo, mobile-oπgmated Internet traffic (datagrams emanating from the Hybnd Network Radio) can be routed through the access point or alternatively through the hybnd mobile packet network 250 depending on 'cost' Mobile node 10 is an

IPv6 (Internet) node consisting of a protocol stack 20 in accordance with definition of a Hybnd Network Radio provided in [4] Fixed node 16 is an IPv6 (Internet) router consisting of the router-specific equivalent of protocol stack, labeled 21 The components of protocol stack 20 are

(I) a combined RF packet network 30 that unifies all the wireless data links available to mobile node 10 into a single abstract data link capable of least-cost switching,

(π) an IPv6 module 60. in accordance with [6], the contents of which are incorporated herein by reference. (in) an ICMPvό module 70. in accordance with [7], the contents of which are incorporated herein by reference, that provides the assembly and parsing mechanisms for the specific datagrams required by ND.

) a Neighbor Discovery (ND) module 80, m accordance with [5], that enables mobile node 10 to dynamically discover other "on-link" mobile nodes, l e . other vehicles capable of communicating on the same IEEE 802 1 1 medium, and

(\ ) a Router Discovery (RD) module 90. in accordance with [5], which enables mobile node 10 to discover dynamically IPv6 router 16

Both the ND and the RD protocols require the broadcasting of, respectively, neighbor and router advertisement datagrams, defined in ICMPvό These datagrams are sent to the interface 40 to the combined RF packet network 30 Broadcast datagrams can only be transmitted on data links that are broadcast-enabled Typically, wide area RF packet networks do not support broadcasting initiated by subscπbers. although they often allow multicasting to selected groups of mobile subscnbers Since

IEEE 802 1 1 depends on broadcast frames to establish the data link, it should identify itself to interface 40 as broadcast-enabled, whereas all other RF packet networks incoφorated in the combined packet network 30 should report that they are not broadcast-enabled The intelligent switching mechanism of this interface, which ensures that datagrams are transmitted over the least-cost data link, will therefore switch all mobile-onginated broadcast datagrams over the IEEE 802 1 1 data link

In case of overlapping of the coverage areas of two or more Access Points, a mobile node may receive router advertisements from more than one fixed station, in response to its broadcast of router solicitations, providing it with alternative on-link loutes to use for outbound datagrams Both neighbor and router discovery should rely pπmanly on unsolicited neighbor and router advertisements

Registration of the "care-of-address" provides a means for requests from the OBD telemetry client to reach a mobile node via the foreign mobility agent, which, by definition, is an IEEE 802 access point The maximum acceptable impedance values associated with these requests can be set such that the mobile-terminated ATP traffic that would otherwise incur costs traveling over RF packet networks, can be deferred until the "care-of-address" is registered with the home address

Cluster Intelligence

The cluster object as an ATP client is a specialization of the genenc

SNMP client using the UDP/IP protocol The ATP allows for message passing to the cluster object

The establishment of an IEEE 802 1 1 ad-hoc neuvork as a "mobile cluster" m accordance with the present example is shown in Figure 5 Mobile node 10 incoφorates the User Datagram Protocol (UDP) module 100 and the ATP module 1 10

An equivalent mobile node 1 1 , with equivalent UDP and ATP modules 101 and 1 1 1. respectively, can interact with mobile node 10 such that the automotive behavior of 1 1 is known to 10 This is accomplished through the mechanism of an ATP request issued by 10 to 1 1 and an ATP response from 1 1 to 10

The interaction between any two mobile nodes is managed by a "cluster", which is an active object that registers with the ATP for reports from neighbonng vehicles Cluster 120 has container 130 of neighbors, or more precisely, "images^" of neighbors These neighbors are placed in the container when detected by the ND mechanism operating over the IEEE 802 1 1 data link, as shown in Figure 4 By propagating the discovery mechanism in ND module 90 upwards through the UDP/IP stack. Node 1 1 becomes a member of Node 10's cluster when the ATP signals the cluster that a new neighbor has appeared (The whole process can be repeated for mobile node 12, which becomes a second neighbor of node 10)

Registration of neighbors discovered through the ND requires an implementation of IPv6 that can be asynchronously notified of ND. which requires a "callback" method of IPv6 to be invoked when the neighbor's response to a solicitation request is being processed The conventional processing of such a response is simply to update the cache of on-lmk neighbors known for that interface However, the requirements of cluster intelligence are that dynamic neighbor identification propagate upward from the subnetwork layer to an application port of the UDP/IP protocol stack

In this example, cluster communications over wireless data links is intended to take place only over the license-free spread spectrum band The cluster object itself has "no knowledge" of the fact that there are alternative radio paths between vehicles However, when the cluster asks each new neighbor to transmit GPS position reports and automotive events m which it is interested, both the requests as well as the responses will travel only over zero-cost links - which are precisely the same links over which the ND operates In others words, by virtue of the least-cost mechanism descnbed in [4], a license-free wireless data link will always be the data link over which the ND datagrams are transmitted ND can and should be configured such that its maximum acceptable impedance level can only be supported by the license-free links ND will therefore only discover neighbors that are on the license free links and cluster traffic that follows from this will travel only over these links

Provided that an implementation of cluster 130 is compliant with the requirements for the interface to the module ATP 1 10. already specified in [ 1 ], the internal behavior of the cluster may vary depending on the design objectives and

- 28 -

< I . Λ r- ---»ιι«ι. implementation style for a specific vehicular device The precise design of the methods (behavior) or the specification of other methods intended to process (and act on) information reports from neighbonng vehicles is not withm the scope of the present invention

5 Process Architecture

Figure 6 illustrates the process architecture of the device compnsmg the mobile node ATP client process 300 is part of the cluster intelligence module Figure 6 illustrates the architecture of the processes, running on top of the UDP/IP stack, that provide all of the functionality of the system These processes are 0 (l) an OBD process, with the behavior of an ATP server.

(n) a Cluster Intelligence process with the behavior of an ATP client, (in) a Mobile EP process, with the behavior specified in [3], and (IV) a diagnostic data acquisition process

ATP is registered with UDP module 330 through the application port 305 5 Similarly Mobile IP process 310, which is responsible for registration of care-of- addresses (l e . addresses of foreign mobility agents) with home mobility agents, is registered with UDP module 330 through the application port 315 The ATP server process 320, registered with UDP module 330 through port 325, provides access to the Diagnostic Information date Base (DIB) 340 This data base, similar to the Management 0 Information data Base (MIB) used by SNMP (from which ATP is denved), contains all of the on-board diagnostic information obtained from the data acquisition processes 350 (Analog and digital signal processing), 360 (CAN-bus data processing) and 370 (GPS receiver data processing)

Whereas the present invention does not limit the scope or character sties of i f possible cluster implementations, the behavior recommended for effective use of the ATP to implement cluster intelligence within each vehicle is descnbed by the pseudo-code below The cluster is defined as an object that owns an ATP client process with a set of methods corresponding to the handling of each of the possible messages that could be received through the ATP

In one example, the cluster's ATP client process would be

ClusterProcessQ

I whdef TRUE ) { pointer _event _objecι =

pointer _event_object->Handler(), 7 behavior of event object destroy _event( pointer _event_object-)

} \

The cluster process blocks on an event queue, registered with the ATP. to which the ATP can append events relevant to the cluster process as they occur These events are removed from the queue and processed on a first-m first-out basis All events are treated as objects denved from a common base class within a virtual "handler" method, the internal behavior of which vanes for each type of event The handler method of the event is invoked by the cluster process when the event is removed from the queue

The pnmary type of event which the ATP should signal to the cluster is a

GPS position report from a neighbor This implies, of course, that all nodes on the ad- hoc IEEE 802 1 1 neuvork should broadcast GPS position reports Other on-link nodes receiving these broadcasts should propagate the reports upward through the protocol stack to the ATP, which should signal an Event _Gps Report to the cluster Event _GpsReport_Handler() is the method invoked when the GpsRepon signaled oy the ATP is removed by the cluster process from its queue The inputs to this method are

(1) ID_Remote_Vehιcle - which should be the unique IP address of the vehicle.

(n) GpsPosition - which is a latitude-longitude coordinate pair, determined by the GPS receiver of the remote node and contained in the payload of the UDP segment received from the remote, and

(in) GpsHeading - which is a heading determined by the GPS receiver of the remote node and contained in the payload of the UDP segment received from the remote

Event JGpsReport _Handler ( ID _Reτnote_Vehιcle, GpsPosition, GpsHeading )

I !

Remote _Vehιcle = GetRemote( ID_Remote_Vehιcle), Proximity - Compar eGps( Remote _Vehιcle, GpsPosition, GpsHeading )

IffProximity ) {

AtpRequest( Remote Vehicle, speed, frequency, duration amplitude )

AtpRequest( Remote _Vehιcle, foot brake, 0, 0, 0 ), I ;

Event _Gps Report _Handler cames out the following functions

(l) Invokes the pπvate function GetRemote using the input

ID _Remote_Vehιcle (The term private signifies that the function is usable only by the cluster module and is not accessible to "external" software modules) This searches the cluster^'s container of remote vehicles for the object matching ID _Remote_Vehιcle.

(n) Uses the pnvate function CompareGps to determine whether this vehicle is within a specified distance threshold This function takes as inputs

(a) pointer to the Remote Vehicle object, and

(b) the new GPS position and heading

The GPS position and heading of the remote vehicle are compared to the position and heading of the "local" vehicle. The "local" position and heading are maintained in the DIB (diagnostic information base) Since the ATP is a peer-to-peer protocol, cluster intelligence request/response exchanges can be symmetπcal The DIB can therefore be used by the ATP client to obtain GPS information for companson with reports from remote nodes, as well as by the local OBD server to respond to cluster intelligence requests from remote nodes

The ouφut of CompareGps is a boolean vaπable {Proximity) indicating whether ATP requests to this remote are warranted because the vehicle is within a specified distance threshold to require preventive measures if there is a sudden change in speed Since the implementation of cluster intelligence is not withm the scope of the present invention, the internal algonthm of CompareGps is not defined here However, it should be noted that any implementation of CompareGps must account for margins of enor m the accuracy of the GPS receiver where the remote position report oπginates Furthermore, it may not be possible to distinguish between several remote vehicles moving in parallel in different lanes ahead of the "local^" vehicle so that the identity of the

- 3: vehicle directly m front may remain indeterminate The cluster intelligence decision algorithm may have to assume that all of these vehicles are equally important to monitor

If Proximity is TRUE, then ATP requests can be issued to the remote node's OBD server, the responses to which enable the cluster to provide decision support to other intelligent modules withm the complete automotive system A minimum set of requests could consist of speed reports, at values of frequency and duration established by the owner of the cluster. (1 e . one of the aforementioned automotive modules), and of notifications for the application of the foot brake

Another embodiment of the present invention is shown m figure 7 A mobile automotive telemetry system is shown generally at 1 10 in Figure 1 System 410 compnses a diagnostic means 415 for monitoπng the operational functions of the vehicle in which system 410 is installed and generatmg operational information The generated operational information may be stored in a memory 420 until required Both diagnostic means 415 and memory 420 are m communication with a server 425 which ultimately controls the operation of system 410

Server 425 can communicate with a remote client 430 via a data link 435 To this end. server 425 compπses a means (440) to receive a request for information from remote client 430, a means (445a. 445b) to retπeve the generated operational information from memory 420. and a means (450) to transmit the retπeved generated operational information to remote client 430 Server 425 is a processor which is programmed to respond to requests for information from remote clients and to respond to control commands

Diagnostic means 415 may be a conventional, computer-based OBD module which monitors vaπous operational functions of the vehicle in which system 410 is located Diagnostic means 415 may, for example, monitor exhaust emissions, fuel use. ignition timing, engine temperature, speed and/or distance travelled Diagnostic means 415 receives inputs from the vanous vehicle sites via a plurality of communication lines 460 and. after mteφreting the inputs and generating formatted operational information, passes the operational information to memory 420 via communication line 465 Diagnostic modules suitable for use in the present invention are known m the art and are refeπed to as Electronic Control Modules (ECM) or Electronic Control Units (ECU) The specifications for the diagnostic modules may be found in Society of Automotive Engineers. "On-Board Diagnostics for Light and Medium Duty Vehicle, Standards Manual" 1997 Edition, the contents of which are mcoφorated herein by reference

Memory 420 may be any conventional computer memory, the size and operation of which will be dependent on the nature of the operational features of the vehicle a user wishes to monitor The choice of suitable memory is believed to be withm the purview of a person of skill in the art In one embodiment of the present invention, system 410 compπses a memory 420 which includes 32k of non-volatile RAM and a configurable amount of additional RAM, allocated at run-time from the host processor system Memory 420 receives the operational information, generated by diagnostic means 415. via communication line 465 and stores the operational information Memory means 420 is in communication with server 420 and is capable of receiving instructions from server 425 and sending information to server 425 via communication lines 470a and 470b. respectively As will be apparent to a person of skill in the art, communication lines 470a and 470b may be replaced by a single communication line if the appropπate communication protocol is used

Server 425 acts as a gateway between remote client 430 and diagnostic means 415 and eliminates the requirement that remote client 430 has knowledge of the specialist OBD protocols of diagnostic means 415 Server 425 in effect acts as a

"universal translator", allowing a remote client to interact with any diagnostic means of any vehicle One way of achieving this end is through the implementation of a i equest/ response protocol which acts as a proxy for the corresponding OBD protocols Under this type of protocol, an abstract request from the remote client which is received by the server is mapped to the corresponding request under the specialist OBD protocols and is then transmitted on the diagnostic means or memory, as appropπate In the other direction, the responses returned by the diagnostic means or memory to the server are then mapped to an abstract response which is sent back to the client

Such request/response protocols are known in the art and include, for example. IAS protocol for infrared links and UDP/IP protocol for wide area network communications

Data link 435 may be any conventional communication link, including, for example, telephony (wired and mobile wireless), specialized mobile radio (SMR), infrared and satellite (both low earth orbit (LEO) and geosynchronous) Server 425 may be provided with the hardware and operational protocols necessary for communicating with remote client 430 by a vanety of means, thereby not restπctmg communication to a remote client having one particular type of data link Providing server 425 with a plurality of communication protocols aids in making the system of the present invention universally acceptable

In one embodiment, server 425 is provided with infrared data link capabilities An infrared data link between the server and the remote client provides a local wireless method of acquinng data from an OBD module It therefore removes the need for the client's equipment to incoφorate a system-compatible connector (I e, an OBD-connector as specified by the SAE) and to be physically joined by a cable in order to communicate with the system

When, for example, the client is test equipment in a garage, the use of an infrared data link renders possible the development of service bays where information can be transferred almost instantaneously from the vehicle to the service technician's computer without requiπng the customer to get out of the vehicle The infrared connection may be achieved by attaching a senal infrared connector to a seπal port on the server and by ensunng that there is an unobstructed path for IR transmission beuveen the LED's of the infrared connector and that of the service technician's computer

As will be apparent, the reliability of an infrared data link is improved with the implementation of a robust protocol which detects transmission errors and avoids collisions by operating in a half-duplex fashion Such protocols are known and have, for example, been implemented by computer and software manufacturers for incoφoration in consumer electronic products such as micro-computers, modems and cellular phones (I e the IrDA stack) Suitable protocols are descnbed in Infrared Data Association, "Seπal Infrared Link Access Protocol (IrLAP)", Version 1 1. June 1996 and Infrared Data Association, "Link Management Protocol". Version 1 1 , January 1996, the contents of both of which are incoφorated herein by reference Through compliance with these infrared protocols, the server achieves a goal of rendeπng client test equipment independent of the OBD protocols Accordingly, any micro-computing equipment which is infrared-aware, such as a desk-top, notebook or palm-top (Personal Digital Assistant or PDA) can effectively become a remote client

In an alternative embodiment, the infrared data link may be replaced or enhanced by incoφorating mobile wireless data links, coupled with the UDP/EP infrastructure for peer-to-peer client/server exchanges over a wide area network This adaptation of the system extends the range of the services offered by the server beyond its capabilities with only the infrared connector and data link The pπnciples descnbed in the previous sections remain the same, with the exception that access to OBD information no longer requires that the vehicle be moved withm infrared detection range (typically 2-5 metres) of the test equipment The vehicle can be in any location which is reachable on the Internet, via a mobile data link The system of the present invention may further compπse a means to transmit generated operational information to a remote client, in the absence of a request from the client, when the generated operational information satisfies predetermined criteπa Such transmissions of the generated operational information implies that server 25 effectively becomes a client with respect to a remote site which is capable of logging the transmission This functionality can be achieved by utilizing the peer-to-peer communication architecture descπbed above and is useful in. for example, alarm/ emergency situations

If. for example, while momtonng the exhaust emissions of a vehicle on the road, the level of carbon monoxide in the exhaust gases exceeds a predetermined level, the diagnostic means can communicate this information directly to server 125 via communication line 175 Server 125 can then transmit an alarm report to a remote site advising of the problem This report can be transmitted m real-time, allowing the problem to be dealt with immediately, rather than having to wait until the vehicle undergoes routine servicing and diagnosis, days or even months after the problem has first come to light

It is envisioned that the threshold values for alarms, as well as the frequency and duration of the alarm message, can be configured either directly at the server dunng installation or servicing, or by using remote commands from the client

The system descnbed herein may also incoφorate Internet access technology for the dπvers or passengers The existing method of Internet access for individual personal computers (PC) is well-known The PC establishes a senal link with a computer which has a permanent Internet (IP) address The latter computer, for the puφoses of this descπption. can be called a gateway The seπal link is physically either a direct cable connection or via a telephone circuit, using modems at both ends of the link The PC does not have a permanent IP address It is assigned a temporary IP address by the gateway for the duration of the connection Therefore, if the link is maintained via a telephone circuit, then the connection automatically terminates when the circuit is dropped and the temporanly assigned IP address ceases to be valid

One of the conventional methods of Internet access from a vehicle follows the technique descπbed above, using an analog cellular phone and a cellular modem By connecting the PC to the cellular modem, the dnver/passenger can obtain a temporary EP address in the same fashion as with wired telephony

Another method of Internet access from a vehicle is a technology called Cellular Digital Packet Data (CDPD), which is a form of packet-switching overlaid on the existing analog cellular infrastructure in the United States CDPD operates with a portion of the bandwidth of the analog cellular system and provides a multiple access data link technology withm each cellular base station^'s temtory of coverage However, contrary to the method already descπbed, the network architecture of CDPD also allows each access device (CDPD modem) to have its own permanent EP address Therefore, no dial-up connection is required to establish the presence of the PC on the Internet It suffices for the PC to be connected to the CDPD modem (which is typically in the form of a credit- card style PCMCIA card) for any Internet traffic from another location to reach the PC

IP V6 is a new version of the Internet Protocol One of the design objectives of EP V6 is to enable portable computing devices (notebooks, palm-tops, etc ) to have permanent IP addresses which can be reached regardless of where the portable device is physically connected to the Internet Therefore, the device could be connected, at different times, to both an office LAN (Local Area Network) as well as a residential LAN, without requmng manual intervention by a network administrator in either LAN to ensure delivery of Internet traffic This is achieved by ensunng that both LAN's have at least one node (computer) which acts as a "Mobility Agent" The Mobility Agent incoφorates software which implements EP V6 and related protocols The puφose of the mobility-related functions m this software is to ensure that roaming computing devices are automatically "discovered" when they establish a link to the Mobility Agent and that the rest of the Internet is informed of the new path which must be used to route traffic to the roaming device Only those routers m the Internet which have been upgraded to 5 support EP V6 will participate in this function

A Mobility Agent can reside m a mobile environment as well as a fixed LAN This scenaπo is a distinct departure from the existing models of Internet access already descπbed A mobile Mobility Agent, installed in a vehicle in the form of a mobile computer, can effectively "host" any IP V6-enable portable computing device, provided 0 that it has a wireless data link to a network which is capable of routing packets on the

Internet, such as CDPD The implication is that if a vehicle is equipped with a Mobility Agent using, for instance. CDPD. then any portable device which a driver or passenger wishes to use in the vehicle to obtain access to the Internet does not also need the CDPD modem It only requires the IP V6 software

5 In order to equip any vehicle with IP V6 support, a hardware platform is required to host all of the required protocols and to provide the data links for portable devices trying to connect to the Mobility Agent In order to support the SAE diagnostic test modes in the remote fashion descπbed herein, the server contains all of the components which will also allow it to function as a mobile Mobility Agent

0 It is envisioned that the Infrared port (and IrDA protocols), which is pnmaπly useful for OBD diagnostic test modes while the vehicle is stationary and being examined, can "double" as an m-vehicle wireless point of entry to the internet for portable devices operated by the dnver/passengers

Another embodiment is shown in figures 8a. 8b which provides an

">s integrated circuit board for a vehicular computing device which supports the following a) Acquisition of diagnostic data via an automotive data bus interface (or directly through analog and digital inputs) and storage of the data

b) Data communications using spread spectrum radio in accordance with the IEEE 802 1 1 specification for wireless local area neuvorks

c) Reception of signals from Global Positioning System satellites and determination of position, heading and speed based on these signals

d) The IEEE 802 1 1 protocol stack is implemented in an additional task executed by the host CPU Depending on the choice of processing resources, the GPS position determination may be earned out by an additional task executed by the host CPU

In both Figures 8a) and 8b), the CPU board 510 compnses the Universal OBD Server host system into which both the spread spectrum modem and GPS receiver functions are integrated m the form of chipsets

In Figure 8a), spread spectrum transceiver circuitry 512 compnses the RF processing functions required for implementation of a spread spectrum radio modem

These are embodied in a seπes of semiconductor devices constituting a chipset for integration of spread spectrum radio in a host CPU board As these devices constitute externally defined components that are integrated m the present invention, only those components that interface with the host system are numbered

Host CPU 520 communicates with spread spectrum transceiver circuitry

512 through (2) seπal interfaces Seπal interface 514 handles inbound data received from the sequence generator 516 while senal interface 518 handles outbound data sent to the decimator 519 The embedded software required to dπve the spread spectrum transceiver is an implementation of the EEEE 802 1 1 specification, executed by the host CPU The functional interface between the host CPU and the spread spectrum sub-system conesponds to the interface between the two bottom layers of the IEEE 802 1 1 physical layer architecture The lower layer is called the Physical Medium Dependent (PMD) sublayer, which is embodied in the spread spectrum transceiver circuitry The upper layer is called the Physical Layer Convergence Procedure (PLCP) sub-layer, which constitutes the lowest level of the protocol stack implemented in software to be executed by the host system

Similarly, in Figure 8 b), GPS reception circuitry 542 compnses the RF processing functions required for implementation of a GPS receiver These are embodied in a seπes of semiconductor devices constituting a chipset for implementation of a GPS receiver As these devices constitute externally defined components that are integrated in the present invention, only those components that mterface with the host system are numbered

Yet another embodiment is shown in figures 9 to 15 The term "Automotive Telemetry" refers to the conveyance of operational data from a mobile vehicle to a regulatory or maintenance authoπty as well as to other, neighbonng mobile vehicles The data transmitted are acquired directly from analog and digital sensors, the m-vehicle data bus, ECU and from a GPS receiver The data are conveyed via a wireless packet-onented data links provided by terrestrial RF packet networks, spread spectrum and satellite

An Automotive Telemetry System according to the present invention may be configured to enable interested parties (regulatory agencies, OEM's, dealers) to obtain cntical automotive performance information in a wireless manner It is believed that a system according to the present invention may also be configured to enable - reliable, substantially eπor-free data communications between the on-board CPU and persistent data storage,

- high-level services in the form of API's (Application Programmer Interfaces) for real-time alarm momtonng, trending and back-office decision-support systems IT developers responsible for maintenance, performance momtoπng and automotive engineeπng systems can invoke high-level services that make the CAN-bus, or any sensors and actuators, appear as though they are directly connected to the fixed-location host system

- flexible communications architecture enabling many-to-many, simultaneous, multiple virtual connections between on-board CPU's and fixed-location host systems This means that both the on-board CPU and the ground-based workstation can maintain client-server relationships with several peers at the same

on-board filtenng intelligence and remote configuration capability The on-board CPU should have the ability to restrict real-time transmission of diagnostic data according to threshold levels that can be dynamically changed from a fixed- location host In addition, the host should also be able to remotely configure the frequency and duration of telemetry reports as well as logging to nonvolatile ram (NOVRAM).

- minimal use of wireless bandwidth There is an inherent economic cost associated with the deployment of infrastructures supporting wireless data links, regardless of the method used to recover this cost Therefore both the application and the communication software should, where possible, minimize the use of these links through such methods as exception-dπven reporting and data compression

An exemplified system according to the present invention has three components

- Universal On-Board Diagnostic (UOBD) Server (m-vehicle telemetry computer)

- Communications Protocol Stack

- Application Programmer Interface (API)

A hardware instantiation of the m-vehicle UOBD Server has been built based on an embedded 80386 CPU and a hard real-time multitasking kernel The current model incoφorates the following features

- 512KB flash memory ( 192 KB for data logging)

- 512 SRAM

- 8 A/D channels for analog sensor inputs - 8 digital channels for discrete inputs (each channel configurable as an output)

- CAN-mterface

- RS-485 seπal ports for interface to J-1708 bus (heavy trucks and buses)

- 2 RS-232 ports for PPP and or IrDA (InfraRed) connections with external computing devices - GPS receiver with NMEA-comphant data link to the CPU

- RF packet radio network interface (Mobitex or ARDIS) - Spread spectrum data link (2 4 GHz ISM band, frequency hopping CMSA/CA protocol)

Real-Time Executive

The operating kernel adopted for the UOBD is RTEMS (Real-time executive for multi -processor systems) However, the entire body of sofuvare embedded in the UOBD (with the exception of the real-time kernel itself and bootstrapping code) is capable of running in alternative operating environments This is achieved through the definition of an abstract operating system in terms of an object-oπented abstract base class, with specific instantiations for whatever operating environments are required

In particular, a Windows NT instantiation of the operating environment has been developed for emulation and testing of the embedded system

Communications Sub-System

The communications sub-system is a protocol stack which supports any combination of terrestrial RF packet network, satcom packet networks and short-range spread spectrum data links As shown in Figure 9, the software architecture treats each wireless data link as part of a sub-network according to the Internet paradigm

The Internet standards are implemented withm the protocol stack so that, if required, the UOBD Server can become addressable on the Internet Internet accessibility to the UOBD Server is an option which facilitates remote diagnostics by a variety of authorized clients The protocol capabilities of the device include both PPP and IrDA (InfraRed) which provide connectivity to other devices in the vehicle such as palm-tops or notebook computers

The architecture of the communications sub-system is designed to provide an infrastructure for "seamless" peer-to-peer communications between the vehicle and a fixed-location host system or another vehicle

The following sections descnbe the vaπous layers of the protocol stack in more detail

Session Layer Automotive Telemetry Protocol

The Automotive Telemetry Protocol (ATP) provides a simple and effective bi-directional request-response mechanism From the vehicle. ATP allows the diagnostic monitor embedded in the UOBD Server to report fault conditions to a host system application In the reverse direction, diagnostic inquiries and parameter configurations can be issued from the host The ATP message syntax is similar to that of SNMP and contains streamed versions of Object Identifiers (OID's) as ameans of specifying the performance or operational parameter to which the message pertains

Figure 10 illustrates this mechanism with the request initiated from a fixed location host However, the implementation of the ATP supports both client and server functionality in either the host or the UOBD Server As such, the UOBD Server may provide simultaneous OBD services to more than one (authonzed) OBD "client"

Sub-net and DataLmk Layers Hybnd RF Short-range spread spectrum data links provide apowerful complement to RF packet networks for vehicle-to- vehicle telemetry and a potentially low-cost mechanism for OBD-IEI compliance monitoπng The UOBD mcoφorates both technologies with the intelligence to switch between them on a "least-cost" basis In order to preserve the IP addressing mechanism allowing for a unique IP address at the interface beuveen the UOBD

-^β" er's IP module and the dnvers for its wireless data links, the present system has implemented the concept of

- an Hybrid Network, which is an abstraction that combines multiple physical data links This is illustrated m Figure 1 1

Any node on a Hybrid Network is either an m-vehicle UOBD Server or a

Hybrid Network Gateway (HNG) This is a ground-based EP gateway to the Hybrid Nen^ork and is functionally symmetrical to the UOBD Server It has an EP module bound to a network interface for the Hybrid Network This network interface has a unique IP address

The current HNG resides on a dedicated Windows NT workstation and effectively provides an EP-level gateway between the Hybnd Neuvork and the rest of the

Internet or coφorate Intranet

The complete protocol stack for a hybnd network node is illustrated in Figure 9 At the lowest level of this stack are data link drivers for RF packet networks A combination of such data links is subsumed by a single abstract Hybnd Network interface. which is responsible for switching outbound transmissions over the least-cost data link in a manner that is transparent to the EP The "cost" of using any given wireless data link is expressed as a measure of "impedance", which is established in terms of the monetary cost of transmission and of the availability of service Figure 12 illustrates the mechanism implemented for switching of mobile- originated frames over the least-cost wireless data link Note that this descπbes the protocol behavior only at the data link layer of the stack The behavior of the stack at other layers is descπbed herembelow

In part (a) of Figure 12. the UOBD CPU sends a frame over the seπal link to the pπmary RF radio modem (spread spectrum), which in turn successfully sends it over the airlmk to a base radio modem (spread spectrum access point) From there, the payload is sent to the Hybnd Network Gateway from where it can be routed over a neuvork backbone (possibly the Internet) to a host system

Part (b) of Figure 12 shows the instance where a mobile-oπginated frame fails to traverse the airlmk In this instance, a failure notification is received, either from the radio modem, or from a timer expiry within the CPU T e failure notification is propagated back up the protocol stack to the process which was responsible for the message contained in the frame (e g the ATP client or server process), which can then choose to reschedule the transmission The failure notification also causes the impedance level for the destination address to be i aised to a maximum level The retry is therefore earned out over the alternate RF data link The impedance will be lowered whenever a notification is received that the mobile has returned withm "RF range" of the base

Neuvork Layer In-Vehicle Routing and EP Header Compression

The IP implementation is intended to enable the UOBD Server to act as a gateway from the wireless HybπdNetwork to a subnet of computing devices used within the vehicle The data link used for any of the devices is PPP (point-to-point protocol) over an RS-232 serial connection This is designed to support a palm-top or notebook computer using PPP with a direct serial link to obtain a temporary EP address In many cases, the Automotive Telemetry System does not encompass more than one host site (client) The mobile UOBD Servers do not therefore need to distinguish beuveen remote addresses Furthermore, the HybπdNetwork Gateway has address tables for resolving all IP addresses to unique physical addresses, associated with each of the RF data links, for each UOBD Therefore, mobile-terminated datagrams do not require an explicit destination address m transmission Similarly, mobile-ongmated datagrams do not require an explicit source address in transmission In these cases, the EP headers can be compressed from 20 to 3 bytes, without loss of information The overhead of 3 bytes is necessary to provide a sequence number for the datagram, an identifier for the transport protocol to be used and the m-vehicle subnet address of the destination Regardless of the protocol, this amount of overhead would be required in any event

The IP implementation supports varying levels of compression simultaneously Telemetry traffic from a "well-known" client is subject to full compression as descπbed above, whereas "external" Internet traffic must preserve more header information

Transport Layer UDP and ICMP

There are two basic types of transport protocol "stream-oπented" and "datagram" The corresponding specifications commonly used m conjunction with the Internet are called, respectively, TCP (Transport Control Protocol) and UDP (User Datagram Protocol)

When the quantities of data transmitted are very small, relative to the maximum size of individual packets allowed over the wireless data links, the transport mechanism used is UDP Typically, this is applied m a « request/response » mechanism one of the following three (3) scenaπos -Host « requests » data for a specific parameter - UOBD Server « responds »

- UOBD Server reports alarm value for a specific parameter - Host confirms alarm received

- Host « commands » UOBD Server to set new configuration value - UOBD Server confirms setting

The transport-level protocols included in the stack are UDP (User Datagram Protocol) and ICMP (Internet Control and Message Protocol) UDP supports the Automotive Telemetry Protocol in a manner identical to its use m other request/response protocols such an SNMP

In contrast to UDP. TCP/IP provides what is commonly referred to as a

« reliable, stream-onented. virtual circuit » Vaπable quantities of data can be pushed mto the circuit at one end. and will be delivered at the other end the same sequence that they were submitted If ercors occur, or individual packets traversing the actual physical networks are lost, the TCP/IP protocol stack is responsible for re-transmission However, this is not manifest to the application software using the circuit At each end of the circuit (called a

« socket ») all that is understood is two steady « streams » of octets (bytes) one for reception and one for transmission

The successful operation of TCPTP requires significant « overhead ». 1 e octets which are not part of the deliverable « payload » but are used for addressing, routing and retransmission control Therefore, in a network environment where transmission of each packet is relatively expensive, such as RF TCP/IP should be used frugally

ICMP is used as an error reporting mechanism, specifically for the case where the destination for an EP datagram cannot be reached This mechanism is used in conjunction with a switching mechanism for directing over the least-cost wireless data link The use of ICMP is illustrated in Figure 13 The fixed location host sends an ATP message using UDP to the mobile (It is irrelevant whether the ATP message is a request or a response UDP is indifferent) The message is transported in an Internet datagram which must transit the Hybrid Network Gateway The HNG attempts to route the datagram to the UOBD using the pnmary RF data link This attempt fails because the UOBD is not currently reachable via the primary RP data link

The HNG is not responsible for attempting a retry Instead, it generates, on reception of the failure notification from the RF data link, an ICMP "destination unreachable" message which is sent to the source address of the ongmal EP datagram The ATP process (either client or server, depending on whether the ATP message was a request or a response) handing this message can reschedule a retransmission at a later time. In the meantime, the HNG will have changed the impedance level of the pnmary RF data link for the destination address in question When the datagram transmission is retried, the HNG will route it through the lower impedance data link, l e. the alternate RF data link. The impedance of the pnmary RF data link will return to its lower level when a registration packet is received from the mobile indicating that it is reachable, I e it is within "RF range"

Figure 9 also shows the TCP and IGMP protocols at the transport level These protocols are not incoφorated in the current version of the UOBD Server but they may have future roles in. respectively, "batch" data acquisition and multicast messaging to fleet groups

API

The API. as described in the system objectives, provides a platform on which application programmers can develop database systems and user interfaces The API resides above the Automotive Telemetry Protocol at the "Presentation" layer of the stack ATP is deπved from SNMP. and therefore the API resembles an interface to SNMP It consists of

"> <. three types of objects which must be allocated and which methods must be invoked to execute the interface The following provides bπef definitions for these objects and a conceptual outline of their use The precise class definitions, function prototypes, initialization sequences and so on. are provided in a separate programmer's manual

Diagnostic information Base (DEB)

These objects are similar to the notion of MIB (Management Information

Base) used in SNMP Each one corresponds to a specific data source from the vehicle, e g engine temperature, oil pressure, fuel level, etc They have a unique OED (object identifier) and a cache vaπable for stonng for the most recent value received from a remote vehicle A DIB must be allocated for each data source which the application intends to monitor from any given vehicle Only one DIB is required for a given data source, regardless of the number of vehicles being monitored In other words, DIB's are not needed for each vehicle but only for each unique type of data

All the DIB's are held in a container belonging to the ATP (see below) When a DEB is allocated, the user must add it to the ATP container by invoking a method of the ATP

Λ.TP (Automotive Telemetry Protocol)

The ATP is the object that encapsulates the UDP portion of the communications protocol stack A method of the ATP is used to allocate a "listener", which is an ATP Server object that handles requests from unknown remote clients If a UDP message had been received from a mobile client for which no ATPClient object (see below) has been allocated, the ATPServer allocates a new ATPClient and registers it with the DIB's

ATPClient An ATPClient should be allocated for each remote vehicle being monitored The ATPClient needs to be "registered" with each DEB in the container belonging to the ATP

Sending requests to a mobile is accomplished in two (2) steps First, the user needs to invoke the appropπate ATPClient methods which will specify the OID. the message type (I e what type of command is being issued to the remote) and any data values which should be appended to the message (e g new thresholds for alarms) In the second step, the transmit method of the ATPClient is invoked

Reception of messages from a mobile, whether requests or responses, is handled withm the ATP The user can provide a "hook" for each ATPClient to process the payload data of both requests and responses This is registered with the ATPClient m the form of a function pointer For processing of requests, the user-supplied function should indicate to the caller whether the data was correctly processed For example, if the request received is to log an alarm to persistent storage and there is an error, a Boolean return code should indicate FALSE As a result, the response message to the mobile will indicate failure and appropnate action can be taken at the mobile end (I e rescheduling the transmission)

Design and Development Practices

Object Design

All software implementation is based on the object-onented design pnnciples of inheπtance and encapsulation This means that every module (class definition) of the sofuvare is derived from an abstract base class (with the exception of the abstract base classes themselves) This section descπbes the class hierarchies at the Operating System level and the data link layer of the protocol stack

f ^"> . Operating Kernel

The operating system level is defined as an abstract set of services, to which user interfaces are standardized in order to facilitate rapid porting of the code to different operating environments This is illustrated in Figure 1 1

Figure 14 also shows vaπous instantiations of the multi-tasking kernel, including a "device emulation" version in Windows NT

Data Link Layer

All the data links in the embedded system, whether airlmks to RF packet neuvorks or internal bus data links (CAN, J-1708) share common logic which is implemented in a geneπc data link object The entire behavior which is unique to any particular data link protocol is encapsulated in class deπvations of an abstract base class called a link identity

This architecture, illustrated in Figure 14, is intended not only to minimize the code space required in the embedded system, but also to facilitate rapid integration of new RF data link protocols, particularly as they become available in the form of newly deployed infrastructures

While this invention has been descπbed with reference to illustrative embodiments, this descπption is not intended to be construed in a limiting sense Vanous modifications of the illustrative embodiments as well as other embodiments will be apparent to a person of skill in the art upon reference to this descπption It is therefore contemplated that the appended claims will cover any such modifications or embodiments APPENDIX A

[ 1 ] Nathanson. M . "System and Method for Providing Mobile Automotive Telemetry", August 1997 ( I^s' Transcontech Patent Filing)

[2] Case. J . Fedor. M . Schoffstall. M , and J Davm. " A Simple Neuvork Management Protocol (SNMP)". RFC 1 157, May 1990

[3] Internet Engineering Task Force. Perkins. C (ed ). " IPv6 Mobility Support". March 1995

[4] Nathanson. M , "System and Method for Hybnd Mobile Data Communications", November 1997 (2^nd Transcontech Patent Filing)

[5] Narten. T , Nordmark, E . and W Simpson, " Neighbor Discovery for EP Version 6

(IPv6)", RFC 1970. August 1996

[6] Deeπng, S and Hmden, R . "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883. December 1995

[7] Conta, A and Deeπng. S . "Internet Control Message Protocol (ICMPvό) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885. December 1995

Claims

What is claimed is

1 A method of exchanging data beuveen a mobile node and an access point on a communication neuvork. compnsmg the steps of

a) providing at least two data links beuveen the mobile node and the access point.

b) measunng impedance on each data link, and

c) transmitting said data across the data link having the lowest impedance

2 A method as defined m claim 1. wherem a first of said data links is established on a spread spectrum band

3 A method as defined m claim 1. wherem said mobile node and said access point are IEEE 802 1 1 compliant

4 A method as defined in claim 1. wherein one of said data links is a satellite RF packet network

5 A method as defined in claim 1. wherein one of said data links is a terrestrial RF packet neuvork

6 A communications system, compnsmg

a mobile node,

a fixed communications neuvork having an access point. a pair of alternative data links, each of which joins said mobile node with said access point, and

a switching unit for switching beuveen said alternative data links to exchange data between said mobile node and said access point

7 A system as defined in claim 6. where said mobile node is Internet addressable

8 A system as defined in claim 6. further compnsmg a measunng module for measunng impedance on each of said data links, said switching unit being operable to select the data link having the least impedance

9 A system as defined m claim 6. wherein both said mobile node and said access point are EEEE 802 1 1 compliant

10 A system as defined m claim 6, wherem said mobile node is one of a plurality of mobile nodes on a communications network

1 1 A system as defined in claim 10. wherein each of said mobile nodes is on a vehicle

12 A system as defined in claim 6, wherein said fixed communications neuvork includes a plurality of access points, wherem said data links join each mobile node with at least one access point

13 A system as defined in claim 12. wherein some of said access points are located adjacent a roadway 14 A system as defined in claim 10 wherem at least some of said mobile nodes are Internet addressable

15 A system as defined in claim 10. wherein at least some of said mobile nodes are IPv6 addressable

16 A communications network for exchanging data beuveen a plurality of vehicles, compnsmg a computing unit onboard a corresponding vehicle, each compunngunit operable in a first phase to broadcast enquiry messages m a region surrounding said vehicle, a second phase to receive reply messages from other vehicles in said region, a third phase to exchange status messages with selected ones of said other vehicles

17 A network as defined in claim 16. wherem each computing unit includes an

IEEE 802 1 1 node

18 A neuvork as defined in claim 16. wherein each computing unit exchanges data using an SNMP-deπved protocol

19 A neuvork as defined in claim 16. wherem each node is Internet addressable

20 A vehicle compnsmg an onboard computing unit which is operable in a first phase to broadcast neighbour solicitation messages in a region surrounding said vehicle, a secondphaseto receive neighbour response messages from computing units of other vehicles in said region, and a third phase to exchange status messages with computing units of selected other vehicles

21 A vehicle as defined in claim 20. which is operable in a fourth phase to exchange data with a remote site 22 A vehicle as defined in claim 21. wherein the remote site is reached through non-mobile neuvork gateway

23 A vehicle as defined in claim 20 wherem said computing unit includes an IEEE 802 1 1 node

24 A vehicle as defined in claim 20. wherein said computing unit is capable of exchanging data using an SNMP protocol

25 A hybnd communications system, compnsmg a wired network portion and a wireless neuvork portion, each having a neuvork connection node, at least two data link means beuveen the network connection nodes, and a switch means for enabling either of the data links for data exchange beuveen said connection nodes

26 A system as defined in claim 25, further compnsmg measurement means for measunng impedance on said data links, said switch means being responsive to said measurement means for enabling the data link having a lower impedance

27 A vehicle communications system having a controller, a datapathway joining said controller with a plurality of vehicle components and means for establishing a data link with other vehicles withm a given region surrounding said vehicle in order to exchange data therewith

28 A system as defined in claim 2^"\ wherein said data link is operable in A spread spectrum band

29 An operational event -reporting system for use by a plurality of neighbonng vehicles to support IVHS compnsmg a plurality of communication units, each onboard a coiτespondmg vehicle to collect operational data from selected components thereof and to exchange data with the communication units of one or more of the neighbonng vehicles

30 A system as defined in claim 29. wherem the communication units broadcast messages on a spread spectrum band

31 A method of exchanging data between a vehicle and at least one remote site, comprising the step of providing the vehicle with a transmitter and receiver capable of transmitting and receiving messages under an SNMP protocol

32 A method as defined in claim 31. herem the at least one data exchange site includes a neighbonng vehicle

33 A method as defined in claim 32. further compnsmg the steps of

- exchanging discovery signals with neighbonng vehicles, and

- exchanging status data with selected ones of the neighbounng vehicles

34 A system for transferπng data beuveen a vehicle and a data exchange site, compπsing a pair of data link means, wherem at least one of said data link means has a varying signal impedance level and switch means for switching beuveen said data link means so that said data is transferred on the data link means having the least impedance

35 A system as defined in claim 34. wherem a first of said data link means is operable in a spread spectrum band

36 An extension of the hybnd RF packet neuvork compπsing (1) an interface to an IEEE 802 1 1 data link integrated in the Hybnd Network Radio.

( n) an EEEE 802 1 1 Access Point acting as an IPv6 router and a foreign mobility- agent for mobile nodes implementing Mobile IP.

(m) an interface to a non-wireless subnetwork from which the Hybnd Network

Gateway can route mobile-terminated traffic through an IEEE 802 1 1 Access Point, and

(IV ) a cluster intelligence module, based on the establishment of ad-hoc networks beuveen a vehicle and its IEEE 802 1 1 neighbors

37 The system according to claim 36. wherem mobile nodes that are ATP- enabled can exchange Internet traffic with regulatory agencies over license-free wireless data links (EEEE 802 1 1 ) whenever connections are established with Mobile IP-enabled Access Points

38 The system according to claim 3", wherein the cluster intelligence module is operable using ATP from vehicular node to acquire information about the automotive behavior of any of its discovered neighbors

39 A method of exchanging data beuveen a mobile node and an access point on a communications neuvork. compnsmg

a) a step for providing at least two wireless data links between the mobile node and the access point.

b) a step for measunng impedance on each data link, and c) a step for transmitting said data across the data link having the lowest impedance

40 A method as defined in claim 39, wherein a first of said data links is established on a spread spectrum band

41 A method as defined m claim 39, wherein the mobile node and the access point are IEEE 802 1 1 compliant

42 A method as defined in claim 39. wherein one of said data links is a satellite RF packet neuvork

43 A method as defined in claim 39. wherein one of said data links is a terrestnal RF packet network

44 A method of exchanging data between a motor vehicle and a remote station, compnsmg

a) a step for providing at least uvo data links beuveen the vehicle and the station.

b) a step for measunng impedance on each data link, and

c) a step for transmitting said data across the data link having the lowest impedance

45 An mter-vehicle communications network, compnsmg at least two motor vehicles, each having an on-board control system, the system including monitonng portion and a spread spectrum radio portion and which is operable to exchange useful vehicle operational data with the control system of the other vehicle

46 A neuvork as defined in claim 45 wherein each monitoπng portion is capable of registenng a vehicular event

47 A neuvork as defined in claim 45, wherein each control system is operable with other vehicular overnde systems to overnde a vehicle function according to a vehicular event

48 A neuvork as defined in claim 45. wherem each control system includes a memory portion for stonng vehicle operational data of the other vehicle

49 A neuvork as defined in claim 45. further compnsmg at least one remote station which includes a spread spectrum radio portion to be capable of exchanging data with either of said vehicles

50 A neuvork as defined in claim 49. wherem the remote station is an internet access point

51 A network as defined in claim 50. wherem the vehicles are operable to exchange data using an SNMP-deπved protocol

52 A network as defined in claim 49. wherem the remote station is located along a road way on which the vehicles are traveling

53 A network as defined in claim 52. wherem a plurality of remote stations are located along said road vav 54 A neuvork as defined in claim 45, where each vehicle is capable of monitonng vehicular events in its own region

55 A motor vehicle compnsmg an onboard general puφose computer and a spread spectrum radio, the computer operable to monitor a number of predetermined operating characteπstics of the vehicle, the spread spectrum radio operable to establish a data link with a radio in at least one other neighbounng vehicle, wherem the computer is capable of identifying at least one vehicular event from data received on the data link

56 A computer program product for operating a programmable computer system on board a motor vehicle, wherem the system includes a spread spectrum radio, compnsmg a computer readable medium including the computer executable steps of

- instructing the radio to issue a signal to a region surrounding the motor vehicle.

- monitoπng the radio for reply signals from other vehicles in the region, and when a reply signal is received from another vehicle,

- establishing a data link with the other vehicle, and

- exchanging operational data with the other vehicle over the data link

57 A mobile automotive telemetry system for installation on-board a vehicle, compnsmg

(0 diagnostic means for monitonng operational functions of the v ehicle and generating operational information.

(n) memory for stonng the generated operational information, and ( in ) a server, in communication with the diagnostic means and the memory, the server compnsmg

(a) means to receive a request from a remote client for the generated operational information. (b) means to retrieve the generated operational information from the memory means, and

(c) means to transmit the generated operational information to the remote client

58 The system according to claim 57, wherem the means to receive and the means to transmit are wireless communication means

59 The system according to claim 58. wherem the wireless communication means is an infrared communication means

60 The system according to claim 57, further compnsmg a means to transmit generated operational information to a remote client, in absence of a request from the client. when the generated operational information satisfies predetermined cπtena

61 The system according to claim 57, further compnsmg an Internet access means

62 The system according to claim 61 , wherem the Internet access means is compliant with IP V6 internet protocol and allows the server to act as a mobility agent

63 The system according to claim 57. further compnsmg means to interface to a global positioning system (GPS) receiver