Between-load-and-vehicle communication system

The present invention uses road-to-vehicle communication performed between a mobile station traveling on a road and a base station device installed on the road to provide an applied service to the mobile station. It's about the system.<u style="single">It also relates to a base station device and a mobile station device used in such a road-to-vehicle communication system.</u>

As an example of the conventional road-to-vehicle communication system, the standard "Narrow Area Communication (DSRC) System Standard ARIB STD-T75" (established on September 6, 2001) established by the Association of Radio Industries and Businesses is known. ing. This standard defines a road-to-vehicle communication method by spot communication that limits the communication zone, and supports multiple applications by using an identifier called AID for each application. However, in the above-mentioned prior art, the base station is always the master and the mobile station is the slave, and only a master-slave type application can be realized. Communication can be started from the mobile station side, or the mobile station and the base station communicate on an equal footing. It could not be applied to such applications. In addition, since only 32 identifiers called AIDs can be specified, there is also a problem that it is difficult to deal with an increase in the types of applications. Furthermore, the data size that can be sent and received at one time is as small as several hundred bytes, and it is difficult to use it for applications that require large-capacity data communication of several tens of kilobytes or more.

As an example of a method for solving these problems, the extended communication control protocol (ASL-), which is a protocol capable of bidirectional communication on the standard (Dedicated Short Range Communication (DSRC) system standard ARIB STD-T75), is used. ELCP) is placed, and the base station periodically polls for the presence or absence of communication from the mobile station to realize communication from the mobile station. Further, an identifier called an access point identifier is defined in the extended communication control protocol (ASL-ELCP), and the standard (Narrow Area Communication (DSRC) system standard ARIB STD-T75) and the extended communication control protocol (ASL-) are defined. It enables the operation of multiple protocols on the hierarchy consisting of ELCP), and by using the Internet Protocol as one of these multiple protocols, it is possible to support multiple applications. In addition, by having a division / assembly mechanism called bulk transfer, it is possible to send and receive messages of up to about 50 kilobytes. Further, in the broadcast communication, the same data is continuously transmitted a plurality of times to reduce the communication error rate (see, for example, Non-Patent Document 1).

<nplcit num="1"><text>Information Processing Society of Japan ITS Study Group "DSRC (ARIB STD-T75 compliant) System Implementation and Evaluation" (2002-ITS-10-10)</text></nplcit>

<p> However, in the prior art, in order to realize multi-application, IP address allocation and TCP setup are used in order to use the Internet Protocol, which is a network-type protocol, on the extended communication control protocol (ASL-ELCP). There is a problem that it is difficult to apply it to a running application due to an overhead problem related to the initial connection such as the time required for the operation. Also, due to similar problems, it was still difficult to apply to applications where the data size transmitted while driving exceeds 100 kilobytes. Furthermore, since the bulk transfer function simply divides the data, the retransmission of the divided data depends on the DSRC, which is a lower layer, and there is a problem in dealing with the missing data for reasons other than DSRC communication. .. In addition, in areas where communication is not possible for a predetermined time, such as shadowing or weak radio waves, there is a possibility that individual retransmitted data or continuously transmitted data may be lost, so there is a problem that the error rate cannot be improved. ..</p><p> The present invention has been made to solve such a problem, and utilizes road-to-vehicle communication performed between a mobile station that travels and stops on a road and a base station device installed on the road. In the road-to-vehicle communication system that provides application services to the mobile station, in order to enable various applications to be executed even while driving, a mechanism for data transfer between a plurality of applications and a mechanism for exceeding 100 kilobytes. It provides a non-network type communication protocol having a mechanism for transmitting a large amount of data and a mechanism capable of improving the communication error rate even when communication cannot be performed for a certain period of time.</p>

<p>The road-to-vehicle communication system according to the present invention is a road-to-vehicle communication system performed between a mobile station traveling on a road and a base station device installed on the road.<u style="single">Narrow area</u>In a road-to-vehicle communication system that provides applied services to the mobile station using communication<u style="single">The mobile station and the base station device, respectively,</u>A transfer service processing unit that provides a mechanism for data transfer between a plurality of applications, a retransmit mechanism for undelivered data, a data transmission / reception mechanism for each message, and a message division / assembly mechanism.<u style="single">, With a connection management mechanism that manages the status of the receiving port of the partner station that is the communication partner</u>Equipped with a transaction management unit that provides unidirectional data transmission and request / response type transaction services.<u style="single">The transfer service processing unit identifies the application of the partner station using the port number which is the application identifier and determines the data transfer destination, and the transaction management unit divides the message into a plurality of data. An identifier and a sequence number specified for each transmission from the application are assigned to each divided data in order to identify the transaction unit, and the sequence number is given to each data having the same identifier specified by the application on the receiving side. Determine the assembly order based on, and assemble to the original message,</u><u style="single">The connection management mechanism notifies the partner station of the port number that identifies the application possessed by the own station as a receivable port list at the time of initial connection, and specifies the destination port number in the own station when receiving a message from the partner station. When the application is not present, the destination port number is notified to the other station as a non-receivable port number, the state of the reception port of the other station is set for each port number, and the initial state is unknown whether communication is possible or not. It is managed as one of three types of states, that is, communication is possible, communication is not possible, and communication is not possible, and the state of the receiving port of the partner station is based on the port number of the receivable port list notified from the partner station. If the status of the receiving port is communicable or communication is unknown, data transmission to the receiving port is permitted, and if the status of the receiving port is not communicable, data to the receiving port is permitted. Characterized by blocking transmission</u>It is a thing.</p>

<p> The road-to-vehicle communication system according to the present invention is a system in which both local applications in the base station apparatus and the mobile station communicate using a non-network type protocol, and the non-network type protocol is used as a transfer service processing unit. Since it is composed of the transaction management unit and the transaction management unit, various applications can be executed even while driving. Further, even when communication cannot be performed for a certain period of time, the communication error rate can be improved.</p><p> In addition, since the transfer service processing unit and the transaction management unit are configured independently, the simplest application can be realized by directly using the transfer service processing unit, and it is possible to realize high-speed connectivity and low overhead while driving. It can meet the requirements for road-to-vehicle communication. Further, when the protocol is extended, the extension part can be localized in the transaction management unit, and the extension can be easily performed.</p><p> The forwarding service processing unit uses the port number to identify both the sending and receiving applications. As a result, data transfer between a plurality of applications can be realized. In addition, there are 65536 types of port numbers, which can fully support the increase in application types in the future.</p><p> In the transaction management unit, the unit of transmission data is identified by an identifier (transmission data identifier) specified by the application. In addition, when the transmission data unit is larger than the size that can be transmitted at one time by the lower layer protocol, this protocol divides it into the size that can be transmitted, assigns a sequence number, and sends the sequence number on the receiving side. It has the function of assembling originally. At this time, in the case of individual communication, the transmitting side retransmits only the unreceived data by notifying the transmitting side of the sequence number of the unreceived data when the final data is received. This can improve the communication error rate. In the case of individual communication / broadcast communication, if the set of the source application identifier (source port number) and the transmission data identifier specified by the application are the same, the same identifier that has already been received on the receiving side. Treat as the same data as the data in. As a result, the transmitting side can retransmit data at an arbitrary timing, and even when communication cannot be performed for a certain period of time, the communication error rate can be improved.</p>

Embodiment 1. FIG. 1 is a diagram showing a concept of connection identification in a road-to-vehicle communication system according to the first embodiment of the present invention. Further, FIG. 3 is a diagram showing an outline of data flow in the road-to-vehicle communication system according to the first embodiment of the present invention. The basic configuration of the base station apparatus and the mobile station will be described with reference to FIGS. 1 and 3. The communication protocols used in the base station equipment and mobile stations are the narrow area communication (DSRC) protocol (ARIB STD-T75), the extended communication control protocol (ASL-ELCP), which is a bidirectional communication protocol, and the transfer service. It has a hierarchical structure consisting of a processing unit (Local Port Control Protocol (LPCP)) and a transaction management unit (Local Port Protocol (LPP)). Application is executed. The forwarding service processing unit is the narrow area communication (DSRC) protocol (ARIB). It is a control protocol for realizing application multiplexing on STD-T75) and extended communication control protocol (ASL-ELCP), and has the minimum functions for realizing multi-application. On the other hand, the transaction management unit is a communication protocol that intervenes between the transfer service processing unit and the application and extends the communication service of the transfer service processing unit, and provides more advanced communication services such as large-capacity data communication to the application. To do. The transfer service processing unit and the transaction management unit will be described in detail below.

1. Forwarding service processing unit (local port control protocol) 1.1 Overview The forwarding service processing unit (local port control protocol) will be described in detail below. The Local Port Control Protocol (LPCP) provides a data transfer service for data transfer and a management service for management control to a higher-level protocol such as an application in order to provide a communication means to a non-network application. It is a control protocol. The forwarding service processing unit identifies the source and destination applications by using an identifier called a local port number. It also provides service primitives (interfaces) for data transfer and management services to upper layer protocols such as higher layer applications and transaction management units. Furthermore, it has control information for realizing data transfer service and management service as internal data, and realizes various services by adding control information to data (PDU) exchanged between transfer service processing units of road vehicles. are doing.

1.2 Local port number 1.2.1 Access point identification In order to correctly deliver data from the source application to the opposite application, the Local Port Control Protocol (LPCP) provides a local port number as an access point to identify the application on the LPCP as shown in Fig. 1. , The pair of vehicle ID (link address, etc.) and local port number identifies the connection with the other party for each application.

1.2.2 Classification of local port numbers FIG. 2 is a diagram showing an example of classification of local port numbers. The local port number is used as a connection identifier in non-network applications, and the local port number is specified as follows. 0 to 0x0FFF is a reserved port, and 0x1000 to 0xFFFF is an arbitrary port. By specifying the port number in this way, 65536 types of port numbers can be specified, and it is possible to sufficiently cope with the increase in application types in the future.

1.2.3 Relationship between application and local port number The relationship between the application and the local port number specified in the previous section will be explained. The application form assumes a client / server model and a peer-to-peer model. Therefore, in the client / server model, the server process port that is globally unique is the number reservation port, and the client process port that is unique within the station is an arbitrary port. In the peer-to-peer model, both processes basically use the number reservation port. In the case of an original application, it is possible to use any port for both the server and client.

1.2.4 Setting the local port number Follow the rules below for setting the local port number. (1) Reservation numbers should be numbered globally without duplication. (2) The application can have multiple receiving ports. (3) For each base station and mobile station, each application should use the receiving port number so that there is no duplication within the station. (4) If it is not necessary to specify the source or if the source is known, the source port can be omitted.

1.3 Functions of LPCP Next, the function of LPCP will be described in detail. 1.3.1 Data transfer function Datagram transmission service FIG. 3 is a diagram showing an example of a datagram transmission service. Configuration of the local port based applications in DSRC-ASL is a plurality of applications on LPCP has a hierarchical structure that exists Deployment, LPCP it is necessary to perform an identification of the destination application's data. Therefore, the source and destination port numbers are assigned to the LPCP, and the data transfer destination is determined accordingly.

The communication service provided by LPCP is a high-speed, low-overhead connectionless datagram transmission service, and the specific operation between LPCP and the application (upper layer protocol) is as follows. 1: The application (upper layer protocol) asks LPCP to create a new receiving port to receive data. 2: Receive the vehicle ID (link address, etc.), source port number and received data from LPCP through the receiving port, On the contrary 3: The application (upper layer protocol) passes the transmission data, link address and transmission / reception port number to LPCP, and LPCP generates LPCP datagram from the information and sends it to the other party.

1.3.2 Management service In the management service process, the following services are provided for applications and upper layer protocols. -A service that transparently notifies the application of the own station of errors and events (communication connection, disconnection notification, etc.) notified by the ASL-ELCP (Extended Communication Control Protocol) management service. -A service that notifies the application of the partner station or own station of errors and events that occur in LPCP.

The specific operation between LPCP and the application (or upper layer protocol) is as follows. 1. The application (or upper layer protocol) asks LPCP to create a new port to receive the event. 2. Receive the link address, state identifier, and event additional information from LPCP through that port.

1.4 Interface with application Next, the interface between LPCP and the application will be described. 1.4.1 Notation description FIG. 4 shows a list of primitive types defined in the present invention, and FIG. 5 shows a list of parameter types used in the primitive definition table. 1.4.2 Data transfer service interface Figure 6 shows the logical relationship of the data transfer service. As a data transfer service, the local port control protocol prepares the following one type of primitive for the application (or upper layer protocol). 1.4.2.1 Transfer Primitive (Transfer Data) This primitive is a primitive for data transfer between ELCP of DSRC-ASL and non-IP application or upper layer protocol. Figure 7 shows the definition of the transfer primitive. In Figure 7, Link Address: ID that can be mapped one-to-one with the DSRC LID or LID used in this transmission. Source Port: Port number of the source application Destination Port: Port number of the destination application User Data: Transmission data body User Data Size: Transmission data size

1.4.3 Management service interface Figure 8 shows the logical relationship of the management service interface. As a management service, the local port control protocol prepares the following three types of primitives for the application (or upper layer protocol). -Event Report (event notification primitive) Open Port (port generation primitive) -Close Port (port discard primitive)

1.4.3.1 Event Report Primitive This primitive is a primitive for reporting event occurrences and errors to non-IP applications and upper layer protocols. There are two types: one that transparently forwards the event notified by the ASL-ELCP management service to the local port protocol, and one that transparently forwards the notification from the management service of the partner station. Figure 9 shows the definition of the event notification primitive. In Figure 9, Link Address: Specify the (inside) LID used by the notification recipient. Event Code: Stores the state identifier (Fig. 17) as an event code. Extention Parameter: Additional event information corresponding to each event code.

1.4.3.2 Port generation primitive (Open Port) This primitive is a primitive for generating a receiving port for data and events for LPCP. Figure 10 shows the definition of the port generation primitive. In Figure 10, Port: Port number requesting notification Type: Specify the primitive type that needs to be notified 1: TransferData 2: Event Report If this parameter is omitted, all primitive notifications are requested. Type of event that needs to be notified when Code: Type = 2 (Event Report) If this parameter is omitted, notification of all events will be requested. See Figure 17 for details on event types.

1.4.3.3 Port Discard Primitive (Close Port) This primitive is a primitive for discarding the receiving port generated by the port generation primitive. FIG. 11 is a diagram showing the definition of the port discard primitive. In FIG. Port: Port number to discard

1.5 Control information 1.5.1 Overview Next, LPCP control information used in the management service will be described. The LPCP management service manages the communication parameters used by LPCP. The LPCP management service manages the following information. (1) Receivable port list (2) Communication control information

1.5.2.1 List of receivable ports Information on the port number that can be received by the base station / mobile station. It is added to the list when the receive port generation primitive is received, and is deleted from the list when the receive port discard primitive is received. Figure 12 shows a configuration example of the receivable port list. 1.5.2.2 Communication control information Information about the application being communicated by the base station / mobile station. It is added to the list when the DSRC connection notification is received from the communication control management of ASL-ELCP, and is deleted from the list when the DSRC disconnection notification is received. Figure 13 shows an example of the configuration of communication control information. Abbreviation explanation: LID: link address Port No: Receivable port number Primitive Type: Primitive type to receive Event Code: Type of event code to receive Equipment ID: On-board unit specific information

1.6 Protocol Data Unit (PDU) Next, the LPCP protocol data unit (PDU) used in the datagram transmission service and the management service will be described. The LPCP PDU consists of a local port control protocol header and an application data part. 1.6.1 Datagram Transmission Service Protocol Data Unit Figure 14 shows the LPCP PDU format used in the datagram transmission service. Access point identifier: An identifier that identifies the network control protocol. Always store local Port Control (1). Protocol identifier: Represents the PDU type. In the datagram transmission service, message (0) is stored. See Figure 15 for details. Source port number: Port number of the source application Destination port number: Port number of the destination application User data section length: Specifies the data length of the subsequent user data section. The unit is octet. The size of this area is expanded according to the ASN.1 coding rules. If there is no user data to add (null), 0 is specified in this area. The maximum length of data that LPCP can pass to ASL-ELCP, the maximum transmission unit (MTU) of LPCP, is 522 octets (including access control information). Contents of user data part: Transmission data body. Stores OCTET STRING type indefinite length data. FIG. 15 is a diagram showing the protocol identifier of LPCP.

1.6.2 Management Service Protocol Data Unit Figure 16 shows the LPCP PDU format used in the management service. The PDUs shown below are used to notify the LPCP of the partner station of an event. FIG. 16 is a diagram showing the format of the event notification message. Access point identifier: An identifier that identifies the network control protocol. Always store local Port Control (1). Protocol identifier: Represents the PDU type. The management service always stores event Report (1). Event code: An identifier that indicates the content of the event that occurred. 0 to 127 are state identifiers of the communication control protocol, and 128 to 255 are LPCP state identifiers. FIG. 17 is a diagram showing the contents of the event code. Event additional information length: Specifies the data length of the subsequent event additional information. The unit is octet. The size of this area is expanded according to the ASN.1 coding rules. If there is no event information to be added (null), 0 is specified in this area. Contents of event additional information: Contents of event additional information. Stores OCTET STRING type indefinite length data.

1.7 Processing procedure The processing procedure in LPCP will be described. 1.7.1 Initial connection procedure (a) The application requests the LPCP for DSRC connection notification in advance by using the port generation primitive. (b) Upon entry of the vehicle into the DSRC coverage, the ASL-ELCP management service event notification primitive (Event Information.ind) receives the status "Notification of communication connection". (c) Notify the event code "DSRC connection notification (96)" with the event notification primitive (Event Report.ind) to the port for which DSRC connection notification is requested by the port generation primitive. Figure 18 shows an example of the processing sequence when connecting to DSRC.

1.7.2 Communication termination procedure (a) The application requests the LPCP for DSRC disconnection notification in advance by using the port generation primitive. (b) Receive the status "Notification of communication disconnection" in the management service event notification primitive (EventInformation.ind) of ASL-ELCP. (c) Notify the LPP connection management service of the event code "DSRC disconnection notification" with the event notification primitive (EventReport.ind). Figure 19 shows an example of the processing sequence at the end of communication.

1.7.3 Message forwarding procedure (1) Transmission processing (a) A data transfer request primitive (TransferData.req) is issued. (b) Refer to the communication control information, and if the specified Link Adress is a private link address and DSRC is not connected at that link address, the source port number specified in the data transfer request primitive is used. On the other hand, the event notification primitive whose state identifier is "DSRC is not connected (128)" is issued, and the transmission process is completed. However, this procedure assumes that the event notification is requested by the local port generation primitive, and if the event notification is not requested, the event notification to the upper layer protocol is not performed. Whether or not there is an event notification is determined by the list of receivable local ports. (c) When DSRC is connected, generate a packet whose access point identifier is local Port Protocol (1) and protocol identifier is message (0), and send ASL-ELCP data transfer primitive (Send Unit). Send with Data.req) and complete the sending process. (d) When an event notification message is received from the partner station that sent the data transfer message after the transmission process is completed, the event code passed in that message is confirmed, and the content of the event code is "The destination local port is. If it is "not valid", the event notification primitive (Event Report.ind) notifies "the destination local port is not valid" to the source local port number specified in the event additional information of the message. However, this procedure assumes that the event notification is requested by the local port generation primitive, and if the event notification is not requested, the event notification to the upper layer protocol is not performed. Whether or not there is an event notification is determined by the list of receivable local ports.

(2) Reception processing (a) The application requests the LPCP for forwarding notification by the port generation primitive and opens the receiving port. (b) When a packet whose protocol identifier is message (0) is received from the ASL-ELCP in the data transfer notification primitive (Send Unit Data.ind), the protocol identifier, destination local port number, and source local are received from the packet. Extract port number and user data. (c) Refer to the receivable port list, and if the destination port number received in (b) is valid, use the data transfer primitive (TransferData.ind) for the higher-level entity specified by the destination port number. Notifies the reception of data from the partner station and completes the reception process. If (d) the link address is a private address and the destination port number received in (b) is not valid, the protocol identifier is event. Report (1), create a packet whose status identifier is "destination port is not valid (129)", send it to the partner station with the data transfer primitive of ASL-ELCP, and complete the reception process. That is, if the destination application does not exist in the own station when the message is received from the other station, the other station is immediately notified to that effect. If the link address is a group broadcast address and the destination port number received in (b) is not valid, the received data is discarded and the reception process is completed. FIG. 20 shows an example of basic processing sequence for message forwarding, FIG. 21 shows an example of processing sequence when DSRC is not connected, and FIG. 22 shows an example of processing sequence when the destination local port number is not valid.

2. Transaction management department (local port protocol) The transaction management unit (local port protocol) will be described in detail below.

2.1 Overview The Local Port Protocol (LPP) intervenes between the Local Port Control Protocol (LPCP) and non-network applications, extends the functionality of the Local Port Control Protocol, and extends the functionality of the DSRC vehicle / roadside aircraft non-network. It is a transaction-oriented protocol that aims to improve the efficiency of application construction by providing the following transaction services and connection management services for related applications (see Fig. 23). This protocol consists of a transaction service processing unit that extends the communication function of the local port control protocol and a connection management service processing unit that manages communication status such as initial connection and disconnection. The functions of each service processing unit are as follows. Transaction service processing unit -Transaction-based data exchange function One-way data transmission transaction service Request / response type transaction service Data retransmission function Message division / assembly function -Transaction discard function Connection management service processing department DSRC connection inquiry service DSRC disconnection notification service Receivable port inquiry service In addition, the transaction management unit provides the application with a service primitive (interface with the application) for using the above function. Furthermore, in order to realize the above functions, the structure of data (PDU) exchanged between the transaction management units of road vehicles is defined. In the transaction management unit, the sending side adds control information according to the function requested by the service primitive (or an event generated inside the transaction management unit), and the receiving side analyzes and uses the control information added to the PDU. This realizes the above function.

2.2 LPP features Next, the functions of each service processing unit in the above-mentioned LPP will be described in detail. 2.2.1 Transaction service processing 2.2.1.1 Transaction-based data exchange function In the local port protocol, application data is exchanged on a transaction-by-transaction basis. Each transaction is distinguished by the transaction ID (see Fig. 24). This makes it possible to handle situations where multiple transactions exist at the same time between the same applications. FIG. 24 is a diagram showing an example of data exchange between transactions in LPP. The transaction ID numbering method is as follows. (1) 16-bit configuration (2) The first bit represents the transaction start side (0 on the vehicle side, 1 on the road side). (3) Every time a transaction is issued (Invoke.req), it is incremented by 1.

2.2.1.2 Two types of transaction service provision functions This protocol provides the following two types of transaction services. One-way data transmission transaction service Request / response type transaction service Each of these transaction services is used at the required level according to the communication requirements of each application, and the optimum communication service can be used for each application.

2.2.1.2.1 Basic transaction (1) Data transmission service Provides data transmission services for non-network applications on both roads and vehicles. (See FIG. 25) FIG. 25 is a diagram showing an example of a data transmission service. (2) Request / response type transaction service Notify the other party of the message and get the return value for the message. It is used for remote method calls. (See Figure 26) FIG. 26 is a diagram showing an example of a request / response type transaction service.

2.2.1.2.2 Data retransmission function This function is a function for ensuring the reliability of communication, and the retransmission is controlled by the retransmission timer and the retransmission counter. Communication reliability is ensured by retransmitting when the retransmission timer times out (less than or equal to the maximum number of retransmissions) (see Fig. 27). It can be applied to data transmission and reply, and the application specifies whether to apply it. The processing sequence is shown below. FIG. 27 is a diagram showing an example of data retransmission. -When transmitting a packet, the retransmission timer is started and the retransmission counter is set to 0. -If the response data cannot be received before the retransmission timer times out, the retransmission counter is incremented and the packet is retransmitted. -If the retransmission counter exceeds the maximum number of retransmissions, the transaction is terminated and the application is notified to that effect. Further, in a transaction using the data retransmission function, there is a possibility that the previously received PDU is received again due to reasons such as the delivery confirmation not being reached. This duplicate reception is detected using the transaction ID (see Fig. 28). The specific check method is an implementation requirement and is not specified here. FIG. 28 is a diagram showing an example of duplicate reception check.

2.2.1.2.3 Message division / assembly function This function enables the application to be provided with a message transmission interface that exceeds the LPCP MTU by dividing and assembling the message. FIG. 29 shows the procedure of message communication using the division / assembly function. When the LPP receives a message from the application that exceeds the LPCP MTU, it divides the PDU into the LPCP MTU size within the LPP and sequentially passes it to the LPCP. The packets divided by this are stacked in the DSRC-ASL transmission queue and sequentially transferred to layer 7. At this time, since it is assumed that the transmission queue of DSRC-ASL overflows, LPP guarantees that all packets are transmitted by retransmitting the packet that failed to be transmitted and performing flow control. The receiving side sequentially captures the divided packets passed from the LPCP and stacks them in the receiving queue prepared by the receiving application. At this time, due to factors such as layer 2 retransmission processing, there is no guarantee that each packet will be stored in the receive queue in the order of transmission, and the receiving side determines the assembly order based on the sequence number assigned to each packet and PDUs. Assemble to. After receiving all the packets, the receiving side returns a arrival confirmation to the transmitting side.

In addition, it is assumed that packet loss will occur due to reception queue overflow in DSRC-ASL or data loss in DSRC, and there is no guarantee that all transmitted packets will reach the LPP of the partner station. In this case, the loss of one packet results in the loss of data for the entire message. Therefore, the packet that was not received when the final packet was received is notified by a negative response, and the missing packet is retransmitted (selective retransmission processing). ) To guarantee the arrival of the entire message. In addition, the arrival of the missing final packet is guaranteed by normal retransmission processing. The same control is performed for the packet group transmitted by selective retransmission. FIG. 30 shows an example of the selective retransmission process. Since it is expected that the size of the receive queue required for each application will differ greatly, the application prepares the receive queue in this function. Therefore, only one transaction that requires division / assembly can be issued at a time for each destination (identified by the link address and destination port number). Further, in the case of data transmission to the broadcast address, the reliability of the required communication is ensured by the transaction re-execution request without performing the arrival confirmation reply, the selective retransmission process, or the retransmission control of the final segment. Figure 32 shows an example of transaction re-execution processing.

2.2.1.3 Transaction discard function In a request-response type transaction, the transaction can be requested to be destroyed at the request of the application (see Fig. 33). The following processing is executed according to the transaction status at the time of request. -If the message has not been sent, discard the message. -If a message has been sent or is being sent, all data related to the transaction is discarded, and the other party is notified that the transaction has been discarded. -When a transaction destruction request is received due to a transaction destruction request on the other side, the application is notified of the transaction destruction and all data related to the transaction is destroyed. FIG. 33 is a diagram showing an example of a transaction discard notification. Also, -The DSRC communication path is disconnected. -The destination port is not a receivable port. In such a case, in order to suppress unnecessary communication, the transaction is not started and the application is notified that the request has failed.

2.2.2 Connection management service processing The connection management service provides the following services to the application to provide the application with a trigger for starting / ending communication. -A service that manages and monitors the connection status of DSRC, reports the connection status, and notifies new connections and disconnections in response to requests from applications. -By notifying each other of the receivable port numbers between the road and vehicle connection management services, the receivable port numbers of the partner station can be managed, and the status can be reported or a certain port in response to a request from the application. A service that notifies you that you can receive. The connection management service is positioned in the same way as the application on the local port control protocol, and the data transfer service of the local port control protocol is used for sending and receiving events between the connection management services of road vehicles. The port number used by the connection management service will be 0x0FFF for the time being.

2.2.2.1 DSRC connection inquiry service Ability to inquire if DSRC is connected. Two types of services are specified: a reference service that immediately responds to the DSRC connection status when making inquiries, and a notification service that waits until a connection is made and notifies when the connection is made. 2.2.2.2 DSRC disconnection notification service A function to notify the DSRC disconnection to the application that requests the disconnection notification.

2.2.2.3 Receivable port inquiry service A function to inquire whether the receiving port on the partner station exists. There are the following three types of port states. -Receivable port: A port on which the partner station has opened this port as a data reception port. -Unreceivable port: A port on which the partner station does not open this port as a data reception port. -Unknown port: A port for which it is unknown whether the partner station has this port open as a data receiving port. This is the initial state. In addition, the receivable port inquiry service waits until the inquired port becomes a receivable port with the reference service that immediately answers the state of the port at the time of inquiry, and notifies the receivable port from the partner station. Two types of services are specified: a notification service that notifies you when it is received (if the port you have already inquired about is known to be a receivable port, it will be answered immediately). In order to enable the above service, the management service of the local port protocol between road vehicles provides the port number that the own station can receive or the port that cannot be received to the partner station when the DSRC communication is connected or the receivable port is changed. It has a function to notify the number.

2.3 Interface with application Next, the interface between the LPP and the application will be described. 2.3.1 Explanation of notation A list of primitive types defined in the present invention is shown in FIG. In addition, FIG. 35 shows a list of parameter types used in the primitive definition table in the present invention. 2.3.2 Transaction service primitive As a transaction service, LPP prepares the following two types of primitives for the application. -Invoke: (transaction start primitive) -Abort: (transaction discard primitive)

2.3.2.1 Invoke (transaction start primitive) Outline of processing: The Invoke primitive is a primitive for creating a new transaction. All transactions are initiated by issuing this primitive. Definition: FIG. 36 is a diagram showing the arguments of the Invoke primitive. Link Address: DSRC LID or ID that can be mapped one-to-one with LID Source Port: Port number of the source application Destination Port: Port number of the destination application User Data Size: Send data size (in octets) User Data: Send data body Transaction Type: Transaction service type 0: Data transmission transaction service 1: Request-response transaction service Require Ack: Flag for whether to enable retransmission processing (0: Retransmission processing not required, 1: Retransmission processing required) Result Timeout: The timeout period before receiving the Result PDU in the request-response transaction service. If no Result PDU is received by this time after issuing Invoke.req, this transaction will be discarded. Handle: An ID that distinguishes transactions locally. Specified by the application. The Handle specified here must meet the following conditions. The issuer of Invoke.req must be able to uniquely identify Handle and Source Port by transaction ID. The issuer of Invoke.res must be able to uniquely identify the Link Address, Source Port, and transaction ID by Handle. If the same Handle as the immediately executed broadcast communication is specified in the broadcast communication, it is treated as a transaction re-execution request.

2.3.2.2 Abort (Transaction Discard Primitive) Outline of processing: The Abort primitive is a primitive for destroying a generated transaction. Definition: FIG. 37 is a diagram showing the arguments of the Abort primitive. Abort Type: Indicates whether the reason for discarding is a system error (0) or a user request (1). Abort Code: Indicates why the transaction was abandoned. (See Figure 38 for details on system errors) Handle: An ID that distinguishes transactions locally. FIG. 38 is a diagram showing a list of Abort Codes when Abort Type = 0 (system error).

2.3.3 Connection management service As a connection management service, LPP prepares the following four types of primitives for the application. -Connect: (Transaction startable query / notification primitive) -Disconnect: (DSRC disconnection notification primitive) -Register Port (port registration primitive) Deregister Port

2.3.3.1 Connect (transaction startable query / notification primitive) Outline of processing: The Connect.req primitive is a primitive for querying whether a transaction can be started. The Connect.cnf primitive is a primitive for notifying the application of the inquiry source of the DSRC connection and LID and the receivable port number of the partner station (pointed to by the LID) in response to the inquiry by Connect.req. Definition: FIG. 39 is a diagram showing the arguments of the Connect primitive. Querist Port: The port number of the inquirer, used to identify the app that made the inquiry. Query LID: The LID to query. When LID is specified, it is treated as an inquiry for an already connected link. On the other hand, if not specified, it is treated as waiting for a new connection. If omitted together with QueryPort, Connect.cnf will be issued immediately after DSRC connection (high-speed connection). On the other hand, when QueryPort is specified, Connect.cnf is issued after receiving the receivable port notification (normal connection). Query Port: The destination port number to query. Time Out: Wait time until Connect.cnf is issued when DSRC is not connected. If connected during the wait, issue Connect.cnf immediately. If this parameter is omitted, it is treated as timeout time = . Connected LID: If Query LID is specified and that LID is connected, the same LID as Query LID is specified. Query If a LID is specified and the LID is not connected, or if the Query LID is not specified and there is no new connection within the time specified by the TimeOut parameter, -1 is specified. Accept Port: Receivable port number of the partner station represented by Connected LID. If specified in Query Port, only that port number will be notified. If the specified port number is a reception refusal port number, -1 is specified. If Query Port is omitted, 0 is specified.

2.3.3.2 Disconnect (DSRC disconnection notification primitive) Outline of processing: It is a primitive for notifying the application of the disconnection of DSRC. Definition: FIG. 40 is a diagram showing the arguments of the Disconnect primitive. 2.3.3.3 Register Port Outline of processing: The Register Port primitive is a primitive for registering a receiving port to LPP. Definition: FIG. 41 is a diagram showing the arguments of the RegisterPort primitive. Port No: Receive port number Bulk Area: Area for assembling split messages Bulk Area Size: Bulk Area Size

2.3.3.4 Deregister Port Outline of processing: The Deregister Port primitive is a primitive for deleting a receive port for LPP. Definition: FIG. 42 is a diagram showing the arguments of the DeregisterPort primitive. Port No: Incoming port number to delete the registration

2.4 Protocol Data Unit (PDU) Next, the protocol data unit (PDU) of LPP used in the transaction service and the connection management service will be described. 2.4.1 Transaction service protocol data unit There are seven types of protocol data units used in transaction services, as shown in Fig. 43, depending on the usage scene. The PDU used in the transaction service consists of a header part defined for each PDU type and a data part in which application data is stored. The basic structure of the PDU is shown in FIG.

2.4.1.1 Invoke PDU FIG. 45 is a diagram showing header information of the Invoke PDU. PDU Type: The type of PDU. Invoke PDU is always Invoke (1). Version: Represents the version of the local port protocol. The current version is 0x00. TT: Abbreviation for Transaction Type. Specifies the type of transaction. 0: Data transmission transaction service, 1: Request / response type transaction service. RA: Abbreviation for Require Ack. A flag that indicates whether retransmission processing is valid. 1 when retransmission processing is enabled. RD: Abbreviation for Retransmitted Data. A flag that indicates whether the data has been resent. 1 when resending. TID: Transaction ID. RES: Reservation.

2.4.1.2 Result PDU FIG. 46 is a diagram showing the header information of the Result PDU. PDU Type: The type of PDU. Result PDU is always Result (2). RA: Abbreviation for Require Ack. A flag that indicates whether retransmission processing is valid. 1 when retransmission processing is enabled. RD: A flag that indicates whether the data has been resent. 1 when resending. TID: Transaction ID. RES: Reservation.

2.4.1.3 Acknowledgement PDU FIG. 47 is a diagram showing header information of the Acknowledgement PDU. PDU Type: The type of PDU. Always Ack (3) in Acknowledgement PDUs. RD: A flag that indicates whether the data has been resent. 1 when resending. TID: Transaction ID. RES: Reservation.

2.4.1.4 Abort PDU FIG. 48 is a diagram showing header information of the Abort PDU. PDU Type: The type of PDU. Abort PDU is always Abort (4). AT: A flag that indicates whether the reason for discarding is a system error (0) or a user request (1). TID: Transaction ID. Abort Code: Specify the reason for discarding the transaction as a code. (See Figure 38) RES: Reservation.

2.4.1.5 InvokeSegment PDU FIG. 49 is a diagram showing the header information of the Invoke Segment PDU. PDU Type: The type of PDU. Invoke Segment PDU is always Invoke Sgm (5). Version: Represents the version of the local port protocol. The current version is 0x00. TT: Abbreviation for Transaction Type. Specifies the type of transaction. 0: Data transmission transaction service, 1: Request / response type transaction service. FIN: A flag that indicates whether it is the last segment. 1 in the final segment. RD: Abbreviation for Retransmitted Data. A flag that indicates whether the data has been resent. 1 when resending. TID: Transaction ID. Segment No: PDU sequence number.

2.4.1.6 Result Segment PDU FIG. 50 is a diagram showing the header information of the Result Segment PDU. PDU Type: The type of PDU. ResultSegment PDU always results in ResultSgm (6). FIN: A flag that indicates whether it is the last segment. 1 in the final segment. RD: A flag that indicates whether the data has been resent. 1 when resending. TID: Transaction ID. RES: Reservation. Segment No: PDU sequence number.

2.4.1.7 Nack PDU FIG. 51 is a diagram showing header information of the Nack PDU. PDU Type: The type of PDU. Always Nack (7) for Nack PDUs. RD: Flag indicating whether the data was resent. 1 when resending. TID: Transaction ID. RES: Reservation. Num Seg: Number of unreceived PDU sequence numbers Segment Number List: List of sequence numbers of unreceived PDUs

2.4.2 Connection Management Service Protocol Data Unit The connection management service of the local port protocol uses the transfer service of the local port control protocol for the connection management service of the partner station when a DSRC is newly connected or the number of receivable ports increases or decreases, and the receivable port list. And notify the unreceivable port. The PDUs shown below are protocol data units used in these notifications and are stored in the user data section of the local port control protocol.

2.4.2.1 Receivable port list Protocol data unit in notification FIG. 52 is a diagram showing a protocol data unit in the receivable port list notification. Status: Indicates the type of event. In the case of receivable port list notification, always store accept Port List (1). Num Ports: Stores the number of receivable port numbers. Accept Port List: Stores a list of receivable port numbers.

2.4.2.2 Protocol data unit for unreceivable port notification FIG. 53 is a diagram showing a protocol data unit for non-transmission port notification. Status: Indicates the type of event. In the case of non-receivable port notification, rejectPort (2) is always stored. Reject Port: Stores the unreceivable port number.

2.5 Processing procedure The processing procedure in LPP will be described. 2.5.1 Initial connection procedure (1) Initial connection procedure for normal apps FIG. 54 is a diagram showing the initial connection procedure of the local port protocol. (a) Mobile and base station applications register receivable port numbers in the LPP using the Register Port. (b) LPP updates the connection management table and registers the receivable port number and connection management service port registered in (a) above in LPCP as data reception ports. The management service port is also registered in LPCP as an event reception port. (c) Each application does not specify the Query LID parameter, specifies the Query Port parameter, issues the DSRC connection query primitive (Connect.req), and waits for the DSRC connection (blocking call). (d) The LPP connection management service receives the event "DSRC connection notification (96)" from the LPCP as an event notification primitive (Event Report). (e) The LPP connection management service creates a connection management table for the LID received by the primitive, and sends a receivable port list to the connection management service port of the partner station. (f) When the LPP connection management service receives the receivable port list from the LPCP with the data transfer primitive (Send Unit Data.ind), the receivable port is registered in the connection management table of the LID notified by the primitive. .. After that, the transaction start request for the same LID is accepted only for this receivable port. (g) For the application issuing the DSRC connection inquiry primitive (Connect.req) for the port number included in the receivable port list received in (e) above, the DSRC connection notification primitive (Connect.cnf) ), Notify the LID and the transmittable port number. (h) A transaction is started by issuing a transaction start request primitive (Invoke.req) to the LID or broadcast address notified by the DSRC connection notification primitive (Connect.cnf) and the destination port number. ..

(2) Initial connection procedure for high-speed connection app High-speed connection is a method of realizing high-speed initial connection by omitting a part of the processing for initial connection. FIG. 55 is a diagram showing an example of an initial connection sequence of a high-speed connection application. (a) Mobile and base station applications register receivable port numbers in the LPP using the Register Port. (b) LPP updates the connection management table and registers the receivable port number in LPCP. (c) Each application issues a transaction startable query primitive (Connect.req) without specifying both Query LID and Query Port, and waits for DSRC connection. (d) Receive the event "DSRC connection notification (96)" in the event notification primitive (EventReport.ind) from LPCP. (e) LPP creates a connection management table for the LID received by the primitive. Since this is an application that requires a high-speed connection, a transaction start request for all ports with this LID and broadcast address is required until the partner station's receivable port list is received from the partner station's LPP connection management service. Accept. (f) Notify the LID by the DSRC connection notification primitive (Connect.cnf) to the application issuing the DSRC connection inquiry primitive (Connect.req). (g) Each application issues a transaction start request primitive (Invoke.req) for the LID or broadcast address notified by the DSRC connection notification primitive, and starts the transaction. (h) If the port number specified in (g) above exists in the partner station, this transaction succeeds. If the port number specified in (g) above does not exist in the partner station, the LPCP of the partner station notifies the event "Destination local port is not valid (129)" in the event notification primitive, and connection management of this LID. Update the table. When Transaction Type = 1, the corresponding application is notified of the transaction failure with the transaction destruction notification primitive (Abort.ind). After that, if there is a transaction start request (Invoke.req) with Transaction Type = 1 for this LID / port pair, the transaction discard primitive (Abort.ind) notifies the transaction discard.

2.5.2 Data transmission Transaction service data transfer procedure (1) Transmission processing (a) The transaction of the data transmission service is started by issuing the transaction start request primitive (Invoke.req) with Transaction Type = 0 by the application. (b) If the specified LID and source port number pair is a reception refusal port, the application is notified of the status "Rejection port notification" in Abort.ind, and this transaction is completed. (c) If the specified message exceeds the MTU and does not support the division / assembly process, Abort.ind notifies the application of the status "MTU error" and this transaction is completed. .. The processing when the division / assembly processing is supported is described in Section 2.5.5. (d) Invoke with TT = 0 except for (b) and (c) above. Create a PDU and send it to the partner station using the LPCP transfer primitive (TransferData.req). The processing when the retransmission processing is effective is described in Section 2.5.4. (2) Reception processing (a) When the Invoke PDU transmitted in (1)-(d) above is received by the LPCP transfer primitive (TransferData.ind), it is received by the application using the transaction notification primitive (Invoke.ind). Notify the data. Figure 56 shows an example of the processing sequence of the data transfer procedure of the data transmission transaction service.

2.5.3 Data transfer procedure for request-response transaction service (1) Transmission processing (a) The transaction of the request / response type transaction service is started by issuing the transaction start request primitive (Invoke.req) with Transaction Type = 1. (b) If the specified LID and source port number pair is a reception refusal port, the application is notified of the status "Rejection port notification" in Abort.ind, and this transaction is completed. (c) If the number of transactions that can be executed at the same time is exceeded, the application is notified of the status "transaction could not be started" in Abort.ind, and this transaction is completed. (d) If the specified message exceeds the MTU and does not support the division / assembly process, Abort.ind notifies the application of the status "MTU error" and this transaction is completed. .. The processing when the division / assembly processing is supported is described in Section 2.5.5. (e) In cases other than (b), (c), and (d), an Invoke PDU with TT = 1 is created, transmitted to the partner station using the LPCP transfer primitive (TransferData.req), and then Result. Start the timer (the timeout value of the Result timer is specified by Invoke.req) and wait for the result PDU to be received from the partner station. (f) When the Result timer started in (e) above times out, an Abort PDU with AT = 0 and Abort Code = 0x08 is generated, the partner station is notified of the status "Result timer timeout", and the transaction is discarded. The notification primitive (Abort.ind) notifies the application of transaction failure. (g) Result sent from the partner station by the LPCP transfer primitive (TransferData.ind) before the Result timer times out. When the PDU is received, the Result timer started in (e) above is stopped, and the response data is notified to the application by the response notification primitive (Invoke.cnf).

(2) Reception processing (a) When the Invoke PDU sent from the partner station is received by the LPCP transfer primitive (TransferData.ind), the application is notified of the received data by using the transaction notification primitive (Invoke.ind). Wait for the response primitive (Invoke.res) to be received from. (b) When the LPCP transfer primitive (TransferData.ind) receives the Abort PDU sent from the partner station, the transaction discard notification primitive (Abort.ind) is issued to notify the application of the transaction failure. And this transaction is complete. (c) The application issues a response primitive (Invoke.res), requesting the LPP to send a response. (d) Generate a Result PDU and send it to the partner station by the LPCP transfer primitive (TransferData.req). Figure 57 shows an example of the basic processing sequence of the request / response type transaction service, and Figure 58 shows an example of the processing sequence when the Result timer times out.

2.5.4 Data transfer procedure when retransmission processing is enabled Retransmission processing is applied when Require Ack = 1 is specified in Invoke.req and Invoke.res. The following describes the sequence when the retransmission process is applied to Invoke.req of the data transmission transaction. In the request / response type transaction service, the same processing can be applied to Invoke.res. (1) Transmission processing (a) When the application issues a transaction start request primitive (Invoke.req) with Require Ack = 1, the data transfer service for which retransmission processing is valid is started. (b) Create an Invoke PDU with RA = 1, use the LPCP transfer primitive (TransferData.req), send it to the partner station, activate the retransmission timer, and wait for the reception of the Acknowledgement PDU from the partner station. (c) Acknowledgement for some reason, such as the Invoke PDU sent in (b) above not reaching. If the retransmission timer started in (b) above times out before receiving the PDU, set the RD flag of the Invoke PDU transmitted in (b) above to 1, retransmit to the partner station, and then restart the retransmission timer. Start up and increment the retransmission counter. (d) If the retransmission counter exceeds the maximum number of retransmissions after repeating retransmissions several times, an Abort PDU (see Section 2.4.1.4) with AT = 0 and Abort Code = 0x07 is generated and the status "Retransmission" is generated. In addition to notifying the partner station of "timer timeout", the transaction destruction notification primitive (Abort.ind) notifies the application of the transaction failure, and this transaction is completed. (e) When the Acknowledgement PDU transmitted from the partner station is received by the LPCP transfer primitive (TransferData.ind) before the retransmission timer times out, the retransmission timer started in (b) or (c) above is stopped. , Complete this transaction.

(2) Reception processing (a) When an Invoke PDU is received by the LPCP transfer primitive (TransferData.ind), the application is notified of the received data by using the transaction notification primitive (Invoke.ind). (b) If the RA flag of the PDU received in (a) above is valid, an Acknowledgement PDU is generated, an Acknowledgement PDU is sent to the partner station by the LPCP transfer primitive (TransferData.req), and the wait timer is used. To start. (c) If the Invoke PDU received in (a) above is re-received because the Acknowledgement PDU transmitted in (b) above does not arrive, this PDU is discarded, the Acknowledgement PDU is generated again, and LPCP. By the transfer primitive (TransferData.req) of, it is sent to the partner station and the wait timer is restarted. (d) When the wait timer started in (b) or (c) above times out, this transaction is completed. FIG. 59 shows an example of the processing sequence when the retransmission processing is enabled, FIG. 60 shows an example of the processing sequence when the retransmission processing succeeds, and FIG. 61 shows an example of the processing sequence when the retransmission processing fails.

2.5.5 Message forwarding procedure when division / assembly processing is enabled The division / assembly process is applied when a message exceeding the MTU is specified in Invoke.req and Invoke.res. The following describes the sequence when the division / assembly process is applied to Invoke.req. (1) Transmission procedure (a) When the application specifies a message with a size larger than the MTU and issues a transaction start request primitive (Invoke.req), the transaction of the data transmission service for which the division / assembly process is valid is started. (b) If the specified LID and source port number pair is a reception refusal port, notify the application of the status "Rejection port notification" in Abort.ind. (c) If a transaction that requires division / assembly processing has already been executed for the specified set of LID and source port number, the status "Divided transfer in progress" is displayed in Abort.ind for the application. Is notified. (d) In cases other than (b) and (c) above, the transmission data is divided by MTU in order from the beginning, and a header according to the provisions of Invoke Segment PDU (see Section 2.4.1.5) is added to each divided segment. , LPCP transfer primitive (TransferData.req) is used to make sequential transmission requests. (e) When the ASL send queue overflows and LPCP notifies Event Report.ind of the status "Send queue is full, send failed", the data is waited for a certain period of time and the send fails. And start sending again. (f) After transmitting the last segment data, activate the retransmission timer and wait for the reception of the Acknowledgement PDU (see section 2.4.1.3) or Nack PDU (see section 2.4.1.7) from the partner station. (g) When the Nack PDU sent from the partner station is received by the LPCP transfer primitive (TransferData.ind), the Nack PDU Segment Number Resend the segment specified in List. At this time, the RD flag of all the segments to be retransmitted is set to 1, and the FIN flag of the last segment to be retransmitted is set to 1. After retransmitting all segments, activate the retransmission timer and wait for the Acknowledgement PDU (see Section 2.4.1.3) or Nack PDU to be received from the partner station. (h) If the retransmission timer started in (f) or (g) above times out, the final segment is transmitted again and the retransmission timer is restarted. (i) When the Acknowledgement PDU transmitted from the partner station is received by the LPCP transfer primitive (TransferData.ind), the retransmission timer started in the upper (f), the above (g), or the above (h) is stopped. Complete this transaction.

(2) Reception procedure (a) The application specifies the received data assembly buffer area by the port registration primitive (Register Port). (b) When the Invoke Segment PDU is received by the LPCP transfer primitive (TransferData.ind), it is sequentially stored in the receive queue specified by the application. (c) When the final segment data is received, check if there are any unreceived segments, and if there is unreceived segment data, create a Nack PDU (see section 2.4.1.7) and transfer primitives for LPCP. Use (TransferData.req) to send to the partner station and store the final segment number to be received thereafter. (d) After sending the Nack PDU in (c) above, if data for which the RD flag is not set is received due to a change in the arrival order, etc., that data is discarded. (e) If all segment data is received when the final segment data is received, the transaction notification primitive (Invoke.ind) is used to notify the application of the received data and generate an Acknowledgement PDU to generate LPCP. It is transmitted to the partner station by the transfer primitive (TransferData.req). FIG. 62 shows an example of the basic processing sequence when the division / assembly processing is effective, FIG. 63 shows an example of the processing sequence when a part of the division data is missing and selective retransmission processing is performed, and FIG. 64 shows the final segment data. An example of a processing sequence is shown when is missing and retransmission processing is performed.

2.5.6 Communication termination procedure (a) Receive the event "DSRC disconnection notification (98)" in the event notification primitive (EventReport.ind) from LPCP. (b) Issue a DSRC disconnection notification primitive (Disconnect.ind) to the application using the LID. (c) LPP deletes the connection management table of LID received by the primitive. After that, the transaction start request for the same LID will not be accepted. FIG. 65 is a diagram showing a procedure at the time of DSRC disconnection.

2.5.7 Transaction discard procedure The local port protocol allows an application to request a transaction to be destroyed when the transaction is in one of the following states: FIG. 66 is a diagram showing a transaction discard procedure. Sender -After receiving Invoke.req in a request-response type transaction, until issuing Invoke.cnf by receiving Result PDU. Receiver -In a request-response type transaction, after issuing Invoke.ind until the Result PDU is sent by Invoke.res reception. The processing sequence is described below. (a) This sequence is initiated by receiving a transaction destruction request primitive (Abort.req) from the application. (b) LPP generates an Abort PDU for the transaction specified by the primitive and sends it to the partner station using the LPCP transfer request primitive (TransferData.req). (c) Issue a transaction destruction notification primitive (Abort.ind) to the requesting application to notify the completion of transaction destruction. (d) When the LPP receives the Abort PDU by the LPCP transfer notification primitive (TransferData.ind), if the transaction specified by the TID of the PDU is running in its own station, all resources related to that transaction are discarded. After that, the transaction destruction notification primitive (Abort.ind) is issued to the application to notify the transaction destruction.

In the above embodiment, the narrow range communication (DSRC) protocol (ARIB STD-T75), the extended communication control protocol (ASL-ELCP) which is a protocol capable of bidirectional communication, and the transfer service processing unit (LPCP) And the transaction management unit (LPP) is shown, but another protocol that can communicate in both directions may be used instead of the extended communication control protocol (ASL-ELCP).

As described above, the road-to-vehicle communication system according to the present invention is a system in which both local applications in the roadside system and the mobile station communicate using a non-network type protocol, and the road-to-vehicle communication according to the present invention. The system is a system in which both local applications in the roadside system and the mobile station communicate using a non-network type protocol, and a transfer service processing unit for realizing a multi-application using the non-network type protocol. A transaction management unit that has a mechanism for retransmitting undelivered data, a mechanism for sending and receiving data for each message, and a mechanism for dividing and assembling messages, and provides a transaction service that provides unidirectional data transmission and request / response type transaction services. It is characterized by being composed of and.

Further, in the road-to-vehicle communication system of the present invention, by using a port number to identify both transmission and reception applications, it is possible to execute a plurality of applications at the same time even in a non-network type protocol. In addition, the simplest application can be realized by directly using the transfer service processing unit, and can meet the requirements for road-to-vehicle communication during driving such as high-speed connectivity and low overhead. In addition, when stopped or running at low speed, the transaction management unit makes it easy for applications that require advanced communication services such as sending and receiving large amounts of data and request / response services. You will be able to respond. Further, when the protocol is extended, the extension can be facilitated by localizing the extension point in the transaction management unit. Furthermore, the unit of transmission data is identified by the identifier (transmission data identifier) specified by the application. In addition, when the transmission data unit is larger than the size that can be transmitted at one time by the lower layer protocol, this protocol divides it into the size that can be transmitted, assigns a sequence number, and sends the sequence number on the receiving side. It has the function of assembling originally. At this time, by notifying the transmitting side of the sequence number of the unreceived data when the final data is received, only the unreceived data is retransmitted to improve the communication error rate. Also, if the set of the source application identifier (source port number) and the transmission data identifier specified by the application are the same, the data can be treated as the same data as the data of the same identifier that has already been received on the receiving side. Allows data to be retransmitted at any time. Therefore, even when communication is not possible for a certain period of time, the communication error rate can be improved.

<figref num="1">It is a figure which shows the concept of connection identification in the road-to-vehicle communication system by Embodiment 1 of this invention.</figref><figref num="2">It is a figure which shows the classification of a local port number.</figref><figref num="3">It is a figure which shows the example of the datagram transmission service.</figref><figref num="4">It is a figure which shows the primitive type.</figref><figref num="5">It is a figure which shows the parameter type.</figref><figref num="6">It is a figure which shows the logical relationship of a data transfer service.</figref><figref num="7">It is a figure which shows the definition of a transfer primitive.</figref><figref num="8">It is a figure which shows the logical relationship of the management service interface.</figref><figref num="9">It is a figure which shows the definition of the event notification primitive.</figref><figref num="10">It is a figure which shows the definition of a port generation primitive.</figref><figref num="11">It is a figure which shows the definition of a port discard primitive.</figref><figref num="12">It is a figure which shows the configuration example of the receivable port list.</figref><figref num="13">It is a figure which shows the structural example of the communication control information.</figref><figref num="14">It is a figure which shows the format of the data transfer message.</figref><figref num="15">It is a figure which shows the protocol identifier of LPCP.</figref><figref num="16">It is a figure which shows the format of the message of the event notification.</figref><figref num="17">It is a figure which shows the content of the event code (eventCode).</figref><figref num="18">It is a figure which shows an example of the initial connection procedure of LPCP.</figref><figref num="19">It is a figure which shows an example of the communication termination procedure of LPCP.</figref><figref num="20">It is a figure which shows the message forwarding procedure of LPCP.</figref><figref num="21">It is a figure which shows the processing procedure when DSRC is not connected.</figref><figref num="22">It is a figure which shows the message forwarding procedure when the destination port number is not valid.</figref><figref num="23">It is a figure which shows the concept of LPP.</figref><figref num="24">It is a figure which shows the example of data exchange between transactions in LPP.</figref><figref num="25">It is a figure which shows the example of the data transmission service.</figref><figref num="26">It is a figure which shows the example of the request-response type transaction service.</figref><figref num="27">It is a figure which shows the example of data retransmission.</figref><figref num="28">It is a figure which shows the example of the duplicate reception check.</figref><figref num="29">It is a figure which shows the example of the message division / assembly processing.</figref><figref num="30">It is a figure which shows the example of the selective retransmission process.</figref><figref num="31">It is a figure which shows the example of the retransmission processing of a final packet.</figref><figref num="32">It is a figure which shows the example of the re-execution of a transaction.</figref><figref num="33">It is a figure which shows the example of the transaction discard notification.</figref><figref num="34">It is a figure which shows the primitive type.</figref><figref num="35">It is a figure which shows the parameter type.</figref><figref num="36">It is a figure which shows the argument of an Invoke primitive.</figref><figref num="37">It is a figure which shows the argument of Abort primitive.</figref><figref num="38">It is a figure which shows the Abort Code list when Abort Type = 0 (system error).</figref><figref num="39">It is a figure which shows the argument of the Connect primitive.</figref><figref num="40">It is a figure which shows the argument of the Disconnect primitive.</figref><figref num="41">It is a figure which shows the argument of the RegisterPort primitive.</figref><figref num="42">It is a figure which shows the argument of a DeregisterPort primitive.</figref><figref num="43">It is a figure which shows the PDU type list.</figref><figref num="44">It is a figure which shows the protocol data unit basic structure of a local port protocol.</figref><figref num="45">It is a figure which shows the header information of an Invoke PDU.</figref><figref num="46">It is a figure which shows the header information of the Result PDU.</figref><figref num="47">It is a figure which shows the header information of the Acknowledgement PDU.</figref><figref num="48">It is a figure which shows the header information of Abort PDU.</figref><figref num="49">It is a figure which shows the header information of an Invoke Segment PDU.</figref><figref num="50">It is a figure which shows the header information of the Result Segment PDU.</figref><figref num="51">It is a figure which shows the header information of a Nack PDU.</figref><figref num="52">It is a figure which shows the protocol data unit in the receiveable port list notification.</figref><figref num="53">It is a figure which shows the protocol data unit in the transmission non-transmission port notification.</figref><figref num="54">It is a figure which shows the initial connection procedure of a local port protocol.</figref><figref num="55">It is a figure which shows the example of the initial connection sequence of a high-speed connection application.</figref><figref num="56">It is a figure which shows the processing sequence example of a data transmission transaction service.</figref><figref num="57">It is a figure which shows the example of the basic processing sequence of the request-response type transaction service.</figref><figref num="58">It is a figure which shows the processing sequence example when the Result timer times out.</figref><figref num="59">It is a figure which shows the data transfer procedure (basic sequence) when a retransmission process is effective.</figref><figref num="60">It is a figure which shows the retransmission processing procedure (when retransmission is successful).</figref><figref num="61">It is a figure which shows the retransmission processing procedure (when retransmission fails).</figref><figref num="62">It is a figure which shows the sequence example when the division / assembly process is effective.</figref><figref num="63">It is a figure which shows the sequence example (selective retransmission process) when the division / assembly process is effective.</figref><figref num="64">It is a figure which shows the sequence example (when the last segment is not reached) when the division / assembly process is effective.</figref><figref num="65">It is a figure which shows the procedure at the time of DSRC disconnection.</figref><figref num="66">It is a figure which shows the transaction discard procedure.</figref>