Communication control method, communication device, and program

Abstract

To provide a communication control method, a communication apparatus, and a program that can efficiently create communication routes within a vehicle group.SOLUTION: When an in-vehicle apparatus 1 detects another vehicle group apparatus, which is an in-vehicle apparatus 1 belonging to another vehicle group to be merged, as an adjacent node, the in-vehicle apparatus acquires a route table held by the other vehicle group apparatus from the other vehicle group apparatus. The in-vehicle apparatus then creates a route table that includes its own vehicle group and the other vehicle group by integrating the route table acquired from the other vehicle group apparatus and a route table originally held by itself. The in-vehicle apparatus 1 that has updated the route table expands the updated route table to original members, thereby also adapting the route table of each in-vehicle apparatus 1 to a vehicle group formation after merging.SELECTED DRAWING: Figure 17

Description

[Technical Field]

[0001] The present disclosure relates to a communication control method, a communication device, and a program for performing data communication with a server or a roadside device using the concept of a vehicle convoy. [Background technology]

[0002] Patent Document 1 discloses a so-called proactive routing method in which adjacent nodes are detected by transmitting and receiving HALLO packets at regular intervals, and a routing table is updated as needed.

[0003] Additionally, 3GPP (registered trademark) is studying a communication control method for realizing cellular V2X (Non-Patent Document 1). [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 3936338 [Non-patent literature]

[0005] [Non-Patent Document 1] 3GPP TS 36.000 V16.7.0 (2021-12) 3rd Generation Partnership Project, “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 16)” Summary of the Invention [Problem to be solved by the invention]

[0006] To realize practical autonomous driving and a safer transportation society, it is desirable to wirelessly distribute dynamic maps from a center to each vehicle via roadside units or wide-area wireless base stations such as 4G. Here, dynamic maps refer to data on dynamic map elements, such as information on moving objects in blind spots on roads and the status of traffic lights. However, a configuration in which data is distributed from wide-area wireless base stations to each vehicle raises concerns about wireless resource constraints. On the other hand, a configuration in which data is distributed individually from roadside units to each vehicle is expected to alleviate the above issues, but another issue may arise: the amount of data that can be transmitted to the vehicle is limited due to the short connection time between the roadside units and each vehicle.

[0007] Taking such circumstances into consideration, the developers of this disclosure have studied a method for efficiently distributing data via roadside units using the concept of a vehicle convoy, which is a group of multiple vehicles. Specifically, they have studied a configuration in which vehicles that are part of a vehicle convoy and are outside the communication area of ​​the roadside unit (out-of-area vehicles) communicate with the roadside unit via a connecting vehicle that is part of the vehicle convoy and can communicate with the roadside unit. This studied configuration can extend the communication time between the vehicle and the roadside unit, and as a result, the size of data that can be distributed can be increased.

[0008] In such a configuration, it is preferable that communication routes within a vehicle group be set in advance so that communication can be initiated promptly when a communication request is generated from a vehicle outside the area. Meanwhile, the configuration of a vehicle group is dynamically changed. Therefore, the communication routes within the vehicle group should also be dynamically updated in response to reorganization of the vehicle group. However, Patent Document 1 and Non-Patent Document 1 do not consider at all a method for generating communication routes within a vehicle group.

[0009] The present disclosure has been made based on the above considerations or points of view, and one of its objectives is to provide a communication control method, communication device, and program that can efficiently create communication paths within a vehicle fleet. [Means for solving the problem]

[0010] The communication control method disclosed herein is executed in a communication device configured to be able to perform direct wireless communication with another device, which is a communication device mounted on another vehicle. ,Direct communication between the hop source and the hop destination is performed multiple times to send data to the final destination. A communication control method in which the same vehicle as the own vehicle within the group The communication path in and contains per-destination hop information and metrics. Communication route data within the vehicle fleet update To do, Members who are other vehicles belonging to the group From the said Member acquiring intra-vehicle group communication route data held by the as other-vehicle route data; Including, Updating the communication route data within the vehicle group is Integrating other vehicle route data acquired from the vehicle with the vehicle-flock communication route data held by the vehicle itself. When an adjacent node that is a member with a received signal strength equal to or greater than a predetermined value is detected, the vehicle exchanges intra-vehicle group communication route data with the adjacent node, adds 1 to the metric indicated in the other vehicle route data received from the adjacent node, creates a temporary table that is a route table to the member via the adjacent node, compares the temporary table with the intra-vehicle group communication route data held by the vehicle itself, and adopts the route with the smaller metric for the route data to the same destination. Includes.

[0011] The communication device of the present disclosure is configured to be able to directly communicate wirelessly with another device, which is a communication device mounted on a vehicle. ,Direct communication between the hop source and the hop destination is performed multiple times to send data to the final destination. A communication device that is connected to the same vehicle as your own. within the group The communication path in and contains per-destination hop information and metrics. Communication route data within the vehicle fleet update To do, Members who are other vehicles belonging to the group From the said Member acquiring intra-vehicle group communication route data held by the as other-vehicle route data; and updating the communication route data within the vehicle group is performed by the member Integrating other vehicle route data acquired from the vehicle with the vehicle-flock communication route data held by the vehicle itself. and when an adjacent node that is a member with a received signal strength equal to or greater than a predetermined value is detected, exchanging intra-vehicle group communication route data with the adjacent node, adding 1 to the metric indicated in the other vehicle route data received from the adjacent node, creating a temporary table that is a route table to members via the adjacent node, comparing the temporary table with intra-vehicle group communication route data held by the own vehicle, and adopting a route with a smaller metric for route data to the same destination. .

[0012] Furthermore, the program disclosed herein is configured to be able to directly communicate wirelessly with another device that is a communication device mounted on another vehicle. ,Direct communication between the hop source and the hop destination is performed multiple times to send data to the final destination. The computer in the communication device has the same car as your own. within the group The communication path in and contains per-destination hop information and metrics. Communication route data within the vehicle fleet update To do, Members who are other vehicles belonging to the group From the said Member acquiring intra-vehicle group communication route data held by the as other-vehicle route data; and updating the communication route data within the vehicle group. Integrating other vehicle route data acquired from the vehicle with the vehicle-flock communication route data held by the vehicle itself. and when an adjacent node that is a member with a received signal strength equal to or greater than a predetermined value is detected, exchanging intra-vehicle group communication route data with the adjacent node, adding 1 to the metric indicated in the other vehicle route data received from the adjacent node, creating a temporary table that is a route table to members via the adjacent node, comparing the temporary table with intra-vehicle group communication route data held by the own vehicle, and adopting a route with a smaller metric for route data to the same destination. .

[0013] According to the above-described method, communication device, and program, a communication device uses intra-vehicle group communication route data held by other devices to create new intra-vehicle group communication route data for itself. In other words, existing intra-vehicle group communication route data can be reused, making it possible to efficiently create communication routes in response to changes in the vehicle group.

[0014] Note that the symbols in parentheses in the claims indicate a correspondence with the specific means described in the embodiments described below as one aspect, and do not limit the technical scope of the present disclosure. [Brief explanation of the drawings]

[0015] [Figure 1] 1 is a diagram illustrating an overall view of a vehicle communication system; [Figure 2] FIG. 1 is a diagram illustrating the relationship between a central server, an edge server, and an RSU. [Figure 3] FIG. 1 is a diagram illustrating an example of a vehicle group. [Figure 4] FIG. 10 is a diagram illustrating an example of setting communication routes within a vehicle group at each time point. [Figure 5] FIG. 1 is a block diagram showing a configuration of an in-vehicle system. [Figure 6] FIG. 10 is a diagram illustrating the configuration of a short-range communication packet. [Figure 7] FIG. 2 is a functional block diagram for explaining the flow of data within the in-vehicle system. [Figure 8] FIG. 10 is a diagram illustrating an RSU connection table. [Figure 9] FIG. 10 is a diagram illustrating an example of route allocation for each application. [Figure 10] FIG. 10 is a diagram illustrating an example of a correspondence relationship between a destination and a hop destination (transfer destination). [Figure 11] FIG. 1 is a diagram illustrating a configuration of a wireless base station. [Figure 12] A diagram showing the configuration of an RSU. [Figure 13] FIG. 10 is a functional block diagram of an RSU involved in transmitting and receiving data. [Figure 14] FIG. 2 is a diagram illustrating a configuration of an edge server. [Figure 15] FIG. 2 is a functional block diagram of an edge server. [Figure 16] FIG. 2 is a diagram illustrating the configuration of a central server. [Figure 17] 10 is a flowchart illustrating a flow of a route update when a member joins. [Figure 18] FIG. 10 is a diagram illustrating a simulated scene in which two vehicle groups merge. [Figure 19] FIG. 10 is a diagram showing changes in the route table in the vehicle-mounted device that has detected a subscriber device. [Figure 20] FIG. 10 is a diagram for explaining a process of updating a route table in a detector. [Figure 21] FIG. 10 shows a self table updated with a path table from a detector. [Figure 22] FIG. 10 is a diagram for explaining a change in the route table accompanying a change in the positional relationship. [Figure 23] FIG. 10 is a diagram illustrating updating of a self table using a temporary table. [Figure 24] FIG. 10 is a diagram showing an example of the operation of the remaining aircraft when a detached aircraft occurs. DETAILED DESCRIPTION OF THE INVENTION

[0016] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. Fig. 1 is a diagram showing an example of a schematic configuration of a vehicle communication system Sys according to the present disclosure. In the following, as an example, it is assumed that the system is used in an area where traffic drives on the left, and the leftmost lane in the direction of travel is referred to as the first lane. In an area where traffic drives on the right, the rightmost lane can be the first lane.

[0017] <Overall structure> As shown in FIG. 1, the vehicle communication system Sys may include an on-board device 1, a wireless base station 2, an RSU (Roadside Unit) 3, an edge server 4, and a central server 5.

[0018] The on-board device 1 is a communication device that has the function of performing wireless communication with other vehicles, the RSU 3, and the wireless base station 2. The on-board device 1 is installed in each of multiple vehicles and used. The on-board device 1 is configured to be capable of short-range communication with other on-board devices 1 and the RSU 3. Here, short-range communication refers to communication that complies with a predetermined wireless communication standard in which the actual communication distance is, for example, about 150 m or 250 m. Any standard such as DSRC (Dedicated Short Range Communications) or Cellular V2X (PC5) can be used as the short-range communication standard here.

[0019] Although FIG. 1 shows only two vehicles equipped with the on-board device 1, there may actually be three or more vehicles in the entire system. Hereinafter, for a certain on-board device 1, the vehicle in which the on-board device 1 is installed will also be referred to as the subject vehicle, and vehicles other than the subject vehicle will also be referred to as other vehicles. Hereinafter, the term "vehicle" refers to a vehicle equipped with the on-board device 1 unless otherwise noted. The on-board device 1 corresponds to a communication device.

[0020] In addition, in this disclosure, the vehicle-mounted device 1 itself will be referred to as its own device in order to distinguish it from other vehicle-mounted devices 1, and the vehicle-mounted device 1 used in another vehicle will be referred to as another device. Since there is a one-to-one relationship between the vehicle and the vehicle-mounted device 1, the expression "vehicle" as the source / destination of a wireless signal / data / packet can be read as "vehicle-mounted device." Therefore, the expressions "own device" / "other device" in the following description can be read as "own vehicle" / "other vehicle."

[0021] There may also be multiple wireless base stations 2, multiple RSUs 3, and multiple edge servers 4. For example, as shown in Figure 2, multiple edge servers 4 are connected to a central server 5, and multiple RSUs 3 are connected to each of the multiple edge servers 4.

[0022] The wireless base station 2 is a wireless device that provides a mobile communication system that complies with, for example, the 4G / LTE (Long Term Evolution) standard. The wireless base station 2 is also called an eNB (evolved NodeB). In this disclosure, wireless communication using a method that can achieve a communication distance of 500 m or more is called wide-area communication. The dashed-dotted line in FIG. 1 indicates the communication range of the wireless base station 2.

[0023] The wireless base station 2 may provide wireless communication conforming to the 3G standard. Furthermore, the wireless base station 2 may be equipment (so-called gNB: next generation NodeB) that performs wireless communication conforming to 5G if the communication range can be formed relatively wide. The following embodiments can be implemented by modifying them as appropriate so as to conform to communication architectures such as LTE / 4G / 5G defined by 3GPP (Third Generation Partnership Project). Portions not described in this disclosure can be implemented using methods defined in standards such as LTE.

[0024] The radio base station 2 is connected to a core network CN via an access line such as an IP (Internet Protocol) network. The radio base station 2 relays traffic between the in-vehicle device 1 and the core network CN. The core network CN is a so-called EPC (Evolved Packet Core). The core network CN includes various facilities such as an MME (Mobility Management Entity) and an S-GW (Serving Gateway). The core network CN may include, for example, the Internet, a private network, a public communication network, etc. Part or all of the core network CN can be replaced with a 5th Generation Core network (5GC).

[0025] The RSU3 is a wireless communication device installed along a road and configured to be able to perform short-range communication. The RSU3 is sometimes called a roadside unit. The RSU3 forms a communication range that is relatively narrower than that of the wireless base station 2. For example, the RSU3 forms a communication area with a radius of approximately 50 m to 250 m. The two-dot chain line in FIG. 1 conceptually indicates the communication area of ​​the RSU3. In the present disclosure, communication between the RSU3 and the in-vehicle device 1 is also referred to as road-to-vehicle communication. Note that the RSU3 may perform 5G communication. In other words, the RSU3 may be a gNB.

[0026] The edge server 4 is a facility that performs so-called edge computing, collecting data from a large number of in-vehicle devices 1 and RSUs 3 and analyzing the collected data. The data collected and analyzed by the edge server 4 is transmitted to the central server 5. The edge server 4 may be realized by utilizing facilities that constitute the core network CN, such as an MME or an S-GW. Such an edge server 4 can be called an edge container.

[0027] The edge server 4 is arranged, for example, for each predetermined management area. The management area may correspond to a mesh, which is a division unit of a map, or may be an administrative division unit such as a prefecture, or may be another division unit. The management area corresponds to an area from which the edge server 4 can collect information. The edge server 4 compiles reports from the RSUs 3 and onboard devices 1 present within its own management area and reports them to the central server 5. In addition, the edge server 4 may have a function to generate and distribute control data for a group of vehicles present within the management area or for individual vehicles.

[0028] The central server 5 corresponds to a type of application server. For example, the central server 5 updates and distributes static map data and dynamic map data based on data provided by the edge servers 4. The static map data indicates road structures and the locations of various features. The features include traffic signs and road markings.

[0029] Dynamic map data is data related to dynamic map elements whose positions and status change over time, from minutes to hours. Dynamic map elements include, for example, congested sections, construction sections, broken-down vehicles, fallen objects, accident locations, lane-restricted sections, traffic volume, weather, and road surface conditions. Dynamic map data may also include average driving speeds and traffic volumes for each road segment, which is the management unit for roads. In other words, dynamic map data can be understood as data that shows relatively real-time traffic conditions.

[0030] The central server 5 distributes adjacent area information to each edge server 4. The adjacent area information is traffic condition data for areas within a specified distance from the area managed by other adjacent edge servers 4. The adjacent area information can be used for organizing vehicle convoys, etc. The division of roles between the central server 5 and the edge servers 4 can be changed as appropriate. The functions of the edge server 4 may be integrated into the central server 5. The edge servers 4 and the central server 5 correspond to external servers.

[0031] <Description of the convoy> In this embodiment, each vehicle communicates with the RSU 3 in units of a vehicle group, as shown in FIG. 3. A vehicle group here refers to a group of multiple vehicles. There can be multiple vehicle groups in the entire vehicle communication system Sys. FIG. 3 illustrates a state in which vehicles A to F form one vehicle group Gr. Vehicle A is the leading vehicle of the vehicle group Gr, and vehicle F is the trailing vehicle of the vehicle group Gr. As an example, the RSU 3 is placed on the shoulder on the first lane side.

[0032] In the present disclosure, multiple vehicles constituting a vehicle group are divided into connecting vehicles Mx and general vehicles My. A connecting vehicle Mx is a vehicle in the vehicle group that performs short-range communication with an RSU3. The connecting vehicle Mx plays a role of relaying communication between a general vehicle My and an RSU3. The connecting vehicle Mx can also be called a representative vehicle because it represents the vehicle group in one aspect. A general vehicle My is a vehicle that is not a connecting vehicle Mx. The general vehicle My communicates with an RSU3 via the connecting vehicle Mx. An out-of-area vehicle, which is a vehicle that exists at least outside the communication area of ​​an RSU3, operates as a general vehicle My. Because the relative position of a vehicle with respect to an RSU3 changes as the vehicle travels, the vehicle that plays the role of connecting vehicle Mx may change over time among vehicles belonging to the same vehicle group. The vehicle group configuration (formation) and the time-specific configuration of connecting vehicles Mx within the vehicle group are performed by the edge server 4.

[0033] In the example shown in FIG. 3, vehicles A, B, and C first connect to the RSU 3 in order as connected vehicles Mx. While vehicle A is a connected vehicle, it distributes the data for the vehicle group received by vehicle A to vehicles B to F as general vehicles My according to a pre-established intra-vehicle group communication route. The data for the vehicle group is data that should be used by all of the multiple vehicles that make up the vehicle group, such as data related to cruise control for each vehicle group, static map data, and dynamic map data. The intra-vehicle group communication route can be configured as a tree topology with the connected vehicle Mx as the root node, as shown in FIG. 4. As described above, the connected vehicle Mx changes dynamically, and therefore the intra-vehicle group communication route also changes over time.

[0034] The intra-vehicle group communication path is reversible. That is, the intra-vehicle group communication path is a communication path from the connecting vehicle Mx to the general vehicle My, and also a communication path from the general vehicle My to the connecting vehicle Mx. The intra-vehicle group communication path corresponds to a short-range communication path for the general vehicle My to communicate data with an external server via the connecting vehicle Mx and the RSU3.

[0035] Hereinafter, the onboard device 1 used in the connecting vehicle Mx, in other words, the onboard device 1 that has established a short-range communication link with the RSU 3, will be referred to as a connecting node 1x. The connecting node 1x can also be called a representative node. In this disclosure, the onboard device 1 used in the general vehicle My will also be referred to as a general node 1y. In the following, the terms connecting node 1x and general node 1y can be replaced with the terms connecting vehicle Mx and general vehicle My.

[0036] Note that the onboard units 1 belonging to a vehicle group can share and complement each other's data for the vehicle group, which is distributed from the RSU 3 in a state of being divided into multiple pieces, through vehicle-to-vehicle communication. Furthermore, each onboard unit 1 may be programmed so that only one of the onboard units 1 constituting the vehicle group uploads probe data indicating the driving environment. For example, the onboard unit 1 of the leading vehicle may be configured to generate and transmit the probe data. If an onboard unit 1 other than the leading vehicle is a connection node 1x during a period in which the onboard unit 1 of the leading vehicle is a connection node 1x, the onboard unit 1 of the leading vehicle may upload the probe data via the connection node 1x according to the time.

[0037] <About the in-vehicle device connected to in-vehicle device 1> 5, the on-vehicle device 1 is connected to a vehicle state sensor 6, a periphery monitoring sensor 7, a locator 8, and an ECU 9 via an in-vehicle network IvN, which is a communication network established within the vehicle. The ECU 9 is an abbreviation for Electronic Control Unit and refers to an electronic control device. In the present disclosure, the configuration including the on-vehicle device 1 itself and various devices connected to the on-vehicle device 1 is also referred to as an on-vehicle system IvS.

[0038] The vehicle state sensor 6 is a sensor that detects state quantities related to the driving control of the host vehicle. The vehicle state sensor 6 includes a shift sensor, a driving speed sensor, a steering angle sensor, an acceleration sensor, etc. The types of sensors to be connected to the on-board device 1 as the vehicle state sensor 6 may be designed as appropriate, and it is not necessary to include all of the sensors described above.

[0039] The perimeter monitoring sensor 7 is a sensor that detects the environmental conditions around the vehicle. Examples of the perimeter monitoring sensor 7 include a perimeter monitoring camera that captures an image of a predetermined area around the vehicle, a millimeter-wave radar that transmits a search wave within a predetermined area around the vehicle, a sonar, and a LiDAR. LiDAR stands for Light Detection and Ranging or Laser Imaging Detection and Ranging. The perimeter monitoring sensor 7 detects objects around the vehicle, such as moving objects and obstacles. Moving objects can include vehicles, bicycles, pedestrians, and animals. Obstacles refer to stationary, three-dimensional objects such as guardrails and utility poles. Falling objects, parked vehicles, construction zones, and lane-restricted zones can also be considered obstacles. The perimeter monitoring sensor 7 also detects road markings such as lane markings and stop lines, as well as traffic signs. The detection results of the perimeter monitoring sensor 7 are sequentially input to the in-vehicle device 1.

[0040] The locator 8 is a device that sequentially calculates the position of the vehicle. For example, the locator 8 includes a GNSS receiver that receives positioning signals transmitted by positioning satellites that constitute the GNSS (Global Navigation Satellite System), and calculates the position using the positioning signals received by the GNSS receiver. The locator 8 can identify the vehicle's lane ID, etc. The vehicle's lane ID is a number that indicates which lane the vehicle is traveling in from the left or right edge of the road, and can also be called a driving lane ID. Position information that indicates the current position sequentially identified by the locator 8 is provided to the in-vehicle device 1. The function of identifying the vehicle's lane ID may be provided by a surrounding monitoring camera or a specific ECU 9.

[0041] The ECU 9 is a computer equipped with a processor, memory, storage, etc. The ECU 9 is configured to be able to execute one or more application software (hereinafter referred to as application X). Application X is a program that runs on the ECU 9. Application X realizes a predetermined service / function by communicating with the central server 5. In this disclosure, the terms "application" / "app" can be interpreted as a device / computing core that executes an application. The computing core refers to a processor such as a CPU (Central Processing Unit).

[0042] Note that "App" in FIG. 5 is an abbreviation for application (app). "AppN" in the figure means the Nth app. For example, "App1" refers to the first app X1. Although only one ECU 9 is shown in FIG. 5, multiple ECUs 9 can be connected to the in-vehicle device 1. Furthermore, the in-vehicle system IvS can have three or more apps X. Each of the multiple apps X provides a different service / function. The in-vehicle system IvS can have a variety of apps, such as a driving assistance app and a probing app.

[0043] The driving assistance app is an app that provides a function to assist the driver in driving. For example, the driving assistance app automatically adjusts the driving speed based on the detection results of the perimeter monitoring sensor 7, or controls the steering angle to keep the vehicle within the lane. The driving assistance app corresponds to a vehicle control app. The probing app is an app that uploads probe data to the central server 5. The probe data here is, for example, a data set indicating the position coordinates of features detected by the perimeter monitoring sensor 7. The probe data may also include vehicle behavior information such as the driving speed, steering angle, yaw rate, turn signal operation status, and wiper operation status.

[0044] An application ID, which is unique identification information, is assigned to each application X. The application ID may be assigned by the designer / distributor of the application X, or may be assigned by a predetermined ECU 9 that comprehensively manages the installation of software in the vehicle (actually, the ECU 9) when the application X is installed in the vehicle.

[0045] Note that some or all of the various devices described above may be directly connected to the on-board device 1 without going through the in-vehicle network IvN. Furthermore, the devices connected to the on-board device 1 are not limited to those exemplified above.

[0046] <Configuration of in-vehicle device 1> The in-vehicle device 1 includes a control unit 11, an in-vehicle communication unit 12, and a wireless module 13. The control unit 11 is mainly configured as a computer. The control unit 11 includes a processor 111, a memory 112, and a storage 113. The processor 111 is, for example, a CPU. The memory 112 is, for example, a volatile memory such as a RAM (Random Access Memory). The storage 113 is configured to include a non-volatile storage medium such as a flash memory. The storage 113 stores a vehicle communication control program as a program executed by the processor 111. The vehicle communication control program corresponds to a program for causing the processor 111 to execute a communication control method.

[0047] The in-vehicle communication unit 12 is a circuit module for communicating with other in-vehicle devices via the in-vehicle network IvN. The in-vehicle communication unit 12 is implemented using analog circuit elements, ICs, PHY chips conforming to the communication standards of the in-vehicle network IvN, and the like. The in-vehicle communication unit 12 outputs sensor data received from the vehicle state sensors 6 and the like to the control unit 11. Examples of the sensor data include the driving speed, remaining charge, acceleration, steering angle, wiper operation status, shift position, turn signal operation status, and vehicle position. The remaining charge refers to the remaining charge of the battery. If the vehicle has a fuel tank, the remaining amount of fuel (e.g., gasoline) is also included in the sensor data. Obstacle information detected by the perimeter monitoring sensor 7 and vehicle position information identified by the locator 8 are also included in the sensor data.

[0048] The wireless module 13 is a module equipped with a circuit for wireless communication with an external device, and includes, for example, a wide-area communication unit 131 and a narrow-area communication unit 132. The wide-area communication unit 131 and the narrow-area communication unit 132 each include an antenna according to the frequency used for communication, a modulation / demodulation circuit, and the like. For the in-vehicle device 1, an external device refers to communication equipment located outside the vehicle, such as another device, a wireless base station 2, or an RSU 3. By including the wireless module 13, the in-vehicle device 1 can communicate data with an edge server 4 or the like via the wireless base station 2 or the RSU 3.

[0049] The wide-area communication unit 131 is a communication module for performing wide-area communication. The wide-area communication unit 131 is wirelessly connected to the wireless base station 2 and transmits and receives data based on instructions from the control unit 11. The wide-area communication unit 131 can generate data indicating the quality of communication with the wireless base station 2 (hereinafter, wide-area communication quality) and output it to the control unit 11. The data indicating the wide-area communication quality includes, for example, received signal strength indication (RSSI), transmission speed, latency (response time), and packet loss rate.

[0050] If the vehicle-mounted device 1 is configured to use multiple wide-area communication lines by including multiple SIMs (Subscriber Identity Modules), the wide-area communication unit 131 generates data indicating wide-area communication quality for each wide-area communication line. In this disclosure, the communication quality for each wide-area communication line is collectively referred to as the wide-area communication status. Note that the control unit 11 may have a function to calculate some of the data indicating the various communication qualities described above.

[0051] The short-range communication unit 132 is a communication module for performing short-range communication. The short-range communication unit 132 performs signal processing (e.g., modulation and demodulation) for transmitting and receiving wireless signals compliant with short-range communication standards. The short-range communication unit 132 can generate data indicating the quality of communication with the RSU 3 or other devices (hereinafter, short-range communication quality) and output the data to the control unit 11. Examples of data indicating the short-range communication quality include RSSI, SNR (Signal-to-Noise Ratio), and packet loss rate. The short-range communication unit 132 generates data indicating the short-range communication quality for each communication partner. In the present disclosure, the short-range communication quality for each communication partner is also collectively referred to as the short-range communication status. Note that the control unit 11 may have a function for calculating part of the data indicating the short-range communication quality.

[0052] In the present disclosure, a wireless signal exchanged in short range communication is also referred to as a short range communication signal or a short range communication packet. Note that a user packet exchanged in short range communication includes a payload section, a source field, a final destination field, a hop source field, and a hop destination field, as shown in FIG. 6, for example. The user packet is a packet generated by application X. The payload section is an area where the data itself is stored. The source field is an area where source information indicating the source (creator) of the packet is stored. The source information can also be called GS (Global Source). The final destination field is an area where final destination information indicating the final destination of the packet is stored. The final destination information can be called GD (Global Destination).

[0053] The source information and final destination information may be expressed by a vehicle ID, a device ID, or an IP address. The source and final destination are preferably expressed by a globally unique identifier, which is identification information that uniquely determines a device across the entire network. The source information and final destination information may also be expressed by a combination of an IP address and a port number. The source field and final destination field may be part of a layer 3 header, for example, part of an IP header or a TCP header.

[0054] The hop source field is an area where information indicating the direct sender of the packet is stored. The hop source can also be called LS (Local Source). The hop destination field is an area where information indicating the destination of the packet is stored. The hop destination information can be called LD (Local Destination). The hop source information and hop destination information may be expressed by a vehicle ID, a device ID, a MAC address, etc. The hop source and hop destination may also be expressed by a locally unique identifier, which is an identification number that is dynamically set so that it is different for each device within a short-range communication range. The source field and destination field may correspond to part of the Layer 2 header. The arrangement order of the various fields can be changed as appropriate. Between the hop source field and the final destination field, fields may be provided in which other information such as the service type, time to live (TTL), protocol, etc. is stored.

[0055] 7 is a functional block diagram showing the flow of data within the in-vehicle system IvS. The in-vehicle system IvS includes a wireless module 13, at least one application X, an in-vehicle device storage unit M1, a route selection unit F11, and a route control unit F12. The in-vehicle device storage unit M1, the route selection unit F11, and the route control unit F12 are functional units realized by the control unit 11 executing a vehicle communication control program.

[0056] As described above, the wireless module 13 includes the wide-area communication unit 131 and the short-range communication unit 132. The wireless module 13 wirelessly transmits a transmission packet input from the route selection unit F11 via a route specified by the route selection unit F11. The wireless module 13 also outputs a received packet, which is a packet received via wide-area communication or short-range communication, to the route selection unit F11.

[0057] As described above, application X is a software configuration executed by the ECU 9. A part of application X may run on the control unit 11. Application X generates a packet to be transmitted to the central server 5 or the edge server 4 and inputs the packet to the route selection unit F11. Application X also receives a packet addressed to itself from the route selection unit F11.

[0058] Application X outputs application information to the route control unit F12. App_Info in FIG. 7 indicates application information. Application information is information indicating, for example, an application ID, application type, and communication requirements (communication characteristics). Possible application types include driving control, security, and entertainment. Communication requirements include the allowable latency, allowable RTT, main communication direction, communication frequency, and average size. The allowable latency indicates the waiting time until communication starts that application X can tolerate. The allowable RTT indicates the response delay time that application X can tolerate. The main communication direction indicates which is larger, uplink (sending) or downlink (receiving). The communication frequency indicates the frequency of data transmission / reception. The average size indicates the estimated size of data sent or received by application X. Based on the application information, the route control unit F12 can determine / change the port number, packet transmission priority, assigned route, etc. for each application X.

[0059] The in-vehicle device memory unit M1 is a storage medium that stores various data necessary for communication control, such as vehicle group setting data, an RSU connection table, a route table, and RSU location information. The in-vehicle device memory unit M1 is realized using a part of the storage area of ​​the memory 112 or the storage 113.

[0060] Vehicle group setting data is data that indicates the setting (formation) of a vehicle group. The vehicle group setting data includes a list of other vehicles (and ultimately other machines) that make up the vehicle group. The vehicle group refers to the vehicle group to which the vehicle belongs, as seen from the route control unit F12. The vehicle group setting data is created and distributed by the edge server 4.

[0061] The vehicle group setting data may include information on a vehicle group to be joined, which is an onboard device 1 that is scheduled to join the vehicle group, and a vehicle group to be left, which is an onboard device 1 that is scheduled to leave the vehicle group. The vehicle group setting data may include the time / location coordinates at which the onboard device to be joined is scheduled to join, and the time / location coordinates at which the onboard device to be left is scheduled to leave. The vehicle group setting data may also include information such as the ID of another vehicle group that is scheduled to merge with the vehicle group within a predetermined time, and the scheduled merging point. Furthermore, the vehicle group setting data may include data indicating a medium-term driving plan for the vehicle group, created by the edge server 4. The medium-term driving plan includes target values ​​such as driving lane IDs and driving speeds for road sections that are scheduled to be passed through within a predetermined time, such as one minute or five minutes.

[0062] The vehicle-mounted device 1 may acquire the vehicle group setting data via the RSU 3 or may receive it from the wireless base station 2. In this disclosure, a communication path via the RSU 3 is referred to as a short-range communication path, and a path via the wireless base station 2 is referred to as a wide-area communication path. The route control unit F12 updates the vehicle group setting data stored in the vehicle-mounted device memory unit M1 based on the vehicle group setting data transmitted from the edge server 4.

[0063] Furthermore, the route control unit F12 receives data on other vehicle groups, which are other vehicle groups adjacent to the own vehicle group, from the edge server 4 as other vehicle group data and stores it in the vehicle-mounted device memory unit M1. The other vehicle group data also includes the current location, movement direction, movement speed, etc. of the other vehicle group. The other vehicle group data corresponds to adjacent information at the vehicle group level. The other vehicle group data may include information on other vehicle groups / vehicle-mounted devices 1 that are scheduled to merge with the own vehicle group. The other vehicle groups that are scheduled to merge correspond to the scheduled merging vehicle groups. The other vehicle group data may be integrated with the above-mentioned vehicle group setting data.

[0064] The RSU connection table is a table that shows the connected vehicles Mx (connection nodes 1x) at each time. The RSU connection table includes the connection period for each vehicle-mounted device 1, as shown in FIG. 8, for example. The connection period includes the connection start time and the connection end time. The route control unit F12 updates the RSU connection table stored in the vehicle-mounted device memory unit M1 based on the RSU connection table sent from the edge server 4. The RSU connection table may also include information such as the number of the RSU 3 to be connected and resource allocation information such as frequencies / time slots that can be used for communication.

[0065] The route allocation table is configuration data that indicates the allocation status of a communication route for each application X, as shown in FIG. 9. Elements that configure a communication route include line types, such as short-range communication or wide-area communication. If the wide-area communication unit 131 is configured to be able to use multiple wide-area communication lines, variations in the wide-area communication lines may also be included as elements of the communication route. Furthermore, if one line has multiple channels, the channel number may also be a component of the communication route. The channels may be divided by frequency, may be realized by time division like time slots, or may be realized by different modulation methods.

[0066] In the example shown in FIG. 9, the first channel of the short-range communication line is assigned to the first application, the second channel of the short-range communication line is assigned to the second application, the third channel of the short-range communication line is assigned to the third application, and the first and second channels of the wide-area communication line are assigned to the fourth application. Applications to which wide-area communication lines are assigned include, for example, emergency call applications, which require high real-time / immediacy. The route control unit F12 dynamically changes the route assignment status for each application based on the application information provided by application X and the status of each communication route. Of course, the communication route assigned to application X may be fixed.

[0067] In a real environment, there may be a situation where there is no on-board device 1 functioning as a connection node 1x in the vehicle group, such as when there is no RSU 3 near the vehicle group. In such a situation where the vehicle group itself cannot connect to the RSU 3, the route control unit F12 may change the assigned route of each application X so that wide-area communication is adopted as a means of communication with the central server 5. When short-range communication is not possible for each vehicle group, the control policy, such as whether to wait for data transmission or to use a wide-area communication route, may differ depending on the communication requirements of each application X.

[0068] The route table held by the vehicle-mounted device 1 is a table that indicates the destination according to the final destination of the short-range communication packet. The route table held by the vehicle-mounted device 1 corresponds to the intra-vehicle group communication route data. The route table can also be called topology information, network information, etc. The route table includes hop destination information for each destination, as shown in the example of Figure 10. Figure 10 is an example of a route table for short-range communication held by the vehicle-mounted device 1 used in vehicle F. The route table is created by the route control unit F12 performing a route update process.

[0069] The route selection unit F11 has a configuration equivalent to a router. For a packet input from the application X or the route control unit F12, the route selection unit F11 selects a transmission route according to the packet's origin, and causes the wireless module 13 to transmit the packet in a manner according to the selected route. For example, for a packet to be transmitted by short-range communication, the route selection unit F11 adds a header that sets the final destination, the current connection node 1x, or a hop destination according to the hop source, and outputs the packet to the short-range communication unit 132. For a packet to be transmitted by wide-area communication, the route selection unit F11 adds a Layer 2 header that complies with the wide-area communication standard, and outputs the packet to the wide-area communication unit 131.

[0070] The route selection unit F11 also processes the received packet input from the wireless module 13 according to the final destination. If the received packet is a packet whose final destination is application X of the host vehicle, it outputs the received packet to the application X. If the received packet is a control packet such as vehicle group setting data whose final destination is the route control unit F12, it forwards the received packet to the route control unit F12. If the packet received via short-range communication is a packet whose destination is another device, an RSU 3, or an external server, it forwards the received packet to the hop destination indicated in the route table.

[0071] The route control unit F12 performs mobility management such as selecting a serving cell based on, for example, the reception strength of a reference signal transmitted from the wireless base station 2. In addition, the route control unit F12 detects the presence of the RSU 3 by receiving a predetermined control signal emitted from the RSU 3, and establishes a communication connection with the RSU 3 based on the RSU connection table.

[0072] The route control unit F12 also periodically transmits advertising packets from the short-range communication unit 132. The advertising packet is a signal for notifying other devices and the RSU3 of the presence of the device itself, and includes at least source information indicating the source of the signal. The advertising packet may also be called a Hello packet. The advertising packet may be a packet for confirming communication. The advertising packet may include vehicle information of the source, such as the source's current location, traveling direction, traveling speed, and acceleration. The advertising packet may be a signal equivalent to a CAM (Cooperative Awareness Message) or a BSM (Basic Safety Message). The route control unit F12 basically transmits the advertising packet in the form of multicast, broadcast, or geocast.

[0073] In this embodiment, as an example, the route control unit F12 periodically transmits advertisement packets. Also, when a route confirmation event occurs, the route control unit F12 may transmit advertisement packets to check adjacent nodes.

[0074] In other embodiments, the vehicle-mounted device 1 may not periodically transmit advertising packets. For example, the vehicle-mounted device 1 may transmit advertising packets triggered by the detection of a previously undetected vehicle by the perimeter monitoring sensor 7. The vehicle-mounted device 1 may also be configured to transmit advertising packets triggered by the reception of a specific control packet from the edge server 4. The specific control packet refers to a packet notifying the presence and timing of a vehicle to join or leave the vehicle group, or a packet instructing a change in the vehicle group to which the vehicle belongs or a split / combination of the vehicle group. The vehicle-mounted device 1 may be configured to periodically transmit advertising packets only for a predetermined period after a trigger, such as the detection of a new vehicle by the perimeter monitoring sensor 7 or the reception of a specific control signal from the edge server 4, has been detected. In this case, the vehicle-mounted device 1 may suspend the periodic transmission of advertising packets during other periods.

[0075] When the route control unit F12 receives a short-range communication packet transmitted from another device or the RSU 3, it associates the source information indicated in the received packet with the communication quality data of the received packet and stores the data in the memory 112. In other words, the route control unit F12 stores the communication quality data for each communication partner separately.

[0076] Furthermore, the route control unit F12 extracts other devices whose RSSI of received packets is equal to or greater than a predetermined value (referred to as an adjacent node recognition value) as adjacent nodes. An adjacent node corresponds to a party with which direct data communication is possible. The adjacent node recognition value is set to a value that allows stable inter-vehicle communication. Note that the conditions (specific conditions) for determining an adjacent node may include an SNR of equal to or greater than a predetermined value, or a packet loss rate within a predetermined time period of equal to or less than a predetermined value.

[0077] The route control unit F12 performs a route update process based on the occurrence of a predetermined route confirmation event, and updates the route table in the in-vehicle device storage unit M1. The route confirmation event is registered as a specific event related to one of (i) a change in a member, (ii) a change in the positional relationship within the vehicle group, or (iii) a change in the communication status between members. A member refers to another device belonging to the vehicle group.

[0078] A change in members specifically refers to the addition of a new member, the addition of the vehicle to another vehicle group, or the departure of a member. A change in members can be detected based on vehicle group setting data distributed from the edge server 4. For example, the route control unit F12 detects a change in members based on receiving vehicle group setting data from the edge server 4 that instructs a change in member configuration / belonging vehicle group. Note that a change in members may also be detected based on the detection results of the perimeter monitoring sensor 7.

[0079] A change in the positional relationship within a group of vehicles specifically refers to a change in the front-to-back / left-to-right positional relationship between members due to overtaking or changing lanes. The change in relative position in real space due to overtaking or the like may be identified based on the detection results of the perimeter monitoring sensor 7, or may be detected based on the position coordinates of each member received via vehicle-to-vehicle communication.

[0080] A change in the communication state between members corresponds to a case where the reception strength of a signal from another device that has been detected as an adjacent node falls below a predetermined value, or a case where a new adjacent node is detected. A change in the communication state between members can be detected based on the communication quality data provided by the short-range communication unit 132.

[0081] Additionally, the in-vehicle device 1 may register, as a route confirmation event, the fact that the remaining distance to an intersection / junction point falls below a predetermined value. Alternatively, the initiation of operation of a turn signal of the vehicle or a member may be registered as a route confirmation event. The activation of a turn signal can be detected based on the output signal of the perimeter monitoring sensor 7 or data received via vehicle-to-vehicle communication. Furthermore, the entry of a non-member vehicle, such as a vehicle not equipped with the in-vehicle device 1 or a vehicle belonging to another vehicle group, between members can also be used as a route confirmation event. This event can be detected based on the signal of the perimeter monitoring sensor 7. Note that when a non-member vehicle enters between members, the non-member vehicle body may cause fluctuations in the short-range communication environment, potentially resulting in the disconnection of the short-range communication link between members. A configuration in which the route update process is triggered by the entry of a non-member vehicle between members, or the like, enables the construction of a communication route within the vehicle group that corresponds to the actual communication environment in real time. Alternatively, the detection of a device not registered as an adjacent node as an adjacent node may be registered as a route confirmation event.

[0082] The route confirmation event corresponds to the specific event. Note that it is not necessary for all of the above-mentioned events to be registered as route confirmation events in the vehicle-mounted device 1. The route confirmation events registered in the vehicle-mounted device 1 may be only a part of the above-mentioned examples, or events other than those mentioned above may be registered as route confirmation events.

[0083] The route control unit F12 also acquires various sensor data via the in-vehicle network IvN. For example, the route control unit F12 acquires the vehicle's lane ID, obstacle information, surrounding vehicle information, vehicle position information, remaining charge, turn signal operation status, wiper operation status, etc. The surrounding vehicle information refers to the position and movement speed of other vehicles detected by the perimeter monitoring sensor 7, the distance between the vehicle and the vehicle, etc. The route control unit F12 may identify the driving environment using other vehicle information received from other vehicles by the short-range communication unit 132, dynamic map data received from the RSU 3 or the wireless base station 2, etc.

[0084] The route control unit F12 generates a status report at a predetermined interval, which indicates the status of short-range communication between the own device and other devices and the current state of the own vehicle, packetizes the report, and outputs it to the route selection unit F11. The status report can be divided into multiple packets depending on the data size and transmitted. The packet corresponding to the status report is a type of control packet.

[0085] The current status report includes sender information and information on adjacent nodes. The current status report also includes data indicating the short-range communication quality for each communication partner. This allows the edge server 4, which receives the information, to identify the communication status between vehicles that are in a positional relationship where vehicle-to-vehicle communication is possible, such as combinations of vehicles with good communication quality and combinations with difficult or unstable communication. The current status report corresponds to the short-range communication environment, i.e., a list of other vehicles with which short-range communication is possible, and a control packet indicating the communication quality with each vehicle. Furthermore, the current status report may include data indicating the wide-area communication status.

[0086] The current status report may also include sensor data, i.e., the vehicle's lane ID, obstacle information, vehicle position information, remaining charge, turn signal operation status, wiper operation status, etc. Furthermore, the current status report may also include information such as whether the vehicle is traveling across a lane boundary line, and the time when the packet was generated.

[0087] <Configuration of wireless base station 2> Next, the configuration of the wireless base station 2 will be described with reference to Fig. 11. As shown in Fig. 11, the wireless base station 2 includes a wide-area communication device 21, a network connection device 22, and a base station control unit 23. The wide-area communication device 21 and the network connection device 22 are connected to the base station control unit 23 so as to be able to communicate with each other. Note that "NW" in Fig. 11 and elsewhere is an abbreviation for network.

[0088] The wide-area communication device 21 is a communication module for performing wide-area communication with the in-vehicle device 1. The wide-area communication device 21 outputs received data to the base station control unit 23. The wide-area communication device 21 also transmits data input from the base station control unit 23 using wireless resources instructed by the base station control unit 23. The network connection device 22 is equipment for communicating with the edge server 4 via the core network CN. The network connection device 22 outputs data input from the edge server 4 and the RSU 3 to the base station control unit 23. The network connection device 22 also outputs data input from the base station control unit 23 to the RSU 3 or the edge server 4 depending on the destination of the data.

[0089] The base station control unit 23 is mainly configured as a computer. That is, the base station control unit 23 includes a processor 24, a memory 25, and a storage 26. The base station control unit 23 manages and controls the in-vehicle device 1 connected to the wireless base station 2. For example, the base station control unit 23 performs handover and the like when the in-vehicle device 1 moves. The base station control unit 23 also controls the allocation state of radio resources for each in-vehicle device 1 based on a control signal from, for example, an MME. Based on the allocation of radio resources determined by the base station control unit 23, the wide-area communication device 21 transmits data to the in-vehicle device 1 and receives data from the in-vehicle device 1.

[0090] Furthermore, the base station control unit 23 can function as a router, transferring data input from the edge server 4 and the in-vehicle device 1 to an appropriately specified destination. For example, the base station control unit 23 transmits vehicle group setting data generated by the edge server 4 to each vehicle that makes up the vehicle group. The vehicle group setting data can be distributed by any method, such as unicast, multicast, geocast, or broadcast.

[0091] The destination of the vehicle group setting data may be only one of the plurality of vehicles constituting the vehicle group. In that case, the in-vehicle unit 1 that has received the vehicle group setting data distributes the vehicle group setting data to the members by vehicle-to-vehicle communication. Further, the base station control unit 23 may distribute the medium-term driving plan data for each vehicle group / each vehicle input from the edge server 4 to each vehicle group / vehicle. In addition, the base station control unit 23 performs a process of transferring control packets such as the current situation report transmitted from each of the plurality of vehicles to the edge server 4.

[0092] <Regarding the configuration of RSU3> Here, the configuration of RSU3 will be described. RSU3 is arranged, for example, near intersections or near branch / merging points of expressways. RSU3 may be integrally formed with structures installed along the road, such as traffic signals, lighting facilities, toll gates of toll roads, etc. Here, along the road includes not only the side of the road but also the airspace above the road surface. Further, RSU3 may be installed as a marker buried in the road surface.

[0093] As shown in FIG. 12, RSU3 includes a short-range communication device 31, a network connection device 32, an area monitoring device 33, and an RSU control unit 34. Each of the short-range communication device 31, the network connection device 32, and the area monitoring device 33 is connected to the RSU control unit 34 so as to be able to communicate with each other.

[0094] The short-range communication device 31 is a communication module for performing short-range communication with the in-vehicle unit 1. The short-range communication device 31 also generates information indicating the communication quality with the in-vehicle unit 1 and outputs it to the RSU control unit 34 in association with the received data. The network connection device 32 is a facility for connecting to the core network CN via an optical fiber or the like and communicating with the edge server 4. The network connection device 32 outputs the data input from the edge server 4 to the RSU control unit 34. Further, the data input from the RSU control unit 34 is output to the radio base station 2 or the edge server 4 according to the destination of the data.

[0095] The area monitoring device 33 is a device that monitors the traffic conditions in a monitoring area that is preset for the RSU 3. The area monitoring device 33 can be a camera, LiDAR, millimeter-wave radar, or the like. For example, the area monitoring device 33 detects the position, size, and movement status of moving objects present in the monitoring area as information indicating the traffic conditions. Components of the movement status include the presence or absence of movement, the movement speed, and the movement direction. Furthermore, the traffic conditions can also include road surface conditions, such as whether the road surface is wet due to rain or snow, and weather conditions, such as whether it is raining. One RSU 3 may include one or more area monitoring devices 33. The RSU 3 may include multiple types of sensors, such as a camera and LiDAR, as the area monitoring device 33.

[0096] The RSU control unit 34 is mainly configured as a computer including a processor 35, a memory 36, and a storage 37. The storage 37 stores an RSU control program as a program executed by the processor 35.

[0097] The RSU control unit 34 controls the communication connection between the short-range communication device 31 and the vehicle-mounted device 1. For example, based on the short-range communication device 31 receiving a short-range communication signal, such as an advertising packet, emitted from the vehicle-mounted device 1, the RSU control unit 34 detects the presence of a vehicle-mounted device 1 to be connected (hereinafter, a connection candidate) and performs processing related to the communication connection with the vehicle-mounted device 1.

[0098] 13 is a functional block diagram showing the flow of data within the RSU 3. The RSU 3 comprises an RSU transceiver unit F30, an RSU memory unit M3, an RSU router F31, and a data processing unit F32. The RSU memory unit M3, the RSU router F31, and the data processing unit F32 are functional units realized when the RSU control unit 34 executes an RSU communication control program.

[0099] The RSU transceiver unit F30 is a functional unit for transmitting and receiving data to and from the vehicle-mounted device 1 and the edge server 4. The configuration combining the short-range communication device 31 and the network connection device 32 corresponds to the RSU transceiver unit F30. The RSU transceiver unit F30 outputs packets received from the vehicle-mounted device 1 or the edge server 4 to the RSU router F31. In addition, the RSU transceiver unit F30 transmits packets input from the RSU router F31 to the destination specified by the RSU router F31.

[0100] The RSU memory unit M3 is a storage medium that stores vehicle convoy data, a connection table, a route table, etc. The RSU memory unit M3 is realized using a part of the storage area of ​​the memory 36 or the storage 37. The vehicle convoy data is data about a vehicle convoy that will arrive within the communication area of ​​the RSU3 within a predetermined time, and includes a vehicle convoy ID, which is an identification number of the vehicle convoy, a current location, a movement speed, a movement direction, the number of vehicles, etc. The connection table is a table that shows the connection nodes 1x and their resource allocations for each time. The connection table may be integrated with the vehicle convoy data. The vehicle convoy data and the connection table are distributed from the edge server 4.

[0101] The routing table held by the RSU3 is also a table showing the correspondence between the final destination of a packet and the actual (direct) transmission destination. The routing table corresponds to data indicating a communication route according to the destination. The RSU router F31 transmits a packet input from the data processing unit F32 to the RSU transceiver unit F30 via a route according to the routing table stored in the RSU memory unit M3. The RSU router F31 also performs a process of forwarding a received packet input from the RSU transceiver unit F30 to a device corresponding to the final destination of the packet. If the received packet is a packet whose final destination is the RSU3 itself, the RSU router F31 outputs the received packet to the data processing unit F32.

[0102] The data processing unit F32 updates the vehicle convoy data, connection table, route table, etc. stored in the RSU memory unit M3 based on data transmitted from the edge server 4. The data processing unit F32 also acquires traffic conditions within the monitoring area based on data input from the area monitoring device 33. The data processing unit F32 may identify / correct traffic conditions within the monitoring area using data received from the in-vehicle device 1. The data processing unit F32 transmits traffic condition data for the monitoring area to the edge server 4 via the network connection device 32. The traffic condition data reported by the RSU 3 can be used to generate dynamic map data, create vehicle convoy formations and driving plans, etc.

[0103] Furthermore, when the short-range communication device 31 receives a short-range communication signal from an on-vehicle device 1, the data processing unit F32 stores information indicating the communication quality with the on-vehicle device 1 in association with the transmission source information. The data processing unit F32 transmits the acquired communication status data indicating the communication quality for each on-vehicle device 1 to the edge server 4 via the network connection device 32.

[0104] The data processing unit F32 may obtain information indicating the quality of inter-vehicle communication between vehicles from the connection node 1x and report it to the edge server 4. The communication status data for each on-board unit 1 reported by the RSU 3 may be used for generating a vehicle fleet organization or an RSU connection table in the edge server 4. In addition, the data processing unit F32 periodically calculates the degree of communication load and the usage rate of wireless resources available for short-range communication (so-called congestion degree) and reports them to the edge server 4.

[0105] Additionally, the RSU 3 may receive traffic condition data observed by neighboring RSUs 3 as neighbor information from the edge server 4. The neighboring RSUs 3 may be, for example, other RSUs 3 located within 100 m.

[0106] <Configuration of Edge Server 4> Next, the configuration of the edge server 4 will be described with reference to Fig. 14. As shown in Fig. 14, the edge server 4 includes an edge communications device 41, an edge database 42, and an edge control unit 43. The edge communications device 41 and the edge database 42 are each connected to the edge control unit 43 so as to be able to communicate with each other.

[0107] The edge communication device 41 is equipment for communicating with the wireless base station 2, the RSU 3, and the central server 5. The edge communication device 41 is configured to be able to communicate with the wireless base station 2, the RSU 3, and the central server 5 via, for example, optical fiber. The edge database 42 is a database realized using a rewritable nonvolatile storage medium. The edge database 42 is configured so that the edge control unit 43 can write, read, delete, and so on data.

[0108] The edge database 42 stores various data, such as data transmitted from the onboard device 1 and the RSU 3. For example, the edge database 42 stores data (hereinafter, individual situation data) for each onboard device 1, indicating the current location, driving plan, and implementation status of short-range communication with other vehicles and the RSU 3, in association with the vehicle ID. The individual situation data for each vehicle may include not only data transmitted from the vehicle or the RSU 3, but also information generated within the edge server 4. The individual situation data for each onboard device 1 is stored in any data structure, such as a list format. The individual situation data may include information such as the current travel speed, driving lane ID, traveling direction, and planned points for changing the driving position. As the implementation status of short-range communication between each vehicle and other vehicles, at least one of various items indicating the communication quality with other vehicles as communication partners is registered, for example.

[0109] The edge control unit 43 is mainly configured as a computer. That is, the edge control unit 43 includes a processor 44, a memory 45, and a storage 46. The storage 46 stores an edge program as a program executed by the processor 44. The edge program can be called a V2X edge application. In addition, the storage 46 stores data related to the installation position and communication area of ​​the RSU 3.

[0110] 15 is a block diagram showing the flow of data within the edge server 4. In addition to an edge communications device 41 and an edge database 42, the edge server 4 includes, as functional units provided by an edge control unit 43, a communication path storage unit M4, an edge router F41, and an edge processing unit F42.

[0111] The edge communication device 41 outputs packets received from the RSU3 and the central server 5 to the edge router F41. The edge communication device 41 also transmits packets input from the edge router F41 to a destination specified by the edge router F41. The communication path memory unit M4 is a storage area that holds a path table. The communication path memory unit M4 is realized using a part of the storage area of ​​the memory 45 or the storage 46. The path table held by the edge server 4 stores information about vehicle groups and on-board units 1 with which each RSU3 can communicate, and information about vehicle groups and on-board units 1 to which each RSU3 is scheduled to connect.

[0112] The edge router F41 transmits the packet input from the edge processing unit F42 to the edge communications device 41 via a communications path according to the routing table stored in the communications path storage unit M4. The edge router F41 also performs processing to forward the received packet input from the edge communications device 41 to a device according to the final destination of the packet. If the received packet is a packet whose final destination is the edge router F41, the edge router F41 sends the received packet toward the edge processing unit F42.

[0113] The edge processing unit F42 acquires vehicle-to-vehicle communication status and road-to-vehicle communication status between vehicles, communication load, congestion level, traffic condition data, etc. in the RSUs 3 from multiple RSUs 3. The edge processing unit F42 also acquires location information, traveling speed, etc. from each vehicle via the RSUs 3 or the wireless base station 2. The edge processing unit F42 may acquire setting data related to the destination from a vehicle in which a destination is set.

[0114] The edge processing unit F42 updates the route table stored in the communication route storage unit M4 as needed based on the communication status with the RSUs 3 and the travel plans for each vehicle group, which will be described later. The edge processing unit F42 also performs processing to transmit traffic condition data collected from multiple RSUs 3 to the central server 5.

[0115] The traffic condition data uploaded to the central server 5 can be transferred to other related edge servers 4. For example, the edge processing unit F42 acquires traffic condition data for areas outside the own area collected by other edge servers 4 but within a predetermined distance from the own area from the central server 5 as adjacent area information.

[0116] The edge processing unit F42 predicts the traffic conditions for each road section within its own area after a predetermined prediction time based on the collected traffic condition data for each road section. Based on the prediction results, the edge processing unit F42 generates dynamic map data for the RSU3 to distribute to each vehicle group. The dynamic map data for the RSU3 to distribute to each vehicle group can be, for example, a data set indicating the predicted traffic conditions for an area within a certain range from the RSU3. In other words, the dynamic map data includes the average driving speed and traffic volume for each road section.

[0117] Furthermore, the edge processing unit F42 organizes a vehicle group based on the individual situation data for each vehicle registered in the edge database 42. For example, the edge processing unit F42 sets vehicles whose RSSI is equal to or greater than a predetermined grouping strength to the same group (in other words, a vehicle group). The grouping strength only needs to be set to a value that allows stable inter-vehicle communication, and can be changed according to the standard value of transmission power specified in the inter-vehicle communication standard. The grouping strength can be, for example, -50 dBm, -40 dBm, -30 dBm, etc. The grouping strength may be the same as the aforementioned adjacent certification value. The edge processing unit F42 may set a vehicle group so that adjacent nodes belong to the same vehicle group.

[0118] It is not necessary for the RSSI of all combinations of vehicles constituting a vehicle group to be equal to or greater than the grouping strength. A vehicle can belong to a vehicle group based on the RSSI of communication with at least one of the vehicles constituting the vehicle group being equal to or greater than the grouping strength. For example, the RSSI of communication between vehicle A, which is located at the front of the vehicle group Gr shown in Figure 3, and vehicle F, which is located at the rear, may be less than the grouping strength.

[0119] The RSSI used to organize the vehicle group may be the most recent observation value, or the average, median, maximum, or minimum value of observation values ​​within a specified time period. Here, RSSI is used as an example to select vehicles to be included in the same vehicle group, but this is not limiting. Other grouping conditions may be adopted, such as an SNR greater than or equal to a specified value, or a packet loss rate within a specified time period less than a specified value. The thresholds for each item that define the grouping conditions are also referred to as grouping thresholds. The aforementioned grouping strength is also an example of a grouping threshold. As described above, the edge processing unit F42 organizes vehicle groups taking into account the communication quality between vehicles. This makes it easier to ensure communication quality within the vehicle group compared to organizing vehicle groups based solely on inter-vehicle distance and location information.

[0120] Of course, the edge processing unit F42 may be configured to set a vehicle group using the inter-vehicle distance in addition to at least one parameter indicating the communication quality between vehicles. For example, the condition for belonging to the same vehicle group may be that the RSSI is equal to or greater than the grouping strength and the inter-vehicle distance is less than a predetermined grouping distance. The grouping distance may be, for example, 50 mm, 100 m, or 150 m. The grouping distance may be defined by the number of seconds it takes for the preceding vehicle and the following vehicle to pass the same point (the so-called inter-vehicle time). The inter-vehicle time is equivalent to the value obtained by dividing the inter-vehicle distance by the traveling speed of the following vehicle.

[0121] The edge processing unit F42 creates a medium-term driving plan for each vehicle group based on the individual situation data provided by each vehicle and the traffic situation data. The medium-term driving plan for each vehicle group may correspond to the medium-term driving plan for each vehicle. Note that the edge processing unit F42 may create a long-term driving plan based on the destination information of the vehicle, and then create the medium-term driving plan. The long-term plan corresponds to, for example, information that roughly indicates the driving route from the current position to the destination.

[0122] The edge processing unit F42 may control the traveling speed of each vehicle group. For example, the edge processing unit F42 may adjust the speed plan of each vehicle in the vehicle group so that the vehicle group does not split up at intersections or branching / merging points. The edge processing unit F42 may also shorten or lengthen the inter-vehicle distance so that the inter-vehicle communication quality within the vehicle group is maintained at a desired level. In addition, the edge processing unit F42 may adjust the length of the entire vehicle group or suppress the traveling speed so that the road-to-vehicle group communication time is equal to or longer than a predetermined value.

[0123] The road-vehicle group communication time is the communication time with the RSU3 for the entire vehicle group. The road-vehicle group communication time corresponds to, for example, the time from when the first vehicle of the vehicle group enters the communication area of ​​the RSU3 to when the last vehicle of the vehicle group leaves the communication area of ​​the RSU3. In the present disclosure, the period (time zone) corresponding to the road-vehicle group communication time is also referred to as the vehicle group connection period. The start time of the vehicle group connection period corresponds to the time when the first vehicle of the vehicle group enters the communication area of ​​the RSU3, and the end time corresponds to the time when the last vehicle leaves the communication area of ​​the RSU3. In the example shown in FIG. 8, the vehicle group connection period is from time T1a_s to time T2c_e.

[0124] The edge processing unit F42 performs communication scheduling for each combination of the RSU 3 and the vehicle group based on the RSU information and the vehicle group information. The communication scheduling includes setting, for each time, the vehicle-mounted device 1 (i.e., the connection node 1x) that performs short-range communication with the RSU 3 in the vehicle group. The RSU information here includes the installation location coordinates of the RSU 3 and the size of the communication area. Furthermore, the vehicle group information may include the current location, movement speed, and movement direction of the vehicle group itself, as well as individual situation data for each vehicle that makes up the vehicle group.

[0125] For example, the edge processing unit F42 sets connection candidates based on the traveling position of each vehicle relative to the RSU3. For example, in the example shown in FIG. 3, vehicles A to C traveling in the first lane, which are relatively close to the RSU3, are likely to have a higher RSSI than vehicles D to F traveling in the second lane. In addition, signals from vehicles traveling in the first lane, which does not have other lanes between them and the RSU3, are less likely to be blocked by other vehicles or affected by multipath. In other words, it can be expected that vehicles traveling in lanes closer to the RSU3 will have better communication quality with the RSU3 than vehicles traveling in lanes farther away from the RSU3.

[0126] Taking note of this tendency, the edge processing unit F42, for example, prioritizes setting a vehicle traveling in the lane closest to the RSU 3 as a connection candidate. A connection candidate refers to an onboard unit 1 that is to be connected to the RSU 3 for communication among the onboard units 1 constituting the vehicle group, in other words, an onboard unit 1 that functions as a connection node 1x. In the example shown in FIG. 3, the edge processing unit F42 sequentially sets vehicles A to C traveling in the first lane as connection candidates. Note that, in order to extend the road-to-vehicle group communication time, the edge processing unit F42 may set the leading vehicle and the trailing vehicle as connection candidates regardless of their lane IDs. That is, in another aspect, in addition to vehicles A to C, vehicle F located at the end of the vehicle group may be set as a connection candidate.

[0127] The connection period, which is the period during which the connection candidate actually connects to the RSU, is determined based on a predicted transition of the relative position of the connection candidate with respect to the RSU3. For example, the edge processing unit F42 may estimate the time when the RSSI between the RSU3 and the connection candidate will be equal to or greater than the connection threshold based on the driving plan of each vehicle and the installation location of the RSU3, and determine the timing to switch the connection node 1x within the vehicle group based on the estimation result. The connection period corresponds to the period during which the connection candidate actually functions as the connection node 1x. The edge processing unit F42 may also determine the allocation of communication resources with the RSU3 for each connection candidate in accordance with the setting of the connection period. Note that the edge processing unit F42 may create a communication path within the vehicle group for each combination of onboard devices 1 and for each time based on the communication status of each onboard device 1 constituting the vehicle group with other devices.

[0128] The edge processing unit F42 then transmits packets indicating the mid-term plan data of each vehicle, vehicle group setting data, communication schedule, etc. to the associated RSU3 and each vehicle. The communication schedule data is data indicating the connection node 1x for each time. The communication schedule data is used as an RSU connection table in the vehicle-mounted device 1 and as a connection table in the RSU3. The communication schedule may include data indicating communication routes within the vehicle group. The packet indicating the vehicle group setting corresponds to a packet notifying the existence and timing of a device to join / leave the vehicle group, or a packet instructing a change in the vehicle group to which the vehicle belongs or a split / combination of the vehicle group. The edge server 4 may also transmit packets indicating a mid-term driving plan for each vehicle group.

[0129] The edge processing unit F42 may distribute various data via the RSU 3 or via the wireless base station 2. The destination of the vehicle group setting data, etc., may be all vehicles that make up the vehicle group, or just one vehicle. A vehicle that receives the vehicle group setting data may forward the vehicle group setting data to the members indicated in the vehicle group setting data. In addition, the edge processing unit F42 also controls the allocation state of wireless resources for wide-area communication with vehicles in the wireless base station 2.

[0130] <Configuration of Central Server 5> The configuration of the central server 5 will be described below with reference to Fig. 16. As shown in Fig. 16, the central server 5 includes a server communication device 51, a static map storage unit 52, a dynamic map storage unit 53, and a server control unit 54. The server control unit 54 is connected to each of the server communication device 51, the static map storage unit 52, and the dynamic map storage unit 53 so as to be able to communicate with each other.

[0131] The server communication device 51 is a facility for communicating with the edge server 4. The server communication device 51 is configured to be able to communicate with the edge server 4 using, for example, optical fiber. The static map storage unit 52 is a database in which static map data is stored. The static map storage unit 52 is realized using a rewritable non-volatile storage medium. The dynamic map storage unit 53 is a database in which traffic condition data, which is data indicating the traffic conditions at each point, is stored as a dynamic map.

[0132] The server control unit 54 is mainly configured as a computer including a processor 55, a memory 56, and a storage 57. The storage 57 stores a server program as a program executed by the processor 55. The server program can be called a V2X application. The server control unit 54 performs various processes by the processor 55 executing the server program.

[0133] For example, the server control unit 54 updates the map stored in the static map storage unit 52 based on integrated map data obtained by integrating probe data uploaded from multiple vehicle-mounted devices 1. The server control unit 54 may also update the map stored in the static map storage unit 52 based on map data provided by a predetermined map vendor.

[0134] The server control unit 54 also sequentially updates the data stored in the dynamic map storage unit 53 based on the traffic condition data observed by each of the multiple RSUs 3, which is input from the edge server 4. The update interval may be, for example, 1 second, 5 seconds, 30 seconds, or 5 minutes, 10 minutes, 30 minutes, etc. The server control unit 54 may update the weather information for each point stored in the dynamic map storage unit 53 based on weather information acquired from an external server, for example, the contents of a raincloud radar.

[0135] The server control unit 54 distributes, to each of the multiple edge servers 4, a data set in which static map data for the management area is associated with dynamic map data. The edge server 4 distributes, to the multiple RSUs 3, map data for the range corresponding to the RSUs 3 out of the received map data. The RSUs 3 distribute the map data for distribution to each vehicle via road-to-vehicle communication. In other words, the map data sent from the central server 5 is distributed to each vehicle in a form subdivided by area. In addition, the server control unit 54 controls communication between the onboard device 1 and the wireless base station 2 and communication between the onboard device 1 and the RSUs 3.

[0136] <About route update processing> The route table is updated mainly when the members of a vehicle group change, that is, when a new vehicle-mounted device 1 joins an existing vehicle group or when a member leaves. When a new vehicle-mounted device 1 joins an existing vehicle group, this also includes when two vehicle groups merge. The route update process involves members of a vehicle group exchanging their own route tables, as will be described below.

[0137] (1) Operation when adding members First, the operation of each vehicle-mounted device 1 for updating the route table when vehicle groups are joined will be described using the example of a case where a second vehicle group joins a first vehicle group. The route update process when a member is added includes steps S101 to S108, as shown in FIG. 17, for example. The vehicle-mounted device 1 of the first vehicle group executes the route update process based on the occurrence of the above-mentioned route confirmation event. Note that the following route update process can be executed in parallel not only by the vehicle-mounted device of the first vehicle group but also by the vehicle-mounted device of the second vehicle group.

[0138] Step S101 is a step for checking whether there has been a change in adjacent nodes. Checking adjacent nodes is achieved by sending and receiving advertising packets, etc. When the first vehicle group merges with the second vehicle group, one of the members of the first vehicle group may detect another vehicle belonging to the second vehicle group as an adjacent node as a result of step S101. The vehicle-mounted devices 1 to be detected in step S101 may be limited to vehicle-mounted devices 1 that have been notified in advance by the edge server 4 as devices scheduled to join. If none of the vehicle-mounted devices 1 in the first vehicle group can detect an onboard device 1 belonging to the second vehicle group in step S101, this flow ends. If a device scheduled to join cannot be detected, the vehicle-mounted devices in the first vehicle group may retry step S101 after a certain period of time.

[0139] For convenience, the on-board unit 1 newly detected in step S101 will be referred to as a newly joining unit. Also, the on-board unit 1 that detected the newly joining unit will be referred to as a detecting unit. Note that, as an example, the newly joining unit will be described as an other vehicle group unit that is an on-board unit 1 that belongs to some vehicle group, but the newly joining unit may also be an isolated unit that does not belong to any vehicle group.

[0140] Step S102 is a step in which the detecting device adds route data (metrics, etc.) destined for the newly joining device to its own table. The own table refers to the route table held by the detecting device itself. The hop destination of route data destined for the newly joining device is the newly joining device itself, and the metric value is set to, for example, 1. The metric is a parameter that indicates the distance to the communication partner, and in this embodiment, the number of hops is used. The metric can represent the cost of a link in a route search. Note that, in addition to the number of hops, RTT (Round-Trip Time), propagation loss, etc. may also be used as the metric.

[0141] In step S103, the detecting device transmits its own table to the newly joining device. By executing this step, the newly joining device updates the route table it holds using the route table transmitted from the detecting device. In other words, the newly joining device creates a route table that includes members of the first vehicle group in its destination list in addition to members of the vehicle group (second vehicle group) to which it originally belongs.

[0142] Step S104 is a step in which the detecting device acquires the route table of the newly joining device from the newly joining device. The route table held by the newly joining device corresponds to communication route data within another vehicle group. Step S105 is a step in which the detecting device updates its own table based on the route table (also referred to as a reception table) acquired in step S104. That is, by executing steps S104 to S105, the detecting device creates a route table whose destination list includes members of the second vehicle group to which the newly joining device belongs, in addition to members of the vehicle group to which the detecting device originally belongs (first vehicle group). The hop destination for the members of the second vehicle group is the newly joining device, and the metric is a value obtained by adding 1 to the metric shown in the route table of the newly joining device.

[0143] In step S106, the detector transmits the self table updated in step S105 to the members of the first vehicle group (particularly adjacent nodes). In step S107, one of the onboard devices 1 belonging to the first vehicle group that has received the route table from the detector (receiving side) updates its own table based on the received route table. The route tables received from other devices, such as newly joining devices and existing members, correspond to other device route data.

[0144] In step S108, the vehicle-mounted device 1 that updated its own table in step S107 further transmits the updated own table to other members. Steps S107 to S108 can be repeatedly executed until the route tables held by each vehicle-mounted device 1 converge. In order to reduce the processing load / traffic volume, the number of times each vehicle-mounted device 1 transmits its updated route table may be limited to a predetermined number or less, such as once or twice. In addition, in order to prevent excessive transmission of route tables, the vehicle-mounted device 1 may be restricted so that it does not retransmit the route table to the same destination within a predetermined time after transmitting the route table once. The route table is transmitted by unicast. In addition, the vehicle-mounted device 1 may transmit the route table by multicast addressed to members.

[0145] Examples: Here, the operation of the in-vehicle device 1 when adding a member (when merging vehicles) will be described in more detail using Figure 18. Figure 18 is a diagram showing a situation in which a second vehicle group Gr2 approaches a first vehicle group Gr1 from behind and merges with the first vehicle group Gr1. For example, the first vehicle group Gr1 is a vehicle group whose constituent members are vehicles A to F, with vehicle A being the lead vehicle and vehicle F being the tail vehicle. The second vehicle group Gr2 is a vehicle group whose constituent members are three vehicles P to R, with vehicle P being the lead vehicle and vehicle R being the tail vehicle.

[0146] (A) shown in the upper part of Figure 18 shows the situation just before merging (time T = t0). (B) shown in the middle part of Figure 18 shows the situation at time T = t1 (t1 > t0) when vehicle F, located at the end of the first vehicle group Gr1, detects vehicle P, located at the front of the second vehicle group Gr2, as an adjacent node; in other words, the situation just after the two vehicle groups merge. (B) shown in the lower part of Figure 18 shows the situation at time T = t2 (t2 > t1) when vehicle E detects vehicle P as an adjacent node. It is assumed that information about the first vehicle group Gr1 and the second vehicle group Gr2 has been distributed to each other in advance from the edge server 4 as vehicle group information about the vehicles to be merging.

[0147] When vehicle F detects vehicle P as an adjacent node, it adds vehicle P to its route table as shown in FIG. 19. Vehicle F also receives the route table held by vehicle P from vehicle P and integrates its own route table with the received table. Specifically, vehicle F sets vehicle P as the hop destination for vehicles Q and R, which are newly registered nodes based on the received table, as shown in FIG. 20. Furthermore, the metrics for vehicles Q and R are set to a value obtained by adding the metric from vehicle F to vehicle P (here, 1) to the metric shown in the received table.

[0148] When vehicle F completes updating its own table, it transmits the data of its updated table to adjacent nodes on the first vehicle group Gr1 side, such as vehicles C and E. Accordingly, vehicle E updates its route table as shown in FIG. 21 based on the route table of vehicle F provided by vehicle F. That is, vehicle E adds vehicles P to R to the list of destinations and sets vehicle F as the hop destination. The metric value from vehicles P to R is the metric value from vehicles P to R notified by vehicle F plus 1. In addition, vehicle E transmits the updated route table of vehicle E to vehicle D, which causes vehicle D to update its own route table in the same way. Similar processing is performed by each vehicle.

[0149] According to the above configuration, when two vehicle groups are combined, it is possible to efficiently create a communication path within the vehicle group after the merger. Note that the third vehicle group Gr3, which is the combined vehicle group, may inherit the ID of either the first vehicle group Gr1 or the second vehicle group Gr2, or may be assigned a new vehicle group ID.

[0150] After that, when vehicle E detects vehicle P as an adjacent node, vehicle E updates the route data (hop destination and metric) in its own table with vehicle P as the destination, as shown in Fig. 22. Then, vehicle E and vehicle P exchange route tables and update their respective route tables.

[0151] For example, vehicle E adds 1 to the metric value of the destination indicated in the route table received from vehicle P to create a temporary table, which is a route table to each member via vehicle P ((B) of FIG. 23). The hop destination in the temporary table is set to the route table exchange partner (vehicle P). Then, the route control unit F12 of vehicle E compares the temporary table with its own table ((C) of FIG. 23), and for route data to the same destination, adopts the route with the smaller metric. In this way, a route table after the positional relationship change is created.

[0152] Of course, the route control unit F12 may register multiple hop destinations (communication routes) for one destination. For example, to provide communication redundancy, it may be configured to be able to register up to two hop destinations for one destination. Of the routes to the same destination, the one with the larger metric corresponds to the backup route.

[0153] From the viewpoint of the onboard device 1 of vehicle P, the above scene can be understood as a scene in which vehicle P joins the first vehicle group Gr1. That is, when the onboard device 1 of vehicle P newly joins the first vehicle group Gr1, the onboard device 1 of vehicle P operates to acquire a route table from at least one other device belonging to the first vehicle group Gr1 and create its own route table based on the received route table. According to this control, the onboard device 1 of vehicle P can create route data addressed to members of the first vehicle group, which is the vehicle group to join, simply by communicating with vehicle F.

[0154] (2) Operation when a member leaves Next, the operation of the onboard device 1 when a member leaves the vehicle group will be described. For convenience, the onboard device 1 leaving the vehicle group will be referred to as the leaving device, and the onboard device 1 remaining in the vehicle group will be referred to as the remaining device. The leaving device corresponds to the onboard device 1 that has been notified by the edge server 4 as a device scheduled to leave. The route control unit F12 of each remaining device obtains information about the device scheduled to leave and the timing of its departure from the edge server 4.

[0155] The route control unit F12 of the remaining vehicle deletes the route data destined for the departing vehicle from the route table at / or after a predetermined time has elapsed since the timing of departure notified by the edge server 4. For example, when vehicles C, E, and F, which are located at the rear of the vehicle group Gr shown in FIG. 3, leave the group, the route control units F12 of vehicles A, B, and D delete the route data destined for vehicles C, E, and F from the route table at the timing of departure. This configuration makes it possible to smoothly establish communication routes within the vehicle group when a departing vehicle occurs. Note that the route data related to the departing vehicle may be deleted at the timing when the departing vehicle actually leaves.

[0156] Furthermore, the route control unit F12 of the remaining aircraft also deletes routes with the remaining aircraft as the destination and the departing aircraft as the hop destination, i.e., route data that passes through the departing aircraft. This is because, for routes that pass through the departing aircraft, the hop destination becomes unknown (absent) after the departing aircraft actually leaves. For example, if vehicle D leaves the vehicle group Gr shown in FIG. 10 by turning right, etc., the hop destination of data with vehicle E as the destination becomes unknown from the perspective of vehicle A, the remaining aircraft.

[0157] The route control unit F12 of the remaining aircraft deletes all route data in which the departing aircraft is set as a hop destination from its own table, and then determines whether routes to all remaining aircraft are registered in its own table. If, as a result of deleting the route data related to the departing aircraft, there is a remaining aircraft whose communication route is unknown, specifically, a remaining aircraft with no hop destination set, the route control unit F12 exchanges route tables with the remaining aircraft to obtain the communication route to each remaining aircraft. Obtaining route tables from other remaining aircraft can be achieved by, for example, requesting the transmission of a route table.

[0158] If there is no destination for which the route becomes unknown due to the departure of the leaving device, the route control unit F12 omits exchanging route tables with other remaining devices. This configuration makes it possible to reduce the frequency of sending and receiving topology information when a leaving device occurs.

[0159] Figure 24 is a flowchart conceptually illustrating the operation of remaining aircraft when a departing aircraft occurs as described above. Step S201 in Figure 24 is a step in which each remaining aircraft deletes route data that has the departing aircraft as the destination or hop destination. Step S202 is a step in which each remaining aircraft determines whether there are any remaining aircraft with unknown communication routes. Step S203 is a step in which, if there are any remaining aircraft with unknown communication routes, the remaining aircraft exchange route tables with each other. Step S204 is a step in which each remaining aircraft updates its own table based on the route tables received from the other remaining aircraft. When updating the table, as described above, for routes with the same destination, the route with the smaller metric value is used.

[0160] <Supplementary Note (1)> In a real environment, there may be cases where there are no other vehicles within the range where short-range communication is possible, and the on-board device 1 becomes an isolated device. The edge server 4 may transmit a control message to the isolated device so that the isolated device belongs to a vehicle group. Here, the control message corresponds to a control message instructing the vehicle to accelerate or decelerate.

[0161] <Supplementary Note (2)> The routing table can be transmitted and received using the V2X sidelink or NR sidelink supported in 3GPP Releases 14 to 16, etc., or a sidelink equivalent thereto. The onboard device 1 transmits and receives the routing table, for example, using the PSSCH (Physical Sidelink Shared CHannel) and SL-SCH (SideLink Shared CHannel) described in Non-Patent Document 1. In one embodiment, the onboard device 1 does not use the PSCCH (Physical Sidelink Control CHannel) to transmit and receive the routing table. Of course, in another aspect, the onboard device 1 may exchange the routing table using the PSCCH. Furthermore, the onboard device 1 may multicast its own table using the PSBCH (Physical Sidelink Broadcast CHannel). The PSSCH, PSBCH, and PSCCH are physical channels realized using different frequencies or time slots, respectively. The SL-SCH is a channel defined in the transport layer.

[0162] <About the effects> According to the above configuration, when a communication request is generated, a communication route within the vehicle group is already prepared and maintained. Therefore, when a communication request is generated by application X, etc., no overhead of route construction occurs. In other words, communication can be started promptly in response to a communication request generated by application X, etc.

[0163] Furthermore, with the above configuration, when a predetermined route confirmation event occurs, such as a change in the members of the vehicle group, route tables are exchanged, and a route table corresponding to the configuration of the vehicle group after the reorganization is created. Each vehicle-mounted device 1 does not voluntarily transmit a route table unless a route confirmation event is detected. In other words, each vehicle-mounted device does not need to periodically transmit a route table. With this configuration, it is possible to apply a communication route according to the configuration / situation of the vehicle group at any time while suppressing the frequency of transmitting the route table.

[0164] Furthermore, when the vehicle-mounted device 1 newly joins a vehicle group to which it does not belong, it obtains a route table from at least one other device belonging to the destination vehicle group, which is the vehicle group the vehicle-mounted device is joining, and creates its own table. This configuration makes it possible to efficiently create route data addressed to members of the destination vehicle group. Furthermore, each vehicle-mounted device updates its own table based on the route tables provided by the members. Rather than creating a route table from scratch each time, a route table suited to the actual situation of the vehicle group is created by integrating existing route tables. This configuration is expected to have the effect of reducing the number of times each vehicle-mounted device 1 exchanges its route table.

[0165] Although the embodiments of the present disclosure have been described above, the present disclosure is not limited to the above-described embodiments, and various modifications described below are also included within the technical scope of the present disclosure. Furthermore, various modifications other than those described below can be implemented without departing from the gist of the present disclosure. For example, the various supplements and modifications described below can be implemented in appropriate combinations as long as no technical contradictions arise. Note that components having the same functions as the components described above are given the same reference numerals, and their description may be omitted. Furthermore, when only a portion of the configuration is mentioned, the above description can be applied to the other portions.

[0166] <Variation (1)> Furthermore, each vehicle-mounted device 1 may be configured to detect other devices with an RSSI equal to or greater than a predetermined neighbor recognition value as neighboring nodes, regardless of whether the communication partner is a member or a device to be added, and exchange route tables with the detected neighboring nodes. This configuration makes it possible to create communication routes within the vehicle group after the reorganization even before the vehicle group is reorganized. Therefore, data communication using the changed communication routes within the vehicle group can be performed promptly after the configuration of the vehicle group is actually changed.

[0167] As described above, each vehicle-mounted device 1 may be configured to detect, as neighboring nodes, only the vehicle-mounted devices 1 that have been notified as members of the vehicle group and the vehicle-mounted devices 1 that have been notified as devices that will join, among other devices whose RSSI is equal to or greater than a predetermined neighboring recognition value. With this configuration, the search range for neighboring nodes is limited, and the processing load of the route control unit F12 can be reduced.

[0168] <Variation (2)> Although the above describes a mode in which the edge server 4 organizes a vehicle group, the vehicle-mounted devices 1 may autonomously organize a vehicle group by sharing their communication status with other devices. The conditions for the vehicle-mounted devices 1 to be considered as part of the same vehicle group may be the same as when the edge server 4 organizes a vehicle group. Furthermore, in a system configuration in which the vehicle-mounted device 1 organizes a vehicle group using distributed control (autonomously), the isolated device may transmit its traveling information to the preceding or following vehicle group via an RSU 3 or smartphone located in its vicinity. The vehicle group that receives the information about the isolated device may control its vehicle speed so as to merge with the isolated device.

[0169] <Variation (3)> The short-range communication standard may be Wi-Fi (registered trademark), EnOcean (registered trademark), Wi-SUN (Wireless Smart Utility Network), or the like. The on-board device 1 may be configured to be able to use WiMAX, 3G, or the like in addition to 4G / LTE and short-range communication. The on-board device 1 may also be configured to implement road-to-vehicle communication and inter-vehicle communication using different communication methods. For example, the on-board device 1 may implement road-to-vehicle communication using DSRC, while implementing inter-vehicle communication using Wi-Fi. The on-board device 1 may also be configured to be able to use two or more communication methods in combination as short-range communication methods. For example, the on-board device 1 may be configured to be able to use Cellular V2X (PC5) and DSRC / WAVE (Wireless Access in Vehicular Environments) in parallel or selectively.

[0170] <Additional remarks> The various flowcharts shown in this disclosure are merely examples, and the number of steps in the flowcharts and the execution order of the processes can be changed as appropriate. The same applies to sequence diagrams. The devices, systems, and methods described in this disclosure may be implemented by a dedicated computer comprising a processor programmed to execute one or more functions embodied in a computer program. The processor (computing core) may be a CPU, MPU, GPU, or DFP (Data Flow Processor). Computers also include system-on-chip (SoC), integrated circuits (ICs), and field-programmable gate arrays (FPGAs). The concept of an IC also includes application-specific integrated circuits (ASICs). The computer program may be stored as instructions executed by a computer on a computer-readable, non-transitive, tangible storage medium. Examples of the program storage medium include hard-disk drives (HDDs), solid-state drives (SSDs), and flash memory. [Explanation of symbols]

[0171] 1 Vehicle-mounted device (communication device), 1x Representative node, 1y General node, 2 Wireless base station, 3 RSU (roadside unit), 4 Edge server, 5 Central server, 11 Control unit, 13 Wireless module, F11 Route selection unit, F12 Route control unit, Mx Representative vehicle, My General vehicle

Claims

1. A communication control method executed in a communication device configured to be able to perform direct wireless communication with another device, which is a communication device mounted on another vehicle, and transmitting data to a final destination by performing direct communication between a hop source and a hop destination multiple times, comprising: updating intra-vehicle group communication route data indicating a communication route within the same vehicle group as the vehicle itself, the communication route data including hop destination information and metrics for each destination; acquiring, from the other vehicle member belonging to the vehicle group, the intra-vehicle group communication route data held by the member as other vehicle route data; Updating the vehicle group communication route data includes: A communication control method comprising: integrating the other-vehicle route data acquired from the member with the intra-vehicle group communication route data held by the own device; when an adjacent node that is a member whose received signal strength is equal to or greater than a predetermined value is detected, exchanging the intra-vehicle group communication route data with the adjacent node; adding 1 to the metric indicated in the other-vehicle route data received from the adjacent node to create a temporary table that is a route table to the member via the adjacent node; comparing the temporary table with the intra-vehicle group communication route data held by the own device; and adopting the route with the smaller metric for route data to the same destination.

2. 2. The communication control method according to claim 1, A communication control method including not periodically transmitting the intra-vehicle group communication path data.

3. 2. The communication control method according to claim 1, When the own device newly joins a vehicle group to which it does not belong, the own device acquires, from at least one of the other devices belonging to the joining destination vehicle group, the vehicle group to which the own device will join, the vehicle group intra-vehicle group communication route data held by the other device as the other device route data; and creating intra-vehicle group communication route data for the vehicle itself based on the other vehicle route data.

4. 4. A communication control method according to claim 1, further comprising: Acquiring information about the other vehicle that is a vehicle to be added to the vehicle group to which the vehicle belongs from an external server that organizes the vehicle group; and updating the intra-vehicle group communication route data held by the device itself by exchanging intra-vehicle group communication route data with the device to join based on the fact that a signal from the device to join has been received.

5. 4. A communication control method according to claim 1, further comprising: Acquiring information about a vehicle group to which the vehicle belongs and a vehicle group to which the vehicle is scheduled to merge, from an external server that organizes vehicle groups; and updating the intra-vehicle group communication route data held by the vehicle itself by exchanging intra-vehicle group communication route data with the other vehicle, based on the fact that the vehicle has been able to receive a signal from the other vehicle belonging to the group of vehicles scheduled to merge.

6. 4. A communication control method according to claim 1, further comprising: A communication control method including, when at least one of the other vehicles leaves the vehicle group, deleting route data addressed to the other vehicle that is leaving the vehicle group from the vehicle group communication route data.

7. 7. A communication control method according to claim 6, Acquiring information about a vehicle leaving the vehicle group and the timing of the departure from the vehicle group from an external server that organizes the vehicle group; and deleting route data having the departing aircraft as its destination within a predetermined time from the timing of the departing.

8. 4. A communication control method according to claim 1, further comprising: A communication control method that updates communication path data within a vehicle group based on detecting at least one of the following: addition of a member, departure of a member, departure from the vehicle group, joining another vehicle group, change in positional relationship within the vehicle group, or change in communication status within the vehicle group.

9. 4. A communication control method according to claim 1, further comprising: A communication control method for updating communication path data within a vehicle group based on receiving data indicating a change in the members from an external server that organizes the vehicle group.

10. 4. A communication control method according to claim 1, further comprising: The communication device is configured to be able to communicate with the other device using a plurality of types of communication methods.

11. A communication device configured to be able to perform direct wireless communication with another device that is a communication device mounted on another vehicle, and that transmits data to a final destination by performing direct communication between a hop source and a hop destination multiple times, updating intra-vehicle group communication route data indicating a communication route within the same vehicle group as the vehicle itself, the communication route data including hop destination information and metrics for each destination; and acquiring, from the other vehicle member belonging to the vehicle group, the intra-vehicle group communication route data held by the other vehicle member as other vehicle route data, Updating the vehicle group communication route data includes: A communication device that integrates the other device's route data obtained from the member with the intra-vehicle group communication route data it holds, and when it detects an adjacent node that is a member whose received signal strength is above a predetermined value, exchanges the intra-vehicle group communication route data with the adjacent node, adds 1 to the metric indicated in the other device's route data received from the adjacent node, creates a temporary table that is a route table to the member via the adjacent node, compares the temporary table with the intra-vehicle group communication route data it holds, and adopts the route with the smaller metric for route data to the same destination.

12. A computer included in a communication device configured to be able to perform direct wireless communication with another device that is a communication device mounted on another vehicle, and that transmits data to a final destination by performing direct communication between a hop source and a hop destination multiple times, updating intra-vehicle group communication route data indicating a communication route within the same vehicle group as the vehicle itself, the communication route data including hop destination information and metrics for each destination; acquiring, from the other vehicle members belonging to the vehicle group, the intra-vehicle group communication route data held by the other vehicle members as other vehicle route data; Updating the vehicle group communication route data includes: A program that integrates the other-vehicle route data obtained from the member with the intra-vehicle group communication route data held by the own device, and when an adjacent node that is a member whose received signal strength is greater than or equal to a predetermined value is detected, exchanges the intra-vehicle group communication route data with the adjacent node, adds 1 to the metric indicated in the other-vehicle route data received from the adjacent node, creates a temporary table that is a route table to the member via the adjacent node, compares the temporary table with the intra-vehicle group communication route data held by the own device, and adopts the route with the smaller metric for route data to the same destination.

Images