Vehicle communication systems, communication devices

Abstract

To provide a vehicle communication system and a communication device that can further improve communication efficiency between a vehicle and an external server.SOLUTION: An on-vehicle device 1 as a general node stores inter-vehicle group propagation time up to a current connection node and connection finish time of the current connection node, as well as next period connection node information. The on-vehicle device 1 determines whether or not transmission data reaches to the current connection node up to the connection finish time of the current connection node on the basis of the current time and the inter-vehicle group propagation time when the transmission data to the external server is generated. When it is determined that the transmission data does not reach to the current connection node up to the connection finish time of the current connection node, the general node holds the data transmission, or transmits data toward the next period connection node.SELECTED DRAWING: Figure 19

Description

Technical Field

[0006] , ,

[0001] The present disclosure relates to a vehicle communication system and a communication device that perform data communication between a server or a roadside unit using the concept of a vehicle group.

Background Art

[0002] Patent Document 1 discloses a configuration in which a MEC (Multi-access Edge Computing) node permits uplink transmission of data such as a drive recorder only to a part of a plurality of vehicles constituting a vehicle group.

[0003] In addition, in 3GPP (registered trademark), a communication control method for realizing cellular V2X has been studied (Non-Patent Document 1).

Prior Art Documents

Patent Documents

[0004] ​​​​​​​​​​​​​​​​​​​​​​​Patent Document 1 does not mention any configuration for efficiently transmitting data other than route-dependent data, such as vehicle-specific data, via the uplink. On the other hand, a variety of data can be expected to be handled by vehicles, and a variety of servers can be expected to be the recipients of data communication. The frequency with which vehicles communicate with servers for data is increasing.

[0007] In response to these circumstances, the developers of this disclosure have been considering a configuration in which multiple vehicles constituting a single vehicle group are divided into general vehicles and representative vehicles, as one way to improve communication efficiency. A representative vehicle is a vehicle that communicates with a roadside unit, and the representative vehicle plays the role of relaying communication between general vehicles and the roadside unit (and by extension, an external server). A roadside unit is a communication facility installed along a road that forms a relatively narrow wireless communication area. General vehicles refer to vehicles among the vehicles constituting the vehicle group that are not representative vehicles. In this configuration, general vehicles transmit data to a desired server using the communication connection between the representative vehicle and the roadside unit. The representative vehicle itself is switched over time (dynamically) within the vehicle group as it moves.

[0008] According to the above-examined configuration, even if the connection time between a single representative vehicle and the roadside unit is short, the connection time between the vehicle group and the roadside unit can be made relatively longer because the representative vehicles themselves are rotated sequentially. As a result, each vehicle can more easily perform tasks such as transmitting large amounts of data to its desired server. Furthermore, in a configuration where the communication connection between a single vehicle and the roadside unit is shared by multiple vehicles, an improvement in communication efficiency can be expected due to the swarm effect.

[0009] However, in the above-examined configuration, a delay may occur between the source and the representative vehicle for data transmitted by a regular vehicle (My) to reach the representative vehicle, depending on the number of hops from the source to the representative vehicle. As a result, while data transmitted from a certain regular vehicle (My) is propagating through the vehicle group toward the representative vehicle, the representative vehicle itself may be replaced by a different vehicle than the one at the time of transmission. In such cases, the transmitted data may be discarded during the transfer process or may reach the current representative vehicle via a roundabout route.

[0010] This disclosure is based on the above considerations or perspectives, and one of its purposes is to provide a vehicle communication system and communication device that can further improve the communication efficiency between the vehicle and an external server. [Means for solving the problem]

[0011] The first vehicle communication system disclosed herein is a vehicle communication system for which each of a group of vehicles forming a vehicle group communicates data with an external server (4, 5) via a representative vehicle (Mx) dynamically set among the group of vehicles constituting the vehicle group, wherein a general node (1y), which is a communication device used in a vehicle other than the representative vehicle, is configured to control the transmission of data toward the external server based on the communication status between itself and the representative node (1x), which is a communication device used in the representative vehicle. The general node is configured to obtain the connection start time, which is the time when the representative node begins communicating with the roadside unit; the vehicle group propagation time, which is the time it takes for the data it sends to reach the representative node; and to adjust the data transmission schedule based on the connection start time and the vehicle group propagation time. ru.

[0012] According to the above configuration, each general node adjusts its transmission schedule to the external server according to the communication status with the representative node. Therefore, the risk of transmission data being discarded midway or the communication path to the representative node becoming longer due to a change in the representative node can be reduced. In other words, the communication efficiency between the vehicle and the external server can be improved.

[0015] The communication device included in the present disclosure is a communication device used in a vehicle, configured to perform data communication with an external server via a roadside unit (3), and includes acquiring information of other communication devices, which are other vehicle group members used in other vehicles constituting a vehicle group including the own vehicle; acquiring a communication status with a representative node, which is a communication device responsible for communicating with the roadside unit, among the vehicle group members; and being configured to control transmission of data to the external server based on the communication status with the representative node. The system is configured to obtain the connection start time, which is the time when the representative node begins communicating with the roadside unit; the vehicle group propagation time, which is the time it takes for the data it has sent to reach the representative node; and to adjust the data transmission schedule based on the connection start time and vehicle group propagation time. It is.

[0016] The above communication device is a communication device for a vehicle that constitutes a first vehicle communication system, and exhibits the same effects by the same actions as the first vehicle communication system.

[0017] Note that the reference numerals in parentheses described in the claims indicate the correspondence with the specific means described in the embodiments described later as one aspect, and do not limit the technical scope of the present disclosure.

Brief Description of the Drawings

[0018] [Figure 1] It is a diagram schematically showing an overall view of a vehicle communication system. [Figure 2] It is a diagram showing the relationship between a central server, an edge server, and an RSU. [Figure 3] It is a diagram showing an example of a vehicle group. [Figure 4] It is a block diagram showing the configuration of an in-vehicle system. [Figure 5] It is a diagram showing the configuration of a narrow area communication packet. [Figure 6] It is a functional block diagram for explaining the data flow in an in-vehicle system. [Figure 7] It is a diagram for explaining an RSU connection table. [Figure 8] It is a diagram showing another example of an RSU connection table. [Figure 9] It is a diagram showing an example of the correspondence between a destination and a hop destination (transfer destination). [Figure 10]It is a diagram showing an example of setting a communication path within a vehicle group at each moment. [Figure 11] It is a diagram showing the configuration of a wireless base station. [Figure 12] It is a diagram showing the configuration of an RSU. [Figure 13] It is a functional block diagram of an RSU related to data transmission and reception. [Figure 14] It is a diagram showing the configuration of an edge server. [Figure 15] It is a functional block diagram of an edge server. [Figure 16] It is a diagram showing the configuration of a central server. [Figure 17] It is a sequence diagram related to the formation of a vehicle group. [Figure 18] It is a sequence diagram related to the transmission of a user packet to the central server. [Figure 19] It is a flowchart for explaining the transmission path control process performed by an in-vehicle device. [Figure 20] It is a flowchart for explaining the transmission control process performed by an external server.

Embodiments for Carrying out the Invention

[0019] 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. Hereinafter, as an example, it is assumed that the system is used in an area with left-hand traffic, and the leftmost lane in the traveling direction is called the first lane. In an area with right-hand traffic, the rightmost lane may be the first lane.

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

[0021] The on-board unit 1 is a communication device that performs wireless communication with other vehicles, RSU 3, and wireless base station 2. Each of the on-board units 1 is installed and used in multiple vehicles. The on-board unit 1 is configured to enable short-range communication with other on-board units 1 and RSU 3. Here, short-range communication refers to communication compliant with a predetermined wireless communication standard where the effective communication range is, for example, 150m or 250m. Any short-range communication standard can be adopted, such as DSRC (Dedicated Short Range Communications) or Cellular V2X (PC5).

[0022] Although Figure 1 only shows two vehicles equipped with the on-board unit 1, the system as a whole may actually consist of three or more vehicles. Hereafter, for a given on-board unit 1, the vehicle on which that on-board unit 1 is installed will be referred to as "its own vehicle," and other vehicles will be referred to as "other vehicles." Hereafter, the term "vehicle" basically refers to the vehicle equipped with the on-board unit 1. The on-board unit 1 corresponds to the communication device.

[0023] Furthermore, in this disclosure, the in-vehicle unit 1 will be referred to as "itself" to distinguish it from other in-vehicle units 1, and an in-vehicle unit 1 used in another vehicle will be referred to as "another unit." Since there is a one-to-one relationship between a vehicle and an in-vehicle unit 1, the expression "vehicle" as the source / destination of wireless signals / data / packets can be read as "in-vehicle unit." Therefore, the terms "itself" and "another unit" in the following explanation may be interpreted as "its own vehicle" and "another vehicle."

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

[0025] Radio base station 2 is a radio facility that provides a mobile communication system compliant with standards such as 4G / LTE (Long Term Evolution). Radio base station 2 is also referred to as eNB (evolved NodeB). In this disclosure, wireless communication using a method that can achieve a communication range of 500m or more is referred to as wide-area communication. The dashed line in Figure 1 shows the communication range of radio base station 2.

[0026] Furthermore, the wireless base station 2 may provide wireless communication compliant with the 3G standard. Also, if the wireless base station 2 can create a relatively wide communication range, it may be equipment (so-called gNB: next generation NodeB) that implements wireless communication compliant with 5G. The following embodiments can be implemented by appropriately modifying them to comply with communication architectures such as LTE / 4G / 5G as defined by 3GPP (Third Generation Partnership Project). Parts omitted from this disclosure can be carried out in the manner defined by standards such as LTE.

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

[0028] RSU3 is a wireless communication device positioned along a road and configured to perform narrow-area communication. RSU3 is sometimes referred to as a roadside unit. RSU3 forms a communication range that is relatively narrower than that of the wireless base station 2. For example, RSU3 forms a communication area with a radius of approximately 50m to 250m. The dashed line in Figure 1 conceptually shows the communication area of ​​RSU3. In this disclosure, communication between RSU3 and the vehicle-mounted unit 1 is also referred to as vehicle-to-infrastructure communication. Note that RSU3 may also perform 5G communication. That is, RSU3 may be a gNB.

[0029] The edge server 4 is equipment that performs so-called edge computing, collecting data from numerous 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 implemented using equipment that constitutes the core network CN, such as an MME or S-GW. Such an edge server 4 can be called an edge container.

[0030] Edge servers 4 are located, for example, in each designated management area. A management area may correspond to a grid grid, an administrative division such as a prefecture, or any other division. A management area corresponds to an area from which edge servers 4 can collect information. Edge servers 4 collect reports from RSUs 3 and in-vehicle devices 1 located within their own management area and report them to the central server 5. In addition, edge servers 4 may have the function of generating and distributing control data for in-vehicle devices 1 located within their management area.

[0031] The central server 5 is equipment that generates and distributes data for groups of vehicles or for individual vehicles. The central server 5 is equivalent 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 server 4. Static map data is data that shows road structures and the locations of various features. Features include traffic signs and road markings.

[0032] Dynamic map data refers to data on dynamic map elements whose location and status change over time, ranging from a few minutes to several hours. Dynamic map elements include, for example, congested areas, construction zones, broken-down vehicles, fallen objects, accident locations, lane closures, traffic volume, weather, and road surface conditions. Dynamic map data may also include average driving speed and traffic volume for each road segment, which is a road management unit. In other words, dynamic map data can be understood as data that shows relatively real-time traffic conditions.

[0033] The central server 5 distributes adjacent area information to each edge server 4. Adjacent area information is traffic data for areas within a predetermined distance from the edge server 4's management area. This adjacent area information can be used for things like organizing vehicle groups. The division of roles between the central server 5 and the edge servers 4 can be changed as needed. The functions of the edge servers 4 may be integrated into the central server 5. Both the edge servers 4 and the central server 5 correspond to external servers.

[0034] <Introduction of a group of vehicles> In this embodiment, each vehicle communicates with the RSU3 in units of a vehicle group, as shown in Figure 3. A vehicle group here refers to a group of multiple vehicles. Multiple vehicle groups can exist within the entire vehicle communication system Sys. Figure 3 illustrates a state in which vehicles A to J form one vehicle group Gr. Vehicle A is the leading vehicle of vehicle group Gr, and vehicle J is the last vehicle of vehicle group Gr. In Figure 3, the first RSU3a, which is RSU3 with RSU number 1, and the second RSU3b, which is RSU3 with RSU number 2, are located in front of vehicle group Gr. The second RSU3b is an RSU3 located further forward (i.e., in the direction of travel) from the perspective of vehicle group Gr than the first RSU3a. The first RSU3a and the second RSU3b are positioned on the shoulder or similar on the first lane side.

[0035] In this disclosure, multiple vehicles constituting a single vehicle group are classified into connected vehicle Mx and general vehicle My. Connected vehicle Mx is a vehicle that performs narrow-range communication with RSU3 within the vehicle group. Connected vehicle Mx plays the role of relaying communication between general vehicle My and RSU3. Since connected vehicle Mx is a vehicle that represents the vehicle group in one respect, it can also be called a representative vehicle. General vehicle My is a vehicle that is not a connected vehicle Mx. General vehicle My communicates with RSU3 via connected vehicle Mx. Since the relative position of a vehicle with respect to RSU3 changes as it travels, the vehicle that takes on the role of connected vehicle Mx may change over time among the vehicles belonging to the same vehicle group. The setting (configuration) of the vehicle group and the setting of connected vehicle Mx for each time within the vehicle group are performed by the edge server 4 as described later.

[0036] In the example shown in Figure 3, vehicle A first connects to the first RSU3a as connected vehicle Mx, and then vehicles B through E and J sequentially connect to the first RSU3a. Vehicles A through E and J can also establish communication connections with the second RSU3b as they move.

[0037] Hereafter, the onboard unit 1 used in connected vehicle Mx, in other words, the onboard unit 1 that has established a narrow-area communication link with RSU3, will be referred to as connected node 1x. Connected node 1x corresponds to the representative node. In the following, the term connected node 1x may be interpreted as the representative node or connected vehicle. In addition, in this disclosure, the onboard unit 1 used in general vehicle My will also be referred to as general node 1y. In the following, the term general node 1y can be replaced with general vehicle My.

[0038] In-vehicle units 1 belonging to a group of vehicles share and complement each other's content data, which is distributed in multiple parts from, for example, an RSU 3, via vehicle-to-vehicle communication. Here, content data refers to, for example, static map data or dynamic map data. Furthermore, regarding the uploading of probe data indicating the driving environment, each in-vehicle unit 1 may be programmed so that only one of the multiple in-vehicle units 1 making up the group performs this upload. For example, the in-vehicle unit 1 of the lead vehicle may be configured to be responsible for generating and transmitting probe data. If an in-vehicle unit 1 other than the lead vehicle is a connected node 1x, the in-vehicle unit 1 of the lead vehicle may send a packet of generated probe data to the connected node 1x according to the time. This packet can reach the edge server 4 or central server 5 via the connected node 1x and the RSU 3.

[0039] <About the configuration of the in-vehicle system> As shown in Figure 4, the in-vehicle unit 1 is used in conjunction with the vehicle condition sensor 6, surrounding monitoring sensor 7, locator 8, and ECU 9 via the in-vehicle network IvN, which is a communication network established within the vehicle. ECU 9 is an abbreviation for Electronic Control Unit and refers to an electronic control unit. In this disclosure, the configuration including the various devices connected to the in-vehicle unit 1 and the in-vehicle unit 1 itself is also referred to as the in-vehicle system IvS.

[0040] The vehicle state sensor 6 is a sensor that detects state quantities related to the vehicle's driving control. 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 that the in-vehicle unit 1 should connect to as the vehicle state sensor 6 can be designed as appropriate, and it is not necessary to have all of the above-mentioned sensors.

[0041] The surrounding monitoring sensor 7 is a sensor that detects the environmental conditions around the vehicle. The surrounding monitoring sensor 7 is, for example, a surrounding monitoring camera that takes images of a predetermined range around the vehicle, a millimeter-wave radar that transmits detection waves to a predetermined range around the vehicle, sonar, or LiDAR. LiDAR is an abbreviation for Light Detection and Ranging or Laser Imaging Detection and Ranging. The surrounding 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 three-dimensional stationary objects such as guardrails and utility poles. Fallen objects, parked vehicles, construction zones, and lane restriction zones can also be included as obstacles. In addition, it detects road markings such as lane markings around the vehicle. The detection results of the surrounding monitoring sensor 7 are input sequentially to the in-vehicle unit 1.

[0042] Locator 8 is a device that sequentially calculates the position of the vehicle. For example, Locator 8 is equipped with 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. 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 edge or right edge of the road, and can also be called the driving lane ID. The position information indicating the current position, which Locator 8 sequentially identifies, is provided to the in-vehicle unit 1. Note that the function of identifying the vehicle's lane ID may also be provided by a surrounding surveillance camera or a specific ECU 9.

[0043] ECU9 is a computer equipped with a processor, memory, storage, etc. ECU9 is configured to run one or more application software (hereinafter referred to as App X). App X is a program that runs on ECU9. App X realizes predetermined services / functions by communicating with the central server 5. In this disclosure, the terms "application" or "app" can be read as the device / processing core that runs the application. A processing core refers to a processor such as a CPU (Central Processing Unit).

[0044] In Figure 4, "App" 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 ECU9 is shown in Figure 4, multiple ECU9s may be connected to the in-vehicle unit 1. In addition, the in-vehicle system IvS may have three or more apps X. Each of the multiple apps X provides a different service / function. The in-vehicle system IvS may have a variety of apps, such as driver assistance apps and probing apps.

[0045] The driver assistance app is an application that provides functions to assist the driver in driving. For example, the driver assistance app automatically adjusts the driving speed based on detection results from surrounding monitoring sensors 7, etc., and controls the steering angle to keep the vehicle in the lane. The driver assistance app corresponds to the vehicle control system app. The probing app is an application that uploads probe data to the central server 5. Here, the probe data is a dataset showing the position coordinates of features detected by surrounding monitoring sensors 7, for example. The probe data may also include vehicle behavior information such as driving speed, steering angle, yaw rate, turn signal operation status, and wiper operation status.

[0046] Each application X is assigned a unique identification information called an application ID. The application ID may be assigned by the designer / distributor of application X, or it may be assigned by a designated ECU9 that comprehensively manages the software installation on the vehicle (effectively the ECU9) during installation on the vehicle.

[0047] Furthermore, some or all of the various devices described above may be directly connected to the in-vehicle unit 1 without going through the in-vehicle network IvN. Also, the devices connected to the in-vehicle unit 1 are not limited to those exemplified above.

[0048] <Configuration of In-Vehicle Unit 1> The in-vehicle unit 1 comprises a control unit 11, an in-vehicle communication unit 12, and a wireless module 13. The control unit 11 is mainly composed of a computer. The control unit 11 comprises a processor 111, memory 112, and storage 113. The processor 111 is, for example, a CPU. The memory 112 is, for example, volatile memory such as RAM (Random Access Memory). The storage 113 includes a non-volatile storage medium such as flash memory. The storage 113 stores a vehicle communication control program as a program executed by the processor 111.

[0049] 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, and a PHY chip compliant with the communication standards of the in-vehicle network IvN. The in-vehicle communication unit 12 outputs sensor data received from the vehicle condition sensor 6 and other sources to the control unit 11. Sensor data includes, for example, 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 fuel (e.g., gasoline) is also included in the sensor data. Obstacle information detected by the surrounding monitoring sensor 7 and vehicle position information identified by the locator 8 are also included in the sensor data.

[0050] The wireless module 13 is a module equipped with circuits for wireless communication with external devices, 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 corresponding to the communication frequency used, a modulation / demodulation circuit, etc. For the in-vehicle unit 1, external devices refer to other devices, wireless base stations 2, RSUs 3, and other communication equipment located outside the vehicle. By equipping the wireless module 13, the in-vehicle unit 1 can communicate data with edge servers 4, etc., via wireless base stations 2 or RSUs 3.

[0051] The wide-area communication unit 131 is a communication module for performing wide-area communication. The wide-area communication unit 131 wirelessly connects 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 communication quality with the wireless base station 2 (hereinafter referred to as wide-area communication quality) and output it to the control unit 11. Data indicating wide-area communication quality includes, for example, the received signal strength indication (RSSI), transmission speed, latency (response time), and packet loss rate.

[0052] If the in-vehicle device 1 is configured to use multiple wide-area communication lines by having multiple SIMs (Subscriber Identity Modules), the wide-area communication unit 131 generates data indicating the 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. The control unit 11 may also have a function to calculate some of the various data indicating communication quality described above.

[0053] The narrow-area communication unit 132 is a communication module for implementing narrow-area communication. The narrow-area communication unit 132 performs signal processing (e.g., modulation / demodulation) related to the transmission and reception of wireless signals compliant with the narrow-area communication standard. The narrow-area communication unit 132 can generate data indicating the communication quality with the RSU3 and other devices (hereinafter referred to as narrow-area communication quality) and output it to the control unit 11. Data indicating narrow-area communication quality includes, for example, RSSI, SNR (Signal-to-Noise Ratio), and packet loss rate. The narrow-area communication unit 132 generates data indicating narrow-area communication quality for each communication partner. In this disclosure, the narrow-area communication quality for each communication partner is collectively referred to as the narrow-area communication status. The control unit 11 may also have a function to calculate a portion of the data indicating narrow-area communication quality.

[0054] Packets exchanged in narrow-area communication include, for example, a payload section, a source field, a final destination field, a hop source field, and a hop destination field, as shown in Figure 5. The payload section is the area where the data itself is stored. The source field is the area where source information indicating the source (origin) of the packet is stored. Source information can also be called GS (Global Source). The final destination field is the area where final destination information indicating the final destination of the packet is stored. Final destination information can also be called GD (Global Destination).

[0055] Source information and destination information may be represented by a vehicle ID or device ID, or by an IP address. Preferably, the source and destination are represented by a globally unique identifier, which is identification information that uniquely identifies a device across the entire network. Source information and destination information may also be represented by a combination of an IP address and a port number. The source field and destination field may be part of a Layer 3 header, such as an IP header or a TCP header.

[0056] The source field is an area that stores information indicating the direct source of the packet. The source can also be called the LS (Local Source). The destination field is an area that stores information indicating the destination of the packet. Destination information can be called the LD (Local Destination). Source and destination information may be represented by vehicle IDs, device IDs, MAC addresses, etc. Source and destination may also be represented by locally unique identifiers, which are dynamically set identification numbers that differ for each device within the narrow-area communication range. The source and destination fields may correspond to part of the Layer 2 header. The order of the various fields can be changed as appropriate. Between the source field and the final destination field, there may be fields that store other information such as service type, time to live (TTL), and protocol.

[0057] Figure 6 is a functional block diagram showing the data flow within the in-vehicle system IvS. The in-vehicle system IvS comprises a wireless module 13, at least one application X, an in-vehicle device memory unit M1, a route selection unit F11, and a route control unit F12. The in-vehicle device memory 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.

[0058] As described above, the wireless module 13 includes a wide-area communication unit 131 and a narrow-area communication unit 132. The wireless module 13 wirelessly transmits the transmission packets input from the route selection unit F11 via the communication path specified by the route selection unit F11. The wireless module 13 also outputs received packets, which are packets received via wide-area or narrow-area communication, to the route selection unit F11.

[0059] As mentioned above, application X is a software configuration that runs on ECU9. Some parts of application X may run on control unit 11. Application X generates transmission packets destined for central server 5 or edge server 4 and inputs them to route selection unit F11. Application X also receives packets addressed to itself from route selection unit F11.

[0060] App X outputs application information to the routing control unit F12. In Figure 6, App_Info indicates the application information. Application information includes, for example, the application ID, application type, and communication requirements (communication characteristics). Possible application types include driving control systems, security systems, and entertainment systems. Communication requirements refer to acceptable waiting time, acceptable RTT, main communication direction, communication frequency, and average size. Acceptable waiting time indicates by when communication must start, in other words, the waiting time until communication starts that App X can tolerate. Acceptable RTT indicates the response delay time that App X can tolerate. RTT is an abbreviation for Round Trip Time. Main communication direction indicates whether the ratio of uplink (transmission) or downlink (reception) is larger. Communication frequency indicates the frequency of data transmission / reception. Average size indicates the expected size of the data transmitted or received by App X. Based on the application information, the routing control unit F12 can determine / change the port number, packet transmission priority, assigned route, etc., for each App X.

[0061] The in-vehicle device storage unit M1 is a storage medium that stores various data necessary for communication control, such as vehicle group setting data, RSU connection table, routing table, and RSU location information. The in-vehicle device storage unit M1 is implemented using a portion of the storage area provided by memory 112 or storage 113.

[0062] Vehicle group configuration data refers to data that indicates the configuration (formation) of a vehicle group, and may include a list of other vehicles (and by extension, other machines) that make up the vehicle group. The vehicle group refers to the vehicle group to which the machine belongs, as seen from the perspective of the route control unit F12. In this disclosure, other machines belonging to the vehicle group are also referred to as vehicle group members. Vehicle group configuration data may also include data created by the edge server 4 that indicates the medium-term driving plan for the vehicle group. The medium-term driving plan includes target values ​​such as driving lane ID and driving speed for road sections that are scheduled to be passed within a predetermined time, such as 1 minute or 5 minutes.

[0063] Vehicle group configuration data is distributed from edge server 4. The in-vehicle device 1 may acquire the vehicle group configuration data via RSU 3 or receive it from wireless base station 2. In this disclosure, the communication path via RSU 3 is referred to as the narrow-area communication path, and the path via wireless base station 2 is referred to as the wide-area communication path. The path control unit F12 updates the vehicle group configuration data stored in the in-vehicle device storage unit M1 based on the vehicle group configuration data transmitted from edge server 4.

[0064] Furthermore, the route control unit F12 receives data from the edge server 4 about other vehicle groups adjacent to its own vehicle group, as other vehicle group data, and stores it in the in-vehicle device storage unit M1. The other vehicle group data also includes the current position, direction of movement, and speed of movement of the other vehicle group. The other vehicle group data corresponds to adjacency information at the vehicle group level.

[0065] The RSU connection table is a table that shows the settings for connected vehicles Mx for each time period, i.e., the connected node 1x at each time period. The RSU connection table shows the number of the RSU3 to which each in-vehicle unit 1 connects, and the connection period, as shown in Figure 7 for example. The connection period includes the connection start time and connection end time. The route control unit F12 updates the RSU connection table stored in the in-vehicle unit storage unit M1 based on the RSU connection table transmitted from the edge server 4. Note that Figure 7 is an example of the RSU connection table for the vehicle group Gr shown in Figure 3. The RSU connection table may also be separated by RSU3, as shown in Figure 8.

[0066] A routing table is a table that indicates the destination of a packet based on its final destination, whether it is an incoming or outgoing packet. The routing table indicates which communication path should be used to send packets destined for at least the edge server 4 / central server 5. Elements that constitute a communication path include the type of line, such as narrow-area communication or wide-area communication. Furthermore, if narrow-area communication is used as the communication line, the destination (hop destination, etc.) corresponding to the communication path within the vehicle group is also a component of the communication path. Other elements such as the frequency and modulation scheme used for communication may also be components of the communication path. If the wide-area communication unit 131 is configured to use multiple wide-area communication lines, variations in wide-area communication lines may also be included as components of the communication path. In addition, a routing table for narrow-area communication may include hop destination information according to the destination, as illustrated in Figure 9. Figure 9 is an example of a routing table for narrow-area communication held by the in-vehicle unit 1h, which is an in-vehicle unit 1 used in vehicle H.

[0067] The route selection unit F11 has a configuration equivalent to a router. The route selection unit F11 receives packets from application X and route control unit F12, selects a transmission route according to the routing table corresponding to the current time stored in the in-vehicle device memory unit M1, and has the wireless module 13 transmit the packets in a manner corresponding to the selected route. For example, for packets transmitted via narrow-area communication, the route selection unit F11 adds a header that sets the final destination, the current connected node 1x, or the hop destination according to the hop source, and outputs it to the narrow-area communication unit 132. For packets transmitted via wide-area communication, the route selection unit F11 adds a Layer 2 header that conforms to the wide-area communication standard and outputs it to the wide-area communication unit 131.

[0068] Furthermore, the route selection unit F11 processes the received packets input from the wireless module 13 according to their final destination. If the received packet is destined for the vehicle's application X, it outputs the received packet toward application X. If the received packet is a control packet destined for the route control unit F12, such as vehicle group setting data, it forwards the received packet toward the route control unit F12. Additionally, if the packet received via narrow-area communication is destined for another device, RSU3, or an external server, it forwards the received packet toward the hop destination indicated in the routing table.

[0069] The routing control unit F12 updates the routing table based on or periodically upon the occurrence of a predetermined routing update event. Routing update events include changes in the vehicle group configuration and changes in location within the vehicle group. As a preparatory process for updating the routing table, the routing control unit F12 may construct intra-vehicle group communication paths to each connection candidate as needed. For example, the routing control unit F12 of vehicle H creates intra-vehicle group communication paths for each time period shown in Figure 10, based on the RSU connection table shown in Figure 8. In this embodiment, each in-vehicle unit 1 autonomously creates intra-vehicle group communication paths, but this is not limited to this. In other embodiments, a specific in-vehicle unit 1 or edge server 4 within the vehicle group may create intra-vehicle group communication paths for each combination of in-vehicle units 1 and distribute them to each in-vehicle unit 1.

[0070] A connection candidate is an in-vehicle unit 1 that makes up a group of vehicles and for which a connection period has been set. The current connection node 1x and future connection node 1x are considered connection candidates. Among the connection candidates, those within the connection period function as connection nodes 1x. In the example shown in Figure 7 or Figure 8, vehicles A to E and J are considered connection candidates. Details of the operation of the edge server 4 regarding the setting of connection candidates and connection periods will be described separately.

[0071] Any algorithm / sequence can be used to construct the communication path within the vehicle group. The communication path within the vehicle group can be determined using a variety of algorithms, such as OSPF (Open Shortest Path First) which utilizes Dijkstra's algorithm. Hop count is used as the cost (metric) for pathfinding. Since the connected node 1x may differ from time to time, the path control unit F12, in other words, creates the communication path within the vehicle group for each time period.

[0072] Furthermore, the communication path within the vehicle group is reversible. That is, the communication path within the vehicle group is both the communication path from connected node 1x to general node 1y and the communication path from general node 1y to connected node 1x. In one aspect, the communication path within the vehicle group corresponds to a narrow-area communication path for general node 1y to communicate with the central server 5 and edge server 4 via connected node 1x and RSU 3.

[0073] Furthermore, the routing control unit F12 of this embodiment calculates the intra-swarm propagation time to each connection candidate. The intra-swarm propagation time is the time it takes from when the local unit sends a packet until the packet reaches the connection candidate. The intra-swarm propagation time can also be called the arrival delay time from the source to the final destination within the swarm (i.e., connection node 1x). The intra-swarm propagation time can be the value obtained by multiplying the number of hops from the local unit to the connection candidate by the unit delay time, which is the time required per hop. Alternatively, the intra-swarm propagation time may be determined based on the measured value of RTT, which is the time from when an acknowledgment packet is actually sent to the destination until a response signal (so-called Ack) indicating that it has been successfully received is received. For example, the routing control unit F12 may adopt half the observed RTT value as the intra-swarm propagation time. The routing control unit F12 may calculate the intra-swarm propagation time for all members of the local swarm, not just connection candidates.

[0074] Incidentally, in real-world environments, there are scenarios where no in-vehicle device 1, which functions as a connection node 1x, exists within a group of vehicles, such as when RSU3 is not present near the group. In such situations where the group of vehicles itself cannot connect to RSU3, the routing control unit F12 may modify the routing table to adopt wide-area communication as the means of communication with the central server 5. When narrow-area communication is not possible on a group-by-group basis, the control policy, such as whether to wait for data transmission or use a wide-area communication route, may differ for each application X based on the application information.

[0075] In addition, the routing control unit F12 performs movement management, such as selecting a cell in the area, based on the received strength of the reference signal transmitted from the radio base station 2. Furthermore, the routing control unit F12 detects the presence of RSU3 by receiving a predetermined control signal emitted from RSU3 and establishes a communication connection with RSU3 based on the RSU connection table.

[0076] Furthermore, the route control unit F12 periodically transmits a predetermined advertisement signal from the narrow-area communication unit 132. The advertisement signal is a signal for notifying other units and RSU3 of the presence of the unit, and includes at least source information indicating the source of the signal. The advertisement signal may also include vehicle information of the source, such as the source's current position, direction of travel, speed, and acceleration. The advertisement signal may be a signal equivalent to a CAM (Cooperative Awareness Message) or a BSM (Basic Safety Message). The advertisement signal may be transmitted periodically in a so-called broadcast manner, without specifying individual destinations. In this disclosure, wireless signals exchanged in narrow-area communication are also referred to as narrow-area communication signals or narrow-area communication packets.

[0077] When the routing control unit F12 receives a narrow-band communication signal transmitted from another device or RSU3, it stores the source information indicated in the advertisement signal in memory 112, associating it with communication quality data such as the received signal strength of the advertisement signal. The routing control unit F12 also extracts other devices whose RSSI of the advertisement packet is equal to or greater than a predetermined value (referred to as the adjacent recognition value) as adjacent nodes. Adjacent nodes correspond to partners with whom data communication is directly possible.

[0078] The route control unit F12 also acquires various sensor data. For example, the route control unit F12 acquires the vehicle's lane ID, obstacle information, surrounding vehicle information, vehicle position information, remaining battery charge, turn signal operation status, wiper operation status, etc. Surrounding vehicle information refers to the position and speed of other vehicles detected by the surrounding monitoring sensor 7, the distance between them and the vehicle itself, etc. The route control unit F12 may also determine the driving environment using other vehicle information received from other vehicles by the narrow-area communication unit 132, or dynamic map data received from RSU 3 or wireless base station 2.

[0079] The route control unit F12 generates a status report at predetermined intervals, indicating the status of narrow-area communication between its own vehicle and other vehicles, as well as the current status of its own vehicle. This report is then packetized and output to the route selection unit F11. The status report may be transmitted in multiple packets depending on the data size. The packets corresponding to the status report are a type of control packet.

[0080] The status report includes source information and data indicating the narrow-area 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 or combinations with communication difficulties / unstable conditions. The status report corresponds to a control packet that shows a list of other vehicles (e.g., adjacent nodes) capable of narrow-area communication. Furthermore, the status report may include data indicating the wide-area communication status. In other words, the status report corresponds to data indicating the implementation status for each communication method.

[0081] Furthermore, the status report may include sensor data, such as the vehicle's lane ID, obstacle information, vehicle position information, remaining battery charge, turn signal operation status, and wiper operation status. In addition, the status report may include information such as the driving environment, whether or not the vehicle is crossing lane boundaries, and the packet generation time.

[0082] <Regarding the configuration of wireless base station 2> Next, the configuration of the wireless base station 2 will be explained using Figure 11. As shown in Figure 11, the wireless base station 2 comprises 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 in a manner that allows for mutual communication. Note that "NW" in Figure 11 and other documents is an abbreviation for network.

[0083] The wide-area communication device 21 is a communication module for performing wide-area communication with the in-vehicle unit 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 the radio 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 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 edge server 4 depending on the destination of the data.

[0084] The base station control unit 23 is mainly composed of 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 unit 1 connected to the radio base station 2. For example, the base station control unit 23 performs handovers and the like associated with the movement of the in-vehicle unit 1. Also, the base station control unit 23 controls the allocation state of radio resources for each in-vehicle unit 1 based on control signals from, for example, the MME or the like. Based on the radio resource allocation determined by the base station control unit 23, the wide-area communication device 21 performs data transmission to the in-vehicle unit 1 and data reception from the in-vehicle unit 1.

[0085] Furthermore, the base station control unit 23 can perform processing as a router to transfer the data input from the edge server 4 and the in-vehicle unit 1 to an appropriately designated destination. For example, the base station control unit 23 transmits the vehicle group setting data generated by the edge server 4 to each vehicle constituting the vehicle group. The distribution mode of the vehicle group setting data can adopt any method such as unicast, multicast, geocast, broadcast, and the like.

[0086] The distribution 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 of its own vehicle group by vehicle-to-vehicle communication. Also, 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 / each vehicle. In addition, the base station control unit 23 performs processing to transfer control packets such as the current situation report transmitted from each of the plurality of vehicles to the edge server 4.

[0087] <Regarding the configuration of the RSU3> This section describes the configuration of RSU3. RSU3 is typically placed near intersections or highway junctions / merging points. RSU3 may be integrated with structures installed along the road, such as traffic lights, lighting equipment, or toll booths (gates) on toll roads. "Along the road" here includes not only the sides of the road but also the airspace above the road surface. RSU3 may also be installed as markers embedded in the road surface.

[0088] As shown in Figure 12, the RSU3 comprises a narrow-area communication device 31, a network connection device 32, an area monitoring device 33, and an RSU control unit 34. The narrow-area communication device 31, the network connection device 32, and the area monitoring device 33 are each connected to the RSU control unit 34 so as to be able to communicate with each other.

[0089] The narrow-area communication device 31 is a communication module for performing narrow-area communication with the in-vehicle unit 1. The narrow-area 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 equipment for connecting to the core network CN via optical fiber or the like and communicating with the edge server 4. The network connection device 32 outputs data input from the edge server 4 to the RSU control unit 34. It also outputs data input from the RSU control unit 34 to the wireless base station 2 or the edge server 4 according to the destination of the data.

[0090] The area monitoring device 33 is a device that monitors the traffic conditions in a pre-configured monitoring area for the RSU 3. The area monitoring device 33 can employ cameras, LiDAR, millimeter-wave radar, and other similar devices. For example, the area monitoring device 33 detects information indicating traffic conditions, such as the position, size, and movement status of moving objects within the monitoring area. Components of movement status include whether or not an object is moving, its speed, and its direction of movement. Road surface conditions, such as whether the road is wet from rain or covered in snow, and weather conditions, such as whether or not it is raining, can also be included in the traffic conditions. A single RSU 3 may have one or more area monitoring devices 33. The RSU 3 may also be equipped with multiple types of sensors, such as cameras and LiDAR, as part of the area monitoring device 33.

[0091] The RSU control unit 34 is primarily a computer, comprising a processor 35, memory 36, and storage 37. The storage 37 stores the RSU control program as a program executed by the processor 35.

[0092] The RSU control unit 34 controls the communication connection between the narrow-range communication device 31 and the in-vehicle unit 1. For example, based on the narrow-range communication device 31 receiving a narrow-range communication signal emitted from the in-vehicle unit 1, such as an advertisement signal, the RSU control unit 34 detects the existence of an in-vehicle unit 1 to be connected to (i.e., a connection candidate) and performs processing related to the communication connection with that in-vehicle unit 1.

[0093] Figure 13 is a functional block diagram showing the data flow within RSU3. RSU3 comprises an RSU transceiver unit F30, an RSU storage unit M3, an RSU router F31, and a data processing unit F32. The RSU storage unit M3, RSU router F31, and data processing unit F32 are functional units realized by the RSU control unit 34 executing an RSU communication control program.

[0094] The RSU transceiver unit F30 is a functional unit for sending and receiving data with the in-vehicle unit 1 and the edge server 4. The configuration of the narrow-area communication device 31 and the network connection device 32 is equivalent to the RSU transceiver unit F30. The RSU transceiver unit F30 outputs packets received from the in-vehicle unit 1 or the edge server 4 to the RSU router F31. The RSU transceiver unit F30 also transmits packets input from the RSU router F31 to the destination specified by the RSU router F31.

[0095] The RSU memory unit M3 is a storage medium that holds vehicle group data, connection tables, routing tables, etc. The RSU memory unit M3 is implemented using a portion of the storage area provided by memory 36 or storage 37. Vehicle group data is data about vehicle groups that reach the communication area of ​​RSU3 within a predetermined time, and includes vehicle group ID, which is the identification number of the vehicle group, current location, speed of movement, direction of movement, number of vehicles in the group, etc. The connection table is a table that shows the connected node 1x and its resource allocation for each time period. The connection table may be integrated with the vehicle group data. The vehicle group data and connection table are distributed from the edge server 4.

[0096] A routing table is a table that shows the correspondence between the final destination and the actual (direct) destination. The routing table also functions as a table that shows the communication path according to the destination. The RSU router F31 has the RSU transceiver F30 transmit packets input from the data processing unit F32 via the communication path corresponding to the routing table stored in the RSU memory unit M3. The RSU router F31 also performs the process of forwarding received packets input from the RSU transceiver F30 to the device corresponding to the final destination of the packet. If the received packet has RSU3 itself as its final destination, the RSU router F31 outputs the received packet to the data processing unit F32.

[0097] The data processing unit F32 updates vehicle group data, connection tables, routing tables, 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 monitored area based on data input from the area monitoring device 33. The data processing unit F32 may also identify / correct traffic conditions within the monitored area using data received from the in-vehicle device 1. The data processing unit F32 transmits the traffic condition data for the monitored area to the edge server 4 via the network connection device 32. The traffic condition data reported by the RSU 3 can be used for generating dynamic map data, creating vehicle group formations and driving plans, etc.

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

[0099] Furthermore, the data processing unit F32 may obtain information indicating the quality of vehicle-to-vehicle communication from the connected node 1x and report it to the edge server 4. The vehicle-to-infrastructure / vehicle-to-vehicle communication quality information reported by RSU3 can be used by the edge server 4 for tasks such as vehicle group organization and RSU connection table generation. In addition, the data processing unit F32 periodically calculates the degree of communication load and the utilization rate of wireless resources available for narrow-area communication (so-called congestion level) and reports them to the edge server 4.

[0100] In addition, RSU3 can receive traffic condition data observed by adjacent RSU3s from edge server 4 as adjacent information. Adjacent RSU3s can be, for example, other RSU3s located within 100m.

[0101] <Regarding the configuration of Edge Server 4> Next, the configuration of the edge server 4 will be described using Figure 14. As shown in Figure 14, the edge server 4 comprises an edge communication device 41, an edge database 42, and an edge control unit 43. The edge communication 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.

[0102] The edge communication device 41 is equipment for communicating with the wireless base station 2, RSU 3, and central server 5. The edge communication device 41 is configured to communicate with the wireless base station 2, RSU 3, and central server 5, for example, via optical fiber. The edge database 42 is a database implemented using a rewritable non-volatile storage medium. The edge database 42 is configured to allow data writing, reading, deletion, etc., by the edge control unit 43.

[0103] The edge database 42 stores a variety of data, including data transmitted from the in-vehicle unit 1 and RSU 3. For example, the edge database 42 stores data for each in-vehicle unit 1, such as its current location, driving plan, and the status of narrow-area communication with other vehicles and RSU 3 (hereinafter referred to as individual status data), associated with the vehicle ID. The individual status data for each vehicle may include not only information transmitted from the vehicle and RSU 3, but also information generated internally by the edge server 4. The individual status data for each in-vehicle unit 1 is maintained in an arbitrary data structure, such as a list format. The individual status data may include information such as the current speed, driving lane ID, direction of travel, and planned locations for changing driving position. As for the status of narrow-area communication with other vehicles for each vehicle, at least one of various items indicating the communication quality with other vehicles as communication partners is registered.

[0104] The edge control unit 43 is primarily composed of a computer. Specifically, the edge control unit 43 includes a processor 44, memory 45, and storage 46. The storage 46 stores edge programs, which are executed by the processor 44. These edge programs can also be called V2X edge applications. In addition, the storage 46 stores data related to the installation location and communication area of ​​the RSU 3.

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

[0106] 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 received from the edge router F41 to the destination specified by the edge router F41. The communication path storage unit M4 is a storage area that holds the routing table. The communication path storage unit M4 is implemented using a portion of the storage area provided by the memory 45 or storage 46. The routing table held by the edge server 4 stores information about the vehicle groups and in-vehicle devices 1 that each RSU3 can communicate with, and information about the vehicle groups and in-vehicle devices 1 that each RSU3 is scheduled to connect to.

[0107] The edge router F41 directs packets received from the edge processing unit F42 to the edge communication device 41 via a communication path corresponding to the routing table stored in the communication path memory unit M4. The edge router F41 also forwards received packets from the edge communication device 41 to the device corresponding to the packet's final destination. If the received packet is destined for the device itself, the edge router F41 sends the received packet back to the edge processing unit F42.

[0108] The edge processing unit F42 acquires data from multiple RSU3s, including vehicle-to-vehicle communication status, vehicle-to-infrastructure communication status, communication load on the RSU3s, congestion levels, and traffic condition data. The edge processing unit F42 also acquires location information, driving speed, etc., from each vehicle via the RSU3s or the wireless base station 2. The edge processing unit F42 may also acquire destination setting data from vehicles for which a destination has been set.

[0109] The edge processing unit F42 updates the routing table stored in the communication path memory unit M4 as needed, based on the communication status with RSU3 and the driving plan for each vehicle group described later. The edge processing unit F42 also performs the process of sending traffic condition data collected from multiple RSU3s to the central server 5.

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

[0111] The edge processing unit F42 predicts the traffic conditions in each road section within its area after a predetermined predicted time, based on the collected traffic condition data for each road section. Based on the above prediction results, the edge processing unit F42 generates dynamic map data for RSU3 to distribute to each vehicle group. The dynamic map data that RSU3 distributes to each vehicle group can be, for example, a dataset showing the predicted traffic conditions for an area within a certain range from RSU3. That is, the dynamic map data includes the average driving speed and traffic volume for each road section.

[0112] Furthermore, the edge processing unit F42 organizes vehicle groups based on individual vehicle status data registered in the edge database 42. For example, the edge processing unit F42 sets vehicles with an RSSI of a predetermined grouping strength or higher into the same group (in other words, vehicle group). The grouping strength only needs to be set to a value sufficient to enable stable vehicle-to-vehicle communication, and can be changed according to the standard value of transmission power specified in the vehicle-to-vehicle communication standard. The grouping strength can be, for example, -50dBm, -40dBm, or -30dBm.

[0113] Furthermore, the RSSI does not need to be equal to or greater than the grouping strength for all combinations of vehicles that make up a group. A vehicle can belong to a group if the RSSI of its communication with at least one of the vehicles that make up the group is equal to or greater than the grouping strength. For example, the RSSI of the communication between vehicle A, which is at the front of the group Gr shown in Figure 7, and vehicle J, which is at the rear, may be less than the grouping strength.

[0114] The RSSI used to organize the vehicle group may be the most recent observation, or the average, median, maximum, or minimum of observations within a fixed time interval in the immediate vicinity. Here, as an example, RSSI is used to select vehicles to be included in the same vehicle group, but this is not the only method. Conditions for grouping may also be adopted, such as an SNR of or above a predetermined value or a packet loss rate within a fixed time interval in the immediate vicinity being below a predetermined value. The thresholds for each item that defines the grouping conditions are also called grouping thresholds. The aforementioned grouping strength is also an example of a grouping threshold. As described above, the edge processing unit F42 organizes the vehicle group considering the communication quality between vehicles. This makes it easier to ensure communication quality within the vehicle group compared to organizing the vehicle group using only inter-vehicle distance and location information.

[0115] Of course, the edge processing unit F42 may be configured to set up a group of vehicles by using the inter-vehicle distance in conjunction with at least one parameter indicating the communication quality between vehicles. For example, the conditions for belonging to the same group of vehicles 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 can be, for example, 50 mm, 100 m, or 150 m. The grouping distance may also be defined by the number of seconds (so-called inter-vehicle time) until the preceding vehicle and the following vehicle pass the same point. The inter-vehicle time corresponds to the value obtained by dividing the inter-vehicle distance by the driving speed of the following vehicle.

[0116] The edge processing unit F42 creates a medium-term driving plan for each vehicle group based on individual status data provided by each vehicle and traffic condition data. The medium-term driving plan for each vehicle group can correspond to the medium-term driving plan for each individual vehicle. Alternatively, the edge processing unit F42 may create a long-term driving plan based on the vehicle's destination information before creating the medium-term driving plan. The long-term plan corresponds to information that roughly shows the driving route from the current location to the destination, for example.

[0117] The edge processing unit F42 may control the driving speed on a vehicle group basis. For example, it may adjust the speed plan of individual vehicles that make up the vehicle group so that the group does not split at intersections or junctions / merging points. The edge processing unit F42 may also shorten or lengthen the distance between vehicles so that the quality of inter-vehicle communication within the vehicle group is ensured to a desired level. In addition, the edge processing unit F42 may adjust the overall length of the vehicle group or suppress the driving speed so that the vehicle-infrastructure communication time is greater than or equal to a predetermined value.

[0118] The vehicle-to-infrastructure communication time is the total communication time with RSU3 for the entire vehicle group. The vehicle-to-infrastructure communication time corresponds to the time from when the lead vehicle of the vehicle group enters the RSU3 communication area until the last vehicle of the vehicle group exits the RSU3 communication area. In this disclosure, the period (time zone) corresponding to the vehicle-to-infrastructure 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 lead vehicle of the vehicle group enters the RSU3 communication area, and the end time corresponds to the time when the last vehicle exits the RSU3 communication area. In the example shown in Figure 8, the period from time T1a_s to time T2j_e corresponds to the vehicle group connection period of vehicle group Gr with respect to the first RSU3a.

[0119] The edge processing unit F42 performs communication scheduling for each combination of RSU3 and vehicle group based on RSU information and vehicle group information. Communication scheduling includes setting the vehicle-mounted unit 1 (i.e., connection node 1x) that will perform narrow-area communication with RSU3 within the vehicle group on a time-by-time basis. The RSU information here includes the installation position coordinates of RSU3 and the size of the communication area. The vehicle group information may include the current position, speed, and direction of movement of the vehicle group itself, as well as individual status data for each vehicle that makes up the vehicle group.

[0120] For example, the edge processing unit F42 sets candidate connection nodes 1x based on the driving position of each vehicle relative to the RSU3. In the example shown in Figure 7, for example, vehicles A to E, which are traveling in the first lane, which is relatively closer to the RSU3, tend to have a higher RSSI than vehicles F to J, which are traveling in the second lane. In addition, signals from vehicles traveling in the first lane, which has no other lanes between it and the RSU3, are less likely to be interrupted by other vehicles or affected by multipath interference. In other words, vehicles traveling in lanes closer to the RSU3 can be expected to have better communication quality with the RSU3 than vehicles traveling in lanes further away from the RSU3.

[0121] Focusing on this trend, the edge processing unit F42 prioritizes setting vehicles moving in the nearest lane from RSU3 as connection candidates. In the example shown in Figure 3, vehicles A to E traveling in the first lane are set as connection candidates in order. In addition, the leading and trailing vehicles are selected as connection candidates regardless of their lane ID in order to extend the vehicle-infrastructure communication time.

[0122] The connection period, which is the period during which a connection candidate is actually connected to the RSU, is determined based on a prediction 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 exceeds the connection threshold, based on the driving plan of each vehicle and the installation location of the RSU3, and determine the timing to switch connection nodes 1x within the vehicle group based on this estimation result. The connection period corresponds to the period during which the connection candidate actually functions as a 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. Furthermore, the edge processing unit F42 may create a communication path within the vehicle group for each combination of in-vehicle units 1 / for each time period, based on the communication status of each in-vehicle unit 1 that makes up the vehicle group with other units.

[0123] The edge processing unit F42 then transmits the medium-term plan data for each vehicle, vehicle group configuration data, and communication schedule to the relevant RSU3 and each vehicle. The communication schedule data is data indicating the connected node 1x for each time period. The communication schedule data is used as an RSU connection table in the in-vehicle unit 1 and as a connection table in the RSU3. The communication schedule may also include data indicating the communication path within the vehicle group.

[0124] The edge processing unit F42 may distribute various data via RSU3 or via wireless base station 2. The destination for vehicle group configuration data, etc., may be all vehicles constituting the vehicle group, or just one vehicle. A vehicle that receives vehicle group configuration data may forward the vehicle group configuration data to its own vehicle group members indicated in the data. In addition, the edge processing unit F42 also controls the allocation status of wireless resources for wide-area communication with vehicles at wireless base station 2.

[0125] <Regarding the configuration of Central Server 5> Here, the configuration of the central server 5 will be explained using Figure 16. As shown in Figure 16, the central server 5 comprises 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 the server communication device 51, the static map storage unit 52, and the dynamic map storage unit 53 in a manner that allows for mutual communication.

[0126] The server communication device 51 is equipment for communicating with the edge server 4. The server communication device 51 is configured 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 implemented using a rewritable, non-volatile storage medium. The dynamic map storage unit 53 is a database in which traffic condition data, which is data showing the traffic conditions at each location, is stored as a dynamic map.

[0127] The server control unit 54 is primarily a computer, comprising a processor 55, memory 56, and storage 57. The storage 57 stores server programs, which are executed by the processor 55. These server programs can also be called V2X applications. The server control unit 54 performs various processes by having the processor 55 execute these server programs.

[0128] 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 processing probe data uploaded from multiple in-vehicle devices 1. Alternatively, the server control unit 54 may update the map stored in the static map storage unit 52 based on map data provided by a predetermined map vendor.

[0129] Furthermore, the server control unit 54 sequentially updates the data stored in the dynamic map storage unit 53 based on traffic condition data observed at each of the multiple RSUs 3, which are 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 also update the location-specific weather information stored in the dynamic map storage unit 53 based on weather information acquired from an external server, for example, the contents of a rain cloud radar.

[0130] The server control unit 54 distributes a dataset to each of the multiple edge servers 4, which associates static map data with dynamic map data for the management area, as map data. The edge servers 4 distribute the map data corresponding to each RSU 3 from the received map data. The RSU 3 distributes the map data to each vehicle via vehicle-to-infrastructure communication. In other words, the map data sent from the central server 5 is distributed to each vehicle in a manner subdivided by area. In addition, the server control unit 54 controls the communication between the in-vehicle unit 1 and the wireless base station 2, and the communication between the in-vehicle unit 1 and the RSU 3.

[0131] <Regarding the interaction of various devices related to train formation> Here, the operation of each device related to the formation of a train group will be explained using the sequence diagram shown in Figure 17.

[0132] The in-vehicle unit 1 acquires various sensor data at predetermined timings (S101). The in-vehicle unit 1 also acquires various data indicating the wireless communication status based on signals from the wireless module 13 (S102). The wireless communication status may include wide-area communication status and narrow-area communication status. The in-vehicle unit 1 then updates the communication path within the vehicle group based on the wireless communication status data acquired in the above step, particularly the data indicating the narrow-area communication status (S103).

[0133] Steps S101 to S102 are executed periodically. Step S103 is executed when a specific event occurs or periodically. When updating the communication path within the vehicle group, the in-vehicle unit 1 may determine the communication path within the vehicle group by exchanging control packets with other in-vehicle units 1 within the vehicle group to evaluate the link cost. That is, steps S102 to S103 may include a sequence for sending and receiving control signals for creating a routing table. In conjunction with updating the communication path within the vehicle group, the in-vehicle unit 1 obtains the propagation time within the vehicle group for each destination.

[0134] Step S104 is the step in which the in-vehicle unit 1 generates and transmits a status report. The final destination of the status report is the edge server 4. When vehicle-to-infrastructure communication is possible, the in-vehicle unit 1 generates a narrow-area communication packet specifying the hop destination according to the vehicle-to-infrastructure communication path and transmits it wirelessly. A situation in which vehicle-to-infrastructure communication is possible refers to a situation in which any of the in-vehicle units 1 constituting the vehicle-to-infrastructure group can communicate with RSU 3 via narrow-area communication.

[0135] Of course, depending on the wireless environment and the route selection policy of application X, the in-vehicle unit 1 may also transmit the status report via wide-area communication. For example, in situations where vehicle-infrastructure communication is impossible, such as immediately after the driving power is switched from off to on, the route control unit F12 may set a wide-area communication route as the transmission route for the status report. When a wide-area communication route is applied as the transmission route for the status report, the packets corresponding to the status report are transmitted to the edge server 4 via the wide-area communication unit 131 and the wireless base station 2.

[0136] By the way, the timeliness of the status report is important. In other words, old status reports are of little use. In addition to this principle, to avoid congestion caused by retransmission, the in-vehicle device 1 transmits the status report using a protocol that does not require delivery confirmation. Specifically, a protocol that does not require delivery confirmation refers to UDP (User Datagram Protocol), etc.

[0137] When RSU3 receives a status report from the in-vehicle unit 1, it forwards it to the edge server 4 (S105). When the edge server 4 receives the status report, it saves the data shown in the status report as individual status data in the edge database 42. It then regenerates a medium-term driving plan at the vehicle group level and reorganizes the vehicle group as necessary (S106). The medium-term driving plan at the vehicle group level is reflected in the medium-term driving plan at the vehicle level level. In addition, for each vehicle group, the edge server 4 creates an RSU connection table for each RSU3 that the vehicle group is scheduled to pass through within a predetermined time.

[0138] Once the above processing related to vehicle group control is complete, edge server 4 sends a control message with RSU3 as the final destination (S107). The control message addressed to RSU may include the connection table and vehicle group information scheduled to pass through within a predetermined time. The control message addressed to RSU3 is sent using an acknowledgment protocol to confirm the route setting to RSU3. The acknowledgment protocol is TCP (Transmission Control Protocol). The control message, which includes the RSU connection table, is a type of control packet.

[0139] When RSU3 receives a control message from edge server 4 with RSU3 as the final destination, it sends an Ack (acknowledgment) back to edge server 4 as a reception response (S108). RSU3 also updates the data stored in RSU memory unit M3 based on the data indicated in the received control message (S109). For example, RSU control unit 34 updates the connection table and routing table based on the control message from edge server 4.

[0140] Edge server 4 periodically sends control messages destined for the vehicle group to the RSU3 that the vehicle group is scheduled to pass through / is connected to (S110). The control messages addressed to the vehicle group include, for example, the RSU connection table, RSU installation location information, and vehicle group configuration data. The control messages addressed to the vehicle group are delivered via acknowledgment multicast.

[0141] Acknowledgment multicast refers to a method in which RSU3 distributes data to a group of vehicles (connecting node 1x) using acknowledgment unicast, and connecting node 1x shares the received data with its own group members. Data sharing within a group refers to the distribution of received data from connecting node 1x to each individual vehicle My. Data sharing within a group can be performed using unicast. In acknowledgment multicast, if RSU3 receives a reception response (Ack) from connecting node 1x, it sends a message back to edge server 4 indicating that data distribution has been successfully completed. Acknowledgment multicast is equivalent to a method of distributing data using an acknowledgment unicast method, treating one group of vehicles as one communication partner. The final destination of control messages addressed to a group of vehicles may be expressed as the address of connecting node 1x, or as a group ID, etc.

[0142] A control message addressed to a group of vehicles corresponds to a control message directed to the individual vehicles that make up that group. Note that vehicle-specific control messages do not necessarily need to be delivered on a group-by-group basis. Vehicle-specific control messages may be delivered individually to each vehicle-mounted unit 1. Furthermore, the transmission path is not limited to RSU3; it may also be via wide-area communication.

[0143] When RSU3 receives a control message addressed to a vehicle, it performs the process of forwarding it to the vehicle corresponding to the destination according to the routing table (S111). If a vehicle group ID is set as the destination for a vehicle-addressed control message, the forwarding destination will be the connection node 1x of that vehicle group. If a specific in-vehicle unit 1 is specified as the destination for a vehicle-addressed control message, RSU3 forwards the data via narrow-range communication to that in-vehicle unit 1 or the connection node 1x of the vehicle group to which that in-vehicle unit 1 belongs.

[0144] When the in-vehicle unit 1, acting as a connected node 1x, receives a control message from RSU3 destined for its vehicle group, it provides the data to its own route control unit F12 and also performs processing to distribute it to the vehicle group members. A control message destined for the vehicle group is equivalent to a control message destined for the unit itself. When the connected node 1x receives a control message destined for the unit itself, it sends an Ack to RSU3. Furthermore, when the in-vehicle unit 1, acting as a connected node 1x, receives a control message from RSU3 destined for another vehicle within its vehicle group, it forwards the data to the vehicle group member corresponding to the final destination according to the routing table.

[0145] When each in-vehicle unit 1 receives a control message addressed to itself, it updates the vehicle group configuration data based on the data indicated in the control message addressed to that vehicle. Furthermore, if the constituent members of the vehicle group to which the unit belongs change, it executes a sequence to reconstruct the communication paths within the vehicle group. In addition, the in-vehicle unit 1 transmits the medium-term driving plan data included in the control message to the vehicle control system application X, driver assistance applications, and autonomous driving applications.

[0146] <Regarding uploading user packets> Next, using a sequence diagram in Figure 18, we will explain the flow of data from a general node to the central server 5, using the example of a user packet sent to the central server 5 from vehicle H, which acts as a general node. As a premise, the time when the user packet is generated in vehicle H corresponds to the period (T1b_s~T1be) when vehicle B acts as connected node 1x, and the communication path within the vehicle group is assumed to be vehicle H → vehicle G → vehicle B.

[0147] Note that, in this context, user packets refer to communication packets that are not control packets. For example, communication packets that make up data generated by application X, such as probe data, are considered user packets. User packets are the packets exchanged between application X and the central server 5.

[0148] When the in-vehicle unit 1h receives a user packet from application X within its own vehicle destined for the central server 5 (S201), it wirelessly transmits the user packet using a transmission path appropriate to the time. Specifically, the in-vehicle unit 1h wirelessly transmits a user packet with vehicle G as the hop destination and the central server 5 as the final destination (S202).

[0149] When in-vehicle unit 1g, which is installed in vehicle G, receives a user packet designated as its hop destination, it determines whether the data is destined for itself based on the final destination field. Since the final destination of the user packet received this time is set to the central server 5, in-vehicle unit 1g determines that the received packet should be forwarded to connected node 1x. Then, in-vehicle unit 1g performs the process of forwarding the received packet transmitted from in-vehicle unit 1h to vehicle B, which corresponds to the current connected node 1x (S203). Note that the route selection unit F11 of in-vehicle unit 1g may also determine whether the data is destined for itself based on the hop source information and determine the forwarding destination. The forwarding process within the vehicle group itself corresponds to rewriting the destination information in the Layer 2 header and transmitting it wirelessly.

[0150] Vehicle unit 1b, which is vehicle unit B, also performs receive / forward processing according to its routing table when it receives a user packet that it has set as its hop destination (S204). That is, since the final destination of the received user packet is set to the central server 5, vehicle unit 1b forwards the received packet to RSU3 (S205). Vehicle-to-vehicle and vehicle-to-infrastructure communication for sending user packets is performed using unicast. Note that whether or not arrival confirmation is required, in other words, whether to use TCP or UDP, can be specified by application X.

[0151] When RSU3 receives a user packet destined for central server 5, it performs forwarding according to the pre-configured routing table (S205). Specifically, RSU3 forwards the received packet to edge server 4. Edge server 4 also performs forwarding according to the pre-configured routing table when it receives a user packet destined for central server 5 (S206). That is, edge server 4 forwards the received packet to central server 5.

[0152] When the central server 5 receives a user packet destined for itself, it performs processing according to the content of the received packet (S207). For example, if the received packet corresponds to probe data, the central server 5 saves the probe data to a database for map updates or similar.

[0153] As described above, user packets transmitted by each in-vehicle unit 1 are transmitted to the central server 5 via the connected node 1x, RSU 3, and edge server 4. Note that the transmission of user packets can be performed at any time. If, for example, the group of vehicles is not in a state to communicate with RSU 3 when a user packet is received from application X, the in-vehicle unit 1 may transmit the user packet via wide-area communication, or it may hold off on transmitting until the group of vehicles can connect with RSU 3.

[0154] <Regarding transmission routing control> Next, the transmission route control process performed by the in-vehicle unit 1, particularly the route control unit F12, will be explained using the flowchart shown in Figure 19. The transmission route control process corresponds to the process of managing effective routes, which are valid narrow-area communication routes, and invalid routes, which are invalid narrow-area communication routes. An effective route is a communication route within the vehicle group in which packets transmitted by the unit can reach RSU3 without taking a detour. An invalid route refers to a communication route within the vehicle group in which packets transmitted by the unit cannot reach RSU3, or a communication route within the vehicle group in which a detour may result due to switching of connected node 1x. As an example, the transmission route control process includes steps S301 to S308. Each step may be executed in order.

[0155] Step S301 is a step in which any one of the members of the vehicle group is set as a target candidate. Step S301 may also be a step in which any one of the connection candidates shown in the RSU connection table is set as a target candidate. The route control unit F12 may determine that there are no valid narrow-area communication paths if there are no in-vehicle devices 1 connected to RSU3 at the current time.

[0156] Step S302 is the step of obtaining the current time (Tc). Step S303 is the step of obtaining the propagation time within the vehicle group to the target candidate (dT). Step S304 is the step of obtaining the connection period of the target candidate by referring to the RSU connection table. In the figure, Ts represents the connection start time of the target candidate, and Te represents the connection end time. Note that if there are no RSU3s that the target candidate is scheduled to connect to within the immediate vicinity fixed time, the route control unit F12 may determine that the narrow-area communication path for packet forwarding from the target candidate to RSU3 is invalid.

[0157] Step S305 is a step in which the estimated arrival time (Tcd), which is calculated by adding the propagation time within the vehicle group to the current time, is determined to determine whether it falls within the connection period of the target candidate. If the estimated arrival time (Tcd) falls within the connection period of the target candidate, the packet transmitted by the local machine is transmitted from the target candidate to RSU3 and becomes available for transmission to the central server 5. Therefore, if the estimated arrival time (Tcd) falls within the connection period of the target candidate, the route control unit F12 sets the vehicle group communication path with the target candidate as the root node as an active path (S306).

[0158] On the other hand, if the expected arrival time (Tcd) does not fall within the connection period of the target candidate, it means that the packets sent by the local unit cannot be sent from the target candidate to RSU3. Therefore, the route control unit F12 sets the in-vehicle group communication path with the target candidate as the root node as an invalid path (S307).

[0159] Step S308 is a step in which it is determined whether the processing in steps S302 to S308 has been performed for all members of the vehicle group, in other words, for all communication paths within the vehicle group. If the valid / invalid determination has been completed for all communication paths within the vehicle group, this flow is terminated.

[0160] The route selection unit F11 then sends control packets and user packets as needed using the in-vehicle communication paths that have been set as valid paths by the route control unit F12 as described above. For example, if the narrow-area communication path through the current connection node, which is the current connection node 1x, is invalid due to the propagation time within the vehicle group, then data is transmitted via the narrow-area communication path through the next connection node, which will be the next connection node 1x. In other words, if the in-vehicle device 1 foresees that the data to be transmitted will not arrive by the connection termination time of the current connection node, it transmits the data to the next connection node. The current connection node corresponds to the current representative node, and the next connection node corresponds to the next representative node.

[0161] <Regarding the effects of the above transmission path control> When transmitting data using a narrow-area communication path, it is possible that the connected node 1x itself may switch between the time the device sends a packet and the time the packet reaches the connected node 1x.

[0162] For example, if vehicle A corresponds to connection node 1x, the in-vehicle device 1h transmits a packet along the intra-vehicle communication path toward vehicle A. However, while the packet is being forwarded by vehicle G or vehicle F, connection node 1x may switch from vehicle A to vehicle B. If, for example, connection node 1x has switched to vehicle B by the time the packet transmitted by vehicle H reaches vehicle A, then a further step may occur where the transmitted packet is forwarded from vehicle A to vehicle B. Considering that the intra-vehicle communication path from vehicle H to vehicle B is equivalent to two hops, in the above case, the transmitted packet will take a roundabout route to reach connection node 1x.

[0163] In other words, in a configuration that uses the current in-vehicle communication path destined for connection node 1x without considering the propagation time within the vehicle group to connection node 1x, the efficiency of utilizing narrow-area communication resources may deteriorate. To address this issue, the configuration described above, which selects the transmission path while considering the propagation time within the vehicle group to connection node 1x, allows for more efficient use of narrow-area communication resources.

[0164] Furthermore, by having each in-vehicle unit 1 perform the above-described transmission path control, valid and invalid paths can be set according to the arrival time not only at the packet source but also at the in-vehicle unit 1 acting as the forwarding unit. As a result, the forwarding vehicle can also forward received packets to the appropriate hop destination according to the arrival time.

[0165] <Supplement (1)> According to the above configuration, if it is expected that the transmitted packets will not arrive at the current connected node by the connection termination time of the current connected node, general node 1y will operate to transmit packets via an alternative communication path. For example, general node 1y will basically adopt the intra-vehicle communication path toward the next connected node as the alternative communication path. However, if the current connected node is the last vehicle in the vehicle group and the entire vehicle group will soon be unable to communicate with RSU3, the path control unit F12 may adopt a wide-area communication path as the alternative communication path. General node 1y may suspend / cancel data transmission if it is expected that the transmitted data will not arrive at the current connected node by the connection termination time of the current connected node.

[0166] <Supplement (2)> In the above configuration, general node 1y obtains the scheduled time when each connection candidate will begin communicating with RSU3 from edge server 4. In other words, the general node holds the start time of the vehicle-infrastructure connection period. If vehicle-infrastructure communication is not possible, general node 1y may transmit data so that the data destined for the server arrives at the leading connection node by the start time of the vehicle-infrastructure connection period. The leading connection node is the on-board unit 1 that first connects to RSU3 within the vehicle-infrastructure, such as the on-board unit 1 of the leading vehicle. Specifically, on-board units 1 other than the leading connection node may transmit data toward the leading connection node by the time calculated by the vehicle-infrastructure propagation time from the connection start time of the leading connection node to the leading connection node. Furthermore, if general node 1y anticipates that the transmitted data will not reach the current connection node by the connection end time of the current connection node, it may start transmitting data so that the data arrives at the next connection node by the connection start time of the next connection node.

[0167] <Supplement (3)> Packet transmission and reception in narrow-area communication can be performed using V2X sidelink or NR sidelink, or corresponding sidelinks, as supported by 3GPP releases 14-16, etc. The in-vehicle device 1 may selectively use PSSCH (Physical Sidelink Shared Channel), PSBCH (Physical Sidelink Broadcast Channel), or PSCCH (Physical Sidelink Control Channel) as described in Non-Patent Literature 1 for packet transmission in narrow-area communication. PSSCH, PSBCH, and PSCCH are channels implemented using different frequencies or time slots. For example, the in-vehicle device 1 uses PSSCH for unicast packet transmission, while using PSBCH for multicast packet transmission. Control packets such as status reports are also transmitted and received using PSSCH. In one embodiment, the in-vehicle device 1 does not use PSCCH for transmitting control packets.

[0168] While embodiments of the present disclosure have been described above, the present disclosure is not limited to the embodiments described above. Various modifications described below are also included within the technical scope of the present disclosure, and further modifications can be made in various ways without departing from the gist of the invention. For example, the various supplements and modifications described below can be combined as appropriate without causing any technical inconsistencies. In addition, components having the same function as those described above may be denoted by the same reference numerals, and their descriptions may be omitted. Also, if only a part of the configuration is referred to, the above description may be applied to the other parts.

[0169] <Example (1)> Since the communication period between RSU3 and the vehicle group is finite, the edge server 4 and the central server 5 may also control the selection of the communication path and the transmission timing, taking into account the delay time to reach RSU3. For example, the central server 5 performs a transmission control process that adjusts the delivery timing and delivery path of control messages and static / dynamic map data, taking into account the delay time to reach RSU3. The transmission control process includes steps S401 to S407, as shown in Figure 20, for example.

[0170] Step S401 is a step to measure the arrival delay time to each RSU3. The arrival delay time to RSU3 corresponds to the time required for the roadside unit to arrive. The arrival delay time from the central server 5 to RSU3 can be half the actually measured RTT. The RTT can be determined by sending and receiving arrival confirmation type control packets. The central server 5 may perform step S401 periodically. For example, the central server 5 may measure the arrival delay time while also confirming communication with each RSU3.

[0171] Step S402 is the step of generating transmission data to be sent to a group of vehicles. Step S402 is performed as needed for each group of vehicles. Hereafter, any one group of vehicles corresponding to the destination will be referred to as the target group of vehicles.

[0172] Step S403 is a step in which the RSU3 that the target vehicle group is currently connected to or is scheduled to connect to next is identified as a relay RSU based on the control plan of the target vehicle group and the installation location information of the RSU3. Step S404 is a step in which the connection period between the relay RSU and the target vehicle group is read.

[0173] Step S405 is a step to determine whether the data to be transmitted will reach the relay RSU within the connection period between the relay RSU and the target vehicle group. This determination corresponds, for example, to determining whether the estimated arrival time, which is calculated by adding the arrival delay time to the relay RSU to the current time, falls within the connection period between the relay RSU and the target vehicle group. If, as a result of step S405, the estimated arrival time falls within the connection period between the relay RSU and the target vehicle group (S405 YES), the data addressed to the target vehicle group is transmitted to the relay RSU (S406).

[0174] On the other hand, if, as a result of step S405, the expected arrival time falls outside the connection period between the relay RSU and the target vehicle group (S405 NO), the central server 5 changes the transmission route (S407). For example, the central server 5 may set RSU3, which the target vehicle group is scheduled to pass through after the currently set relay RSU, as the new relay RSU and perform the determination in step S405. This operation is equivalent to distributing data via the route that passes through RSU3, which is the next RSU the vehicle group is scheduled to pass through.

[0175] Furthermore, if the estimated arrival time falls outside the connection period between the relay RSU and the target vehicle group (S405 NO), the central server 5 may adopt wide-area communication as the data distribution route. Whether to adopt the narrow-area communication route via the next RSU 3 or the wide-area communication route as an alternative route when immediate data distribution is not possible should be determined by the characteristics of the data to be transmitted, such as importance, immediacy, and data size.

[0176] Furthermore, the central server 5 may cancel the transmission of data if the waiting time until the target group of vehicles connects to the RSU3 next is greater than a predetermined value and the data to be transmitted is not important. The transmission control processing described above is not limited to the central server 5; the edge server 4 may also perform the same transmission control processing.

[0177] With the above configuration, downlink communication can also be performed efficiently. In other words, the risk of retransmission control occurring during data distribution from the external server to the vehicles using RSU3 can be reduced. Furthermore, in the above configuration, the external server holds the connection start time of the target vehicle group. Therefore, the external server may pre-distribute data for the target vehicle group to RSU3 by the time the target vehicle group starts connecting to RSU3. In other words, the edge server 4 may send data addressed to the target vehicle group to RSU3 more than the time required for the roadside unit to arrive before the connection start time. With this configuration, data distribution to the target vehicle group can be performed as soon as the target vehicle group connects to RSU3. In other words, the period during which the vehicle group is connected to RSU3 can be used efficiently.

[0178] <Example (2)> The above exemplifies how the route control unit F12 selects a transmission route and controls the transmission schedule based on the data communication requirements and narrow-area communication status requested by application X. In addition, the route control unit F12 may change the data transmission schedule or transmission route depending on the driving conditions. For example, the route control unit F12 may evaluate the driving conditions of its own vehicle in three stages: high, medium, and normal, based on vehicle speed information input as sensor data, or based on the frequency with which the wide-area communication unit 131 has performed cell reselection within a fixed time period in the immediate vicinity. Driving conditions can also be described as the state of movement.

[0179] For example, if the driving status is high, the route control unit F12 may use the wide-area communication route instead of the narrow-area communication route. Also, if the vehicle's movement status is normal, the route control unit F12 will actively use the narrow-area communication route. If the vehicle's movement status is medium, the route control unit F12 will use the narrow-area communication route and the wide-area communication route depending on the communication requirements from application X. Note that the movement status = high corresponds to moving at high speed (e.g., 80 km / h or more), the medium state corresponds to moving at medium speed (e.g., 40 km / h to 80 km / h), and the normal state refers to driving at low speed (less than 40 km / h) or being stopped. With this configuration, the risk of retransmission control etc. can be reduced by selecting a route according to the movement status.

[0180] Furthermore, when the movement status is high, the connection period of connected node 1x is relatively shorter. Taking these circumstances into consideration, the route control unit F12 may start transmitting data earlier when the movement status is high compared to when the movement status is normal or medium. With this configuration, the risk of data communication failure via connected node 1x can be reduced. As described above, a configuration in which the route control unit F12 changes the transmission timing and transmission path determination rules in narrow-area communication according to the movement status can reduce the risk of packet loss, etc.

[0181] <Variation (3)> The narrow-area communication standard may be Wi-Fi® or EnOcean®. The in-vehicle unit 1 may be configured to use 4G / LTE and narrow-area communication in conjunction with WiMAX, 3G, etc. Furthermore, the in-vehicle unit 1 may be configured to perform vehicle-to-infrastructure communication and vehicle-to-vehicle communication using different communication methods. For example, the in-vehicle unit 1 may perform vehicle-to-infrastructure communication using DSRC while performing vehicle-to-vehicle communication using Wi-Fi. In addition, the in-vehicle unit 1 may be configured to use two or more communication methods in conjunction as the narrow-area communication method. For example, the in-vehicle unit 1 may be configured to use Cellular V2X (PC5) and DSRC / WAVE (Wireless Access in Vehicular Environments) in parallel / selectively. A configuration that allows the in-vehicle unit 1 to use multiple communication methods in conjunction can enhance its robustness.

[0182] <Additional remark (1)> The various flowcharts shown in this disclosure are all examples, and the number of steps constituting the flowchart and the execution order of the processes can be changed as appropriate. The same applies to sequence diagrams. Furthermore, 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 by a computer program. As the processor (processing core), a CPU, MPU, GPU, DFP (Data Flow Processor), etc. can be used. Computers also include system-on-chip (SoC), IC (Integrated Circuit), and FPGA (Field-Programmable Gate Array). The concept of IC also includes ASIC (Application Specific Integrated Circuit). Furthermore, the above computer program only needs to be stored on a computer-readable non-transitory tangible storage medium as instructions to be executed by the computer. As the storage medium for the program, an HDD (Hard-disk Drive), SSD (Solid State Drive), flash memory, etc. can be used. [Explanation of Symbols]

[0183] 1 Vehicle-mounted unit (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 vehicle communication system for which each of a group of vehicles in a single vehicle group communicates data with an external server (4, 5) via a representative vehicle (Mx) dynamically set among the group of vehicles constituting the vehicle group, A general node (1y), which is a communication device used in a vehicle other than the aforementioned representative vehicle, is configured to control the transmission of data to the external server based on the communication status between itself and the representative node (1x), which is a communication device used in the aforementioned representative vehicle. The aforementioned general node is The representative node obtains the connection start time, which is the time when it begins communicating with the roadside unit, Obtain the propagation time within the vehicle group, which is the time it takes for the data sent by itself to reach the aforementioned representative node, A vehicle communication system configured to adjust the data transmission schedule based on the connection start time and the propagation time within the vehicle group.

2. A vehicle communication system according to claim 1, A vehicle communication system configured such that the general node starts transmitting the data so that the data arrives at the representative node by the connection start time.

3. A vehicle communication system according to claim 1 or 2, The general node is a vehicle communication system that determines the propagation time within the vehicle group according to the number of hops to the representative node or the measured round-trip time.

4. A vehicle communication system according to claim 1 or 2, The aforementioned general node is The representative node obtains the connection termination time, which is the time when it terminates communication with the roadside unit. A vehicle communication system configured to determine the data transmission schedule based on the connection termination time and the vehicle group propagation time.

5. A vehicle communication system according to claim 4, The general node is configured in a vehicle communication system that, if the data does not arrive at the current representative node by the connection termination time, either suspends data transmission or performs data transmission via a different communication path.

6. A vehicle communication system according to claim 1 or 2, The aforementioned general node is The current representative node obtains the connection termination time, which is the time when it terminates communication with the roadside unit, Identifying the next representative node, which is the communication device that will initiate communication with the roadside device after the current representative node, Obtain the propagation time within the vehicle group, which is the time it takes for the data sent by itself to reach the current representative node. Based on the current time, the propagation time within the vehicle group, and the connection termination time, it is determined whether or not the data will arrive at the representative node by the connection termination time. A vehicle communication system configured to transmit the data to the next representative node if it is determined that the data will not arrive at the representative node by the connection termination time.

7. A vehicle communication system according to claim 1 or 2, The aforementioned external server is This involves obtaining the time required for data transmitted by the external server to arrive at the roadside unit, and The representative node obtains the connection start time, which is the time when it begins communicating with the roadside unit. A vehicle communication system configured to create a data transmission schedule to the group of vehicles based on the connection start time and the time required for the roadside unit to arrive.

8. A vehicle communication system according to claim 7, The external server is a vehicle communication system that starts transmitting the data to the roadside unit, destined for the group of vehicles, to the roadside unit at a time greater than or equal to the time required for the roadside unit to arrive, prior to the connection start time.

9. A vehicle communication system according to claim 8, The aforementioned communication device is a vehicle communication system configured to communicate with other aforementioned communication devices using multiple types of communication methods.

10. A vehicle communication system according to claim 1 or 2, The aforementioned communication device is a vehicle communication system that controls the transmission schedule or transmission route of the data according to the data communication requirements, driving conditions, and communication conditions requested by the application.

11. A vehicle communication system according to claim 1 or 2, The aforementioned communication device is a vehicle communication system configured to autonomously determine the communication path to the aforementioned representative node at each time interval.

12. A communication device used in a vehicle, configured to enable data communication with an external server via a roadside unit (3), This involves obtaining information about other communication devices used by other vehicles that make up the group of vehicles, including your own vehicle, and other information about the members of your vehicle group. To obtain the communication status with the representative node, which is the communication device that is responsible for communicating with the roadside unit, among the members of the vehicle group, It is configured to control the transmission of data to the external server based on the communication status with the aforementioned representative node. The representative node obtains the connection start time, which is the time when it begins communicating with the roadside unit, Obtain the propagation time within the vehicle group, which is the time it takes for the data sent by itself to reach the aforementioned representative node, A communication device configured to perform the following: adjust the data transmission schedule based on the connection start time and the propagation time within the vehicle group.

Images