KR20210098071A - Methods for comparing data on a vehicle in autonomous driving system - Google Patents

Abstract

The present specification relates to a method of comparing data of a vehicle in an autonomous driving system. The method can include the following steps of: generating first sensing data related with a specific object through a sensor; receiving local dynamic map (LDM) data related with the specific object from a server; based on a comparison result between the first sensing data and the LDM data, when the first sensing data is not matched with the LDM data, receiving second sensing data related with the specific object from another vehicle; based on a comparison result between the LDM data and the second sensing data, when the LDM data is matched with the second sensing data, performing a control operation using the LDM data or the second sensing data; and resetting an autonomous driving function in order to prevent the sensing data generated through the sensor from being used for autonomous driving. Therefore, the present invention enables a vehicle to use data in accordance with an established priority.

Description

How to compare vehicle data in autonomous driving system {METHODS FOR COMPARING DATA ON A VEHICLE IN AUTONOMOUS DRIVING SYSTEM}

This specification relates to an autonomous driving system, and in order to secure reliability of autonomous driving cognitive data, it is a method of comparing and analyzing cognitive data of own vehicle, server, and surrounding vehicles, selecting optimal data, and controlling the own vehicle accordingly.

A vehicle may be classified into an internal combustion engine vehicle, an external combustion engine vehicle, a gas turbine vehicle, an electric vehicle, or the like, according to a type of a prime mover used.

Autonomous vehicle refers to a vehicle that can operate on its own without driver or passenger manipulation. say

An object of the present specification is to propose a data comparison method of a vehicle in an autonomous driving system.

In addition, an object of the present specification is to propose a method of using data according to priority when there is no matching data as a result of comparing vehicle data in an autonomous driving system.

The technical problems to be achieved by this specification are not limited to the technical problems mentioned above, and other technical problems not mentioned are clear to those of ordinary skill in the art to which this specification belongs from the detailed description of the invention below. will be able to be understood

An aspect of the present specification provides a data comparison method of a vehicle in an autonomous driving system, the method comprising: generating first sensed data related to a specific object through a sensor; receiving, from a server, LDM (Local Dynamic Map) data related to the specific object; receiving second sensing data related to the specific object from another vehicle when the first sensing data and the LDM data do not match, based on a comparison result of the first sensing data and the LDM data; performing a control operation using the LDM data or the second sensing data when the LDM data and the second sensing data match based on a comparison result of the LDM data and the second sensing data; and resetting the autonomous driving function so as not to use the sensing data generated through the sensor for autonomous driving. may include.

In addition, the step of broadcasting a request message for requesting sensing data related to the surrounding object (Broadcast); and receiving sensing data related to the surrounding object as a response to the request message. may further include.

In addition, when the LDM data and the second sensed data do not match, when the first sensed data and the second sensed data match based on a comparison result of the first sensed data and the second sensed data , performing a control operation using the first sensed data; may further include.

In addition, when all of the first sensing data, the second sensing data, and the LDM data do not match, performing a control operation based on a preset priority rule; may further include.

In addition, the priority rule may be prioritized based on the location information of the specific object.

In addition, the priority rule may be prioritized based on a classification result of the first sensing data, the second sensing data, and the LDM data.

In addition, the priority rule is When the shortest distance between the predicted path of the specific object and the predicted path of the vehicle is less than or equal to a reference distance, data related to the specific object may be set to be prioritized.

In addition, based on the plurality of first sensed data, specifying the first sensed data to be the target of the comparison method; may further include.

Also, the vehicle may be a leader vehicle of a platoon in which the other vehicle is included as a slave vehicle.

In addition, when the LDM data and the second sensed data do not match, when the first sensed data and the second sensed data match based on a comparison result of the first sensed data and the second sensed data , performing a control operation using the first sensed data; and when all of the first sensing data, the second sensing data, and the LDM data do not match, performing a control operation based on a preset priority rule; Further comprising, the priority rule may be set so that data received from the other vehicle is prioritized.

In addition, when the shortest distance between the predicted path of the surrounding object and the expected path of the vehicle is less than or equal to a reference distance, performing a control operation using the sensing data related to the surrounding object; may further include.

Another aspect of the present specification provides a vehicle for a data comparison method in an autonomous driving system, comprising: a sensor; transceiver; Memory; and a processor operatively coupled to the sensor, the transceiver, and the memory. including, wherein the processor generates first sensed data related to a specific object through the sensor, receives LDM (Local Dynamic Map) data related to the specific object from a server through the transceiver, and the second Based on the comparison result of the first sensed data and the LDM data, when the first sensed data and the LDM data do not match, the second sensed data related to the specific object is received from another vehicle, and the LDM data and the second sensed data are received. When the LDM data and the second sensed data match based on the comparison result of the two sensed data, a control operation is performed using the LDM data or the second sensed data, and the sensed data generated through the sensor to not be used for autonomous driving, the autonomous driving function may be reset in the memory.

According to an embodiment of the present specification, a vehicle can efficiently compare data in an autonomous driving system.

Also, according to an embodiment of the present specification, when there is no matching data as a result of data comparison of the vehicle in the autonomous driving system, the vehicle may use the data according to a set priority.

The effects obtainable in the present specification are not limited to the above-mentioned effects, and other effects not mentioned will be clearly understood by those of ordinary skill in the art to which this specification belongs from the description below. .

1 illustrates a block diagram of a wireless communication system to which the methods proposed in the present specification can be applied.
2 shows an example of a signal transmission/reception method in a wireless communication system.
3 is a diagram illustrating a vehicle according to an embodiment of the present specification.
4 is a control block diagram of a vehicle according to an embodiment of the present specification.
5 is a control block diagram of an autonomous driving apparatus according to an embodiment of the present specification.
6 is a signal flow diagram of an autonomous vehicle according to an embodiment of the present specification.
7 is an example of V2X communication to which this specification can be applied.
8 illustrates a resource allocation method in a sidelink in which V2X is used.
9 is a diagram illustrating a procedure for a broadcast mode of V2X communication using PC5.
10 illustrates an architecture of an MEC server that can be applied in this specification.
11 is an example of an autonomous driving system using an LDM to which this specification can be applied.
12 is an example of an LDM to which this specification can be applied.
13 is an example of a communication method to which this specification can be applied.
14 is an example of critical data determination to which this specification can be applied.
15 is an embodiment of a vehicle to which this specification can be applied.
16 is an example of a data comparison method to which this specification can be applied.
17 is an embodiment to which the present specification can be applied.
18 is an embodiment to which the present specification can be applied.
19 is an embodiment to which the present specification can be applied.
20 is an embodiment to which the present specification can be applied.
21 shows a wireless communication device according to an embodiment of the present specification.
22 illustrates a block diagram of a network node according to an embodiment of the present specification.
23 illustrates a block diagram of a communication device according to an embodiment of the present specification.
BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are included as a part of the detailed description to help the understanding of the present specification, provide embodiments of the present specification, and together with the detailed description, explain the technical features of the present specification.

Hereinafter, the embodiments disclosed in the present specification will be described in detail with reference to the accompanying drawings, but the same or similar components are assigned the same reference numbers regardless of reference numerals, and redundant description thereof will be omitted. The suffixes "module" and "part" for the components used in the following description are given or mixed in consideration of only the ease of writing the specification, and do not have a meaning or role distinct from each other by themselves. In addition, in describing the embodiments disclosed in the present specification, if it is determined that detailed descriptions of related known technologies may obscure the gist of the embodiments disclosed in the present specification, the detailed description thereof will be omitted. In addition, the accompanying drawings are only for easy understanding of the embodiments disclosed in the present specification, and the technical spirit disclosed herein is not limited by the accompanying drawings, and all changes included in the spirit and scope of the present specification , should be understood to include equivalents or substitutes.

Terms including an ordinal number, such as first, second, etc., may be used to describe various elements, but the elements are not limited by the terms. The above terms are used only for the purpose of distinguishing one component from another.

When a component is referred to as being “connected” or “connected” to another component, it is understood that the other component may be directly connected or connected to the other component, but other components may exist in between. it should be On the other hand, when it is said that a certain element is "directly connected" or "directly connected" to another element, it should be understood that no other element is present in the middle.

The singular expression includes the plural expression unless the context clearly dictates otherwise.

In the present application, terms such as "comprises" or "have" are intended to designate that a feature, number, step, operation, component, part, or combination thereof described in the specification exists, but one or more other features It should be understood that this does not preclude the existence or addition of numbers, steps, operations, components, parts, or combinations thereof.

A. Example UE and 5G network block diagram

1 illustrates a block diagram of a wireless communication system to which the methods proposed in the present specification can be applied.

Referring to FIG. 1 , a device (autonomous driving device) including an autonomous driving module may be defined as a first communication device ( 910 in FIG. 1 ), and a processor 911 may perform a detailed autonomous driving operation.

A 5G network including another vehicle communicating with the autonomous driving device may be defined as a second communication device ( 920 in FIG. 1 ), and the processor 921 may perform a detailed autonomous driving operation.

The 5G network may be represented as the first communication device and the autonomous driving device may be represented as the second communication device.

For example, the first communication device or the second communication device may be a base station, a network node, a transmitting terminal, a receiving terminal, a wireless device, a wireless communication device, an autonomous driving device, or the like.

For example, a terminal or user equipment (UE) includes a vehicle, a mobile phone, a smart phone, a laptop computer, a digital broadcasting terminal, personal digital assistants (PDA), and a portable multimedia player (PMP). , navigation, slate PC, tablet PC, ultrabook, wearable device, for example, watch-type terminal (smartwatch), glass-type terminal (smart glass), HMD ( head mounted display) and the like. For example, the HMD may be a display device worn on the head. For example, an HMD may be used to implement VR, AR or MR. Referring to FIG. 1 , a first communication device 910 and a second communication device 920 include a processor 911,921, a memory 914,924, and one or more Tx/Rx RF modules (radio frequency module, 915,925). , including Tx processors 912 and 922 , Rx processors 913 and 923 , and antennas 916 and 926 . Tx/Rx modules are also called transceivers. Each Tx/Rx module 915 transmits a signal via a respective antenna 926 . The processor implements the functions, processes and/or methods salpinned above. The processor 921 may be associated with a memory 924 that stores program code and data. Memory may be referred to as a computer-readable medium. More specifically, in DL (communication from a first communication device to a second communication device), the transmit (TX) processor 912 implements various signal processing functions for the L1 layer (ie, the physical layer). The receive (RX) processor implements the various signal processing functions of L1 (ie, the physical layer).

The UL (second communication device to first communication device) is handled in the first communication device 910 in a manner similar to that described with respect to the receiver function in the second communication device 920 . Each Tx/Rx module 925 receives a signal via a respective antenna 926 . Each Tx/Rx module provides an RF carrier and information to the RX processor 923 . The processor 921 may be associated with a memory 924 that stores program code and data. Memory may be referred to as a computer-readable medium.

B. Signal transmission/reception method in wireless communication system

2 is a diagram illustrating an example of a signal transmission/reception method in a wireless communication system.

Referring to FIG. 2 , the UE performs an initial cell search operation such as synchronizing with the BS when the power is turned on or a new cell is entered ( S201 ). To this end, the UE receives a primary synchronization channel (P-SCH) and a secondary synchronization channel (S-SCH) from the BS, synchronizes with the BS, and acquires information such as cell ID can do. In the LTE system and the NR system, the P-SCH and the S-SCH are called a primary synchronization signal (PSS) and a secondary synchronization signal (SSS), respectively. After the initial cell discovery, the UE may receive a physical broadcast channel (PBCH) from the BS to obtain broadcast information in the cell. Meanwhile, the UE may check the downlink channel state by receiving a downlink reference signal (DL RS) in the initial cell search step. After the initial cell search, the UE receives a physical downlink control channel (PDCCH) and a physical downlink shared channel (PDSCH) according to information carried on the PDCCH to obtain more specific system information. It can be done (S202).

On the other hand, when there is no radio resource for the first access to the BS or signal transmission, the UE may perform a random access procedure (RACH) to the BS (steps S203 to S206). To this end, the UE transmits a specific sequence as a preamble through a physical random access channel (PRACH) (S203 and S205), and a random access response to the preamble through the PDCCH and the corresponding PDSCH (random access response, RAR) message may be received (S204 and S206). In the case of contention-based RACH, a contention resolution procedure may be additionally performed.

After performing the process as described above, the UE receives PDCCH/PDSCH (S207) and a physical uplink shared channel (PUSCH)/physical uplink control channel as a general uplink/downlink signal transmission process. Uplink control channel, PUCCH) transmission (S208) may be performed. In particular, the UE receives downlink control information (DCI) through the PDCCH. The UE monitors a set of PDCCH candidates in monitoring opportunities set in one or more control element sets (CORESETs) on a serving cell according to corresponding search space configurations. The set of PDCCH candidates to be monitored by the UE is defined in terms of search space sets, which may be a common search space set or a UE-specific search space set. CORESET consists of a set of (physical) resource blocks with a time duration of 1 to 3 OFDM symbols. The network may configure the UE to have multiple CORESETs. The UE monitors PDCCH candidates in one or more search space sets. Here, monitoring means trying to decode PDCCH candidate(s) in the search space. If the UE succeeds in decoding one of the PDCCH candidates in the search space, the UE determines that the PDCCH is detected in the corresponding PDCCH candidate, and performs PDSCH reception or PUSCH transmission based on the DCI in the detected PDCCH. The PDCCH may be used to schedule DL transmissions on PDSCH and UL transmissions on PUSCH. Here, the DCI on the PDCCH is a downlink assignment (i.e., downlink grant; DL grant) including at least modulation and coding format and resource allocation information related to the downlink shared channel, or uplink It includes an uplink grant (UL grant) including a modulation and coding format and resource allocation information related to a shared channel.

Referring to FIG. 2 , an initial access (IA) procedure in a 5G communication system will be additionally described.

The UE may perform cell search, system information acquisition, beam alignment for initial access, DL measurement, and the like based on the SSB. The SSB is mixed with an SS/PBCH (Synchronization Signal/Physical Broadcast channel) block.

SSB consists of PSS, SSS and PBCH. The SSB is configured in four consecutive OFDM symbols, and PSS, PBCH, SSS/PBCH or PBCH are transmitted for each OFDM symbol. PSS and SSS consist of 1 OFDM symbol and 127 subcarriers, respectively, and PBCH consists of 3 OFDM symbols and 576 subcarriers.

Cell discovery refers to a process in which the UE acquires time/frequency synchronization of a cell, and detects a cell ID (Identifier) (eg, Physical layer Cell ID, PCI) of the cell. PSS is used to detect a cell ID within a cell ID group, and SSS is used to detect a cell ID group. PBCH is used for SSB (time) index detection and half-frame detection.

There are 336 cell ID groups, and there are 3 cell IDs for each cell ID group. There are a total of 1008 cell IDs. Information on the cell ID group to which the cell ID of the cell belongs is provided/obtained through the SSS of the cell, and information on the cell ID among 336 cells in the cell ID is provided/obtained through the PSS

The SSB is transmitted periodically according to the SSB period (periodicity). The SSB basic period assumed by the UE during initial cell discovery is defined as 20 ms. After cell access, the SSB period may be set to one of {5ms, 10ms, 20ms, 40ms, 80ms, 160ms} by the network (eg, BS).

Next, the acquisition of system information (SI) will be described.

The SI is divided into a master information block (MIB) and a plurality of system information blocks (SIB). SI other than MIB may be referred to as Remaining Minimum System Information (RMSI). The MIB includes information/parameters for monitoring the PDCCH scheduling the PDSCH carrying the System Information Block1 (SIB1) and is transmitted by the BS through the PBCH of the SSB. SIB1 includes information related to availability and scheduling (eg, transmission period, SI-window size) of the remaining SIBs (hereinafter, SIBx, where x is an integer of 2 or more). SIBx is included in the SI message and transmitted through the PDSCH. Each SI message is transmitted within a periodically occurring time window (ie, an SI-window).

Referring to FIG. 2 , a random access (RA) process in a 5G communication system will be additionally described.

The random access process is used for a variety of purposes. For example, the random access procedure may be used for network initial access, handover, and UE-triggered UL data transmission. The UE may acquire UL synchronization and UL transmission resources through a random access procedure. The random access process is divided into a contention-based random access process and a contention free random access process. The detailed procedure for the contention-based random access process is as follows.

The UE may transmit the random access preamble through the PRACH as Msg1 of the random access procedure in the UL. Random access preamble sequences having two different lengths are supported. The long sequence length 839 applies for subcarrier spacings of 1.25 and 5 kHz, and the short sequence length 139 applies for subcarrier spacings of 15, 30, 60 and 120 kHz.

When the BS receives the random access preamble from the UE, the BS sends a random access response (RAR) message (Msg2) to the UE. The PDCCH scheduling the PDSCH carrying the RAR is CRC-masked and transmitted with a random access (RA) radio network temporary identifier (RNTI) (RA-RNTI). The UE detecting the PDCCH masked by the RA-RNTI may receive the RAR from the PDSCH scheduled by the DCI carried by the PDCCH. The UE checks whether the random access response information for the preamble it has transmitted, that is, Msg1, is in the RAR. Whether or not random access information for Msg1 transmitted by itself exists may be determined by whether a random access preamble ID for the preamble transmitted by the UE exists. If there is no response to Msg1, the UE may retransmit the RACH preamble within a predetermined number of times while performing power ramping. The UE calculates the PRACH transmit power for the retransmission of the preamble based on the most recent path loss and power ramping counter.

The UE may transmit UL transmission on the uplink shared channel as Msg3 of the random access procedure based on the random access response information. Msg3 may include the RRC connection request and UE identifier. As a response to Msg3, the network may send Msg4, which may be treated as a contention resolution message on DL. By receiving Msg4, the UE can enter the RRC connected state.

C. Beam Management (BM) Procedure of 5G Communication System

The BM process may be divided into (1) a DL BM process using SSB or CSI-RS, and (2) a UL BM process using a sounding reference signal (SRS). In addition, each BM process may include Tx beam sweeping to determine a Tx beam and Rx beam sweeping to determine an Rx beam.

Let's look at the DL BM process using SSB.

A configuration for a beam report using the SSB is performed during channel state information (CSI)/beam configuration in RRC_CONNECTED.

- The UE receives from the BS a CSI-ResourceConfig IE including a CSI-SSB-ResourceSetList for SSB resources used for BM. The RRC parameter csi-SSB-ResourceSetList indicates a list of SSB resources used for beam management and reporting in one resource set. Here, the SSB resource set may be set to {SSBx1, SSBx2, SSBx3, SSBx4, ??}. The SSB index may be defined from 0 to 63.

- UE receives signals on SSB resources from the BS based on the CSI-SSB-ResourceSetList.

- When the CSI-RS reportConfig related to reporting on SSBRI and reference signal received power (RSRP) is configured, the UE reports the best SSBRI and RSRP corresponding thereto to the BS. For example, when the reportQuantity of the CSI-RS reportConfig IE is set to 'ssb-Index-RSRP', the UE reports the best SSBRI and the corresponding RSRP to the BS.

If the CSI-RS resource is configured in the same OFDM symbol(s) as the SSB, and 'QCL-TypeD' is applicable, the UE has the CSI-RS and the SSB similarly located in the 'QCL-TypeD' point of view ( quasi co-located, QCL). Here, QCL-TypeD may mean QCL between antenna ports in terms of spatial Rx parameters. When the UE receives signals of a plurality of DL antenna ports in a QCL-TypeD relationship, the same reception beam may be applied.

Next, a DL BM process using CSI-RS will be described.

The Rx beam determination (or refinement) process of the UE using the CSI-RS and the Tx beam sweeping process of the BS will be described in a normal order. In the UE Rx beam determination process, the repetition parameter is set to 'ON', and in the BS Tx beam sweeping process, the repetition parameter is set to 'OFF'.

First, a process of determining the Rx beam of the UE will be described.

- The UE receives the NZP CSI-RS resource set IE including the RRC parameter for 'repetition' from the BS through RRC signaling. Here, the RRC parameter 'repetition' is set to 'ON'.

- The UE repeats signals on the resource(s) in the CSI-RS resource set in which the RRC parameter 'repetition' is set to 'ON' in different OFDM symbols through the same Tx beam (or DL spatial domain transmission filter) of the BS receive

- The UE determines its own Rx beam.

- The UE omits CSI reporting. That is, the UE may omit the CSI report when the multi-RRC parameter 'repetition' is set to 'ON'.

Next, the Tx beam determination process of the BS will be described.

- The UE receives the NZP CSI-RS resource set IE including the RRC parameter for 'repetition' from the BS through RRC signaling. Here, the RRC parameter 'repetition' is set to 'OFF' and is related to the Tx beam sweeping process of the BS.

- The UE receives signals on resources in the CSI-RS resource set in which the RRC parameter 'repetition' is set to 'OFF' through different Tx beams (DL spatial domain transmission filter) of the BS.

- The UE selects (or determines) the best beam.

- The UE reports the ID (eg, CRI) and related quality information (eg, RSRP) for the selected beam to the BS. That is, when the CSI-RS is transmitted for the BM, the UE reports the CRI and the RSRP to the BS.

Next, a UL BM process using SRS will be described.

- The UE receives the RRC signaling (eg, SRS-Config IE) including the (RRC parameter) usage parameter set to 'beam management' from the BS. SRS-Config IE is used for SRS transmission configuration. The SRS-Config IE includes a list of SRS-Resources and a list of SRS-ResourceSets. Each SRS resource set means a set of SRS-resources.

- The UE determines Tx beamforming for the SRS resource to be transmitted based on the SRS-SpatialRelation Info included in the SRS-Config IE. Here, the SRS-SpatialRelation Info is set for each SRS resource and indicates whether to apply the same beamforming as that used in SSB, CSI-RS, or SRS for each SRS resource.

- If SRS-SpatialRelationInfo is configured in the SRS resource, the same beamforming as that used in SSB, CSI-RS, or SRS is applied and transmitted. However, if SRS-SpatialRelationInfo is not configured in the SRS resource, the UE arbitrarily determines Tx beamforming and transmits the SRS through the determined Tx beamforming.

Next, a beam failure recovery (BFR) process will be described.

In a beamformed system, Radio Link Failure (RLF) may frequently occur due to rotation, movement, or beamforming blockage of the UE. Therefore, BFR is supported in NR to prevent frequent RLF from occurring. BFR is similar to the radio link failure recovery process, and can be supported when the UE knows new candidate beam(s). For beam failure detection, the BS sets beam failure detection reference signals to the UE, and the UE determines that the number of beam failure indications from the physical layer of the UE is within a period set by the RRC signaling of the BS. When a threshold set by RRC signaling is reached (reach), a beam failure is declared (declare). after beam failure is detected, the UE triggers beam failure recovery by initiating a random access procedure on the PCell; Beam failure recovery is performed by selecting a suitable beam (if the BS provides dedicated random access resources for certain beams, these are prioritized by the UE). Upon completion of the random access procedure, it is considered that beam failure recovery has been completed.

D. URLLC (Ultra-Reliable and Low Latency Communication)

URLLC transmission defined in NR is (1) a relatively low traffic size, (2) a relatively low arrival rate (low arrival rate), (3) extremely low latency requirements (eg, 0.5, 1ms), (4) a relatively short transmission duration (eg, 2 OFDM symbols), and (5) transmission for an urgent service/message. In the case of UL, transmission for a specific type of traffic (eg, URLLC) is multiplexed with other previously scheduled transmissions (eg, eMBB) in order to satisfy a more stringent latency requirement. Needs to be. In this regard, as one method, information to be preempted for a specific resource is given to the previously scheduled UE, and the resource is used by the URLLC UE for UL transmission.

For NR, dynamic resource sharing between eMBB and URLLC is supported. eMBB and URLLC services may be scheduled on non-overlapping time/frequency resources, and URLLC transmission may occur on resources scheduled for ongoing eMBB traffic. The eMBB UE may not know whether the PDSCH transmission of the corresponding UE is partially punctured, and the UE may not be able to decode the PDSCH due to corrupted coded bits. In consideration of this, NR provides a preemption indication. The preemption indication may be referred to as an interrupted transmission indication.

With respect to the preemption indication, the UE receives the DownlinkPreemption IE through RRC signaling from the BS. When the UE is provided with the DownlinkPreemption IE, for monitoring the PDCCH carrying DCI format 2_1, the UE is configured with the INT-RNTI provided by the parameter int-RNTI in the DownlinkPreemption IE. The UE is additionally configured with a set of serving cells by INT-ConfigurationPerServing Cell including a set of serving cell indices provided by servingCellID and a corresponding set of positions for fields in DCI format 2_1 by positionInDCI, dci-PayloadSize It is established with the information payload size for DCI format 2_1 by , and is set with the indicated granularity of time-frequency resources by timeFrequencySect.

The UE receives DCI format 2_1 from the BS based on the DownlinkPreemption IE.

When the UE detects the DCI format 2_1 for the serving cell in the configured set of serving cells, the UE determines that the DCI format of the set of PRBs and the set of symbols of the monitoring period immediately preceding the monitoring period to which the DCI format 2_1 belongs. It can be assumed that there is no transmission to the UE in the PRBs and symbols indicated by 2_1. For example, the UE sees that the signal in the time-frequency resource indicated by the preemption is not the scheduled DL transmission for itself and decodes data based on the signals received in the remaining resource region.

E. mMTC (massive MTC)

mMTC (massive machine type communication) is one of the scenarios of 5G to support hyper-connectivity service that communicates simultaneously with a large number of UEs. In this environment, the UE communicates intermittently with a very low transmission rate and mobility. Therefore, mMTC is primarily aimed at how long the UE can run at a low cost. In relation to mMTC technology, 3GPP deals with MTC and NB (NarrowBand)-IoT.

The mMTC technology has features such as repeated transmission of PDCCH, PUCCH, physical downlink shared channel (PDSCH), PUSCH, and the like, frequency hopping, retuning, and guard period.

That is, a PUSCH (or PUCCH (particularly, long PUCCH) or PRACH) including specific information and a PDSCH (or PDCCH) including a response to specific information are repeatedly transmitted. Repeated transmission is performed through frequency hopping, and (RF) retuning is performed in a guard period from a first frequency resource to a second frequency resource for repeated transmission, and specific information And a response to specific information may be transmitted/received through a narrowband (ex. 6 RB (resource block) or 1 RB).

Driving

(1) Vehicle exterior

3 is a diagram illustrating a vehicle according to an embodiment of the present specification.

Referring to FIG. 3 , a vehicle 10 according to an exemplary embodiment of the present specification is defined as a transportation means traveling on a road or track. The vehicle 10 is a concept including a car, a train, and a motorcycle. The vehicle 10 may be a concept including all of an internal combustion engine vehicle having an engine as a power source, a hybrid vehicle having an engine and an electric motor as a power source, and an electric vehicle having an electric motor as a power source. The vehicle 10 may be a vehicle owned by an individual. The vehicle 10 may be a shared vehicle. The vehicle 10 may be an autonomous vehicle.

(2) Components of the vehicle

4 is a control block diagram of a vehicle according to an embodiment of the present specification.

Referring to FIG. 4 , the vehicle 10 includes a user interface device 200 , an object detection device 210 , a communication device 220 , a driving manipulation device 230 , a main ECU 240 , and a driving control device 250 . ), an autonomous driving device 260 , a sensing unit 270 , and a location data generating device 280 . The object detecting device 210 , the communication device 220 , the driving manipulation device 230 , the main ECU 240 , the driving control device 250 , the autonomous driving device 260 , the sensing unit 270 , and the location data generating device 280 may be implemented as electronic devices that each generate electrical signals and exchange electrical signals with each other.

1) User interface device

The user interface device 200 is a device for communication between the vehicle 10 and a user. The user interface device 200 may receive a user input and provide information generated in the vehicle 10 to the user. The vehicle 10 may implement a user interface (UI) or a user experience (UX) through the user interface device 200 . The user interface device 200 may include an input device, an output device, and a user monitoring device.

2) Object detection device

The object detection apparatus 210 may generate information about an object outside the vehicle 10 . The information about the object may include at least one of information on the existence of the object, location information of the object, distance information between the vehicle 10 and the object, and relative speed information between the vehicle 10 and the object. . The object detecting apparatus 210 may detect an object outside the vehicle 10 . The object detecting apparatus 210 may include at least one sensor capable of detecting an object outside the vehicle 10 . The object detecting apparatus 210 may include at least one of a camera, a radar, a lidar, an ultrasonic sensor, and an infrared sensor. The object detecting apparatus 210 may provide data on an object generated based on a sensing signal generated by a sensor to at least one electronic device included in the vehicle.

2.1) Camera

The camera may generate information about an object outside the vehicle 10 by using the image. The camera may include at least one lens, at least one image sensor, and at least one processor that is electrically connected to the image sensor to process a received signal, and generate data about the object based on the processed signal.

The camera may be at least one of a mono camera, a stereo camera, and an AVM (Around View Monitoring) camera. The camera may obtain position information of the object, distance information from the object, or relative speed information with the object by using various image processing algorithms. For example, the camera may acquire distance information and relative velocity information from an object based on a change in the size of the object over time from the acquired image. For example, the camera may acquire distance information and relative speed information with respect to an object through a pinhole model, road surface profiling, or the like. For example, the camera may acquire distance information and relative velocity information from an object based on disparity information in a stereo image obtained from the stereo camera.

The camera may be mounted at a position where a field of view (FOV) can be secured in the vehicle in order to photograph the outside of the vehicle. The camera may be disposed adjacent to the front windshield in the interior of the vehicle to acquire an image of the front of the vehicle. The camera may be placed around the front bumper or radiator grill. The camera may be disposed adjacent to the rear glass in the interior of the vehicle to acquire an image of the rear of the vehicle. The camera may be placed around the rear bumper, trunk or tailgate. The camera may be disposed adjacent to at least one of the side windows in the interior of the vehicle in order to acquire an image of the side of the vehicle. Alternatively, the camera may be disposed around a side mirror, a fender or a door.

2.2) Radar

The radar may generate information about an object outside the vehicle 10 using radio waves. The radar may include an electromagnetic wave transmitter, an electromagnetic wave receiver, and at least one processor that is electrically connected to the electromagnetic wave transmitter and the electromagnetic wave receiver, processes a received signal, and generates data for an object based on the processed signal. The radar may be implemented in a pulse radar method or a continuous wave radar method in terms of a radio wave emission principle. The radar may be implemented as a frequency modulated continuous wave (FMCW) method or a frequency shift keyong (FSK) method according to a signal waveform among continuous wave radar methods. The radar detects an object based on an electromagnetic wave, a time of flight (TOF) method or a phase-shift method, and detects the position of the detected object, the distance to the detected object, and the relative speed. can The radar may be placed at a suitable location outside of the vehicle to detect objects located in front, rear or side of the vehicle.

2.3) Lidar

The lidar may generate information about an object outside the vehicle 10 using laser light. The lidar may include at least one processor that is electrically connected to the light transmitter, the light receiver, and the light transmitter and the light receiver, processes the received signal, and generates data about the object based on the processed signal. . The lidar may be implemented in a time of flight (TOF) method or a phase-shift method. Lidar can be implemented as driven or non-driven. When implemented as a driving type, the lidar is rotated by a motor and can detect an object around the vehicle 10 . When implemented as a non-driven type, the lidar may detect an object located within a predetermined range with respect to the vehicle by light steering. Vehicle 100 may include a plurality of non-driven lidar. LiDAR detects an object based on a time of flight (TOF) method or a phase-shift method with a laser light medium, and calculates the position of the detected object, the distance to the detected object, and the relative speed. can be detected. The lidar may be placed at a suitable location outside of the vehicle to detect an object located in front, rear or side of the vehicle.

3) communication device

The communication apparatus 220 may exchange signals with a device located outside the vehicle 10 . The communication device 220 may exchange signals with at least one of an infrastructure (eg, a server, a broadcasting station), another vehicle, and a terminal. The communication device 220 may include at least one of a transmit antenna, a receive antenna, a radio frequency (RF) circuit capable of implementing various communication protocols, and an RF element to perform communication.

For example, the communication apparatus may exchange a signal with an external device based on C-V2X (Cellular V2X) technology. For example, the C-V2X technology may include LTE-based sidelink communication and/or NR-based sidelink communication. Contents related to C-V2X will be described later.

For example, communication devices communicate with external devices based on IEEE 802.11p PHY/MAC layer technology and IEEE 1609 Network/Transport layer technology-based Dedicated Short Range Communications (DSRC) technology or WAVE (Wireless Access in Vehicular Environment) standard. can be exchanged for DSRC (or WAVE standard) technology is a communication standard prepared to provide ITS (Intelligent Transport System) service through short-distance dedicated communication between in-vehicle devices or between roadside devices and in-vehicle devices. The DSRC technology may use a frequency of 5.9 GHz and may be a communication method having a data transmission rate of 3 Mbps to 27 Mbps. IEEE 802.11p technology can be combined with IEEE 1609 technology to support DSRC technology (or WAVE standard).

The communication apparatus of the present specification may exchange a signal with an external device using either one of the C-V2X technology or the DSRC technology. Alternatively, the communication apparatus of the present specification may exchange signals with an external device by hybridizing C-V2X technology and DSRC technology.

4) Driving control device

The driving operation device 230 is a device that receives a user input for driving. In the manual mode, the vehicle 10 may be driven based on a signal provided by the driving manipulation device 230 . The driving manipulation device 230 may include a steering input device (eg, a steering wheel), an acceleration input device (eg, an accelerator pedal), and a brake input device (eg, a brake pedal).

5) Main ECU

The main ECU 240 may control the overall operation of at least one electronic device included in the vehicle 10 .

6) drive control device

The drive control device 250 is a device that electrically controls various vehicle drive devices in the vehicle 10 . The drive control device 250 may include a power train drive control device, a chassis drive control device, a door/window drive control device, a safety device drive control device, a lamp drive control device, and an air conditioning drive control device. The power train drive control device may include a power source drive control device and a transmission drive control device. The chassis drive control device may include a steering drive control device, a brake drive control device, and a suspension drive control device. Meanwhile, the safety device drive control device may include a safety belt drive control device for seat belt control.

The drive control device 250 includes at least one electronic control device (eg, a control ECU (Electronic Control Unit)).

The pitch control device 250 may control the vehicle driving device based on a signal received from the autonomous driving device 260 . For example, the control device 250 may control a power train, a steering device, and a brake device based on a signal received from the autonomous driving device 260 .

7) autonomous driving device

The autonomous driving device 260 may generate a path for autonomous driving based on the obtained data. The autonomous driving device 260 may generate a driving plan for driving along the generated path. The autonomous driving device 260 may generate a signal for controlling the movement of the vehicle according to the driving plan. The autonomous driving device 260 may provide the generated signal to the driving control device 250 .

The autonomous driving apparatus 260 may implement at least one Advanced Driver Assistance System (ADAS) function. ADAS includes Adaptive Cruise Control (ACC), Autonomous Emergency Braking (AEB), Forward Collision Warning (FCW), Lane Keeping Assist (LKA), ), Lane Change Assist (LCA), Target Following Assist (TFA), Blind Spot Detection (BSD), Adaptive High Beam Control (HBA) , Auto Parking System (APS), Pedestrian Collision Warning System (PD Collision Warning System), Traffic Sign Recognition (TSR), Trafffic Sign Assist (TSA), Night Vision System At least one of a night vision (NV), a driver status monitoring system (DSM), and a traffic jam assist system (TJA) may be implemented.

The autonomous driving device 260 may perform a switching operation from the autonomous driving mode to the manual driving mode or a switching operation from the manual driving mode to the autonomous driving mode. For example, the autonomous driving device 260 may switch the mode of the vehicle 10 from the autonomous driving mode to the manual driving mode or from the manual driving mode to the autonomous driving mode based on a signal received from the user interface device 200 . can be converted to

8) Sensing unit

The sensing unit 270 may sense the state of the vehicle. The sensing unit 270 may include an inertial measurement unit (IMU) sensor, a collision sensor, a wheel sensor, a speed sensor, an inclination sensor, a weight sensor, a heading sensor, a position module, and a vehicle. It may include at least one of a forward/reverse sensor, a battery sensor, a fuel sensor, a tire sensor, a steering sensor, a temperature sensor, a humidity sensor, an ultrasonic sensor, an illuminance sensor, and a pedal position sensor. Meanwhile, an inertial measurement unit (IMU) sensor may include one or more of an acceleration sensor, a gyro sensor, and a magnetic sensor.

The sensing unit 270 may generate state data of the vehicle based on a signal generated by at least one sensor. The vehicle state data may be information generated based on data sensed by various sensors provided inside the vehicle. The sensing unit 270 may include vehicle attitude data, vehicle motion data, vehicle yaw data, vehicle roll data, vehicle pitch data, vehicle collision data, vehicle direction data, vehicle angle data, and vehicle speed. data, vehicle acceleration data, vehicle inclination data, vehicle forward/reverse data, vehicle weight data, battery data, fuel data, tire pressure data, vehicle interior temperature data, vehicle interior humidity data, steering wheel rotation angle data, vehicle exterior illumination Data, pressure data applied to the accelerator pedal, pressure data applied to the brake pedal, and the like may be generated.

9) Location data generating device

The location data generating device 280 may generate location data of the vehicle 10 . The location data generating apparatus 280 may include at least one of a Global Positioning System (GPS) and a Differential Global Positioning System (DGPS). The location data generating apparatus 280 may generate location data of the vehicle 10 based on a signal generated from at least one of GPS and DGPS. According to an embodiment, the location data generating apparatus 280 may correct the location data based on at least one of an Inertial Measurement Unit (IMU) of the sensing unit 270 and a camera of the object detecting apparatus 210 . The location data generating device 280 may be referred to as a Global Navigation Satellite System (GNSS).

The vehicle 10 may include an internal communication system 50 . A plurality of electronic devices included in the vehicle 10 may exchange signals via the internal communication system 50 . Signals may contain data. The internal communication system 50 may use at least one communication protocol (eg, CAN, LIN, FlexRay, MOST, Ethernet).

(3) Components of an autonomous driving device

5 is a control block diagram of an autonomous driving apparatus according to an embodiment of the present specification.

Referring to FIG. 5 , the autonomous driving device 260 may include a memory 140 , a processor 170 , an interface unit 180 , and a power supply unit 190 .

The memory 140 is electrically connected to the processor 170 . The memory 140 may store basic data for the unit, control data for operation control of the unit, and input/output data. The memory 140 may store data processed by the processor 170 . The memory 140 may be configured as at least one of ROM, RAM, EPROM, flash drive, and hard drive in terms of hardware. The memory 140 may store various data for the overall operation of the autonomous driving device 260 , such as a program for processing or controlling the processor 170 . The memory 140 may be implemented integrally with the processor 170 . According to an embodiment, the memory 140 may be classified into a sub-configuration of the processor 170 .

The interface unit 180 may exchange signals with at least one electronic device provided in the vehicle 10 in a wired or wireless manner. The interface unit 280 includes an object detecting device 210 , a communication device 220 , a driving manipulation device 230 , a main ECU 240 , a driving control device 250 , a sensing unit 270 , and a location data generating device. A signal may be exchanged with at least one of 280 by wire or wirelessly. The interface unit 280 may be composed of at least one of a communication module, a terminal, a pin, a cable, a port, a circuit, an element, and a device.

The power supply unit 190 may supply power to the autonomous driving device 260 . The power supply unit 190 may receive power from a power source (eg, a battery) included in the vehicle 10 and supply power to each unit of the autonomous driving apparatus 260 . The power supply unit 190 may be operated according to a control signal provided from the main ECU 240 . The power supply unit 190 may include a switched-mode power supply (SMPS).

The processor 170 may be electrically connected to the memory 140 , the interface unit 280 , and the power supply unit 190 to exchange signals. Processor 170, ASICs (application specific integrated circuits), DSPs (digital signal processors), DSPDs (digital signal processing devices), PLDs (programmable logic devices), FPGAs (field programmable gate arrays), processors (processors), controller It may be implemented using at least one of controllers, micro-controllers, microprocessors, and other electrical units for performing functions.

The processor 170 may be driven by power provided from the power supply 190 . The processor 170 may receive data, process data, generate a signal, and provide a signal while power is supplied by the power supply unit 190 .

The processor 170 may receive information from another electronic device in the vehicle 10 through the interface unit 180 . The processor 170 may provide a control signal to another electronic device in the vehicle 10 through the interface unit 180 .

The autonomous driving device 260 may include at least one printed circuit board (PCB). The memory 140 , the interface unit 180 , the power supply unit 190 , and the processor 170 may be electrically connected to the printed circuit board.

(4) Operation of autonomous driving device

6 is a signal flow diagram of an autonomous vehicle according to an embodiment of the present specification.

1) Receive operation

Referring to FIG. 6 , the processor 170 may perform a reception operation. The processor 170 may receive data from at least one of the object detecting device 210 , the communication device 220 , the sensing unit 270 , and the location data generating device 280 through the interface unit 180 . can The processor 170 may receive object data from the object detection apparatus 210 . The processor 170 may receive HD map data from the communication device 220 . The processor 170 may receive vehicle state data from the sensing unit 270 . The processor 170 may receive location data from the location data generating device 280 .

2) processing/judgment action

The processor 170 may perform a processing/determination operation. The processor 170 may perform a processing/determination operation based on the driving situation information. The processor 170 may perform a processing/determination operation based on at least one of object data, HD map data, vehicle state data, and location data.

2.1) Driving plan data generation operation

The processor 170 may generate driving plan data. For example, the processor 1700 may generate Electronic Horizon Data, which is understood as driving plan data within a range from a point where the vehicle 10 is located to a horizon. Horizon may be understood as a point in front of a preset distance from a point where the vehicle 10 is located based on a preset driving route The horizon is a point where the vehicle 10 is located along a preset driving route. It may mean a point to which the vehicle 10 can reach after a predetermined time from the point.

The electronic horizon data may include horizon map data and horizon pass data.

2.1.1) Horizon Map Data

The horizon map data may include at least one of topology data, road data, HD map data, and dynamic data. According to an embodiment, the horizon map data may include a plurality of layers. For example, the horizon map data may include a first layer matching topology data, a second layer matching road data, a third layer matching HD map data, and a fourth layer matching dynamic data. The horizon map data may further include static object data.

Topology data can be described as a map created by connecting road centers. The topology data is suitable for roughly indicating the location of the vehicle, and may be in the form of data mainly used in navigation for drivers. The topology data may be understood as data on road information excluding information on lanes. The topology data may be generated based on data received from an external server through the communication device 220 . The topology data may be based on data stored in at least one memory provided in the vehicle 10 .

The road data may include at least one of slope data of the road, curvature data of the road, and speed limit data of the road. The road data may further include data on an overtaking prohibited section. The road data may be based on data received from an external server through the communication device 220 . The road data may be based on data generated by the object detecting apparatus 210 .

HD map data includes detailed lane-by-lane topology information of the road, connection information of each lane, and characteristic information for vehicle localization (eg, traffic signs, Lane Marking/attributes, Road furniture, etc.). can The HD map data may be based on data received from an external server through the communication device 220 .

The dynamic data may include various dynamic information that may be generated on the road. For example, the dynamic data may include construction information, variable speed lane information, road surface condition information, traffic information, moving object information, and the like. The dynamic data may be based on data received from an external server through the communication device 220 . The dynamic data may be based on data generated by the object detection apparatus 210 .

The processor 170 may provide map data within a range from the point where the vehicle 10 is located to the horizon.

2.1.2) Horizon Pass Data

The horizon pass data may be described as a trajectory that the vehicle 10 can take within a range from a point where the vehicle 10 is located to the horizon. The horizon pass data may include data representing a relative probability of selecting any one road at a decision point (eg, a fork, a junction, an intersection, etc.). The relative probability may be calculated based on the time it takes to arrive at the final destination. For example, at the decision point, if the time taken to arrive at the final destination is shorter when selecting the first road than when selecting the second road, the probability of selecting the first road is higher than the probability of selecting the second road. can be calculated higher.

The horizon pass data may include a main path and a sub path. The main path may be understood as a track connecting roads with a high relative probability of being selected. The sub-path may diverge at at least one decision point on the main path. The sub-path may be understood as a trajectory connecting at least one road having a low relative probability of being selected from at least one decision point on the main path.

3) Control signal generation operation

The processor 170 may perform a control signal generating operation. The processor 170 may generate a control signal based on the Electronic Horizon data. For example, the processor 170 may generate at least one of a powertrain control signal, a brake device control signal, and a steering device control signal based on the electronic horizon data.

The processor 170 may transmit the generated control signal to the driving control device 250 through the interface unit 180 . The drive control device 250 may transmit a control signal to at least one of the power train 251 , the brake device 252 , and the steering device 253 .

V2X (Vehicle-to-Everything)

7 is an example of V2X communication to which this specification can be applied.

V2X communication is V2V (Vehicle-to-Vehicle), which refers to communication between vehicles, V2I (Vehicle to Infrastructure), which refers to communication between a vehicle and an eNB or RSU (Road Side Unit), vehicle and individual It includes communication between the vehicle and all entities, such as V2P (Vehicle-to-Pedestrian) and V2N (vehicle-to-network), which refers to communication between UEs possessed by (pedestrian, cyclist, vehicle driver, or passenger).

V2X communication may represent the same meaning as V2X sidelink or NR V2X, or may represent a broader meaning including V2X sidelink or NR V2X.

V2X communication is, for example, forward collision warning, automatic parking system, cooperative adaptive cruise control (CACC), loss of control warning, traffic queue warning, traffic vulnerable safety warning, emergency vehicle warning, when driving on a curved road. It can be applied to various services such as speed warning and traffic flow control.

V2X communication may be provided through a PC5 interface and/or a Uu interface. In this case, in a wireless communication system supporting V2X communication, specific network entities for supporting communication between the vehicle and all entities may exist. For example, the network entity may be a BS (eNB), a road side unit (RSU), a UE, or an application server (eg, a traffic safety server).

In addition, the UE performing V2X communication, as well as a general handheld UE (handheld UE), vehicle UE (V-UE (Vehicle UE)), pedestrian UE (pedestrian UE), BS type (eNB type) RSU, or UE It may mean an RSU of a UE type, a robot equipped with a communication module, and the like.

V2X communication may be performed directly between UEs, or may be performed through the network entity(s). A V2X operation mode may be divided according to a method of performing such V2X communication.

V2X communication is required to support the anonymity and privacy of the UE when using the V2X application so that an operator or a third party cannot track the UE identifier within the region where V2X is supported. do.

Terms frequently used in V2X communication are defined as follows.

- RSU (Road Side Unit): RSU is a V2X service capable device that can transmit/receive with a mobile vehicle using V2I service. In addition, RSU is a fixed infrastructure entity that supports V2X applications, and can exchange messages with other entities that support V2X applications. RSU is a term frequently used in the existing ITS specification, and the reason for introducing this term to the 3GPP specification is to make the document easier to read in the ITS industry. The RSU is a logical entity that combines the V2X application logic with the function of a BS (referred to as BS-type RSU) or UE (referred to as UE-type RSU).

- V2I service: A type of V2X service, in which one side is a vehicle and the other side is an entity belonging to the infrastructure.

- V2P service: A type of V2X service where one side is a vehicle and the other side is a device carried by an individual (eg, a portable UE device carried by a pedestrian, cyclist, driver or passenger).

- V2X service: A 3GPP communication service type involving a vehicle transmitting or receiving device.

-V2X enabled (enabled) UE: UE supporting the V2X service.

- V2V service: A type of V2X service, where both sides of the communication are vehicles.

- V2V communication range: Direct communication range between two vehicles participating in V2V service.

V2X applications, called Vehicle-to-Everything (V2X), are (1) vehicle-to-vehicle (V2V), (2) vehicle-to-infrastructure (V2I), (3) vehicle-to-network (V2N), (4) vehicle There are 4 types of pedestrians (V2P).

8 illustrates a resource allocation method in a sidelink in which V2X is used.

In the sidelink, different sidelink control channels (physical sidelink control channels, PSCCHs) may be allocated spaced apart in the frequency domain, and different physical sidelink shared channels (PSSCHs) may be allocated spaced apart from each other. Alternatively, different PSCCHs may be consecutively allocated in the frequency domain, and PSSCHs may also be allocated consecutively in the frequency domain.

NR V2X

To extend the 3GPP platform to the automotive industry during 3GPP Releases 14 and 15, support for V2V and V2X services in LTE was introduced.

The requirements for support for the enhanced (enhanced) V2X use case are largely organized into four use case groups.

(1) Vehicle Platooning allows vehicles to dynamically form platoons that move together. All vehicles in the Platoon get information from the lead vehicle to manage this Platoon. This information allows vehicles to drive more harmoniously than normal, go in the same direction and drive together.

(2) extended sensors are collected through a local sensor or a live video image in a vehicle, a road site unit, a pedestrian device, and a V2X application server raw (raw) ) or to exchange processed data. Vehicles can increase their environmental awareness beyond what their sensors can detect, and provide a broader and holistic picture of local conditions. A high data rate is one of the main characteristics.

(3) Advanced driving enables semi-automatic or fully-automatic driving. Each vehicle and/or RSU shares self-awareness data obtained from local sensors with nearby vehicles, allowing the vehicle to synchronize and coordinate its trajectory or maneuver. Each vehicle shares driving intent with the proximity-driving vehicle.

(4) Remote driving enables remote drivers or V2X applications to drive remote vehicles by themselves or for passengers who cannot drive with remote vehicles in hazardous environments. When variability is limited and routes can be predicted, such as in public transport, driving based on cloud computing can be used. High reliability and low latency are key requirements.

Identifier for V2X communication through PC5

Each terminal has a Layer-2 identifier for V2 communication through one or more PC5. This includes a source Layer-2 ID and a destination Layer-2 ID.

The source and destination Layer-2 IDs are included in the Layer-2 frame, and the Layer-2 frame is transmitted over the layer-2 link of PC5 that identifies the source and destination of Layer-2 on the frame.

Source and destination Layer-2 ID selection of the terminal is based on the communication mode of V2X communication of PC5 of the layer-2 link. The source Layer-2 ID may be different between different communication modes.

If IP-based V2X communication is allowed, the terminal sets the link-local IPv6 address to be used as the source IP address. The UE may use this IP address for V2X communication of PC5 without sending a Neighbor Solicitation and Neighbor Advertisement message for duplicate address discovery.

If one terminal has an activated V2X application that requires privacy protection supported in the current geographic area, the source terminal (eg, vehicle) is tracked or identified from other terminals only for a specific time, source Layer- 2 IDs change over time and can be randomized. In the case of IP-based V2X communication, the source IP address must also change over time and must be randomized.

The change of identifiers of the source terminal should be synchronized in the layer used for PC5. That is, if the application layer identifier is changed, the change of the source Layer-2 ID and the source IP address is also required.

Broadcast mode

9 is a diagram illustrating a procedure for a broadcast mode of V2X communication using PC5.

One. The receiving terminal determines a destination Layer-2 ID for broadcast reception. The destination Layer-2 ID is transmitted to the AS layer of the receiving terminal for reception.

2. The V2X application layer of the transmitting terminal may provide a data unit, and may provide V2X application requirements (Application Requirements).

3. The transmitting terminal determines the destination Layer-2 ID for the broadcast. The transmitting terminal itself allocates a source Layer-2 ID.

4. One broadcast message transmitted by the transmitting terminal transmits V2X service data using a source Layer-2 ID and a destination Layer-2 ID.

The above salpin 5G communication technology may be applied in combination with the methods proposed in the present specification to be described later, or may be supplemented to specify or clarify the technical characteristics of the methods proposed in the present specification.

MEC Server

10 illustrates an architecture of a Mobile Edge Computing (MEC) server that can be applied in the present specification.

In addition to being able to perform the role of a general server, the MEC server is connected to the base station (BS) next to the road within the RAN (Radio Access Network) to provide flexible vehicle-related services and efficiently configure the network. makes it possible to operate In particular, network-slicing and traffic scheduling policies supported by the MEC server can help optimize the network.

In the architecture, the MEC servers are integrated in the RAN, and may be located in the S1-User plane interface (eg, between the core network and the base station) in the 3GPP system. Each MEC server can be considered as an independent network element, and does not affect the connection of an existing wireless network. The independent MEC server is connected to the base station through a dedicated communication network, and can provide specific services to several end-users located in the cell. The MEC server and the cloud server may be connected to each other through an internet-backbone and share information. In this architecture, the Internet-backbone is exemplified to be connected through a wired connection, but of course, it may be connected wirelessly according to a configuration method.

The MEC server operates independently and can control a plurality of base stations. In particular, it performs application operations such as services for autonomous vehicles and virtual machines (VMs) and operations at the edge of mobile networks based on virtualization platforms.

A base station (BS) is connected to both the MEC servers and the core network, enabling flexible user traffic scheduling required for performing the provided service.

The MEC server and the 3G radio network controller (RNC: Radio Network Controller) are located at a similar network level, but have the following differences.

- The number of base stations controlled by the RNC may be tens, hundreds, or more, and as the number of configured base stations increases, the occurrence of transmission delay increases. However, since the MEC server directly interacts with less than 10 base stations in general, excessive transmission delay can be prevented.

- In addition, the MEC server of this architecture not only provides efficient communication between the base station and the core network, but also allows the existing communication between the base stations and the communication between the base station and the core network. can be used in

- When a large amount of user traffic is generated in a specific cell, the MEC server may perform task offloading and cooperative processing based on the interface between adjacent base stations.

- While RNC provides only a fixed function for wireless network control, MEC server has an open operating environment based on software, so that new services from application providers can be easily provided.

The architecture with the MEC server can provide the following advantages.

- Reduction of service waiting time: Since the service is performed close to the end-user, the data round trip time is shortened and the service provision speed is fast.

- Flexible service provision: MEC applications and virtual network functions (VNFs) provide flexibility and geographic distribution in the service environment. Using this virtualization technology, various applications and network functions may be programmed, and only a specific user group may be selected or compilation may be possible only for them. Therefore, the services provided can be more closely adapted to user requirements.

- Collaboration between base stations: In addition to the central control capability, the MEC server can minimize the interaction between base stations. This may simplify a process for performing basic functions of the network, such as handover between cells. This feature can be particularly useful in autonomous driving systems with many users.

- Minimization of congestion: In the autonomous driving system, terminals on the road periodically generate a large number of small packets. By performing a specific service in the RAN, the MEC server can reduce the amount of traffic that needs to be delivered to the core network, thereby reducing the processing burden of the cloud in the centralized cloud system and minimizing network congestion. .

- Reduced operating costs: MEC server integrates network control functions and individual services, which can increase the profitability of Mobile Network Operators (MNOs), and enables quick and efficient maintenance and upgrades through adjustment of installation density. .

Hereinafter, various embodiments of the present specification will be described in detail with reference to the accompanying drawings.

For safe autonomous driving, a vehicle needs to secure reliable cognitive data. However, due to errors in sensors, recognition SW, and communication, the vehicle may fail to acquire accurate recognition data. For example, the sensing data of each sensor may be inconsistent. In more detail, inconsistency in sensing data may occur due to inconsistency according to the recognition performance of each sensor installed in the vehicle, failure of each sensor, or a temporary error. For example, the camera sensor may output abnormal lane information data (eg, skid marks, partially erased lanes, etc.). In addition, the camera/radar/lidar sensor may output abnormal object information (eg, foreign objects flying from the outside cover the sensor, or inaccurate calibration due to external shock/vibration, etc.).

As another example, a case in which LDM (Local Dynamic Map) data is inconsistent may occur. For example, an LDM in which real-time traffic conditions are not reflected may be provided due to a failure of a communication module, a temporary communication delay, or an unexpected situation. Through this, all cognitive data of the server, own vehicle, and other vehicle may be inconsistent, and the vehicle may require an appropriate response method.

To this end, in the present specification, a vehicle may acquire cognitive data from a server or another vehicle. In addition, the vehicle may compare and analyze the cognitive data based on the LDM received from the server and the cognitive data received from another vehicle. If the cognitive data of the server, vehicle, and other vehicle do not match, the vehicle may select cognitive data with higher reliability and perform judgment/control in response to errors in the cognitive data.

LDM (Local Dynamic Map)

LDM may include permanent/temporary static data (e.g., precision maps, road facilities, traffic signs, etc.) and dynamic data (e.g., traffic signals, real-time traffic information such as accident/congestion sections, pedestrians, etc.) . Accordingly, the vehicle may supplement the limitations of vehicle sensors by using the LDM, but may fail to acquire accurate recognition data due to problems such as sensor/communication errors. Therefore, in order to secure reliable data, a comparison of cognitive data between the LDM and the vehicle and surrounding vehicles is required for the vehicle.

11 is an example of an autonomous driving system using an LDM to which this specification can be applied.

Referring to FIG. 11 , the LDM is a precision electronic map-based dynamic information system, and may store static/dynamic information collected through vehicles and infrastructure. The autonomous driving system using the LDM may include a road facility, a road/traffic information collection and communication roadside installation (RSE), an LDM, a GPS local reception/control station, and an operation center (server).

The operation center can provide real-time information to vehicles by fusion of road traffic and surrounding vehicle conditions (dynamic information) based on a precision electronic map (static information) at the level of the lane. In addition, since there is a limit to the sensor recognition performance of an autonomous vehicle, cooperation between the road and the vehicle is required to secure safety.

12 is an example of an LDM to which this specification can be applied.

Referring to FIG. 12 , the LDM includes regulatory lines (eg, lanes, road boundary lines, stop lines, lane center lines) necessary for autonomous driving, road facilities (eg, median strips, tunnels, bridges, underpasses), and sign facilities. It is a precision road map that expresses (eg, a traffic safety sign, a road surface mark, a signal flag) in three dimensions, and may include four layers. For example, Layer 1 may contain persistent static data, precision electronic maps. Layer 2 may include information such as temporary static data, road facilities, and traffic signs. Layer 3 may include real-time traffic information such as temporary dynamic data, traffic signals/traffic information (eg, accident section, congestion section), and local weather information. Layer 4 may include data related to full-fledged autonomous vehicles, such as dynamic data and vehicle pedestrians.

Communication method and data format

13 is an example of a communication method to which this specification can be applied.

Referring to FIG. 13 , a vehicle 1300 may communicate with a server 1320 and another vehicle 1310 through V2X communication. Here, there may be a plurality of other vehicles 1310 . For example, the vehicle 1300 periodically transmits object data in a defined format to the server 1320 and other vehicles 1310 through V2X communication, or receives a request from the server 1320 and other vehicles 1310 . can be transmitted In addition, the vehicle 1300 periodically receives object data of a format defined through V2X communication to the server 1320 and other vehicle 1310, or requests from the server 1320 and other vehicle 1310 to receive can

Table 1 is an example of an object data format that can be applied in this specification.

Item Contents ID number of each object Time Absolute time at which each object data was acquired Class(Classification) Type of each object: pedestrian (adult, child), vehicle (sedan, SUV), bus, truck, special vehicle, two-wheeled vehicle, construction area, animal, static object (unknown), dynamic object (unknown) Class Status Pedestrians (leg length, backpack or not) Age Object Tracking Time Length Position X, Y object position Heading Object direction Velocity X, Y Object speed Acceleration X, Y Object acceleration Size (Width, Length, Height) Object size Position Covariance X, Y Distribution of Position data Heading Covariance Distribution of Heading Data Velocity Covariance X, Y Distribution of Velocity Data Acceleration Covariance X, Y Distribution of Acceleration Data acquisition sensor Camera, radar, lidar, ultrasound, server, other vehicles

Referring to Table 1, in the present specification, the state data of a specific object may include ID, position_x, position_y, heading, velocity_x, velocity_y , width, length, and height items related to the specific object.

14 is an example of critical data determination to which this specification can be applied.

Referring to FIG. 14 , the vehicle 1300 may determine critical data through V2X communication, based on received or generated object data.

In this specification, critical data may refer to object data related to a current location of the vehicle 1300 or an object approaching in a moving direction of the vehicle 1300 .

To determine this, the vehicle 1300 may use the current state data of the vehicle 1300 or the predicted route data for t (sec) predicted as a route generation result. Also, the vehicle 1300 may predict the expected path of the other object for t seconds in the future, based on object data related to the other object.

When there is a point where the shortest distance between the predicted path of the vehicle 1300 and the predicted path of another object is equal to or less than the reference distance, the vehicle 1300 may determine the corresponding object as a critical object.

Referring back to FIG. 14 , V2 may be determined as a critical object threatening the progress of the vehicle 1300 , and V1 and V3 may be determined as objects having no threat to the progress of the vehicle 1300 .

15 is an embodiment of a vehicle to which this specification can be applied.

Referring to FIG. 15 , sensing data may include object data related to a sensed object. In addition, the LDM data may include object data related to an object included in the LDM data.

The vehicle acquires first sensing data related to the sensed object through the sensor (S1500). For example, the first sensing data may be generated in the form of object data related to the sensed object.

The vehicle receives LDM data from the server (S1510). For example, the vehicle may generate object data related to an object included in the LDM data by using the LDM data.

The vehicle determines whether the data of the detected object in the LDM data matches the first sensed data (S1520). In more detail, the vehicle compares the object data of the generated detected object with the first sensed data through the LDM data, and whether the class is the same and the path of the detected object that can be predicted through the state data is within a certain range It can be determined whether or not If the Class is the same and the path of the detected object is within a predetermined range, the vehicle may determine that the data of the detected object in the LDM data and the first sensing data match.

When the data of the detected object in the LDM data and the first sensing data match, the vehicle performs a control operation using the LDM data or the first sensing data (S1530). Additionally, the vehicle may receive sensing data of another vehicle. To this end, the vehicle may broadcast a request message requesting sensing data to other nearby vehicles. The vehicle may receive sensing data from another vehicle as a response to this request message. If the location of the object included in the sensing data is a threat to the driving of the vehicle, the vehicle may also use the sensing data received from the other vehicle to perform a control operation. In more detail, when the object data included in the sensing data is determined to be critical data, the control operation can be performed by using the same together.

When the data of the detected object in the LDM data and the first sensed data do not match, the vehicle receives second sensed data related to the sensed object from another vehicle (S1540). For example, the second sensing data may be generated in the form of object data related to the sensed object.

The vehicle determines whether the data of the detected object in the LDM data matches the second sensed data (S1550). In more detail, the vehicle compares the object data of the generated detected object with the second sensing data through the LDM data, and whether the class is the same and the path of the detected object that can be predicted through the state data is within a certain range. It can be determined whether or not If the Class is the same and the path of the sensed object matches, the vehicle may determine that the data of the sensed object in the LDM data and the second sensed data match.

When the data of the detected object in the LDM data and the second sensing data match, the vehicle limits the autonomous driving function of the vehicle (S1560). For example, the vehicle may determine that there is an error in the first sensed data. Also, the vehicle may exclude the generated sensing data from the sensing data that may be used for the autonomous driving function through the sensor in which the first sensing data is generated. Accordingly, the vehicle may perform autonomous driving by using the LDM data or the second sensing data.

When the data of the object sensed in the LDM data and the second sensed data do not match, the vehicle determines whether the first sensed data and the second sensed data match ( S1570 ). In more detail, the vehicle may compare generated object data of the same object with each other through the first sensing data and the second sensing data.

When the first sensed data and the second sensed data match, the vehicle performs a control operation using the first sensed data (S1580).

When the first sensed data and the second sensed data do not match, the vehicle performs a control operation based on a set priority rule (S1590). For example, the priority rule may be set to (1) give priority to object data determined to exist in the front or (2) to prioritize object data determined to exist in the next lane. Alternatively, the priority rule may be set to prioritize object data determined as critiacl data.

As another example, a priority rule may be set according to a Class value or state data. In more detail, if the class value is different (eg, Object class 1 (pedestrian), Object class 2 (static information such as vehicle, construction, Unknown)), if it is set to give priority to the class value determined as a pedestrian, the vehicle determines that an object corresponding to class 1 (a pedestrian) exists in front, and can perform emergency braking. On the contrary, if static information such as vehicle, construction, etc. or class value of Unknown is set to be given priority, the vehicle may determine that an object corresponding to class 2 exists in front of the vehicle, and may change lanes.

As another example, when the Class values are the same but the state data are different, the priority rule may be set as follows.

(1) When the location information (x, y) is different, the object data determined to be located close to the vehicle is prioritized;

(2) If the magnitude of the velocity (v) is different, priority is given to object data having a high velocity value;

(3) when the direction of the speed v is different, priority is given to object data having the direction of the speed approaching the vehicle;

(4) If the size is different, the object data having a larger size is given priority;

If the priority rule is not determined, the vehicle may determine each object data as a separate object and perform a control operation.

In addition, the vehicle may broadcast a request message for requesting additional sensing data from surrounding vehicles.

Data comparison method

16 is an example of a data comparison method to which this specification can be applied. Referring to FIG. 16 , the vehicle receives object data from a server or another vehicle through the above-described communication method ( S1610 ).

The vehicle converts object data (S1620). For example, the vehicle may select object data related to a specific object. Also, for comparison of each object data, object data can be converted based on the same coordinate system. In more detail, for comparison of object data, the vehicle may convert object data based on a relative coordinate system based on (0,0,0) of the vehicle's location as a reference. Among the acquired object data, object data whose covariance is larger than the standard, the time is longer than the standard, or the age (for example, the time to track the object) is shorter than the standard is judged to have low reliability So, it may not be used.

The vehicle compares each object data (S1630). In more detail, the vehicle can compare the data of each object that has undergone coordinate transformation. For example, the vehicle compares the similarities of the position of the object, the velocity vector, the time data, etc. included in the object data, and determines that the difference is smaller than the reference value to match.

For example, the position comparison of objects can be calculated through the following equation.

|Position A - Position B| <thresh_position

In addition, the speed vector comparison of objects can be calculated through the following equation.

|Velocity A - Velocity B| <thresh_position

For example, a vehicle can trust two object data that match among three object data. However, the vehicle may use inconsistent object data. For example, if the variance of inconsistent object data is smaller than the standard, the time is recent information, and the age is greater than the standard, the vehicle may use the inconsistent object data.

Alternatively, the vehicle may use the inconsistent object data even when it is determined that the inconsistent object data is the aforementioned critical data.

If the vehicle compares 4 or more object data (eg, A, B, C, D, E, F), the vehicle groups object data with similar state data, Object data that does not match a group can also be used according to variance, time, and age values, as described above. Alternatively, the vehicle may determine whether object data that does not match a group including a plurality of object data is critical data. However, as the number of object data received by the vehicle increases, the reliability of the determined object will increase. Therefore, the vehicle may set a low level of use of inconsistent object data.

first embodiment

17 is an embodiment to which the present specification can be applied.

Referring to FIG. 17 , a case in which a pedestrian exists in front of a lane in which a vehicle travels is exemplified. Referring to FIG. 17A , when the vehicle uses the LDM received from the server, it may not be able to determine the pedestrian. Referring to FIG. 17( b ) , the vehicle may determine that there is an object in front using object data generated through a sensor, but may not determine whether the object is a pedestrian. Referring to FIG. 17(c) , the vehicle may determine that there is an object in front of it and that the object is a pedestrian through object data received from another vehicle.

Referring back to FIG. 17 , although the class value of each object data is different, the vehicle may set a priority rule such that the class value has priority over the pedestrian object data. In this case, the vehicle may determine that there is a pedestrian in front, and may perform an emergency stop for emergency avoidance or safety of the pedestrian.

second embodiment

18 is an embodiment to which the present specification can be applied.

Referring to FIG. 18( a ) , the vehicle may select object data to be compared and verified in order to secure reliability from among object data of various objects generated through sensing data. For example, the vehicle may select object data of an object located closest to it, or may select object data of an object having the lowest reliability value of sensing data generated through a sensor. In more detail, the vehicle may select the first object data according to the above criteria.

Referring to FIG. 18(b) , the vehicle may compare the velocity vectors of object data of other vehicles. In more detail, when the speed vectors of the server, the other vehicle, and the object data generated through the vehicle all do not match, the vehicle may prioritize specific object data and perform a control operation according to the above-described priority rule. For example, the vehicle may select object data having oncoming speed vector information, and may determine that there is an oncoming object according to the object data, and may decelerate or change lanes to avoid it.

third embodiment

19 is an embodiment to which the present specification can be applied.

Referring to FIG. 19 , the leader vehicle may form a group with the slave vehicles to perform platooning driving. This platooning operation can be performed through the leader vehicle.

For example, a leader vehicle may not detect a third vehicle when using LDM. In addition, the object data generated through the sensor of the leader vehicle may not detect the third vehicle due to the limitation of the sensing range or occlusion by the slave vehicles in the rear. On the other hand, among the slave vehicles, the slave vehicle 1910 located at the rear may sense the third vehicle through a sensor and generate object data of the third vehicle. In this case, the leader vehicle may have priority over the object data of the slave vehicle 1910 located in the rear while the leader vehicle performs a lane change to avoid the obstacle 1900 .

4th embodiment

20 is an embodiment to which the present specification can be applied.

Referring to FIG. 20 , a vehicle may detect an object by using object data generated through a server, a vehicle, or another vehicle. For example, Object-1 may be an object detected using object data generated through a server and a vehicle. Also, Object-2 may be an object detected by using object data generated through another vehicle.

As described above, in general, when two object data are the same, the vehicle may perform autonomous driving using the same object data. However, if there is an element that may threaten the driving of the vehicle, the vehicle can perform autonomous driving using other object data as well.

To this end, when the data of the detected object in the LDM data and the first sensing data of the vehicle match (S1520), the vehicle performs a control operation using the LDM data and the first sensing data (S1530) and at the same time another vehicle The second sensing data may be received from When the position of the object determined using the information of the object in the object data generated through the second sensing data threatens the driving of the vehicle (eg, object data generated through the second sensing data) is determined as critical data), the vehicle may drive by using the generated object data through the second sensing data.

Referring back to FIG. 20 , the vehicle detects Object-1, performs a control operation, and simultaneously receives object data for Object-2 from another vehicle. As it is judged that it poses a threat, the vehicle can change lanes or make an emergency stop to avoid Object-2.

General devices to which this specification can be applied

Hereinafter, an apparatus to which the present specification can be applied will be described.

21 shows a wireless communication device according to an embodiment of the present specification.

Referring to FIG. 21 , a wireless communication system may include a first device 9010 and a second device 9020 .

The first device 9010 includes a base station, a network node, a transmitting terminal, a receiving terminal, a wireless device, a wireless communication device, a vehicle, a vehicle equipped with an autonomous driving function, a connected car, a drone (Unmanned Aerial Vehicle, UAV), Artificial Intelligence (AI) Module, Robot, AR (Augmented Reality) Device, VR (Virtual Reality) Device, MR (Mixed Reality) Device, Hologram Device, Public Safety Device, MTC Device, IoT Device, Medical Device, Pin It may be a tech device (or financial device), a security device, a climate/environment device, a device related to 5G services, or other devices related to the 4th industrial revolution field.

The second device 9020 includes a base station, a network node, a transmitting terminal, a receiving terminal, a wireless device, a wireless communication device, a vehicle, a vehicle equipped with an autonomous driving function, a connected car, a drone (Unmanned Aerial Vehicle, UAV), Artificial Intelligence (AI) Module, Robot, AR (Augmented Reality) Device, VR (Virtual Reality) Device, MR (Mixed Reality) Device, Hologram Device, Public Safety Device, MTC Device, IoT Device, Medical Device, Pin It may be a tech device (or financial device), a security device, a climate/environment device, a device related to 5G services, or other devices related to the 4th industrial revolution field.

For example, the terminal includes a mobile phone, a smart phone, a laptop computer, a digital broadcasting terminal, personal digital assistants (PDA), a portable multimedia player (PMP), a navigation system, a slate PC, and a tablet. PC (tablet PC), ultrabook (ultrabook), wearable device (wearable device, for example, a watch-type terminal (smartwatch), glass-type terminal (smart glass), HMD (head mounted display), etc. may be included. . For example, the HMD may be a display device worn on the head. For example, an HMD may be used to implement VR, AR or MR.

For example, the drone may be a flying vehicle that does not ride by a person and flies by a wireless control signal. For example, the VR device may include a device that implements an object or a background of a virtual world. For example, the AR device may include a device that implements by connecting an object or background in the virtual world to an object or background in the real world. For example, the MR device may include a device that implements a virtual world object or background by fusion with a real world object or background. For example, the hologram device may include a device for realizing a 360-degree stereoscopic image by recording and reproducing stereoscopic information by utilizing an interference phenomenon of light generated by the meeting of two laser beams called holography. For example, the public safety device may include an image relay device or an image device that can be worn on a user's body. For example, the MTC device and the IoT device may be devices that do not require direct human intervention or manipulation. For example, the MTC device and the IoT device may include a smart meter, a bending machine, a thermometer, a smart light bulb, a door lock, or various sensors. For example, a medical device may be a device used for the purpose of diagnosing, treating, alleviating, treating, or preventing a disease. For example, a medical device may be a device used for the purpose of diagnosing, treating, alleviating or correcting an injury or disorder. For example, a medical device may be a device used for the purpose of examining, replacing, or modifying structure or function. For example, the medical device may be a device used for the purpose of controlling pregnancy. For example, the medical device may include a medical device, a surgical device, an (ex vivo) diagnostic device, a hearing aid, or a device for a procedure. For example, the security device may be a device installed to prevent a risk that may occur and maintain safety. For example, the security device may be a camera, CCTV, recorder or black box. For example, the fintech device may be a device capable of providing financial services such as mobile payment. For example, the fintech device may include a payment device or a Point of Sales (POS). For example, the climate/environment device may include a device for monitoring or predicting the climate/environment.

The first device 9010 may include at least one processor such as a processor 9011 , at least one memory such as a memory 9012 , and at least one transceiver such as a transceiver 9013 . The processor 9011 may perform the functions, procedures, and/or methods described above. The processor 9011 may perform one or more protocols. For example, the processor 9011 may perform one or more layers of an air interface protocol. The memory 9012 is connected to the processor 9011 and may store various types of information and/or instructions. The transceiver 9013 may be connected to the processor 9011 and may be controlled to transmit/receive a wireless signal.

The second device 9020 may include at least one processor such as a processor 9021 , at least one memory device such as a memory 9022 , and at least one transceiver such as a transceiver 9023 . The processor 9021 may perform the functions, procedures, and/or methods described above. The processor 9021 may implement one or more protocols. For example, the processor 9021 may implement one or more layers of an air interface protocol. The memory 9022 is connected to the processor 9021 and may store various types of information and/or commands. The transceiver 9023 may be connected to the processor 9021 and may be controlled to transmit/receive a wireless signal.

The memory 9012 and/or the memory 9022 may be respectively connected inside or outside the processor 9011 and/or the processor 9021, and may be connected to another processor through various technologies such as wired or wireless connection. may be connected to

The first device 9010 and/or the second device 9020 may have one or more antennas. For example, antenna 9014 and/or antenna 9024 may be configured to transmit and receive wireless signals.

22 illustrates a block diagram of a network node according to an embodiment of the present specification.

In particular, in FIG. 22, when the base station is divided into a central unit (CU) and a distributed unit (DU), it is a diagram illustrating the network node of FIG. 21 in more detail.

Referring to FIG. 22 , base stations W20 and W30 may be connected to the core network W10 , and the base station W30 may be connected to a neighboring base station W20 . For example, the interface between the base stations W20 and W30 and the core network W10 may be referred to as NG, and the interface between the base station W30 and the neighboring base station W20 may be referred to as Xn.

The base station W30 may be divided into CUs W32 and DUs W34 and W36. That is, the base station W30 may be hierarchically separated and operated. The CU W32 may be connected to one or more DUs W34 and W36, for example, an interface between the CU W32 and the DUs W34 and W36 may be referred to as F1. The CU (W32) may perform functions of upper layers of the base station, and the DUs (W34, W36) may perform functions of lower layers of the base station. For example, the CU W32 is a radio resource control (RRC), service data adaptation protocol (SDAP), and packet data convergence protocol (PDCP) layer of a base station (eg, gNB) hosting a logical node (logical node) , and the DUs W34 and W36 may be logical nodes hosting radio link control (RLC), media access control (MAC), and physical (PHY) layers of the base station. Alternatively, the CU W32 may be a logical node hosting the RRC and PDCP layers of the base station (eg, en-gNB).

The operation of the DUs W34 and W36 may be partially controlled by the CU W32. One DU (W34, W36) may support one or more cells. One cell can be supported by only one DU (W34, W36). One DU (W34, W36) may be connected to one CU (W32), and one DU (W34, W36) may be connected to a plurality of CUs by appropriate implementation.

23 illustrates a block diagram of a communication device according to an embodiment of the present specification.

In particular, FIG. 23 is a diagram illustrating the terminal of FIG. 22 in more detail above.

Referring to FIG. 23 , the terminal includes a processor (or digital signal processor (DSP) (Y10), an RF module (or RF unit) (Y35), and a power management module (Y05). ), antenna (Y40), battery (Y55), display (Y15), keypad (Y20), memory (Y30), SIM card (SIM (Subscriber Identification Module) ) card) (Y25) (this configuration is optional), a speaker (Y45) and a microphone (Y50) may be included. The terminal may also include a single antenna or multiple antennas. can

The processor Y10 implements the functions, processes and/or methods proposed above. The layer of the air interface protocol may be implemented by the processor Y10.

The memory Y30 is connected to the processor Y10 and stores information related to the operation of the processor Y10. The memory Y30 may be inside or outside the processor Y10, and may be connected to the processor Y10 by various well-known means.

The user inputs command information such as a phone number by, for example, pressing (or touching) a button of the keypad Y20 or by voice activation using the microphone Y50. The processor Y10 receives such command information and processes it to perform an appropriate function, such as making a call to a phone number. Operational data may be extracted from the SIM card Y25 or the memory Y30. In addition, the processor Y10 may display command information or driving information on the display Y15 for the user to recognize and for convenience.

The RF module Y35 is connected to the processor Y10 to transmit and/or receive RF signals. The processor Y10 transmits command information to the RF module Y35 to transmit, for example, a radio signal constituting voice communication data to initiate communication. The RF module Y35 includes a receiver and a transmitter to receive and transmit a radio signal. The antenna Y40 functions to transmit and receive radio signals. When receiving a wireless signal, the RF module Y35 may forward the signal and convert the signal to baseband for processing by the processor Y10. The processed signal may be converted into audible or readable information output through the speaker Y45.

The embodiments described above are those in which the elements and features of the present specification are combined in a predetermined form. Each component or feature should be considered optional unless explicitly stated otherwise. Each component or feature may be implemented in a form that is not combined with other components or features. It is also possible to configure embodiments of the present specification by combining some components and/or features. The order of operations described in the embodiments of the present specification may be changed. Some features or features of one embodiment may be included in another embodiment, or may be replaced with corresponding features or features of another embodiment. It is obvious that claims that are not explicitly cited in the claims can be combined to form an embodiment or included as a new claim by amendment after filing.

Embodiments according to the present specification may be implemented by various means, for example, hardware, firmware, software, or a combination thereof. In the case of implementation by hardware, an embodiment of the present specification provides one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs ( field programmable gate arrays), a processor, a controller, a microcontroller, a microprocessor, and the like.

In the case of implementation by firmware or software, an embodiment of the present specification may be implemented in the form of a module, procedure, function, etc. that perform the functions or operations described above. The software code may be stored in the memory and driven by the processor. The memory may be located inside or outside the processor, and may transmit/receive data to and from the processor by various known means.

The above-described specification is permitted to be implemented as computer-readable code on a medium in which a program is recorded. The computer-readable medium includes all types of recording devices in which data readable by a computer system is stored. Examples of computer-readable media include Hard Disk Drive (HDD), Solid State Disk (SSD), Silicon Disk Drive (SDD), ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc. There is also a carrier wave (eg, transmission over the Internet) that is implemented in the form of. In addition, the computer may include a processor Y120 of the terminal. Accordingly, the above detailed description should not be construed as restrictive in all respects but as exemplary. The scope of this specification should be determined by a reasonable interpretation of the appended claims, and all modifications within the scope of equivalents of this specification are included in the scope of this specification.

Claims (20)

A method for comparing vehicle data in an autonomous driving system, the method comprising:
generating, through a sensor, first sensing data related to a specific object;
receiving, from a server, LDM (Local Dynamic Map) data related to the specific object;
receiving second sensing data related to the specific object from another vehicle when the first sensing data and the LDM data do not match, based on a comparison result of the first sensing data and the LDM data;
performing a control operation using the LDM data or the second sensing data when the LDM data and the second sensing data match based on a comparison result of the LDM data and the second sensing data; and
resetting the autonomous driving function so as not to use the sensing data generated through the sensor for autonomous driving;
Including, data comparison method.
According to claim 1,
Broadcasting a request message for requesting sensing data related to a surrounding object; and
receiving sensing data related to the surrounding object as a response to the request message;
Further comprising a, data comparison method.
According to claim 1,
When the LDM data and the second sensing data do not match, when the first sensing data and the second sensing data match, based on a comparison result of the first sensing data and the second sensing data, the performing a control operation using the first sensed data;
Further comprising a, data comparison method.
According to claim 1,
performing a control operation based on a preset priority rule when all of the first sensing data, the second sensing data, and the LDM data do not match;
Further comprising a, data comparison method.
5. The method of claim 4,
The priority rule is
Based on the location information of the specific object, the priority is set, a data comparison method.
5. The method of claim 4,
The priority rule is
Based on a classification result of the first sensing data, the second sensing data, and the LDM data, a priority is set, a data comparison method.
5. The method of claim 4,
The priority rule is
When the shortest distance between the predicted path of the specific object and the predicted path of the vehicle is less than or equal to a reference distance, data related to the specific object is set to be prioritized.
According to claim 1,
specifying, based on the plurality of first sensed data, the first sensed data to be subjected to the comparison method;
Further comprising a, data comparison method.
3. The method of claim 2,
and the vehicle is a leader vehicle of a platoon in which the other vehicle is a slave vehicle.
10. The method of claim 9,
When the LDM data and the second sensing data do not match, when the first sensing data and the second sensing data match, based on a comparison result of the first sensing data and the second sensing data, the performing a control operation using the first sensed data; and
performing a control operation based on a preset priority rule when all of the first sensing data, the second sensing data, and the LDM data do not match;
further comprising,
The priority rule is
data received from the other vehicle is set to be prioritized.
3. The method of claim 2,
performing a control operation using sensing data related to the surrounding object when the shortest distance between the predicted path of the surrounding object and the expected path of the vehicle is less than or equal to a reference distance;
Further comprising a, data comparison method.
In a vehicle for a data comparison method in an autonomous driving system,
sensor;
transceiver;
Memory; and
a processor operatively coupled to the sensor, the transceiver and the memory; includes,
the processor
Through the sensor, generating first sensing data related to a specific object,
Receives LDM (Local Dynamic Map) data related to the specific object from the server through the transceiver, and based on a comparison result of the first sensed data and the LDM data, the first sensed data and the LDM data are If there is a discrepancy, receive second sensing data related to the specific object from another vehicle,
Based on the comparison result of the LDM data and the second sensed data, when the LDM data and the second sensed data match, a control operation is performed using the LDM data or the second sensed data,
A vehicle for resetting an autonomous driving function in the memory in order not to use the sensed data generated through the sensor for autonomous driving.
13. The method of claim 12,
the processor
A vehicle that broadcasts a request message for requesting sensing data related to a surrounding object through the transceiver, and receives sensing data related to the surrounding object as a response to the request message.
13. The method of claim 12,
the processor
When the LDM data and the second sensing data do not match, when the first sensing data and the second sensing data match, based on a comparison result of the first sensing data and the second sensing data, the A vehicle that performs a control operation using the first sensed data.
13. The method of claim 12,
the processor
When all of the first sensing data, the second sensing data, and the LDM data do not match, the vehicle performs a control operation based on a priority rule preset in the memory.
16. The method of claim 15,
The priority rule is
Based on the location information of the specific object, a priority is set in the memory, the vehicle.
16. The method of claim 15,
The priority rule is
Based on a classification result of the first sensing data, the second sensing data, and the LDM data, a priority is set in the memory, the vehicle.
16. The method of claim 15,
The priority rule is
When the shortest distance between the predicted path of the specific object and the predicted path of the vehicle is less than or equal to a reference distance, the data related to the specific object is set in the memory to be prioritized.
13. The method of claim 12,
the processor
a vehicle for specifying the first sensed data to be subjected to the comparison method based on a plurality of the first sensed data.
14. The method of claim 13,
wherein the vehicle is a leader vehicle of a platoon in which the other vehicle is included as a slave vehicle.

Images