KR20240059478A - Electronic device and method for managing event in vehcile communication system - Google Patents

Abstract

In embodiments, a device in a vehicle may include at least one transceiver, a memory configured to store instructions, and at least one processor operatively coupled with the at least one transceiver and the memory. The at least one processor may be configured to receive an event message related to an event of the source vehicle when the instructions are executed. The event message may include identification information about a serving road side unit (RSU) of the source vehicle and direction information indicating the driving direction of the source vehicle. The at least one processor may be configured to identify whether the serving RSU of the source vehicle is included in the driving list of the vehicle when the instructions are executed. The at least one processor may be configured to identify whether the driving direction of the source vehicle matches the driving direction of the vehicle when the instructions are executed. When the instructions are executed, the at least one processor identifies that the driving direction of the source vehicle matches the driving direction of the vehicle and that the serving RSU of the source vehicle is included in the driving list of the vehicle (upon identifying ), may be configured to perform driving according to the event message. When executing the instructions, the at least one processor identifies that the driving direction of the source vehicle does not match the driving direction of the vehicle, or that the serving RSU of the source vehicle is not included in the driving list of the vehicle. (upon identifying), may be configured to perform driving without the event message.

Description

Electronic device and method for managing events in a vehicle communication system {ELECTRONIC DEVICE AND METHOD FOR MANAGING EVENT IN VEHCILE COMMUNICATION SYSTEM}

This disclosure relates to a vehicle communication system, and more specifically to an electronic device and method for managing events in a vehicle communication system.

An advanced driver assistance system (ADAS) is being developed to prevent traffic accidents involving vehicles in advance and improve the efficiency of traffic flow. At this time, as a vehicle communication system, V2X (vehicle-to-everything) may be used. Representative examples of V2X include vehicle to vehicle (V2V) communication and vehicle to infrastructure (V2I) communication. Vehicles that support V2V and V2I communication can send collision warnings or the presence of a forward accident to other vehicles (surrounding vehicles) that support V2X communication. Management devices such as road side units (RSUs) can control traffic flow by informing vehicles of real-time traffic conditions or controlling signal waiting times.

In embodiments, a device in a vehicle may include at least one transceiver, a memory configured to store instructions, and at least one processor operatively coupled with the at least one transceiver and the memory. The at least one processor may be configured to receive an event message related to an event of the source vehicle when the instructions are executed. The event message may include identification information about a serving road side unit (RSU) of the source vehicle and direction information indicating the driving direction of the source vehicle. The at least one processor may be configured to identify whether the serving RSU of the source vehicle is included in the driving list of the vehicle when the instructions are executed. The at least one processor may be configured to identify whether the driving direction of the source vehicle matches the driving direction of the vehicle when the instructions are executed. When the instructions are executed, the at least one processor identifies that the driving direction of the source vehicle matches the driving direction of the vehicle and that the serving RSU of the source vehicle is included in the driving list of the vehicle (upon identifying ), may be configured to perform driving according to the event message. When the at least one processor executes the instructions, the driving direction of the source vehicle does not match the driving direction of the vehicle, or the serving RSU of the source vehicle is not included in the driving list of the vehicle. (upon identifying), may be configured to perform driving without the event message.

In embodiments, an apparatus implemented by a road side unit (RSU) includes at least one transceiver, a memory configured to store instructions, and at least one processor operatively coupled to the at least one transceiver and the memory. may include. The at least one processor may be configured to receive, when the instructions are executed, an event message related to an event in the vehicle from the vehicle serviced by the RSU. The event message may include identification information of the vehicle and direction information indicating the driving direction of the vehicle. The at least one processor may be configured to identify a driving path of the vehicle when the instructions are executed, based on identification information of the vehicle. When the instructions are executed, the at least one processor is configured to identify at least one RSU located in a direction opposite to the driving direction of the vehicle from the RSU among one or more RSUs included in the driving path of the vehicle. It can be configured. The at least one processor may be configured to deliver the event message to each of the identified at least one RSU when the instructions are executed.

In embodiments, a method performed by a vehicle may include receiving an event message related to an event of the source vehicle. The event message may include identification information about a serving road side unit (RSU) of the source vehicle and direction information indicating the driving direction of the source vehicle. The method may include identifying whether the serving RSU of the source vehicle is included in the vehicle's driving list. The method may include identifying whether the driving direction of the source vehicle matches the driving direction of the vehicle. The method performs driving according to the event message when the driving direction of the source vehicle matches the driving direction of the vehicle and upon identifying that the serving RSU of the source vehicle is included in the driving list of the vehicle. It may include actions such as: If the method identifies that the driving direction of the source vehicle does not match the driving direction of the vehicle, or the serving RSU of the source vehicle is not included in the driving list of the vehicle, without the event message, It may include the operation of performing driving.

In embodiments, a method performed by a road side unit (RSU) may include receiving an event message related to an event in the vehicle from a vehicle serviced by the RSU. The event message may include identification information of the vehicle and direction information indicating the driving direction of the vehicle. The method may include an operation of identifying a driving path of the vehicle based on identification information of the vehicle. The method may include identifying at least one RSU located in a direction opposite to the driving direction of the vehicle from the RSU among one or more RSUs included in the driving path of the vehicle. The method may include delivering the event message to each of the identified at least one RSU.

1 shows a wireless communication system according to embodiments.
2 shows an example of a traffic environment according to embodiments.
Figure 3 shows an example of groupcast-based vehicle communication according to an embodiment.
Figure 4 shows an example of unicast vehicle communication according to an embodiment.
Figure 5 shows an example of an autonomous driving service establishment procedure through a road side unit (RSU) according to an embodiment.
Figure 6 shows an example of an event-based autonomous driving service according to an embodiment.
Figure 7 shows an example of signaling between entities for setting a driving route based on an event according to an embodiment.
Figures 8A to 8C illustrate examples of efficient processing of event messages when setting a driving route based on an event, according to an embodiment.
Figure 9 shows the operation flow of an RSU for event message processing according to one embodiment.
Figure 10 shows a vehicle operation flow for event message processing according to one embodiment.
Figure 11 shows the operation flow of an event-related vehicle according to an embodiment.
Figure 12 illustrates the operational flow of a service provider to reset a driving route in response to an event according to one embodiment.
Figure 13A shows an example of components of a vehicle according to one embodiment.
Figure 13B shows an example of components of an RSU according to one embodiment.
Figure 14 is a block diagram showing the autonomous driving system of a vehicle.
15 and 16 are block diagrams showing an autonomous mobile device according to an embodiment.

Terms used in the present disclosure are merely used to describe specific embodiments and may not be intended to limit the scope of other embodiments. Singular expressions may include plural expressions, unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as commonly understood by a person of ordinary skill in the technical field described in this disclosure. Among the terms used in this disclosure, terms defined in general dictionaries may be interpreted to have the same or similar meaning as the meaning they have in the context of related technology, and unless clearly defined in this disclosure, have an ideal or excessively formal meaning. It is not interpreted as In some cases, even terms defined in the present disclosure cannot be interpreted to exclude embodiments of the present disclosure.

In various embodiments of the present disclosure described below, a hardware approach method is explained as an example. However, since various embodiments of the present disclosure include technology using both hardware and software, the various embodiments of the present disclosure do not exclude software-based approaches.

In the following description, terms referring to signals (e.g., signal, information, message, signaling), terms referring to data types (e.g., list, set, subset), and operation states are used. Terms referring to data (e.g. step, operation, procedure), terms referring to data (e.g. packet, user stream, information, bit, symbol, code) Word (codeword), terms referring to resources (e.g. symbol, slot, subframe, radio frame, subcarrier, RE (resource element), RB (resource block), BWP (bandwidth part), opportunity), terms referring to channels, terms referring to network entities, terms referring to device components, etc. are examples for convenience of explanation. It has been done. Accordingly, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meaning may be used.

In addition, in the present disclosure, the expressions greater than or less than may be used to determine whether a specific condition is satisfied or fulfilled, but this is only a description for expressing an example, and the description of more or less may be used. It's not exclusion. Conditions written as ‘more than’ can be replaced with ‘more than’, conditions written as ‘less than’ can be replaced with ‘less than’, and conditions written as ‘more than and less than’ can be replaced with ‘greater than and less than’. In addition, hereinafter, 'A' to 'B' means at least one of the elements from A to (including A) and B (including B).

The present disclosure uses terms used in some communication standards (e.g., 3rd Generation Partnership Project (3GPP), European Telecommunications Standards Institute (ETSI), extensible radio access network (xRAN), and open-radio access network (O-RAN). Although various embodiments are described, this is only an example for explanation and the various embodiments of the present disclosure can be easily modified and applied to other communication systems. , The terminology in 3GPP-based C(cellular)-V2X is described as an example, but in addition to C-V2X, Wi-Fi-based dedicated short range communication (DSRC), and other organizations (e.g., 5GAA (5G automotive association)) ) or a communication method defined by a separate organization may be used for embodiments of the present disclosure.

Terms used in the present disclosure are merely used to describe specific embodiments and may not be intended to limit the scope of other embodiments. Singular expressions may include plural expressions, unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as commonly understood by a person of ordinary skill in the technical field described in this disclosure. Among the terms used in this disclosure, terms defined in general dictionaries may be interpreted to have the same or similar meaning as the meaning they have in the context of related technology, and unless clearly defined in this disclosure, have an ideal or excessively formal meaning. It is not interpreted as In some cases, even terms defined in the present disclosure cannot be interpreted to exclude embodiments of the present disclosure.

In various embodiments of the present disclosure described below, a hardware approach method is explained as an example. However, since various embodiments of the present disclosure include technology using both hardware and software, the various embodiments of the present disclosure do not exclude software-based approaches.

1 illustrates a wireless communication system according to embodiments of the present disclosure. Figure 1 illustrates a base station 110, a terminal 120, and a terminal 130 as some of the nodes that use a wireless channel in a wireless communication system. Figure 1 shows only one base station, but other base stations identical or similar to the base station 110 may be further included.

The base station 110 is a network infrastructure that provides wireless access to terminals 120 and 130. Base station 110 has coverage defined as a certain geographic area based on the distance over which signals can be transmitted. In addition to the base station, the base station 110 includes 'access point (AP)', 'eNodeB (eNB)', '5G node (5th generation node)', and 'next generation nodeB'. , gNB)', 'wireless point', 'transmission/reception point (TRP)', or other terms with equivalent technical meaning.

Each of the terminal 120 and terminal 130 is a device used by a user and communicates with the base station 110 through a wireless channel. The link from the base station 110 to the terminal 120 or terminal 130 is downlink (DL), and the link from the terminal 120 or terminal 130 to the base station 110 is uplink (UL). ) is referred to as. Additionally, the terminal 120 and the terminal 130 may communicate with each other through a wireless channel. At this time, the link between the terminal 120 and the terminal 130 is referred to as a sidelink, and the sidelink may be used interchangeably with the PC5 interface. In some cases, at least one of the terminal 120 and the terminal 130 may be operated without user involvement. That is, at least one of the terminal 120 and the terminal 130 is a device that performs machine type communication (MTC) and may not be carried by the user. The terminal 120 and the terminal 130 each include a 'user equipment (UE)', 'mobile station', 'subscriber station', and 'remote terminal' in addition to the terminal. )', 'wireless terminal', or 'user device', or other terms with equivalent technical meaning.

2 shows an example of a traffic environment according to embodiments. Vehicles on the road can communicate. Vehicles performing communication can be viewed as terminals 120 and 130 of FIG. 1, and communication between terminals 120 and 130 can be viewed as vehicle-to-vehicular (V2V) communication. That is, the terminals 120 and 130 are a vehicle supporting vehicle-to-vehicle communication, a vehicle or pedestrian handset (e.g., smartphone) supporting vehicle-to-pedestrian (V2P) communication, and a vehicle and network. It may refer to a vehicle that supports communication between vehicles (vehicular-to-network, V2N) or a vehicle that supports communication between vehicles and infrastructure (vehicular-to-infrastructure: V2I). In addition, in the present disclosure, the terminal is an RSU (road side unit) equipped with a terminal function, an RSU equipped with the function of the base station 110, or a part of the function of the base station 110 and a part of the function of the terminal 120. It can mean one RSU.

Referring to FIG. 2, vehicles (eg, vehicle 211, vehicle 212, vehicle 213, vehicle 215, and vehicle 217) may be driving on the road. To support communication with a running vehicle, a plurality of RSUs (eg, RSU 231, RSU 233, and RSU 235) may be located across the road. Each RSU can perform the base station or some functions of the base station instead. For example, each RSU may allocate resources to individual vehicles and communicate with vehicles to provide services (e.g., autonomous driving services) to each vehicle. As an example, the RSU 231 may communicate with the vehicle 211, vehicle 212, and vehicle 213. RSU 233 may communicate with vehicle 215. RSU 235 may communicate with vehicle 217. Meanwhile, in addition to the RSU of the terrestrial network, the vehicle may also communicate with network entities of a non-terrestrial network, such as a GNSS satellite 250.

RSU controller 240 can control multiple RSUs. The RSU controller 240 may assign each RSU ID to each of the RSUs. The RSU controller 240 may generate a neighboring RSU list including RSU IDs of neighboring RSUs of each RSU. RSU controller 240 may be connected to each RSU. For example, the RSU controller 240 may be connected to the first RSU 231. The RSU controller 240 may be connected to the second RSU 233. The RSU controller 240 may be connected to the third RSU 235.

Vehicles can access the network through RSU. However, vehicles may also communicate directly with other vehicles as well as network entities such as base stations. Vehicles can communicate with each other. In other words, not only V2I but also V2V is possible, and the transmitting vehicle can transmit a message to at least one other vehicle. For example, the transmitting vehicle may transmit a message to at least one other vehicle through resources allocated from the RSU. As another example, the transmitting vehicle may transmit a message to at least one other vehicle through resources within a pre-configured resource pool.

Figure 3 shows an example of groupcast-based vehicle communication according to an embodiment. Hereinafter, each vehicle exemplifies the vehicles 211, 212, and 213 in FIG. 2.

Referring to FIG. 3, the one-to-many transmission method may be referred to as groupcast or multicast. The transmitting vehicle 320, the first vehicle 321a, the second vehicle 321b, the third vehicle 321c, and the fourth vehicle 321d form one group, and vehicles within the group are grouped. Cast communication can be performed. Vehicles may perform group cast communication within the group they belong to, and may perform unicast, group cast, or broadcast communication with at least one other vehicle belonging to different groups. Meanwhile, unlike FIG. 3, sidelink vehicles can perform broadcast communication. Broadcast communication refers to a method in which all surrounding sidelink vehicles receive data and control information transmitted through the sidelink by the sidelink transmitting vehicle. For example, in FIG. 3, when another vehicle is driving near the transmitting vehicle 320, if the other vehicle is not designated as a group, the other vehicle receives data and control information according to the groupcast communication of the transmitting vehicle 320. cannot be received. However, even if said other vehicles are not designated as a group. The other vehicle can receive data and control information according to the broadcast communication of the transmitting vehicle 320.

Figure 4 shows an example of unicast vehicle communication according to an embodiment.

Referring to FIG. 4, the one-to-one transmission method may be referred to as unicast. The one-to-many transmission method may be referred to as groupcast or multicast. The transmitting vehicle 420a designates the first vehicle 420b as the target to receive the message among the first vehicle 420b, the second vehicle 420c, and the third vehicle 420d, and the first vehicle 420b You can send a message for . The transmitting vehicle 420a may transmit a message to the first vehicle 420b in a unicast manner through a radio access technology (eg, LTE, NR).

In the case of the NR sidelink, unlike the LTE sidelink, it supports a transmission type in which a vehicle transmits data to only one specific vehicle through unicast and a transmission type in which data is transmitted to a plurality of specific vehicles through groupcast. This can be considered. For example, when considering a service scenario such as platooning, which is a technology that connects two or more vehicles to one network and moves in a group form, these unicast and group cast technologies can be useful. Specifically, unicast communication can be used for the purpose of controlling one specific vehicle by the leader vehicle of a group connected by platooning, and group cast communication can be used for the purpose of controlling a group consisting of a specific number of vehicles simultaneously. This can be used.

As an example, resource allocation in sidelink systems such as V2X, V2V, and V2I can be divided into the following two modes.

(1) Mode 1 resource allocation

Mode 1 is a method based on scheduled resource allocation by the RSU (or base station). More specifically, in mode 1 resource allocation, the RSU can allocate resources used for sidelink transmission to vehicles connected to RRC (Radio Resource Control Connection) according to a dedicated scheduling method. Because the RSU can manage the resources of the sidelink, scheduled resource allocation is advantageous for interference management and management of resource pools (e.g., dynamic allocation and/or semi-persistent transmission). When the RRC connected mode vehicle has data to transmit to other vehicle(s), the vehicle may use an RRC message or MAC control element to transmit information informing the RSU that there is data to transmit to the other vehicle(s). For example, the RRC message notifying the existence of data may be a sidelink terminal information (SidelinkUEInformation) or terminal assistance information (UEAssistanceInformation) message. For example, the MAC control element notifying the existence of data may be a buffer status report (BSR) MAC control element for sidelink communication, or a scheduling request (SR). The buffer status report includes at least one of an indicator indicating BSR and information about the size of data buffered for sidelink communication. Since the RSU schedules resources to the transmitting vehicle when applying mode 1, mode 1 can only be applied when the transmitting vehicle is within the coverage of the RSU.

(2) Mode 2 resource allocation

Mode 2 is a method based on UE autonomous resource selection, in which the sidelink transmitting vehicle selects resources. Specifically, according to mode 2, the RSU provides the sidelink transmission/reception resource pool for the sidelink to the vehicle as system information or RRC messages (e.g., RRCReconfiguration message, PC-5 RRC message) , the transmitting vehicle selects resource pools and resources according to established rules. Because the RSU provides configuration information for the sidelink resource pool, mode 2 can be used when the vehicle is within the coverage of the RSU. If the vehicle exists outside the coverage of the RSU, the vehicle can perform operations according to mode 2 in a pre-configured resource pool. For example, as an autonomous resource selection method for a vehicle, zone mapping, sensing-based resource selection, random selection, etc. may be used.

(3) Others

Additionally, even if located within the coverage of the RSU, there may be cases where resource allocation or resource selection cannot be performed in scheduled resource allocation or vehicle autonomous resource selection mode. In this case, the vehicle may perform sidelink communication through a preconfigured resource pool.

Currently, in order to implement autonomous vehicles, many companies and developers are working to enable the vehicle to perform all tasks on its own in the same way that humans perform while driving the vehicle. These tasks are largely divided into a perception stage where the environment surrounding the vehicle is recognized through various sensors, a decision-making stage where the various information recognized through the sensors are used to determine how to control the vehicle, and the determined It can be divided into a control stage that controls the vehicle's operation according to decisions.

In the recognition stage, data from the surrounding environment is collected through radar, lidar, cameras, ultrasonic sensors, etc., and this is used to recognize vehicles, pedestrians, roads, lanes, obstacles, etc. . In the judgment stage, the driving situation is recognized based on the results recognized in the previous stage, the driving path is explored, and vehicle/pedestrian collision prevention and obstacle avoidance are judged to determine optimal driving conditions (path, speed, etc.). In the control stage, commands are generated to control the vehicle's drive system and steering system to control vehicle driving and movement based on recognition and judgment results. However, in order to implement more complete autonomous driving, rather than recognizing the external environment of the vehicle using only the sensors mounted on the vehicle, information received from other vehicles or road infrastructure through a wireless communication device mounted on the vehicle must be additionally recognized. It is desirable to use it in .

Various technologies related to wireless communication of such vehicles have been studied for a long time, and a representative technology among these technologies is the intelligent transport system (ITS). Recently, VANET (Vehicular Ad hoc Network) has been attracting attention as one of the technologies for realizing ITS. VANET is a network technology that provides V2V and V2I communication using wireless communication technology. VANET can be used to provide various services, such as delivering various information to the vehicle, such as the speed and location of surrounding vehicles and traffic information on the road on which it is driving, to enable drivers to drive safely and efficiently. In particular, it is important to deliver emergency messages needed by drivers, such as traffic accident information, secondary accident prevention, and efficient traffic flow management.

In order to deliver various information to all drivers using VANET, a broadcast routing technique is used. Broadcast routing technique is the simplest method used to transmit information. When sending a specific message, the message is transmitted to all nearby vehicles regardless of the recipient's ID and whether or not the message was received. The vehicle also delivers the message to all vehicles on the network by retransmitting the message to all nearby vehicles. As such, the broadcast routing method is the simplest way to deliver information to all vehicles, but because it generates enormous network traffic, it causes a network congestion problem called a broadcast storm in urban areas with high vehicle density. Additionally, the broadcast routing method requires setting a TTL (Time to Live) to limit the message delivery range, but there is also the problem that the TTL cannot be set accurately because the message is delivered using a wireless network.

To solve this broadcast storm problem, research is being conducted on various methods such as probability-based, region-based, and clustering-based algorithms. However, in the case of probability-based algorithms, vehicles for retransmission are selected probabilistically, so in the worst case, retransmission may occur in many vehicles or no retransmission may occur. Additionally, in the case of clustering-based algorithms, frequent retransmissions may occur if the cluster size is not large enough.

The following application technologies are being researched to satisfy the previously mentioned VANET security requirements. Each vehicle in the vehicular network has a built-in, immutable tamper-proof device (TPD). The TPD contains a vehicle's unique electronic number and secret information about the vehicle user is stored. Each vehicle performs user authentication through TPD. Digital Signature is a message authentication technique used to independently authenticate a message and provide a non-repudiation function for the user who sent the message. Each message contains a signature signed with the user's private key, and the recipient of the message verifies the signed value using the user's public key to confirm that the message was sent from a legitimate user.

In addition, IEEE (institute of electrical and electronics Engineers) 1609.2 is a standard related to WAVE (wireless access in vehicular environments), a standard for wireless communication in automotive environments, and is a security standard that vehicles must comply with when communicating wirelessly with other vehicles or external systems. is researching. If wireless communication traffic in vehicles rapidly increases in the future, the number of attacks such as eavesdropping, spoofing, and packet reuse that occur in general network environments will also increase, which will clearly have a very negative impact on vehicle safety. do. Therefore, IEEE 1609.2 standardizes the VANET security structure based on PKI (Public Key Infrastructure). VPK (Vehicular PKI) is a technology that applies Internet-based PKI to vehicles, and TPD includes a certificate provided by a public authority. Vehicles use certificates granted by public authorities to authenticate themselves and each other in vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications. However, because vehicles move at high speed in the PKI structure, it is difficult for vehicles to respond quickly in services that require rapid response, such as vehicle emergency messages and traffic status messages, due to the procedure for verifying the validity of the certificate of the vehicle sending the message. Anonymous keys are used to protect the privacy of vehicles using the network in a VANET environment, and the purpose of VANET is to prevent personal information leakage through anonymous keys.

As described above, various methods are being studied to quickly transmit event messages that can occur in various situations in a VANET environment to other vehicles or infrastructure while maintaining high security. However, in general, in order to maintain high security, complex encryption algorithms and/or various authentication procedures to verify integrity must be additionally performed, and this requires rapid data processing for the safe operation of devices that move at high speeds such as vehicles. It still acts as an obstacle to sending and receiving. Therefore, the following will describe embodiments for quickly transmitting data generated in a vehicle in which an event occurs to another vehicle while maintaining high security. First, in Figure 5, messages and related procedures required for a vehicle performing autonomous driving services are described.

(1) RSU unit encryption

Figure 5 shows an example of an autonomous driving service establishment procedure through a road side unit (RSU) according to an embodiment. The vehicle 210 that receives the autonomous driving service is, for example, the vehicle 211, vehicle 212, vehicle 213, vehicle 215, or vehicle 217 in FIG. 2 . The same reference numerals may be used for corresponding descriptions.

Referring to FIG. 5, in operation S501, the RSU controller 240 may transmit a request message for requesting security-related information to the certification authority server 560. The certification authority server 560 is an organization that manages or supervises a plurality of RSUs, and can generate and manage keys and certificates for each RSU. Additionally, the certification authority server 560 may issue a certificate for the vehicle or manage the issued certificate. The RSU controller 240 may request an encryption key/decryption key to be used within the coverage of each RSU from the certification authority server 560.

In operation S503, the certification authority server 560 may transmit a response message containing security-related information. The certification authority server 560 may generate security-related information for the RSU controller 240 in response to the request message. According to one embodiment, the security-related information may include encryption-related information to be applied to messages between the RSU and the vehicle. For example, the security-related information may include at least one of the encryption method, encryption version (which may be a version of the encryption algorithm), and key to be used (e.g., symmetric key, or public key). there is.

In operation S505, the RSU controller 240 may provide a configuration message including an RSU ID and security-related information to each RSU (eg, RSU 230). RSU controller 240 may be connected to one or more RSUs. According to one embodiment, the RSU controller 240 may configure security-related information required for individual RSUs of the one or more RSUs based on security-related information obtained from the certification authority server 560. RSU controller 240 may assign an encryption/decryption key to be used to each RSU. For example, RSU controller 240 may configure security-related information to be used in RSU 230. According to one embodiment, the RSU controller 240 may assign RSU IDs to the one or more RSUs. The setup message may include information about the RSU ID assigned to the corresponding RSU.

In operation S507, RSU 230 may transmit a broadcast message to vehicle 210. The RSU 230 may generate a broadcast message based on the security-related information and the RSU ID. RSU 230 may transmit a broadcast message to vehicles (eg, vehicle 210) within the coverage of RSU 230. Vehicle 210 can receive a broadcast message. For example, the broadcast message may have a message format as shown in the table below.

Field Description Note Message Type Broadcast Indicates that this is a broadcast message transmitted through R2V communication. RSU ID ID of RSU sending broadcast message Serving RSU ID RSU location information Location information of RSU Neighbor RSU's information List information of adjacent RSUs Encryption Policy Password policy information Encryption scheme symmetric-key schemeasymmetric-key scheme Information indicating whether the applied encryption method is a symmetric key method or an asymmetric key method Encryption algorithm version Encryption algorithm version Information Information indicating the encryption version Encryption Key/Decryption Key Encryption Key information/Decryption Key information Indicates key information used according to the applied encryption method
(For example, when the asymmetric key method is used, the public key is used for encryption or decryption, and when the symmetric key method is used, the symmetric key is used for encryption/decryption. Key information Key issuance date, key validity date, certification authority information, key version information

The symmetric key method refers to an algorithm in which the same key is used for encryption and decryption. One symmetric key can be used for both encryption and decryption. For example, as an algorithm for the symmetric key method, data encryption standard (DES), advanced encryption standard (AES), and SEED may be used. The asymmetric key method refers to an algorithm that performs encryption and/or decryption using a public key and a private key. For example, a public key may be used for encryption, but a private key may be used for decryption. In another example, a private key may be used for encryption, but a public key may be used for decryption. For example, RSA (Rivest, Shamir and Adleman) and ECC (elliptic curve cryptosystem) may be used as algorithms for the symmetric key method.

According to one embodiment, the vehicle 210 may identify the serving RSU, that is, the RSU 230, corresponding to the coverage into which the vehicle 210 has entered by receiving a broadcast message. Vehicle 210 may identify the encryption method in RSU 230 based on the broadcast message. For example, vehicle 210 can identify the encryption method in RSU 230. For example, vehicle 210 may decrypt a message encrypted by the public key or symmetric key of RSU 230. Meanwhile, the broadcast message illustrated in Table 1 is illustrative, and embodiments of the present disclosure are not limited thereto. If the encryption method to be used for communication between the vehicle 210 and the RSU 230 is predetermined in the communication standard, at least one of the elements of the broadcast message (e.g., encryption scheme) may be omitted. .

In operation S509, vehicle 210 may transmit a service request message to RSU 230. The vehicle 210 entering the RSU 230 may initiate an autonomous driving service after receiving a broadcast message. The vehicle 210 may generate a service request message to initiate an autonomous driving service. For example, the service request message may have a message format as shown in the table below.

Field Description Note Service Request ID Service Request ID Information to identify the autonomous driving service requested by the vehicle (to distinguish it from autonomous driving service requests received from other vehicles) Vehicle ID Vehicle Identifier Unique information assigned to identify vehicles (VIN, subscriber identification module (SIM), vehicle international mobile subscriber identity (IMSI), etc.) // may be assigned by the vehicle manufacturer or wireless carrier User ID User Identifier User ID that requested self-driving service (user ID that signed up for self-driving service) Departure location Autonomous driving service starting point Autonomous driving start location (location information of vehicle, electronic devices) Destination location Autonomous driving service end point (destination) Autonomous driving end location (destination information entered by the user) Serving RSU ID Serving RSU ID RSU ID of the coverage where the vehicle is currently located Map data version map data version Map data version information currently stored in the vehicle Autonomous driving software version Autonomous driving software version Autonomous driving software version information currently stored in the vehicle

Meanwhile, the service request message illustrated in Table 2 is illustrative, and embodiments of the present disclosure are not limited thereto. According to one embodiment, the service request message may further include additional information (eg, autonomous driving service level, vehicle capability). According to another embodiment, at least one of the elements of the service request message (eg, autonomous driving service start point) may be omitted.

In operation S511, the RSU 230 may transmit a service request message to the service provider server 550.

In operation S513, the service provider server 550 may confirm subscription information. The service provider server 550 can identify whether the vehicle 210 has subscribed to the autonomous driving service by checking the user ID ('User ID') and 'Vehicle ID' of the service request message. The service provider server 550 may store the service user's information when the vehicle 210 subscribes to the autonomous driving service.

In operation S515, the service provider server 550 may transmit a service response message to the RSU 230. The service provider server 550 may generate driving plan information for the vehicle 210 based on the service request message for the vehicle 210 received from the RSU 230.

According to one embodiment, the service provider server 550 may obtain a list of one or more RSUs adjacent to or located on the expected route based on driving plan information. For example, the list may include at least one of RSU IDs assigned by the RSU controller 240. Each time the vehicle 210 enters a new RSU along the route, the vehicle 210 can identify that it has reached the RSU in the driving plan information through the RSU ID of the broadcast message of the new RSU.

According to one embodiment, the service provider server 550 may generate encryption information for each RSU in the list. In order to collect and process information generated from an area expected to pass through, i.e., an RSU, the vehicle 210 needs to know pre-encryption information about the RSU. Accordingly, the service provider server 550 may generate encryption information for each RSU about the expected path of the vehicle 210 and include the generated encryption information in the service response message. For example, the service response message may have a message format as shown in the table below.

Field Description Note Service request response Service Request ID Service request message ID corresponding to response Route plan information Start Point, Destination Point,Global Path Planning information(Route Number, Cost vales for each calculated route) Route plan information (hereinafter referred to as driving plan information) calculated from the starting point to the destination, and the cost value for each of the plurality of routes calculated from the starting point to the destination. Neighbor RSU List RSU 12, RSU 13, RSU 34, RSU 35 etc. RSU List information existing on the calculated path (e.g., list of RSU IDs assigned by the RSU controller 240) Pre-EncryptionKey
RSU 12: 04 CE D7 61 49 49 FD;
RSU 13: 11 70 4E 49 16 61 FC;
RSU 34: FA 7F BA 6F 0C 05 53;
RSU 35: 1B 86 BC A3 C5 BC D8. Etc. N pre-encryption keys assigned to each RSU on the path
(where N is an integer greater than or equal to 1)

In operation S517, the RSU 230 may transmit a service response message to the vehicle 210. The RSU 230 may transmit the service response message received from the service provider server 550 to the vehicle 210.

In operation S519, the vehicle 210 may perform an autonomous driving service. The vehicle 210 may perform autonomous driving service based on the service response message. The vehicle 210 may perform an autonomous driving service based on the expected route of the driving plan information. The vehicle 210 may move along each RSU existing on the route.

According to one embodiment, a sender transmitting a message within the coverage of an RSU may transmit the message based on the public key or symmetric key of the RSU. For example, the RSU 230 may encrypt a message (e.g., a service response message in operation S517 or an event message in operation S711 of FIG. 7) based on the public key or symmetric key of the RSU. The receiver cannot decrypt the message without the symmetric key or the private key corresponding to the RSU's public key. For example, a vehicle that does not have a private key corresponding to the RSU's public key or a vehicle that does not have a symmetric key cannot decrypt the message.

According to one embodiment, messages transmitted from a vehicle may be encrypted based on the vehicle's private key or symmetric key. When a symmetric key algorithm is used, the sender can transmit a message (eg, an event message in operation S701 of FIG. 7) using the symmetric key of the RSU. The recipient may obtain the symmetric key through a broadcast message in operation S501 or a service response message in operation S515. The recipient can decode the message. Meanwhile, when an asymmetric key algorithm is used, the private key of the vehicle and the public key of the RSU serving the vehicle may be grouped for the asymmetric key algorithm. Each vehicle within an RSU may be assigned a private key, and the RSU may be assigned a public key. Each private key and public key can be used for encryption/decryption or decryption/encryption, respectively. The sender may transmit a message (eg, an event message in operation S701 of FIG. 7) using the private key corresponding to the public key of the RSU. The recipient must know the public key of the RSU to decrypt the message. If the recipient is a vehicle that knows the public key of the RSU, the recipient can decrypt the event message even if it is in the coverage of an RSU that is different from the serving RSU of the vehicle that sent the event message. To this end, the service response message for autonomous driving can provide encryption information (e.g., pre-encryption key) about the RSU on the driving path to the vehicle.

In FIG. 5, a situation in which a broadcast message is received and a service request message is transmitted is described, but embodiments of the present disclosure are not limited to this. Each time the vehicle 210 newly enters the coverage of the RSU, it does not transmit a service request message. The vehicle 210 may transmit a service request message through the serving RSU periodically or according to the occurrence of a specific event. That is, when the vehicle 210 enters another RSU, if the vehicle 210 already has driving plan information, the service request message may not be transmitted after receiving the broadcast message.

In FIG. 5, for an autonomous driving service, an example of vehicle 210 entering a new RSU and identifying RSUs on the expected path through a service provider server is described. The autonomous driving service can be used to provide adaptive driving information by detecting events in advance at an autonomous driving server (eg, service provider server 550) instead of manually setting a route. That is, even if an unexpected event occurs, the autonomous driving server can provide a changed driving route to the vehicle by collecting and analyzing information about the event. Hereinafter, in Figure 6, a situation in which an event occurs during driving is described.

(2) Event message

Figure 6 shows an example of an event-based autonomous driving service according to an embodiment.

Referring to FIG. 6, vehicles 611, 612, 613, 614, 621, 622, 623, 624 and RSUs 631, 633, in a traffic environment with a specific driving direction (e.g., highway or automobile lane) 635) is an example. Vehicles 611, 612, 613, 614, 621, 622, 623, and 624 illustrate vehicles 211, 212, and 213 in FIG. 2 or vehicle 210 in FIG. 5. The description of the vehicle depicted in FIGS. 2 to 5 may be applied to the vehicles 611, 612, 613, 614, 621, 622, 623, and 624. The RSUs 631, 633, and 635 exemplify the RSUs 231, 233, and 235 of FIG. 2 or the RSU 230 of FIG. 5. The description of the RSU described in FIGS. 2 to 5 may be applied to the RSUs 631, 633, and 635.

The vehicle can move depending on the direction of travel. The driving direction may be determined depending on the lane in which the vehicle is traveling. For example, vehicle 611, vehicle 612, vehicle 613, and vehicle 614 may be traveling in the upper lane of two lanes. The driving direction of the upper lane may be from left to right. Vehicle 621, vehicle 622, vehicle 623, and vehicle 624 may be traveling in the lower lane of the two lanes. The driving direction of the lower lane may be from right to left.

RSU can provide wireless coverage to support vehicle communications (e.g., V2I). Communication can be performed with a vehicle entering the wireless coverage area. For example, the RSU 631 may communicate with the vehicle 614 and vehicle 621 within the coverage 651 of the RSU 631. RSU 633 may communicate with vehicle 612, vehicle 613, vehicle 622, and vehicle 623 within coverage 653 of RSU 633. The RSU 635 allows the vehicle 611 and the vehicle 624 within the coverage 655 of the RSU 635 to communicate.

Each RSU may be connected to the RSU controller 240 via the Internet 609. Each RSU may be connected to the RSU controller 240 through a wired network or may be connected to the RSU controller 240 through a backhaul interface (or fronthaul interface). Additionally, each RSU may be connected to the certification authority server 560 via the Internet 609. The RSU may be connected to the certification authority server 560 through the RSU controller 240, or may be directly connected to the certification authority server 560. The certification authority server 560 can authenticate and manage RSUs and vehicles.

Let us assume a situation where an event occurs in the vehicle 612 within the coverage of the RSU 633. A situation in which normal driving of the vehicle 612 is difficult may be detected due to the vehicle 612 hitting an unexpected obstacle or a functional defect of the vehicle 612. Vehicle 612 may report an event of vehicle 612 to another vehicle (e.g., vehicle 613, vehicle 622, or vehicle 623) or an RSU (e.g., RSU 633). Vehicle 612 may broadcast an event message containing information related to the event.

Event messages according to embodiments of the present disclosure may include various information in order to operate autonomous driving services more accurately and efficiently. Below, elements included in the event message are exemplified. Not all of the elements described below must be included in the event message, and in some embodiments, at least some of the elements described below may be included in the event message.

According to one embodiment, the event message may include vehicle information. Vehicle information may include information indicating the vehicle that generated the event message. For example, vehicle information may include vehicle ID. Additionally, for example, vehicle information is information about the vehicle itself and may include information about the vehicle type (eg, vehicle model, brand), vehicle year, or mileage.

According to one embodiment, the event message may include RSU information. For example, the RSU information may include identification information (eg, serving RSU ID) in the serving RSU of the vehicle in which the event occurred (hereinafter referred to as source vehicle). Additionally, for example, the RSU information may include driving information of the vehicle in which the event occurred or identification information (eg, RSU ID list) of RSUs according to the driving path.

According to one embodiment, the event message may include location information. For example, location information may include information about where an event occurred. Additionally, for example, the location information may include information about the current location of the source vehicle. Additionally, for example, the location information may include information about the location where the event message was generated. Location information may point to precise location coordinates. Additionally, as an additional embodiment, the location information may further include information about whether the event occurrence point is in the middle of the road, the entrance or exit of the exclusive road, or which lane it is in.

According to one embodiment, the event message may include event-related data. Event-related data may refer to data collected from the vehicle at the time the event occurs. Event-related data may refer to data collected from sensors or vehicles over a certain period of time. The certain section may be determined based on the time of event occurrence. For example, the certain section may be set from a specific time (e.g., 5 minutes) before the event occurrence to a specific time (e.g., 1 minute) after the event occurrence. . For example, event-related data includes image data, impact data, steering data, speed data, acceleration data, braking data, location data, and sensor data (e.g., LiDAR (light detection and ranging). ) It may include at least one of a sensor and RADAR (radio detection and ranging) sensor data.

According to one embodiment, the event message may include priority information. Priority information may be information indicating the severity of an event that has occurred. For example, '1' in priority information may indicate that a collision or fire occurs in a vehicle. '2' in the priority information may indicate a vehicle's own failure. '3' in priority information may indicate the presence of an object on the road. '4' in the priority information may mean that the previously stored map data and the current road information are different. A higher priority information value means lower priority.

According to one embodiment, the event message may include event type information. Depending on the type of event that occurred in the vehicle, such as priority information, the service provider for autonomous driving service can provide adaptive route settings or adaptive notifications. For example, in the case of a temporary defect of the vehicle (e.g. detection of a foreign object, display defect, media application termination, buffering of control commands, side mirror malfunction) or if it does not affect other vehicles, the service provider may only operate at a certain distance. You may not change the driving information for your existing vehicle. Additionally, for example, when the vehicle is discharged or runs out of fuel, the service provider can calculate the normalization time and reset the driving information based on the normalization time. To this end, a plurality of types of vehicle events may be defined in advance for each stage, and event type information may indicate at least one of the plurality of types.

According to one embodiment, the event message may include driving direction information. The driving direction information may indicate the driving direction of the vehicle. The road may be divided into a first lane and a second lane based on the direction in which the vehicle travels. Based on the driver of a specific vehicle, the first lane has a driving direction toward the driver, and the second lane has a driving direction toward the driver. For example, when the vehicle moves along the first lane, the driving direction information may indicate '1', and when the vehicle moves along the second lane, the driving direction information may indicate '0'. For example, since the vehicle 612 is driving on the first lane, the vehicle 612 may transmit an event message including driving direction information indicating '1'. As another example, since the vehicle 621 is driving on the second lane, the vehicle 621 may transmit an event message including driving direction information indicating '0'. If the driving direction of the source vehicle and the driving direction of the receiving vehicle are different, the driving information of the receiving vehicle does not need to be changed based on the event. Therefore, in order to improve the efficiency of autonomous driving services through event messages, the driving direction information may be included in the event message.

According to one embodiment, the event message may further include lane information. Similar to the driving direction information, an event of a vehicle located in the first lane may have less impact on a vehicle located in the fourth lane. The service provider can provide adaptive routing for each lane. To this end, the source vehicle can include lane information in the event message.

According to one embodiment, the event message may include information about the time the event message was created (hereinafter, creation time information). Event messages may be provided via links between vehicles and/or vehicles and RSUs. In other words, since the event message is delivered through a multi-hop method, a situation may occur in which the event message is received after sufficient time has elapsed after the event occurs. In order to identify when an event occurs in a vehicle that has received an event message, the generation time information may be included in the event message.

According to one embodiment, the event message may include transmission method information. It may be provided from the RSU back to other vehicles via a link between the vehicle and the vehicle and/or the vehicle and the RSU. Therefore, in order for the vehicle or RSU receiving the event message to recognize the transmission method of the currently received event message, transmission method information may be included in the event message. Transmission method information may indicate whether the event message was transmitted through a V2V method or a V2R (or R2V) method.

According to one embodiment, the event message may include vehicle maneuver information. Vehicle operation information may refer to information about the vehicle itself when an event occurs. For example, vehicle operation information may include information about the state of the vehicle according to the occurrence of an event, the vehicle's wheels, and whether the door is open or closed.

According to one embodiment, the event message may include driver behavior information. Driver behavior information may refer to information about the driver's vehicle operation when an event occurs. Driver behavior information may mean information that the autonomous driving mode is released and manually manipulated by the user. For example, driver behavior information may include information about braking, steering wheel operation, starting, etc. when an event occurs.

For example, a message transmitted from the vehicle 612 may have a message format as shown in the table below.

Field Description Note Source Vehicle Information indicating the vehicle that generated the event message Source Vehicle: True
Other vehicles: False Vehicle ID Vehicle Identifier assigned to vehicle Message Type Event message Indicates Message Type Location Information Location information where event message was generated Event-related data Image data, impact data, steering data, speed data, acceleration data, braking data, location data Information obtained related to the event Generated Time Message creation time To determine whether the message validity period has expired Serving RSU Information Serving RSU ID Serving RSU ID of the coverage where the vehicle is located Driving direction Information indicating the direction of travel of the source vehicle where the event occurred "1" or "2" Transmission Information Transmission method information for sending event messages Information indicating whether the event message was transmitted via V2V communication method or V2R (R2V) communication method Priority Information “1” if the source vehicle crashes or catches fire “2” if the source vehicle breaks down
“3” for detecting the presence of dangerous objects on the road
“4” in case of obtaining road information that is different from the previously stored electronic map data Predetermined depending on the type of event that may occur on the road Vehicle maneuver information GPS, odometry information, a gyro information and kinematic information Vehicle operation information when the event occurred Driver behavior information When the event occurred, information which human driver operates to maneuver a vehicle. When an event occurs, driver behavior information (vehicle operation information) autonomous driving mode is canceled and information manually operated by the user

Meanwhile, the event message illustrated in Table 4 is illustrative, and embodiments of the present disclosure are not limited thereto. In order to lighten the event message, at least one of the elements of the event message (eg, transmission method information ('transmission information') of the event message) may be omitted.

Figure 7 shows an example of signaling between entities for setting a driving route based on an event according to an embodiment. In FIG. 7 , an example of resetting the driving route based on an event of the vehicle 612 in FIG. 6 is described.

Referring to FIG. 7, in operation S701, the vehicle 612 may transmit an event message to the RSU 633. Vehicle 612 may detect the occurrence of an event of vehicle 612 . The vehicle 612 may generate the event message based on an event of the vehicle 612. Vehicle 612 may transmit the event message to RSU 633, which is the serving RSU of vehicle 612. The event message may be the event message described in FIG. 6. According to one embodiment, the event message includes vehicle information, RSU information, location information, event-related data, priority information, event type information, driving direction information, lane information, generation time information, transmission method information, vehicle operation information, Alternatively, it may include at least one of driver behavior information.

The vehicle 612 may transmit the event message not only to the serving RSU but also to other vehicles or other RSUs (700). In operation S703, the vehicle 612 may transmit an event message to another vehicle (hereinafter referred to as a receiving vehicle). In operation S705, the receiving vehicle (eg, vehicle 613, vehicle 622, or vehicle 623) may transmit an event message to another vehicle. In operation S707, the receiving vehicle may transmit an event message to another RSU.

When the RSU 633 receives an event message from the vehicle 612, it can perform integrity verification on the event message. When the RSU 633 receives an event message from the vehicle 612, it can decode the event message. Once integrity and decryption are completed, the RSU 633 may transmit the event message to another receiving vehicle (e.g., vehicle 613) or a neighboring RSU (e.g., RSU 635). In operation S711, the RSU 633 may transmit an event message to the receiving vehicle. In operation S713, the RSU 633 may transmit an event message to another RSU.

The RSU 633 may update autonomous driving data based on an event of the vehicle 612 (720). In operation S721, the RSU 633 may transmit an event message to the service provider server 550. Events in vehicle 612 may affect not only vehicle 612 but also other vehicles. Accordingly, the RSU 633 may transmit an event message to the service provider server 550 to reset the driving path of a vehicle using an autonomous driving service.

In operation S723, the service provider server 550 may transmit an update message to the RSU 633. The service provider server 550 may reset the driving path for each vehicle based on the event. If the driving route needs to be changed, the service provider server 550 may generate an update message containing reset driving route information.

According to one embodiment, the update message may include driving plan information. Driving plan information may mean a newly calculated driving path from the current point of the corresponding vehicle (e.g., vehicle 612 or vehicle 613) to the previous destination. Additionally, according to one embodiment, the update message may include a list of one or more RSUs existing on the calculated path. When the driving route changes, RSUs adjacent to or located on the driving route also change, so the update message may include a list of updated RSUs. Additionally, according to one embodiment, the update message may include encryption information. This is because the driving path has changed, so the RSU ID for the RSU adjacent to or located on the driving path changes. Meanwhile, encryption information about RSUs that are duplicated due to update may be omitted from the update message in order to make the update message lighter.

Field Description Note Route plan information Link ID, Node ID, route ID and cost value for each route ID related to planned route Route plan information calculated from the origin to the destination (hereinafter referred to as driving plan information) Neighbor RSU List Please refer to Table 3 RSU List information existing on the calculated path (e.g., list of RSU IDs assigned by the RSU controller 240) Pre-EncryptionKey Please refer to Table 3 N pre-encryption keys assigned to each RSU on the path
(where N is an integer greater than or equal to 1)

In operation S725, RSU 633 may transmit an update message to vehicle 613, vehicle 622, and vehicle 623. The update message received from the service provider server 550 may include driving information for each vehicle within the coverage of the RSU 633, and the RSU 633 may identify driving information for the vehicle 612. The RSU 633 may transmit an update message containing driving information for the vehicle 612 to the vehicle 612 .

According to one embodiment, an event message transmitted from a vehicle (eg, vehicle 612 or vehicle 613) may be encrypted based on the vehicle's private key. The vehicle's private key and the public key of the RSU serving the vehicle (e.g., RSU 633) may be used for an asymmetric key algorithm. The sender may transmit a message (e.g., an event message in operation S701) using a symmetric key or a private key corresponding to the public key of the RSU. For example, the sender may be a vehicle. The recipient must know the symmetric key or the public key of the RSU to decrypt the message. If the recipient is a vehicle that knows the public key of the RSU (hereinafter referred to as the receiving vehicle), the receiving vehicle can decrypt the event message even if the recipient is in the coverage of an RSU different from the serving RSU of the vehicle that sent the event message. there is. To this end, the receiving vehicle may obtain and store encryption information (e.g., pre-encryption key) about the RSU on the driving path in advance through a service response message (e.g., the service response message in FIG. 5).

In FIG. 7 , only the operation of the serving RSU (e.g., RSU 633) of the vehicle in which the accident occurred (e.g., vehicle 612) is described, but embodiments of the present disclosure are not limited thereto. Driving information reset according to the event message must be shared with other RSUs (e.g., RSU 631 and RSU 635) and other vehicles (e.g., vehicle 614 and vehicle 621). The service provider server 550 may also transmit update messages to other vehicles through other RSUs.

Although not shown in FIG. 7, the vehicle 612 in which an accident occurred may terminate autonomous driving. The vehicle 612 may transmit a service end message to the service provider server 550 through the RSU 633. Thereafter, the service provider server 550 may discard the information about the vehicle 612 and the information about the user of the vehicle 612.

(3) Driving route and RSU

Figures 8A to 8C illustrate an example of efficiently processing an event message when setting a driving route based on an event, according to an embodiment. To explain the driving environment related to the event, the driving environment in FIG. 6 is illustrated. The same reference numerals may be used for the same description.

Referring to FIG. 8A, vehicle 611, vehicle 612, vehicle 613, and vehicle 614 may be traveling in the first lane. The driving direction of the first lane may be from left to right. The first lane may be on the left based on the driver's driving direction. Vehicle 621, vehicle 622, vehicle 623, and vehicle 624 may be traveling in the second lane. The driving direction of the second lane may be from right to left. The driving direction of the second lane may be opposite to the driving direction of the first lane.

A vehicle that is not affected by the event of a specific vehicle does not need to be aware of the event of the specific vehicle. Here, not being affected by an event means that the driving plan of the vehicle does not change due to the event. Hereinafter, for convenience of explanation, a vehicle that is not affected by the event of the specific vehicle may be referred to as an independent vehicle for the event. Conversely, a vehicle affected by the event of the specific awning may be referred to as a dependent vehicle for the event.

Vehicles 810 whose driving directions of the source vehicle and the receiving vehicle are different may correspond to independent vehicles. The independent vehicle's driving information does not need to be changed based on the event. For example, when the driving direction of the vehicle 612 is in the first lane direction (e.g., left to right), the vehicle 621 and the vehicle 622 are in the second lane direction (e.g., right to left). ), vehicle 623, and vehicle 624 are not affected by the event. Additionally, vehicles 820 (e.g., vehicle 611) located ahead of the source vehicle (e.g., vehicle 612) may correspond to independent vehicles. Independent vehicles may not be affected by information about events. Since it is not common (almost non-existent) for a vehicle to suddenly reverse on an automobile road, the vehicle 611 ahead of the vehicle 612 based on the driving direction may be involved in an accident, combination, or failure of the vehicle 612. It may not be affected by events due to etc.

The impact due to the event can be identified depending on whether the driving plan information for the autonomous driving service is changed. If the expected driving path of a specific vehicle (e.g., vehicle 613) changes before and after the event occurs, the specific vehicle may be interpreted as being affected by the event. The specific vehicle may be a dependent vehicle for the event. Embodiments of the present disclosure propose a method for reducing unnecessary driving path updates when an event occurs in a vehicle, even if a vehicle unrelated to the event, that is, an independent vehicle, does not receive the event message, and even if it does receive the event message. .

To determine whether a vehicle is related to an event, the encryption method, RSU ID, and driving direction may be used.

According to one embodiment, the encryption method refers to encryption information (eg, public key or symmetric key of the used RSU) applied to an event message notifying the event. Additionally, according to one embodiment, the RSU ID may be used to identify whether a specific RSU is included in the RSU list included in the vehicle's driving path. Additionally, according to one embodiment, driving direction may be used to distinguish between dependent vehicles affected by the event and independent vehicles not affected by the event.

Referring to FIG. 8B, the vehicle's driving path may be related to RSUs. For example, a vehicle's driving path can be expressed by RSU IDs. The service response message (eg, the service response message in FIG. 5) may include a list of RSUs on the route of the driving plan information. The RSU list may include one or more RSU IDs. For example, the RSU list for a driving path for vehicle 612 may include an RSU ID for RSU 633 and an RSU ID for RSU 635. Vehicle 612 is currently located within the coverage of RSU 633, but may be expected to be located within coverage of RSU 635 in the direction of travel. Based on the driving direction of the vehicle in which the event occurred (i.e., the source vehicle), vehicles within the coverage 830 of the RSU located ahead of the vehicle may not be affected by the event. In other words, all vehicles within the coverage 830 of the RSU may be independent vehicles for the event.

According to one embodiment, an RSU may broadcast an event message received from an adjacent RSU to vehicles within the RSU. However, an RSU located in an area ahead of the vehicle (e.g., RSU 635) does not need to receive the event message and does not need to transmit the event message to other vehicles within the coverage 830. As an example of an implementation, , the RSU controller 240 or the serving RSU (e.g., RSU 633) may not deliver an event message to an RSU disposed in a position ahead of the vehicle, depending on the driving path of the source vehicle. In addition, one implementation For example, when an RSU receives an event message from a serving RSU, another RSU, or the RSU controller 240, it does not re-deliver the event message based on the location of the serving RSU and the vehicle's driving path (e.g., RSU list). It may not be possible.

According to one embodiment, the service provider may reset driving route information based on a vehicle event. However, the driving path information for vehicles (e.g., vehicle 611 and vehicle 624) of the RSU (e.g., RSU 635) located in an area ahead of the vehicle does not need to be updated. The service provider may not transmit the update message to the RSU. Accordingly, an update message such as operation S723 of FIG. 7 may not be transmitted to at least some RSUs. Since the RSU did not receive the update message, the vehicle (e.g., vehicle 611) within the RSU's coverage (e.g., coverage 820) cannot perform autonomous driving based on previously provided autonomous driving information. there is.

Referring to FIG. 8C, the driving direction of the vehicle may be divided into the same direction as the traveling direction of the event vehicle or a different direction from the traveling direction of the event vehicle. The vehicle that generated the event message may include information about the driving direction in the event message. Since the event message is delivered to other vehicles or RSUs through a multi-hop method, the receiving vehicle can know the driving direction of the vehicle in which the event occurred (i.e., the source vehicle).

Vehicle 611, vehicle 612, vehicle 613, and vehicle 614 may be traveling in the first lane. The driving direction of the first lane may be from left to right. Vehicle 621, vehicle 622, vehicle 623, and vehicle 624 may be traveling in the second lane. The driving direction of the second lane may be from right to left. The vehicle that received the event message may determine whether its vehicle is an independent vehicle or a dependent vehicle, based on the driving direction of the source vehicle. The vehicle that received the event message can be identified as an independent vehicle if its driving direction is the same as that of the source vehicle. If the vehicle receiving the event message has a driving direction different from that of the source vehicle, it can be identified as a dependent vehicle.

The event message may include driving direction information of the source vehicle (eg, vehicle 612). For example, the driving direction information of the vehicle 612 may indicate '1'. Vehicle 622 may receive an event message. Vehicle 622 may receive an event message from RSU 633 or vehicle 612. Since the driving direction information of the vehicle 622 is '0' and the driving direction information of the vehicle 612 is '1', the vehicle 622 can ignore the event message. Vehicle 622 may discard the event message. In this way, vehicle 621, vehicle 622, and vehicle 623, as dependent vehicles 840, may ignore the received event message. Meanwhile, since the RSU 635 is located ahead of the driving path of the vehicle 612, the vehicle 624 within the RSU 635 may not receive an event message for determining the driving direction.

Figure 9 shows the operation flow of an RSU for event message processing according to one embodiment.

Referring to Figure 9, at operation 901, the RSU may receive an event message. RSU can receive event messages from the vehicle. The event message may include information about an event that occurred in the vehicle or another vehicle. Additionally, as another example, the RSU may receive the event message from an adjacent RSU other than the vehicle. The event message may be the event message described in FIG. 6. According to one embodiment, the event message includes vehicle information, RSU information, location information, event-related data, priority information, event type information, driving direction information, lane information, generation time information, transmission method information, vehicle operation information, Alternatively, it may include at least one of driver behavior information.

According to one embodiment, the RSU may decode the event message. The RSU can identify whether the event message is encrypted based on encryption information for the RSU. Encryption information for the RSU may mean key information used to enable decryption within the coverage of the RSU. Encryption information for the RSU may be valid only within the coverage of the RSU. For example, the RSU may include key information (e.g., 'Encryption Key/Decryption Key' in Table 1) in a broadcast message (e.g., broadcast message in Table 1). In addition, for example, when an RSU requests autonomous driving service, the RSU includes encryption information (e.g., pre-encryption key in Table 3) for the RSU in a service response message (e.g., the service response message in FIG. 5). Can be included. Encryption information may be RSU-specific.

According to one embodiment, the RSU may perform an integrity check of the event message. The RSU can discard the event message through an integrity check, or obtain information in the event message through decoding the event message. For example, if the integrity check passes, the RSU can identify the priority for the event based on the priority information in the event message. If the RSU has a priority higher than the specified value, it can deliver the event message to the emergency center. Here, the event message may be encrypted based on the encryption information of the RSU.

Although not shown in FIG. 9, the RSU may transmit the received event message to another RSU or another vehicle. According to one embodiment, an RSU may transmit an event message to another RSU based on driving direction information. In this example, the RSU 633 in FIG. 8B may deliver an event message to the RSU 631. However, the RSU 633 may not deliver the event message to the RSU 635. This is because the RSU 635 is deployed in the preceding area based on the driving direction of the source vehicle where the event occurred, that is, the vehicle 612. Additionally, according to one embodiment, the RSU may generate an event message based on encryption information about the RSU. The RSU can generate other event messages containing information received from the vehicle. The RSU can enable only other vehicles within the coverage of the RSU to receive the other event message by encrypting the other event message using encryption information for the RSU.

At operation 903, the RSU may transmit event information to the service provider. In response to vehicle events, the driving plan information of the autonomous driving service being provided needs to be changed. The RSU can transmit event information to the service provider to update the vehicle's driving plan information.

At operation 905, the RSU may receive updated autonomous driving information from the service provider. The service provider may identify vehicles located behind the source vehicle based on receiving the event information. Based on the source vehicle (e.g., vehicle 612 in FIGS. 8A to 8C), receiving vehicles (e.g., vehicle 613 and vehicle 614) located behind the source vehicle have an influence on the accident of the source vehicle. You can receive it. That is, receiving vehicles located behind the source vehicle (eg, vehicle 613 and vehicle 614) may be dependent vehicles for the event of the source vehicle.

The service provider may change autonomous driving information (eg, driving plan information) for the dependent vehicle. The service provider can obtain autonomous driving information reflecting events for the source vehicle. The RSU may receive the autonomous driving information that has changed due to the occurrence of the event through an update message from the service provider. The service provider may transmit autonomous driving information about the dependent vehicle to the RSU within the coverage of the RSU.

In operation 907, the RSU may transmit encrypted autonomous driving information to each vehicle. The RSU can transmit an update message containing autonomous driving information to each vehicle. At this time, rather than transmitting autonomous driving information to all vehicles, the RSU may transmit updated autonomous driving information to the relevant vehicle in a unicast manner. This is because each vehicle has a different driving plan. According to one embodiment, the RSU may transmit autonomous driving information to each vehicle based on encryption information about the RSU.

Figure 10 shows a vehicle operation flow for event message processing according to one embodiment. The vehicle may be referred to as a receiving vehicle. As an example, the receiving vehicle is a vehicle different from the vehicle 612 in the driving environment of FIGS. 6 to 8C.

Referring to Figure 10, in operation 1001, the receiving vehicle may receive an event message. The receiving vehicle may receive an event message from a vehicle in which an event occurred (hereinafter referred to as source vehicle) or an RSU. The event message may include information about an event that occurred in the source vehicle. The event message may be the event message described in FIG. 6. According to one embodiment, the event message includes vehicle information, RSU information, location information, event-related data, priority information, event type information, driving direction information, lane information, generation time information, transmission method information, vehicle operation information, Alternatively, it may include at least one of driver behavior information.

According to one embodiment, the receiving vehicle can decode the event message. The receiving vehicle can identify whether the event message is encrypted based on encryption information about the RSU. Encryption information for the RSU may mean key information used to enable decryption within the coverage of the RSU. Encryption information may be RSU-specific.

According to one embodiment, the receiving vehicle uses key information (e.g., 'Encryption Key/Decryption Key' in Table 1) included in the broadcast message (e.g., the broadcast message in FIG. 5) to provide an RSU for coverage where the receiving vehicle is located. You can know the encryption information about . In addition, the receiving vehicle uses encryption information (pre-encryption key in Table 3) included in the service response message (e.g., the service response message in FIG. 5) to encrypt the RSUs in the neighboring RSU list and for each RSU. Encryption information can be found. When an event occurs, the vehicle may transmit an event message based on encryption information about the vehicle's RSU. In other words, even if the receiving vehicle receives an event message from another vehicle, if the driving path of the receiving vehicle includes the RSU of the other vehicle, the receiving vehicle can know the encryption information about the RSU in advance. The receiving vehicle can decrypt the event message through a public key algorithm or a symmetric key algorithm. The receiving vehicle may obtain information about the serving RSU serving the source vehicle from the event message. The receiving vehicle may obtain information about the driving direction of the source vehicle from the event message.

At operation 1003, the receiving vehicle may identify whether the RSU associated with the event is included in the driving list of the current vehicle (i.e., the receiving vehicle). The receiving vehicle can identify the RSU related to the event from the information in the event message (e.g., serving RSU ID in Table 4). The receiving vehicle may identify one or more RSUs in the driving list of the receiving vehicle. The driving list (e.g., Neighbor RSU List in Table 3) may refer to a set of RSU IDs for RSU(s) located on the expected route for autonomous driving service. If it is not an RSU that the receiving vehicle plans to visit, the receiving vehicle determines whether the RSU associated with the event is related to the receiving vehicle, since the receiving vehicle is not necessarily required to have an event in the RSU. can do. If an RSU related to an event is included in the driving list of the receiving vehicle, the receiving vehicle may perform operation 1005. If the RSU related to the event is not included in the driving list of the receiving vehicle, the receiving vehicle may perform operation 1009.

At operation 1005, the receiving vehicle may identify whether the direction of travel of the vehicle associated with the event matches the direction of travel of the current vehicle. The receiving vehicle can identify the driving direction information of the source vehicle from the information in the event message (e.g., driving direction in Table 4). The receiving vehicle can identify the current driving direction of the vehicle. According to one embodiment, the traveling direction may be determined as a relative value. For example, a road may consist of two lanes. The two lanes may include a first lane providing a driving direction in the first direction and a second lane providing a traveling direction in the second direction. The driving direction may be relatively determined by a reference to an RSU (e.g., RSU 230), an RSU controller (e.g., RSU controller 240), or a service provider (e.g., service provider server 550). As an example, 1-bit may be used to indicate direction. The bit value may be set to '1' for the first direction and '0' for the second direction. According to another embodiment, the driving direction may be determined in an absolute direction through the movement of vehicle sensors.

If the RSU associated with the event is a vehicle associated with the event, that is, the driving direction of the source vehicle matches the driving direction of the receiving vehicle, the receiving vehicle may perform operation 1007. If the RSU associated with the event indicates that the driving direction of the vehicle associated with the event does not match the driving direction of the receiving vehicle, the receiving vehicle may perform operation 1009.

In operation 1007, the receiving vehicle may perform driving according to the event message. The receiving vehicle may drive based on other information (e.g., event occurrence location, event type) in the event message. For example, the receiving vehicle may perform an operation to prevent an accident of the receiving vehicle based on the event message. Additionally, the receiving vehicle may determine that delivery of the event message is necessary. The receiving vehicle may transmit the encrypted event message to the receiving vehicle's RSU or another vehicle.

At operation 1009, the receiving vehicle may ignore the event message. The receiving vehicle may determine that the event indicated in the event message does not directly affect the receiving vehicle. The receiving vehicle may identify that an event of a source vehicle having a driving direction different from that of the receiving vehicle does not affect driving of the receiving vehicle. The receiving vehicle does not need to change the driving settings by decoding or processing the event message for the source vehicle if there is no source vehicle in the driving path of the receiving vehicle.

In Figure 10, an example of identifying whether the receiving vehicle is an independent vehicle or a dependent vehicle for an event of the source vehicle is described, based on the driving path in operation 1003 and the driving direction in operation 1005. However, the decision sequence or judgment operations in FIG. 10 are only examples for identifying whether the receiving vehicle is an independent vehicle or a dependent vehicle, and other embodiments of the present disclosure are not limited to the operations in FIG. 10 . According to another embodiment, the receiving vehicle may not perform operation 1003 and may only perform operation 1005. According to another embodiment, the receiving vehicle may perform operation 1005 before operation 1003.

Figure 11 shows the operation flow of an event-related vehicle according to an embodiment. The vehicle may be referred to as a source vehicle. As an example, the source vehicle illustrates vehicle 612 in the driving environment of FIGS. 6-8C.

At operation 1101, the source vehicle may detect the occurrence of an event. The source vehicle may detect the occurrence of an event such as a collision with another vehicle, a fire in the source vehicle, or a breakdown of the source vehicle. The source vehicle may independently perform vehicle control based on the detected event. The source vehicle may determine that generation of an event message is necessary, based on the type of event. The source vehicle may decide to generate an event message if the event is not resolved within a specified time or if it is required to notify other entities of the occurrence of the event.

In operation 1103, the source vehicle may generate event information including serving RSU identification information and driving direction. The source vehicle may generate event information including the ID of the RSU currently serving the source vehicle, that is, the serving RSU. The source vehicle may include information indicating the driving direction of the source vehicle in the event information.

At operation 1105, the source vehicle may transmit an event message containing event information. The source vehicle may perform encryption to transmit the event message. The source vehicle may encrypt the event message based on encryption information for the serving RSU (e.g., RSU 633). According to one embodiment, the source vehicle uses key information (e.g., 'Encryption Key/Decryption Key' in Table 1) included in the broadcast message (e.g., the broadcast message of FIG. 5) to provide an RSU for coverage where the source vehicle is located. You can know the encryption information about . Additionally, the source vehicle may transmit an encrypted event message to vehicles other than the source vehicle within the RSU (e.g., RSU 613, RSU 622, and RSU 623).

Figure 12 illustrates the operational flow of a service provider for resetting a driving route in response to an event according to one embodiment. The operation of the service provider may be performed by a service provider server (eg, service provider server 550).

Referring to Figure 12, at operation 1201, the service provider server may receive an event message from the RSU. The service provider server may identify the source vehicle based on the event message. The service provider server may identify the RSU ID of the source vehicle's RSU, that is, the serving RSU, based on the event message.

In operation 1203, the service provider server may update autonomous driving information according to the occurrence of an event. The service provider may identify a vehicle (hereinafter referred to as a dependent vehicle) whose driving path includes the serving RSU of the source vehicle where the event occurred. The service provider server may update autonomous driving information of the subordinate vehicle. For example, the service provider server may update autonomous driving information for each dependent vehicle. The service provider server may not update autonomous driving information for independent vehicles. In other words, the service provider server can update autonomous driving information for each dependent vehicle.

In operation 1205, the service provider may generate autonomous driving data. Autonomous driving data may include autonomous driving information for each dependent vehicle. The service provider can update autonomous driving data based on autonomous driving information for each dependent vehicle.

In operation 1207, the service provider may transmit autonomous driving data to each RSU. According to one embodiment, a service provider may transmit autonomous driving data to an RSU that services a vehicle that needs to be updated. For example, the service provider does not need to transmit updated autonomous driving data to an RSU that is ahead of the source vehicle where the accident occurred. Meanwhile, the service provider needs to transmit updated autonomous driving data to an RSU that is located before the source vehicle and serves a vehicle that will later pass the serving RSU.

Although not shown in FIG. 12, the service provider may perform a service subscription procedure for the vehicle before processing the event message. When a service request message is received from a vehicle, the service provider can check whether the vehicle is a service subscriber. If the vehicle is a service subscriber, the service provider may obtain identifier information (eg, vehicle ID, user ID), location information of the vehicle, and destination information from the service request message. A service provider may calculate driving plan information for the vehicle. The driving plan information may indicate a driving path from the starting location of the vehicle to the destination. The service provider may transmit a service response message including driving plan information and a list of RSU IDs existing on the route to the serving RSU. The service provider may continuously provide autonomous driving services through update messages until a service termination notification is received from the vehicle or the vehicle arrives at its destination. Thereafter, when the service provider receives a service termination notification from the vehicle or when the vehicle arrives at the destination, the service provider may discard information about the vehicle that requested service and information about the user of the vehicle.

FIG. 13A shows an example of components of a vehicle 210 according to one embodiment. Terms such as '... unit' and '... unit' used hereinafter refer to a unit that processes at least one function or operation, which can be implemented through hardware, software, or a combination of hardware and software. there is.

Referring to FIG. 13A, the vehicle 210 may include at least one transceiver 1310, at least one memory 1320, and at least one processor 1330. Hereinafter, components are described in the singular, but implementation of multiple components or subcomponents is not excluded.

The transceiver 1310 performs functions for transmitting and receiving signals through a wireless channel. For example, the transceiver 1310 performs a conversion function between a baseband signal and a bit stream according to the physical layer standard of the system. For example, when transmitting data, the transceiver 1310 generates complex symbols by encoding and modulating the transmission bit stream. Additionally, when receiving data, the transceiver 1310 restores the received bit stream by demodulating and decoding the baseband signal. Additionally, the transceiver 1310 upconverts the baseband signal into a radio frequency (RF) band signal and transmits it through an antenna, and downconverts the RF band signal received through the antenna into a baseband signal.

To this end, the transceiver 1310 may include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a digital to analog convertor (DAC), an analog to digital convertor (ADC), etc. Additionally, the transceiver 1310 may include multiple transmission and reception paths. Furthermore, the transceiver 1310 may include at least one antenna array composed of multiple antenna elements. In terms of hardware, the transceiver 1310 may be composed of a digital unit and an analog unit, and the analog unit may be divided into a number of sub-units according to operating power, operating frequency, etc. It can be configured.

The transceiver 1310 transmits and receives signals as described above. Accordingly, the transceiver 1310 may be referred to as a 'transmitter', 'receiver', or 'transceiver'. Additionally, in the following description, transmission and reception performed through a wireless channel, backhaul network, optical cable, Ethernet, and other wired paths are used to mean that the processing as described above is performed by the transceiver 1310. According to one embodiment, the transceiver 1310 may provide an interface for communicating with other nodes. That is, the transceiver 1310 transmits a bit string transmitted from the vehicle 210 to another node, for example, another vehicle, another RSU, or an external server (e.g., the service provider server 550, the certification authority server 560). It can be converted into a signal, and the physical signal received from the other node can be converted into a bit string.

The memory 1320 may store data such as basic programs, application programs, and setting information for operation of the vehicle 210. The memory 1320 may store various data used by at least one component (eg, the transceiver 1310 and the processor 1320). Data may include, for example, input data or output data for software and instructions related thereto. The memory 1320 may be comprised of volatile memory, non-volatile memory, or a combination of volatile memory and non-volatile memory.

Processor 1330 controls overall operations of vehicle 210. For example, the processor 1330 writes and reads data into the memory 1320. For example, the processor 1330 transmits and receives signals through the transceiver 1310. And the memory 1320 may provide stored data according to the request of the processor 1330. Although FIG. 13A shows one processor, embodiments of the present disclosure are not limited thereto. Vehicle 210 may include a plurality of processors to perform embodiments of the present disclosure. The processor 1330 may be referred to as a control unit or control means. Depending on embodiments, the processor 1330 may control the vehicle 210 to perform at least one operation or method according to embodiments of the present disclosure.

Figure 13B shows an example of components of RSU 230 according to one embodiment. Terms such as '... unit' and '... unit' used hereinafter refer to a unit that processes at least one function or operation, which can be implemented through hardware, software, or a combination of hardware and software. there is.

Referring to FIG. 13B, the RSU 230 includes an RF transceiver 1360, a backhaul transceiver 1365, a memory 1370, and a processor 1380.

The RF transceiver 1360 performs functions for transmitting and receiving signals through a wireless channel. For example, the RF transceiver 1360 upconverts the baseband signal into an RF band signal and transmits it through an antenna, and downconverts the RF band signal received through the antenna into a baseband signal. For example, the RF transceiver 1360 may include a transmit filter, receive filter, amplifier, mixer, oscillator, DAC, ADC, etc.

The RF transceiver 1360 may include multiple transmission and reception paths. Furthermore, the RF transceiver 1360 may include an antenna unit. The RF transceiver 1360 may include at least one antenna array comprised of multiple antenna elements. In terms of hardware, the RF transceiver 1360 may be composed of digital circuits and analog circuits (eg, radio frequency integrated circuit (RFIC)). Here, the digital circuit and analog circuit can be implemented in one package. Additionally, the RF transceiver 1360 may include multiple RF chains. The RF transceiver 1360 can perform beamforming. The RF transceiver 1360 may apply a beamforming weight to the signal to be transmitted and received in order to give directionality according to the settings of the processor 1380. According to one embodiment, the RF transceiver 1360 may include a radio frequency (RF) block (or RF unit).

According to one embodiment, the RF transceiver 1360 may transmit and receive signals on a radio access network. For example, the RF transceiver 1360 may transmit a downlink signal. Downlink signals include synchronization signal (SS), reference signal (RS) (e.g., cell-specific reference signal (CRS), demodulation (DM)-RS), system information (e.g., MIB, SIB, It may include remaining system information (RMSI), other system information (OSI), configuration message, control information, or downlink data. Additionally, for example, the RF transceiver 1360 may receive an uplink signal. Uplink signals include random access-related signals (e.g., random access preamble (RAP) (or Msg1 (message 1)), Msg3 (message 3)), reference signals (e.g., sounding reference signal (SRS), DM) -RS), or power headroom report (PHR), etc. Although only the RF transceiver 1360 is shown in FIG. 13B, according to another implementation example, the RSU 230 may include two or more RF transceivers.

The backhaul transceiver 1365 can transmit and receive signals. According to one embodiment, the backhaul transceiver 1365 may transmit and receive signals on the core network. For example, the backhaul transceiver 1365 communicates with an external server (service provider server 550, certification authority server 560) or external device (e.g., RSU controller 240) by connecting to the Internet through the core network. can be performed. Additionally, for example, the backhaul transceiver 1365 may communicate with other RSUs. Although only the backhaul transceiver 1365 is shown in FIG. 13B, according to another implementation example, the RSU 230 may include two or more backhaul transceivers.

The RF transceiver 1360 and the backhaul transceiver 1365 transmit and receive signals as described above. Accordingly, all or part of the RF transceiver 1360 and the backhaul transceiver 1365 may be referred to as a 'communication unit', a 'transmission unit', a 'reception unit', or a 'transceiver unit'. Additionally, in the following description, transmission and reception performed through a wireless channel are used to mean that the processing as described above is performed by the RF transceiver 1360. In the following description, transmission and reception performed through a wireless channel are used to mean that the processing as described above is performed by the RF transceiver 1360.

The memory 1370 stores data such as basic programs, application programs, and setting information for the operation of the RSU 230. Memory 1370 may be referred to as a storage unit. The memory 1370 may be comprised of volatile memory, non-volatile memory, or a combination of volatile memory and non-volatile memory. And, the memory 1370 provides stored data according to the request of the processor 1380.

Processor 1380 controls overall operations of RSU 230. The processor 1380 may be referred to as a control unit. For example, processor 1380 transmits and receives signals through RF transceiver 1360 or backhaul transceiver 1365. Additionally, the processor 1380 writes and reads data into the memory 1370. Additionally, the processor 1380 can perform protocol stack functions required by communication standards. Although only the processor 1380 is shown in FIG. 13B, according to another implementation example, the RSU 230 may include two or more processors. The processor 1380 is a set of instructions or code stored in the memory 1370, which is a storage space that stores instructions/code or instructions/code that are at least temporarily residing in the processor 1380, or the processor 1380 It may be part of the circuitry that constitutes. Additionally, the processor 1380 may include various modules for performing communication. The processor 1380 may control the RSU 230 to perform operations according to embodiments described later.

The configuration of the RSU 230 shown in FIG. 13B is only an example, and the example of the RSU performing the embodiments of the present disclosure is not limited to the configuration shown in FIG. 13B. In some embodiments, some configurations may be added, deleted, or changed.

Figure 14 is a block diagram showing the autonomous driving system of a vehicle. The vehicle in FIG. 14 may be referenced to vehicle 210 in FIG. 5 . The electronic devices 120 and 130 of FIG. 1 may include an autonomous driving system 1400.

The autonomous driving system 1400 of the vehicle according to FIG. 14 includes sensors 1403, an image preprocessor 1405, a deep learning network 1407, an artificial intelligence (AI) processor 1409, a vehicle control module 1411, It may be a deep learning network including a network interface 1413 and a communication unit 1415. In various embodiments, each element may be connected through various interfaces. For example, sensor data sensed and output by the sensors 1403 may be fed to the image preprocessor 1405. Sensor data processed by the image preprocessor 1405 may be fed to the deep learning network 1407 running on the AI processor 1409. The output of the deep learning network 1407 running by the AI processor 1409 may be fed to the vehicle control module 1411. Intermediate results of the deep learning network 1407 running on the AI processor 1407 may be fed to the AI processor 1409. In various embodiments, the network interface 1413 communicates with electronic devices within the vehicle, thereby transmitting autonomous driving path information and/or autonomous driving control commands for autonomous driving of the vehicle to internal block configurations. In one embodiment, the network interface 1431 may be used to transmit sensor data obtained through the sensor(s) 1403 to an external server. In some embodiments, autonomous driving control system 1400 may include additional or fewer components as appropriate. For example, in some embodiments, image preprocessor 1405 may be an optional component. As another example, a post-processing component (not shown) may be included within the autonomous driving control system 1400 to perform post-processing on the output of the deep learning network 1407 before the output is provided to the vehicle control module 1411. You can.

In some embodiments, sensors 1403 may include one or more sensors. In various embodiments, sensors 1403 may be attached to different locations on the vehicle. Sensors 1403 may point in one or more different directions. For example, the sensors 1403 are positioned at the front, sides, and rear of the vehicle to face directions such as forward-facing, rear-facing, and side-facing. ), and/or may be attached to the roof. In some embodiments, sensors 1403 may be image sensors, such as high dynamic range cameras. In some embodiments, sensors 1403 include non-visual sensors. In some embodiments, the sensors 1403 include RADAR, Light Detection And Ranging (LiDAR), and/or ultrasonic sensors in addition to an image sensor. In some embodiments, sensors 1403 are not mounted on a vehicle with vehicle control module 1411. For example, sensors 1403 may be included as part of a deep learning system to capture sensor data and may be attached to the environment or roadway and/or mounted on nearby vehicles.

In some embodiments, an image pre-processor 1405 may be used to preprocess sensor data from sensors 1403. For example, image preprocessor 1405 may be used to preprocess sensor data, split sensor data into one or more components, and/or postprocess one or more components. In some embodiments, image preprocessor 1405 may be a graphics processing unit (GPU), a central processing unit (CPU), an image signal processor, or a specialized image processor. there is. In various embodiments, the image preprocessor 1405 may be a tone-mapper processor for processing high dynamic range data. In some embodiments, the image preprocessor 1405 may be a component of the AI processor 1409.

In some embodiments, the deep learning network 1007 may be a deep learning network for implementing control commands for controlling an autonomous vehicle. For example, deep learning network 1407 may be an artificial neural network such as a convolutional neural network (CNN) trained using sensor data, and the output of deep learning network 1407 is sent to vehicle control module 1411. provided.

In some embodiments, the artificial intelligence (AI) processor 1409 may be a hardware processor for running the deep learning network 1407. In some embodiments, the AI processor 1409 is a specialized AI processor for performing inference on sensor data through a convolutional neural network (CNN). In some embodiments, AI processor 1409 may be optimized for bit depth of sensor data. In some embodiments, AI processor 1409 may be optimized for deep learning operations, such as convolution, dot product, and neural network operations including vector and/or matrix operations. In some embodiments, the AI processor 1409 may be implemented through a plurality of graphics processing units (GPUs) that can effectively perform parallel processing.

In various embodiments, AI processor 1409 performs deep learning analysis on sensor data received from sensor(s) 1403 while AI processor 1409 is running and operates the vehicle at least partially autonomously. Can be coupled via an input/output interface to a memory configured to provide an AI processor with instructions that cause it to determine the machine learning results used. In some embodiments, the vehicle control module 1411 processes commands for controlling the vehicle output from the artificial intelligence (AI) processor 1409, and controls various modules of the vehicle. ) can be used to translate the output of ) into commands for controlling the modules of each vehicle. In some embodiments, the vehicle control module 1411 is used to control a vehicle for autonomous driving. In some embodiments, vehicle control module 1411 may adjust the steering and/or speed of the vehicle. For example, the vehicle control module 1411 may be used to control vehicle driving such as deceleration, acceleration, steering, lane change, and lane maintenance. In some embodiments, the vehicle control module 1411 may generate control signals for controlling vehicle lighting, such as brake lights, turn signals, headlights, etc. You can. In some embodiments, vehicle control module 1411 can configure the vehicle's sound system, vehicle's audio warnings, vehicle's microphone system, and vehicle's horn system. It can be used to control vehicle audio-related systems such as system).

In some embodiments, vehicle control module 1411 may provide notification systems, including warning systems to notify passengers and/or drivers of driving events, such as approaching an intended destination or potential collision. ) can be used to control. In some embodiments, vehicle control module 1411 may be used to coordinate sensors, such as sensors 1403 in the vehicle. For example, the vehicle control module 1411 may modify the orientation of the sensors 1403, change the output resolution and/or format type of the sensors 1403, and adjust the capture rate. You can increase or decrease it, adjust the dynamic range, and adjust the camera's focus. Additionally, the vehicle control module 1411 can turn on/off the operation of sensors individually or collectively.

In some embodiments, vehicle control module 1411 may modify the frequency range of filters, adjust edge detection parameters for feature and/or object detection, or adjust bit depth and channels. It can be used to change the parameters of the image preprocessor 1405, such as by adjusting channels and bit depth. In various embodiments, the vehicle control module 1411 may be used to control autonomous driving of the vehicle and/or driver assistance functions of the vehicle.

In some embodiments, the network interface 1413 may be responsible for an internal interface between the block components of the autonomous driving control system 1400 and the communication unit 1415. Specifically, the network interface 1413 may be a communication interface for receiving and/or sending data including voice data. In various embodiments, the network interface 1413 connects voice calls through the communication unit 1415, receives and/or sends text messages, transmits sensor data, updates the vehicle's software with an autonomous driving system, or It can be connected to external servers to update the software of the autonomous driving system.

In various embodiments, the communication unit 1415 may include various wireless interfaces such as cellular or WiFi. For example, the network interface 1413 receives sensors 1403, an image preprocessor 1405, a deep learning network 1407, an AI processor 1409, and a vehicle control module from an external server connected through the communication unit 1415. Can be used to receive updates on operating parameters and/or instructions for 1411. For example, the machine learning model of the deep learning network 1407 may be updated using the communication unit 1415. According to another example, the communication unit 1415 may be used to update the operating parameters of the image preprocessor 1405, such as image processing parameters, and/or the firmware of the sensors 1403.

In another embodiment, the communication unit 1415 may be used to activate communications for emergency contact with emergency services in an accident or near-accident event. For example, in a crash event, communication unit 1415 may be used to call emergency services for assistance and may be used to notify emergency services of the crash details and the location of the vehicle. In various embodiments, communication unit 1415 may update or obtain the expected arrival time and/or destination location.

According to one embodiment, the autonomous driving system 1400 shown in FIG. 14 may be composed of an electronic device of a vehicle. According to one embodiment, when an autonomous driving cancellation event occurs from a user while the vehicle is autonomously driving, the AI processor 1409 of the autonomous driving system 1400 converts information related to the autonomous driving cancellation event into training set data of a deep learning network. By controlling the input, the vehicle's autonomous driving software can be controlled to learn.

The vehicle control module 1411 according to this embodiment performs collision avoidance, collision mitigation, lane changing, acceleration, and deceleration according to the message element included in the received event message. It is possible to generate various vehicle operation information to prevent secondary accidents, such as braking and steering wheel control.

15 and 16 are block diagrams showing an autonomous mobile device according to an embodiment. Referring to FIG. 15, the autonomous mobile device 1500 according to this embodiment may include a control device 1600, sensing modules 1504a, 1504b, 1504c, and 1504d, an engine 1506, and a user interface 1508. You can. For example, the self-driving mobile object 1500 may be an example of the vehicles 211, 212, 213, 215, and 217 of FIG. 2. For example, the autonomous mobile device 1500 may be controlled by the electronic devices 120 and 130.

The self-driving mobile object 1500 may have an autonomous driving mode or a manual mode. For example, the manual mode may be switched to the autonomous driving mode, or the autonomous driving mode may be switched to the manual mode, depending on the user input received through the user interface 1508.

When the mobile object 1500 is operated in an autonomous driving mode, the autonomous mobile object 1500 may be driven under the control of the control device 1600.

In this embodiment, the control device 1600 may include a controller 1620 including a memory 1622 and a processor 1624, a sensor 1610, a communication device 1630, and an object detection device 1640.

Here, the object detection device 1640 may perform all or part of the functions of a distance measuring device (eg, electronic devices 120 and 130).

That is, in this embodiment, the object detection device 1640 is a device for detecting an object located outside the moving body 1500, and the object detecting device 1640 detects an object located outside the moving body 1500. , object information can be generated according to the detection result.

The object information may include information about the presence or absence of the object, location information of the object, distance information between the moving object and the object, and information on the relative speed between the moving object and the object.

Objects may include various objects located outside the moving object 1500, such as lanes, other vehicles, pedestrians, traffic signals, lights, roads, structures, speed bumps, terrain, and animals. Here, a traffic signal may be a concept including a traffic light, a traffic sign, or a pattern or text drawn on the road surface. Additionally, the light may be light generated from a lamp provided in another vehicle, light generated from a street lamp, or sunlight.

Additionally, the structure may be an object located near the road and fixed to the ground. For example, structures may include streetlights, trees, buildings, electric poles, traffic lights, and bridges. Landforms may include mountains, hills, etc.

This object detection device 1640 may include a camera module. The controller 1620 may extract object information from an external image captured by a camera module and allow the controller 1620 to process the information.

Additionally, the object detection device 1640 may further include imaging devices for recognizing the external environment. In addition to LIDAR, RADAR, GPS devices, odometry, other computer vision devices, ultrasonic sensors, and infrared sensors can be used, and these devices can be selected or operated simultaneously as needed to enable more precise detection. .

Meanwhile, the distance measuring device according to an embodiment of the present invention calculates the distance between the autonomous mobile object 1500 and the object, and calculates the distance based on the distance calculated in connection with the control device 1600 of the autonomous mobile object 1500. The movement of a moving object can be controlled.

For example, if there is a possibility of a collision depending on the distance between the autonomous mobile device 1500 and an object, the autonomous mobile device 1500 may control the brakes to slow down or stop. As another example, when the object is a moving object, the autonomous mobile object 1500 may control the traveling speed of the autonomous mobile object 1500 to maintain a predetermined distance or more from the object.

The distance measuring device according to an embodiment of the present invention may be configured as a module within the control device 1600 of the autonomous mobile device 1500. That is, the memory 1622 and processor 1624 of the control device 1600 can implement the collision prevention method according to the present invention in software.

Additionally, the sensor 1610 can acquire various sensing information by connecting the internal/external environment of the moving object with the sensing modules 1504a, 1504b, 1504c, and 1504d. Here, the sensor 1610 is a posture sensor (e.g., yaw sensor, roll sensor, pitch sensor, collision sensor, wheel sensor, speed sensor, tilt sensor). , weight sensor, heading sensor, gyro sensor, position module, moving vehicle forward/backward sensor, battery sensor, fuel sensor, tire sensor, steering sensor by steering wheel rotation, inside the moving vehicle It may include a temperature sensor, a moving object internal humidity sensor, an ultrasonic sensor, an illumination sensor, an accelerator pedal position sensor, a brake pedal position sensor, etc.

Accordingly, the sensor 1610 includes moving object posture information, moving object collision information, moving object direction information, moving object location information (GPS information), moving object angle information, moving object speed information, moving object acceleration information, moving object tilt information, moving object forward/backward information, Sensing signals for battery information, fuel information, tire information, moving object lamp information, moving object internal temperature information, moving object internal humidity information, steering wheel rotation angle, moving object external illumination, pressure applied to the accelerator pedal, pressure applied to the brake pedal, etc. It can be obtained.

In addition, the sensor 1610 includes an accelerator pedal sensor, a pressure sensor, an engine speed sensor, an air flow sensor (AFS), an intake air temperature sensor (ATS), a water temperature sensor (WTS), and a throttle position sensor. It may further include a sensor (TPS), a TDC sensor, a crank angle sensor (CAS), etc.

In this way, the sensor 1610 can generate moving object status information based on sensing data.

The wireless communication device 1630 is configured to implement wireless communication between autonomous mobile devices 1500. For example, it allows the self-driving mobile device 1500 to communicate with a user's mobile phone, another wireless communication device 1630, another mobile device, a central device (traffic control device), a server, etc. The wireless communication device 1630 can transmit and receive wireless signals according to a connection wireless protocol. The wireless communication protocol may be Wi-Fi, Bluetooth, Long-Term Evolution (LTE), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), and Global Systems for Mobile Communications (GSM). It is not limited to this.

Additionally, in this embodiment, the self-driving mobile device 1500 can also implement communication between mobile devices through the wireless communication device 1630. That is, the wireless communication device 1630 can communicate with other mobile objects and other mobile objects on the road through vehicle-to-vehicle (V2V) communication. The self-driving mobile device 1500 can transmit and receive information such as driving warnings and traffic information through inter-vehicle communication, and can also request information from or receive requests from other mobile devices. For example, the wireless communication device 1630 may perform V2V communication as a dedicated short-range communication (DSRC) device or a cellular-V2V (C-V2V) device. Additionally, in addition to communication between vehicles, communication between vehicles and other objects (e.g., electronic devices carried by pedestrians, etc.) (V2X, Vehicle to Everything communication) can also be implemented through the wireless communication device 1630.

In this embodiment, the controller 1620 is a unit that controls the overall operation of each unit within the moving object 1500, and may be configured by the manufacturer of the moving object at the time of manufacturing or may be additionally configured after manufacturing to perform the function of autonomous driving. . Alternatively, a configuration for continuously performing additional functions may be included by upgrading the controller 1620 configured at the time of manufacturing. This controller 1620 may also be called an Electronic Control Unit (ECU).

The controller 1620 collects various data from the connected sensor 1610, object detection device 1640, communication device 1630, etc., and sends control signals based on the collected data to sensors included in other components in the moving object ( 1610), engine 1506, user interface 1508, communication device 1630, and object detection device 1640. In addition, although not shown, a control signal may be transmitted to an acceleration device, braking system, steering device, or navigation device related to the driving of the moving object.

In this embodiment, the controller 1620 may control the engine 1506 and, for example, detect the speed limit of the road on which the autonomous vehicle 1500 is traveling and prevent the engine 1506 from exceeding the speed limit. ), or the engine 1506 can be controlled to accelerate the traveling speed of the autonomous mobile object 1500 within a range that does not exceed the speed limit.

Additionally, if the autonomous vehicle 1500 approaches or deviates from its lane while the autonomous vehicle 1500 is driving, the controller 1620 determines whether such lane proximity or departure is due to a normal driving situation or other driving situation. The engine 1506 can be controlled to control the running of the moving object according to the determination result. Specifically, the autonomous mobile object 1500 can detect lanes formed on both sides of the lane in which the mobile object is traveling. In this case, the controller 1620 determines whether the autonomous vehicle 1500 is approaching the lane or deviating from the lane. If it is determined that the autonomous vehicle 1500 is approaching the lane or deviating from the lane, the controller 1620 determines whether the autonomous vehicle 1500 is approaching the lane or deviating from the lane. It can be determined whether the driving is based on the correct driving situation or another driving situation. Here, as an example of a normal driving situation, there may be a situation in which a moving object needs to change lanes. Additionally, as an example of another driving situation, there may be a situation in which changing the lane of the moving object is not necessary. If the controller 1620 determines that the autonomous mobile object 1500 is approaching the lane or deviating from the lane in a situation in which the mobile object does not need to change lane, the autonomous mobile object 1500 does not deviate from the lane and the mobile object 1500 does not deviate from the lane. The driving of the self-driving mobile object 1500 can be controlled to drive normally.

If another moving object or obstacle exists in front of the moving object, the engine 1606 or the braking system can be controlled to decelerate the moving object, and in addition to the speed, the trajectory, travel path, and steering angle can be controlled. Alternatively, the controller 1620 may control the driving of the mobile object by generating necessary control signals according to recognition information of the external environment, such as the driving lane of the mobile object and driving signals.

In addition to generating its own control signal, the controller 1620 can also control the driving of the mobile object by communicating with a nearby mobile object or a central server and transmitting commands to control peripheral devices through received information.

In addition, if the position of the camera module 1650 changes or the angle of view changes, the controller 1620 may find it difficult to accurately recognize moving objects or lanes according to this embodiment, so to prevent this, the controller 1620 performs calibration of the camera module 1650 ( It is also possible to generate a control signal to control calibration. Therefore, in this embodiment, the controller 1220 generates a calibration control signal to the camera module 1650, so that the mounting position of the camera module 1650 is changed due to vibration or shock generated according to the movement of the autonomous mobile object 1500. Even if it is changed, the normal mounting position, direction, angle of view, etc. of the camera module 1650 can be continuously maintained. The controller 1620 determines the pre-stored initial mounting position, direction, and angle of view information of the camera module 1620 and the initial mounting position, direction, and angle of view information of the camera module 1620 measured while the autonomous mobile object 1500 is running. If it varies beyond the value, a control signal may be generated to calibrate the camera module 1620.

In this embodiment, the controller 1620 may include a memory 1622 and a processor 1624. The processor 1624 may execute software stored in the memory 1622 according to a control signal from the controller 1620. Specifically, the controller 1620 stores data and instructions for performing the lane detection method according to the present invention in the memory 1622, and the instructions can be executed by the processor 1624 to implement one or more methods disclosed herein. there is.

At this time, the memory 1622 may be stored in a non-volatile recording medium executable by the processor 1624. Memory 1622 may store software and data through appropriate internal or external devices. The memory 1622 may be composed of a memory 1622 device connected to random access memory (RAM), read only memory (ROM), a hard disk, and a dongle.

The memory 1622 can store at least an operating system (OS), user applications, and executable commands. Memory 1222 may also store application data and array data structures.

Processor 1224 may be a microprocessor or other suitable electronic processor, such as a controller, microcontroller, or state machine.

The processor 1624 may be implemented as a combination of computing devices, and the computing device may be a digital signal processor, a microprocessor, or an appropriate combination thereof.

Meanwhile, the self-driving mobile object 1500 may further include a user interface 1508 for user input to the control device 1600 described above. User interface 1508 may allow a user to enter information with appropriate interaction. For example, it can be implemented with a touch screen, keypad, operation button, etc. The user interface 1508 transmits an input or command to the controller 1620, and the controller 1620 can perform a control operation of the moving object in response to the input or command.

Additionally, the user interface 1508 may enable a device external to the autonomous vehicle 1500 to communicate with the autonomous vehicle 1500 through the wireless communication device 1630. For example, the user interface 1508 can be interfaced with a mobile phone, tablet, or other computer device.

Furthermore, in this embodiment, the self-driving vehicle 1500 has been described as including an engine 1506, but it may also include other types of propulsion systems. For example, a mobile vehicle can be driven by electric energy, hydrogen energy, or a hybrid system combining these. Accordingly, the controller 1620 may include a propulsion mechanism according to the propulsion system of the autonomous mobile vehicle 1500 and provide control signals accordingly to the components of each propulsion mechanism.

Hereinafter, the detailed configuration of the control device 1600 according to the present invention according to this embodiment will be described in more detail with reference to FIG. 16.

Control device 1600 includes a processor 1624. Processor 1624 may be a general-purpose single or multi-chip microprocessor, a dedicated microprocessor, a microcontroller, a programmable gate array, etc. A processor may also be referred to as a central processing unit (CPU). Additionally, in this embodiment, the processor 1624 can be used as a combination of multiple processors.

Control device 1600 also includes memory 1622. Memory 1622 may be any electronic component capable of storing electronic information. The memory 1622 may also include a combination of memories 1622 in addition to a single memory.

Data and commands 1622a for performing the distance measuring method of the distance measuring device according to the present invention may be stored in the memory 1622. When the processor 1624 executes the instructions 1622a, all or part of the instructions 1622a and the data 1622b required to execute the instructions may be loaded (1624a, 1624b) onto the processor 1624.

The control device 1600 may include a transmitter 1630a, a receiver 1630b, or a transceiver 1630c to allow transmission and reception of signals. One or more antennas 1632a and 1632b may be electrically connected to the transmitter 1630a, the receiver 1630b, or each transceiver 1630c, and may include additional antennas.

Control device 1600 may include a digital signal processor (DSP) 1670. Through the DSP (1670), digital signals can be processed quickly by a moving object.

Control device 1600 may include a communication interface 1680. The communication interface 1680 may include one or more ports and/or communication modules for connecting other devices to the control device 1600. Communication interface 1680 may allow a user and control device 1600 to interact.

The various components of control device 1600 may be connected together by one or more buses 1690, which may include a power bus, control signal bus, status signal bus, data bus, etc. Under the control of the processor 1624, the components can transfer information to each other through the bus 1690 and perform the desired function.

In embodiments, the processor 1624 of the control device 1600 may control communication with other vehicles and/or RSUs through the communication interface 1680. If the vehicle equipped with the control device 1600 is the source vehicle, the processor 1624 reads the event-related information stored in the memory 1622, includes it in the element of the event message, and then encodes it according to a designated encryption method. Event messages can be encrypted. The processor 1624 may transmit the encrypted message to other vehicles and/or RSUs through the communication interface 1680.

Additionally, in embodiments, when receiving an event message through the communication interface 1680, the processor 1624 of the control device 1600 may decrypt the event message using the decryption-related information stored in the memory 1622. You can. After the decryption, the processor 1624 of the control device 1600 can determine whether the vehicle is a slave vehicle dependent on the event message. If the vehicle corresponds to a dependent vehicle, the processor 1624 of the control device 1600 may control the vehicle to perform autonomous driving according to elements included in the event message.

In embodiments, a device in a vehicle may include at least one transceiver, a memory configured to store instructions, and at least one processor operatively coupled with the at least one transceiver and the memory. The at least one processor may be configured to receive an event message related to an event of the source vehicle when the instructions are executed. The event message may include identification information about a serving road side unit (RSU) of the source vehicle and direction information indicating the driving direction of the source vehicle. The at least one processor may be configured to identify whether the serving RSU of the source vehicle is included in the driving list of the vehicle when the instructions are executed. The at least one processor may be configured to identify whether the driving direction of the source vehicle matches the driving direction of the vehicle when the instructions are executed. When the instructions are executed, the at least one processor identifies that the driving direction of the source vehicle matches the driving direction of the vehicle and that the serving RSU of the source vehicle is included in the driving list of the vehicle (upon identifying ), may be configured to perform driving according to the event message. When executing the instructions, the at least one processor identifies that the driving direction of the source vehicle does not match the driving direction of the vehicle, or that the serving RSU of the source vehicle is not included in the driving list of the vehicle. (upon identifying), may be configured to perform driving without the event message.

According to one embodiment, the vehicle's driving list may include identification information for one or more RSUs. The driving direction may indicate one of a first lane direction and a second lane direction opposite to the first lane direction.

According to one embodiment, the at least one processor may be configured to identify encryption information for the serving RSU based on receiving the event message when the instructions are executed. When the instructions are executed, the at least one processor decrypts the event message based on encryption information for the serving RSU, thereby generating the identification information for the serving RSU of the source vehicle and the driving direction of the source vehicle. It may be configured to obtain the direction information indicating.

According to one embodiment, the at least one processor may be configured to transmit a service request message to a service provider server through an RSU before receiving the event message when the instructions are executed. The at least one processor may be configured to receive a service response message corresponding to the service request message from the service provider server through the RSU when the instructions are executed. The service response message may include driving plan information for indicating the expected driving path of the vehicle, information on one or more RSUs related to the expected driving path, and encryption information for each of the one or more RSUs. there is. The encryption information may include encryption information about the serving RSU.

According to one embodiment, the at least one processor may be configured to receive a broadcast message from the serving RSU before receiving the event message when the instructions are executed. The broadcast message may include identification information for the RSU, information indicating at least one RSU adjacent to the RSU, and encryption information for the RSU.

According to one embodiment, when the instructions are executed, the at least one processor may be configured to change driving-related settings of the vehicle based on the event message in order to perform driving according to the event message. . The driving-related settings may include at least one of a driving path of the vehicle, a driving lane of the vehicle, a driving speed of the vehicle, a driving lane of the vehicle, or braking of the vehicle.

According to one embodiment, when the instructions are executed, the at least one processor may be configured to generate a delivery event message based on the event message in order to perform driving according to the event message. When the instructions are executed, the at least one processor may be configured to encrypt the delivery event message based on encryption information about the RSU servicing the vehicle in order to perform driving according to the event message. When the instructions are executed, the at least one processor may be configured to transmit the encrypted delivery event message to the RSU or to another vehicle in order to perform driving according to the event message.

According to one embodiment, when the instructions are executed, the at least one processor sends an update request message to a service provider server through an RSU servicing the vehicle in order to perform driving according to the event message. It may be configured to transmit. When the instructions are executed, the at least one processor may be configured to receive an update message from the service provider server through the RSU in order to perform driving according to the event message. The update request message may include information related to the event of the source vehicle. The update message may include information indicating the updated driving path of the vehicle.

In embodiments, an apparatus implemented by a road side unit (RSU) includes at least one transceiver, a memory configured to store instructions, and at least one processor operatively coupled to the at least one transceiver and the memory. may include. The at least one processor may be configured to receive, when the instructions are executed, an event message related to an event in the vehicle from the vehicle serviced by the RSU. The event message may include identification information of the vehicle and direction information indicating the driving direction of the vehicle. The at least one processor may be configured to identify a driving path of the vehicle when the instructions are executed, based on identification information of the vehicle. When the instructions are executed, the at least one processor is configured to identify at least one RSU located in a direction opposite to the driving direction of the vehicle from the RSU among one or more RSUs included in the driving path of the vehicle. It can be configured. The at least one processor may be configured to deliver the event message to each of the identified at least one RSU when the instructions are executed.

According to one embodiment, the at least one processor may be configured to generate a delivery event message based on the event message when the instructions are executed. The at least one processor encrypts the delivery event message based on encryption information for the RSU when the instructions are executed, and the at least one processor encrypts the encrypted delivery event message when the instructions are executed. It may be configured to transmit to other vehicles within the RSU. Encryption information about the RSU may be broadcast from the RSU.

In embodiments, a method performed by a vehicle may include receiving an event message related to an event of the source vehicle. The event message may include identification information about a serving road side unit (RSU) of the source vehicle and direction information indicating the driving direction of the source vehicle. The method may include identifying whether the serving RSU of the source vehicle is included in the vehicle's driving list. The method may include identifying whether the driving direction of the source vehicle matches the driving direction of the vehicle. The method performs driving according to the event message when the driving direction of the source vehicle matches the driving direction of the vehicle and upon identifying that the serving RSU of the source vehicle is included in the driving list of the vehicle. It may include actions such as: If the method identifies that the driving direction of the source vehicle does not match the driving direction of the vehicle, or the serving RSU of the source vehicle is not included in the driving list of the vehicle, without the event message, It may include the operation of performing driving.

According to one embodiment, the vehicle's driving list may include identification information for one or more RSUs. The driving direction may indicate one of a first lane direction and a second lane direction opposite to the first lane direction.

According to one embodiment, the method may include identifying encryption information for the serving RSU based on receiving the event message. The method includes an operation of obtaining the identification information for the serving RSU of the source vehicle and the direction information indicating the driving direction of the source vehicle by decoding the event message based on encryption information for the serving RSU. It can be included.

According to one embodiment, the method may include transmitting a service request message to a service provider server through an RSU before receiving the event message. The method may include receiving a service response message corresponding to the service request message from the service provider server through the RSU. The service response message may include driving plan information for indicating the expected driving path of the vehicle, information on one or more RSUs related to the expected driving path, and encryption information for each of the one or more RSUs. there is. The encryption information may include encryption information about the serving RSU.

According to one embodiment, the method may include receiving a broadcast message from the serving RSU before receiving the event message. The broadcast message may include identification information for the RSU, information indicating at least one RSU adjacent to the RSU, and encryption information for the RSU.

According to one embodiment, the operation of driving according to the event message may include the operation of changing driving-related settings of the vehicle based on the event message. The driving-related settings may include at least one of a driving path of the vehicle, a driving lane of the vehicle, a driving speed of the vehicle, a driving lane of the vehicle, or braking of the vehicle.

According to one embodiment, the operation of driving according to the event message may include the operation of generating a delivery event message based on the event message. The operation of driving according to the event message may include encrypting the delivery event message based on encryption information about the RSU servicing the vehicle. The operation of driving according to the event message may include transmitting the encrypted delivery event message to the RSU or to another vehicle.

According to one embodiment, the operation of driving according to the event message may include transmitting an update request message to a service provider server through an RSU servicing the vehicle. The operation of driving according to the event message may include receiving an update message from the service provider server through the RSU. The update request message may include information related to the event of the source vehicle. The update message may include information indicating the updated driving path of the vehicle.

In embodiments, a method performed by a road side unit (RSU) may include receiving an event message related to an event in the vehicle from a vehicle serviced by the RSU. The event message may include identification information of the vehicle and direction information indicating the driving direction of the vehicle. The method may include an operation of identifying a driving path of the vehicle based on identification information of the vehicle. The method may include identifying at least one RSU located in a direction opposite to the driving direction of the vehicle from the RSU among one or more RSUs included in the driving path of the vehicle. The method may include delivering the event message to each of the identified at least one RSU.

According to one embodiment, the method may include generating a delivery event message based on the event message. The method may include encrypting the delivery event message based on encryption information for the RSU. The method may include transmitting the encrypted delivery event message to another vehicle within the RSU. Encryption information about the RSU may be broadcast from the RSU.

Methods according to embodiments described in the claims or specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

When implemented as software, a computer-readable storage medium that stores one or more programs (software modules) may be provided. One or more programs stored in a computer-readable storage medium are configured to be executable by one or more processors in an electronic device (configured for execution). One or more programs include instructions that cause the electronic device to execute methods according to embodiments described in the claims or specification of the present disclosure.

These programs (software modules, software) may include random access memory, non-volatile memory, including flash memory, read only memory (ROM), and electrically erasable programmable ROM. (electrically erasable programmable read only memory, EEPROM), magnetic disc storage device, compact disc-ROM (CD-ROM), digital versatile discs (DVDs), or other types of disk storage. It can be stored in an optical storage device or magnetic cassette. Alternatively, it may be stored in a memory consisting of a combination of some or all of these. Additionally, multiple configuration memories may be included.

In addition, the program may be distributed through a communication network such as the Internet, an intranet, a local area network (LAN), a wide area network (WAN), or a storage area network (SAN), or a combination thereof. It may be stored on an attachable storage device that is accessible. This storage device can be connected to a device performing an embodiment of the present disclosure through an external port. Additionally, a separate storage device on a communications network may be connected to the device performing embodiments of the present disclosure.

In the specific embodiments of the present disclosure described above, elements included in the disclosure are expressed in singular or plural numbers depending on the specific embodiment presented. However, singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components, and even components expressed in plural may be composed of singular or singular. Even expressed components may be composed of plural elements.

Meanwhile, in the detailed description of the present disclosure, specific embodiments have been described, but of course, various modifications are possible without departing from the scope of the present disclosure.

Claims (20)

In the device of a vehicle,
at least one transceiver;
a memory configured to store instructions; and
At least one processor operatively coupled to the at least one transceiver and the memory, wherein when the instructions are executed, the at least one processor:
Receive an event message related to an event of the source vehicle, wherein the event message includes identification information about a serving road side unit (RSU) of the source vehicle and direction information indicating the driving direction of the source vehicle. do,
Identify whether the serving RSU of the source vehicle is included in the driving list of the vehicle,
Identify whether the driving direction of the source vehicle matches the driving direction of the vehicle,
When the driving direction of the source vehicle matches the driving direction of the vehicle, and upon identifying that the serving RSU of the source vehicle is included in the driving list of the vehicle, driving according to the event message is performed,
If the driving direction of the source vehicle does not match the driving direction of the vehicle, or if the serving RSU of the source vehicle identifies that it is not included in the driving list of the vehicle (upon identifying), driving is performed without the event message. configured to,
Device.
In claim 1,
The vehicle's driving list includes identification information for one or more RSUs,
The driving direction indicates one of a first lane direction and a second lane direction opposite to the first lane direction,
Device.
The method of claim 1, wherein when the at least one processor executes the instructions,
Based on receiving the event message, identify encryption information for the serving RSU,
further configured to obtain the identification information for the serving RSU of the source vehicle and the direction information indicating the driving direction of the source vehicle by decoding the event message based on encryption information for the serving RSU,
Device.
The method of claim 3, wherein when the at least one processor executes the instructions,
Before receiving the event message, a service request message is sent to the service provider server through RSU,
Additionally configured to receive a service response message corresponding to the service request message from the service provider server through the RSU,
The service response message includes driving plan information for indicating an expected driving path of the vehicle, information on one or more RSUs related to the expected driving path, and encryption information for each of the one or more RSUs,
The encryption information includes encryption information for the serving RSU,
Device.
The method of claim 3, wherein the at least one processor is further configured to receive a broadcast message from the serving RSU before receiving the event message when the instructions are executed,
The broadcast message includes identification information for the RSU, information for indicating at least one RSU adjacent to the RSU, and encryption information for the RSU,
Device.
The method according to claim 1, wherein when the instructions are executed, the at least one processor is configured to change driving-related settings of the vehicle based on the event message to perform driving according to the event message,
The driving-related settings include at least one of a driving path of the vehicle, a driving lane of the vehicle, a driving speed of the vehicle, a lane of the vehicle, or braking of the vehicle,
Device.
The method according to claim 1, wherein when the instructions are executed, the at least one processor performs driving according to the event message.
Generate a delivery event message based on the event message,
Encrypting the delivery event message based on encryption information about the RSU servicing the vehicle,
configured to transmit the encrypted delivery event message to the RSU or to another vehicle,
Device.
In claim 1,
When the instructions are executed, the at least one processor performs driving according to the event message,
Transmitting an update request message to a service provider server through the RSU servicing the vehicle,
Additional configured to receive an update message from the service provider server through the RSU,
The update request message includes information related to the event of the source vehicle,
The update message includes information indicating an updated driving path of the vehicle.
Device.
In a device performed by a road side unit (RSU),
at least one transceiver;
a memory configured to store instructions; and
At least one processor operatively coupled to the at least one transceiver and the memory, wherein when the instructions are executed, the at least one processor:
Receiving an event message related to an event in the vehicle from a vehicle serviced by the RSU, the event message including identification information of the vehicle and direction information indicating a driving direction of the vehicle,
Based on the identification information of the vehicle, identify the driving path of the vehicle,
Among one or more RSUs included in the driving path of the vehicle, identify at least one RSU located in a direction opposite to the driving direction of the vehicle from the RSU,
Configured to deliver the event message to each of the identified at least one RSU,
Device.
The method of claim 9, wherein when the at least one processor executes the instructions,
Generate a delivery event message based on the event message,
Encrypting the delivery event message based on encryption information for the RSU,
further configured to transmit the encrypted delivery event message to another vehicle within the RSU,
Encryption information for the RSU is broadcast from the RSU,
method.
In a method performed by a vehicle,
An operation of receiving an event message related to an event of a source vehicle, wherein the event message includes identification information about a serving road side unit (RSU) of the source vehicle and direction information indicating a driving direction of the source vehicle. Including,
An operation of identifying whether the serving RSU of the source vehicle is included in the driving list of the vehicle;
An operation of identifying whether the driving direction of the source vehicle matches the driving direction of the vehicle;
When the driving direction of the source vehicle matches the driving direction of the vehicle and the serving RSU of the source vehicle is identified as being included in the driving list of the vehicle, performing driving according to the event message; ,
If the driving direction of the source vehicle does not match the driving direction of the vehicle, or if the serving RSU of the source vehicle identifies that it is not included in the driving list of the vehicle (upon identifying), driving is performed without the event message. Including the action of
method.
In claim 11,
The vehicle's driving list includes identification information for one or more RSUs,
The driving direction indicates one of a first lane direction and a second lane direction opposite to the first lane direction,
method.
In claim 11,
Based on receiving the event message, identifying encryption information for the serving RSU;
Further comprising the operation of obtaining the identification information for the serving RSU of the source vehicle and the direction information indicating the driving direction of the source vehicle by decoding the event message based on encryption information for the serving RSU. ,
method.
In claim 13,
Before receiving the event message, transmitting a service request message to a service provider server through RSU;
Further comprising receiving a service response message corresponding to the service request message from the service provider server through the RSU,
The service response message includes driving plan information for indicating an expected driving path of the vehicle, information on one or more RSUs related to the expected driving path, and encryption information for each of the one or more RSUs,
The encryption information includes encryption information for the serving RSU,
method.
In claim 13,
Before receiving the event message, further comprising receiving a broadcast message from the serving RSU,
The broadcast message includes identification information for the RSU, information for indicating at least one RSU adjacent to the RSU, and encryption information for the RSU.
method.
The method of claim 11, wherein the operation of driving according to the event message includes:
An operation of changing driving-related settings of the vehicle based on the event message,
The driving-related settings include at least one of a driving path of the vehicle, a driving lane of the vehicle, a driving speed of the vehicle, a lane of the vehicle, or braking of the vehicle,
method.
The method of claim 11, wherein the operation of driving according to the event message includes:
An operation of generating a delivery event message based on the event message;
Encrypting the delivery event message based on encryption information about the RSU servicing the vehicle;
Including transmitting the encrypted delivery event message to the RSU or to another vehicle,
method.
The method of claim 11, wherein the operation of driving according to the event message includes:
An operation of transmitting an update request message to a service provider server through an RSU servicing the vehicle;
Further comprising receiving an update message from the service provider server through the RSU,
The update request message includes information related to the event of the source vehicle,
The update message includes information indicating an updated driving path of the vehicle.
method.
In a method performed by a road side unit (RSU),
An operation of receiving, from a vehicle serviced by the RSU, an event message related to an event in the vehicle, the event message including identification information of the vehicle and direction information indicating a driving direction of the vehicle,
An operation of identifying a driving path of the vehicle based on the identification information of the vehicle;
Among one or more RSUs included in the driving path of the vehicle, identifying at least one RSU located in a direction opposite to the driving direction of the vehicle from the RSU;
Including delivering the event message to each of the identified at least one RSU,
method.
In claim 19,
An operation of generating a delivery event message based on the event message;
Encrypting the delivery event message based on encryption information for the RSU;
Further comprising transmitting the encrypted delivery event message to another vehicle within the RSU,
Encryption information for the RSU is broadcast from the RSU,
method.

Images