[go: up one dir, main page]

WO2009133740A1 - 車載通信装置および路車間－車々間通信連携システム - Google Patents

車載通信装置および路車間－車々間通信連携システム Download PDF

Info

Publication number
WO2009133740A1
WO2009133740A1 PCT/JP2009/056057 JP2009056057W WO2009133740A1 WO 2009133740 A1 WO2009133740 A1 WO 2009133740A1 JP 2009056057 W JP2009056057 W JP 2009056057W WO 2009133740 A1 WO2009133740 A1 WO 2009133740A1
Authority
WO
WIPO (PCT)
Prior art keywords
processing unit
vehicle communication
service processing
vehicle
inter
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2009/056057
Other languages
English (en)
French (fr)
Inventor
悠司 濱田
良次 澤
幸夫 後藤
茂樹 森田
喜秋 津田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
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 Electric Corp filed Critical Mitsubishi Electric Corp
Priority to DE112009001028.8T priority Critical patent/DE112009001028B4/de
Priority to CN2009801204592A priority patent/CN102047698B/zh
Priority to US12/937,605 priority patent/US8412107B2/en
Priority to JP2010510064A priority patent/JP4999989B2/ja
Publication of WO2009133740A1 publication Critical patent/WO2009133740A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

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
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096766—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission
    • G08G1/096791—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission where the origin of the information is another vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
    • Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
    • Y04S40/18—Network protocols supporting networked applications, e.g. including control of end-device applications over a network

Definitions

  • the present invention provides services to mobile stations using inter-vehicle communication performed between mobile stations traveling on a road and road-to-vehicle communication performed between a base station apparatus installed on the road and the mobile station.
  • the present invention relates to an in-vehicle communication device to be provided and a road-vehicle-to-vehicle communication cooperation system.
  • Patent Document 1 congestion is avoided by performing transmission cycle control (information amount control) of the host vehicle based on the dangerous situation of the vehicle and the traffic amount of the communication path so that congestion does not occur in the inter-vehicle communication system.
  • transmission cycle control information amount control
  • the in-vehicle communication device described in Patent Literature 1 performs communication control assuming only a single application as an information exchange type application, and therefore supports communication control when simultaneously using other multiple applications such as an emergency application. I did not.
  • the in-vehicle communication device described in Patent Document 1 cannot secure a communication band in advance for other multiple applications such as an emergency application.
  • the present invention has been made to solve the above-described problems, and performs communication control to avoid information congestion, and provides priority control and initial connection establishment procedures required for a vehicle-to-vehicle communication system.
  • an in-vehicle communication device and a road-vehicle-to-vehicle communication cooperation system that can handle a plurality of applications, can retransmit, divide / assemble messages, and can handle both a road-vehicle communication system and a vehicle-to-vehicle communication system are provided. For the purpose.
  • the in-vehicle communication device is mounted on each of a mobile station and a base station, and is mutually connected between the mobile station and between the mobile station and the base station by radio communication.
  • the in-vehicle communication device is connected to the application processing unit that periodically transmits a message to the in-vehicle communication device on the receiving side, and is received from the application processing unit.
  • a transaction management unit that provides at least a transaction service including retransmission and division / assembly of the message; and an upper-layer protocol that is connected to the transaction management unit and includes the application processing unit in the message received from the transaction management unit.
  • a transfer service processing unit connected to the transfer service processing unit and the messages received from the transfer service processing unit are transmitted to the in-vehicle communication device on the receiving side in order of priority of applications processed by the application processing unit.
  • Connected to the inter-vehicle communication transfer service processing unit for transmitting and receiving the message to the transfer service processing unit and notifying event information including error information, and the inter-vehicle communication transfer service.
  • the message received from the processing unit is connected to the transmission / reception service processing unit that transmits / receives the message to / from the receiving-side in-vehicle communication device by wireless communication, the application processing unit, and the inter-vehicle communication transfer service processing unit, and the application
  • the priority is set by the processing unit.
  • An inter-vehicle communication management service processing unit that notifies the priority in response to a request from the inter-vehicle communication transfer service processing unit, and the transaction management unit and the transfer service processing unit are connected between the mobile station and the base station.
  • a vehicle-to-vehicle communication protocol for performing road-to-vehicle communication between the vehicles, and the vehicle-to-vehicle communication transfer service processing unit has communication control information of the vehicle-to-vehicle communication management service processing unit with respect to the in-vehicle communication device on the receiving side
  • the in-vehicle communication device on the receiving side transmits the communication control information given to the received message to the inter-vehicle communication management service processing unit in the inter-vehicle communication transfer service processing unit, and receives the received The message is transmitted to the transfer service processing unit.
  • An in-vehicle communication device is mounted on each of a mobile station and a base station, and is connected to the reception side and the transmission side between the mobile stations and between the mobile station and the base station by wireless communication.
  • the in-vehicle communication device is an application processing unit that transmits a message from the transmitting side to the receiving side using road-to-vehicle communication and inter-vehicle communication, and the application processing unit.
  • Transaction service including retransmission and division / assembly of the received message, addition of a local port number for identifying an upper protocol including the application processing unit, and a path for determining the transmission destination of the message according to the upper protocol
  • Inter-Vehicle-Vehicle Communication Cooperation Service Processing Unit and the Road-Vehicle-Vehicle Communication Cooperation Service Processing Unit Vehicle-to-vehicle communication transfer service processing unit for transmitting the message received from the unit to the in-vehicle communication device on the receiving side in order of priority of the application processed by the application processing unit, and the vehicle-to-vehicle communication transfer service processing unit
  • An identifier for identification is given to the message given via the network and the message directly given from the road-vehicle-to-vehicle communication cooperation service processing unit, and transmitted to the in-vehicle communication device on the receiving side by wireless communication
  • a transmission / reception service processing unit and an inter-vehicle communication management service processing unit that sets the priority from the application processing
  • the inter-vehicle communication cooperation service processing unit receives from the application processing unit. It is determined whether the message is transmitted by road-to-vehicle communication or vehicle-to-vehicle communication. In the case of road-to-vehicle communication, the message is directly given to the transmission / reception service processing unit, and in the case of vehicle-to-vehicle communication.
  • the transmission / reception service processing unit is given to the transmission / reception service processing unit via the inter-vehicle communication transfer service processing unit, and the transmission / reception service processing unit of the reception-side in-vehicle communication device is attached to the message received from the transmission-side in-vehicle communication device Based on the received identifier, the message is transmitted to the road-vehicle-vehicle communication cooperation service processing unit or the vehicle-to-vehicle communication transfer service processing unit.
  • the transaction management unit and the transfer service processing unit which are existing road-to-vehicle communication protocols, include an inter-vehicle communication transfer service processing unit and an inter-vehicle communication management service processing unit.
  • an inter-vehicle communication transfer service processing unit and an inter-vehicle communication management service processing unit.
  • road-to-vehicle communication data can be transmitted without going through the vehicle-to-vehicle communication transfer service processing unit
  • the inter-vehicle communication data can be transmitted to the other party by performing necessary control via the inter-vehicle communication transfer service processing unit.
  • a system capable of the above-described service can be obtained by configuring a road-to-vehicle / vehicle-to-vehicle communication cooperation system by the in-vehicle communication device.
  • Embodiment 1 > ⁇ A-1. Protocol configuration> Embodiment 1 according to the present invention will be described with reference to FIGS.
  • the in-vehicle communication device and the road-vehicle-to-vehicle communication linkage system according to the first embodiment provide a service as an in-vehicle communication device of a road-to-vehicle communication system, or provide a service as an in-vehicle communication device of a vehicle-to-vehicle communication system. be able to.
  • a service is provided mainly as an in-vehicle communication device of an inter-vehicle communication system will be described.
  • FIG. 1 is a block diagram schematically showing the protocol configuration of the in-vehicle communication device 100 and the road-vehicle-vehicle-to-vehicle communication linkage system according to Embodiment 1 of the present invention
  • FIG. 2 is a block diagram showing the protocol configuration in detail. is there. 1 and 2, the same or corresponding components are denoted by the same reference numerals, and this is common throughout the entire specification.
  • the in-vehicle communication device 100 is mounted on each of a plurality of vehicles. Then, wireless communication is performed between the vehicles through the in-vehicle communication device 100.
  • the in-vehicle communication device 100 refers to a communication device that is fixed like a mobile communication terminal or a base station mounted on an automobile.
  • the wireless communication may use DSRC, or communication using a protocol such as a wireless LAN (Local Area Network) or a mobile phone.
  • first vehicle first vehicle
  • second vehicles peripheral vehicles
  • the in-vehicle communication device 100 includes an inter-vehicle communication transfer service processing unit 1, an inter-vehicle communication management service processing unit 2, an application processing unit 3, a transaction management unit 4, a transfer service processing unit 5, A transmission / reception service processing unit 6 and a transmission / reception service management unit 7 are provided.
  • inter-vehicle communication transfer service processing unit 1 and the inter-vehicle communication management service processing unit 2 are collectively referred to as an inter-vehicle communication sub-protocol.
  • the inter-vehicle communication transfer service processing unit 1 (hereinafter also referred to as an inter-vehicle communication transport sub-layer) is interposed between the transfer service processing unit 5 and the transmission / reception service processing unit 6 and communicates the priority of the application of the application processing unit 3 to the inter-vehicle communication.
  • a priority control service that obtains from the management service processing unit 2 and controls the order of transmission according to the priority is provided.
  • a data transfer service for transmitting / receiving messages and an event notification service for notifying errors are provided to the transfer service processing unit 5, the inter-vehicle communication management service processing unit 2, and the like.
  • the inter-vehicle communication management service processing unit 2 (hereinafter also referred to as an inter-vehicle communication management layer) is connected to the application processing unit 3, the transaction management unit 4, the transfer service processing unit 5, the inter-vehicle communication transfer service processing unit 1 and the transmission / reception service management unit 7.
  • Information congestion by using vehicle information such as vehicle position information and speed information of the application processing unit 3 and communication channel utilization rate information of the transmission / reception service management unit 7. Provide a congestion control service to avoid it.
  • the vehicle information includes vehicle speed, acceleration / deceleration, position, traveling direction, turn signal ON / OFF information, and the like.
  • inter-vehicle communication management service processing unit 2 provides a connection procedure and a disconnection procedure for initial connection and a communication connection management service for managing the communication status in order to connect to the inter-vehicle communication management service processing unit 2 of the counterpart station. To do.
  • the inter-vehicle communication management service processing unit 2 communicates with the application processing unit 3 in order to notify the application processing unit 3 of the transmission cycle used for the congestion control service and the communication status of the communication connection management service (third Interface). Further, the inter-vehicle communication management service processing unit 2 sets the transmission power, reception sensitivity, and transmission channel information used for the congestion control service, and acquires the communication channel utilization rate information. Interface (first interface).
  • the inter-vehicle communication management service processing unit 2 acquires communication control information added to data to be transmitted, sets communication control information added to received data, and sets the control data to the inter-vehicle communication management service processing unit of the counterpart station. 2 also has an interface (second interface) with the inter-vehicle communication transfer service processing unit 1. Furthermore, the inter-vehicle communication management service processing unit 2 also provides a retransmission control service for control data transmitted to the counterpart station.
  • the application processing unit 3 (hereinafter also referred to as an application) includes an inter-vehicle communication application that operates on the transaction management unit 4.
  • the application processing unit 3 may include an application other than an application related to a road-to-vehicle communication system or an application related to ITS (Intelligent Transport Systems) in addition to the inter-vehicle communication application.
  • the transaction management unit 4 (hereinafter also referred to as a local port protocol) is a communication protocol that is interposed between the application processing unit 3 and the transfer service processing unit 5 and extends the functions of the transfer service processing unit 5.
  • the transaction management unit 4 provides a transaction service such as message retransmission and division / assembly, and a connection management service for managing communication status such as communication connection and disconnection.
  • the transfer service processing unit 5 (hereinafter also referred to as a local port control protocol) is a control protocol for interposing applications between the transaction management unit 4 and the inter-vehicle communication transfer service processing unit 1.
  • the transfer service processing unit 5 has a service primitive (interface) for a management service such as data transfer and event notification for the upper protocol, in order to realize a multi-application, by identifying the upper protocol by a local port number.
  • the transmission / reception service processing unit 6 (hereinafter also referred to as a physical layer and a data link layer) provides a transmission service and a reception service in order to perform wireless communication with the in-vehicle communication device 100 mounted on a peripheral station.
  • the transmission / reception service management unit 7 (hereinafter also referred to as a physical layer management unit or a data link layer management unit) manages a transmission / reception service processing unit 6 and stores a management information base ( MIB: Management Information Base.
  • MIB Management Information Base
  • the inter-vehicle communication transfer service processing unit 1 includes a data transfer service processing unit 11, an event notification service processing unit 12, and a priority control service processing unit 13.
  • the data transfer service processing unit 11 provides a data transfer service that transmits a message in response to a request from a higher-level protocol such as the application processing unit 3. Further, by adding communication control information such as a transmission period and transmission power to transmitted / received data (PDU), information for use in congestion control can be notified to the inter-vehicle communication transfer service processing unit 1 of the surrounding vehicle. it can.
  • the inter-vehicle communication transfer service processing unit 1 acquires communication control information from the management information storage unit 24 of the inter-vehicle communication management service processing unit 2. Furthermore, the inter-vehicle communication transfer service processing unit 1 has an interface for transferring data to the transfer service processing unit 5.
  • the event notification service processing unit 12 notifies an error or event occurring in the inter-vehicle communication transfer service processing unit 1 to an upper protocol, or an error or event generated in the inter-vehicle communication management service processing unit 2 or a lower protocol is set to an upper protocol. Transparently. Furthermore, the inter-vehicle communication transfer service processing unit 1 has an interface for notifying the transfer service processing unit 5 of an event.
  • the priority control service processing unit 13 controls the order of transmission according to the priority of the message that the upper level protocol such as the application processing unit 3 requests to transmit.
  • the inter-vehicle communication transfer service processing unit 1 acquires the priority of the application from the management information storage unit 24 of the inter-vehicle communication management service processing unit 2.
  • the inter-vehicle communication transfer service processing unit 1 has an interface with respect to the inter-vehicle communication management service processing unit 2 in order to realize transmission control according to priority.
  • the inter-vehicle communication management service processing unit 2 includes a congestion control service processing unit 21, a connection management service processing unit 22, a retransmission control service processing unit 23, and a management information storage unit 24.
  • the congestion control service processing unit 21 provides the application processing unit 3 with a congestion control service that controls the transmission period, transmission power, and reception sensitivity in order to improve communication reliability.
  • the congestion control service processing unit 21 acquires vehicle information of the local station and the partner station used in the congestion control service from the application processing unit 3, and transmits communication control information such as the communication channel utilization rate and transmission power of the local station to the transmission / reception service. Obtained from the communication control information storage unit 71 of the management unit 7. Further, communication control information such as communication channel utilization rate and transmission power of peripheral stations is acquired from the management information storage unit 24.
  • the inter-vehicle communication management service processing unit 2 has an interface for providing a congestion control service to the application processing unit 3 and the transmission / reception service management unit 7.
  • the congestion control service processing unit 21 includes a transmission cycle control processing unit 211, a transmission power control processing unit 212, and a reception sensitivity control processing unit 213.
  • the transmission cycle control processing unit 211 calculates and notifies a transmission cycle for avoiding congestion to the application processing unit 3 that periodically transmits a message. As a result, the application processing unit 3 of the in-vehicle communication device periodically increases and decreases the transmission traffic because the message is periodically transmitted according to the transmission cycle notified from the congestion control service processing unit 21.
  • the transmission power control processing unit 212 calculates and notifies the transmission / reception service management unit 7 of transmission power for avoiding congestion. As a result, the transmission / reception service management unit 7 of this in-vehicle communication device sets the power threshold value for receiving a message in accordance with the transmission power notified from the transmission power control processing unit 212, so that the transmission area is enlarged or reduced. It can be made.
  • the reception sensitivity control processing unit 213 calculates and notifies the transmission / reception service management unit 7 of the reception sensitivity for avoiding congestion. As a result, the transmission / reception service management unit 7 of this in-vehicle communication device sets the power threshold value for receiving a message in accordance with the reception sensitivity notified from the reception sensitivity control processing unit 213, so that the receivable area is enlarged or reduced. It can be made.
  • connection management service processing unit 22 transmits a control message for starting an initial connection with a peripheral station in response to a request from the application processing unit 3.
  • the connection management service processing unit 22 manages the communication status with the peripheral stations and notifies the application processing unit 3.
  • the connection management service processing unit 22 provides an efficient connection management service by properly using the initial connection procedure depending on whether or not the application processing unit 3 that periodically transmits a message is operating.
  • the retransmission control service processing unit 23 retransmits a message that has not reached the counterpart station in response to a control message for providing a connection management service.
  • the vehicle-to-vehicle communication management service processing unit 2 can perform retransmission control on the control message of the vehicle-to-vehicle communication management service processing unit 2 that cannot be supported by the transaction management unit 4.
  • the management information storage unit 24 stores communication control information such as a transmission cycle and transmission power used in the congestion control service, vehicle information of the local station and peripheral stations used in the connection management service, and the like.
  • the management information storage unit 24 stores communication control information such as a transmission cycle and transmission power included in data (PDU) transmitted and received by the inter-vehicle communication transfer service processing unit 1. Furthermore, the management information storage unit 24 stores information on applications that can be provided that are registered / deleted from the application processing unit 3.
  • the application processing unit 3 includes an inter-vehicle communication application unit 31.
  • the inter-vehicle communication application unit 31 is an application that periodically broadcasts vehicle information of the host vehicle, an application that broadcasts vehicle information of the host vehicle during operation of a brake or a winker, and the driver's comfort and convenience. Includes applications that enhance the performance.
  • the transaction management unit 4 includes a transaction service processing unit 41 and an LPP connection management service processing unit 42.
  • the transaction service processing unit 41 provides a transaction service such as retransmission of a message that has not arrived at the partner station and message division / assembly. This provides retransmission control and division / assembly control required for the inter-vehicle communication system. In addition, it provides a transaction service for sending a message to the partner station and requesting a response from the partner station for the transmitted message. Further, the transaction service processing unit 41 provides a continuous transmission control service for continuously transmitting messages transmitted from the application processing unit 3. Thereby, this vehicle-mounted communication communication apparatus can raise the probability that a message will arrive at a partner station.
  • a transaction service such as retransmission of a message that has not arrived at the partner station and message division / assembly. This provides retransmission control and division / assembly control required for the inter-vehicle communication system. In addition, it provides a transaction service for sending a message to the partner station and requesting a response from the partner station for the transmitted message. Further, the transaction service processing unit 41 provides a continuous transmission control service for continuously transmit
  • the LPP connection management service processing unit 42 reports a connection status in response to a request from the application processing unit 3, notifies a new connection or disconnection, manages a port number that can be received by the other station, and can receive a certain port.
  • a connection management service such as a notification to the application processing unit 3 is provided.
  • the transfer service processing unit 5 includes an LPCP (Local Port Control Protocol) transfer service processing unit 51 and a management service processing unit 52.
  • LPCP Local Port Control Protocol
  • the LPCP transfer service processing unit 51 identifies the source and destination application processing units 3 using an identifier called a local port number for an upper level protocol such as the application processing unit 3.
  • the transfer service processing unit 5 has an interface for performing data transfer with respect to the application processing unit 3 and the transaction management unit 4 which are upper protocols. Thereby, this in-vehicle communication device can realize a multi-application.
  • the management service processing unit 52 provides a management service for notifying an upper station protocol of an error or event occurring in the transfer service processing unit 5 to the other station or the own station.
  • the management service processing unit 52 provides a service for transparently notifying the application processing unit 3 of the local station of errors and events notified from lower protocols such as the inter-vehicle communication transfer service processing unit 1.
  • the transfer service processing unit 5 has an interface for providing an event notification service to the transaction management unit 4.
  • the transmission / reception service processing unit 6 includes a transmission service processing unit 61 and a reception service processing unit 62.
  • the transmission service processing unit 61 broadcasts the data transmitted from the inter-vehicle communication transfer service processing unit 1 to the surrounding vehicles or unicasts the specific vehicles.
  • the transmission service processing unit 61 can switch the transmission power, and acquires the transmission power for transmission from the communication control information storage unit 71.
  • the transmission service processing unit 61 can switch the communication channel to be transmitted. For example, the transmission service processing unit 61 transmits information from the inter-vehicle communication management service processing unit 2 to the control channel, and transmits information from the application processing unit 3 to the data channel. can do.
  • the reception service processing unit 62 receives information transmitted from surrounding vehicles, and transmits the received information to the inter-vehicle communication transfer service processing unit 1.
  • the reception service processing unit 62 can switch the reception sensitivity, and acquires the reception sensitivity from the communication control information storage unit 71. Further, the reception service processing unit 62 determines that the case where the radio wave intensity of a certain value or more is received on the communication channel is busy, and observes the communication channel for a predetermined time. Then, the reception service processing unit 62 measures the busy rate of the predetermined time as the communication channel usage rate and stores it in the communication control information storage unit 71.
  • the transmission / reception service management unit 7 includes a communication control information storage unit 71.
  • the communication control information storage unit 71 stores information such as transmission power and reception sensitivity for performing wireless communication with the in-vehicle communication device 100 mounted on a peripheral station.
  • the communication control information storage unit 71 stores information such as the communication channel utilization rate measured by the reception service processing unit 62. Further, the communication control information storage unit 71 sets the transmission power and the reception sensitivity to values for avoiding congestion by the congestion control service processing unit 21 of the inter-vehicle communication management service processing unit 2.
  • the inter-vehicle communication sub-protocol includes an inter-vehicle communication transport sub-layer (C2C Transport Sub Layer: CTL) and an inter-vehicle communication management layer (C2C Management Layer: CML).
  • C2C Transport Sub Layer CTL
  • C2C Management Layer CML
  • the Inter-Vehicle Communication Transport Sublayer is interposed between the local port control protocol (Local Port Control Control Protocol: LPCP) and the lower communication protocol, and provides priority control for inter-vehicle communication system applications.
  • LPCP Local Port Control Control Protocol
  • CML management layer
  • an event transfer service for transferring a message to an upper protocol (hereinafter also referred to as “Upper Layer”) or CML, and an event notification service for notifying an upper protocol of errors and events occurring in the CTL are provided.
  • the Inter-Vehicle Communication Management Layer is a congestion control service that controls the transmission period, transmission power, reception sensitivity, and transmission channel to improve the reliability of communication for applications or CTLs, and initial connection start and disconnection. Connection management services that perform communication and manage communication status.
  • the CML also extends the function of the management layer of the lower communication protocol. Furthermore, the CML provides a data retransmission service in order to improve the reliability of the control message for performing the initial connection.
  • LPP Local Port Protocol
  • LPP provides transaction services such as data retransmission and division / assembly, and connection management services for managing communication status such as initial connection and disconnection.
  • the LPP implements retransmission control and division / assembly control required for the inter-vehicle communication system.
  • LPCP identifies an upper protocol such as the application processing unit 3 using a local port number, and has an interface for a management service such as data transfer and event notification with respect to the upper protocol. Thereby, LPCP implements multi-applications in the inter-vehicle communication system.
  • the lower communication protocol the IEEE 802.11p protocol and the communication protocol of 5.8 GHz band and UHF / VHF band are assumed. Further, the lower communication protocol has a management layer for storing information of the lower communication protocol.
  • the communication lower layer protocol includes a data link layer (Layer2: L2), a physical layer (Layer1: L1) below the data link layer, and a data link layer management unit (Media access control Layer Management Entity: MLME) that manages the data link layer. ) And a physical layer management unit (Physical Layer Management Entity: PLME) that manages the physical layer.
  • a data link layer (Layer2: L2)
  • a physical layer Layer management unit
  • PLME Physical Layer Management Entity
  • the lower communication protocol for example, an IEEE802.11p protocol and a communication protocol of 5.8 GHz band or UHF / VHF band may be used, or another communication protocol may be used.
  • the MLME and the PLME have a management information base (MIB: Management Information Base) in which management information is stored.
  • MIB Management Information Base
  • the data link layer is the second layer of the OSI (Open Systems Interconnection) reference model, and is specified for the access method.
  • the physical layer is the first layer of the OSI reference model and is physically defined for the transmission method.
  • the data link layer management unit (MLME) manages the data link layer and stores information used in the data link layer.
  • the physical layer management unit (PLME) manages the physical layer and stores information used in the physical layer.
  • CTL and CML are as follows.
  • Service provided by CTL (a) Data transfer service (b) Event notification service (c) Priority control service (2) Service provided by CML (a) Congestion control service (b) Connection management service (c) Data retransmission service ⁇ 2.
  • CTL provides a data transfer service to applications and upper protocols such as LPP and LPCP and CML. The detailed procedure of the data transfer service will be described in section 5.1.
  • FIG. 4 shows an example of providing a data transfer service for the upper protocol
  • FIG. 5 shows an example of providing a data transfer service for CML.
  • the CTL provides an event notification service for notifying events and errors that have occurred in the CTL, and events (communication connection / disconnection notification, etc.) to the higher-level protocol and the partner station when received from the CML. provide.
  • FIG. 6 shows an example of providing an event notification service.
  • the CTL provides a priority control service that controls the transmission order according to the upper protocol and the data priority of the CML. This makes it possible to preferentially transmit data with a high degree of urgency.
  • the detailed procedure of the priority control service will be described in section 5.2.
  • FIG. 7 shows an example of the priority control service. However, the priority control service is provided as an option when it is provided by the lower communication protocol.
  • FIG. 8 shows an example of a queue configuration for providing the priority control service.
  • Congestion control service CML provides a congestion control service that controls the transmission period, transmission power, and reception sensitivity in order to improve communication reliability for applications. provide. The detailed procedure of the congestion control service will be described in Section 5.3.
  • the congestion control service any of the following services may be used, or some of them may be used in cooperation.
  • Transmission cycle control service A service that notifies an application of a transmission cycle of an application that periodically transmits messages such as vehicle information.
  • Transmission power control service A service that controls transmission power in order to secure a communication area necessary for an application or to narrow down a communication area in order to avoid congestion.
  • Reception sensitivity control service A service that controls reception sensitivity in order to limit the communication area required for the application.
  • 2.2.1.1 Transmission cycle control service The CML notifies the transmission cycle set to avoid congestion to an application that periodically transmits messages such as vehicle information. .
  • the CML calculates the transmission cycle using the information on the own vehicle and the information on the surrounding vehicles, the channel utilization rate information detected by the own vehicle, and the channel utilization rate information detected by the surrounding vehicles. To do. Thereby, this in-vehicle communication device can control the transmission cycle in accordance with a dangerous situation with surrounding vehicles and a congestion situation of the communication environment.
  • the CML After calculating the transmission cycle, the CML notifies the application that periodically transmits information of the change of the transmission cycle. After receiving the notification, the application that is notified of the transmission cycle starts transmitting a message for each notified transmission cycle.
  • FIG. 9 shows an example of the transmission cycle control service.
  • the CML secures a communication area required for an application to the management layer of the lower communication protocol, and performs communication for avoiding congestion. In order to limit to an area, the transmission power at the time of transmitting a message is controlled.
  • the CML requires communication by using the information on the own vehicle and the information on the surrounding vehicles, the channel utilization rate information detected by the own vehicle, and the channel utilization rate information detected by the surrounding vehicles.
  • a transmission power that secures a communication area with a vehicle and avoids transmitting radio waves to unnecessary areas is calculated.
  • FIG. 10 shows an example of the transmission power control service.
  • the CML limits the management layer of the lower communication protocol to the communication area required for the application or the communication area for avoiding congestion. Therefore, a function of controlling the reception sensitivity when receiving a message is provided.
  • the CML uses the CML's own vehicle information and surrounding vehicle information, the channel usage rate information detected by the host vehicle and the channel usage rate information detected by the surrounding vehicle, and the communication area required for the application.
  • the reception sensitivity limited to the communication area for avoiding congestion is calculated.
  • the CML calculates the reception sensitivity and then notifies the PLME of the reception sensitivity, and the lower communication protocol receives the message according to the notified reception sensitivity.
  • FIG. 11 shows an example of the reception sensitivity control service.
  • the CML provides a connection management service for starting an initial connection of a communication connection required for a vehicle-to-vehicle communication system, and managing and notifying a connection state.
  • connection management service the CML provides the application with the following service, thereby providing the application with a start or end of communication.
  • Connection inquiry service A service that manages and monitors the connection status with peripheral mobile stations and notifies the connection status and new connection / disconnection in response to a request from the application.
  • Connection / disconnection notification service A service for notifying the upper level protocol of the connection status and new connection / disconnection via the CTL.
  • Time synchronization service A service that synchronizes time in order to synchronize the timing of channel switching when multiple communication channels are available.
  • the CML receives an application data that periodically transmits a message and a beacon message that is periodically transmitted. To start.
  • connection inquiry service is a service for inquiring whether an application establishes a connection for inter-vehicle communication.
  • connection inquiry services There are two types of connection inquiry services: a reference service that immediately responds to the connection status of inter-vehicle communication when making an inquiry, and a notification service that waits until the connection is established when the connection is not established and notifies when the connection is established. Define the services.
  • FIG. 12 shows an example of the connection inquiry service.
  • connection / disconnection notification service is a service for notifying communication connection and disconnection to applications and CTLs.
  • FIG. 13 shows an example of the connection / disconnection notification service.
  • Time synchronization service When the inter-vehicle communication protocol supports a plurality of communication channels, the CML provides a time synchronization service in order to unify timing for switching communication channels.
  • CML defines one of a plurality of channels as a control channel and periodically transmits a beacon message on the control channel. With beacon messages, it is possible to grasp application information supported by the other station simultaneously with time synchronization.
  • the CML provides a data retransmission service for control messages in order to ensure communication reliability.
  • the CML controls retransmission using a retransmission timer and a retransmission counter, and retransmits when the retransmission timer times out.
  • FIG. 14 shows an example of the data retransmission service
  • FIG. 15 shows an example of duplication check of the data retransmission service. An outline of the retransmission processing procedure of the data retransmission service is shown below. (1) When transmitting a control message, a retransmission timer is started and a retransmission counter is set to 0.
  • FIG. 16 shows a list of primitive types defined in the present invention.
  • FIG. 17 shows a list of parameter types used in the primitive definition table in the present invention.
  • FIG. 18 shows a list of service interfaces that the CTL and CML have. Further, FIG. 19 shows the position of the SAP in the inter-vehicle communication protocol stack.
  • ACML SAP As a congestion control service and a connection management service, CML provides the following six types of primitives to applications.
  • Connection start primitive ACML-Connection
  • Application notification primitive ACML-Notify
  • Application information registration primitive ACML-Registration
  • Application information deletion primitive ACML-Deregistration
  • CML information acquisition primitive ACML-Get
  • CML information setting primitive ACML-Set
  • ACML-Connection (1) Process Overview
  • the ACML-Connection primitive is a primitive for an application to request connection with a peripheral station, inquire about connection status, or to request transmission of a beacon message. An application that performs individual communication is started by issuing an ACML-Connection primitive.
  • FIG. 20 is a diagram showing arguments of the ACML-Connection primitive.
  • portNo an identifier for identifying the request source application.
  • serviceType an identifier indicating the type of connection inquiry service. “0” indicates a reference service that immediately answers the connection status, and “1” indicates a notification service that provides a notification when the connection is established.
  • connectionFlag a flag indicating whether the application connects to the partner station. “0” indicates that connection with the partner station is not performed, and “1” indicates that connection with the partner station is performed.
  • destinationLID an identifier indicating a partner station that makes a connection request or the like.
  • connectStatus an identifier indicating the connection status. “0” indicates an unconnected state, and “1” indicates a connected state.
  • beaconFlag a flag indicating whether transmission of a beacon message is requested. “0” indicates that beacon message transmission is not requested, and “1” indicates that beacon message transmission is requested.
  • ACML-Notify is a primitive in which the CML notifies the application of a change in transmission cycle or the application requests the CML to transmit a congestion control message. The change of the transmission cycle is issued to an application that periodically transmits.
  • the ACML-Notify primitive is used when notifying the application of information or requesting processing from the CML.
  • FIG. 21 is a diagram showing arguments of the ACML-Notify primitive.
  • portNo an identifier for identifying the request source application.
  • notifyCode An identifier indicating the content notified to the application.
  • notifyParameter a parameter value of contents to be notified to the application.
  • ACML-Registration is a primitive for an application to register application information with the CML.
  • FIG. 22 is a diagram showing arguments of the ACML-Registration primitive.
  • portNo an identifier for identifying an application that requests registration.
  • priority An identifier indicating the priority of the application.
  • applicationType an identifier indicating the type of application (between road and vehicle / between vehicles / others).
  • resultCode an identifier indicating the registration result.
  • ACML-Deregistration Application information deletion primitive
  • ACML-Deregistration primitive is a primitive for an application to delete application information from the CML.
  • FIG. 23 is a diagram showing arguments of the ACML-Deregistration primitive.
  • portNo an identifier for identifying an application that requests deletion.
  • resultCode an identifier indicating the deletion result.
  • FIG. 24 is a diagram showing arguments of the ACML-Get primitive.
  • mibIndex an identifier that indicates a variable for which acquisition is requested.
  • mibStatus an identifier indicating the result of executing the request.
  • mibParameter The content of the acquired variable.
  • ACML-Set 3.3.6 CML information setting primitive
  • the ACML-Set primitive is a primitive for an application to set a CML variable.
  • FIG. 25 is a diagram showing arguments of the ACML-Set primitive.
  • mibIndex an identifier indicating a variable for which setting is requested.
  • mibStatus an identifier indicating the result of executing the request.
  • mibParameter The contents of the variable to be set.
  • CTL provides the following two types of primitives to the upper protocol.
  • Application data transfer primitive (sendData)
  • EventReport (eventReport)
  • Application data transfer primitive (sendData)
  • the sendData primitive is a primitive for the upper protocol to transmit / receive application data to / from the CTL.
  • FIG. 26 is a diagram showing arguments of the sendData primitive.
  • linkAddress A link address used in inter-vehicle communication, and an identifier used to identify a communicating partner station.
  • parameter Indicates the data body exchanged with the upper protocol.
  • Event notification primitive (1) Process Overview
  • the eventReport primitive is a primitive for the CTL to notify an upper level protocol of an event such as an error that has occurred in the CTL.
  • FIG. 27 is a diagram showing arguments of the eventReport primitive.
  • linkAddress A link address used in inter-vehicle communication, and an identifier used to identify a communicating partner station.
  • eventCode an identifier representing a code indicating the event or error that has occurred.
  • extensionParameter indicates a parameter for supplementing the contents of the variable eventCode.
  • CTL SAP CML SAP
  • CML SAP CML SAP
  • CTL-SendData Control data transfer primitive
  • Event notification primitive CMCTL-EventReport
  • CML information acquisition primitive CMCTL-Get
  • CML information setting primitive CMCTL-Set
  • CMCTL-SendData (1) Process Overview
  • the CMCTL-SendData primitive is a primitive for the CML to request the CTL to transmit a control message.
  • FIG. 28 is a diagram illustrating arguments of the CMCTL-SendData primitive.
  • linkAddress A link address used in inter-vehicle communication, and an identifier used to identify a communicating partner station.
  • pduIdentifier Indicates the type of PDU exchanged with the CML.
  • parameter Indicates the data body exchanged with the CML.
  • priority Indicates the priority of data to be transmitted.
  • CMCTL-EventReport (1) Process Overview
  • the CMCTL-EventReport primitive notifies the CTL of an event such as an error that has occurred in the CML to the CTL, or the CTL notifies the CML of an event such as an event that has occurred in the CTL. It is a primitive to do.
  • FIG. 29 is a diagram illustrating arguments of the CMCTL-EventReport primitive.
  • linkAddress A link address used in inter-vehicle communication, and an identifier used to identify a communicating partner station.
  • eventCode an identifier representing a code indicating the event that has occurred.
  • extensionParameter indicates a parameter for supplementing the contents of the variable eventCode.
  • CMCTL-Get 3.5.3 CML information acquisition primitive
  • the CMCTL-Get primitive is a primitive for the CTL to acquire a CML variable.
  • FIG. 30 is a diagram illustrating arguments of the CMCTL-Get primitive.
  • mibIndex an identifier that indicates a variable for which acquisition is requested.
  • mibStatus an identifier indicating the result of executing the request.
  • mibParameter The content of the acquired variable.
  • CMCTL-Set 3.5.4 CML information setting primitive
  • the CMCTL-Set primitive is a primitive for setting a CML variable by the CTL.
  • FIG. 31 is a diagram showing arguments of the CMCTL-Set primitive.
  • mibIndex an identifier indicating a variable for which setting is requested.
  • mibStatus an identifier indicating the result of executing the request.
  • mibParameter The contents of the variable to be set.
  • CML provides the following two types of primitives to MLME.
  • the MLME-Get primitive is a primitive for the CML to acquire the MLME variable.
  • FIG. 32 is a diagram showing arguments of the MLME-Get primitive.
  • mibIndex an identifier that indicates a variable for which acquisition is requested.
  • mibStatus an identifier indicating the result of executing the request.
  • mibParameter The content of the acquired variable.
  • MLME-Set 3.6.2 MLME information setting primitive
  • the MLME-Set primitive is a primitive for the CML to set a variable of MLME.
  • FIG. 33 is a diagram showing arguments of the MLME-Set primitive.
  • mibIndex an identifier indicating a variable for which setting is requested.
  • mibStatus an identifier indicating the result of executing the request.
  • mibParameter The contents of the variable to be set.
  • CML provides the following two types of primitives to PLME.
  • PLME information acquisition primitive (PLME-Get)
  • PLME information setting primitive (PLME-Set) 3.7.1
  • PLME information acquisition primitive (PLME-Get)
  • FIG. 34 is a diagram showing arguments of the PLME-Get primitive.
  • mibIndex an identifier that indicates a variable for which acquisition is requested.
  • mibStatus an identifier indicating the result of executing the request.
  • mibParameter The content of the acquired variable.
  • FIG. 35 is a diagram showing arguments of the PLME-Set primitive.
  • mibIndex an identifier indicating a variable for which setting is requested.
  • mibStatus an identifier indicating the result of executing the request.
  • mibParameter The contents of the variable to be set.
  • Protocol data unit (PDU) 4.1 Configuration of PDU
  • PDU protocol data unit
  • FIG. 36 shows a PDU configuration when transmitting application data
  • FIG. 37 shows a PDU configuration when transmitting control data.
  • PDUs Service Data Units
  • the PDU shown in FIG. 36 is passed to the CTL with the LPP header and LPCP header added to the application data, added with the C2C header in the CTL, and passed to the lower communication protocol (Layer 2).
  • control data generated by the CML is passed to the CTL, a C2C header is added in the CTL, and the lower communication protocol (Layer 2) is passed.
  • application data is handled as LPP SDU on LPP, an LPP header is added to become LPP PDU, and it is passed to LPCP.
  • the passed data is treated as LPCP SDU on LPCP, and an LPCP header is added to become LPCP PDU and passed to CTL.
  • the passed data is treated as C2C SDU on CTL, added with a C2C header to become C2C PDU, passed to Layer2, and treated as MSDU (MAC SDU) on Layer2.
  • FIG. 38 is a diagram showing C2C header information that is a header added in CTL.
  • Data Indetifier data identifier
  • PDU Identifier This is an identifier for distinguishing the type of PDU.
  • the data identifier and PDU identifier values shown in FIG. 39 are shown.
  • Node Priority The priority (risk level) of the vehicle. Acquired by the CML variable acquisition primitive of CML.
  • Channel Occupancy (communication channel utilization rate) The communication band within a predetermined time is a busy rate.
  • the unit is [%], and a value from 0 to 100 is set. Acquired by a CML variable acquisition primitive.
  • Cyclic Interval transmission cycle
  • the unit is [10 msec], and a value from 1 (10 msec) to 255 (2550 msec) is set.
  • Transmission Power This is the value of the transmission power set when the C2C header is generated.
  • the unit is [0.1 dBm], and values from ⁇ 5.0 dBm to 20.0 dBm are set. Acquired by a CML variable acquisition primitive.
  • Receiver Sensitivity Stores the value of the reception sensitivity set when the C2C header is generated.
  • the unit is [1 dBm], and a value from ⁇ 127 dBm to 0 dBm is set. Get by CML variable acquisition primitive.
  • Beacon PDU This is a PDU that transmits a beacon message for triggering to start an initial connection or for time synchronization.
  • FIG. 40 shows the format of the beacon message.
  • TSF Timer This is a TSF timer for time synchronization. The value takes a range of 0-2 64.
  • Next Beacon Transmission Timing This is the next timing for transmitting a beacon message. The unit is [msec] and takes a range of 0-1000.
  • CML Profile This is a CML profile in which functions supported by the own station, application information, channel information, and communication control information are stored.
  • Connection Request Message This is a PDU for making a communication connection request.
  • FIG. 41 shows the format of the connection request message.
  • Required Ack Flag (Retransmission request flag) This is a flag indicating whether the retransmission process is valid. In the case of “1”, PDU retransmission processing is enabled, and a message is notified to the other party and an acknowledgment (Ack PDU) is requested. In the case of “0”, the retransmission process is invalidated.
  • Retransmit Flag This is a flag indicating whether the PDU has been retransmitted. When “1” is indicated, it indicates a retransmitted PDU.
  • Sequence Number It is a sequence number. Duplicate PDUs are detected from the link address and sequence number of the partner station.
  • CML Profile This is a CML profile in which functions supported by the own station, application information, channel information, and communication control information are stored.
  • FIG. 42 shows the format of the connection response message.
  • (1) Result Code Indicates the result of whether or not to make an initial connection. If the partner station to be connected and the application to be supported are different, “not connect” is notified, and if the application to be supported exists, “connect” is notified.
  • FIG. 43 shows the contents of Result Code.
  • (2) Required Ack Flag (Retransmission request flag) This is a flag indicating whether the retransmission process is valid. In the case of “1”, PDU retransmission processing is enabled, and a message is notified to the other party and an acknowledgment (Ack PDU) is requested. In the case of “0”, the retransmission process is invalidated.
  • Retransmit Flag This is a flag indicating whether the PDU has been retransmitted. When “1” is indicated, it indicates a retransmitted PDU.
  • Sequence Number It is a sequence number. Duplicate PDUs are detected from the link address and sequence number of the partner station.
  • Profile Flag This flag indicates whether CML profile information is added to the Connect Response PDU. In the case of “0”, no CML profile is stored in the subsequent CML Profile field, and in the case of “1”, the CML profile is stored in the subsequent CML Profile field. When the CML profile has already been provided by the Beacon PDU, this identifier is set to “0” and the CML profile is not stored.
  • CML Profile This is a CML profile in which functions supported by the own station, application information, channel information, and communication control information are stored.
  • 4.6 Acknowledgment message This is a PDU that returns an acknowledgment when a retransmission request is made.
  • FIG. 44 shows the format of the confirmation response message.
  • Retransmit Flag It is a flag indicating whether it is a retransmitted PDU. When “1” is indicated, it indicates a retransmitted PDU.
  • Sequence Number It is a sequence number. Duplicate PDUs are detected from the link address and sequence number of the partner station.
  • Congestion Control Message This is a PDU when requesting communication parameters to be set in surrounding vehicles in order to perform congestion control.
  • FIG. 45 shows the format of the congestion control message.
  • (1) Transmission Power for others This is the value of the transmission power requested to the surrounding vehicle.
  • the unit is [0.1 dBm], and values from ⁇ 5.0 dBm to 20.0 dBm are set.
  • (2) Transmission Interval for others (Requested transmission cycle) This is the value of the transmission cycle requested to the surrounding vehicle.
  • the unit is [10 msec], and a value from 1 (10 msec) to 255 (2550 msec) is set.
  • (3) Receiver Sensitivity for others This is the value of the reception sensitivity required for the surrounding vehicle.
  • the unit is [1 dBm], and values from ⁇ 127 dBm to 0 dBm are set.
  • Event PDU This is a PDU that notifies an opposite station of an event such as an error that has occurred in CTL and CML.
  • FIG. 46 shows an event notification message format.
  • eventCode event code
  • FIG. 47 shows the contents of the event code.
  • extensionParameter It is a parameter that complements the contents of the event.
  • FIG. 48 shows an example of a basic processing sequence for message transfer.
  • Sending procedure (1) When the CTL receives a data transmission request primitive (sendData.req) from the LPCP, the CTL acquires a C2C SDU from the variable parameter. (2) The CTL refers to the LPCP control information in the C2C SDU and acquires the transmission source port number. (3) The CTL acquires the priority of the source port number using a CML information acquisition primitive (CMCTL-Get). (4) CYL adds a C2C Header, generates a C2C PDU, stores it in the acquired priority queue, and applies priority control processing. (5) The CTL waits for transmission under priority control, and then transmits the data using a data transmission primitive (DL-Unitdata.req) of the lower communication protocol to complete the transmission process.
  • DL-Unitdata.req data transmission primitive
  • variable linkAddress is a group broadcast link address and the address value is not “0”
  • the request primitive is discarded, and the status “designated group broadcast link” is sent to the LPCP using the event notification primitive (eventReport). "The address is not valid”.
  • CTL is a data transmission primitive (DL-Unitdata.ind) from a communication lower level protocol.
  • a data identifier When a C2C PDU is received, a data identifier, a PDU identifier, a vehicle priority, a channel usage rate, a transmission cycle, a transmission power, Receive sensitivity and user data are extracted.
  • the data identifier indicates “0”
  • the PDU identifier PDU Identifier
  • the data transmission notification primitive sendsendData.ind
  • C2C SDU To transfer reception of data (C2C SDU) from the other station.
  • CTL is a CML information setting primitive (CMCTL) with respect to CML with the transmission source link address obtained by DL-Unitdata.ind and the received vehicle priority, channel utilization rate, transmission cycle, transmission power, and reception sensitivity. -Set) to register and complete the reception process.
  • C2C PDUs in the following cases are invalid and are not processed.
  • the notification primitive is discarded, and the state “designated PDU identifier is indicated in the event notification message to the partner station CTL. Not valid ". If the data identifier is not valid, the notification primitive is discarded, and the status “designated data identifier is not valid” is notified to the partner station CTL by an event notification message.
  • FIG. 49 shows an example of a basic processing sequence for message transfer.
  • Sending procedure (1) When the CTL receives a control data transmission request primitive (CMCTL-SendData.req) from the CML, the CTL acquires a C2C SDU from the variable parameter and a priority from the variable priority. (2) The CTL adds a C2C Header to generate a C2C PDU, stores it in the priority queue acquired from the variable priority, and applies the priority control process. (3) The CTL waits for transmission by priority control, and then transmits the data using a data transmission primitive (DL-Unitdata.req) of the lower communication protocol, thereby completing the transmission process. C2C PDUs in the following cases are invalid and are not processed.
  • CMCTL-SendData.req control data transmission request primitive
  • variable linkAddress is a group broadcast link address and the address value is not “0”
  • the request primitive is discarded, and the state “specified group same as the specified group” is discarded by the event notification primitive (CMCTL-EventReport).
  • Information link address is not valid.
  • CTL takes out the data stored in the queue for each priority in order from the highest priority and transmits it using the data transmission primitive (DL-Unitdata.req) .
  • the CTL takes out data from the queue with one lower priority and transmits it.
  • the priority “Middle” queue stores only the data of the information exchange type application that periodically sends information. When new data is stored, the old data in the queue is discarded. Keep the latest data.
  • the priority “High” queue stores emergency information
  • the “Low” queue stores non-real-time information.
  • FIG. 50 shows a basic sequence of congestion control in CML.
  • the application uses the application information setting primitive (ACML-Set) for the CML to set the vehicle information of the host vehicle and the vehicle information received from the surrounding vehicles.
  • the CML periodically acquires the utilization information of the communication channel by using a PLME information acquisition primitive (PLME-Get) for PLME.
  • the CML calculates a transmission cycle, transmission power, and reception sensitivity to be set in order to avoid congestion from the collected information.
  • a specific algorithm for calculating each parameter is shown in 5.3.1.1.
  • the CML notifies the application periodically transmitting information of the transmission cycle calculated using the application notification primitive (ACML-Notify). (5) The application repeatedly transmits vehicle information after the next timing according to the notified transmission cycle. (6) The CML sets the calculated transmission power and reception sensitivity for the PLME using a PLME information setting primitive (PLME-Set). (7) In the lower communication protocol, the next transmission / reception is started according to the set transmission power and reception sensitivity. At this time, the set transmission power and reception sensitivity may be switched depending on the type of channel to be transmitted.
  • a congestion control algorithm in CML will be described. First, collection and setting of information necessary for congestion control will be described. The position, speed, acceleration, and traveling direction of the host vehicle and surrounding vehicles are set in the CML by the application, and communication control parameters (channel utilization rate, transmission cycle, transmission power, reception sensitivity) of the own vehicle and communication control of surrounding vehicles are set. Parameters are also stored in the CML. Furthermore, the necessary communication distance used here may be calculated in the CML, may be calculated by an application, and may be set by a CML information setting primitive. Next, congestion control for controlling the transmission cycle will be described.
  • Transmission cycle control algorithm In the present invention, when the communication channel is not congested, a transmission cycle value that is a requirement specification of the application is applied, and when the communication channel starts to be congested, a method of gradually increasing the transmission cycle is used.
  • the maximum value Omax (t) is selected from the communication channel utilization rate Oi (t) of the own vehicle and the communication channel utilization rate Oj (t) of the surrounding vehicle.
  • N shows the number of vehicles with which the own vehicle i is communicating.
  • the transmission cycle is calculated based on the communication channel utilization rate Omax (t).
  • the transmission cycle T (t + 1) is set to converge to the target communication channel utilization rate Oth based on the communication channel utilization rate.
  • T (t + 1) T (t) + K ⁇ ⁇ Omax (t) ⁇ Oth ⁇ + K / I ⁇ ⁇ ⁇ Omax (t) ⁇ Oth ⁇ dt + K ⁇ Td ⁇ d / dt ⁇ Omax (t) ⁇ Oth ⁇
  • T (t + 1) indicates the transmission cycle to be applied next
  • T (t) indicates the transmission cycle applied last time
  • Omax (t) is the maximum communication channel utilization rate
  • K is the proportional gain
  • I is the integral Time
  • Td indicates a derivative time.
  • the time required to converge the communication channel utilization rate to the target threshold can be changed by the set values of the proportional gain, the integration time, and the derivative time. Further, since the communication reliability that can be realized can be changed by adjusting the target channel utilization rate, the target channel utilization rate can be set according to the reliability required by the application. Next, congestion control for controlling transmission power will be described.
  • Transmission power control algorithm Similar to the transmission interval, it is considered that congestion can be efficiently avoided by controlling the transmission power. Therefore, when the congestion starts, the communication area is narrowed down.
  • the transmission power is calculated so that the number of communication with the host vehicle is equal to or less than a certain number.
  • the communication channel utilization rate O ( t) is calculated.
  • S indicates the data size [bit] to be transmitted
  • C indicates the transmission rate [bit per sec].
  • the inter-vehicle distance at this time is Dm, which is the target communication distance.
  • the required communication distance D (t + 1) is calculated as follows so that the number of vehicles that can communicate with the host vehicle converges to m [units].
  • D (t + 1) D (t) + K ⁇ ⁇ n (t) ⁇ m ⁇ + K / I ⁇ ⁇ ⁇ n (t) ⁇ m ⁇ dt + K ⁇ Td ⁇ d / dt ⁇ n (t) ⁇ m ⁇
  • D (t + 1) indicates the communication distance to be transmitted next
  • D (t) indicates the previously set communication distance
  • n (t) [unit] is the number of currently communicating with the own vehicle
  • K Proportional gain
  • I integration time
  • Td derivative time. Note that the proportional gain, integration time, and differential time here may be the same as the transmission cycle control algorithm, or different values.
  • the transmission power P (t + 1) for realizing the communication distance D (t + 1) is calculated from the preset communication specifications and applied as new transmission power.
  • reception sensitivity control algorithm By controlling the reception sensitivity, it is possible to limit the area that can be received by the host vehicle. While the transmission power avoids congestion that occurs in the partner vehicle, the reception sensitivity can avoid congestion that occurs in the host vehicle. Therefore, by allocating only a part of the difference between the transmission power P (t + 1) calculated in the transmission power control algorithm and the previous transmission power P (t) to the reception sensitivity, It is possible to select whether to reduce congestion.
  • a P (t + 1) ⁇ P (t)) [dBm].
  • the transmission power is set to be smaller (ab) [dBm]
  • the receiving sensitivity is set to be larger by b [dBm].
  • the congestion control message is transmitted in the following procedure.
  • Send procedure (1) When the CML triggers the transmission of the congestion control message, the CML determines a communication control parameter value to instruct the other station. For example, in the present invention, the transmission timing of the congestion control message is assumed when the communication channel utilization rate exceeds 40%, or when the application processing unit 3 receives a congestion control message transmission request. Further, the communication control parameter value instructed to the partner station is a value set by the own station. (2) The CML generates a Congestion Control PDU and issues a control data transmission request primitive (CMCTL-SendData.req) to the CTL.
  • CMCTL-SendData.req control data transmission request primitive
  • Initial Connection Start Procedure (1) The application uses the connection start primitive (ACML-Connection) to make a connection request for individual communication to the CML. (2) When the variable connectionFlag of ACML-Connection indicates “1”, the CML sets the connection request flag to “1” so that the application performs individual communication (when the connection request flag is “1”). (Initial connection sequence is started when broadcast message and beacon message are received from peripheral station). (3) The CML refers to the application information table and confirms whether a broadcast application that periodically transmits vehicle information is supported. (A) When the broadcast application is supported, the CML sets a beacon message (Beacon PDU) transmission flag to “0” and triggered by reception of the broadcast application message as shown in 5.4.3. Start the initial connection sequence. (B) When the broadcast application is not supported and the variable beaconFlag of the connection start primitive indicates “1”, the CML sets a beacon message (Beacon PDU) transmission flag to “1”, and 5.4 Start the beacon message transmission sequence as shown in .2.
  • ACML-Connection connection start
  • FIG. 51 shows a basic sequence of an initial connection procedure when a beacon message in CML is used.
  • FIG. 52 shows a sequence for discarding the beacon message of the initial connection procedure using the beacon message in the CML.
  • the CML confirms whether the peripheral station is transmitting a beacon message. In order to perform a beacon scan, a beacon scan timer is started.
  • A When the CML receives a Beacon PDU from a peripheral station before the beacon scan timer times out, the CML starts an initial connection sequence according to the procedure described in (3) and thereafter.
  • the CML If the CML does not receive a Beacon PDU from the peripheral station before the beacon scan timer times out, the CML starts an initial connection sequence according to the procedure described in (2) and thereafter. (2) The CML generates a Beacon PDU and requests transmission to the CTL using a control message transmission primitive (CMCTL-SendData). (3) When a message indicating the Beacon PDU is notified from the CTL by the control message transmission primitive, the connection management table is referred to confirm the connection status. (A) If “connected”, the received Beacon PDU is discarded and the initial connection sequence is completed.
  • CMCTL-SendData control message transmission primitive
  • connection request flag when “not connected”, and registers the CML profile in the connection management table from the link address of the partner station and the received Beacon PDU when the connection request flag indicates “1”, and Connect A Request PDU is generated, and transmission is requested to the CTL using a control message transmission primitive (CMCTL-SendData).
  • CMCTL-SendData control message transmission primitive
  • the connection request flag indicates “0”
  • the initial connection sequence is not started.
  • the CML refers to the connection management table in order to confirm the connection status.
  • A In the case of “connected”, the received Connect Request PDU is discarded, and a resultCode “connected” is returned using the Connect Response PDU.
  • FIG. 53 shows a basic sequence of an initial connection procedure when a broadcast application in CML is used.
  • FIG. 54 shows a sequence in the case where connection in the initial connection procedure using the broadcast application in CML is not performed. However, the initial connection procedure using an application that periodically transmits information is supported only when using a single channel.
  • the CML uses the CML information setting primitive from the CTL to refer to the connection management table when registration of information included in the C2C Header is requested. Confirm the connection status with the other station.
  • A When “connected”, the initial connection sequence is completed.
  • B In the case of “not connected”, the connection request flag is referred to.
  • connection request flag indicates “1”
  • a Connect Request PDU is generated, and the control message transmission primitive (CMCTL-SendData) is used to generate the CTL. Request to send to.
  • the connection request flag indicates “0”
  • the initial connection sequence is not started.
  • the CML refers to the connection management table in order to confirm the connection status.
  • A In the case of “connected”, the received Connect Request PDU is discarded, and a resultCode “connected” is returned using the Connect Response PDU.
  • connection request flag in the case of “not connected”, and register the CML Profile in the connection management table from the LinkAddress of the partner station and the received Connect Request PDU when the connection request flag indicates “1”. Set to “Connected”.
  • a Connect Response PDU is generated, and transmission is requested to the CTL using a control message transmission primitive (CMCTL-SendData).
  • CMCTL-SendData control message transmission primitive
  • the CML refers to the variable resultCode, and when it indicates “not connected”, discards the Connect Response PDU and “connects”.
  • the connection management table is referred to.
  • connection management table Set the connection management table to “connected” for the LinkAddress of the partner station.
  • An Ack PDU is generated, and transmission is requested to the CTL using a control message transmission primitive (CMCTL-SendData).
  • CMCTL-SendData a control message transmission primitive
  • the CML returns a connection start response primitive (ACML-Connection.cnf) to the application and completes the initial connection sequence.
  • FIG. 55 shows an example of a procedure for notifying the connection status.
  • the CML receives a Connect Request PDU and a Connect Response PDU, and establishes a communication connection with the counterpart station.
  • the CML notifies the CTL that a connection has been established using an event notification primitive (CMCTL-EventReport).
  • the CTL notifies the upper layer that the connection has been established by using an event notification primitive (EventReport.ind).
  • FIG. 56 shows a registration and deletion procedure of application information in the CML.
  • Each application of the mobile station notifies the CML using an application deletion primitive (ACML-Deregistration) when it becomes in a state where it cannot be provided.
  • the CML updates the application information table.
  • the CML notifies the application of the deletion result using an application deletion notification primitive (ACML-Deregistration.ind).
  • FIG. 57 shows an example of a basic processing sequence in CML when retransmission processing is valid
  • FIG. 58 shows an example of a processing sequence in CML when retransmission is performed
  • FIG. 59 shows an overlap check in retransmission processing. The sequence example in CML in the case of performing will be shown.
  • Send procedure (1) When the CML transmits control data (connection request message, connection response message), a connection management service with effective retransmission processing is started. (2) The CML creates a PDU whose Required Ack Flag (retransmission request flag) indicates “1”, and requests transmission to the CTL using a control message transmission primitive (CMCTL-SendData.req). (3) The CML requests transmission and starts a retransmission timer, holds the PDU, and waits for reception of a response message from the partner station. (4) When the CML receives a response message from the partner station before the retransmission timer times out, the CML stops the retransmission timer, discards the held PDU, and completes this transaction.
  • CMCTL-SendData.req control message transmission primitive
  • the CML sets the Retransmit Flag to 1 Then, at the same time as requesting the CTL to transmit the PDU, the retransmission timer is restarted and the retransmission counter is incremented by one. (6) If the CML does not receive a response message even after repeating retransmissions several times and the retransmission counter exceeds the maximum number of retransmissions, the CML discards the held PDU and completes this transaction.
  • the CML generates a response message when receiving a PDU whose Required Ack Flag (retransmission request flag) is “1” by the control message transmission notification primitive (CMCTL-SendData.ind) from the CTL, and transmits the control message. Request transmission to the CTL using a primitive (CMCTL-SendData.req). (2) The CML requests transmission and starts a wait timer at the same time.
  • the in-vehicle communication device and the road-vehicle-to-vehicle communication linkage system according to Embodiment 1 operate according to the specifications of the vehicle-to-vehicle communication sub-protocol described above.
  • FIG. 60 is a flowchart showing the operation of the data transfer service processing unit 11 of the inter-vehicle communication transfer service processing unit 1.
  • the data transfer service processing unit 11 waits until a message transmission request and reception notification are received (step S101).
  • the transmission request and the reception notification are not received (in the case of “No”)
  • the data transfer service processing unit 11 continues to wait for reception of the transmission request and the reception notification.
  • the process proceeds to step S102.
  • step S102 the transmission request and reception notification of the data received in step S101 are identified, and if it is a transmission request (in the case of “Yes”), the process proceeds to step S103. On the other hand, when it is a reception notification (in the case of “No”), the process proceeds to step S110.
  • step S103 it is identified whether the transmission request received in step S102 is a request from the transfer service processing unit 5 or a request from the inter-vehicle communication management service processing unit 2, and in the case of a request from the transfer service processing unit 5 (“Yes ”), The process proceeds to step S104. In contrast, in the case of a request from the inter-vehicle communication management service processing unit 2 (in the case of “No”), the process proceeds to step S108.
  • step S104 data to be transmitted (C2C) SDU) is extracted from the primitive issued from the LPCP transfer service processing unit 51, and the transmission source port number is acquired from the LPCP header.
  • step S105 the data transfer service processing unit 11 acquires, from the management information storage unit 24 of the inter-vehicle communication management service processing unit 2, the priority of the application indicating the transmission source port number and the parameter of the communication control information to be added to the message.
  • step S106 a C2C header is created from the acquired communication control information, and a C2C2 PDU is generated.
  • step S107 the C2C PDU generated in step S106 and the priority acquired in S105 are transmitted to the priority control service processing unit 13, and the data transmission procedure from the transfer service processing unit 5 is completed.
  • step S108 data to be transmitted (C2C SDU) is transmitted from the primitive issued from the inter-vehicle communication management service processing unit 2. ) And priority.
  • step S109 the data transfer service processing unit 11 acquires parameters of communication control information to be added to the C2C header from the management information storage unit 24 of the inter-vehicle communication management service processing unit 2.
  • steps S106 and S107 are performed, and the data transmission procedure of the inter-vehicle communication management service processing unit 2 is completed.
  • step S110 the data transfer service processing unit 11 receives the received data (C2C PDU) from the primitive issued from the transmission / reception service processing unit 6. get. Further, each parameter is acquired from the C2C header.
  • step S111 the data identifier (Data Identifier) is referred to in order to select a distribution destination of the received data, and is transmitted to the transfer service processing unit 5 (LPCP) or the inter-vehicle communication management service processing unit 2 (CML). ).
  • LPCP transfer service processing unit 5
  • CML inter-vehicle communication management service processing unit 2
  • step S111 If the data identifier indicates “0” in step S111 (in the case of “Yes”), the process proceeds to step S112. On the other hand, when the data identifier indicates “1” (in the case of “No”), the process proceeds to step S114.
  • step S112 the received C2C SDU is transmitted to the LPCP transfer service processing unit 51 of the transfer service processing unit 5.
  • step S113 the received communication control information of the C2C header is set in the management information storage unit 24 of the inter-vehicle communication management service processing unit 2, and the data reception procedure is completed.
  • step S111 determines whether the received data is to be transmitted to the inter-vehicle communication management service processing unit 2 is to be transmitted to the inter-vehicle communication management service processing unit 2.
  • the acquired C2C2SDU is transmitted to the inter-vehicle communication management service processing unit 2 in step S114.
  • step S113 the process of step S113 is performed, and the data reception procedure is completed.
  • steps S107 and S113 the process returns to step S101 and waits until the next message transmission request and reception notification are received.
  • FIG. 61 is a flowchart showing the operation of the event notification service processing unit 12 of the inter-vehicle communication transfer service processing unit 1.
  • the event notification service processing unit 12 waits until receiving an event notification notifying that an error or event has occurred (step S201). When the event notification is not received (in the case of “No”), the standby state is continued. On the other hand, when the event notification is received (in the case of “Yes”), the process proceeds to step S202.
  • step S202 it is identified whether the event notification received in step S201 is an event in the inter-vehicle communication transfer service processing unit 1 or an event notified from the inter-vehicle communication management service processing unit 2, and the inter-vehicle communication transfer service processing unit 1 In the case of an event (in the case of “Yes”), the process proceeds to step S203. In contrast, in the case of an event of the inter-vehicle communication management service processing unit 2 (in the case of “No”), the process proceeds to step S205.
  • step S203 an event code corresponding to the generated error or event is set.
  • step S204 an event notification primitive is transmitted to the management service processing unit 52, and the event notification processing is completed.
  • step S202 if the event notification from the inter-vehicle communication management service processing unit 2 is identified in step S202, the event code notified from the inter-vehicle communication management service processing unit 2 is used as the event notification of the event notification service processing unit 12.
  • the code is set (S205).
  • step S204 is performed to complete the event notification process.
  • it returns to step S201 and performs the next process.
  • FIG. 62 is a flowchart showing the operation of the priority control service processing unit 13 of the inter-vehicle communication transfer service processing unit 1.
  • the priority control service processing unit 13 waits until data (message) to be transmitted / received is received (step S301). When the message is not received (in the case of “No”), the data reception standby state is continued. On the other hand, when the message is received (in the case of “Yes”), the process proceeds to step S302.
  • step S302 whether the data received in step S301 is data to be transmitted or received is identified. If the data is to be transmitted (in the case of “Yes”), the process proceeds to step S303. On the other hand, in the case of received data (in the case of “No”), the process proceeds to step S306.
  • step S303 the priority received simultaneously with the data to be transmitted is referred to, and the transmission data is stored in the transmission queue of the priority.
  • step S304 it is checked whether transmission data is stored in each transmission queue. If data exists (in the case of “Yes”), the process proceeds to step S305.
  • step 304 when it is confirmed in step 304 that no data exists in the transmission queue (in the case of “No”), the process returns to step S301 and waits until a message is received.
  • step S305 the priority control service processing unit 13 transmits the data stored in the transmission queue having a high priority to the reception service processing unit 61 in order, and completes the transmission procedure of the priority control processing. Then, the process returns to step S301 and waits until the next message is received.
  • step S305 After the process in step S305 is completed, the process returns to step S304. If there is data remaining in the queue, the transmission is repeated. If there is no data, the process returns to step S301 and waits until a message is received. .
  • step S302 when the priority control service processing unit 13 identifies that the data has been received from the reception service processing unit 62, in step S306, the received data is transmitted to the data transfer service processing unit 11, and priority control processing is performed. Complete the receiving procedure. Note that after the processing in step S306 is completed, the process returns to step S301 and waits until the next message is received.
  • FIG. 63 is a flowchart showing the operation of the congestion control service processing unit 21 of the inter-vehicle communication management service processing unit 2.
  • the congestion control service processing unit 21 waits until a congestion control message is received (step S401). If the message has not been received (in the case of “No”), the process proceeds to step S407. On the other hand, when the message is received (in the case of “Yes”), the process proceeds to step S402.
  • step S402 communication control information such as the risk level of the partner station, the transmission cycle requested by the partner station, the transmission power, and the reception sensitivity is acquired from the congestion control message received in step S401.
  • step S403 the risk level of the partner station acquired in step S402 is compared with the risk level of the own station, and if it is determined that the partner station is more dangerous than the own station (in the case of “Yes”). The process proceeds to step S404. On the other hand, when it is determined that the own station is more dangerous than the other station (in the case of “No”), the process proceeds to step S406.
  • step S404 the inter-vehicle communication application unit 31 is notified in order to set the transmission cycle acquired in step S402 as the application of the own station.
  • step S405 the transmission power and reception sensitivity acquired in step S402 are set in the communication control information storage unit 71 of the own station, and the processing procedure when the congestion control message is received is completed.
  • step S406 the congestion control message received in step S401 is discarded, and the processing procedure when the congestion control message is received. To complete.
  • step S401 vehicle information is obtained from the inter-vehicle communication application unit 31 and the communication control information storage unit 71 in step S407 in order to calculate communication control parameters for controlling congestion. And communication channel information.
  • step S408 based on the congestion control algorithm, based on the information acquired in step S407, a transmission cycle, transmission power, and reception sensitivity for avoiding congestion are calculated.
  • step S409 the inter-vehicle communication application unit 31 is notified of the transmission cycle calculated in step S408.
  • step S410 the transmission power and reception sensitivity calculated in step S408 are set in the communication control information storage unit 71, and the communication control parameter setting procedure for congestion control is completed. Note that after the processing in steps S405, S406, and S410 is completed, the process returns to step S401 and waits until the next message is received.
  • connection management Service Processing Unit 22 and Retransmission Control Service Processing Unit 23 The operations of the connection management service processing unit 22 and the retransmission control service processing unit 23 of the inter-vehicle communication management service processing unit 2 will be described with reference to FIGS.
  • FIG. 64 is a flowchart for determining a method of an initial connection procedure of the connection management service processing unit 22
  • FIG. 65 is a flowchart showing an initial connection procedure when a beacon message is used
  • FIG. 66 is a broadcast application. It is a flowchart which shows the initial connection procedure at the time of utilizing.
  • connection management service processing unit 22 waits until a connection request is received from the inter-vehicle communication application unit 31 (step S501). When the connection request has not been received (in the case of “No”), the process proceeds to step S507. On the other hand, when the connection request is received (in the case of “Yes”), the process proceeds to step S502.
  • step S502 it is determined whether or not the connection request flag, which is a variable of the connection request received in step S501, indicates “1”. If the connection request flag does not indicate “1” (“No”), the process returns to step S501. In contrast, when the connection request flag indicates “1” (in the case of “Yes”), the process proceeds to step S503.
  • step S503 it is determined whether or not an application that periodically transmits information is being activated.
  • the application is not activated (in the case of “No”), the process proceeds to step S505.
  • the application is activated (in the case of “Yes”), the process proceeds to step S504.
  • step S504 the initial connection procedure (sequence) using the broadcast application is applied, and the initial connection is started according to the procedure shown in FIG.
  • the broadcast application is an application that periodically transmits information.
  • step S505 If it is determined in step S503 that the application that periodically transmits information is not activated, it is determined in step S505 whether or not the variable beacon flag of the connection request received in step S501 indicates “1”. . When the beacon flag does not indicate “1” (in the case of “No”), the process returns to step S501. On the other hand, when the beacon flag indicates “1” (in the case of “Yes”), the process proceeds to step S506, the initial connection procedure (sequence) using the beacon message is applied, and the procedure illustrated in FIG. Start the initial connection.
  • step S501 when a connection request is not received from the inter-vehicle communication application unit 31 in step S501, the process waits until a beacon message and a connection request message are received from a peripheral station in step S507. And when the said message is not received (in the case of "No"), it returns to step S501. On the other hand, when the message is received (in the case of “Yes”), the process proceeds to step S508.
  • step S508 the message received in step S507 is discarded, and the process returns to step S501.
  • connection management service processing unit 22 Since the connection management service processing unit 22 performs a beacon scan to check whether a beacon message is transmitted, it starts a scan timer (step S601).
  • step S602 the connection management service processing unit 22 determines whether a beacon message has been received before the scan timer in step S601 times out. When the beacon message is not received (in the case of “No”), the process proceeds to step S612. On the other hand, when the beacon message is received (in the case of “Yes”), the process proceeds to step S603.
  • step S603 the connection management service processing unit 22 refers to the connection management table and confirms the connection status with the beacon transmission source vehicle. If it is determined in step S604 that the connection with the partner station has been completed (in the case of “No”), the process proceeds to step S611 to complete the initial connection procedure. On the other hand, when it is determined that it is not connected to the other station (in the case of “Yes”), the process proceeds to step S605.
  • step S605 the connection management service processing unit 22 generates a connection request message and transmits the connection request message to the retransmission control service processing unit 23 in order to make a connection request to the beacon transmission source vehicle.
  • step S606 the retransmission control service processing unit 23 transmits a connection request message to the data transfer service processing unit 11 and starts a retransmission timer at the same time.
  • step S607 the retransmission control service processing unit 23 determines whether or not the connection response message has been received before the retransmission timer times out, and when the connection response message cannot be received (in the case of “No”). Returning to step S606, the connection request message is retransmitted. On the other hand, when the connection response message is received (in the case of “Yes”), the process proceeds to step S608.
  • step S608 the retransmission control service processing unit 23 passes the received message to the connection management service processing unit 22, and the connection management service processing unit 22 updates the connection management table to “connected” and initial connection with the partner station. Establish.
  • step S609 the connection management service processing unit 22 generates an acknowledgment message and passes it to the data transfer service processing unit 11 for transmission to the partner station.
  • step S610 the application processing unit is notified that the connection has been established, and the initial connection procedure is completed.
  • step S602 the connection management service processing unit 22 determines whether or not the connection request message is received in step S612. When the connection request message cannot be received (in the case of “No”), the process proceeds to step S621. On the other hand, when the connection request message is received (in the case of “Yes”), the process proceeds to step S613.
  • step S613 the connection management service processing unit 22 refers to the connection management table and confirms the connection status with the partner station. If it is determined in step S614 that the connection with the partner station has been completed (in the case of “No”), the process proceeds to step S620. On the other hand, when it is determined that it is not connected to the other station (in the case of “Yes”), the process proceeds to step S615.
  • step S615 the connection management service processing unit 22 updates the connection management table to “connected”, establishes an initial connection with the counterpart station, and notifies the inter-vehicle communication application 31 that the connection has been established.
  • step S616 the connection management service processing unit 22 transmits a connection response message to the retransmission control service processing unit 23 in order to respond to the connection request from the partner station.
  • step S617 the retransmission control service processing unit 23 transmits a connection response message to the data transfer service processing unit 11, and simultaneously starts a retransmission timer.
  • step S618 the retransmission control service processing unit 23 determines whether an acknowledgment message has been received before the retransmission timer times out. If the confirmation response message cannot be received (in the case of “No”), the process returns to step S617 to retransmit the connection response message. On the other hand, when the confirmation response message is received (in the case of “Yes”), the process proceeds to step S619.
  • step S619 the retransmission control service processing unit 23 transmits the received message to the connection management service processing unit 22, and the connection management service processing unit 22 completes the initial connection procedure.
  • step S614 the connection management service processing unit 22 sets the variable result code of the connection response message to “connected” in step S620 if the connection with the partner station has been completed, and the connection response in step S616. Generate a message. Thereafter, the initial connection procedure is executed according to the procedures of steps S617 to S619.
  • connection management service processing unit 22 cannot receive the connection request message in step S612, it generates a beacon message in step S621. And a beacon timer is started simultaneously with transmitting a beacon message (step S622).
  • step S623 the connection management service processing unit 22 determines whether or not the connection request message can be received before the beacon timer activated in step S622 times out. If the message cannot be received (in the case of “No”), the process returns to step S622, and the beacon message is transmitted again. On the other hand, if the connection request message is received before the time-out (in the case of “Yes”), the process proceeds to step S613, and the initial connection is executed according to the procedure of steps S613 to S619.
  • the connection management service processing unit 22 determines whether or not the information in the management information storage unit 24 has been updated when the inter-vehicle communication transfer service processing unit 1 receives the broadcast application (step S701). When the information is not updated (in the case of “No”), the process proceeds to step S713. On the other hand, when the information is updated (in the case of “Yes”), the process proceeds to step S702.
  • step S702 the connection management service processing unit 22 refers to the connection management table and confirms the connection status with the vehicle whose information has been updated. If it is determined in step S703 that the connection with the partner station has been completed (in the case of “No”), the process proceeds to step S711, and the initial connection procedure is terminated. On the other hand, if it is not connected (in the case of “Yes”), the process proceeds to step S704.
  • step S704 the connection management service processing unit 22 refers to the connection request flag to determine whether or not “1” is indicated.
  • the connection request flag does not indicate “1” (“No” ”)
  • the process proceeds to step S712, and the initial connection procedure is terminated.
  • the connection request flag indicates “1” (in the case of “Yes”)
  • the process proceeds to step S705.
  • step S705 the connection management service processing unit 22 generates a connection request message and transmits the connection request message to the retransmission control service processing unit 23 in order to make a connection request to the partner vehicle.
  • step S706 the connection management service processing unit 22 starts the retransmission timer simultaneously with the retransmission control service processing unit 23 transmitting a connection request message to the data transfer service processing unit 11.
  • step S707 the retransmission control service processing unit 23 determines whether a connection response message has been received before the retransmission timer times out. If the connection response message cannot be received (in the case of “No”), the process returns to step S706 to retransmit the connection request message. On the other hand, when the connection response message is received (in the case of “Yes”), the process proceeds to step S708.
  • step S708 the retransmission control service processing unit 23 passes the received message to the connection management service processing unit 22, and the connection management service processing unit 22 updates the connection management table to “connected” and establishes an initial connection with the partner station. Simultaneously with the establishment, the inter-vehicle communication application unit 31 is notified of the connection.
  • step S709 the connection management service processing unit 22 generates an acknowledgment message and passes it to the data transfer service processing unit 11 for transmission to the partner station.
  • step S710 the application processing unit is notified that the connection has been established, and the initial connection procedure is completed.
  • step S701 determines whether the connection request message has been received in step S713, and If the request message cannot be received (in the case of “No”), the process returns to step S701. On the other hand, when the connection request message is received (in the case of “Yes”), the process proceeds to step S714.
  • step S714 the connection management service processing unit 22 refers to the connection management table and confirms the connection status with the partner station. If it is determined in step S715 that the connection with the counterpart station has been completed (in the case of “No”), the process proceeds to step S721. On the other hand, when it is not connected (in the case of “Yes”), the process proceeds to step S716.
  • step S716 the connection management service processing unit 22 updates the connection management table to “connected”, establishes an initial connection with the counterpart station, and notifies the inter-vehicle communication application 31 that the connection has been established.
  • step S717 the connection management service processing unit 22 transmits a connection response message to the retransmission control service processing unit 23 in order to respond to the connection request from the partner station.
  • step S718 the retransmission control service processing unit 23 transmits a connection response message to the data transfer service processing unit 11, and simultaneously starts a retransmission timer.
  • step S719 the retransmission control service processing unit 23 determines whether or not an acknowledgment message has been received before the retransmission timer times out, and when the acknowledgment message has not been received (in the case of “No”). Returning to step S718, the connection response message is retransmitted. On the other hand, when the confirmation response message is received (in the case of “Yes”), the process proceeds to step S720 to complete the initial connection procedure.
  • step S715 If it is determined in step S715 that the retransmission control service processing unit 23 has already been connected to the partner station, the variable result code of the connection response message is set to “connected” in step S721, and the connection is made in step S717. Generate a response message. Thereafter, the initial connection procedure is executed according to the procedures of steps S718 to S720.
  • FIG. 67 is a flowchart showing the operation of the vehicle-to-vehicle communication application unit 31 of the application processing unit 3.
  • the vehicle-to-vehicle communication application unit 31 registers application information in the management information storage unit 24 of the vehicle-to-vehicle communication management service processing unit 2 after activation (step S801).
  • step S802 the vehicle-to-vehicle communication application unit 31 stands by until there is a data transmission request or a data reception notification (step S802).
  • step S803 the process proceeds to step S803.
  • step S803 it is determined whether or not the content received in step S802 is a transmission request. If the content is a transmission request (in the case of “Yes”), the process proceeds to step S804. On the other hand, in the case of a reception notification (in the case of “No”), the process proceeds to step S806.
  • step S804 it is determined whether or not the data requested to be transmitted is broadcast, and in the case of broadcast communication (in the case of “Yes”), the process proceeds to step S805. On the other hand, in the case of individual communication (in the case of “No”) instead of broadcast communication, the process proceeds to step S807.
  • step S805 the data to be transmitted is transmitted to the transaction service processing unit 41 of the transaction management unit 4, and the broadcast communication processing procedure of the application processing unit is completed.
  • step S806 the inter-vehicle communication application unit 31 reads the received data, and the vehicle information is managed by the management information storage unit 24 of the inter-vehicle communication management service processing unit 2. To complete the data reception processing procedure of the application processing unit.
  • step S804 when data is individually communicated, the inter-vehicle communication application unit 31 transmits a connection request to the connection management service processing unit 22 of the inter-vehicle communication management service processing unit 2 in step S807.
  • step S808 it is determined whether or not a connection establishment notification is received from the connection management service processing unit 22, and if connection establishment is notified (in the case of “Yes”), the process proceeds to step S809. On the other hand, when the connection establishment notification cannot be received (in the case of “No”), the process proceeds to step S810.
  • step S809 the inter-vehicle communication application unit 31 transmits data to be transmitted to the transaction service processing unit 41, and completes the transmission processing procedure of the individual communication.
  • step S810 the inter-vehicle communication application unit 31 discards the data requested to be transmitted and completes the transmission processing procedure.
  • FIG. 68 is a flowchart showing the operation of the transaction service processing unit 41 of the transaction management unit 4.
  • the transaction service processing unit 41 waits until there is a data transmission request or a data reception notification (step S901). When the request and notification are not received (in the case of “No”), standby is continued until the request and notification are received. On the other hand, when the request and notification are received (in the case of “Yes”), the process proceeds to step S902.
  • step S902 it is determined whether or not the content received in step S901 is a transmission request. If the content is a transmission request (“Yes”), the process proceeds to step S903. On the other hand, in the case of a reception notification (in the case of “No”), the process proceeds to step S905.
  • step S903 the transaction service processing unit 41 performs transmission processing such as division, retransmission, and continuous transmission as necessary.
  • step S904 an LPP header is added to the transmission data, and the LPCP transfer service processing of the transfer service processing unit 5 is performed. To the unit 51.
  • step S902 reception processing such as assembly and connection management is executed in step S905.
  • step S906 it is determined whether or not the received data is data to be transferred to the application. If the data is to be transmitted to the application (in the case of “Yes”), the process proceeds to step S907. On the other hand, when the control data transmitted from the LPP connection management service processing unit 42 is received (in the case of “No”), the process proceeds to step S908.
  • step S907 transmission data is passed to the inter-vehicle communication application unit 31 of the application processing unit 3, and the application data reception processing procedure of the transaction management unit 4 is completed.
  • step S908 control data is passed to the LPP connection management service processing unit 42, and the control data reception processing procedure of the transaction management unit 3 is completed.
  • step S901 is repeatedly performed.
  • FIG. 69 is a flowchart showing the operation of the LPCP transfer service processing unit 51 of the transfer service processing unit 5.
  • the LPCP transfer service processing unit 51 stands by until there is a data transmission request or a data reception notification (step S1001).
  • step S1001 When the request and notification are not received (in the case of “No”), standby is continued until the request and notification are received.
  • step S1002 When the request and notification are received (in the case of “Yes”), the process proceeds to step S1002.
  • step S1002 it is determined whether or not the content received in step S1001 is a transmission request. If the content is a transmission request (“Yes”), the process proceeds to step S1003. On the other hand, in the case of a reception notification (in the case of “No”), the process proceeds to step S1005.
  • step S1003 the LPCP transfer service processing unit 51 assigns an LPCP header such as a local port number, and passes the transmission data to the data transfer service processing unit 11 of the transfer service processing unit 5 in step S1004 to perform transfer service processing.
  • the data transmission processing procedure in the unit 5 is completed.
  • step S1002 if a data reception notification is received in step S1002, the LPCP transfer service processing unit 51 refers to the local port number in step S1005 to identify the distribution destination of the received data.
  • step S1006 the reception data is transmitted to the distribution destination, and the data reception processing procedure of the transfer service processing unit 5 is completed.
  • step S1001 is repeatedly executed.
  • FIG. 70 is a flowchart showing the operation of the transmission / reception service processing unit 6.
  • the transmission service processing unit 61 and the reception service processing unit 62 wait until there is a data transmission request or a data reception notification (step S1101).
  • step S1101 When the request and notification are not received (in the case of “No”), standby is continued until the request and notification are received.
  • step S1102 it is determined whether or not the content received in S1101 is a transmission request. If the content is a transmission request (in the case of “Yes”), the process proceeds to step S1103. On the other hand, in the case of a reception notification (in the case of “No”), the process proceeds to step S1105.
  • step S1103 the transmission service processing unit 61 acquires transmission power from the communication control information storage unit 71 of the transmission / reception service management unit 7.
  • step S1104 the transmission service processing unit 61 performs wireless communication using the acquired transmission power and performs transmission / reception service. The transmission processing procedure of the processing unit 6 is completed.
  • step S1102 if it is determined in step S1102 that the data reception notification has been made, in step S1105, the reception service processing unit 62 acquires the reception sensitivity from the communication control information storage unit 71 of the transmission / reception service management unit 7.
  • step S1106 it is determined whether or not the power of the received data is equal to or higher than the carrier sense sensitivity. If power equal to or higher than the carrier sense sensitivity is received (in the case of “Yes”), the process proceeds to step S1107. When the power less than the carrier sense sensitivity is received (in the case of “No”), the process proceeds to step S1108.
  • step S1107 the reception service processing unit 62 determines that the communication channel is busy, and updates the utilization rate of the communication channel in the communication control information storage unit 71.
  • step S1108 the reception service processing unit 62 determines whether or not the power of the received data is equal to or higher than the reception sensitivity. If power equal to or higher than the reception sensitivity is received (in the case of “Yes”), the process proceeds to step S1109. To do. On the other hand, when power less than the reception sensitivity is received (in the case of “No”), the process proceeds to step S1110.
  • step S1109 the reception service processing unit 62 transmits the received data to the priority control service processing unit 13 of the inter-vehicle communication management service processing unit 1, and completes the reception processing procedure.
  • step S1110 the reception service processing unit 62 discards the received data and completes the reception processing procedure.
  • step S1104, S1109, and S1110 is completed, the process after step S1101 is repeatedly performed.
  • the vehicle-to-vehicle communication transfer service processing unit 1 and the vehicle-to-vehicle communication management service processing unit 2 use existing road-to-vehicle communication protocols.
  • LPCP transfer service processing unit
  • an in-vehicle communication device that can share an in-vehicle device that provides a road-to-vehicle communication system and an in-vehicle device that provides an inter-vehicle communication system can be obtained. It is possible to obtain an in-vehicle communication device that can provide services to both the communication system and the inter-vehicle communication system.
  • inter-vehicle communication transfer service processing unit 1 is interposed between the application processing unit and the transmission / reception service processing unit, communication can be controlled according to the priority of a plurality of applications. Can be transmitted automatically.
  • the vehicle-to-vehicle communication management service processing unit 2 is arranged so as to be parallel to the application processing unit 3, the vehicle-to-vehicle communication transfer service processing unit 1, and the transmission / reception service management unit 7. It is possible to perform communication control for avoiding congestion of the host vehicle and the surrounding vehicles based on the vehicle information and the degree of danger, and the channel utilization rate acquired from the transmission / reception service management unit. Thereby, even when the number of vehicles increases, the communication error rate can be improved.
  • the inter-vehicle communication transfer service processing unit 1 can acquire the priority via the inter-vehicle communication management service processing unit 2, the transaction management unit (local port protocol) 4 and the transfer service processing unit (local Even when the priority cannot be obtained from the port control protocol (5) or the like, priority control can be provided.
  • the inter-vehicle communication transfer service processing unit 1 efficiently adds information necessary for communication control by adding communication control information such as transmission power, reception sensitivity, and communication channel utilization rate to a message to be transmitted. Can be collected.
  • the inter-vehicle communication management service processing unit 2 can set communication parameters such as a transmission cycle and transmission power based on information detected by surrounding vehicles when performing congestion control, and efficient congestion control can be performed. It becomes possible to do.
  • inter-vehicle communication management service processing unit 2 is arranged so as to extend in parallel from the application processing unit 3 to the transmission / reception service management unit 6, acquisition of information of the application processing unit 3 and the transmission / reception service management unit 7, Setting to the application processing unit 3 and the transmission / reception service management unit 7 is possible.
  • the inter-vehicle communication management service processing unit 2 regulates the connection procedure for performing the initial connection and manages the connection status in order to provide the communication connection management service. Communication can be started individually. Further, when the transmission / reception service processing unit 6 does not have the initial connection procedure, the inter-vehicle communication management service processing unit 2 can start the initial connection and manage the communication connection.
  • inter-vehicle communication management service processing unit 2 can notify the application processing unit 3 and the transaction management unit 4 of establishment of communication connection via the inter-vehicle communication transfer service processing unit 1.
  • the inter-vehicle communication management service processing unit 2 sends a connection request for initial connection to the partner mobile station upon receiving the message of the application. By transmitting, high-speed and efficient initial connection can be performed.
  • the inter-vehicle communication management service processing unit 2 periodically transmits a message when an application that periodically transmits a message is not operating, and triggered by the neighboring mobile stations receiving the message. By transmitting a connection request for initial connection to the partner mobile station, initial connection can be started.
  • inter-vehicle communication management service processing unit 2 avoids useless message transmission by monitoring whether a message required for the initial connection is transmitted on the communication channel when performing the initial connection. Communication bandwidth can be used effectively.
  • the inter-vehicle communication management service processing unit 2 can immediately suppress the utilization rate of the communication band by transmitting a control message that can instruct the transmission power, reception sensitivity, transmission channel, and the like to the surrounding mobile stations. Thus, it becomes possible to preferentially transmit the own station.
  • a protocol IEEE 1609.3 studied in the United States or a protocol FAST or Geo-Routing studied in the European CALM (Communications Architecture for Land Mobile Environment) may be used.
  • the inter-vehicle communication management service processing unit 2 is arranged in parallel to the application processing unit 3, the transaction management unit 4, the transfer service processing unit 5, the inter-vehicle communication transfer service processing unit 1, and the transmission / reception service management unit 7.
  • the management unit WME (WAVE Management Entity) studied by IEEE 1609.3 and the management unit CME (CALM Management Management Entity) studied by CALM are also arranged in the same manner as the inter-vehicle communication management service processing unit 2 Therefore, a configuration including the inter-vehicle communication management service processing unit 2 in the WME or CME or a configuration including the WME or CME may be used.
  • WAVE is an abbreviation for Wireless Access in Vehicular Environments.
  • the interface between the application processing unit 3 and the transmission / reception service management unit 7 is replaced with or added to the interface between the WME and the application and between the WME and the MLME / PLME. May be.
  • the interface between the inter-vehicle communication transfer service unit 1 and the inter-vehicle communication management service processing unit 2 may be integrated with an interface between the CME and FAST.
  • the application processing unit 3 is not limited to the application of the inter-vehicle communication system, and may use an application other than the application of the road-to-vehicle communication system or the application related to ITS.
  • inter-vehicle communication management service processing unit 2 is not limited to the transmission period, transmission power, and reception sensitivity as communication parameters to be set to avoid congestion, but the directivity of the transmission channel and transmission / reception antenna, the frequency band to be transmitted, etc. May be used.
  • FIG. 71 is a block diagram showing a protocol configuration of the in-vehicle communication device 101 and the road-to-vehicle / vehicle-to-vehicle communication cooperation system according to the second embodiment of the present invention, and FIG. It is a block diagram which shows a protocol structure in detail.
  • symbol is attached
  • the in-vehicle communication device 101 includes an inter-vehicle communication transfer service processing unit 1, an inter-vehicle communication management service processing unit 2, an application processing unit 3, a transmission / reception service processing unit 6, and a transmission / reception service. It has a management unit 7.
  • the transaction management unit 4 and the transfer service processing unit 5 which are the existing road-to-vehicle communication protocols in the in-vehicle communication device 100 shown in FIG.
  • the in-vehicle communication device 100 and the road-to-vehicle to vehicle-to-vehicle communication cooperation described in Embodiment 1 It is different from the system.
  • the in-vehicle communication device 101 includes the road-to-vehicle communication application unit 32 and the road-to-vehicle-to-vehicle communication cooperation service processing unit 8, it is possible to provide an application for road-to-vehicle communication.
  • the road-to-vehicle-to-vehicle communication cooperation service processing unit 8 has functions equivalent to those of the transaction management unit 4 and the transfer service processing unit 5 shown in the first embodiment.
  • in-vehicle communication device 101 the data transmitted by the road-to-vehicle communication application unit 32 is transmitted and received through the transaction service processing unit 41 and the LPCP transfer service processing unit 51 of the road-vehicle-to-vehicle communication cooperation service processing unit 8. Unlike the data transmitted from the unit 6 to the partner station and transmitted by the inter-vehicle communication application unit 31, the data does not pass through the data transfer service processing unit 11 of the inter-vehicle communication transfer service processing unit 1.
  • the transmission / reception service processing unit 6 when receiving data from the peripheral station, refers to the header information given by the transmission service processing unit 6 and transmits it to the road-vehicle-vehicle communication cooperation service processing unit 8 or transfers the communication between vehicles. Whether to transmit to the service processing unit 1 is determined. As a result, the road-to-vehicle communication application is transmitted to the road-to-vehicle communication application unit 32 via the road-to-vehicle-to-vehicle communication cooperation service processing unit 8, and the vehicle-to-vehicle communication application is the vehicle-to-vehicle communication transfer service processing unit 1. The data is transmitted to the inter-vehicle communication application unit 31 via the communication cooperation service processing unit 8.
  • the in-vehicle communication device 101 includes the road-to-vehicle-to-vehicle communication cooperation service processing unit 8 so that road-to-vehicle communication data does not pass through the vehicle-to-vehicle communication transfer service processing unit 1.
  • the inter-vehicle communication data can be transmitted to the partner station, and can be transmitted to the peripheral stations by performing necessary control via the inter-vehicle communication transfer service processing unit 1.
  • the vehicle-mounted device for road-to-vehicle communication and the vehicle-mounted device for vehicle-to-vehicle communication can be shared.
  • the road-vehicle-to-vehicle communication cooperation service processing unit 8 the vehicle-to-vehicle communication transfer service processing unit 1, and the vehicle-to-vehicle communication management service processing unit 2 are shown.
  • an existing protocol such as a local port protocol or a local port control protocol may be used as in the first embodiment.
  • Embodiment 3 > ⁇ C-1. Protocol configuration> Embodiment 3 according to the present invention will be described with reference to FIGS. 73 and 74.
  • FIG. 73 and 74 FIG. 74
  • FIG. 73 is a block diagram showing in detail the protocol configuration of the in-vehicle communication device 102 and the road-to-vehicle / vehicle-to-vehicle communication cooperation system according to the second embodiment of the present invention.
  • symbol is attached
  • the in-vehicle communication device 102 has substantially the same configuration as the in-vehicle communication device 100 of the first embodiment described with reference to FIG. 1, but the application processing unit 3 includes a road-to-vehicle communication application unit 32. This is different from the in-vehicle communication device 101 of the first embodiment.
  • the inter-vehicle communication transfer service processing unit 1 refers to the port number of the LPCP header from the C2C SDU received from the transfer service processing unit 5, and simultaneously acquires the application type when acquiring the priority in step S105 of FIG. Identify the road-to-vehicle communication application or the car-to-vehicle communication application.
  • the transmission / reception procedure described in the first embodiment is applied to transmit / receive a message.
  • the transmission power transmitted by the transmission service processing unit 61 defines a value for road-to-vehicle communication, and the value may be applied, or the vehicle-to-vehicle communication management service processing unit 2 is suitable for road-to-vehicle communication.
  • the transmission power may be calculated. Further, when the information of the road-to-vehicle communication application unit 32 is transmitted, the congestion control service and the connection management service need not be provided.
  • the vehicle-to-vehicle communication management service processing unit 2 transmits a congestion control message from the road-to-vehicle communication application unit 32 by using an application notification primitive or an application registration primitive before transmitting the information of the road-to-vehicle communication application unit 32.
  • the transmission cycle of the inter-vehicle communication application unit 31 can be lengthened or the transmission power can be lowered.
  • the inter-vehicle communication transfer service processing unit 1 refers to the C2C header and identifies the transfer destination and the reception processing from the data identifier and the PDU identifier.
  • the data identifier indicates “0” and the PDU identifier indicates “0”
  • processing is performed in the same procedure as in the first embodiment.
  • the data identifier indicates “0” and the PDU identifier indicates “1”
  • the data body part is taken out and transferred to the transfer service processing unit 5 to complete the reception process.
  • the reception sensitivity set by the reception service processing unit 62 defines a value for road-to-vehicle communication, and the value may be applied, or the vehicle-to-vehicle communication management service processing unit 2 is suitable for road-to-vehicle communication.
  • the reception sensitivity may be calculated.
  • the inter-vehicle communication transfer service processing unit 1 When the inter-vehicle communication transfer service processing unit 1 receives the data of the road-to-vehicle communication application unit 32, the inter-vehicle communication transfer service processing unit 1 issues an event notification primitive to the inter-vehicle communication management service processing unit 2, and there is a roadside device around the own station. Notify that. Thereby, the inter-vehicle communication management service processing unit 2 sets the transmission power when transmitting the data of the inter-vehicle communication application unit 31 to be smaller than the value set by the congestion control service, or sets the transmission cycle to be longer. Or
  • the in-vehicle communication device 102 according to the third embodiment is similar to the in-vehicle communication device 100 according to the first embodiment, and the application processing unit 3 includes the inter-vehicle communication application unit 31. Can be provided. Further, since the in-vehicle communication device 102 includes the road-to-vehicle communication application unit 32, it is possible to provide an application for road-to-vehicle communication.
  • the inter-vehicle communication transfer service processing unit 1 uses different transmission / reception procedures depending on the road-to-vehicle communication application and the inter-vehicle communication application, in the case of road-to-vehicle communication application data, a minimum header information is added and the data body is transmitted. Can do.
  • the in-vehicle communication device 102 does not affect the operation of the existing road-vehicle communication system, and can provide various control services only to the vehicle-to-vehicle communication system.
  • the vehicle-to-vehicle communication management service processing unit 2 can control the transmission power and transmission cycle of the vehicle-to-vehicle communication application of the peripheral station by the congestion control message. Thereby, the communication reliability of the road-vehicle communication application can be improved.
  • the vehicle-to-vehicle communication transfer service processing unit 1 notifies the vehicle-to-vehicle communication management service processing unit 2 of the presence or absence of the road-to-vehicle communication application, so that the road-to-vehicle communication application is transmitted and received preferentially. Can be suppressed or the transmission cycle can be lengthened. Thereby, the communication reliability of the road-vehicle communication application can be improved.
  • Embodiment 4 > ⁇ D-1. Protocol configuration> Embodiment 4 according to the present invention will be described with reference to FIGS. 75 to 77.
  • FIG. the same code
  • FIG. 75 is a block diagram showing a configuration of the in-vehicle communication device 103 according to the fourth embodiment of the present invention.
  • the in-vehicle communication device 103 has substantially the same configuration as the in-vehicle communication device 100 of the first embodiment described with reference to FIG. 1, but the transaction management unit 4 and the transfer service processing unit 5 are configured with WAVE (Wireless (Access in Vehicular Environments)
  • the transfer unit 9 is different from the in-vehicle communication device 100 of the first embodiment in that the inter-vehicle communication management service processing unit 2 is included in the WAVE management unit 10.
  • the WAVE transfer unit 9 is a protocol called WSMP (WAVE Short Message Protocol) in IEEE1609.3, provides a service for transmitting data according to a request from the application processing unit 3, and notifies the application processing unit 3 of the received data To provide services.
  • WSMP Wi-Fi Short Message Protocol
  • the WAVE management unit 10 is a management function called WME in IEEE 1609.3, which provides connection management services in response to requests from the application processing unit 3 and sets / gets data managed by the WME for applications. Provide information access services to be performed.
  • FIG. 3 In the configuration of FIG. 3 in the first embodiment, a hierarchical structure including the transaction management unit 4 (LPP) and the transfer service processing unit 5 (LPCP) which are Japanese road-to-vehicle communication standards is shown.
  • LPP transaction management unit 4
  • LPCP transfer service processing unit 5
  • FIG. 4 the configuration of the fourth embodiment uses WSMP of protocol IEEE 1609.3 which is an American road-to-vehicle communication and vehicle-to-vehicle communication standard.
  • inter-vehicle communication management service processing unit 2 having the configuration of FIG. 3 according to the first embodiment is arranged in the same manner as the management unit WME of IEEE 1609.3, the inter-vehicle communication having the configuration of FIG. 75 according to the fourth embodiment.
  • the management service processing unit 2 is included in the WME.
  • the transmission / reception service processing unit 6 assumes IEEE802.11p and IEEE1609.4, and performs wireless communication with the in-vehicle communication device 103 installed in the peripheral station, and switches the frequency channel for wireless communication. .
  • the inter-vehicle communication transfer service processing unit 1 exists between the WAVE transfer unit 9 and the transmission / reception service processing unit 6, and provides a data transfer service and a priority control service to the WAVE transfer unit 9 and the WAVE management unit 10. I will provide a. Further, an event notification service is provided to the WAVE management service processing unit 10.
  • the inter-vehicle communication management service processing unit 2 exists as one function of the WAVE management unit 10 inside the WAVE management unit 10 and is congested with the application processing unit 3 and the inter-vehicle communication transfer service processing unit 1. Provides control services, connection management services, and data retransmission services. Further, the WAVE management unit 10 extends the function of the transmission / reception service management unit 7.
  • FIG. 76 is a diagram showing the position of the SAP in the protocol configuration of the inter-vehicle communication architecture according to the fourth embodiment of the present invention.
  • SAP Service Interface
  • FIG. 76 a list of SAPs different from those in the first embodiment is shown in FIG.
  • the same SAP as in the first embodiment has the same function as that of the SAP shown in FIG.
  • the description of the SAP parameters shown in FIG. 77 is disclosed in the IEEE standard and can be understood by those skilled in the art by referring to the standard.
  • the CMCTL SAP, MLME SAP, and PLME SAP in FIG. 18 shown in Embodiment 1 can be used as they are because they are the same SAP as in Embodiment 4, but the ACML SAP and ACTL SAP in FIG. Since it is different from the SAP of the fourth embodiment, the first embodiment cannot be applied as it is. Therefore, in the case of the configuration shown in FIG. 76, in the fourth embodiment, ACML SAP is replaced with WME SAP and ACTL SAP is replaced with LSAP in order to match the interface provided by WSMP or WME.
  • the WME provides the following six types of primitives to the application as shown in FIG. (1) Connection request primitive (WME-Application) Functions and parameters equivalent to the ACML-Connect primitive of the first embodiment are provided.
  • the WME-Application primitive is a primitive that an application requests or disconnects from a peripheral station.
  • Application notification primitive (WME-Notification) Functions and parameters equivalent to the ACML-Notify primitive of the first embodiment are provided.
  • WME-Notification is a primitive that is notified from the WAVE management unit 10 to the application processing unit 3 when there is a change in the connection state with the peripheral station.
  • the WME-ApplicationRegistration primitive is a primitive for registering and deleting application information.
  • WME information acquisition primitive (WME-Get) Functions and parameters equivalent to the ACML-Get primitive of the first embodiment are provided.
  • the WME-Get primitive is a primitive for an application to acquire information managed by the WME.
  • WME information setting primitive (WME-Set) Functions and parameters equivalent to the ACML-Set primitive of the first embodiment are provided.
  • the WME-Set primitive is a primitive for an application to set information managed by the WME.
  • Receive power request primitive (WME-RCPIREQUEST) The primitive is not supported in the first embodiment.
  • the WME-RCPIREQUEST primitive is a primitive that an application requests data transmission for measuring received power to a specific vehicle.
  • CTL provides the following one kind of primitive to WSMP as shown in FIG. Further, since LSAP is also a primitive provided by the data link layer to ACTL, insertion of CTL does not affect IEEE 1609.3 communication.
  • UL-UNITDATA Data transfer primitive
  • the UL-UNITDATA primitive is a primitive for the WSMP to transmit / receive data to / from the CTL.
  • the name of the SAP is different from that of the first embodiment, but the data transfer service and event provided by the CTL and CML of the present invention can be used even when IEEE1609.3 is used by replacing the SAP with the SAP shown in FIG. It is possible to provide a notification service, a priority control service, a congestion control service, a connection management service, and a data retransmission service.
  • the WAVE transfer unit 8 adds a WSM header including the type of application, a list of applications that can be provided, available frequency channel information, and the like to the data passed from the application processing unit 3, and the inter-vehicle communication transfer service processing unit 1 To pass.
  • the inter-vehicle communication transfer service processing unit 1 acquires the type of application from the WSM header, and acquires the priority of the corresponding application from the inter-vehicle communication management service processing unit 2 and the WAVE management unit 10.
  • the inter-vehicle communication transfer service processing unit 1 assigns the C2C header, passes it to the priority control service processing unit, performs priority control, and transmits data to the peripheral station via the transmission / reception service processing unit 6.
  • event information is notified to the application processing unit 3 via the inter-vehicle communication management service processing unit 2 using a CMCTL-EventReport primitive.
  • a connection management service is performed using the WME-Application primitive provided by the WAVE management unit 10.
  • initial connection can be performed using the function of the WAVE management unit 10, and the function of the inter-vehicle communication management service processing unit 2 can be used. Can also be used for initial connection.
  • the application processing unit 3 registers the information of the application that has become available in the WAVE management unit 10 using the WME-ApplicationRegistration primitive. If the application processing unit 3 is unable to provide the information, the WAVE management is performed using the primitive. Delete from part 10.
  • the in-vehicle communication device 103 having the protocol configuration of the fourth embodiment includes the WAVE transfer unit 9 and the WAVE management unit 10, so that the in-vehicle communication device in the case of using the IEEE protocol is also implemented.
  • the in-vehicle communication device 100 having the protocol configuration of the first embodiment it is possible to obtain an in-vehicle communication device that can provide services to both the road-to-vehicle communication system and the inter-vehicle communication system.
  • in-vehicle communication transfer service processing unit 1 and the inter-vehicle communication management service processing unit 2 in the in-vehicle device using the IEEE protocol, it is possible to realize a congestion control service that cannot be provided by the IEEE protocol.
  • Embodiment 5 > ⁇ E-1. Protocol configuration> Embodiment 5 according to the present invention will be described with reference to FIGS. 78 to 80.
  • FIG. the same code
  • FIG. 78 is a block diagram showing a configuration of the in-vehicle communication device 104 according to the fifth embodiment of the present invention.
  • the in-vehicle communication device 104 has substantially the same configuration as the in-vehicle communication device 100 according to the first embodiment described with reference to FIG. 1, but the transaction management unit 4 and the transfer service processing unit 5 have the CALM ( (Communication Access for Land Mobiles) Transfer unit 111 is different from in-vehicle communication device 100 of the first embodiment in that inter-vehicle communication management service processing unit 2 is included in CALM management unit 112.
  • CALM Common Access for Land Mobiles
  • the CALM transfer unit 111 is configured by protocols called FAL, CA-Routing, and LPTP (Local Port Port Transport Protocol) of CALM, and provides a service for transmitting data in accordance with a request from the application processing unit 3, or a destination vehicle Provide route search service that delivers data to
  • the CALM management unit 112 is a management layer called a CALM CME (CALM Management Management Entity), provides connection management services in response to requests from the application processing unit 3, and sets / manages data managed by the CME for applications. Provides information access services for acquisition.
  • CALM CME CALM Management Management Entity
  • a hierarchical structure including a transaction management unit 4 (LPP) and a transfer service processing unit 5 (LPCP) which are Japanese road-to-vehicle communication standards is shown.
  • LPP transaction management unit 4
  • LPCP transfer service processing unit 5
  • FIG. 78 the configuration of the fifth embodiment uses a network layer, a transport layer, and a management layer of the CALM protocol, which is a road-to-vehicle communication and vehicle-to-vehicle communication standard studied in Europe.
  • inter-vehicle communication management service processing unit 2 having the configuration of FIG. 3 according to the first embodiment is arranged in the same manner as the management unit CME of the CALM. Therefore, in the configuration of FIG.
  • the service processing unit 2 is included in the CME.
  • the transmission / reception service processing unit 6 performs wireless communication with the in-vehicle communication device 104 installed in a peripheral station assuming IEEE 802.11p, a wireless LAN, or the like.
  • the transmission / reception service management unit 7 of the fifth embodiment uses a management layer called IME (Interface Management Management Entity) of CALM.
  • IME Interface Management Management Entity
  • the inter-vehicle communication transfer service processing unit 1 exists between the CALM transfer unit 111 and the transmission / reception service processing unit 6, and provides data transfer service and priority to the CALM transfer unit 111 and the CALM management unit 112. Provide degree control service. Furthermore, an event notification service is provided to the CALM management unit 112.
  • the inter-vehicle communication management service processing unit 2 exists inside the CALM management unit 112, and provides a congestion control service, a connection management service, an application processing unit 3 and an inter-vehicle communication transfer service processing unit 1, And provide a data retransmission service.
  • the CALM management unit 112 extends the function of the transmission / reception service management unit 7.
  • FIG. 79 is a diagram showing the position of the SAP in the protocol configuration of the inter-vehicle communication architecture according to the fifth embodiment of the present invention.
  • FIG. 79 a list of SAPs different from those in the first embodiment is shown in FIG.
  • the same SAP as in the first embodiment has the same function as that of the SAP shown in FIG.
  • the SAP parameters shown in FIG. 80 are not established in both the CALM protocol and the IEEE protocol, but it is possible to know the outline of the draft stage. Since the same kind of SAP parameters are used, the present invention can be applied even if the standard is not yet determined.
  • mibIndex and mibParameter are specified for ACML-Set and ACML-Get, respectively, and data is set and acquired, whereas for A-SetParam and A-GetParam, ParamNo and Since it is assumed to be realized by replacing with ParamValue, it is possible to cope even if the standard is not yet confirmed. This will be specifically described below.
  • the CMCTL SAP in FIG. 18 shown in the first embodiment can be used as it is because it is the same SAP as in the fifth embodiment.
  • the ACML SAP, CTL SAP, MLME SAP, and PLME SAP in FIG. Since the fifth embodiment is different from the SAP, the first embodiment cannot be applied as it is. Therefore, in the case of the protocol configuration shown in FIG. 79, ACML SAP is replaced with A-SAP, and CTL SAP is replaced with C-SAP to match the interface provided by the CALM network layer / transport layer and CME.
  • PLME SAP and PLME SAP are replaced with M-SAP.
  • the CME provides the following four types of primitives to the application as shown in FIG. (1)
  • Command execution primitive A-Command Functions and parameters equivalent to the primitives of ACML-Connect, ACML-Notify, ACML-Registration, and ACML-Deregistration of Embodiment 1 are provided, and various commands are executed to the CALM transfer unit 111 and the CALM management unit 112 Request.
  • Request execution primitive A-Request Functions and parameters equivalent to the primitives of ACML-Connect, ACML-Notify, ACML-Registration, and ACML-Deregistration of Embodiment 1 are provided, and various requests are executed to the CALM transfer unit 111 and the CALM management unit 112 Request.
  • CME information acquisition primitive (A-GetParam) This is a primitive that provides the same functions and parameters as the ACML-Get primitive of Embodiment 1 and obtains information held by the CME.
  • CME information setting primitive (A-SetParam) It is a primitive that provides functions and parameters equivalent to the ACML-Set primitive of Embodiment 1 and sets information for the CME.
  • the CTL provides the following one type of primitive to the CALM transfer unit 111 as shown in FIG. Further, since the C-SAP is also a primitive that the data link layer provides to the CALM transfer unit 111, even if the CTL is inserted, the communication of the CALM transfer unit 111 is not affected.
  • (1) Data transfer primitive (UL-UNITDATA) Functions and parameters equivalent to the SendData primitive of the first embodiment are provided.
  • the UL-UNITDATA primitive is a primitive for the CALM transfer unit 111 to transmit / receive data to / from the CTL.
  • IME information acquisition primitive (CIMAE-SetParam) This is a primitive that provides functions and parameters equivalent to those of the MLME-Set and PLME-Set primitives of Embodiment 1 and obtains information held by the IME.
  • IME information setting primitive (CIMAE-GetParam) This is a primitive that provides functions and parameters equivalent to those of the MLME-Get primitive and PLME-Get primitive of Embodiment 1 and sets information for the IME.
  • the name of the SAP is different from that of the first embodiment, but the CTL and CML of the present invention are provided by using the SAP shown in FIG. 80 even when the CALM transfer unit 111 and the CALM management unit 112 are used. It is possible to realize the function to perform.
  • the CALM transfer unit 111 includes a CALM header including an application type, a list of applications that can be provided, and usable communication media information. And give it to the inter-vehicle communication transfer service processing unit 1.
  • the inter-vehicle communication transfer service processing unit 1 acquires the type of application from the CALM header, and acquires the priority of the corresponding application from the inter-vehicle communication management service processing unit 2 and the CALM management unit 112.
  • the inter-vehicle communication transfer service processing unit 1 assigns a C2C header, passes it to the priority control service processing unit, performs priority control, and transmits data from the transmission / reception service processing unit 6.
  • event information is notified to the application processing unit 3 via the inter-vehicle communication management service processing unit 2 using a CMCTL-EventReport primitive.
  • connection management service is performed using the A-Command primitive and the A-Request primitive provided by the CALM management unit 112.
  • the initial connection can be performed using the function of the CALM management unit 112, or the inter-vehicle communication management service processing The initial connection can also be performed using the function of the unit 2.
  • the application processing unit 3 registers the information of the application that has become available to the CALM management unit 112 using the A-SetParam primitive. If the application processing unit 3 cannot provide the information, the application management unit 3 performs CALM management using the primitive. It deletes from the part 112.
  • the in-vehicle communication device 104 having the protocol configuration of the fifth embodiment includes the CALM transfer unit 111 and the CALM management unit 112, so that the in-vehicle communication device using the CALM protocol is also implemented.
  • the in-vehicle communication device 100 having the protocol configuration of the first embodiment it is possible to obtain an in-vehicle communication device that can provide services to both the road-to-vehicle communication system and the inter-vehicle communication system.
  • inter-vehicle communication transfer service processing unit 1 and the inter-vehicle communication management service processing unit 2 in the in-vehicle device using the CALM protocol, it is possible to realize a congestion control service that cannot be provided by the CALM protocol.

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Traffic Control Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

　本発明は、路車間通信システムと車々間通信システムの双方に対応できる車載通信装置および路車間－車々間通信連携システムを提供することを目的とし、車載通信装置１００は、車々間通信転送サービス処理部１と、車々間通信管理サービス処理部２と、アプリケーション処理部３と、トランザクション管理部４と、転送サービス処理部５と、送受信サービス処理部６と、送受信サービス管理部７とを有し、車々間通信転送サービス処理部１と車々間通信管理サービス処理部２は、既存の路車間通信プロトコルである転送サービス処理部５に対して、インタフェースを有する。

Description

車載通信装置および路車間－車々間通信連携システム
　本発明は、道路上を走行する移動局間で行われる車々間通信、および道路上に設置された基地局装置と移動局間で行われる路車間通信を利用して、移動局に対してサービスを提供する車載通信装置および路車間－車々間通信連携システムに関する。
　近年、車々間通信を行う車載通信装置を利用して安全運転支援システムを実用化する案が検討されている。この場合、車載通信装置には、一般的に各車両間で一定周期ごとに自車両の情報を送受信し合う情報交換型アプリケーションが用いられる。また、車々間通信システムにおいては、各車両が自発的に情報を送信するために、従来からアクセス方式にＣＳＭＡ（Carrier Sense Multiple Access）方式を用いることが知られている。
　ＣＳＭＡ方式において、情報交換型アプリケーションを利用すると、通信エリア内に存在する車両台数が増加した場合、通信トラフィックが増加し、通信容量を超えてしまうため、通信の信頼性が劣化する輻輳が発生し、車々間通信による情報伝達を確実に行えず安全支援サービスを提供できなくなることが考えられる。
　そこで、特許文献１では、車々間通信システムにおいて輻輳が発生しないように、車両の危険な状況や通信路のトラフィック量に基づいて自車両の送信周期制御（情報量制御）を行うことによって輻輳を回避する方法が開示されている。
　また、車々間通信システムでは情報交換型アプリケーション以外にも緊急情報を送信するアプリケーションなど複数のアプリケーションを利用することが将来的に想定されている。さらに、これらのアプリケーションを提供するためにはメッセージの再送や分割組み立てが必要と考えられている。
　そこで、社団法人電波産業界にて定められた標準規格「狭域通信（ＤＳＲＣ）アプリケーションサブレイヤ　ＡＲＩＢ　ＳＴＤ－Ｔ８８」（平成１６年５月２５日策定）および特許文献２では路車間通信システムにおいて、マルチアプリケーションに対応するためにローカルポート制御プロトコル（Local Port Control Protocol:LPCP）を用い、メッセージの再送や分割組み立てに対応するためにローカルポートプロトコル（Local Port Protocol:LPP）を用いる方法が開示されている。
特開２００６－２０９３３３号公報 国際公開第２００５－０３９０７５号
　特許文献１に記載の車載通信装置では、情報交換型アプリケーションとして単一のアプリケーションのみを想定した通信制御を行っていたため、緊急アプリケーションなどの他の複数アプリケーションを同時に利用する場合の通信制御には対応していなかった。また、特許文献１に記載の車載通信装置では、緊急アプリケーションなどの他の複数アプリケーションのためにあらかじめ通信帯域を確保しておくこともできなかった。
　さらに、特許文献１に記載の車載通信装置では、自車両に対してのみ通信制御を行って輻輳を回避しているが、自車両の通信制御だけではネットワーク全体のトラフィック量を即座に減らすことができない問題があった。
　また、特許文献２に記載の路車間通信システムでは、ローカルポート制御プロトコルによって、マルチアプリケーションに対応することが可能であり、ローカルポートプロトコルによって、メッセージの再送や分割／組み立てを行っていたが、車々間通信で必要とされる輻輳制御や優先度制御に対応することができなかった。
　さらに特許文献２に記載の路車間通信システムでは、ローカルポートプロトコルによって、狭域通信（Dedicated Short Range Communication:DSRC）の接続状況を管理していたが、ローカルポートプロトコルには初期接続の手順を規定していないため、車々間通信システムに特許文献２に記載の路車間通信システムを直接利用することはできなかった。
　本発明は上記のような問題点を解消するためになされたもので、情報の輻輳を回避する通信制御を行うとともに、車々間通信システムに必要とされる優先度制御や初期接続の確立手順を提供し、複数のアプリケーションに対応できて、メッセージの再送や分割／組み立てを行うことができ、路車間通信システムと車々間通信システムの双方に対応できる車載通信装置および路車間－車々間通信連携システムを提供することを目的とする。
　本発明に係る請求項１記載の車載通信装置は、移動局および基地局にそれぞれ搭載され、無線通信により前記移動局間および前記移動局と前記基地局との間で相互に受信側および送信側となる車載通信装置であって、前記車載通信装置は、前記受信側の前記車載通信装置に周期的にメッセージを送信するアプリケーション処理部と、前記アプリケーション処理部に接続され、前記アプリケーション処理部から受信した前記メッセージの再送や分割／組み立てを含むトランザクションサービスを少なくとも提供するトランザクション管理部と、前記トランザクション管理部に接続され、前記トランザクション管理部から受信した前記メッセージに、前記アプリケーション処理部を含む上位プロトコルを識別するためのローカルポート番号を付加する転送サービス処理部と、前記転送サービス処理部に接続され、前記転送サービス処理部から受信した前記メッセージを、前記アプリケーション処理部で処理されるアプリケーションの優先度順に前記受信側の前記車載通信装置に対して送信し、前記転送サービス処理部に対する前記メッセージを送受信し、エラー情報を含むイベント情報を通知する車々間通信転送サービス処理部と、前記車々間通信転送サービス処理部に接続され、前記車々間通信転送サービス処理部から受信した前記メッセージを、無線通信により前記受信側の前記車載通信装置との間で送受信する送受信サービス処理部と、前記アプリケーション処理部および前記車々間通信転送サービス処理部に接続され、前記アプリケーション処理部から前記優先度を設定され、前記車々間通信転送サービス処理部からの要求に応じて前記優先度を通知する車々間通信管理サービス処理部とを備え、前記トランザクション管理部および前記転送サービス処理部は、前記移動局と前記基地局との間での路車間通信を行うための路車間通信プロトコルを構成し、前記車々間通信転送サービス処理部は、前記受信側の前記車載通信装置に対して前記車々間通信管理サービス処理部の有する通信制御情報を通知し、前記受信側の前記車載通信装置は、前記車々間通信転送サービス処理部において、受信した前記メッセージに付与された前記通信制御情報を前記車々間通信管理サービス処理部に送信し、受信した前記メッセージは前記転送サービス処理部に送信される。
　本発明に係る請求項８記載の車載通信装置は、移動局および基地局にそれぞれ搭載され、無線通信により前記移動局間および前記移動局と前記基地局との間で相互に受信側および送信側となる車載通信装置であって、前記車載通信装置は、前記送信側から前記受信側に対して、路車間通信および車々間通信を利用してメッセージを送信するアプリケーション処理部と、前記アプリケーション処理部から受信した前記メッセージの再送や分割／組み立てを含むトランザクションサービス、前記アプリケーション処理部を含む上位プロトコルを識別するためのローカルポート番号の付加、および前記上位プロトコルに応じて前記メッセージの送信先を判別する路車間－車々間通信連携サービス処理部と、前記路車間－車々間通信連携サービス処理部から受信した前記メッセージを、前記アプリケーション処理部で処理されるアプリケーションの優先度順に前記受信側の前記車載通信装置に対して送信する車々間通信転送サービス処理部と、前記車々間通信転送サービス処理部を介して与えられる前記メッセージ、および前記路車間－車々間通信連携サービス処理部から直接与えられる前記メッセージに、識別のための識別子を付与して、無線通信により前記受信側の前記車載通信装置に送信する送受信サービス処理部と、前記アプリケーション処理部から前記優先度を設定され、前記車々間通信転送サービス処理部からの要求に応じて前記優先度を通知する車々間通信管理サービス処理部とを備え、前記路車間－車々間通信連携サービス処理部は、前記アプリケーション処理部から受信した前記メッセージを、路車間通信で送信するか、車々間通信で送信するかを判別し、前記路車間通信の場合には前記送受信サービス処理部に直接前記メッセージを与え、前記車々間通信の場合には前記車々間通信転送サービス処理部を経由して前記送受信サービス処理部に与え、前記受信側の前記車載通信装置の前記送受信サービス処理部は、前記送信側の前記車載通信装置から受信した前記メッセージに付与された前記識別子に基づき、前記メッセージを、路車間－車々間通信連携サービス処理部または車々間通信転送サービス処理部に送信する。
　本発明に係る請求項１記載の車載通信装置によれば、既存の路車間通信プロトコルであるトランザクション管理部および転送サービス処理部に、車々間通信転送サービス処理部および車々間通信管理サービス処理部を備えることにより、路車間通信システムを提供する車載器と車々間通信システムを提供する車載器を共用化した車載通信装置を得ることができ、路車間通信システムと車々間通信システムの両方にサービスを提供することが可能となる。また、車々間通信転送サービス処理部と、車々間通信管理サービス処理部によって、アプリケーションごとの優先度が提供され、優先度制御が可能となるので、通信遅延の短縮が可能となる。また、当該車載通信装置により路車間－車々間通信連携システムを構成することで、上述したサービスが可能なシステムを得ることができる。
　本発明に係る請求項８記載の車載通信装置によれば、路車間－車々間通信連携サービス処理部を備えることによって、路車間通信のデータは車々間通信転送サービス処理部を経由せずに送信でき、車々間通信のデータは車々間通信転送サービス処理部を経由して、必要な制御を行って相手に送信することができる。また、当該車載通信装置により路車間－車々間通信連携システムを構成することで、上述したサービスが可能なシステムを得ることができる。
本発明に係る実施の形態１に係る車載通信装置および路車間－車々間通信連携システムの構成の概略を示す図である。 本発明に係る実施の形態１の車載通信装置および路車間－車々間通信連携システムの構成の詳細を示す図である。 本発明に係る実施の形態１の車載通信装置および路車間－車々間通信連携システムの車々間通信アーキテクチャのプロトコル構成を示す図である。 本発明に係る実施の形態１のデータ転送サービスにおけるアプリケーションデータ転送手順の一例を示す図である。 本発明に係る実施の形態１のデータ転送サービスにおける制御データ転送手順の一例を示す図である。 本発明に係る実施の形態１のイベント通知サービスの一例を示す図である。 本発明に係る実施の形態１の優先度制御サービスの一例を示す図である。 本発明に係る実施の形態１の優先度制御サービスのシステム構成の一例を示す図である。 本発明に係る実施の形態１の輻輳制御サービスの送信周期制御の一例を示す図である。 本発明に係る実施の形態１の輻輳制御サービスの送信電力制御の一例を示す図である。 本発明に係る実施の形態１の輻輳制御サービスの受信感度制御の一例を示す図である。 本発明に係る実施の形態１の接続管理サービスの接続問い合わせの一例を示す図である。 本発明に係る実施の形態１の接続管理サービスの接続切断通知の一例を示す図である。 本発明に係る実施の形態１のデータ再送の一例を示す図である。 本発明に係る実施の形態１の重複受信チェックの一例を示す図である。 本発明に係る実施の形態１のプリミティブ種別を示す図である。 本発明に係る実施の形態１のパラメータ種別を示す図である。 本発明に係る実施の形態１のプリミティブ一覧を示す図である。 本発明に係る実施の形態１のプロトコルスタック上でのサービスインタフェースを示す図である。 本発明に係る実施の形態１のＡＣＭＬ-Connectionプリミティブの引数を示す図である。 本発明に係る実施の形態１のＡＣＭＬ-Notifyプリミティブの引数を示す図である。 本発明に係る実施の形態１のＡＣＭＬ-Registrationプリミティブの引数を示す図である。 本発明に係る実施の形態１のＡＣＭＬ-Deregistrationプリミティブの引数を示す図である。 本発明に係る実施の形態１のＡＣＭＬ-Getプリミティブの引数を示す図である。 本発明に係る実施の形態１のＡＣＭＬ-Setプリミティブの引数を示す図である。 本発明に係る実施の形態１のsendDataプリミティブの引数を示す図である。 本発明に係る実施の形態１のeventReportの引数を示す図である。 本発明に係る実施の形態１のＣＭＣＴＬ-sendDataプリミティブの引数を示す図である。 本発明に係る実施の形態１のＣＭＣＴＬ-eventReportプリミティブの引数を示す図である。 本発明に係る実施の形態１のＣＭＣＴＬ-Getプリミティブの引数を示す図である。 本発明に係る実施の形態１のＣＭＣＴＬ-Setプリミティブの引数を示す図である。 本発明に係る実施の形態１のＭＬＭＥ-Setプリミティブの引数を示す図である。 本発明に係る実施の形態１のＭＬＭＥ-Getプリミティブの引数を示す図である。 本発明に係る実施の形態１のＰＬＭＥ-Setプリミティブの引数を示す図である。 本発明に係る実施の形態１のＰＬＭＥ-Getプリミティブの引数を示す図である。 本発明に係る実施の形態１のアプリケーションデータのＰＤＵの関係を示す図である。 本発明に係る実施の形態１の制御データのＰＤＵの関係を示す図である。 本発明に係る実施の形態１のＣ２Ｃヘッダ情報を示す図である。 本発明に係る実施の形態１のＰＤＵ識別子を示す図である。 本発明に係る実施の形態１のBeacon ＰＤＵを示す図である。 本発明に係る実施の形態１のConnect Request ＰＤＵを示す図である。 本発明に係る実施の形態１のConnect Response ＰＤＵを示す図である。 本発明に係る実施の形態１のResult Codeの一覧を示す図である。 本発明に係る実施の形態１のAck PDUを示す図である。 本発明に係る実施の形態１のCongestion Control ＰＤＵを示す図である。 本発明に係る実施の形態１のEvent ＰＤＵを示す図である。 本発明に係る実施の形態１のEvent Codeの一覧を示す図である。 本発明に係る実施の形態１のデータ転送サービスのアプリケーションデータ送受信手順の一例を示す図である。 本発明に係る実施の形態１のデータ転送サービスの制御データ送受信手順の一例を示す図である。 本発明に係る実施の形態１の輻輳制御サービスの手順の一例を示す図である。 本発明に係る実施の形態１のBeacon ＰＤＵを利用した初期接続手順の一例を示す図である。 本発明に係る実施の形態１の初期接続手順のBeacon ＰＤＵ破棄の一例を示す図である。 本発明に係る実施の形態１の同報アプリケーションを利用した初期接続手順の一例を示す図である。 本発明に係る実施の形態１の初期接続手順の接続が無効な場合の手順の一例を示す図である。 本発明に係る実施の形態１の接続状態を通知する手順を示す図である。 本発明に係る実施の形態１のアプリケーションの登録／削除手順を示す図である。 本発明に係る実施の形態１の再送処理が有効な場合のデータ転送手順（基本シーケンス）を示す図である。 本発明に係る実施の形態１の再送処理手順の一例を示す図である。 本発明に係る実施の形態１の再送処理における重複チェック手順の一例を示す図である。 本発明に係る実施の形態１の車々間通信転送サービス処理部のデータ転送サービス処理部の処理手順を示すフローチャートである。 本発明に係る実施の形態１の車々間通信転送サービス処理部のイベント通知サービス処理部の処理手順を示すフローチャートである。 本発明に係る実施の形態１の車々間通信転送サービス処理部の優先度制御サービス処理部の処理手順を示すフローチャートである。 本発明に係る実施の形態１の車々間通信管理サービス処理部の輻輳制御サービス処理部の処理手順を示すフローチャートである。 本発明に係る実施の形態１の車々間通信管理サービス処理部の接続管理サービス処理部の初期接続手順の決定手順を示すフローチャートである。 本発明に係る実施の形態１の車々間通信管理サービス処理部の接続管理サービス処理部のビーコンを用いた初期接続手順を示すフローチャートである。 本発明に係る実施の形態１の車々間通信管理サービス処理部の接続管理サービス処理部の同報アプリケーションを用いた初期接続手順を示すフローチャートである。 本発明に係る実施の形態１のアプリケーション処理部の処理手順を示すフローチャートである。 本発明に係る実施の形態１のトランザクション管理部の処理手順を示すフローチャートである。 本発明に係る実施の形態１の転送サービス処理部の処理手順を示すフローチャートである。 本発明に係る実施の形態１の送受信サービス処理部の処理手順を示すフローチャートである。 本発明に係る実施の形態２の車載通信装置の構成の概略を示す図である。 本発明に係る実施の形態２の車載通信装置の構成の詳細を示す図である。 本発明に係る実施の形態３の車載通信装置の構成の詳細を示す図である。 本発明に係る実施の形態３の路車間通信アプリケーションに付加するＣ２Ｃヘッダ情報を示す図である。 本発明に係る実施の形態４の車載通信装置の構成の概略を示す図である。 本発明に係る実施の形態４のプロトコルスタック上でのサービスインタフェースを示す図である。 本発明に係る実施の形態４と実施の形態１とのプリミティブの相違点一覧を示す図である。 本発明に係る実施の形態５の車載通信装置の構成の概略を示す図である。 本発明に係る実施の形態５のプロトコルスタック上でのサービスインタフェースを示す図である。 本発明に係る実施の形態５と実施の形態１とのプリミティブの相違点一覧を示す図である。
　＜Ａ．実施の形態１＞
　＜Ａ－１．プロトコル構成＞
　本発明に係る実施の形態１について、図１～図７０を用いて説明する。なお、実施の形態１に係る車載通信装置および路車間－車々間通信連携システムは、路車間通信システムの車載通信装置としてサービスを提供したり、車々間通信システムの車載通信装置としてサービスを提供したりすることができる。本実施の形態１では、主として車々間通信システムの車載通信装置としてサービスを提供する場合について説明する。
　図１は本発明の実施の形態１に係る車載通信装置１００および路車間－車々間通信連携システムのプロトコル構成を概略的に示すブロック図であり、図２は当該プロトコル構成を詳細に示すブロック図である。なお、図１および図２において、同一または相当する構成には同一の符号を付し、これは明細書の全文において共通する。
　車載通信装置１００は、複数の車両の各々に搭載される。そして、当該車載通信装置１００を通じて、各車両間において無線通信が行われる。ここでの、車載通信装置１００とは自動車に搭載される移動可能な通信端末や基地局のように固定された通信装置を示す。また、無線通信とは、ＤＳＲＣを用いても良いし、無線ＬＡＮ（Local Area Network）や携帯電話など採用されるプロトコルを用いた通信でも良い。
　また、本願明細書においては、車載通信装置１００が搭載された「自車両」（第１の車両）と称す１の車両に注目して説明するものとし、当該「自車両」以外で車載通信装置１００を搭載した複数の車両を、「周辺車両」（第２の車両）と称する。
　図１に示すように、車載通信装置１００は、車々間通信転送サービス処理部１と、車々間通信管理サービス処理部２と、アプリケーション処理部３と、トランザクション管理部４と、転送サービス処理部５と、送受信サービス処理部６と、送受信サービス管理部７とを有する。
　ここで、本実施の形態１においては、車々間通信転送サービス処理部１と、車々間通信管理サービス処理部２とを総称して、車々間通信サブプロトコルと呼ぶ。
　車々間通信転送サービス処理部１（以下、車々間通信トランスポートサブレイヤとも呼称）は、転送サービス処理部５と送受信サービス処理部６との間に介在し、アプリケーション処理部３のアプリケーションの優先度を車々間通信管理サービス処理部２から取得し、優先度に応じて送信する順番を制御する優先度制御サービスを提供する。さらに、転送サービス処理部５や車々間通信管理サービス処理部２などに対して、メッセージを送受信するデータ転送サービスやエラーなどを通知するイベント通知サービスを提供する。
　また、送受信されるデータ（ＰＤＵ：Protocol Data Unit）に送信周期や送信電力などの通信制御情報を付加することによって、輻輳制御に利用するための情報を周辺車両の車々間通信転送サービス処理部１に通知することができる。
　車々間通信管理サービス処理部２（以下、車々間通信マネジメントレイヤとも呼称）は、アプリケーション処理部３、トランザクション管理部４、転送サービス処理部５、車々間通信転送サービス処理部１および送受信サービス管理部７に対して平行するように配置され、アプリケーション処理部３の有する車両の位置情報や速度情報などの車両情報と、送受信サービス管理部７の有する通信チャネルの利用率情報とを利用して、情報の輻輳を回避するための輻輳制御サービスを提供する。
　ここで、車両情報とは車両の速度、加減速度、位置、走行方向およびウィンカーのＯＮ／ＯＦＦ情報などである。
　さらに、車々間通信管理サービス処理部２は、相手局の車々間通信管理サービス処理部２と接続するために、初期接続の接続手順や切断手順を提供し、通信状況を管理する通信接続管理サービスを提供する。
　また、車々間通信管理サービス処理部２は、輻輳制御サービスに利用する送信周期や通信接続管理サービスの通信状況をアプリケーション処理部３に通知するために、アプリケーション処理部３との間にインタフェース（第３のインタフェース）を有する。さらに、車々間通信管理サービス処理部２は、輻輳制御サービスに利用する送信電力、受信感度、および送信チャネルの情報を設定するためや、通信チャネル利用率の情報を取得するために送受信サービス管理部７との間にもインタフェース（第１のインタフェース）を有する。
　また、車々間通信管理サービス処理部２は、送信するデータに付加する通信制御情報の取得や、受信したデータに付加された通信制御情報の設定、および制御データを相手局の車々間通信管理サービス処理部２への送信のために、車々間通信転送サービス処理部１とのインタフェース（第２のインタフェース）も有する。さらに、車々間通信管理サービス処理部２は、相手局に送信する制御データの再送制御サービスも提供する。
　アプリケーション処理部３（以下、アプリケーションとも呼称）は、トランザクション管理部４上で動作する車々間通信アプリケーションを備えている。ここで、アプリケーション処理部３は、車々間通信アプリケーション以外にも、路車間通信システムのアプリケーションまたはＩＴＳ（Intelligent Transport Systems）に関するアプリケーション以外のアプリケーションなどを含んでも良い。
　トランザクション管理部４（以下、ローカルポートプロトコルとも呼称）は、アプリケーション処理部３と転送サービス処理部５との間に介在し、転送サービス処理部５の機能を拡張する通信プロトコルである。トランザクション管理部４は、メッセージの再送や分割／組み立てなどのトランザクションサービス、および通信接続、切断などの通信状況を管理する接続管理サービスを提供する。
　転送サービス処理部５（以下、ローカルポート制御プロトコルとも呼称）は、トランザクション管理部４と車々間通信転送サービス処理部１との間に介在し、アプリケーションの多重化を実現するための制御プロトコルである。転送サービス処理部５は、マルチアプリケーションを実現するために、上位プロトコルをローカルポート番号によって識別し、上位プロトコルに対してデータ転送とイベント通知などの管理サービスのためのサービスプリミティブ（インタフェース）を有する。
　送受信サービス処理部６（以下、物理層およびデータリンク層ともいう）は、周辺局に搭載された車載通信装置１００との無線通信を行うために、送信サービスおよび受信サービスを提供する。
　送受信サービス管理部７（以下、物理層管理部あるいはデータリンク層管理部とも呼称）は、送受信サービス処理部６の管理や、情報の格納のために、通信制御情報が格納される管理情報ベース（ＭＩＢ：Management Information Base）を備えている。
　次に、図２を用いて車載通信装置１００の構成についてさらに説明する。
  ＜車々間通信転送サービス処理部１＞
　車々間通信転送サービス処理部１は、データ転送サービス処理部１１と、イベント通知サービス処理部１２と、優先度制御サービス処理部１３とを有している。
　データ転送サービス処理部１１は、アプリケーション処理部３などの上位プロトコルの要求に応じて、メッセージを送信するデータ転送サービスを提供する。また、送受信されるデータ（ＰＤＵ）に送信周期や送信電力などの通信制御情報を付加することによって、輻輳制御に利用するための情報を周辺車両の車々間通信転送サービス処理部１に通知することができる。車々間通信転送サービス処理部１は、通信制御情報を車々間通信管理サービス処理部２の管理情報格納部２４より取得する。さらに、車々間通信転送サービス処理部１は、転送サービス処理部５に対して、データ転送を行うためのインタフェースを有する。
　イベント通知サービス処理部１２は、車々間通信転送サービス処理部１内で発生したエラーやイベントを上位プロトコルに通知したり、車々間通信管理サービス処理部２や下位プロトコルで発生したエラーおよびイベントを上位プロトコルに透過的に通知したりする。さらに、車々間通信転送サービス処理部１は、転送サービス処理部５に対して、イベント通知を行うためのインタフェースを有する。
　優先度制御サービス処理部１３は、アプリケーション処理部３などの上位プロトコルが送信を要求するメッセージの優先度に応じて、送信する順序を制御する。車々間通信転送サービス処理部１は、アプリケーションの優先度を車々間通信管理サービス処理部２の管理情報格納部２４より取得する。また、車々間通信転送サービス処理部１は、優先度に応じた送信制御を実現するために車々間通信管理サービス処理部２に対して、インタフェースを有する。
　　＜車々間通信管理サービス処理部２＞
　車々間通信管理サービス処理部２は、輻輳制御サービス処理部２１と、接続管理サービス処理部２２と、再送制御サービス処理部２３と、管理情報格納部２４とを有している。
　輻輳制御サービス処理部２１は、アプリケーション処理部３に対して、通信の信頼性を向上させるために、送信周期や送信電力、および受信感度を制御する輻輳制御サービスを提供する。輻輳制御サービス処理部２１は、輻輳制御サービスで利用する自局や相手局の車両情報をアプリケーション処理部３から取得し、自局の通信チャネル利用率や送信電力などの通信制御情報を、送受信サービス管理部７の通信制御情報格納部７１から取得する。また、周辺局の通信チャネル利用率や送信電力などの通信制御情報は管理情報格納部２４より取得する。車々間通信管理サービス処理部２は、アプリケーション処理部３および送受信サービス管理部７に対して輻輳制御サービスを行うためのインタフェースを有する。
　そして、輻輳制御サービス処理部２１は、送信周期制御処理部２１１と、送信電力制御処理部２１２と、受信感度制御処理部２１３とを有している。
　送信周期制御処理部２１１は、周期的にメッセージを送信するアプリケーション処理部３に対して、輻輳を回避するための送信周期を算出し、通知する。これにより、この車載通信装置のアプリケーション処理部３は、輻輳制御サービス処理部２１から通知された送信周期に従ってメッセージを周期的に送信するため、送信トラフィックを増減させることができる。
　送信電力制御処理部２１２は、送受信サービス管理部７に対して、輻輳を回避するための送信電力を算出し、通知する。これにより、この車載通信装置の送受信サービス管理部７は、送信電力制御処理部２１２から通知された送信電力に従ってメッセージを受信する電力の閾値を設定するため、送信するエリアを拡大したり、縮小したりさせることができる。
　受信感度制御処理部２１３は、送受信サービス管理部７に対して、輻輳を回避するための受信感度を算出し、通知する。これにより、この車載通信装置の送受信サービス管理部７は、受信感度制御処理部２１３から通知された受信感度に従ってメッセージを受信する電力の閾値を設定するため、受信できるエリアを拡大したり、縮小したりさせることができる。
　接続管理サービス処理部２２は、アプリケーション処理部３の要求に応じて、周辺局との初期接続を開始するための制御メッセージを送信する。また、接続管理サービス処理部２２は、周辺局との通信状況の管理およびアプリケーション処理部３への通知を行う。さらに、接続管理サービス処理部２２は、周期的にメッセージを送信するアプリケーション処理部３が動作しているかどうかで、初期接続手順を使い分け、効率的な接続管理サービスを提供する。
　再送制御サービス処理部２３は、接続管理サービスを提供するための制御メッセージに対して、相手局に到達しなかったメッセージの再送を行う。これにより、車々間通信管理サービス処理部２は、トランザクション管理部４がサポートできない車々間通信管理サービス処理部２の制御メッセージに対しても再送制御が可能となる。
　管理情報格納部２４は、輻輳制御サービスで利用する送信周期や送信電力などの通信制御情報や、接続管理サービスで利用する自局や周辺局の車両情報などを格納する。また、管理情報格納部２４は、車々間通信転送サービス処理部１が送受信するデータ（ＰＤＵ）に含まれる送信周期および送信電力などの通信制御情報を格納する。さらに、管理情報格納部２４は、アプリケーション処理部３から登録／削除される提供可能なアプリケーションの情報を格納する。
　　＜アプリケーション処理部３＞
　アプリケーション処理部３は、車々間通信アプリケーション部３１を有している。
  車々間通信アプリケーション部３１は、周期的に自車両の車両情報を同報送信するアプリケーション、ブレーキやウィンカーなどの動作時に自車両の車両情報を同報送信するアプリケーション、およびその他にドライバーの快適性や利便性を高めるアプリケーションなどを含んでいる。
　　＜トランザクション管理部４＞
　トランザクション管理部４は、トランザクションサービス処理部４１と、ＬＰＰ接続管理サービス処理部４２とを有している。
　トランザクションサービス処理部４１は、相手局に到達しなかったメッセージの再送や、メッセージの分割／組み立てなどのトランザクションサービスを提供する。これにより、車々間通信システムに要求される再送制御や分割／組み立て制御を提供する。また、相手局へのメッセージの送信や、送信したメッセージに対して相手局からの応答を要求するトランザクションサービスを提供する。さらに、トランザクションサービス処理部４１は、アプリケーション処理部３から送信されたメッセージを連続して送信する連送制御サービスを提供する。これにより、この車載通信通信装置は、相手局に対してメッセージが到着する確率を高くすることができる。
　ＬＰＰ接続管理サービス処理部４２は、アプリケーション処理部３からの要求に応じての接続状況の報告、新規接続や切断の通知、相手局が有する受信可能なポート番号の管理、およびあるポートが受信可能になったことをアプリケーション処理部３への通知などの接続管理サービスを提供する。
　　＜転送サービス処理部５＞
　転送サービス処理部５は、ＬＰＣＰ（Local Port Control Protocol）転送サービス処理部５１と、管理サービス処理部５２とを有している。
　ＬＰＣＰ転送サービス処理部５１は、アプリケーション処理部３などの上位プロトコルを、ローカルポート番号と呼ぶ識別子を用いて、送信元および送信先のアプリケーション処理部３を識別する。また、転送サービス処理部５は、上位プロトコルであるアプリケーション処理部３およびトランザクション管理部４に対して、データ転送を行うためのインタフェースを有する。これにより、この車載通信通信装置は、マルチアプリケーションを実現することができる。
　管理サービス処理部５２は、上位プロトコルに対して、転送サービス処理部５内で発生したエラーやイベントを相手局や自局に通知する管理サービスを提供する。また、管理サービス処理部５２は、車々間通信転送サービス処理部１などの下位プロトコルから通知されるエラーやイベントを自局のアプリケーション処理部３に対して透過的に通知するサービスを提供する。また、転送サービス処理部５は、トランザクション管理部４に対して、イベント通知サービスを提供するためのインタフェースを有する。
　　＜送受信サービス処理部６＞
　送受信サービス処理部６は、送信サービス処理部６１と、受信サービス処理部６２とを有している。
　送信サービス処理部６１は、車々間通信転送サービス処理部１から送信されたデータを、周辺車両にブロードキャスト送信または特定車両にユニキャスト送信する。また、送信サービス処理部６１は、送信電力を切り替えることができ、送信する際の送信電力を通信制御情報格納部７１より取得する。また、送信サービス処理部６１は、送信する通信チャネルを切り替えることができ、例えば、車々間通信管理サービス処理部２からの情報を制御チャネルに送信し、アプリケーション処理部３からの情報をデータチャネルに送信することができる。
　受信サービス処理部６２は、周辺車両から送信された情報を受信し、受信した情報を車々間通信転送サービス処理部１に送信する。また、受信サービス処理部６２は、受信感度を切り替えることができ、受信感度を通信制御情報格納部７１より取得する。さらに、受信サービス処理部６２は、通信チャネル上において一定値以上の電波強度を受信した場合をビジーと判定し、所定時間通信チャネルを観測する。そして、受信サービス処理部６２は、その所定時間のビジーの割合を通信チャネルの利用率として計測し、通信制御情報格納部７１に格納する。
　　＜送受信サービス管理部７＞
　送受信サービス管理部７は、通信制御情報格納部７１を有している。
  通信制御情報格納部７１は、周辺局に搭載された車載通信装置１００との無線通信を行うための送信電力や受信感度などの情報を格納する。また、通信制御情報格納部７１は、受信サービス処理部６２が測定した通信チャネル利用率などの情報を格納する。さらに、通信制御情報格納部７１は、送信電力や受信感度を、車々間通信管理サービス処理部２の輻輳制御サービス処理部２１により、輻輳を回避するための値に設定する。
　＜Ａ－２．プロトコル仕様＞
　以下では、本発明に係る車載通信装置および路車間－車々間通信連携システムにおける車々間通信転送サービス処理部１と、車々間通信管理サービス処理部２とで構成される車々間通信サブプロトコルの仕様について詳細に説明する。
　　＜１．車々間通信サブプロトコルの概要＞
　車々間通信サブプロトコル（Car-To-Car Sub Protocol）は、車々間通信トランスポートサブレイヤ（Ｃ２Ｃ Transport Sub Layer：ＣＴＬ）と車々間通信マネジメントレイヤ（Ｃ２Ｃ Management Layer：ＣＭＬ）とで構成される。車々間通信アーキテクチャのプロトコル構成を図３に示す。
　車々間通信トランスポートサブレイヤ（ＣＴＬ）は、ローカルポート制御プロトコル（Local Port Control Protocol：ＬＰＣＰ）と通信下位プロトコルとの間に介在し、車々間通信システムのアプリケーションに対して優先度制御を提供し、車々間通信マネジメントレイヤ（ＣＭＬ）の機能を補完する。また、上位プロトコル（以下、Upper Layerとも呼称）またはＣＭＬに対してメッセージを転送するイベント転送サービスおよびＣＴＬ内で発生したエラーおよびイベントなどを上位プロトコルに通知するイベント通知サービスを提供する。
　車々間通信マネジメントレイヤ（ＣＭＬ）は、アプリケーションまたはＣＴＬに対して、通信の信頼性を向上させるために送信周期、送信電力、受信感度および送信チャネルを制御する輻輳制御サービスと、初期接続の開始や切断を行ったり、通信状況を管理したりする接続管理サービスを提供する。また、ＣＭＬは通信下位プロトコルの管理層の機能を拡張する。さらに、ＣＭＬは初期接続を行うための制御メッセージの信頼性を向上させるためにデータ再送サービスを提供する。
　ローカルポートプロトコル（Local Port Protocol：ＬＰＰ）は、データの再送や分割／組み立てなどのトランザクションサービス、および初期接続や切断などの通信状況を管理する接続管理サービスを提供する。これにより、ＬＰＰは、車々間通信システムに要求される再送制御や分割／組み立て制御を実現する。
　ＬＰＣＰは、アプリケーション処理部３などの上位プロトコルをローカルポート番号を用いて識別し、上位プロトコルに対してデータ転送やイベント通知などの管理サービスのためのインタフェースを有する。これにより、ＬＰＣＰは、車々間通信システムにおいてマルチアプリケーションを実現する。
　また、通信下位プロトコルとしては、ＩＥＥＥ８０２．１１ｐプロトコルおよび５．８ＧＨｚ帯やＵＨＦ／ＶＨＦ帯の通信プロトコルなどを想定している。さらに、通信下位プロトコルは、通信下位プロトコルの情報を格納する管理層を有する。
　通信下位プロトコルは、データリンク層（Layer2：Ｌ２）と、データリンク層の下位に物理層（Layer1：Ｌ１）と、データリンク層を管理するデータリンク層管理部（Media access control Layer Management Entity：ＭＬＭＥ）と、物理層を管理する物理層管理部（Physical Layer Management Entity：ＰＬＭＥ）とを有する。ここで、通信下位プロトコルとして、例えばＩＥＥＥ８０２．１１ｐプロトコルおよび５．８ＧＨｚ帯やＵＨＦ／ＶＨＦ帯の通信プロトコルを用いても良いし、それ以外の通信プロトコルを用いても良い。また、特に図示していないがＭＬＭＥおよびＰＬＭＥは、管理情報が格納される管理情報ベース（ＭＩＢ：Management Information Base）を備えている。
　データリンク層は、ＯＳＩ（Open Systems Interconnection）参照モデルの第２層であり、アクセス方式について規定される。物理層は、ＯＳＩ参照モデルの第１層であり、物理的に伝送方式について規定される。データリンク層管理部（ＭＬＭＥ）は、データリンク層を管理したり、データリンク層で利用する情報を格納したりする。物理層管理部(ＰＬＭＥ）は、物理層を管理したり、物理層で利用する情報を格納したりする。
　ＣＴＬとＣＭＬが有する機能は以下の通りである。
（１）ＣＴＬが提供するサービス
　（ａ）データ転送サービス
　（ｂ）イベント通知サービス
　（ｃ）優先度制御サービス
（２）ＣＭＬが提供するサービス
　（ａ）輻輳制御サービス
　（ｂ）接続管理サービス
　（ｃ）データ再送サービス
　＜２．機能の概要＞
　２．１　車々間通信トランスポートサブレイヤの機能
　２．１．１　データ転送サービス
　ＣＴＬは、アプリケーションおよびＬＰＰ、ＬＰＣＰなどの上位プロトコルおよびＣＭＬに対して、データ転送サービスを提供する。データ転送サービスの詳細な手順は５．１節で説明する。図４に上位プロトコルに対してデータ転送サービスを提供する例を示し、図５にＣＭＬに対してデータ転送サービスを提供する例を示す。
　２．１．２　イベント通知サービス
　ＣＴＬは、ＣＴＬ内で発生したイベントやエラー、およびＣＭＬから受信したらイベント（通信接続や切断の通知など）を上位プロトコルおよび相手局に通知するためにイベント通知サービスを提供する。図６にイベント通知サービスを提供する例を示す。
　２．１．３　優先度制御サービス
　ＣＴＬは、上位プロトコルおよびＣＭＬのデータ優先度に応じて送信順を制御する優先度制御サービスを提供する。これにより、緊急度の高いデータを優先的に送信することが可能になる。優先度制御サービスの詳細な手順は５．２節で説明する。図７に優先度制御サービスの例を示す。ただし、優先度制御サービスは通信下位プロトコルで提供される場合にはオプションとして提供される。
　ＣＴＬは、優先度制御サービスでは、優先度ごとにキューを用意し、優先度の高いキューにあるデータを優先的に通信下位プロトコルに渡す。図８に優先度制御サービスを提供するためのキュー構成の例を示す。
　２．２　車々間通信マネジメントレイヤの機能
　２．２．１　輻輳制御サービス
　ＣＭＬは、アプリケーションに対して通信の信頼性を向上させるために、送信周期や送信電力、および受信感度を制御する輻輳制御サービスを提供する。輻輳制御サービスの詳細な手順は５．３節で説明する。輻輳制御サービスは、次のサービスのいずれかを用いても良いし、いくつかを連携して用いても良い。
（１）送信周期制御サービス
　周期的に車両情報などのメッセージを送信するアプリケーションの送信周期をアプリケーションに通知するサービス。
（２）送信電力制御サービス
　アプリケーションに必要な通信エリアを確保したり、輻輳を回避するために通信エリアを絞ったりするために送信電力を制御するサービス。
（３）受信感度制御サービス
　アプリケーションに必要な通信エリアを限定するために受信感度を制御するサービス。
　２．２．１．１　送信周期制御サービス
　ＣＭＬは、送信周期制御サービスは、周期的に車両情報などのメッセージを送信するアプリケーションに対して、輻輳を回避するために設定される送信周期を通知する。
　ＣＭＬは、送信周期制御サービスでは、ＣＭＬの有する自車両の情報および周辺車両の情報と、自車両の検出するチャネル利用率情報および周辺車両の検出するチャネル利用率情報を利用して送信周期を算出する。これにより、この車載通信装置は、周辺車両との危険な状況や通信環境の混雑状況に応じて送信周期を制御することが可能になる。
　ＣＭＬは、送信周期を算出した後、周期的に情報の送信を行うアプリケーションに対して送信周期の変更を通知する。送信周期を通知されたアプリケーションは、通知を受信した後は通知された送信周期ごとにメッセージの送信を開始する。図９に送信周期制御サービスの例を示す。
　２．２．１．２　送信電力制御サービス
　ＣＭＬは、送信電力制御サービスでは、通信下位プロトコルの管理層に対して、アプリケーションに必要とされる通信エリアを確保したり、輻輳を回避するための通信エリアに制限したりするために、メッセージを送信する際の送信電力を制御する。
　ＣＭＬは、送信電力制御サービスでは、ＣＭＬの有する自車両の情報および周辺車両の情報と、自車両の検出するチャネル利用率情報および周辺車両の検出するチャネル利用率情報を利用して、通信が必要な車両との通信エリアを確保したり、不必要なエリアに電波を送信することを回避したりする送信電力を算出する。
　ＣＭＬは、送信電力を算出した後、ＰＬＭＥに対して送信電力を通知し、通信下位プロトコルは通知された送信電力に従ってメッセージの送信を行う。図１０に送信電力制御サービスの例を示す。
　２．２．１．３　受信感度制御サービス
　ＣＭＬは、受信感度制御サービスでは、通信下位プロトコルの管理層に対して、アプリケーションに必要とされる通信エリアまたは輻輳を回避するための通信エリアに限定するために、メッセージを受信する際の受信感度を制御する機能を提供する。
　ＣＭＬは、ＣＭＬの有する自車両の情報および周辺車両の情報と、自車両の検出するチャネル利用率情報および周辺車両の検出するチャネル利用率情報を利用して、アプリケーションに必要とされる通信エリアや輻輳を回避するための通信エリアに限定する受信感度を算出する。
　ＣＭＬは、受信感度を算出した後、ＰＬＭＥに対して受信感度を通知し、通信下位プロトコルは通知された受信感度に従ってメッセージの受信を行う。図１１に受信感度制御サービスの例を示す。
　２．２．２　接続管理サービス
　ＣＭＬは、車々間通信システムに必要な通信接続の初期接続を開始したり、接続状態の管理や通知を行ったりする接続管理サービスを提供する。
　ＣＭＬは、接続管理サービスでは、次のサービスをアプリケーションに対して提供することで、アプリケーションに通信の開始や終了のトリガーを提供する。また、接続管理サービス間で提供可能なアプリケーションを通知し合うことで、相手移動局がサポートするアプリケーションを管理し、各アプリケーションの要求に応じてそれらの状況を報告したり、通信可能になったりすることを通知する機能を提供する。
（１）接続問い合わせサービス
　周辺移動局との接続状況を管理および監視を行い、アプリケーションからの要求に応じて接続状況および新規接続・切断を通知するサービス。
（２）接続／切断通知サービス
　ＣＴＬを経由して上位プロトコルに対して接続状況および新規接続／切断を通知するサービス。
（３）時刻同期サービス
　複数の通信チャネルが利用できる場合にチャネルを切り替えるタイミングを同期させるために、時刻を同期するサービス。
　ＣＭＬは、接続管理サービスでは、高速な初期接続を実現するために、周期的にメッセージを送信するアプリケーションのデータ、および周期的に送信するビーコンメッセージを受信した場合に、相手移動局との初期接続を開始する。
　２．２．２．１　接続問い合わせサービス
　接続問い合わせサービスは、アプリケーションが車々間通信の接続が確立しているかどうかを問い合わせるサービスである。接続問い合わせサービスは、問い合わせする際に、車々間通信の接続状況を即座に回答を行う参照サービスと、接続が確立していない場合に接続するまで待機し接続した時点で通知を行う通知サービスの２種類のサービスを規定する。図１２に接続問い合わせサービスの例を示す。
　２．２．２．２　接続／切断通知サービス
　接続／切断通知サービスは、アプリケーションおよびＣＴＬに対して、通信接続の通知および切断の通知を行うサービスである。図１３に接続／切断通知サービスの例を示す。
　２．２．２．３　時刻同期サービス
　ＣＭＬは、車々間通信プロトコルが複数の通信チャネルをサポートしている場合、通信チャネルを切り替えるタイミングを統一するために時刻同期サービスを提供する。
　ＣＭＬは、時刻同期サービスでは、複数あるチャネルのうち一つを制御チャネルと定義し、制御チャネル上に周期的にビーコンメッセージを送信する。ビーコンメッセージによって、時刻同期を取ると同時に相手局のサポートするアプリケーション情報を把握することも可能である。
　２．２．３　データ再送サービス
　ＣＭＬは、制御メッセージに対して、通信の信頼性を確保するためにデータ再送サービスを提供する。ＣＭＬは、データ再送サービスでは、再送タイマと再送カウンタにより再送の制御を行い、再送タイマがタイムアウト時に再送を行う。図１４にデータ再送サービスの例を示し、図１５にデータ再送サービスの重複チェックの例を示す。
  データ再送サービスの再送処理手順の概要を以下に示す。
（１）制御メッセージ送信する際に、再送タイマをスタートし、再送カウンタを０にセットする。
（２）再送タイマのタイムアウトまでに、相手移動局から応答のメッセージを受信できなかった場合には再送カウンタを１インクリメントし、メッセージを再送すると同時に再送タイマをリスタートする。
（３）再送カウンタが最大再送回数を超えた場合には、メッセージ再送を中止する。
　　＜３．サービスインタフェース（Service Access Point：ＳＡＰ）＞
　次に、ＣＴＬおよびＣＭＬが有するインタフェースについて説明する。
  ３．１　記法の説明
　本発明で規定されるプリミティブ種別の一覧を図１６に示す。また、本発明でのプリミティブの定義テーブルで用いられるパラメータ種別の一覧を図１７に示す。
　３．２　サービスインタフェース一覧
　ＣＴＬおよびＣＭＬが有するサービスインタフェースの一覧を図１８に示す。また、車々間通信プロトコルスタックにおけるＳＡＰの位置を図１９に示す。
　３．３　アプリケーションとＣＭＬとのＳＡＰ（ＡＣＭＬ ＳＡＰ）
　輻輳制御サービスおよび接続管理サービスとして、ＣＭＬはアプリケーションに対して、以下の６種類のプリミティブを提供する。
（１）接続開始プリミティブ（ＡＣＭＬ-Connection）
（２）アプリケーション通知プリミティブ（ＡＣＭＬ-Notify）
（３）アプリケーション情報登録プリミティブ（ＡＣＭＬ-Registration）
（４）アプリケーション情報削除プリミティブ（ＡＣＭＬ-Deregistration）
（５）ＣＭＬ情報取得プリミティブ（ＡＣＭＬ-Get）
（６）ＣＭＬ情報設定プリミティブ（ＡＣＭＬ-Set）
　３．３．１　接続開始プリミティブ（ＡＣＭＬ-Connection）
　（１）処理概要
　ＡＣＭＬ-Connectionプリミティブは、アプリケーションが周辺局との接続を要求したり、接続状態を問い合わせたり、ビーコンメッセージの送信を要求したりするプリミティブである。個別通信を行うアプリケーションは、ＡＣＭＬ-Connectionプリミティブの発行により開始される。
  （２）定義
　図２０は、ＡＣＭＬ-Connectionプリミティブの引数を示す図である。
  portNo：要求元アプリケーションを識別するための識別子である。
  serviceType：接続問い合わせサービスのタイプを示す識別子である。「０」の場合は接続状況を即座に回答を行う参照サービスを示し、「１」の場合は接続した時点で通知を行う通知サービスを示す。
  connectionFlag：アプリケーションが相手局との接続を行うかを示すフラグである。「０」の場合は相手局との接続を行わないことを示し、「１」の場合は相手局と接続を行うことを示す。
  destinationLID：接続要求などを行う相手局を示す識別子である。
  connectStatus：接続状態を示す識別子である。「０」の場合は未接続の状態を示し、「１」の場合は接続済みの状態を示す。
  beaconFlag：ビーコンメッセージの送信を要求するかを示すフラグである。「０」の場合はビーコンメッセージの送信を要求しないことを示し、「１」の場合はビーコンメッセージの送信を要求することを示す。
　３．３．２　アプリケーション通知プリミティブ（ＡＣＭＬ-Notify）
　（１）処理概要
　ＡＣＭＬ-Notifyプリミティブは、ＣＭＬがアプリケーションに対して、送信周期の変更などを通知したり、アプリケーションがＣＭＬに対して輻輳制御メッセージの送信を要求したりするプリミティブである。送信周期の変更は、周期的に送信を行うアプリケーションに対して発行される。また、ＡＣＭＬ-Notifyプリミティブは、上記以外にもアプリケーションに情報を通知したり、ＣＭＬに処理を要求したりする場合に利用する。
  （２）定義
　図２１は、ＡＣＭＬ-Notifyプリミティブの引数を示す図である。
  portNo：要求元アプリケーションを識別するための識別子である。
  notifyCode：アプリケーションに通知する内容を示す識別子である。
  notifyParameter：アプリケーションに通知する内容のパラメータ値である。
　３．３．３　アプリケーション情報登録プリミティブ（ＡＣＭＬ-Registration）
　（１）処理概要
　ＡＣＭＬ-Registrationプリミティブは、アプリケーションがＣＭＬに対して、アプリケーション情報を登録するためのプリミティブである。
  （２）定義
　図２２は、ＡＣＭＬ-Registrationプリミティブの引数を示す図である。
  portNo：登録を要求するアプリケーションを識別するための識別子である。
  priority：アプリケーションの優先度を示す識別子である。
  applicationType：アプリケーションの種類（路車間／車々間／その他）を示す識別子である。
  resultCode：登録結果を示す識別子である。
　３．３．４　アプリケーション情報削除プリミティブ（ＡＣＭＬ-Deregistration）
　（１）処理概要
　ＡＣＭＬ-Deregistrationプリミティブは、アプリケーションがＣＭＬに対して、アプリケーション情報を削除するためのプリミティブである。
　（２）定義
　図２３は、ＡＣＭＬ-Deregistrationプリミティブの引数を示す図である。
  portNo：削除を要求するアプリケーションを識別するための識別子である。
  resultCode：削除結果を示す識別子である。
　３．３．５　ＣＭＬ情報取得プリミティブ（ＡＣＭＬ-Get）
　（１）処理概要
　ＡＣＭＬ-Getプリミティブは、アプリケーションがＣＭＬの変数を取得するためのプリミティブである。
  （２）定義
　図２４は、ＡＣＭＬ-Getプリミティブの引数を示す図である。
  mibIndex：取得を要求する変数を指示する識別子である。
  mibStatus：要求を実行した結果を示す識別子である。
  mibParameter：取得した変数の内容である。
　３．３．６　ＣＭＬ情報設定プリミティブ（ＡＣＭＬ-Set）
　（１）処理概要
　ＡＣＭＬ-Setプリミティブは、アプリケーションがＣＭＬの変数を設定するためのプリミティブである。
  （２）定義
　図２５は、ＡＣＭＬ-Setプリミティブの引数を示す図である。
  mibIndex：設定を要求する変数を指示する識別子である。
  mibStatus：要求を実行した結果を示す識別子である。
  mibParameter：設定する変数の内容である。
　３．４　ＣＴＬと上位プロトコルとのＳＡＰ（ＡＣＴＬ ＳＡＰ）
　データ転送サービスおよびイベント通知サービスとして、ＣＴＬは上位プロトコルに対して、以下の２種類のプリミティブを提供する。
  （１）アプリケーションデータ転送プリミティブ（sendData）
　（２）イベント通知プリミティブ（eventReport）
　３．４．１　アプリケーションデータ転送プリミティブ（sendData）
　（１）処理概要
　sendDataプリミティブは、上位プロトコルがＣＴＬに対して、アプリケーションデータの送受信を行うためのプリミティブである。
  （２）定義
　図２６は、sendDataプリミティブの引数を示す図である。
  linkAddress：車々間通信で利用するリンクアドレスであり、通信する相手局を識別するために用いる識別子である。
  parameter：上位プロトコルとやり取りするデータ本体を示す。
　３．４．２　イベント通知プリミティブ（eventReport）
　（１）処理概要
　eventReportプリミティブは、ＣＴＬが上位プロトコルに対して、ＣＴＬ内で発生したエラーなどの事象を通知するためのプリミティブである。
  （２）定義
　図２７は、eventReportプリミティブの引数を示す図である。
  linkAddress：車々間通信で利用するリンクアドレスであり、通信する相手局を識別するために用いる識別子である。
  eventCode：発生したイベントやエラーを示すコードを表す識別子である。
  extensionParameter：変数eventCodeの内容を補足するためのパラメータを示す。
　３．５　ＣＴＬとＣＭＬとのＳＡＰ（ＣＭＣＴＬ ＳＡＰ）
　データ転送サービスおよびイベント通知サービスとして、ＣＴＬはＣＭＬに対して、以下の４種類のプリミティブを提供する。
  （１）制御データ転送プリミティブ（ＣＭＣＴＬ-SendData）
　（２）イベント通知プリミティブ（ＣＭＣＴＬ-EventReport）
　（３）ＣＭＬ情報取得プリミティブ（ＣＭＣＴＬ-Get）
　（４）ＣＭＬ情報設定プリミティブ（ＣＭＣＴＬ-Set）
　３．５．１　制御データ転送プリミティブ（ＣＭＣＴＬ-SendData）
　（１）処理概要
　ＣＭＣＴＬ-SendDataプリミティブは、ＣＭＬがＣＴＬに対し、制御メッセージの送信を要求するためのプリミティブである。
  （２）定義
　図２８は、ＣＭＣＴＬ-SendDataプリミティブの引数を示す図である。
  linkAddress：車々間通信で利用するリンクアドレスであり、通信する相手局を識別するために用いる識別子である。
  pduIdentifier：ＣＭＬとやり取りするＰＤＵの種類を示す。
  parameter：ＣＭＬとやり取りするデータ本体を示す。
  priority：送信するデータの優先度を示す。
　３．５．２　イベント通知プリミティブ（ＣＭＣＴＬ-EventReport）
　（１）処理概要
　ＣＭＣＴＬ-EventReportプリミティブは、ＣＭＬがＣＴＬに対し、ＣＭＬ内で発生したエラーなどの事象を通知したり、ＣＴＬがＣＭＬに対し、ＣＴＬ内で発生したイベントなどの事象を通知したりするためのプリミティブである。
  （２）定義
　図２９は、ＣＭＣＴＬ-EventReportプリミティブの引数を示す図である。
  linkAddress：車々間通信で利用するリンクアドレスであり、通信する相手局を識別するために用いる識別子である。
  eventCode：発生したイベントを示すコードを表す識別子である。
  extensionParameter：変数eventCodeの内容を補足するためのパラメータを示す。
　３．５．３　ＣＭＬ情報取得プリミティブ（ＣＭＣＴＬ-Get）
　（１）処理概要
　ＣＭＣＴＬ-Getプリミティブは、ＣＴＬがＣＭＬの変数を取得するためのプリミティブである。
  （２）定義
　図３０は、ＣＭＣＴＬ-Getプリミティブの引数を示す図である。
  mibIndex：取得を要求する変数を指示する識別子である。
  mibStatus：要求を実行した結果を示す識別子である。
  mibParameter：取得した変数の内容である。
　３．５．４　ＣＭＬ情報設定プリミティブ（ＣＭＣＴＬ-Set）
　（１）処理概要
　ＣＭＣＴＬ-Setプリミティブは、ＣＴＬがＣＭＬの変数を設定するためのプリミティブである。
  （２）定義
  図３１は、ＣＭＣＴＬ-Setプリミティブの引数を示す図である。
  mibIndex：設定を要求する変数を指示する識別子である。
  mibStatus：要求を実行した結果を示す識別子である。
  mibParameter：設定する変数の内容である。
　３．６　ＣＭＬとＭＬＭＥとのＳＡＰ（ＭＬＭＥ－ＣＭＬ ＳＡＰ）
　輻輳制御サービスとして、ＣＭＬはＭＬＭＥに対して、以下の２種類のプリミティブを提供する。
  （１）ＭＬＭＥ情報取得プリミティブ（ＭＬＭＥ-Get）
　（２）ＭＬＭＥ情報設定プリミティブ（ＭＬＭＥ-Set）
　３．６．１　ＭＬＭＥ情報取得プリミティブ（ＭＬＭＥ-Get）
　（１）処理概要
　ＭＬＭＥ-Getプリミティブは、ＣＭＬがＭＬＭＥの変数を取得するためのプリミティブである。
  （２）定義
　図３２は、ＭＬＭＥ-Getプリミティブの引数を示す図である。
  mibIndex：取得を要求する変数を指示する識別子である。
  mibStatus：要求を実行した結果を示す識別子である。
  mibParameter：取得した変数の内容である。
　３．６．２　ＭＬＭＥ情報設定プリミティブ（ＭＬＭＥ-Set）
　（１）処理概要
　ＭＬＭＥ-Setプリミティブは、ＣＭＬがＭＬＭＥの変数を設定するためのプリミティブである。
  （２）定義
　図３３は、ＭＬＭＥ-Setプリミティブの引数を示す図である。
  mibIndex：設定を要求する変数を指示する識別子である。
  mibStatus：要求を実行した結果を示す識別子である。
  mibParameter：設定する変数の内容である。
　３．７　ＣＭＬとＰＬＭＥとのＳＡＰ（ＰＬＭＥ－ＣＭＬ ＳＡＰ）
　輻輳制御サービスとして、ＣＭＬはＰＬＭＥに対して、以下の２種類のプリミティブを提供する。
  （１）ＰＬＭＥ情報取得プリミティブ（ＰＬＭＥ-Get）
　（２）ＰＬＭＥ情報設定プリミティブ（ＰＬＭＥ-Set）
　３．７．１　ＰＬＭＥ情報取得プリミティブ（ＰＬＭＥ-Get）
　（１）処理概要
　ＰＬＭＥ-Getプリミティブは、ＣＭＬがＰＬＭＥの変数を取得するためのプリミティブである。
  （２）定義
　図３４は、ＰＬＭＥ-Getプリミティブの引数を示す図である。
  mibIndex：取得を要求する変数を指示する識別子である。
  mibStatus：要求を実行した結果を示す識別子である。
  mibParameter：取得した変数の内容である。
　３．７．２　ＰＬＭＥ情報設定プリミティブ（ＰＬＭＥ-Set）
　（１）処理概要
　ＰＬＭＥ-Setプリミティブは、ＣＭＬがＰＬＭＥの変数を設定するためのプリミティブである。
  （２）定義
  図３５は、ＰＬＭＥ-Setプリミティブの引数を示す図である。
  mibIndex：設定を要求する変数を指示する識別子である。
  mibStatus：要求を実行した結果を示す識別子である。
  mibParameter：設定する変数の内容である。
　　＜４．プロトコルデータ単位（Protocol Data Unit：ＰＤＵ）
　４．１　ＰＤＵの構成
　次に、ＣＴＬおよびＣＭＬで用いられるプロトコルデータユニット（ＰＤＵ）について説明する。図３６にアプリケーションデータを送信する際のＰＤＵ構成について示し、図３７に制御データを送信する際のＰＤＵ構成を示す。ここで、ＰＤＵとＳＤＵ（Service Data Unit）の関係について述べると、あるLayerにおいてヘッダがない状態をＳＤＵと呼び、そのLayerにおいてヘッダを付与した状態をＰＤＵと呼ぶ。
　図３６に示すＰＤＵは、アプリケーションデータに、ＬＰＰヘッダ、ＬＰＣＰヘッダを付加してＣＴＬに渡され、ＣＴＬにおいてＣ２Ｃヘッダを付与され、通信下位プロトコル（Layer2）に渡される。図３７に示すＰＤＵは、ＣＭＬで生成される制御データをＣＴＬに渡され、ＣＴＬにおいてＣ２Ｃヘッダを付与され、通信下位プロトコル（Layer2）に渡される。
　ここで、図３６に示すＰＤＵは、アプリケーションデータがＬＰＰ上でＬＰＰ ＳＤＵとして扱われ、ＬＰＰヘッダを付加されＬＰＰ ＰＤＵとなり、ＬＰＣＰに渡す。渡されたデータはＬＰＣＰ上でＬＰＣＰ ＳＤＵとして扱われ、ＬＰＣＰヘッダを付加されＬＰＣＰ ＰＤＵとなり、ＣＴＬに渡される。ＣＴＬ上では、渡されたデータがＣ２Ｃ ＳＤＵとして扱われ、Ｃ２Ｃヘッダを付加されＣ２Ｃ ＰＤＵとなり、Layer2に渡され、Layer2上ではＭＳＤＵ（ＭＡＣ ＳＤＵ）として扱われる。
　４．２　Ｃ２Ｃヘッダ情報
　図３８はＣＴＬにおいて付与するヘッダであるＣ２Ｃヘッダ情報を示す図である。
  （１）Data Indetifier(データ識別子）
　データの種類を区別する識別子である。「０」はアプリケーションデータ（上位プロトコルのデータ）を示し、「１」は管理データ（ＣＭＬのデータ）を示す。
  ２）ＰＤＵ Identifier（ＰＤＵ識別子）
　ＰＤＵの種類を区別する識別子である。図３９に示すData IdentifierとＰＤＵ Identifierの値を示す。
  （３）Node Priority（車両優先度）
　車両の優先度（危険度）である。ＣＭＬのＣＭＬ変数取得プリミティブにより取得する。
  （４）Channel Occupancy（通信チャネル利用率）
　所定時間内における通信帯域がビジーの割合である。単位は［％］とし、０から１００までの値を設定される。ＣＭＬ変数取得プリミティブにより取得される。
  （５）Cyclic Interval（送信周期）
　周期的に情報を送信するアプリケーションの送信する時間間隔である。単位は［１０msec］とし、１（１０msec）から２５５（２５５０msec）までの値が設定される。ＣＭＬ変数取得プリミティブにより取得される。
  （６）Transmission Power（送信電力）
　Ｃ２Ｃヘッダ生成時に設定されている送信電力の値である。単位は［０．１dBm］とし、－５．０dBmから２０．０dBmまでの値が設定される。ＣＭＬ変数取得プリミティブにより取得される。
  （７）Receiver Sensitivity(受信感度）
　Ｃ２Ｃヘッダ生成時に設定されている受信感度の値を格納する。単位は［１dBm］とし、－１２７dBmから０dBmまでの値を設定する。ＣＭＬ変数取得プリミティブにより取得する。
  （８）Reserved（予約）
　予約領域を確保する。
　４．３　ビーコンメッセージ（Beacon ＰＤＵ）
　初期接続を開始するトリガーとしたり、時刻同期を取ったりするためのビーコンメッセージを送信するＰＤＵである。図４０にビーコンメッセージの形式を示す。
  （１）ＴＳＦ Timer（ＴＳＦタイマ）
　時刻同期を取るためのＴＳＦタイマである。値は０－２64の範囲を取る。
  （２）Next Beacon Transmission Timing（次にビーコンを送信するタイミング）
　ビーコンメッセージを送信する次回のタイミングである。単位は［msec］とし、０－１０００の範囲を取る。
  （３）ＣＭＬ Profile（ＣＭＬプロファイル）
　自局のサポートする機能、アプリケーション情報、チャネル情報、および通信制御情報が格納されるＣＭＬプロファイルである。
　４．４　接続要求メッセージ（Connect Request ＰＤＵ）
　通信接続の要求を行うためのＰＤＵである。図４１に接続要求メッセージの形式を示す。
  （１）Required Ack Flag（再送要求フラグ）
　再送処理が有効かどうかを示すフラグである。「１」の場合はＰＤＵの再送処理が有効となり、メッセージを相手に通知する共に確認応答（Ack ＰＤＵ）を要求する。「０」の場合は再送処理を無効とする。
  （２）Retransmit Flag（再送フラグ）
　再送されたＰＤＵかどうかを示すフラグである。「１」を示す場合は、再送されたＰＤＵであることを示す。
  （３）Sequence Number（シーケンス番号）
　シーケンス番号である。相手局のリンクアドレスとシーケンス番号から、重複するＰＤＵを検出する。
  （４）ＣＭＬ Profile（ＣＭＬプロファイル）
　自局のサポートする機能や、アプリケーション情報、チャネル情報、および通信制御情報が格納されるＣＭＬプロファイルである。
　４．５　接続応答メッセージ（Connect Response ＰＤＵ）
　接続要求に応答するためのＰＤＵである。図４２に接続応答メッセージの形式を示す。
  （１）Result Code（リザルトコード）
　初期接続を行うか否かの結果を示す。接続する相手局とサポートするアプリケーションが異なる場合は「接続しない」を通知し、サポートするアプリケーションが存在する場合は「接続する」を通知する。図４３にResult Codeの内容を示す。
  （２）Required Ack Flag（再送要求フラグ）
　再送処理が有効かどうかを示すフラグである。「１」の場合はＰＤＵの再送処理が有効となり、メッセージを相手に通知する共に確認応答（Ack ＰＤＵ）を要求する。「０」の場合は再送処理を無効とする。
  （３）Retransmit Flag（再送フラグ）
　再送されたＰＤＵかどうかを示すフラグである。「１」を示す場合は、再送されたＰＤＵであることを示す。
  （４）Sequence Number（シーケンス番号）
　シーケンス番号である。相手局のリンクアドレスとシーケンス番号から、重複するＰＤＵを検出する。
  （５）Profile Flag（プロファイルフラグ）
　Connect Response ＰＤＵにＣＭＬプロファイル情報が付加されているかどうかを示すフラグである。「０」の場合は、後続するＣＭＬ ProfileフィールドにはＣＭＬプロファイルが格納されておらず、「１」の場合は後続するＣＭＬ ProfileフィールドにＣＭＬプロファイルが格納されている。
  Beacon ＰＤＵにより、ＣＭＬプロファイルが提供済みの場合に、この識別子を「０」に設定し、ＣＭＬプロファイルを格納しない。Beacon ＰＤＵを利用していない場合（周期的に送信するアプリケーション主導の接続手順の場合）は、この識別子を「１」に設定し、ＣＭＬプロファイルを格納する。
  （６）ＣＭＬ Profile（ＣＭＬプロファイル）
　自局のサポートする機能や、アプリケーション情報、チャネル情報、および通信制御情報が格納されるＣＭＬプロファイルである。
　４．６　確認応答メッセージ（Ack ＰＤＵ）
　再送要求が行われている場合に確認応答を返すＰＤＵである。図４４に確認応答メッセージの形式を示す。
  （１）Retransmit Flag（再送フラグ）
　再送されたＰＤＵかどうかを示すフラグをである。「１」を示す場合は、再送されたＰＤＵであることを示す。
  （２）Sequence Number（シーケンス番号）
　シーケンス番号である。相手局のリンクアドレスとシーケンス番号から、重複するＰＤＵを検出する。
　４．７　輻輳制御メッセージ（Congestion Control ＰＤＵ）
　輻輳制御を行うために、周辺車両に設定する通信パラメータを要求する場合のＰＤＵである。図４５に輻輳制御メッセージの形式を示す。
  （１）Transmission Power for others（要求する送信電力）
　周辺車両に対して要求する送信電力の値である。単位は［０．１dBm］とし、－５．０dBmから２０．０dBmまでの値が設定される。
  （２）Transmission Interval for others（要求する送信周期）
　周辺車両に対して要求する送信周期の値である。単位は［１０msec］とし、１（１０msec）から２５５（２５５０msec）までの値が設定される。
  （３）Receiver Sensitivity for others（要求する受信感度）
　周辺車両に対して要求する受信感度の値である。単位は［１dBm］とし、－１２７dBmから０dBmまでの値が設定される。
　４．８　イベント通知メッセージ（Event ＰＤＵ）
　ＣＴＬおよびＣＭＬ内で発生したエラーなどのイベントを相手局に通知するＰＤＵである。図４６にイベント通知メッセージの形式に示す。
  （１）eventCode（イベントコード）
　イベントの内容を示すコードである。図４７にイベントコードの内容を示す。
  （２）extensionParameter（パラメータ）
　イベントの内容を補完するパラメータである。
　　＜５．動作手順＞
　５．１　データ転送手順
　５．１．１　アプリケーションデータ送受信手順
　ＣＴＬにおけるアプリケーションデータを送受信する手順について記載する。図４８にメッセージ転送の基本処理シーケンス例を示す。
　（送信手順）
　（１）ＣＴＬはＬＰＣＰからデータ送信要求プリミティブ（sendData.req）を受け取ると、変数parameterからＣ２Ｃ ＳＤＵを取得する。
  （２）ＣＴＬはＣ２Ｃ ＳＤＵ内のＬＰＣＰ制御情報を参照して、送信元ポート番号を取得する。
  （３）ＣＴＬはＣＭＬ情報取得プリミティブ（ＣＭＣＴＬ-Get）を用いて、送信元ポート番号の優先度を取得する。
  （４）ＣＹＬはＣ２Ｃ Headerを付加して、Ｃ２Ｃ ＰＤＵを生成した後、取得した優先度のキューに格納し、優先度制御処理を適用する。
  （５）ＣＴＬは優先度制御により、送信待機した後、通信下位プロトコルのデータ伝送プリミティブ（ＤＬ-Unitdata.req）で送信し、送信処理を完了する。
　以下の場合のＣ２ＣＳ ＤＵは無効とし、処理しない。
　・変数linkAddressがグループ同報リンクアドレスで、そのアドレス値が「０」でない場合、その要求プリミティブは破棄し、ＬＰＣＰに対してイベント通知プリミティブ（eventReport）にて、状態「指定されたグループ同報リンクアドレスは有効でない」を通知する。
　（受信手順）
　（１）ＣＴＬは通信下位プロトコルからデータ伝送プリミティブ（ＤＬ-Unitdata.ind）で、Ｃ２Ｃ ＰＤＵを受け取ると、そのＰＤＵからデータ識別子、ＰＤＵ識別子、車両優先度、チャネル利用率、送信周期、送信電力、受信感度、ユーザデータを取り出す。
  （２）ＣＴＬはデータ識別子（Data Identifier）が「０」を示し、ＰＤＵ識別子（ＰＤＵ Identifier）が「０」または「１」の場合は、上位プロトコルに対して、データ送信通知プリミティブ（sendData.ind）で相手局からのデータ（Ｃ２Ｃ ＳＤＵ）の受信を転送する。
  （３）ＣＴＬはＤＬ-Unitdata.indで得られた送信元リンクアドレスと、受信した車両優先度、チャネル利用率、送信周期、送信電力、受信感度をＣＭＬに対して、ＣＭＬ情報設定プリミティブ（ＣＭＣＴＬ-Set）を用いて登録し、受信処理を完了する。
  以下の場合のＣ２Ｃ ＰＤＵは無効とし、処理しない。
  ・データ識別子が「０」であり、ＰＤＵ識別子が「０」または「１」でない場合、その通知プリミティブは破棄し、相手局ＣＴＬに対してイベント通知メッセージにて、状態「指定されたＰＤＵ識別子は有効でない」を通知する。
  ・データ識別子が有効でない場合、その通知プリミティブは破棄し、相手局ＣＴＬに対してイベント通知メッセージにて、状態「指定されたデータ識別子は有効でない」を通知する。
　５．１．２　制御データ送受信手順
　ＣＴＬにおける制御データを送受信する手順について記載する。図４９にメッセージ転送の基本処理シーケンス例を示す。
　（送信手順）
　（１）ＣＴＬはＣＭＬから制御データ送信要求プリミティブ（ＣＭＣＴＬ-SendData.req）を受け取ると、変数parameterからＣ２Ｃ ＳＤＵ、変数priorityから優先度を取得する。
  （２）ＣＴＬはＣ２Ｃ Headerを付加して、Ｃ２Ｃ ＰＤＵを生成した後、変数priorityから取得した優先度のキューに格納し、優先度制御処理を適用する。
  （３）ＣＴＬは優先度制御により、送信待機した後、通信下位プロトコルのデータ伝送プリミティブ（ＤＬ-Unitdata.req）で送信し、送信処理を完了する。
  以下の場合のＣ２Ｃ ＰＤＵは無効とし、処理しない。
  ・変数linkAddressがグループ同報リンクアドレスで、そのアドレス値が「０」でない場合、その要求プリミティブは破棄し、ＣＭＬに対してイベント通知プリミティブ（ＣＭＣＴＬ-EventReport）にて、状態「指定されたグループ同報リンクアドレスは有効でない」を通知する。
　（受信手順）
　（１）ＣＴＬは通信下位プロトコルからデータ伝送プリミティブ（ＤＬ-Unitdata.ind）でＣ２Ｃ ＰＤＵを受け取ると、そのＰＤＵからデータ識別子、ＰＤＵ識別子、車両優先度、チャネル利用率、送信周期、送信電力、受信感度、ユーザデータを取り出す。
  （２）ＣＴＬはデータ識別子（Data Identifier）が「１」を示す場合はＣＭＬに対して、制御データ送信通知プリミティブ（ＣＭＣＴＬ-SendData.ind）で相手局からのデータの受信を通知する。
  （３）ＤＬ-Unitdata.indで得られた送信元リンクアドレスと、受信した車両優先度、チャネル利用率、送信周期、送信電力、受信感度をＣＭＬに対して、ＣＭＬ情報設定プリミティブ（ＣＭＣＴＬ-Set）を用いて登録し、受信処理を完了する。
　５．２　優先度制御サービス手順
　（１）ＣＴＬは優先度ごとにキューに格納されたデータを、優先度の高いほうから順に取り出し、データ伝送プリミティブ（ＤＬ-Unitdata.req）を用いて、送信する。
  （２）ＣＴＬは優先度の高いキューが空になれば、優先度が一つ低いキューからデータを取り出して送信する。
  優先度のキューにおいて、優先度“Middle”キューには周期的に情報を送信する情報交換型アプリケーションのデータのみが格納され、新しいデータが格納された場合にはキューにある古いデータは破棄し、最新のデータを保持する。なお、優先度“High”キューには緊急情報、“Low”キューには非リアルタイム情報を格納する。
　５．３　輻輳制御サービス手順
　５．３．１　通信制御手順
　輻輳制御は以下の手順を、車両情報が変更された場合および周期的に行う。図５０にＣＭＬにおける輻輳制御の基本シーケンスを示す。
  （１）アプリケーションはＣＭＬに対して、アプリケーション情報設定プリミティブ（ＡＣＭＬ-Set）を用いて、自車両の車両情報および周辺車両から受信した車両情報を設定する。
  （２）ＣＭＬは周期的にＰＬＭＥに対して、ＰＬＭＥ情報取得プリミティブ（ＰＬＭＥ-Get）を用いて、通信チャネルの利用率情報を取得する。
  （３）ＣＭＬは収集した情報から、輻輳を回避するために設定すべき送信周期・送信電力・受信感度を算出する。ここでは各パラメータを算出する具体的なアルゴリズムについては５．３．１．１に示す。
  （４）ＣＭＬは周期的に情報を送信するアプリケーションに対して、アプリケーション通知プリミティブ（ＡＣＭＬ-Notify）を用いて算出した送信周期を通知する。
  （５）前記アプリケーションは通知された送信周期に従って、次のタイミング以降の車両情報の送信を繰り返し行う。
  （６）ＣＭＬはＰＬＭＥに対して、ＰＬＭＥ情報設定プリミティブ（ＰＬＭＥ-Set）を用いて、算出した送信電力および受信感度を設定する。
  （７）通信下位プロトコルでは設定された送信電力および受信感度に従って、次の送受信を開始する。この際、送信するチャネルの種類によって、設定する送信電力および受信感度を切り替えても良い。
　５．３．１．１　輻輳制御アルゴリズム
　ＣＭＬにおける輻輳制御アルゴリズムを説明する。まず、輻輳制御に必要な情報の収集および設定について述べる。自車両および周辺車両の位置、速度、加速度、および走行方向はアプリケーションによって、ＣＭＬに設定され、自車両の通信制御パラメータ（チャネル利用率、送信周期、送信電力、受信感度）および周辺車両の通信制御パラメータもＣＭＬに格納されている。さらに、ここで用いる必要な通信距離はＣＭＬ内で算出しても良いし、アプリケーションで算出し、ＣＭＬ情報設定プリミティブで設定しても良い。
  次に、送信周期を制御する輻輳制御について示す。
　（送信周期制御アルゴリズム）
　本発明では、通信チャネルが混雑していない場合はアプリケーションの要求仕様である送信周期の値を適用し、通信チャネルが混雑し始めた場合に送信周期を徐々に長くする手法を利用する。
　まず、自車両の通信チャネル利用率Ｏｉ（ｔ）と周辺車両の通信チャネル利用率Ｏｊ（ｔ）から最大値Ｏｍａｘ（ｔ）を選択する。
　Ｏｍａｘ（ｔ）＝ｍａｘ｛Ｏｉ（ｔ）、Ｏｊ（ｔ）｝（ｊ＝１，・・・，Ｎ）
ただし、Ｎは自車両ｉが通信中の車両台数を示す。
　次に、送信周期を通信チャネル利用率Ｏｍａｘ（ｔ）に基づいて算出する。ここでは送信周期Ｔ（ｔ＋１）は通信チャネル利用率に基づき、目標とする通信チャネル利用率Ｏｔｈに収束する設定する。自車両の検出するチャネル利用率と周辺車両のチャネル利用率および目標のチャネル利用率を用いて、目標値と最大値の差分を利用してフィードバック制御を行うと、送信周期は次式のように算出する。
　Ｔ（ｔ＋１）＝Ｔ（ｔ）＋Ｋ×｛Ｏｍａｘ（ｔ）－Ｏｔｈ｝
　　　　　　　　　　　　＋Ｋ／Ｉ×∫｛Ｏｍａｘ（ｔ）－Ｏｔｈ｝ｄｔ
　　　　　　　　　　　　＋Ｋ×Ｔｄ×ｄ／ｄｔ｛Ｏｍａｘ（ｔ）－Ｏｔｈ｝
　ただし、Ｔ（ｔ＋１）は次に適用する送信周期を示し、Ｔ（ｔ）は前回適用された送信周期を示し、Ｏｍａｘ（ｔ）は最大の通信チャネル利用率、Ｋは比例ゲイン、Ｉは積分時間、Ｔｄは微分時間を示す。この比例ゲイン、積分時間、および微分時間の設定値によって、通信チャネル利用率を目標の閾値に収束させるまでに要する時間を変更させることができる。また、目標のチャネル利用率を調整することによって、実現できる通信の信頼性を変更できるため、アプリケーションが要求する信頼性によって目標のチャネル利用率を設定することができる。
  次に、送信電力を制御する輻輳制御について示す。
　（送信電力制御アルゴリズム）
　送信間隔と同様に、送信電力を制御することで効率的に輻輳を回避できると考えられるので、混雑し始めた場合には通信エリアを絞る。
　送信電力を制御する場合においても、通信チャネル利用率を通信の信頼性確保が見込める目標値に抑える手法を利用する。自車両の送信電力を絞ることで、周辺車両にとっては通信トラフィック量が減らすことができる。そのため、周辺車両の通信チャネル利用率の最も高い値に基づいて制御を行うことで、最もチャネル利用率の高い車両の検出する通信トラフィック量を効率的に制限できる。
　送信電力の算出には、送信周期と同様にフィードバック制御を適用し、自車両との通信台数が一定台数以下になるように送信電力を算出する。まず、周辺車両から受信した送信周期Ｔｊ（ｔ）（ｊ＝１，・・・，Ｎ）と自車両で把握できる通信台数Ｎ［台］から次のように自車両の通信チャネル利用率Ｏ（ｔ）を算出する。
Figure JPOXMLDOC01-appb-M000001
　ただし、Ｓは送信するデータサイズ［bit］、Ｃは伝送速度［bit per sec］を示す。
　次に、通信チャネル利用率Ｏ（ｔ）が目標チャネル利用率Ｏｔｈよりも小さくなる通信台数ｍ［台］を算出する。自車両との車間距離Ｄｊが短い周辺車両から順に、ｊ＝１、２、３・・・、Ｎと設定し、Ｏ（ｔ）＞Ｏｔｈとなる最初のｊをｊ＝ｌとすると、ｍ＝ｌ－１と設定できる。この際の車間距離はＤｍであり、これが目標の通信距離となる。
　自車両と通信できる台数がｍ［台］に収束するように次式のように必要となる通信距離Ｄ（ｔ＋１）を算出する。
　Ｄ（ｔ＋１）＝Ｄ（ｔ）＋Ｋ×｛ｎ（ｔ）－ｍ｝
　　　　　　　　　　　　＋Ｋ／Ｉ×∫｛ｎ（ｔ）－ｍ｝ｄｔ
　　　　　　　　　　　　＋Ｋ×Ｔｄ×ｄ／ｄｔ｛ｎ（ｔ）－ｍ｝
　ただし、Ｄ（ｔ＋１）は次に送信する通信距離を示し、Ｄ（ｔ）は前回設定された通信距離を示し、ｎ（ｔ）［台］は現在自車両と通信している台数、Ｋは比例ゲイン、Ｉは積分時間、Ｔｄは微分時間を示す。なお、ここでの比例ゲイン、積分時間、微分時間は送信周期制御アルゴリズムと同じ値を適用してもいいし、異なる値を適用しても良い。
　次に、通信距離Ｄ（ｔ＋１）を実現するための送信電力Ｐ（ｔ＋１）をあらかじめ設定されている通信仕様から算出し、新たな送信電力として適用する。
　（受信感度制御アルゴリズム）
　受信感度を制御することによって、自車両の受信できるエリアを制限することができる。送信電力が相手車両において発生する輻輳を回避するのに対し、受信感度は自車両において発生する輻輳を回避できる。そのため、送信電力制御アルゴリズムにおいて算出された送信電力Ｐ（ｔ＋１）と以前の送信電力Ｐ（ｔ）の差分を一部だけ受信感度に振り分けることで、相手車両における輻輳を軽減するか、自車両における輻輳を軽減するかを選択することができる。
　まず、送信電力制御だけの場合には、送信電力をａ（ａ＝Ｐ（ｔ＋１）－Ｐ（ｔ））［dBm］だけ小さく設定していた。ここで、受信感度制御を適用し、一部ｂ［dBm］を受信感度に振り分けると、送信電力は（ａ－ｂ）［dBm］小さく設定し、受信感度はｂ［dBm］だけ大きく設定することで、送信電力制御を利用した場合と同様に輻輳を軽減することが可能になる。
　５．３．２　輻輳制御メッセージ送信手順
　輻輳制御メッセージは以下の手順で送信される。
  （送信手順）
　（１）ＣＭＬは輻輳制御メッセージの送信契機になると、相手局に指示する通信制御パラメータ値を決定する。例えば、本発明では輻輳制御メッセージの送信契機は通信チャネル利用率が４０％を超えた場合に行ったり、アプリケーション処理部３から輻輳制御メッセージの送信要求があったりした場合うものとする。また、相手局に指示する通信制御パラメータ値は自局で設定される値を適用する。
  （２）ＣＭＬはCongestion Control ＰＤＵを生成し、ＣＴＬに対して、制御データ送信要求プリミティブ（ＣＭＣＴＬ-SendData.req）を発行する。
　（受信手順）
　（１）ＣＭＬはＣＴＬから制御データ送信通知プリミティブ（ＣＭＣＴＬ-SendData.ind）を受信すると、変数parameterから指示された通信制御パラメータ値を取り出す。
  （２）ＣＭＬは相手局の車両優先度と自局の車両優先度を比較し、相手局の車両優先度が高く、通信チャネル利用率が大きければ、相手局の指定するパラメータに設定して通信を行う。
　５．４　初期接続手順
　５．４．１　初期接続開始手順
　（１）アプリケーションはＣＭＬに対して、接続開始プリミティブ（ＡＣＭＬ-Connection）を用いて、個別通信を行うための接続要求を行う。
  （２）ＣＭＬは、ＡＣＭＬ-Connectionの変数connectionFlagが「１」を示す場合にはアプリケーションが個別通信を行うために、接続要求フラグを「１」に設定する（接続要求フラグが「１」の場合には、周辺局から同報メッセージおよびビーコンメッセージを受信した場合に初期接続シーケンスを開始する）。
  （３）ＣＭＬは、アプリケーション情報テーブルを参照し、周期的に車両情報を送信する同報アプリケーションがサポートされているかを確認する。
  （ａ）ＣＭＬは同報アプリケーションがサポートされている場合にはビーコンメッセージ（Beacon ＰＤＵ）送信フラグを「０」に設定し、５．４．３に示すように同報アプリケーションメッセージの受信を契機に初期接続シーケンスを開始する。
  （ｂ）ＣＭＬは同報アプリケーションがサポートされていない場合、かつ接続開始プリミティブの変数beaconFlagが「１」を示す場合にはビーコンメッセージ（Beacon ＰＤＵ）送信フラグを「１」に設定し、５．４．２に示すようにビーコンメッセージの送信シーケンスを開始する。
　５．４．２　ビーコンメッセージを用いた初期接続手順
　図５１にＣＭＬにおけるビーコンメッセージを用いた場合の初期接続手順の基本シーケンスを示す。また、図５２にＣＭＬにおけるビーコンメッセージを用いた初期接続手順のビーコンメッセージを破棄する場合のシーケンスを示す。
  （１）ＣＭＬは周辺局がビーコンメッセージを送信しているかを確認する。ビーコンスキャンを行うために、ビーコンスキャンタイマを起動する。
  （ａ）ＣＭＬはビーコンスキャンタイマがタイムアウトするまでに、周辺局からBeacon ＰＤＵを受信した場合は、（３）以降に記載の手順に従って初期接続シーケンスを開始する。
  （ｂ）ＣＭＬはビーコンスキャンタイマがタイムアウトするまでに、周辺局からBeacon ＰＤＵを受信しなかった場合は、（２）以降に記載の手順に従って初期接続シーケンスを開始する。
  （２）ＣＭＬはBeacon ＰＤＵを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData）を用いて、ＣＴＬに送信を要求する。
  （３）ＣＴＬから制御メッセージ送信プリミティブによって、Beacon ＰＤＵを示すメッセージが通知されると、接続状況を確認するために接続管理テーブルを参照する。
  （ａ）「接続済み」の場合には受信したBeacon ＰＤＵを破棄し、初期接続シーケンスを完了する。
  （ｂ）「未接続」の場合には接続要求フラグを参照し、接続要求フラグが「１」を示す場合は相手局のLinkAddressと受信したBeacon ＰＤＵからＣＭＬ Profileを接続管理テーブルに登録し、Connect Request ＰＤＵを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData）を用いて、ＣＴＬに送信を要求する。接続要求フラグが「０」を示す場合は初期接続シーケンスを開始しない。
  （４）ＣＭＬはＣＴＬから制御メッセージ送信プリミティブによって、Connect Request ＰＤＵを示すメッセージが通知されると、接続状況を確認するために接続管理テーブルを参照する。
  （ａ）「接続済み」の場合には受信したConnect Request ＰＤＵを破棄し、Connect Response ＰＤＵを用いて、resultCode「接続済み」を返す。
  （ｂ）「未接続」の場合には相手局のLinkAddressと受信したConnect Request ＰＤＵからＣＭＬ Profileを接続管理テーブルに登録し「接続済み」に設定する。Connect Response ＰＤＵを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData）を用いて、ＣＴＬに送信を要求する。
  （５）ＣＭＬはＣＴＬから制御メッセージ送信プリミティブによって、Connect Response ＰＤＵを示すメッセージが通知されると、接続状況を確認するために接続管理テーブルを参照する。相手局のLinkAddressに対して、接続管理テーブルを「接続済み」に設定する。Ack ＰＤＵを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData）を用いて、ＣＴＬに送信を要求する。
  （６）ＣＭＬはＣＴＬから制御メッセージ送信プリミティブによって、Ack ＰＤＵを示すメッセージが通知されると、アプリケーションに接続開始応答プリミティブ（ＡＣＭＬ-Connection.cnf）を返し、初期接続シーケンスを完了する。
　５．４．３　同報アプリケーションを用いた初期接続手順
　図５３にＣＭＬにおける同報アプリケーションを用いた場合の初期接続手順の基本シーケンスを示す。また、図５４にＣＭＬにおける同報アプリケーションを用いた初期接続手順の接続を行わない場合のシーケンスを示す。ただし、周期的に情報を送信するアプリケーションを用いた初期接続手順は、シングルチャネル利用時にのみサポートされる。
  （１）ＣＴＬは相手局から同報アプリケーションのデータを受信した後、ＣＭＬは、ＣＴＬからＣＭＬ情報設定プリミティブを用いて、Ｃ２Ｃ Headerに含まれる情報の登録を要求されると、接続管理テーブルを参照し、相手局との接続状況を確認する。
  （ａ）「接続済み」の場合には、初期接続シーケンスを完了する。
  （ｂ）「未接続」の場合には接続要求フラグを参照し、接続要求フラグが「１」を示す場合はConnect Request ＰＤＵを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData）を用いて、ＣＴＬに送信を要求する。接続要求フラグが「０」を示す場合は初期接続シーケンスを開始しない。
  （２）ＣＭＬはＣＴＬから制御メッセージ送信プリミティブによって、Connect Request ＰＤＵを示すメッセージが通知されると、接続状況を確認するために接続管理テーブルを参照する。
  （ａ）「接続済み」の場合には受信したConnect Request ＰＤＵを破棄し、Connect Response ＰＤＵを用いて、resultCode「接続済み」を返す。
  （ｂ）「未接続」の場合には接続要求フラグを参照し、接続要求フラグが「１」を示す場合は相手局のLinkAddressと受信したConnect Request ＰＤＵからＣＭＬ Profileを接続管理テーブルに登録し、「接続済み」に設定する。Connect Response ＰＤＵを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData）を用いて、ＣＴＬに送信を要求する。接続要求フラグが「０」を示す場合はConnect Response ＰＤＵを用いて、resultCode「接続しない」を返す。
  （３）ＣＭＬはＣＴＬから制御メッセージ送信プリミティブによって、Connect Response ＰＤＵを示すメッセージが通知されると、変数resultCodeを参照し、「接続しない」を示す場合はConnect Response ＰＤＵを破棄し、「接続する」を示す場合は接続状況を確認するために接続管理テーブルを参照する。相手局のLinkAddressに対して、接続管理テーブルを「接続済み」に設定する。Ack ＰＤＵを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData）を用いて、ＣＴＬに送信を要求する。
  （４）ＣＭＬはＣＴＬから制御メッセージ送信プリミティブによって、Ack ＰＤＵを示すメッセージが通知されると、アプリケーションに接続開始応答プリミティブ（ＡＣＭＬ-Connection.cnf）を返し、初期接続シーケンスを完了する。
　５．４．４　接続状況通知手順
　ＣＭＬは、相手局との接続が確立すると、イベント通知プリミティブを利用してＣＴＬに「接続が確立した」ことを通知する。ＣＴＬは接続が確立したことを通知されると、イベント通知プリミティブを用いて上位層に通知する。また、タイムアウトなどにより、相手局と切断した場合にも同様の手順によって、「切断した」イベントを通知する。図５５に接続状況を通知する手順の例を示す。
  （１）ＣＭＬは、Connect Request ＰＤＵおよび、Connect Response ＰＤＵを受信して、相手局との通信接続が確立する。
  （２）ＣＭＬは、イベント通知プリミティブ（ＣＭＣＴＬ-EventReport）を用いて、ＣＴＬに接続が確立したことを通知する。
  （３）ＣＴＬは、イベント通知プリミティブ（EventReport.ind）を用いて、上位層に接続が確立したことを通知する。
　５．５　アプリケーション登録／削除手順
　図５６にＣＭＬにおけるアプリケーション情報の登録および削除手順を示す。
　５．５．１　登録手順
　（１）移動局の各アプリケーションは、提供可能な状態になったらアプリケーション登録要求プリミティブ（ＡＣＭＬ-Registration.req）を用いて、ＣＭＬに登録する。
  （２）ＣＭＬはアプリケーション情報テーブルを更新する。
  （３）ＣＭＬはアプリケーション登録通知プリミティブ（ＡＣＭＬ-Registration.ind）を用いて、アプリケーションに登録結果を通知する。
　５．５．２　削除手順
　（１）移動局の各アプリケーションは、提供不可能な状態になったらアプリケーション削除プリミティブ（ＡＣＭＬ-Deregistration）を用いて、ＣＭＬに通知する。
  （２）ＣＭＬはアプリケーション情報テーブルを更新する。
  （３）ＣＭＬはアプリケーション削除通知プリミティブ（ＡＣＭＬ-Deregistration.ind）を用いて、アプリケーションに削除結果を通知する。
　５．６　再送制御手順
　図５７に再送処理が有効な場合のＣＭＬにおける基本処理シーケンス例を示し、図５８に再送を行う場合のＣＭＬにおける処理シーケンス例を示し、図５９に再送処理における重複チェックを行う場合のＣＭＬにおけるシーケンス例を示す。
　（送信手順）
　（１）ＣＭＬは制御データ（接続要求メッセージ、接続応答メッセージ）を送信する場合、再送処理が有効な接続管理サービスが開始される。
  （２）ＣＭＬはRequired Ack Flag（再送要求フラグ）が「１」を示すＰＤＵを作成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData.req）を用いて、ＣＴＬに送信を要求する。
  （３）ＣＭＬは送信を要求すると同時に再送タイマを起動し、前記ＰＤＵを保持し、相手局からの応答メッセージの受信を待機する。
  （４）ＣＭＬは再送タイマがタイムアウトするまでに、相手局からの応答メッセージを受信すると、再送タイマを停止し、保持していたＰＤＵを破棄し、このトランザクションを完了する。
  （５）ＣＭＬは（３）で送信したＰＤＵが相手局に到達しないなど何らかの理由により応答メッセージを受信するまでに再送タイマがタイムアウトした場合は、Retransmit Flag（再送フラグ）を「１」に設定して、ＣＴＬにＰＤＵの送信を要求すると同時に再送タイマを再起動、再送カウンタを１インクリメントする。
  （６）ＣＭＬは数回再送を繰り返しても応答メッセージを受信できずに、再送カウンタが最大再送回数を超えた場合は、保持していたＰＤＵを破棄し、このトランザクションを完了する。
　（受信手順）
　（１）ＣＭＬはＣＴＬから制御メッセージ送信通知プリミティブ（ＣＭＣＴＬ-SendData.ind）により、Required Ack Flag（再送要求フラグ）が「１」を示すＰＤＵを受信した場合は応答メッセージを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData.req）を用いて、ＣＴＬに送信を要求する。
  （２）ＣＭＬは送信を要求すると同時にウェイトタイマを起動する。
  （３）ＣＭＬは（２）で送信した応答メッセージが相手局に到達しないなどの理由で、再度同じＣＭＬ－ＳＤＵを受信した場合には、受信したＰＤＵを破棄し、再度応答メッセージを生成し、制御メッセージ送信プリミティブ（ＣＭＣＴＬ-SendData.req）を用いて、ＣＴＬに送信を要求し、ウェイとタイマを再起動する。
  （４）（２）または（３）で起動したウェイトタイマがタイムアウトすると、このトランザクションを完了する。
　実施の形態１に係る車載通信装置および路車間－車々間通信連携システムは、以上説明した車々間通信サブプロトコルの仕様に従って動作する。
　＜Ａ－３．車載通信装置１００の動作＞
　以下、図２を参照しつつ図６０～図７１を用いて実施の形態１の車載通信装置１００の各部の動作について説明する。
　　＜Ａ－３－１．データ転送サービス処理部１１の動作＞
　図６０は、車々間通信転送サービス処理部１のデータ転送サービス処理部１１の動作を示すフローチャートである。
　データ転送サービス処理部１１は、メッセージの送信要求および受信通知の受信まで待機する（ステップＳ１０１）。ここで送信要求および受信通知を受信していない場合（「Ｎｏ」の場合）には、データ転送サービス処理部１１は、送信要求および受信通知の受信の待機を継続する。これに対して、送信要求および受信通知を受信した場合（「Ｙｅｓ」の場合）には、ステップＳ１０２へと移行する。
　ステップＳ１０２では、ステップＳ１０１で受信したデータの送信要求および受信通知を識別し、送信要求である場合（「Ｙｅｓ」の場合）には、ステップＳ１０３へと移行する。これに対して、受信通知である場合（「Ｎｏ」の場合）、ステップＳ１１０へと移行する。
　ステップＳ１０３では、ステップＳ１０２で受信した送信要求が転送サービス処理部５からの要求か、車々間通信管理サービス処理部２からの要求かを識別し、転送サービス処理部５からの要求の場合（「Ｙｅｓ」の場合）には、ステップＳ１０４へと移行する。これに対して、車々間通信管理サービス処理部２からの要求の場合（「Ｎｏ」の場合）には、ステップＳ１０８へと移行する。
　次に、ステップＳ１０４では、ＬＰＣＰ転送サービス処理部５１から発行されたプリミティブから、送信するデータ（Ｃ２Ｃ ＳＤＵ）を取り出し、ＬＰＣＰヘッダから送信元ポート番号を取得する。
　ステップＳ１０５では、データ転送サービス処理部１１は車々間通信管理サービス処理部２の管理情報格納部２４から、送信元ポート番号を示すアプリケーションの優先度およびメッセージに付与する通信制御情報のパラメータを取得する。
　そして、ステップＳ１０６では、取得した通信制御情報からＣ２Ｃヘッダ作成し、Ｃ２Ｃ ＰＤＵを生成する。
　次に、ステップＳ１０７では、ステップＳ１０６で生成したＣ２Ｃ ＰＤＵと、Ｓ１０５で取得した優先度とを、優先度制御サービス処理部１３に送信し、転送サービス処理部５からのデータ送信手順が完了する。
　また、ステップＳ１０３で、車々間通信管理サービス処理部２からの送信要求であると識別された場合、ステップＳ１０８では、まず車々間通信管理サービス処理部２から発行されたプリミティブから、送信するデータ（Ｃ２Ｃ ＳＤＵ）と優先度とを取得する。
　次に、ステップＳ１０９では、データ転送サービス処理部１１は車々間通信管理サービス処理部２の管理情報格納部２４から、Ｃ２Ｃヘッダに付与する通信制御情報のパラメータを取得する。
　そして、ステップＳ１０６およびＳ１０７の処理を行い、車々間通信管理サービス処理部２のデータ送信手順を完了する。
　また、ステップＳ１０２において、データの受信通知を受け取ったものと識別された場合、ステップＳ１１０ではデータ転送サービス処理部１１は送受信サービス処理部６から発行されたプリミティブから、受信したデータ（Ｃ２Ｃ ＰＤＵ）を取得する。さらに、Ｃ２Ｃヘッダから各パラメータを取得する。
　次に、ステップＳ１１１では、受信したデータの配信先を選択するためにデータ識別子（Data Identifier）を参照し、転送サービス処理部５（ＬＰＣＰ）に送信するか、車々間通信管理サービス処理部２（ＣＭＬ）に送信するかを判断する。
　ステップＳ１１１でデータ識別子が「０」を示す場合（「Ｙｅｓ」の場合）は、ステップＳ１１２へと移行する。これに対して、データ識別子が「１」を示す場合（「Ｎｏ」の場合）は、ステップＳ１１４へと移行する。
　そして、ステップＳ１１２では、受信したＣ２Ｃ ＳＤＵを転送サービス処理部５のＬＰＣＰ転送サービス処理部５１に送信する。
　次に、ステップＳ１１３では、受信したＣ２Ｃヘッダの通信制御情報を車々間通信管理サービス処理部２の管理情報格納部２４に設定し、データ受信手順が完了する。
　一方、ステップＳ１１１において、受信したデータを車々間通信管理サービス処理部２に送信すると判断された場合、ステップＳ１１４では、取得したＣ２Ｃ ＳＤＵを車々間通信管理サービス処理部２に送信する。次に、ステップＳ１１３の処理を行い、データ受信手順が完了する。
　なお、ステップＳ１０７およびＳ１１３の処理完了後、ステップＳ１０１へと戻り、次のメッセージの送信要求および受信通知の受信まで待機する。
　　＜Ａ－３－２．イベント通知サービス処理部１２の動作＞
　図６１は、車々間通信転送サービス処理部１のイベント通知サービス処理部１２の動作を示すフローチャートである。
　イベント通知サービス処理部１２は、エラーやイベントの発生を知らせるイベント通知を受信するまで待機する（ステップＳ２０１）。当該イベント通知を受信していない場合（「Ｎｏ」の場合）には、待機状態を継続する。これに対して、イベント通知を受信した場合（「Ｙｅｓ」の場合）には、ステップＳ２０２へと移行する。
　ステップＳ２０２では、ステップＳ２０１で受信したイベント通知が車々間通信転送サービス処理部１内でのイベントか、車々間通信管理サービス処理部２から通知されたイベントかを識別し、車々間通信転送サービス処理部１のイベントの場合（「Ｙｅｓ」の場合）には、ステップＳ２０３へと移行する。これに対して、車々間通信管理サービス処理部２のイベントの場合（「Ｎｏ」の場合）には、ステップＳ２０５へと移行する。
　次に、ステップＳ２０３では、発生したエラーやイベントに該当するイベントコードを設定する。
　そして、ステップＳ２０４では、イベント通知プリミティブを管理サービス処理部５２に対して送信し、イベント通知処理を完了する。
　一方、ステップＳ２０２において、車々間通信管理サービス処理部２からのイベント通知であると識別された場合には、車々間通信管理サービス処理部２から通知されたイベントコードを、イベント通知サービス処理部１２のイベントコードに設定する（Ｓ２０５）。
　次に、ステップＳ２０４の処理を行い、イベント通知処理を完了する。なお、ステップＳ２０４の処理完了後、ステップＳ２０１へと戻り、次の処理を実行する。
　　＜Ａ－３－３．優先度制御サービス処理部１３の動作＞
　図６２は、車々間通信転送サービス処理部１の優先度制御サービス処理部１３の動作を示すフローチャートである。
　優先度制御サービス処理部１３は、送受信するデータ（メッセージ）を受信するまで待機する（ステップＳ３０１）。当該メッセージを受信していない場合（「Ｎｏ」の場合）には、データ受信の待機状態を継続する。これに対して、当該メッセージを受信した場合（「Ｙｅｓ」の場合）は、ステップＳ３０２へと移行する。
　ステップＳ３０２では、ステップＳ３０１で受信したデータが送信するデータか、受信したデータかを識別し、送信するデータの場合（「Ｙｅｓ」の場合）には、ステップＳ３０３へと移行する。これに対して、受信したデータの場合（「Ｎｏ」の場合）は、ステップＳ３０６へと移行する。
　次に、ステップＳ３０３では、送信するデータと同時に受け取った優先度を参照し、当該優先度の送信キューに送信データを格納する。
　そして、ステップＳ３０４では、各送信キューに送信データが格納されているかを確認し、データが存在する場合（「Ｙｅｓ」の場合）には、ステップＳ３０５へと移行する。
　それに対して、ステップ３０４で、送信キューにデータが存在しないことを確認した場合（「Ｎｏ」の場合）には、ステップＳ３０１へと戻り、メッセージを受信するまで待機する。
　一方、ステップＳ３０５に進んだ場合、優先度制御サービス処理部１３は優先度の高い送信キューに格納されているデータから順番に受信サービス処理部６１に送信し、優先度制御処理の送信手順を完了し、ステップＳ３０１に戻って、次のメッセージの受信まで待機する。
　なお、ステップＳ３０５での処理終了後は、ステップＳ３０４に戻り、キューに残ったデータがある場合には送信を繰り返し、データが存在しない場合にはステップＳ３０１へと戻り、メッセージを受信するまで待機する。
　ステップＳ３０２において、優先度制御サービス処理部１３が受信サービス処理部６２からデータを受信したものと識別した場合、ステップＳ３０６では、受信したデータをデータ転送サービス処理部１１に送信し、優先度制御処理の受信手順を完了する。なお、ステップＳ３０６の処理完了後、ステップＳ３０１へと戻り、次のメッセージの受信まで待機する。
　　＜Ａ－３－４．輻輳制御サービス処理部２１の動作＞
　図６３は、車々間通信管理サービス処理部２の輻輳制御サービス処理部２１の動作を示すフローチャートである。
　輻輳制御サービス処理部２１は、輻輳制御メッセージを受信するまで待機する（ステップＳ４０１）。当該メッセージを受信していない場合（「Ｎｏ」の場合）には、ステップＳ４０７へと移行する。これに対して、当該メッセージを受信した場合（「Ｙｅｓ」の場合）には、ステップＳ４０２へと移行する。
　ステップＳ４０２では、ステップＳ４０１で受信した輻輳制御メッセージから、相手局の危険度や、相手局が自局に要求する送信周期、送信電力、および受信感度などの通信制御情報を取得する。
　次に、ステップＳ４０３では、ステップＳ４０２で取得した相手局の危険度と自局の危険度とを比較し、自局よりも相手局のほうが危険と判断した場合（「Ｙｅｓ」の場合）には、ステップＳ４０４へと移行する。これに対して、相手局より自局のほうが危険と判断した場合（「Ｎｏ」の場合）には、ステップＳ４０６へと移行する。
　ステップＳ４０４では、ステップＳ４０２で取得した送信周期を自局のアプリケーションに設定するために、車々間通信アプリケーション部３１に通知する。
　そして、ステップＳ４０５では、ステップＳ４０２で取得した送信電力や受信感度を自局の通信制御情報格納部７１に設定し、輻輳制御メッセージを受信した場合の処理手順を完了する。
　一方、ステップＳ４０３において、相手局よりも自局が危険な状況にあると判断した場合、ステップＳ４０６では、ステップＳ４０１で受信した輻輳制御メッセージを破棄して、輻輳制御メッセージを受信した場合の処理手順を完了する。
　また、ステップＳ４０１において、輻輳制御メッセージを受信しなかった場合、ステップＳ４０７では、輻輳を制御するための通信制御パラメータを算出するために、車々間通信アプリケーション部３１および通信制御情報格納部７１から車両情報や通信チャネル情報などを取得する。
　次に、ステップＳ４０８では、輻輳制御アルゴリズムに基づき、ステップＳ４０７で取得した情報を元に、輻輳を回避するための送信周期、送信電力、および受信感度を算出する。
　そして、ステップＳ４０９では、ステップＳ４０８で算出した送信周期を車々間通信アプリケーション部３１に通知する。
　さらに、ステップＳ４１０では、ステップＳ４０８で算出した送信電力、受信感度を通信制御情報格納部７１に設定し、輻輳制御のための通信制御パラメータ設定手順を完了する。なお、ステップＳ４０５、Ｓ４０６、Ｓ４１０の処理完了後は、ステップＳ４０１へと戻り、次のメッセージの受信まで待機する。
　　＜Ａ－３－５．接続管理サービス処理部２２および再送制御サービス処理部２３の動作＞
　図６４～図６６を用いて、車々間通信管理サービス処理部２の接続管理サービス処理部２２および再送制御サービス処理部２３の動作について説明する。
　図６４は、接続管理サービス処理部２２の初期接続手順の方法を決定するフローチャートであり、図６５は、ビーコンメッセージを利用した場合の初期接続手順を示すフローチャートであり、図６６は、同報アプリケーションを利用した場合の初期接続手順を示すフローチャートである。
　まず、図６４を用いて、初期接続手順の方法を説明する。
　接続管理サービス処理部２２は、車々間通信アプリケーション部３１からの接続要求を受信するまで待機する（ステップＳ５０１）。当該接続要求を受信していない場合（「Ｎｏ」の場合）には、ステップＳ５０７へと移行する。これに対して、当該接続要求を受信した場合（「Ｙｅｓ」の場合）には、ステップＳ５０２へと移行する。
　ステップＳ５０２では、ステップＳ５０１で受信した接続要求の変数である接続要求フラグが「１」を示すか否かを判定する。そして、当該接続要求フラグが「１」を示さない場合（「Ｎｏ」の場合）は、ステップＳ５０１へ戻る。これに対して、当該接続要求フラグが「１」を示す場合（「Ｙｅｓ」の場合）は、ステップＳ５０３へと移行する。
　次に、ステップＳ５０３では、周期的に情報を送信するアプリケーションが起動中であるか否かを判定する。当該アプリケーションが起動していない場合（「Ｎｏ」の場合）には、ステップＳ５０５へと移行する。これに対して、当該アプリケーションが起動している場合（「Ｙｅｓ」の場合）には、ステップＳ５０４へと移行する。
　そして、ステップＳ５０４では、同報アプリケーションを利用した初期接続手順（シーケンス）を適用し、図６６に示す手順で初期接続を開始する。ここで、同報アプリケーションとは周期的に情報を送信するアプリケーションのことである。
　ステップＳ５０３において、周期的に情報を送信するアプリケーションが起動していないと判定された場合、ステップＳ５０５では、ステップＳ５０１で受信した接続要求の変数ビーコンフラグが「１」を示すか否かを判定する。当該ビーコンフラグが「１」を示さない場合（「Ｎｏ」の場合）は、ステップＳ５０１へ戻る。これに対して、当該ビーコンフラグが「１」を示す場合（「Ｙｅｓ」の場合）、ステップＳ５０６へ移行し、ビーコンメッセージを利用した初期接続手順（シーケンス）を適用し、図６５に示す手順で初期接続を開始する。
　一方、ステップＳ５０１において、車々間通信アプリケーション部３１から接続要求を受信しなかった場合、ステップＳ５０７で、周辺局からビーコンメッセージおよび接続要求メッセージを受信するまで待機する。そして、当該メッセージを受信しなかった場合（「Ｎｏ」の場合）は、ステップＳ５０１へ戻る。それに対して、当該メッセージを受信した場合は（「Ｙｅｓ」の場合）は、ステップＳ５０８へ移行する。
　次に、ステップＳ５０８では、ステップＳ５０７で受信したメッセージを破棄し、ステップＳ５０１に戻る。
　次に、図６５を用いてビーコンメッセージを利用した場合の初期接続手順について説明する。
　接続管理サービス処理部２２は、ビーコンメッセージが送信されているかを確認するためビーコンスキャンを行うので、スキャンタイマを起動する（ステップＳ６０１）。
　ステップＳ６０２では、接続管理サービス処理部２２は、ステップＳ６０１のスキャンタイマがタイムアウトするまでにビーコンメッセージを受信したか否かを判断する。当該ビーコンメッセージを受信しなかった場合（「Ｎｏ」の場合）は、ステップＳ６１２へ移行する。それに対して、当該ビーコンメッセージを受信した場合（「Ｙｅｓ」の場合）は、ステップＳ６０３へ移行する。
　次に、ステップＳ６０３では、接続管理サービス処理部２２は、接続管理テーブルを参照し、ビーコンの送信元車両との接続状況を確認する。そして、ステップＳ６０４で相手局と接続済みと判定された場合（「Ｎｏ」の場合）は、ステップＳ６１１へ移行し、初期接続手順を完了する。それに対して、相手局と未接続と判定された場合（「Ｙｅｓ」の場合）は、ステップＳ６０５へ移行する。
　そして、ステップＳ６０５では、接続管理サービス処理部２２は、ビーコンの送信元車両に対して接続要求を行うために、接続要求メッセージを生成し、接続要求メッセージを再送制御サービス処理部２３に送信する。そして、ステップＳ６０６において、再送制御サービス処理部２３は、接続要求メッセージをデータ転送サービス処理部１１に送信すると同時に再送タイマを起動する。
　ステップＳ６０７では、再送制御サービス処理部２３は、再送タイマがタイムアウトするまでに接続応答メッセージを受信したか否かを判断し、当該接続応答メッセージを受信できなかった場合（「Ｎｏ」の場合）は、ステップＳ６０６に戻り、接続要求メッセージを再送する。それに対して、当該接続応答メッセージを受信した場合（「Ｙｅｓ」の場合）は、ステップＳ６０８へ移行する。
　ステップＳ６０８では、再送制御サービス処理部２３は、受信したメッセージを接続管理サービス処理部２２に渡し、接続管理サービス処理部２２は接続管理テーブルを「接続済み」に更新し、相手局との初期接続を確立する。次に、ステップＳ６０９において、接続管理サービス処理部２２は確認応答メッセージを生成し、相手局に送信するためにデータ転送サービス処理部１１に渡す。そして、ステップＳ６１０で、アプリケーション処理部に接続が確立したことを通知し、初期接続手順を完了する。
　一方、ステップＳ６０２で、接続管理サービス処理部２２は、ビーコンメッセージを受信せずにスキャンタイマがタイムアウトした場合、ステップＳ６１２で、接続要求メッセージを受信したか否かを判断する。そして、当該接続要求メッセージを受信できなかった場合（「Ｎｏ」の場合）は、ステップＳ６２１へ移行する。それに対して、当該接続要求メッセージを受信した場合（「Ｙｅｓ」の場合）は、ステップＳ６１３へ移行する。
　ステップＳ６１３では、接続管理サービス処理部２２は接続管理テーブルを参照し、相手局との接続状況を確認する。そして、ステップＳ６１４で相手局と接続済みと判定された場合（「Ｎｏ」の場合）は、ステップＳ６２０へ移行する。それに対して、相手局と未接続と判定された場合（「Ｙｅｓ」の場合）は、ステップＳ６１５へ移行する。
　そして、ステップＳ６１５では、接続管理サービス処理部２２は、接続管理テーブルを「接続済み」に更新し、相手局との初期接続を確立し、車々間通信アプリケーション３１に接続が確立したことを通知する。
　次に、ステップＳ６１６では、接続管理サービス処理部２２は相手局からの接続要求に対する応答を行うために、接続応答メッセージを再送制御サービス処理部２３に送信する。
　ステップＳ６１７では、再送制御サービス処理部２３は、接続応答メッセージをデータ転送サービス処理部１１に送信すると同時に再送タイマを起動する。
　そして、ステップＳ６１８で、再送制御サービス処理部２３は、再送タイマがタイムアウトするまでに確認応答メッセージを受信したか否かを判断する。当該確認応答メッセージを受信できなかった場合（「Ｎｏ」の場合）は、ステップＳ６１７に戻り、接続応答メッセージを再送する。それに対して、当該確認応答メッセージを受信した場合（「Ｙｅｓ」の場合）は、ステップＳ６１９へ移行する。
　ステップＳ６１９では、再送制御サービス処理部２３は、受信したメッセージを接続管理サービス処理部２２へ送信し、接続管理サービス処理部２２は初期接続手順を完了する。
　なお、ステップＳ６１４において、接続管理サービス処理部２２は、相手局と接続済みだった場合には、ステップＳ６２０で、接続応答メッセージの変数リザルトコードを「接続済み」に設定し、ステップＳ６１６で接続応答メッセージを生成する。以降は、ステップＳ６１７～Ｓ６１９の手順に従って初期接続手順を実行する。
　一方、ステップＳ６１２において、接続管理サービス処理部２２は、接続要求メッセージを受信できなかった場合には、ステップＳ６２１で、ビーコンメッセージを生成する。そして、ビーコンメッセージを送信すると同時にビーコンタイマを起動する（ステップＳ６２２）。
　その後、ステップＳ６２３において、接続管理サービス処理部２２は、ステップＳ６２２で起動したビーコンタイマがタイムアウトするまでに接続要求メッセージを受信できるか否かを判断する。当該メッセージを受信できなかった場合（「Ｎｏ」の場合）には、ステップＳ６２２へ戻り、ビーコンメッセージを再度送信する。それに対して、当該タイムアウトするまでに接続要求メッセージを受信した場合（「Ｙｅｓ」の場合）には、ステップＳ６１３へ移行し、ステップＳ６１３～Ｓ６１９の手順に従って初期接続を実行する。
　次に、図６６を用いて同報アプリケーションを利用した場合の初期接続手順について説明する。
　接続管理サービス処理部２２は、車々間通信転送サービス処理部１が同報アプリケーションを受信したことによって、管理情報格納部２４の情報が更新されたか否かを判定する（ステップＳ７０１）。当該情報が更新されなかった場合（「Ｎｏ」の場合）には、ステップＳ７１３へ移行する。それに対して、当該情報が更新された場合（「Ｙｅｓ」の場合）には、ステップＳ７０２へ移行する。
　次に、ステップＳ７０２では、接続管理サービス処理部２２は、接続管理テーブルを参照し、情報が更新された車両との接続状況を確認する。そして、ステップＳ７０３で相手局と接続済みと判定された場合（「Ｎｏ」の場合）は、ステップＳ７１１へ移行し、初期接続手順を終了する。それに対して、未接続の場合（「Ｙｅｓ」の場合）は、ステップＳ７０４へ移行する。
　そして、ステップＳ７０４では、接続管理サービス処理部２２は、接続要求フラグを参照して、「１」を示すか否かを判定し、当該接続要求フラグが「１」を示していない場合（「Ｎｏ」の場合）は、ステップＳ７１２へ移行し、初期接続手順を終了する。それに対して、当該接続要求フラグが「１」を示す場合（「Ｙｅｓ」の場合）は、ステップＳ７０５へ移行する。
　そして、ステップＳ７０５では、接続管理サービス処理部２２は、相手車両に対して接続要求を行うために、接続要求メッセージを生成し、接続要求メッセージを再送制御サービス処理部２３に送信する。
　その後、ステップＳ７０６では、接続管理サービス処理部２２は、再送制御サービス処理部２３は、接続要求メッセージをデータ転送サービス処理部１１に送信すると同時に再送タイマを起動する。
　ステップＳ７０７では、再送制御サービス処理部２３は、再送タイマがタイムアウトするまでに接続応答メッセージを受信したか否かを判断する。そして、当該接続応答メッセージを受信できなかった場合（「Ｎｏ」の場合）は、ステップＳ７０６へ戻り、接続要求メッセージを再送する。それに対して、当該接続応答メッセージを受信した場合（「Ｙｅｓ」の場合は）、ステップＳ７０８へ移行する。
　ステップＳ７０８では、再送制御サービス処理部２３は受信したメッセージを接続管理サービス処理部２２に渡し、接続管理サービス処理部２２では接続管理テーブルを「接続済み」に更新し、相手局との初期接続を確立すると同時に車々間通信アプリケーション部３１に接続を通知する。
　次に、ステップＳ７０９では、接続管理サービス処理部２２は確認応答メッセージを生成し、相手局に送信するためにデータ転送サービス処理部１１に渡す。そして、ステップＳ７１０で、アプリケーション処理部に接続が確立したことを通知し、初期接続手順を完了する。
　一方、ステップＳ７０１で、接続管理サービス処理部２２は、管理情報格納部２４の情報が更新されなかったと判定された場合、ステップＳ７１３で、接続要求メッセージを受信できたか否かを判断し、当該接続要求メッセージを受信できなかった場合（「Ｎｏ」の場合）は、ステップＳ７０１へ戻る。それに対して、当該接続要求メッセージを受信した場合（「Ｙｅｓ」の場合）は、ステップＳ７１４へ移行する。
　次に、ステップＳ７１４では、接続管理サービス処理部２２は、接続管理テーブルを参照し、相手局との接続状況を確認する。そして、ステップＳ７１５で相手局と接続済みと判定された場合（「Ｎｏ」の場合）は、ステップＳ７２１へ移行する。それに対して、未接続の場合（「Ｙｅｓ」の場合）は、ステップＳ７１６へ移行する。
　そして、ステップＳ７１６では、接続管理サービス処理部２２は、接続管理テーブルを「接続済み」に更新し、相手局との初期接続を確立し、車々間通信アプリケーション３１に接続が確立したことを通知する。
　次にステップＳ７１７では、接続管理サービス処理部２２は相手局からの接続要求に対する応答を行うために、接続応答メッセージを再送制御サービス処理部２３に送信する。
　その後、ステップＳ７１８では、再送制御サービス処理部２３は、接続応答メッセージをデータ転送サービス処理部１１に送信すると同時に再送タイマを起動する。
　ステップＳ７１９では、再送制御サービス処理部２３は、再送タイマがタイムアウトするまでに確認応答メッセージを受信したか否かを判断し、当該確認応答メッセージを受信できなかった場合（「Ｎｏ」の場合）は、ステップＳ７１８へ戻り、接続応答メッセージを再送する。それに対して、当該確認応答メッセージを受信した場合（「Ｙｅｓ」の場合）は、ステップＳ７２０へ移行し、初期接続手順を完了する。
　なお、ステップＳ７１５において、再送制御サービス処理部２３は、相手局と接続済みと判定された場合は、ステップＳ７２１で、接続応答メッセージの変数リザルトコードを「接続済み」に設定し、ステップＳ７１７で接続応答メッセージを生成する。なお、以降はステップＳ７１８～Ｓ７２０の手順に従って初期接続手順を実行する。
　　＜Ａ－３－６．車々間通信アプリケーション部３１の動作＞
　図６７は、アプリケーション処理部３の車々間通信アプリケーション部３１の動作を示すフローチャートである。
　車々間通信アプリケーション部３１は、起動後、車々間通信管理サービス処理部２の管理情報格納部２４に対して、アプリケーション情報を登録する（ステップＳ８０１）。
　次に、車々間通信アプリケーション部３１はデータの送信要求またはデータの受信通知があるまで待機する（ステップＳ８０２）。当該要求および通知を受信していない場合（「Ｎｏ」の場合）は、要求および通知の受信まで待機を継続する。これに対して、当該要求および通知を受信した場合（「Ｙｅｓ」の場合）は、ステップＳ８０３へと移行する。
　ステップＳ８０３では、ステップＳ８０２で受信した内容が送信要求であるか否かを判定し、送信要求の場合（「Ｙｅｓ」の場合）には、ステップＳ８０４へと移行する。これに対して、受信通知の場合（「Ｎｏ」の場合）には、ステップＳ８０６へと移行する。
　次に、ステップＳ８０４では、送信要求されたデータを同報通信するか否かを判定し、同報通信の場合（「Ｙｅｓ」の場合）には、ステップＳ８０５へと移行する。これに対して、同報通信ではなく個別通信の場合（「Ｎｏ」の場合）には、ステップＳ８０７へと移行する。
　そして、ステップＳ８０５では、送信するデータをトランザクション管理部４のトランザクションサービス処理部４１に送信し、アプリケーション処理部の同報通信処理手順を完了する。
　一方、ステップＳ８０３において、データの受信通知を受け取ったと判定された場合、ステップＳ８０６では、車々間通信アプリケーション部３１は受信したデータを読み取り、車両情報を車々間通信管理サービス処理部２の管理情報格納部２４に設定し、アプリケーション処理部のデータ受信処理手順を完了する。
　また、ステップＳ８０４において、データを個別通信する場合、ステップＳ８０７では、車々間通信アプリケーション部３１は車々間通信管理サービス処理部２の接続管理サービス処理部２２に接続要求を送信する。
　次に、ステップＳ８０８では、接続管理サービス処理部２２から接続確立通知を受信したか否かを判定し、接続確立を通知した場合（「Ｙｅｓ」の場合）には、ステップＳ８０９へと以降する。これに対して、接続確立通知を受信できなかった場合（「Ｎｏ」の場合）は、ステップＳ８１０へと移行する。
　ステップＳ８０９では、車々間通信アプリケーション部３１はトランザクションサービス処理部４１に送信するデータを送信し、個別通信の送信処理手順を完了する。
　また、ステップＳ８１０では、車々間通信アプリケーション部３１は送信要求のあったデータを破棄し、送信処理手順を完了する。
　なお、ステップＳ８０５、Ｓ８０６，Ｓ８０９およびＳ８１０の処理完了後は、Ｓ８０２以降の処理を繰り返し実行する。
　　＜Ａ－３－７．トランザクションサービス処理部４１の動作＞
　図６８は、トランザクション管理部４のトランザクションサービス処理部４１の動作を示すフローチャートである。
　トランザクションサービス処理部４１は、データの送信要求またはデータの受信通知があるまで待機する（ステップＳ９０１）。当該要求および通知を受信していない場合（「Ｎｏ」の場合）には、要求および通知の受信まで待機を継続する。これに対して、当該要求および通知を受信した場合（「Ｙｅｓ」の場合）には、ステップＳ９０２へと移行する。
　ステップＳ９０２では、ステップＳ９０１で受信した内容が送信要求であるか否かを判定し、送信要求の場合（「Ｙｅｓ」の場合）には、ステップＳ９０３へと移行する。これに対して、受信通知の場合（「Ｎｏ」の場合）には、ステップＳ９０５へと移行する。
　ステップＳ９０３では、トランザクションサービス処理部４１は、必要に応じて分割や再送、連送などの送信処理を行い、ステップＳ９０４で送信データにＬＰＰヘッダを付与し、転送サービス処理部５のＬＰＣＰ転送サービス処理部５１に送信する。
　一方、ステップＳ９０２でデータの受信通知を受け取ったと判定された場合、ステップＳ９０５で、組み立や接続管理などの受信処理を実行する。
　そして、ステップＳ９０６では、受信したデータがアプリケーションへ渡すデータか否かを判定し、アプリケーションに送信するデータの場合（「Ｙｅｓ」の場合）は、ステップＳ９０７へと移行する。これに対して、ＬＰＰ接続管理サービス処理部４２から送信した制御データを受信した場合（「Ｎｏ」の場合）は、ステップＳ９０８へと移行する。
　ステップＳ９０７では、アプリケーション処理部３の車々間通信アプリケーション部３１に送信データを渡し、トランザクション管理部４のアプリケーションデータ受信処理手順を完了する。
　また、ステップＳ９０８では、ＬＰＰ接続管理サービス処理部４２に制御データを渡し、トランザクション管理部３の制御データ受信処理手順を完了する。
　なお、ステップＳ９０４、Ｓ９０７およびＳ９０８の処理完了後は、ステップＳ９０１以降の処理を繰り返し実行する。
　　＜Ａ－３－８．ＬＰＣＰ転送サービス処理部５１の動作＞
　図６９は、転送サービス処理部５のＬＰＣＰ転送サービス処理部５１の動作を示すフローチャートである。
　ＬＰＣＰ転送サービス処理部５１は、データの送信要求またはデータの受信通知があるまで待機する（ステップＳ１００１）。当該要求および通知を受信していない場合（「Ｎｏ」の場合）には、要求および通知の受信まで待機を継続する。これに対して、当該要求および通知を受信した場合（「Ｙｅｓ」の場合）には、ステップＳ１００２へと移行する。
　ステップＳ１００２では、ステップＳ１００１で受信した内容が送信要求であるか否かを判定し、送信要求の場合（「Ｙｅｓ」の場合）には、ステップＳ１００３へと移行する。これに対して、受信通知の場合（「Ｎｏ」の場合）には、ステップＳ１００５へと移行する。
　次に、ステップＳ１００３では、ＬＰＣＰ転送サービス処理部５１はローカルポート番号などのＬＰＣＰヘッダを付与し、ステップＳ１００４で転送サービス処理部５のデータ転送サービス処理部１１に送信データを渡して、転送サービス処理部５でのデータ送信処理手順を完了する。
　一方、ステップＳ１００２においてデータの受信通知を受け取った場合、ステップＳ１００５において、ＬＰＣＰ転送サービス処理部５１はローカルポート番号を参照し、受信したデータの配信先を識別する。そして、ステップＳ１００６では、配信先へ受信データを送信し、転送サービス処理部５のデータ受信処理手順を完了する。
　なお、ステップＳ１００４およびＳ１００６の処理完了後は、ステップＳ１００１以降の処理を繰り返し実行する。
　　＜Ａ－３－９．送受信サービス処理部６の動作＞
　図７０は、送受信サービス処理部６の動作を示すフローチャートである。
　送信サービス処理部６１および受信サービス処理部６２は、データの送信要求またはデータの受信通知があるまで待機する（ステップＳ１１０１）。当該要求および通知を受信していない場合（「Ｎｏ」の場合）には、要求および通知の受信まで待機を継続する。これに対して、当該要求および通知を受信した場合（「Ｙｅｓ」の場合）は、ステップＳ１１０２へと移行する。
　ステップＳ１１０２では、Ｓ１１０１で受信した内容が送信要求であるか否かを判定し、送信要求の場合（「Ｙｅｓ」の場合）には、ステップＳ１１０３へと移行する。これに対して、受信通知の場合（「Ｎｏ」の場合）には、ステップＳ１１０５へと移行する。
　次に、ステップＳ１１０３では、送信サービス処理部６１は送受信サービス管理部７の通信制御情報格納部７１から送信電力を取得し、ステップＳ１１０４では、取得した送信電力を用いて無線通信を行い、送受信サービス処理部６の送信処理手順を完了する。
　一方、ステップＳ１１０２でデータの受信通知がされたと判定された場合、ステップＳ１１０５では、受信サービス処理部６２は送受信サービス管理部７の通信制御情報格納部７１から受信感度を取得する。
　そして、ステップＳ１１０６では、受信したデータの電力がキャリアセンス感度以上か否かを判定し、キャリアセンス感度以上の電力を受信した場合（「Ｙｅｓ」の場合）には、ステップＳ１１０７へと移行し、キャリアセンス感度に満たない電力を受信した場合（「Ｎｏ」の場合）には、ステップＳ１１０８へと移行する。
　ステップＳ１１０７では、受信サービス処理部６２が通信チャネルがビジーと判定し、通信制御情報格納部７１の通信チャネルの利用率を更新する。
　そして、Ｓ１１０８では、受信サービス処理部６２は受信したデータの電力が受信感度以上あるか否かを判定し、受信感度以上の電力を受信した場合（「Ｙｅｓ」の場合）、ステップＳ１１０９へと移行する。これに対して、受信感度に満たない電力を受信した場合（「Ｎｏ」の場合）は、ステップＳ１１１０へと移行する。
　ステップＳ１１０９では、受信サービス処理部６２は受信したデータを車々間通信管理サービス処理部１の優先度制御サービス処理部１３に送信し、受信処理手順を完了する。
　一方、ステップＳ１１１０では、受信サービス処理部６２は受信したデータを破棄し、受信処理手順を完了する。
　なお、ステップＳ１１０４、Ｓ１１０９およびＳ１１１０の処理完了後は、ステップＳ１１０１以降の処理を繰り返し実行する。
　＜Ａ－４．効果＞
　以上説明した、本発明に係る実施の形態１の車載通信装置および路車間－車々間通信連携システムにおいては、車々間通信転送サービス処理部１と車々間通信管理サービス処理部２は、既存の路車間通信プロトコルである転送サービス処理部（ＬＰＣＰ）に対するインタフェースを有することで、路車間通信システムを提供する車載器と車々間通信システムを提供する車載器とを共用化できる車載通信装置を得ることができ、路車間通信システムと車々間通信システムの両方にサービスを提供できる車載通信装置を得ることが可能となる。
　また、車々間通信転送サービス処理部１は、アプリケーション処理部と、送受信サービス処理部との間に介在するので、複数アプリケーションの優先度に応じて通信を制御できるため優先度の高いアプリケーションの情報を優先的に送信することが可能となる。
　また、車々間通信管理サービス処理部２は、アプリケーション処理部３、車々間通信転送サービス処理部１および送受信サービス管理部７に対して平行するように配置されているので、アプリケーション処理部３から受け取る各車両の車両情報および危険度、および送受信サービス管理部から取得するチャネル利用率に基づいて、自車両および周辺車両の輻輳を回避するための通信制御を行うことが可能となる。これにより、車両台数が増加した場合でも通信誤り率が改善できる。
　また、車々間通信転送サービス処理部１は、車々間通信管理サービス処理部２を経由して優先度を取得できるので、既存のプロトコルであるトランザクション管理部（ローカルポートプロトコル）４や転送サービス処理部（ローカルポート制御プロトコル）５などから優先度を取得できない場合でも、優先度制御を提供することが可能になる。
　また、車々間通信転送サービス処理部１は、送信するメッセージに送信電力や受信感度、および通信チャネルの利用率などの通信制御情報を付加することで、通信制御を行う際に必要な情報を効率的に収集することができる。これにより、車々間通信管理サービス処理部２が、輻輳制御を行う際に周辺車両の検出した情報に基づいて送信周期や送信電力などの通信パラメータの設定を行うことができ、効率的な輻輳制御を行うことが可能になる。
　また、車々間通信管理サービス処理部２は、アプリケーション処理部３から送受信サービス管理部６に渡って平行するように配置されているので、アプリケーション処理部３や送受信サービス管理部７の情報の取得や、アプリケーション処理部３や送受信サービス管理部７への設定が可能となる。
　また、車々間通信管理サービス処理部２は、通信接続管理サービスを提供するために、初期接続を行うための接続手順を規定し、接続状況を管理するので、アプリケーション処理部３が移動局に対して個別に通信を開始することが可能となる。また、送受信サービス処理部６が初期接続手順を有していない場合に、車々間通信管理サービス処理部２が初期接続の開始や通信接続の管理を行うことができる。
　また、車々間通信管理サービス処理部２は、車々間通信転送サービス処理部１を経由して、アプリケーション処理部３やトランザクション管理部４に、通信接続確立の通知を行うことができる。
　また、車々間通信管理サービス処理部２は、周期的にメッセージを送信するアプリケーションが動作している場合には、当該アプリケーションのメッセージを受信したことを契機に、初期接続の接続要求を相手移動局に送信することで、高速かつ効率的な初期接続を行うことが可能となる。
　また、車々間通信管理サービス処理部２は、周期的にメッセージを送信するアプリケーションが動作していない場合には、周期的にメッセージを送信し、周辺の移動局がメッセージを受信することを契機に、初期接続の接続要求を相手移動局に送信することで、初期接続を開始することが可能となる。
　また、車々間通信管理サービス処理部２は、初期接続を行う際に、通信チャネル上に初期接続に必要とされるメッセージが送信されているかを監視することで、無駄なメッセージの送信を回避し、通信帯域を有効に利用できる。
　また、車々間通信管理サービス処理部２は、周辺移動局に対して、送信電力や受信感度、および送信チャネルなどを指示できる制御メッセージを送信することで、即座に通信帯域の利用率を抑えることや、自局の送信を優先的に行うことが可能になる。
　＜Ａ－５．変形例＞
　以上説明した実施の形態１では、トランザクション管理部４（ローカルポートプロトコル）と、転送サービス処理部５（ローカルポート制御プロトコル）と、車々間通信転送サービス処理部１（車々間通信トランスポートサブレイヤ）と、車々間通信管理サービス処理部２（車々間通信マネジメントレイヤ）とで構成される階層構造を示したが、ローカルポートプロトコルやローカルポート制御プロトコルの代わりに他の双方向に通信可能なプロトコルを用いても良い。
　例えば、アメリカで検討されているプロトコルＩＥＥＥ１６０９．３やヨーロッパのＣＡＬＭ（Communications Architecture for Land Mobile environment）で検討されているプロトコルＦＡＳＴやＧｅｏ－Ｒｏｕｔｉｎｇなどを用いても良い。
　また、車々間通信管理サービス処理部２は、アプリケーション処理部３、トランザクション管理部４、転送サービス処理部５、車々間通信転送サービス処理部１および送受信サービス管理部７に対して平行するように配置される構造を示したが、ＩＥＥＥ１６０９．３で検討されている管理部ＷＭＥ（WAVE Management Entity）やＣＡＬＭで検討されている管理部ＣＭＥ（CALM Management Entity）も車々間通信管理サービス処理部２と同じように配置されるため、車々間通信管理サービス処理部２をＷＭＥやＣＭＥに含める構成やＷＭＥやＣＭＥを含む構成を用いても良い。ここで、ＷＡＶＥはWireless Access in Vehicular Environmentsの略語である。
　また、車々間通信管理サービス処理部２がＷＭＥに含まれる場合、アプリケーション処理部３や送受信サービス管理部７とのインタフェースは、ＷＭＥとアプリケーション間およびＷＭＥとＭＬＭＥ／ＰＬＭＥ間のインタフェースに置き換えたり、追加しても良い。また、車々間通信転送サービス部１と車々間通信管理サービス処理部２とのインタフェースは、ＣＭＥとＦＡＳＴとのインタフェースに統合しても良い。
　また、アプリケーション処理部３は、車々間通信システムのアプリケーションに限らず、路車間通信システムのアプリケーションやＩＴＳに関するアプリケーション以外のアプリケーションなどを用いても良い。
　また、車々間通信管理サービス処理部２は、輻輳を回避するために設定する通信パラメータとして送信周期、送信電力、および受信感度に限らず、送信チャネルや送受信アンテナの指向性、および送信する周波数帯域などを用いても良い。
　＜Ｂ．実施の形態２＞
　＜Ｂ－１．プロトコル構成＞
　本発明に係る実施の形態２について、図７１および図７２を用いて説明する。
　図７１は本発明に係る実施の形態２の車載通信装置１０１および路車間－車々間通信連携システムのプロトコル構成を示すブロック図であり、図７２は車載通信装置１０１および路車間－車々間通信連携システムのプロトコル構成を詳細に示すブロック図である。なお、実施の形態１と同一の部位には同一の符号を付し、重複する詳細な説明は省略する。
　図７１および図７２に示すように、実施の形態２の車載通信装置１０１は、車々間通信転送サービス処理部１、車々間通信管理サービス処理部２、アプリケーション処理部３、送受信サービス処理部６および送受信サービス管理部７を有している。
　従って、実施の形態２の車載通信装置１０１および路車間－車々間通信連携システムにおいては、図１に示した車載通信装置１００における既存の路車間通信プロトコルであるトランザクション管理部４および転送サービス処理部５に代えて、路車間－車々間通信連携サービス処理部８を有し、アプリケーション処理部３に路車間通信アプリケーション部３２を有する点が実施の形態１に示す車載通信装置１００および路車間－車々間通信連携システムと異なる点である。
　そして、実施の形態２の車載通信装置１０１では、実施の形態１と同様にアプリケーション処理部３には車々間通信アプリケーション部３１を備えているため、車々間通信のアプリケーションを提供可能である。
　さらに車載通信装置１０１では路車間通信アプリケーション部３２と路車間－車々間通信連携サービス処理部８とを備えているため、路車間通信のアプリケーションを提供することも可能となる。
　図７２に示すように、路車間－車々間通信連携サービス処理部８は、実施の形態１に示すトランザクション管理部４および転送サービス処理部５と同等の機能を有しており、トランザクションサービス処理部４１、ＬＰＰ接続管理サービス処理部４２、ＬＰＣＰ転送サービス処理部５１および管理サービス処理部５２を有している。
　＜Ｂ－２．車載通信装置１０１の動作＞
　車載通信装置１０１においては、路車間通信アプリケーション部３２が送信するデータは、路車間－車々間通信連携サービス処理部８のトランザクションサービス処理部４１およびＬＰＣＰ転送サービス処理部５１を経由して、送受信サービス処理部６から相手局へ送信され、車々間通信アプリケーション部３１が送信するデータとは異なり、車々間通信転送サービス処理部１のデータ転送サービス処理部１１を経由しない。
　また、送受信サービス処理部６は、周辺局からデータを受信した場合、送信サービス処理部６が付与したヘッダ情報を参照し、路車間－車々間通信連携サービス処理部８に送信するか、車々間通信転送サービス処理部１に送信するかを判別する。これにより、路車間通信のアプリケーションは路車間－車々間通信連携サービス処理部８を経由して路車間通信アプリケーション部３２へ送信され、車々間通信のアプリケーションは車々間通信転送サービス処理部１、路車間－車々間通信連携サービス処理部８を経由して車々間通信アプリケーション部３１へ送信される。
　＜Ｂ－３．効果＞
　以上説明したように、実施の形態２の車載通信装置１０１は、路車間－車々間通信連携サービス処理部８を備えることによって、路車間通信のデータは車々間通信転送サービス処理部１を経由せずに相手局に送信でき、車々間通信のデータは車々間通信転送サービス処理部１を経由して、必要な制御を行って周辺局に送信することができる。これにより、路車間通信の車載器と車々間通信の車載器を共用化することができる。
　＜Ｂ－４．変形例＞
　なお、実施の形態２では、路車間－車々間通信連携サービス処理部８と、車々間通信転送サービス処理部１と、車々間通信管理サービス処理部２とで構成される階層構造を示したが、路車間－車々間通信連携サービス処理部８には、実施の形態１と同様にローカルポートプロトコルやローカルポート制御プロトコルなどの既存のプロトコルを用いても良い。
　＜Ｃ．実施の形態３＞
　＜Ｃ－１．プロトコル構成＞
　本発明に係る実施の形態３について、図７３および図７４を用いて説明する。
　図７３は本発明に係る実施の形態２の車載通信装置１０２および路車間－車々間通信連携システムのプロトコル構成を詳細に示すブロック図である。なお、実施の形態１および実施の形態２と同一の部位には同一の符号を付し、重複する詳細な説明は省略する。
　図７３に示すように、車載通信装置１０２は、図１を用いて説明した実施の形態１の車載通信装置１００とほぼ同じ構成であるが、アプリケーション処理部３において、路車間通信アプリケーション部３２を有する点が実施の形態１の車載通信装置１０１と異なる点である。
　＜Ｃ－２．車載通信装置１０２の動作＞
　路車間通信アプリケーション部３２が送信するデータは、実施の形態１の車載通信装置１００と同様にトランザクション処理部４、転送サービス処理部５を経由して、車々間通信転送サービス処理部１に渡される。
　車々間通信転送サービス処理部１は、転送サービス処理部５から受信したＣ２Ｃ　ＳＤＵからＬＰＣＰヘッダのポート番号を参照し、図６０のステップＳ１０５において優先度を取得する際に、同時にアプリケーションの種類を取得し、路車間通信アプリケーションか、車々間通信アプリケーションかを識別する。
　取得したアプリケーションの種類が、車々間通信アプリケーションの場合には実施の形態１に記載の送受信手順を適用してメッセージの送受信を行うが、路車間通信アプリケーションの場合には図３８に示すＣ２Ｃヘッダの代わりに図７４に示すＣ２Ｃヘッダを付与して、優先度制御サービス処理部１３を経由せずに、送受信サービス処理部６に渡し、メッセージの送信を行う。この際、送信サービス処理部６１が送信する送信電力は路車間通信用の値を定義しておき、その値を適用しても良いし、車々間通信管理サービス処理部２が路車間通信に適した送信電力を算出しても良い。また、路車間通信アプリケーション部３２の情報を送信する場合には、輻輳制御サービスや接続管理サービスは提供しなくても良い。
　車々間通信管理サービス処理部２は、前記路車間通信アプリケーション部３２の情報を送信する前に、路車間通信アプリケーション部３２からアプリケーション通知プリミティブやアプリケーション登録プリミティブにより、輻輳制御メッセージを送信し、周辺局の車々間通信アプリケーション部３１の送信周期を長くしたり、送信電力を低くしたりすることができる。
　車々間通信転送サービス処理部１は、前記送信データを受信サービス処理部６２から受信した場合には、Ｃ２Ｃヘッダを参照し、データ識別子とＰＤＵ識別子から転送先および受信処理を識別する。データ識別子が「０」、ＰＤＵ識別子が「０」を示す場合には実施の形態１と同様の手順で処理を行い、データ識別子が「０」、ＰＤＵ識別子が「１」を示す場合には、データ本体部分を取り出し、転送サービス処理部５に渡して受信処理を完了する。この際、受信サービス処理部６２が設定する受信感度は路車間通信用の値を定義しておき、その値を適用しても良いし、車々間通信管理サービス処理部２が路車間通信に適した受信感度を算出しても良い。
　車々間通信転送サービス処理部１は、前記路車間通信アプリケーション部３２のデータを受信した場合、車々間通信管理サービス処理部２に対してイベント通知プリミティブを発行し、自局の周辺に路側機が存在することを通知する。これにより、車々間通信管理サービス処理部２は、車々間通信アプリケーション部３１のデータを送信する際の送信電力を輻輳制御サービスにより設定される値よりも小さめに設定したり、送信周期は長めに設定したりする。
　＜Ｃ－３．効果＞
　以上説明したように、実施の形態３の車載通信装置１０２は、実施の形態１の車載通信装置１００と同様に、アプリケーション処理部３は車々間通信アプリケーション部３１を備えているため、車々間通信のアプリケーションを提供可能である。さらに車載通信装置１０２は路車間通信アプリケーション部３２を備えているため、路車間通信のアプリケーションを提供することも可能となる。
　また、車々間通信転送サービス処理部１が、路車間通信アプリケーションと車々間通信アプリケーションによって、送受信手順を使い分けるため、路車間通信アプリケーションデータの場合は最小限のヘッダ情報を付加し、データ本体を透過させることができる。これにより、車載通信装置１０２は既存の路車間通信システムの動作に対しては影響を与えず、車々間通信システムにのみ各種制御サービスを提供できる。
　また、車々間通信管理サービス処理部２が、路車間通信アプリケーションの送信を優先的に行うために、輻輳制御メッセージにより周辺局の車々間通信アプリケーションの送信電力および送信周期を制御できる。これにより、路車間通信アプリケーションの通信信頼性を向上させることができる。
　また、車々間通信転送サービス処理部１が、路車間通信アプリケーションの有無を車々間通信管理サービス処理部２に通知することによって、路車間通信アプリケーションを優先的に送受信させるために、車々間通信アプリケーションの送信電力を抑えたり、送信周期を長くしたりさせることができる。これにより、路車間通信アプリケーションの通信信頼性を向上させることができる。
　＜Ｄ．実施の形態４＞
　＜Ｄ－１．プロトコル構成＞
　本発明に係る実施の形態４について、図７５～図７７を用いて説明する。なお、実施の形態１と同一の部位には同一の符号を付し、重複する詳細な説明は省略する。
　図７５は本発明に係る実施の形態４の車載通信装置１０３の構成を示すブロック図である。図７５に示すように、車載通信装置１０３は図１を用いて説明した実施の形態１の車載通信装置１００とほぼ同じ構成であるが、トランザクション管理部４と転送サービス処理部５がＷＡＶＥ（Wireless Access in Vehicular Environments）転送部９に置き換わっている点と、車々間通信管理サービス処理部２がＷＡＶＥ管理部１０に含まれている点で、実施の形態１の車載通信装置１００と異なっている。
　ＷＡＶＥ転送部９は、ＩＥＥＥ１６０９．３内のＷＳＭＰ（WAVE Short Message Protocol）と呼ばれるプロトコルであり、アプリケーション処理部３の要求に従ってデータを送信するサービスの提供や、受信したデータをアプリケーション処理部３に通知するサービスの提供を行う。
　ＷＡＶＥ管理部１０は、ＩＥＥＥ１６０９．３内のＷＭＥと呼ばれる管理機能であり、アプリケーション処理部３の要求に応じて接続管理サービスを提供したり、アプリケーションに対してＷＭＥの管理するデータの設定／取得を行う情報アクセスサービスを提供する。
　実施の形態１の図３の構成では、日本の路車間通信規格であるトランザクション管理部４（ＬＰＰ）と、転送サービス処理部５（ＬＰＣＰ）とで構成される階層構造を示したが、図７５に示すように実施の形態４の構成ではアメリカの路車間通信および車々間通信規格であるプロトコルＩＥＥＥ１６０９．３のＷＳＭＰを利用した構成である。
　また、実施の形態１の図３の構成の車々間通信管理サービス処理部２は、ＩＥＥＥ１６０９．３の管理部ＷＭＥと同じように配置されているため、実施の形態４の図７５の構成の車々間通信管理サービス処理部２はＷＭＥに含まれた構成となる。
　実施の形態４の送受信サービス処理部６は、ＩＥＥＥ８０２．１１ｐとＩＥＥＥ１６０９．４を想定し、周辺局に搭載された車載通信装置１０３と無線通信を行ったり、無線通信を行う周波数チャネルを切り替えたりする。
　実施の形態４の車々間通信転送サービス処理部１はＷＡＶＥ転送部９と送受信サービス処理部６との間に存在し、ＷＡＶＥ転送部９やＷＡＶＥ管理部１０に対してデータ転送サービスおよび優先度制御サービスを提供する。さらに、ＷＡＶＥ管理サービス処理部１０に対して、イベント通知サービスを提供する。
　実施の形態４の車々間通信管理サービス処理部２は、ＷＡＶＥ管理部１０の内部にＷＡＶＥ管理部１０の一つの機能として存在し、アプリケーション処理部３や車々間通信転送サービス処理部１に対して、輻輳制御サービス、接続管理サービス、およびデータ再送サービスを提供する。また、ＷＡＶＥ管理部１０は送受信サービス管理部７の機能を拡張する。
　＜Ｄ－２．サービスインタフェース（ＳＡＰ）＞
　図７６は本発明に係る実施の形態４の車々間通信アーキテクチャのプロトコル構成におけるＳＡＰの位置を示した図である。図７６におけるサービスインタフェースのうち、実施の形態１と異なるＳＡＰの一覧を図７７に示す。実施の形態１と同じＳＡＰについては図１８に示したＳＡＰと同等の機能であるため、重複する説明は省略する。また、図７７に示すＳＡＰのパラメータの説明については、ＩＥＥＥの標準規格に開示されており、当業者であれば当該規格を参照することで理解できるので、説明を省略する。
　実施の形態１で示した図１８のＣＭＣＴＬ　ＳＡＰ、ＭＬＭＥ　ＳＡＰ、ＰＬＭＥ　ＳＡＰは、実施の形態４と同じＳＡＰであるためそのまま利用することが可能であるが、図１８のＡＣＭＬ　ＳＡＰおよびＡＣＴＬ　ＳＡＰは、実施の形態４のＳＡＰとは異なるため、実施の形態１をそのまま適用することができない。そこで、図７６に示される構成の場合、実施の形態４ではＷＳＭＰやＷＭＥが提供するインタフェースに合わせるために、ＡＣＭＬ　ＳＡＰはＷＭＥ　ＳＡＰに置換し、ＡＣＴＬ　ＳＡＰはＬＳＡＰに置換している。
　＜Ｄ－２－１．アプリケーションとＷＭＥとのＳＡＰ（ＷＭＥ　ＳＡＰ）＞
　ＷＭＥはアプリケーションに対して、図７７に示すように次の６種類のプリミティブを提供する。
（１）接続要求プリミティブ（ＷＭＥ-Application）
　実施の形態１のＡＣＭＬ-Connectプリミティブと同等の機能、パラメータを提供する。ＷＭＥ-Applicationプリミティブはアプリケーションが周辺局との接続を要求したり、切断するプリミティブである。
（２）アプリケーション通知プリミティブ（ＷＭＥ-Notification）
　実施の形態１のＡＣＭＬ-Notifyプリミティブと同等の機能、パラメータを提供する。ＷＭＥ-Notificationは周辺局との接続状態に変化があった場合に、ＷＡＶＥ管理部１０からアプリケーション処理部３に対して通知するプリミティブである。
（３）アプリケーション情報登録プリミティブ（ＷＭＥ-ApplicationRegistration）
　実施の形態１のＡＣＭＬ-RegistrationプリミティブおよびＡＣＭＬ-Deregistrationプリミティブと同等の機能、パラメータを提供する。ＷＭＥ-ApplicationRegistrationプリミティブは、アプリケーション情報の登録や削除を行うプリミティブである。
（４）ＷＭＥ情報取得プリミティブ（ＷＭＥ-Get）
　実施の形態１のＡＣＭＬ-Getプリミティブと同等の機能、パラメータを提供する。ＷＭＥ-Getプリミティブは、アプリケーションがＷＭＥの管理する情報を取得するためのプリミティブである。
（５）ＷＭＥ情報設定プリミティブ（ＷＭＥ-Set）
　実施の形態１のＡＣＭＬ-Setプリミティブと同等の機能、パラメータを提供する。ＷＭＥ-Setプリミティブは、アプリケーションがＷＭＥの管理する情報を設定するためのプリミティブである。
（６）受信電力要求プリミティブ（ＷＭＥ-RCPIREQUEST）
　実施の形態１ではサポートしていないプリミティブである。ＷＭＥ-RCPIREQUESTプリミティブは、アプリケーションが特定の車両に対して、受信電力を測定するためのデータ送信を要求するプリミティブである。
　＜Ｄ－２－２．ＣＴＬとＷＳＭＰとのＳＡＰ（ＬＳＡＰ）＞
　ＣＴＬはＷＳＭＰに対して、図７７に示すように次の１種類のプリミティブを提供する。また、ＬＳＡＰはデータリンク層がＡＣＴＬに提供するプリミティブでもあるため、ＣＴＬを挿入してもＩＥＥＥ１６０９．３の通信には影響を与えない。
（１）データ転送プリミティブ（ＵＬ-ＵＮＩＴＤＡＴＡ）
　実施の形態１のSendDataプリミティブと同等の機能、パラメータを提供する。ＵＬ-ＵＮＩＴＤＡＴＡプリミティブは、ＷＳＭＰがＣＴＬに対して、データ送受信を行うためのプリミティブである。
　以上のように、ＳＡＰの名前は実施の形態１と異なるが、図７７に示すＳＡＰに置き換えることにより、ＩＥＥＥ１６０９．３を利用した場合でも、本発明のＣＴＬおよびＣＭＬが提供するデータ転送サービス、イベント通知サービス、優先度制御サービス、輻輳制御サービス、接続管理サービス、およびデータ再送サービスを提供することが可能となる。
　＜Ｄ－３．車載通信装置１０３の動作＞
　アプリケーション処理部３がデータを送信する場合、送信するデータはＷＡＶＥ転送部８に渡す。
　ＷＡＶＥ転送部８は、アプリケーション処理部３から渡されたデータに、アプリケーションの種類、提供可能なアプリケーションリスト、利用可能な周波数チャネル情報などを含むＷＳＭヘッダを付与して、車々間通信転送サービス処理部１に渡す。
　車々間通信転送サービス処理部１は、ＷＳＭヘッダからアプリケーションの種類を取得し、該当するアプリケーションの優先度を車々間通信管理サービス処理部２およびＷＡＶＥ管理部１０から取得する。車々間通信転送サービス処理部１はＣ２Ｃヘッダを付与した後、優先度制御サービス処理部に渡して優先度制御を行い、送受信サービス処理部６を経由してデータを周辺局に送信する。
　車々間通信転送サービス処理部１内でエラーやイベントが発生した場合、ＣＭＣＴＬ-EventReportプリミティブを用いて、車々間通信管理サービス処理部２を経由して、アプリケーション処理部３にイベント情報を通知する。
　アプリケーション処理部３が初期接続を要求する場合、ＷＡＶＥ管理部１０の提供するＷＭＥ-Applicationプリミティブを利用して、接続管理サービスを実施する。
　また、ＷＭＥ-Applicationプリミティブに初期接続の種類を選択するパラメータを追加した場合には、ＷＡＶＥ管理部１０の機能を用いて初期接続を行うこともできるし、車々間通信管理サービス処理部２の機能を用いて初期接続を行うこともできる。
　アプリケーション処理部３は、提供可能な状態になったアプリケーションの情報を、ＷＭＥ-ApplicationRegistrationプリミティブを用いてＷＡＶＥ管理部１０に登録し、提供不可能な状態になった場合は同プリミティブを用いてＷＡＶＥ管理部１０から削除する。
　＜Ｄ－４．効果＞
　以上説明したように、実施の形態４のプロトコル構成を有する車載通信装置１０３は、ＷＡＶＥ転送部９およびＷＡＶＥ管理部１０を備えることにより、ＩＥＥＥのプロトコルを用いた場合の車載通信装置においても、実施の形態１のプロトコル構成の車載通信装置１００と同様に、路車間通信システムと車々間通信システムの両方にサービスを提供できる車載通信装置を得ることが可能となる。
　また、ＩＥＥＥプロトコルを用いた車載装置に車々間通信転送サービス処理部１および車々間通信管理サービス処理部２を備えることにより、ＩＥＥＥプロトコルでは提供できなかった輻輳制御サービスを実現することができる。
　＜Ｅ．実施の形態５＞
　＜Ｅ－１．プロトコル構成＞
　本発明に係る実施の形態５について、図７８～図８０を用いて説明する。なお、実施の形態１と同一の部位には同一の符号を付し、重複する詳細な説明は省略する。
　図７８は本発明に係る実施の形態５の車載通信装置１０４の構成を示すブロック図である。図７８に示すように、車載通信装置１０４は図１を用いて説明した実施の形態１の車載通信装置１００とほぼ同じ構成であるが、トランザクション管理部４と転送サービス処理部５が、ＣＡＬＭ（Communication Access for Land Mobiles）転送部１１１に置き換わっている点と、車々間通信管理サービス処理部２がＣＡＬＭ管理部１１２に含まれている点が、実施の形態１の車載通信装置１００と異なっている。
　ＣＡＬＭ転送部１１１は、ＣＡＬＭのＦＡＳＴ、Ｇｅｏ-Routing、およびＬＰＴＰ（Local Port Transport Protocol）と呼ばれるプロトコルで構成されており、アプリケーション処理部３の要求に従ってデータを送信するサービスを提供したり、宛先車両までデータを届ける経路探索サービスを提供する。
　ＣＡＬＭ管理部１１２は、ＣＡＬＭのＣＭＥ（CALM Management Entity）と呼ばれる管理層であり、アプリケーション処理部３の要求に応じて接続管理サービスを提供したり、アプリケーションに対してＣＭＥの管理するデータの設定／取得を行う情報アクセスサービスを提供する。
　実施の形態１の図３に示した構成では、日本の路車間通信規格であるトランザクション管理部４（ＬＰＰ）と、転送サービス処理部５（ＬＰＣＰ）とで構成される階層構造を示したが、図７８に示すように、実施の形態５の構成ではヨーロッパで検討されている路車間通信および車々間通信規格であるＣＡＬＭのプロトコルのネットワーク層、トランスポート層、および管理層を利用した構成である。
　また、実施の形態１の図３の構成の車々間通信管理サービス処理部２は、ＣＡＬＭの管理部ＣＭＥと同じように配置されているため、実施の形態５の図７８の構成では、車々間通信管理サービス処理部２をＣＭＥに含めている。
　実施の形態５の送受信サービス処理部６は、ＩＥＥＥ８０２．１１ｐや無線ＬＡＮなどを想定し、周辺局に搭載された車載通信装置１０４と無線通信を行う。
　また、実施の形態５の送受信サービス管理部７は、ＣＡＬＭのＩＭＥ（Interface Management Entity）と呼ばれる管理層を利用する。
　また、実施の形態５の車々間通信転送サービス処理部１は、ＣＡＬＭ転送部１１１と送受信サービス処理部６との間に存在し、ＣＡＬＭ転送部１１１やＣＡＬＭ管理部１１２に対してデータ転送サービスおよび優先度制御サービスを提供する。さらに、ＣＡＬＭ管理部１１２に対して、イベント通知サービスを提供する。
　また、実施の形態５の車々間通信管理サービス処理部２は、ＣＡＬＭ管理部１１２の内部に存在し、アプリケーション処理部３や車々間通信転送サービス処理部１に対して、輻輳制御サービス、接続管理サービス、およびデータ再送サービスを提供する。また、ＣＡＬＭ管理部１１２は送受信サービス管理部７の機能を拡張する。
　＜Ｅ－２．サービスインタフェース（ＳＡＰ）＞
　図７９は本発明に係る実施の形態５の車々間通信アーキテクチャのプロトコル構成におけるＳＡＰの位置を示した図である。図７９におけるサービスインタフェースのうち、実施の形態１と異なるＳＡＰの一覧を図８０に示す。実施の形態１と同じＳＡＰについては図１８に示したＳＡＰと同等の機能であるため、重複する説明は省略する。
　また、図８０に示すＳＡＰのパラメータは、ＣＡＬＭのプロトコル、ＩＥＥＥのプロトコルの双方において規格が成立していないが、ドラフト段階の概要を知ることはでき、それによれば、両プロトコルともに、本願発明と同種のＳＡＰパラメータを有するため、規格が未確定でも本願発明の適用は可能である。
　例えば、Ａ-Command（またはＡ-Request）を用いる場合、ＳＡＰパラメータとしてCommandNoとCommandValue（RequestNoとRequestValue）を指定するのに対し、本願では、コマンドやリクエストごとに、ＡＣＭＬ-Connect、ＡＣＭＬ-Notify、ＡＣＭＬ-Registration、ＡＣＭＬ-Deregistrationを規定することで対応するものとしている。
　また、本願では、ＡＣＭＬ-SetおよびＡＣＭＬ-Getに対して、それぞれmibIndexおよびmibParameterを指定してデータの設定および取得を行うのに対して、Ａ-SetParamおよびＡ-GetParamに対しては、ParamNoおよびParamValueに置き換えて実現することを想定しているので、規格が未確定でも対応することが可能である。以下、具体的に説明する。
　実施の形態１で示した図１８のＣＭＣＴＬ　ＳＡＰは、実施の形態５と同じＳＡＰであるためそのまま利用することが可能であるが、図１８のＡＣＭＬ　ＳＡＰ、ＣＴＬ　ＳＡＰ、ＭＬＭＥ　ＳＡＰ、およびＰＬＭＥ　ＳＡＰは、実施の形態５とＳＡＰが異なるため、実施の形態１をそのまま適用することができない。そこで、図７９に示されるプロトコル構成の場合、ＣＡＬＭネットワーク層／トランスポート層およびＣＭＥが提供するインタフェースに合わせるために、ＡＣＭＬ　ＳＡＰはＡ－ＳＡＰに置換し、ＣＴＬ　ＳＡＰはＣ－ＳＡＰに置換し、ＰＬＭＥ　ＳＡＰとＰＬＭＥ　ＳＡＰはＭ－ＳＡＰに置換している。
　＜Ｅ－２－１．アプリケーションとＣＭＥとのＳＡＰ（Ａ－ＳＡＰ）＞
　ＣＭＥはアプリケーションに対して、図８０に示すように次の４種類のプリミティブを提供する。
（１）コマンド実行プリミティブ（Ａ-Command）
　実施の形態１のＡＣＭＬ-Connect、ＡＣＭＬ-Notify、ＡＣＭＬ-Registration、ＡＣＭＬ-Deregistrationの各プリミティブと同等の機能、パラメータを提供し、各種コマンドの実行をＣＡＬＭ転送部１１１およびＣＡＬＭ管理部１１２に対して要求する。
（２）リクエスト実行プリミティブ（Ａ-Request）
　実施の形態１のＡＣＭＬ-Connect、ＡＣＭＬ-Notify、ＡＣＭＬ-Registration、ＡＣＭＬ-Deregistrationの各プリミティブと同等の機能、パラメータを提供し、各種リクエストの実行をＣＡＬＭ転送部１１１およびＣＡＬＭ管理部１１２に対して要求する。
（３）ＣＭＥ情報取得プリミティブ（Ａ-GetParam）
　実施の形態１のＡＣＭＬ-Getプリミティブと同等の機能、パラメータを提供し、ＣＭＥの有する情報を取得するプリミティブである。
（４）ＣＭＥ情報設定プリミティブ（Ａ-SetParam）
　実施の形態１のＡＣＭＬ-Setプリミティブと同等の機能、パラメータを提供し、ＣＭＥに対して情報を設定するプリミティブである。
　＜Ｅ－２－２．ＣＴＬとＣＡＬＭネットワーク層／トランスポート層とのＳＡＰ（Ｃ－ＳＡＰ）＞
　ＣＴＬはＣＡＬＭ転送部１１１に対して、図８０に示すように次の１種類のプリミティブを提供する。また、Ｃ－ＳＡＰはデータリンク層がＣＡＬＭ転送部１１１に提供するプリミティブでもあるため、ＣＴＬを挿入してもＣＡＬＭ転送部１１１の通信には影響を与えない。
（１）データ転送プリミティブ（ＵＬ-ＵＮＩＴＤＡＴＡ）
　実施の形態１のSendDataプリミティブと同等の機能、パラメータを提供する。ＵＬ-ＵＮＩＴＤＡＴＡプリミティブは、ＣＡＬＭ転送部１１１がＣＴＬに対して、データ送受信を行うためのプリミティブである。
　＜Ｅ－２－３．ＣＭＥとＩＭＥとのＳＡＰ（Ｍ－ＳＡＰ）＞
　ＣＭＥはＩＭＥに対して、図８０に示すように次の２種類のプリミティブを提供する。
（１）ＩＭＥ情報取得プリミティブ（ＣＩＭＡＥ-SetParam）
　実施の形態１のＭＬＭＥ-SetおよびＰＬＭＥ-Setプリミティブと同等の機能、パラメータを提供し、ＩＭＥの有する情報を取得するプリミティブである。
（２）ＩＭＥ情報設定プリミティブ（ＣＩＭＡＥ-GetParam）
　実施の形態１のＭＬＭＥ-GetプリミティブおよびＰＬＭＥ-Getプリミティブと同等の機能、パラメータを提供し、ＩＭＥに対して情報を設定するプリミティブである。
　以上のように、ＳＡＰの名前は実施の形態１と異なるが、図８０に示すＳＡＰを用いることにより、ＣＡＬＭ転送部１１１およびＣＡＬＭ管理部１１２を利用した場合でも、本発明のＣＴＬおよびＣＭＬが提供する機能を実現することが可能となる。
　＜Ｅ－３．車載通信装置１０４の動作＞
　アプリケーション処理部３がデータを送信する場合、送信するデータはＣＡＬＭ転送部１１１に渡され、ＣＡＬＭ転送部１１１はアプリケーションの種類、提供可能なアプリケーションリスト、利用可能な通信メディア情報などを含むＣＡＬＭヘッダを付与して、車々間通信転送サービス処理部１に渡す。
　車々間通信転送サービス処理部１は、ＣＡＬＭヘッダからアプリケーションの種類を取得し、該当するアプリケーションの優先度を車々間通信管理サービス処理部２およびＣＡＬＭ管理部１１２から取得する。車々間通信転送サービス処理部１はＣ２Ｃヘッダを付与した後、優先度制御サービス処理部に渡して優先度制御を行い、送受信サービス処理部６からデータを送信する。
　車々間通信転送サービス処理部１内でエラーやイベントが発生した場合、ＣＭＣＴＬ-EventReportプリミティブを用いて、車々間通信管理サービス処理部２を経由して、アプリケーション処理部３にイベント情報を通知する。
　アプリケーション処理部３が初期接続を要求する場合、ＣＡＬＭ管理部１１２の提供するＡ-CommandプリミティブやＡ-Requestプリミティブを利用して、接続管理サービスを実施する。
　また、Ａ-CommandプリミティブやＡ-Requestプリミティブに初期接続の種類を選択するパラメータを追加した場合には、ＣＡＬＭ管理部１１２の機能を用いて初期接続を行うこともできるし、車々間通信管理サービス処理部２の機能を用いて初期接続を行うこともできる。
　アプリケーション処理部３は、提供可能な状態になったアプリケーションの情報を、Ａ-SetParamプリミティブを用いてＣＡＬＭ管理部１１２に登録し、提供不可能な状態になった場合は同プリミティブを用いてＣＡＬＭ管理部１１２から削除する。
　＜Ｅ－４．効果＞
　以上説明したように、実施の形態５のプロトコル構成を有する車載通信装置１０４は、ＣＡＬＭ転送部１１１およびＣＡＬＭ管理部１１２を備えることにより、ＣＡＬＭのプロトコルを用いた場合の車載通信装置においても、実施の形態１のプロトコル構成の車載通信装置１００と同様に、路車間通信システムと車々間通信システムの両方にサービスを提供できる車載通信装置を得ることが可能となる。
　また、ＣＡＬＭプロトコルを用いた車載装置に車々間通信転送サービス処理部１および車々間通信管理サービス処理部２を備えることにより、ＣＡＬＭプロトコルでは提供できなかった輻輳制御サービスを実現することができる。
　この発明は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、この発明がそれに限定されるものではない。例示されていない無数の変形例が、この発明の範囲から外れることなく想定され得るものと解される。

Claims (12)

  1. 移動局および基地局にそれぞれ搭載され、無線通信により前記移動局間および前記移動局と前記基地局との間で相互に受信側および送信側となる車載通信装置であって、
    　前記車載通信装置は、
    　前記受信側の前記車載通信装置に周期的にメッセージを送信するアプリケーション処理部と、
    　前記アプリケーション処理部に接続され、前記アプリケーション処理部から受信した前記メッセージの再送や分割／組み立てを含むトランザクションサービスを少なくとも提供するトランザクション管理部と、
    　前記トランザクション管理部に接続され、前記トランザクション管理部から受信した前記メッセージに、前記アプリケーション処理部を含む上位プロトコルを識別するためのローカルポート番号を付加する転送サービス処理部と、
    　前記転送サービス処理部に接続され、前記転送サービス処理部から受信した前記メッセージを、前記アプリケーション処理部で処理されるアプリケーションの優先度順に前記受信側の前記車載通信装置に対して送信し、前記転送サービス処理部に対する前記メッセージを送受信し、エラー情報を含むイベント情報を通知する車々間通信転送サービス処理部と、
    　前記車々間通信転送サービス処理部に接続され、前記車々間通信転送サービス処理部から受信した前記メッセージを、無線通信により前記受信側の前記車載通信装置との間で送受信する送受信サービス処理部と、
    　前記アプリケーション処理部および前記車々間通信転送サービス処理部に接続され、前記アプリケーション処理部から前記優先度を設定され、前記車々間通信転送サービス処理部からの要求に応じて前記優先度を通知する車々間通信管理サービス処理部とを備え、
    　前記トランザクション管理部および前記転送サービス処理部は、前記移動局と前記基地局との間での路車間通信を行うための路車間通信プロトコルを構成し、
    　前記車々間通信転送サービス処理部は、前記受信側の前記車載通信装置に対して前記車々間通信管理サービス処理部の有する通信制御情報を通知し、
    　前記受信側の前記車載通信装置は、
    　前記車々間通信転送サービス処理部において、受信した前記メッセージに付与された前記通信制御情報を前記車々間通信管理サービス処理部に送信し、受信した前記メッセージは前記転送サービス処理部に送信される、車載通信装置。
  2. 前記送受信サービス処理部が、前記メッセージを送受信する際の送信電力、受信感度および通信チャネルの利用率を少なくとも含む前記通信制御情報を管理する送受信サービス管理部をさらに備え、
    　前記車々間通信管理サービス処理部は、
    　前記送受信サービス管理部との間に設けられ、前記送受信サービス管理部からの前記通信チャネルの利用率の取得、前記送受信サービス管理部に対する前記送信電力および前記受信感度の設定のための第１のインタフェースと、
    　前記車々間通信転送サービス処理部との間に設けられ、前記通信制御情報を前記車々間通信転送サービス処理部に与える第２のインタフェースと、
    　前記アプリケーション処理部との間に設けられ、周期的に送信される前記メッセージの送信周期を設定するための第３のインタフェースと、を有し、
    　前記アプリケーション処理部は前記車々間通信管理サービス処理部を経由して、前記車々間通信転送サービス部に対する前記イベント情報の通知、前記受信側の前記送信周期、前記送信電力および前記受信感度を指定するメッセージの送信要求、前記送受信サービス管理部に対する前記送信電力および前記受信感度の設定を行う、請求項１記載の車載通信装置。
  3. 前記車々間通信転送サービス処理部は、
    　前記車々間通信管理サービス処理部から取得した前記送信電力、前記受信感度および前記通信チャネルの利用率に前記送信周期の情報を加えて前記通信制御情報とし、前記転送サービス処理部から受信した前記メッセージに付加することで、前記受信側の前記車載通信装置に対して前記通信制御情報を通知し、
    　前記受信側の前記車々間通信管理サービス処理部は、前記送信側の前記通信制御情報に基づいて、前記受信側の前記アプリケーション処理部からのメッセージを送信する際の送信電力、受信感度、送信周期を決定する、請求項２記載の車載通信装置。
  4. 前記送信側の前記車載通信装置の前記車々間通信管理サービス処理部は、
    　前記受信側の前記車載通信装置との初期接続を行うためのメッセージを、前記アプリケーション処理部からの要求に応じて、前記車々間通信転送サービス処理部を経由して受信側の前記車々間通信管理サービス処理部に対して送信開始する、請求項１記載の車載通信装置。
  5. 前記車々間通信管理サービス処理部は、
    　前記車々間通信転送サービス処理部を経由して、前記トランザクション管理部および前記アプリケーション処理部を含む上位プロトコルに対して、通信接続の状況および前記車々間通信管理サービス処理部内で発生したイベント情報を少なくとも通知する、請求項１記載の車載通信装置。
  6. 前記受信側の前記車載通信装置の前記車々間通信転送サービス処理部は、
    　前記送信側の前記車載通信装置からの前記メッセージを受信し、前記メッセージに含まれる前記通信制御情報を前記車々間通信管理サービス処理部に設定し、
    　前記受信側の前記車載通信装置の前記車々間通信管理サービス処理部は、
    　前記通信制御情報が設定されることを契機に、前記送信側の前記車載通信装置に対して初期接続の接続手順を開始する請求項１記載の車載通信装置。
  7. 前記アプリケーション処理部は、
    　アプリケーションの種類を前記車々間通信管理サービス処理部に登録し、
    　前記車々間通信転送サービス処理部は、
    　前記メッセージに付加されたローカルポート番号を利用して、前記車々間通信管理サービス処理部から前記アプリケーションの種類を取得し、識別することにより、前記アプリケーションの種類に応じた送受信処理を行い、路車間通信アプリケーションの場合には前記メッセージを車々間通信アプリケーションよりも優先的に前記送受信サービス処理部に送信する、請求項１記載の車載通信装置。
  8. 移動局および基地局にそれぞれ搭載され、無線通信により前記移動局間および前記移動局と前記基地局との間で相互に受信側および送信側となる車載通信装置であって、
    　前記車載通信装置は、
    　前記送信側から前記受信側に対して、路車間通信および車々間通信を利用してメッセージを送信するアプリケーション処理部と、
    　前記アプリケーション処理部から受信した前記メッセージの再送や分割／組み立てを含むトランザクションサービス、前記アプリケーション処理部を含む上位プロトコルを識別するためのローカルポート番号の付加、および前記上位プロトコルに応じて前記メッセージの送信先を判別する路車間－車々間通信連携サービス処理部と、
    　前記路車間－車々間通信連携サービス処理部から受信した前記メッセージを、前記アプリケーション処理部で処理されるアプリケーションの優先度順に前記受信側の前記車載通信装置に対して送信する車々間通信転送サービス処理部と、
    　前記車々間通信転送サービス処理部を介して与えられる前記メッセージ、および前記路車間－車々間通信連携サービス処理部から直接与えられる前記メッセージに、識別のための識別子を付与して、無線通信により前記受信側の前記車載通信装置に送信する送受信サービス処理部と、
    　前記アプリケーション処理部から前記優先度を設定され、前記車々間通信転送サービス処理部からの要求に応じて前記優先度を通知する車々間通信管理サービス処理部とを備え、
    　前記路車間－車々間通信連携サービス処理部は、
    　前記アプリケーション処理部から受信した前記メッセージを、路車間通信で送信するか、車々間通信で送信するかを判別し、前記路車間通信の場合には前記送受信サービス処理部に直接前記メッセージを与え、前記車々間通信の場合には前記車々間通信転送サービス処理部を経由して前記送受信サービス処理部に与え、
    　前記受信側の前記車載通信装置の前記送受信サービス処理部は、
    　前記送信側の前記車載通信装置から受信した前記メッセージに付与された前記識別子に基づき、前記メッセージを、路車間－車々間通信連携サービス処理部または車々間通信転送サービス処理部に送信する車載通信装置。
  9. 前記車々間通信転送サービス処理部は、路車間通信アプリケーションのメッセージを受信したことを、前記車々間通信管理サービス処理部に通知し、
    　前記車々間通信管理サービス処理部は、前記路車間通信アプリケーションのメッセージの受信を契機に、車々間通信アプリケーションのメッセージを送信する際の前記送信電力および前記送信周期を制御することにより、路車間通信アプリケーションのメッセージを優先的に送受信する、請求項１記載の車載通信装置。
  10. 移動局および基地局にそれぞれ搭載され、無線通信により前記移動局間および前記移動局と前記基地局との間で相互に受信側および送信側となる車載通信装置であって、
    　前記車載通信装置は、
    　アプリケーションから受信したメッセージを、アプリケーションの優先度順に前記受信側の前記車載通信装置に対して送信し、アプリケーションに対するメッセージを送受信し、エラー情報を含むイベント情報を通知し、送信電力、受信感度、通信チャネルの利用率に送信周期の情報を加えて通信制御情報とし、アプリケーションから受信したメッセージに付加することにより前記受信側の前記車載通信装置に対して前記通信制御情報を通知する車々間通信転送サービス処理部と、
    　アプリケーションおよび前記車々間通信転送サービス処理部に接続され、アプリケーションから優先度を設定され、前記車々間通信転送サービス処理部からの要求に応じて前記優先度を通知し、前記通信制御情報に基づいてメッセージを送信する際の送信電力、受信感度、送信周期を決定および設定し、前記車載通信装置との初期接続を行うためのメッセージをアプリケーションからの要求に応じて、前記車々間通信転送サービス処理部を経由して前記受信側の前記車々間通信管理サービス処理部に対して送信する車々間通信管理サービス処理部とを備え、
    　前記車々間通信転送サービス処理部は、前記受信側の前記車載通信装置に対して前記車々間通信管理サービス処理部の有する通信制御情報を通知し、
    　前記受信側の前記車載通信装置は、
    　前記車々間通信転送サービス処理部において、受信した前記メッセージに付与された前記通信制御情報を前記車々間通信管理サービス処理部に送信し、受信した前記メッセージをアプリケーションに送信する、車載通信装置。
  11. 移動局および基地局にそれぞれ搭載され、無線通信により前記移動局間および前記移動局と前記基地局との間で相互に受信側および送信側となる車載通信装置であって、
    　前記車載通信装置は、
    　前記受信側の前記車載通信装置に周期的にメッセージを送信するアプリケーション処理部と、
    　前記アプリケーション処理部に接続され、前記アプリケーション処理部から受信した前記メッセージの送信を行うとともに、前記アプリケーション処理部から受信した前記メッセージに、前記アプリケーション処理部を含む上位プロトコルを識別するためのアプリケーション番号や提供可能なアプリケーション一覧および利用可能な周波数チャネル情報を付与する転送部と、
    　前記転送部に接続され、前記転送部から受信した前記メッセージを、前記アプリケーション処理部で処理されるアプリケーションの優先度順に前記受信側の前記車載通信装置に対して送信し、前記転送部に対する前記メッセージを送受信し、エラー情報を含むイベント情報を通知し、送信電力、受信感度、通信チャネルの利用率に送信周期の情報を加えて通信制御情報とし、アプリケーションから受信したメッセージに付加することにより前記受信側の前記車載通信装置に対して前記通信制御情報を通知する車々間通信転送サービス処理部と、
    　前記車々間通信転送サービス処理部に接続され、前記車々間通信転送サービス処理部から受信した前記メッセージを、無線通信により前記受信側の前記車載通信装置との間で送受信する送受信サービス処理部と、
    　前記送受信サービス処理部が、前記メッセージを送受信する際の送信電力、受信感度および通信チャネルの利用率を少なくとも含む前記通信制御情報を管理する送受信サービス管理部と、
    　前記アプリケーション処理部と前記車々間通信転送サービス処理部と前記送受信サービス管理部に接続され、前記アプリケーション処理部の情報を管理するとともに、前記アプリケーションの要求に応じて接続管理サービスを開始する管理部とを備え、
    　前記管理部は、
    　前記アプリケーション処理部から前記優先度を設定され、前記車々間通信転送サービス処理部からの要求に応じて前記優先度を通知し、前記通信制御情報に基づいてメッセージを送信する際の送信電力、受信感度、送信周期を決定または設定する車々間通信管理サービス処理部を含み、
    　前記転送部および前記管理部は、前記移動局と前記基地局との間での路車間通信および車々間通信を行うためのプロトコルを構成し、
    　前記車々間通信転送サービス処理部は、前記受信側の前記車載通信装置に対して前記車々間通信管理サービス処理部の有する前記通信制御情報を通知し、
    　前記受信側の前記車載通信装置は、
    　前記車々間通信転送サービス処理部において、受信した前記メッセージに付与された前記通信制御情報を前記車々間通信管理サービス処理部に送信し、受信した前記メッセージは前記転送部に送信される、車載通信装置。
  12. 請求項１、請求項８、請求項１０および請求項１１の何れかに記載の車載通信装置により構成され、前記移動局間および前記移動局と前記基地局との間での無線通信を行う、路車間－車々間通信連携システム。
PCT/JP2009/056057 2008-04-30 2009-03-26 車載通信装置および路車間－車々間通信連携システム Ceased WO2009133740A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE112009001028.8T DE112009001028B4 (de) 2008-04-30 2009-03-26 Verfahren zur Bordkommunikation, Bordkommunikationsvorrichtung und Kooperatives Strasse-Fahrzeug/Auto-Auto Kommunikationssystem
CN2009801204592A CN102047698B (zh) 2008-04-30 2009-03-26 车载通信装置以及路车间-车车间通信协作系统
US12/937,605 US8412107B2 (en) 2008-04-30 2009-03-26 On-board communication device and cooperative road-to-vehicle/car-to-car communication system
JP2010510064A JP4999989B2 (ja) 2008-04-30 2009-03-26 車載通信装置および路車間−車々間通信連携システム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2008118689 2008-04-30
JP2008-118689 2008-04-30

Publications (1)

Publication Number Publication Date
WO2009133740A1 true WO2009133740A1 (ja) 2009-11-05

Family

ID=41254963

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/056057 Ceased WO2009133740A1 (ja) 2008-04-30 2009-03-26 車載通信装置および路車間－車々間通信連携システム

Country Status (5)

Country Link
US (1) US8412107B2 (ja)
JP (1) JP4999989B2 (ja)
CN (1) CN102047698B (ja)
DE (1) DE112009001028B4 (ja)
WO (1) WO2009133740A1 (ja)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011249858A (ja) * 2010-04-30 2011-12-08 Ntt Docomo Inc 端末装置、基地局装置、移動通信システム、及び送信モード設定方法
WO2013136748A1 (ja) * 2012-03-12 2013-09-19 パナソニック株式会社 無線装置
WO2014002438A1 (ja) * 2012-06-29 2014-01-03 パナソニック株式会社 端末装置
WO2014017503A1 (ja) * 2012-07-27 2014-01-30 京セラ株式会社 移動通信システム、移動通信システムで用いる移動通信方法
JP2014049911A (ja) * 2012-08-30 2014-03-17 Panasonic Corp 無線装置
JP2014241653A (ja) * 2014-10-02 2014-12-25 日本電気株式会社 移動体無線通信装置および輻輳制御方法
US9313749B2 (en) 2010-09-27 2016-04-12 Nec Corporation Vehicle-mounted device and congestion control method
JP6141564B1 (ja) * 2016-09-21 2017-06-07 三菱電機株式会社 路側通信装置および車載通信装置
JP2019022022A (ja) * 2017-07-13 2019-02-07 株式会社Ｓｏｋｅｎ 車載通信装置および移動体通信システム
JP2020162057A (ja) * 2019-03-27 2020-10-01 パナソニックＩｐマネジメント株式会社 無線通信装置、路側機および無線通信方法
JP2022501854A (ja) * 2018-09-28 2022-01-06 コンティネンタル・テーベス・アクチエンゲゼルシヤフト・ウント・コンパニー・オッフェネ・ハンデルスゲゼルシヤフト 車対ｘメッセージのフィルタリング方法、車対ｘ通信装置およびコンピュータ可読記録媒体

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2415242B1 (de) * 2009-04-03 2019-05-08 Continental Teves AG & Co. OHG Datensicherheit für die kommunikation mit gleichgestellten teilnehmern
EP2444290A4 (en) * 2009-06-19 2012-12-12 Bosch Corp BRAKE REGULATOR DEVICE FOR VEHICLE
US10368318B2 (en) * 2010-12-30 2019-07-30 Telefonaktiebolaget Lm Ericsson (Publ) Wireless operation in very high density environments
US8863256B1 (en) 2011-01-14 2014-10-14 Cisco Technology, Inc. System and method for enabling secure transactions using flexible identity management in a vehicular environment
US9485114B2 (en) * 2011-03-25 2016-11-01 Mediatek Inc. MAC abstraction sub-layer and MAC table for a communication system and related communication device
DE102011018572A1 (de) * 2011-04-26 2012-10-31 Continental Automotive Gmbh Verfahren zur Anzeige der Funktionsfähigkeit der Fahrzeug-zu-Umgebung-Kommunikation in ISM-Funkbändern
EP2650856B1 (en) * 2011-05-12 2016-11-30 Toyota Jidosha Kabushiki Kaisha Road-to-vehicle communication system and driving support system
EP2552136B1 (en) * 2011-07-28 2018-09-05 Gemalto M2M GmbH Communication method of broadcast at a localized area of a location of an infrastructure facility, communication system, communication module, localized broadcast data structure and application layer computer program
DE102012200126A1 (de) * 2012-01-05 2013-07-11 Robert Bosch Gmbh Fahrerassistenzdienst
DE102012003776B3 (de) 2012-02-25 2013-07-25 Volkswagen Ag Verfahren zum Identifizieren eines Fahrzeugs bei einer Fahrzeug-zu-Fahrzeug-Kommunikation
US8704679B2 (en) * 2012-06-27 2014-04-22 GM Global Technology Operations LLC Framework for packet processing for secure V2V applications on resource-constrained platforms
JP6204021B2 (ja) * 2013-01-28 2017-09-27 三菱重工メカトロシステムズ株式会社 車載器
US9280897B2 (en) * 2013-07-11 2016-03-08 Siemens Industry, Inc. Emergency traffic management system
WO2015019234A1 (en) 2013-08-05 2015-02-12 Universidade De Aveiro Method and apparatus for multi-network communication in vehicular networks
JP6026012B2 (ja) * 2013-11-18 2016-11-16 三菱電機株式会社 車車間通信装置
JP5935818B2 (ja) * 2014-01-17 2016-06-15 株式会社デンソー 車両用無線機及び通信システム
CN104066124B (zh) * 2014-02-27 2017-06-20 浙江浙大中控信息技术有限公司 一种车联网传输速率自适应控制装置及控制方法
US20150195765A1 (en) * 2014-03-25 2015-07-09 Sanjay Bhardwaj Method, Apparatus and System for Connected Automobiles
CN104134345B (zh) * 2014-07-25 2015-06-03 赵立 一种车辆稽查无线通讯防碰撞方法
JP6398739B2 (ja) * 2015-01-19 2018-10-03 株式会社デンソー 車載機、車載機診断システム
KR20160107636A (ko) * 2015-03-04 2016-09-19 엘지전자 주식회사 차량 사고 방지를 위한 장치 및 그의 동작 방법
DE102015209463A1 (de) * 2015-05-22 2016-11-24 Continental Automotive Gmbh Verfahren zur Detektion eines DRSC-Signals in einem Kraftfahrzeug
US10206076B2 (en) * 2015-06-09 2019-02-12 Lg Electronics Inc. Communication method for user equipment in V2X communication system, and user equipment
US9773411B2 (en) 2015-10-31 2017-09-26 Steven Cameron Popple Vehicle-to-vehicle and traffic signal-to-vehicle communication system
JP6191971B2 (ja) * 2015-12-18 2017-09-06 パナソニックＩｐマネジメント株式会社 歩行者端末装置、車載端末装置、歩車間通信制御装置、歩車間通信システムおよび歩車間通信方法
DE102016205142A1 (de) * 2016-03-29 2017-10-05 Volkswagen Aktiengesellschaft Verfahren, Vorrichtungen und Computerprogramm zum Initiieren oder Durchführen eines kooperativen Fahrmanövers
AR108456A1 (es) * 2016-05-13 2018-08-22 Ericsson Telefon Ab L M Retransmisión de paquetes en un sistema de comunicaciones inalámbricas
US9940142B2 (en) 2016-05-20 2018-04-10 At&T Mobility Ii Llc Connected car resource manager with associated applications control
DE102016210092B4 (de) * 2016-06-08 2023-05-04 Volkswagen Aktiengesellschaft Vorrichtung, Verfahren und Computerprogramm zum Erfassen und Übertragen von Daten
DE102016211750B4 (de) * 2016-06-29 2019-06-19 Volkswagen Aktiengesellschaft Verfahren zur spektral-effizienten Ermittlung von kollektiver Umfeld-Information für das kooperative und/oder autonome Fahren, sowie berichtendes Fahrzeug und weiteres Fahrzeug zur Verwendung bei dem Verfahren
US10424197B2 (en) * 2016-08-10 2019-09-24 Futurewei Technologies, Inc. Apparatus, computer program, and method for supporting vehicle-to-vehicle communication utilizing a base station
US10109120B2 (en) 2016-10-25 2018-10-23 International Business Machines Corporation Predicting vehicular failures using autonomous collaborative comparisons to detect anomalies
US10362509B2 (en) * 2016-12-09 2019-07-23 Redpine Signals, Inc. Incident broadcast retransmission in a vehicular network
US10171953B2 (en) * 2016-12-15 2019-01-01 At&T Mobility Ii Llc Vehicle event notification via cell broadcast
EP3592087A1 (en) * 2018-07-02 2020-01-08 Nxp B.V. Wireless vehicular communications according to vehicular communications protocols using reservation times
US10741070B1 (en) * 2019-03-04 2020-08-11 GM Global Technology Operations LLC Method to prioritize transmission of sensed objects for cooperative sensor sharing
CN110505601A (zh) * 2019-07-30 2019-11-26 大连理工大学 一种车联网中基于车辆行驶态势场模型的信息发送频率优化方法
US12211009B2 (en) * 2020-02-21 2025-01-28 Idsc Holdings Llc Method and system of providing cloud-based vehicle history session
DE102020120970A1 (de) 2020-08-10 2022-02-10 Audi Aktiengesellschaft Verfahren zum Übertragen einer Eilnachricht von einem Sendefahrzeug zu zumindest einem Empfängerfahrzeug über ein Funknetzwerk sowie Kraftfahrzeug, Sendeschaltung und Empfangsschaltung
CN113192348A (zh) * 2021-04-21 2021-07-30 支付宝(杭州)信息技术有限公司 车辆异常告警方法、装置及计算机设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005039075A1 (ja) * 2003-10-15 2005-04-28 Mitsubishi Denki Kabushiki Kaisha 路車間通信システム
JP2005286756A (ja) * 2004-03-30 2005-10-13 Toyota Motor Corp 移動体間通信経路選択方法、無線通信装置および移動体
JP2008011343A (ja) * 2006-06-30 2008-01-17 Oki Electric Ind Co Ltd 車々間通信システム及び車々間通信方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
JP4131056B2 (ja) * 1999-06-15 2008-08-13 株式会社デンソー 移動体通信装置および固定局通信装置ならびに移動体通信装置の通信方法
JP2006209333A (ja) 2005-01-26 2006-08-10 Toyota Central Res & Dev Lab Inc 危険度判定装置及び通信装置
US8294594B2 (en) * 2008-03-10 2012-10-23 Nissan North America, Inc. On-board vehicle warning system and vehicle driver warning method
US8233389B2 (en) * 2009-08-19 2012-07-31 Mitsubishi Electric Research Laboratories, Inc. Method and protocol for congestion control in a vehicular network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005039075A1 (ja) * 2003-10-15 2005-04-28 Mitsubishi Denki Kabushiki Kaisha 路車間通信システム
JP2005286756A (ja) * 2004-03-30 2005-10-13 Toyota Motor Corp 移動体間通信経路選択方法、無線通信装置および移動体
JP2008011343A (ja) * 2006-06-30 2008-01-17 Oki Electric Ind Co Ltd 車々間通信システム及び車々間通信方法

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9232477B2 (en) 2010-04-30 2016-01-05 Ntt Docomo, Inc. Terminal apparatus, base station apparatus, mobile communication system, and transmission mode setting method
JP2011249858A (ja) * 2010-04-30 2011-12-08 Ntt Docomo Inc 端末装置、基地局装置、移動通信システム、及び送信モード設定方法
US9420549B2 (en) 2010-09-27 2016-08-16 Nec Corporation Vehicle-mounted device and congestion control method
US9313749B2 (en) 2010-09-27 2016-04-12 Nec Corporation Vehicle-mounted device and congestion control method
US9451559B2 (en) 2010-09-27 2016-09-20 Nec Corporation Vehicle-mounted device and congestion control method
WO2013136748A1 (ja) * 2012-03-12 2013-09-19 パナソニック株式会社 無線装置
WO2014002438A1 (ja) * 2012-06-29 2014-01-03 パナソニック株式会社 端末装置
JPWO2014002438A1 (ja) * 2012-06-29 2016-05-30 パナソニックＩｐマネジメント株式会社 端末装置
WO2014017503A1 (ja) * 2012-07-27 2014-01-30 京セラ株式会社 移動通信システム、移動通信システムで用いる移動通信方法
US9973317B2 (en) 2012-07-27 2018-05-15 Kyocera Corporation Mobile communication system and mobile communication method used in a mobile communication system
US9515801B2 (en) 2012-07-27 2016-12-06 Kyocera Corporation Mobile communication system and mobile communication method used in a mobile communication system
JP2014049911A (ja) * 2012-08-30 2014-03-17 Panasonic Corp 無線装置
JP2014241653A (ja) * 2014-10-02 2014-12-25 日本電気株式会社 移動体無線通信装置および輻輳制御方法
JP6141564B1 (ja) * 2016-09-21 2017-06-07 三菱電機株式会社 路側通信装置および車載通信装置
WO2018055685A1 (ja) * 2016-09-21 2018-03-29 三菱電機株式会社 路側通信装置および車載通信装置
US10863332B2 (en) 2016-09-21 2020-12-08 Mitsubishi Electric Corporation Roadside communication apparatus and in-vehicle communication apparatus
JP2019022022A (ja) * 2017-07-13 2019-02-07 株式会社Ｓｏｋｅｎ 車載通信装置および移動体通信システム
JP2022501854A (ja) * 2018-09-28 2022-01-06 コンティネンタル・テーベス・アクチエンゲゼルシヤフト・ウント・コンパニー・オッフェネ・ハンデルスゲゼルシヤフト 車対ｘメッセージのフィルタリング方法、車対ｘ通信装置およびコンピュータ可読記録媒体
US11930387B2 (en) 2018-09-28 2024-03-12 Continental Teves Ag & Co. Ohg Method for filtering vehicle-to-X messages, vehicle-to-X communication device, and computer-readable storage medium
JP7473528B2 (ja) 2018-09-28 2024-04-23 コンティネンタル・テーベス・アクチエンゲゼルシヤフト・ウント・コンパニー・オッフェネ・ハンデルスゲゼルシヤフト 車対ｘメッセージのフィルタリング方法、車対ｘ通信装置およびコンピュータ可読記録媒体
JP2020162057A (ja) * 2019-03-27 2020-10-01 パナソニックＩｐマネジメント株式会社 無線通信装置、路側機および無線通信方法
WO2020195356A1 (ja) * 2019-03-27 2020-10-01 パナソニックＩｐマネジメント株式会社 無線通信装置、路側機および無線通信方法
JP7336732B2 (ja) 2019-03-27 2023-09-01 パナソニックＩｐマネジメント株式会社 無線通信装置、路側機および無線通信方法
US12335840B2 (en) 2019-03-27 2025-06-17 Panasonic Intellectual Property Management Co., Ltd. Wireless communication device, roadside unit, and wireless communication method

Also Published As

Publication number Publication date
JP4999989B2 (ja) 2012-08-15
CN102047698B (zh) 2013-06-19
JPWO2009133740A1 (ja) 2011-09-01
US20110034201A1 (en) 2011-02-10
DE112009001028B4 (de) 2017-05-04
CN102047698A (zh) 2011-05-04
US8412107B2 (en) 2013-04-02
DE112009001028T5 (de) 2011-04-28

Similar Documents

Publication Publication Date Title
JP4999989B2 (ja) 車載通信装置および路車間−車々間通信連携システム
US10440668B1 (en) Vehicle platooning management and power control with LTE/5G V2X communications
CN101611434B (zh) 车辆用通信装置
AU2014402993B2 (en) Method and apparatus for reporting terminal device capability
JP7468321B2 (ja) 通信制御装置、通信制御方法、及び中継サーバ
EP2474194B1 (en) Method for enabling mutli-channel signaling in a communication network
JP2010028636A (ja) 基地局、移動局、通信制御方法
EP4152828A1 (en) Method for establishing a relay bearer and communication apparatus
CN106603658B (zh) 一种基于软件定义网络的车联网数据传输方法和装置
CN110351686B (zh) 车联网数据传输系统中实施的方法、车载单元、以及车联网数据传输系统
KR101407280B1 (ko) 이동 통신 중계 시스템을 기반으로 하는 데이터 전송 방법 및 그 장치
CA2583927C (en) Arranging data transfer for mobile mine device
JP7537341B2 (ja) 車両用通信システム、中継サーバ、車両用通信機
JP3446028B2 (ja) 移動体通信システム
US11765711B2 (en) Unicast and groupcast transmissions over sidelink
JP6141564B1 (ja) 路側通信装置および車載通信装置
CN117917174A (zh) 管理侧行链路中继的方法和装置
EP4349042A1 (en) Hybrid quality of service flow
JP4117240B2 (ja) 無線移動通信システム
KR101335280B1 (ko) 유비쿼터스 차량센싱 통신망계층 라우팅 프로토콜 및 그 관리정보 베이스 설정방법
KR100438181B1 (ko) Ｄｓｒｃ 노변기지국의 신뢰성 있는 통신 제공을 위한프레임 데이터 생성 및 관리 방법
JP2026503826A (ja) Ｉａｂ通信システムにおけるノードのマイグレーション
KR20250069549A (ko) 무선 통신 시스템에서 메시지를 전송하는 방법 및 이를 위한 장치
JP2025522684A (ja) 無線通信システムにおけるネットワークコネクティビティの管理

Legal Events

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

Ref document number: 200980120459.2

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09738677

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010510064

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 12937605

Country of ref document: US

RET De translation (de og part 6b)

Ref document number: 112009001028

Country of ref document: DE

Date of ref document: 20110428

Kind code of ref document: P

122 Ep: pct application non-entry in european phase

Ref document number: 09738677

Country of ref document: EP

Kind code of ref document: A1