WO2005039075A1 - 路車間通信システム - Google Patents

路車間通信システム Download PDF

Info

Publication number
WO2005039075A1
WO2005039075A1 PCT/JP2004/014490 JP2004014490W WO2005039075A1 WO 2005039075 A1 WO2005039075 A1 WO 2005039075A1 JP 2004014490 W JP2004014490 W JP 2004014490W WO 2005039075 A1 WO2005039075 A1 WO 2005039075A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
data
port
road
vehicle communication
Prior art date
Application number
PCT/JP2004/014490
Other languages
English (en)
French (fr)
Inventor
Masahiko Ikawa
Yukio Goto
Hiroyuki Kumazawa
Yoshiaki Tsuda
Original Assignee
Mitsubishi Denki Kabushiki Kaisha
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mitsubishi Denki Kabushiki Kaisha filed Critical Mitsubishi Denki Kabushiki Kaisha
Priority to JP2005514730A priority Critical patent/JP4396639B2/ja
Priority to CN2004800252613A priority patent/CN1846375B/zh
Priority to US10/568,346 priority patent/US7843869B2/en
Publication of WO2005039075A1 publication Critical patent/WO2005039075A1/ja

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the present invention provides an application service to a mobile station using road-to-vehicle communication performed between a mobile station traveling on a road and a base station device installed on the road. It relates to a road-vehicle communication system.
  • An example of a conventional road-to-vehicle communication system is a standard defined by the Japan Radio Industries and Businesses Association, “Narrow Area Communication (DSRC) System Standard ARIBSTD-T75J (established on September 6, 2001). This standard defines a road-to-vehicle communication method using spot communication with a limited communication zone, and uses an identifier called AID for each application to support multi-applications. You.
  • DSRC Short Area Communication
  • the base station is always the master and the mobile station is the slave, so that only a master-slave type application can be realized, and communication can be started from the mobile station side, or the mobile station can communicate with the base station. It cannot be applied to applications where stations communicate equally.
  • AIDs since only 32 identifiers called AIDs can be specified, there is a problem that it is difficult to cope with an increase in the types of applications.
  • an extended communication control which is a protocol capable of performing bidirectional communication, based on the standard (the short-range communication (DSRC) system standard ARIB STD-T75)
  • the protocol (ASL-ELCP) is deployed, and communication from mobile stations is realized by the base station periodically polling for the presence or absence of communication from mobile stations.
  • an identifier called an access point identifier is defined in the extended communication control protocol (ASL-ELCP), and the standard (the narrow area communication (DSRC) system standard ARIB STD-T75) and the extended communication control protocol (ASL-ELCP) are defined.
  • -ELCP to enable the operation of multiple protocols on the same layer, and use the Internet protocol as one of the multiple protocols.
  • Balta transfer it is possible to send and receive messages up to about 50 kilobytes. Furthermore, in the broadcast communication, the same data is continuously transmitted a plurality of times to realize a low communication error rate (for example, see Non-Patent Document 1).
  • Non-Patent Document 1 Information Processing Society of Japan ITS Workshop, “Implementation and Evaluation of DSRC (ARIB STD-T75 Compliant) System” (2002-ITS-10-10)
  • the present invention has been made in order to solve such a problem, and a road-to-vehicle communication between a mobile station traveling and stopping on a road and a base station apparatus installed on the road is provided.
  • a road-to-vehicle communication system that provides application services to the mobile station using communication, various applications can be executed even while traveling, so that data transfer between a plurality of applications can be performed.
  • It provides a non-network type communication protocol that includes a mechanism for transmitting large-capacity data exceeding 100 kilobytes, and a mechanism that can improve the communication error rate even if communication cannot be performed for a certain period of time. is there.
  • the road-to-vehicle communication system uses the road-to-vehicle communication performed between a mobile station traveling on a road and a base station device installed on the road to provide the mobile station with the mobile station.
  • a transfer service processing unit that provides a mechanism for data transfer between multiple applications, a retransmission mechanism for undelivered data, and a message unit
  • a transaction management unit that provides unidirectional data transmission and request-response-type transaction services.
  • the road-to-vehicle communication system is a system in which local applications in both the base station device and the mobile station communicate using a non-network type protocol. Since it is composed of the transfer service processing section and the transaction management section, various applications can be executed even during traveling. Further, even when communication cannot be performed for a certain period of time, the communication error rate can be improved.
  • the transfer service processing unit and the transaction management unit are configured independently of each other, it is possible to realize the simplest application by directly using the transfer service processing unit, such as high-speed connectivity and low overhead. It can satisfy the requirements for road-to-vehicle communication during driving. Furthermore, when a protocol is extended, the extension point can be locally located in the transaction management unit, and the extension can be performed easily.
  • the transfer service processing unit uses a port number to identify both the transmitting 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 sufficiently cope with the increase of application types in the future.
  • the unit of transmission data is also identified by the specified identifier (transmission data identifier) of the application.
  • transmission data identifier transmission data identifier
  • this protocol when the transmission data unit is larger than the size that can be transmitted at a time in the lower layer protocol! / ⁇ , it is divided into transmittable sizes, transmitted with a sequence number, and transmitted on the receiving side. Based on the sequence number Has a function to stand.
  • the transmitting side notifies the transmitting side of the sequence number of the unreceived data when the final data is received, and the transmitting side retransmits only the unreceived data. Thereby, the communication error rate can be improved.
  • the transmitting side can retransmit data at an arbitrary timing, and can improve the communication error rate even when communication cannot be performed for a certain period of time.
  • FIG. 1 is a diagram showing a concept of connection identification in a road-to-vehicle communication system according to Embodiment 1 of the present invention.
  • FIG. 2 is a diagram showing classifications of local port numbers.
  • FIG. 3 is a diagram showing an example of a datagram transmission service.
  • FIG. 4 is a diagram showing primitive types.
  • FIG. 5 is a diagram showing parameter types.
  • FIG. 6 is a diagram showing a logical relationship of a data transfer service.
  • FIG. 7 is a diagram showing a definition of a transfer primitive.
  • FIG. 8 is a diagram showing the logical relationship of the management service interface.
  • FIG. 9 is a diagram showing definitions of event notification primitives.
  • FIG. 10 is a diagram showing a definition of a port generation primitive.
  • FIG. 11 is a diagram showing a definition of a port discard primitive.
  • FIG. 12 is a diagram showing a configuration example of a receivable port list.
  • FIG. 13 is a diagram illustrating a configuration example of communication control information.
  • FIG. 14 is a diagram showing a format of a data transfer message.
  • FIG. 15 is a diagram showing a protocol identifier of LPCP.
  • FIG. 16 is a diagram showing the format of an event notification message.
  • FIG. 17 is a diagram showing the contents of an event code (eventCode).
  • FIG. 18 is a diagram showing an example of an initial connection procedure of LPCP.
  • FIG. 19 is a diagram showing an example of an LPCP communication termination procedure.
  • FIG. 20 is a diagram showing an LPCP message transfer procedure.
  • FIG. 21 is a diagram showing a processing procedure when the DSRC is not connected.
  • FIG. 22 is a diagram showing a message transfer procedure when a destination port number is not valid.
  • FIG. 23 is a diagram showing the concept of LPP.
  • FIG. 24 is a diagram showing an example of data exchange between transactions in LPP.
  • FIG. 25 is a diagram showing an example of a data transmission service.
  • FIG. 26 is a diagram showing an example of a request'response type transaction service.
  • FIG. 27 is a diagram illustrating an example of data retransmission.
  • FIG. 28 is a diagram showing an example of duplicate reception check.
  • FIG. 29 is a diagram showing an example of message division / assembly processing.
  • FIG. 30 is a diagram illustrating an example of a selective retransmission process.
  • FIG. 31 is a diagram illustrating an example of retransmission processing of the last packet.
  • FIG. 32 is a diagram showing an example of re-executing a transaction.
  • FIG. 33 is a diagram showing an example of a transaction discard notification.
  • FIG. 34 is a diagram showing primitive types.
  • FIG. 35 is a diagram showing parameter types.
  • FIG. 36 is a diagram showing arguments of an Invoke primitive.
  • FIG. 37 is a diagram showing bow I numbers of Abort primitives.
  • FIG. 39 is a diagram showing arguments of a Connect primitive.
  • FIG. 40 is a diagram showing arguments of a Disconnect primitive.
  • FIG. 41 is a diagram showing arguments of RegisterPort primitive.
  • FIG. 42 is a diagram showing arguments of a DeregisterPort primitive.
  • FIG. 43 is a diagram showing a PDU type list.
  • FIG. 44 is a diagram showing a basic structure of a protocol data unit of a local port protocol.
  • FIG. 45 is a diagram showing header information of an Invoke PDU.
  • FIG. 46 is a diagram showing header information of a Result PDU.
  • FIG. 47 is a diagram showing header information of an Acknowledgement PDU.
  • FIG. 48 is a diagram showing Abort PDU header information.
  • FIG. 49 is a diagram showing header information of an Invoke Segment PDU.
  • FIG. 50 is a diagram showing header information of a Result Segment PDU.
  • FIG. 51 is a diagram showing Nack PDU header information.
  • FIG. 52 is a diagram showing a protocol data unit in a receivable port list notification.
  • FIG. 53 is a diagram showing a protocol data unit in a transmission impossible port notification.
  • FIG. 54 is a diagram showing an initial connection procedure of a local port protocol.
  • FIG. 55 is a diagram showing an example of an initial connection sequence of the high-speed connection application.
  • FIG. 56 is a diagram showing a processing sequence example of the data transmission transaction service.
  • FIG. 57 is a diagram showing an example of a basic processing sequence of a request'response-type transaction service.
  • FIG. 58 is a diagram showing an example of a processing sequence when a Result timer times out.
  • FIG. 59 is a diagram showing a data transfer procedure (basic sequence) when retransmission processing is valid.
  • FIG. 60 is a diagram showing a retransmission processing procedure (when retransmission is successful).
  • FIG. 61 is a diagram showing a retransmission processing procedure (when retransmission fails).
  • FIG. 62 is a diagram showing an example of a sequence in a case where a 'split' assembly process is valid.
  • FIG. 63 is a diagram showing a sequence example (selective retransmission processing) in a case where the splitting / assembling processing is valid.
  • FIG. 64 is a diagram showing an example of a sequence in a case where the splitting / assembling process is valid (when the final segment has not been reached).
  • FIG. 65 is a diagram showing a procedure at the time of DSRC disconnection.
  • FIG. 66 is a diagram showing a transaction discarding procedure.
  • FIG. 1 is a diagram showing connection knowledge in a road-to-vehicle communication system according to Embodiment 1 of the present invention. It is a figure showing another concept.
  • FIG. 3 is a diagram showing an outline of a 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.
  • the communication protocols used in the base station equipment and mobile stations are the short-range communication (DSRC) protocol (ARIB STD-T75), the extended communication control protocol (ASL-ELCP), which is a bidirectional communication protocol, and It has a hierarchical structure consisting of a transfer service processing unit (Local Port Control Protocol (LPCP)) and a transaction management unit (Local Port Protocol (LPP)). Runs multiple applications.
  • DSRC short-range communication
  • ASL-ELCP extended communication control protocol
  • LCP transfer service processing unit
  • Local Port Protocol LDP Protocol
  • the transfer service processing unit is a control protocol for multiplexing applications on the short range communication (DSRC) protocol (ARIB STD-T75) and the extended communication control protocol (ASL-ELCP), and realizes multi-applications. It has the minimum functions to perform
  • the transaction management unit is a communication protocol interposed between the transfer service processing unit and the application to extend the communication service of the transfer service processing unit, and provides a more advanced communication service such as large-capacity data communication to the application. provide.
  • the transfer service processing unit and the transaction management unit will be described in detail.
  • Transfer service processing unit (local port control protocol)
  • the Local Port Control Protocol provides a data transfer service for data transfer and a management service for management control to higher-level protocols such as applications in order to provide communication means for non-network applications. Control protocol.
  • the transfer service processing unit identifies the source and destination applications using an identifier called a local port number. It also provides data transfer and management services for upper layer protocols such as the application management unit, which is the upper layer application. Provide service primitives (interfaces) for Furthermore, it has control information for realizing the data transfer service and management service as internal data, and adds various control services to the data (PDU) exchanged between the road and vehicle transfer service processing units to provide various services. Realized.
  • the local port control protocol uses the local port number as an access point to identify the application on the LPC P as shown in Fig. 1.
  • the connection between the application and each other is identified for each application using a set of vehicle ID (link address, etc.) and local port number.
  • 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 specifies the local port number as follows. 0—OxOFFF is a reserved number port, OxlOOO—OxF FFF is an optional port.
  • 0—OxOFFF is a reserved number port
  • OxlOOO—OxF FFF is an optional port.
  • the relationship between the application and the local port number specified in the previous section will be described.
  • the form of the application is based on the client Z server model and the peer-to-peer model. Therefore, in the client Z server model, the port of the server process, which is globally unique, is a number reserved port, and the port of the client process, which is unique in the office, is an arbitrary port. Also, in the peer-to-peer model, it is basically that both processes use the number reservation port. For your own app
  • Any port can be used with the server and the client.
  • the rules for setting the local port number follow the rules below. (1)
  • the reservation numbers must be numbered globally without duplication.
  • An application can have multiple receiving ports.
  • each application shall use the reception port number so that there is no duplication within the station.
  • the source port can be omitted.
  • FIG. 3 is a diagram showing an example of a datagram transmission service.
  • DSRC The configuration of local port applications in ASL has a hierarchical structure in which multiple applications exist on LPCP, and LPCP needs to identify the application to which data is to be transferred.
  • the LPCP location, the source and destination port numbers are assigned, and the destination of the data is determined based on this.
  • the communication service provided by LPCP is a high-speed, low-overhead, connectionless datagram transmission service.
  • the specific operation between LPCP and an application (upper layer protocol) is as follows. is there.
  • the application (upper layer protocol) passes the transmission data, link address, and transmission / reception port number to LPCP, which generates the information LPCP datagram and transmits it to the other party.
  • a service that transparently notifies the application of its own station of error events (such as notification of communication connection and non-connection) notified by the management service of ASL-ELCP (Extended Communication Control Protocol).
  • FIG. 4 shows a list of primitive types defined in the present invention
  • FIG. 5 shows a list of parameter types used in the primitive definition table.
  • Figure 6 shows the logical relationship of the data transfer service.
  • the local port control protocol provides the following one type of primitive for the application (or upper layer protocol) as a data transfer service.
  • Link Address DSRC LID used in this transmission or an ID that can be mapped one-to-one with the LID
  • Source Port Port number of the source application Destination Port: Port number of destination application
  • Figure 8 shows the logical relationship of the management service interface.
  • the local port control protocol provides the following three types of primitives for the application (or upper layer protocol) as a management service.
  • Event Report Event notification primitive
  • This primitive is used to report event occurrences and errors to non-IP applications and upper layer protocols.
  • ASL There are two types of events: those that transparently transmit events notified by the ELCP management service to the local port protocol and those that transparently transmit the notification of the management service of the partner station.
  • Figure 9 shows the definition of the event notification primitive. In FIG.
  • Link Address Specify the (medium) LID used by the notification partner.
  • Event Code The state identifier (Fig. 17) is stored as the event code.
  • Extention Parameter Additional event information corresponding to each event code.
  • This primitive is used to generate a data and event reception port for LPCP.
  • Figure 10 shows the definition of the port generation primitive.
  • Port Port number for which notification is requested
  • Type Specify the type of primitive that needs to be notified
  • This primitive is used to discard the receiving port generated by the port generation primitive.
  • FIG. 11 is a diagram showing the definition of the port discard primitive.
  • Port Port number to be discarded
  • the LPCP management service manages communication parameters used in LPCP.
  • the LPCP management service manages the following information.
  • Fig. 12 shows a configuration example of the receivable port list.
  • ASL—ELC P communication control and management information Add to the list when DSRC connection notification is received, and delete from the list when DSRC disconnection notification is received.
  • Fig. 13 shows a configuration example of the communication control information.
  • Primitive Type Primitive type to receive
  • Event Code Type of event code to be received
  • Equipment ID OBE-specific information
  • protocol data unit (PDU) of LPCP used in the datagram transmission service and the management service will be described.
  • the LPCP PDU consists of the local port control protocol header and the application data part.
  • Figure 14 shows the format of the LPCP PDU used in the datagram transmission service.
  • Access point identifier An identifier for identifying a network control protocol. Always store local Port Control (1).
  • Protocol identifier Indicates 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 destination application
  • Length of user data section indicates the data length of the following user data section.
  • the unit is octet.
  • the size of this area is extended according to the ASN.1 encoding rule. If there is no user data to add (NULL), 0 is specified in this area.
  • the maximum length of data that can be passed to the LPCP power S ASL-ELCP and the maximum transmission unit (MTU) of the LPCP are 522 octets (including access control information).
  • Content of user data part Transmission data body. Stores OCTET STRING type undefined length data.
  • FIG. 15 is a diagram showing an LPCP protocol identifier.
  • FIG 16 shows the format of the LPCP PDU used in the management service.
  • the PDU shown below is used to send an event notification to the partner station's LPCP.
  • FIG. 16 is a diagram showing the format of an event notification message.
  • Access point identifier An identifier for identifying a network control protocol. Always store local Port Control (1). Protocol identifier: Indicates the PDU type. The management service always stores event Report (1).
  • Event code an identifier indicating the content of an event that has occurred. 0 to 127 are communication control protocol state identifiers, and 128 to 255 are LPCP state identifiers. FIG. 17 is a diagram showing the contents of an event code.
  • Length of event additional information Indicates the data length of the subsequent event additional information.
  • the unit is octet.
  • the size of this area is extended according to the ASN.1 encoding rule. If there is no event information (NULL), a value of 0 is specified in this area.
  • Content of event additional information Content of event additional information. Stores OCTET STRING type undefined length data.
  • a request for notification of DSRC connection is made in advance to the application power LPCP using a port generation primitive.
  • Figure 18 shows an example of the processing sequence when connecting to DSRC.
  • a request for DSRC disconnection notification is made in advance to the application power LPCP using the port generation primitive.
  • FIG. 19 shows an example of a processing sequence at the end of communication.
  • Event Report Ind
  • Event Report indicates that the destination local port is not valid for the source local port number specified in the event additional information of the message. , ".
  • this procedure assumes that an event notification request has been made by the local port generation primitive. If no event notification request has been made, event notification to the upper layer protocol is not performed. The presence / absence of event notification is determined from the receivable local port list.
  • 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) and the status identifier is “The destination port is not valid ( 129)), and sends it to the partner station using the ASL-ELCP data transfer primitive, completing the receiving process.
  • 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 receiving process is completed.
  • Fig. 20 shows an example of the basic processing sequence for message transfer
  • Fig. 21 shows an example of the processing sequence when DSRC is connected
  • Fig. 22 shows an example of the processing sequence when the destination local port number is valid. Is shown.
  • the Local Port Protocol is located between the Local Port Control Protocol (LPCP) and non-network applications, extends the functions of the Local Port Control Protocol, and enables non-
  • This transaction-oriented protocol aims to improve the efficiency of application construction by providing the following transaction services and connection management services for system applications (see Figure 23).
  • This protocol is a communication of the local port control protocol. It consists of a transaction service processing unit that expands functions 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.
  • the transaction management unit provides service primitives (interface with the application) for using the above functions to the application. Furthermore, in order to realize the above functions, the structure of data (PDU) exchanged between the transaction management units of road and vehicle is specified.
  • the sender adds control information according to the function requested by the service primitive (or an event generated inside the transaction management unit), and the receiver analyzes and uses the control information added to the PDU. This realizes the above function.
  • FIG. 24 is a diagram showing an example of data exchange between transactions in LPP.
  • the transaction ID numbering system is as follows.
  • the first bit indicates the start side of the transaction (0 on the vehicle side, 1 on the road side).
  • This protocol provides the following two types of transaction services.
  • the required level is used according to the communication requirements of each application, and the optimal communication service can be used for each application.
  • FIG. 25 is a diagram showing an example of a data transmission service.
  • Fig. 26 is a diagram showing an example of the request'response type transaction service.
  • This function is to ensure the reliability of communication, and controls retransmission by using a retransmission timer and a retransmission counter.
  • Retransmission is performed when the retransmission timer times out (below the maximum number of retransmissions) to ensure communication reliability (see Figure 27). It can be applied to data transmission and reply, and the application specifies whether to apply. The processing sequence Shown below.
  • FIG. 27 is a diagram illustrating an example of data retransmission.
  • the retransmission power counter is incremented and the packet is retransmitted.
  • FIG. 28 is a diagram showing an example of the duplicate reception check.
  • This function enables the application to provide a message transmission interface that exceeds the MTU of LPCP by performing message division and assembly processing.
  • FIG. 29 shows the procedure of message communication using the splitting / assembling function.
  • the LPP receives a message that exceeds the LPCP MTU from the application, the LPP divides the PDU into the size of the LPCP MTU within the LPP and operates to sequentially pass it to the LPCP.
  • the packets thus divided are accumulated in the transmission queue of DSRC-ASL, and are sequentially transferred to Layer 7.
  • LPP guarantees that all packets are transmitted by retransmitting the failed packets and performing flow control. .
  • the receiving side sequentially fetches the divided packets passed from the LPCP and stacks them in the receiving queue prepared by the application on the receiving side. 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. Assemble. After receiving all the packets, the receiving side returns an acknowledgment to the transmitting side. [0043] Also, DSRC-guarantees that all transmitted packets will reach the LPP of the partner station due to the possibility of packet loss due to reception queue overflow in ASL or data loss in DSRC. There is no. In this case, the missing data of one packet will cause the data of the entire S message to be lost.
  • FIG. 30 shows an example of the selective retransmission processing.
  • FIG. 32 shows an example of transaction re-execution processing.
  • the application can request that the transaction be discarded (see Figure 33).
  • the following processing is performed according to the state of the transaction at the time of the request.
  • FIG. 33 is a diagram showing an example of a transaction discard notification. Also,
  • the destination port is not a receivable port.
  • connection management service provides the following services to the application to provide the application with a trigger to start and end communication.
  • the receivable port numbers owned by the partner station are managed, and their status is reported or a certain port is requested in response to application requirements.
  • connection management service has the same position as the application on the local port control protocol, and the transmission and reception of events between road and vehicle connection management services uses the data transfer service of the local port control protocol.
  • the port number used by the connection management service will be OxOFFF for the time being.
  • Receivable port The partner station has opened this port as a data receiving port port.
  • Unknown port A port that does not know whether the partner station has opened this port as a data reception port. This is the initial state.
  • the receivable port inquiry service includes a reference service that immediately answers the status of the port at the time of inquiry and a wait until the inquired port becomes a receivable port.
  • Two types of services are provided: a notification service that issues a notification when a notification is received (it is already determined that the combined port is a receivable port, and if this is the case, it responds immediately).
  • the local port protocol management service between the road and the vehicle requires that the local station be able to receive the port number that the local station can receive or the port cannot be received when the DSRC communication connection or the receivable port is changed. It has the function of notifying the port number.
  • FIG. 34 shows a list of primitive types defined in the present invention.
  • FIG. 35 shows a list of parameter types used in the primitive definition table in the present invention.
  • LPP As a transaction service, LPP prepares the following two types of primitives for applications.
  • the Invoke primitive is a new primitive for generating a transaction. All transactions are started by issuing this primitive.
  • ⁇ iI
  • FIG. 36 is a diagram showing the bow
  • Source Port Port number of the source application
  • Transmission data size (in octets)
  • Transaction Type Transaction service type
  • Require Ack Flag for whether to enable retransmission processing (0: retransmission processing not required, 1: retransmission processing required)
  • Result Timeout Time-out period until receiving the Result PDU in the request 'response type transaction service. If no Result PDU is received by this time after Invoke, req is issued, this transaction is discarded.
  • Handle ID to identify the transaction locally. Specified by the application. Handle specified here must satisfy the following conditions. On the issuer side of Invoke and req, Handle and Source Port must be able to be uniquely specified by the transaction ID. The issuer of Invoke and res must be able to specify LinkAddress, Source Port, and transaction ID by Handle. If the same Handle is specified in the broadcast that was executed immediately before, it is treated as a transaction re-execution request.
  • Abort primitive is a primitive to abort the transaction being created.
  • FIG. 37 shows the arguments of the Abort primitive.
  • Abort Type Indicates whether the abort reason is a system error (0) or a user request (1).
  • Abort Code Indicates the reason the transaction was aborted. (See Figure 38 for details on system errors.)
  • LPP As a connection management service, LPP prepares the following four types of primitives for applications.
  • Connect and req primitives are used to query whether a transaction can be started.
  • the Connect, cnf primitive is a primitive for notifying the inquiring application of the DSRC connection, the LID, and the receivable port number of the partner station (indicated by the LID) in response to the inquiry by Connect, req.
  • Figure 39 shows the Connect primitive bow
  • Querist Port The port number of the inquiry source used to identify the application that made the inquiry.
  • Query LID LID to query.
  • LID LID to query.
  • it is handled as an inquiry for the already connected link.
  • if there is no designation it is treated as waiting for a new connection.
  • Connect cnf is issued immediately after DSRC connection (high-speed connection).
  • the connection ct.cnf is issued (normal connection).
  • Connected LID If a Query LID is specified and the LID is connected, the same LID as the Query LID is specified. If the Query 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.
  • FIG. 40 shows the arguments of the Disconnect primitive.
  • the Register Port primitive is a primitive for registering a receiving port with LPP.
  • Figure 41 shows the bow
  • the Deregister Port primitive is a primitive for deleting a receiving port for LPP.
  • FIG. 42 is a diagram showing arguments of the DeregisterPort primitive.
  • the PDU used in the transaction service consists of a header part defined for each PDU type and a data part that stores application data.
  • Figure 44 shows the basic structure of the PDU.
  • FIG. 45 shows the header information of the Invoke PDU.
  • PDU Type PDU type. Invoke (1) for Invoke PDUs.
  • Version Indicates the version of the local port protocol.
  • the current version is 0x00.
  • TT Transaction Type. Specify the type of transaction. 0: Data transmission transaction service, 1: Request / response type transaction service.
  • RA Require Ack. Flag indicating whether retransmission processing is enabled. 1 when retransmission processing is enabled.
  • RD Retransmitted Data. Flag indicating whether the data was retransmitted. 1 when resending.
  • TID Transaction ID.
  • FIG. 46 shows the header information of the Result PDU.
  • PDU Type PDU type. Result (2) is always used for Result PDU.
  • RA Require Ack. Flag indicating whether retransmission processing is enabled. 1 when retransmission processing is enabled.
  • RD Flag indicating whether the data has been retransmitted. 1 when resending.
  • TID Transaction ID.
  • FIG. 47 is a diagram showing header information of the Acknowledgement PDU.
  • PDU Type PDU type. Ack (3) for Acknowledgement PDU.
  • RD Flag indicating whether the data has been retransmitted. 1 when resending.
  • TID Transaction ID.
  • FIG. 48 is a diagram showing the header information of the Abort PDU.
  • PDU Type PDU type. Abort (4) for Abort PDUs.
  • TID Transaction ID.
  • Abort Code Specify the reason for aborting the transaction as a code. (See Figure 38) RES: Reserved.
  • FIG. 49 shows the header information of the Invoke Segment PDU.
  • PDU Type PDU type. Invoke Segment PDU always uses Invoke Sgm (
  • Version Indicates the version of the local port protocol.
  • the current version is 0x00.
  • TT Transaction Type. Specify the type of transaction. 0: Data transmission transaction service, 1: Request / response transaction service.
  • FIN Flag indicating whether or not the last segment. 1 for the last segment.
  • RD Retransmitted Data. Flag indicating whether the data was retransmitted. 1 when resending.
  • TID Transaction ID.
  • FIG. 50 is a diagram showing the header information of the Result Segment PDU.
  • PDU Type PDU type. ResultSgm (6) is always used for ResultSegmentPDU.
  • FIN Flag indicating whether or not the last segment. 1 for the last segment.
  • RD Flag indicating whether the data has been retransmitted. 1 when resending.
  • TID Transaction ID.
  • FIG. 51 is a diagram showing the header information of the Nack PDU.
  • PDU Type PDU type. Nack (7) for Nack PDUs.
  • RD Flag indicating whether or not the data has been retransmitted.
  • TID Transaction ID.
  • Segment Number List List of sequence numbers of unreceived PDUs
  • connection management service of the local port protocol can use the transfer service of the local port control protocol for the connection management service of the partner station when a new DSRC connection is made or when the number of receivable ports increases or decreases. Notify the port list and unreceivable ports.
  • the PDU shown below is a protocol data unit used for these notifications, and is stored in the user data part of the local port control protocol.
  • FIG. 52 is a diagram showing a protocol data unit in the receivable port list notification. Status: Indicates the type of event. Accept Port for notification of the list of available ports
  • Accept Port List Stores a list of receivable port numbers.
  • FIG. 53 is a diagram showing a protocol data unit in the transmission disabled port notification. Status: Indicates the type of event. In the case of notification of a port that cannot be received, rejectPort (2) is always stored.
  • Reject Port Store the port number that cannot be received.
  • FIG. 54 is a diagram showing an initial connection procedure of the local port protocol.
  • Each application of the mobile station and the base station registers a receivable port number in the LPP using a port registration primitive (Register Port).
  • a port registration primitive (Register Port).
  • the LPP updates the connection management table, and registers the receivable port number and the connection management service port registered in (a) as a data reception port in the LPCP. Also, the management service port is registered in the LPCP as an event reception port.
  • Each application specifies the Query LID parameter, specifies the Query Port parameter, issues a DSRC connection inquiry primitive (Connect, req), and waits for the DSRC connection (blocking call).
  • connection management service of LPP receives the event “DSRC connection notification (96)” from LPCP with the event notification primitive (Event Report).
  • the LPP connection management service creates a connection management table for the LID received by the primitive and transmits a list of receivable ports to the connection management service port of the partner station.
  • LPP connection management service capability LPCP capability is also a data transfer primitive (Send Unit)
  • Send Unit When receiving the receivable port list in (Data, ind), the receivable port is registered in the connection management table of the LID notified by the primitive. Thereafter, a transaction start request for the same LID is accepted only for this receivable port.
  • the application issues 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, and the transaction starts. Is started.
  • High-speed connection is a technique for achieving high-speed initial connection by omitting some processing for initial connection.
  • FIG. 55 is a diagram showing an example of an initial connection sequence of the high-speed connection application.
  • Each application of the mobile station and the base station registers a receivable port number in the LPP using a port registration primitive (Register Port).
  • a port registration primitive (Register Port).
  • LPP updates the connection management table and registers the receivable port number in LPCP.
  • Each application does not specify both QueryLID and Query Port, issues a transaction start query primitive (Connect, req), and waits for DSRC connection.
  • LPP creates a connection management table for the LID received by the primitive. Since this application requires a high-speed connection, transactions for all ports with this LID and broadcast address will be received from the LPP connection management service of the partner station until the receivable port list of the partner station is received. Accept start request.
  • Figure 56 shows a processing sequence example of the data transfer procedure of the data transmission transaction service.
  • the application issues a response primitive (Invoke, res) and requests the LPP to send a response.
  • a response primitive Invoke, res
  • Fig. 57 shows an example of the basic processing sequence of the request 'response type transaction service
  • Fig. 58 shows an example of the processing sequence when the Result timer times out.
  • the sequence when retransmission processing is applied to Invoke and req of the data transmission transaction is described below. In the request / response type transaction service, the same processing can be applied to Invoke and res.
  • FIG. 59 shows an example of a processing sequence when retransmission processing is valid
  • FIG. 60 shows an example of a processing sequence when retransmission is successful
  • FIG. 61 shows an example of a processing sequence when retransmission processing fails.
  • the splitting / assembling process is applied when a message exceeding the MTU is specified in Invoke, req and Invoke, res.
  • the sequence in the case where the splitting / assembling process is applied to Invoke and req is described.
  • the application specifies a message with a size larger than the MTU and issues a transaction start request primitive (Invoke, req) to start a transaction of the data transmission service in which the segmentation / assembly processing is valid.
  • a transaction start request primitive Invoke, req
  • the transmission data is divided by the MTU in order from the first packet, and an Invoke Segment PDU (see 2.2.4.1.5) is divided for each divided segment.
  • a header according to the regulations is added, and a sequential transmission request is made using the LPCP transfer primitive (TransferData. Req).
  • Fig. 62 shows an example of the basic processing sequence when the split / assembly process is valid
  • Fig. 63 shows an example of the processing sequence when a part of the split data is missing and selective retransmission is performed.
  • FIG. 65 is a diagram showing a procedure at the time of DSRC disconnection.
  • an application can request that a transaction be discarded when the transaction is in the following states.
  • FIG. 66 is a diagram showing a transaction discarding procedure.
  • the 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 (TmnsferData. req).
  • the LPP uses the LPCP transfer notification primitive (TransferData.
  • TransferData When receiving U, if a transaction specified by the TID of the same PDU is being executed in the local station, all resources related to the transaction are discarded, and the application is notified of the transaction discard notification primitive (Abort, ind ) To notify the transaction discard.
  • the short-range communication (DSRC) protocol (ARIB STD-T75)
  • the extended communication control protocol (ASL-ELCP) that is a bidirectional communication protocol
  • the transfer service processing unit instead of the extended communication control protocol (ASL-ELCP) showing a hierarchical structure composed of the (LPCP) and the transaction management unit (LPP), another protocol capable of bidirectional communication may be used.
  • the road-to-vehicle communication system is a system in which local applications in both the roadside system and the mobile station communicate using a non-network type protocol.
  • a road-to-vehicle communication system is a system in which a local application in a roadside system and a local application in a mobile station communicate using a non-network type protocol. It provides a unidirectional data transmission and request / response type transaction service with a transfer service processing unit, a retransmission mechanism for unreached data, a data transmission / reception mechanism for each message, and a message division / assembly mechanism.
  • Transaction management unit that provides transaction services And said that you configure.
  • a port number is used to identify both transmitting and receiving applications, thereby enabling simultaneous execution of a plurality of applications even in a non-network type protocol.
  • the simplest application can be realized by directly using the transfer service processing unit, and can satisfy the requirements for road-to-vehicle communication during traveling, such as high-speed connectivity and low overhead.
  • the transaction management unit can be used to transmit and receive large amounts of data and applications that require advanced communication services such as request-response services. Can also be easily handled.
  • the extension location is locally mapped to the transaction management unit. This can facilitate expansion.
  • the unit of transmission data is identified by the identifier (transmission data identifier) specified by the application. Also, if the transmission data unit is larger than the size that can be transmitted at a time in the lower layer protocol, this protocol divides the data into transmittable sizes, attaches them to a sequence number, and transmits them. It has a function to assemble based on numbers. At this time, when the last data is received, the transmission side is notified of the sequence number of the unreceived data, so that only the unreceived data is retransmitted, thereby improving the communication error rate.
  • the identifier transmission data identifier
  • the receiving side treats it as the same data as the data of the same identifier already received on the receiving side. In addition, it is possible to retransmit data at any timing. Therefore, even when communication cannot be performed for a certain period of time, the communication error rate can be improved.

Abstract

　道路上を走行する移動局と、道路上に設置された基地局装置との間で行われる路車間通信を利用して、移動局に対して応用サービスを提供する路車間通信システムにおいて、走行中においても様々なアプリケーションを実行可能なメカニズムを備えた非ネットワーク型の通信プロトコルを提供することを目的とする。 　この発明の路車間通信システムは、複数のアプリケーション間のデータ転送のためのメカニズムを提供する転送サービス処理部、及び未達データの再送信機構と、メッセージ単位のデータ送受信機構と、メッセージの分割・組立機構とを有し、単方向のデータ送信とリクエスト・レスポンス型のトランザクションサービスを提供するトランザクション管理部から構成される。

Description

明 細 書
路車間通信システム
技術分野
[0001] この発明は、道路上を走行する移動局と、道路上に設置された基地局装置との間 で行われる路車間通信を利用して、前記移動局に対して応用サービスを提供する路 車間通信システムに関するものである。
背景技術
[0002] 従来の路車間通信システムの一例としては、社団法人 電波産業会にて定められ た標準規格「狭域通信 (DSRC)システム標準規格 ARIBSTD-T75J (平成 13年 9 月 6日 策定）が知られて 、る。この標準規格は通信ゾーンを限定したスポット通信に よる路車間通信方式を定めたものであり、アプリケーション毎に AIDとよばれる識別 子を用いることでマルチアプリケーションに対応して 、る。
し力しながら、前記従来技術では、常に基地局がマスター、移動局がスレーブであ り、マスター 'スレーブ型のアプリケーションしか実現できず、移動局側から通信を起 動したり、移動局と基地局が対等に通信するようなアプリケーションには適用できなか つた。また、この AIDと呼ばれる識別子は 32個しか規定できないため、アプリケーショ ンの種類が増大した場合に対応が困難であるという問題もあった。さらに、一度に送 受信可能なデータサイズが、数百バイト程度と小さぐ数十キロバイト以上の大容量の データ通信を必要とするアプリケーションに利用することは困難であった。
[0003] これらの課題を解決するための手法の一例として、前記標準規格 (狭域通信 (DSR C)システム標準規格 ARIB STD— T75)上に、双方向に通信可能なプロトコルで ある拡張通信制御プロトコル (ASL - ELCP)を配置し、基地局が定期的に移動局か らの通信の有無をポーリングすることで、移動局からの通信を実現している。さらに、 前記拡張通信制御プロトコル (ASL— ELCP)にアクセス点識別子と呼ばれる識別子 を定義し、前記標準規格 (狭域通信 (DSRC)システム標準規格 ARIB STD-T7 5)と前記拡張通信制御プロトコル (ASL-ELCP)とからなる階層上に複数のプロトコ ルの動作を可能とし、この複数のプロトコルの一つとしてインターネットプロトコルを利 用することで、マルチアプリケーションへの対応を実現している。また、バルタ転送とよ ばれる分割 ·組立機構を有することで、最大で 50キロバイト程度のメッセージの送受 信が可能である。さらに、同報通信においては、同一データを複数回連続して送信 することで通信の誤り率を小さく抑えることを実現している（例えば、非特許文献 1参 照。）。
[0004] 非特許文献 1：情報処理学会 ITS研究会「DSRC (ARIB STD— T75準拠)システム の実装及び評価」（2002-ITS— 10-10)
発明の開示
発明が解決しょうとする課題
[0005] し力しながら、前記従来技術においては、マルチアプリケーションを実現するために 、前記拡張通信制御プロトコル (ASL - ELCP)上で、ネットワーク型のプロトコルであ るインターネットプロトコルを利用するため、 IPアドレスの割当や TCPのセットアップに 要する時間などの初期接続に係わるオーバヘッドの問題から、走行中のアプリケー シヨンに対して適用が困難であるという問題があった。また、同様の問題により、走行 中に送信するデータサイズが 100キロノイトを超えるようなアプリケーションへの適用 は依然として困難であった。さらに前記バルタ転送機能では、データを単に分割して いるだけなので、分割データの再送を下位レイヤである DSRCに依存しており、 DSR C通信以外の理由で欠落したデータへの対応に問題があった。また、シャドーイング や電波が弱いなど、所定の時間通信不可能な領域では、再送した個々のデータや 連送したデータすべてが欠落する可能性があるため、誤り率を改善できないという問 題があった。
[0006] 本発明はカゝかる問題点を解決するためになされたもので、道路上を走行及び停止 する移動局と、前記道路上に設置された基地局装置との間で行われる路車間通信を 利用して、前記移動局に対して応用サービスを提供する路車間通信システムにお 、 て、走行中においても様々なアプリケーションを実行可能とするため、複数のアプリケ ーシヨン間のデータ転送のためのメカニズムと、 100キロバイトを超えるような大容量 のデータ送信のメカニズムと、一定時間通信できない場合においても、通信誤り率を 改善可能なメカニズムとを備えた非ネットワーク型の通信プロトコルを提供するもので ある。
課題を解決するための手段
[0007] この発明に係る路車間通信システムは、道路上を走行する移動局と、前記道路上 に設置された基地局装置との間で行われる路車間通信を利用して、前記移動局に 対して応用サービスを提供する路車間通信システムにお ヽて、複数のアプリケーショ ン間のデータ転送のためのメカニズムを提供する転送サービス処理部、及び未達デ 一タの再送信機構と、メッセージ単位のデータ送受信機構と、メッセージの分割'組 立機構とを有し、単方向のデータ送信とリクエスト 'レスポンス型のトランザクションサ 一ビスを提供するトランザクション管理部を備えるものである。
発明の効果
[0008] この発明に係る路車間通信システムは、基地局装置および移動局内の双方のロー カルアプリケーションが非ネットワーク型のプロトコルを利用して通信を行うシステムで あり、前記非ネットワーク型のプロトコルを、転送サービス処理部とトランザクション管 理部とで構成したので、走行中にぉ 、ても様々なアプリケーションが実行可能となる 。また、一定時間通信できない場合においても、通信誤り率が改善可能となる。
[0009] また、転送サービス処理部とトランザクション管理部とをそれぞれ独立した構成とし たため、最も単純なアプリケーションでは転送サービス処理部を直接使用することで 実現が可能であり、高速接続性、低オーバヘッドといった走行中の路車間通信に必 要な要件を満たすことができる。さらに、プロトコルを拡張する際には拡張箇所をトラ ンザクシヨン管理部に局所ィ匕でき、拡張を容易に行うことができる。
[0010] 転送サービス処理部においては、送受信双方のアプリケーションを識別するために ポート番号を利用する。これにより複数のアプリケーション間のデータ転送が実現で きる。また、このポート番号は 65536種類あり、今後のアプリケーション種類の増大に も十分に対応が可能である。
[0011] トランザクション管理部においては、アプリケーション力も指定された識別子 (送信デ ータ識別子）により送信データの単位を識別する。またこのプロトコルは、送信データ 単位が下位層のプロトコルで一度に送信可能なサイズよりも大き!/ヽ場合には、送信可 能なサイズに分割し、順序番号を付けて送信し、受信側でその順序番号を元に組み 立てる機能を有する。このとき、個別通信の場合には、最終データの受信時に未受 信のデータの順序番号を送信側に通知することで、送信側は未受信のデータのみを 再送信する。これにより通信誤り率が改善できる。
また、個別通信'同報通信の場合には、送信元のアプリケーション識別子 (送信元 ポート番号)とそのアプリケーションが指定した送信データ識別子の組が同一の場合 には、受信側で既受信の同一識別子のデータと同一のデータとして扱う。これにより 送信側は任意のタイミングでデータの再送信が可能となり、一定時間通信できない場 合においても、通信誤り率を改善できる。
図面の簡単な説明
[図 1]この発明の実施の形態 1による路車間通信システムにおけるコネクション識別の 概念を示す図である。
[図 2]ローカルポート番号の分類を示す図である。
[図 3]データグラム伝送サービスの例を示す図である。
[図 4]プリミティブ種別を示す図である。
圆 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プリミティブの弓 I数を示す図である。
[図 38] Abort Type = 0の場合（システムエラー）の Abort Code—覧を示す図であ る。
[図 39]Connectプリミティブの引数を示す図である。
[図 40]Disconnectプリミティブの引数を示す図である。
[図 41]RegisterPortプリミティブの引数を示す図である。
[図 42]DeregisterPortプリミティブの引数を示す図である。
[図43] PDU種別一覧を示す図である。
[図 44]ローカルポートプロトコルのプロトコルデータユニット基本構造を示す図である [図 45]Invoke PDUのヘッダ情報を示す図である。
[図 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タイマーがタイムアウトした場合の処理シーケンス例を示す図である。
[図 59]再送処理が有効な場合のデータ転送手順 (基本シーケンス)を示す図である。
[図 60]再送処理手順 (再送成功時)を示す図である。
圆 61]再送処理手順 (再送失敗時)を示す図である。
[図 62]分割'組立処理が有効な場合のシーケンス例を示す図である。
圆 63]分割 '組立処理が有効な場合のシーケンス例 (選択的再送処理)を示す図で ある。
[図 64]分割'組立処理が有効な場合のシーケンス例（最終セグメントが未達時の場合 )を示す図である。
[図 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)にも制御情報を付加することで 各種サービスを実現して 、る。
[0015] 1. 2 ローカルポート番号
1. 2. 1 アクセス点識別
発信元となるアプリケーション力 対向するアプリケーションに対して正しくデータを 送り届けるために、ローカルポート制御プロトコル（LPCP)では図 1に示すように LPC P上のアプリケーションを識別するためのアクセス点としてローカルポート番号を設け 、車両 ID (リンクアドレス等）とローカルポート番号の組で、それぞれのアプリケーショ ンに対して相手先との接続を識別する。
[0016] 1. 2. 2 ローカルポート番号の分類
図 2はローカルポート番号の分類の例を示す図である。ローカルポート番号は非ネ ットワーク系アプリケーションにおけるコネクション識別子として使用され、ローカルポ ート番号を以下のように規定する。 0— OxOFFFを番号予約ポート、 OxlOOO— OxF FFFを任意ポートとする。このようにポート番号を規定することで、 65536種類のポー ト番号を規定でき、今後のアプリケーション種類の増大にも十分に対応が可能となる
[0017] 1. 2. 3 アプリケーションとローカルポート番号の関係
アプリケーションと前節で規定されたローカルポート番号との関係を説明する。 アプリケーションの形態は、クライアント Zサーバモデルおよびピアツーピアモデル を前提とする。従って、クライアント Zサーバモデルにおいては大域的に一意である サーバプロセスのポートは番号予約ポート、局内で一意であるクライアントプロセスの ポートは任意ポートを利用することを基本とする。またピアツーピアモデルにぉ ヽては 双方のプロセスが番号予約ポートを利用することを基本とする。独自アプリの場合は
、任意ポートをサーバ'クライアント共に使用することも可能である。
[0018] 1. 2. 4 ローカルポート番号の番号設定
ローカルポート番号の番号設定については、以下の規則に従う。 (1)予約番号にっ 、ては、グローバルに重複のな 、付番を行うこと。
(2)アプリケーションは複数の受信ポートを持つことができる。
(3)基地局、移動局を単位とし、各アプリケーションは、局内で重複の無いように受信 ポート番号を使用すること。
(4)送信元の特定が不要な場合や送信元が既知の場合には、送信元ポートを省略 することができる。
[0019] 1. 3 LPCPの機能
次に LPCPの機能について詳細に説明する。
1. 3. 1 データ転送機能データグラム伝送サービス
図 3はデータグラム伝送サービスの例を示す図である。 DSRC— ASLにおけるロー カルポート系アプリケーションの構成は、 LPCP上に複数のアプリケーションが存在 する階層構造となっており、 LPCPはデータの転送先アプリケーションの識別を行う 必要がある。
そこで、 LPCP〖こ、送信元及び送信先ポート番号を付与し、これによりデータの転 送先を決定する。
[0020] なお、 LPCPが提供する通信サービスは、高速、低オーバヘッドなコネクションレス 型のデータグラム伝送サービスであり、 LPCPとアプリケーション（上位層プロトコル） 間での具体的な動作は、以下の通りである。
1：データを受け取る受信ポートをアプリケーション（上位層プロトコル）力 LPCPに依 頼して新しく作成し、
2 :その受信ポートを通して、 LPCPから車両 ID (リンクアドレス等）、送信元ポート番 号および受信データを受け取り、
また逆に
3 :アプリケーション（上位層プロトコル）は送信データ、リンクアドレスおよび送受信ポ ート番号を LPCPに渡し、 LPCPがその情報力 LPCPデータグラムを生成して相手 へ送信する。
[0021] 1. 3. 2 管理サービス
管理サービス処理では、以下のサービスをアプリケーションや上位層プロトコルに 対して提供する。
•ASL-ELCP (拡張通信制御プロトコル)の管理サービスで通知されるエラーゃィべ ント (通信の接続、非接続の通知等）を、自局のアプリケーションに対して透過的に通 知するサービス。
•LPCP内で発生したエラーやイベントを相手局ゃ自局のアプリケーションに対して 通知するサービス。
[0022] LPCPとアプリケーション（または上位層プロトコル）間での具体的な動作は、以下 の通りである。
1.イベントを受け取るポートをアプリケーション（または上位層プロトコル）力LPCPに 依頼して新しく作成し、
2.そのポートを通して、 LPCPからリンクアドレス、状態識別子、イベント付加情報を 受け取る。
[0023] 1. 4 アプリケーションとのインタフェース
次に、 LPCPとアプリケーションとのインタフェースについて説明する。
1. 4. 1 記法の説明
本発明で規定されるプリミティブ種別の一覧を図 4に、プリミティブの定義テーブル で用いられるパラメータ種別の一覧を図 5に示す。
1. 4. 2 データ転送サービスインタフェース
図 6にデータ転送サービスの論理関係を示す。
ローカルポート制御プロトコルはデータ転送サービスとして、アプリケーション（また は上位層プロトコル）に対して、以下の 1種類のプリミティブを用意する。
1. 4. 2. 1 転送プリミティブ（TransferData)
本プリミティブは DSRC— ASLの ELCPと非 IPアプリケーションや上位層プロトコル との間でデータ転送を行うためのプリミティブである。図 7に転送プリミティブの定義を 示す。図 7において、
Link Address：本送信で使用する DSRCの LIDまたは LIDと 1対 1でマッピング可 能な ID
Source Port:送信元アプリケーションのポート番号 Destination Port：送信先アプリケーションのポート番号
User Data :伝达データ本体
User Data Size :伝送データサイズ
[0024] 1. 4. 3 管理サービスインタフェース
図 8に管理サービスインタフェースの論理関係を示す。ローカルポート制御プロトコ ルは管理サービスとして、アプリケーション (または上位層プロトコル）に対して、以下 の 3種類のプリミティブを用意する。
•Event Report (イベント通知プリミティブ）
•Open Port (ポート生成プリミティブ）
•Close Port (ポート破棄プリミティブ）
[0025] 1. 4. 3. 1 イベント通知プリミティブ（Event Report)
本プリミティブは非 IPアプリケーションや上位層プロトコルに対してイベントの発生や エラーを報告するためのプリミティブである。 ASL— ELCPの管理サービスで通知さ れたイベントをローカルポートプロトコルに対して透過的に転送するものと、相手局の 管理サービス力もの通知を透過的に転送するものの 2種類がある。図 9にイベント通 知プリミティブの定義を示す。図 9において、
Link Address :通知相手が使用する（中の） LIDを指定する。
Event Code：イベントコードとして状態識別子（図 17)を格納する。
Extention Parameter：各イベントコードに対応するイベント付加情報。
[0026] 1. 4. 3. 2 ポート生成プリミティブ（Open Port)
本プリミティブは LPCPに対して、データおよびイベントの受信ポートを生成するた めのプリミティブである。図 10にポート生成プリミティブの定義を示す。図 10において
Port：通知を要求するポート番号
Type：通知が必要なプリミティブ種別の指定
1： TransferData
2： Event Report
このパラメータが省略された場合は、全てのプリミティブ通知を要求する。 Code : Type = 2 (Event Report)の場合に通知が必要なイベントの種別 このパラメータが省略された場合は全てのイベントの通知を要求する。
イベント種別の詳細は図 17を参照。
[0027] 1. 4. 3. 3 ポート破棄プリミティブ（Close Port)
本プリミティブはポート生成プリミティブで生成した受信ポートを破棄するためのプリ ミティブである。
図 11はポート破棄プリミティブの定義を示す図である。図 11にお 、て、 Port:破棄するポート番号
[0028] 1. 5 制御情報
1. 5. 1 概要
次に、前記管理サービスにおいて用!、る LPCPの制御情報について説明する。 LPCPの管理サービスでは、 LPCPで使用する通信パラメータを管理する。
LPCPの管理サービスでは以下の情報を管理する。
(1)受信可能ポートリスト
(2)通信制御情報
[0029] 1. 5. 2. 1 受信可能ポートリスト
基地局 Z移動局が受信可能なポート番号の情報で、受信ポート生成プリミティブ受 信時にリストに追加し、受信ポート破棄プリミティブ受信時にリストから削除する。 受信可能ポートリストの構成例を図 12に示す。
1. 5. 2. 2 通信制御情報
基地局 Z移動局において通信中のアプリケーションに関する情報で、 ASL— ELC Pの通信制御管理力もの DSRC接続通知の受信時にリストに追加し、 DSRC切断通 知の受信時にリストから削除する。通信制御情報の構成例を図 13に示す。
略語解説：
LID :リンクアドレス
Port No :受信可能ポート番号
Primitive Type ：受信するプリミティブ種別
Event Code :受信するイベントコードの種別 Equipment ID :車載器固有情報
[0030] 1. 6 プロトコルデータユニット（PDU)
次に、データグラム伝送サービスおよび管理サービスで用いられる LPCPのプロトコ ルデータユニット（PDU)について説明する。
LPCPの PDUはローカルポート制御プロトコルヘッダとアプリケーションデータ部か ら構成される。
1. 6. 1 データグラム伝送サービスのプロトコルデータユニット
図 14にデータグラム伝送サービスで用いられる LPCPの PDUの形式を示す。 アクセス点識別子:ネットワーク制御プロトコルを識別するための識別子。常に local Port Control (1)を格納する。
プロトコル識別子： PDU種別を表す。データグラム伝送サービスでは、 message (0) を格納する。詳細は図 15を参照。
送信元ポート番号:送信元アプリケーションのポート番号
送信先ポート番号:送信先アプリケーションのポート番号
ユーザデータ部の長さ：後続するユーザデータ部のデータ長を指示する。単位はォ クテツト。なお、このエリアのサイズは、 ASN. 1符号ィ匕規則に従い拡張する。付加す るユーザデータがない（NULLの）場合、この領域に 0が指定される。なお、 LPCP力 S ASL— ELCPに渡すことができるデータの最大長、 LPCPの MTU (Maxim urn T ransmission Unit)は、 522オクテット（アクセス制御情報含む）とする。
ユーザデータ部の内容：伝送データ本体。 OCTET STRING型の不定長データを 格納する。
図 15は LPCPのプロトコル識別子を示す図である。
[0031] 1. 6. 2 管理サービスのプロトコルデータユニット
図 16に管理サービスで用いられる LPCPの PDUの形式を示す。以下に示す PDU は相手局の LPCPヘイベント通知を行う場合に用いられるものである。
図 16はイベント通知のメッセージの形式を示す図である。
アクセス点識別子:ネットワーク制御プロトコルを識別するための識別子。常に local Port Control (1)を格納する。 プロトコル識別子： PDU種別を表す。管理サービスでは、常に event Report (1)を 格納する。
イベントコード：発生したイベント内容を指示する識別子。 0— 127は通信制御プロト コルの状態識別子であり、 128— 255が LPCPの状態識別子である。図 17はィベン トコード（event Code)の内容を示す図である。
イベント付加情報の長さ：後続するイベント付加情報のデータ長を指示する。単位は オクテット。なお、このエリアのサイズは、 ASN. 1符号ィ匕規則に従い拡張する。付カロ するイベント情報がな 、 (NULLの）場合、この領域に 0が指定される。
イベント付加情報の内容：イベント付加情報の内容。 OCTET STRING型の不定 長データを格納する。
[0032] 1. 7 処理手順
LPCPにおける処理手順について説明する。
1. 7. 1 初期接続手順
(a)アプリケーション力LPCPに対して、ポート生成プリミティブにより、 DSRC接続通 知の要求をあらかじめ行っておく。
(b)車両の DSRC覆域への進入により、 ASL— ELCPの管理サービスイベント通知プ リミティブ (Event Information, ind)で状態「通信接続の通知」を受領する。
(c)ポート生成プリミティブで、 DSRC接続通知を要求されているポートに対して、ィ ベント通知プリミティブ（Event Report, ind)でイベントコード「DSRC接続通知（96 ；)」を通知する。
図 18に DSRC接続時の処理シーケンス例を示す。
[0033] 1. 7. 2 通信終了手順
(a)アプリケーション力LPCPに対して、ポート生成プリミティブにより、 DSRC切断通 知の要求をあらかじめ行っておく。
(b) ASL— ELCPの管理サービスイベント通知プリミティブ（Eventlnformation. ind
)で状態「通信切断の通知」を受領する。
(c) LPPの接続管理サービスに対して、イベント通知プリミティブ（EventReport. in d)でイベントコード「DSRC切断通知」を通知する。 図 19に通信終了時の処理シーケンス例を示す。
[0034] 1. 7. 3 メッセージ転送手順
(1)送信処理
(a)データ転送要求プリミティブ (TransferData. req)が発行される。
(b)通信制御情報を参照し、指定された Link Adressがプライベートリンクアドレス であり、かつそのリンクアドレスで DSRCが接続されていない場合は、データ転送要 求プリミティブで指定されて ヽた送信元ポート番号に対して、状態識別子が「DSRC が接続されて ヽな ヽ（ 128)」であるイベント通知プリミティブを発行し、送信処理を完 了する。ただし、この手順はローカルポート生成プリミティブにより、イベント通知の要 求が行われていた場合とし、イベント通知の要求が行われていない場合には、上位 プロトコルに対するイベント通知は行わな 、。イベント通知の有無は受信可能ロー力 ルポ一トリストにより判別する。
(c) DSRCが接続している場合は、アクセス点識別子が local Port Protocol (1) , プロトコル識別子が message (0)である、パケットを生成し、 ASL— ELCPのデータ転 送プリミティブ（Send Unit Data, req)で送信し、送信処理を完了する。
(d)送信処理完了後、データ転送メッセージを送信した相手局からイベント通知メッ セージを受領した場合には、そのメッセージで渡されたイベントコードを確認し、ィべ ントコードの内容が「送信先ローカルポートが有効でない」の場合、そのメッセージの イベント付加情報に指定されて 、る送信元ローカルポート番号に対して、イベント通 知プリミティブ（Event Report, ind)により「送信先ローカルポートが有効でな!、」を 通知する。ただし、この手順はローカルポート生成プリミティブにより、イベント通知の 要求が行われていた場合とし、イベント通知の要求が行われていない場合には、上 位プロトコルに対するイベント通知は行わな 、。イベント通知の有無は受信可能ロー カルポートリストにより判別する。
[0035] (2)受信処理
(a)アプリケーション力LPCPに対して、ポート生成プリミティブにより、転送通知の要 求を行い、受信ポートをオープンする。
(b) ASL— ELCPからデータ転送通知プリミティブ（Send Unit Data, ind)で、プ ロトコル識別子が message (0)であるパケットを受信すると、そのパケットから、プロト コル識別子、送信先ローカルポート番号、送信元ローカルポート番号、ユーザデータ を取り出す。
(c)受信可能ポートリストを参照し、 (b)で受信した送信先ポート番号が有効な場合は 、送信先ポート番号で指定された上位エンティティに対して、データ転送プリミティブ（ TransferData. ind)で相手局からのデータの受信を通知し、受信処理を完了する
(d)リンクアドレスがプライベートアドレスであり、かつ（b)で受信した送信先ポート番 号が有効でない場合は、プロトコル識別子が event Report (1)、状態識別子が「送 信先ポートが有効でない（129)」であるパケットを作成し、 ASL— ELCPのデータ転 送プリミティブで相手局に送信し、受信処理を完了する。すなわち、相手局からのメッ セージ受信時に自局に送信先アプリケーションが存在しない場合は、その旨を相手 局に対して即座に通知する。またリンクアドレスがグループ同報アドレスであり、かつ（ b)で受信した送信先ポート番号が有効でない場合は、受信データを破棄し、受信処 理を完了する。
図 20にメッセージ転送の基本処理シーケンス例を、図 21に DSRCが接続されて!ヽ な 、場合の処理シーケンス例を、図 22に送信先ローカルポート番号が有効でな 、場 合の処理シーケンス例を示す。
[0036] 2.トランザクション管理部（ローカルポートプロトコル）
以下に、トランザクション管理部（ローカルポートプロトコル）について詳細に説明す る。
[0037] 2. 1 概要
ローカルポートプロトコル（LPP : Local Port Protocol)は、ローカルポート制御 プロトコル（LPCP)と非ネットワーク系アプリケーションの間に介在し、ローカルポート 制御プロトコルの機能を拡張し、 DSRC車載器 Z路側機上の非ネットワーク系アプリ ケーシヨンに対して、以下のトランザクションサービスと接続管理サービスを提供する ことで、アプリケーション構築の効率ィ匕を図ることを目的としたトランザクション指向の プロトコルである（図 23参照）。本プロトコルは、ローカルポート制御プロトコルの通信 機能を拡張するトランザクションサービス処理部と、初期接続や切断などの通信状況 を管理する接続管理サービス処理部から構成されて!、る。各サービス処理部が有す る機能は以下の通り。
トランザクションサービス処理部
•トランザクション単位のデータ交 能
•単方向データ送信トランザクションサービス
.リクエスト .レスポンス型トランザクションサービス
，データ再送機能
•メッセージの分割.組み立て機能
'トランザクションの破棄機能
接続管理サービス処理部
• DSRC接続問 、合わせサービス
• DSRC切断通知サービス
•受信可能ポート問!、合わせサービス
またトランザクション管理部は、アプリケーションに対して前記機能を利用するため のサービスプリミティブ (アプリケーションとのインタフェース）を提供する。さらに上記 機能を実現するため、路車のトランザクション管理部間でやりとりされるデータ (PDU )の構造を規定している。トランザクション管理部では、送信側がサービスプリミティブ で要求された機能 (またはトランザクション管理部内部で発生したイベント）に応じた 制御情報を付加するとともに、受信側では PDUに付加された制御情報を解析、利用 することで前記機能を実現する。
2. 2 LPPの機會
次に上述の LPPにおける各サービス処理部の機能について、各々詳細に説明す る。
2. 2. 1 トランザクションサービス処理
2. 2. 1. 1 トランザクション単位のデータ交 «能
ローカルポートプロトコルでは、トランザクション単位でアプリケーションデータを交 換する。 トランザクション IDにより、各々のトランザクションを区別する（図 24参照)。これによ り、同一アプリケーション間で複数トランザクションが同時に存在する状況への対応も 可會 になる。
図 24は LPPにおけるトランザクション間データ交換例を示す図である。
なおトランザクション IDの付番方式は以下の通りとする。
(1) 16ビット構成
(2)先頭ビットはトランザクションの開始側を表す (車載側が 0、 路側側が 1)。
(3)トランザクションの発行（Invoke, req)毎に 1インクリメントされる。
[0039] 2. 2. 1. 2 2種類のトランザクションサービス提供機能
本プロトコルは以下の 2種類のトランザクションサービスを提供する。
•単方向データ送信トランザクションサービス
.リクエスト ·レスポンス型トランザクションサービス
これらの各トランザクションサービスは、アプリケーション個々の通信要件に応じて、必 要なレベルのものが用いられ、アプリケーション毎に最適な通信サービスを利用でき る。
[0040] 2. 2. 1. 2. 1 基本トランザクション
(1)データ送信サービス
路車双方の非ネットワーク系アプリケーションに対して、データ送信サービスを提供 する。（図 25参照）図 25はデータ送信サービスの例を示す図である。
(2)リクエスト .レスポンス型トランザクションサービス
メッセージを相手に対して通知すると共に、そのメッセージに対する返り値を取得す る。リモートに対するメソッド呼び出しなどの用途に利用する。（図 26参照） 図 26はリクエスト 'レスポンス型トランザクションサービスの例を示す図である。
[0041] 2. 2. 1. 2. 2 データ再送機能
本機能は、通信の信頼性を確保するための機能であり、再送タイマーと再送カウン タにより再送の制御を行う。再送タイマーのタイムアウト時に再送を行う（最大再送回 数以下)ことで、通信の信頼性を確保する（図 27参照)。データの送信や返信に適用 が可能であり、適用するかどうかはアプリケーションが指定する。処理シーケンスを以 下に示す。
図 27はデータ再送の例を示す図である。
•パケット送信時に、再送タイマをスタートさせ、再送カウンタを 0にセットする。
•再送タイマのタイムアウト前にレスポンスデータを受信できな力つた場合には再送力 ゥンタをインクリメントし、パケットを再送する。
•再送カウンタが最大再送回数を超えた場合には、トランザクションを終了し、その旨 をアプリケーションに通知する。
また、データ再送機能を使用するトランザクションにおいては、送達確認の未到達 などの理由により、以前に受信した 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の送信キューがオーバフロ 一することが想定されるため、 LPPでは送信を失敗したパケットの再送や、フロー制 御を行うことで、すべてのパケットが送信されることを保証する。
受信側は、 LPCPから渡された分割されたパケットを順次取り込み、受信側のアプリ ケーシヨンが用意した受信キューへ積み上げる。この際、レイヤ 2の再送処理などの 要因により、受信キューには送信順に各パケットが格納される保証はなぐ受信側は 、各パケットに付番されたシーケンス番号で組み立て順を判別して PDUへ組み上げ る。受信側では、全てのパケットを受信後、送信側に対して到達確認を返す。 [0043] また、 DSRC— ASLでの受信キューオーバフローや DSRCでのデータの欠落など で、パケットの欠落が発生することが想定され、送信された全てのパケットが相手局の LPPまで到達される保証はない。この場合、 1つのパケットの欠落力 Sメッセージ全体 のデータの欠落となってしまうため、最終パケット受信時に受信できていないパケット を、否定応答により通知し、欠落したパケットの再送を行う（選択的再送処理)ことによ り、メッセージ全体の到着を保証する。また最終パケットの欠落については、通常の 再送処理により、到達を保証する。なお、選択的再送によって送信するパケット群に ついても同様の制御を行う。図 30に選択的再送処理の例を示す。
なお、アプリケーション毎に必要となる受信キューのサイズが大きく異なることが予 想されることから、本機能では受信キューをアプリケーションが用意する。そのため、 分割'組立が必要なトランザクションは、送信先 (リンクアドレスと送信先ポート番号で 識別）毎に、同時には 1つし力発行できないものとする。
また同報アドレスに対するデータ送信の場合には、到達確認の返信、選択的再送 処理や最終セグメントの再送制御を行わず、トランザクションの再実行要求により、必 要とされる通信の信頼性を確保する。図 32にトランザクションの再実行処理の例を示 す。
[0044] 2. 2. 1. 3 トランザクションの廃棄機能
リクエスト.レスポンス型のトランザクションでは、アプリケーションからの要求により、ト ランザクシヨンの破棄を要求できる（図 33参照)。要求時のトランザクションの状態に 応じて、以下の処理が実施される。
'メッセージが送信されて 、な 、場合は、そのメッセージを破棄する。
•メッセージを送信済みもしくは送信中の場合は、そのトランザクションに関連する全 てのデータを破棄し、相手側に対してそのトランザクションが破棄されたことを通知す る。
'相手側でのトランザクション破棄要求により、トランザクションの破棄要求を受信し た場合は、アプリケーションに対して、トランザクション破棄を通知すると共に、そのト ランザクシヨンに関連する全てのデータを破棄する。
図 33はトランザクション破棄通知の例を示す図である。 また、
• DSRC通信路が切断されて 、る。
•宛先ポートが受信可能ポートではない。
といった場合は、無駄な通信を抑制するために、トランザクションを開始せず、要求が 失敗したことをアプリケーションに通知する。
[0045] 2. 2. 2 接続管理サービス処理
接続管理サービスでは、以下のサービスをアプリケーションに対して提供することで 、アプリケーションに通信開始 '終了のトリガーを提供する。
•DSRCの接続状況を管理、監視し、アプリケーション力ゝらの要求に応じて、接続状 況の報告や新規接続、切断を通知するサービス。
-路車間の接続管理サービス間で受信可能ポート番号を通知しあうことで、相手局 が有する受信可能ポート番号を管理し、アプリケーション力もの要求に応じて、それら の状況を報告したり、あるポートが受信可能となったことを通知するサービス。
なお、接続管理サービスは、ローカルポート制御プロトコル上のアプリケーションと 同様の位置づけとし、路車の接続管理サービス間でのイベントの送受信は、ローカル ポート制御プロトコルのデータ転送サービスを利用する。接続管理サービスが利用す るポート番号は、当面、 OxOFFFとする。
[0046] 2. 2. 2. 1 DSRC接続問い合わせサービス
DSRCが接続して 、るかどうかを問 、合わせる機能。
問!、合わせ時に DSRCの接続状況を即座に回答を行う参照サービスと、接続して!/ヽ ない場合に、接続するまで待ち、接続した時点で通知をおこなう通知サービスの 2種 類のサービスを規定する。
2. 2. 2. 2 DSRC切断通知サービス
切断通知を要求するアプリケーションに対して、 DSRCの切断を通知する機能。
[0047] 2. 2. 2. 3 受信可能ポート問い合わせサービス
相手局にある受信ポートが存在しているかどうかを問い合わせる機能。ポートの状 態には以下の 3種類がある。
•受信可能ポート:相手局がこのポートをデータ受信ポートとしてオープンしている ポート。
'受信不可ポート：相手局がこのポートをデータ受信ポートとしてオープンしていな いポート。
•不明ポート：相手局がこのポートをデータ受信ポートとしてオープンしているかどう かわからないポート。初期状態がこの状態。
なお、受信可能ポート問い合わせサービスには、問い合わせ時にそのポートがどの 状態であるかを即座に回答を行う参照サービスと問い合わせたポートが受信可能ポ ートになるまで待ち、相手局力 の受信可能ポート通知を受け取った時点で通知を 行う通知サービス (すでに問 、合わせたポートが受信可能ポートであることが判明し て 、る場合は即座に回答する）の 2種類のサービスを規定する。
前記サービスを可能とするため、路車間のローカルポートプロトコルの管理サービス は、 DSRC通信接続時や受信可能ポート変更時に相手局に対して、自局が受信可 能なポート番号や受信不可となったポート番号を通知する機能を有する。
[0048] 2. 3 アプリケーションとのインタフェース
次に、 LPPとアプリケーションとのインタフェースについて説明する。
2. 3. 1 記法の説明
本発明で規定されるプリミティブ種別の一覧を図 34に示す。
また、本発明でのプリミティブの定義テーブルで用いられるパラメータ種別の一覧を 図 35に示す。
2. 3. 2 トランザクションサービスプリミティブ
トランザクションサービスとして、 LPPはアプリケーションに対して、以下の 2種類の プリミティブを用意する。
•Invoke： (トランザクション開始プリミティブ）
•Abort: (トランザクション破棄プリミティブ）
[0049] 2. 3. 2. 1 Invoke (トランザクション開始プリミティブ）
処理概要：
Invokeプリミティブは新し 、トランザクションを生成するためのプリミティブである。全 てのトランザクションはこのプリミティブの発行により開始される。 ¾i我：
図 36は Invokeプリミティブの弓 |数を示す図である。
Link Address : DSRCの LIDもしくは LIDと 1対 1でマッピング可能な 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、 Sourc e Port, トランザクション IDがー意に特定できなければならない。また、同報通信 において、直前の実行済みの同報通信と同一の Handleが指定された場合には、トラ ンザクシヨンの再実行要求として扱われる。
2. 3. 2. 2 Abort (トランザクション破棄プリミティブ）
処理概要：
Abortプリミティブは生成されているトランザクションを破棄するためのプリミティブで ある。
¾1我：
図 37は Abortプリミティブの引数を示す図である。 Abort Type :破棄理由がシステムエラー（0)か、ユーザ要求（1)かを表す。
Abort Code :トランザクションが破棄された理由を示す。（システムエラーの詳細は 図 38参照）
Handle：ローカルでトランザクションを区別するための ID。
図 38は Abort Type = 0の場合（システムエラー）の Abort Code—覧を示す図で ある。
[0051] 2. 3. 3 接続管理サービス
接続管理サービスとして、 LPPはアプリケーションに対して、以下の 4種類のプリミテ イブを用意する。
• Connect： (トランザクション開始可能問い合わせ Z通知プリミティブ） •Disconnect: (DSRC切断通知プリミティブ）
•Register Port (ポート登録プリミティブ）
•Deregister Port (ポート登録削除プリミティブ）
[0052] 2. 3. 3. 1 Connect (トランザクション開始可能問い合わせ Z通知プリミティブ） 処理概要：
Connect, reqプリミティブは、トランザクションが開始可能かどうかを問い合わせるた めのプリミティブである。 Connect, cnfプリミティブは Connect, reqによる問い合わ せに対し、 DSRCの接続と LIDおよび (その LIDが指し示す)相手局が有する受信可 能ポート番号を問い合わせ元のアプリケーションに通知するためのプリミティブである
¾i我：
図 39は Connectプリミティブの弓 |数を示す図である。
Querist Port:問い合わせ元の Port番号で、問い合わせを行ったアプリを特定す るために使用する。
Query LID:問い合わせを行う LID。 LID指定時は、既接続済みのリンクに対する 問い合わせとして扱う。一方指定が無い場合は、新規接続待ちとして扱う。 QueryPo rtとともに省略された時は DSRC接続後すぐに Connect, cnfが発行される（高速接 続)。一方、 QueryPortが指定された場合は、受信可能ポート通知受信後に Conne ct. cnfが発行される（通常接続)。
Query Port：問!、合わせを行う宛先ポート番号。
Time Out : DSRC未接続時に Connect, cnfを発行するまでのウェイト時間。ゥェ イト中に接続された場合は、即座に Connect, cnfを発行する。このパラメータを省略 時はタイムアウト時間 =∞として扱う。
Connected LID : Query LIDが指定され、かつその LIDが接続中の場合は、 Qu eryLIDと同じ LIDが指定さる。 Query LIDが指定されかつその LIDが未接続の場 合、および Query LIDが未指定で、 TimeOutパラメータで指定される時間内に新 規接続が無い場合は 1が指定される。
Accept Port Connected LIDで表される相手局が有する受信可能ポート番号。 Query Portにて指定があった場合は、そのポート番号のみを通知する。なお、指 定された Port番号が受信拒否ポート番号の場合は、ー1が指定される。また Query Portが省略されている場合は、 0が指定される。
[0053] 2. 3. 3. 2 Disconnect (DSRC切断通知プリミティブ）
処理概要：
DSRCの切断をアプリケーションに通知するためのプリミティブである。
ΐ£我：
図 40は Disconnectプリミティブの引数を示す図である。
2. 3. 3. 3 Register Port (ポート登録プリミティブ）
処理概要：
Register Portプリミティブは、 LPPに対して受信ポートを登録するためのプリミティ ブである。
¾i我：
図 41は RegisterPortプリミティブの弓 |数を示す図である。
Port No :受信ポート番号
Bulk Area：分割されたメッセージを組み立てるエリア
Bulk Area Size : Bulk Areaのサイズ
[0054] 2. 3. 3. 4 Deregister Port (ポート登録削除プリミティブ） 処理概要：
Deregister Portプリミティブは、 LPPに対して受信ポートを削除するためのプリミテ イブである。
¾i我：
図 42は DeregisterPortプリミティブの引数を示す図である。
Port No :登録を削除する受信ポート番号
[0055] 2. 4 プロトコルデータユニット（PDU)
次に、トランザクションサービスおよび接続管理サービスで用いられる LPPのプロト コルデータユニット（PDU)について説明する。
2. 4. 1 トランザクションサービスのプロトコルデータユニット
トランザクションサービスで用いられる、プロトコルデータユニットはその利用シーン に応じて図 43に示す 7種類存在する。トランザクションサービスで用いられる PDUは PDU種別毎に定義されるヘッダ部とアプリケーションデータが格納されるデータ部か ら構成される。 PDUの基本構造を図 44に示す。
[0056] 2. 4. 1. 1 Invoke PDU
図 45は Invoke PDUのヘッダ情報を示す図である。
PDU Type : PDUのタイプ。 Invoke PDUでは常に Invoke (1)。
Version:ローカルポートプロトコルのバージョンを表す。現バージョンは 0x00。 TT: Transaction Typeの略。トランザクションのタイプを指定する。 0 :データ送信ト ランザクシヨンサービス、 1：リクエスト ·レスポンス型トランザクションサービス。
RA: Require Ackの略。再送処理が有効かどうかを表すフラグ。再送処理有効時 は 1。
RD: Retransmitted Dataの略。再送されたデータかどうかを表すフラグ。再送時 は 1。
TID：トランザクション ID。
RES :予約。
[0057] 2. 4. 1. 2 Result PDU
図 46は Result PDUのヘッダ情報を示す図である。 PDU Type : PDUのタイプ。 Result PDUでは常に Result (2)。
RA: Require Ackの略。再送処理が有効かどうかを表すフラグ。再送処理有効時 は 1。
RD:再送されたデータ力どうかを表すフラグ。再送時は 1。
TID：トランザクション ID。
RES :予約。
[0058] 2. 4. 1. 3 Acknowledgement PDU
図 47は Acknowledgement PDUのヘッダ情報を示す図である。
PDU Type : PDUのタイプ。 Acknowledgement PDUでは常に Ack (3)。
RD:再送されたデータ力どうかを表すフラグ。再送時は 1。
TID：トランザクション ID。
RES :予約。
[0059] 2. 4. 1. 4 Abort PDU
図 48は Abort PDUのヘッダ情報を示す図である。
PDU Type : PDUのタイプ。 Abort PDUでは常に Abort (4)。
AT:破棄理由がシステムエラー（0)、ユーザ要求（1)のどちらによるものかを表すフ ラグ。
TID：トランザクション ID。
Abort Code :トランザクションの破棄理由をコードとして指定。（図 38を参照） RES :予約。
[0060] 2. 4. 1. 5 InvokeSegment PDU
図 49は Invoke Segment PDUのヘッダ情報を示す図である。
PDU Type : PDUのタイプ。 Invoke Segment PDUでは常に Invoke Sgm (
5) 0
Version:ローカルポートプロトコルのバージョンを表す。現バージョンは 0x00。 TT: Transaction Typeの略。トランザクションのタイプを指定する。 0 :データ送信ト ランザクシヨンサービス、 1：リクエスト ·レスポンス型トランザクションサービス。
FIN：最終セグメントかどうかを表すフラグ。最終セグメントでは 1。 RD: Retransmitted Dataの略。再送されたデータかどうかを表すフラグ。再送時 は 1。
TID：トランザクション ID。
Segment No : PDUの順序番号。
[0061] 2. 4. 1. 6 Result Segment PDU
図 50は Result Segment PDUのヘッダ情報を示す図である。
PDU Type : PDUのタイプ。 ResultSegmentPDUでは常に ResultSgm (6)。
FIN：最終セグメントかどうかを表すフラグ。最終セグメントでは 1。
RD:再送されたデータ力どうかを表すフラグ。再送時は 1。
TID：トランザクション ID。
RES :予約。
Segment No : PDUの順序番号。
[0062] 2. 4. 1. 7 Nack PDU
図 51は Nack PDUのヘッダ情報を示す図である。
PDU Type : PDUのタイプ。 Nack PDUでは常に Nack (7)。
RD:再送されたデータ力どうかを表すフラグ.再送時は 1。
TID：トランザクション ID。
RES :予約。
Num Seg :未受信の PDUの順序番号の数
Segment Number List:未受信の PDUの順序番号のリスト
[0063] 2. 4. 2 接続管理サービスのプロトコルデータユニット
ローカルポートプロトコルの接続管理サービスは、 DSRCの新規接続時や、受信可 能ポートが増減した場合に、相手局の接続管理サービスに対して、ローカルポート制 御プロトコルの転送サービスを利用し、受信可能ポートリストや受信不可ポートを通知 する。以下に示す PDUはこれらの通知で用いられるプロトコルデータユニットであり、 ローカルポート制御プロトコルのユーザデータ部に格納される。
[0064] 2. 4. 2. 1 受信可能ポートリスト通知におけるプロトコルデータユニット
図 52は受信可能ポートリスト通知におけるプロトコルデータユニットを示す図である。 Status :イベントの種別を表す。受信可能ポートリスト通知の場合は、 accept Port
List (1)を常に格納する。
Num Ports :受信可能ポート番号の数を格納する。
Accept Port List:受信可能ポート番号のリストを格納する。
[0065] 2. 4. 2. 2 受信不可ポート通知におけるプロトコルデータユニット
図 53は送信不可ポート通知におけるプロトコルデータユニットを示す図である。 Status :イベントの種別を表す。受信不可ポート通知の場合は、 rejectPort (2)を常 に格納する。
Reject Port:受信不可ポート番号を格納する。
[0066] 2. 5 処理手順
LPPにおける処理手順について説明する。
2. 5. 1 初期接続手順
(1)通常アプリの初期接続手順
図 54はローカルポートプロトコルの初期接続手順を示す図である。
(a) 移動局及び基地局の各アプリケーションは受信可能なポート番号をポート登録 プリミティブ (Register Port)を用いて、 LPPに登録する。
(b) LPPは接続管理テーブルを更新し、前記 (a)で登録された受信可能ポート番 号および接続管理サービスポートをデータ受信ポートとして LPCPに登録する。また 、管理サービスポートはイベント受信ポートとしても LPCPに登録する。
(c) 各アプリは Query LIDパラメータを未指定、 Query Portパラメータを指定し 、 DSRC接続問い合わせプリミティブ (Connect, req)を発行し、 DSRC接続を待ち 合わせる（ブロッキング呼出）。
(d) LPPの接続管理サービスは、 LPCPからイベント通知プリミティブ (Event Rep ort)で、イベント「DSRC接続通知（96)」を受領する。
(e) LPPの接続管理サービスは同プリミティブで受信した LIDの接続管理テーブル を作成するとともに、相手局の接続管理サービスポートに対して、受信可能ポートリス トを送信する。
(f) LPPの接続管理サービス力 LPCP力もデータ転送プリミティブ（Send Unit Data, ind)で、受信可能ポートリストを受領すると、同プリミティブで通知された LID の接続管理テーブルに受信可能ポートを登録する。以降は同 LIDに対するトランザ クシヨン開始要求はこの受信可能ポートに対してのみ受け付ける。
(g) 前記 (e)で受信した受信可能ポートリストに含まれるポート番号に対して、 DSR C接続問 、合わせプリミティブ (Connect, req)を発行して 、るアプリケーションに対 して、 DSRC接続通知プリミティブ（Connect, cnf)にて、 LIDおよび送信可能ポート 番号を通知する。
(h) アプリケーションが DSRC接続通知プリミティブ（Connect, cnf)で通知された LIDもしくは同報アドレス、および送信先ポート番号に対して、トランザクション開始要 求プリミティブ (Invoke, req)を発行することで、トランザクションが開始される。
(2)高速接続アプリの初期接続手順
高速接続とは初期接続のための処理を一部省略することにより、高速な初期接続 を実現する手法である。図 55は高速接続アプリの初期接続シーケンス例を示す図で ある。
(a) 移動局及び基地局の各アプリケーションは受信可能なポート番号をポート登録 プリミティブ (Register Port)を用いて、 LPPに登録する。
(b) LPPは接続管理テーブルを更新し、受信可能ポート番号を LPCPに登録する。
(c) 各アプリは QueryLIDおよび Query Portを共に未指定で、トランザクション開 始可能問い合わせプリミティブ (Connect, req)を発行し、 DSRC接続を待ち合わせ る。
(d) LPCPからイベント通知プリミティブ（EventReport. ind)で、イベント「DSRC 接続通知（96)」を受領する。
(e) LPPは同プリミティブで受信した LIDの接続管理テーブルを作成する。高速接 続を必要とするアプリのため、以後、相手局の LPP接続管理サービスから、相手局側 の受信可能ポートリストを受信するまでは、この LIDおよび同報アドレスの全てのポー トに対するトランザクションの開始要求を受け付ける。
(f) DSRC接続問い合わせプリミティブ（Connect, req)を発行しているアプリケー シヨンに対して、 DSRC接続通知プリミティブ（Connect, cnf)にて、 LIDを通知する (g) 各アプリは DSRC接続通知プリミティブで通知された LIDもしくは同報アドレス に対するトランザクション開始要求プリミティブ (Invoke, req)を発行し、トランザクショ ンを開始する。
(h) 前記 (g)で指定したポート番号が相手局に存在する場合は、このトランザクショ ンは成功する。前記 (g)で指定したポート番号が相手局に存在しない場合は、相手 局の LPCP力 イベント通知プリミティブで、イベント「送信先ローカルポートが有効で ない（129)」が通知され、この LIDの接続管理テーブルを更新する。 Transaction Type= 1の場合は、該当するアプリケーションにトランザクション破棄通知プリミティ ブ (Abort, ind)でトランザクションの失敗を通知する。これ以後に、この LIDとポート の組に対し、 Transaction Type= lのトランザクション開始要求（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を作成し、 LPC Pの転送プリミティブ (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タイマー（Resultタイマーのタイムアウト値は Invoke, reqにより指定）を起動 し、相手局からの Result PDUの受信を待ちうける。
(f) 前記（e)で起動した Resultタイマーがタイムアウトすると、 AT=0、 Abort Cod e = 0x08である Abort PDUを生成し、相手局に対して状態「： Resultタイマータイム アウト」を通知するとともに、トランザクション破棄通知プリミティブ (Abort, ind)でトラ ンザクシヨンの失敗をアプリケーションに対して通知する。
(g) Resultタイマーのタイムアウト前に、 LPCPの転送プリミティブ（TransferData . ind)により、相手局カゝら送信された Result PDUを受信すると、前記 (e)で起動し た Resultタイマーを停止するとともに、応答通知プリミティブ (Invoke, cnf)により応 答データをアプリケーションに対して通知する。
[0070] (2)受信処理
(a) LPCPの転送プリミティブ (TransferData. ind)〖こより、相手局から送信された I nvoke 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タイマーがタイムアウトした場合の処理シーケンス例を示す。
[0071] 2. 5. 4 再送処理が有効な場合のデータ転送手順
再送処理は、 Invoke, reqおよび Invoke, resにおいて Require Ack= lを指定 した場合に適用する。以下ではデータ送信トランザクションの Invoke, reqに再送処 理を適用した場合のシーケンスを記述する。リクエスト ·レスポンス型トランザクション サービスにおいては、 Invoke, resについても同様の処理が適用可能である。
(1)送信処理
(a) アプリケーションが Require Ack= 1でトランザクション開始要求プリミティブ（I nvoke. req)を発行することで再送処理が有効なデータ転送サービスが開始される (b) RA= 1である Invoke PDUを作成し、 LPCPの転送プリミティブ（TransferDa ta. req)を用いて、相手局に送信後、再送タイマーを起動し、相手局からの Acknow ledgement PDUの受信を待つ。
(c) 前記（b)で送信された Invoke PDUが到達しないなど何らかの理由により、 Ac knowledgement PDU受信前に、前記（b)で起動した再送タイマーがタイムアウト した場合は、前記 (b)で送信した Invoke PDUの RDフラグを 1にセットして、相手局 に再送信後、再送タイマーを再起動し、再送カウンタをインクリメントする。
(d) 何度か再送を繰り返した後、再送カウンタが最大再送回数を超えた場合は、 A T=0、 Abort Code = 0x07である Abort PDU (2. 4. 1. 4節参照）を生成し、状 態「再送タイマタイムアウト」を相手局に対して通知するとともに、トランザクション破棄 通知プリミティブ (Abort, ind)でトランザクションの失敗をアプリケーションに対して通 知し、このトランザクションを完了する。
(e) 再送タイマーのタイムアウト前に、 LPCPの転送プリミティブ（TransferData. in d)により、相手局から送信された 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を破棄し、再度 A cknowledgement 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 Segment PDU (2. 4. 1. 5節参照）の規定に従つ たヘッダを付カ卩して、 LPCPの転送プリミティブ (TransferData. req)を用いて、順 次送信要求を行う。
(e) ASLの送信キューがオーバフローし、 LPCPから Event Report, indにて、状 態「送信キューに空きがない、送信に失敗した」が通知されると、一定時間ウェイトし、 送信が失敗したデータを含め、再度送信を開始する。
(f) 最後のセグメントデータを送信後、再送タイマーを起動し、相手局からの Ackno wledgement PDU (2. 4. 1. 3節参照）または Nack PDU (2. 4. 1. 7節参照）の 受信を待つ。
(g) LPCPの転送プリミティブ (TransferData. ind)により、相手局から送信された Nack PDUを受信すると、 Nack PDUの Segment Number Listに指定されて いるセグメントを再送する。この際、再送するすべてのセグメントの 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 P DUを受信すると、アプリケーション力 指定された受信キューに順次格納する。
(c) 最終セグメントデータを受信すると、未受信のセグメントがないかどうかを確認し 、未受信のセグメントデータが存在する場合は、 Nack PDU (2. 4. 1. 7節参照）を 作成し、 LPCPの転送プリミティブ (TransferData. req)を用いて、相手局に送信し 、以後受けるべき最終セグメント番号を記憶しておく。
(d) 前記（c)で Nack PDUを送信後に、到着順の入れ替わりなどの理由で、 RDフ ラグがセットされて 1、な 1、データを受信した場合は、そのデータを破棄する。
(e) 最終セグメントデータを受信時に、全てのセグメントデータを受信していれば、ト ランザクシヨン通知プリミティブ (Invoke, ind)を用いて、アプリケーションに対して、 受信データを通知するとともに、 Acknowledgement PDUを生成し、 LPCPの転 送プリミティブ (TransferData. req)により、相手局に対して送信する。
図 62に分割'組立処理が有効な場合の基本処理シーケンス例を、図 63に分割デ ータの一部が欠落し、選択的再送処理が行われる場合の処理シーケンス例を、図 6 4に最終セグメントデータが欠落し、再送処理が行われる場合の処理シーケンス例を 示す。
[0075] 2. 5. 6 通信終了手順
(a) LPCPからイベント通知プリミティブ（EventReport. ind)で、イベント「DSRC 切断通知（98)」を受領する。
(b) 当該 LIDを使用中のアプリケーションに対し、 DSRC切断通知プリミティブ (Dis connect, ind)を発行する。
(c) LPPは同プリミティブで受信した LIDの接続管理テーブルを削除する。以後同 LIDに対するトランザクション開始要求は受け付けない。
図 65は DSRC切断時の手順を示す図である。
[0076] 2. 5. 7 トランザクションの破棄手順
ローカルポートプロトコルでは、トランザクションが以下の状態にあるとき、アプリケー シヨンからトランザクションの破棄を要求できる。
図 66はトランザクション破棄手順を示す図である。
送信側
•リクエスト.レスポンス型のトランザクションで Invoke, req受付後、 Result PDUの 受信により、 Invoke, cnfを発行するまでの間。
受信側
'リクエスト.レスポンス型のトランザクションで、 Invoke, ind発行後、 Invoke, res受 付により、 Result PDUを送信するまでの間。
以下に処理シーケンスを記述する。
(a)アプリケーションからトランザクション破棄要求プリミティブ (Abort, req)を受信す ることで、このシーケンスは開始される。
(b) LPPは同プリミティブで指定されたトランザクションに対する Abort PDUを生成 し、 LPCPの転送要求プリミティブ (TmnsferData. req)を用いて、相手局に送信す る。
(c)要求元のアプリケーションに対してトランザクション破棄通知プリミティブ (Abort, ind)を発行し、トランザクションの破棄完了を通知する。
(d) LPPが LPCPの転送通知プリミティブ（TransferData. ind)により、 Abort PD Uを受信すると、自局内に同 PDUの TIDにより指定されたトランザクションが実行中 の場合は、そのトランザクションに関するリソースをすベて破棄した後、アプリケーショ ンに対して、トランザクション破棄通知プリミティブ (Abort, ind)を発行し、トランザク シヨン破棄を通知する。
[0077] なお、上記実施の形態では、狭域通信（DSRC)プロトコル (ARIB STD— T75)と 、双方向に通信可能なプロトコルである拡張通信制御プロトコル (ASL— ELCP)と、 転送サービス処理部 (LPCP)と、トランザクション管理部 (LPP)とからなる階層構造 を示した力 拡張通信制御プロトコル (ASL— ELCP)の代わりに他の双方向に通信 可能なプロトコルを用いても良 、。
[0078] 以上のように、本発明に係る路車間通信システムは、路側システムおよび移動局内 の双方のローカルアプリケーションが非ネットワーク型のプロトコルを利用して通信を 行うシステムであって、本発明に係る路車間通信システムは、路側システムおよび移 動局内の双方のローカルアプリケーションが非ネットワーク型のプロトコルを利用して 通信を行うシステムであって、前記非ネットワーク型のプロトコルを、マルチアプリケー シヨンを実現するための転送サービス処理部と、未達データの再送信機構、メッセ一 ジ単位のデータ送受信機構、メッセージの分割 ·組立機構を有し、単方向のデータ 送信とリクエスト ·レスポンス型のトランザクションサービスを提供するトランザクションサ 一ビスを行うトランザクション管理部とで構成することを特徴とする。
[0079] また、本発明の路車間通信システムにおいては、送受信双方のアプリケーションを 識別するためにポート番号を利用することで、非ネットワーク型のプロトコルにおいて も、複数のアプリケーションの同時実行を可能にする。
また、最も単純なアプリケーションは転送サービス処理部を直接使用することで実 現が可能であり、高速接続性、低オーバヘッドといった走行中の路車間通信に必要 な要件を満たすことができる。
また、停止中や低速走行中などでは、トランザクション管理部を使用することによつ て、大容量データの送受信やリクエスト ·レスポンス型のサービスのような高度な通信 サービスを必要とするアプリケーションに対しても容易に対応できるようになる。
また、プロトコルを拡張する際に、拡張箇所をトランザクション管理部に局所ィ匕する ことで、拡張を容易にすることができる。
さらに、アプリケーション力 指定された識別子 (送信データ識別子）により送信デ ータの単位を識別する。またこのプロトコルは、送信データ単位が下位層のプロトコ ルで一度に送信可能なサイズよりも大きい場合には、送信可能なサイズに分割し、順 序番号を付けて送信し、受信側でその順序番号を元に組み立てる機能を有する。 このとき、最終データの受信時に未受信のデータの順序番号を送信側に通知する ことで、未受信のデータのみを再送信することで通信誤り率を改善する。
また、送信元のアプリケーション識別子 (送信元ポート番号）とそのアプリケーション が指定した送信データ識別子の組が同一の場合には、受信側で既受信の同一識別 子のデータと同一のデータとして扱うことで、任意のタイミングでのデータの再送信を 可能とする。このため、一定時間通信できない場合においても、通信誤り率を改善で きる。

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に記載の路車間通信システム。
PCT/JP2004/014490 2003-10-15 2004-10-01 路車間通信システム WO2005039075A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2005514730A JP4396639B2 (ja) 2003-10-15 2004-10-01 路車間通信システム、基地局装置、及び移動局装置
CN2004800252613A CN1846375B (zh) 2003-10-15 2004-10-01 道路车间通信系统
US10/568,346 US7843869B2 (en) 2003-10-15 2004-10-01 Roadside to vehicle communication system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2003-355354 2003-10-15
JP2003355354 2003-10-15

Publications (1)

Publication Number Publication Date
WO2005039075A1 true WO2005039075A1 (ja) 2005-04-28

Family

ID=34463167

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2004/014490 WO2005039075A1 (ja) 2003-10-15 2004-10-01 路車間通信システム

Country Status (5)

Country Link
US (1) US7843869B2 (ja)
JP (2) JP4396639B2 (ja)
KR (1) KR100733196B1 (ja)
CN (1) CN1846375B (ja)
WO (1) WO2005039075A1 (ja)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007067886A (ja) * 2005-08-31 2007-03-15 Mitsubishi Electric Corp 移動局装置及び外部端末
JP2008072287A (ja) * 2006-09-13 2008-03-27 Mitsubishi Electric Corp 路車間通信装置
JP2008099116A (ja) * 2006-10-13 2008-04-24 Matsushita Electric Ind Co Ltd 路車間通信方法及び路車間通信装置
JP2008141708A (ja) * 2005-12-08 2008-06-19 Mitsubishi Electric Corp Ｄｓｒｃ無線装置およびｄｓｒｃシステム
WO2009133740A1 (ja) * 2008-04-30 2009-11-05 三菱電機株式会社 車載通信装置および路車間－車々間通信連携システム
JP2012521698A (ja) * 2009-03-25 2012-09-13 インターナショナル・ビジネス・マシーンズ・コーポレーション 複数のデータ処理アプリケーションのためのデータ通信パケットのステアリング
JP2012199816A (ja) * 2011-03-22 2012-10-18 Denso Corp データ受信装置、およびデータ受信プログラム
KR20190039569A (ko) 2016-09-21 2019-04-12 미쓰비시덴키 가부시키가이샤 노측 통신 장치 및 차량탑재 통신 장치
WO2020175604A1 (ja) * 2019-02-27 2020-09-03 パナソニックＩｐマネジメント株式会社 無線通信端末装置及びその無線通信方法
JP2020141218A (ja) * 2019-02-27 2020-09-03 パナソニックＩｐマネジメント株式会社 無線通信端末装置及びその無線通信方法

Families Citing this family (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101265628B1 (ko) 2006-01-05 2013-05-22 엘지전자 주식회사 이동 통신 시스템에서의 무선 자원 스케줄링 방법
CN105515736A (zh) 2006-01-05 2016-04-20 Lg电子株式会社 在移动通信系统中发送数据
KR101319870B1 (ko) 2006-01-05 2013-10-18 엘지전자 주식회사 이동 통신 시스템에서의 핸드오버 방법
CN101682557A (zh) * 2006-01-05 2010-03-24 Lg电子株式会社 在移动通信系统中发送数据
EP1969738B1 (en) 2006-01-05 2014-03-12 LG Electronics Inc. Transmitting information in mobile communications system
KR101268200B1 (ko) 2006-01-05 2013-05-27 엘지전자 주식회사 이동통신 시스템에서의 무선자원 할당방법
WO2007078171A2 (en) 2006-01-05 2007-07-12 Lg Electronics Inc. Method of transmitting feedback information in a wireless communication system
KR101333918B1 (ko) 2006-01-05 2013-11-27 엘지전자 주식회사 이동 통신 시스템의 점-대-다 서비스 통신
KR101211807B1 (ko) * 2006-01-05 2012-12-12 엘지전자 주식회사 이동통신 시스템에서 무선단말의 동기상태 관리방법
KR101203841B1 (ko) 2006-01-05 2012-11-21 엘지전자 주식회사 무선 통신 시스템에서의 페이징 메시지 전송 및 수신 방법
KR101187076B1 (ko) * 2006-01-05 2012-09-27 엘지전자 주식회사 이동 통신 시스템에 있어서 신호 전송 방법
KR101358469B1 (ko) 2006-02-07 2014-02-06 엘지전자 주식회사 무선 네트워크(ｎｅｔｗｏｒｋ) 안에서 상향(ｕｐｌｉｎｋ)및 하향(ｄｏｗｎｌｉｎｋ) 대역폭(ｂａｎｄｗｉｄｔｈ)의선택 및 신호 방법
KR101216751B1 (ko) 2006-02-07 2012-12-28 엘지전자 주식회사 이동 통신 시스템에서 식별자를 이용한 충돌 회피 방법
US8493854B2 (en) 2006-02-07 2013-07-23 Lg Electronics Inc. Method for avoiding collision using identifier in mobile network
KR101387475B1 (ko) 2006-03-22 2014-04-22 엘지전자 주식회사 복수의 네트워크 엔터티를 포함하는 이동 통신시스템에서의 데이터 처리 방법
US8570956B2 (en) 2006-06-21 2013-10-29 Lg Electronics Inc. Method of communicating data in a wireless mobile communications system using message separation and mobile terminal for use with the same
WO2007148881A2 (en) 2006-06-21 2007-12-27 Lg Electronics Inc. Method of supporting data retransmission in a mobile communication system
KR20070121505A (ko) * 2006-06-21 2007-12-27 엘지전자 주식회사 무선링크 재설정 방법
KR20070121513A (ko) 2006-06-21 2007-12-27 엘지전자 주식회사 이동통신 시스템의 상향 접속 방법
KR101369135B1 (ko) 2006-06-21 2014-03-05 엘지전자 주식회사 이동통신 시스템에서의 멀티미디어 및 방송서비스의 품질보장 방법 및 그 단말
KR100881419B1 (ko) * 2006-11-02 2009-02-05 한국전자통신연구원 Ｓｃａ 기반 시스템의 애플리케이션 컴포넌트 통신 장치 및방법
US7953895B1 (en) * 2007-03-07 2011-05-31 Juniper Networks, Inc. Application identification
DE102007053255B4 (de) * 2007-11-08 2009-09-10 Continental Automotive Gmbh Verfahren zum Bearbeiten von Nachrichten und Nachrichtenbearbeitungsvorrichtung
JP5374929B2 (ja) * 2008-06-05 2013-12-25 富士通株式会社 移動通信システム、移動通信方法および通信装置
US20100161518A1 (en) * 2008-12-22 2010-06-24 Nathan Bowman Littrell Electricity storage controller with integrated electricity meter and methods for using same
US20100161517A1 (en) * 2008-12-22 2010-06-24 Nathan Bowman Littrell Systems and methods for electricity metering for vehicular applications
US9030153B2 (en) 2008-12-22 2015-05-12 General Electric Company Systems and methods for delivering energy to an electric vehicle with parking fee collection
US9505317B2 (en) 2008-12-22 2016-11-29 General Electric Company System and method for electric vehicle charging and billing using a wireless vehicle communication service
US9396462B2 (en) 2008-12-22 2016-07-19 General Electric Company System and method for roaming billing for electric vehicles
US8583551B2 (en) 2008-12-22 2013-11-12 General Electric Company Systems and methods for prepaid electric metering for vehicles
US8315930B2 (en) 2008-12-22 2012-11-20 General Electric Company Systems and methods for charging an electric vehicle using broadband over powerlines
US8213990B2 (en) * 2009-06-05 2012-07-03 Mediatek Inc. System for providing remote subscriber identity card to mobile station and methods thereof
CN102014530A (zh) * 2009-09-04 2011-04-13 中兴通讯股份有限公司 一种配置更新失败后的处理方法和网元设备
CN103562979B (zh) * 2011-05-12 2014-11-19 丰田自动车株式会社 路车间通信系统和驾驶支援系统
JP5804072B2 (ja) * 2011-09-22 2015-11-04 日本電気株式会社 車載装置、通信システムおよび通信方法
US9077752B2 (en) * 2011-12-23 2015-07-07 Cirrus Data Solutions, Inc. Systems, apparatus, and methods for identifying stored data that may be accessed by a host entity and providing data management services
US9686190B2 (en) * 2012-03-29 2017-06-20 Intel Corporation Techniques for forwarding or receiving data segments associated with a large data packet
US9794311B2 (en) * 2014-03-18 2017-10-17 Qualcomm Incorporated Transport accelerator implementing extended transmission control functionality
US20170279924A1 (en) 2016-03-27 2017-09-28 International Business Machines Corporation Cancellation management with respect to a web application
KR102331209B1 (ko) * 2016-07-12 2021-11-24 후아웨이 테크놀러지 컴퍼니 리미티드 차량 외부 통신 방법, 장치 및 단말
KR101915944B1 (ko) * 2017-05-08 2018-11-08 주식회사 애포샤 클러스터 시스템에서의 클라이언트 요청 처리 방법, 상기 클라이언트 요청에 따른 입출력 처리 방법 및 장치
US10606604B2 (en) * 2017-08-22 2020-03-31 Bank Of America Corporation Predictive queue control and allocation
EP3941020B1 (en) * 2020-07-16 2023-06-14 Volkswagen Aktiengesellschaft A method for controlling a communication between a vehicle and a backend device
DE102021208802A1 (de) 2021-08-11 2023-02-16 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zur Absicherung einer Kommunikation zwischen einer straßenseitigen Funkeinheit und Fahrzeugen, Computerprogramm und System zur Unterstützung von Fahrzeugen, Verfahren zur Überwachung der straßenseitigen Funkeinheit und Überwachungseinheit

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000358276A (ja) * 1999-06-15 2000-12-26 Denso Corp 移動体通信装置および固定局通信装置ならびに移動体通信装置の通信方法
JP2001186576A (ja) * 1999-10-15 2001-07-06 Denso Corp 移動体通信装置、固定局通信装置、アプリケーション処理装置および移動体通信装置の通信方法
JP2001298397A (ja) * 2000-04-13 2001-10-26 Denso Corp 通信システム及び車載装置並びに記録媒体
JP2003032752A (ja) * 2001-07-19 2003-01-31 Nec Eng Ltd 大容量狭域通信システム

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5424727A (en) * 1994-03-22 1995-06-13 Best Network Systems, Inc. Method and system for two-way packet radio-based electronic toll collection
JP3208305B2 (ja) * 1995-11-14 2001-09-10 シャープ株式会社 通信装置および通信方法
JP3211674B2 (ja) * 1996-08-22 2001-09-25 株式会社デンソー 車両用通信装置
US6496502B1 (en) * 1998-06-29 2002-12-17 Nortel Networks Limited Distributed multi-link trunking method and apparatus
WO2000003516A1 (en) * 1998-07-08 2000-01-20 Broadcom Corporation Network switching architecture with multiple table synchronization, and forwarding of both ip and ipx packets
JP3053181B1 (ja) * 1999-01-28 2000-06-19 日本電気株式会社 無線デ―タ通信装置及び無線デ―タ通信方法
JP3764016B2 (ja) 1999-05-10 2006-04-05 財団法人流通システム開発センタ− 統合ｉｐ転送網
JP3669619B2 (ja) 1999-09-06 2005-07-13 富士通株式会社 無線端末装置のソフトウェア更新方法及びその装置
FI19992470A (fi) * 1999-11-17 2001-05-18 Nokia Mobile Phones Ltd Tiedonsiirto
US6834326B1 (en) * 2000-02-04 2004-12-21 3Com Corporation RAID method and device with network protocol between controller and storage devices
JP3514228B2 (ja) * 2000-10-25 2004-03-31 日本電気株式会社 狭域無線連続通信方法とシステム
KR100400549B1 (ko) * 2000-12-22 2003-10-08 엘지전자 주식회사 단거리 무선전용 통신망을 이용한 지리정보 서비스 장치
DE10104713A1 (de) * 2001-02-02 2002-08-08 Siemens Ag Verfahren und Vorrichtungen zum Zugreifen auf Nachrichten
JP3777996B2 (ja) 2001-03-13 2006-05-24 株式会社Ｋｄｄｉ研究所 路車間通信システムにおけるハンドオーバのデータ制御方法
JP3666406B2 (ja) * 2001-04-04 2005-06-29 日本電気株式会社 ノンストップ料金課金方法及びシステム
JP2004528783A (ja) * 2001-05-22 2004-09-16 ノキア コーポレイション コンテキスト起動を制御するための方法、ネットワーク装置、及び端末装置
JP3804477B2 (ja) 2001-06-27 2006-08-02 三菱電機株式会社 Ａｔｍ終端装置およびｐｏｎシステム
US20030033418A1 (en) * 2001-07-19 2003-02-13 Young Bruce Fitzgerald Method of implementing and configuring an MGCP application layer gateway
KR100798597B1 (ko) * 2001-08-29 2008-01-28 엘지전자 주식회사 노변기지국의 채널정보 제공방법
KR100431003B1 (ko) 2001-10-31 2004-05-12 삼성전자주식회사 데이터 송수신 시스템 및 방법
JP4062489B2 (ja) 2002-02-07 2008-03-19 独立行政法人情報通信研究機構 通信方法、基地局および端末
US7146427B2 (en) * 2002-04-23 2006-12-05 Lsi Logic Corporation Polling-based mechanism for improved RPC timeout handling
US7277449B2 (en) * 2002-07-29 2007-10-02 Freescale Semiconductor, Inc. On chip network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000358276A (ja) * 1999-06-15 2000-12-26 Denso Corp 移動体通信装置および固定局通信装置ならびに移動体通信装置の通信方法
JP2001186576A (ja) * 1999-10-15 2001-07-06 Denso Corp 移動体通信装置、固定局通信装置、アプリケーション処理装置および移動体通信装置の通信方法
JP2001298397A (ja) * 2000-04-13 2001-10-26 Denso Corp 通信システム及び車載装置並びに記録媒体
JP2003032752A (ja) * 2001-07-19 2003-01-31 Nec Eng Ltd 大容量狭域通信システム

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4615399B2 (ja) * 2005-08-31 2011-01-19 三菱電機株式会社 移動局装置及び外部端末
JP2007067886A (ja) * 2005-08-31 2007-03-15 Mitsubishi Electric Corp 移動局装置及び外部端末
JP2008141708A (ja) * 2005-12-08 2008-06-19 Mitsubishi Electric Corp Ｄｓｒｃ無線装置およびｄｓｒｃシステム
JP2008072287A (ja) * 2006-09-13 2008-03-27 Mitsubishi Electric Corp 路車間通信装置
JP2008099116A (ja) * 2006-10-13 2008-04-24 Matsushita Electric Ind Co Ltd 路車間通信方法及び路車間通信装置
JP4697804B2 (ja) * 2006-10-13 2011-06-08 パナソニック株式会社 路車間通信方法及び路車間通信装置
US8412107B2 (en) 2008-04-30 2013-04-02 Mitsubishi Electric Corporation On-board communication device and cooperative road-to-vehicle/car-to-car communication system
WO2009133740A1 (ja) * 2008-04-30 2009-11-05 三菱電機株式会社 車載通信装置および路車間－車々間通信連携システム
DE112009001028T5 (de) 2008-04-30 2011-04-28 Mitsubishi Electric Corp. Bordkommunikationsvorrichtung und Kooperatives Strasse-Fahrzeug/Auto-Auto Kommunikationssystem
CN102047698A (zh) * 2008-04-30 2011-05-04 三菱电机株式会社 车载通信装置以及路车间-车车间通信协作系统
JP4999989B2 (ja) * 2008-04-30 2012-08-15 三菱電機株式会社 車載通信装置および路車間−車々間通信連携システム
DE112009001028B4 (de) * 2008-04-30 2017-05-04 Mitsubishi Electric Corp. Verfahren zur Bordkommunikation, Bordkommunikationsvorrichtung und Kooperatives Strasse-Fahrzeug/Auto-Auto Kommunikationssystem
JP2012521698A (ja) * 2009-03-25 2012-09-13 インターナショナル・ビジネス・マシーンズ・コーポレーション 複数のデータ処理アプリケーションのためのデータ通信パケットのステアリング
JP2012199816A (ja) * 2011-03-22 2012-10-18 Denso Corp データ受信装置、およびデータ受信プログラム
KR20190039569A (ko) 2016-09-21 2019-04-12 미쓰비시덴키 가부시키가이샤 노측 통신 장치 및 차량탑재 통신 장치
US10863332B2 (en) 2016-09-21 2020-12-08 Mitsubishi Electric Corporation Roadside communication apparatus and in-vehicle communication apparatus
WO2020175604A1 (ja) * 2019-02-27 2020-09-03 パナソニックＩｐマネジメント株式会社 無線通信端末装置及びその無線通信方法
JP2020141218A (ja) * 2019-02-27 2020-09-03 パナソニックＩｐマネジメント株式会社 無線通信端末装置及びその無線通信方法
JP7373737B2 (ja) 2019-02-27 2023-11-06 パナソニックＩｐマネジメント株式会社 無線通信端末装置及びその無線通信方法
US11882606B2 (en) 2019-02-27 2024-01-23 Panasonic Intellectual Property Management Co., Ltd. Wireless communication terminal device, and wireless communication method therefor

Also Published As

Publication number Publication date
CN1846375A (zh) 2006-10-11
JP4396639B2 (ja) 2010-01-13
KR100733196B1 (ko) 2007-06-28
JP4697490B2 (ja) 2011-06-08
US7843869B2 (en) 2010-11-30
JP2009077422A (ja) 2009-04-09
CN1846375B (zh) 2011-04-20
JPWO2005039075A1 (ja) 2007-02-08
US20060193282A1 (en) 2006-08-31
KR20060095868A (ko) 2006-09-04

Similar Documents

Publication Publication Date Title
WO2005039075A1 (ja) 路車間通信システム
US9674832B2 (en) Method and apparatus for layer 2 ARQ for packets
RU2289204C2 (ru) Способ и система мобильной связи
US7965674B2 (en) Sub-segment based transport layer protocol for wireless medium
TWI260884B (en) Method for handling a triggered reset when an RLC is stopped in a wireless communications system
KR101653310B1 (ko) Ｍａｃ 헤더 타입 정보를 이용한 ｍａｃ ｐｄｕ 송수신 방법 및 장치
WO2011020233A1 (zh) 多跳中继通信系统中对下行数据传输控制的方法和装置
JP2003124969A (ja) 通信システムでデータを送信するための方法及び装置
KR20030042847A (ko) 송신버퍼의 프로토콜 데이터 유닛 폴링 방법
WO2011100911A2 (zh) 探测处理方法、数据发送端、数据接收端以及通信系统
CN107342983A (zh) 一种事务性处理多分包的高效udp通讯的方法及系统
CN102769520A (zh) 基于sctp协议的无线网络拥塞控制方法
US7680122B2 (en) Communication method for data communication based on point-to-point protocol
US7535916B2 (en) Method for sharing a transport connection across a multi-processor platform with limited inter-processor communications
US7414974B2 (en) Transmission control apparatus and method for TCP/IP suite
JP3727198B2 (ja) ゲートウェイ装置
CN107968754B (zh) 流表下发方法、接收方法、控制器、交换机及转发系统
JP4882856B2 (ja) 通信システム、通信装置、通信方法及び通信プログラム
KR20030094974A (ko) 이동통신 시스템의 데이터 호 트래픽 프레임 제어방법
KR100370060B1 (ko) 차세대 이동 통신 시스템의 통신 운용 방법
JP2003046432A (ja) 路側装置及び車載装置
JP2003229900A (ja) 中継処理装置及び中継処理方法
KR100291021B1 (ko) 광 가입자 분배망에서 호스트 디지털 터미널과 광 네트워크 유니트의 프로세서간 통신 프로토콜방법
CN100399841C (zh) 一种应用于即按即说通信中的信令消息重发方法
CN117956045A (en) Communication system and method based on UDP protocol

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200480025261.3

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2005514730

Country of ref document: JP

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2006193282

Country of ref document: US

Ref document number: 10568346

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 1020067007142

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 10568346

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 1020067007142

Country of ref document: KR

122 Ep: pct application non-entry in european phase