CN1846375A

CN1846375A - 道路车间通信系统

Info

Publication number: CN1846375A
Application number: CNA2004800252613A
Authority: CN
Inventors: 伊川雅彦; 后藤幸夫; 熊泽宏之; 津田喜秋
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2003-10-15
Filing date: 2004-10-01
Publication date: 2006-10-11
Anticipated expiration: 2024-10-01
Also published as: CN1846375B; KR100733196B1; WO2005039075A1; JP4396639B2; JP4697490B2; JP2009077422A; KR20060095868A; JPWO2005039075A1; US7843869B2; US20060193282A1

Abstract

本发明的目的在于：在利用在道路上行驶的移动站、设置在道路上的基站装置之间进行的道路车间通信，向上述移动站提供应用服务的道路车间通信系统中，提供一种具备即使在行驶中也能够执行各种应用程序的机制的非网络型通信协议。本发明的道路车间通信系统包括：提供用于多个应用程序间的数据转送的机制的转送服务处理部件；具有未送达数据的再发送机构、信息单位的数据发送接收机构、信息的分割·组合机构，并且提供单方向的数据发送和请求·响应型的事务服务的事务管理部件。

Description

道路车间通信系统

技术领域

本发明涉及利用在道路上行驶的移动站、设置在道路上的基站装置之间进行的道路车间通信，向上述移动站提供对应的服务的道路车间通信系统。

背景技术

作为现有的道路车间通信系统的一个例子，已知由社团法人电波产业会确定的标准规格“狭域通信(DSRC)系统标准规格ARIBSTD-T75”(平成13年9月6日定稿)。该标准规格确定了基于限定了通信地域(zone)的点通信的道路车间通信方式，通过对每个应用程序使用被称为AID的标识符来与多应用程序(multi-application)对应。

但是，在上述现有技术中，经常是基站为主机(master)，移动站为从机(slave)，只能实现主机·从机型的应用程序，无法适用于从移动站侧发起通信、或移动站和基站对等地进行通信那样的应用程序。另外，由于该被称为AID的标识符只规定了32个，所以有难以与应用程序种类增多了的情况对应的问题。进而，难以用于以下的应用程序：一次能够发送接收的数据大小小到数百字节左右，而需要进行数十千字节(kilobyte：kbyte)以上的大容量的数据通信。

作为用于解决这些问题的方法的一个例子，通过在上述标准规格(狭域通信(DSRC)系统标准规格ARIB STD-T75)上，配置作为能够双方向地进行通信的协议的扩展通信控制协议(ASL-ELCP)，并且基站定期地对来自移动站的通信的有无进行轮询(polling)，来实现从移动站的通信。进而，通过在上述扩展通信控制协议(ASL-ELCP)中定义被称为接入点(access point)标识符的标识符，使得能够在由上述标准规格(狭域通信(DSRC)系统标准规格ARIB STD-T75)和上述扩展通信控制协议(ASL-ELCP)组成的层次上进行多个协议的动作，并作为该多个协议的一个而利用因特网协议，从而实现对多应用程序的对应。另外，通过具有被称为大容量(bulk)传送的分割·组合机构，而最大能够进行50kbyte左右的信息的发送接收。进而，在同文电报通信中，通过多次连续发送同一数据来实现将通信的错误率抑制为很小(例如参考非专利文献1)。

非专利文献1：信息处理学会ITS研究会“DSRC(ARIB STD-T75标准)系统的安装和评价”(2002-ITS-10-10)

但是，在上述现有技术中，为了实现多应用程序，而在上述扩展通信控制协议(ASL-ELCP)上利用作为网络型协议的因特网协议，因此由于IP地址的分配和TCP的设置所需要的时间等与初始连接有关的消耗的问题，而有难以适用于行驶中的应用程序的问题。另外，根据同样的问题，依然难以适用于在行驶中发送的数据大小超过100kbyte那样的应用程序。进而在上述大容量传送功能中，由于只简单地分割数据，所以分割数据的再送依存于作为下位层的DSRC，有无法对应由于DSRC通信以外的理由而丢失的数据的问题。另外，在因屏蔽(shadowing)或电波减弱等而规定时间不能通信的区域中，有可能丢失再送的每个数据或连续发送的全部数据，因此有无法改善错误率的问题。

发明内容

本发明就是为了解决这样的问题点而提出的，在利用在道路上行驶和停止的移动站、设置在上述道路上的基站装置之间进行的道路车间通信而向上述移动站提供应用服务的道路车间通信系统中，提供一种为了即使在行驶中也能够执行各种应用程序，而具备用于多个应用程序间的数据转送的机制(mechanism)、超过100kbyte那样的大容量的数据发送接收的机制、在一定时间无法通信的情况下也能够改善通信错误率的机制的的非网络型通信协议。

本发明的道路车间通信系统是利用在道路上行驶的移动站、设置在上述道路上的基站装置之间进行的道路车间通信而向上述移动站提供应用服务的道路车间通信系统，具备：提供用于多个应用程序间的数据转送的机制的转送服务处理部件；具有未送达数据的再发送机构、信息单位的数据发送接收机构、信息的分割·组合机构，并且提供单方向的数据发送和请求·响应型的事务服务的事务(transaction)管理部件。

本发明的道路车间通信系统是基站装置和移动站内的双方的局域应用程序利用非网络型协议进行通信的系统，由于由转送服务处理部件和事务管理部件构成上述非网络型协议，所以能够在行驶中执行各种应用程序。另外，在一定时间无法通信的情况下，也能够改善通信错误率。

另外，由于各自独立地构成转送服务处理部件和事务管理部件，所以能够在单纯的应用程序中直接使用转送服务处理部件而实现，能够满足高速连接性、低消耗那样的行驶中的道路车间通信所需要的条件。进而，在扩展协议时，能够在事务管理部件中对扩展的地方进行局域化，能够容易地进行扩展。

在转送服务部件中，为了识别发送接收双方的应用程序而利用端口编号。由此，能够实现多个应用程序间的数据转送。另外，该端口编号有65536种，能够充分对应今后的应用程序种类的增多。

在事务管理部件中，根据从应用程序指定的标识符(发送数据标识符)来识别发送数据的单位。另外，该协议具有以下功能：在发送数据单位比通过下位层的协议一次能够发送的大小还大的情况下，将其分割为能够发送的大小，并且赋予顺序编号而发送，在接收侧根据该顺序编号进行组合。这时，在个别通信的情况下，通过在接收最终数据时向发送侧通知未接收的数据的顺序编号，从而发送侧只再发送未接收的数据。由此，改善通信错误率。

另外，在个别通信、同文电报通信的情况下，在发送方的应用程序标识符(发送方端口编号)和该应用程序指定的发送数据标识符的组是一样的情况下，在接收侧作为与已经接收的同一标识符的数据一样的数据进行处理。由此，发送侧能够以任意的定时进行数据的再发送，在一定时间无法通信的情况下，也能够改善通信错误率。

附图说明

图1是表示本发明的实施例1的道路车间通信系统的连接(connection)识别的概念的图。

图2是表示局域端口编号的分类的图。

图3是表示数据报(data gram)传送服务的例子的图。

图4是表示原语(primitive)种类的图。

图5是表示参数种类的图。

图6是表示数据转送服务的逻辑关系的图。

图7是表示转送原语的定义的图。

图8是表示管理服务接口的逻辑关系的图。

图9是表示事件通知原语的定义的图。

图10是表示端口生成原语的定义的图。

图11是表示端口废弃原语的定义的图。

图12是表示能够接收端口列表的结构例子的图。

图13是表示通信控制信息的结构例子的图。

图14是表示数据转送信息的形式的图。

图15是表示LPCP的协议标识符的图。

图16是表示事件通知的信息的形式的图。

图17是表示事件代码(eventCode)的内容的图。

图18是表示LPCP的初始连接步骤的一个例子的图。

图19是表示LPCP的通信结束步骤的一个例子的图。

图20是表示LPCP的信息转送步骤的图。

图21是表示没有连接DSRC的情况下的处理步骤的图。

图22是表示发送目标端口编号不是有效的情况下的信息转送步骤的图。

图23是表示LPP的概念的图。

图24是表示LPP的事务间数据交换例子的图。

图25是表示数据发送服务的例子的图。

图26是表示请求、响应型事务服务的例子的图。

图27是表示数据再送的例子的图。

图28是表示重复接收检查的例子的图。

图29是表示信息的分割、组合处理的例子的图。

图30是表示选择性再送处理的例子的图。

图31是表示最终分组的再送处理的例子的图。

图32是表示事务的再执行的例子的图。

图33是表示事务废弃通知的例子的图。

图34是表示原语种类的图。

图35是表示参数种类的图。

图36是表示Invoke原语的参数的图。

图37是表示Abort原语的参数的图。

图38是表示在Abort Type＝0的情况下(系统错误)的AbortCode一览的图。

图39是表示Connect原语的参数的图。

图40是表示Disconnect原语的参数的图。

图41是表示RegisterPort原语的参数的图。

图42是表示DeregisterPort原语的参数的图。

图43是表示PDU种类一览的图。

图44是表示局域端口协议的协议数据单元基本结构的图。

图45是表示Invoke PDU的报头(head)信息的图。

图46是表示Result PDU的报头信息的图。

图47是表示Acknowledgement的PDU的报头信息的图。

图48是表示Abort PDU的报头信息的图。

图49是表示Invoke Segment PDU的报头信息的图，

图50是表示Result Segment PDU的报头信息的图，

图51是表示Nack PDU的报头信息的图。

图52是表示能够接收端口列表通知中的协议数据单元的图。

图53是表示不能发送端口列表通知中的协议数据单元的图。

图54是表示局域端口协议的初始连接步骤的图。

图55是表示高速连接应用程序的初始连接时序例子的图。

图56是表示数据发送事务服务的处理时序例子的图。

图57是表示请求、响应型事务服务的基本处理时序例子的图。

图58是表示在Result计时器(timer)到时(timeout)了的情况下的处理时序例子的图。

图59是表示在再送处理有效的情况下的数据转送步骤(基本时序)的图。

图60是表示再送处理步骤(再送成功时)的图。

图61是表示再送处理步骤(再送失败时)的图。

图62是表示在分割、组合处理有效的情况下的时序例子的图。

图63是表示在分割、组合处理有效的情况下的时序例子(选择性再送处理)的图。

图64是表示在分割、组合处理有效的情况下的时序例子(最终段(segment)未送达时的情况)的图。

图65是表示DSRC切断时的步骤的图。

图66是表示事务废弃步骤的图。

具体实施方式

实施例1

图1是表示本发明的实施例1的道路车间通信系统的连接识别的概念的图。另外，图3是表示本发明的实施例1的道路车间通信系统的数据的流程的概要的图。使用图1、图3说明基站装置和移动站的基本结构。

在基站装置和移动站中使用的通信协议具有由狭域通信(DSRC)协议(ARIB STD-T75)、作为能够双方向进行通信的协议的扩展通信控制协议(ASL-ELCP)、转送服务处理部件(局域端口控制协议(LPCP：Local Port Control Protocol))事务管理部件(局域端口协议(LPP：Local Port Protocol))组成的层次结构，在该通信协议上执行多个应用程序。

转送服务处理部件是用于在狭域通信(DSRC)协议(ARIB STD-T75)和扩展通信控制协议(ASL-ELCP)上实现应用程序的多重化的控制协议，具有用于实现多应用程序的最小限的功能。

另一方面，事务管理部件处于上述转送服务处理部件和应用程序之间，是对转送服务处理部件的通信协议进行扩展的通信协议，通过大容量数据通信等而向应用程序提供高度的通信服务。

以下，详细说明该转送服务处理部件和事务管理部件。

1.转送服务处理部件(局域端口控制协议)

1.1概要

以下，详细说明转送服务处理部件(局域端口控制协议)。局域端口控制协议(LPCP)是为了向非网络系统的应用程序提供通信手段，而向应用程序等上位协议提供用于数据转送的数据转送服务、用于管理控制的管理服务的控制协议。

在转送服务处理部件中，使用被称为局域端口编号的标识符，识别发送方和发送目标的应用程序。另外，向作为上位层的应用程序和事务管理部件等上位层协议提供用于数据转送和管理服务的服务原语(接口)。进而，通过作为内部数据具有用于实现数据转送服务和管理服务的控制信息，同时向在道路车辆的转送服务处理部件之间交换的数据(PDU)附加控制信息，来实现各种服务。

1.2局域端口编号

1.2.1接入点识别

为了从作为发送方的应用程序向对方的应用程序正确地发送数据，而在局域端口控制协议(LPCP)中，如图1所示，作为用于识别LPCP上的应用程序的接入点而设置局域端口编号，并以车辆ID(连接地址等)和局域端口编号的组，来针对各个应用程序识别与对方的连接。

1.2.2局域端口编号的分类

图2是表示局域端口编号的分类的例子的图。局域端口编号被作为非网络系统应用程序的连接标识符而使用，如下这样规定局域端口编号。将0～0×0FFF设置为编号预约端口，将0×1000～0×FFFF设置为任意端口。通过这样地规定端口编号，能够规定65536种的端口编号，也能够充分地对应今后的应用程序种类的增多。

1.2.3应用程序和局域端口编号的关系

说明应用程序和在前节中规定的局域端口编号的关系。

应用程序的形式是以客户端/服务器模型和对等(Peer-to-Peer)模型为前提的。因此，在客户端/服务器模型中，基本上是广域唯一的服务器处理的端口利用编号预约端口，在站内是唯一的客户端处理的端口利用任意端口。在对等模型中，基本上是双方的处理利用编号预约端口。在独自应用程序的情况下，也可以在服务器、客户端中同时使用任意端口。

1.2.4局域端口编号的编号设置

依照以下的规则，进行局域端口编号的编号设置。

(1)对于预约编号，在全局上进行不重复的编号。

(2)应用程序可以具有多个接收端口。

(3)以基站、移动站为单位，各应用程序使用接收端口编号使得在站内没有重复。

(4)在不需要确定发送方的情况或发送方是已知的情况下，可以省略发送方端口。

1.3LPCP的功能

接着，详细说明LPCP的功能。

1.3.1数据转送功能数据报(data gram)传送服务

图3是表示数据报传送服务的例子的图。DSRC-ASL中的局域端口系统应用程序的结构为在LPCP上存在多个应用程序的层次结构，LPCP必须进行数据的转送目标应用程序的识别。

因此，在LPCP中赋予发送方和发送目标端口编号，由此决定数据的转送目标。

另外，LPCP所提供的通信服务是高速、低消耗的少连接(connection less)型的数据报传送服务，LPCP与应用程序(上位层协议)之间的具体动作如下。

1：应用程序(上位层协议)依存于LPCP地新作成接收数据的接收端口，

2：通过该接收端口，从LPCP接收车辆ID(连接地址等)、发送方端口编号和接收数据，

3：应用程序(上位层协议)向LPCP发送发送数据、连接地址和发送接收端口编号，LPCP根据该信息生成LPCP数据报并发送到对方。

1.3.2管理服务

在管理服务处理中，向应用程序或上位层协议提供以下的服务。

·透过性地向本站的应用程序通知由ASL-ELCP(扩展通信控制协议)的管理服务通知的错误或事件(通信的连接、非连接的通知等)的服务。

·向对方站或本站的应用程序通知在LPCP内产生的错误或事件的服务。

LPCP和应用程序(或上位层协议)之间的具体动作如下。

1.应用程序(或上位层协议)依存于LPCP地新作成接收事件的端口，

2.通过该端口，从LPCP接收连接地址、状态标识符、事件附加信息。

1.4与应用程序的接口

接着，说明LPCP和应用程序的接口。

1.4.1标记的说明

图4表示在本发明中规定的原语(primitive)种类的一览，图5表示在原语的定义表中使用的参数种类的一览。

1.4.2数据转送服务接口

图6表示数据转送服务的逻辑关系。

作为数据转送服务，局域端口控制协议针对应用程序(或上位层协议)规定以下的一种原语。

1.4.2.1转送原语(TransferData)

本原语是用于在DSRC-ASL的ELCP和非IP应用程序或上位层协议之间进行数据转送的原语。图7表示转送原语的定义。在图7中，

Link Address：在本发送中使用的DSRC的LID或能够与LID一对一地映射的ID

Source Port：发送方应用程序的端口编号

Destination Port：发送目标应用程序的端口编号

User Data：传送数据本身

User Data Size：传送数据大小

1.4.3管理服务接口

图8表示管理服务接口的逻辑关系。作为管理服务，局域端口控制协议针对应用程序(或上位层协议)规定以下的3种原语。

·Event Report(事件通知原语)

·Open Port(端口生成原语)

·Close Port(端口废弃原语)

1.4.3.1事件通知原语(Event Report)

本原语是用于向非IP应用程序或上位层协议报告事件的产生或错误的原语。有以下的2种：透过性地向局域端口协议转送在ASL-ELCP的管理服务中通知的事件的原语；透过性地转送来自对方站的管理服务的通知的原语。图9表示事件通知原语的定义。在图9中，

Link Address：指定通知对方所(正在)使用的LID。

Event Code：作为事件代码而存储状态标识符(图17)。

Extention Parameter：与各事件代码对应的事件附加信息。

1.4.3.2端口生成原语(Open port)

本原语是用于针对LPCP生成数据和事件的接收端口的原语。图10表示端口生成原语的定义。在图10中，

Port：请求通知的端口编号

Type：需要进行通知的原语种类的指定

1：TransferData

2：Event Report

在省略了该参数的情况下，请求全部的原语通知。

Code：是在Type＝2(Event Report)的情况下需要进行通知的事件的种类

在省略了该参数的情况下，请求全部的事件的通知。

参照图17说明事件种类的详细。

1.4.3.3端口废弃原语(Close Port)

本原语是用于废弃在端口生成原语中生成了的接收端口的原语。

图11是表示端口废弃原语的定义的图。在图11中，

Port：废弃的端口编号

1.5控制信息

1.5.1概要

接着，说明在上述管理服务中使用的LPCP的控制信息。

在LPCP的管理服务中，对在LPCP中使用的通信参数进行管理。

在LPCP的管理服务中，管理以下的信息。

(1)能够接收端口列表

(2)通信控制信息

1.5.2.1能够接收端口列表

是基站/移动站能够接收的端口编号的信息，在接收端口生成原语接收时向列表中追加，在接收端口废弃原语接收时从列表中删除。

图12表示能够接收端口列表的结构例子。

1.5.2.2通信控制信息

是与在基站/移动站中正在通信的应用程序有关的信息，在来自ASL-ELCP的通信控制管理的DSRC连接通知的接收时向列表追加，在DSRC切断通知的接收时从列表中删除。图13表示通信控制信息的结构例子。

名词解说：

LID：连接地址

Port No：能够接收端口编号

Primitive Type：接收的原语种类

Event Code：接收的事件代码的种类

Equipment ID：车载器固有信息

1.6协议数据单元(PDU)

接着，说明在数据报传送服务和管理服务中使用的LPCP的协议数据单元(PDU)。

LPCP的PDU由局域端口控制协议报头和应用程序数据部分构成。

1.6.1数据报传送服务的协议数据单元

图14表示在数据报传送服务中使用的LPCP的PDU的形式。

接入点标识符：用于识别网络控制协议的标识符。始终存储localPort Control(1)。

协议标识符：表示PDU种类。在数据报传送服务中，存储message(0)。详细参考图15。

发送方端口编号：发送方应用程序的端口编号

发送目标端口编号：发送目标应用程序的端口编号

用户数据部分的长度：指示后续的用户数据部分的数据长度。单位是八比特位组(octet)。另外，该区域的大小依照ASN.1编码规则而扩展。在没有附加的用户数据(NULL)的情况下，在该区域中指定0。另外，LPCP能够传送给ASL-ELCP的数据的最大长度、LPCP的MTU(Maximum Transmission Unit)为522八比特位组(包含访问控制信息)。

用户数据部分的内容：传送数据自身。存储OCTET STRING型的不定长数据。

图15是表示LPCP的协议标识符的图。

1.6.2管理服务的协议数据单元

图16表示在管理服务中使用的LPCP的PDU的形式。以下所示的PDU在向对方站的LPCP进行事件通知时使用。

图16是表示事件通知的信息的形式的图。

访问点标识符：用于识别网络控制协议的标识符。始终存储localPort Control(1)。

协议标识符：表示PDU种类。在管理服务中，始终存储eventReport(1)。

事件代码：指示产生了的事件内容的标识符。0～127是通信控制协议的状态标识符，128～255是LPCP的状态标识符。图17是表示事件代码(event Code)的内容的图。

事件附加信息的长度：指示后续的事件附加信息的数据长度。单位是八比特位组。另外，该区域的大小依照ASN.1编码规则进行扩展。在没有附加的事件信息(NULL)的情况下，在该区域中指定0。

事件附加信息的内容：事件附加信息的内容。存储OCTETSTRING型的不定长数据。

1.7处理步骤

说明LPCP的处理步骤。

1.7.1初始连接步骤

(a)应用程序预先通过端口生成原语，向LPCP请求DSRC连接通知。

(b)根据车辆进入DSRC覆盖区域，而通过ASL-CLCP的管理服务事件通知原语(Event Information.ind)接收“通信连接的通知”状态。

(c)在端口生成原语中，向被请求了DSRC连接通知的端口，通过事件通知原语(Event Report.ind)通知事件代码“DSRC连接通知(96)”。

图18表示DSRC连接时的处理时序例子。

1.7.2通信结束步骤

(a)应用程序预先通过端口生成原语，向LPCP请求DSRC切断通知。

(b)通过ASL-ELCP的管理服务事件通知原语(EventInformation.ind)接收“通信切断的通知”状态。

(c)向LPP的连接管理服务，通过事件通知原语(EventReport.ind)通知事件代码“DSRC切断通知”。

图19表示通信结束时的处理时序。

1.7.3信息转送步骤

(1)发送处理

(a)发出数据转送请求原语(TransferData.req)。

(b)参照通信控制信息，在指定了的Link Address是专用连接地址(private link address)，并且该连接地址没有连接DSRC的情况下，向由数据转送请求原语指定的发送方端口编号，发出状态标识符是“没有连接DSRC(128)”的事件通知原语，完成发送处理。但是，在该步骤中，在通过局域端口生成原语进行了事件通知的请求的情况下，即已经进行了事件通知的请求的情况下，不向上位协议进行事件通知。根据能够接收局域端口列表来判别有无事件通知。

(c)在连接了DSRC的情况下，生成接入点标识符是local PortProtocol(1)、协议标识符是message(0)的分组，通过ASL-ELCP的数据转送原语(Send Unit Data.req)进行发送，完成发送处理。

(d)在发送处理完成后，在从接收到数据转送信息的对方站接收到事件通知信息的情况下，确认通过该信息传送的事件代码，在事件代码的内容是“发送目标局域端口不是有效的”的情况下，向在该信息的事件附加信息中指定的发送方局域端口编号，通过事件通知原语(EventReport.ind)通知“发送目标局域端口不是有效的”。但是，在该步骤中，在通过局域端口生成原语进行了事件通知的请求的情况下，即已经进行了事件通知的请求的情况下，不向上位协议进行事件通知。根据能够接收局域端口列表来判别有无事件通知。

(2)接收处理

(a)应用程序通过端口生成原语向LPCP进行转送通知的请求，打开(open)接收端口。

(b)如果通过数据转送通知原语(Send Unit Data.ind)，从ASL-ELCP接收到协议标识符是message(0)的分组，则取出协议标识符、发送目标局域端口编号、发送方局域端口编号、用户数据。

(c)参照能够接收端口列表，在(b)中接收到的发送目标端口编号是有效的情况下，向由发送目标端口编号指定的上位实体，通过数据转送原语(TransferData.ind)通知来自对方站的数据的接收，完成接收处理。

(d)在连接地址是专用地址，并且在(b)中接收到的发送目标端口编号不是有效的情况下，作成协议标识符为event Report(1)、状态标识符为“发送目标端口不是有效的(129)”的分组，通过ASL-ELCP的数据转送原语发送到对方站，完成接收处理。即，在从对方站接收信息时在本站中不存在发送目标应用程序的情况下，立即向对方站通知该情况。另外，在连接地址是组同文电报地址，并且在(b)中接收到的发送目标端口编号不是有效的情况下，废弃接收数据，完成接收处理。

图20表示信息转送的基本处理时序的例子，图21表示没有连接DSRC的情况下的处理时序例子，图22表示在发送目标局域端口编号不是有效的情况下的处理时序的例子。

2.事务(transaction)管理部件(局域端口协议)

以下，详细说明事务管理部件(局域端口协议)。

2.1概要

局域端口协议(LPP：Local Port Protocol)是具有以下目的的面向事务的协议：位于局域端口控制协议(LPCP)和非网络系统应用程序之间，对局域端口控制协议的功能进行扩展，向DSRC车载器/路侧机上的非网络系统应用程序提供以下的事务服务和连接管理服务，由此谋求应用程序构筑的高效化(参照图23)。本协议包括：对局域端口控制协议的通信功能进行扩展的事务服务处理部件；管理初始连接或切断等通信状况的连接管理服务处理部件。各服务处理部件所具有的功能如下。

事务服务处理部件

·事务单位的数据交换功能

·单方向数据发送事务服务

·请求、响应型事务服务

·数据再送功能

·信息的分割、组合功能

·事务的废弃功能

·连接管理服务处理部件

·DSRC连接查询服务

·DSRC切断通知服务

·能够接收端口查询服务

另外，事务管理部件向应用程序提供用于利用上述功能的服务原语(与应用程序的接口)。进而，为了实现上述功能，规定了在道路车的事务管理部件之间交换的数据(PDU)的构造。在事务管理部件中，通过附加与发送侧通过服务原语请求了的功能(或在事务管理部件内部产生的事件)对应的控制信息，同时在接收侧对附加在PDU中的控制信息进行分析、利用，来实现上述功能。

2.2LPP的功能

接着，分别详细说明上述LPP的各服务处理部件的功能。

2.2.1事务服务处理

2.2.1.1事务单位的数据交换功能

在局域端口协议中，以事务为单位交换应用程序数据。

根据事务ID，区别各个事务(参照图24)。由此，能够对应在相同的应用程序之间同时存在多个事务的状况。

图24是表示LPP的事务间数据交换例子的图。

另外，事务ID的编号方式如下。

(1)16比特结构

(2)先头比特表示事务的开始侧(车载侧为0，道路侧为1)。

(3)每次发行事务(Invoke.req)都加1。

2.2.1.22种事务服务提供功能

本协议提供以下的2种事务服务。

·单方向数据发送事务服务

·请求、响应型事务服务

对于这些各事务服务，与应用程序各自的通信条件对应地，使用必要等级的服务，能够利用对每个应用程序最优的通信服务。

2.2.1.2.1基本事务

(1)数据发送服务

向道路车双方的非网络系统应用程序提供数据发送服务(参照图25)。图25是表示数据发送服务的例子的图。

(2)请求、响应型事务服务

向对方通知信息，同时取得对该信息的返回值。在对远程的方法调用等的用途中利用(参照图26)。

图26是表示请求、响应型事务服务的例子的图。

2.2.1.2.2数据再送功能

本功能是用于确保通信的可靠性的功能，通过再送定时器和再送计数器进行再送的控制。通过在再送定时器的到时(timeout)时进行再送(小于等于最大再送次数)，来确保通信的可靠性(参照图27)。可以适用于数据的发送和回送，由应用程序指定是否适用。以下表示处理时序。

图27是表示数据再送的例子的图。

·分组发送时，使再送定时器开始，将再送计数器复位为0。

·在再送定时器的到时之前没能接收到响应数据的情况下，将再送计数器加1，并再送分组。

·在再送计数器超过最大再送次数的情况下，结束事务，向应用程序通知该情况。

另外，在使用数据再送功能的事务中，根据送达确认的未送达等的理由，能够再次接收以前接收过的PDU。使用事务ID来检测该重复接收(参照图28)。具体的检查方法是安装条件，在此不特别规定。

图28是表示重复接收检查的例子的图。

2.2.1.2.3信息分割、组合功能

本功能是通过进行信息的分割、组合处理，能够向应用程序提供超过LPCP的MTU的信息的发送接口的功能。

图29是表示利用了分割、组合功能的信息通信的步骤的图。LPP在从应用程序接收到超过LPCP的MTU的信息的情况下，进行操作在LPP内将PDU分割为LPCP的MTU的大小，并顺序地发送到LPCP。由此，分割了的分组被积蓄在DSRC-ASL的发送队列中，顺序地转送到层7。这时，由于设想DSRC-ASL的发送队列溢出(overflow)，所以通过在LLP中再送发送失败了的分组、进行流程控制，来保证发送所有的分组。

接收侧顺序地取得从LPCP发送的分割了的分组，并积蓄在接收侧的应用程序所准备的接收队列中。这时，根据层2的再送处理等的因素，并不保证以发送顺序将各分组存储在接收队列中，接收侧根据附加在各分组中的顺序编号来判别组合顺序，组合为PDU。在接收侧，在接收了全部分组后，向发送侧回送到达确认。

另外，设想由于在DSRC-ASL中的接收队列溢出或在DSRC中的数据丢失等，发生了分组的丢失，不保证发送了的全部分组都到达了对方站的LPP。在该情况下，由于一个分组的丢失就是信息全体的数据的丢失，所以在接收最终分组时，通过否定应答来通知无法接收到的分组，通过进行丢失了的分组的再送(选择性再送处理)，来保证信息全体的送达。对于最终分组的丢失，通过通常的再送处理来保证送达。另外，对通过选择性再送而发送的分组群，也进行同样的控制。图30表示选择性再送处理的例子。

另外，由于设想了每个应用程序所必需的接收队列的大小有很大的不同，所以在本功能中，由应用程序准备接收队列。因此，根据每个发送目标(连接地址和发送目标端口编号)，同时只能产生一个需要进行分割、组合的事务。

另外，在对同文电报地址的数据发送的情况下，不进行达到确认的回送、选择性再送处理和最终段的再送控制，而通过事务的再执行请求，来确保必要的通信的可靠性。图32表示事务的再执行处理的例子。

2.2.1.3事务的废弃功能

在请求、响应型的事务中，通过从应用程序的请求，能够请求事务的废弃(参照图33)。与请求时的事务的状态对应地，实施以下的处理。

·在没有发送信息的情况下，废弃该信息。

·在已经发送了信息或正在发送的情况下，废弃与该事务相关联的全部数据，向对方侧通知废弃了该事务的情况。

·在根据对方侧的事务废弃请求，接收到事务的废弃请求的情况下，向应用程序通知事务废弃，同时废弃与该事务相关联的全部数据。

图33是表示事务废弃通知的例子的图。

另外，在以下的情况下，即

·DSRC通信路径被切断。

·发送目的地端口不是能够接收端口。

为了抑制无用的通信，不开始事务，向应用程序通知请求失败。

2.2.2连接管理服务处理

在连接管理服务中，通过向应用程序提供以下的服务，来向应用程序提供通信开始、结束的触发(trigger)。

·管理、监视DSRC的连接状况，与来自应用程序的请求对应地，通知连接状况的报告和新连接、切断的服务。

·通过在道路车间的连接管理服务之间相互通知能够接收端口编号，来管理对方站所具有的能够接收端口编号，与来自应用程序的请求对应地，报告这些状况，或通知某端口能够进行接收的服务。

另外，连接管理服务位于与局域端口控制协议上的应用程序同样的位置，道路车的路径管理服务间的事件的发送接收利用局域端口控制协议的数据转送服务。连接管理服务所利用的端口编号当前为0×0FFFF。

2.2.2.1DSRC连接查询服务

查询是否连接有DSRC的功能。

规定了以下的2种服务：在查询时立即回答DSRC的连接状况的参照服务；在没有连接的情况下，等待连接，在连接上的时刻进行通知的通知服务。

2.2.2.2DSRC切断通知服务

向请求切断通知的应用程序通知DSRC的切断的功能。

2.2.2.3能够接收端口查询服务

查询是否存在对方站中的接收端口的功能。端口的状态有以下3种。

·能够接收端口：作为数据接收端口，对方站已经打开了该端口。

·不能接收端口：对方站没有作为数据接收端口打开该端口。

·不明端口：不知道对方站是否作为数据接收端口打开了该端口的端口。初始状态就是该状态。

另外，在能够接收端口查询服务中，规定了以下的2种服务：在查询时立即回答该端口处于哪种状态的参照服务；等待所查询的端口成为能够接收端口，在接收到来自对方站的能够接收端口通知的时刻进行通知的通知服务(在已经判断出所查询的端口是能够接收端口的情况下，立即进行回答)。

由于能够进行上述服务，所以道路车间的局域端口协议的管理服务具有以下的功能：在DSRC通信连接时和能够接收端口变更时，本站向对方站通知能够接收的端口编号和不能接收的端口编号。

2.3与应用程序的接口

接着，说明LPP和应用程序的接口。

2.3.1标记的说明

图34表示在本发明中规定的原语种类的一览。

另外，图35表示在本发明中的原语的定义表中使用的参数种类的一览。

2.3.2事务服务原语

作为事务服务，LPP针对应用程序准备以下的2种原语。

·Invoke：(事务开始原语)

·Abort：(事务废弃原语)

2.3.2.1Invoke(事务开始原语)

处理概要：

Invoke原语是用于生成新的事务的原语。全部的事务都通过发出该原语来开始。

定义：

图36是表示Invoke原语的参数的图。

LinkAddress：DSRC的LID或能够与LID一对一映射的ID

Source Port：发送方应用程序的端口编号

Destination Port：发送目标应用程序的端口编号

User Data Size：发送数据大小(八比特位组单位)

User Data：发送数据自身

Transaction Type：事务服务的类型

0：数据发送事务服务

1：请求、响应型事务服务

Require Ack：是否使再送处理有效的标志(0：不要再送处理，1：需要再送处理)

Result Timeout：在请求、响应型事务服务中到接收Result PDU为止的到时时间。在发出Invoke.req后，如果到该时间为止没有接收到Result PDU，则废弃该事务。

Handle：用于在局域区别事务的ID。从应用程序指定。在此指定的Handle必须满足以下的条件。在Invoke.req的发出侧，根据事务ID，必须能够唯一地确定Handle和Source Port。在Invoke.res的发出侧，根据Handle，必须能够唯一地确定LinkAddress、Source Port、事务ID。另外，在同文电报通信中，在指定了与之前的已经执行的同文电报通信一样的Handle的情况下，作为事务再执行请求来处理。

2.3.2.2Abort(事务废弃原语)

处理概要：

Abort原语是用于废弃已经生成了的事务的原语。

定义：

图37是表示Abort原语的参数的图。

AbortType：表示废弃理由是系统错误(0)、还是用户请求(1)。

Abort Code：表示废弃事务的理由(系统错误的详细参照图38)。

Handle：用于在局域区别事务的ID。

图38是表示Abort Type＝0(系统错误)的情况下的Abort Code一览的图。

2.3.3连接管理服务

作为连接管理服务，LPP针对应用程序准备以下的4种原语。

·Connect：(事务能够开始查询/通知原语)

·Disconnect：(DSRC切断通知原语)

·Register Port(端口登记原语)

·Deregister Port(端口登记删除原语)

2.3.3.1Connect(事务能够开始查询/通知原语)

处理概要：

Connect.req原语是用于查询是否能够开始事务的原语。Connect.cnf原语是用于针对Connect.req的查询，向查询方的应用程序通知DSRC的连接和LID以及(该LID所指示的)对方站具有的能够接收端口编号的原语。

定义：

图39是表示Connect原语的参数的图。

Querist Port：为了根据查询方的Port编号来确定进行了查询的应用程序而使用。

Query LID：进行查询的ID。在指定LID时，作为对已经连接上的连接的查询来处理。另一方面，在没有指定的情况下，作为新连接等待来处理。在与QureyPort一起省略时，在DSRC连接后马上发出Connect.cnf(高速连接)。另一方面，在指定了QueryPort的情况下，在接收到能够接收端口通知后，发出Connect.cnf(通常连接)。

Query Port：进行查询的发送目的地端口编号。

Time Out：在未连接DSRC时，到发出Connect.cnf为止的等待时间。在等待中连接上的情况下，立即发出Connect.cnf。在省略该参数时，作为到时时间＝∞进行处理。

Connected LID：在指定了Query LID并且正在与该LID连接的情况下，指定与QueryLID一样的LID。在指定了Query LID并且未连接该LID的情况下，以及在未指定Query LID并且在由TimeOut参数指定的时间内没有新的连接的情况下，指定-1。

Accept Port：由Connected LID表示的对方站所具有的能够接收端口编号。

在通过Query Port进行了指定的情况下，只通知该端口编号。另外，在指定了的Port编号是拒绝接收端口编号的情况下，指定-1。另外，在省略了Query Port的情况下，指定0。

2.3.3.2Disconnect(DSRC切断通知原语)

处理概要：

是用于向应用程序通知DSRC的切断的原语。

定义：

图40是表示Disconnect原语的参数的图。

2.3.3.3Register Port(端口登记原语)

处理概要：

Register Port原语是用于向LPP登记接收端口的原语。

定义：

图41是表示Register Port原语的参数的图。

Port No：接收端口编号

Bulk Area：对分割了的信息进行组合的区域

Bulk Area Size：Bulk Area的大小

2.3.3.4Deregister Port(端口登记删除原语)

处理概要：

Deregister Port原语是用于对LPP删除接收端口的原语。

定义：图42是表示Deregister Port原语的参数的图。

Port No：删除登记的接收端口编号

2.4协议数据单元(PDU)

接着，说明在事务服务和连接管理服务中使用的LPP的协议数据单元(PDU)。

2.4.1事务服务的协议数据单元

在事务服务中使用的协议数据单元与其利用情况对应地存在图43所示的7种。在事务服务中使用的PDU由对每种PDU定义的报头部分和存储有应用程序数据的数据部分构成。图44表示PDU的基本构造。

2.4.1.1Invoke PDU

图45是表示PDU的报头信息的图。

PDU Type：PDU的类型。在Invoke PDU中始终为Invoke(1)。

Version：表示局域端口协议的版本。当前的版本是0x00。

TT：Transaction Type的简称。指定事务的类型。0：数据发送事务服务，1：请求、响应型事务服务。

RA：Require Ack的简称。是表示再送处理是否有效的标志。在再送处理有效时为1。

RD：Retrasmitted Data的简称。是表示是否是再送的数据的标志。在再送时为1。

TID：事务ID。

RES：预约。

2.4.1.2Result PDU

图46是表示PDU的报头信息的图。

PDU Type：PDU的类型。在Result PDU中始终为Result(2)。

RD：是表示是否是再送的数据的标志。再送时为1。

TID：事务ID。

RES：预约。

2.4.1.3Acknowledgement PDU

图47是表示Acknowledgement PDU的报头信息的图。

PDU Type：PDU的类型。在Acknowledgement PDU中始终为Ack(3)。

RD：是表示是否是再送的数据的标志。在再送时为1。

TID：事务ID。

RES：预约。

2.4.1.4Abort PDU

图48是表示Abort PDU的报头信息的图。

PDU Type：PDU的类型。在Abort PDU中始终为Abort(4)。

AT：表示废弃理由是系统错误(0)、还是用户请求(1)的哪个的标志。

TID：事务ID。

Abort Code：作为代码而指定事务的废弃理由(参照图38)。

RES：预约。

2.4.1.5InvokeSegment PDU

图49是表示Invoke Segment PDU的报头信息的图。

PDU Type：PDU的类型。在Invoke Segment PDU中始终为Invoke Sgm(5)。

Version：表示局域端口协议的版本。现在版本是0x00。

FIN：表示是否是最终段的标志。最终段为1。

RD：Retransmitted Data的简称。表示是否是再送的数据的标志。在再送时为1。

TID：事务ID。

Segment No：PDU的顺序编号。

2.4.1.6Result Segment PDU

图50是表示Result Segment PDU的报头信息的图。

PDU Type：PDU的类型。在Result Segment PDU中始终为ResultSgm(6)。

FIN：表示是否是最终段的标志。最终段为1。

RD：表示是否是再送的数据的标志。在再送时为1。

TID：事务ID。

RES：预约。

Segment No：PDU的顺序编号。

2.4.1.7Nack PDU

图51是表示Nack PDU的报头信息的图。

PDU Type：PDU的类型。在Nack PDU中始终为Nack(7)。

RD：表示是否是再送的数据的标志。在再送时为1。

TID：事务ID。

RES：预约。

Num Seg：未接收的PDU的顺序编号的个数。

Segment Number List：未接收的PDU的顺序编号的列表

2.4.2连接管理服务的协议数据单元

局域端口协议的连接管理服务在DSRC的新连接时、能够接收端口增减了的情况下，利用局域端口控制协议的转送服务，向对方站的连接管理服务通知能够接收端口列表或不能接收端口。以下所示的PDU是在这些通知中使用的协议数据单元，被存储在局域端口控制协议的用户数据部分中。

2.4.2.1能够接收端口列表通知中的协议数据单元

图52是表示能够接收端口列表通知中的协议数据单元的图。

Status：表示事件的种类。在能够接收端口列表通知的情况下，始终存储accept Port List(1)。

Num Ports：存储能够接收端口编号。

Accept Port List：存储能够接收端口编号的列表。

2.4.2.2不能接收端口通知中的协议数据单元

图53是表示不能发送端口通知中的协议数据单元的图。

Status：表示事件的种类。在不能接收端口通知的情况下，始终存储rejectPort(2)。

Reject Port：存储不能接收端口编号。

2.5处理步骤

说明LPP的处理步骤。

2.5.1初始连接步骤

(1)通常应用程序的初始连接步骤

图54是表示局域端口协议的初始连接步骤的图。

(a)移动站和基站的各应用程序使用端口登记原语(RegisterPort)向LPP登记能够接收的端口编号。

(b)LPP更新连接管理表，并作为数据接收端口将在上述(a)中登记了的能够接收端口编号和连接管理服务端口登记到LPCP中。另外，还作为事件接收端口向LPCP登记管理服务端口。

(c)各应用程序不指定Query LID参数，指定Query Port参数，发出DSRC连接查询原语(Connect.req)，等待DSRC连接(模块调用)。

(d)LPP的连接管理服务从LPCP通过事件通知原语(EventReport)接收“DSRC连接通知(96)”事件。

(e)LPP的连接管理服务作成由该原语接收到的LID的连接管理表，同时向对方站的连接管理服务端口发送能够接收端口列表。

(f)LPP的连接管理服务如果通过数据转送原语(Send UnitData.ind)从LPCP接收到能够接收端口列表，则向通过该原语通知了的LID的连接管理表中登记能够接收端口。以后，只针对该能够接收端口，接受对该LID的事务开始请求。

(g)针对在上述(e)中接收到的能够接收端口列表中所包含的端口编号，向发出了DSRC连接查询原语(Connect.req)的应用程序，通过DSRC连接通知原语(Connect.cnf)通知LID和能够发送端口编号。

(h)通过向应用程序通过DSRC连接通知原语(Connect.cnf)通知的LID或同文电报地址和发送目标端口编号发出事务开始请求原语(Invoke.req)，来开始事务。

(2)高速连接应用程序的初始连接步骤

高速连接是指通过省略一部分的用于初始连接的处理来实现高速的初始连接的方法。图55是表示高速连接应用程序的初始连接时序例子的图。

(a)移动站和基站的各应用程序使用端口登记原语(RegisterPort)，向LPP登记能够接收的端口编号。

(b)LPP更新连接管理表，向LPCP登记能够接收端口编号。

(c)各应用程序不指定Query LID以及Query Port，发出事务开始可能查询原语(Connect.req)，等待DSRC连接。

(d)从LPCP通过事件通知原语(EventReport.ind)接收“DSRC连接通知(96)”事件。

(e)LPP作成通过该原语接收到的LID的连接管理表。由于是需要进行高速连接的应用程序，所以以后到接收到对方站侧的能够接收端口列表为止，从对方站的LPP连接管理服务接受对该LID和同文电报地址的全部端口的事务的开始请求。

(f)通过DSRC连接通知原语(Connect.cnf)，向发出了DSRC连接查询原语(Connect.req)的应用程序通知LID。

(g)各应用程序发出对由DSRC连接通知原语通知了的LID或同文电报地址的事务开始请求原语(Invoke.req)，开始事务。

(h)在对方站中存在在上述(g)中指定了的端口编号的情况下，该事务成功。在对方站中不存在在上述(g)中指定了的端口编号的情况下，通过事件通知原语，从对方站的LPCP通知“发送目标局域端口不是有效的(129)”事件，更新该LID的连接管理表。在TransactionType＝1的情况下，通过事务废弃通知原语(Abort.ind)向对应的应用程序通知事务的失败。此后，针对该LID和端口的组，在有了Transaction Type＝1的事务开始请求(Invoke.req)的情况下，通过事务废弃原语(Abort.ind)通知事务的废弃。

2.5.2数据发送事务服务的数据转送步骤

(1)发送处理

(a)通过应用程序以Transaction Type＝0而发出事务开始请求原语(Invoke.req)，来开始数据发送服务的事务。

(b)在指定了的LID和发送方端口编号的组是拒绝接收端口的情况下，通过Abort.ind向应用程序通知“拒绝接收端口通知”事件，该事务结束。

(c)在指定的信息超过了MTU，并且不支持分割、组合处理的情况下，通过Abort.ind向应用程序通知“MTU错误”状态，该事务结束。将在2.5.5节中说明支持分割、组合处理的情况下的处理。

(d)在上述(b)和上述(c)以外的情况下，作成TT＝0的Invoke PDU，使用LPCP的转送原语(TransferData.req)发送到对方站。另外，将在2.5.4节中说明再送处理有效的情况下的处理。

(2)接收处理

(a)如果通过LPCP的转送原语(TransferData.ind)接收到在上述(1)-(d)中发送的Invoke PDU，则使用事务通知原语(Invoke.ind)，向应用程序通知接收数据。

图56表示数据发送事务服务的数据转送步骤的处理时序例子。

2.5.3请求、响应型事务服务的数据转送步骤

(1)发送处理

(a)通过应用程序以Transaction Type＝1而发出事务开始请求原语(Invoke.req)，来开始请求、响应型事务服务的事务。

(b)在指定了的LID和发送方端口编号的组是拒绝接收端口的情况下，通过Abort.ind向应用程序通知“拒绝接收端口通知”状态，该事务结束。

(c)在超过了能够同时执行的事务数的情况下，通过Abort.ind向应用程序通知“事务无法开始”状态，该事务结束。

(d)在指定了的信息超过了MTU，并且不支持分割、组合处理的情况下，通过Abort.ind向应用程序通知“MTU错误”状态，该事务结束。将在2.5.5节中说明支持分割、组合处理的情况下的处理。

(e)在上述(b)、上述(c)和上述(d)以外的情况下，作成TT＝1的Invoke PDU，使用LPCP的转送原语(TransferData.req)发送到对方站后，启动Result计时器(通过Invoke.req来指定Result计时器的到时值)，等待从对方站接收Result PDU。

(f)如果在上述(e)中启动了的Result计时器到时，则生成AT＝0、Abort Code＝0x08的Abort PDU，向对方站通知“Result计时器到时”状态，同时通过事务废弃通知原语(Abort.ind)向应用程序通知事务的失败。

(g)如果在Result计时器的到时之前，通过LPCP的转送原语(TransferData.ind)，接收到从对方站发送的Result PDU，则停止在上述(e)中启动了的Result计时器，同时通过应答通知原语(Invoke.cnf)向应用程序通知应答数据。

(2)接收处理

(a)如果通过LPCP的转送原语(TransferData.ind)接收到从对方站发送的Invoke PDU，则使用事务通知原语(Invoke.ind)，向应用程序通知接收数据，等待从应用程序的应答原语(Invoke.res)的接收。

(b)在通过LPCP的转送原语(TransferData.ind)接收到从对方站发送的Abort PDU的情况下，发出事务废弃通知原语(Abort.ind)向应用程序通知事务的失败，该事务结束。

(c)应用程序发出应答原语(Invoke.res)，向LPP请求应答的发送。

(d)生成Result PDU，通过LPCP的转送原语(TransferData.req)，向对方站发送。

图57表示请求、响应型事务服务的基本处理时序例子，图58表示在Result计时器到时了的情况下的处理时序例子。

2.5.4再送处理有效的情况下的数据转送步骤

再送处理适用于在Invoke.req和Invoke.res中指定了Require Ack＝1的情况。以下，说明在数据发送事务的Invoke.req中适用了再送处理的情况下的时序。在请求、响应型事务服务中，也可以对Invoke.res适用同样的处理。

(1)发送处理

(a)通过应用程序以Require Ack＝1而发出事务开始请求原语(Invoke.req)，来开始再送处理有效的数据转送服务。

(b)作成RA＝1的Invoke PDU，使用LPCP的转送原语(TransferData.req)向对方站发送后，启动再送计时器，等待从对方站接收Acknowledgement PDU。

(c)根据在上述(b)中发送的Invoke PDU没有到达等的任意的理由，在接收Acknowledgement PDU之前在上述(b)中启动了的再送计时器到时了的情况下，将在上述(b)中发送了的Invoke PDU的RD标志设置为1，在再发送到对方站后，再启动再送计时器，并将再送计数器加1。

(d)在若干次地循环进行再送后，再送计数器超过了最大再送次数的情况下，生成AT＝0、Abort Code＝0x07的Abort PDU(参照2.4.1.4节)，向对方站通知“再送计时器到时”状态，同时通过事务废弃通知原语(Abort.ind)向应用程序通知事务的失败，结束该事务。

(e)在再送计时器的到时之前，通过LPCP的转送原语(TransferData.ind)接收到从对方站发送的Acknowledgement PDU，则停止在上述(b)或上述(c)中启动了的再送计时器，结束该事务。

(2)接收处理

(a)如果通过LPCP的转送原语(TransferData.ind)接收到Invoke PDU，使用事务通知原语(Invoke.ind)向应用程序通知接收数据。

(b)在上述(a)中接收到的PDU的RA标志是有效的情况下，生成Acknowledgement PDU，通过LPCP的转送原语(TransferData.req)，向对方站发送Acknowledgement PDU，并启动等待计时器。

(c)根据在上述(b)中发送的Acknowledgement PDU没有到达等的理由，在再接收到在上述(a)中接收到的Invoke PDU的情况下，废弃该PDU，再次生成Acknowledgement PDU，通过LPCP的转送原语(TransferData.req)向对方站发送，并再启动等待计时器。

(d)如果在上述(b)或上述(c)中启动了的等待计时器到时，则结束该事务。

图59表示再送处理有效的情况下的处理时序例子，图60表示再送成功了的情况下的处理时序例子，图61表示再送处理失败了的情况下的处理时序例子。

2.5.5分割、组合处理有效的情况下的信息转送步骤

分割、组合处理适用于在Invoke.req和invoke.res中指定了超过MTU的信息的情况。以下，说明在Invoke.req中适用分割、组合处理的情况的时序。

(1)发送步骤

(a)通过应用程序指定比MTU大的大小的信息，并发出事务开始请求原语(Invoke.req)，而开始分割、组合处理有效的数据发送服务的事务。

(b)在指定的LID和发送方端口编号的组是拒绝接收端口的情况下，通过Abort.ind向应用程序通知“拒绝接收端口通知”状态。

(c)在针对指定的LID和发送方端口编号的组，已经执行了需要进行分割、组合处理的事务的情况下，通过Abort.ind向应用程序通知“正在分割转送”状态。

(d)在上述(b)和上述(c)以外的情况下，从先头开始顺序地用MTU分割发送数据，向每个分割了的段附加依据Invoke SegmentPDU(参照2.4.1.5节)的规定的报头，使用LPCP的转送原语(TransferData.req)，顺序进行发送请求。

(e)如果ASL的发送队列溢出，从LPCP通过Event Report.ind通知了“发送队列不空，发送失败”状态，则等待一定时间，包含发送失败了的数据地再次开始发送。

(f)在发送了最后的段数据后，启动再送计时器，等待从对方站接收Acknowledgement PDU(参照2.4.1.3节)或Nack PDU(参照2.4.1.7节)。

(g)如果通过LPCP的转送原语(TransferData.ind)，接收到从对方站发送的Nack PDU，则再送在Nack PDU的Segment NumberList中指定的段。这时，将再送的全部段的RD标志设置为1，将最后再送的段的FIN标志设置为1。在再发送了全部段后，启动再送计时器，等待从对方站接收Acknowledgement PDU(参照2.4.1.3节)或Nack PDU。

(h)在上述(f)或上述(g)中启动了的再送计时器到时了的情况下，再次发送最终段，再启动再送计时器。

(i)如果通过LPCP的转送原语(TransferData.ind)接收到从对方站发送的Acknowledgement PDU，则停止在上述(f)、上述(g)或上述(h)中启动了的再送计时器，结束该事务。

(2)接收步骤

(a)应用程序通过端口登记原语(Register Port)，指定接收数据组合缓存器区域。

(b)如果通过LPCP的转送原语(TransferData.ind)接收到Invoke Segment PDU，则顺序地存储到从应用程序指定了的接收队列中。

(c)如果接收到最终段数据，则确认是否没有未接收的段，在存在未接收的段的情况下，作成Nack PDU(参照2.4.1.7节)，使用LPCP的转送原语(TransferData.req)向对方站发送，并存储以后应该接收的最终段编号。

(d)在上述(c)中发送了Nack PDU后，在因到达顺序的更换等的理由，接收到没有设置RD标志的数据的情况下，废弃该数据。

(e)在接收到最终段数据时，如果接收到全部的段数据，则使用事务通知原语(Invoke.ind)向应用程序通知接收数据，同时生成Acknowledgement PDU，通过LPCP的转送原语(TransferData.req)向对方站发送。

图62表示分割、组合处理有效的情况下的基本处理时序例子，图63表示分割数据的一部分丢失而进行选择性再送处理的情况下的处理时序例子，图64表示最终段数据丢失而进行再送处理的情况下的处理时序例子。

2.5.6通信结束步骤

(a)从LPCP通过事件通知原语(EventReport.ind)接收到“DSRC切断通知(98)”事件。

(b)向正在使用该LID的应用程序发出DSRC切断通知原语(Disconnect.ind)。

(c)LPP删除通过该原语接收到的LID的连接管理表。以后，不接受对该LID的事务开始请求。

图65是表示DSRC切断时的步骤的图。

2.5.7事务的废弃步骤

在局域端口协议中，在事务处于以下的状态时，可以从应用程序请求事务的废弃。

图66是表示事务废弃步骤的图。

发送侧

·在请求、响应型事务中接收到Invoke.req后，从接收ResultPDU，到发出Invoke.cnf为止的之间。

接收侧

·在请求、响应型事务中发出Invoke.ind后，从接收Invoke.res，到发送Result PDU为止的之间。

以下说明处理时序。

(a)通过从应用程序接收事务废弃请求原语(Abort.req)来开始该时序。

(b)LPP生成对由该原语指定的事务的Abort PDU，使用LPCP的转送原语(TransferData.req)，向对方站发送。

(c)向请求方的应用程序发出事务废弃通知原语(Abort.ind)，通知事务的废弃完成。

(d)如果LPP通过LPCP的转送原语(TransferData.ind)接收到Abort PDU，则在本站内通过该PDU的TID指定的事务正在执行的情况下，在全部废弃了与该事务有关的资源后，向应用程序发出事务废弃通知原语(Abort.ind)，通知事务废弃。

另外，在上述实施例中，表示了由狭域通信(DSRC)协议(ARIBSTD-T75)、作为能够双方向进行通信的协议的扩展通信控制协议(ASL-ELCP)、转送服务处理部件(LPCP)、事务管理部件(LPP)组成的层次结构，但也可以使用其他的能够双方向进行通信的协议来代替扩展通信控制协议(ASL-ELCP)。

如上所示，本发明的道路车间通信系统是道路侧系统和移动站内的双方的局域应用程序利用非网络型的协议进行通信的系统，其特征在于：通过以下部分构成上述非网络型的协议，即：用于实现多应用程序(multi-application)的转送服务处理部件；具有未送达数据的再送机构、信息单位的数据发送接收机构、信息的分割、组合机构，并提供单方向的数据发送和请求、响应型的事务服务的进行事务服务的事务管理部件。

另外，在本发明的道路车间通信系统中，为了识别发送接收双方的应用程序而利用端口编号，由此在非网络型的协议中，也能够同时执行多个应用程序。

另外，通过直接使用转送服务处理部件，能够实现最简单的应用程序，能够满足高速连接性、低消耗那样的正在行驶的道路车间通信所必需的条件。

另外，在停止或正在低速行驶等时，通过使用事务管理部件，能够容易地对应需要大容量数据的发送接收和请求、响应性服务那样的高度的服务的应用程序。

另外，在扩展协议时，通过在事务管理部件中将扩展的地方局部化，能够容易地进行扩展。

进而，根据从应用程序指定的标识符(发送数据标识符)来识别发送数据的单位。另外，该协议具有以下功能：在发送数据单位比在下位层的协议中一次能够发送的大小还大的情况下，将其分割为能够发送的大小，并附加顺序编号进行发送，在接收侧根据该顺序编号进行组合。

这时，通过在接收最终数据时向发送侧通知未接收的数据的顺序编号，只再发送未接收的数据，来改善通信错误率。

另外，在发送方的应用程序标识符(发送方端口编号)和该应用程序指定的发送数据标识符的组是一样的情况下，通过在接收侧作为与已经接收的同一标识符的数据一样的数据进行处理，能够在任意的定时再发送数据。因此，在一定时间无法进行通信的情况下，也能够改善通信错误率。

Claims

1.一种道路车间通信系统，利用在道路上行驶的移动站、设置在上述道路上的基站装置之间进行的道路车间通信而向上述移动站提供应用服务，其特征在于包括：

提供用于多个应用程序间的数据转送的机制的转送服务处理部件；

具有未送达数据的再发送机构、信息单位的数据发送接收机构、上述信息的分割·组合机构，并且提供单方向的数据发送和请求·响应型的事务服务的事务管理部件。

2.根据权利要求1记载的道路车间通信系统，其特征在于：

转送服务处理部件在识别多个应用程序时利用端口编号。

3.根据权利要求2记载的道路车间通信系统，其特征在于：

在识别应用程序的端口编号中，使用在广域中是唯一的预约端口、在局域中是唯一的任意端口。

4.根据权利要求1记载的道路车间通信系统，其特征在于：

转送服务处理部件向应用程序通知无线通信的确立状态。

5.根据权利要求3记载的道路车间通信系统，其特征在于：

转送服务处理部件在初始连接时向对方站通知用于识别本站具有的应用程序的端口编号。

6.根据权利要求5记载的道路车间通信系统，其特征在于：

转送服务处理部件和事务管理部件可以省略初始连接步骤。

7.根据权利要求2记载的道路车间通信系统，其特征在于：

转送服务处理部件在从对方站接收信息时在本站中不存在发送目标应用程序的情况下，立即向对方站进行通知。

8.根据权利要求1记载的道路车间通信系统，其特征在于：

事务管理部件为了识别事务的单位而使用从应用程序指定的标识符。

9.根据权利要求8记载的道路车间通信系统，其特征在于：

事务管理部件根据分配给事务的标识符，来进行事务的重复确认。

10.根据权利要求8记载的道路车间通信系统，其特征在于：

事务管理部件根据分配给事务的标识符，来进行事务的废弃。

11.根据权利要求8记载的道路车间通信系统，其特征在于：

事务管理部件将信息分割为多个数据，对分割了的各数据附加用于识别事务的标识符和顺序编号，在接收侧根据顺序编号来组合上述标识符一样的各数据并判别顺序，而组合为原来的信息。

12.根据权利要求11记载的道路车间通信系统，其特征在于：

事务管理部件在分割发送时，根据下位层的发送队列的状态，控制发送间隔。

13.根据权利要求11记载的道路车间通信系统，其特征在于：

事务管理部件在接收分割了的信息的最终数据时，向发送侧通知未接收的数据的顺序编号，发送侧只再发送上述未接收的数据。

14.根据权利要求8记载的道路车间通信系统，其特征在于：

事务管理部件在识别事务的单位的标识符与已经接收的数据是一样的情况下，作为与已经接收的相同标识符的数据一样的数据进行处理。

15.根据权利要求11记载的道路车间通信系统，其特征在于：

16.根据权利要求11记载的道路车间通信系统，其特征在于：

事务管理部件从应用程序指定进行信息的组合的区域。