CN1481631A

CN1481631A - 机动车的遥测协议

Info

Publication number: CN1481631A
Application number: CNA018206166A
Authority: CN
Inventors: M��D��̹ɭ; M·D·纳坦森
Original assignee: PAXGRID TELEMETRIC SYSTEM Inc
Current assignee: PAXGRID TELEMETRIC SYSTEM Inc
Priority date: 2000-10-13
Filing date: 2001-10-15
Publication date: 2004-03-10
Anticipated expiration: 2021-10-15
Also published as: CN1218537C; AU2001295325A1; CA2425985C; WO2002031793A2; WO2002031793A3; US20170221357A1; US20130342368A1; EP1327233A2; KR20030070010A; CA2425985A1; US9922557B2; US9633562B2; JP2004511188A

Abstract

公开的是一种将来自车辆的车辆运行数据传递到远程监视接收者的方法，包括以下步骤：建立车辆和远程监视接收者之间的数据链路；从车辆里的数据源采集车辆运行数据；利用源自SNMP的协议将车辆运行数据封装在数据分组中；以及在数据链路上传递数据分组。

Description

机动车的遥测协议

共同未决申请的参考

1997年8月26日提出的临时申请序号60/056,388和1998年8月26日提出的发明专利申请序号09/140,759(标题都是SYSTEM ANDMETHOD FOR PROVIDING MOBILE AUTOMOTIVE TELEMETRY(用于提供移动机动车的遥测的系统和方法))的主题都是被合并在这里供参考。1998年10月23日提出的名为TELECOMMUNICATIONS SYSTEM(电信系统)并且指定美国的PCT申请序号PCT/CA98/00986的主题也被合并在这里供参考。1999年6月17日提出的名为VEHICULAR TELEMETRY(车辆遥测)的临时申请序号60/139,573的主题也被合并在这里供参考。1999年8月11日提出的名为VEHICULAR COMPUTING DEVICE(车辆计算设备)的美国临时申请序号60/148,270的主题也被合并在这里供参考。2000年3月6日提出的名为VEHICULAR TELEMETRY(车辆遥测)的美国临时申请序号60/187,022的主题也被合并在这里供参考。2000年4月24日提出的名为VEHICULAR TELEMETRY(车辆遥测)的美国申请序号09/556,289的主题也被合并在这里供参考。2000年6月19日提出的名为VEHICULAR TELEMETRY(车辆遥测)并且指定美国的PCT申请序号PCT/CA00/00712的主题也被合并在这里供参考。

2000年10月13日提出的名为INTELLIGENT TRANSPORTATIONSYSTEMS WITH AD HOC NETWORKING(具有特设连网的智能传输系统)的美国临时申请序号60/239,920的主题也被合并在这里供参考。2000年11月27日提出的名为INTELLIGENT TRANSPORTATION SYSTEMS WITHAD HOC NETWORKING(具有特设连网的智能传输系统)的美国临时申请序号60/252,885的主题也被合并在这里供参考。2000年12月18日提出的名为INTELLIGENT TRANSPORTATION SYSTEMS WITH AD HOCNETWORKING(具有特设连网的智能传输系统)的美国临时申请序号60/255,896的主题也被合并在这里供参考。

发明背景

1.发明领域

本发明涉及车辆的遥测协议及其在智能传输系统中的使用。

2.相关技术描述

传统的，车辆被已知在硬连线或红外的数据链路上与(如车辆修理厂中的)诊断计算机系统交换数据，或者利用低功率转发器通过数据链路与管理计算机系统(如电子收费公路)交换数据。

在最近几年通过陆地和卫星RF分组网对于商业车队更复杂的车辆遥测已经成为可能。在这些车辆遥测系统中，车辆传感器数据可以在例如不需要车辆在特定的装配间的情况下，在无线数据链路上被传送到被编程来监视和记录车辆现象并且支持用于车辆维护的数据库系统的计算机。但是，这些系统操作相对昂贵。

大量的研究专注于开发可行的智能车辆公路系统(IVHS)，其是一种计算机辅助方法用于管理公路基础设施、同步信号灯、测量交通量，以便通过电子广告牌和旨在改善车辆的道路运输系统的质量和效率的其他新发明来提示司机前进的交通情况。

加利弗尼亚空气资源委员会(CARB)已经成为建立用于监视车辆的标准的领先者。最近CARB的被称为OBD-III的创新是第三代交通工具内的诊断要求，要求发出管理机构远程检索来自车辆的诊断数据，从而避免访问清洁空气检查站的需要。在一个驾驶程序中，低功率转发器被用于每个车辆，能够在车辆和路边接收机之间传送数据。当然，为使OBD-III提议进行下去，每个车辆必须有一个能够通过转发器采集和分发请求数据的系统。CARB积极地评估目前可用的技术并且调查电信行业以便看看什么是设计的未来的设备。到目前由CARB测试的操作平台相对麻烦并且有有限的能力被用于未来所需的其他数据交换。有兴趣找到一个平台能够很经济地运行以便使加在实现这个提议的消费者上的财务负担最小化。

而且，对于选择的平台希望能够实现不仅是向空气清洁机构发送诊断信息。电信和车辆行业在寻找方法来利用到达车辆中的域内往返者的巨大的商业机会，他们每天在其往返路途中要花几个小时。

车辆交通成为城市规划者的一个主要问题。随着土地价值暴涨以及土地使用问题变得越受关注，规划者在寻找方法使更多的车辆通过已有的市郊干线作为扩展它们的替代。还知道当交通变得拥塞时由干道测锤处理的实际交通量。因此，希望有车辆，其能够自己交换数据作为控制安全驾驶距离以便避免碰撞的方式以及与交通监视系统交换数据来控制驾驶速度这样的事。

因此本发明的一个目的是提供改进的平台用于车辆遥测。

本发明的另一个目的是提供改进的车辆遥测系统，其相对便宜，仍能够通过车辆和固定位置之间的数据通信系统交换一定范围的有用数据。

本发明还有一个目的是提供车辆通信系统，在其中的每个车辆都能够通过数据通信系统通信以及与它们自己通信。

发明概述

在其方面之一，本发明提供了一种将车辆运行数据从车辆传递到远程监视接收者的方法，包括步骤：

-建立车辆和远程监视接收者之间的数据链路；

-从车辆里的数据源采集车辆运行数据；

-利用从SNMP得出的协议将车辆运行数据封装到数据分组中；以及

-在数据链路上传递数据分组。

在其另一个方面，本发明提供了一种将车辆运行数据从车辆服务器传递到远程监视客户端的方法，包括步骤：

-建立车辆和远程监视客户端之间的数据链路；

-从车辆服务器里的数据源采集车辆运行数据；

-将数据封装到具有协议数据单元有效负荷的协议数据单元中，有效负荷包括多个VARIABLE BINDING(可变绑定)域，每个可变绑定域有一个两字节的OBJECT IDENTIFIER(对象识别符)域、一字节的VALUETYPE(值类型)域以及大小按照值类型域的可变绑定值；以及

-在数据链路上传递协议数据单元。

在其另一个方面，本发明提供了一种采集来自车辆的车辆运行数据用于以最小化后面传输的带宽需求的方式随后传输到远程监视接收者的方法，包括步骤：

-提供车辆车内计算设备；

-提供多个数据获取模块，每个测量车辆的一个或多个运行特征，运行特征对应于一组被管理的对象的当前值；

-将车辆车内计算设备与每个数据获取模块接口；

-配置车辆车内计算设备以便：

a)形成一个诊断信息库用于从每个对应数据获取模块接收和存储对于每个被管理对象的值；

b)基于在诊断信息库中包含的信息来组合事件报告；以及

c)根据源自SNMP的协议将事件报告封装在协议数据单元中。

优选的，运行特征包括如GPS位置、引擎速度、道路速度、里程表、或引擎温度、或与车辆发射相关的OBD-II参数。一个OBD-II参数是不点火检测，虽然其他的也可用，如O₂传感器。

在一个实施方案中，本发明还包括使车辆车内计算设备能够做如下事情的步骤：

a)建立与远程监视接收者的数据链路；以及

b)在数据链路上传递协议数据单元。

采集、封装和传递步骤可以同时出现或者在不同时间出现。在这种情况下，可以使计算设备以定期或不定期间隔采集数据并且累积某些类型的数据用于后来的传输，如行进距离，或用于立即传输的其他类型的数据，如当前GPS位置或超过的管理阈值。替代的，有一些实例，其中计算设备能够在有线或其他数据链路上传递协议数据单元。

优选的，该方法包括使远程监视接收者能够发出GET协议数据单元以便检索来自车辆车内计算设备的特定一组被管理对象的当前值。在这种情况下，远程监视接收者被启动来等待由车辆车内计算设备对于的GET协议数据单元的确认。

优选的，该方法包括使得车辆车内计算设备能够发出TRAP协议数据单元以便报告车辆事件的步骤。

优选的，该方法包括使得车辆车内计算设备能够做下列事情的步骤：

a)存储每个车辆事件的阈值或报告间隔；以及

b)当超过阈值时或者在相应的报告间隔中，发出每个TRAP协议数据单元。

在这种情况下，TRAP协议数据单元报告如GPS位置等的车辆报告。

优选的，该方法包括发出来自车辆的INFORM协议数据单元以便报告例外车辆事件的步骤。在这种情况下，该方法优选地包括使车辆车内计算设备能够做下列事情的步骤：

a)在诊断信息库中存储例外车辆事件的多个详细说明的任何一个，包括一个或多个管理例外，维护例外或运行例外；以及

b)当特定事件的任何一个发生时，发出INFORM协议数据。

在一个实施方案中，诊断信息库包括什么构成“事件”的发生而不是事件本身的详细说明。当事件发生时，事件记录被放在传输队列中并且保留在那里直到确认消息(在这种情况下是RESP消息)被车内计算设备接收为止。因此，该方法在一个实施方案中提供在寄存器或其他临时存储模块中车辆事件的存储，这些事件被在诊断信息库中规定。

被管理的对象，例如，可以是ENGINE TEMPERATURE(引擎温度)，以及用于被管理对象的条件可以是当当前值被测量时用于记录的MAXIMUM THRESHOLD(最大阈值)、CURRENT VALUE(当前值)以及TIME COUNT(时间计数)。

诊断信息库的一个例子被显示在下表中：

表1

被管理对象	值1	值2	值3	值4
被管理对象	值1	值2	值3	值4	TE：引擎温度	阈值	当前值	每10分钟测量值
TO2：O2传感器	阈值	当前值	每30分钟测量值		TE：引擎温度	阈值	当前值	每10分钟测量值

事件记录寄存器的例子显示在下表中，该表显示在特定时间T＝T1的被管理对象的当前值

表2

		X_T1
		X_T1					Y_T1

在一个例子中，INFORM协议数据单元作为超过的管理阈值的结果被发送。

优选的，该方法包括使得车辆车内计算设备能够等待由远程监视接收者对于前一个INFORM协议数据单元已经被登录在数据库中的确认。在这种情况下，该方法还优选地包括在没有由远程监视接收者对于前一个INFORM协议数据单元已经被登录在数据库中的确认的情况下重新发送INFORM协议数据单元的步骤。

优选的，该方法包括使得远程监视接收者能够向车辆车内计算设备发出SET协议数据单元以便设置一个或多个被管理对象的步骤。

无线数据链路可以是IEEE 802.11标准下的无线电频段，卫星RF分组网或陆地RF分组网，或其他。

在一个实施方案中，协议数据单元是“请求”类型(GET、SET或INFORM)协议数据单元，协议数据单元排除SNMP协议的ERROR STATUS(错误状态)和ERROR INDEX(错误索引)域。

在一个实施方案中，协议数据单元排除SNMP协议的每个可变绑定的LENGTH(长度)域。

在其另一个方面，本发明提供了一种将车辆运行数据从车辆传递到远程监视接收者的方法，包括步骤：

-建立车辆和远程监视接收者之间的数据链路；

-从车辆里的数据源采集车辆运行数据；

-在数据链路上传递数据分组，协议数据单元被响应远程监视接收者的请求而发出，包括该请求和该请求中的被请求的值并且被封装在单一消息中和单一未分段的网络分组中。

-提供车辆车内计算设备；

-提供多个数据获取模块，每个记录车辆的被管理对象的当前值；

-将车辆车内计算设备与每个数据获取模块接口；

-配置车辆车内计算设备以便：

a)形成一个诊断信息库用于从每个数据获取模块接收和存储被管理对象的值；

b)基于在诊断信息库中包含的信息来组合事件报告；以及

c)将事件报告封装到协议数据单元中，该协议数据单元包括具有多个VARIABLE BINDING(可变绑定)域的协议数据单元有效负荷，每个可变绑定域有一个两字节的OBJECT IDENTIFIER(对象识别符)域、一字节的VALUE TYPE(值类型)域以及大小按照值类型域的可变绑定值。

在一个实施方案中，协议数据单元包括一个具有PDU TYPE数据元素的头，该数据元素具有对应于一组值之一的值，该组包括GET值、SET值、TRAP值、INFORM值和RESPONSE值。

在其另一个方面，本发明提供用于将来自车辆的车辆运行数据传递到远程监视接收者的计算机实现的系统，包括：

-与车辆内多个车辆运行数据源通信的车辆车内计算设备；

-用于建立与车辆车内计算设备和远程监视接收者的无线数据链路的无线通信设备；

-车辆车内计算设备，该设备能够利用从SNMP得出的协议将车辆运行数据封装在数据分组中用于在无线数据链路上传输到远程监视接收者。

在其另一个方面，本发明提供了一种用于将来自车辆的车辆运行数据采集和传递到远程监视接收者的计算机可读数据结构，包括：

-用于接收来自车辆里多个数据源的车辆运行数据的应用模块；

-用于存储诊断信息库的存储模块，诊断信息库包括对于多个车辆运行参数的多个被管理对象以及对于每个被管理对象的多个值；以及

-用于在从SNMP得出的协议下在无线数据链路上向远程监视接收者传递协议数据单元的通信模块。

在其另一个方面，本发明提供了在计算机可读介质中编码的计算机程序产品，包括多个计算机可执行步骤用于车辆内的计算机将来自车辆的车辆运行数据采集和传递到远程监视接收者，包括：

-从车辆里的多个数据源接收车辆运行数据；

-在诊断信息库中存储对于多个车辆运行参数的每个的多个被管理对象；

-建立计算机和远程监视接收者之间的无线数据链路；

-在从SNMP得出的协议下在无线数据链路上向远程监视接收者传递协议数据单元。

在其另一个方面，本发明提供在载体介质上传播的信号，该信号包括包含根据从SNMP得出的协议编码机动车辆的预定运行数据的有效负荷的封装的协议数据单元。

优选的，有效负荷包括多个VARIABLE BINDING(可变绑定)域，每个可变绑定域有一个两字节的OBJECT IDENTIFIER(对象识别符)域、一字节的VALUE TYPE(值类型)域以及大小按照VALUE TYPE(值类型)域数据单元的VARIABLE BINDING(可变绑定)值。

优选的，有效负荷包括GPS位置段、GPS方向段、车辆速度段或OBDII车辆发射段。

在其另一个方面，本发明提供了用于将来自车辆的车辆运行数据传递到远程监视接收者的系统，包括：

-与车辆里的多个车辆运行数据源装置通信的车辆车内计算设备；

-用于建立与车辆车内计算装置和远程监视接收者的无线数据链路的无线通信装置；

-车辆车内计算装置，该装置能够利用从SNMP得出的协议将车辆运行数据封装在数据分组中用于在无线数据链路上传输到远程监视接收者。

在其另一个方面，本发明提供了一种将来自车辆的车辆运行数据传递到远程监视接收者的方法，包括：

-建立车辆和远程监视接收者之间的数据链路的步骤；

-用于采集来自车辆里数据源的车辆运行数据的步骤；

-用于利用从SNMP得出的协议将车辆运行数据封装到数据分组中的步骤；以及

-用于在数据链路上传递数据分组的步骤。

在其另一个方面，提供了一个用于将来自车辆的车辆运行数据采集和传递到远程监视接收者的计算机可读数据结构，包括：

在其另一个方面，本发明提供了用于在多个车辆之间交换数据的通信网，包括一个相应的车辆的车内计算单元，其中给定车辆里的计算单元是可操作的以便广播识别消息和接收来自相邻区域的其他车辆的等价识别消息，其中所述消息被用于识别网络中相邻的车辆，以便与其中选定的车辆交换数据。

优选的，计算单元是可操作的以便更新相邻车辆列表。在这种情况下，随着识别消息被从进入该区域的新的车辆接收，计算单元可以将新的相邻车辆加到列表中。替代的，当在预定的时间周期之后没有从给定的相邻车辆接收到识别消息，则计算单元可以将该给定的相邻车辆从列表中删除。替代的，当没有从给定的相邻车辆接收到标识消息指示相邻的车辆已经离开了相邻区域时，计算单元可以将给定的相邻车辆从相邻数据库中删除。

优选的，通信介质是高频信道化的RF频段并且每个所述计算单元对该频段的使用被根据IEEE 802.11介质接入控制(MAC)协议而控制。

优选的，计算单元是互联网可寻址的。

优选的，计算单元是IPv6可寻址的。

优选的，计算单元利用从SNMP得出的协议交换数据。

希望识别消息包括GPS信息和发送器的IEEE 802.11 MAC地址，其中GPS信息包括纬度、经度、速度和方向信息。

在一个实施方案中，附近的所有车辆在足够允许任何给定的车辆认识其邻居的发现时间周期里广播其识别消息。发现周期的长度和区域的地理大小可以与附近的车辆平均速度成比例地调整。

如果想要，则用于发送至少某些消息的信道选择可基于GPS方向。

在一个实施方案中，每个计算单元还包括能够在SNMP协议下发送和接收消息的发送机和接收机。

在其另一个方面，本发明提供如上的机动车辆。

在其另一个方面，本发明提供包括速度段、方向段和位置段的数据结构。优选的，位置段包括经度部分和纬度部分。

在其另一个方面，本发明提供了在载体介质上传播的信号，该信号包括速度段、方向段和位置段。优选的，位置段包括经度部分和纬度部分。

在其另一个方面，本发明提供了包括一个车内计算单元，该计算单元可操作来接收来自相邻区域中的其他车辆的消息用于组成附近列表，以便与其中所列的车辆中被选定的车辆交换数据。

在其另一个方面，本发明提供了用于运行机动车内的可编程计算机系统的计算机程序产品，包含一个计算机可读介质，该介质包括接收来自相邻区域中的其他车辆的消息以及组合成邻近列表用于与其中所列的车辆中被选定的车辆交换数据的计算机可执行步骤。

在其另一方面，本发明提供了包括车内通用计算机和扩频无线电单元的机动车，扩频无线电单元可操作以便建立与至少另一个其它相邻车辆里的无线电单元的数据链路，其中该计算机可操作地记录来自相邻区域中至少另一个车辆的消息用于组合成邻近列表，以及从在数据链路上接收的数据中识别至少一个车辆事件。

在本发明的另一个目的中，提供了一种用于采集和传递来自车辆车内计算设备和远程监视接收者的车辆运行数据的计算机可读数据结构，包括：

-用于索引一系列协议值和用于车辆车内计算设备和远程监视接收者之间的数据交换的相应的请求和响应的模块；

-用于索引用于车辆的多个运行特征的一系列被管理对象的模块；以及

-用于记录每个被管理对象的值的模块。

优选的，数据结构还包括用于索引每个远程监视接收者的身份的模块。

优选的，数据结构还包括用于索引每个远程监视接收者的一个或多个授权等级的列表的模块。这些授权等级可被用于在被传递到接收者的被管理对象值上施加条件。有些接收者可以被授予所有的被管理对象值，其他的仅被授予其中一些，并且仍有其他(那些不在列表中的)请求实体根本没有被授予。

附图简述

参考附图，本发明的几个优选实施方案将被提供仅作为例子，其中：

图1是协议栈的示意图；

图2是基于UDP的协议的示意图；

图3是基于TCP的协议的示意图；

图4是在基于UDP的协议中头部的示意图；

图5(a)和(b)是两个网络方案的透视示意图；

图6是SNMP协议数据单元的示意图；

图7是数据报交换的示意顺序图；

图8是GET协议数据单元例子的示意图；

图9是用于SNMP的MIB分层示意图；

图10是DIB分层的一部分的示意图；

图11是消息序列的示意图；

图12是网络的示意图；

图13是用于利用图12的网络交换数据的协议栈的示意图；

图14是另一个网络的示意图；

图15是信标帧序列的时距图；

图16a是特设网的一部分的示意图；

图16b是由图16a的网络中的车辆发布的信标帧的时距图；

图17是另一个特设网的示意图；

图18是另一个协议栈的示意图；

图19是另一个协议数据单元的示意图；

图20是象限划分的公路段的示意图；

图21是在驾驶操纵期间数据交换的示意图；以及

图22是在另一个驾驶操纵期间数据交换的示意图。

优选实施方案描述

下面所述的是一种实现用于车辆的诊断遥测的对等的基于互联网协议栈的系统和方法。这个栈计划驻留在车内的车辆嵌入系统中并且使远程PC工作站能够利用如Winsock的标准的通信API与这些系统交互。

栈的会话和表示层被标记为车辆遥测协议(ATP)。ATP解决了消息格式、协议过程、安全机制和外部接口的清楚规范的需要，可以利用它来开发软件，用于在不同的移动和固定计算平台上以相互可操作的形式实现OBD-III1。

¹由加利福尼亚空气资源委员会(CARB)带头的车内诊断III提议立法，其要求来自车辆里的引擎控制模块(ECM)发射有关的诊断信息以便使其在移动通信网上检索。

下面回顾的是寻求的目标并且然后提供了第3-6层(网络、传输、会话和表示)的更详细的描述。显示会话和表示层源自简单网络管理协议(SNMP)的规范。底层的传输机制是UDP/IP栈，UDP头为了带宽效率而被压缩。

安全性的问题在下面也被解决，以及配置栈的实现因此特定数据源可以被限制到特定的请求实体(“客户端”)的能力。加密套接字协议层(SSL)协议的应用被回顾以便说明由车内计算机对来自外部源的信息的请求的授权。

协议栈被应用于道路上车辆之间的运行数据的交换。这是基于在围绕任何给定车辆的“邻居”里建立的“特设网”的概念。假设采用路边的基础设施，特设网可以利用相同的RF介质与到互联网的数据链路共存。这种技术改善公路安全的潜力通过操作信息的车辆到车辆的交换的各种例子被说明。

还描述了用于在智能车辆和智能公路系统中的遵从IEEE 802.11的技术的集成的方法。下面做出对智能运输系统或ITS的参考以便包含这样系统的任何组件，无论是车辆内的还是公路基础设施的一部分。

智能车辆技术的当前焦点的大部分面向基于雷达的碰撞避免。另一方面，智能公路系统发展很大程度上依据车辆和公路基础设施之间的短程通信的使用。但是，来自车辆原始设备制造商以及政府机构的专家已经认识到车辆到车辆的通信组成了一个应该向前探索的领域。

IEEE 802.11规范是用于高速无线局域网(LAN)的相对新的标准。其使用称为扩频的RF传输方法，其中2.4GHz范围被作为未经授权的频段可用。这种技术还在商业标语Wi-Fi(无线保真)下被确认。其用于ITS领域的应用的潜力是基于其商业潜力。现在有商用的Wi-Fi产品，使得可能创建支持计算机设备的移动性的网络基础设施。使得包括膝上型电脑和笔记本的个人计算机能够使用Wi-Fi的网络接口卡(NIC)可用。随着Wi-Fi普及性增加，有望有更多移动无线设备(例如，PDA、蜂窝电话)在市场上出现，开发出接入点的增加的基础设施，通过其用户可以以目前达到11Mbps的比特传输率无线地连接到互联网上。

IEEE 802.11的一个特性是特设连网的概念，其使得两个或更多设备在不需要固定接入点的情况下能够直接彼此通信。换句话说，网络基础设施不是移动设备之间连接性的必要条件。结果，IEEE 802.11可以以创新和意想不到的方式支持同时的车辆到车辆和车辆到基础设置的通信。从技术角度和商业要求的这种灵活性的组合是在ITS中使用IEEE 802.11的基本原理。

在这个文档中描述的方法在没有修改规范的情况下，遵守实现完全依从802.11的节点的原则，以便满足用于ITS的特设连网的要求。

与ATP的关系

这里所述的方法想要提供一个平台，在其上车辆遥测协议(ATP)可以在两个车辆之间运行。ATP是源自SNMP的会话层协议，能够在移动通信的两个端点之间建立双向客户端-服务器关系[1]。在车辆到车辆通信的环境中，ATP允许“客户端”的车辆向请求确认的特定“服务器”车辆发送异步通知。这种请求-响应机制在本文档后面有描述的应用。

协议栈

图1利用OSI(开放系统互连)参考模型说明了OBD-III所需的完整的协议栈。

协议栈想要满足一个或多个下列目标：

·无线数据链路透明

这指技术独立性的需要。利用各种无线数据链路技术满足OBD-III服从应该是可能的。移动设备应该能够使用分组蜂窝、RF分组网、无线LAN(Wi-Fi)、卫星或其中的任何组合。

·互联网连接性(OEM门户之外)

在远程IP地址的工作站直接与与车辆里的OBD和其他运行数据接口的车辆内车辆设备交互应该可能。换句话说，车辆和任何远程主机之间的完全的互联网连接性是使授权的主机能够运行不需要转换OEM门户的应用的一个想要的结果。这暗示着车辆设备需要符合支持与互联网上任何授权的主机的对等交换的标准的协议规范。(参见下面与授权主机概念有关的安全性)。

·有效的带宽利用

负责监视的固定站点和移动单元之间的数据交换不应该是没必要的“罗嗦”。在无线应用中有一种趋势来假设某种形式的“web”表示被需要来简化用户接口(UI)，其部分地负责无线应用协议(WAP)的发展。WAP是一种提供Web的UI特性和空中链路上带宽效率的需要之间的一些折衷的技术。这些考虑没有一个考虑了遥测交通在目的上与其他形式的无线数据非常不同并且应该以不同的但是基于标准的方式被支持的事实。

·标准化的数据交换机制

协议栈的更高层(会话和表示)因明显的原因需要被标准化。这将简化在选择来实现规则的所有权限方面顺从OBD-III的任务。

·安全性

安全性的需要被CARB强调。OBD-III概念的政治接受依赖于公众的该技术不会成为一种国家对个人隐私侵犯的形式的信心。乘车辆的人和车辆的拥有者应该有这样的感觉，即在信息发出上的电子控制应该至少和目前在基于Web的电子商务中使用的一样有效。设想本系统，如果需要，将能够以在商业到消费者电子商务中实现的相同的方式实现会话层上的公共密钥加密。这确保了虽然还有与互联网上任何主机的连接性，但仅有通过安全机制获得授权的那些主机接收来自车辆的任何“注意信号”。

网络和传输层UDP/IP-为了理解其中ATP运行的上下文，支持其的下层传输机制需要被考虑。用户数据报(UDP)是用于“无连接的”客户端-服务器通信的传输层机制。UDP组成了可以在互联网上运行的传输协议之一。“无连接”协议的概念指没有专用于可靠的端到端通信的维护的系统开销的事实。在这个意义上，UDP被区别于TCP(传输控制协议)。更短的UDP头(8字节)反映这个区别。

互联网的基本的协议数据单元(PDU)被称为数据报。数据报头包含用于在栈的下一层指定协议的域。UDP和TCP的IANA²f值分别是17和6。下面的图显示根据数据报头中的“协议”域的值，不同数据报的有效负荷如何供UDP和TCP使用。

如上所述，标准的UDP头是8字节长度，包括：

·源端口(2字节)

²IANA(互联网分配号码的管理机构)

·目的地端口(2字节)

·有效负荷长度(2字节)

·校验和(2字节)

在UDP的传统使用中，源和目的地端口是与分别在发送器和接收器的地址空间里执行的过程相关的IANA批准的数字。对于本车辆遥测应用当前没有分配数字。本系统使用数字0x0A(整数10)来指定ATP端口。³

UDP头的压缩-在车辆遥测的应用中，UDP头的系统开销将消耗无线带宽而在灵活性和可靠性方面没有提供任何显著的优点。源端口和目的地端口都可以被限制使用相同的号。有效负荷长度可以从基础网络分组中的域或UDP段被封装在其中的数据链路帧得到。最后，校验和可以被看作是冗余的，因为基础的数据链路协议无论如何应该合并数据流的完整性检查。⁴

给定最小化无线带宽消耗的需要，在一个实施方案中，UDP头在移动通信协议栈的其中的实现中被减少到1个字节，其在图4中被说明。这个字节中的值(0x0A或整数10)识别源和目的地的ATP端口。

会话和表示层-ATP概念地存在于会话层。其是一种请求/响应机制，类似于简单网络管理协议(SNMP)，其确保对于从移动单元到基本位置或者相反的每个消息，总有一个确认。同样的，来自车辆的例外报告被移动计算平台丢弃，直到基本系统确认其已经被注册到“持久存储”数据库中。

ATP的设计基本原理是基于简单网络管理协议(SNMP)，其能够进行通信设备的远程诊断和配置并且是互联网基础设施的元件必须服从的事实上的标准。可以在通信设备和车辆的远程诊断之间进行比较。这在图5(a)和(b)中被图形地说明。

在SNMP中，“被管理实体”典型地是如桥接器或路由器的通信交换设备。这个被管理实体实现一个“代理”，其是负责检索被请求信息并且通过到通信协议栈的接口与远程“管理器”交互的软件模块。³这个号是还未被IANA分配的。⁴如果从源到目的地经过的任何数据链路不在协议中合并完整性检查，则ATP的数据完整性会有问题。但是，很难想象这样的情况。图5(a)显示这个栈的顶层是SNMP，其基本上是会话和表示层的组合。远程管理器请求的信息存在于管理信息库(MIB)中，其是由控制对外部世界(“通信模块”)的硬件接口的设备驱动器采集的操作数据的本地存储库。例如，带有以太网适配器的路由器维护报告通过以太网接口的入站和出站帧的数量的统计数字。这个信息被缓存在MIB中并且由代理代表发出请求的远程管理器检索。

在ATP的情况下，在下面的图5(b)显示的，等同于SNMP管理器的实体被称为监视器，并且被管理的实体是与各种数据获取模块接口的车辆车内的计算设备⁵。这被称为本地数据存储库诊断信息库(DIB)。在DIB中缓存的信息来自各种源，如ECU诊断端口、模拟和数字传感器、GPS接收机等。图中所示的三个例子是：·SAE J-1979(OBD-II所要求的诊断测试模式)·GPS接收机·直接模拟和数字输入信道

这不是一个详尽的可能的数据源的列表。其他例子有：·SAE J-2190(对立法的建议补充)·SAE J-2178(正常的车辆操作)·SAE J-1708(重型卡车和公共车辆)·SAE J-1939(J-1708的后续)

SNMP和ATP消息格式-SNMP消息由头⁶和协议数据单元(PDU)组成。头包含两个域：

·版本号

它指定由消息的发起者使用的SNMP的版本。

·社区名

这个作为认证的基本方法。属于社区的管理器被假定存在于相同的管理域里。当管理代理接收来自包含其不认识的社区名的管理器的SNMP消息时，其不参与SNMP运行。⁵这样的设备的现有版本被称为通用车内诊断服务器(U-OBD)。⁶这描述了SNMP最初版本的消息头格式。SNMP v3规定了一个更复杂的格式。当为ATP规定安全机制时，这将作为参考点变得有用。

在本系统中，优选地去掉潜在地冗余的域以便减少无线带宽的消耗。因为，如所示的，在表示层(也就是ATP上的层)需要更牢固形式的认证，所以这是带有社区名的情况。版本号仅在ATP发展超出实验阶段时，才变得必要。

SNMP协议运行-SNMP消息的剩余部分是协议数据单元(PDU)。在SNMP规范[1]⁷中定义了四种基本类型的请求PDU：

·Get

管理器使用Get PDU检索来自代理的MIB的项目

·Set

Set PDU由管理器用于在代理的MIB中设置值。

·Trap

代理使用Trap PDU来向管理器发送异步通知或“警报”。管理器不确认这些通知。

·Inform

Inform PDU类似于Trap PDU。任何SNMP实体(代理或与另一个管理器通信的管理器)使用Inform PDU来发送异步通知。与Trap PDU相反，接收管理器必须确认Inform PDU。

协议数据单元格式-这四类PDU⁸非常适合于ATP。在其使用在车辆遥测的环境中被检测之前，SNMP PDU的实际格式规范被概述。图6说明Get、Set和Response PDU的格式：

·PDU类型

这规定了PDU的类型。这是已经描述的四个请求PDU类型之一或者是响应。⁷参考书目[1]中的文档是对于SNMP最初版本的最近的RFC(互联网草案)。对SNMP的规范的完整的补充还包括对SNMPv2的一组RFC，其扩展了SNMP的功能，以及对SNMPv3的一组RFC，其提供安全特性。术语“SNMP规范”在本文档中被用于指由互联网工程任务组(IETF)出版的RFC中提供的规范的完整补充。⁸以前描述的请求PDU的类型是分类的，其中几个子类由SNMP的后来版本定义。

·Request ID

这本质上是PDU的序号。请求PDU的接收器在响应PDU中使用这个，以便发送器可以用以前发送的请求来匹配该响应。其还确保接收器可以过滤出重复的消息。这在移动无线连网环境中尤其重要，其中瞬时情况造成移动节点频繁地“不可到达”，其导致发送器试图重试。在这种情景下，到达目的地的重复消息的可能性非常高。

这在图7中被显示。封装在数据报中的请求PDU通过到移动网的网关被传送到移动代理。然后其被包入移动网分组中并且通过无线链路被从最近的RF基站发送到移动代理。然而移动代理可接收包含该分组的空中链路帧，RF基站可以不“听”在响应中被发送的确认。在必要的暂停周期之后，RF基站向移动网网关报告移动代理是“不可到达的”。当这个报告被传播回发送器(ATP监视器)时，该消息被重新发送。

·错误状态

这个域仅被用于响应PDU中。其指示多个错误和错误类型之一。

·错误索引

这个域仅被用于响应PDU中。其将该错误(如果合适)与在PDU的剩余部分中封装的“可变绑定”之一相关。

·可变绑定

这是SNMP PDU的数据域。每个可变绑定是被管理对象的特定实例的一个关联，其是MIB的一部分，带有其当前值(除了Get请求PDU，对于其这个值被忽略。)对象识别符(OID)域识别对象实例。变量的值根据三个一组的TLV(类型、长度、值)被编码，其中类型指定数据类型，长度是其中该值在后续流中被表示的字节数并且值包含长度字节中的值。这个编码方案遵守在抽象语法符号语言(ASN.1)的基本编码规则(BER)中被提出的实践。

ASN.1是经常被用于定义在OSI模型的表示和应用层的数据交换协议的ISO-指定的语言。其抽象的性质使得其独立于在不同的计算平台上可以遇到的不同的数据表示技术。当然，用于表示数据结构的语法越抽象，当这些结构在通信网上的数据流中被串行化时需要越多的系统开销。为此，SNMP仅使用ASN.1的子集(特别地是BER的子集)以便限制与编码方案相关的系统开销，并且因此保存了互联网上的带宽。[2]，[3]

在ATP中，仍然为了保存带宽的目的(这在ATP的移动环境中更加重要)，通过对除了可变长串之外的所有串去掉长度域来对编码方案施加进一步的限制。这显示在以前说明的SNMP PDU格式中可变绑定的详细格式中。只有类型域被使用。接收器必须从接收的类型推断值域的长度。

在一个实施方案中，这个相同的格式已经被采用作为ATP PDU的模型。但是，为了限制无线环境中带宽的不必要的使用，产生下列例外：

1.错误状态和错误索引域在请求PDU中不存在。

2.可变绑定的值域在Get PDU中不存在。

3.在PDU中所有域的长度，包括可变绑定中的OID和值域(除了字符串)是隐含的；也就是它们没有如由ASN.1所规定在数据流中被明显地编码。所有头域的长度被限制为一个字节。OID域的长度是两个字节并且可变绑定值的长度依赖于值域，其被编码在一个字节中。

带有SNMP PDU的ATP协议运行-如已经陈述的，带有前面一节中所述的修改的SNMP PDU适合于ATP的协议要求。当ATP监视器想要检索对于来自车辆的一组特定的被管理对象的当前值时，需要Get PDU。例子在图8中被说明。车辆拥有者可从固定位置工作站获得车辆的GPS位置、引擎速度、道路速度和引擎温度。对来自包含所有被请求值的车辆的所有这个数据的请求和响应将被封装在单一ATP消息和未分段的网络分组中。

Trap PDU可被用于发送不要求确认的来自车辆的事件报告。典型的例子是循环的GPS位置报告。车内设备中的应用软件⁹可以在GPS“被管理对象”的数据结构里规定的间隔生成带有GPS位置的PDU。这个报告的目的是实时跟踪车辆。因此因为发送器没有原因来重新发送立即变得陈旧的GPS位置，所以来自监视器的确认是多余的。⁹对于代理软件结构的SNMP规范称此为通知发起方应用。管理器实体里的对等软件被称为通知接收方应用。

要求确认的Inform PDU是在ATP中更通常使用的机制以便发送来自车辆的同步事件报告。这些事件可以对应于：

·管理例外(例如要求干预的发射有关的事件)

·维护例外(例如要求立即检查/验证/修理的故障情况)

·运行例外(例如在未被授权方式下车辆的使用)

因为对于这个PDU需要确认，所以车内监视代理有确认事件报告是否已经在数据库中被注册的方法¹⁰。

Set PDU被用于远程改变车内设备的运行参数。这可以是，例如管理例外发生的阈值等级或者主动提供的GPS位置报告的间隔(对于带有Trap PDU的跟踪应用)。

MIB层次和DIB得出-SNMP提供访问的MIB是按图9所示被分层组织的被管理对象的集合。被管理对象¹¹是被管理设备的任意数量的特定特征之一。被管理对象由基本上可变的一个或多个对象实例组成。

图9说明象一个树的MIB层次，其等级由不同的组织分配。对象识别符(OID)唯一地识别这个层次中的被管理对象。顶层的OID属于不同的标准组织，而较低层的OID由相关组织分配。OID由对应于通过其被管理对象可以从树的根部被到达的节点的数字序列形成。例如，序列是：

1 3 6 1 2识别MIB-2对象，其是服从TCP/IP协议栈规范的实体的MIB。完整的对象名为：

iso.identified-organization.dod.intern6t.mgmt.mib-2

假设这个MIB在有到几个网络的接口的远程路由器上被维护。表示这些接口的对象在表中被维护，这些实体的每个是与网络接口相关的变量的集合。假设，例如，SNMP管理器想要检索在第一个网络接口上接收的(从最后的启动以来)八位字节的数量。识别这个对象的OID是：

1 3 6 1 2 1 2 1 1 0¹⁰通知接收方应用的责任是确保在确认PDU被返回到代理之前这些报告被提交给数据库。¹¹术语MIB对象、对象、或者只是MIB与术语被管理对象互换使用。

并且对象名是

iso.identified-organization.dod.internet.mgmt.mib-2.interfaces.iftable.ifentry-1.ifoctets

对于诊断信息库，类似的方案被设想。出现的问题是DIB子树是否应从互联网节点分支出来或者SAE子树是否应该从被识别的组织分支出来。很显然这两个选项将如图10所示出现。该说明使新的子树的根部是DIB节点。而且，因为ATP是在互联网协议组中与SNMP在相同层运行的(被建议)协议，所以很清楚，DIB将与从互联网节点开始的子树一起存在。

不明显的是DIB在没有互联网节点的副本的情况下，如何在其根部在SAE节点处的子树里存在。这是对层次中任何节点可以被唯一识别的规则的违犯。因此，新的子树从ATP节点开始显得更合乎逻辑。

如前面提到的，ATP PDU的可变绑定中的OID被编码成两字节的固定长度。这意味着OID涉及到的对象的整个父层次没有被包括。前缀

1 3 6 1 2 8

对应于对象名

iso.identified-organization.dod.internet.mgmt.dib

是每个OID隐含的部分。只有DIB节点下面的部分是串行的并且在网络上被发送。

用户配置-在协议栈的最高层，可以有某些形式的用户接口允许安装者(或者最终的驾驶者)指定内部车辆数据的哪些源应该是远程“客户端”可访问的。下一节解释任何远程客户端的身份如何可以被完全认证以及客户端和(车辆的)服务器之间的后续数据交换如何可以防止偷听者被安全实现。

安全性-通过ATP，代理应该有权力基于请求的特性和监视器的身份来接受或拒绝来自监视器的请求。例如，如果其源自没有被车辆拥有者控制的一个位置，则来自远程监视器报告当前GPS位置的请求可被认为是对隐私的侵犯。类似的，对OBD信息(SAE J-1979)的请求也可以被拒绝，除非其源自根据用户配置被授权的监视器。

为了满足这些需求，移动代理和监视器之间的通信链路必须提供请求实体的保密性和授权；所述请求实体也就是监视器。这个的理想框架是加密套接字协议层(SSL)协议。SSL由Netscape开发并且成为互联网中客户端和服务器之间以及特别对于基于Web的电子商务的互操作安全性的事实标准¹²。SSL定义了握手协议，该协议允许任一方利用有效地牢不可破的公共密钥加密方法对另一方的授权。

通常，SSL在TCP/IP之上运行，其构成了对于Web业务的下层传输机制。但是，因为遥测应用的特性，ATP使用TCP/IP栈。SSL记录层的较低边缘因此必须适合于对UDP传输机制的接口。

图11显示在ATP层和表示层之间引入的SSL的安全机制，其中协议数据单元(PDU)被解析成对特定数据源的各个请求。安全层作为防止未被授权的入侵者的有效的“防火墙”。其认证远程监视器并且维护通过会话交换的后续PDU的内容的保密性。SSL握手协议和表示层之间的接口应该为SSL提供一种机制来使得通过认证的监视器请求信息的识别放在接收的PDU声明之前。

这种机制，以及后续的数据交换，由图11中的序列说明。

这个序列的各个步骤可以被描述如下：

1.监视器的表示层通知其安全层其想要向移动代理发布请求。

SSL握手必须现在在客户端(监视器)和服务器(移动代理)之间发生。

2.SSL握手层要求SSL记录层封装必需的握手消息。

3.SSL记录层向另一端发送不对称加密的消息(公共密钥加密)。

4.SSL记录层向SSL握手层递送解密的消息。

步骤2-4在两个方向被重复直到客户端的认证已经被建立。

5.一旦监视器已经被认证，SSL就向表示层报告其身份，因此对信息的后续请求可以根据用户配置被接受或拒绝。

6.监视器端的安全层向表示层报告认证被确认。

7.监视器的表示层为会话保密性加密向安全层发送PDU.加密在SSL握手期间通过各方之间交换的对称一次密钥进¹²参见[4]中的规范。行(其确保交换的保密性)。

8.加密的PDU“被发送”到移动代理。换句话说，其被向下传递通过监视器协议栈的会话层。

9.当加密的PDU到达移动代理的SSL记录层时，其在被递送到表示层之前解密。

10.来自表示层的响应被发送到SSL记录层。这个响应是：

·被监视器请求的数据

·由监视器发送的命令已经被执行的确认，或者

·因为监视器没有对于请求或命令的必须的权力，所以命令或对数据的请求的拒绝。

11.SSL记录层用对称会话密钥加密响应并且发送回监视器(也就是通过以移动代理的会话层开始的协议栈)。

12.监视器的SSL记录层解密PDU并且将其传递到表示层。

注意这个序列的全部或部分可以以反向被执行。假设监视器表示发射控制管理代理并且移动代理每年从这个监视器接收请求以便报告所有不服从的事件。移动代理可在表示层用肯定确认响应，也就是请求的接受。对于跟随的365天周期的剩余部分，所有的例外情况将导致移动代理启动通信以便报告这些条件。因此请求从移动代理发出，然而来自监视器的响应将指示例外报告已经被记录并且在永久存储器中被记入日志。(U-OBD可以被配置在闪存中保留这些例外报告，直到从监视器接收到确认为止。这确保了在车辆没有在覆盖范围里的时候发生的例外没有“被忘记”)。

车辆到车辆遥测- 与无线LAN的特设连网-OBD-III是包含移动服务器和固定位置客户端的遥测的例子。被预见的还有两辆车辆之间的客户端-服务器关系的情况。两辆车辆之间的数据链路可以利用无线局域网的IEEE 802.11规范的特设连网功能被建立。无线局域网中的特设网在没有被称为接入点的中央协调节点的情况下被创建。图12说明特设无线局域网和具有接入点的一个之间的区别。

通过使用不同的扩频信道，两种类型的网络可以在相同的硬件平台上共存。接入点为车辆提供到广域网(也就是互联网)的连接性但是对于特设网不需要。特设网使得车辆能够建立与其邻居的逻辑链路，其可被用于在车辆之间交换关键的运行信息。

特设网可以利用这里具体化的允许每个车辆保持其“邻居”的实时图像的方案被创建。这个邻居可包括在前面和后面方向等于五百码的车辆。每辆车辆里维护的图像随着周围情况的改变而动态地改变。

ATP协议栈可以被利用与被用于与远程诊断客户端交互的几乎相同的方式用于车辆到车辆的消息传送。区别是因为所有车辆必须必要地并且自由地交换信息，所以安全性限制在这种情况下不能应用。这在图13中被说明。

应用：安全与拥塞管理比较-车辆到车辆通信在用于智能传输系统(ITS)的“排(platooning)”环境中已经被用于实验的基础。“排”只是在下面被称为道路上的“群集智能”的一个例子。群集是邻近的车辆的聚集。因为任何车辆的邻居组成围绕其的流动网络拓扑，所以相关群集的成员关系是动态的。

群集里信息的交换(或者广播)在道路安全以及针对减少拥塞的交通管理方面有价值。在有些方面，这些区域之间有人为的区别。更好的交通管理应该导致更好的安全并且反之亦然。下列应用区域的描述在这两个目的之间没有区别。

冗余-如巡航控制或驾驶座电子信息系统的车辆车内系统可以从各种输入中获益，包括转发碰撞避免雷达以及由带有特设连网的ATP促进的车辆到车辆信息交换。

因此特设连网可以被看做提供到控制/信息系统的一组补充输入/服务。在有些情况下，这些输入/业务可以是另一种的补充，而在另一些情况下它们可以重叠。例如，在车辆是启用IEEE 802.11的情况下，雷达可以通过为立即相邻的车辆提供相邻信息来补充特设连网。当然，如果这些车辆也是启用IEEE 802.11的，则这个功能与雷达的功能重叠。这提供了一定程度的冗余，这仅对于增强的安全的目的有益，特别是因为提供基于IEEE 802.11的服务的边际成本无关紧要¹³。

对于远程车内数据获取的移动数据通信的增加的使用引起了对能够通过广域网参与车辆遥测的模块的互操作性的标准结构的需要。具¹³假设车辆是为广域连网目的启用IEEE 802.11的。有最大潜力用于广泛使用的应用是无线车内诊断(OBD-III)，但是有多个其他应用，包括车辆维护和跟踪。其中节点诸如桥接器和路由器的节点可以被管理实体远程诊断的通信网络管理的范例，提供了用于远程车辆诊断的合适的模型。因此简单网络管理协议(SNMP)的规范被以创新和想不到的方式被用做得到车辆遥测协议(ATP)的基础。ATP在开放互联网环境中运行，该环境允许位于网络中任何位置的车内诊断“代理”和“监视器”之间的客户端-服务器关系。SSL协议在此之上分层以便提供安全性。相同的协议结构，减去安全性，可以在用于智能传输系统(ITS)中的应用的基于IEEE 802.11的特设网的上面分层。

网络邻域

网络邻域的概念已经象其被用于在拓扑意义上来描述数据链路上相邻节点的特征而被借用。如果节点A在没有经过通信桥接器的情况下可以到达(传输到)节点B，则A和B被认为在相同的邻域。这在图14中被说明，其描述通过桥接器连接的两个数据链路。右边的数据链路被IEEE 802.3(以太网)规范定义，其通常被用于无线局域网(LAN)。左边的数据链路由是无线LAN的IEEE 802.11规定。如图14所示，A、B和C是无线LAN上的邻居，而D、E、F和G是有线LAN上的邻居。虽然这在图14中没有被清晰地显示，但是无线和有线LAN的邻域被节点之间的拓扑关系而不是物理距离定义。如果两个节点共享相同的介质并且它们之间的信号质量是可接受的(在错误等级方面)，则它们拓扑地在相同的邻域或是临近的。

在智能公路网络邻域的情况下，如果想要，额外的地理标准可以被增加到邻接性的确定中。通过将数据链路上其他节点的GPS位置报告与其自己的GPS位置相比较，每个节点可以过滤出在特定地理阈值之外并且因此与车辆的运行无关的那些节点。

从单一节点的观点看，前面的描述允许直到提出ITS Wi-Fi邻域的定义。

ITS Wi-Fi邻域是周围IEEE 802.11节点的集合，这些节点共享一个公共物理介质(也就是特定的直接序列扩频信道)以及用于介质访问控制的定时参数，并且在对任何类型公共道理上车辆的安全运行很重要的有关地理位置。

在网络上注册

IEEE 802.11规范定义被与定时同步功能一起使用来协调对介质的访问的定时参数；也就是，最小化对信道的争夺并且减少碰撞的可能性。节点不能使用介质来传输数据直到它们接收来自已经是网络一部分的节点的合适的“注册”帧。注册帧包含在介质上正确地运行所需的信息，包括允许新的项目与已有节点同步的时间戳。

在802.11中，用于协调对介质访问的方法被称为类似于在802.3(以太网)中使用的方法的带有冲突避免的载波侦听多路存取(CSMA/CA)。其基于在传输之前“查找”载波信道的思想。如果介质忙，则带有要发送数据的节点在重试之前进入随机计算的等待周期，其最小化由等待该信道的多个节点同时重试(并且可能造成结果的“完全拥塞”)的可能性。

802.11规范称这个为分布式协调功能(DCF)。其还定义被称为点协调功能(PCF)的无争用机制。虽然DCF是缺省的运行模式，但是PCF已经可被用于处理特殊情况，如在音频和视频的时间关键的业务的情况中。典型地PCF通过固定接入点被提供，其在ITS的情况下将采用路边基站的形式。

想要接入互联网的车辆将利用为这个应用分配的信道向路边接入点注册¹⁴。流音频和视频，或者对于VOIP(IP上的语音)的性能标准，可能需要信道管理的PCF方法。但是，共享相同邻域的车辆的特设网将使用DCF来管理其信道。因为DCF不依赖于“主”站的存在来协调对介质的接入，所以特设网不需要路边基础设施以便正确地起作用。

这不能排除路边基础设施的使用。即使互联网接入和其他服务是可选的，基站对于各种辅助ITS功能仍被需要，包括差分GPS信标、关于公路系统的地理方向¹⁵、电子收费、电子道路标志和旅行信息。

注册机制本身可以在被动或主动模式运行。这两种方法被描述如下。

¹⁴参见为在ITS和互联网功能之间信道分配的讨论的名为Wi-Fi信道选择的章节。

¹⁵参见Wi-Fi信道选择。

被动注册

在被动模式中，候选节点侦听来自已有节点的信标。在特设网中，所有已有节点周期性地发送信标帧，允许节点进入网络以便与已有节点同步用于信道管理。信标帧信号通知无争用周期的开始，在此期间邻域中的所有其他节点推迟传输，因此想要声明其存在的新节点可以这样做。信标帧和后续无争用周期之间的间隔都是典型地可分别在范围1-2秒、以及100毫秒-0.5秒的访问中设置的可配置参数。但是，如可以在下一节看到的，在相同的邻域里，特别是在拥挤的公路情况下可以有几百辆车辆，这使得不可能实现这些设置。增加信标帧之间的间隔仅是解决方案的一部分。图15说明如果100辆车辆的每一辆要以10秒的间隔发送信标帧，每个声明100毫秒无争用周期的开始，则在10秒周期里将没有时间剩余来发送任何用户数据。

完整的解决方案依赖于ITS特设网节点不需要协商在802.11的介质访问控制(MAC)层规定的关联和认证的任何逻辑管理功能的事实。关联是一种机制，由此一个节点请求来自另一个节点的显式识别。在基础设施网中，请求被发送到接入点，其在本地表中存储请求节点的地址并且发送响应帧。由接入点维护的地址表控制去往特定地址的分组是否实际被发送。如果对于一个地址没有关联被建立，则将没有用户数据被发送到那里。

但是，如在名为邻居发现的章节中解释的，ITS特设网中的大多数用户数据被发送到广播地址(也就是到所有节点)，对其不需要关联。有一些应用，其中与周围车辆的关联被需要，但是这些仅是与物理相邻的车辆。每个节点应仅与规定边界里的邻居协商关联，其中这些邻居的驾驶操纵足够重要来保证(也就是寻址到特定的目的地节点的)单播消息。因为每个节点将接收来自其不需要关联的邻居的很大量的信标帧，所以跟随这些信标帧的无争用周期将基本上被浪费。为了保存带宽，无争用周期应该被减少到最小可允许值(也就是1毫秒)并且关联的协商应该不被信标帧的接收而是被在下面一节描述的通过发现过程确定的条件所触发。

认证是请求节点被由此授权允许利用对称加密密钥通信的过程。在ITS特设网中，认证不仅不被请求，而且其对于车辆排(platoon)或“群集智能”的概念是正相反(anti-thetical)的，因为所有方必须在没有限制的情况下必要地和自由地交换信息。

主动注册

主动注册方法使得候选节点能够发送探测帧，其基本上是对于某些其他节点要响应的“ping”请求。在特设网拓扑中，探测必须被广播给所有听者，因为没有单一的节点可以被依赖以便总是存在(也就是固定接入点)。IEEE 802.11规则是对探测的响应由发送最近的信标帧的节点发送。

主动注册的功能使得我们能够通过信标帧的传输来最小化带宽的使用。假设信标帧之间的间隔被配置为60秒。通过每个信标帧之后的仅1毫秒的无争用周期，5辆车辆的排将使用大约.01％的可用时间用于信标帧的广播，并且500辆车辆的排将仅使用1％。

5辆车辆的情景被显示在图16a和16b中。信标之间的平均时间是12秒。排中的每辆车辆根据其用于发送信标帧的序列位置被编号。进入进路坡道的车辆6，在车辆4发送其信标帧之后开始发送探测请求帧，以便发现新的特设网¹⁶。车辆4几乎立即用探测响应来响应¹⁷。

邻居发现

邻居发现机制与被用于在具有动态拓扑的网络环境中对于数据业务量进行路由的邻居发现协议的概念可比。该方法基于如前面解释的，合并地理组件的主动提供的邻居广告。这些是每个节点广播包含其GPS信息，包括经度、纬度、速度和方向的周期性的消息¹⁸。

¹⁶进入高速公路的新车辆必须知道何时试图切换到新的特设网。如在Wi-Fi信道选择中讨论的，特定信道基于方向被分配给分道公路上的车辆流。我们假设车辆没有被装备准确的数字地图并且因此不能使用GPS来确定其是否进入分道的公路。因此有必要采取这样一个规则，也就是当车辆的邻域的“前进”区域突然变得“数量减少”时，则车辆必须开始在所有合适的信道上广播探测帧，直到其接收来自具有匹配方向的车辆的响应为止。参见名为改变邻居的章节。

¹⁷探测响应帧必须竞争带有邻居发现和其他用户业务量的信道。参见下面的章节。

¹⁸仰角也需要。这使得接收车辆能够从水平面的车辆中区分出高架快速道上的车辆。

邻居广告由特设网中的每个节点用于在存储器中建立邻居的当前配置的“图像”。图17说明这个概念，显示由在通过路线中第二个车辆形成的邻域图像。

被称为发现循环的广播之间的时间间隔，必须足够频繁以便维护在每个邻居的相关位置方面准确的邻域图片。GPS报告的准确性，在地理临近另一个的两个节点的相对位置方面，比绝对的GPS报告的准确性高很多，因为卫星信号的处理中固有的误差应同等地影响所有节点。因此，每个节点关于另一个的相对位置应理论上，基本不包含误差，使得车辆能够以对碰撞避免和排的任务有效的一定的精度来判断它们之间的距离。例如，以70mph行驶的车辆的位置改变每秒超过100英尺。这建议需要每秒更新几次以便维护准确性。但是，更新的频率由在发现周期期间生成的数据业务量的数量限制，以便避免信道争用。这进而是在RF范围里的车辆的数量，也就是邻域总数的函数。

但是，应该认识到，所有这些变量之间的有循环关系。邻域总数是周围车辆的平均速度的函数。速度越高，邻域总数越少；因此发现周期里数据业务量的数量越小，则虑及越高频度的更新。

这可以由例子说明。在70mph，安全停止距离大致是200英尺。假设所有的车辆考虑建议的停止距离¹⁹，最大RF范围3000英尺²⁰并且在相同方向最大四车道²¹，则周围邻域可以包含最多60辆车辆。

为了确定在扩频信道上发送的业务量的总量，必须首先建立每个发现分组的整体大小。这在图18中显示，其描述从物理层到会话层(ATP)的协议栈。预计数据链路层(IEEE 802逻辑链路控制)上的所有要求的用户信息可被压缩成8字节。结果是在物理层汇聚过程(PLCP)子层的帧大小为64字节。因此，发现循环中的业务量的总量是：

64×60＝3840字节或30,770比特。

¹⁹这当然是这个技术的最终目标之一。

²⁰基于每个发送机0.5公里的最大范围，每个节点可以听到这个半径里的发送。因此邻域的“宽度”是1公里或大约3000英尺。

²¹在相反方向或相邻的“收集器”或“高速”流中行进的车辆，不在相同信道上发送发现帧。参见Wi-Fi信道选择。

在11Mbps²²，扩频信道的数据速率应该能够支持一秒间隔里的几个发现循环，甚至考虑归因于这种相当大量的节点的信道争用的吞吐量的某些下降。

为了补偿这个改变，“群集智能”过程的事件队列应该包括周期性定时器，基于其最后广播中报告的速度和方向驱动邻域中所有车辆的位置更新。

过滤邻域广告

每个节点可以限制其邻域的总数，使得仅有足够近以便对车辆的安全运行有潜在影响的那些邻域被包括。通过过滤出这个边界之外的节点，存储器里邻域“对象”的集合的大小被限制并且周期性更新属于这些对象的任何状态变量所需的处理量也被限制。

消息压缩

已经说明GPS发现消息可以被压缩成8字节。这通过仅合并经度和纬度的最低有效2字节来实现²³。这2字节表示该数的分部分的小数部分。因为经度或纬度的一分大于1英里，这远在0.5公里的最大RF范围之外，所以这足够了。因此，接收节点可以通过用其自己的GPS位置的度和分来替换经度和纬度来很容易地重建发送节点的GPS位置。其还必须增加或减少充当接近测量边界的这些值。例如，如果接收节点有43度和56.9982分的纬度，而接收的消息指示0.0053分的小数部分，则被替代的分值应该是57，而不是56。

图19说明完整的GPS发现消息的格式。速度是从0到255的整数值(一个字节)并且方向是带有7比特的小数度的从0-360(9比特)。前导字节在最高有效位中指示要由发送者用于在下一个发现循环的广播的信道。这在下面一节被解释。前导字节的其他位被保留供以后使用。

²²因在信道选择中解释的原因，利用特设连网的信道的数据速率更可能是2Mbps，其仍被期望对于每秒几个发现循环足够。

²³如果包括仰角，则这个消息的大小增加到10字节。

Wi-Fi信道选择²⁴

用于移动应用的802.11规范要求可以在不干预的情况下同时运行的直接序列扩展(DSS)的至少3个信道。但是，通过发送器的基于软件的配置，在更低数据速率可以获得更多信道。例如，通过为高速互联网接入分配单一11Mbps信道，更大量的至少6个2Mbps信道可以从剩余带宽中被获得。这允许移动节点将特设连网数据业务量从使用路边接入点的基于基础设施数据业务量中分离。因为不需要在中线对边的车辆之间的通信，所以其满足每个节点监视用于由在相同方向行进的所有其他节点广播发现消息的信道。

为了避免在相反方向行进的车辆之间不必要的信道争用，用于发现广播的信道选择可以在方向的基础上被确定。简单的方案是分配10个信道中的4个用于特设连网并且将罗盘划分成四个象限²⁵。但是，如图20所显示，这不能处理一个很小的道路弯曲会导致这样一个情况，也就是后行车辆监听领先车辆不再在其上发送的信道。这可以通过以指示邻居下一个消息将在哪个信道上被发送的方式来标记发现消息而被解决。

换句话说，当车辆检测道其方向已经偏移到不同的象限时，其不应该立即开始在相应信道上发送。下一个消息在当前信道上被发送但是所有的听者将被建议被用于后续消息的信道²⁶。只有后行车辆应该转换到监视新的信道。如果其在接收来自前面车辆的信道标记的改变之前检测方向的改变，则其还应该转换。

这个车辆进入过渡阶段，其中其监视一个不同于其在上面发送的信道。在这个周期期间，下一个后行车辆将仅从在“旧”信道上发送的邻居接收消息(也就是在道路上的弯曲之前)。其将不接收任何发

²⁴这一节描述对于未经许可的2.4GHz波段的规范下可用的信道的使用。这个规范名为IEEE 802.11(b)。具有其他频段，如由FCC为智能公路分配的5.9GHz频段的IEEE 802.11 MAC的使用可规定不同的调制和信道化技术因此可用信道数可以不同。但是，分配对各种IVHS功能可用的信道的概念没有改变。

²⁵额外的信道应该被分配由未分道的公路和城市街道上的所有车辆使用。

²⁶还注意后续消息不能被发送，直到利用探测帧在新信道上的注册已经发生。件报告。为了补偿这个，需要连续地扫描“旧”和“新”信道，直到现消息。更重要的，其将不接收来自排中前面几辆车辆的任何异布事其接收来自其前面的车辆的“下一个信道”标记为止。

改变邻域

为了建立车辆在其下改变邻域的条件，现在参考前面给出的ITSWi-Fi邻域的定义。当共享介质改变时，邻域改变。当道路方向偏移到一个新的罗盘象限并且有所述排的到新的Wi-Fi信道的分段转换时，这个改变的一个例子已经被描述。

为了解决这个问题，下面的问题需要被回答：在不需要使用详细的数字地图的情况下车辆如何确定其进入高速公路？如果车辆跟随着进入高速公路的另一辆车辆，则解决方案很简单。这是领先的车辆的问题！后行车辆只需要为来自领先车辆的“下一个信道”标记监视当前信道。当然，这是很容易做到的解决方案，因为其将问题转移给领先的车辆并且除此之外，其没有针对当前在邻域里没有领先车辆的情景。

答案由利用探测帧用于主动网络注册的机制提供。当车辆检测到其前面没有车辆时，其必须开始探测分配给车辆的当前方向落入的罗盘的象限的四个信道的任何一个。其应该继续监视用于未分割的公路和城市道路的已有信道，直到其接收来自新的信道上的某个节点的响应。两种可能性之一将出现。

·新的邻居被找到(通过已有信道上的发现机制)。这些可以在相同或接近的方向上移动。或者甚至在横向方向上。它们的位置排除了车辆在到高速公路的进路坡道的可能性。在这种情况下，车辆停止周期性的探测。

·探测响应在新的信道上被接收。车辆必须准备转换信道并且通过设置其下一个发现消息中的“下一个信道”标记来通知所有其当前邻居它在这样做。

在车辆离开分离的高速公路的情况下，这个情景相反。

服务广告

有这样的情况，其中特定节点可提供在带宽方面昂贵的信息流来以主动提供的形式广播。代替的，这些节点可以通过周期性地广播一个消息来为这样的业务的可用性做广告，该消息通知所有听者该服务一旦请求就可用。这样一个例子是在车辆内或者交通信号灯上安装的数字视频摄象机。

应用

安全性与拥塞管理相对

特设网对ITS任务的应用在道路安全以及旨在减少拥塞的交通管理方面都有价值。在某些方面，这些区域之间有人为的区别。更好的交通管理应该导致更好的安全性并且反之亦然。下列应用领域的描述在这两个目的之间不区分。

事件通知

参与特设ITS网的所有节点被要求通知其邻居对其相邻车辆可能很重要的任何运行事件，如加速、刹车应用、转弯或变化车道等。这些事件应该被作为发送到广播地址的异步通知被报告。换句话说，在监听的任何邻居应该接收事件的实时通知。例如，脚制动器的应用不仅应该被报告给后面的后行的车辆还应该给在后面的排中的任何其他车辆。刹车灯的反应时间(如果其起作用)典型地在0.5秒的范围里。因此，如果在七辆车辆的排的最前面的车辆应用脚制动器，则在排的末尾的车辆在看到其前面的车辆的刹车灯之前可以接收多达3秒的通知。

所有异步事件通知应该被重复n次，其中n是IEEE 802.11 MIB(管理信息库)的可配置参数。事件通知的重复将确保被要求监听超过一个信道(在Wi-Fi信道选择中描述的转换阶段期间)的后行邻居将有机会听到该消息。

意向通知

特设网提供对于关于驾驶操纵的车辆到车辆的意向通知的装置。要求来自通知的接收器的明确的确认的这种通知的种类可以被规定。(LLC层的确认无连接服务)。这些对应于可以通过ATP客户端服务的使用被发布的Set命令。通过确认这些通知，接收器通知发送器其“知道”发送器的意向。然后两方知道的状态可以变成对其各自控制或驾驶座电子信息系统的输入。

超车

图21演示可以由特设连网辅助的驾驶操纵的例子。在超车车道的车辆A的速度大于在慢车道的车辆B的速度。假设B的速度保持恒定，A可以利用其自己的速度和与B的邻域位置来确定在其经过B之前有多少时间。当剩余时间等于提前通知所需的时间间隔(Δτ)时，A向B发送包含想要在左边超过的通知的单播帧。如果B用确认响应，则因此A能够为合适的控制或驾驶员信息系统提供要被超过的车辆“知道”该意向的确认。

车道改变

要改变车道的意向可以以类似于要超车的意向被声明和确认。准备改变车道的车辆向该车道最近的后行车辆发布其想要改变车道的通知。再次，双方都知道并且准备操纵。

并入和退让

特设连网的最有兴趣的潜在应用之一是在高速公路上的进路坡道和终止车道上的车道的并入和退让的管理。如图22所说明，退让和并入车辆都知道彼此的位置和速度，其为它们各自的驾驶舱电子信息系统提供辅助驾驶员平稳地调节到新情况的输入。

智能交通信号通知/公路信息系统

上面讨论的是Wi-Fi支持同时发生的特设连网和基于基础设施的通信的功能。而智能交通灯是路边基础设施的一部分，它们需要使用为特设连网分配的信道以便有效，因为只有这些信道被车辆有规律地监视。使用Wi-Fi，智能交通灯可以例如：

·对接近的车辆发送“黄灯”通知

·警告在以高速的横向方向到达的交通中的车辆27

·识别闯红灯的车辆²⁸

另一方面，公路信息系统(电子标志、自动收费等)不应该在特设信道上运行(除非其可以被确定即使在最拥挤的驾驶条件下基本带宽有剩余)。车辆可以如驾驶员输入功能发起和终止地监视这些基础设施信道。

²⁷如果接近的车辆没有配备Wi-Fi，但是交通灯可以通过雷达检测到它们。

²⁸交通灯请求来自闯过灯的车辆的注册。请求可以被在ATP层认证为来自被授权的客户端。如果是事实，则这将产生可能完全消除问题的威慑。

参考文献

[1]J.D.Case，M.Fedor，M.L.Schoffstall，和C.Davin，“Simple Network Management Protocol(SNMP)(简单网络管理协议)(SNMP)”，RFC 1157，SNMP研究，计算机科学的性能系统国际和MIT实验室，1990年5月

[2]信息处理系统-开放系统互连，“Specification of AbstractSyntax Notation One(ASN.1)(抽象语法符号一(ASN.1)规范”，标准化国际组织，国际标准8824，1987年12月

[3]信息处理系统-开放系统互连，“Specification of BasicEncoding Rules for Abstract Notation One(ASN.1)(用于抽象符号一(ASN.1)的基本编码规则规范)”，国际

[4]A.O.Freier，P.Karlton，P.C.Koche，“The SSL Protocol，Version 3.0(SSL协议第3版)”，互联网草案，Netscape通信，1996年3月

[5]互联网工程工作组，Perkins，C.(ed.)，“IPv6 MobilitySupport(IPv6移动性支持)”，1995年3月。

[6]Narten，T.，Nordmark，E.，和W.Simpson，“NeighborDiscovery for IP Version 6(IPv6)(对于IP版本6(IPv6)的邻居发现)”，RFC 1970，1996年8月

[7]Deering，S.和Hinden，R.，“Internet Protocol，Version6(IPv6)Specification(互联网协议版本6(IPv6)规范)”，RFC1883，1995年12月

[8]Conta，A.和Deering，S.，“Internet Control MessageProtocol(ICMPv6)forthe Internet Protocol Version 6(IPv6)Specification(用于互联网协议版本6(IPv6)的互联网控制消息协议(ICMPv6)”，RFC 1885，1995年12月

Claims

1.一种将车辆运行数据从车辆传递到远程监视接收者的方法，包括步骤：

-建立车辆和远程监视接收者之间的数据链路；

-采集来自车辆里数据源的车辆运行数据；

-利用源自SNMP的协议将车辆运行数据封装在数据分组中；以及

-在数据链路上传递数据分组。

2.一种将车辆运行数据从车辆服务器传递到远程监视客户端的方法，包括步骤：

-建立车辆和远程监视客户端之间的数据链路；

-采集来自车辆服务器里数据源的车辆运行数据；

-将数据封装在具有协议数据单元有效负荷的协议数据单元中，有效负荷包括多个可变绑定域，每个可变绑定域有两个字节的对象识别符域、一个字节的值类型域以及大小根据值类型域的可变绑定域值；以及

-在数据链路上传递协议数据单元。

3.一种采集来自车辆的车辆运行数据用于以最小化对后来发送的带宽需求的方式后来发送到远程监视接收者的方法，包括步骤：

-提供车辆车内计算设备；

-提供多个数据获取模块，每个测量车辆的一个或多个运行特征，运行特征对应于一组被管理对象的当前值；

-将车辆车内计算设备与每个数据获取模块接口；

-配置车辆车内计算设备以便：

a)形成诊断信息库用于为每个被管理对象接收和存储来自每个对应数据获取模块的值；

b)基于在诊断信息库中包含的信息组合事件报告；以及

c)根据SNMP得出的协议将事件报告封装在协议数据单元中。

4.如权利要求3所述的方法，其中运行特征包括GPS位置、引擎速度、道路速度、或者引擎温度、或者与车辆发射有关的OBD-II参数。

5.如权利要求4所述的方法，其中OBD-II参数包括不点火检测。

6.如权利要求3所述的方法，还包括使得车辆车内计算设备能够执行下列动作的步骤：

a)建立与远程监视接收者的数据链路；以及

b)在数据链路上传递协议数据单元。

7.如权利要求6所述的方法，还包括使得远程监视接收者能够发布GET协议数据单元以便检索来自车辆车内计算设备的一组特定的被管理对象的当前值的步骤。

8.如权利要求7所述的方法，还包括使得远程监视接收者能够等待由车辆车内计算设备对GET协议数据单元的确认的步骤。

9.如权利要求6所述的方法，还包括使得车辆车内计算设备能够发布TRAP协议数据单元以便报告车辆事件的步骤。

10.如权利要求9所述的方法，还包括使得车辆车内计算设备能够执行如下动作的步骤：

a)存储对每个车辆事件的阈值或报告间隔；以及

b)当阈值已经被超过时或者在相应的报告间隔，发布每个TRAP协议数据单元。

11.如权利要求10所述的方法，其中TRAP协议数据单元报告GPS位置。

12.如权利要求6所述的方法，还包括发布来自车辆的INFORM协议数据单元以便报告例外的车辆事件的步骤。

13.如权利要求12所述的方法，还包括使得车辆车内计算设备能够执行如下动作的步骤：

a)在诊断信息库中存储多个特定例外车辆事件的任何一个，包括一个或多个管理例外、维护例外或运行例外；以及

b)当规定的事件的任何一个发生时，发布INFORM协议数据单元。

14.如权利要求13所述的方法，其中INFORM协议数据单元被作为管理阈值等级被超过的结果而发送。

15.如权利要求13所述的方法，还包括使得车辆车内计算设备能够等待远程监视接收者对以前的INFORM协议数据单元已经被在数据库中记入日志的确认的步骤。

16.如权利要求15所述的方法，还包括在没有远程监视接收者对以前的INFORM协议数据单元已经被在数据库中记入日志的确认的情况下重新发送INFORM协议数据单元的步骤。

17.如权利要求6所述的方法，还包括使得远程监视接收者能够向车辆车内计算设备发布SET协议数据单元以便设置一个或多个被管理对象的步骤。

18.如权利要求6所述的方法，其中数据链路是无线的并且包括在IEEE 802.11标准下的无线电频带、卫星RF分组网或陆地RF分组网。

19.如权利要求6所述的方法，其中协议数据单元是REQUEST协议数据单元，所述协议数据单元排除SNMP协议的错误状态和错误索引域。

20.如权利要求6所述的方法，其中协议数据单元排除SNMP协议的每个可变绑定的长度域。

21.一种将来自车辆的车辆运行数据传递到远程监视接收者的方法，包括步骤：

-建立车辆和远程监视接收者之间的数据链路；

-采集来自车辆里数据源的车辆运行数据；

-利用由SNMP得出的协议将车辆运行数据封装在数据分组中；以及

-在数据链路上传递数据分组，协议数据单元被远程监视接收者响应一个请求而发布并且包含请求和请求中被请求的值并且被封装在一个单独的消息中并且在一个单独的未分段的网络分组中。

22.一种采集来自车辆的车辆运行数据用于以最小化对后来发送的带宽需求的方式后来发送到远程监视接收者的方法，包括步骤：

-提供车辆车内计算设备；

-将车辆车内计算设备与每个数据获取模块接口；

-配置车辆车内计算设备以便：

a)形成诊断信息库用于为被管理对象接收和存储来自每个数据获取模块的值；

b)基于在诊断信息库中包含的信息组合事件报告；以及

c)将事件报告封装到协议数据单元中，该协议数据单元包括具有多个可变绑定域的协议数据单元有效负荷，每个可变绑定域有两个字节的对象识别符域、一个字节的值类型域以及大小根据值类型域的可变绑定值。

23.如权利要求22所述的方法，其中协议数据单元包括具有对应于一组值之一的值的PDU类型数据元素的头部，所述组包括GET值、SET值、TRAP值、INFORM值和RESPONSE值。

24.一种用于将来自车辆的车辆运行数据传递到远程监视接收者的计算机实现的系统，包括：

-与车辆里多个车辆运行数据源通信的车辆车内计算设备；

-能够利用由SNMP得出的协议将车辆运行数据封装在数据分组中，用于在无线数据链路上发送到远程监视接收者的车辆车内计算设备。

25.一种用于将来自车辆的车辆运行数据采集和传递到远程监视接收者的计算机可读数据结构，包括：

-用于存储诊断信息库的存储模块，诊断信息库包括用于多个车辆运行参数的多个被管理对象和用于每个被管理对象的多个值；以及

-用于在无线数据链路上在由SNMP得出的协议下将协议数据单元传递到远程监视接收者的通信模块。

26.在计算机可读介质中被编码的计算机程序产品，包括多个计算机可执行步骤，用于车内计算机将来自车辆的车辆运行数据采集和传递到远程监视接收者，包括：

-接收来自车辆里多个数据源的车辆运行数据；

-在诊断信息库中存储用于多个车辆运行参数的每个的多个被管理对象以及对于每个被管理对象的多个值；

-建立计算机和远程监视接收者之间的无线数据链路；

-在无线数据链路上在由SNMP得出的协议下向远程监视接收者传递多个协议数据单元。

27.一种在载体介质上传播的信号，所述信号包括一个根据源自SNMP的协议封装的协议数据单元，该协议数据单元包含编码机动车辆的预定运行数据的有效负荷。

28.如权利要求27所述的信号，有效负荷包括多个可变绑定域，每个可变绑定域有两个字节的对象识别符域、一个字节的值类型域以及大小根据值类型域数据单元的可变绑定值。

29.如权利要求27所述的信号，其中有效负荷包括GPS位置段、GPS方向段、车辆速度段或OBDII车辆发射段。

30.一种用于将来自车辆的车辆运行数据传递到远程监视接收者的系统，包括：

-与车辆里多个车辆运行数据源装置通信的车辆车内计算装置；

-能够利用由SNMP得出的协议将车辆运行数据封装在数据分组里用于在无线数据链路上发送到远程监视接收者的车辆车内计算装置。

31.一种将来自车辆的车辆运行数据传递到远程监视接收者的方法，包括：

-用于建立车辆和远程监视接收者之间的数据链路的步骤；

-用于从车辆中的数据源采集车辆运行数据的步骤；

-用于利用由SNMP得出的协议将车辆运行数据封装在数据分组中的步骤；以及

-在数据链路上传递数据分组的步骤。

32.一种用于在多个车辆之间交换数据的通信网，包括相应车辆车内的计算单元，其中给定车辆里的计算单元可操作来广播识别消息并且接收来自相邻区域中的其他车辆的等价识别消息，其中所述消息被用于识别网络中相邻的车辆，以便与其中的选定的车辆交换数据。

33.如权利要求32所述的网络，其中计算单元可操作来更新相邻车辆的列表并且其中所述GPS信息中的固有误差通过整个网络是不变的，因此邻域布局可以被根据相对位置而不是绝对位置而建立。

34.如权利要求33所述的网络，其中计算单元随着从进入区域的新车辆接收身份消息而向列表中加入新的邻居车辆。

35.如权利要求34所述的网络，其中当在预定时间周期之后没有从给定的邻居车辆接收到身份消息时，计算单元从列表中删除所述给定的邻居车辆。

36.如权利要求35所述的网络，其中当从给定的邻居车辆接收的身份消息指示该邻居车辆正在离开或者已经离开相邻区域时，计算单元从邻居数据库中删除所述给定的邻居车辆。

37.如权利要求33所述的网络，其中通信介质是高频信道化RF频段并且每个所述计算单元对其的使用被根据IEEE 802.11介质访问控制(MAC)协议而控制。

38.如权利要求33所述的网络，其中所述计算单元是互联网可寻址的。

39.如权利要求33所定义的网络，其中所述计算单元是IPv6可寻址的。

40.如权利要求33所述的网络，其中所述计算单元利用由SNMP得出的协议交换数据。

41.如权利要求33所述的网络，其中身份消息包括GPS信息和发送者的IEEE 802.11MAC地址。

42.如权利要求40所述的网络，其中GPS信息包括纬度、经度、速度和方向信息。

43.如权利要求42所述的网络，其中邻域中的所有车辆在足够允许任何给定的车辆认识所有其邻居的发现时间周期里广播其身份消息。

44.如权利要求43所述的网络，其中用于发送至少一些消息的信道选择是基于GPS方向。

45.如权利要求44所述的网络，其中发现周期的长度和区域的地理大小可以与邻域里车辆的平均速度成比例地被调整。

46.如权利要求43所述的网络，其中每个所述计算单元还包括能够在SNMP协议下发送和接收消息的发送机和接收机。

47.一种如权利要求32所述的车辆。

48.一种包括速度段、方向段和位置段的数据结构。

49.如权利要求48所述的数据结构，其中位置段包括经度部分和纬度部分。

50.一种在载体介质上传播的信号，所述信号包括速度段、方向段和位置段。

51.如权利要求50所述的信号，其中位置段包括经度部分和纬度部分。

52.一种包括车内计算单元的车辆，该车内计算单元可操作来接收来自相邻域中的其他车辆的消息，用于组合邻域列表，以便与在其中所列的车辆中选定的车辆交换数据。

53.一种用于操作机动车内可编程计算机系统的计算机程序产品，包含一个计算机可读介质，该介质包括从相邻区域中其他车辆接收消息以及组合邻域列表用于与其中所列的车辆中选定的车辆交换数据的计算机可执行步骤。

54.一种包含车内通用计算机和扩频无线电单元的机动车，所述扩频无线电单元可操作来建立与至少另一个相邻车辆里的无线电单元的数据链路，其中所述计算机可操作来记录来自相邻区域中至少另一个车辆的消息用于组合邻域列表，以及从在数据链路上接收的数据来识别至少一个车辆事件。

55.一种用于采集和传递来自车辆车内计算设备和远程监视接收者的车辆运行数据的计算机可读数据结构，包括：

-一个模块，用于索引一系列协议值以及用于车辆车内计算设备和远程监视接收者之间的数据交换的对应请求和响应；

-用于为车辆的多个运行特征索引一系列被管理对象的模块；

-用于为每个被管理对象记录值的模块。

56.如权利要求55所述的数据结构，还包括用于为每个远程监视接收者索引身份的模块。

57.如权利要求56所述的数据结构，还包括用于为每个远程监视接收者索引一个或多个被管理对象的列表的模块。