WO2025042195A1 - Method by which user equipment performs communication in wireless communication system and apparatus therefor - Google Patents

Abstract

Disclosed are a method for performing an operation related to maneuver coordination in a wireless communication system and an apparatus therefor, according to various embodiments. Disclosed are the method and apparatus therefor, the method comprising the steps of: periodically transmitting a recognition message including status information about a user equipment; receiving a message including group status information about a temporary group from a first device; and determining whether to participate in the temporary group for maneuver coordination on the basis of the group status information of the message.

Description

Method for performing communication by a terminal in a wireless communication system and device therefor

The present invention relates to a method for performing communication for performing operations related to maneuver coordination in a wireless communication system and a device therefor.

A wireless communication system is a multiple access system that supports communication with multiple users by sharing available system resources (e.g., bandwidth, transmission power, etc.). Examples of multiple access systems include a CDMA (code division multiple access) system, an FDMA (frequency division multiple access) system, a TDMA (time division multiple access) system, an OFDMA (orthogonal frequency division multiple access) system, an SC-FDMA (single carrier frequency division multiple access) system, and an MC-FDMA (multi carrier frequency division multiple access) system.

Sidelink (SL) refers to a communication method that establishes a direct link between user equipment (UE) to directly exchange voice or data between terminals without going through a base station (BS). SL is being considered as a solution to solve the burden on base stations due to rapidly increasing data traffic.

V2X (vehicle-to-everything) refers to a communication technology that exchanges information with other vehicles, pedestrians, and objects with built-in infrastructure through wired/wireless communication. V2X can be divided into four types: V2V (vehicle-to-vehicle), V2I (vehicle-to-infrastructure), V2N (vehicle-to-network), and V2P (vehicle-to-pedestrian). V2X communication can be provided through the PC5 interface and/or the Uu interface.

Meanwhile, as more and more communication devices require greater communication capacity, there is a growing need for improved mobile broadband communication over existing Radio Access Technology (RAT). Accordingly, communication systems that consider services or terminals sensitive to reliability and latency are being discussed, and the next-generation radio access technology that considers improved mobile broadband communication, massive MTC (Machine Type Communication), URLLC (Ultra-Reliable and Low Latency Communication), etc. can be called new RAT (new radio access technology) or NR (new radio). V2X (vehicle-to-everything) communication can also be supported in NR.

Figure 1 is a diagram for explaining and comparing V2X communication based on RAT before NR and V2X communication based on NR.

In relation to V2X communication, in RATs prior to NR, methods for providing safety services based on V2X messages such as Basic Safety Message (BSM), Cooperative Awareness Message (CAM), and Decentralized Environmental Notification Message (DENM) have been mainly discussed. V2X messages may include location information, dynamic information, attribute information, etc. For example, a terminal may transmit a CAM of a periodic message type and/or a DENM of an event triggered message type to another terminal.

For example, CAM may include basic vehicle information such as vehicle dynamic status information such as direction and speed, vehicle static data such as dimensions, exterior lighting status, and route history. For example, the terminal may broadcast CAM, and the latency of the CAM may be less than 100ms. For example, when an emergency situation such as vehicle breakdown or accident occurs, the terminal may generate DENM and transmit it to other terminals. For example, all vehicles within the transmission range of the terminal may receive CAM and/or DENM. In this case, DENM may have a higher priority than CAM.

Since then, various V2X scenarios have been proposed in NR in relation to V2X communication. For example, various V2X scenarios may include vehicle platooning, advanced driving, extended sensors, and remote driving.

For example, based on vehicle platooning, vehicles can dynamically form a group and move together. For example, in order to perform platoon operations based on vehicle platooning, vehicles belonging to the group can receive periodic data from the lead vehicle. For example, vehicles belonging to the group can use the periodic data to reduce or increase the gap between vehicles.

For example, based on improved driving, the vehicles can be semi-autonomous or fully automated. For example, each vehicle can adjust its trajectories or maneuvers based on data acquired from local sensors of nearby vehicles and/or nearby logical entities. Also, for example, each vehicle can share driving intentions with nearby vehicles.

For example, based on the extended sensors, raw data or processed data, or live video data acquired through local sensors can be exchanged between vehicles, logical entities, pedestrian terminals, and/or V2X application servers. Thus, for example, the vehicle can perceive the environment better than it can perceive using its own sensors.

For example, based on remote driving, for a person who cannot drive or a remote vehicle located in a dangerous environment, a remote driver or V2X application can operate or control the remote vehicle. For example, in the case of predictable paths such as public transportation, cloud computing-based driving can be used to operate or control the remote vehicle. In addition, for example, access to a cloud-based back-end service platform can be considered for remote driving.

Meanwhile, a method to specify service requirements for various V2X scenarios, such as vehicle platooning, enhanced driving, expanded sensors, and remote driving, is being discussed in NR-based V2X communications.

The technical challenge to be achieved is to provide a method for efficiently and quickly performing maneuver coordination in a wireless communication system and a device therefor.

The technical challenges are not limited to the technical challenges mentioned above, and other technical challenges not mentioned will be clearly understood by those skilled in the art to which the present invention belongs from the description below.

A method for a terminal to perform an operation related to maneuver coordination in a wireless communication system according to one aspect comprises the steps of: periodically transmitting an identification message including status information about the terminal; receiving a message including group status information about a temporary group from a first device; and determining whether the temporary group participates in the maneuver coordination based on the group status information of the message, wherein the group status information may include driving intention information related to the temporary group.

Alternatively, based on the correspondence between the driving intention information and the driving intention of the terminal, the first terminal transmits an approval message approving participation in the temporary group to the first device.

Alternatively, based on transmission of said approval message, said recognition message is characterized in that transmission is stopped or the transmission cycle is increased based on said message.

Or, based on the transmission of the approval message, the method further comprises the step of receiving, from the first device, group status sharing information including information on the number of terminals included in the temporary group, the waiting order of the terminals, and the expected waiting time according to the waiting order.

Alternatively, based on the group status information further including information on an expected waiting time for the driving intention of the temporary group to be achieved, the terminal is characterized in that it determines whether to participate in the temporary group by considering both the expected waiting time and the driving intention information.

Alternatively, based on the search for a detour shorter than the expected waiting time, the terminal transmits a rejection message to the first device rejecting participation in the temporary group even if the driving intention of the terminal corresponds to the driving intention information.

Alternatively, based on the driving intention information not corresponding to the driving intention of the terminal, the terminal is characterized in that it changes the route to leave the area where the temporary group is located.

Alternatively, the message is characterized in that it is a Maneuver Coordination Message (MCM) or a Maneuver Sharing and Coordination Message (MSCM), and the group status information is included in an extension field of the MCM or MSCM.

Alternatively, the first device is characterized as being a network supporting V2X (Vehicle to Everything) communication or a leader terminal of the temporary group.

According to another aspect, a non-transitory computer-readable storage medium having recorded thereon instructions for performing operations related to maneuver coordination may be provided.

According to another aspect, a terminal may be provided that performs operations related to the above-described maneuver coordination.

According to another aspect, a processing device may be provided for controlling a terminal performing operations related to the above-described maneuver coordination.

In another aspect, a method for a network to perform an operation related to maneuver coordination in a wireless communication system comprises the steps of: receiving an identification message including status information from a terminal; transmitting a message including group status information about a temporary group to the terminal; and receiving a response message from the terminal regarding whether the temporary group participates in the maneuver coordination, wherein the group status information may include driving intention information related to the temporary group.

According to another aspect, a network may be provided that performs operations related to the above-described maneuver coordination.

According to one embodiment, group-based maneuver coordination can be performed efficiently and quickly in a wireless communication system.

The effects that can be obtained in various embodiments are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art to which the present invention pertains from the description below.

The drawings appended hereto are included to provide an understanding of the present invention and to illustrate various embodiments of the present invention and, together with the description of the specification, serve to explain the principles of the present invention.

Figure 1 is a diagram for explaining and comparing V2X communication based on RAT before NR and V2X communication based on NR.

Figure 2 shows the structure of the LTE system.

Figure 3 shows the structure of the NR system.

Figure 4 shows the structure of a radio frame of NR.

Figure 5 shows the slot structure of an NR frame.

Figure 6 shows a radio protocol architecture for SL communication.

Figure 7 shows a terminal performing V2X or SL communication.

Figure 8 shows resource units for V2X or SL communication.

FIG. 9 illustrates a communication structure that can be provided in a 6G system according to one embodiment of the present disclosure.

FIG. 10 illustrates an electromagnetic spectrum according to one embodiment of the present disclosure.

Figure 11 is a drawing for explaining the ITS station reference architecture.

Fig. 12 is an example structure of an ITS station that can be designed and applied based on a reference structure.

Figure 13 is a drawing for explaining a method of forming a group for maneuver coordination or participating in the group.

Figure 14 is a drawing for explaining the structure of a message for maneuver coordination.

Figures 15 to 18 are diagrams for explaining a group participation procedure, a group status sharing procedure, and a group start negotiation procedure.

Figures 19 and 20 are diagrams for explaining a method of utilizing group-based maneuver coordination according to traffic conditions.

Figure 21 is a drawing for explaining how a terminal performs operations related to maneuver coordination.

Figure 22 is a diagram illustrating how a network performs operations related to maneuver coordination.

Figure 23 illustrates a communication system applied to the present invention.

Figure 24 illustrates a wireless device that can be applied to the present invention.

Fig. 25 shows another example of a wireless device applied to the present invention.

Figure 26 illustrates a vehicle or autonomous vehicle to which the present invention is applied.

A wireless communication system is a multiple access system that supports communication with multiple users by sharing available system resources (e.g., bandwidth, transmission power, etc.). Examples of multiple access systems include a CDMA (code division multiple access) system, an FDMA (frequency division multiple access) system, a TDMA (time division multiple access) system, an OFDMA (orthogonal frequency division multiple access) system, an SC-FDMA (single carrier frequency division multiple access) system, and an MC-FDMA (multi carrier frequency division multiple access) system.

Sidelink refers to a communication method that establishes a direct link between user equipment (UE) to directly exchange voice or data between terminals without going through a base station (BS). Sidelink is being considered as a solution to solve the burden on base stations due to rapidly increasing data traffic.

V2X (vehicle-to-everything) refers to a communication technology that exchanges information with other vehicles, pedestrians, and objects with built-in infrastructure through wired/wireless communication. V2X can be divided into four types: V2V (vehicle-to-vehicle), V2I (vehicle-to-infrastructure), V2N (vehicle-to-network), and V2P (vehicle-to-pedestrian). V2X communication can be provided through the PC5 interface and/or the Uu interface.

Meanwhile, as more and more communication devices require greater communication capacity, there is a growing need for improved mobile broadband communication over existing radio access technologies (RATs). Accordingly, communication systems that consider services or terminals sensitive to reliability and latency are being discussed, and the next-generation radio access technology that considers improved mobile broadband communication, massive MTC, and URLLC (Ultra-Reliable and Low Latency Communication) can be called new RAT (new radio access technology) or NR (new radio). V2X (vehicle-to-everything) communication can also be supported in NR.

The following technology can be used in various wireless communication systems, such as CDMA (code division multiple access), FDMA (frequency division multiple access), TDMA (time division multiple access), OFDMA (orthogonal frequency division multiple access), and SC-FDMA (single carrier frequency division multiple access). CDMA can be implemented with wireless technologies such as UTRA (universal terrestrial radio access) or CDMA2000. TDMA can be implemented with wireless technologies such as GSM (global system for mobile communications)/GPRS (general packet radio service)/EDGE (enhanced data rates for GSM evolution). OFDMA can be implemented with wireless technologies such as IEEE (institute of electrical and electronics engineers) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, E-UTRA (evolved UTRA). IEEE 802.16m is an evolution of IEEE 802.16e, providing backward compatibility with systems based on IEEE 802.16e. UTRA is part of UMTS (universal mobile telecommunications system). 3GPP (3rd generation partnership project) LTE (long term evolution) is a part of E-UMTS (evolved UMTS) that uses E-UTRA (evolved-UMTS terrestrial radio access), employing OFDMA in the downlink and SC-FDMA in the uplink. LTE-A (advanced) is an evolution of 3GPP LTE.

5G NR is a new clean-slate type mobile communication system that is the successor technology to LTE-A and has the characteristics of high performance, low latency, and high availability. 5G NR can utilize all available spectrum resources, from low frequency bands below 1 GHz to intermediate frequency bands between 1 GHz and 10 GHz, and high frequency (millimeter wave) bands above 24 GHz.

For clarity of explanation, the description will focus on LTE-A or 5G NR, but the technical idea of the embodiment(s) is not limited thereto.

Figure 2 shows the structure of an applicable LTE system. This may be called an Evolved-UMTS Terrestrial Radio Access Network (E-UTRAN), or a Long Term Evolution (LTE)/LTE-A system.

Referring to FIG. 2, the E-UTRAN includes a base station (20; BS) that provides a control plane and a user plane to a terminal (10). The terminal (10) may be fixed or mobile, and may be called by other terms such as a mobile station (MS), a user terminal (UT), a subscriber station (SS), a mobile terminal (MT), a wireless device, etc. The base station (20) refers to a fixed station that communicates with the terminal (10), and may be called by other terms such as an evolved-NodeB (eNB), a base transceiver system (BTS), an access point, etc.

Base stations (20) can be connected to each other through the X2 interface. The base station (20) is connected to an EPC (Evolved Packet Core, 30) through the S1 interface, more specifically, to an MME (Mobility Management Entity) through the S1-MME and to an S-GW (Serving Gateway) through the S1-U.

EPC (30) consists of MME, S-GW, and P-GW (Packet Data Network-Gateway). MME has terminal connection information or terminal capability information, and this information is mainly used for terminal mobility management. S-GW is a gateway with E-UTRAN as an end point, and P-GW is a gateway with PDN as an end point.

The layers of the radio interface protocol between the terminal and the network can be divided into L1 (the first layer), L2 (the second layer), and L3 (the third layer) based on the three lower layers of the Open System Interconnection (OSI) standard model, which is widely known in communication systems. Among these, the physical layer belonging to the first layer provides an information transfer service using a physical channel, and the RRC (Radio Resource Control) layer located in the third layer controls radio resources between the terminal and the network. To this end, the RRC layer exchanges RRC messages between the terminal and the base station.

Figure 3 shows the structure of the NR system.

Referring to FIG. 3, the NG-RAN may include a gNB and/or an eNB that provides user plane and control plane protocol termination to the UE. FIG. 7 illustrates a case where only a gNB is included. The gNB and the eNB are connected to each other via an Xn interface. The gNB and the eNB are connected to a 5th generation core network (5G Core Network: 5GC) via an NG interface. More specifically, they are connected to an access and mobility management function (AMF) via an NG-C interface, and to a user plane function (UPF) via an NG-U interface.

Figure 4 shows the structure of a radio frame of NR.

Referring to FIG. 4, a radio frame can be used in uplink and downlink transmission in NR. A radio frame has a length of 10 ms and can be defined as two 5 ms half-frames (Half-Frames, HF). A half-frame can include five 1 ms subframes (Subframes, SF). A subframe can be divided into one or more slots, and the number of slots in a subframe can be determined according to the subcarrier spacing (SCS). Each slot can include 12 or 14 OFDM (A) symbols according to the cyclic prefix (CP).

When normal CP is used, each slot can include 14 symbols. When extended CP is used, each slot can include 12 symbols. Here, the symbols can include OFDM symbols (or CP-OFDM symbols), SC-FDMA (Single Carrier - FDMA) symbols (or DFT-s-OFDM (Discrete Fourier Transform-spread-OFDM) symbols).

Table 1 below illustrates the number of symbols per slot ((N ^slot _symb ), the number of slots per frame ((N ^frame,u slot )) and the number of slots per subframe ((N ^subframe,u _slot )) depending on the SCS setting ( _u ) when normal CP is used.

SCS (15*2 ^u ) N ^slot _symb N ^frame,u _slot N ^subframe,u _slot 15KHz (u=0) 14 10 1 30KHz (u=1) 14 20 2 60KHz (u=2) 14 40 4 120KHz (u=3) 14 80 8 240KHz (u=4) 14 160 16

Table 2 illustrates the number of symbols per slot, the number of slots per frame, and the number of slots per subframe according to SCS when extended CP is used.

SCS (15*2 ^u ) N ^slot _symb N ^frame,u _slot N ^subframe,u _slot 60KHz (u=2) 12 40 4

In an NR system, OFDM(A) numerology (e.g., SCS, CP length, etc.) may be set differently between multiple cells that are merged into one terminal. Accordingly, the (absolute time) section of a time resource (e.g., subframe, slot, or TTI) (conveniently referred to as TU (Time Unit)) consisting of the same number of symbols may be set differently between the merged cells.

In NR, multiple numerologies or SCS can be supported to support various 5G services. For example, when the SCS is 15 kHz, wide area in traditional cellular bands can be supported, and when the SCS is 30 kHz/60 kHz, dense-urban, lower latency and wider carrier bandwidth can be supported. When the SCS is 60 kHz or higher, a bandwidth greater than 24.25 GHz can be supported to overcome phase noise.

The NR frequency band can be defined by two types of frequency ranges. The two types of frequency ranges can be FR1 and FR2. The numerical value of the frequency range can be changed, and for example, the two types of frequency ranges can be as shown in Table 3 below. Among the frequency ranges used in the NR system, FR1 can mean "sub 6GHz range", and FR2 can mean "above 6GHz range" and can be called millimeter wave (mmW).

Frequency Range designation Corresponding frequency range Subcarrier Spacing (SCS) FR1 450MHz - 6000MHz 15, 30, 60kHz FR2 24250MHz - 52600MHz 60, 120, 240kHz

As described above, the numerical value of the frequency range of the NR system can be changed. For example, FR1 can include a band of 410 MHz to 7125 MHz as shown in Table 4 below. That is, FR1 can include a frequency band of 6 GHz (or 5850, 5900, 5925 MHz, etc.) or higher. For example, the frequency band of 6 GHz (or 5850, 5900, 5925 MHz, etc.) or higher included in FR1 can include an unlicensed band. The unlicensed band can be used for various purposes, for example, it can be used for communication for vehicles (e.g., autonomous driving).

Frequency Range designation Corresponding frequency range Subcarrier Spacing (SCS) FR1 410MHz - 7125MHz 15, 30, 60kHz FR2 24250MHz - 52600MHz 60, 120, 240kHz

Figure 5 shows the slot structure of an NR frame.

Referring to FIG. 5, a slot includes multiple symbols in the time domain. For example, in the case of a normal CP, one slot may include 14 symbols, but in the case of an extended CP, one slot may include 12 symbols. Or, in the case of a normal CP, one slot may include 7 symbols, but in the case of an extended CP, one slot may include 6 symbols.

A carrier includes multiple subcarriers in the frequency domain. An RB (Resource Block) can be defined as multiple (e.g., 12) consecutive subcarriers in the frequency domain. A BWP (Bandwidth Part) can be defined as multiple consecutive (P)RBs ((Physical) Resource Blocks) in the frequency domain and can correspond to one numerology (e.g., SCS, CP length, etc.). A carrier can include up to N (e.g., 5) BWPs. Data communication can be performed through activated BWPs. Each element can be referred to as a Resource Element (RE) in the resource grid and can be mapped to one complex symbol.

Meanwhile, the wireless interface between terminals or between terminals and a network may be composed of an L1 layer, an L2 layer, and an L3 layer. In various embodiments of the present disclosure, the L1 layer may mean a physical layer. In addition, for example, the L2 layer may mean at least one of a MAC layer, an RLC layer, a PDCP layer, and an SDAP layer. In addition, for example, the L3 layer may mean an RRC layer.

Below, V2X or SL (sidelink) communication is explained.

Fig. 6 shows a radio protocol architecture for SL communication. Specifically, Fig. 6 (a) shows a user plane protocol stack of NR, and Fig. 6 (b) shows a control plane protocol stack of NR.

Below, the SL synchronization signal (Sidelink Synchronization Signal, SLSS) and synchronization information are described.

SLSS is an SL-specific sequence and may include a Primary Sidelink Synchronization Signal (PSSS) and a Secondary Sidelink Synchronization Signal (SSSS). The PSSS may be referred to as a Sidelink Primary Synchronization Signal (S-PSS), and the SSSS may be referred to as a Sidelink Secondary Synchronization Signal (S-SSS). For example, length-127 M-sequences may be used for the S-PSS, and length-127 Gold sequences may be used for the S-SSS. For example, a terminal may detect an initial signal (signal detection) and acquire synchronization using the S-PSS. For example, the terminal may acquire detailed synchronization and detect a synchronization signal ID using the S-PSS and the S-SSS.

PSBCH (Physical Sidelink Broadcast Channel) may be a (broadcast) channel through which basic (system) information that a terminal must know first before transmitting and receiving an SL signal is transmitted. For example, the basic information may be information related to SLSS, duplex mode (DM), TDD UL/DL (Time Division Duplex Uplink/Downlink) configuration, resource pool related information, type of application related to SLSS, subframe offset, broadcast information, etc. For example, in order to evaluate PSBCH performance, in NR V2X, the payload size of PSBCH may be 56 bits including a 24-bit CRC.

The S-PSS, S-SSS and PSBCH may be included in a block format supporting periodic transmission (e.g., SL SS (Synchronization Signal)/PSBCH block, hereinafter referred to as S-SSB (Sidelink-Synchronization Signal Block)). The S-SSB may have the same numerology (i.e., SCS and CP length) as the PSCCH (Physical Sidelink Control Channel)/PSSCH (Physical Sidelink Shared Channel) in a carrier, and a transmission bandwidth may be within a (pre-)configured SL BWP (Sidelink BWP). For example, the bandwidth of the S-SSB may be 11 RBs (Resource Blocks). For example, the PSBCH may span 11 RBs. And, the frequency location of the S-SSB may be (pre-)configured. Therefore, the terminal does not need to perform hypothesis detection in frequency to discover the S-SSB in the carrier.

Meanwhile, in the NR SL system, multiple numerologies having different SCS and/or CP lengths may be supported. In this case, as the SCS increases, the length of the time resource for a transmitting terminal to transmit an S-SSB may become shorter. Accordingly, the coverage of the S-SSB may decrease. Therefore, in order to ensure the coverage of the S-SSB, the transmitting terminal may transmit one or more S-SSBs to a receiving terminal within one S-SSB transmission period according to the SCS. For example, the number of S-SSBs that the transmitting terminal transmits to the receiving terminal within one S-SSB transmission period may be pre-configured or configured for the transmitting terminal. For example, the S-SSB transmission period may be 160 ms. For example, an S-SSB transmission period of 160 ms may be supported for all SCSs.

For example, when the SCS is 15 kHz at FR1, the transmitting terminal can transmit one or two S-SSBs to the receiving terminal within one S-SSB transmission period. For example, when the SCS is 30 kHz at FR1, the transmitting terminal can transmit one or two S-SSBs to the receiving terminal within one S-SSB transmission period. For example, when the SCS is 60 kHz at FR1, the transmitting terminal can transmit one, two, or four S-SSBs to the receiving terminal within one S-SSB transmission period.

For example, when the SCS is 60 kHz at FR2, the transmitting terminal can transmit 1, 2, 4, 8, 16, or 32 S-SSBs to the receiving terminal within one S-SSB transmission period. For example, when the SCS is 120 kHz at FR2, the transmitting terminal can transmit 1, 2, 4, 8, 16, 32, or 64 S-SSBs to the receiving terminal within one S-SSB transmission period.

Meanwhile, when SCS is 60 kHz, two types of CP can be supported. In addition, the structure of the S-SSB transmitted by the transmitting terminal to the receiving terminal may be different depending on the CP type. For example, the CP type may be Normal CP (NCP) or Extended CP (ECP). Specifically, for example, when the CP type is NCP, the number of symbols to which the PSBCH is mapped in the S-SSB transmitted by the transmitting terminal may be 9 or 8. On the other hand, for example, when the CP type is ECP, the number of symbols to which the PSBCH is mapped in the S-SSB transmitted by the transmitting terminal may be 7 or 6. For example, the PSBCH may be mapped to the first symbol in the S-SSB transmitted by the transmitting terminal. For example, the receiving terminal receiving the S-SSB may perform an AGC (Automatic Gain Control) operation in the first symbol section of the S-SSB.

Figure 7 shows a terminal performing V2X or SL communication.

Referring to Fig. 7, the term terminal in V2X or SL communication may mainly mean a user's terminal. However, if a network device such as a base station transmits and receives a signal according to a communication method between terminals, the base station may also be considered a type of terminal. For example, terminal 1 may be a first device (100), and terminal 2 may be a second device (200).

For example, terminal 1 can select a resource unit corresponding to a specific resource within a resource pool, which means a set of a series of resources. Then, terminal 1 can transmit an SL signal using the resource unit. For example, terminal 2, which is a receiving terminal, can be configured with a resource pool in which terminal 1 can transmit a signal, and can detect a signal of terminal 1 within the resource pool.

Here, if terminal 1 is within the connection range of the base station, the base station can inform terminal 1 of the resource pool. On the other hand, if terminal 1 is outside the connection range of the base station, another terminal can inform terminal 1 of the resource pool, or terminal 1 can use a pre-configured resource pool.

In general, a resource pool can be composed of multiple resource units, and each terminal can select one or multiple resource units to use for its SL signal transmission.

Figure 8 shows resource units for V2X or SL communication.

Referring to Fig. 8, the entire frequency resources of the resource pool can be divided into NF units, and the entire time resources of the resource pool can be divided into NT units. Accordingly, a total of NF * NT resource units can be defined within the resource pool. Fig. 8 shows an example in which the resource pool repeats with a period of NT subframes.

As shown in Fig. 8, one resource unit (e.g., Unit #0) may appear repeatedly periodically. Or, in order to obtain a diversity effect in the time or frequency dimension, the index of the physical resource unit to which one logical resource unit is mapped may change in a pre-determined pattern over time. In the structure of such resource units, a resource pool may mean a set of resource units that a terminal that wishes to transmit an SL signal can use for transmission.

Resource pools can be subdivided into several types. For example, depending on the content of the SL signal transmitted from each resource pool, resource pools can be divided as follows.

(1) Scheduling Assignment (SA) may be a signal that includes information such as the location of resources used by a transmitting terminal for transmission of an SL data channel, MCS (Modulation and Coding Scheme) or MIMO (Multiple Input Multiple Output) transmission method required for demodulation of other data channels, and TA (Timing Advance). SA may also be transmitted multiplexed with SL data on the same resource unit, in which case the SA resource pool may mean a resource pool in which SA is multiplexed with SL data and transmitted. SA may also be called an SL control channel.

(2) SL data channel (Physical Sidelink Shared Channel, PSSCH) may be a resource pool used by a transmitting terminal to transmit user data. If SA is multiplexed and transmitted together with SL data on the same resource unit, only SL data channels excluding SA information may be transmitted in the resource pool for the SL data channel. In other words, REs (Resource Elements) used to transmit SA information on individual resource units within the SA resource pool may still be used to transmit SL data in the resource pool of the SL data channel. For example, a transmitting terminal may transmit PSSCH by mapping it to consecutive PRBs.

(3) A discovery channel may be a resource pool for transmitting terminals to transmit information such as their IDs. Through this, the transmitting terminals can enable adjacent terminals to discover themselves.

Even when the content of the SL signal described above is the same, different resource pools may be used depending on the transmission/reception properties of the SL signal. For example, even when it is the same SL data channel or discovery message, it may be again divided into different resource pools depending on the transmission timing determination method of the SL signal (for example, whether it is transmitted at the time of reception of a synchronization reference signal or whether it is transmitted by applying a certain timing advance at the time of reception), the resource allocation method (for example, whether the base station designates transmission resources of individual signals to individual transmitting terminals or whether individual transmitting terminals select individual signal transmission resources on their own within the resource pool), the signal format (for example, the number of symbols that each SL signal occupies in one subframe or the number of subframes used for transmission of one SL signal), the signal strength from the base station, the transmission power strength of the SL terminal, etc.

FIG. 9 illustrates a communication structure that can be provided in a 6G system according to an embodiment of the present disclosure. The embodiment of FIG. 9 can be combined with various embodiments of the present disclosure.

New network characteristics in 6G could include:

- Satellite integrated network

- Connected intelligence: Unlike previous generations of wireless communication systems, 6G is revolutionary and will update the wireless evolution from “connected things” to “connected intelligence.” AI can be applied at each stage of the communication process (or at each stage of signal processing, as described below).

- Seamless integration of wireless information and energy transfer

- Ubiquitous super 3D connectivity: Access to networks and core network functions of drones and very low Earth orbit satellites will create super 3D connectivity in 6G ubiquitous.

Some general requirements from the new network characteristics of 6G as mentioned above can be as follows:

- small cell networks

- Ultra-dense heterogeneous network

- High-capacity backhaul

- Radar technology integrated with mobile technology: High-precision localization (or location-based services) through communications is one of the functions of 6G wireless communication systems. Therefore, radar systems will be integrated with 6G networks.

- Softwarization and virtualization

Below, the core implementation technologies of the 6G system are described.

- Artificial Intelligence: Introducing AI into communications can simplify and improve real-time data transmission. AI can use a lot of analytics to determine how complex target tasks are performed. In other words, AI can increase efficiency and reduce processing delays. Time-consuming tasks such as handover, network selection, and resource scheduling can be performed instantly using AI. AI can also play a significant role in M2M, machine-to-human, and human-to-machine communications. AI can also be a rapid communication in Brain Computer Interface (BCI). AI-based communication systems can be supported by metamaterials, intelligent structures, intelligent networks, intelligent devices, intelligent cognitive radios, self-sustaining wireless networks, and machine learning.

- THz communication (terahertz communication): The data rate can be increased by increasing the bandwidth. This can be done by using sub-THz communication with wide bandwidth and applying advanced massive MIMO technology. THz waves, also known as sub-millimeter waves, generally refer to the frequency band between 0.1 THz and 10 THz with corresponding wavelengths ranging from 0.03 mm to 3 mm. The 100 GHz–300 GHz band range (Sub THz band) is considered to be the main part of the THz band for cellular communications. Adding the Sub THz band to the mmWave band will increase the capacity of 6G cellular communications. Of the defined THz bands, 300 GHz–3 THz is in the far infrared (IR) frequency band. The 300 GHz–3 THz band is part of the optical band but is at the boundary of the optical band, just behind the RF band. Therefore, this 300 GHz–3 THz band shows similarities with RF. FIG. 10 illustrates an electromagnetic spectrum according to an embodiment of the present disclosure. The embodiment of FIG. 10 may be combined with various embodiments of the present disclosure. Key characteristics of THz communications include (i) widely available bandwidth to support very high data rates, and (ii) high path loss at high frequencies (highly directional antennas are indispensable). The narrow beam width generated by the highly directional antennas reduces interference. The small wavelength of THz signals allows a much larger number of antenna elements to be integrated into devices and BSs operating in this band. This enables the use of advanced adaptive array techniques to overcome range limitations.

- Large-scale MIMO technology

- Hologram beamforming (HBF)

- Optical wireless technology

- Free space optical transmission backhaul network (FSO backhaul network)

- Quantum communication

- Cell-free communication

- Integration of wireless information and power transmission

- Integration of wireless communication and sensing

- Integrated access and backhaul network

- Big data analysis

- Reconfigurable intelligent surface

- Metaverse

- Block-chain

- Unmanned aerial vehicles (UAV): UAVs or drones will be a crucial element in 6G wireless communications. In most cases, high-speed data wireless connectivity can be provided using UAV technology. The base station (BS) entity can be installed on the UAV to provide cellular connectivity. UAVs may have certain features not found in fixed BS infrastructure such as easy deployment, robust line-of-sight links, and freedom of movement with controlled mobility. During emergency situations such as natural disasters, deployment of terrestrial communication infrastructure is not economically feasible and sometimes cannot provide services in volatile environments. UAVs can easily handle such situations. UAVs will be a new paradigm in wireless communications. This technology facilitates three basic requirements of wireless networks namely eMBB, URLLC, and mMTC. UAVs can also support several purposes such as enhancing network connectivity, fire detection, disaster emergency services, security and surveillance, pollution monitoring, parking monitoring, and accident monitoring. Therefore, UAV technology is recognized as one of the most important technologies for 6G communications.

- Autonomous driving (self-driving): V2X (vehicle to everything), a key element of building autonomous driving infrastructure, can be a technology that allows cars to communicate and share with various elements on the road, such as vehicle to vehicle (V2V) wireless communication and vehicle to infrastructure (V2I) wireless communication. In order to maximize the performance of autonomous driving and ensure high safety, fast transmission speed and low-latency technology are essential. In addition, in the future, autonomous driving may need to go beyond the level of delivering warnings or guidance messages to drivers and actively intervene in vehicle operation and directly control the vehicle in dangerous situations. To this end, the amount of information that needs to be transmitted and received may become enormous, so 6G is expected to maximize autonomous driving with faster transmission speeds and lower latency than 5G.

Vehicular Communications for ITS

ITS (Intelligent Transport System) utilizing V2X (Vehicle-to-Everything) can be mainly composed of Access layer, Network & Transport layer, Facilities layer, Application layer, Security, Management Entity, etc. Vehicular communication can be applied to various scenarios such as vehicle-to-vehicle communication (V2V), vehicle-to-base station communication (V2N, N2V), vehicle-to-Road-Side Unit (RSU) communication (V2I, I2V), RSU-to-RSU communication (I2I), vehicle-to-person communication (V2P, P2V), RSU-to-person communication (I2P, P2I). Vehicles, base stations, RSUs, and people that are the subjects of vehicle communication are referred to as ITS stations.

Figure 11 is a drawing for explaining the ITS station reference architecture.

The ITS station reference architecture consists of an Access layer, a Network & Transport layer, a Facilities layer, an Entity for Security and Management, and an Application layer at the top, and basically follows the layered OSI model.

Specifically, referring to FIG. 11, the ITS station reference structure features based on the OSI model are illustrated. The access layer of the ITS station corresponds to OSI layer 1 (physical layer) and layer 2 (data link layer), the network & transport layer of the ITS station corresponds to OSI layer 3 (network layer) and layer 4 (transport layer), and the facilities layer of the ITS station corresponds to OSI layer 5 (session layer), layer 6 (presentation layer), and layer 7 (application layer).

The application layer located at the top of the ITS station performs functions that support the actual implementation of use cases and can be selectively used depending on the use case. The management entity manages all layers including communication and operation of the ITS station. The security entity provides security services for all layers. Each layer of the ITS station exchanges data to be transmitted or received through vehicle communication and additional information for various purposes through interfaces. The following is an abbreviation description of various interfaces.

MA: Interface between management entity and application layer

MF: Interface between management entity and facilities layer

MN: Interface between management entity and networking & transport layer

MI: Interface between management entity and access layer

FA: Interface between facilities layer and ITS-S applications

NF: Interface between networking & transport layer and facilities layer

IN: Interface between access layer and networking & transport layer

SA: Interface between security entity and ITS-S applications

SF: Interface between security entity and facilities layer

SN: Interface between security entity and networking & transport layer

SI: Interface between security entity and access layer

Fig. 12 is an example structure of an ITS station that can be designed and applied based on a reference structure.

The main concept of the reference architecture of an ITS station is to allow communication processing between two end-vehicles/users, which are configured as a communication network, to be divided into layers, each with its own special function. That is, when a message between vehicles is generated, the data is transmitted through each layer down one layer at a time from the vehicle and the ITS system (or other ITS-related terminal/system), and on the other side, when a message arrives, the vehicle or ITS (or other ITS-related terminal/system) that receives the message passes through one layer at a time and transmits it.

The ITS system via vehicle communication and network is organically designed by considering various access technologies, network protocols, communication interfaces, etc. to support various use cases, and the role and function of each layer described below may change depending on the situation. The following is a brief description of the main functions of each layer.

The application layer plays a role in supporting various use cases by actually implementing them, such as providing safety and efficient traffic information and other entertainment information.

The Application layer controls the ITS Station to which the application belongs in various forms, or provides services by transmitting service messages to end vehicles/users/infrastructures through vehicle communication through the lower access layer, network & transport layer, and facilities layer. At this time, the ITS application can support various use cases, and generally, these use cases can be supported by grouping them with other applications such as road safety, traffic efficiency, local services, and infotainment. Application classification, use cases, etc. can be updated when a new application scenario is defined. Layer management manages and services information related to the operation and security of the application layer, and the related information is bidirectionally transmitted and shared through the MA (interface between management entity and application layer) and SA (interface between security entity and ITS-S applications) (or SAP: Service Access Point, e.g. MA-SAP, SA-SAP). The transmission of requests from the application layer to the facilities layer or service messages and related information from the facilities layer to the application layer is performed through FA (interface between facilities layer and ITS-S applications or FA-SAP).

The facilities layer plays a role in supporting the effective realization of various use cases defined in the upper application layer, and can perform, for example, application support, information support, and session/communication support.

The facilities layer basically supports the upper three layers of the OSI model, i.e., session layer, presentation layer, application layer, and functions. Specifically, it provides facilities such as application support, information support, and session/communication support for ITS. Here, facilities refer to components that provide functionality, information, and data.

Application support facilities are facilities that support the operation of ITS applications (mainly creating messages for ITS, sending and receiving messages with lower layers, and managing the same). The application support facilities include CA (Cooperative Awareness) basic service and DEN (Decentralized Environmental Notification) basic service. In the future, facility entities and related messages for new services such as CACC (Cooperative Adaptive Cruise Control), Platooning, VRU (Vulnerable Roadside User), and CPS (Collective Perception Service) may be additionally defined.

Information support facilities are facilities that provide common data information or databases to be used by various ITS applications, such as Local Dynamic Map (LDM).

Session/communication support facilities are facilities that provide services for communications and session management, including addressing mode and session support.

Additionally, facilities can be divided into common facilities and domain facilities.

Common facilities are facilities that provide common services or functions required for various ITS applications and ITS station operations, such as time management, position management, and services management.

Domain facilities are facilities that provide special services or functions that are only required by some (one or more) ITS applications, such as the DEN basic service for Road Hazard Warning applications (RHW). Domain facilities are optional and will not be used if they are not supported by the ITS station.

Layer management manages and services information related to the operation and security of the facilities layer, and the related information is bidirectionally transmitted and shared through the MF (interface between management entity and facilities layer) and SF (interface between security entity and facilities layer) (or MF-SAP, SF-SAP). Requests from the application layer to the facilities layer or service messages and related information from the facilities layer to the application layer are transmitted through FA (or FA-SAP), and bidirectional service messages and related information between the facilities layer and the lower networking & transport layer are transmitted by NF (interface between networking & transport layer and facilities layer, or NF-SAP).

It plays a role in configuring a network for vehicle communication between homogeneous or heterogeneous networks by supporting various transport protocols and network protocols. For example, it provides Internet access, routing, and vehicle networks using Internet protocols such as TCP/UDP+IPv6, and can form a vehicle network using BTP (Basic Transport Protocol) and GeoNetworking-based protocols. At this time, networking utilizing geographical position information can also be supported. The vehicle network layer can be designed or configured dependent on the technology used in the access layer (access layer technology-dependent), or can be designed or configured regardless of the technology used in the access layer (access layer technology-independent, access layer technology agnostic).

The functions of the European ITS network & transport layer are as follows. Basically, the functions of the ITS network & transport layer are similar or identical to the OSI 3 layer (network layer) and 4 layer (transport layer) and have the following characteristics:

The transport layer is a connection layer that transmits service messages and related information provided from upper layers (session layer, presentation layer, application layer) and lower layers (network layer, data link layer, physical layer), and plays a role in managing the data sent by the application of the sending ITS station so that it arrives accurately at the application process of the destination ITS station. As shown in Figure OP5.1, examples of transport protocols that can be considered in European ITS include TCP and UDP, which are used as existing Internet protocols, as well as transport protocols for ITS only, such as BTS.

The network layer determines the logical address and packet delivery method/path, and adds information such as the destination's logical address and delivery path/method to the header of the network layer for the packet provided by the transport layer. Examples of packet methods include unicast, broadcast, and multicast between ITS stations. Various networking protocols for ITS can be considered, such as GeoNetworking, IPv6 networking with mobility support, and IPv6 over GeoNetworking. GeoNetworking protocols can apply various delivery paths or delivery ranges, such as forwarding using the location information of stations including vehicles, or forwarding using the number of forwarding hops, in addition to simple packet transmission.

Layer management related to the network & transport layer manages and services information related to the operation and security of the network & transport layer, and the related information is bidirectionally transmitted and shared through MN (interface between management entity and networking & transport layer, or MN-SAP) and SN (interface between security entity and networking & transport layer, or SN-SAP). Bidirectional transmission of service messages and related information between the facilities layer and the networking & transport layer is performed by NF (or NF-SAP), and exchange of service messages and related information between the networking & transport layer and the access layer is performed by IN (interface between access layer and networking & transport layer, or IN-SAP).

The North American ITS network & transport layer, like Europe, supports IPv6 and TCP/UDP to support existing IP data, and defines WSMP (WAVE Short Message Protocol) as a protocol exclusive to ITS.

The packet structure of WSM (WAVE Short Message) generated according to WSMP consists of WSMP Header and WSM data through which the Message is transmitted. The WSMP header consists of version, PSID, WSMP header extension field, WSM WAVE element ID, and length.

Version is defined by the WsmpVersion field that indicates the actual WSMP version of 4 bits and the reserved field of 4 bits. PSID is a provider service identifier that is assigned to the application from the upper layer and helps the receiver determine the appropriate upper layer. Extension fields are fields for extending the WSMP header and insert information such as channel number, data-rate, and transmit power used. WSMP WAVE element ID specifies the type of WAVE short message to be transmitted. Lenth specifies the length of the transmitted WSM data in octets through the 12-bit WSMLemgth field, and the remaining 4 bits are reserved. LLC Header enables IP data and WSMP data to be transmitted separately and is distinguished through the Ethertype of SNAP. The structure of LLC header and SNAP header is defined in IEEE802.2. When transmitting IP data, Ethertype is set to 0x86DD to configure the LLC header. When transmitting WSMP, the LLC header is configured by setting the Ethertype to 0x88DC. For the receiver, the Ethertype is checked, and if it is 0x86DD, the packet is sent up to the IP data path, and if the Ethertype is 0x88DC, it is sent up to the WSMP path.

The access layer is responsible for transmitting messages or data received from the upper layer through a physical channel. As an access layer technology, ITS-G5 vehicle communication technology based on IEEE 802.11p, satellite/broadband wireless mobile communication technology, 2G/3G/4G (LTE (Long-Term Evolution) etc.)/5G wireless cellular communication technology, cellular-V2X vehicle-only communication technology such as LTE-V2X and NR-V2X (New Radio), broadband terrestrial digital broadcasting technology such as DVB-T/T2/ATSC3.0, GPS technology, etc. can be applied.

The data link layer is a layer that converts a physical line between adjacent nodes (or between vehicles) that is usually noisy into a communication channel without transmission errors that can be used by the upper network layer. It performs the functions of transmitting/transporting/delivering a 3-layer protocol, the framing function that groups and divides data to be transmitted into packets (or frames) as transmission units, the flow control function that compensates for the speed difference between the sender and the receiver, and the function of detecting transmission errors and correcting them (since errors and noise are likely to occur randomly due to the characteristics of the physical transmission medium) or detecting transmission errors through a timer and ACK signal on the sending side using methods such as ARQ (Automatic Repeat Request) and retransmitting packets that were not received correctly. It also performs the function of assigning sequence numbers to packets and ACK signals to avoid confusing packets or ACK signals, and the functions of controlling the establishment, maintenance, short-circuiting, and data transmission of data links between network entities. The main functions of the LLC (Logical Link Control), RRC (Radio Resource Control), PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control), and MCO (Multi-channel Operation) sub-layers that make up the data link layer of Figure OP6.1 are as follows.

The LLC sub-layer allows various different lower MAC sub-layer protocols to be used, allowing communication independent of the network topology. The RRC sub-layer performs functions such as broadcasting cell system information required for all UEs in the cell, managing the delivery of paging messages, managing (establishment/maintenance/release) RRC connection between UEs and E-UTRAN, mobility management (handover), transferring UE context between eNodeBs during handover, UE measurement reporting and control thereof, UE capability management, temporary assignment of cell ID to UE, security management including key management, RRC message encryption, etc. The PDCP sub-layer can perform IP packet header compression using compression methods such as ROHC (Robust Header Compression), and performs functions such as encryption (ciphering) of control messages and user data, data integrity, and prevention of data loss during handover. The RLC sub-layer transmits data by fitting packets from the upper PDCP layer to the allowable size of the MAC layer through packet segmentation/concatenation, and improves data transmission reliability through transmission error and retransmission management, and performs order confirmation, reordering, and duplication checks for received data. The MAC sub-layer performs the functions of controlling collision/contention between nodes for use of shared media by multiple nodes, fitting packets transmitted from the upper layer to the physical layer frame format, assigning and identifying transmitter/receiver addresses, carrier detection, collision detection, and detecting obstacles in the physical medium. The MCO sub-layer enables effective provision of various services using multiple frequency channels, and its main function is to effectively distribute the traffic load on a specific frequency channel to other channels to minimize collision/contention of vehicle-to-vehicle communication information on each frequency channel.

The physical layer is the lowest layer in the ITS hierarchy. It defines the interface between nodes and transmission media, performs modulation, coding, and mapping transmission channels to physical channels for bit transmission between data link layer entities, and notifies the MAC sublayer whether the wireless medium is busy or idle through carrier sense and clear channel assessment (CCA).

Meanwhile, the SoftV2X system is a V2X communication using the UU interface, in which the SoftV2X server receives a VRU message or a PSM (Personal Safety Message) from a VRU (Vulnerable Road User) or a V2X vehicle, transmits information on surrounding VRUs or vehicles based on the VRU message or PSM message, or analyzes road conditions on which surrounding VRUs or vehicles are moving, and transmits a message notifying surrounding VRUs or vehicles of a collision warning based on the analyzed information. Here, the VRU message or PSM message is a message transmitted to the SoftV2X server through the UU interface, and may include mobility information on the VRU, such as the location, moving direction, moving path, and speed of the VRU. In other words, the SoftV2X system receives mobility information on VRUs and/or vehicles related to V2X communication through the UU interface, and the SoftV2X server, such as a network, controls the driving path of the VRU, the VRU movement flow, etc. based on the received mobility information. Alternatively, the SoftV2X system may be configured in relation to V2N communication.

User equipment or pedestrian equipment (VRU devices) that are difficult to perform direct communication (PC5, DSRC) related to V2X communication can provide or receive driving information and mobility information to surrounding vehicles or VRUs through a SoftV2X system based on the UU interface. Through this, the user equipment or pedestrian equipment (VRU devices) that are difficult to perform direct communication (PC5, DSRC) can be protected from safety by surrounding vehicles.

The method proposed below can be applied to a terminal or a vehicle configured with a terminal driving on a road, etc., and for convenience of explanation, a terminal or a vehicle configured with a terminal is defined as a terminal.

Support for group-level Maneuver coordination

Conventionally, when maneuver driving is required between V2X terminals, maneuver coordination can be performed through a procedure for exchanging messages such as MSCM (Maneuver sharing and coordination message) or MCM (Manoeuvre coordination message). Referring to SAE J3186 (Application Protocol and Requirements for Maneuver Sharing and Coordination Service), maneuver coordination can be performed through awareness state, maneuver negotiation state, and maneuver execution state. However, when a queue occurs between lanes requiring maneuver coordination, the conventional procedure may be inefficient in terms of both communication traffic and traffic operation because it is performed on a per-terminal basis.

In addition, the terminal can recognize the cause of the queue by receiving a V2X message (such as DENM or RSA) that includes event information about an unexpected situation on the road. However, a queue can also occur even if it is not a specific event. For example, a queue can occur in a specific lane due to signal control, traffic congestion, etc. In this case, it is difficult for the terminals to identify the cause of the queue, and thus they cannot perform appropriate driving-related actions according to the cause of the queue. In this case, unnecessary waiting time can occur due to the queue. Therefore, when the length of the queue is longer than a predetermined length due to factors such as signal control or traffic congestion, it is necessary to manage terminals/vehicles having the same driving mission as a group with respect to the factor.

Below, we describe in detail a method for managing/coordinating the movement of terminals with the same driving mission/driving intent as a group through support of various V2X infrastructures (e.g., vehicles, RSUs, servers, etc.) in cases where a waiting line of terminals/vehicles occurs on a specific road section due to road facilities (e.g., traffic lights, etc.) or geographical/road geometry characteristics (e.g., connecting roads, intersections, etc.).

Below, specific embodiments of the proposed method described above are described in detail.

Depending on the road environment (e.g., road geometry characteristics or road facility types, etc.), there may be cases where the driving intention/mission of terminals is different for each lane. In this case, a waiting line may occur between terminals having the same or similar driving intention/mission in a specific lane. For example, at an intersection, the driving directions (Direction) may be different for each lane, such as going straight, turning left, turning right, and turning U-turn. In this case, a waiting line of terminals (or users of terminals) having the driving intention/mission to make a left turn may occur. When a waiting line (or low-speed driving line) of terminals having the same driving intention/mission occurs, path prediction of the terminals may be easy and the moving distance of the terminals may not be large. In this case, since each of the terminals periodically broadcasts/transmits individual recognition information, communication traffic efficiency may be significantly reduced. In addition, when individual maneuver coordination is performed between terminals, delays resulting from one-to-one negotiation procedures, acceleration and deceleration delays resulting from starting and stopping, etc. may accumulate, and the efficiency of traffic flow may be significantly reduced due to such accumulated delays.

Therefore, the proposed method proposes a method/device that can support state sharing and maneuver coordination at the group level by forming a temporary group (i.e., a group for maneuver coordination) among terminals (or vehicles) with the same/similar driving intention/mission/direction with the support of various V2X infrastructures. Here, the driving intention/mission can mean having a clear driving goal or will.

Below, we describe in detail the process of forming a temporary group for maneuver coordination and operating the temporary group.

Figure 13 is a drawing for explaining a method of forming a group for maneuver coordination or participating in the group, and Figure 14 is a drawing for explaining the structure of a message for maneuver coordination.

Referring to FIG. 13 (a), the V2X infrastructure receives messages including status information from terminals (e.g., CAM, BSM, PSM, VAM (vulnerable road user awareness message) including individual recognition information, which are recognition messages) (S131), and can determine whether a group creation condition is satisfied based on the received status information (S132). The group creation condition may be when the number of terminals with similar or identical driving intentions/missions is a specific number or more, or when the waiting time of the terminals is a specific waiting time or more (i.e., when the number of terminals having a threshold waiting time or more is a threshold number or more), or, the V2X infrastructure may determine whether the group creation condition is satisfied by further considering various traffic environments in addition to the number of terminals forming the waiting line and the waiting time.

Next, if terminals satisfying the group creation conditions are confirmed/detected, the V2X infrastructure can request the terminals to create/join a group for maneuver coordination. If the terminals approve the group creation/participation (S133), the V2X infrastructure can create a temporary group for maneuver coordination. In this case, the terminals can increase the transmission cycle of a recognition message including individual recognition information or stop transmitting the recognition message. In addition, the V2X infrastructure can periodically share the group status for the temporary group with the terminals and/or surrounding terminals (S134). The V2X infrastructure can calculate the traffic flow for performing maneuver coordination of the group by considering the status/waiting time for the group (S135). If the waiting time for the group is greater than a specific threshold or the signal of the traffic light is changed to a signal allowing a traffic flow corresponding to the driving intention, the V2X infrastructure can transmit a departure command message for the group (S136-1). Alternatively, if the waiting time for the group is below a certain threshold or the signal of the traffic light is a signal that does not allow traffic flow corresponding to the driving intention, the V2X infrastructure may transmit a stop command message to the group (S136-2).

In addition, the V2X infrastructure can provide group status information including at least one of a cause for a waiting line in front (e.g., driving intention/mission for the group), the number of terminals, and an expected waiting/exit time) to a rear approaching terminal after group creation, and can enable the rear approach terminal to decide whether to participate in the group by providing the group status information. If the rear approach terminal participates in the group, the V2X infrastructure can update the group status information and share the updated group status information (with terminals in the group/surrounding terminals) (S134). Alternatively, if the rear approach terminal refuses to participate in the group, the V2X infrastructure can request the approaching terminal to change lanes/paths, etc. (S137).

Referring to Fig. 13 (b), a terminal may determine whether to participate in a group for maneuver coordination with the support of a V2X infrastructure, etc. The terminal may periodically transmit an awareness message including status information for its own recognition. The terminal may receive a message including group status information for maneuver coordination and/or a group participation message from a V2X infrastructure (or a leader terminal of the group) (S141-1). The terminal may determine whether to participate in the group based on the cause (driving intention/mission of the group), the number of terminals, and the expected waiting/exit time for the waiting line included in the group status information (S141-2). If the terminal's driving intention/mission corresponds to the driving intention/mission of the group, the terminal may transmit an approval message approving participation in the group to the V2X infrastructure. In this case, the terminal may stop transmitting an awareness message for individual awareness information or increase a transmission cycle of the awareness message (S142). The terminal may receive group status information for the group it has joined and perform an operation of waiting within the waiting line (S143). The above terminal can perform driving operation related to maneuver coordination based on a control message for group control received from the V2X infrastructure (or, Road Side Unit; RSU) (S144). When the terminal leaves the group due to achievement of driving intention/driving mission related to the group or change of route, the terminal can transmit a group departure message to the V2X infrastructure (or, RSU) (S145), and set a value of a transmission period of a recognition message including its own individual recognition information to a default value, or restart transmission of the recognition message that was interrupted (S146). In this case, the terminal can transmit the recognition message at a shorter period than when participating in the group.

In summary, the proposed invention can form a temporary group when the number of terminals having the same driving mission/driving intent is greater than a certain threshold number, and can support/control status sharing and maneuver coordination in group units. For example, the V2X infrastructure can determine whether a group creation condition for maneuver coordination is satisfied through the status information of the terminals received in a specific section. Here, the group creation condition can be determined by considering various traffic situations and conditions such as the waiting queue level/size of terminals having the same driving intent/driving mission, status information of the terminals (speed, location, etc.), and expected waiting time. If there are terminals satisfying the group creation condition, the V2X infrastructure can transmit a message for group participation/group creation to the terminals. If a message approving group participation/creation is received from the terminals, the V2X infrastructure can create a temporary group for maneuver coordination, increase the transmission cycle of the message for the awareness information of each terminal, and periodically share the status information in group units (or, the V2X infrastructure can periodically transmit the status information in group units directly). After the group is created, there may be a rear approaching terminal approaching from behind the group. In this case, the V2X infrastructure may provide the rear approaching terminal with information (Group intent), number of terminals, expected waiting time, expected departure time, etc. for the front queue (or, temporary group for the queue) information (Group status). The rear approaching terminal may decide whether to participate in the group related to the front queue based on the information (Group status). When the rear approaching terminal joins the group, the V2X infrastructure may update group information for the group and share the updated group information with terminals included in the group (and/or surrounding terminals). In contrast, when the rear approaching terminal refuses to join, the V2X infrastructure may request the rear approaching terminal to change lanes/courses, etc., to induce an avoidance action of the approaching terminal for the queue or group (Queue/Group). Finally, when maneuver coordination is required, the terminals included in the group may perform maneuver coordination for each group with the support of the V2X infrastructure. To support such group-based maneuver coordination, terminals and/or V2X infrastructure can utilize existing V2X messages (adding new fields) or use new messages for group-based maneuver coordination. The proposed method can support decision-making of users of the surrounding terminals/approaching terminals by providing driving intentions/missions of the front group to surrounding terminals/approaching terminals, and reduce unnecessary waiting time of users of the surrounding terminals/approaching terminals. In addition, when a group for maneuver coordination is formed, the transmission/reception of messages including unnecessary recognition information between terminals in the group can be reduced, and the efficiency of the communication channel can be improved through sharing of group-based status information. In addition, the proposed method can efficiently control traffic flow by supporting group-based maneuver coordination.

In this way, the V2X infrastructure can create a temporary group for maneuver coordination for terminals having the same driving intention/mission or mission. If it is difficult to mutually share/recognize/predict the driving intention/mission of the terminals (for example, if the terminals do not transmit status information for individual recognition), the V2X infrastructure can determine whether the terminals located in the lane satisfy the group creation conditions based on the characteristics of the lane (a lane with a high probability of having the same mission in a specific section, for example, a left-turn lane at an intersection, a lane that can enter/exit a connecting road of a highway, etc.). For example, the V2X infrastructure can estimate/predict the driving intention/mission of the terminals located in the lane based on the characteristics of the lane, and determine whether the terminals located in the lane satisfy the group creation conditions based on the estimated and predicted driving intention/mission. If the above terminals satisfy the group creation conditions, the V2X infrastructure can transmit a group participation/creation message including driving intention information for the predicted/determined driving intention/mission to the terminals, and can induce terminals among the terminals that have not performed the driving intention/mission of the group to avoid waiting in the lane.

For example, the V2X infrastructure may transmit a message requesting participation in group A1 to the waiting terminals when the number of waiting terminals located in a predetermined lane and waiting at a speed below the threshold speed (condition 1 below) is equal to or greater than the minimum threshold number, or when the total waiting time of the waiting terminals is equal to or greater than the minimum threshold time (condition 2 below). Alternatively, since the number of terminals to be included in the group to be created/requested to be created/participated may be inefficiently operated when controlling traffic between signals or other groups if it is excessively large, the maximum number of terminals to participate in the group may be determined/limited based on the current traffic situation. To this end, the V2X infrastructure may determine the number of groups to be formed for the terminals based on whether the total waiting time is equal to or greater than the maximum waiting time (e.g., condition 3 below). For example, the V2X infrastructure may create one group A1 when the sum of the total waiting times of all terminals is equal to or less than the maximum threshold time. Alternatively, when the total waiting time exceeds the maximum threshold time, the V2X infrastructure may create group A1 and group A2 for the terminals. Here, the total waiting time may mean the sum of all times for waiting and moving from the current terminal location to a reference line (e.g., a stop line) before performing a mission. For example, in the case of waiting for a signal, it may mean the total time for the waiting time due to the signal and the predicted time from the current location to the time when the traffic signal turns on and to accelerate and pass the stop line. The V2X infrastructure may set a threshold value by considering the maximum waiting time for group A1 to pass the stop line at the next traffic signal in a signal waiting situation, and may set/determine the maximum threshold number of terminals to be included in group A1 based on the maximum waiting time. Meanwhile, the minimum threshold time and the maximum threshold time may be flexibly changed based on the location of each terminal, the characteristics of the lane, the traffic situation, etc.

- Condition 1: Terminal speed < threshold speed (threshold A),

- Condition 2: Total number of waiting terminals > minimum threshold number (threshold B), or total waiting time > minimum waiting time (threshold C).

- Condition 3: Total waiting time < maximum waiting time (threshold D)

For example, the V2X infrastructure may transmit a message to the terminals waiting in the specific lane to create a group for the waiting terminals when the number of terminals waiting in a specific lane (i.e., terminals moving below a specific threshold speed) is equal to or greater than a minimum threshold number or when the maximum waiting time of the waiting terminals (e.g., the total time required for all of the waiting terminals to achieve the driving intention/mission) is equal to or greater than a minimum threshold time (Condition 1 and Condition 2). Meanwhile, the size of the group may be determined based on the maximum threshold time that can be allowed for the group to achieve the driving intention/mission (Condition 3). Here, the maximum threshold time may be set/determined in consideration of the road environment/signal change cycle (e.g., the time for which a traffic permit signal is maintained), etc.

A message for supporting/implementing the proposed method (hereinafter, “proposed message”) may be a message utilizing a conventional V2X message or a new V2X message. For example, a message according to the proposed method may be a message that extends the message set/message format of MCM, an ETSI ITS standard message or MSCM, an SAE International standard message, which are used to perform existing maneuver coordination, to enable group-level maneuver coordination, or may be a message that adds a new field to MCM, an ETSI ITS standard message, or MSCM, an SAE International standard message.

Referring to FIG. 14, a proposal message for group-based maneuver coordination according to the proposed method may be a message to which an extension field of MCM has been added. The Extension field may include a group MCM container (Optional), and the group MCM container may include fields/information for at least one of a group ID, number of terminals, queue length, expected waiting time, and transmission power control level/transmission period of an individual recognition message when joining a group, which may indicate the status of the group. In this way, a V2X infrastructure (e.g., RSU/network/network) or a group leader may transmit and receive a group MCM defined as a proposal message to support group-based maneuver coordination by using the extension field of MCM.

Alternatively, the procedure (or MCM/MSCM state) of group-based maneuver coordination based on MCM (or MSCM) applied to group-based maneuver coordination may be for the overall state of the group rather than for individual terminals. In the maneuver negotiation procedure (or maneuver negotiation state), negotiation for maneuver coordination between groups may be performed, and group-based maneuver may be performed by the maneuver negotiation procedure performed in the maneuver execution procedure (or maneuver execution state). In addition, a group participation/leaving (join/leave) procedure that can determine participation or departure of a group may be additionally defined.

In addition, messages required for each procedure can be defined. For example, messages defined for each procedure can be configured by adding new fields/extension fields based on the message structure/format of existing MCM and MSCM, or new types of messages can be defined. Or, or, messages defined for each procedure can be BSM, CAM or PSM, VAM in which new fields including information on driving intention/driving mission are additionally defined. In the following, the group participation procedure, the group status sharing procedure, and the group maneuver negotiation procedure are described in detail.

Figures 15 to 18 are diagrams for explaining a group participation procedure, a group status sharing procedure, and a group start negotiation procedure.

The proposal message can be newly defined for each group participation procedure, group status sharing procedure, and group start negotiation procedure. Below, the operation method of each procedure and message is explained in detail.

1. Group participation procedure (or group participation state)

In a group participation procedure, the group leader or V2X infrastructure may provide group status information to a new terminal or an entering terminal to determine whether to participate in the group. For example, the group leader or V2X infrastructure may transmit a message including group status information about a group driving intention/mission that a currently occurring waiting line is caused by waiting for a left turn signal to a rear-facing terminal approaching a group waiting in a left turn lane. Alternatively, the group status information may further include information about an expected waiting time predicted when joining the group. To this end, a proposal message for a group participation procedure may additionally define an additional field/extension field including the group status information in the existing MCM and MSCM formats.

In this case, the access terminal/new terminal can determine whether to participate in the group based on at least one of the group driving intention/mission and expected waiting time included in the group status information included in the proposal message, and transmit a response message (ACK, NACK) thereto.

Alternatively, the group leader or V2X infrastructure may stop transmitting a message requesting participation in the group and transmit a message for creating/forming a new group when the number of terminals included in the group is greater than or equal to the maximum number of terminals set for the group. Here, the maximum number of terminals may be determined by considering the number of lanes corresponding to the group, the number of terminals, signals, the maximum waiting time described above, the presence of terminals that do not support maneuvering, etc. Meanwhile, the proposal message may further include configuration information for increasing a transmission cycle of a recognition message including individual recognition information for terminals participating in the group, or for stopping transmission of the recognition message.

2. Group state sharing procedure (or, group state sharing state)

In the group status sharing procedure, the group leader or V2X infrastructure can send messages to periodically update/share overall situation/status information about the group.

Specifically, the group leader or V2X infrastructure may transmit a message including group state sharing information about at least one of the number of terminals belonging to the group, the length of the queue (queue length), the positions/orders of the terminals within the group, the expected waiting time according to the positions/orders of the terminals, and the expected waiting/entry time for the group. That is, a proposal message for a group state sharing procedure may additionally define at least one additional field/extension field including the group state sharing information in the existing MCM and MSCM formats.

Meanwhile, the group leader or V2X infrastructure can determine/update the expected waiting time for the group in real time by considering the occurrence of events on the road, the signal cycle of traffic lights, negotiations between groups, etc. In other words, depending on the implementation of the group leader or V2X infrastructure, the expected waiting time can be determined by considering various conditions.

For example, if the group is predicted to be able to pass within the next green light period at an intersection, the group leader or V2X infrastructure can determine/predict the total waiting time for the group by combining the remaining signal waiting time (i.e., red light period) at the current time and the time for the group to achieve the group driving intention/mission (e.g., driving intention/mission to pass through the intersection). Here, the total waiting time for the group may be the sum of the signal waiting time at the intersection and the expected waiting time consumed in the unit zone of the terminal order in the group. Alternatively, the group leader or V2X infrastructure can determine the predicted time calculated for each zone of the terminal departing after waiting/stopping based on a distance margin with respect to a stop line. The group leader or V2X infrastructure can correct the predicted time if an emergency situation (insufficient signal confirmation of a preceding vehicle, an event on the road (accident, hazard, presence of VRU, etc.)) occurs and the predicted/determined predicted time falls outside a specific threshold range. Alternatively, in order to prevent tailgating and/or stop line violations, etc. in the case of a group that cannot pass during the next green light period, the group leader or V2X infrastructure may specify information that it cannot pass during the next signal period, re-calculate (signal waiting time × 2) + (estimated time consumed in the unit area of the expected order of group terminals during the second signal waiting), and provide the re-calculated time as information on the expected waiting/exit time to the terminals in the group. Alternatively, in the case of an unprotected/unprotected left turn, if there is a terminal in the opposite lane (e.g., a terminal included in a vehicle), it may be difficult for the group leader or V2X infrastructure to predict the exact expected waiting time. Therefore, the group leader or V2X infrastructure may perform a maneuver negotiation procedure with the terminal in the opposite lane or another group, and periodically update the expected waiting time based on the negotiation result of the maneuver negotiation procedure. Alternatively, in the case where it is difficult to predict the expected waiting time, the group leader or V2X infrastructure may transmit a message including group status sharing information in which the expected waiting time is set to a Null value. A group leader or V2X infrastructure can predict the expected waiting/exit time in real time by calculating movement volume and margin, etc. by time unit in a situation where there is no signal control, such as a connection, and provide group status sharing information including the expected waiting/exit time predicted in real time to terminals in the group.

3. Group mobilization negotiation procedure (group mobilization negotiation state)

First, the maneuver negotiation procedure may be omitted when the group-to-group negotiation procedure is not required. For example, in a situation where group maneuver coordination is required, if one V2X infrastructure (RSU, server, etc.) can control the maneuver coordination for two or more groups within the coverage, the V2X infrastructure can analyze the traffic flow between the two groups and request/instruct group maneuver for the two groups without performing a separate group maneuver negotiation procedure.

In contrast, when two or more V2X infrastructures (RSUs, servers, etc.) need to collect/manage information about each group (or, when group leaders of two groups directly instruct/execute group maneuvering), the group maneuvering negotiation procedure can be performed using a message/message set defined for maneuver negotiation (request/acceptance/rejection) between V2X infrastructures (or between leader terminals elected from the groups). Specifically, the proposed message for the group maneuvering negotiation procedure can be defined to have a message structure/format similar to the existing standard messages MSCM and MCM defined for the maneuvering coordination procedure. However, considering that the proposed message/message set is a message for negotiation between groups, not a message for one-on-one negotiation between terminals, some data elements/fields may be defined/configured differently from the existing standard messages MSCM and MCM.

When the group-based maneuver negotiation procedure according to the proposed method described above is performed, the delay can be significantly reduced compared to the case where the existing terminal-based maneuver negotiation procedure is performed. For example, referring to FIG. 15, multiple terminals (i.e., multiple terminals configured in multiple vehicles) can be located in a lane where two lanes merge. When maneuver coordination and negotiation are performed one-on-one between terminals as in the past, there is a limitation that the time required for all terminals in the waiting queue to negotiate maneuver one-on-one and the acceleration/deceleration delay that occurs when the terminal moves are cumulatively weighted by the number of terminals. In contrast, when group maneuver coordination is performed, the entire sequence of the maneuver negotiation procedure can be reduced. In this case, the time required for maneuver coordination negotiation is reduced, and the acceleration/deceleration delay can also be reduced by performing simultaneous acceleration/deceleration of all terminals in the group through group-based maneuver coordination (e.g., group-based driving start).

With regard to such delay reduction, referring to FIG. 16, when performing a group-based maneuver negotiation procedure, the delay can be significantly reduced compared to performing individual terminal-based maneuver coordination. Here, FIG. 16 (a) illustrates an example of a delay that occurs when a terminal-based maneuver negotiation procedure is performed, and FIG. 16 (b) illustrates an example of a delay that occurs when a group-based maneuver negotiation procedure is performed. Here, it can be assumed that there are four terminals in each of the main lane and the participating lane in a lane merging situation, and that a group is formed with two terminals in each of the main lane and the participating lane when a group is formed. In addition, it can be assumed that the delay time required for the maneuver negotiation is 2 seconds, and the acceleration/deceleration delay time required for the departure of the waiting vehicle is 2 seconds.

Specifically, referring to Fig. 16 (a), when the maneuver coordination of individual terminals is performed, a delay may occur in four sequences. Since the maneuver negotiation delay in each sequence is 2 seconds and the acceleration/deceleration delay is 4 seconds (2 seconds in the terminal of the main lane and 2 seconds in the terminal of the participating lane), the delay in each sequence may be 6 seconds. In this case, the total delay in all sequences may be 24 seconds. In contrast, referring to Fig. 16 (b), when the maneuver coordination is performed in a group unit, a delay may occur in two sequences. At this time, since the vehicles in the group start simultaneously due to the departure of the group unit, the acceleration/deceleration delays of the terminals in the group may not accumulate. Therefore, the maneuver negotiation delay in each sequence may be 2 seconds and the acceleration/deceleration delay may be 4 seconds (2 seconds in the terminal of the main lane and 2 seconds in the group of the participating lane). In this case, the total delay time for all sequences may be 12 seconds. Meanwhile, the examples in Figs. 16 (a) and (b) are calculated only for simple delay, excluding the time for the terminal to drive and pass.

4. Group Startup Execution Procedure

The group maneuver execution procedure may be a procedure in which an action for maneuver coordination of a group unit is instructed. For example, through the group maneuver negotiation procedure, it may be negotiated that group A1 will first make a left turn and group B1 will wait. In this case, in the group maneuver execution procedure, the V2X infrastructure or group leaders may instruct group A1 to perform a left turn and group B1 to wait/stop. In addition, as described above, the group maneuver execution procedure may be performed even in a situation where the negotiation procedure does not exist, if necessary. For example, the V2X infrastructure may perform an instruction for each group without performing the group maneuver negotiation procedure. For example, when the group's driving start is performed by the termination of the signal waiting, the V2X infrastructure may transmit a message instructing the group to start driving even if the group that started the driving did not perform negotiation with other groups.

5. Group Leave Procedure

When a terminal within a group leaves by completing a driving intention/mission (e.g., a left turn), the terminal may transmit a group leaving message to the group leader or the V2X infrastructure. In addition, when a terminal that has received the message for group participation (or the group joining message) described above refuses to participate in the group (or moves to a different route after refusing to participate), the terminal may transmit a group leaving message. Alternatively, when the terminal transmitting the group leaving message is the group leader, the terminal may additionally perform an operation of transferring the qualification of the group leader to another terminal within the group. When the group leaving procedure is completed, the terminal that has left the group may set the transmission cycle of a PSM or VAM, BSM or CAM, which is a recognition message including individual recognition information, to a default value, or may restart the transmission of a suspended recognition message.

The proposed method can be applied to all V2X environments regardless of the support of communication methods (PC5, Uu, etc.) and infrastructure aspects (RSU, server, etc.). In the following, the case with V2X infrastructure support is described in detail in Fig. 17, and the case without V2X infrastructure support is described in detail in Fig. 18.

Referring to FIG. 17, a group for maneuver coordination can be formed with the support of V2X infrastructure such as RSU/integrated server. In this way, in case of receiving support from the infrastructure side, an RSU or network (or integrated server) installed near an intersection or connecting road can receive BSM/CAMs from surrounding terminals (S171). The RSU/network can collect signal information, information on the traffic environment of the relevant section, and/or collect sensing information using a sensor to form/create a group. In addition, the RSU/network can provide group status sharing information for the formed/created group to each group and/or surrounding terminals (S172). When an approaching terminal approaching the group is detected, the RSU/network can transmit a message including group status information to the approaching terminal, and receive a response message approving group participation from the approaching terminal (S174). In this case, the RSU/network may update the group status sharing information by considering the participation of the access terminal in the group, and provide the updated group status sharing information to the group and/or surrounding terminals (S175). In addition, the RSU/network may comprehensively analyze/judge traffic information (traffic volume, speed, distance to stop line, etc.) for two lanes requiring maneuver negotiation in situations such as unprotected/unsignaled left turns, exiting a connecting road, etc., and determine maneuver coordination for each group based on the analyzed/judged traffic information, and directly request/instruct each group about the determined maneuver coordination (S176). Alternatively, the RSU/network may indirectly support the group's decision-making by providing the analyzed information to each group.

Meanwhile, the message exchange procedure for group-unit maneuver coordination with the instruction/support of the RSU/network may share the driving intention/mission between groups, but may omit the procedure for exchanging additional information such as signals, sensor information (Object, VRU information, etc.) and/or event information (since the message exchange procedure for group-unit maneuver coordination is a procedure focused on the maneuver coordination procedure). However, since the RSU/network receives/analyzes comprehensive information, it may additionally receive additional information such as signals, sensor information (Object, VRU information, etc.) and/or event information to appropriately instruct/support the maneuver coordination of each group.

Alternatively, referring to FIG. 18, groups for maneuver coordination may be formed even without support from V2X infrastructure such as RSU/network. Specifically, in the absence of support from the infrastructure side, terminals may form/create groups (group A, group B) at appropriate levels on their own, and maneuver coordination may be performed between group leaders (group A leader, group B leader). Here, the leader of each group may update group state information about the group state, share the updated group state information, and perform maneuver negotiation procedures, maneuver execution procedures, etc. between groups. Each group leader may be designated as the frontmost or rearmost vehicle of the group. Each group leader may perform a procedure for changing the group leader by considering the situation of a terminal leaving or newly entering its group. Alternatively, each group leader may perform a procedure for changing the group leader when it is difficult to perform the role of an appropriate group leader due to its own processing load. A rear-approaching terminal/vehicle newly approaching from the rear of the group may inform the leader of the group of information about its approach (S181). In this case, the group leader can transmit a group participation message together with information such as group status, driving intention/mission, etc. to the rear approach terminal (S183). If the rear entry terminal transmits a message approving participation of the group (S184), the rear entry terminal can stop or reduce the cycle of individual recognition message transmission. The group leader can periodically update and share the group status message (S185). If maneuver coordination is required between groups, such as in an unprotected/unsignaled left turn situation, the group A leader can transmit a maneuver request to perform a left turn first to the group B leader in the opposite lane (S186). If the group B leader approves the maneuver request (S187), group A can perform a left turn before group B.

In this way, terminals can perform the operation coordination through the procedure of exchanging messages between groups by electing a group leader without the instruction/support of the RSU or server. In the procedure of exchanging messages between groups, the procedure for exchanging additional information such as signals, sensor information (object, VRU information, etc.), and event information is omitted, but group operation coordination can be adjusted by receiving such additional information.

Figures 19 and 20 are diagrams for explaining a method of utilizing group-based maneuver coordination according to traffic conditions.

The proposed method described above can be applied to actual traffic situation scenarios as follows. For example, there is a group waiting scenario in which terminals with the same/similar driving intention/mission temporarily form a group and share the group state during waiting or low-speed driving.

Specifically, referring to FIG. 19, a queue may occur in a left-turn lane at an intersection where traffic flow is controlled by a traffic light. In this case, the V2X infrastructure (or terminal) may predict the number of terminals that can pass at the next left-turn signal, and form a temporary group with a left-turn driving intention/mission. The V2X infrastructure (or terminal) may transmit a group participation message including driving intention/mission information and group status information such as expected waiting/exit time to a rear-entry terminal, which is a terminal entering from the rear of the formed group, to inform that the queue has occurred due to terminals waiting for a left-turn signal. The rear-entry terminal may join the group if it has a left-turn driving intention/mission. In this case, the rear-entry terminal may increase the transmission cycle of a message including individual recognition information or stop transmitting the message before leaving the group, and may periodically receive group status information for each group from the V2X infrastructure or the leader terminal of the group. Here, the group status information provided from the V2X infrastructure or the leader terminal of the group may include the number of vehicles belonging to the group, the order of the current subject terminal, the expected waiting/exit time by order, etc. Or, in the case of having an intention/mission to drive straight or turn right, group participation may be rejected (for example, a message rejecting group participation may be transmitted to the V2X infrastructure/terminal) and driving may be performed to avoid the waiting line. In this case, a rear-entry terminal that does not have a left-turn purpose may prevent unnecessary waiting time due to the waiting line by driving outside the lane where the waiting line has occurred. In particular, as illustrated in FIG. 19, in the case where a separate left-turn lane is added, it is difficult for a rear-entry vehicle to identify the cause of the waiting line, and thus the group status information may effectively identify the cause of the waiting line. In addition, a rear-entry terminal with an intention to turn left may also effectively determine whether to detour by a route other than a left turn based on the expected waiting time included in the group participation message. For example, the rear entry terminal may search for a detour route with a shorter time than the expected waiting time based on the group participation message, and if a shorter detour route is identified, may perform driving to avoid the waiting queue in order to drive along the detour route.

When a terminal within the group terminates group standby (e.g., when the driving intention/mission is completed), the terminal may transmit a group exit message to the group, retransmit a message including individual recognition information, or change the transmission cycle to a basic transmission cycle. Here, terminating group standby may be when the terminal leaves the standby queue due to a change in the existing driving intention/mission, such as for a lane change, or leaves the standby queue due to the completion of the existing driving intention/mission.

In addition, referring to FIG. 20, the proposed method can support the decision-making of rear-entry vehicles by providing information on the waiting queue in front of the ramp on the highway connection, and can reduce the amount of messages transmitted for unnecessary individual recognition of terminals belonging to the group, thereby increasing the efficiency of the communication channel related to the waiting queue. In addition, in a signal control situation, if the remaining green light time is simply displayed, it may be difficult for the terminal or the user of the terminal to determine whether he or she can communicate at an intersection, etc. within the green light section due to various factors such as the delay of the waiting queue. In this case, the terminal or the vehicle including the terminal may be in a situation where it must rapidly accelerate or rapidly decelerate. In contrast, the proposed invention can manage the group by matching the signal current time with the situation of the group and designating whether the group passes. In this case, rapid acceleration/sudden deceleration of terminals/vehicles within the group can be prevented, and the likelihood of occurrence of violations of laws such as tailgating/violating the stop line can be greatly reduced.

Figure 21 is a drawing for explaining how a terminal performs operations related to maneuver coordination.

Referring to FIG. 21, the terminal may periodically transmit a recognition message including its own status information (mobility information such as moving speed, location, and direction of travel) (S211). Here, the recognition message may be the above-described CAM, BSM, PSM, VAM, MCM, and MSCM, and the terminal may be a terminal equipped in a mobile device (vehicle, motorcycle, bicycle) that drives along a predetermined driving path, or a terminal related to a pedestrian. Meanwhile, the recognition message may further include information on the driving intention/driving mission of the terminal (e.g., temporary driving purpose such as left turn, lane merge, etc.).

Next, the terminal may receive a message (or a group participation request message) including group status information for a temporary group from the first device (S213). For example, the terminal may receive a message including group status information from the first device when entering a specific area (e.g., an intersection, a lane merging section, etc.) and there is a waiting line for the lane in which the terminal is driving in the specific area. Here, the message may be an MCM or MSCM requesting participation in a temporary group for maneuver coordination, and the first device may be a leader of the temporary group, a network providing V2X service, or an RSU. Alternatively, the message may include the group status information in an extension field of the MCM or MSCM. Alternatively, the message may be a BSM, a CAM, a PSM, or a VAM in which a new field including information on driving intention/driving mission is additionally defined.

In addition, the message may include at least one of driving intention information related to the driving intention/driving mission for the temporary group as described above, lane information in which the temporary group is located, and information about an expected waiting time related to the driving intention/driving mission. The temporary group may be formed regardless of the final destination between terminals in the temporary group as a group that is temporarily maintained only until the driving intention/driving mission is completed (e.g., only until a left turn or a lane merge is completed). Alternatively, the message may further include configuration information for transmission parameters related to the transmission of the recognition message. For example, the message may further include configuration information for adjusting a transmission period of the recognition message or stopping transmission of the recognition message. In addition, the message may further include instruction information for instructing departure from a specific area (e.g., a specific lane) in which the temporary group is located when participation in the temporary group is rejected.

Next, the terminal may determine whether to participate in the temporary group for the maneuver coordination based on the message (S215). For example, the terminal may determine to participate in the temporary group if its driving intention/mission and the driving intention/mission of the temporary group are the same/corresponding, and may transmit an approval message for participation in the temporary group to the first device. In this case, the terminal may stop transmitting the recognition message or increase the transmission cycle of the recognition message based on the configuration information included in the message. Alternatively, the terminal may request the first device to specify a position in which it will intervene among the terminals in the temporary group if the lane in which it is located and the lane in which the temporary group is located are different.

In contrast, the terminal may determine not to participate in the temporary group if its driving intention/mission is different from that of the temporary group, and may transmit a rejection message for participation in the temporary group to the first device. In this case, the terminal may perform an operation to depart from the current driving/positioning lane based on the message. For example, the message may additionally include instruction information to depart from the lane associated with the temporary group if the driving intention/mission of the terminal and the driving intention/mission of the group do not match each other. In this case, when transmitting the rejection message, the terminal may perform an operation to depart from the lane in which the temporary group is positioned (a lane change operation) according to the instruction information.

Alternatively, the terminal may additionally consider the expected waiting time included in the message to determine whether to participate in the temporary group. For example, the driving intention of the terminal and the driving intention of the group may be identical/corresponding. At this time, the terminal may calculate/search for an alternative route/transit route that takes a shorter time than the driving route according to the driving intention based on the expected waiting time of the group. If an alternative route/transit route that takes a shorter time than the expected waiting time is searched, the terminal may transmit a message rejecting participation in the temporary group to the first device. In this case, the terminal may perform an operation of departing from the lane in which the temporary group is located according to the alternative route/transit route. Alternatively, the terminal may further include information on the alternative route/transit route in the rejection message. In this case, the first device may transmit a message further including the alternative route/transit route included in the rejection message to the next rear approach terminal. Through this, effective distributed driving of the rear approach terminals can be supported.

Alternatively, when the terminal transmits the approval message, the terminal may receive group status sharing information including information about the number of terminals included in the temporary group, the waiting order of the terminals, and the expected waiting time according to the waiting order from the first device. Alternatively, after the terminal has joined the temporary group, it may drive in units of the temporary group according to the maneuver coordination instruction/request of the first device, and when the driving intention of the temporary group is achieved, it may transmit a group departure message for leaving the temporary group to the first device. At this time, the group departure message may further include time information from the time when the terminal joined the temporary group to the time when it leaves the temporary group. In this case, the first device may correct the expected waiting time to be included in the message based on the time information.

Figure 22 is a diagram illustrating how a network performs operations related to maneuver coordination.

Referring to Fig. 22, the network can periodically receive a recognition message including status information of the terminal (mobility information such as moving speed, location, and direction of travel) from the terminal (S221). The recognition message may further include information about the driving intention/driving mission of the terminal (e.g., temporary driving purpose such as left turn, lane merging, etc.).

Next, the network can transmit a group participation request message including group status information for the temporary group (S223). For example, if a terminal entering the rear of a pre-formed temporary group is detected based on the recognition message, the network can transmit the group participation request message to the terminal, which requests the existence of a waiting line for a specific lane, the cause of the waiting line, and participation in a temporary group related to the waiting line. Here, the message can be an MCM or MSCM requesting participation in a temporary group for maneuver coordination, and can include the group status information in an extension field of the MCM or MSCM.

Alternatively, the network may determine whether to form a temporary group for maneuver coordination based on the received recognition messages, surrounding road environment, etc. For example, if the number of terminals driving in a specific lane at a speed below a specific threshold is greater than or equal to a specific threshold based on the recognition messages and surrounding road environment, the network may determine to form a temporary group composed of terminals greater than or equal to the specific threshold number, and transmit a group participation request message requesting participation in the temporary group for maneuver coordination to the terminals greater than or equal to the specific threshold number. Meanwhile, the network may estimate/predict the driving intention of the terminals based on the specific lane and road environment as described above, and may include information about the estimated/predicted driving intention in the group participation request message.

In addition, the group participation request message may further include, in addition to driving intention information related to the driving intention/driving mission for the temporary group as described above, information about the lane in which the temporary group is located and an expected waiting time related to the driving intention/driving mission. Here, the temporary group may be formed regardless of the final destination between terminals in the temporary group as a group that is temporarily maintained only until the driving intention/driving mission is completed (e.g., only until the left turn or lane merging is completed). Alternatively, the group participation request message may further include configuration information about transmission parameters related to the transmission of the recognition message. For example, the message may further include configuration information for adjusting a transmission period of the recognition message or stopping the transmission of the recognition message.

Next, the network can receive a response message from the terminal regarding whether to participate in the temporary group (S225). For example, the network can receive an approval message approving participation in the temporary group from a terminal whose driving intention/mission is the same as/corresponds to the driving intention/mission of the terminal and the driving intention/mission of the temporary group. In this case, the network can transmit configuration information instructing the terminal to stop transmitting the recognition message or increase the transmission period of the recognition message. Alternatively, as described above, the group participation request message may further include configuration information regarding transmission parameters of the recognition message applied when participating in the temporary group.

Alternatively, the network may receive a rejection message rejecting participation in the temporary group from a terminal whose driving intention/mission is different from that of the temporary group. In this case, the network may instruct/request the terminal to leave the lane corresponding to the temporary group. Alternatively, as described above, the group participation request message may further include instruction information instructing the terminal to change the driving lane in the case of rejecting participation in the temporary group.

Alternatively, the network may update the group status for the temporary group when receiving the approval message from the terminal, and transmit a message including group status sharing information for the updated group status to the terminals belonging to the temporary group. Here, the group status sharing information may receive group status sharing information including information about the number of terminals included in the temporary group, the waiting order of the terminals, and the expected waiting time according to the waiting order as described above. In addition, the network may determine the maneuver coordination between the plurality of groups, and instruct the driving method of each group according to the determined maneuver coordination. When the driving intention of the temporary group is achieved, the network may receive a group departure message for the departure of the temporary group from the terminals belonging to the temporary group. At this time, the group departure message may further include time information from the time when the terminal joins the temporary group to the time when it leaves the temporary group. In this case, the network may also correct the expected waiting time to be included in the group participation message based on the time information.

In this way, the proposed invention can additionally provide driving intention information of the temporary group to the surrounding terminals/approaching terminals, thereby effectively supporting the confirmation of the cause of formation of the temporary group by the surrounding terminals/approaching terminals and the decision-making on participation in the temporary group. Alternatively, the proposed invention can additionally provide information on the driving intention of the temporary group to the surrounding terminals/approaching terminals, thereby inducing terminals with different driving intentions to avoid driving with respect to the temporary group, thereby preventing unnecessary waiting time from occurring to the users of the terminals. Alternatively, the proposed invention can significantly improve the efficiency of the communication channel in the area where the waiting line is formed by reducing the transmission and reception of individual recognition messages of the terminals belonging to the temporary group. Alternatively, the proposed method can efficiently control the traffic flow in a congested road environment by supporting group-level maneuver coordination.

Examples of communication systems to which the invention applies

Although not limited thereto, the various descriptions, functions, procedures, proposals, methods and/or operational flowcharts of the present invention disclosed in this document may be applied to various fields requiring wireless communication/connectivity (e.g., 5G) between devices.

Hereinafter, more specific examples will be provided with reference to the drawings. In the drawings/descriptions below, the same drawing symbols may represent identical or corresponding hardware blocks, software blocks, or functional blocks, unless otherwise described.

Figure 23 illustrates a communication system applied to the present invention.

Referring to FIG. 23, a communication system (1) applied to the present invention includes a wireless device, a base station, and a network. Here, the wireless device means a device that performs communication using a wireless access technology (e.g., 5G NR (New RAT), LTE (Long Term Evolution)) and may be referred to as a communication/wireless/5G device. Although not limited thereto, the wireless device may include a robot (100a), a vehicle (100b-1, 100b-2), an XR (eXtended Reality) device (100c), a hand-held device (100d), a home appliance (100e), an IoT (Internet of Thing) device (100f), and an AI device/server (400). For example, the vehicle may include a vehicle equipped with a wireless communication function, an autonomous vehicle, a vehicle capable of performing vehicle-to-vehicle communication, etc. Here, the vehicle may include a UAV (Unmanned Aerial Vehicle) (e.g., a drone). XR devices include AR (Augmented Reality)/VR (Virtual Reality)/MR (Mixed Reality) devices and can be implemented in the form of HMD (Head-Mounted Device), HUD (Head-Up Display) installed in a vehicle, television, smartphone, computer, wearable device, home appliance, digital signage, vehicle, robot, etc. Portable devices can include smartphone, smart pad, wearable device (e.g., smart watch, smart glass), computer (e.g., laptop, etc.). Home appliances can include TV, refrigerator, washing machine, etc. IoT devices can include sensors, smart meters, etc. For example, base stations and networks can also be implemented as wireless devices, and a specific wireless device (200a) can act as a base station/network node to other wireless devices.

Wireless devices (100a to 100f) can be connected to a network (300) via a base station (200). Artificial Intelligence (AI) technology can be applied to the wireless devices (100a to 100f), and the wireless devices (100a to 100f) can be connected to an AI server (400) via the network (300). The network (300) can be configured using a 3G network, a 4G (e.g., LTE) network, a 5G (e.g., NR) network, etc. The wireless devices (100a to 100f) can communicate with each other via the base station (200)/network (300), but can also communicate directly (e.g., sidelink communication) without going through the base station/network. For example, vehicles (100b-1, 100b-2) can communicate directly (e.g. V2V (Vehicle to Vehicle)/V2X (Vehicle to everything) communication). Also, IoT devices (e.g., sensors) can communicate directly with other IoT devices (e.g., sensors) or other wireless devices (100a to 100f).

Wireless communication/connection (150a, 150b, 150c) can be established between wireless devices (100a to 100f)/base stations (200), and base stations (200)/base stations (200). Here, the wireless communication/connection can be achieved through various wireless access technologies (e.g., 5G NR) such as uplink/downlink communication (150a), sidelink communication (150b) (or, D2D communication), and communication between base stations (150c) (e.g., relay, IAB (Integrated Access Backhaul). Through the wireless communication/connection (150a, 150b, 150c), a wireless device and a base station/wireless device, and a base station and a base station can transmit/receive wireless signals to/from each other. For example, the wireless communication/connection (150a, 150b, 150c) can transmit/receive signals through various physical channels. To this end, at least some of various configuration information setting processes for transmitting/receiving wireless signals, various signal processing processes (e.g., channel encoding/decoding, modulation/demodulation, resource mapping/demapping, etc.), and resource allocation processes can be performed based on various proposals of the present invention.

Examples of wireless devices to which the present invention is applied

Figure 24 illustrates a wireless device that can be applied to the present invention.

Referring to FIG. 24, the first wireless device (100) and the second wireless device (200) can transmit and receive wireless signals through various wireless access technologies (e.g., LTE, NR). Here, {the first wireless device (100), the second wireless device (200)} can correspond to {the wireless device (100x), the base station (200)} and/or {the wireless device (100x), the wireless device (100x)} of FIG. 23.

A first wireless device (100) includes one or more processors (102) and one or more memories (104), and may additionally include one or more transceivers (106) and/or one or more antennas (108). The processor (102) controls the memory (104) and/or the transceiver (106), and may be configured to implement the descriptions, functions, procedures, suggestions, methods, and/or operational flowcharts disclosed in this document. For example, the processor (102) may process information in the memory (104) to generate first information/signal, and then transmit a wireless signal including the first information/signal via the transceiver (106). Additionally, the processor (102) may receive a wireless signal including second information/signal via the transceiver (106), and then store information obtained from signal processing of the second information/signal in the memory (104). The memory (104) may be connected to the processor (102) and may store various information related to the operation of the processor (102). For example, the memory (104) may perform some or all of the processes controlled by the processor (102), or may store software codes including instructions for performing the descriptions, functions, procedures, proposals, methods, and/or operational flowcharts disclosed in this document. Here, the processor (102) and the memory (104) may be part of a communication modem/circuit/chipset designed to implement wireless communication technology (e.g., LTE, NR). The transceiver (106) may be connected to the processor (102) and may transmit and/or receive wireless signals via one or more antennas (108). The transceiver (106) may include a transmitter and/or a receiver. The transceiver (106) may be used interchangeably with an RF (Radio Frequency) unit. In the present invention, a wireless device may also mean a communication modem/circuit/chipset.

Specifically, the first wireless device or terminal (100) may include a processor (102) and a memory (104) connected to a transceiver (106). The memory (104) may include at least one program capable of performing operations related to the embodiments described in FIGS. 13 to 22.

The processor (102) controls the transceiver (106) to periodically transmit a recognition message including status information for the terminal, receive a message including group status information for a temporary group from the first device, and determine whether to participate in the temporary group for the maneuver coordination based on the group status information of the message. Here, the group status information may include driving intention information related to the temporary group.

Alternatively, a processing device controlling the terminal (100) may be configured. The processing device may include at least one processor and at least one memory connected to the at least one processor and storing instructions, wherein the instructions, based on being executed by the at least one processor, may cause the terminal to: periodically transmit a recognition message including status information about the terminal, receive a message including group status information about a temporary group from a first device, and determine whether to participate in the temporary group for the maneuver coordination based on the group status information of the message. Here, the group status information may include driving intention information related to the temporary group.

The second wireless device (200) includes one or more processors (202), one or more memories (204), and may additionally include one or more transceivers (206) and/or one or more antennas (208). The processor (202) may be configured to control the memories (204) and/or the transceivers (206), and implement the descriptions, functions, procedures, suggestions, methods, and/or operational flowcharts disclosed in this document. For example, the processor (202) may process information in the memory (204) to generate third information/signals, and then transmit a wireless signal including the third information/signals via the transceivers (206). Additionally, the processor (202) may receive a wireless signal including fourth information/signals via the transceivers (206), and then store information obtained from signal processing of the fourth information/signals in the memory (204). The memory (204) may be connected to the processor (202) and may store various information related to the operation of the processor (202). For example, the memory (204) may perform some or all of the processes controlled by the processor (202), or may store software codes including commands for performing the descriptions, functions, procedures, proposals, methods, and/or operational flowcharts disclosed in this document. Here, the processor (202) and the memory (204) may be part of a communication modem/circuit/chip designed to implement wireless communication technology (e.g., LTE, NR). The transceiver (206) may be connected to the processor (202) and may transmit and/or receive wireless signals via one or more antennas (208). The transceiver (206) may include a transmitter and/or a receiver. The transceiver (206) may be used interchangeably with an RF unit. In the present invention, a wireless device may also mean a communication modem/circuit/chip.

Specifically, the second wireless device or network/server (200) may include a processor (202) and a memory (204) coupled to a transceiver (206). The memory (204) may include at least one program capable of performing operations related to the embodiments described in FIGS. 13 to 22.

The processor (202) can control the transceiver (206) to receive a recognition message including status information from a terminal, transmit a message including group status information for a temporary group to the terminal, and receive a response message from the terminal regarding whether the temporary group participates in the maneuver coordination. Here, the group status information can include driving intention information related to the temporary group.

Hereinafter, hardware elements of the wireless device (100, 200) will be described in more detail. Although not limited thereto, one or more protocol layers may be implemented by one or more processors (102, 202). For example, one or more processors (102, 202) may implement one or more layers (e.g., functional layers such as PHY, MAC, RLC, PDCP, RRC, SDAP). One or more processors (102, 202) may generate one or more Protocol Data Units (PDUs) and/or one or more Service Data Units (SDUs) according to the descriptions, functions, procedures, proposals, methods, and/or operational flowcharts disclosed in this document. One or more processors (102, 202) may generate messages, control information, data, or information according to the descriptions, functions, procedures, proposals, methods, and/or operational flowcharts disclosed in this document. One or more processors (102, 202) can generate signals (e.g., baseband signals) comprising PDUs, SDUs, messages, control information, data or information according to the functions, procedures, suggestions and/or methodologies disclosed herein and provide the signals to one or more transceivers (106, 206). One or more processors (102, 202) can receive signals (e.g., baseband signals) from one or more transceivers (106, 206) and obtain PDUs, SDUs, messages, control information, data or information according to the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed herein.

The one or more processors (102, 202) may be referred to as a controller, a microcontroller, a microprocessor, or a microcomputer. The one or more processors (102, 202) may be implemented by hardware, firmware, software, or a combination thereof. For example, one or more Application Specific Integrated Circuits (ASICs), one or more Digital Signal Processors (DSPs), one or more Digital Signal Processing Devices (DSPDs), one or more Programmable Logic Devices (PLDs), or one or more Field Programmable Gate Arrays (FPGAs) may be included in the one or more processors (102, 202). The descriptions, functions, procedures, suggestions, methods, and/or operational flowcharts disclosed in this document may be implemented using firmware or software, and the firmware or software may be implemented to include modules, procedures, functions, etc. The descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed in this document may be implemented using firmware or software configured to perform one or more of the following: included in one or more processors (102, 202), or stored in one or more memories (104, 204) and driven by one or more of the processors (102, 202). The descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed in this document may be implemented using firmware or software in the form of codes, instructions and/or sets of instructions.

One or more memories (104, 204) may be coupled to one or more processors (102, 202) and may store various forms of data, signals, messages, information, programs, codes, instructions and/or commands. The one or more memories (104, 204) may be comprised of ROM, RAM, EPROM, flash memory, hard drives, registers, cache memory, computer readable storage media and/or combinations thereof. The one or more memories (104, 204) may be located internally and/or externally to the one or more processors (102, 202). Additionally, the one or more memories (104, 204) may be coupled to the one or more processors (102, 202) via various technologies, such as wired or wireless connections.

One or more transceivers (106, 206) can transmit user data, control information, wireless signals/channels, etc., as described in the methods and/or flowcharts of this document, to one or more other devices. One or more transceivers (106, 206) can receive user data, control information, wireless signals/channels, etc., as described in the descriptions, functions, procedures, suggestions, methods and/or flowcharts of this document, from one or more other devices. For example, one or more transceivers (106, 206) can be coupled to one or more processors (102, 202) and can transmit and receive wireless signals. For example, one or more processors (102, 202) can control one or more transceivers (106, 206) to transmit user data, control information, or wireless signals to one or more other devices. Additionally, one or more processors (102, 202) may control one or more transceivers (106, 206) to receive user data, control information, or wireless signals from one or more other devices. Additionally, one or more transceivers (106, 206) may be coupled to one or more antennas (108, 208), and one or more transceivers (106, 206) may be configured to transmit and receive user data, control information, wireless signals/channels, and the like, as described in the descriptions, functions, procedures, proposals, methods, and/or operational flowcharts disclosed herein, via one or more antennas (108, 208). In the present document, one or more antennas may be multiple physical antennas, or multiple logical antennas (e.g., antenna ports). One or more transceivers (106, 206) may convert received user data, control information, wireless signals/channels, etc. from RF band signals to baseband signals in order to process the received user data, control information, wireless signals/channels, etc. using one or more processors (102, 202). One or more transceivers (106, 206) may convert processed user data, control information, wireless signals/channels, etc. from baseband signals to RF band signals using one or more processors (102, 202). For this purpose, one or more transceivers (106, 206) may include an (analog) oscillator and/or filter.

Examples of wireless devices to which the present invention is applied

Fig. 25 shows another example of a wireless device applied to the present invention. The wireless device can be implemented in various forms depending on the use-example/service (see Fig. 23).

Referring to FIG. 25, the wireless device (100, 200) corresponds to the wireless device (100, 200) of FIG. 24 and may be composed of various elements, components, units/units, and/or modules. For example, the wireless device (100, 200) may include a communication unit (110), a control unit (120), a memory unit (130), and an additional element (140). The communication unit may include a communication circuit (112) and a transceiver(s) (114). For example, the communication circuit (112) may include one or more processors (102, 202) and/or one or more memories (104, 204) of FIG. 25. For example, the transceiver(s) (114) may include one or more transceivers (106, 206) and/or one or more antennas (108, 208) of FIG. 24. The control unit (120) is electrically connected to the communication unit (110), the memory unit (130), and the additional elements (140) and controls overall operations of the wireless device. For example, the control unit (120) may control electrical/mechanical operations of the wireless device based on programs/codes/commands/information stored in the memory unit (130). In addition, the control unit (120) may transmit information stored in the memory unit (130) to an external device (e.g., another communication device) via a wireless/wired interface through the communication unit (110), or store information received from an external device (e.g., another communication device) via a wireless/wired interface in the memory unit (130).

The additional element (140) may be configured in various ways depending on the type of the wireless device. For example, the additional element (140) may include at least one of a power unit/battery, an input/output unit (I/O unit), a driving unit, and a computing unit. Although not limited thereto, the wireless device may be implemented in the form of a robot (FIG. 23, 100a), a vehicle (FIG. 23, 100b-1, 100b-2), an XR device (FIG. 23, 100c), a portable device (FIG. 23, 100d), a home appliance (FIG. 23, 100e), an IoT device (FIG. 23, 100f), a digital broadcasting terminal, a hologram device, a public safety device, an MTC device, a medical device, a fintech device (or a financial device), a security device, a climate/environmental device, an AI server/device (FIG. 23, 400), a base station (FIG. 23, 200), a network node, etc. Wireless devices may be mobile or stationary, depending on the use/service.

In FIG. 25, various elements, components, units/parts, and/or modules within the wireless device (100, 200) may be entirely interconnected via a wired interface, or at least some may be wirelessly connected via a communication unit (110). For example, within the wireless device (100, 200), the control unit (120) and the communication unit (110) may be wired, and the control unit (120) and the first unit (e.g., 130, 140) may be wirelessly connected via the communication unit (110). In addition, each element, component, unit/part, and/or module within the wireless device (100, 200) may further include one or more elements. For example, the control unit (120) may be composed of one or more processor sets. For example, the control unit (120) may be composed of a set of a communication control processor, an application processor, an electronic control unit (ECU), a graphic processing processor, a memory control processor, etc. As another example, the memory unit (130) may be composed of RAM (Random Access Memory), DRAM (Dynamic RAM), ROM (Read Only Memory), flash memory, volatile memory, non-volatile memory, and/or a combination thereof.

Examples of vehicles or autonomous vehicles to which the present invention is applied

Fig. 26 illustrates a vehicle or autonomous vehicle applied to the present invention. The vehicle or autonomous vehicle may be implemented as a mobile robot, a car, a train, a manned/unmanned aerial vehicle (AV), a ship, etc.

Referring to FIG. 26, a vehicle or autonomous vehicle (100) may include an antenna unit (108), a communication unit (110), a control unit (120), a driving unit (140a), a power supply unit (140b), a sensor unit (140c), and an autonomous driving unit (140d). The antenna unit (108) may be configured as a part of the communication unit (110). Blocks 110/130/140a to 140d correspond to blocks 110/130/140 of FIG. 25, respectively.

The communication unit (110) can transmit and receive signals (e.g., data, control signals, etc.) with external devices such as other vehicles, base stations (e.g., base stations, road side units, etc.), servers, etc. The control unit (120) can control elements of the vehicle or autonomous vehicle (100) to perform various operations. The control unit (120) can include an ECU (Electronic Control Unit). The drive unit (140a) can drive the vehicle or autonomous vehicle (100) on the ground. The drive unit (140a) can include an engine, a motor, a power train, wheels, brakes, a steering device, etc. The power supply unit (140b) supplies power to the vehicle or autonomous vehicle (100) and can include a wired/wireless charging circuit, a battery, etc. The sensor unit (140c) can obtain vehicle status, surrounding environment information, user information, etc. The sensor unit (140c) may include an IMU (inertial measurement unit) sensor, a collision sensor, a wheel sensor, a speed sensor, an incline sensor, a weight detection sensor, a heading sensor, a position module, a vehicle forward/backward sensor, a battery sensor, a fuel sensor, a tire sensor, a steering sensor, a temperature sensor, a humidity sensor, an ultrasonic sensor, a light sensor, a pedal position sensor, etc. The autonomous driving unit (140d) may implement a technology for maintaining a driving lane, a technology for automatically controlling speed such as adaptive cruise control, a technology for automatically driving along a set path, a technology for automatically setting a path and driving when a destination is set, etc.

For example, the communication unit (110) can receive map data, traffic information data, etc. from an external server. The autonomous driving unit (140d) can generate an autonomous driving route and a driving plan based on the acquired data. The control unit (120) can control the driving unit (140a) so that the vehicle or autonomous vehicle (100) moves along the autonomous driving route according to the driving plan (e.g., speed/direction control). During autonomous driving, the communication unit (110) can irregularly/periodically acquire the latest traffic information data from an external server and can acquire surrounding traffic information data from surrounding vehicles. In addition, the sensor unit (140c) can acquire vehicle status and surrounding environment information during autonomous driving. The autonomous driving unit (140d) can update the autonomous driving route and driving plan based on the newly acquired data/information. The communication unit (110) can transmit information on the vehicle location, autonomous driving route, driving plan, etc. to an external server. External servers can predict traffic information data in advance using AI technology, etc. based on information collected from vehicles or autonomous vehicles, and provide the predicted traffic information data to vehicles or autonomous vehicles.

Here, the wireless communication technology implemented in the wireless device (XXX, YYY) of the present specification may include LTE, NR, and 6G, as well as Narrowband Internet of Things for low-power communication. At this time, for example, NB-IoT technology may be an example of LPWAN (Low Power Wide Area Network) technology, and may be implemented with standards such as LTE Cat NB1 and/or LTE Cat NB2, and is not limited to the above-described names. Additionally or alternatively, the wireless communication technology implemented in the wireless device (XXX, YYY) of the present specification may perform communication based on LTE-M technology. At this time, for example, LTE-M technology may be an example of LPWAN technology, and may be called by various names such as eMTC (enhanced Machine Type Communication). For example, the LTE-M technology can be implemented by at least one of various standards such as 1) LTE CAT 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-BL (non-Bandwidth Limited), 5) LTE-MTC, 6) LTE Machine Type Communication, and/or 7) LTE M, and is not limited to the above-described names. Additionally or alternatively, the wireless communication technology implemented in the wireless device (XXX, YYY) of the present specification can include at least one of ZigBee, Bluetooth, and Low Power Wide Area Network (LPWAN) considering low-power communication, and is not limited to the above-described names. For example, the ZigBee technology can create PAN (personal area networks) related to small/low-power digital communication based on various standards such as IEEE 802.15.4, and can be called by various names.

The embodiments described above are combinations of components and features of the present invention in a predetermined form. Each component or feature should be considered optional unless explicitly stated otherwise. Each component or feature may be implemented in a form that is not combined with other components or features. In addition, it is also possible to form an embodiment of the present invention by combining some components and/or features. The order of operations described in the embodiments of the present invention may be changed. Some components or features of one embodiment may be included in another embodiment, or may be replaced with corresponding components or features of another embodiment. It is obvious that claims that do not have an explicit citation relationship in the scope of the patent may be combined to form an embodiment or included as a new claim by post-application amendment.

In this document, the embodiments of the present invention have been mainly described with a focus on the signal transmission/reception relationship between a terminal and a base station. This transmission/reception relationship is equally/similarly extended to signal transmission/reception between a terminal and a relay or a base station and a relay. A specific operation described as being performed by a base station in this document may, in some cases, be performed by its upper node. That is, it is obvious that various operations performed for communication with a terminal in a network composed of a plurality of network nodes including a base station may be performed by the base station or other network nodes other than the base station. The base station may be replaced with terms such as a fixed station, a Node B, an eNode B (eNB), an access point, etc. In addition, the terminal may be replaced with terms such as a UE (User Equipment), an MS (Mobile Station), an MSS (Mobile Subscriber Station), etc.

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

In the case of implementation by firmware or software, one embodiment of the present invention may be implemented in the form of a module, procedure, function, etc. that performs the functions or operations described above. The software code may be stored in a memory unit and may be driven by a processor. The memory unit may be located inside or outside the processor and may exchange data with the processor by various means already known.

It will be apparent to those skilled in the art that the present invention can be embodied in other specific forms without departing from the scope of the present invention. Therefore, the above detailed description should not be construed as limiting in all aspects, but should be considered as illustrative. The scope of the present invention should be determined by a reasonable interpretation of the appended claims, and all changes within the equivalent scope of the present invention are included in the scope of the present invention.

The embodiments of the present invention as described above can be applied to various mobile communication systems.

Claims (15)

A method for a terminal to perform an operation related to maneuver coordination in a wireless communication system, A step of periodically transmitting a recognition message including status information for the terminal; A step of receiving a message containing group status information for a temporary group from a first device; and A step of determining whether to participate in the temporary group for the maneuver coordination based on the group status information of the message, A method wherein the group status information includes driving intention information related to the temporary group. In the first paragraph, A method characterized in that, based on the correspondence between the driving intention information and the driving intention of the terminal, the first terminal transmits an approval message approving participation in the temporary group to the first device. In the second paragraph, A method, characterized in that based on the transmission of the above-mentioned approval message, the transmission of the above-mentioned recognition message is stopped or the transmission cycle is increased based on the above-mentioned message. In the second paragraph, A method, characterized in that it further comprises the step of receiving, from the first device, group status sharing information including information on the number of terminals included in the temporary group, the waiting order of the terminals, and the expected waiting time according to the waiting order, based on the transmission of the above approval message. In the first paragraph, A method characterized in that the terminal determines whether to participate in the temporary group by considering both the expected waiting time and the driving intention information, based on the group status information further including information on the expected waiting time for the driving intention of the temporary group to be achieved. In paragraph 5, A method characterized in that, based on the search for a detour shorter than the expected waiting time, the terminal transmits a rejection message to the first device rejecting participation in the temporary group even if the driving intention of the terminal and the driving intention information correspond. In paragraph 1, A method characterized in that, based on the driving intention information and the driving intention of the terminal not corresponding, the terminal changes the route to leave the area where the temporary group is located. In the first paragraph, The above messages are MCM (Maneuver Coordination Messages) or MSCM (Maneuver Sharing and Coordination Messages). A method, characterized in that the group status information is included in an extension field of the MCM or MSCM. In the first paragraph, A method, characterized in that the first device is a network supporting V2X (Vehicle to Everything) communication or a leader terminal of the temporary group. A computer-readable recording medium having recorded thereon a program for performing the method described in claim 1. In a terminal performing an operation related to maneuver coordination in a wireless communication system, RF(Radio Frequency) transceiver; and comprising a processor connected to the RF transceiver; The processor controls the RF transceiver to periodically transmit an identification message including status information for the terminal, receives a message including group status information for a temporary group from the first device, and determines whether to participate in the temporary group for the maneuver coordination based on the group status information of the message. The terminal, wherein the group status information includes driving intention information related to the temporary group. In a processing device for controlling a terminal performing an operation related to maneuver coordination in a wireless communication system, at least one processor; and At least one memory coupled to said at least one processor and storing instructions, said instructions being executed by said at least one processor, wherein said terminal causes: Periodically transmitting a recognition message including status information for the terminal, receiving a message including group status information for a temporary group from the first device, and determining whether to participate in the temporary group for the maneuver coordination based on the group status information of the message; A processing device, wherein the group status information includes driving intention information related to the temporary group. A method for a network to perform operations related to maneuver coordination in a wireless communication system, A step of receiving a recognition message including status information from a terminal; A step of transmitting a message including group status information about a temporary group to the terminal; and A step of receiving a response message from the terminal regarding whether to participate in the temporary group for the maneuver coordination, A method wherein the group status information includes driving intention information related to the temporary group. In Article 13, A method characterized in that the network transmits to the terminals the message including driving intention information predicted for the terminals based on the number of terminals below a specific threshold speed in a specific area being greater than or equal to a specific threshold number. In a network that performs operations related to maneuver coordination in a wireless communication system, RF(Radio Frequency) transceiver; and comprising a processor connected to the RF transceiver; The processor controls the RF transceiver to receive a recognition message including status information from a terminal, transmit a message including group status information for a temporary group to the terminal, and receive a response message from the terminal regarding whether to participate in the temporary group for the maneuver coordination. A network wherein the group state information includes driving intention information related to the temporary group.

Images