US20020150050A1 - Automotive telemetry protocol - Google Patents

Automotive telemetry protocol Download PDF

Info

Publication number
US20020150050A1
US20020150050A1 US10014889 US1488901A US2002150050A1 US 20020150050 A1 US20020150050 A1 US 20020150050A1 US 10014889 US10014889 US 10014889 US 1488901 A US1488901 A US 1488901A US 2002150050 A1 US2002150050 A1 US 2002150050A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
data
vehicle
protocol
remote
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10014889
Inventor
Martin Nathanson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Paxgrid Telemetric Systems Inc
Original Assignee
Paxgrid Telemetric Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Images

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • G07C5/008Registering or indicating the working of vehicles communicating information to a remotely located station
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance or administration or management of packet switching networks
    • H04L41/02Arrangements for maintenance or administration or management of packet switching networks involving integration or standardization
    • H04L41/0213Arrangements for maintenance or administration or management of packet switching networks involving integration or standardization using standardized network management protocols, e.g. simple network management protocol [SNMP] or common management interface protocol [CMIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance or administration or management of packet switching networks
    • H04L41/12Arrangements for maintenance or administration or management of packet switching networks network topology discovery or management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing packet switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/166Implementing security features at a particular protocol layer at the transport layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/12Network-specific arrangements or communication protocols supporting networked applications adapted for proprietary or special purpose networking environments, e.g. medical networks, sensor networks, networks in a car or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/04Protocols for data compression
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/16Transmission control protocol/internet protocol [TCP/IP] or user datagram protocol [UDP]
    • H04L69/164Adaptation or special uses of UDP protocol
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32High level architectural aspects of 7-layer open systems interconnection [OSI] type protocol stacks
    • H04L69/322Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/327Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions in the session layer, i.e. layer five
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q9/00Arrangements in telecontrol or telemetry systems for selectively calling a substation from a main station, in which substation desired apparatus is selected for applying a control signal thereto or for obtaining measured values therefrom
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H20/00Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/53Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers
    • H04H20/57Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers for mobile receivers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H60/00Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/29Arrangements for monitoring broadcast services or broadcast-related services
    • H04H60/32Arrangements for monitoring conditions of receiving stations, e.g. malfunction or breakdown of receiving stations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H60/00Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/76Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet
    • H04H60/81Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself
    • H04H60/90Wireless transmission systems
    • H04H60/92Wireless transmission systems for local area
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing packet switching networks
    • H04L43/10Arrangements for monitoring or testing packet switching networks using active monitoring, e.g. heartbeat protocols, polling, ping, trace-route
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing packet switching networks
    • H04L43/16Arrangements for monitoring or testing packet switching networks using threshold monitoring
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/16Transmission control protocol/internet protocol [TCP/IP] or user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATIONS NETWORKS
    • H04W24/00Supervisory, monitoring or testing arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATIONS NETWORKS
    • H04W8/00Network data management
    • H04W8/18Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATIONS NETWORKS
    • H04W8/00Network data management
    • H04W8/18Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20Transfer of user or subscriber data

Abstract

Disclosed is a method of conveying vehicle operation data from a vehicle to a remote monitoring recipient, comprising the steps of establishing a data link between the vehicle and the remote monitoring recipient; collecting vehicle operation data from data sources in the vehicle; packaging the vehicle operation data in a data packet using protocol derived from SNMP; and conveying the data packet over the data link.

Description

    BACKGROUND OF THE INVENTION
  • [0001]
    1. Field of the Invention
  • [0002]
    The present invention relates to automotive telemetry protocols and their use in Intelligent Transportation Systems.
  • [0003]
    2. Description of the Related Art
  • [0004]
    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.
  • [0005]
    More sophisticated vehicular telemetry for commercial fleets has been made possible in the last several years through both terrestrial and 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 be in a particular service bay for example. However, these systems are relatively expensive to operate.
  • [0006]
    A considerable amount of research is being dedicated to developing feasible Intelligent Vehicle Highway Systems (IVHS) which are computer-assisted methods to manage highway infrastructures, synchronize traffic lights, measure traffic flow, to alert drivers to ongoing traffic conditions through electronic billboards and other innovations aimed at improving the quality and efficiency of road transportation systems for vehicles.
  • [0007]
    The California Air Resources Board (CARB) has been a leader in establishing standards for monitoring vehicle emissions. A recent CARB initiative, known as OBD-III, is the third generation of on-board diagnostic requirements, 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 transferring 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.
  • [0008]
    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 industries 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.
  • [0009]
    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 arteries 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 driving distances to avoid collisions and exchanging data with traffic monitoring systems to control such things as driving speeds.
  • [0010]
    It is therefore an object of the present invention to provide an improved platform for vehicular telemetry.
  • [0011]
    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.
  • [0012]
    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
  • [0013]
    In one of its aspects, the present invention provides a method of conveying vehicle operation data from a vehicle to a remote monitoring recipient, comprising the steps of:
  • [0014]
    establishing a data link between the vehicle and the remote monitoring recipient;
  • [0015]
    collecting vehicle operation data from data sources in the vehicle;
  • [0016]
    packaging the vehicle operation data in a data packet using protocol derived from SNMP; and
  • [0017]
    conveying the data packet over the data link.
  • [0018]
    In another of its aspects, the present invention provides a method of conveying vehicle operation data from a vehicle server to a remote monitoring client, comprising the steps of:
  • [0019]
    establishing a data link between the vehicle and the remote monitoring client;
  • [0020]
    collecting vehicle operation data from data sources in the vehicle server;
  • [0021]
    packaging the data in a protocol data unit having a protocol data unit payload, the payload including a plurality of VARIABLE BINDING fields, each VARIABLE BINDING field having an OBJECT IDENTIFIER field of two bytes, a VALUE TYPE field of one byte and a VARIABLE BINDING value of a size according to the VALUE TYPE field; and
  • [0022]
    conveying the protocol data unit over the data link.
  • [0023]
    In still another of its aspects, the present invention provides a method of collecting vehicle operation data from a vehicle for later transmission to a remote monitoring recipient in a manner to minimize the bandwidth requirements for the later transmission, comprising the steps of:
  • [0024]
    providing a vehicle on-board computing device;
  • [0025]
    providing a number of data acquisition modules, each to measure one or more operating characteristics of the vehicle, the operating characteristics corresponding to current values of a set of managed objects;
  • [0026]
    interfacing the vehicle on-board computing device with each of the data acquisition modules;
  • [0027]
    configuring the vehicle on-board computing device to:
  • [0028]
    a) form a diagnostic information base for receiving and storing values for each of the managed objects from each of the corresponding data acquisition modules;
  • [0029]
    b) assemble an event report based on information contained in the diagnostic information base; and
  • [0030]
    c) package the event report in a protocol data unit according to an SNMP-derived protocol.
  • [0031]
    Preferably, the operating characteristics include such things as GPS position, engine speed, road speed, odometer, or engine temperature, or an OBD-II parameter related to vehicle emissions. One OBD-II parameter is misfire detection, though others are also applicable, such as the O2 sensor.
  • [0032]
    In one embodiment, the present invention further comprises the step of enabling the vehicle on-board computing device to:
  • [0033]
    a) establish a data link with the remote monitoring recipient; and
  • [0034]
    b) convey the protocol data unit over the data link.
  • [0035]
    The collecting and packaging and conveying steps may occur at the same or they may occur at different times. The computing device, in this case, may be enabled to collect data at regular or irregular intervals and accumulate some types of data for later transmission, such as distance travelled, or other types of data for immediate transmission, such as a current GPS position or an exceeded regulatory threshold. Alternatively, there may be some instances where the computing device is enabled to convey the protocol data unit over a wired or other data link.
  • [0036]
    Preferably, the method includes the step of enabling the remote monitoring recipient to issue a GET protocol data unit to retrieve the current values for a specific set of managed objects from the vehicle on-board computing device. In this case, the remote monitoring recipient is enabled to wait for an acknowledgement to the GET protocol data unit by the vehicle on-board computing device.
  • [0037]
    Preferably, the method includes the step of enabling the vehicle on-board computing device to issue a TRAP protocol data unit to report a vehicular event.
  • [0038]
    Preferably, the method includes the step of enabling the vehicle on-board computing device to:
  • [0039]
    a) store threshold values or a reporting interval for each vehicular event; and
  • [0040]
    b) issue each TRAP protocol data unit, either when a threshold value has been exceeded or at a corresponding reporting interval.
  • [0041]
    In this case, the TRAP protocol data unit may report such vehicle reports as GPS position and the like.
  • [0042]
    Preferably, the method includes the step of issuing an INFORM protocol data unit from the vehicle to report an exceptional vehicular event. The method, in this case, preferably includes the step of enabling the vehicle on-board computing device to:
  • [0043]
    a) store any one of a plurality of specifications for exceptional vehicular events in the diagnostic information base, including one or more regulatory exceptions, maintenance exceptions or operational exceptions; and
  • [0044]
    b) issue the INFORM protocol data unit when any one of the specified events occurs.
  • [0045]
    In one embodiment, the diagnostic information base contains a specification of what constitutes the occurrence of an “event” and not the event itself. When the event occurs, a record of the event is made in a transmission queue and remains there until an acknowledgement message (in this case a RESP message) is received by the onboard computing device. Accordingly, the method provides, in one embodiment, for a storage of vehicular events in a register or other temporary storage module, the events being specified in the diagnostic information base.
  • [0046]
    The managed object, for example, may be ENGINE TEMPERATURE, and the conditions for that managed object may be a MAXIMUM THRESHOLD, CURRENT VALUE, and a TIME COUNT for recording when the current value is to be measured.
  • [0047]
    An example of a diagnostic information base is shown in the following table:
    TABLE 1
    MANAGED
    OBJECT VALUE 1 VALUE 2 VALUE 3 VALUE 4
    TE: ENGINE THRESHOLD CURRENT MEASURE
    TEMPERA- VALUE EVERY
    TURE 10
    MINUTES
    TO2: O2 THRESHOLD CURRENT MEASURE
    SENSOR VALUE EVERY 30
    MINUTES
  • [0048]
    An example of an event recording register is shown in the following table showing the current values for the managed objects at a particular time T=T1
    TABLE 2
    XT1
    YT1
  • [0049]
    In one example, the INFORM protocol data unit is sent as a result of a regulatory threshold level being exceeded.
  • [0050]
    Preferably, the method includes the step of enabling the vehicular onboard computing device to wait for a confirmation that a previous INFORM protocol data unit has been logged in a data base by the remote monitoring recipient. In this case, the method preferably also includes the step of re-transmitting the INFORM protocol data unit in the absence of a confirmation that a previous INFORM protocol data unit has been logged in a database by the remote monitoring recipient.
  • [0051]
    Preferably, the method includes the step of enabling the remote monitoring recipient to issue a SET protocol data unit to the vehicle on-board computing device to set one or more of the managed objects.
  • [0052]
    The wireless data link may be a radio frequency band under the IEEE 802.11 standard, a satellite RF packet network or a terrestrial RF packet network, or others.
  • [0053]
    In one embodiment, the protocol data unit is a “request”-type (GET, SET or INFORM) protocol data unit, the protocol data unit excluding the ERROR STATUS and ERROR INDEX fields of the SNMP protocol.
  • [0054]
    In one embodiment, the protocol data unit excludes the LENGTH field of each variable binding of the SNMP protocol.
  • [0055]
    In still another of its aspects, the present invention provides a method of conveying vehicle operation data from a vehicle to a remote monitoring recipient, comprising the steps of:
  • [0056]
    establishing a data link between the vehicle and the remote monitoring recipient;
  • [0057]
    collecting vehicle operation data from data sources in the vehicle;
  • [0058]
    packaging the vehicle operation data in a data packet using protocol derived from SNMP; and
  • [0059]
    conveying the data packet over the data link, the protocol data unit being issued in response to a request by the remote monitoring recipient and containing both the request and requested values in the request and being encapsulated within a single message and in a single unfragmented network packet.
  • [0060]
    In still another of its aspects, the present invention provides a method of collecting vehicle operation data from a vehicle for later transmission to a remote monitoring recipient in a manner to minimize the bandwidth requirements for the later transmission, comprising the steps of:
  • [0061]
    providing a vehicle on-board computing device;
  • [0062]
    providing a number of data acquisition modules, each to record a current value of a managed object of the vehicle;
  • [0063]
    interfacing the vehicle on-board computing device with each of the data acquisition modules;
  • [0064]
    configuring the vehicle on-board computing device to:
  • [0065]
    a) form a diagnostic information base for receiving and storing values of the managed objects from each of the data acquisition modules;
  • [0066]
    b) assemble an event report based on information contained in the diagnostic information base; and
  • [0067]
    c) package the event report into a protocol data unit, the protocol data unit including a protocol data unit payload having a plurality of VARIABLE BINDING fields, each VARIABLE BINDING field having an OBJECT IDENTIFIER field of two bytes, a VALUE TYPE field of one byte and a VARIABLE BINDING value of a size according to the VALUE TYPE field.
  • [0068]
    In one embodiment, the protocol data unit includes a header having a PDU TYPE data element with a value corresponding to one of a set of values, the set including a GET value, a SET value, a TRAP value, an INFORM value and a RESPONSE value.
  • [0069]
    In still another of its aspects, the present invention provides a computer implemented system for conveying vehicle operation data from a vehicle to a remote monitoring recipient, comprising:
  • [0070]
    a vehicle on-board computing device in communication with a number of vehicle operation data sources in the vehicle;
  • [0071]
    a wireless communications device for establishing a wireless data link with the vehicle on-board computing device and the remote monitoring recipient;
  • [0072]
    the vehicle on-board computing device being enabled to package the vehicle operation data in a data packet using protocol derived from SNMP for transmission to the remote monitoring recipient over the wireless data link.
  • [0073]
    In still another of its aspects, the present invention provides a computer-readable data structure for collecting and conveying vehicle operation data from a vehicle to a remote monitoring recipient, comprising:
  • [0074]
    an application module for receiving vehicle operation data from a number of data sources in the vehicle;
  • [0075]
    a storage module for storing a diagnostic information base, the diagnostic information base including a number of managed objects for a number of vehicle operation parameters and a number of values for each of the managed objects; and
  • [0076]
    a communication module for conveying protocol data units under a protocol derived from SNMP over a wireless data link to the remote monitoring recipient.
  • [0077]
    In still another of its aspects, the present invention provides a computer program product encoded in a computer readable medium including a plurality of computer executable steps for a computer on-board a vehicle for collecting and conveying vehicle operation data from the vehicle to a remote monitoring recipient, comprising:
  • [0078]
    receiving vehicle operation data from a number of data sources in the vehicle;
  • [0079]
    storing, in a diagnostic information base, a plurality of managed objects for each of a number of vehicle operation parameters;
  • [0080]
    establishing a wireless data link between the computer and the remote monitoring recipient.
  • [0081]
    conveying a number of protocol data units under a protocol derived from SNMP over a wireless data link to the remote monitoring recipient.
  • [0082]
    In still another of its aspects, the present invention provides a signal propagated on a carrier medium, the signal including a packaged protocol data unit containing a payload encoding predetermined operational data of an automotive vehicle, according to a protocol derived from SNMP.
  • [0083]
    Preferably, the payload includes a plurality of VARIABLE BINDING fields, each VARIABLE BINDING field having an OBJECT IDENTIFIER field of two bytes, a VALUE TYPE field of one byte and a VARIABLE BINDING value of a size according to the VALUE TYPE field data unit.
  • [0084]
    Preferably, the payload includes a GPS position segment, a GPS heading segment, a vehicle speed segment or an OBDII vehicle emissions segment.
  • [0085]
    In still another of its aspects, the present invention provides a system for conveying vehicle operation data from a vehicle to a remote monitoring recipient, comprising:
  • [0086]
    vehicle on-board computing means in communication with a number of vehicle operation data source means in the vehicle;
  • [0087]
    wireless communications means for establishing a wireless data link with the vehicle on-board computing means and the remote monitoring recipient;
  • [0088]
    the vehicle on-board computing means being enabled to package the vehicle operation data in a data packet using protocol derived from SNMP for transmission to the remote monitoring recipient over the wireless data link.
  • [0089]
    In still another of its aspects, the present invention provides a method of conveying vehicle operation data from a vehicle to a remote monitoring recipient, comprising:
  • [0090]
    a step for establishing a data link between the vehicle and the remote monitoring recipient;
  • [0091]
    a step for collecting vehicle operation data from data sources in the vehicle;
  • [0092]
    a step for packaging the vehicle operation data in a data packet using protocol derived from SNMP; and
  • [0093]
    a step for conveying the data packet over the data link.
  • [0094]
    In yet another of its aspects, there is provided a computer-readable data structure for collecting and conveying vehicle operation data from a vehicle to a remote monitoring recipient, comprising:
  • [0095]
    an application module for receiving vehicle operation data from a number of data sources in the vehicle;
  • [0096]
    a storage module for storing a diagnostic information base, the diagnostic information base including a number of managed objects for a number of vehicle operation parameters and a number of values for each of the managed objects; and
  • [0097]
    a communication module for conveying protocol data units under a protocol derived from SNMP over a wireless data link to the remote monitoring recipient.
  • [0098]
    In still another of its aspects, the present invention provides a communications network for exchanging data between a plurality of vehicles, comprising a computing unit onboard a corresponding vehicle, wherein the computing unit in a given vehicle is operable to broadcast identity messages and to receive equivalent identity messages from other vehicles in an adjacent region, where said messages are used to identify the neighbouring vehicles in the network for exchanging data with selected ones of the vehicles therein.
  • [0099]
    Preferably, the computing unit is operable to update a list of neighbouring vehicles. In this case, the computing unit may add new neighbour vehicles to the list as identity messages are received from new vehicles entering the region. Alternatively, the computing unit may delete a given neighbour vehicle from the list when identity messages are not received from the given neighbour vehicle after a predetermined period of time. Alternatively, the computing unit deletes a given neighbour vehicle vehicles from the neighbour database when the lack of identity messages received from the given neighbour vehicle indicate that the neighbour vehicle has left the adjacent region.
  • [0100]
    Preferably, the medium of communications is a high frequency channelized RF band and its use by each of said computing units is controlled according to the IEEE 802.11 Medium Access Control (MAC) protocol.
  • [0101]
    Preferably, the computing units are Internet addressable.
  • [0102]
    Preferably, the computing units are IPv6 addressable.
  • [0103]
    Preferably, the computing units exchange data using an SNMP-derived protocol.
  • [0104]
    Desirably, the identity messages include GPS information and the IEEE 802.11 MAC address of the sender, wherein the GPS information includes latitude, longitude, speed and heading information.
  • [0105]
    In one embodiment, all vehicles in the neighborhood broadcast their identity messages over a discovery time period that is sufficient to allow any given vehicle to recognize all its neighbours. Both the length of the discovery period and the geographic size of the region may be adjusted in proportion to the average speed of the vehicles in the neighborhood.
  • [0106]
    If desired, the channel selection for transmission of at least some messages may be based on GPS heading.
  • [0107]
    In one embodiment, each of the computing units further comprises a transmitter and receiver capable of transmitting and receiving messages under an SNMP protocol.
  • [0108]
    In another of its aspects, the present invention provides an automotive vehicle as above.
  • [0109]
    In still another of its aspects, the present invention provides a data structure comprising a speed segment, a heading segment and position segment. Preferably, the position segment includes a longitude portion and a latitude portion.
  • [0110]
    In another of its aspects, the present invention provides a signal propagated on a carrier medium, the signal including a speed segment, a heading segment and a position segment. Preferably, the position segment includes a longitude portion and a latitude portion.
  • [0111]
    In still another of its aspects, the present invention provides a vehicle comprising an onboard computing unit operable to receive messages from other vehicles in an adjacent region for assembling a neighbourhood list for exchanging data with selected ones of the vehicles listed therein.
  • [0112]
    In yet another of its aspects, the present invention provides computer program product for operating a programmable computer system on board a motor vehicle, comprising a computer readable medium including the computer executable steps of receiving messages from other vehicles in an adjacent region and of assembling a neighbourhood list for exchanging data with selected ones of the vehicles listed therein.
  • [0113]
    In yet another of its aspects, the present invention provides a motor vehicle comprising an onboard general purpose computer and a spread spectrum radio, the spread spectrum radio operable to establish a data link with a radio in at least one other neighbouring vehicle, wherein the computer is operable to record messages from at least one other vehicle in an adjacent region for assembling a neighbourhood list, and to identify at least one vehicular event from data received on the data link.
  • [0114]
    In yet another of its objects, the present invention provides a computer-readable data structure for collecting and conveying vehicle operation data from a vehicle on-board computing device and a remote monitoring recipient, comprising:
  • [0115]
    a module for indexing a series of protocol values and corresponding requests and responses for data exchange between the vehicle on-board computing device and the remote monitoring recipient;
  • [0116]
    a module for indexing a series of managed objects for a number of operating characteristics of the vehicle; and
  • [0117]
    a module for recording values for each of the managed objects.
  • [0118]
    Preferably, the data structure further comprises a module for indexing an identity for each remote monitoring recipient.
  • [0119]
    Preferably, the data structure also includes a module for indexing a list of one or more authorization levels for each remote monitoring recipient. These authorization levels may be used to impose conditions on the managed object values being conveyed to the recipient. Some recipients may be entitled to all of the managed object values, others to only some of the them, and still other requesting entities (those not in the list) entitled to none at all.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0120]
    Several preferred embodiments of the present invention will be provided, by way of example only, with reference to the appended drawing, wherein:
  • [0121]
    [0121]FIG. 1 is a schematic view of a protocol stack;
  • [0122]
    [0122]FIG. 2 is a schematic view of a UDP based protocol;
  • [0123]
    [0123]FIG. 3 is a schematic view of a TCP based protocol;
  • [0124]
    [0124]FIG. 4 is a schematic view of a header in a UDP based protocol;
  • [0125]
    FIGS. 5(a) and (b) are perspective schematic views of two network arrangements;
  • [0126]
    [0126]FIG. 6 is a schematic view of an SNMP protocol data unit;
  • [0127]
    [0127]FIG. 7 is a schematic sequential view of a data gram exchange;
  • [0128]
    [0128]FIG. 8 is a schematic view of a GET protocol data unit example;
  • [0129]
    [0129]FIG. 9 is a schematic view of an MIB hierarchy for SNMP;
  • [0130]
    [0130]FIG. 10 is a schematic view of a portion of a DIB hierarchy;
  • [0131]
    [0131]FIG. 11 is a schematic view of a message sequence;
  • [0132]
    [0132]FIG. 12 is a schematic view of a network;
  • [0133]
    [0133]FIG. 13 is a schematic view of a protocol stack for exchanging data using the network of FIG. 12;
  • [0134]
    [0134]FIG. 14 is a schematic view of another network;
  • [0135]
    [0135]FIG. 15 is a time plot of beacon frame sequence;
  • [0136]
    [0136]FIG. 16a is a schematic view of a portion of an adhoc network;
  • [0137]
    [0137]FIG. 16b is a time plot of beacon frames issued by vehicles in network of FIG. 16a;
  • [0138]
    [0138]FIG. 17 is a schematic view of another adhoc network
  • [0139]
    [0139]FIG. 18 is a schematic view of another protocol stack;
  • [0140]
    [0140]FIG. 19 is a schematic view of another protocol data unit;
  • [0141]
    [0141]FIG. 20 is a schematic view of a quadrant divided highway segment;
  • [0142]
    [0142]FIG. 21 is a schematic view of a data exchange during a driving manoeuvre; and
  • [0143]
    [0143]FIG. 22 is a schematic view of data exchange during another driving manoeuvre.
  • DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • [0144]
    Described herein below is a system and method which implements a peer-to-peer Internet-based protocol stack for vehicular diagnostic telemetry. This stack is intended to reside in on-board vehicular embedded systems and to enable remote PC workstations to interact with these systems using standard communications API's such as Winsock.
  • [0145]
    The Session and Presentation layers of the stack are labeled the Automotive Telemetry Protocol (ATP). ATP addresses the need for a clear specification of the message formats, protocol procedures, security mechanisms and external interfaces by which software can be developed for implementation of OBD-III1 on different mobile and fixed computing platforms in an inter-operable fashion.
  • [0146]
    Reviewed below are the objectives sought and then provides a more detailed description of the layers 3-6 (network, transport, session and presentation). It has been shown that the Session and Presentation layers are derived from the specifications for Simple Network Management Protocol (SNMP). The underlying transport mechanism is a UDP/IP stack with the UDP header compressed in the interest of bandwidth efficiency.
  • [0147]
    The issue of security is also addressed below, and the ability to configure an implementation of the stack such that specific sources of data can be restricted to specific requesting entities (“clients”). The application of the Secure Socket Layer (SSL) protocol is reviewed in order to demonstrate the authentication of requests for information from external sources by the on-board computer.
  • [0148]
    The protocol stack is applied to the exchange of operational data between vehicles on the road. This is based on the concept of an “ad-hoc network” established within a “neighborhood” surrounding any given vehicle. The ad-hoc network can co-exist with a data link to the Internet, using the same RF medium, provided that a roadside infrastructure is deployed. The potential of this technology to improve highway safety is illustrated with various examples of vehicle-to-vehicle exchange of operational information.
  • [0149]
    Also described a method for the integration of IEEE 802.11 compliant technology in both intelligent vehicle and intelligent highway systems. Reference will be made herein below to Intelligent Transportation Systems or ITS to encompass any component of such systems, whether on board a vehicle or part of the roadway infrastructure.
  • [0150]
    Much of the current focus of intelligent vehicle technology is directed at collision avoidance based on radar. On the other hand, intelligent highway system development has been largely predicated on the use of short-range communications between the vehicle and the roadway infrastructure. However experts from both the automotive OEM's as well as from government agencies have recognized that vehicle-to-vehicle communications constitutes an area that should be explored going forward.
  • [0151]
    The IEEE 802.11 specification is a relatively new standard for high-speed wireless Local Area Networks (LAN). It uses a method of RF transmission known as spread spectrum for which the 2.4 GHz range has been made available as an unlicensed band. This technology is also identified under the commercial banner Wi-Fi (Wireless Fidelity). Its potential for application in the area of ITS is based on its commercial potential. There are now Wi-Fi products commercially available that make it possible to create network infrastructures supporting mobility for computer devices. Network interface cards (NIC's) are available enabling personal computers, including laptops and notebooks, to use Wi-Fi. As the popularity of Wi-Fi grows, it is expected that more mobile wireless appliances (e.g. PDA's, cell phones) will appear in the marketplace that exploit a growing infrastructure of access points through which users can connect to the Internet wirelessly at bit transfer rates that currently reach 11 Mbps.
  • [0152]
    One feature of IEEE 802.11 is the notion of ad hoc networking, which enables two or more devices to communicate directly with one another without requiring a fixed access point. In other words, the network infrastructure is not a necessary condition for connectivity between mobile devices. As a result, IEEE 802.11 can support concurrent vehicle-to-vehicle and vehicle-to-infrastructure communications in novel and unexpected ways. This combination of flexibility, from a technical perspective, and commercial appeal, is the essential rationale for using IEEE 802.11 in ITS.
  • [0153]
    The method described in this document adheres to the principle of implementing fully-compliant 802.11 nodes, without modification of the specification, to meet the requirements of ad hoc networking for ITS.
  • [0154]
    Relationship to ATP
  • [0155]
    The methods described here are intended to provide a platform on which the Automotive Telemetry Protocol (ATP) can operate between two vehicles. ATP is a session level protocol derived from SNMP that enables a bi-directional client-server relationship to be established between the two end points of the mobile communications [1]. In the context of vehicle-to-vehicle communications, ATP allows a “client” vehicle to send an asynchronous notification to specified “server” vehicle requiring acknowledgement. This request-response mechanism has applications described later in this document.
  • [0156]
    Protocol Stack
  • [0157]
    [0157]FIG. 1 illustrates the complete protocol stack that is required for OBD III, using the OSI (Open Systems Interconnect) reference model.
  • [0158]
    The protocol stack is intended to meet one or more of the following objectives:
  • [0159]
    Wireless Data Link Transparency
  • [0160]
    This refers to the need for technology-independence. It should be possible for OBD-III compliance to be met using a variety of wireless data link technologies. Mobile devices should be able to use packet cellular, RF packet networks, wireless LAN (Wi-Fi), satellite or any combination thereof.
  • [0161]
    Internet Connectivity (Beyond OEM Portals)
  • [0162]
    It should be possible for workstations at remote IP addresses to interact directly with an on-board vehicular device that interfaces to OBD and other operational data within the vehicle. In other words, full Internet connectivity between the vehicle and any remote host is a desired outcome that will enable authorized hosts to run applications that do not have to transit the OEM's portals. This implies that the vehicular device needs to comply with standard protocol specifications that support peer-to-peer exchanges with any authorized host on the Internet. (See Security below in relation to the notion of authorized host).
  • [0163]
    Efficient Bandwidth Utilization
  • [0164]
    The data exchange between fixed sites, responsible for monitoring, and the mobile units should not be unnecessarily “verbose”. There is a tendency in wireless applications to assume that some form of “Web” presentation is required to simplify the user interface (UI), which has been partly responsible for the development of Wireless Application Protocol (WAP). WAP is a technique that offers some compromise between the UI features of the Web and the need for bandwidth efficiency over airlinks. None of these considerations take into account the fact that telemetry traffic is quite different in its purpose than other forms of wireless data and should be supported in a different, yet standards-based manner.
  • [0165]
    Standardized Data Exchange Mechanism
  • [0166]
    The higher levels (Session and Presentation) of the protocol stack need to be standardized, for obvious reasons. This will simplify the task of compliance with OBD-III in all jurisdictions that choose to implement the regulations.
  • [0167]
    Security
  • [0168]
    The need for security has been stressed by CARB. Political acceptance of the OBD-III concept is dependent on the public's confidence that the technology will not become a form of state intrusion into individual privacy. Motorists and vehicle owners should have the perception that electronic controls over the release of information are at least as effective as those that are currently in use in Web-based E-commerce. It is contemplated that the present system will, if needed, be capable of implementing public key cryptography above the Session layer, in much the same manner that it is done in business-to-consumer E-commerce. This ensures that, although there is connectivity with any host on the Internet, only those hosts that obtain authorization through the security mechanisms will receive any “attention” from the vehicle.
  • [0169]
    Network and Transport Layers UDP/IP—In order to understand the context in which ATP operates, the underlying transport mechanism which supports it's needs to be considered. The User Datagram Protocol (UDP) is a transport-level mechanism for “connectionless” client-server communications. UDP constitutes one of the transport protocols that can operate over the Internet. The notion of a “connectionless” protocol refers to the fact that there is no overhead dedicated to the maintenance of reliable end-to-end communications. In this sense, UDP is distinguished from TCP (Transport Control Protocol). The shorter UDP header (8 bytes) reflects this difference.
  • [0170]
    The basic protocol data unit (PDU) of the Internet is called a data gram. The datagram header contains a field that is used to designate the protocol at the next level of the stack. The IANA2 f values for UDP and TCP are, respectively, 17 and 6. The figures below show how the payload of different datagrams can be intended for UDP and TCP, depending on the value of the “protocol” field in the datagram header.
  • [0171]
    As mentioned above, the standard UDP header is eight (8) bytes in length, consisting of:
  • [0172]
    source port (2 bytes)
  • [0173]
    destination port (2 bytes)
  • [0174]
    payload length (2 bytes)
  • [0175]
    checksum (2 bytes)
  • [0176]
    In the conventional uses of UDP, the source and destination ports are IANA-approved numbers associated with processes executing within the sender's and the receiver's address spaces, respectively. There is currently no assigned number for the present automotive telemetry application. The present system uses the number 0×0A (integer 10) to specify the ATP port.3
  • [0177]
    Compression of the UDP Header—In the application of automotive telemetry, the overhead of the UDP header would consume wireless bandwidth without providing any significant advantage to the protocol in terms of flexibility or reliability. Both the source and destination ports can be constrained to use the same number. The payload length can be derived from fields in the underlying network packet or data link frame in which the UDP segment is encapsulated. Finally, the checksum can be viewed as redundant, since the underlying data link protocol(s) should incorporate an integrity check of the data stream anyway.4
  • [0178]
    Given the need to minimize wireless bandwidth consumption, the UDP header is, in one embodiment, reduced to 1 byte in the implementation herein of the mobile communications protocol stack, which is illustrated in FIG. 4. The value in this byte (0×0A or integer 10) identifies the ATP port at both the source and destination.
  • [0179]
    Session and Presentation Layers—ATP resides conceptually at the Session Layer. It is a request/response mechanism, similar to Simple Network Management Protocol (SNMP), which ensures that for every message from either a mobile unit to the base location or vice versa, there is always an acknowledgement. As such, exception reports from vehicles cannot be discarded by the mobile computing platform until the base system has confirmed that they have been logged to a “persistent storage” database.
  • [0180]
    The design philosophy of ATP is based on Simple Network Management Protocol (SNMP) which enables remote diagnostics and configuration of communications devices and is the de-facto standard with which elements of the Internet infrastructure must comply. A comparison can be made between remote diagnostics of communications devices and mobile vehicles. This is illustrated graphically in FIGS. 5(a) and (b).
  • [0181]
    In SNMP the “managed entity” is typically a communication switching device such as a bridge or router. This managed entity implements an “agent”, which is a software module responsible for retrieving requested information and interacting with the remote “manager” through an interface to the communications protocol stack. FIG. 5(a) shows that the top level of this stack is SNMP, which is essentially a combination of the Session and Presentation Layers. The information that a remote manager may request resides in the Management Information Base (MIB), which is a local repository for operational data collected by the device drivers controlling the hardware interfaces to the external world (“Communications Modules”). For instance, a router with an Ethernet adapter maintains statistics reporting the number of inbound and outbound frames transiting the Ethernet interface. This information is cached in the MIB and is retrieved by the Agent on behalf of a remote Manager which has issued a request.
  • [0182]
    In the case of ATP, shown in FIG. 5(b) below, the entity equivalent to the SNMP Manager is called a Monitor, and the managed entity is a vehicular on-board computing device interfaced to various data acquisition modules5. This is called the local data repository a Diagnostic Information Base (DIB). The information cached in the DIB originates from various sources such as the ECU diagnostic port, analog and digital sensors, GPS receiver, and so on. The three examples shown in the figure are:
  • [0183]
    SAE J-1979 (diagnostic test modes required for OBD-II)
  • [0184]
    GPS receiver
  • [0185]
    direct analog and digital input channels
  • [0186]
    This is by no means an exhaustive list of the possible sources of data. Other examples are:
  • [0187]
    SAE J-2190 (recommended supplement to legislation)
  • [0188]
    SAE J-2178 (Normal Vehicle Operation)
  • [0189]
    SAE J-1708 (heavy truck and bus)
  • [0190]
    SAE J-1939 (successor to J-1708)
  • [0191]
    SNMP and ATP Message Formats—The SNMP message consists of a header6 and a Protocol Data Unit (PDU). The header contains two fields:
  • [0192]
    Version Number
  • [0193]
    This specifies the version of SNMP that is being used by the originator of the message.
  • [0194]
    Community Name
  • [0195]
    This serves as a primitive method of authentication. Managers belonging to a community are said to exist within the same administrative domain. When a management agent receives an SNMP message from a manager containing a community name that it does not recognize, it does not participate in the SNMP operation.
  • [0196]
    In the present system, it is preferable to eliminate fields that are potentially redundant in order to reduce the consumption of wireless bandwidth. This is the case with the community name since, as will be shown, a much stronger form of authentication is required at the presentation level (i.e. the layer above ATP). A version number will only become necessary once ATP evolves beyond the experimental stage.
  • [0197]
    SNMP Protocol Operations—The rest of the SNMP message is the Protocol Data Unit (PDU). There are four (4) basic types of request PDU defined in the SNMP specification [1]7:
  • [0198]
    Get
  • [0199]
    A manager uses a Get PDU to retrieve an item from an agent's MIB
  • [0200]
    Set
  • [0201]
    A Set PDU is used by a manager to set a value in an agent's MIB.
  • [0202]
    Trap
  • [0203]
    An agent uses a Trap PDU to send asynchronous notifications or “alerts” to a manager. The manager does not acknowledge these notifications.
  • [0204]
    Inform
  • [0205]
    An Inform PDU is similar to a Trap PDU. Any SNMP entity (either an agent or a manager communicating with another manager) may use an Inform PDU to send asynchronous notifications. In contrast to a Trap PDU, the receiving manager must acknowledge an Inform PDU.
  • [0206]
    Protocol Data Unit Formats—These four categories8 of PDU are highly suited to ATP. Before their use is examined in the context of automotive telemetry, the actual format specification for the SNMP PDU's will be summarized. FIG. 6 illustrates the format for Get, Set and Response PDU's:
  • [0207]
    PDU Type
  • [0208]
    This specifies the type of PDU. This is either one of the four request PDU types already described or a response.
  • [0209]
    Request ID
  • [0210]
    This is essentially a sequence number for the PDU. The receiver of a request PDU uses this in the response PDU so that the sender can match the response with a previously transmitted request. It also ensures that the receiver can filter out duplicate messages. This is particularly important in mobile wireless networking environments, where transient conditions render mobile nodes frequently “unreachable”, which causes the sender to attempt retries. In this kind of scenario, the probability of duplicate messages arriving at the destination is very high.
  • [0211]
    This is shown in FIG. 7. A request PDU, encapsulated in a datagram, is routed to a mobile agent through a gateway to a mobile network. It is then wrapped in a mobile network packet and routed to the mobile agent through a wireless link from the closest RF base station. Whereas the mobile agent may receive the airlink frame containing the packet, the RF base station may not “hear” the acknowledgement that is transmitted in response. After the requisite timeout period, the RF base reports back to the mobile network gateway that the mobile agent is “unreachable”. When this report is propagated back to the sender (ATP monitor), the message is re-transmitted.
  • [0212]
    Error Status
  • [0213]
    This field is used only in response PDU's. It indicates one of a number of errors and error types.
  • [0214]
    Error Index
  • [0215]
    This field is used only in response PDU's. It associates the error (if applicable) with one of the “variable bindings” encapsulated in the remainder of the PDU.
  • [0216]
    Variable Bindings
  • [0217]
    This is the data field of the SNMP PDU. Each variable binding is an association of a particular instance of a managed object, which is part of the MIB, with its current value (with the exception of Get request PDU's, for which the value is ignored). The Object Identifier (OID) field identifies the object instance. The value of the variable is encoded according to the triple TLV (type, length, value), where type specifies the data type, length is the number of bytes in which the value is represented in the subsequent stream and value contains the value in length byte. This encoding scheme follows the practice set out in the Basic Encoding Rules (BER) of the Abstract Syntax Notation language (ASN.1).
  • [0218]
    ASN.1 is an ISO-specified language that is often used to define data exchange protocols at the presentation and applications layers of the OSI model. Its abstract quality enables it to be independent of the different data representation techniques that can be encountered on different computing platforms. Of course, the more abstract the syntax for expressing data structure, the more overhead is required when these structures are serialized in a data stream over a communications network. For this reason, SNMP uses only a subset of ASN.1 (specifically a subset of the BER) in order to restrict the overhead associated with the encoding scheme and therefore preserving bandwidth on the Internet. [2], [3].
  • [0219]
    In ATP, still with the objective of preserving bandwidth (which is all the more important in the mobile environment of ATP) a further restriction may be imposed on the encoding scheme by eliminating the length field for all but variable length strings. This is shown in the detailed format of the variable binding in the previous illustration of the SNMP PDU format. Only the type field is used. The receiver must infer the length of the value field from the received type.
  • [0220]
    This same format has been adopted, in one embodiment, as a model for the ATP PDU's. However, in order to limit unnecessary use of bandwidth in the wireless environment, the following exceptions are made:
  • [0221]
    1. The Error Status and Error Index fields are not present in the request PDU's.
  • [0222]
    2. The value fields for the variable bindings are not present in Get PDU's.
  • [0223]
    3. The lengths of all fields in the PDU's, including the OID and value fields in the variable bindings (excluding character strings), are implicit; i.e. they are not explicitly encoded in the data stream as specified by ASN.1. The lengths of all the header fields are restricted to one byte. The length of OID fields is two bytes and the lengths of the variable binding values are dependent on the value type, which is encoded in one byte.
  • [0224]
    ATP Protocol Operations with the SNMP PDU's—As already stated, the SNMP PDU's, with the modifications described in the previous section, are applicable to the protocol requirements of ATP. Get PDU's are needed when an ATP Monitor wants to retrieve the current values for a specific set of managed objects from a vehicle. An example is illustrated in the FIG. 8. A vehicle owner could obtain, from a fixed-location workstation, the vehicle's GPS location, engine speed, road speed and engine temperature. Both the request for all of this data and the response from the vehicle containing all the requested values would be encapsulated within a single ATP message and a unfragmented network packet.
  • [0225]
    The Trap PDU can be used to send event reports from the vehicle for which acknowledgements are not required. A typical example would be a recurring GPS position report. Application software in the on-board device9 could generate a Trap PDU with the GPS position at an interval specified within the data structure for the GPS “managed object”. The purpose of this reporting would be to track a vehicle in real-time. Therefore acknowledgements from the Monitor are superfluous since the sender has no reason to re-transmit GPS positions that become immediately stale.
  • [0226]
    The Inform PDU, which requires acknowledgements, is the mechanism that is used more commonly in ATP to send a synchronous event report from the vehicle. These events can correspond to:
  • [0227]
    Regulatory exceptions (e.g. emissions-related events requiring intervention)
  • [0228]
    Maintenance exceptions (e.g. fault conditions requiring immediate inspection/validation/repair)
  • [0229]
    Operational exceptions (e.g. use of the vehicle in an unauthorized manner)
  • [0230]
    Since an acknowledgement is required for this PDU, the on-board monitoring agent has a means of determining whether the event report has been logged in a database.10
  • [0231]
    The Set PDU is used to remotely change the operating parameters of the on-board device. This could be, for instance, the threshold level at which a regulatory exception occurs or the interval of unsolicited GPS position reports (for a tracking application with Trap PDU's).
  • [0232]
    MIB Hierarchy and DIB Derivation—The MIB to which SNMP provides access is a collection of managed objects which are organized hierarchically, as shown in FIG. 9. A managed object11 is one of any number of specific characteristics of a managed device. Managed objects are comprised of one or more object instances, which are essentially variables.
  • [0233]
    [0233]FIG. 9 illustrates the MIB hierarchy as a tree, the levels of which are assigned by different organizations. An object identifier (OID) uniquely identifies a managed object in this hierarchy. The top-level OID's belong to different standards organizations, while lower-level OID's are allocated by associated organizations. The OID is formed from the sequence of numbers corresponding to the nodes through which a managed object can be reached from the root of the tree. For example, the sequence:
  • [0234]
    1 3 6 1 2
  • [0235]
    identifies the MIB-2 object, which is the MIB for entities that comply with the specifications of the TCP/IP protocol stack. The full object name is:
  • [0236]
    iso.identified-organization.dod.internet.mgmt.mib-2
  • [0237]
    Suppose that this MIB is maintained on a remote router with interfaces to several networks. The objects representing these interfaces are maintained in a table, each of whose entries is a collection of variables associated with network interfaces. Suppose, for instance, that an SNMP manager wanted to retrieve the number of octets received (since the last start-up) on the first network interface. The OID identifying this object would be:
  • [0238]
    1 3 6 1 2 1 2 1 10
  • [0239]
    and the object name would be
  • [0240]
    iso.identified-organization.dod.internet.mgmt.mib-2.interfaces.iftable.ifentry-1.ifoctets
  • [0241]
    A similar arrangement is contemplated for the hierarchy of the Diagnostic Information Base. The question that arises is whether a DIB sub-tree should branch out from the Internet node or whether an SAE sub-tree should branch out from the Identified Organization. It is evident that these two options would appear as shown in FIG. 10. The illustration makes the root of the new sub-tree should be the DIB node. Furthermore, since ATP is a (proposed) protocol which operates at the same level as SNMP within the Internet suite of protocols, it is also clear that the DIB should exist with the sub-tree starting at the Internet node.
  • [0242]
    It is not evident how the DIB could exist within a sub-tree with its root at the SAE node, without a duplication of the Internet node. This would be a violation of the rule that any node on the hierarchy can be uniquely identified. Therefore, it would appear to be more logical that the new sub-tree originates at the ATP node.
  • [0243]
    As mentioned previously, the OID's in the variable binding of ATP PDU's are encoded in a fixed length of two bytes. This means that the entire parent hierarchy of the object is not included to which the OID refers. The prefix
  • [0244]
    1 3 6 1 2 8
  • [0245]
    corresponding to the object name
  • [0246]
    iso.identified-organization.dod.internet.mgmt.dib
  • [0247]
    is an implicit part of each OID. Only the portion below the DIB node is serialized and transmitted over the network.
  • [0248]
    User Configuration—At the highest level of the protocol stack, there can be some form of user interface allowing the installer (or eventually the driver) to specify which sources of internal vehicular data should be accessible to which remote “clients”. The next section explains how the identity of any remote client can be completely authenticated and how the subsequent data exchange between client and (vehicular) server can be made secure against any eavesdroppers.
  • [0249]
    Security—With ATP, the agent should have the authority to accept or reject requests from the monitor, based on the nature of the request and the identity of the monitor. For instance, a request from a remote monitor to report the current GPS location may be considered an invasion of privacy if it originates from a location not controlled by the vehicle owner. Similarly, a request for OBD information (SAE J-1979) could also be rejected, unless it originates from the monitor(s) authorized according to the User Configuration.
  • [0250]
    In order to meet these requirements, the communications link between the mobile agent and the monitor must provide both for privacy and authentication of the requesting entity; i.e. the monitor. An ideal framework for this is the Secure Socket Layer (SSL) protocol. SSL was developed by Netscape and has become the de-facto standard for inter-operable security between clients and servers in the Internet and particularly for Web-based E-commerce12. SSL defines a handshaking protocol allowing for authentication of either party by the other using public-key encryption methods which are effectively unbreakable.
  • [0251]
    Normally, SSL operates on top of TCP/IP, which constitutes the underlying transport mechanism for Web traffic. However, because of the nature of the telemetry application, ATP uses the UDP/IP stack. The lower edge of the SSL record layer must therefore be adapted to interface to the UDP transport mechanism.
  • [0252]
    [0252]FIG. 11 shows the security mechanism of SSL introduced between the ATP layer and the presentation layer, where the Protocol Data Unit (PDU) is parsed into individual requests for specific sources of data. The security layer acts as an effective “firewall” against unauthorized intruders. It authenticates the remote monitor and maintains privacy for the contents of the subsequent PDU's that are exchanged across the session. The interface between the SSL handshaking protocol and the presentation layer should provide a mechanism for SSL to precede the announcement of a received PDU with an identification of an authenticated monitor requesting information.
  • [0253]
    This mechanism, as well as the subsequent data exchange, is illustrated by the sequence in FIG. 11.
  • [0254]
    The individual steps of this sequence can be described as follows:
  • [0255]
    1. The Monitor's presentation layer notifies its security layer that it wants to issue a request to the Mobile Agent.
  • [0256]
    The SSL Handshaking must now take place between client (Monitor) and server (Mobile Agent).
  • [0257]
    2. The SSL handshake layer asks the SSL Record Layer to encapsulate the requisite handshake message.
  • [0258]
    3. The SSL Record Layer sends an asymmetrically encrypted message (public key cryptography) to the other side.
  • [0259]
    4. The SSL Record Layer delivers a decrypted message to the SSL Handshake layer.
  • [0260]
    Steps 2-4 are repeated in both directions until the authentication of the client has been established.
  • [0261]
    5. Once the Monitor has been authenticated, SSL reports its identity to the presentation layer, so that subsequent requests for information can be accepted or rejected according to the User Configuration.
  • [0262]
    6. The security layer on the Monitor side reports to the presentation layer that the authentication has been confirmed.
  • [0263]
    7. The Monitor's presentation layer sends the PDU to the security layer for session privacy encryption. The encryption is carried out with a symmetrical one-time key exchanged between the parties during the SSL handshaking (and which ensures the privacy of the exchange).
  • [0264]
    8. The encrypted PDU is “transmitted” to the Mobile Agent. In other words, it is passed on down through the Session Layer of the Monitor's protocol stack.
  • [0265]
    9. When the encrypted PDU arrives at the SSL Record Layer of the Mobile Agent, it is decrypted before being handed-off to the Presentation Layer.
  • [0266]
    10. The response from the Presentation Layer is sent to the SSL Record Layer. This response may be:
  • [0267]
    data requested by the monitor
  • [0268]
    a confirmation that a command sent by the Monitor has been executed, or
  • [0269]
    a rejection of either a command or a request for data because the Monitor does not have the requisite authority for the request or command.
  • [0270]
    11. The SSL Record Layer encrypts the response with the symmetrical session key and transmits back to the Monitor (i.e. through the protocol stack starting with the Mobile Agent's Session Layer.
  • [0271]
    12. The Monitor's SSL Record Layer decrypts the PDU and hands it off to the Presentation Layer.
  • [0272]
    Note that all or part of this sequence could be carried out in the reverse direction. Suppose that the Monitor represents an emissions control regulatory agency and that a Mobile Agent receives a request every year from this Monitor to report all non-compliance events. The Mobile Agent may respond with a positive acknowledgement at the presentation layer, i.e. an acceptance of the request. For the rest of the following 365-day period, all exception conditions will cause the Mobile Agent to initiate communications to report these conditions. The request will therefore emanate from the Mobile Agent whereas the response from the Monitor will indicate that the exception report has been noted and logged to permanent storage. (The U-OBD can be configured to keep these exception reports in Flash memory until an acknowledgement is received from the Monitor. This ensures that exceptions that occur while the vehicle is not within coverage range are not “forgotten”).
  • [0273]
    VEHICLE-TO-VEHICLE TELEMETRY—Ad Hoc Networking with Wireless LAN's—OBD-III is an example of telemetry consisting of a mobile server and a fixed-location client. Also envisioned is the case of a client-server relationship between two mobile vehicles. A data link between two vehicles can be established using the ad-hoc networking capability of the IEEE 802.11 specification for wireless LAN. Ad-hoc networks in wireless LAN's are created without a central coordinating node, called an access point. FIG. 12 illustrates the distinction between an ad-hoc wireless LAN and one with an access point.
  • [0274]
    By using different spread spectrum channels, both types of networks can co-exist on the same hardware platform. The access point provides the vehicle with connectivity to a Wide Area Network (i.e. the Internet) but is not required for an ad hoc network. The ad hoc network enables vehicles to establish logical links with their neighbors, which can be used to exchange critical operational information between vehicles.
  • [0275]
    Ad hoc networks can be created using a scheme embodied herein that permits each vehicle to maintain a real-time image of its “neighborhood”. This neighborhood can include vehicles up to five hundred yards in both the forward and rear directions. The image maintained within each vehicle changes dynamically with changes in the surrounding conditions.
  • [0276]
    The ATP protocol stack can be used for vehicle-to-vehicle messaging in almost the same manner as it is used to interact with remote diagnostic clients. The difference is that security restrictions cannot apply in this case since all vehicles must necessarily and freely exchange information. This is illustrated in FIG. 13.
  • [0277]
    Applications: Safety vs. Congestion Management—Vehicle-to-vehicle communications have been used on an experimental basis in the context of “platooning” for Intelligent Transport Systems (ITS). Platooning is simply one example of what is referred to herein below as “cluster intelligence” on the road. A cluster is the aggregation of vehicles within a neighborhood. Since the neighborhood of any vehicle constitutes a fluid network topology surrounding it, the membership of the associated cluster is dynamic.
  • [0278]
    The exchange (or the broadcasting) of information within a cluster has value in terms of both road safety as well as traffic management aimed at reducing congestion. In some respects, there is an artificial distinction between these areas. Better traffic management should result in better safety and vice versa. The descriptions of the following application areas do not distinguish between these two purposes.
  • [0279]
    Redundancy—Vehicle on-board systems such as cruise control or cockpit electronic information systems can benefit from a variety of inputs, including forward collision avoidance radar as well as vehicle-to-vehicle information exchange facilitated by ATP with ad hoc networking.
  • [0280]
    Ad hoc networking is therefore seen as providing a supplementary set of inputs/services to control/information systems. In some instances, these inputs/services may be complementary to one another whereas in other instances they would overlap. For instance, in the case where vehicles are IEEE 802.11-enabled, radar can complement ad hoc networking by providing neighbor information for immediate adjacent vehicles. Of course, if these vehicles are also IEEE 802.11-enabled, this functionality overlaps that of radar. This provides a degree of redundancy that can only be beneficial to the objective of enhanced safety, particularly since the marginal cost of providing services based on IEEE 802.11 is insignificant13.
  • [0281]
    The increasing use of mobile data communications for remote on-board data acquisition has given rise to a need for a standard architecture enabling interoperability of modules participating in vehicular telemetry across wide area networks. The application with the greatest potential for widespread use is wireless On Board Diagnostics (OBD-III), but there is a number of other applications, including vehicle maintenance and tracking. The paradigm of communications network management, where nodes such as bridges and routers can be remotely diagnosed by a management entity, provides an appropriate model for remote vehicular diagnostics. The specifications of the Simple Network Management Protocol (SNMP) are therefore used in novel and unexpected ways as a basis for deriving an
  • [0282]
    Automotive Telemetry Protocol (ATP). ATP operates in an open Internet environment that enables client-server relationships between on-board diagnostic “agents” and “monitors” located anywhere in the network. The SSL protocol is layered above this to provide security. The same protocol architecture, minus the security, can be layered on top of IEEE 802.11-based ad hoc networks for application in intelligent transport systems (ITS).
  • [0283]
    Network Neighbourhood
  • [0284]
    The concept of a network neighbourhood has been borrowed as it is used in the topological sense to characterize adjacent nodes on a data link. If node A can reach (transmit to) node B without traversing a communications bridge, then A and B are said to be in the same neighbourhood. This is illustrated in FIG. 14, which depicts two data links connected via a bridge. The data link on the right is defined by the IEEE 802.3 (Ethernet) specification, which is commonly used for wired Local Area Networks (LAN). The data link on the left is specified by IEEE 802.11 which is wireless LAN. As shown in FIG. 14, A, B and C are neighbours on the wireless LAN, whereas D, E, F and G are neighbours on the wired LAN. Although this is not clearly shown in FIG. 14, the neighbourhoods of both the wireless and wired LAN's are defined by topological relationships between the nodes, not by physical distance. If two nodes share the same medium and the quality of the signals between them is acceptable (in terms of error levels), then they are topologically in the same neighbourhood or adjacent.
  • [0285]
    In the case of an intelligent highway network neighbourhood, an additional geographic criterion can be added, if desired, to the determination of adjacency. By comparing GPS position reports of other nodes on the data link with its own GPS position, each node can filter out other nodes which are outside of a specified geographical threshold and therefore not relevant to the operation of the vehicle.
  • [0286]
    The foregoing description allows up to put forward a definition of an ITS Wi-Fi neighbourhood, from the perspective of a single node.
  • [0287]
    An ITS Wi-Fi neighbourhood is a collection of surrounding IEEE 802.11 nodes, sharing a common physical medium (i.e. a specified direct sequence spread spectrum channel) as well as the timing parameters for medium access control, and within a relative geographic position that is significant to the safe operation of a vehicle on any type of public roadway.
  • [0288]
    Registration on the Network
  • [0289]
    The IEEE 802.11 specification defines timing parameters that are used in conjunction with a timing synchronization function to coordinate access to the medium; i.e. to minimize contention for the channel and to reduce the possibility of collisions. Nodes cannot use the medium to transport data until they have received the appropriate “registration” frames from nodes that are already part of the network. Registration frames contain the information needed to correctly operate on the medium, including a time stamp allowing the new entry to synchronize with the existing nodes.
  • [0290]
    In 802.11, the method used to coordinate access to the medium is called Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) which is similar to the method used in 802.3 (Ethernet). It is based on the idea of “sniffing” the channel for a carrier prior to transmission. If the medium is busy, the node with data to send enters a randomly-computed waiting period before retrying, which minimizes the likelihood of simultaneous retries by multiple nodes waiting for the channel (and the resulting “gridlock” that this would create).
  • [0291]
    The 802.11 specification calls this a distributed coordination function (DCF). It also defines a contention-free mechanism which is called point coordination function (PCF). Whereas DCF is the default mode of operation, PCF has been made available to handle special scenarios, as in the case of time-critical traffic such as audio and video. Typically PCF is provided through a fixed access point, which, in the case of ITS, would take the form of a roadside base station.
  • [0292]
    Vehicles wishing to have access to the Internet will register with roadside access points using the channel(s) allocated for this application14. The performance criteria for streaming audio and video, or for VOIP (Voice Over IP), may require the PCF method of channel management. However, the ad hoc network of vehicles sharing the same neighbourhood will use DCF to manage its channel(s). Since DCF does not rely on the presence of a “master” station to coordinate access to the medium, the ad hoc network does not require a roadside infrastructure in order to function properly.
  • [0293]
    This does not preclude the use of a roadside infrastructure. Even if Internet access and other services are optional, base stations may still be required for a variety of ancillary ITS functions, including differential GPS beacons, geographic orientation with respect to the highway system15, electronic toll collection, electronic road signage and travel information.
  • [0294]
    The registration mechanism itself can be operated in either a passive or an active mode. Both of these methods are described below.
  • [0295]
    Passive Registration
  • [0296]
    In the passive mode, a candidate node listens for a beacon frame from an existing node. In ad hoc networks, all existing nodes transmit beacon frames periodically, allowing nodes entering the network to synchronize with the existing nodes for channel management. A beacon frame signals the start of a contention-free period, during which all other nodes in the neighbourhood defer transmissions so that new nodes wishing to announce their presence can do so. Both the interval between beacon frames and the subsequent contention-free period are configurable parameters that are typically set in the ranges of 1-2 seconds, and 100 ms-0.5 seconds, respectively. However, as will be seen in the next section, there may be several hundred vehicles in the same neighbourhood, particularly in congested highway conditions, which would render these settings impossible. Increasing the interval between beacon frames is only part of the solution. FIG. 15 illustrates that if every one of 100 vehicles were to transmit beacon frames at intervals of 10 seconds, each announcing the start of a 100 ms contention-free period, there would be no time left during the 10 second period to transmit any user data.
  • [0297]
    The complete solution lies in the fact that the ITS ad hoc network nodes do not need to negotiate any of the logical management functions of association and authentication, specified in the medium access control (MAC) layer of 802.11. Association is the mechanism whereby one node requests explicit recognition from another node. In an infrastructure network, requests are sent to an access point, which stores the address of the requesting node in a local table and sends a response frame. The address table maintained by the access point controls whether packets destined for specific addresses are actually transmitted. If no association has been established for an address, no user data will be sent to it.
  • [0298]
    However, as explained in the section entitled Neighbour Discovery, most of the user data in the ITS ad hoc network is sent to the broadcast address (i.e. to all nodes), for which no association is required. There are some applications in which associations with surrounding vehicles are required but these would be only with the physically adjacent vehicles. Each node should only negotiate associations with neighbours inside a prescribed boundary wherein the driving manoeuvres of those neighbours are significant enough to warrant unicast messages (i.e. addressed to specific destination node). Since each node will receive a far greater number of beacon frames from neighbours with which it does not need associations, the contention-free periods following these beacon frames will be essentially wasted. In order to preserve bandwidth, the contention-free period should be reduced to a minimum allowable value (say, 1 ms) and the negotiation of associations should be triggered not by the reception of beacon frames, but by conditions determined through the Discovery process, which is described in the next section.
  • [0299]
    Authentication is the process whereby the requesting node is granted permission to communicate using a symmetrical encryption key. In the ITS ad hoc network, authentication is not only not required, it is anti-thetical to the concept of vehicle platooning or “cluster intelligence” because all parties must necessarily and freely exchange information without restriction.
  • [0300]
    Active Registration
  • [0301]
    The active registration method enables the candidate node to send probe frames, which are essentially “ping” requests for some other node to respond. In the ad hoc network topology, probes must be broadcast to all listeners, as there is no single node that can be relied upon to always be present (i.e. fixed access point). The IEEE 802.11 rule is that the response to a probe is sent by the node which transmitted the most recent beacon frame.
  • [0302]
    The facility of active registration enables us to minimize the use of bandwidth by the transmission of beacon frames. Suppose the interval between beacon frames is configured to 60 seconds. With a contention-free period of only 1 ms after each beacon frame, a platoon of 5 vehicles would use roughly 0.01% of the available time for beacon frame broadcasts, and a platoon of 500 vehicles would use only 1%.
  • [0303]
    The scenario with 5 vehicles is shown in FIGS. 16a and 16 b. The average time between beacon frames is 12 seconds. Each vehicle in the platoon is numbered according to its sequence position for transmitting beacon frames. Vehicle 6, entering on the access ramp, begins transmitting probe request frames after vehicle 4 transmits its beacon frame, in order to discover a new ad hoc network16. Vehicle 4 responds almost immediately with a probe responses17.
  • [0304]
    Neighbour Discovery
  • [0305]
    The neighbour discovery mechanism is comparable to the concept of neighbor discovery protocols used for routing data traffic in network environments with dynamic topologies. The method is based on unsolicited neighbor advertisements that incorporate, as explained previously, a geographic component. These are periodic messages that each node broadcasts containing its GPS information, including latitude, longitude, speed and heading18.
  • [0306]
    The neighbour advertisements are used by each node in the ad hoc network to establish an “image”, in memory, of the current configuration of the neighbourhood. FIG. 17 illustrates this concept, showing the neighbourhood image formed by the second vehicle in the passing lane.
  • [0307]
    The time interval between broadcasts, called the discovery cycle, must be frequent enough to maintain a picture of the neighbourhood that is accurate in terms of the relative position of each neighbour. The accuracy of GPS reports, in terms of the relative location of two nodes in geographic proximity to one another, is much higher than the accuracy of absolute GPS reports, since the error inherent in the processing of the satellite signals should affect all nodes equally. Therefore, the relative position of each node with respect to the other should, theoretically, contain essentially no error, enabling vehicles to judge the distances between them with a level of precision that is effective for the tasks of collision avoidance and platooning. For instance, the position of a vehicle travelling at 70 mph changes by more than 100 ft/sec. This would suggest a requirement for several updates per second in order to maintain accuracy. However, the frequency of updates is constrained by the amount of data traffic that is generated during the discovery cycle, in order to avoid channel contention. This, in turn, is a function of the number of vehicles that are within RF range, i.e. the neighborhood population.
  • [0308]
    It should be recognized, however, that there is a circular relationship between all of these variables. The neighbourhood population is a function of the average speed of the surrounding vehicles. The greater the speed, the smaller the neighbourhood population; therefore the smaller the amount of data traffic in the discovery cycle which allows for a greater frequency of updates.
  • [0309]
    This can be illustrated by example. At 70 mph, the safe stopping distance is roughly 200 feet. Assuming all vehicles respect the recommended stopping distance19, a maximum RF range of 3000 ft20 and a maximum of four lanes in the same direction21, the surrounding neighbourhood can contain a maximum of 60 vehicles.
  • [0310]
    To determine the total amount of traffic that is transmitted over the spread spectrum channel, we must first establish the total size of each discovery packet. This is shown in FIG. 18, which describes the protocol stack from the physical to the session (ATP) layer. It is expected that all of the required user information above the data link layer (IEEE 802 Logical Link Control) can be compressed into 8 bytes. The result is a frame size, at the Physical Layer Convergence Procedure (PLCP) sublayer of 64 bytes. Therefore, the total amount of traffic in the discovery cycle is
  • 64×60=3840 bytes or 30,770 bits.
  • [0311]
    At 11 Mbps22, the data rate of the spread spectrum channel should be able to support several discovery cycles within an interval of one second, even allowing for some degradation of throughput due to channel contention with such a relatively large number of nodes.
  • [0312]
    In order to compensate for this change, the event queue of the “cluster intelligence” process should include a periodic timer that drives an update of the position of all vehicles in the neighbourhood, based on the speed and heading reported in their last broadcasts.
  • [0313]
    Filtering Neighbour Advertisements
  • [0314]
    Each node can limit the population of its neighbourhood such that only those neighbours that are close enough to have a potential impact on the safe operation of the vehicle are included. By filtering out node beyond this boundary, the size of the collections of neighbour “objects” in memory are restricted and the amount of processing necessary to periodically update any state variables belonging to these objects are limited.
  • [0315]
    Message Compression
  • [0316]
    It has been stated that the GPS discovery message can be compressed into 8 bytes. This is accomplished by incorporating only the least significant 2 bytes of both the latitude and longitude23. These 2 bytes represent the fractional part of the minutes portion of the reading. This is sufficient since one minute of latitude or longitude is greater than one mile, which is well beyond the maximum RF range of 0.5 kilometers. Therefore, a receiving node can easily reconstruct the GPS position of the transmitting node by substituting the degrees and minutes of its own GPS position for both latitude and longitude. It must also increment or decrement these values where appropriate near measurement boundaries. For instance, if a receiving node has latitude of 43 degrees and 56.9982 minutes, whereas the message received indicates a fractional value of 0.0053 minutes, the minutes value substituted should be 57 instead of 56.
  • [0317]
    [0317]FIG. 19 illustrates the format of the complete GPS discovery message. The speed is an integer value from 0 to 255 (one byte) and the heading is from 0-360 (9 bits) with 7 bits of fractional degrees. The leading byte indicates, in the most significant bits, the channel to be used by the sender for broadcast on the next discovery cycle. This is explained in the following section. The other bits of the leading byte are reserved for future use.
  • [0318]
    Wi-Fi Channel Selection24
  • [0319]
    The 802.11 specification for mobile applications calls for at least 3 channels of direct sequence spreading (DSS) which can operate concurrently without interference. However, through software-based configuration of the transmitter, more channels can be obtained at lower data rates. For instance, by allocating a single 11 Mbps channel for high speed internet access, a larger number of at least six 2 Mbps channels can be obtained from the remaining bandwidth. This allows mobile nodes to separate ad hoc networking data traffic from infrastructure-based data traffic that uses roadside access points. Since there is no need for communications between vehicles on opposite sides of a median, it suffices for each node to monitor the channel used to broadcast discovery messages by all other nodes travelling in the same direction.
  • [0320]
    In order to avoid unnecessary channel contention between vehicles travelling in opposite directions, the channel selection for discovery broadcasts can be determined on the basis of heading. A simple scheme would be to allocate 4 of the 10 channels for ad hoc networking and to divide the compass into four quadrants25. However, as FIG. 20 shows, this would not handle the case where a slight curvature of the roadway would result in a following vehicle listening to a channel on which the leading vehicle is no longer transmitting. This can be resolved by flagging the discovery message in a way that indicates to neighbours on what channel the next message will be transmitted.
  • [0321]
    In other words, when a vehicle detects that its heading has shifted into a different quadrant, it should not immediately begin transmitting on the corresponding channel. The next message is transmitted on the current channel but all listeners are advised of the channel that will be used on the subsequent message26. Only the following vehicle should switch to monitoring the new channel. It should also switch if it detects the heading change before it receives the change of channel flag from the vehicle ahead.
  • [0322]
    This vehicle enters a transitional phase where it may monitor a different channel than the one on which it transmits. During this period, the next following vehicle will receive messages only from neighbours transmitting on the “old” channel (i.e. prior to the curvature in the road). It will not receive any Discovery messages. More importantly, it will not receive any asynchronous event reports from several vehicles ahead in the platoon. In order to compensate for this, it needs to continuously scan both the “old” and the “new” channels until it receives a “next channel” flag from the vehicle ahead of it.
  • [0323]
    Changing Neighbourhoods
  • [0324]
    To establish the conditions under which a vehicle changes neighbourhoods, reference is made to the definition of an ITS Wi-Fi neighbourhood given earlier. The neighbourhood changes when there is a change in the shared medium. An example of such a change has already been described, when the roadway heading shifts to a new compass quadrant and there is a staged transition of the platoon to a new Wi-Fi channel.
  • [0325]
    In order to address this issue, the following question needs to be answered: how does a vehicle determine that it is entering an expressway without requiring the use of detailed digital maps? The solution is simple if the vehicle is following another one that is entering the expressway. It is the leading vehicle's problem! The following vehicle simply needs to monitor the current channel for a “next channel” flag from the leading vehicle. Of course, this is a facile solution since it shifts the problem to the leading vehicle and besides, it does not address the scenario where there is no leading vehicle that is currently within the neighbourhood.
  • [0326]
    The answer is provided by the mechanism for active network registration using probe frames. When a vehicle detects that it has no one ahead of it, it must begin to probe whichever of the four channels allocated to the quadrants of the compass in which the vehicle's current heading falls. Until it receives a response from some node on the new channel, it should continue to monitor the existing channel used for undivided highways and city roads. One of two possibilities will occur.
  • [0327]
    new neighbours are found (through the discovery mechanism on the existing channel). These could be moving either in the same or the oncoming direction. Or even in a transversal direction. Their locations preclude the possibility that the vehicle is on an access ramp to an expressway. In this case, the vehicle ceases the periodic probes.
  • [0328]
    a probe response is received on the new channel. The vehicle must prepare to switch channels and notify all its current neighbours that it is doing so by setting the “next channel” flag in its next discovery message.
  • [0329]
    This scenario is reversed in the case where a vehicle leaves a divided expressway.
  • [0330]
    Service Advertisements
  • [0331]
    There may be cases where specialized nodes may provide streams of information that would be costly, in terms of bandwidth, to broadcast in an unsolicited fashion. Instead, these nodes can advertise the availability of such services by periodically broadcasting a message notifying all listeners that the service is available upon request. Examples of this would be a digital video camera mounted on board a vehicle or on a traffic signalization light.
  • [0332]
    Applications
  • [0333]
    Safety vs. Congestion Management
  • [0334]
    The application of ad hoc networks to ITS tasks has value in terms of both road safety as well as traffic management aimed at reducing congestion. In some respects, there is an artificial distinction between these areas. Better traffic management should result in better safety and vice versa. The descriptions of the following application areas do not distinguish between these two purposes.
  • [0335]
    Event Notification
  • [0336]
    All nodes participating in an ad hoc ITS network are required to inform their neighbours of any operational events that may be significant to a neighbouring vehicle, such as acceleration, brake application, turn or lane change, etc. These events should be reported as asynchronous notifications sent to the broadcast address. In other words, any neighbour that is listening should receive a real-time notification of the event. For instance, application of the foot brake would be reported not only to the following vehicle behind but to every other vehicle in the following platoon. The reaction time to a brake light (if it is working) is typically in the range of 0.5 seconds. Therefore, if the vehicle at the head of a platoon of seven vehicles applies the foot brake, the vehicle at the end of the platoon could receive notification as much as 3 seconds before seeing the brake lights of the vehicle in front of it.
  • [0337]
    All asynchronous event notifications should be repeated up to n times, where n is a configurable parameter of the IEEE 802.11 MIB (Management Information Base). Repetition of event notifications will ensure that following neighbours required to listen to more than one channel (during the transition phase described in Wi_Fi Channel Selection) will have an opportunity to hear the message.
  • [0338]
    Intention Notification
  • [0339]
    The ad hoc network provides the means for vehicle-to-vehicle notification of intention with respect to driving maneouvres. A class of such notifications can be specified that require explicit acknowledgements from the receiver of the notification. (Acknowledged Connectionless Service of the LLC layer) These correspond to Set commands that can be issued through the use of an ATP client service. By acknowledging these notifications, the receiver informs the sender that it is “aware” of the sender's intentions. The state of knowledge of both parties can then become inputs to their respective control or cockpit electronic information systems.
  • [0340]
    Pass
  • [0341]
    [0341]FIG. 21 demonstrates an example of a driving maneouvre that can be assisted by ad hoc networking. The speed of vehicle A in the passing lane is greater than that of vehicle B in the slow lane. Assuming that the speed of B remains constant, A can determine how much time remains before it passes B, using its own speed and the neighborhood position of B. When the remaining time equals the time interval required for advance notification (Δτ), A sends a unicast frame to B containing a notification of intention to pass on the left. If B responds with an acknowledgement, A is therefore able to provide the appropriate control or driver information system with a confirmation that the vehicle to be passed is “aware” of the intentions.
  • [0342]
    Lane Change
  • [0343]
    The intention to change lanes can be announced and acknowledged in a manner similar to the intention to pass. The vehicle preparing to change lanes issues its notification to the closest following vehicle in the lane to which it intends to change. Again, both parties are aware and prepared for the manoeuvre.
  • [0344]
    Merge/Yield
  • [0345]
    One of the most interesting potential applications of ad hoc networking is the management of lane mergers and yielding on access ramps and lane closure on expressways. As illustrated in FIG. 22, both the yielding and the merging vehicles are aware of each other's location and speed, which provides their respective cockpit electronic information systems with inputs to assist the driver in a smooth adjustment to the new conditions.
  • [0346]
    Intelligent Traffic Signalization/Highway Information Systems
  • [0347]
    Discussed herein above is the capability of Wi-Fi to support concurrent ad hoc networking and infrastructure-based communications. Whereas intelligent traffic lights would be part of the roadside infrastructure, they would need to use the channels allocated for ad hoc networking in order to be effective, since it is only these channels that are regularly monitored by vehicles. Using Wi-Fi, an intelligent traffic light could, for example:
  • [0348]
    transmit a “yellow light” notification to approaching vehicles
  • [0349]
    alert vehicles in the transversal direction of oncoming traffic at high speeds27
  • [0350]
    identify vehicles that run red lights28
  • [0351]
    On the other hand, highway information systems (electronic signage, automated toll collection, etc) should not operate on the ad hoc channels (unless it can be determined that substantial bandwidth remains even under the most congested driving conditions). Vehicles could monitor these infrastructure channels as initiated and terminated by driver input functions.
  • [0352]
    Server
  • [0353]
    The disclosure of PCT Application serial number PCT/CA98/00986 filed Oct. 23, 1998 entitled TELECOMMUNICATIONS SYSTEM specifies the mechanism whereby an Internet gateway to a hybrid network (“Hybrid Gateway”) will forward traffic over one of several alternative wireless data links to the same destination IP address.
  • [0354]
    One embodiment of the method described is differentiated from the prior art in terms of what it does not incorporate, in contrast to what it does incorporate. In that embodiment, when a packet fails to traverse a segment of the path to an Internet destination, it is the responsibility of the last router, prior to the failed segment, to report the error back to the source (as specified in Internet Engineering Task Force RFC 792). The use of ICMP, as foreseen in RFC 792, is all the more important for wireless extensions to the Internet in that failures to reach mobile nodes are expected to be a common occurrence, in contrast to the wired portion of the Internet, where failures indicate an unanticipated problem. Therefore the system described in the disclosure complies with RFC 792. When a failure over a wireless segment is encountered, the router (i.e. the Hybrid Gateway) returns an ICMP “Unreachable” error to the source. It is the responsibility of the source host to attempt re-transmissions of the IP datagram. In the interim, the Hybrid Gateway will have raised the impedance along the wireless data link used on the first attempt. Therefore, when the re-transmitted datagram arrives from the source host, the routing function will take into account the increased impedance and forward the datagram along a less expensive path.
  • [0355]
    This embodiment enables the system to “scale” to a level where the data traffic for large numbers of mobile nodes (10,000-100,000 or greater) can be effectively supported by the Hybrid Gateway, without having to allocate memory and system resources (e.g. timers) to keep track of failed packets and re-transmission attempts. An analogy can be drawn between this scenario and a letter that is mailed to an incorrect address. Suppose the addressee no longer lives at that location. The Post Office can not take the responsibility of trying to find the addressee and to deliver the letter, because this would be too costly. The letter is simply returned to the sender. The disclosure describes a similar methodology, which adheres to IETF principles and minimizes cost, whereas the prior art implies that the entity responsible for routing has unlimited resources with which to assume responsibility for delivering failed packets.
  • [0356]
    References
  • [0357]
    The subject matter of each of the references herein below is incorporated herein by reference.
  • [0358]
    [1] J. D. Case, M. Fedor, M. L. Schoffstall, and C. Davin. “Simple Network Management Protocol (SNMP)”, RFC 1157, SNMP Research, Performance Systems International and MIT Laboratory for Computer Science, May, 1990
  • [0359]
    [2] Information processing systems—Open Systems Interconnection, “Specification of Abstract Syntax Notation One (ASN.1)”, International Organization for Standardization, International Standard 8824, December 1987.
  • [0360]
    [3] Information processing systems—Open Systems Interconnection, “Specification of Basic Encoding Rules for Abstract Notation One (ASN.1)”, International
  • [0361]
    [4] A. O. Freier, P. Karlton, P. C Koche, “The SSL Protocol, Version 3.0”, Internet Draft, Netscape Communications, March 1996.
  • [0362]
    [5] Internet Engineering Task Force, Perkins, C. (ed.), “IPv6 Mobility Support”, March 1995.
  • [0363]
    [6] Narten, T., Nordmark, E., and W. Simpson, “Neighbor Discovery for IP Version 6 (IPv6)”, RFC 1970, August 1996.
  • [0364]
    [7] Deering, S. and Hinden, R., “Internet Protocol, Version 6 (IPv6) Specification”, RFC 1883, December 1995.
  • [0365]
    [8] Conta, A. and Deering, S., “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification”, RFC 1885, December 1995.

Claims (20)

  1. 1. A method of collecting vehicle operation data from a vehicle for later transmission to a remote monitoring recipient in a manner to minimize the bandwidth requirements for the later transmission, comprising the steps of:
    providing a vehicle on-board computing device;
    providing a number of data acquisition modules, each to measure one or more operating characteristics of the vehicle, the operating characteristics corresponding to current values of a set of managed objects;
    interfacing the vehicle on-board computing device with each of the data acquisition modules;
    configuring the vehicle on-board computing device to:
    a) form a diagnostic information base for receiving and storing values for each of the managed objects from each of the corresponding data acquisition modules;
    b) assemble an event report based on information contained in the diagnostic information base; and
    c) package the event report in a protocol data unit according to an SNMP-derived protocol.
  2. 2. A method as defined in claim 1 wherein the operating characteristics include GPS position, engine speed, road speed, or engine temperature, or an OBD-II parameter related to vehicle emissions.
  3. 3. A method as defined in claim 2 wherein the OBD-II parameter includes misfire detection.
  4. 4. A method as defined in claim 1, further comprising the step of enabling the vehicle on-board computing device to:
    a) establish a data link with the remote monitoring recipient; and
    b) convey the protocol data unit over the data link.
  5. 5. A method as defined in claim 4, further comprising the step of enabling the remote monitoring recipient to issue a GET protocol data unit to retrieve the current values for a specific set of managed objects from the vehicle on-board computing device.
  6. 6. A method as defined in claim 5 further comprising the step of enabling the remote monitoring recipient to wait for an acknowledgement to the GET protocol data unit by the vehicle on-board computing device.
  7. 7. A method as defined in claim 4, further comprising the step enabling the vehicle on-board computing device to issue a TRAP protocol data unit to report a vehicular event.
  8. 8. A method as defined in claim 7 further comprising the step of enabling the vehicle on-board computing device to:
    a) store threshold values or a reporting interval for each vehicular event; and
    b) issue each TRAP protocol data unit, either when a threshold value has been exceeded or at a corresponding reporting interval.
  9. 9. A method as defined in claim 8 wherein the TRAP protocol data unit reports a GPS position.
  10. 10. A method as defined in claim 4, further comprising the step of issuing an INFORM protocol data unit from the vehicle to report an exceptional vehicular event.
  11. 11. A method as defined in claim 10, further comprising the step of enabling the vehicle on-board computing device to:
    a) store any one of a plurality of specified exceptional vehicular events in the diagnostic information base, including one or more regulatory exceptions, maintenance exceptions or operational exceptions; and
    b) issue the INFORM protocol data unit when any one of the specified events occurs.
  12. 12. A method as defined in claim 11 wherein the INFORM protocol data unit is sent as a result of a regulatory threshold level being exceeded.
  13. 13. A method as defined in claim 11 further comprising the step of enabling the vehicular onboard computing device to wait for a confirmation that a previous INFORM protocol data unit has been logged in a data base by the remote monitoring recipient.
  14. 14. A method as defined in claim 13, further comprising the step of re-transmitting the INFORM protocol data unit in the absence of a confirmation that a previous INFORM protocol data unit has been logged in a database by the remote monitoring recipient.
  15. 15. A method as defined in claim 4, further comprising the step of enabling the remote monitoring recipient to issue a SET protocol data unit to the vehicle on-board computing device to set one or more of the managed objects.
  16. 16. A method as defined in claim 4, wherein the data link is wireless and includes an radio frequency band under the IEEE 802.11 standard, a satellite RF packet network or a terrestrial RF packet network.
  17. 17. A method as defined in claim 4 wherein the protocol data unit is a REQUEST protocol data unit, the protocol data unit excluding the ERROR STATUS and ERROR INDEX fields of the SNMP protocol.
  18. 18. A method as defined in claim 4 wherein the protocol data unit excludes the LENGTH field of each variable binding of the SNMP protocol.
  19. 19. A method of conveying vehicle operation data from a vehicle to a remote monitoring recipient, comprising the steps of:
    establishing a data link between the vehicle and the remote monitoring recipient;
    collecting vehicle operation data from data sources in the vehicle;
    packaging the vehicle operation data in a data packet using protocol derived from SNMP; and
    conveying the data packet over the data link, the protocol data unit being issued in response to a request by the remote monitoring recipient and containing both the request and requested values in the request and being encapsulated within a single message and in a single unfragmented network packet.
  20. 20. A computer implemented system for conveying vehicle operation data from a vehicle to a remote monitoring recipient, comprising:
    an vehicle on-board computing device in communication with a number of vehicle operation data sources in the vehicle;
    a wireless communications device for establishing a wireless data link with the vehicle on-board computing device and the remote monitoring recipient;
    the vehicle on-board computing device being enabled to package the vehicle operation data in a data packet using protocol derived from SNMP for transmission to the remote monitoring recipient over the wireless data link.
US10014889 1999-06-17 2001-12-14 Automotive telemetry protocol Abandoned US20020150050A1 (en)

Priority Applications (11)

Application Number Priority Date Filing Date Title
US13957399 true 1999-06-17 1999-06-17
US14827099 true 1999-08-11 1999-08-11
US18702200 true 2000-03-06 2000-03-06
CAPCT/CA00/00712 2000-06-19
PCT/CA2000/000712 WO2000079727A3 (en) 1999-06-17 2000-06-19 Vehicular telemetry
US23992000 true 2000-10-13 2000-10-13
US25288500 true 2000-11-27 2000-11-27
US25589600 true 2000-12-18 2000-12-18
PCT/CA2001/001420 WO2002031793A3 (en) 2000-10-13 2001-10-15 Automotive telemetry protocol
CAPCT/CA01/01420 2001-10-15
US10014889 US20020150050A1 (en) 1999-06-17 2001-12-14 Automotive telemetry protocol

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US10014889 US20020150050A1 (en) 1999-06-17 2001-12-14 Automotive telemetry protocol
US11616203 US7593999B2 (en) 1997-08-26 2006-12-26 Automotive telemetry protocol
US12535502 US20100030423A1 (en) 1999-06-17 2009-08-04 Automotive telemetry protocol
US13022101 US8560609B2 (en) 1997-08-26 2011-02-07 Automotive telemetry protocol
US14014851 US9633562B2 (en) 2000-10-13 2013-08-30 Automotive telemetry protocol
US15495518 US9922557B2 (en) 2000-10-13 2017-04-24 Automotive telemetry protocol

Related Parent Applications (2)

Application Number Title Priority Date Filing Date
CAPCT/CA01/10420 Continuation 2001-10-15
PCT/CA2001/001420 Continuation WO2002031793A3 (en) 2000-10-13 2001-10-15 Automotive telemetry protocol

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11616203 Continuation US7593999B2 (en) 1997-08-26 2006-12-26 Automotive telemetry protocol

Publications (1)

Publication Number Publication Date
US20020150050A1 true true US20020150050A1 (en) 2002-10-17

Family

ID=27567526

Family Applications (2)

Application Number Title Priority Date Filing Date
US10014889 Abandoned US20020150050A1 (en) 1999-06-17 2001-12-14 Automotive telemetry protocol
US11616203 Active US7593999B2 (en) 1997-08-26 2006-12-26 Automotive telemetry protocol

Family Applications After (1)

Application Number Title Priority Date Filing Date
US11616203 Active US7593999B2 (en) 1997-08-26 2006-12-26 Automotive telemetry protocol

Country Status (1)

Country Link
US (2) US20020150050A1 (en)

Cited By (95)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030028292A1 (en) * 2001-08-03 2003-02-06 Nissan Motor Co., Ltd. Distributed information collecting system
US20030046327A1 (en) * 2001-08-31 2003-03-06 Juergen Reinold Linked vehicle active networks
US20040021579A1 (en) * 2002-05-07 2004-02-05 Oursler Mark A. Commercial vehicle electronic screening hardware/software system with primary and secondary sensor sets
US20040051664A1 (en) * 2002-09-17 2004-03-18 Frank Ed H. Method and system for location based configuration of a wireless access point (WAP) and an access device in a hybrid wired/wireless network
US20040073361A1 (en) * 2002-10-15 2004-04-15 Assimakis Tzamaloukas Enhanced mobile communication device, and transportation application thereof
WO2004047045A1 (en) * 2002-11-19 2004-06-03 Thierry Racine Accident prevention system
US20040215373A1 (en) * 2003-04-22 2004-10-28 Samsung Electronics Co., Ltd. System and method for communicating vehicle management information between vehicles using an ad-hoc network
US20040217852A1 (en) * 2000-04-24 2004-11-04 Kolls H. Brock Method for characterizing a vehicle's fuel efficiency
US20040230370A1 (en) * 2003-05-12 2004-11-18 Assimakis Tzamaloukas Enhanced mobile communication device with extended radio, and applications
US20040252637A1 (en) * 2003-06-12 2004-12-16 Laberteaux Kenneth P. Robust, low-delay, fast reconfiguring wireless system
US20040254700A1 (en) * 2003-06-12 2004-12-16 Fehr Walton L. Automotive switch fabric with improved QoS and method
WO2005004079A1 (en) * 2003-06-25 2005-01-13 Julian Weis A device for exchaging data between moving vehicles
US20050165514A1 (en) * 2004-01-28 2005-07-28 General Motors Corporation Method and system for managing registration requests of telematics units
US6928348B1 (en) 2001-04-30 2005-08-09 Reynolds & Reynolds Holdings, Inc. Internet-based emissions test for vehicles
US20050191988A1 (en) * 2004-02-26 2005-09-01 Research In Motion Limited Mobile communications device with security features
US20050221759A1 (en) * 2004-04-01 2005-10-06 Spadafora William G Intelligent transportation system
US20060052142A1 (en) * 2001-07-24 2006-03-09 Herz Frederick S M Mobile link selection method for establishing highly efficient communications between mobile devices
US7061924B1 (en) * 2001-05-24 2006-06-13 Intel Corporation Methods and apparatus for remote metering
US20060126669A1 (en) * 2004-12-14 2006-06-15 Snap-On Incorporated Data alignment method and system
US20060171306A1 (en) * 2005-01-28 2006-08-03 Craig Stout Socket management for always-on data connections
US7113127B1 (en) * 2003-07-24 2006-09-26 Reynolds And Reynolds Holdings, Inc. Wireless vehicle-monitoring system operating on both terrestrial and satellite networks
US20060259204A1 (en) * 2005-05-10 2006-11-16 Jordan Patrick D Vehicle network with time slotted access and method
US20070036089A1 (en) * 2005-08-09 2007-02-15 Metke Anthony R Method and system for data transmission in a wireless network
WO2006052943A3 (en) * 2004-11-08 2007-02-22 Toyota Technical Ct Usa Inc System and method of vehicular wireless communication
US7188026B2 (en) 2003-05-12 2007-03-06 Dash Navigation, Inc. Hierarchical floating car data network
US20070083304A1 (en) * 2005-10-06 2007-04-12 Denso Corporation On-vehicle network diagnosis system and on-vehicle control apparatus thereof
DE102005059522A1 (en) * 2005-12-13 2007-06-14 Siemens Ag Communication system of a motor vehicle and method for establishing a wireless ad-hoc wireless network
US20070239322A1 (en) * 2006-04-05 2007-10-11 Zonar Comliance Systems, Llc Generating a numerical ranking of driver performance based on a plurality of metrics
US20070294031A1 (en) * 2006-06-20 2007-12-20 Zonar Compliance Systems, Llc Method and apparatus to utilize gps data to replace route planning software
US20080005071A1 (en) * 2006-06-28 2008-01-03 Microsoft Corporation Search guided by location and context
US20080005073A1 (en) * 2006-06-28 2008-01-03 Microsoft Corporation Data management in social networks
US20080015748A1 (en) * 2006-07-14 2008-01-17 David Nagy System for monitoring, controlling, and reporting vehicle operation through onboard diagnostic port
US20080016504A1 (en) * 2006-07-14 2008-01-17 Wesley Homer Cheng Dynamically programmable electronic data collection system combining declarative programming and native coding
US20080016207A1 (en) * 2006-07-14 2008-01-17 Wesley Homer Cheng Electronic driver log application with bi-directional messaging to multiple backend systems
EP1883905A1 (en) * 2005-05-10 2008-02-06 Scania CV AB (PUBL) Transmission of vehicle related data between a vehicle and a vehicle support centre
US20080082221A1 (en) * 2006-07-14 2008-04-03 David Nagy System for monitoring, controlling, and reporting vehicle operation through onboard diagnostic port
US20080151889A1 (en) * 2006-12-20 2008-06-26 Honeywell International Inc. Distance adaptive routing protocol
US20080151793A1 (en) * 2006-12-20 2008-06-26 Honeywell International Inc. Voice-over-internet protocol intra-vehicle communications
US20080151841A1 (en) * 2006-12-20 2008-06-26 Honeywell International Inc. Configuration aware packet routing in an ad-hoc network
US7406710B1 (en) * 2000-12-29 2008-07-29 At&T Delaware Intellectual Property, Inc. System and method for controlling devices at a location
US20080285452A1 (en) * 2007-05-14 2008-11-20 Cisco Technology, Inc. Remote monitoring of real-time internet protocol media streams
US20080285463A1 (en) * 2007-05-14 2008-11-20 Cisco Technology, Inc. Tunneling reports for real-time internet protocol media streams
US20080310316A1 (en) * 2007-06-18 2008-12-18 Cisco Technology, Inc. Surrogate Stream for Monitoring Realtime Media
US20080316007A1 (en) * 2001-09-11 2008-12-25 Zonar Systems, Inc. System and process to ensure performance of mandated inspections
US20090010158A1 (en) * 2007-07-06 2009-01-08 Cisco Technology, Inc. Quasi rtp metrics for non-rtp media flows
US20090010268A1 (en) * 2004-04-02 2009-01-08 Fondazione Silvio Tronchetti Provera Controlling Access to a Shared Communication Medium of a Mobile Adhoc Network
US7502672B1 (en) 2000-04-24 2009-03-10 Usa Technologies, Inc. Wireless vehicle diagnostics with service and part determination capabilities
US20090190514A1 (en) * 2008-01-24 2009-07-30 Honeywell International Inc. Method for enhancement of multicasting forwarding protocol in a wireless network
US20090222280A1 (en) * 2008-02-29 2009-09-03 Shiva Mittal System and method for certification data management
US7589726B2 (en) * 2002-03-21 2009-09-15 Nokia Corporation Service/device indication with graphical interface
US7747365B1 (en) 2001-03-13 2010-06-29 Htiip, Llc Internet-based system for monitoring vehicles
WO2007034428A3 (en) * 2005-09-20 2010-09-10 Maxtech Networks Ltd Real time peer to peer network
US20110038225A1 (en) * 2009-08-12 2011-02-17 Stig Rune Lennart Tenghamn Method for generating spread spectrum driver signals for a seismic vibrator array using multiple biphase modulation operations in each driver signal chip
US20110044172A1 (en) * 2009-08-19 2011-02-24 Raymond Yim Method and Protocol for Congestion Control in a Vehicular Network
US7904219B1 (en) 2000-07-25 2011-03-08 Htiip, Llc Peripheral access devices and sensors for use with vehicle telematics devices and systems
US20110060828A1 (en) * 2007-12-20 2011-03-10 Honeywell International Inc. Automatic sequencing based on wireless connectivity
US7945358B2 (en) 2005-08-18 2011-05-17 Environmental Systems Products Holdings Inc. System and method for testing the integrity of a vehicle testing/diagnostic system
US7944345B2 (en) 2001-09-11 2011-05-17 Zonar Systems, Inc. System and process to ensure performance of mandated safety and maintenance inspections
US20110119546A1 (en) * 2009-11-18 2011-05-19 Cisco Technology, Inc. Rtp-based loss recovery and quality monitoring for non-ip and raw-ip mpeg transport flows
US20110131074A1 (en) * 2009-09-24 2011-06-02 David S Gilleland Maintenance control system
US7983820B2 (en) 2003-07-02 2011-07-19 Caterpillar Inc. Systems and methods for providing proxy control functions in a work machine
US20110307540A1 (en) * 2010-06-10 2011-12-15 Research In Motion Limited Method and system for reducing transmission of redundant data
US20110320111A1 (en) * 2010-06-23 2011-12-29 Massachusetts Institute Of Technolgoy System and method for providing road condition and congestion monitoring using smart messages
US8090598B2 (en) 1996-01-29 2012-01-03 Progressive Casualty Insurance Company Monitoring system for determining and communicating a cost of insurance
US8140358B1 (en) 1996-01-29 2012-03-20 Progressive Casualty Insurance Company Vehicle monitoring system
EP2494743A2 (en) * 2009-10-27 2012-09-05 Microsoft Corporation Quality of service (qos) based systems, networks, and advisors
US8311732B2 (en) * 2008-09-05 2012-11-13 Microsoft Corporation Navigation communication with self-identifying elements
US20130018574A1 (en) * 2011-07-11 2013-01-17 Harman International Industries, Incorporated System and method for determining an optimal route using aggregated route information
US8400296B2 (en) 2001-09-11 2013-03-19 Zonar Systems, Inc. Method and apparatus to automate data collection during a mandatory inspection
WO2013053579A1 (en) * 2011-10-10 2013-04-18 Alcatel Lucent Emission reporting and monitoring
US20130346574A1 (en) * 2012-06-26 2013-12-26 Juniper Networks, Inc. Filtering within device management protocol queries
US20140029588A1 (en) * 2002-02-05 2014-01-30 Sony Corporation Wireless communication system and wireless communication control method, wireless communication device and wireless communication method, and computer program
US8736419B2 (en) 2010-12-02 2014-05-27 Zonar Systems Method and apparatus for implementing a vehicle inspection waiver program
US8810385B2 (en) 2001-09-11 2014-08-19 Zonar Systems, Inc. System and method to improve the efficiency of vehicle inspections by enabling remote actuation of vehicle components
US8819714B2 (en) 2010-05-19 2014-08-26 Cisco Technology, Inc. Ratings and quality measurements for digital broadcast viewers
US8966551B2 (en) 2007-11-01 2015-02-24 Cisco Technology, Inc. Locating points of interest using references to media frames within a packet flow
US8972179B2 (en) 2006-06-20 2015-03-03 Brett Brinton Method and apparatus to analyze GPS data to determine if a vehicle has adhered to a predetermined route
CN104410706A (en) * 2014-12-10 2015-03-11 林斌 Urban smog treatment coordinating system
US9197857B2 (en) 2004-09-24 2015-11-24 Cisco Technology, Inc. IP-based stream splicing with content-specific splice points
US9230437B2 (en) 2006-06-20 2016-01-05 Zonar Systems, Inc. Method and apparatus to encode fuel use data with GPS data and to analyze such data
US9323546B2 (en) 2014-03-31 2016-04-26 Ford Global Technologies, Llc Targeted vehicle remote feature updates
US9325650B2 (en) 2014-04-02 2016-04-26 Ford Global Technologies, Llc Vehicle telematics data exchange
US9384111B2 (en) 2011-12-23 2016-07-05 Zonar Systems, Inc. Method and apparatus for GPS based slope determination, real-time vehicle mass determination, and vehicle efficiency analysis
US9396269B2 (en) 2006-06-28 2016-07-19 Microsoft Technology Licensing, Llc Search engine that identifies and uses social networks in communications, retrieval, and electronic commerce
US9412282B2 (en) 2011-12-24 2016-08-09 Zonar Systems, Inc. Using social networking to improve driver performance based on industry sharing of driver performance data
US9413615B1 (en) 2012-03-02 2016-08-09 Juniper Networks, Inc. Trap filtering within a device management protocol
DE102015206134A1 (en) * 2015-04-07 2016-10-13 Bayerische Motoren Werke Aktiengesellschaft A method for fault diagnosis for a motor vehicle
US9515928B1 (en) * 2008-07-09 2016-12-06 Google Inc. Network transfer protocol
US9520005B2 (en) 2003-07-24 2016-12-13 Verizon Telematics Inc. Wireless vehicle-monitoring system
US9524156B2 (en) 2014-01-09 2016-12-20 Ford Global Technologies, Llc Flexible feature deployment strategy
US9527515B2 (en) 2011-12-23 2016-12-27 Zonar Systems, Inc. Vehicle performance based on analysis of drive data
US9563869B2 (en) 2010-09-14 2017-02-07 Zonar Systems, Inc. Automatic incorporation of vehicle data into documents captured at a vehicle using a mobile computing device
US9716762B2 (en) 2014-03-31 2017-07-25 Ford Global Technologies Llc Remote vehicle connection status
US9766874B2 (en) 2014-01-09 2017-09-19 Ford Global Technologies, Llc Autonomous global software update
US9858462B2 (en) 2006-06-20 2018-01-02 Zonar Systems, Inc. Method and system for making deliveries of a fluid to a set of tanks

Families Citing this family (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7751429B2 (en) * 2004-02-13 2010-07-06 Broadcom Corporation Signaling format for WLANS
GB0505359D0 (en) * 2005-03-16 2005-04-20 Holset Engineering Co Event logging method and device
KR100700244B1 (en) * 2005-06-13 2007-03-26 엘지전자 주식회사 Method and apparatus for sending/receiving traffic information through file transfer protocol
US20070150138A1 (en) 2005-12-08 2007-06-28 James Plante Memory management in event recording systems
US20070136078A1 (en) 2005-12-08 2007-06-14 Smartdrive Systems Inc. Vehicle event recorder systems
US8756331B2 (en) * 2005-12-20 2014-06-17 Caterpillar Inc. QOS-based communications on a work machine
US8996240B2 (en) 2006-03-16 2015-03-31 Smartdrive Systems, Inc. Vehicle event recorders with integrated web server
US9201842B2 (en) 2006-03-16 2015-12-01 Smartdrive Systems, Inc. Vehicle event recorder systems and networks having integrated cellular wireless communications systems
US8989959B2 (en) 2006-11-07 2015-03-24 Smartdrive Systems, Inc. Vehicle operator performance history recording, scoring and reporting systems
US8649933B2 (en) 2006-11-07 2014-02-11 Smartdrive Systems Inc. Power management systems for automotive video event recorders
US8868288B2 (en) 2006-11-09 2014-10-21 Smartdrive Systems, Inc. Vehicle exception event management systems
US8239092B2 (en) 2007-05-08 2012-08-07 Smartdrive Systems Inc. Distributed vehicle event recorder systems having a portable memory data transfer system
US20090070841A1 (en) 2007-09-12 2009-03-12 Proximetry, Inc. Systems and methods for delivery of wireless data and multimedia content to aircraft
US20090212972A1 (en) * 2008-02-21 2009-08-27 Gm Global Technology Operations, Inc. Method for Protecting Deployed Assets in a Cooperative System
US9198017B2 (en) * 2008-05-19 2015-11-24 Qualcomm Incorporated Infrastructure assisted discovery in a wireless peer-to-peer network
US9848314B2 (en) 2008-05-19 2017-12-19 Qualcomm Incorporated Managing discovery in a wireless peer-to-peer network
WO2009143554A1 (en) * 2008-05-28 2009-12-03 Rmtek Pty Ltd Remote telemetry and video
US20100019932A1 (en) * 2008-07-24 2010-01-28 Tele Atlas North America, Inc. Driver Initiated Vehicle-to-Vehicle Anonymous Warning Device
KR101552932B1 (en) * 2008-10-09 2015-09-14 엘지전자 주식회사 Communication method and a terminal via a network
DE102008061710A1 (en) * 2008-12-12 2010-06-17 Continental Automotive Gmbh Method for operating a sensor device and sensor device
US9305288B2 (en) * 2008-12-30 2016-04-05 Ford Global Technologies, Llc System and method for provisioning electronic mail in a vehicle
US8155044B2 (en) * 2009-01-21 2012-04-10 Mitsubishi Electric Research Laboratories, Inc. Method for broadcasting alert message in mobile multi-hop networks using inferred distance prioritization
US20100190439A1 (en) * 2009-01-29 2010-07-29 Ford Global Technologies, Llc Message transmission protocol for service delivery network
DE102010002093A1 (en) * 2009-06-03 2010-12-09 Continental Teves Ag & Co. Ohg C2X communication with reduced data volume
US8762518B2 (en) * 2009-07-10 2014-06-24 Telcordia Technologies, Inc. Program and method for adaptively maintaining a local peer group in a dynamic environment
JP5273250B2 (en) 2009-07-28 2013-08-28 トヨタ自動車株式会社 Vehicle control device, a vehicle control method and a vehicle control system
CN102473346B (en) * 2009-07-29 2014-01-22 丰田自动车株式会社 Vehicle controller, control method for vehicle and control system for vehicle
US8314718B2 (en) * 2009-10-02 2012-11-20 GM Global Technology Operations LLC Reducing the computational load on processors by selectively discarding data in vehicular networks
US20110105157A1 (en) * 2009-10-29 2011-05-05 Binh Ke Nguyen SMS Communication Platform and Methods for Telematic Devices
KR101325807B1 (en) * 2009-12-17 2013-11-05 한국전자통신연구원 APPARATUS AND METHOD FOR COMMUNICATION OF VEHICLE USING IPv6 NETWORK
US20110225228A1 (en) * 2010-03-11 2011-09-15 Ford Global Technologies, Llc Method and systems for queuing messages for vehicle-related services
US9132715B2 (en) * 2010-03-12 2015-09-15 GM Global Technology Operations LLC Vehicle connectivity systems, methods and applications
CN101848233A (en) * 2010-04-12 2010-09-29 南通大学 Logical link control method based on LLC sub layer of on board unit of Chinese standard ETC system
US9357328B1 (en) 2010-06-15 2016-05-31 Thales Avionics, Inc. Systems and methods for distributing content using attributes
US8560168B2 (en) 2010-08-18 2013-10-15 Snap-On Incorporated System and method for extending communication range and reducing power consumption of vehicle diagnostic equipment
US9633492B2 (en) 2010-08-18 2017-04-25 Snap-On Incorporated System and method for a vehicle scanner to automatically execute a test suite from a storage card
US9330507B2 (en) 2010-08-18 2016-05-03 Snap-On Incorporated System and method for selecting individual parameters to transition from text-to-graph or graph-to-text
US8754779B2 (en) 2010-08-18 2014-06-17 Snap-On Incorporated System and method for displaying input data on a remote display device
US8463953B2 (en) 2010-08-18 2013-06-11 Snap-On Incorporated System and method for integrating devices for servicing a device-under-service
US9117321B2 (en) 2010-08-18 2015-08-25 Snap-On Incorporated Method and apparatus to use remote and local control modes to acquire and visually present data
US8983785B2 (en) 2010-08-18 2015-03-17 Snap-On Incorporated System and method for simultaneous display of waveforms generated from input signals received at a data acquisition device
US8718632B2 (en) 2010-08-26 2014-05-06 Ford Global Technologies, Llc Service delivery network
US8599000B2 (en) 2010-11-24 2013-12-03 Toyota Motor Engineering & Manufacturing North America, Inc. Over-the-air issue reporting from vehicles
CN103366411B (en) 2012-03-30 2016-01-06 国际商业机器公司 For the wireless transmission of vehicle position data network residual method and apparatus
US8676428B2 (en) * 2012-04-17 2014-03-18 Lytx, Inc. Server request for downloaded information from a vehicle-based monitor
US9240079B2 (en) 2012-04-17 2016-01-19 Lytx, Inc. Triggering a specialized data collection mode
US9728228B2 (en) 2012-08-10 2017-08-08 Smartdrive Systems, Inc. Vehicle event playback apparatus and methods
US20140095061A1 (en) * 2012-10-03 2014-04-03 Richard Franklin HYDE Safety distance monitoring of adjacent vehicles
US8933802B2 (en) 2012-11-05 2015-01-13 Spireon, Inc. Switch and actuator coupling in a chassis of a container associated with an intermodal freight transport system
US9779379B2 (en) 2012-11-05 2017-10-03 Spireon, Inc. Container verification through an electrical receptacle and plug associated with a container and a transport vehicle of an intermodal freight transport system
WO2014118647A3 (en) 2013-01-09 2014-11-20 Nathanson Martin D Vehicle communications via wireless access vehicular environment
KR101509893B1 (en) * 2013-06-25 2015-04-07 현대자동차주식회사 Apparatus and Method for Communication of Vehicles
US8819313B1 (en) * 2013-07-19 2014-08-26 Superior Traffic Systems, LLC Traffic management system
US9779449B2 (en) 2013-08-30 2017-10-03 Spireon, Inc. Veracity determination through comparison of a geospatial location of a vehicle with a provided data
US9501878B2 (en) 2013-10-16 2016-11-22 Smartdrive Systems, Inc. Vehicle event playback apparatus and methods
US9610955B2 (en) 2013-11-11 2017-04-04 Smartdrive Systems, Inc. Vehicle fuel consumption monitor and feedback systems
US8892310B1 (en) 2014-02-21 2014-11-18 Smartdrive Systems, Inc. System and method to detect execution of driving maneuvers
WO2015134311A1 (en) * 2014-03-03 2015-09-11 Inrix Inc Traffic obstruction detection
US9663127B2 (en) 2014-10-28 2017-05-30 Smartdrive Systems, Inc. Rail vehicle event detection and recording system
US9551788B2 (en) 2015-03-24 2017-01-24 Jim Epler Fleet pan to provide measurement and location of a stored transport item while maximizing space in an interior cavity of a trailer
US9971348B1 (en) 2015-09-29 2018-05-15 Amazon Technologies, Inc. Passenger profiles for autonomous vehicles
US9958870B1 (en) 2015-09-29 2018-05-01 Amazon Technologies, Inc. Environmental condition identification assistance for autonomous vehicles

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5177464A (en) * 1991-09-04 1993-01-05 Ford Motor Company Catalyst monitoring using a hydrocarbon sensor
US6122664A (en) * 1996-06-27 2000-09-19 Bull S.A. Process for monitoring a plurality of object types of a plurality of nodes from a management node in a data processing system by distributing configured agents
US6253122B1 (en) * 1999-06-14 2001-06-26 Sun Microsystems, Inc. Software upgradable dashboard
US6286040B1 (en) * 1998-05-01 2001-09-04 Cisco Technology, Inc. User-friendly interface for setting expressions on an SNMP agent
US6295492B1 (en) * 1999-01-27 2001-09-25 Infomove.Com, Inc. System for transmitting and displaying multiple, motor vehicle information
US6360257B1 (en) * 1998-01-30 2002-03-19 Telefonaktiebolaget L M Ericsson (Publ) Managing group IP addresses in mobile end stations
US6535493B1 (en) * 1998-01-15 2003-03-18 Symbol Technologies, Inc. Mobile internet communication protocol

Family Cites Families (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US2292387A (en) 1941-06-10 1942-08-11 Markey Hedy Kiesler Secret communication system
US4188618A (en) * 1971-06-29 1980-02-12 Weisbart Emanuel S Digital tachograph system with digital memory system
US4831539A (en) * 1984-04-27 1989-05-16 Hagenbuch Roy George Le Apparatus and method for locating a vehicle in a working area and for the on-board measuring of parameters indicative of vehicle performance
US4999833A (en) 1985-05-06 1991-03-12 Itt Corporation Network connectivity control by artificial intelligence
US4804937A (en) 1987-05-26 1989-02-14 Motorola, Inc. Vehicle monitoring arrangement and system
FR2619232B1 (en) 1987-08-07 1994-04-29 Muller & Cie Ets M data acquisition and processing equipment for the center of ITV
US4967390A (en) 1987-09-16 1990-10-30 Bull Hn Information Systems Italia S.P.A. Bus driving and decoding circuit
US4939652A (en) * 1988-03-14 1990-07-03 Centrodyne Inc. Trip recorder
GB8903123D0 (en) 1989-02-11 1989-03-30 Lewis Roger W D Vehicle monitoring system
US5073900A (en) 1990-03-19 1991-12-17 Mallinckrodt Albert J Integrated cellular communications system
US5668880A (en) 1991-07-08 1997-09-16 Alajajian; Philip Michael Inter-vehicle personal data communications device
US5535274A (en) 1991-10-19 1996-07-09 Cellport Labs, Inc. Universal connection for cellular telephone interface
US5886988A (en) 1996-10-23 1999-03-23 Arraycomm, Inc. Channel assignment and call admission control for spatial division multiple access communication systems
GB9200009D0 (en) 1992-01-02 1992-02-26 Davies Leslie K Vehicle monitoring equipment
US5223844B1 (en) 1992-04-17 2000-01-25 Auto Trac Inc Vehicle tracking and security system
DE4229931C2 (en) 1992-09-08 1997-01-23 Daimler Benz Ag A method for programming a bus-compatible electronic motor control unit
CA2110025A1 (en) * 1992-12-16 1994-06-17 Gerard Joseph Hughes Automatic vehicle recognition and customer automobile diagnostic system
US5400018A (en) * 1992-12-22 1995-03-21 Caterpillar Inc. Method of relaying information relating to the status of a vehicle
EP0615391A1 (en) 1993-03-09 1994-09-14 ALCATEL BELL Naamloze Vennootschap Mobile communication network
US5802502A (en) 1993-05-24 1998-09-01 British Telecommunications Public Limited Company System for selective communication connection based on transaction pricing signals
US5854985A (en) 1993-12-15 1998-12-29 Spectrum Information Technologies, Inc. Adaptive omni-modal radio apparatus and methods
US5546444A (en) 1994-03-11 1996-08-13 Bellsouth Corporation Methods and apparatus for communicating data via a cellular network control channel
WO1995025407A1 (en) 1994-03-17 1995-09-21 Sierra Wireless, Inc. Modem for packet and circuit switched communication
JP3215018B2 (en) 1994-09-09 2001-10-02 三菱電機株式会社 Mobile communication system
US5619412A (en) 1994-10-19 1997-04-08 Cummins Engine Company, Inc. Remote control of engine idling time
US5594425A (en) 1994-10-31 1997-01-14 Peoplenet, Inc. Locator device
WO1996027513A1 (en) * 1995-03-03 1996-09-12 Qualcomm Incorporated Method and apparatus for monitoring parameters of vehicle electronic control units
FI106671B (en) 1995-03-13 2001-03-15 Nokia Mobile Phones Ltd The mobile entity, the mobile terminal and a method for establishing a connection from the mobile terminal
US5768531A (en) 1995-03-27 1998-06-16 Toshiba America Information Systems Apparatus and method for using multiple communication paths in a wireless LAN
US5844473A (en) * 1995-04-12 1998-12-01 Products Research, Inc. Method and apparatus for remotely collecting operational information of a mobile vehicle
US5717737A (en) 1995-06-01 1998-02-10 Padcom, Inc. Apparatus and method for transparent wireless communication between a remote device and a host system
US5926745A (en) * 1995-11-30 1999-07-20 Amsc Subsidiary Corporation Network operations center for mobile earth terminal satellite communications system
US5732074A (en) 1996-01-16 1998-03-24 Cellport Labs, Inc. Mobile portable wireless communication system
US5897605A (en) 1996-03-15 1999-04-27 Sirf Technology, Inc. Spread spectrum receiver with fast signal reacquisition
US6477581B1 (en) 1996-04-09 2002-11-05 International Business Machines Corporation Location/motion sensitive computer connection
US6028537A (en) 1996-06-14 2000-02-22 Prince Corporation Vehicle communication and remote control system
EP0934858B1 (en) * 1996-11-13 2009-07-08 Toyota Jidosha Kabushiki Kaisha Vehicle information communication device and vehicle information communication system
US6122514A (en) 1997-01-03 2000-09-19 Cellport Systems, Inc. Communications channel selection
US5905859A (en) * 1997-01-09 1999-05-18 International Business Machines Corporation Managed network device security method and apparatus
DE19720285A1 (en) 1997-05-15 1998-11-19 Bosch Gmbh Robert A method for tamper-proof configuration of a vehicle control unit and the control unit
US6405111B2 (en) * 1997-05-16 2002-06-11 Snap-On Technologies, Inc. System and method for distributed computer automotive service equipment
US6185413B1 (en) 1997-06-17 2001-02-06 Siemens Aktiengesellschaft Mobile station having a cost-efficient call management method and system
DE19725916A1 (en) * 1997-06-19 1999-01-28 Daimler Benz Ag Computer=aided diagnosis device for electronically-controlled systems in motor vehicle
US5961561A (en) 1997-08-14 1999-10-05 Invacare Corporation Method and apparatus for remote maintenance, troubleshooting, and repair of a motorized wheelchair
US6590928B1 (en) 1997-09-17 2003-07-08 Telefonaktiebolaget Lm Ericsson (Publ) Frequency hopping piconets in an uncoordinated wireless multi-user system
US6073089A (en) * 1997-10-22 2000-06-06 Baker; Michelle Systems and methods for adaptive profiling, fault detection, and alert generation in a changing environment which is measurable by at least two different measures of state
JP2001522169A (en) 1997-10-23 2001-11-13 ダニエル ナサンソン,マーチン Telecommunications system
US5999978A (en) * 1997-10-31 1999-12-07 Sun Microsystems, Inc. Distributed system and method for controlling access to network resources and event notifications
US5999179A (en) * 1997-11-17 1999-12-07 Fujitsu Limited Platform independent computer network management client
US6487717B1 (en) * 1999-01-15 2002-11-26 Cummins, Inc. System and method for transmission of application software to an embedded vehicle computer
US6181994B1 (en) * 1999-04-07 2001-01-30 International Business Machines Corporation Method and system for vehicle initiated delivery of advanced diagnostics based on the determined need by vehicle
US6362730B2 (en) * 1999-06-14 2002-03-26 Sun Microsystems, Inc. System and method for collecting vehicle information
US6975612B1 (en) * 1999-06-14 2005-12-13 Sun Microsystems, Inc. System and method for providing software upgrades to a vehicle
US6330499B1 (en) * 1999-07-21 2001-12-11 International Business Machines Corporation System and method for vehicle diagnostics and health monitoring
JP2001154725A (en) * 1999-11-30 2001-06-08 Mitsubishi Motors Corp Method and device for diagnosing fault of vehicle, and computer readable recording medium recorded with fault diagnostic program

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5177464A (en) * 1991-09-04 1993-01-05 Ford Motor Company Catalyst monitoring using a hydrocarbon sensor
US6122664A (en) * 1996-06-27 2000-09-19 Bull S.A. Process for monitoring a plurality of object types of a plurality of nodes from a management node in a data processing system by distributing configured agents
US6535493B1 (en) * 1998-01-15 2003-03-18 Symbol Technologies, Inc. Mobile internet communication protocol
US6360257B1 (en) * 1998-01-30 2002-03-19 Telefonaktiebolaget L M Ericsson (Publ) Managing group IP addresses in mobile end stations
US6286040B1 (en) * 1998-05-01 2001-09-04 Cisco Technology, Inc. User-friendly interface for setting expressions on an SNMP agent
US6295492B1 (en) * 1999-01-27 2001-09-25 Infomove.Com, Inc. System for transmitting and displaying multiple, motor vehicle information
US6253122B1 (en) * 1999-06-14 2001-06-26 Sun Microsystems, Inc. Software upgradable dashboard

Cited By (179)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8090598B2 (en) 1996-01-29 2012-01-03 Progressive Casualty Insurance Company Monitoring system for determining and communicating a cost of insurance
US9754424B2 (en) 1996-01-29 2017-09-05 Progressive Casualty Insurance Company Vehicle monitoring system
US8892451B2 (en) 1996-01-29 2014-11-18 Progressive Casualty Insurance Company Vehicle monitoring system
US8140358B1 (en) 1996-01-29 2012-03-20 Progressive Casualty Insurance Company Vehicle monitoring system
US8595034B2 (en) 1996-01-29 2013-11-26 Progressive Casualty Insurance Company Monitoring system for determining and communicating a cost of insurance
US8311858B2 (en) 1996-01-29 2012-11-13 Progressive Casualty Insurance Company Vehicle monitoring system
US20050102074A1 (en) * 2000-04-24 2005-05-12 Kolls H. B. System for interfacing with an on-board engine control system in a vehicle
US7502672B1 (en) 2000-04-24 2009-03-10 Usa Technologies, Inc. Wireless vehicle diagnostics with service and part determination capabilities
US20040217852A1 (en) * 2000-04-24 2004-11-04 Kolls H. Brock Method for characterizing a vehicle's fuel efficiency
US6856820B1 (en) * 2000-04-24 2005-02-15 Usa Technologies, Inc. In-vehicle device for wirelessly connecting a vehicle to the internet and for transacting e-commerce and e-business
US20150032291A1 (en) * 2000-07-25 2015-01-29 Larkin H. Lowrey Peripheral access devices and sensors for use with vehicle telematics devices and systems
US7904219B1 (en) 2000-07-25 2011-03-08 Htiip, Llc Peripheral access devices and sensors for use with vehicle telematics devices and systems
US9224249B2 (en) * 2000-07-25 2015-12-29 Hti Ip, L.L.C. Peripheral access devices and sensors for use with vehicle telematics devices and systems
US8074269B2 (en) 2000-12-29 2011-12-06 At&T Intellectual Property I, L.P. System and method for controlling devices at a location
US20080279345A1 (en) * 2000-12-29 2008-11-13 Bellsouth Intellectual Property Corporation System And Method For Controlling Devices At A Location
US7406710B1 (en) * 2000-12-29 2008-07-29 At&T Delaware Intellectual Property, Inc. System and method for controlling devices at a location
US8904515B2 (en) 2000-12-29 2014-12-02 At&T Intellectual Property I, L.P. System and method for controlling devices at a location
US7747365B1 (en) 2001-03-13 2010-06-29 Htiip, Llc Internet-based system for monitoring vehicles
US6928348B1 (en) 2001-04-30 2005-08-09 Reynolds & Reynolds Holdings, Inc. Internet-based emissions test for vehicles
US7061924B1 (en) * 2001-05-24 2006-06-13 Intel Corporation Methods and apparatus for remote metering
US20060052142A1 (en) * 2001-07-24 2006-03-09 Herz Frederick S M Mobile link selection method for establishing highly efficient communications between mobile devices
US7254604B2 (en) * 2001-08-03 2007-08-07 Nissan Motor Co., Ltd. Distributed information collecting system
US20030028292A1 (en) * 2001-08-03 2003-02-06 Nissan Motor Co., Ltd. Distributed information collecting system
US7415508B2 (en) * 2001-08-31 2008-08-19 Temic Automotive Of North America, Inc. Linked vehicle active networks
US20030046327A1 (en) * 2001-08-31 2003-03-06 Juergen Reinold Linked vehicle active networks
US8106757B2 (en) 2001-09-11 2012-01-31 Zonar Systems, Inc. System and process to validate inspection data
US7808369B2 (en) 2001-09-11 2010-10-05 Zonar Systems, Inc. System and process to ensure performance of mandated inspections
US8810385B2 (en) 2001-09-11 2014-08-19 Zonar Systems, Inc. System and method to improve the efficiency of vehicle inspections by enabling remote actuation of vehicle components
US20080316007A1 (en) * 2001-09-11 2008-12-25 Zonar Systems, Inc. System and process to ensure performance of mandated inspections
US8400296B2 (en) 2001-09-11 2013-03-19 Zonar Systems, Inc. Method and apparatus to automate data collection during a mandatory inspection
US7944345B2 (en) 2001-09-11 2011-05-17 Zonar Systems, Inc. System and process to ensure performance of mandated safety and maintenance inspections
US8989170B2 (en) * 2002-02-05 2015-03-24 Sony Corporation Wireless communication system and wireless communication control method, wireless communication device and wireless communication method, and computer program
US9907052B2 (en) 2002-02-05 2018-02-27 Sony Corporation Wireless communication system and wireless communication control method, wireless communication device and wireless communication method, and computer program
US20140029588A1 (en) * 2002-02-05 2014-01-30 Sony Corporation Wireless communication system and wireless communication control method, wireless communication device and wireless communication method, and computer program
US7589726B2 (en) * 2002-03-21 2009-09-15 Nokia Corporation Service/device indication with graphical interface
US20040021579A1 (en) * 2002-05-07 2004-02-05 Oursler Mark A. Commercial vehicle electronic screening hardware/software system with primary and secondary sensor sets
US6980093B2 (en) 2002-05-07 2005-12-27 The Johns Hopkins University Commercial vehicle electronic screening hardware/software system with primary and secondary sensor sets
US8315211B2 (en) * 2002-09-17 2012-11-20 Broadcom Corporation Method and system for location based configuration of a wireless access point (WAP) and an access device in a hybrid wired/wireless network
US20040051664A1 (en) * 2002-09-17 2004-03-18 Frank Ed H. Method and system for location based configuration of a wireless access point (WAP) and an access device in a hybrid wired/wireless network
US8908516B2 (en) 2002-10-15 2014-12-09 Blackberry Corporation Maintaining stability of a wireless network by adjusting transmitting period
US20040073361A1 (en) * 2002-10-15 2004-04-15 Assimakis Tzamaloukas Enhanced mobile communication device, and transportation application thereof
WO2004047045A1 (en) * 2002-11-19 2004-06-03 Thierry Racine Accident prevention system
US20040215373A1 (en) * 2003-04-22 2004-10-28 Samsung Electronics Co., Ltd. System and method for communicating vehicle management information between vehicles using an ad-hoc network
US20040230370A1 (en) * 2003-05-12 2004-11-18 Assimakis Tzamaloukas Enhanced mobile communication device with extended radio, and applications
EP1631790A4 (en) * 2003-05-12 2009-05-06 Circumnav Networks Inc Enhanced mobile communication device with extended radio, and applications
WO2004102986A2 (en) 2003-05-12 2004-11-25 Circumnav Networks, Inc. Enhanced mobile communication device with extended radio, and applications
US8965695B2 (en) 2003-05-12 2015-02-24 Google Technology Holdings LLC Hierarchical floating car data network
US6925378B2 (en) 2003-05-12 2005-08-02 Circumnav Networks, Inc. Enhanced mobile communication device with extended radio, and applications
US20070271029A1 (en) * 2003-05-12 2007-11-22 Assimakis Tzamaloukas Hierarchical floating car data network
EP1631790A2 (en) * 2003-05-12 2006-03-08 Circumnav Networks, Inc. Enhanced mobile communication device with extended radio, and applications
US7188026B2 (en) 2003-05-12 2007-03-06 Dash Navigation, Inc. Hierarchical floating car data network
US7272496B2 (en) * 2003-06-12 2007-09-18 Temic Automotive Of North America, Inc. Vehicle network and method of communicating data packets in a vehicle network
US20050038583A1 (en) * 2003-06-12 2005-02-17 Fehr Walton L. Automotive switch fabric with improved resource reservation
US20050004756A1 (en) * 2003-06-12 2005-01-06 Donald Remboski Vehicle network and method of communicating data packets in a vehicle network
US7599772B2 (en) 2003-06-12 2009-10-06 Temic Automotive Of North America, Inc. Automotive switch fabric with improved resource reservation
US7570597B2 (en) 2003-06-12 2009-08-04 Temic Automotive Of North America, Inc. Discovery process in a vehicle network
US20040254700A1 (en) * 2003-06-12 2004-12-16 Fehr Walton L. Automotive switch fabric with improved QoS and method
US20040252637A1 (en) * 2003-06-12 2004-12-16 Laberteaux Kenneth P. Robust, low-delay, fast reconfiguring wireless system
US20040258001A1 (en) * 2003-06-12 2004-12-23 Donald Remboski Discovery process in a vehicle network
WO2005004079A1 (en) * 2003-06-25 2005-01-13 Julian Weis A device for exchaging data between moving vehicles
US20070093959A1 (en) * 2003-06-25 2007-04-26 Julian Weis Device for exchanging data between moving vehicles
US7447569B2 (en) 2003-06-25 2008-11-04 Julian Weis Device for exchanging data between moving vehicles
US7983820B2 (en) 2003-07-02 2011-07-19 Caterpillar Inc. Systems and methods for providing proxy control functions in a work machine
US8452486B2 (en) * 2003-07-24 2013-05-28 Hti Ip, L.L.C. Wireless vehicle-monitoring system operating on both terrestrial and satellite networks
US7113127B1 (en) * 2003-07-24 2006-09-26 Reynolds And Reynolds Holdings, Inc. Wireless vehicle-monitoring system operating on both terrestrial and satellite networks
US9520005B2 (en) 2003-07-24 2016-12-13 Verizon Telematics Inc. Wireless vehicle-monitoring system
US20050165514A1 (en) * 2004-01-28 2005-07-28 General Motors Corporation Method and system for managing registration requests of telematics units
US7020545B2 (en) * 2004-01-28 2006-03-28 General Motors Corporation Method and system for managing registration requests of telematics units
US20050191988A1 (en) * 2004-02-26 2005-09-01 Research In Motion Limited Mobile communications device with security features
US7689230B2 (en) 2004-04-01 2010-03-30 Bosch Rexroth Corporation Intelligent transportation system
WO2005098781A1 (en) * 2004-04-01 2005-10-20 Dana Corporation Intelligent transportation system
US20050221759A1 (en) * 2004-04-01 2005-10-06 Spadafora William G Intelligent transportation system
US7965678B2 (en) * 2004-04-02 2011-06-21 Fondazione Silvio Tronchetti Provera Controlling access to a shared communication medium of a mobile ad-hoc network
US20090010268A1 (en) * 2004-04-02 2009-01-08 Fondazione Silvio Tronchetti Provera Controlling Access to a Shared Communication Medium of a Mobile Adhoc Network
US9197857B2 (en) 2004-09-24 2015-11-24 Cisco Technology, Inc. IP-based stream splicing with content-specific splice points
US8116959B2 (en) 2004-11-08 2012-02-14 Toyota Motor Engineering & Manufacturing North America, Inc. System and method of vehicular wireless communication
WO2006052943A3 (en) * 2004-11-08 2007-02-22 Toyota Technical Ct Usa Inc System and method of vehicular wireless communication
US20070299571A1 (en) * 2004-11-08 2007-12-27 Laberteaux Kenneth P System and Method of Vehicular Wireless Communication
US20090138196A1 (en) * 2004-11-08 2009-05-28 Toyota Engineering & Manufacturing North America, System and method of vehicular wireless communication using an integrated coordinating access point
US7970540B2 (en) 2004-11-08 2011-06-28 Toyota Motor Engineering & Manufacturing North America, Inc. System and method of vehicular wireless communication using an integrated coordinating access point
US7983841B2 (en) 2004-11-08 2011-07-19 Toyota Motor Engineering & Manufacturing North America, Inc. System and method of vehicular wireless communication using a group manager
US7512156B2 (en) * 2004-12-14 2009-03-31 Snap-On Incorporated Data alignment method and system
US20060126669A1 (en) * 2004-12-14 2006-06-15 Snap-On Incorporated Data alignment method and system
US20090129280A1 (en) * 2005-01-28 2009-05-21 Research In Motion Limited Socket management for always-on data connections
US20060171306A1 (en) * 2005-01-28 2006-08-03 Craig Stout Socket management for always-on data connections
US7508812B2 (en) * 2005-01-28 2009-03-24 Research In Motion Limited Socket management for always-on data connections
US7733841B2 (en) 2005-05-10 2010-06-08 Continental Automotive Systems, Inc. Vehicle network with time slotted access and method
EP1883905A4 (en) * 2005-05-10 2010-05-05 Scania Cv Abp Transmission of vehicle related data between a vehicle and a vehicle support centre
US20060259204A1 (en) * 2005-05-10 2006-11-16 Jordan Patrick D Vehicle network with time slotted access and method
EP1883905A1 (en) * 2005-05-10 2008-02-06 Scania CV AB (PUBL) Transmission of vehicle related data between a vehicle and a vehicle support centre
US8149737B2 (en) * 2005-08-09 2012-04-03 Motorola Solutions, Inc. Method and system for data transmission in a wireless network
US20070036089A1 (en) * 2005-08-09 2007-02-15 Metke Anthony R Method and system for data transmission in a wireless network
US7945358B2 (en) 2005-08-18 2011-05-17 Environmental Systems Products Holdings Inc. System and method for testing the integrity of a vehicle testing/diagnostic system
US8355837B2 (en) 2005-08-18 2013-01-15 Envirotest Systems Holdings Corp. System and method for testing the integrity of a vehicle testing/diagnostic system
WO2007034428A3 (en) * 2005-09-20 2010-09-10 Maxtech Networks Ltd Real time peer to peer network
US7912597B2 (en) * 2005-10-06 2011-03-22 Denso Corporation On-vehicle network diagnosis system and on-vehicle control apparatus thereof
US20070083304A1 (en) * 2005-10-06 2007-04-12 Denso Corporation On-vehicle network diagnosis system and on-vehicle control apparatus thereof
US8232889B2 (en) 2005-12-13 2012-07-31 Continental Automotive Gmbh Communication system in a motor vehicle, and method for setting up a wireless ad-hoc radio network
US20100255866A1 (en) * 2005-12-13 2010-10-07 Continental Automotive Gmbh Communication System in a Motor Vehicle, and Method for Setting Up a Wireless Ad-Hoc Radio Network
DE102005059522A1 (en) * 2005-12-13 2007-06-14 Siemens Ag Communication system of a motor vehicle and method for establishing a wireless ad-hoc wireless network
US20070239322A1 (en) * 2006-04-05 2007-10-11 Zonar Comliance Systems, Llc Generating a numerical ranking of driver performance based on a plurality of metrics
US7769499B2 (en) 2006-04-05 2010-08-03 Zonar Systems Inc. Generating a numerical ranking of driver performance based on a plurality of metrics
US9230437B2 (en) 2006-06-20 2016-01-05 Zonar Systems, Inc. Method and apparatus to encode fuel use data with GPS data and to analyze such data
US8972179B2 (en) 2006-06-20 2015-03-03 Brett Brinton Method and apparatus to analyze GPS data to determine if a vehicle has adhered to a predetermined route
US20070294031A1 (en) * 2006-06-20 2007-12-20 Zonar Compliance Systems, Llc Method and apparatus to utilize gps data to replace route planning software
US9858462B2 (en) 2006-06-20 2018-01-02 Zonar Systems, Inc. Method and system for making deliveries of a fluid to a set of tanks
US7680595B2 (en) 2006-06-20 2010-03-16 Zonar Systems, Inc. Method and apparatus to utilize GPS data to replace route planning software
US20080005071A1 (en) * 2006-06-28 2008-01-03 Microsoft Corporation Search guided by location and context
US9536004B2 (en) 2006-06-28 2017-01-03 Microsoft Technology Licensing, Llc Search guided by location and context
US20080005073A1 (en) * 2006-06-28 2008-01-03 Microsoft Corporation Data management in social networks
US9396269B2 (en) 2006-06-28 2016-07-19 Microsoft Technology Licensing, Llc Search engine that identifies and uses social networks in communications, retrieval, and electronic commerce
US9141704B2 (en) 2006-06-28 2015-09-22 Microsoft Technology Licensing, Llc Data management in social networks
US8874592B2 (en) * 2006-06-28 2014-10-28 Microsoft Corporation Search guided by location and context
US20080016504A1 (en) * 2006-07-14 2008-01-17 Wesley Homer Cheng Dynamically programmable electronic data collection system combining declarative programming and native coding
US20080016207A1 (en) * 2006-07-14 2008-01-17 Wesley Homer Cheng Electronic driver log application with bi-directional messaging to multiple backend systems
US20080015748A1 (en) * 2006-07-14 2008-01-17 David Nagy System for monitoring, controlling, and reporting vehicle operation through onboard diagnostic port
US20080082221A1 (en) * 2006-07-14 2008-04-03 David Nagy System for monitoring, controlling, and reporting vehicle operation through onboard diagnostic port
US8059544B2 (en) 2006-12-20 2011-11-15 Honeywell International Inc. Distance adaptive routing protocol
US8451807B2 (en) 2006-12-20 2013-05-28 Honeywell International Inc. Configuration aware packet routing in an ad-hoc network
EP1956799A1 (en) * 2006-12-20 2008-08-13 Honeywell International Inc. Voice-over-internet protocol inter-vehicle communications
US20080151841A1 (en) * 2006-12-20 2008-06-26 Honeywell International Inc. Configuration aware packet routing in an ad-hoc network
US20080151793A1 (en) * 2006-12-20 2008-06-26 Honeywell International Inc. Voice-over-internet protocol intra-vehicle communications
US20080151889A1 (en) * 2006-12-20 2008-06-26 Honeywell International Inc. Distance adaptive routing protocol
US8254348B2 (en) 2006-12-20 2012-08-28 Honeywell International Inc. Voice-over-internet protocol intra-vehicle communications
US20080285452A1 (en) * 2007-05-14 2008-11-20 Cisco Technology, Inc. Remote monitoring of real-time internet protocol media streams
US20080285463A1 (en) * 2007-05-14 2008-11-20 Cisco Technology, Inc. Tunneling reports for real-time internet protocol media streams
US7936695B2 (en) 2007-05-14 2011-05-03 Cisco Technology, Inc. Tunneling reports for real-time internet protocol media streams
US8023419B2 (en) * 2007-05-14 2011-09-20 Cisco Technology, Inc. Remote monitoring of real-time internet protocol media streams
US8867385B2 (en) 2007-05-14 2014-10-21 Cisco Technology, Inc. Tunneling reports for real-time Internet Protocol media streams
US20080310316A1 (en) * 2007-06-18 2008-12-18 Cisco Technology, Inc. Surrogate Stream for Monitoring Realtime Media
US7835406B2 (en) 2007-06-18 2010-11-16 Cisco Technology, Inc. Surrogate stream for monitoring realtime media
US7817546B2 (en) 2007-07-06 2010-10-19 Cisco Technology, Inc. Quasi RTP metrics for non-RTP media flows
US20090010158A1 (en) * 2007-07-06 2009-01-08 Cisco Technology, Inc. Quasi rtp metrics for non-rtp media flows
US8966551B2 (en) 2007-11-01 2015-02-24 Cisco Technology, Inc. Locating points of interest using references to media frames within a packet flow
US9762640B2 (en) 2007-11-01 2017-09-12 Cisco Technology, Inc. Locating points of interest using references to media frames within a packet flow
US8081573B2 (en) 2007-12-20 2011-12-20 Honeywell International Inc. Automatic sequencing based on wireless connectivity
US20110060828A1 (en) * 2007-12-20 2011-03-10 Honeywell International Inc. Automatic sequencing based on wireless connectivity
US8064377B2 (en) 2008-01-24 2011-11-22 Honeywell International Inc. Method for enhancement of multicasting forwarding protocol in a wireless network
US20090190514A1 (en) * 2008-01-24 2009-07-30 Honeywell International Inc. Method for enhancement of multicasting forwarding protocol in a wireless network
US20090222280A1 (en) * 2008-02-29 2009-09-03 Shiva Mittal System and method for certification data management
US9515928B1 (en) * 2008-07-09 2016-12-06 Google Inc. Network transfer protocol
US8311732B2 (en) * 2008-09-05 2012-11-13 Microsoft Corporation Navigation communication with self-identifying elements
US8335127B2 (en) * 2009-08-12 2012-12-18 Pgs Geophysical As Method for generating spread spectrum driver signals for a seismic vibrator array using multiple biphase modulation operations in each driver signal chip
US20110038225A1 (en) * 2009-08-12 2011-02-17 Stig Rune Lennart Tenghamn Method for generating spread spectrum driver signals for a seismic vibrator array using multiple biphase modulation operations in each driver signal chip
US20110044172A1 (en) * 2009-08-19 2011-02-24 Raymond Yim Method and Protocol for Congestion Control in a Vehicular Network
US8233389B2 (en) * 2009-08-19 2012-07-31 Mitsubishi Electric Research Laboratories, Inc. Method and protocol for congestion control in a vehicular network
US20110131269A1 (en) * 2009-09-24 2011-06-02 Gilleland David S Monitoring assets
US20110131074A1 (en) * 2009-09-24 2011-06-02 David S Gilleland Maintenance control system
US20110128163A1 (en) * 2009-09-24 2011-06-02 Gilleland David S Positioning system
US20110137489A1 (en) * 2009-09-24 2011-06-09 Gilleland David S Asset monitoring system
US20110130893A1 (en) * 2009-09-24 2011-06-02 Gilleland David S Energy management system
US20110128118A1 (en) * 2009-09-24 2011-06-02 Gilleland David S Authorization system
EP2494743A2 (en) * 2009-10-27 2012-09-05 Microsoft Corporation Quality of service (qos) based systems, networks, and advisors
EP2494743A4 (en) * 2009-10-27 2013-07-31 Microsoft Corp Quality of service (qos) based systems, networks, and advisors
US20110119546A1 (en) * 2009-11-18 2011-05-19 Cisco Technology, Inc. Rtp-based loss recovery and quality monitoring for non-ip and raw-ip mpeg transport flows
US8301982B2 (en) 2009-11-18 2012-10-30 Cisco Technology, Inc. RTP-based loss recovery and quality monitoring for non-IP and raw-IP MPEG transport flows
US8819714B2 (en) 2010-05-19 2014-08-26 Cisco Technology, Inc. Ratings and quality measurements for digital broadcast viewers
US20110307540A1 (en) * 2010-06-10 2011-12-15 Research In Motion Limited Method and system for reducing transmission of redundant data
US8566010B2 (en) * 2010-06-23 2013-10-22 Massachusetts Institute Of Technology System and method for providing road condition and congestion monitoring using smart messages
US20110320111A1 (en) * 2010-06-23 2011-12-29 Massachusetts Institute Of Technolgoy System and method for providing road condition and congestion monitoring using smart messages
US9563869B2 (en) 2010-09-14 2017-02-07 Zonar Systems, Inc. Automatic incorporation of vehicle data into documents captured at a vehicle using a mobile computing device
US8736419B2 (en) 2010-12-02 2014-05-27 Zonar Systems Method and apparatus for implementing a vehicle inspection waiver program
US8706397B2 (en) * 2011-07-11 2014-04-22 Harman International Industries, Incorporated System and method for determining an optimal route using aggregated route information
US20130018574A1 (en) * 2011-07-11 2013-01-17 Harman International Industries, Incorporated System and method for determining an optimal route using aggregated route information
WO2013053579A1 (en) * 2011-10-10 2013-04-18 Alcatel Lucent Emission reporting and monitoring
JP2015504191A (en) * 2011-10-10 2015-02-05 アルカテル−ルーセント Reporting and monitoring of emissions
US9527515B2 (en) 2011-12-23 2016-12-27 Zonar Systems, Inc. Vehicle performance based on analysis of drive data
US9489280B2 (en) 2011-12-23 2016-11-08 Zonar Systems, Inc. Method and apparatus for 3-D accelerometer based slope determination, real-time vehicle mass determination, and vehicle efficiency analysis
US9384111B2 (en) 2011-12-23 2016-07-05 Zonar Systems, Inc. Method and apparatus for GPS based slope determination, real-time vehicle mass determination, and vehicle efficiency analysis
US9412282B2 (en) 2011-12-24 2016-08-09 Zonar Systems, Inc. Using social networking to improve driver performance based on industry sharing of driver performance data
US9413615B1 (en) 2012-03-02 2016-08-09 Juniper Networks, Inc. Trap filtering within a device management protocol
US20130346574A1 (en) * 2012-06-26 2013-12-26 Juniper Networks, Inc. Filtering within device management protocol queries
US9524156B2 (en) 2014-01-09 2016-12-20 Ford Global Technologies, Llc Flexible feature deployment strategy
US9766874B2 (en) 2014-01-09 2017-09-19 Ford Global Technologies, Llc Autonomous global software update
US9716762B2 (en) 2014-03-31 2017-07-25 Ford Global Technologies Llc Remote vehicle connection status
US9323546B2 (en) 2014-03-31 2016-04-26 Ford Global Technologies, Llc Targeted vehicle remote feature updates
US9325650B2 (en) 2014-04-02 2016-04-26 Ford Global Technologies, Llc Vehicle telematics data exchange
CN104410706A (en) * 2014-12-10 2015-03-11 林斌 Urban smog treatment coordinating system
DE102015206134A1 (en) * 2015-04-07 2016-10-13 Bayerische Motoren Werke Aktiengesellschaft A method for fault diagnosis for a motor vehicle

Also Published As

Publication number Publication date Type
US20070244614A1 (en) 2007-10-18 application
US7593999B2 (en) 2009-09-22 grant

Similar Documents

Publication Publication Date Title
Qian et al. Design of secure and application-oriented VANETs
Wang et al. DMND: Collecting data from mobiles using named data
Zhao et al. VADD: Vehicle-assisted data delivery in vehicular ad hoc networks
Singh et al. Wireless LAN performance under varied stress conditions in vehicular traffic scenarios
Toor et al. Vehicle ad hoc networks: Applications and related technical issues
Whitbeck et al. Relieving the wireless infrastructure: When opportunistic networks meet guaranteed delays
US8060017B2 (en) Methods and systems for a mobile, broadband, routable internet
US7382756B2 (en) Integrated user and radio management in a wireless network environment
Eriksson et al. Cabernet: vehicular content delivery using WiFi
US7149197B2 (en) Movable access points and repeaters for minimizing coverage and capacity constraints in a wireless communications network and a method for using the same
Hartenstein et al. A tutorial survey on vehicular ad hoc networks
US7106219B2 (en) Decentralized vehicular traffic status system
US20070115897A1 (en) Linked equivalent cell header-based approach and protocol for organizing an ad-hoc network
Hartenstein et al. Position-aware ad hoc wireless networks for inter-vehicle communications: the Fleetnet project
Tokuda et al. DOLPHIN for inter-vehicle communications system
US7295524B1 (en) Methods, apparatuses and systems facilitating management of airspace in wireless computer network environments
Ott et al. Drive-thru Internet: IEEE 802.11 b for" automobile" users
US20090124208A1 (en) Protocol reference model, security and inter-operability in a cognitive communications system
US20070115868A1 (en) Group-header based method to organize local peer group of vehicles for inter-vehicle communication
US20100142447A1 (en) Web applications for a mobile, broadband, routable internet
Bychkovsky et al. A measurement study of vehicular internet access using in situ Wi-Fi networks
Jetcheva et al. Design and evaluation of a metropolitan area multitier wireless ad hoc network architecture
US20060022842A1 (en) Vehicle telemetric system
US8233389B2 (en) Method and protocol for congestion control in a vehicular network
Uzcátegui et al. Wave: A tutorial

Legal Events

Date Code Title Description
AS Assignment

Owner name: PAXGRID TELEMETRIC SYSTEMS, INC., MICHIGAN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NATHANSON, MARTIN D.;REEL/FRAME:012823/0809

Effective date: 20020417