KR20210079945A - Distributiom of server resource using vehicle - Google Patents

Abstract

Disclosed is a resource distribution method of a server using vehicles. According to the present specification, the resource distribution method of a server relates to a method of distributing resources of the server for monitoring the status information of vehicles connected to the server and processing a task of requested vehicle. The resource distribution method includes the steps of: receiving a task and a request for processing the task from a requesting vehicle; setting a priority of the vehicle to process the requested task based on a communication state with the vehicles and computing capability of the vehicle; selecting an idle vehicle to request processing of the received task according to the set priority; transmitting the task and a processing request of the task to the selected idle vehicle; receiving a processing result of the task from the selected idle vehicle; and transmitting the processing result of the task to the request vehicle. The idle vehicle may include a processor in a standby state, and may be a vehicle in a state in which power is supplied from the outside. The server resource distribution method of the present specification distributes the server resources by using the resources of a vehicle including a computing device such as a processor.

Description

Distributing server resources using vehicles {DISTRIBUTIOM OF SERVER RESOURCE USING VEHICLE}

This specification relates to server resource distribution using a vehicle.

Recently, with the development of communication technologies such as 5G communication, the amount of data that one server must process is rapidly increasing. As described above, in order to solve the problem caused by the rapid increase of the resource of the server, a technology utilizing a multi-access edge computing (MEC) server or the like has recently been developed.

However, even if the MEC server is utilized, it is still necessary to distribute the resources of the server, for example, there are cases in which it is difficult for the MEC server to digest all of the rapidly increasing resources.

In addition, since the autonomous vehicle is connected to the MEC server and includes a processor with high performance and high stability for calculations required for autonomous driving, there is a need to utilize the resources of the autonomous vehicle in various ways.

An object of the present specification is to distribute resources of a server by using resources of a vehicle including a computing device such as a processor.

In addition, an object of the present specification is to distribute the resources of the server by using the resources of the vehicle in the idle state without affecting the computational capability related to the driving of the vehicle.

In addition, an object of the present specification is to distribute the resources of the server by using the resources in some cases even if the vehicle is not in an idle state.

In addition, the present specification aims to present various criteria for selecting a vehicle for distributing the server's resources.

The technical problems to be achieved by the present invention 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 the present invention belongs from the detailed description of the invention below. will be able to be understood

In order to solve the above problem, the present specification provides a resource distribution method of the server for monitoring status information of vehicles connected to the server and processing a task of the requested vehicle, the task and the Receiving a request for processing a task, setting a priority of a vehicle to process the requested task based on a communication state with the vehicles and computational capabilities of the vehicles, the receiving according to the set priority selecting an idle vehicle to request processing of the task, transmitting the task and a processing request of the task to the selected idle vehicle, receiving a processing result of the task from the selected idle vehicle, and and transmitting a processing result to the request vehicle, wherein the idle vehicle may be a vehicle in a state that includes a processor in a standby state and is supplied with external power.

In addition, the priority may be set in the order of the highest FLOPS value indicating the computing capability among vehicles having a round trip time (RTT) value indicating a communication state with the server equal to or less than a first RTT.

In addition, the step of selecting an idle vehicle to request processing of the received task may include selecting a plurality of idle vehicles based on a resource required for processing the task, and the sum of resources of the selected plurality of idle vehicles is the It can be greater than or equal to the required resource.

In this case, the transmitting of the processing result of the received task to the request vehicle may include integrating processing results received from the plurality of selected idle vehicles and transmitting the integrated processing result to the request vehicle.

In addition, the step of selecting the idle vehicle to request the processing of the received task may include selecting a first-type vehicle including a processor for multiple operations or a second-type vehicle including a processor for high-speed operation according to the characteristics of the task. is selected, and the characteristic of the task may include a first characteristic requiring the multiple operation and a second characteristic requiring the high-speed operation.

In this case, the step of transmitting the task and requesting processing of the task may include, when the characteristic of the task is the first characteristic, transmitting the task to the first type vehicle, and the characteristic of the task is the second characteristic. , the task may be transmitted to the second type vehicle.

In addition, the resource distribution method of the server includes the steps of detecting a total amount of resources used by the selected idle vehicle to process the task, and providing a reward to the selected idle vehicle based on the sensed total amount may include more.

Also, the server may be a Multi-Access Edge Computing (MEC) server.

In addition, the server may perform communication with the vehicles and the request vehicle based on 5G communication.

In addition, the resource distribution method of the server may include detecting a change in state information of the selected idle vehicle and reselecting an idle vehicle to request processing of the received task based on the detected change in state information .

Also, the change in the state information of the selected idle vehicle may include a change from the standby state to the active state, or termination of the charging.

In addition, the change in the state information of the selected vehicle may further include a change from the standby state to a turn-off state.

In order to solve the above problems, the present specification provides a server that processes a task of a requesting vehicle, is connected to idle vehicles for distributing resources, and monitors status information of the idle vehicles, a transceiver ( transceiver), a memory, and a processor for controlling the transceiver and the memory, wherein the processor is configured to prioritize the vehicles based on a communication state between the vehicles connected to the transceiver and the transceiver and computational capabilities of the vehicles set, select an idle vehicle to request processing of the received task based on the set priority, and request processing of the task from the selected idle vehicle, wherein the idle vehicle includes a processor in a standby state, , may be a vehicle in a state in which power is supplied from the outside.

In addition, the priority may be set in the order of the highest FLOPS value indicating the computing capability among vehicles having a round trip time (RTT) value indicating a communication state with the server equal to or less than a first RTT.

In addition, the processor may select a plurality of idle vehicles based on a resource required for processing the task, and a sum of resources of the plurality of selected idle vehicles may be greater than or equal to the required resource.

In addition, the processor may integrate the processing results received from the plurality of selected idle vehicles, and the transceiver may transmit the integrated processing results to the request vehicle.

In addition, the processor selects a first type vehicle including a processor for multiple operation or a second type vehicle including a processor for high-speed operation according to a characteristic of the task, and the characteristic of the task is that the multiple operation It may include a necessary first characteristic and a second characteristic requiring the high-speed operation.

Also, when the characteristic of the task is the first characteristic, the processor may select the first type vehicle, and the transceiver may transmit the task to the first type vehicle.

Also, when the characteristic of the task is the second characteristic, the processor may select the second type vehicle, and the transceiver may transmit the task to the second type vehicle.

Also, the processor may reselect the idle vehicle to request processing of the task based on a change in the state information of the idle vehicle.

In this case, the change in the state information of the idle vehicle may be that the processor in the standby state is changed to an active state, or a state in which power is supplied from the outside is terminated.

According to the present specification, there is an effect of distributing the resources of the server by using the resources of the vehicle including the computing device such as the processor.

In addition, according to the present specification, by using the resources of the vehicle in the idle state, there is an effect of distributing the resources of the server without affecting the computational capability related to the driving of the vehicle.

In addition, the present specification has an effect of distributing the resources of the server by using the resources in some cases even if the vehicle is not in an idle state.

In addition, this specification has the effect of presenting various criteria for selecting a vehicle for distributing the server's resources.

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 shows an example of basic operations of an autonomous vehicle and a 5G network in a 5G communication system.
4 shows an example of a vehicle-to-vehicle basic operation using 5G communication.
5 is an example of V2X communication to which this specification can be applied.
6 illustrates a resource allocation method in a sidelink in which V2X is used.
7 is a diagram illustrating a procedure for a broadcast mode of V2X communication using PC5.
8 is a diagram illustrating a vehicle of the present specification.
9 is a control block diagram of a vehicle according to the present specification.
10 illustrates an architecture of a Mobile Edge Computing (MEC) server that can be applied in the present specification.
11 is a diagram illustrating a resource distribution method of a server according to the first embodiment of the present specification.
12 is a diagram illustrating a task according to the first embodiment of the present specification.
13 is a diagram illustrating state information according to the first embodiment of the present specification.
14 is a diagram illustrating an example of a resource distribution method of a server according to the first embodiment of the present specification.
15 is a diagram illustrating an example of a resource distribution method of a server according to the first embodiment of the present specification.
16 is a diagram illustrating an example of a resource distribution method of a server according to the first embodiment of the present specification.
17 is a diagram illustrating an example of a resource distribution method of a server according to the first embodiment of the present specification.
18 is a diagram illustrating an example of a resource distribution method of a server according to the first embodiment of the present specification.
19 is a diagram illustrating an example of a resource distribution method of a server according to the first embodiment of the present specification.
20 is a diagram illustrating a method of using a vehicle list for resource distribution of a server according to the first embodiment of the present specification.
21 is a diagram illustrating a resource distribution method of a server according to whether or not state information of a vehicle is changed according to the first embodiment of the present specification.
22 is a diagram illustrating a resource distribution method of a server using a vehicle in a running state when an idle vehicle is in a running state according to the first embodiment of the present specification.
23 is a diagram illustrating a wireless communication device including a server according to a second embodiment of the present specification.
24 is a diagram illustrating a resource distribution system of a server according to a third embodiment of the present specification.
25 is a view illustrating a first type vehicle and a second type vehicle according to a third embodiment of the present specification.
26 is a view showing the overall operation of the resource distribution system according to the third 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 communication) 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 111 ports in terms of spatial Rx parameters. When the UE receives signals from a plurality of DL antenna 111 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 turn. 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 transmission (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 for repeated transmission, (RF) retuning is performed in a guard period from a first frequency resource to a second frequency resource, and specific information And a response to specific information may be transmitted/received through a narrowband (ex. 6 RB (resource block) or 1 RB).

F. Basic operation between autonomous vehicles using 5G communication

3 shows an example of basic operations of an autonomous vehicle and a 5G network in a 5G communication system.

The autonomous vehicle transmits specific information transmission to the 5G network (S1). The specific information may include autonomous driving-related information. Then, the 5G network may determine whether to remotely control the vehicle (S2). Here, the 5G network may include a server or module for performing remote control related to autonomous driving. In addition, the 5G network may transmit information (or signals) related to remote control to the autonomous vehicle (S3).

G. Application operation between autonomous vehicle and 5G network in 5G communication system

Hereinafter, the operation of the autonomous vehicle using 5G communication will be described in more detail with reference to FIGS. 1 and 2 and the above salpin wireless communication technology (BM procedure, URLLC, Mmtc, etc.).

First, the method proposed in this specification, which will be described later, and the basic procedure of the application operation to which the eMBB technology of 5G communication is applied will be described.

As in steps S1 and S3 of FIG. 3 , in order for the autonomous vehicle to transmit/receive signals and information to and from the 5G network, the autonomous vehicle performs an initial access procedure with the 5G network before step S1 of FIG. 3 . and a random access procedure.

More specifically, the autonomous vehicle performs an initial access procedure with the 5G network based on the SSB to obtain DL synchronization and system information. A beam management (BM) process and a beam failure recovery process may be added to the initial access procedure, and in the process of the autonomous vehicle receiving a signal from the 5G network, QCL (quasi-co location) ) relationship can be added.

In addition, the autonomous vehicle performs a random access procedure with the 5G network for UL synchronization acquisition and/or UL transmission. In addition, the 5G network may transmit a UL grant for scheduling transmission of specific information to the autonomous vehicle. Accordingly, the autonomous vehicle transmits specific information to the 5G network based on the UL grant. In addition, the 5G network transmits a DL grant for scheduling transmission of a 5G processing result for the specific information to the autonomous vehicle. Accordingly, the 5G network may transmit information (or signals) related to remote control to the autonomous vehicle based on the DL grant.

Next, the method proposed in the present specification to be described later and the basic procedure of the application operation to which the URLLC technology of 5G communication is applied will be described.

As described above, after the autonomous vehicle performs an initial access procedure and/or a random access procedure with the 5G network, the autonomous vehicle may receive a DownlinkPreemption IE from the 5G network. Then, the autonomous vehicle receives DCI format 2_1 including a pre-emption indication from the 5G network based on the DownlinkPreemption IE. In addition, the autonomous vehicle does not perform (or expect or assume) the reception of eMBB data in the resource (PRB and/or OFDM symbol) indicated by the pre-emption indication. Thereafter, the autonomous vehicle may receive a UL grant from the 5G network when it is necessary to transmit specific information.

Next, the method proposed in the present specification, which will be described later, and the basic procedure of the application operation to which the mMTC technology of 5G communication is applied will be described.

Among the steps of FIG. 3, the parts that are changed by the application of mMTC technology will be mainly described.

In step S1 of FIG. 3 , the autonomous vehicle receives a UL grant from the 5G network to transmit specific information to the 5G network. Here, the UL grant includes information on the number of repetitions for the transmission of the specific information, and the specific information may be repeatedly transmitted based on the information on the number of repetitions. That is, the autonomous vehicle transmits specific information to the 5G network based on the UL grant. In addition, repeated transmission of specific information may be performed through frequency hopping, transmission of the first specific information may be transmitted in a first frequency resource, and transmission of the second specific information may be transmitted in a second frequency resource. The specific information may be transmitted through a narrowband of 6RB (Resource Block) or 1RB (Resource Block).

H. Autonomous vehicle-to-vehicle operation using 5G communication

4 illustrates an example of a vehicle-to-vehicle basic operation using 5G communication.

The first vehicle transmits specific information to the second vehicle (S61). The second vehicle transmits a response to the specific information to the first vehicle (S62).

On the other hand, depending on whether the 5G network is directly (sidelink communication transmission mode 3) or indirectly (sidelink communication transmission mode 4) involved in the resource allocation of the specific information and the response to the specific information, the vehicle-to-vehicle application operation Configuration may vary.

Next, a vehicle-to-vehicle application operation using 5G communication will be examined.

First, how the 5G network is directly involved in resource allocation of vehicle-to-vehicle signal transmission/reception will be described.

The 5G network may transmit DCI format 5A to the first vehicle for scheduling of mode 3 transmission (PSCCH and/or PSSCH transmission). Here, a physical sidelink control channel (PSCCH) is a 5G physical channel for scheduling specific information transmission, and a physical sidelink shared channel (PSSCH) is a 5G physical channel for transmitting specific information. Then, the first vehicle transmits SCI format 1 for scheduling specific information transmission to the second vehicle on the PSCCH. Then, the first vehicle transmits specific information to the second vehicle on the PSSCH.

Next, how the 5G network is indirectly involved in resource allocation of signal transmission/reception will be examined.

The first vehicle senses a resource for mode 4 transmission in the first window. Then, the first vehicle selects a resource for mode 4 transmission in the second window based on the sensing result. Here, the first window means a sensing window, and the second window means a selection window. The first vehicle transmits SCI format 1 for scheduling of transmission of specific information to the second vehicle on the PSCCH based on the selected resource. Then, the first vehicle transmits specific information to the second vehicle on the PSSCH.

V2X (Vehicle-to-Everything)

5 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).

6 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.

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

7 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.

Driving

(1) Vehicle exterior

8 is a diagram illustrating a vehicle according to an embodiment of the present invention.

Referring to FIG. 8 , a vehicle 10 according to an exemplary embodiment of the present invention 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

9 is a control block diagram of a vehicle according to an embodiment of the present invention.

Referring to FIG. 9 , 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 a vehicle and a user. The user interface device 200 may receive a user input and provide information generated in the vehicle 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 data of the object, distance information between the vehicle 10 and the object, and relative speed information between the vehicle 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 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 data of an object, distance information with respect to the object, or relative speed information with respect to 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 in which a field of view (FOV) can be secured in the vehicle 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 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 in 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 by using the 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 objects around the vehicle. 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. The vehicle may include a plurality of non-driven lidars. 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. 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 220 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, the communication device 220 is based on the IEEE 802.11p PHY / MAC layer technology and the IEEE 1609 Network / Transport layer technology based on DSRC (Dedicated Short Range Communications) technology or WAVE (Wireless Access in Vehicular Environment) standard based on external It can exchange signals with devices. 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 220 of the present invention may exchange a signal with an external device by using only one of the C-V2X technology or the DSRC technology. Alternatively, the communication device 220 of the present invention may exchange a signal with an external device by hybridizing the C-V2X technology and the 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 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.

6) drive control device

The drive control device 250 is a device that electrically controls various vehicle drive devices in the vehicle. 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 (DSM), and a Traffic Jam Assist (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 change the mode of the vehicle from the autonomous driving mode to the manual driving mode or to switch the vehicle mode from the manual driving mode to the autonomous driving mode based on a signal received from the user interface device 200 . can

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 at least one 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. 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 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 may include an internal communication system 50 . A plurality of electronic devices included in the vehicle may exchange signals through 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).

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 various 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 can 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 consist of 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 the architecture provides efficient communication between the base station and the core network, as well as the existing communication between the base stations and the communication between the base station and the core network. It can be used in the network.

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

- While RNC provides only fixed functions for wireless network control, MEC server has an open operating environment based on software, so 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. .

- Reduction of 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. Do.

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

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

How to distribute resources on the server

Hereinafter, a method for distributing resources of a server according to the first preferred embodiment of the present specification will be described in detail based on the above contents.

In addition, the server resource distribution method according to the first embodiment of the present specification may be used in all devices or servers and systems requiring distribution of computing resources.

In addition, the server 100 according to the first embodiment of the present specification may be the MEC server of FIG. 10 .

11 is a diagram illustrating a resource distribution method of a server according to the first embodiment of the present specification.

The server 100 according to the first embodiment of the present specification may monitor status information of vehicles connected to the server 100 and process a task of the requested vehicle. In this case, the server 100 may monitor the state information of the vehicles connected to the server 100 in real time or monitor at a predetermined period.

The state information may include calculation capabilities of vehicles connected to the server 100 . In addition, the state information may be information on whether the vehicles connected to the server 100 correspond to any one of an idle state, a driving state, or a turn-off state.

Hereinafter, an idle vehicle in the present specification may refer to a vehicle in an idle state. The idle vehicle may refer to a vehicle in which a processor of the vehicle is in a standby state. In addition, the vehicle in an idle state may refer to a vehicle in a state in which power is supplied from outside. In addition, the vehicle in the idle state may refer to a vehicle in a state that includes a processor in a standby state and is supplied with power from the outside.

In addition, the request vehicle 101 of the present specification is an autonomous vehicle, and may refer to a vehicle capable of communicating with the server 100 based on a 5G communication standard.

According to FIG. 11 , in the method for distributing resources of a server according to the first embodiment of the present specification, the step of receiving a task and a processing request of the task from the requesting vehicle ( S1010 ), the server 100 and the communication state with the connected vehicles and setting a priority of a vehicle to process the requested task based on the computing capabilities of the vehicles (S1020), and selecting an idle vehicle to request processing of the received task according to the set priority (S1030) ), transmitting a request for processing the task and the received task to the selected idle vehicle (S1040), receiving a processing result of the task transmitted from the selected idle vehicle (S1050), and requesting the processing result of the task It may include transmitting to the vehicle (S1050).

Also, according to FIG. 11 , the server distribution method according to the present specification may further include a step ( S1070 ) of providing compensation to an idle vehicle that has provided a resource for resource distribution of the server.

In this case, the idle vehicle may be a vehicle in an idle state, including a processor in a standby state, and the idle vehicle may be a vehicle in a state supplied with external power.

In the step of receiving the task and the task processing request from the request vehicle ( S1010 ), a request message is received from the first vehicle 101 . In this case, the request message may include all signals and work data requested by the first vehicle 101 to the server 100 .

In the step of setting the priority of the vehicle to process the task ( S1020 ), the priority of the vehicles connected to the server 100 may be set based on a round trip time (RTT) value indicating a communication state. In addition, the server 100 may set priorities in the order of the highest FLOPS value indicating the computing capability of the processor included in the vehicle, among vehicles having the RTT value of the vehicles connected to the server 100 equal to or less than the first RTT.

The communication speed may be expressed as round trip time (RTT). The RTT may mean a value obtained by adding the time it takes for a signal to be transmitted and the time it takes to check the reception of the corresponding signal. In general, a unit of milliseconds (ms) may be used, but is not limited thereto.

Factors that affect RTT include communication distance (the distance a signal travels), transmission medium (copper wire, fiber optic cable, etc.), number of network hops (intermediate router, server, etc.), traffic level, and the response time of the server itself. may include In general, the RTT may have a high value as the communication distance and the number of network hops are large, and the RTT may have a high value as the traffic level is high or the response time of the server itself is large.

The first RTT may mean a specific numerical value capable of classifying a communication state into good and bad. The first RTT value may be changed according to a setting. The first RTT value of the present specification is described based on 80ms, but this is only an example and does not limit the scope of the present specification. If the RTT value is less than or equal to the first RTT value, the communication state may be smooth, and if the RTT value is greater than the first RTT value, the communication state may not be smooth.

The operation speed may be expressed as floating-point operations per second (FLOPS). FLOPS is a unit that represents the computational speed of a computer, and refers to how many floating-point instructions can be executed per second. In addition, the operation speed may be determined in consideration of the speed of each of the cores of the CPU and the number of cores. Also, the calculation speed may be expressed using Hz units instead of flops.

Accordingly, the server 100 may set a priority of a vehicle having the best computational capability among vehicles having a smooth communication state as the first priority. The server 100 may prioritize the vehicles according to the order of computing power among vehicles having a smooth communication state.

In addition, when setting the priority, the server 100 may set the priority only for idle vehicles among vehicles having a smooth communication state. That is, the server 100 may set priorities, except for vehicles in a driving state, among vehicles having a smooth communication state.

In the step of selecting the idle vehicle to request the task processing ( S1030 ), the idle vehicle may be selected based on the set priority. That is, if the vehicle having the first priority is an idle vehicle, the server 100 may select the vehicle and transmit the task. Also, the server 100 may transmit a task by selecting a vehicle having a first priority among idle vehicles. In this way, the step of selecting the idle vehicle ( S1030 ) is to select an optimal vehicle for resource distribution of the server.

Transmitting a request for processing the task and the received task to the selected idle vehicle (S1040), receiving a processing result of the task transmitted from the selected idle vehicle (S1050), and sending the processing result of the task to the request vehicle The transmitting step (S1050) may use V2X communication or wireless communication based on 5G communication standard.

In step S1050 of receiving the processing result of the task transmitted from the selected idle vehicle, not only receives the processing result of the task, but also detailed information such as time, resources, and power consumption required to process the task may include

The step of providing a reward to the idle vehicle that has provided the resource for resource distribution of the server ( S1070 ) may provide a reward to the idle vehicle that has provided the resource based on the detailed information. In this case, the provided reward may be a monetary reward or a reward that gives priority in receiving the service provision of the server 100 . In addition, the provided compensation may be to provide free time for the idle vehicle to use the server 100 by the amount of the provided resource.

In this way, by giving a reward to the idle vehicle that provides the resource, there is an effect of inducing the active participation of the idle vehicle.

12 is a diagram illustrating a task according to the first embodiment of the present specification.

According to FIG. 12 , all tasks requested from the requesting vehicle may have a priority, and a task having a priority may be referred to as an emergency task, and a task not having the priority may be referred to as a normal task.

The emergency task may include all computational tasks required for the vehicle to autonomously drive. In addition, the emergency task may include an obstacle detection and determination operation, a pedestrian detection and determination operation, and the like. In this case, the task of detecting and determining the obstacle may include a task of recognizing an object appearing on the driving path of the vehicle, such as detecting an object existing in the driving path of the vehicle and classifying the type of the detected object.

For example, if there is an object on the driving path of the vehicle and the object is recognized as a pedestrian, the vehicle may stop in front of the pedestrian or change the driving direction. In order for the vehicle to stop in front of a pedestrian, the driving speed and braking distance of the vehicle may also be calculated.

That is, the emergency task may mean a calculation operation related to driving of the vehicle. In addition, the emergency task may refer to all calculation tasks related to the safety of the vehicle and a driver of the vehicle.

The normal task may mean any computational work that is not required for decision-making of autonomous driving of the vehicle. The normal task may generally refer to a task such as collecting black box images and accident images, or transmitting the corresponding images.

Normal tasks, although not required to process quickly as described above, may occupy a relatively large amount of computing resources, which may place a heavy burden on the server 100 or the MEC server.

Accordingly, the server 100 according to the present specification may directly process an emergency task, and may distribute a normal task to other devices (idle vehicles). The resource distribution method of the server according to the present specification may mainly include content for distributing the normal task received from the request vehicle to the idle vehicle.

According to FIG. 12 , a characteristic of a normal task may be classified into a first characteristic or a second characteristic. The first characteristic may be a characteristic that requires multiple operations (or multi-operation), and the second characteristic may refer to a characteristic that requires high-speed operation.

For example, the first characteristic may be a characteristic that requires parallel processing of operations such as image operation, graphic operation, and the like. Since image or graphic processing requires calculation of a plurality of pixel information, multiple operations (or multiple operations) may be required.

For example, the second characteristic may be a characteristic requiring serial processing such as a mathematical operation. Therefore, a high-speed operation with a higher computing power may be required.

As such, whether the task is an emergency task or a normal task may be classified according to a preset criterion for the requested vehicle. After first checking whether the task included in the message received from the requesting vehicle is urgent, the server 100 may directly process an emergency task and perform resource distribution processing using an idle vehicle if it is a normal task.

In addition, whether the task is an emergency task or a normal task may be classified according to a criterion set in advance by the server 100 rather than the request vehicle. The server 100 may classify the task received from the request vehicle, directly process the urgent task, and perform resource distribution processing using the idle vehicle if it is a normal task.

13 is a diagram illustrating state information according to the first embodiment of the present specification.

Referring to FIG. 13 , state information in the present specification may refer to vehicle-related information for distributed processing of tasks. Specifically, it may mean whether the corresponding vehicle is currently in an idle state, a driving state, or a turned-off state.

Referring to FIG. 13 , the idle state of the vehicle may include a case in which a processor included in the current vehicle is in a standby state or a standby mode. Also, that the vehicle is in an idle state may include a case in which the vehicle is in a charging state. The charging state may include a state in which the battery is charged through a wired/wireless charging method in the case of an electric vehicle. Also, the charging state may refer to any state in which the vehicle receives power from the outside.

As such, the reason for including the charging state is that resources of the idle vehicle are continuously consumed for resource distribution of the server. That is, if power is not supplied from the outside, the idle vehicle is discharged of power. In addition, since the vehicle generally does not drive in a charging state, it is easy to utilize resources not used for driving.

The standby state (or standby mode) may mean a specific mode for saving power, although the power of the processor included in the vehicle is not turned off. The standby state may include a state in which work is stored in RAM, conserving power and waiting without terminating a running program. In general, a processor in a standby state saves power compared to a state in which the processor is activated, and has advantages in that a reboot can be performed faster than in a state in which the processor is turned off.

In addition, since battery consumption may exist even in the standby state, the standby state and the charging state may generally proceed together. In order to prevent power discharging of the idle vehicle during resource distribution processing, it is preferable to distribute the server's resources by transmitting the task to the idle vehicle in which the standby state and the charging state are performed simultaneously.

Referring to FIG. 13 , the driving state of the vehicle may mean the autonomous driving state. In such a driving state, since the resource of the vehicle must be fully used for driving, it is not preferable to perform the task transmitted from the server 100 . However, in some cases, work may be performed in the vehicle even in a limited driving state, and details will be described later.

Referring to FIG. 13 , that the vehicle is in a turn-off state includes a state in which a processor of the vehicle is not operated as a state in which the power is turned off. In this case, even if the server 100 requests status information from the vehicle, the vehicle in the turned-off state cannot transmit a response thereto. Therefore, to determine whether the vehicle is in the turned-off state, after the server 100 transmits a message requesting state information to the vehicle, if a response message is not received for more than a predetermined time, the vehicle is in the turned-off state. can be checked

In addition, since the turn-off state includes a case in which a response message is not received from the vehicle, a case in which power of the vehicle is not actually turned off may also be included. That is, the turn-off state may include a case in which communication of the vehicle becomes impossible or the vehicle is located outside the communication radius.

Referring to FIG. 13 , the vehicle's state information may also include the vehicle's arithmetic capability. Since the resource distribution method of the server according to the present specification uses a computing device such as a processor mounted on the vehicle, it is preferable to receive the computing capability information of the vehicle together.

In addition, the server 100 may receive state information including the computational capability of the vehicle, and appropriately distribute tasks based on the received computational capability. Specifically, the vehicles connected to the server may be classified into a first type vehicle and a second type vehicle according to the computing capability.

The first type vehicle has a number of cores greater than or equal to a certain number, and in general, may include a multi-core processor. Multi-core may refer to integrating two or more independent cores into one package consisting of a single integrated circuit. In general, dual-core, triple-core, quad-core, hexa-core, octa-core, Deca-core , and dodeca core (Dodeca-core) and the like, and the scope of the present specification is not limited thereto. The first type vehicle is preferably a quad-core or more, and may be suitable for a job that processes many calculations in parallel at the same time relatively.

The second type vehicle has a number of cores less than a certain number, and may generally include a single-core. The second type vehicle is preferably less than a quad-core, and may be suitable for a job requiring relatively high computational power in series.

Accordingly, the task of the first characteristic may be suitable for the first type vehicle, and the task of the second characteristic may be suitable for the second type vehicle.

14 is a diagram illustrating an example of a resource distribution method of a server according to the first embodiment of the present specification.

According to FIG. 14 , a first vehicle 101 , which is a requesting vehicle, requests the server 100 to perform a task and a task ( S101 ), and the server 100 sends the second vehicle 102 and the third vehicle 103 . ) can request status information (S102, S104). 14 , it appears that there is a time difference between S102 and S104, but in some cases, it may be performed simultaneously or S104 may be performed before S102.

In addition, although S102 and S104 appear to proceed after S101 in FIG. 14 , in some cases, the server 100 requests status information from the second vehicle 102 and the third vehicle 103 is performed in real time or It can be performed continuously with a certain period.

In response to the request for the above state information, the server 100 may receive state information including computation capability information from the second vehicle 102 and the third vehicle 103 ( S103 and S105 ). The state information of the second vehicle 102 may include information that the second vehicle 102 is in an idle state and information that the calculation capability of the second vehicle 102 is 0.5T flops. The state information of the third vehicle 103 may include information that the third vehicle 103 is in an idle state and information that the calculation capability of the third vehicle 103 is 1T flops.

The server 100 may analyze the required resource required to process the task received from the first vehicle as 1.5T flops (S106). Looking at the analysis result, it can be seen that the sum of the flops of the computational capabilities of the second vehicle 102 and the third vehicle 103 is 1.5T, which is a required resource. Accordingly, the server 100 may distribute the task received from the first vehicle 101 to the second vehicle 102 and the third vehicle 103 .

The server 100 may request the second vehicle 102 to perform a task as much as 0.5T flops and the corresponding task (S108), and the server 100 may receive the task processing result from the second vehicle 102 There is (S109).

In addition, the server 100 may request the third vehicle 103 to perform a task as much as 1T flops and the corresponding task ( S110 ), and the server 100 may receive the task processing result from the third vehicle 103 . can be (S111).

The server 100 may integrate the task processing results received from the second vehicle 102 and the third vehicle 103 ( S112 ), and transmit the integrated processing result to the first vehicle 101 ( 101 ). Also, the server 100 may provide a reward to the second vehicle 102 and the third vehicle 103 according to the task processing result (S114 and S115).

However, although the second vehicle 102 and the third vehicle 103 and specific numerical values are shown in FIG. 14 , this is only for convenience of description, and the scope of the present specification is not limited to these numerical values.

In addition, specific examples of distributing tasks according to required resources are as follows. The number below is not a value in a specific unit, but a size that indicates the size of a relative resource.

As an example, it is assumed that the resource required to perform a certain task is 100. Assuming that there are vehicles having 80 and 120 computing powers of available vehicles capable of distributing current resources, the server may transmit the above task to a vehicle having 120 computing capabilities.

As an example, it is assumed that the resource required to perform a certain task is 100. In this case, there are vehicles having a computing power of 10, 40, and 70 of available vehicles capable of distributing current resources. In this case, the server 100 may distribute and transmit the certain task to vehicles having 40 and 70 computational capabilities, respectively.

As an example, it is assumed that the resource required to perform a certain task is 100. In this case, the available vehicle has a single core having a computing power of 70. In addition, another available vehicle has a quad-core including four cores with a computing power of 30. In this case, the server 100 may transmit the certain task to a vehicle having a quad-core.

As an example, it is assumed that the resource required to perform a certain task is 100. In this case, the available vehicle has 100 computing power, but currently uses half 50. In this case, the resource of the half 50 in use may be processing a task requested from the other server 100 . Accordingly, the server 100 may further select other available vehicles capable of providing 50 or more resources.

In addition, when the server 100 distributes the task, a detailed distribution example according to the characteristics of the idle vehicle will be described as follows.

For example, it is assumed that the server 100 must distribute a task in order to perform a certain task. In this case, the vehicles connected to the server 100 may be connected using various communication standards. In particular, both 5G, which has been commercialized recently, and 4G, which is already widely used, can be used. Depending on the point of use, it may be connected using 6G or the next-generation communication standard specification. Accordingly, in the case of a task requiring faster processing, the server 100 may select an available vehicle in which a 5G antenna is installed rather than an available vehicle in which the 4G antenna is installed. Similarly, it is possible to select an available vehicle equipped with a 6G antenna rather than an available vehicle equipped with a 5G antenna. That is, it is possible to use the communication standard specification of a faster generation. In addition, the communication standard standard used by the available vehicle may be included in status information transmitted by the available vehicle to the server 100 .

15 is a diagram illustrating an example of a resource distribution method of a server according to the first embodiment of the present specification. Among the resource distribution method of the server according to FIG. 15, the content overlapping with FIG. 14 may be omitted, and will be described in detail below focusing on other content.

According to FIG. 15 , a first vehicle 101 , which is a requesting vehicle, requests the server 100 to perform a task and a task ( S201 ), and the server 100 sends the second vehicle 102 and the third vehicle 103 . ) can request status information (S202, S204). 15 , it appears that there is a time difference between S202 and S204, but in some cases, it may be performed simultaneously or S204 may be performed before S202.

Also, the server 100 may request vehicle status information and measure the communication status of the second vehicle 102 and the third vehicle 103 ( S202 and S204 ). In this way, by transmitting one signal and measuring the communication state at the same time, it is possible to reduce traffic and improve power and time efficiency.

However, in some cases, the communication state measurement may be performed separately from the state information request. The communication state measurement may be performed in real time or may be continuously performed with a predetermined period.

As a result of the communication state measurement, the RTT value between the server 100 and the second vehicle 102 is measured as 20 ms, and the RTT value between the server 100 and the third vehicle 103 is measured as 40 ms. Both RTT values are smaller than 80 ms (the first RTT value), and may be determined to be in a current smooth communication state. However, it can be seen that the communication state between the server 100 and the second vehicle 102 is smoother.

In addition, although S202 and S204 appear to proceed after S201 in FIG. 15 , in some cases, the server 100 requests status information from the second vehicle 102 and the third vehicle 103 is performed in real time or It can be performed continuously with a certain period.

In response to the request for the above state information, the server 100 may receive state information including computational capability information from the second vehicle 102 and the third vehicle 103 ( S203 and S205 ). The state information of the second vehicle 102 may include information that the second vehicle 102 is in an idle state and information that the calculation capability of the second vehicle 102 is 1T flops. The state information of the third vehicle 103 may include information that the third vehicle 103 is in an idle state and information that the calculation capability of the third vehicle 103 is 0.5T flops.

As such, the server 100 may set the priorities of the second vehicle 102 and the third vehicle 103 based on the RTT value and the flops value (S206). Since the communication state with the second vehicle 102 is smoother, the server 100 may set the priority of the second vehicle 102 as the first priority. Also, the server 100 may set the priority of the third vehicle 103 as the second priority. However, these priorities may be changed according to a change in communication state with each vehicle.

The server 100 may analyze a resource required for task processing (S207). As a result of the analysis, the required resource for processing the task was analyzed as 0.8T flops. Since the calculation capability of the second vehicle 102 is 1T flops, the server 100 may select the second vehicle 102 ( S208 ). Also, the server 100 may transmit a task to the second vehicle 102 and request execution of the task (S209).

The server 100 may receive the task processing result from the second vehicle 102 ( S210 ), and transmit the task processing result to the first vehicle 101 ( S211 ). Also, the server 100 may provide a reward for the task processing to the second vehicle 102 ( S212 ).

However, although the second vehicle 102 and the third vehicle 103 and specific numerical values are shown in FIG. 15 , this is only for convenience of description, and the scope of the present specification is not limited to these numerical values.

In addition, specific examples of distributing tasks in consideration of the RTT value and operation speed are as follows.

For example, if the communication speed RTT of the second vehicle 102 and the third vehicle 103 are both equal to or less than a constant value and the operation speed of the second vehicle 102 is faster than the operation speed of the third vehicle 103 , at this time The task execution request message may be transmitted to the second vehicle 102 having a high operation speed.

For example, if the communication speed RTT of the second vehicle 102 is equal to or less than a certain value and the communication speed RTT of the third vehicle 103 is greater than the constant value, in this case, the second vehicle ( 102), a task execution request message may be transmitted.

As an example, if the communication speed RTT of the second vehicle 102 and the third vehicle 103 is greater than a predetermined value, since the communication state of both vehicles is unstable, the task execution request message is not transmitted, and the server 100 directly corresponds work can be done.

16 is a diagram illustrating an example of a resource distribution method of a server according to the first embodiment of the present specification. Among the method for distributing resources of the server according to FIG. 16, the contents overlapping those of FIG. 14 or FIG. 15 may be omitted, and will be described in detail below focusing on other contents.

Referring to FIG. 16 , a first vehicle 101 , which is a requesting vehicle, requests the server 100 to perform a task and a task ( S301 ), and the server 100 sends a second vehicle 102 and a third vehicle 103 . ) can request status information (S302, S304). 16 , it seems that there is a time difference between S302 and S304, but in some cases, it may be performed simultaneously or S304 may be performed before S302.

In addition, although S302 and S304 appear to proceed after S301 in FIG. 16 , in some cases, the server 100 requests status information from the second vehicle 102 and the third vehicle 103 is performed in real time or It can be performed continuously with a certain period.

In response to the request for the above state information, the server 100 may receive state information including computing capability information from the second vehicle 102 and the third vehicle 103 ( S303 and S305 ). The state information of the second vehicle 102 may include information that the second vehicle 102 is in an idle state and information that the second vehicle 102 is a first type vehicle. The state information of the third vehicle 103 may include information that the third vehicle 103 is in an idle state and information that the third vehicle 103 is a second type vehicle.

In this way, the server 100 may distribute tasks according to the types of the second vehicle 102 and the third vehicle 103 . To this end, the server 100 analyzes the characteristic of the task requested from the first vehicle 101 ( S306 ), and depending on whether the characteristic of the task is the first characteristic or the second characteristic, the second vehicle or the third vehicle You can request to perform a task.

However, since various operations may be required for one task, one task may be divided into a task of a first characteristic and a task of a second characteristic. Accordingly, the server 100 may request execution while transmitting the task of the first characteristic divided from one task to the second vehicle 102 and the task of the second characteristic to the third vehicle 103 ( S308 , S310 ). ).

The server 100 may receive the task processing results from the second vehicle 102 and the third vehicle 103 (S309, S311), and the server 100 integrates the received task processing results (S312), The integrated processing results may be transmitted to the first vehicle 101 (S313).

Also, the server 100 may provide a reward for task processing to the second vehicle 102 and the third vehicle 103 ( S314 and S315 ).

However, although the second vehicle 102 and the third vehicle 103 and specific numerical values are shown in FIG. 16 , this is only for convenience of explanation, and the scope of the present specification is not limited to these numerical values.

17 is a diagram illustrating an example of a resource distribution method of a server according to the first embodiment of the present specification. Among the method for distributing resources of the server according to FIG. 17, the contents overlapping those of FIGS. 14, 15 or 16 may be omitted, and will be described in detail below focusing on other contents.

Referring to FIG. 17 , a first vehicle 101 , which is a requesting vehicle, requests the server 100 to perform a task and a task ( S401 ), and the server 100 sends the second vehicle 102 and the third vehicle 103 . ) can request status information (S402, S404). 17, it seems that there is a time difference between S402 and S404, but in some cases, it may be performed simultaneously or S404 may be performed before S342.

In addition, although S402 and S404 appear to be performed after S401 in FIG. 17 , in some cases, the server 100 requests status information from the second vehicle 102 and the third vehicle 103 is performed in real time or It can be performed continuously with a certain period.

In response to the request for the above state information, the server 100 may receive state information including computing capability information from the second vehicle 102 and the third vehicle 103 ( S403 and S405 ). The state information of the second vehicle 102 may include information that the second vehicle 102 is in a driving state and information that the calculation capability of the second vehicle 102 is 1T flops. The state information of the third vehicle 103 may include information that the third vehicle 103 is in an idle state and information that the calculation capability of the third vehicle 103 is 0.5T flops.

Also, the server 100 may request vehicle status information and measure the communication status of the second vehicle 102 and the third vehicle 103 ( S402 and S404 ). In this way, by transmitting one signal and measuring the communication state at the same time, it is possible to reduce traffic and improve power and time efficiency.

However, in some cases, the communication state measurement may be performed separately from the state information request. The communication state measurement may be performed in real time or may be continuously performed with a predetermined period.

As a result of the communication state measurement, the RTT value between the server 100 and the second vehicle 102 is measured as 20 ms, and the RTT value between the server 100 and the third vehicle 103 is measured as 40 ms. Both RTT values are smaller than 80 ms (the first RTT value), and may be determined to be in a current smooth communication state. However, it can be seen that the communication state between the server 100 and the second vehicle 102 is smoother.

The server 100 may set priorities of the second vehicle 102 and the third vehicle 103 based on the received state information ( S406 ). Since the second vehicle 102 is in the driving state, the server 100 may set the third vehicle 103 as the first priority. The server 100 may select the third vehicle 103, which is the first priority (S407).

The server 100 may transmit a task to the third vehicle 103, which is the first priority, and request to perform the task according to the set priority (S408). The server 100 may receive the task processing result from the third vehicle 103 ( S409 ) and transmit the task processing result to the first vehicle 101 ( S410 ).

Also, the server 100 may provide a reward for the task processing to the third vehicle 103 ( S411 ).

However, unlike FIG. 17 , the server 100 sets the second vehicle 102 as the first priority and the third vehicle 103 according to the communication speed and arithmetic capability of the second vehicle 102 . It can be set to 2nd priority. However, in this case, when the server 100 selects a vehicle, since the second vehicle 102 is in a running state, it does not transmit a task or request to perform a task, but transmits a task to the third vehicle having the next priority or requests to perform a task can do.

However, although the second vehicle 102 and the third vehicle 103 and specific numerical values are shown in FIG. 17 , this is only for convenience of explanation, and the scope of the present specification is not limited to these numerical values.

18 is a diagram illustrating an example of a resource distribution method of a server according to the first embodiment of the present specification. Among the resource distribution method of the server according to FIG. 18, the contents overlapping those of FIGS. 14 to 17 may be omitted, and other contents will be described in detail below.

Referring to FIG. 18 , a first vehicle 101 , which is a requesting vehicle, requests the server 100 to perform a task and a task ( S501 ), and the server 100 sends the second vehicle 102 and the third vehicle 103 . ) can request status information (S502, S504). 18 , it seems that there is a time difference between S502 and S504, but in some cases, it may be performed simultaneously or S504 may be performed before S502.

In addition, although S502 and S504 appear to be performed after S501 in FIG. 18 , in some cases, the server 100 requests status information from the second vehicle 102 and the third vehicle 103 is performed in real time or It can be performed continuously with a certain period.

According to the above status information request, the server 100 may wait for a response from the second vehicle 102 for a predetermined time. If there is no response from the second vehicle 102 even after a predetermined time has elapsed, the server 100 cannot measure the RTT (S503). That is, the server 100 may classify the state information of the second vehicle 102 as a turned-off state.

In addition, according to the request for the above state information, the server 100 may receive the state information including the computing capability information from the third vehicle 103 ( S505 ). The state information of the third vehicle 103 may include information that the third vehicle 103 is in an idle state and information that the calculation capability of the third vehicle 103 is 0.5T flops.

The server 100 may set priorities of the second vehicle 102 and the third vehicle 103 based on the received state information (S506). The server 100 may set the third vehicle 103 as the first priority because the second vehicle 102 is in the turned-off state. The server 100 may select the third vehicle 103, which is the first priority (S507).

The server 100 may transmit a task to the third vehicle 103, which is the first priority, and request to perform the task according to the set priority (S508). The server 100 may receive the task processing result from the third vehicle 103 ( S509 ) and transmit the task processing result to the first vehicle 101 ( S510 ).

Also, the server 100 may provide a reward for the task processing to the third vehicle 103 ( S511 ).

However, although the second vehicle 102 and the third vehicle 103 and specific numerical values are shown in FIG. 18 , this is only for convenience of explanation, and the scope of the present specification is not limited to these numerical values.

19 is a diagram illustrating an example of a resource distribution method of a server according to the first embodiment of the present specification. Among the method for distributing resources of the server according to FIG. 19, the contents overlapping those of FIGS. 14 to 18 may be omitted, and other contents will be described in detail below.

Referring to FIG. 19 , a first vehicle 101 that is a requesting vehicle requests the server 100 to perform a task and a task ( S601 ), and the server 100 sends the second vehicle 102 and the third vehicle 103 to the server 100 ( S601 ). ) may request the current resource share of each vehicle together with the state information (S602, S604). 19 , it appears that there is a time difference between S602 and S604, but in some cases, it may be performed simultaneously or S604 may be performed before S602.

In addition, although S602 and S604 appear to proceed after S601 in FIG. 19 , in some cases, the server 100 requests status information from the second vehicle 102 and the third vehicle 103 is performed in real time or It can be performed continuously with a certain period.

The current resource occupancy may mean a ratio of a resource currently being used with respect to the total resource of the vehicle. 19 , the second vehicle 102 and the third vehicle 103 have the same RTT value and the same CPU flops value, but differ in resource occupancy of 80% and 10%, respectively.

19 , the second vehicle 102 may additionally use 0.2 flops, and the third vehicle 103 may additionally use 0.9 flops. Accordingly, the server 100 may set a priority for the third vehicle 103 that can utilize more resources (S606), and select the third vehicle 103 accordingly (S607).

In this way, the server 100 may select an idle vehicle in consideration of the resource of each vehicle as well as the current resource occupancy. By considering the current resource occupancy, the effect of considering the actual task processing capability may occur.

In addition, in this way, the second vehicle 102 and/or the third vehicle 103 may transmit the resource occupancy rate as a response when the server 100 requests it. In addition, if the second vehicle 102 and/or the third vehicle 103 are idle even if there is no other request, the resource share may be transmitted to the server 100 in real time.

In addition, when the second vehicle 102 and/or the third vehicle 103 receives a task performance request from the server 100 ( S608 ), it transmits a response message indicating that the task cannot be processed in consideration of its own resource occupancy. may be

Hereinafter, the same or overlapping content as described above will be omitted.

20 is a diagram illustrating a method of using a vehicle list for resource distribution of a server according to the first embodiment of the present specification.

Referring to FIG. 20 , the server 100 may largely perform two processes P1 and P2.

According to the first process P1, the server 100 receives a task execution request from the requesting vehicle 101 (S601), and whether the priority of the task included in the task execution request message is “urgent” (S602). ), the following steps may be performed differently.

If the priority of the transmitted task is "emergency", the server 100 may directly perform the task in the server 100 (S608).

If the priority of the transmitted task is not "emergency", the server 100 may measure the resources required for performing the task (S603), and select a vehicle to transmit the task from the list of vehicles registered in the idle state ( S604). In this case, the server 100 may select one or more vehicles to transmit the task. The selected vehicle may be a vehicle selected according to the server selecting a vehicle ( S1030 ) according to the first embodiment of the present specification.

The server 100 transmits a message for a distributed processing request to the idle vehicle (S605), and receives a result message including the distributed processing task from the idle vehicle. When receiving a plurality of result messages including distributed processed tasks from a plurality of idle vehicles, the results may be integrated ( S606 ).

The server 100 may transmit the entire result of the integrated task processing to the request vehicle 101 (S607).

The second process P2 may be a step of determining whether to update the vehicle list registered in the idle state. A list of vehicles registered in an idle state in advance may be stored in the server 100 or the DB 110 .

In this case, in the list of vehicles registered in the idle state in advance, information including resources of the idle vehicle, a communication standard used by the idle vehicle, and a calculation capability may be stored together. This is because information other than the state information related to whether or not an idle state is a predetermined value may not be updated. In this way, by storing information that does not require real-time update in the list in advance, the second process P2 can be performed more quickly and efficiently. At this time, the stored information is not limited to the above example, and may include all information that does not require real-time update as a predetermined value.

According to the second process P2, the server 100 may transmit a confirmation message and receive a response message in order to confirm that the vehicle connected to the server 100 is previously registered as an idle state. (S611).

The server 100 may transmit a confirmation message and receive a response message thereto in order to confirm whether the state of the vehicle registered in the idle state is changed in advance (S618).

If the state of the vehicle registered in the idle state in advance is not changed, the server 100 stops updating the vehicle list registered in the idle state.

When the state of the vehicle registered in the idle state is changed in advance, the server 100 may transmit a confirmation message and receive a response message thereto in order to confirm whether the current state of the vehicle is the idle state (S612). In addition, when the vehicle connected to the server 100 is not a vehicle registered in an idle state in advance, the server 100 transmits a confirmation message to confirm whether the current state is an idle state and receives a response message therefor. There is (S612).

The server 100, when the current state of the vehicle connected to the server 100 is in the idle state, measures the RTT value between the server 100 and the vehicles, and additionally measures the distance between the server 100 and the vehicles. It can be (S613, S614).

The server 100 may transmit a confirmation message and receive a response message thereto in order to confirm the computing capability of the vehicle connected to the server 100 ( S615 ).

The server 100 may measure the processing efficiency of vehicles connected to the server 100 based on the calculation capability. Also, the server 100 may give priority to vehicles connected to the server 100 based on the processing efficiency (S616). Also, the list of vehicles registered in the idle state may be updated based on the priority (S617).

In this way, the distinction between the first process P1 for selecting an idle vehicle and requesting distributed processing of tasks to the selected vehicle and the second process P2 for updating the vehicle list registered in the idle state is as follows. It works.

First, by having a list of vehicles registered in an idle state in advance, the server scans all vehicles every time and requests the status information, thereby enabling faster resource distribution.

Second, more efficient traffic management is possible by updating and managing only the vehicle list registered in the idle state.

Third, by operating the vehicle list, there is an effect that it is easy to provide compensation by managing the vehicles registered in the list. That is, the vehicle owner may expect other compensation by registering his/her vehicle in the vehicle list. By operating the vehicle list in this way, it is possible to more easily induce active participation of vehicle owners.

21 is a diagram illustrating a resource distribution method of a server according to whether or not state information of a vehicle is changed according to the first embodiment of the present specification.

According to FIG. 21 , the resource distribution method of the server according to the present specification includes the steps of receiving a task and a processing request of the task from a request vehicle ( S2010 ), a communication state with the vehicles connected to the server 100 , and calculation of the vehicles Based on the capability, setting a priority of a vehicle to process the requested task (S2020), selecting an idle vehicle to request processing of the received task according to the set priority (S2030), the selected idle vehicle to transmit a request for processing the task and the received task (S2040), and detecting a change in state information of the selected idle vehicle (S2050).

Detecting a change in state information of the selected idle vehicle ( S2050 ) may be performed by a message for checking state information periodically transmitted by the server 100 . According to the above message, the server 100 may periodically receive status information of the selected idle vehicle.

Also, the state information change may include a change from an idle state to a running state and a change from an idle state to a turn-off state. In this case, the turn-off state may include a case in which a communication connection is disconnected.

Also, the change from the idle state to another state may include changing a processor included in the idle vehicle from the standby state to the active state. Also, the change from the idle state to another state may include terminating charging of the idle vehicle.

When a change in state information of the selected idle vehicle is not detected, the resource distribution method of the server according to the present specification includes the steps of receiving the processing result of the task transmitted from the selected idle vehicle (S2060), the vehicle requesting the processing result of the task It may include a step of transmitting to (S2070) and a step of paying a compensation to the selected idle vehicle (S2080).

In addition, when a change in the state information of the selected idle vehicle is detected, the resource distribution method of the server according to the present specification returns to the step (S2030) of selecting an idle vehicle to request processing of the received task according to the set priority. can That is, the server 100 may select the idle vehicle again based on the priority, except for the vehicle in which the change in state information is detected.

However, since the state information of the existing vehicle that is performing the task processing changes, it may be desirable to stop the processing of the task being performed.

Through this process, by sensitively sensing a change in the state information of the selected idle vehicle, and quickly reselecting another idle vehicle, there is an effect that resource distribution of the server can be efficiently performed.

In addition, when connected to a vehicle through wireless communication, problems such as data loss due to changes in the communication environment around the connected vehicle may occur. There is an effect that can be done.

In addition, an example of reselecting an idle vehicle according to the distance between the request vehicle and the server 100 is as follows.

As an example, it is assumed that the requesting vehicle requests the server 100 to distribute the task. Since the requested vehicle is currently autonomously driving, distributed processing of tasks may be required. Accordingly, the distance between the request vehicle and the server 100 that has received the task may change in real time. In addition, an area range in which the server 100 that has received the task can communicate may be limited. Therefore, when the straight-line distance between the server 100 that has received the task and the requested vehicle is more than a specific distance (ex - 2km, or the distance that the server can communicate), the server 100 that has received the task transfers the task to another server. can be transmitted Another server receiving the task may reselect the idle vehicle through the resource distribution method according to the first embodiment of the present specification. However, the server 100 may transmit the task to another server and, at the same time, transmit the contents of the completed task up to the time of transmission. In this case, it is preferable that the other server is in a position closest to the moving idle vehicle.

22 is a diagram illustrating a resource distribution method of a server using a vehicle in a running state when an idle vehicle is in a running state according to the first embodiment of the present specification.

According to FIG. 22 , the resource distribution method of the server according to the present specification includes the steps of receiving a task and a processing request of the task from the requesting vehicle ( S3010 ), the communication state with the vehicles connected to the server 100 and the operation of the vehicles Based on the capability, setting a priority of a vehicle to process the requested task (S3020), selecting an idle vehicle to request processing of the received task according to the set priority (S3030), the selected idle vehicle to transmit a request for processing the task and the received task (S3040), and detecting whether the state information of the selected idle vehicle is changed to the driving state (S3050).

When there is no change in the state information of the idle vehicle, the resource distribution method of the server according to the present specification includes the steps of receiving the processing result of the task transmitted from the selected idle vehicle (S3210), and transmitting the processing result of the task to the request vehicle It may include a step (S3220), and a step (S3230) of paying compensation to the selected idle vehicle.

When the state information of the idle vehicle is changed to the driving state, the resource distribution method of the server according to the present specification may receive a message indicating whether to continue processing the task transmitted from the vehicle changed to the driving state.

That is, it is possible to confirm the intention of the user of the vehicle from the above message. The vehicle changed to the driving state may display a message on the display asking the user whether to continue performing the operation or ask the user by voice. When the user selects whether to continue to perform the task or to stop the task, the vehicle may transmit the selected result to the server 100 as a message.

When receiving a message stating that the task transmitted from the vehicle changed to the driving state is not continuously performed, the server 100 receives the task performed so far and selects an idle vehicle to process the remaining tasks again based on priority Can be (S3030).

In addition, when receiving a message indicating that the task transmitted from the vehicle changed to the driving state is received, the resource analysis method of the server according to the present specification includes the step of receiving the driving destination from the vehicle (S3070), the received driving destination branch The method may further include analyzing the route and arrival time of , and analyzing spare resources capable of performing the task even if the vehicle performs autonomous driving ( S3080 ).

At this time, in step S3080, the server 100 receives the traffic condition from the vehicle to the destination, and calculates the route from the current location of the vehicle to the destination and the estimated time required to arrive based on the received traffic condition. can do.

Also, the server 100 may further calculate a handover section through which the selected vehicle must pass in order to arrive at a destination and a section passing through the communication shadow area, based on the calculated route.

The server 100 may calculate an estimated time required to arrive, excluding a section in which the selected vehicle passes through the communication shadow area.

In addition, the server 100 may calculate the amount of calculation to be performed per unit time in the selected vehicle based on the calculated expected time excluding the section passing through the communication shadow area. Based on the calculated value, the server 100 may calculate a resource that can be requested from the selected vehicle.

In this case, it is preferable that the calculated resource is such that it does not affect the autonomous driving of the selected vehicle. It may vary depending on the computational performance of the processor included in the selected vehicle, but only about 5 to 20% of the computational performance of the processor included in the selected vehicle may be used.

If the performance is less than 5%, it is difficult to perform work calculations properly, and if the performance is more than 20%, it may affect the autonomous driving of the vehicle.

In addition, the resource analysis method of the server according to the present specification includes the steps of receiving the task processing result performed using the analyzed spare resource (S3090), transmitting the received task processing result to the request vehicle (S3100), and It may further include a step (S3110) of paying a reward to the vehicle that has processed the task.

A server to which this specification can be applied and a general device including the same

Hereinafter, a server to which the resource distribution method according to the second embodiment of the present specification can be applied and a device including the same will be described in general.

For reference, in the second embodiment of the present specification, descriptions of components having the same or similar features as those of the other embodiments are omitted and only differences are described. The server may include features according to FIG. 22 .

23 is a diagram illustrating a wireless communication device including a server according to a second embodiment of the present specification.

Referring to FIG. 23 , 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.

Hereinafter, a server to which the resource distribution method of the server according to the present specification can be applied will be described.

For example, the first device 9010 of the devices of FIG. 23 may be the server 100 , and the second device 9020 of the devices of FIG. 23 may be a vehicle including a communication function. Conversely, the first device 9010 may be a vehicle including a communication function, and the second device 9020 may be the server 100 .

Hereinafter, the server 100 to which the present specification can be applied will be described as the first device 9010 in FIG. 23 , but the scope of the present specification is not limited thereto.

The servers 100 and 9010 to which this specification can be applied may process a task of a request vehicle, be connected to idle vehicles for distributing resources, and monitor status information of the idle vehicles.

In addition, the servers 100 and 9010 may include a transceiver 9013 , a memory 9012 , and a processor 9011 controlling the transceiver 9013 and the memory 9012 .

In the case of the transceiver 9013 , information is transmitted and received with a base station or a vehicle including a communication function through the antenna 9014 . The transceiver 9013 using wireless communication includes a wireless communication module having a modulator, a demodulator, a signal processor, and the like.

The wireless communication refers to communication using a communication facility installed by telecommunication companies and a wireless communication network using the frequency. At this time, various radios such as code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), single carrier frequency division multiple access (SC-FDMA), etc. It may be used in a communication system, as well as 3rd generation partnership project (3GPP) long term evolution (LTE) may be used. In addition, 5G communication, which has been commercialized recently, can be mainly used, and 6G, which is scheduled to be commercialized in the future, may be used. However, in the present specification, a pre-installed communication network may be utilized without being limited by such a wireless communication method.

The processor 9011 is a component capable of performing calculations and controlling other devices. Mainly, it may mean a central processing unit (CPU), an application processor (AP), a graphics processing unit (GPU), or the like. In addition, the CPU, AP, or GPU may include one or more cores therein, and the CPU, AP, or GPU may operate using an operating voltage and a clock signal. However, a CPU or AP may consist of a few cores optimized for serial processing, whereas a GPU may consist of thousands of smaller and more efficient cores designed for parallel processing.

The memory 9012 may include, but is not limited to, a hard disk drive (HDD), a solid state disk (SSD), a silicon disk drive (SDD), a ROM, a RAM, and the like.

The processor 9011 of the servers 100 and 9010 according to a preferred embodiment of the present specification determines the priority of the vehicles based on the communication state with the vehicles connected to the transceiver 9013 and the computing power of the vehicles. can be set. Also, the processor 9011 may select an idle vehicle to request task processing based on the set priority, and request the selected idle vehicle to process the task.

In this case, the idle vehicle may be a vehicle in a state that includes a processor in a standby state and receives power from the outside.

In this case, the priority may be set in the order of the highest FLOPS value indicating the computing capability among vehicles having a round trip time (RTT) value indicating a communication state with the servers 100 and 9010 equal to or less than the first RTT. In this case, since the relationship with the first RTT is the same as that described in the first embodiment of the present specification, it is omitted.

The processor 9011 may analyze a resource required for processing a task, and select a plurality of idle vehicles according to the analyzed necessary resource. In this case, it is preferable that the sum of the resources of the plurality of selected idle vehicles is greater than or equal to the required resource.

The processor 9011 may integrate the processing results received from the plurality of selected idle vehicles. In this case, the transceiver 9013 may transmit the processing result integrated by the processor 9011 to the request vehicle.

The processor 9011 may select a first type vehicle including a processor for multiple calculations or a second type vehicle including a processor for high speed calculation according to task characteristics. In this case, the characteristic of the task may include a first characteristic requiring multiple operations and a second characteristic requiring high-speed operation.

Also, when the characteristic of the task is the first characteristic, the processor 9011 may select the first type vehicle, and the transceiver 9013 may transmit the task to the first type vehicle.

Also, when the characteristic of the task is the second characteristic, the processor 9011 may select the second type vehicle, and the transceiver 9013 may transmit the task to the second type vehicle.

In addition, the processor 9011, based on the communication state between the servers 100 and 9010 and the vehicle, and the distance between the server and the vehicle, among the idle vehicles in which the state information is in the idle state, the servers 100 and 9010 perform the task. You can choose which vehicle to send.

In addition, the processor 9011 searches for a vehicle in an idle state in a DB in which a pre-registered vehicle list is stored, updates the state information for the searched vehicles, and selects a vehicle to transmit a task based on the updated state information. can

In this case, when the task is an emergency task, the processor 9011 may directly perform the corresponding emergency task.

In addition, the case where the state information is changed in the idle state of the vehicle is as follows.

After the task is transmitted to the selected vehicle by the processor 9011 , state information of the selected vehicle may be changed.

The processor 9011 may reselect an idle vehicle to request processing of the task based on a change in the state information of the idle vehicle.

In this case, the change in the state information of the idle vehicle may include a case in which the processor 9011 changes from the standby state to the active state. Also, the change in the state information of the idle vehicle may include termination of external power supply to the idle vehicle (ie, termination of charging).

The transceiver 9013 may periodically transmit a message requesting to check the status information of the selected vehicle and periodically receive the status information of the selected vehicle.

Also, the change in the state information of the idle vehicle may include a case in which wireless communication between the server 100 and the selected vehicle is cut off.

When the transceiver 9013 does not receive a response from the idle vehicle that has transmitted the task for more than a predetermined time, the processor 9011 may determine that the wireless communication connection between the server 100 and the vehicle is disconnected.

Accordingly, if a response is not received from the transceiver 9013 for a certain period of time, the processor 9011 may select a vehicle to transmit the task again.

In addition, a case in which the state of the vehicle is changed from the idle state to the driving state is as follows.

In this case, the processor 9011 may receive, through the transceiver 9013 , information on whether to continue to perform the task transmitted from the vehicle.

The processor 9011 may select, through the transceiver 9013 , an idle vehicle to which the task is to be transmitted again when a message indicating that the selected vehicle is changed to the driving state and does not continue to perform the task is received.

When the processor 9011 receives a message indicating that the task is continued even if the vehicle is changed to the driving state and the driving destination through the transceiver 9013, and the driving destination, the route to the destination, arrival time, and spare resources of the selected vehicle can be calculated. have.

The transceiver 2013 may receive a result message including the task processing result performed using the calculated spare resource, and may transmit the task processing result to the request vehicle.

The processor 9011 may calculate a route from the current location of the vehicle to the destination and an estimated time required to arrive, based on the traffic conditions to the driving destination.

Also, the processor 9011 may further calculate a handover section through which the selected vehicle must pass in order to arrive at a destination and a section passing through the communication shadow area, based on the calculated route. In this case, the processor 9011 may calculate a section passing through the communication shadow area based on the pre-stored road map and the communication facility map installed around the road.

The processor 9011 may calculate an estimated time required to arrive, excluding a section in which the selected vehicle passes through the communication shadow area. In addition, the processor 9011 may calculate the amount of calculation to be performed per unit time in the selected vehicle based on the calculated expected time excluding the section passing through the communication shadow area. The processor 9011 may calculate a resource that can be requested from the selected vehicle based on the calculated value.

In this case, the calculated resource is preferably to a degree that does not affect the autonomous driving of the selected vehicle, and the range thereof is omitted because it is the same as that disclosed in the first embodiment of the present specification.

Server's resource distribution system

Hereinafter, a server resource distribution system according to a third preferred embodiment of the present specification will be described in detail based on the above-mentioned contents.

For reference, among the third embodiments of the present specification, descriptions of components having the same or similar features as those of the first embodiment of the present specification will be omitted and only differences will be described.

In addition, the server resource distribution system according to the third embodiment of the present specification may use the server resource distribution method according to the first embodiment of the present specification, and an apparatus such as a server according to the second embodiment of the present specification may include general.

In addition, the resource distribution system of the server according to the third embodiment of the present specification may perform communication based on 5G communication between each configuration.

24 is a diagram illustrating a resource distribution system of a server according to a third embodiment of the present specification, and FIG. 25 is a diagram illustrating a first type vehicle and a second type vehicle according to the third embodiment of the present specification.

Referring to FIG. 24 , the premise system in which the resource distribution method of the server 100 according to the first embodiment of the present specification is performed includes the first vehicle 101 , the server 100 , the nth vehicle and the DB 110 . may include

The first vehicle 101 transmits a request message to the server 100 . In this case, the request message may include information on tasks requiring distributed processing and priorities of the tasks.

The first vehicle 101 may transmit the priority of the task together with the request message. For example, while requesting task A, the server 100 may transmit a message requesting that the task A be processed with the highest priority, or the task A may transmit an urgent task message together.

The server 100 may be a MEC server frequently used for V2X communication or 5G communication. The server 100 may receive a request message including a task for distributed processing from the first vehicle 101 , and may directly perform the task in case of an urgent task. In addition, in the case of a normal task, the server 100 may analyze a required resource, select an idle vehicle for resource distribution, and transmit a task processing result received from the selected idle vehicle to the first vehicle 101 . .

The n-th vehicle may be a plurality of autonomous vehicles. The n-th vehicle may be one in which the server 100 has previously allowed an authority to be used for resource distribution of the server 100 .

The server 100 may further include a separate DB 110 . The DB 110 may store a vehicle list in which the vehicle owner or user has previously registered their vehicle.

When the vehicle stored in the vehicle list is in an idle state, the server 100 may have received a right to use the resource of the vehicle from the vehicle owner or user.

The server 100 may request status information of the n-th vehicle 102 , 103 , etc., and receive a response including the status information from the n-th vehicle 102 , 103 , etc.). In addition, the server 100 may also receive the location information of the n-th vehicle (102, 103, etc.) through a sensor for measuring location information such as GPS included in the n-th vehicle (102, 103, etc.) .

The server 100 may select an idle vehicle capable of performing a task for resource distribution based on state information, calculation speed, or location information of the n-th vehicle 102 , 103 , and the like.

When vehicles previously registered in the DB 110 request a task request message from the server 100 , the server 100 may preferentially perform the task for vehicles registered in the DB 110 . In this way, by giving a reward to the vehicles registered in the DB 110, it is possible to induce the registration of more vehicles. In this case, the list of vehicles registered in the DB 110 may be periodically updated.

According to FIG. 24 , the second vehicle 102 has an RTT value of 20 ms, and the position is measured as A. As shown in FIG. The CPU computing power of the second vehicle 102 is 0.5T flops, and the number of cores is 6 at this time.

Also, the third vehicle 103 has an RTT value of 20 ms, and the position is measured as B. The CPU computing power of the third vehicle 103 is 1.5T flops, and the number of cores is two at this time.

In addition, the fourth vehicle 104 has an RTT value of 120 ms, and the position is measured as C. The CPU computing power of the fourth vehicle 104 is 0.5T flops, and the number of cores is 6 at this time.

In addition, the fifth vehicle 105 has an RTT value of 120 ms, and the position is measured as D. The CPU computing power of the fifth vehicle 105 is 1.5T flops, and the number of cores is two at this time.

However, the above figures are merely examples for convenience of explanation, and the scope of the present specification is not limited by the above figures.

In this case, a case where the server 100 receives a request for a task for distributed processing from the first vehicle 101 and distributes it will be described as an example.

24 , the second vehicle 102 and the third vehicle 103 have an RTT value of 20 ms, and the fourth vehicle 104 and the fifth vehicle 105 have an RTT value of 120 ms. Accordingly, the fourth vehicle 104 and the fifth vehicle 105 have relatively large RTT values. For example, if the RTT value is 80 ms or more, the communication speed may be classified as below average. Accordingly, the server 100 may distribute tasks by selecting the second vehicle 102 and the third vehicle 103 having a high communication speed.

According to FIG. 25 , the second vehicle 102 may be classified as a first type vehicle because the number of cores is six, and the third vehicle may be classified as a second type vehicle because the number of cores is two.

Accordingly, the server 100 may distribute the task to the vehicle according to whether the characteristic of the task for distributed processing is the first characteristic or the second characteristic. That is, the server 100 may distribute the task of the first characteristic to the second vehicle 102 that is the first type vehicle. Also, the server 100 may decompose the task of the second characteristic into the third vehicle 103 that is the second type vehicle.

Also, the server 100 may distribute the task to a vehicle near the location of the server among the location A of the second vehicle 102 and the location B of the third vehicle 103 . This is because it is determined that the more the vehicle is located relatively farther away, the higher the possibility that the communication state will deteriorate.

If the state information of the vehicle performing the transmitted task is changed from the idle state to the driving state, there is a problem.

The server 100 periodically transmits a message requesting to check the status information of the selected vehicle, and periodically receives the status information of the selected vehicle.

In this case, if the state information of the selected vehicle is not changed and is maintained in an idle state, the task may be performed in the selected vehicle. The server 100 may receive the task processing result from the selected vehicle and transmit the task processing result to the request vehicle.

When the state information of the selected vehicle is changed to the driving state, the vehicle may display a message asking the user whether to continue performing the task. When the user selects whether to continue performing the task or to stop the task, the vehicle transmits the selected result to the server 100 .

When the server 100 receives a message indicating that the selected vehicle is changed to the driving state and does not continue to perform the task, the server 100 may select the vehicle to which the task is to be transmitted again.

When the server 100 receives a message indicating that the task is continued even when the selected vehicle is changed to the driving state, the server 100 may proceed to the next step.

The server 100 may receive a driving destination from the selected vehicle. In addition, the server 100 may analyze the route to the destination, arrival time, and spare resources of the selected vehicle.

Also, the server 100 may receive the task processing result performed using the calculated spare resource, and transmit the task processing result to the request vehicle.

A detailed method of analyzing a route to a destination, an arrival time, and a spare resource of the selected vehicle will be omitted because the content is the same as that of the first embodiment of the present specification.

In addition, the server 100 may select a vehicle and transmit a task to the selected vehicle. In this case, the server 100 may transmit a confirmation request message for periodically confirming whether communication is connected to the selected vehicle. The server 100 receives a response according to the confirmation request message. If the response is not received for more than a predetermined time, it may be determined that the wireless communication connection between the server 100 and the vehicle is disconnected.

Accordingly, if a response is not received from the server 100 for a certain period of time, the server 100 may select a vehicle to transmit the task again. As described above, a description of the case in which wireless communication between the server 100 and the selected vehicle is cut off is the same as that of the first embodiment of the present specification, and thus will be omitted.

26 is a view showing the overall operation of the resource distribution system according to the third embodiment of the present specification.

Referring to FIG. 26 , the operation process of the resource distribution system according to the third embodiment of the present specification includes a step (S5010) of a request vehicle selecting a server 100 to which a task is to be transmitted, and a task to the server 100 to which the request vehicle is selected. It may include the step of transmitting (S5020), and the step of receiving the task from the selected server 100 (S5030).

In the step (S5010) of the request vehicle selecting the server 100 to which the task is to be transmitted, after the request vehicle is connected to the server 100, a request for specification information of the server 100 is requested from the connected server 100, and the server 100 ), it may be determined whether the task has a suitable specification based on the specification information. For example, when the characteristic of the task is the first characteristic, it may be determined whether the server 100 includes a multi-core. In addition, when the characteristic of the task is the second characteristic, it may be determined whether the high-speed operation is advantageous based on the operation performance of each core.

As described above, since the request vehicle transmits the task in consideration of the characteristics of the server 100 , an advantageous effect of being able to process the urgent task faster in the server 100 may occur.

Referring to FIG. 26 , the operation process of the resource distribution system according to the third embodiment of the present specification may further include the step ( S5040 ) of confirming whether the task received by the server 100 is an urgent task.

If the task received by the server 100 is an urgent task, the operation process of the resource distribution system according to the third embodiment of the present specification includes the step (S5210) of the server 100 directly processing the task, and the task processing result The method may further include transmitting the request to the vehicle (S5220).

If the task received by the server 100 is a normal task, the operation process of the resource distribution system according to the third embodiment of the present specification includes the step of selecting an idle vehicle to request processing of the received task (S5050), the selected idle Transmitting a request for processing the task and the received task to a vehicle (S5060), processing the task transmitted by the selected idle vehicle (S5070), and transmitting the task processing result from the selected idle vehicle to the server 100 It may include a step (S5080), a step of transmitting the transmitted task processing result to an idle vehicle (S5090), and a step of providing a reward to the vehicle that has processed the task (S5100).

At this time, the step of selecting the idle vehicle to request the processing of the received task (S5050) is the step of monitoring the status information of the vehicles connected to the server 100 (S5051), when a change in the status information of the vehicles is detected, Updating the list of idle vehicles (S5052), giving priority to the idle vehicle according to the communication state and arithmetic capability based on the updated list (S5053), and selecting the idle vehicle having a high priority (S5053) S5054) may be included.

However, the step ( S5051 ) of monitoring the state information of the vehicles connected to the server 100 is not performed only in the step S5050 , but may be performed in real time or may be continuously performed at a predetermined period.

In addition, when a change in the state of the selected idle vehicle is detected as described above, as described in detail in the first or second embodiment of the present specification, the idle vehicle may be reselected or resources of the vehicle in the driving state may be used. There will be. As such, it will be apparent to those skilled in the art that the first embodiment or the second embodiment can be applied to the resource distribution system of the third embodiment of the present specification.

The above-described specification can be implemented as computer-readable code on a medium in which a program is recorded. The computer-readable medium includes all kinds 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. 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.

In addition, although the embodiments have been mainly described above, these are merely examples and are not intended to limit the present specification, and those of ordinary skill in the art to which this specification belongs are exemplified above in a range that does not depart from the essential characteristics of the present embodiment. It can be seen that various modifications and applications that have not been made are possible. For example, each component specifically shown in the embodiments can be implemented by modification. And differences related to such modifications and applications should be construed as being included in the scope of the present specification defined in the appended claims.

Although the present specification has been mainly described as an example applied to an autonomous driving system (Automated Vehicle & Highway Systems) based on a 5G (5 generation) system, it can be applied to various wireless communication systems and autonomous driving devices.

100: server
101: first vehicle
102: second vehicle
103: third vehicle
104: fourth vehicle
105: fifth vehicle
110: DB

Claims (20)

In the resource distribution method of the server for monitoring the status information of the vehicles connected to the server and processing the task of the requested vehicle,
receiving the task and a request for processing the task from the requesting vehicle;
setting a priority of a vehicle to process the requested task based on the communication state with the vehicles and the computing capability of the vehicles;
selecting an idle vehicle to request processing of the received task according to the set priority;
transmitting the task and a request for processing the task to the selected idle vehicle;
receiving a processing result of the task from the selected idle vehicle; and
Including; transmitting the processing result of the task to the request vehicle;
The idle vehicle
A method for distributing resources of a server, including a processor in a standby state, and is a vehicle in a state that is supplied with power from the outside.
According to claim 1,
The priority is
Among the vehicles having a round trip time (RTT) value indicating a communication state with the server equal to or less than a first RTT, the FLOPS value indicating the computing capability is set in the order of highest.
According to claim 1,
The step of selecting an idle vehicle to request processing of the received task comprises:
selecting a plurality of the idle vehicles according to a resource required for processing the task;
wherein the sum of the resources of the selected plurality of idle vehicles is greater than or equal to the required resource.
4. The method of claim 3,
Transmitting the processing result of the received task to the request vehicle,
The method for distributing resources of a server is to integrate the processing results received from the plurality of selected idle vehicles, and transmit the integrated processing results to the request vehicle.
According to claim 1,
The step of selecting an idle vehicle to request processing of the received task comprises:
Selecting a first type vehicle including a processor for multiple calculations or a second type vehicle including a processor for high speed calculation according to the characteristics of the task,
The characteristic of the task includes a first characteristic requiring the multiple operation and a second characteristic requiring the high-speed operation, the resource distribution method of the server.
6. The method of claim 5,
Sending the task and requesting processing of the task comprises:
when the characteristic of the task is the first characteristic, transmitting the task to the first type vehicle;
When the characteristic of the task is the second characteristic, transmitting the task to the second type vehicle.
According to claim 1,
The method of distributing resources of the server,
detecting a total amount of resources used by the selected idle vehicle to process the task; and
Based on the sensed total amount, providing a reward to the selected idle vehicle; further comprising, the server resource distribution method.
According to claim 1,
The server is a MEC (Multi-Access Edge Computing) server, the resource distribution method of the server.
According to claim 1,
The server is to perform communication based on 5G communication with the vehicles and the request vehicle, the resource distribution method of the server.
According to claim 1,
detecting a change in state information of the selected idle vehicle; and
Further comprising; based on the change in the sensed state information, reselecting an idle vehicle to request processing of the received task;
A change in the state information of the selected idle vehicle is,
A method for distributing resources of a server, including a change from the standby state to an active state, or termination of the charging.
11. The method of claim 10,
The change in the state information of the selected vehicle,
The method of distributing resources of the server, further comprising a change from the standby state to the turn-off state.
A server that processes a task of a requesting vehicle, is connected to idle vehicles for distributing resources, and monitors status information of the idle vehicles, the server comprising:
transceiver;
Memory; and
a processor for controlling the transceiver and the memory;
The processor is
Set the priorities of the vehicles based on the communication state between the vehicles connected to the transceiver and the transceiver and the computing capabilities of the vehicles, and select an idle vehicle to request processing of the received task based on the set priority and requesting the selected idle vehicle to process the task,
The idle vehicle
A server that includes a processor in a standby state, and is a vehicle in a state that is supplied with power from the outside.
13. The method of claim 12,
The priority is
Among the vehicles having a round trip time (RTT) value indicating a communication state with the server equal to or less than a first RTT, the FLOPS value indicating the computing capability is set in the order of highest.
13. The method of claim 12,
The processor is
selecting a plurality of the idle vehicles according to a resource required for processing the task;
and a sum of resources of the plurality of selected idle vehicles is greater than or equal to the required resource.
15. The method of claim 14,
The processor is
integrating the processing results received from the plurality of selected idle vehicles;
The transceiver is
and transmitting the integrated processing result to the request vehicle.
13. The method of claim 12,
The processor is
Selecting a first type vehicle including a processor for multiple calculations or a second type vehicle including a processor for high speed calculation according to the characteristics of the task,
The characteristics of the task include a first characteristic requiring the multiple operation and a second characteristic requiring the high-speed operation, the server.
17. The method of claim 16,
and when the characteristic of the task is the first characteristic, the processor selects the first type vehicle, and the transceiver transmits the task to the first type vehicle.
17. The method of claim 16,
and when the characteristic of the task is the second characteristic, the processor selects the second type vehicle, and the transceiver transmits the task to the second type vehicle.
13. The method of claim 12,
The processor is
Based on a change in the state information of the idle vehicle, the server will reselect the idle vehicle to request the processing of the task.
20. The method of claim 19,
A change in the state information of the idle vehicle,
The server in the standby state is changed to an active state, or the state receiving power from the outside is terminated.

Images