In-vehicle device, vehicle-to-vehicle communication method, and program

Abstract

To provide an in-vehicle device capable of reducing the cost required for information development, a vehicle-to-vehicle communication method, and a program.SOLUTION: An in-vehicle device 40 includes a 920 communication unit 11 serving as a local communication unit equipped with a concentrator 33, and an LTE communication unit 41 serving as a public communication unit. The local communication unit has a data propagation function which forms a multi-hop network with another in-vehicle device, develops data with the other in-vehicle device via the multi-hop network and share information with each other. The concentrator aggregates data from the other in-vehicle device via the multi-hop network to which the device belongs. The public communication unit transmits the aggregated data to a transmission destination via a public mobile communication network.SELECTED DRAWING: Figure 14

Description

[Technical Field]

[0001] An embodiment of the present invention relates to an in-vehicle device, a vehicle-to-vehicle communication method, and a program. [Background technology]

[0002] Systems that use in-vehicle devices to provide various services to users via a network have been put into practical use. In this type of system, the in-vehicle device is connected to a management center via a public communication network, such as 3G / LTE (registered trademark) (Long Term Evolution), and various types of information can be exchanged between the user and the management center. For example, information on wide-area accidents and construction work, weather information, vehicle inspection and regular maintenance notices, etc., are provided to the user. In addition, vehicle information, malfunction information, etc. are transmitted from the vehicle side to the management center, and maintenance services, etc. are provided based on this information. Furthermore, systems that globally share various types of information, such as the vehicle's driving status, are also being developed. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Special Publication No. 2018-528739 [Patent Document 2] International Publication No. 2017 / 130495 Summary of the Invention [Problem to be solved by the invention]

[0004] Since it uses the public communication network of a telecommunications carrier, there are corresponding costs involved. Therefore, an object of the present invention is to provide an in-vehicle device, an inter-vehicle communication method, and a program that can reduce the cost of deploying information. [Means for solving the problem]

[0005] According to an embodiment, an in-vehicle device includes a local communication unit. The local communication unit forms a multi-hop network with other in-vehicle devices and expands data with the other in-vehicle devices via the multi-hop network to share information with each other. The local communication unit also includes a data propagation function that expands data expanded in the first multi-hop network to the second multi-hop network when a vehicle including the in-vehicle device moves from a first multi-hop network to a second multi-hop network. [Brief explanation of the drawings]

[0006] [Figure 1] FIG. 1 is a system diagram showing an example of an inter-vehicle communication system according to an embodiment. [Figure 2] FIG. 2 is a diagram showing an example of a local network and an isolated network. [Figure 3] FIG. 3 is a diagram illustrating an example of a global network. [Figure 4] FIG. 4 is a diagram illustrating an example of a device mounted on a vehicle. [Figure 5] FIG. 5 is a diagram showing an example of data that the in-vehicle devices 30 and 40 acquire from each device. [Figure 6] FIG. 6 is a functional block diagram showing an example of an in-vehicle device 30 mounted on a general vehicle 10. As shown in FIG. [Figure 7] FIG. 7 is a diagram showing an example of the data structure of the neighbor list 32. As shown in FIG. [Figure 8] FIG. 8 is a diagram showing an example of data stored in the neighbor list 32. As shown in FIG. [Figure 9] FIG. 9 is a block diagram showing an example of a routine included in the program 6. [Figure 10] FIG. 10 is a diagram showing an example of commands exchanged between each connected device and the processor 4. In FIG. [Figure 11] FIG. 11 is a diagram showing an example of the data 7 stored in the memory 5. As shown in FIG. [Figure 12]FIG. 12 is a diagram showing an example of the network information 71 stored in the in-vehicle device 30. As shown in FIG. [Figure 13] FIG. 13 is a diagram showing an example of the temporary data 72 shown in FIG. [Figure 14] FIG. 14 is a functional block diagram showing an example of the on-board device 40 mounted on the special vehicle 20. As shown in FIG. [Figure 15] FIG. 15 is a diagram showing an example of the network information 73 stored in the in-vehicle device 40. As shown in FIG. [Figure 16] FIG. 16 is a functional block diagram showing an example of the management center 200. As shown in FIG. [Figure 17] FIG. 17 is a diagram showing an example of a processing procedure when a timer interrupt occurs in the in-vehicle device 30. [Figure 18] FIG. 18 is a flowchart illustrating an example of a processing procedure for the parent node update processing. [Figure 19] FIG. 19 is a flowchart illustrating an example of a processing procedure for the parent node selection processing. [Figure 20] FIG. 20 is a flowchart illustrating an example of a processing procedure for the upper node confirmation processing. [Figure 21] FIG. 21 is a flowchart showing an example of the operation of a node that has received a higher-level node confirmation command. [Figure 22] FIG. 22 is a flowchart showing an example of the operation of a node that has received a connection request command. [Figure 23] FIG. 23 is a flowchart showing an example of the operation of a node that has received a connection update command. [Figure 24] FIG. 24 is a flowchart illustrating an example of a processing procedure for updating a child node list. [Figure 25] FIG. 25 is a diagram showing an example of a processing procedure when a timer interrupt occurs in the in-vehicle device 40. [Figure 26] FIG. 26 is a diagram illustrating an example of multi-hop routing to a lower node. [Figure 27]FIG. 27 is a diagram illustrating an example of multi-hop routing to an upper node. [Figure 28] FIG. 28 is a flowchart illustrating an example of a processing procedure for the data downward expansion processing. [Figure 29] FIG. 29 is a flowchart illustrating an example of a processing procedure in a child node that has received a data downward deployment command. [Figure 30] FIG. 30 is a flowchart illustrating an example of a processing procedure for the data upward expansion processing. [Figure 31] FIG. 31 is a flowchart illustrating an example of a processing procedure in a parent node that receives a data upward deployment command. [Figure 32] FIG. 32 is a flowchart illustrating an example of a processing procedure for the status lower level expansion processing. [Figure 33] FIG. 33 is a flowchart illustrating an example of a processing procedure in a node that receives a status downward expansion command. [Figure 34] FIG. 34 is a flowchart illustrating an example of a processing procedure for the data deletion processing. [Figure 35] FIG. 35 is a flowchart illustrating an example of a processing procedure in a node that receives a data deletion command. [Figure 36] FIG. 36 is a flowchart illustrating an example of a processing procedure in a node that has received a subordinate node number acquisition command. [Figure 37] FIG. 37 is a flowchart illustrating an example of a processing procedure in a node that receives a concentrator function off command. [Figure 38] FIG. 38 is a diagram illustrating an example of data propagation from a local network to an isolated network. [Figure 39] FIG. 39 is a diagram showing another example of data propagation from a local network to an isolated network. [Figure 40] FIG. 40 is a diagram showing an example of the user management data 205a. [Figure 41]FIG. 41 is a diagram showing an example of data propagation from a vehicle in an isolated network to a local network. [Figure 42] FIG. 42 is a diagram showing another example of data propagation from a vehicle in an isolated network to a local network. [Figure 43] FIG. 43 shows a state where multiple concentrators are closely spaced. [Figure 44] FIG. 44 shows a state in which congestion has been resolved after the concentrator function off command is executed. [Figure 45] FIG. 45 is a diagram showing an example of other information managed in the user management data 205a. [Figure 46] FIG. 46 is a diagram for explaining the effects of the embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0007] <Terminology> The terms used in the embodiments will be explained below. Multi-hop communication: This refers to communication over a wireless network constructed using an optimal route selection algorithm that complies with the RPL (Internet Protocol version 6 (IPv6) Routing Protocol for Low-Power and Lossy Networks) standard of the international standardization organization IETF (Internet Engineering Task Force). This type of network can form a mesh or tree-shaped network topology. In the embodiments, a tree-shaped multi-hop network will be described. Regarding multi-hop communication, smart meter systems that use 920 MHz specified low-power wireless communication technology have been put to practical use.

[0008] 920 communication: In this embodiment, communication using the 920 MHz band based on the so-called specified low-power wireless communication technology is abbreviated as 920 communication. Note that the 920 MHz band specified low-power wireless communication is wireless communication for telemetry, telecontrol, and data transmission in the 920 MHz band as specified in ARIB STD-T108. LTE communication: Refers to wireless communication based on the LTE (Long Term Evolution) standard. In the embodiments, LTE communication is a higher-level concept and also includes communication using public mobile communication networks based on other standards. Ordinary vehicle: A vehicle that does not have a concentrator function (aggregation function) in multi-hop communication. In this embodiment, it is designated by the reference numeral 10. Special vehicle: In the embodiments, a vehicle that has a concentrator function and is capable of LTE communication is abbreviated as a special vehicle. In the embodiments, it is indicated by the reference numeral 20. The term "special vehicle" is also used in the embodiments, but this is to be distinguished from the special vehicle. In other words, a special vehicle can be either a general vehicle or a special vehicle. Note that when there is no distinction between a general vehicle and a special vehicle in the embodiments, it is referred to as a "vehicle" without a reference numeral.

[0009] Local Network: In an embodiment, this refers to a multi-hop network that includes special vehicles that can communicate with an LTE base station. Isolated network: In an embodiment, this refers to a multi-hop network that does not include a special vehicle. It also refers to a multi-hop network that includes a special vehicle that cannot communicate with an LTE base station. For example, if a special vehicle leaves the service range of an LTE base station, the local network becomes an isolated network. Furthermore, a single vehicle with no surrounding vehicles that can connect to it is also referred to as an isolated network.

[0010] Global network: In the embodiment, this refers to a network including one or more local networks and a center device that controls these local networks.

[0011] Node: Refers to each vehicle or on-board device that constitutes a multi-hop network. The on-board device in the embodiment can be considered as a node of a local network or an isolated network.

[0012] [Embodiment] <Configuration> FIG. 1 is a system diagram showing an example of a vehicle-to-vehicle communication system according to an embodiment. In FIG. 1, a general vehicle 10 and a special vehicle 20 coexist in the vehicle-to-vehicle communication system. The general vehicle 10 and the special vehicle 20 form a multi-hop network using 920 communication, constituting a tree-shaped network for multi-hop communication. Of these, the special vehicle 20 can communicate with a management center 200 via an LTE base station 100 using LTE communication. The special vehicle 20 has a concentrator function, so it aggregates data acquired from the general vehicle 10 and its own data and transmits the aggregated data to the management center 200 via LTE communication.

[0013] The management center 200 processes the data collected from the special vehicle 20 and generates information according to the service content. The generated information can be published on a web page dedicated to service subscribers, sent to various service vendors 400 via the Internet 300, or distributed to user devices 500 such as smartphones and PCs (Personal Computers).

[0014] Data input by general users from user devices 500 and data provided by service vendors 400 are transmitted to the management center 200. The management center 200 processes the received data and generates information to be distributed to vehicles. This information is transmitted to the special vehicle 20 via the LTE base station 100, and further distributed to lower level vehicles in the multi-hop network via 920 communication.

[0015] A local network and an isolated network will be described with reference to Fig. 2. In Fig. 2, a local network 801 is a multi-hop network capable of communicating with an LTE base station 100 via a special vehicle 20. An isolated network 802 is a multi-hop network to which the special vehicle 20 does not belong. A single ordinary vehicle 10 with no surrounding vehicles that can connect to it is also included in the isolated network 802. Furthermore, a network to which a special vehicle 20 belongs but which cannot communicate with the LTE base station 100 (communication is not possible) is an isolated network 802.

[0016] The global network will be described with reference to Fig. 3. In the embodiment, a network including a plurality of local networks 801 and the Internet 300 is collectively referred to as a global network 900. In the global network 900, the management center 200 receives data from each local network 801 and provides the information to the service vendor 400 and the user device 500 via the Internet 300. The management center 200 also transmits the data acquired from the Internet 300 to the local network 801.

[0017] Fig. 4 is a diagram showing an example of devices mounted on a vehicle. In Fig. 4, only the on-board device, a GPS (Global Positioning System) unit, a car navigation system, and a CAN (Controller Area Network) bus are indicated by reference numerals. Each device functions as an electronic control unit (ECU) on a line-type CAN bus 70. Of these, the on-board device 30 is mounted on a general vehicle 10, and the on-board device 40 is mounted on a special vehicle 20.

[0018] The GPS unit 50 receives positioning signals from GPS satellites and acquires its own location information. The car navigation system 60 includes a user interface such as a display monitor, touch sensor, and speaker, and is responsible for displaying information to the user and for allowing the user to input information. The car navigation system 60 also includes an SSD (Solid State Drive) for storing digital map data such as road maps.

[0019] 5 is a diagram showing an example of data acquired by the in-vehicle devices 30, 40 from each device. For example, location information including latitude, longitude, and altitude is acquired from the GPS unit 50. Furthermore, vehicle speed and direction of travel are acquired from a vehicle speed sensor. In addition, mileage and temperatures outside and inside the vehicle are also acquired.

[0020] 6 is a functional block diagram showing an example of an on-vehicle device 30 mounted on a general vehicle 10. The on-vehicle device 30 as a second on-vehicle device is an embedded computer including a CPU (Central Processing Unit) and a memory. The processing functions described below are realized by a processor as a hardware resource operating in accordance with a program written in the memory.

[0021] The in-vehicle device 30 includes a communication unit 1, a processor 4, a memory 5, a CAN bus interface 8, and a timer 9. These are interconnected via an interface such as a UART (Universal Asynchronous Receiver / Transmitter) or an SPI (Serial Peripheral Interface) bus.

[0022] The 920 communication unit 1, which serves as a local communication unit, has an antenna 2 and performs 920 MHz specified low-power wireless communication. That is, the 920 communication unit 1 forms a multi-hop wireless network with other in-vehicle devices within its radio wave range, and transfers data such as that shown in FIG. 5. The 920 communication unit 1 also has a register 3. The register 3 stores a unique serial number (communication ID 31) assigned to the vehicle itself or the in-vehicle device 30, and a neighbor list 32 that lists other in-vehicle devices in the vicinity.

[0023] The processor 4 is an arithmetic processing unit such as a CPU or MPU (Micro Processing Unit), and executes a program 6 written in advance in a memory 5. For example, the processor 4 expands data with other in-vehicle devices via a multi-hop network formed by 920 communication, and shares information with each other. The memory 5 is a non-volatile semiconductor memory such as a NAND flash memory, and stores the program 6 and data 7 in a predetermined storage area.

[0024] The CAN bus interface 8 mediates communication between each element connected to the CAN bus 70 and the processor 4. For example, data from the GPS unit 50, the car navigation system 60, and various other in-vehicle devices 80 is transferred to the processor 4 and the memory 5 via the CAN bus interface 8.

[0025] The timer 9 is, for example, an RTC (Real Time Clock), and generates a hardware interrupt at a preset timing to cause the processor 4 to execute the program 6. The timer 9 is backed up by an on-board battery. If time information is obtained from the GPS unit 50, the time on the timer 9 may be corrected as needed using that time information.

[0026] 7 is a diagram showing an example of the data structure of the neighbor list 32. The neighbor list 32 includes a plurality of data sets (records) that associate the communication IDs of the communication units 1 920 of other neighboring vehicles with the radio wave strength (Received Signal Strength Indicator: RSSI) received from the communication units 1 920.

[0027] As shown in Figure 8, among the four surrounding vehicles (920 communication unit 1), the RSSI value of the radio waves received from communication ID (S0000010) is the highest, and the RSSI value of the radio waves received from communication ID (S0000200) is the lowest. These data change from moment to moment and are important indicators for dynamically forming a multi-hop route.

[0028] 9 is a block diagram showing an example of routines included in program 6. Program 6 includes an initialization routine 61 that is executed immediately after power is turned on, a timer execution routine 62 that generates a timer interrupt at regular intervals, a command execution routine 63 that is started when a command is received from communication unit 1 920, and an in-vehicle device control routine 64.

[0029] The command execution routine 63 includes a plurality of commands and processes, such as branch processing, connection request command processing, upper node confirmation command, lower node number acquisition command, data deletion command, data expansion command, etc. Commands are exchanged between each connected device and the processor 4. For example, a data deletion command is executed by the processor 4, and functions as a deletion unit that deletes data that has passed a preset expiration date.

[0030] The in-vehicle device control routine 64 communicates with the GPS unit 50 and the car navigation system 60 via the CAN bus 70 to control each device and exchange data. Commands and data are exchanged between each device and the processor 4 via serial communication such as UART.

[0031] 10 is a diagram showing an example of commands exchanged between each connected device and the processor 4. A command has attributes such as a command name, sender, destination, command parameters, and response data. The operation when each command is executed will be explained in detail in the <Action> section.

[0032] Fig. 11 is a diagram showing an example of data 7 stored in memory 5. As shown in Fig. 11, data 7 includes network information 71 and temporary data 72. In particular, the area in memory 5 for storing temporary data 72 is ensured to have a capacity sufficient to store multiple pieces of data.

[0033] Fig. 12 is a diagram showing an example of network information 71 stored in the in-vehicle device 30. As shown in Fig. 12, the network information 71 includes a network type 71a, parent node management data 71b, the number of child nodes 71c, and child node management data 71d.

[0034] The network type 71a stores the type of the multi-hop network formed between the surrounding in-vehicle devices. The parent node management data 71b stores the communication ID and radio wave strength of the parent node of the node itself in the multi-hop network. The child node count 71c stores the number of child nodes of the node itself in the multi-hop network. The child node management data 71d stores the communication ID, count value, and radio wave strength for each child node.

[0035] Fig. 13 is a diagram showing an example of the temporary data 72 shown in Fig. 11. Each piece of data stored in the temporary data 72 has a header section and a data body. The header section includes fields for storing the data type, distribution method, data creation date and time (year / month / day and hour / minute / second information), serial number, validity period, sender information, and recipient information.

[0036] For example, data type M indicates data sent from the management center 200 without specifying a destination. Data type S indicates data sent from the management center 200 with a specified destination (destination communication ID) (such as a specific vehicle). Data type E indicates data generated in a vehicle downstream in the multi-hop network and sent to the management center 200.

[0037] Fig. 14 is a functional block diagram showing an example of an on-board device 40 mounted on the special vehicle 20. The on-board device 40 as the first on-board device is also an embedded computer, and in addition to the configuration shown in Fig. 6, includes an LTE communication unit 41 having a communication antenna 42. The LTE communication unit 41 as a public communication unit is connected to the processor 4 via a UART or the like.

[0038] The 920 communication unit (given reference numeral 11) of the in-vehicle device 40 includes a concentrator 33. In the following description, when there is no need to distinguish between the 920 communication unit 11 and the 920 communication unit 1 that does not have a concentrator function, they will be referred to as the "920 communication unit" without a reference numeral.

[0039] The concentrator 33 aggregates data from other in-vehicle devices via the multi-hop network. That is, the concentrator 33 aggregates data transmitted from child nodes under the multi-hop network to which the concentrator 33 belongs, and passes the data to the LTE communication unit 41.

[0040] The LTE communication unit 41 transmits the aggregated data to the center device via the public mobile communication network. That is, the LTE communication unit 41 transmits the data aggregated by the concentrator 33 to the management center 200 via the LTE base station 100 by LTE communication.

[0041] Fig. 15 is a diagram showing an example of network information 73 stored in the in-vehicle device 40. The memory 5 of the in-vehicle device 40 further includes an area for storing a concentrator function flag 73a in addition to the areas shown in Fig. 12. The concentrator function flag 73a is a flag for managing whether the function of the concentrator 33 is on or off.

[0042] 16 is a functional block diagram showing an example of a management center 200. The management center 200 as a center device includes a database server 203 having a database 205, a transmission / reception server 201, a data processing server 202, and a web server 204. The transmission / reception server 201 transmits and receives data to and from the LTE base station 100 via a backhaul line. The data processing server 202 processes the acquired data to generate various information. The web server 204 transmits and receives data to and from the Internet 300. The database server 203 manages the data held in the database 205.

[0043] The data processing server 202 includes an accounting processing unit 202a and a remote control unit 202b. The billing processing unit 202a generates billing information for sharing the costs of LTE communication between the on-board device 40 installed in the special vehicle 20 and the management center 200 among users of the on-board devices belonging to the multi-hop network to which the on-board device 40 belongs. This billing information is notified to the public mobile communication network by the billing processing unit 202a, processed by the billing server 102, etc., and used to bill the user.

[0044] When there are multiple special vehicles 20 within a range of a predetermined size, the remote control unit 202b disables the concentrator function of the in-vehicle device 40 of at least one of the special vehicles 20 within that range.

[0045] Next, the operation of the above configuration will be described. When the power is turned on to the in-vehicle device 30 or 40, the initialization routine 61 (Fig. 9) first clears the network information 71 (Fig. 12) or 73 (Fig. 15) in the memory 5 to zero and initializes it. The concentrator function flag 73a (Fig. 15) is initialized to 1, indicating that the function is on. Note that the temporary data 72 only needs to be initialized once, for example, at the time of shipping from the factory. Once the initialization is complete, operation starts upon the occurrence of a timer interrupt.

[0046] <effect> (Explanation of processing procedure in the in-vehicle device 30 without concentrator function) 17 is a diagram showing an example of a processing procedure when a timer interrupt occurs in the in-vehicle device 30. The timer execution routine 62 (FIG. 9) generates a timer interrupt at intervals of, for example, one second. Upon receiving a timer interrupt signal, the processor 4 executes a parent node update process (step 16a), a child node list update process (step 16b), and an update process of the temporary data 72 (FIG. 13) (step 16c).

[0047] Fig. 18 is a flowchart showing an example of the processing procedure for the parent node update processing (step 16a in Fig. 17). In Fig. 18, processor 4 refers to parent node management data 71b in network information 71 (Fig. 12) and checks whether the communication ID of the parent node of the own node in the multi-hop network is registered (step 17a). If there is no registration and the communication ID data of the parent node remains initialized (No), processor 4 performs parent node selection processing (step 17d).

[0048] If there is a parent node that satisfies the condition (Yes in step 17e), processor 4 stores and registers the communication ID of the parent node in parent node management data 71b of network information 71 (step 17f). Next, processor 4 transmits a connection request command to the parent node via communication unit 920 (step 17g).

[0049] The connection request command is, for example, a data string in the format shown in Fig. 10. The communication unit 920 stores the communication ID of its own node in the command parameter and transmits the connection request command. Next, the processor 4 transmits a data upward expansion command (Fig. 10) to the parent node and differentially copies each data in the temporary data 72 to the parent node (step 17h).

[0050] On the other hand, if the communication ID data of the parent node has been registered in step 17a (Yes), processor 4 acquires neighbor list data from communication unit 920 (step 17b) and determines whether the registered parent node satisfies the connection condition (step 17c). In step 17c, processor 4 checks whether the communication ID of the parent node exists in the neighbor list and whether the RSSI value of the communication ID is, for example, 128 or greater. If the connection condition is satisfied (Yes), processor 4 transmits a connection update command to the parent node via communication unit 920 (step 17i). If the connection condition is not satisfied (No), processor 4 performs the parent node selection process and subsequent processes in step 17d.

[0051] 19 is a flowchart showing an example of the processing procedure for the parent node selection process (step 17d in FIG. 18). In the parent node selection process, processor 4 refers to elements in the adjacent list in descending order of RSSI value, and checks whether there is a communication ID with an RSSI of 128 or greater that is not a subordinate node of the own node.

[0052] 19, processor 4 acquires neighbor list data from communication unit 920 (step 18a) and sorts the communication IDs in order of RSSI value (step 18b). Next, processor 4 assigns 1 to internal variable i (step 18c) and compares the RSSI value of the i-th element of the sorted neighbor list data with a threshold value (128 in this case) (step 18d). If the RSSI value is less than the threshold value (No), processor 4 increments i (step 18g) until it reaches the number of elements in the neighbor list (step 18h), and the processing procedure returns to step 18d.

[0053] If an element with an RSSI value of 128 or more is found in step 18d (Yes), processor 4 performs upper node confirmation processing (step 18e), and if it is determined that the node itself is not among the upper nodes of the i-th element (No in step 18f), the process ends with OK. If the result in step 18f is Yes, i is incremented in step 18g, and if a parent node that satisfies the condition is not found (No in step 18h), the process ends with NG.

[0054] FIG. 20 is a flowchart showing an example of the processing procedure of the upper node confirmation process (step 18e). In FIG. 20, processor 4 transmits an upper node confirmation command to communication unit 920 of the in-vehicle device of the parent node candidate (the one whose RSSI value was detected to be 128 or more in step 18d) via communication unit 920 (step 19a). The upper node confirmation command is, for example, a data string in the format shown in FIG. 10. Communication unit 920 stores the communication ID of its own node in a command parameter and transmits the upper node confirmation command. The transmitted upper node confirmation command is received by communication unit 920 of the in-vehicle device of the parent node via the wireless section 920 and transferred to processor 4 of the parent node candidate. Upon receiving the upper node confirmation command, processor 4 of the parent node candidate issues an upper node confirmation request command to the parent node of that node using the communication ID in the command parameter as an argument, and then returns a response.

[0055] Processor 4 of the source node waits for a response from the parent node candidate (step 19b). If there is no response within one second (No in step 19c) or if a response is received indicating that "there is a match in the upper node" (No in step 19d), the upper node confirmation process ends with "NG." If there is a response within one second (Yes in step 19c) or if "there is no match in the upper node" (Yes in step 19d), the upper node confirmation process ends with "OK."

[0056] 21 is a flowchart showing an example of the operation of a node that has received an upper node confirmation command. In FIG. 21, the node that has received the upper node confirmation command refers to parent node management data 71b (step 20a), and if there is no parent node (No in step 20b), it returns "No corresponding upper node" as a response to communication unit 920 (step 20c). If there is a parent node (Yes in step 20b), the node checks the communication ID given as an argument, and if there is a match (Yes in step 20d), it returns "Corresponding upper node" as a response to communication unit 920 (step 20e). If there is no match (No in step 20d), the node recursively transmits an upper node confirmation command to the parent node and returns the received response as its own response (step 20f).

[0057] Fig. 22 is a flowchart showing an example of the operation of a node that has received a connection request command. In Fig. 22, the node that has received the connection request command registers the communication ID of the child node specified in the command parameter of the command in the child node management data of the network information 71 (Fig. 12) (step 21a). Next, the node uses a data downward expansion command to differentially copy each data item (Fig. 13) of the temporary data 72 to the lower node (step 21b). Next, the node uses a status downward expansion command to differentially copy the data of the network type 71a to the lower node (step 21c). Then, the node initializes (clears to zero) the count value of the corresponding element in the child node management data (step 21d).

[0058] Fig. 23 is a flowchart showing an example of the operation of a node that has received a connection update command. As shown in Fig. 23, the node that has received the connection update command clears the count value of the element corresponding to the communication ID specified in the command parameter of the connection update command, among the child node management data in network information 71. The parent node update process is carried out according to the processing procedures in Figs. 18 to 23. Next, the child node list update process (Fig. 17) will be described.

[0059] 24 is a flowchart showing an example of a processing procedure for child node list update processing. Processor 4 assigns 1 to internal variable i for initialization (step 23a), then refers to the i-th element of child node management data 71d (FIG. 12) (step 23b) and determines whether the count value is, for example, 10 or greater (step 23c). If the result is Yes, processor 4 deletes the element from child node management data 71d (step 23g), increments i (step 23e), and returns to step 23b to continue processing until i reaches the number of child nodes (step 23f).

[0060] In step 23c, if the count value is less than 10 (No), processor 4 increments the count value (step 23d) and then refers to the next element of child node management data 71d.

[0061] The child node list update process is started every second after being kicked off by the timer execution routine, so each count increases by 1 every second. The count value in the child node management data 71d is cleared if there is a connection request from the corresponding child node. In other words, if the count value reaches 10, it means that there has been no connection request for more than 10 seconds, and the node is disconnected from the network.

[0062] After the child node list update process is completed, the processor 4 executes an update process for the temporary data 72 (FIG. 17). In the temporary data update process, the processor 4 refers to the date and time information acquired from the timer 9, the data creation date and time information of each data item in the temporary data 72, and the validity period information, and deletes data whose validity period has expired from the temporary data 72.

[0063] (Explanation of processing procedure in the in-vehicle device 40 having a concentrator function) Figure 25 is a diagram showing an example of a processing procedure when a timer interrupt occurs in the in-vehicle device 40. The timer execution routine 62 (Figure 9) generates a timer interrupt at intervals of, for example, one second. In Figure 25, upon receiving a timer interrupt signal, the communication unit 11 920 checks whether communication with the management center 200 is possible via the LTE communication unit 41 (step 24a). If communication is possible (Yes), the communication unit 11 920 acquires location information from the GPS unit 50 via the CAN bus interface 8, and transmits a location confirmation command with this location information added to the command parameters to the management center 200 (step 24b).

[0064] Next, the 920 communication unit 11 checks whether the concentrator function flag 73a (FIG. 15) is set (step 24c), and if it is set (Yes), stores the number 1, which indicates that the node belongs to the local network, in the network type 71a of the lower node (step 24d). Thereafter, like the 920 communication unit 1, the 920 communication unit 11 performs a child node list update process (step 24e) and a temporary data update process (step 24f), and the processing procedure returns to the caller (RETURN).

[0065] If it is determined in step 24a that communication with the management center 200 is not possible (No), the 920 communication unit 11 clears the concentrator function flag (step 24h) and executes the parent node update process 24i (step 24i) in the same manner as the 920 communication unit 1. Thereafter, the 920 communication unit 11 executes the child node list update process (step 24e) and the temporary data update process (step 24f).

[0066] In step 24c, if the concentrator function flag is not set (No), the communication unit 11 920 refers to the parent node management data 71b and determines whether or not a parent node exists (step 24j). If a parent node exists (Yes), the processing procedure proceeds to step 24i, and if a parent node does not exist (No), the communication unit 11 920 sets the concentrator function flag (step 24g) and performs the processing from step 24e onwards.

[0067] <Data and Status Routing> Next, the routing of data and status will be explained. Each data item in the temporary data 72 (FIG. 13) and the status stored in the network type 71a (FIG. 12) are developed by multi-hop routing of 920 communication. The status is information indicating whether the node belongs to a local network or an isolated network. For example, the status can be displayed as reference information on the car navigation system 50.

[0068] 26 is a diagram showing an example of routing to a lower node by multi-hop. In FIG. 26, data from a node is branched out and spread toward a lower node in a multi-hop network. Fig. 27 is a diagram showing an example of routing to a higher-level node by multi-hop. In Fig. 27, data from a node is expanded toward a higher-level node in a multi-hop network. In the embodiment, each piece of data that has reached the highest level node is expanded while branching toward a lower level node.

[0069] (Routing of data stored in temporary data 72) 28 is a flowchart showing an example of a processing procedure for data downward expansion processing. A node that expands data to a lower node refers to child node management data 71d (FIG. 12) (step 26a), increments internal variable i from 1 (steps 26b, 26e), and sends a data downward expansion command to the i-th child node via 920 communication with the communication ID and target data as arguments (step 26d). Here, the data to be expanded is specified as a command parameter. When the command has been sent to all child nodes under itself (Yes in step 26c), the processing ends.

[0070] 29 is a flowchart showing an example of a processing procedure in a child node that has received a data downward expansion command. The node that has received the data downward expansion command references the header portion of the temporary data (FIG. 13) and determines whether the data specified in the data downward expansion command is present in the temporary data (step 27a). If the data already exists (Yes), the processing ends. If the data does not exist (No), the received data is added to the temporary data 72 (step 27b). Furthermore, the node references the child node management data 71d (FIG. 12) (step 27c) and transmits the data downward expansion command to all child nodes using the same procedure as in FIG. 28 (steps 27c to 27g). In this way, the data downward expansion command is recursively transmitted to the lower nodes.

[0071] 30 is a flowchart showing an example of a processing procedure for data upward expansion processing. In FIG. 30, if the node is a 920 communication unit 11 having a concentrator function and the concentrator function flag is set (Yes in step 28a), the node transmits data to the management center 200 via the LTE communication unit 41 (28e).

[0072] If the communication unit 1 920 does not have the concentrator function, or if it has the concentrator function but the concentrator function flag is not set (No in step 28a), the node refers to the parent node management data (FIG. 12) (step 28b) and determines whether or not there is a parent node (step 28c). If there is no parent node (No), the process ends.

[0073] In step 28c, if a parent node is found (Yes), the node sends a data upward expansion command to the parent node via communication 920 (step 28d). Here, the data to be expanded and the communication ID of the node itself as the source communication ID are specified in the command parameters.

[0074] 31 is a flowchart showing an example of the processing procedure in a parent node that has received a data expansion command. The parent node that has received the data expansion command references the header section of the temporary data (FIG. 13) and determines whether the data specified in the data expansion command is included in the temporary data (step 29a). If the data already exists (Yes), the processing ends. If the data does not exist (No), the received data is added to the temporary data 72 (step 29b).

[0075] If the node has a 920 communication unit 11 with a concentrator function and the concentrator function flag is set (Yes in step 29c), the node transmits data to the management center 200 via the LTE communication unit 41 (29m).

[0076] If the 920 communication unit 1 does not have a concentrator function, or if it has a concentrator function but the concentrator function flag is not set (No in step 29c), the node refers to the parent node management data (FIG. 12) (step 29d) and determines whether there is a parent node above it (step 29e). If there is a parent node, the node sends a data upward expansion command to the parent node via 920 communication (step 29f). Here, the data to be expanded and the communication ID of the node itself as the sender communication ID are specified in the command parameters.

[0077] Furthermore, the node refers to the child node management data 71d (FIG. 12) (step 29g), increments the internal variable i from 1 (steps 29h, 29l), and sends a data downward expansion command via 920 communication to child nodes other than those with the source communication ID specified in the command parameter (No in step 29j) (step 29k). Here, the data to be expanded is specified in the command parameter. When the command has been sent to all child nodes under the node (excluding those with the source communication ID specified in the command parameter) (No in step 29i), the process ends. In this way, the data downward expansion command is recursively sent to the lower nodes.

[0078] (Status Routing) Fig. 32 is a flowchart showing an example of a processing procedure for the status downward expansion processing. In Fig. 32, the node refers to the child node management data 71d (Fig. 12) (step 30a), increments the internal variable i from 1 (steps 30b, 30e), and sends a status downward expansion command to the i-th child node via 920 communication (step 30d). Here, the value of the network type 71a of the node itself is specified as a command parameter. When the command has been sent to all child nodes under itself (No in step 30c), the processing ends.

[0079] 33 is a flowchart showing an example of a processing procedure in a node that has received a status expand downward command. The node that has received the status expand downward command adds the received data to temporary data 72 (step 31a). Next, this node refers to child node management data 71d (FIG. 12) (step 31b) and sends the status expand downward command to all child nodes using the same procedure as in FIG. 28 (steps 31c to 31f). In this way, the status expand downward command is recursively sent to the lower nodes.

[0080] (Data Deletion) FIG. 34 is a flowchart showing an example of a processing procedure for data deletion processing. Data deletion in the temporary data 72 is performed in order, starting from the highest node. In FIG. 34, the highest node references the header section of the temporary data (FIG. 13) and deletes data that matches the specified header information from the temporary data 72 of its own node (step 32a). Next, this node references the child node management data 71d (FIG. 12) (step 32b) and transmits a data deletion command to all child nodes using the same procedure as in FIG. 28 (steps 32c to 32f). Here, the header information of the data to be deleted is specified in the command parameters. In this way, the data downward expansion command is recursively transmitted to the lower nodes.

[0081] Fig. 35 is a flowchart showing an example of a processing procedure in a node that has received a data deletion command. The node that has received the data deletion command references the header portion of the temporary data (Fig. 13) and deletes data that matches the specified header information from its own temporary data 72 (step 33a). Next, this node references child node management data 71d (step 33b) and sends a delete command for the specified data to all child nodes using the same procedure as in Fig. 34 (steps 33c to 33f). In this way, the data lower expansion command is recursively sent to the lower nodes.

[0082] 36 is a flowchart showing an example of a processing procedure in a node that has received a command to obtain the number of subordinate nodes. The node that has received the command to obtain the number of subordinate nodes refers to the child node management data 71d (FIG. 12) (step 34a), and if there are no child nodes (No in step 34b), returns a 0 code and ends the process.

[0083] If there is a child node (Yes in step 34b), the node assigns 1 to the internal variable i (step 34c), sets the total number of child nodes to 0 (step 34d), and then recursively sends a subordinate node acquisition command to the i-th child node to acquire the number of subordinate nodes (step 34e). Next, the node adds the acquired number of child nodes + 1 to the total number (step 34f), increments i (step 34h), and acquires the number of child nodes from all child nodes under itself (No in step 34g), and then the process ends.

[0084] 37 is a flowchart showing an example of a processing procedure related to a concentrator function off command. The data processing server 202 (FIG. 16) of the management center 200 refers to the location confirmation command transmitted from a concentrator function-equipped vehicle (special vehicle) within the service area of each LTE base station 100, and monitors the location of each vehicle.

[0085] In this embodiment, a state in which there are multiple concentrator function-equipped vehicles within a radius of 100 m is defined as a congested state. When a congested state is formed, a concentrator function off command is transmitted to all concentrator function-equipped vehicles except for the one that is closest to the LTE base station 100.

[0086] Figure 37 shows the operation of a node that has received a concentrator function off command (Figure 10). A parent node is selected (step 35a) using the same process as in Figure 19. If there is no parent node that satisfies the conditions (No in step 35b), the process ends. If there is a parent node that satisfies the conditions (Yes in step 35b), the parent node is registered (step 35c) using the same procedure as in Figure 18, a connection request to the parent node is made (step 35d), and then the concentrator function is turned off (step 35e) by clearing concentrator function flag 73a (Figure 15).

[0087] [Multicast data transmission from management center 200 to vehicles] (Transmission of data from the management center 200 to the vehicle on the local network) The management center 200 transmits information such as wide-area accidents, construction information, or weather information to each vehicle. This data is generated by the data processing server 202 of the management center 200, and includes a header section and data body as shown in Fig. 13. Of these, the data body is, for example, data in XML (eXtended Markup Language) format, and includes data such as text data and location information.

[0088] The header section contains information about the validity period of the datagram. The validity period is set to be relatively long, for example, from one hour to several hours, compared to known 920 communication systems. These data are transmitted from the transmission / reception server 201 (FIG. 16) to the special vehicle 20 via the backhaul line and the LTE base station 100. The special vehicle 20, which has a concentrator function, receives these data at the 920 communication unit 11 and immediately deploys them to each vehicle within the local network using a data deployment command. Each vehicle to which the data has been deployed adds the received data to its temporary data 72 and stores it.

[0089] The in-vehicle device 30 of each vehicle that receives the data controls, for example, the car navigation system 60 via the CAN bus interface 8, and displays the data extracted from the temporary data 72 as text or an image on the monitor of the car navigation system.

[0090] (Explanation of data propagation function) Since the isolated network does not have the special vehicle 20, it is not possible to directly obtain data from the management center 200. Therefore, in the embodiment, data is propagated from vehicle to vehicle so that each vehicle in the isolated network can obtain the data. Note that data that has not yet passed its set expiration date is propagated.

[0091] (Data propagation from management center 200 to vehicles in isolated network) Figure 38 is a diagram showing an example of data propagation from a local network to an isolated network. In the state of Figure 38(A), it is assumed that data C transmitted from the management center 200 is held in the temporary data 72 of each node in local network A. It is also assumed that data C is not held in the temporary data 72 of each node in isolated network B. From this state, as shown in Figure 38(B), when vehicle P in local network A and vehicle Q, which is the top node in isolated network B, approach each other, for example, communication unit 1 920 of vehicle Q is connected to vehicle P as a child node.

[0092] Then, by the data downward expansion function, the data in the temporary data 72 of vehicle P is expanded to the in-vehicle device 30 of each vehicle that belonged to isolated network B via vehicle Q. The in-vehicle device 30 of each vehicle that received the data controls the car navigation system 60 via the CAN bus interface 8, and displays the data extracted from the temporary data 72 on the monitor of the car navigation system 60.

[0093] Figure 39 is a diagram showing another example of data propagation from a local network to an isolated network. In the state of Figure 39(A), it is assumed that data C transmitted from the management center 200 is held in the temporary data 72 of each node in local network A. It is also assumed that data C is not held in the temporary data 72 of each node in isolated network B. From this state, it is assumed that vehicle P in local network A moves and leaves local network A, approaches vehicle Q, which is the top node in isolated network B, and connects as a child node of vehicle Q, as shown in Figure 39(B).

[0094] Then, the data in the temporary data 72 of vehicle P is expanded to vehicle Q by the data upward expansion function. Furthermore, the data is expanded to each vehicle in the isolated network B via vehicle Q by the data upward expansion function and the data downward expansion function. The in-vehicle device 30 of each vehicle that receives the data controls the car navigation system 60 via the CAN bus interface 8, and displays the data extracted from the temporary data 72 on the monitor of the car navigation system 60.

[0095] [Unicast data transmission from vehicle to management center 200] The unicast data is transmitted from each vehicle to the management center 200 by unicast, mainly for maintenance purposes. The unicast data is transmitted from the in-vehicle device 30, for example, at regular intervals. For example, the data includes "vehicle location information," "map version information," "light illumination status," and "wiper operation status."

[0096] These data are acquired by the processor 4 of the in-vehicle device 30 from the GPS unit 50 and various devices via the CAN bus 70. The unicast data is expressed in, for example, XML format, and the header contains validity period information. The data structure of the unicast data is, for example, as shown in FIG. 13.

[0097] (Data transmission from vehicles in a local network) The data created by the processor 4 of the in-vehicle device 30 is encrypted, and then sequentially expanded to higher-level nodes by a data expansion command. At this time, the data is added to the temporary data 72 of each node. In the local network, the data that reaches the in-vehicle device 40 with a concentrator function is transferred by the LTE communication unit 41 to the management center 200 via the LTE base station 100. The transmission / reception server 201 of the management center 200 receives this data and stores it in the user management data 205a of the database 205.

[0098] 40 is a diagram showing an example of user management data 205a. For each communication ID, which is a vehicle ID, data such as a transit concentrator ID, latitude GPS information, longitude GPS information, battery charge status, remaining gasoline, inside vehicle temperature, outside vehicle illuminance, headlight illumination status, and wiper operation status are stored in association with each other. The user management data 205a is processed by the Web server 204 or the database server 203 as necessary.

[0099] The transmitted data is deleted from the network by a data deletion command. The in-vehicle device 40 with a concentrator function deletes the data transmitted from the LTE communication unit 41 from the temporary data 72 of its own node, and then transmits a data deletion command to each child node using the header information of the data as an argument. The data deletion command is expanded in order to the lower nodes in the local network, and the data is deleted from the temporary data 72 of each node.

[0100] (Data propagation from vehicles in isolated networks) In an isolated network, data created by the processor 4 of the in-vehicle device 30 is deployed to higher-level nodes in response to a data deployment command. When the data reaches the highest level node, it is deployed to lower-level nodes in response to a deployment command, and eventually the data is deployed to each node in the entire network. Since there is no concentrator in an isolated network, data cannot be sent directly to the management center 200, but it can be received using a data propagation function as long as the data is within its validity period.

[0101] FIG. 41 is a diagram showing an example of data propagation from a vehicle in an isolated network to a local network. As shown in FIG. 41(A), data D is held in the temporary data 72 of each node in isolated network B. From this state, as shown in FIG. 41(B), assume that vehicle P in local network A and vehicle Q, which is the top node in isolated network B, approach each other, and the 920 communication unit 1 of vehicle Q is connected to vehicle P as a child node. Then, by the data upward expansion function, the data in the temporary data 72 of vehicle Q is expanded to local network A via vehicle P. When this data reaches the on-board device 40 having a concentrator function, the LTE communication unit 41 transfers the data to the transmission / reception server 201 of the management center 200 via the LTE base station 100.

[0102] FIG. 42 is a diagram showing another example of data propagation from a vehicle in an isolated network to a local network. In FIG. 42(A), as in FIG. 41(A), it is assumed that data D is held in the temporary data 72 of each node in isolated network B. From this state, it is assumed that vehicle Q in isolated network B moves and leaves isolated network B, approaches vehicle P in local network A, and the communication unit 1 920 of vehicle Q connects to vehicle P as a child node. Then, by the data upward expansion function, the data in the temporary data 72 of vehicle Q is expanded into local network A via vehicle P. When this data reaches the on-board device 40 having a concentrator function, the LTE communication unit 41 transfers the data to the transmission / reception server 201 of the management center 200 via the LTE base station 100.

[0103] 41 and 42, after transmitting data from the LTE communication unit 41, the in-vehicle device 40 having the concentrator function deletes the data from the temporary data 72 of its own node and transmits the above-mentioned data deletion command to each child node using the header information of the data as an argument. The data deletion command is deployed in order to the lower nodes in the local network A, and the data D is deleted from the temporary data 72 of each node.

[0104] [Unicast data transmission from management center 200 to specific vehicle] Notification information for vehicle inspections and regular maintenance is sent from the management center 200 to specific vehicles. This data is generated by the data processing server of the management center 200, and as shown in FIG. 13, includes a header section and data body. The data body is, for example, data in XML format, and includes data such as text data and location information. The header section stores the communication ID of the in-vehicle device 40 with a concentrator function in the destination vehicle. The validity period information is, for example, 3 minutes.

[0105] The management center 200 references the "passing concentrator ID" in the vehicle data (Figure 40) and transmits the data to the corresponding concentrator and to concentrators in the vicinity of that concentrator. The concentrator then expands the data downward to all nodes in the local network, similar to the case of multicast data transmission from the management center 200 to the vehicle. At this time, each node references the destination communication ID in the data header, and if it matches the communication ID of its own node, it stops expanding downward. After that, it displays this on the car navigation screen and sends an ACK (Figure 13) to the management center 200 indicating that the data has been received, using the same procedure as for unicast data transmission from the vehicle to the management center 200. The validity period of the original data in the ACK is, for example, seven minutes from the date and time the original data was created. If the management center 200 does not receive an ACK after seven minutes have passed, it will resend the data, etc.

[0106] [Reducing concentrator congestion] Figure 43 shows a state in which multiple concentrators are congested. When the management center detects this state, it sends a command to turn off the concentrator function. This will resolve the congested state, as shown in Figure 44, for example. Note that even if the concentrator function is turned off once, it will recover if there are no more parent nodes to connect to, as shown in Figure 25.

[0107] [Manage billing] According to the embodiment, although each vehicle can use existing network services, only vehicles (special vehicles) equipped with an on-board device 40 having a concentrator function incur LTE communication fees. Therefore, communication costs can be significantly reduced compared to existing technologies. Furthermore, in the embodiment, fairness can be ensured by splitting the fee for special vehicles between users.

[0108] FIG. 45 is a diagram showing an example of other information managed in the user management data 205a. That is, billing information is managed for each user ID. For example, it is efficient to install a concentrator in a vehicle that is used frequently. In the example of FIG. 45, the LTE communication costs incurred by U005 and U015 are divided by the number of users and charged to each user.

[0109] [Transmitting data from a vehicle to a nearby vehicle] The maintenance data from the vehicle is transmitted to the management center 200 via the on-board device 40 having a concentrator function, and then deleted from the temporary data 72 of each node in the network. However, it is also possible to keep the data in the temporary data 72 of each node in the network for a certain period of time without deleting it after being transmitted to the management center 200.

[0110] (Information provided by emergency vehicles and construction vehicles) The vehicle user inputs the message text and validity period using the user interface of the car navigation system 60. The car navigation system 60 adds location information from the GPS unit 50 and sends a message transmission command (Fig. 10) to the processor 4 of the in-vehicle device 40 via the CAN bus interface 8. The processor 4 of the in-vehicle device 40 then creates vehicle-to-vehicle data (Fig. 13), and the message is expanded to surrounding vehicles connected to the network using a data upper level expansion command and a data lower level expansion command. The validity period information in the header section is set to a relatively long period, ranging from one hour to several hours. Vehicles that receive the message display the message together with the location information on the monitor of the car navigation system 60.

[0111] With the above configuration, even if there are no vehicles with concentrator functionality nearby or even if the vehicle is outside the LTE service area, information can be transmitted to nearby vehicles connected to the network. Furthermore, the data propagation function makes it possible to propagate information to nearby areas without using LTE communication.

[0112] [Operation as a standalone in-vehicle device] Taking advantage of the low cost and power-saving nature of 920 communication, it is also possible to assume that the data source is a single vehicle-mounted device 30 that is always connected. Even in this case, even if there are no vehicles with concentrator functionality nearby or even if the vehicle is outside the LTE service area, information can be transmitted to nearby vehicles connected to the network. Furthermore, the data propagation function described above makes it possible to propagate information to nearby areas. For example, there are operation examples such as (1) to (3). (1) Distribution of underpass water level and warning information A water level gauge is installed on the vehicle, and when the water level exceeds a certain level, a warning message is sent to nearby vehicles connected to the network, along with position information from the GPS unit 50. Vehicles that receive the message display the warning message along with the position information on the monitor of their car navigation system 60. This makes it possible to warn vehicles approaching dangerous areas. (2) Providing information on full and empty parking spaces By linking this device with a parking lot management system, it is possible to transmit information about whether parking lots are full or empty to nearby vehicles connected to the network. Vehicles that receive the information will display the full or empty information along with their location information on the monitor of their car navigation system 60. (3) Gas station price information The location and price information of gas stations can be transmitted to nearby vehicles connected to the network. Vehicles that receive the information display the price information along with the location information on the monitor of the car navigation system 60.

[0113] <Effects> FIG. 46 is a diagram for explaining the effects of the embodiment. As shown in FIG. 46, in the embodiment, only some of the vehicles 600 (special vehicles) are equipped with an LTE communication function, and a data extraction function allows multiple vehicles to share the same information. In addition, charges for the public communication network using the LTE base station 100 are shared among users. This makes it possible to reduce communication charges per user. The user can access the Internet 300 with the user device 500 and enjoy various services provided by the management center 200 and the service vendor 400 together with other users of the vehicle 600.

[0114] Furthermore, even if a vehicle is outside the LTE service area, if there is a vehicle with concentrator functionality in the network that is within the LTE service area, communication with the global network will be possible through vehicle-to-vehicle multi-hop communication.

[0115] In addition, if a vehicle that was able to communicate with LTE moves out of the service range, the concentrator function flag is cleared, allowing the vehicle to function as a normal node and connect to other networks that support LTE communication, enabling more stable communication.

[0116] Furthermore, when nodes are densely packed and there are multiple concentrators within a certain distance, unnecessary communication costs can be prevented by providing a function to remotely turn on / off the concentrator function from the management center 200. Furthermore, even if there is no on-board concentrator near the vehicle, the data propagation function can be used to provide services equivalent to those when LTE communication is possible.

[0117] If there is no special vehicle in the multi-hop network, the data is stored in the vehicle for a certain period of time, and communication with the management center 200 is performed when communication with the management center 200 becomes possible. Even if there is no vehicle with a concentrator function in the network, by using the data propagation function, LTE communication is performed when the data is transmitted to the concentrator, and the data is transmitted to the global network side.

[0118] In addition, data received by vehicles equipped with a concentrator is stored in each node of the local network and the isolated network, but the data is deleted after a validity period, which prevents memory capacity from exceeding capacity.

[0119] By using the low-cost 920MHz specified low-power wireless communication function, users can transmit information without using expensive communication infrastructure. The high power-saving performance of the 920MHz specified low-power wireless communication device makes it possible to continue transmitting information even when the device is stopped.

[0120] In addition, the in-vehicle device of the embodiment is connected to a car navigation system 60, and vehicle position data and information acquisition from various devices, control of devices, display of information to the user, and data input from the user can be performed via the car navigation system 60.

[0121] As described above, according to the embodiment, some on-board devices have a concentrator function and some do not. Each vehicle forms a network and performs multi-hop communication using low-cost 920 MHz specified low-power wireless communication technology. Only on-board devices in the network that have a concentrator function aggregate data from each general vehicle and perform expensive LTE communication with the management center 200. The communication fee per user is kept low by dividing the payment of the communication fee among all users.

[0122] If there are no special vehicles in the multi-hop network, communication data can be stored in each vehicle in the network for a certain period of time, and by using the data propagation function between networks, it is possible to provide services equivalent to those when each vehicle is using LTE communication.

[0123] By applying multi-hop communication technology, a network can be constructed for low-cost short-range communication between ordinary vehicles, and by equipping only some vehicles with mobile communication functions, it is possible to reduce overall costs while simultaneously realizing sufficient service functions.Furthermore, fairness among users can be ensured by introducing a billing system in which other short-range communication users also share the costs of vehicles equipped with mobile communication functions.

[0124] As described above, according to the embodiments, it is possible to provide an in-vehicle device, an inter-vehicle communication method, and a program that can reduce the cost required for deploying information.

[0125] Although several embodiments have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be embodied in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included within the scope and spirit of the invention, and are also included in the scope of the invention and its equivalents as defined in the claims. The inventions described in the original claims of this application are set forth below. [Appendix 1] a first in-vehicle device; a second in-vehicle device; a center device, The first in-vehicle device a local communication unit that forms a multi-hop network with other in-vehicle devices and that deploys data with the other in-vehicle devices via the multi-hop network to share information with each other; a concentrator that aggregates the data from the other in-vehicle devices via a multi-hop network to which the in-vehicle device belongs; a public communication unit that transmits the aggregated data to the center device via a public mobile communication network, The second in-vehicle device A vehicle-to-vehicle communication system that forms a multi-hop network with other on-board devices, expands data with the other on-board devices via the multi-hop network, and shares information with each other, and when a vehicle equipped with the first on-board device is present in the multi-hop network, has a local communication unit that expands the data with the first on-board device as a root node. [Appendix 2] The center device The vehicle-to-vehicle communication system described in [Appendix 1] includes a billing processing unit that generates billing information for sharing the costs of communication between the first vehicle-mounted device and the center device among users of vehicle-mounted devices belonging to the multi-hop network to which the first vehicle-mounted device belongs, and notifies the public mobile communication network. [Appendix 3] The center device The vehicle-to-vehicle communication system described in [Appendix 1] includes a remote control unit that disables the function of the concentrator of at least one of the first on-board devices within a specified area when multiple vehicles equipped with the first on-board device are present within the specified area. [Appendix 4] In the in-vehicle device, a local communication unit that forms a multi-hop network with other in-vehicle devices and that deploys data with the other in-vehicle devices via the multi-hop network to share information with each other; a concentrator that aggregates the data from the other in-vehicle devices via a multi-hop network to which the in-vehicle device belongs; and a public communication unit that transmits the aggregated data to a destination via a public mobile communication network. [Appendix 5] In the in-vehicle device, a local communication unit that forms a multi-hop network with other in-vehicle devices and expands data with the other in-vehicle devices via the multi-hop network to share information with each other; The local communication unit When a vehicle equipped with an on-board device connectable to a public mobile communication network is present in the multi-hop network, the on-board device of the vehicle deploys the data as a root node in the multi-hop network. [Appendix 6] The in-vehicle device according to [Supplementary Note 4] or [Supplementary Note 5] further comprises a deletion unit that deletes data that has passed a preset expiration date. [Appendix 7] A process in which an in-vehicle device forms a multi-hop network with other in-vehicle devices; a process in which the in-vehicle device deploys data with the other in-vehicle device via the multi-hop network to share information with each other; a step in which the in-vehicle device aggregates the data from the other in-vehicle devices via a multi-hop network to which the in-vehicle device belongs; and a step of the in-vehicle device transmitting the aggregated data to a destination via a public mobile communication network. [Appendix 8] A process in which an in-vehicle device forms a multi-hop network with other in-vehicle devices; a process in which the in-vehicle device deploys data with the other in-vehicle device via the multi-hop network to share information with each other; and when a vehicle equipped with an on-board device connectable to a public mobile communication network is present in the multi-hop network, the on-board device of the vehicle deploys the data, with the on-board device serving as a root node in the multi-hop network. [Supplementary Note 9] A command to cause the in-vehicle device to execute a process of forming a multi-hop network with other in-vehicle devices; a command to cause the in-vehicle device to execute a process of expanding data with the other in-vehicle device via the multi-hop network and sharing information with each other; a command to cause the in-vehicle device to execute a process of aggregating the data from the other in-vehicle devices via a multi-hop network to which the in-vehicle device belongs; and an instruction to cause the in-vehicle device to execute a process of transmitting the aggregated data to a destination via a public mobile communication network. [Appendix 10] A command to cause the in-vehicle device to execute a process of forming a multi-hop network with other in-vehicle devices; a command to cause the in-vehicle device to execute a process of expanding data with the other in-vehicle device via the multi-hop network and sharing information with each other; and an instruction to cause the on-board device of a vehicle that is equipped with an on-board device that can connect to a public mobile communication network to execute a process of expanding the data in the on-board device of the vehicle as a root node in the multi-hop network when the vehicle is present in the multi-hop network. [Explanation of symbols]

[0126] 1...Communication unit, 2...Antenna, 3...Register, 4...Processor, 5...Memory, 6...Program, 7...Data, 8...CAN bus interface, 9...Timer, 10...General vehicle, 11...Communication unit, 20...Special vehicle, 30...In-vehicle device, 32...Adjacent list, 33...Concentrator, 80...Various in-vehicle devices, 40...In-vehicle device, 41...LTE communication unit, 42...Communication antenna, 50...GPS unit, 60...Car navigation system, 61...Initialization routine, 62...Timer execution routine, 63...Command execution routine, 64...In-vehicle device control routine, 70...CAN bus, 71...Network information, 71a...Network type, 71b...Parent node Management data, 71d...child node management data, 72...temporary data, 73...network information, 73a...concentrator function flag, 100...LTE base station, 102...billing server, 200...management center, 201...transmission / reception server, 202...data processing server, 202a...billing processing unit, 202b...remote control unit, 203...database server, 204...web server, 205...database, 205a...user management data, 300...internet, 400...service vendor, 500...user device, 801...local network, 802...isolated network, 900...global network, 920...timer execution routine.

Claims

1. In the in-vehicle device, a local communication unit that forms a multi-hop network with other in-vehicle devices and expands data with the other in-vehicle devices via the multi-hop network to share information with each other; The local communication unit a data propagation function that, when a vehicle including the device moves from a first multi-hop network to a second multi-hop network, spreads data spread in the first multi-hop network to the second multi-hop network; When the first multi-hop network includes a vehicle capable of communicating with a public mobile communication network and the second multi-hop network does not include a vehicle capable of communicating with the public mobile communication network, The data propagation function of the in-vehicle device is to deploy data transmitted from a management center of the public mobile communication network to the second multi-hop network.

2. When the first multi-hop network does not include a vehicle capable of communicating with a public mobile communication network, and the second multi-hop network includes a vehicle capable of communicating with the public mobile communication network, The in-vehicle device according to claim 1 , wherein the data deployed on the second multi-hop network is transferred to a management center of the public mobile communication network via a vehicle capable of communicating with the public mobile communication network.

3. The vehicle capable of communicating with the public mobile communications network is a vehicle that has moved from the first multi-hop network to the second multi-hop network and become capable of communicating with the public mobile communications network, as described in claim 2.

4. An in-vehicle device described in any one of claims 1 to 3, wherein the data propagation function propagates data that has not passed a predetermined expiration date.

5. A process in which an in-vehicle device forms a multi-hop network with other in-vehicle devices; a process in which the in-vehicle device deploys data with the other in-vehicle device via the multi-hop network to share information with each other; a step in which the in-vehicle device, when a vehicle including the in-vehicle device moves from a first multi-hop network to a second multi-hop network, deploys data deployed in the first multi-hop network to the second multi-hop network; a step in which, when the first multi-hop network includes a vehicle capable of communicating with a public mobile communication network and the second multi-hop network does not include a vehicle capable of communicating with the public mobile communication network, the in-vehicle device deploys data transmitted from a management center of the public mobile communication network to the second multi-hop network.

6. When the first multi-hop network does not include a vehicle capable of communicating with a public mobile communication network, and the second multi-hop network includes a vehicle capable of communicating with the public mobile communication network, 6. The vehicle-to-vehicle communication method according to claim 5, further comprising the step of transferring the data deployed in the second multi-hop network to a management center of the public mobile communication network via a vehicle capable of communicating with the public mobile communication network.

7. A vehicle-to-vehicle communication method as described in Claim 6, wherein the vehicle capable of communicating with the public mobile communications network is a vehicle that has moved from the first multi-hop network to the second multi-hop network and become capable of communicating with the public mobile communications network.

8. A vehicle-to-vehicle communication method described in any one of claims 5 to 7, wherein the process of deploying data deployed in the first multi-hop network to the second multi-hop network further includes a process of propagating data that has not passed a predetermined expiration date.

9. An instruction to cause an in-vehicle device to execute a process of forming a multi-hop network with another in-vehicle device; a command to cause the in-vehicle device to execute a process of expanding data with the other in-vehicle device via the multi-hop network and sharing information with each other; an instruction to the in-vehicle device to execute a process of expanding data expanded in the first multi-hop network to the second multi-hop network when a vehicle including the in-vehicle device moves from a first multi-hop network to a second multi-hop network; and an instruction to cause the in-vehicle device to execute a process of expanding data transmitted from a management center of the public mobile communication network to the second multi-hop network when the first multi-hop network includes a vehicle capable of communicating with a public mobile communication network and the second multi-hop network does not include a vehicle capable of communicating with the public mobile communication network.

10. When the first multi-hop network does not include a vehicle capable of communicating with a public mobile communication network, and the second multi-hop network includes a vehicle capable of communicating with the public mobile communication network, The program according to claim 9, further comprising the step of transferring the data deployed in the second multi-hop network to a management center of the public mobile communication network via a vehicle capable of communicating with the public mobile communication network.

11. The program described in Claim 10, wherein the vehicle capable of communicating with the public mobile communications network is a vehicle that has moved from the first multi-hop network to the second multi-hop network and become capable of communicating with the public mobile communications network.

12. A program described in any one of claims 9 to 11, wherein the process of deploying data deployed in the first multi-hop network to the second multi-hop network further includes a process of propagating data that has not passed a predetermined expiration date.

Images