Method and apparatus for transmitting message in wireless communication system

Abstract

A first apparatus for transmitting a message in a wireless communication system, according to various embodiments, may: receive, from first user equipment, a first vehicle-to-everything (V2X) message including apparatus information for a second apparatus; on the basis of a V2X message for the second apparatus not being received from the first user equipment within a specific period of time after the first V2X message is received, determine that the second apparatus is in a first state; on the basis of the second apparatus being in the first state, generate, by using the apparatus information, object information including a first state area and first state information related to the second apparatus; and transmit, to a third apparatus, an object message including the object information.

Description

Method for transmitting a message in a wireless communication system and device therefor

[0001] A method for transmitting a message to an autonomous delivery robot and a mobility device in a wireless communication system and a device therefor are provided.

[0002] Wireless communication systems are multiple access systems that support communication with multiple users by sharing available system resources (e.g., bandwidth, transmission power, etc.). Examples of multiple access systems include code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), single carrier frequency division multiple access (SC-FDMA), and multi-carrier frequency division multiple access (MC-FDMA).

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

[0004] V2X (vehicle-to-everything) refers to a communication technology that exchanges information with other vehicles, pedestrians, and infrastructure-based objects 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 Uu interface.

[0005] Meanwhile, as more and more communication devices demand greater communication capacity, the need for improved mobile broadband communication compared to existing radio access technology (RAT) is emerging. Accordingly, communication systems that consider services or terminals sensitive to reliability and latency are being discussed. Next-generation wireless access technologies that consider improved mobile broadband communication, massive machine type communication (MTC), and ultra-reliable and low latency communication (URLLC) can be called new radio access technology (RAT) or new radio (NR). NR can also support vehicle-to-everything (V2X) communication.

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

[0007] 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) were 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.

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

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

[0010] For example, based on vehicle platooning, vehicles can dynamically form groups and move together. For example, to perform platoon operations based on vehicle platooning, vehicles in the group can receive periodic data from the lead vehicle. For example, vehicles in the group can use this periodic data to narrow or widen the gap between vehicles.

[0011] For example, based on improved driving, vehicles can become 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. Furthermore, for example, each vehicle can share driving intentions with nearby vehicles.

[0012] For example, based on extended sensors, raw data, 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, a vehicle can perceive its environment better than it can perceive using its own sensors.

[0013] For example, based on remote driving, a remote driver or V2X application can operate or control the remote vehicle for people who cannot drive or for remote vehicles located in hazardous environments. For example, in cases where the route is predictable, such as public transportation, cloud computing-based driving can be utilized to operate or control the remote vehicle. Additionally, access to a cloud-based back-end service platform, for example, can be considered for remote driving.

[0014] 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 communication.

[0015] The technical problem to be solved by the present invention is to provide a method for transmitting and receiving messages that can provide a more accurate and efficient safety service.

[0016] 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 pertains from the description below.

[0017] A method for transmitting a message by a first device in a wireless communication system according to one aspect comprises the steps of: receiving a first V2X (Vehicle-to-Everything) message including device information for a second device from a first terminal; generating object information including a first state area and first state information related to the second device using the device information based on the second device being in a first state; and transmitting an object message including the object information to a third device; wherein the first device can determine that the second device is in the first state based on the first terminal not receiving a V2X message for the second device within a specific time after receiving the first V2X message.

[0018] Alternatively, the object information is characterized in that it includes information on a reference position value, length and width for specifying the first state area, or includes two position values ​​for specifying the first state area.

[0019] Alternatively, the method further comprises: a step of receiving PSM (Personal Safety Message) or VRU messages including information on a movement path of a Vulnerable Road User (VRU) from second terminals located around the second device; and a step of correcting the object information for the second device based on the VRU movement path.

[0020] Alternatively, the object information further includes gap information and gap rank information related to the second device in the first state, wherein the gap information includes information about a gap between the second device and another device, and the gap rank information includes a rank value counted based on the number of VRU movement paths passing through the gap.

[0021] Alternatively, the method further comprises a step of grouping the second device and at least one device adjacent to the second device into one group based on the location of the second device.

[0022] Alternatively, based on the formation of said one group for said second device, the first state area associated with said second device is characterized as being an area including both said second device and said at least one device included in said one group.

[0023] Alternatively, the first device is characterized in that, based on a V2X message for the second device in the first state received from the first terminal, the first device determines the state of the second device as the second state and stops generating the object information for the second device.

[0024] Alternatively, the first state is characterized as being a parking state.

[0025] According to another aspect, a non-transitory computer-readable storage medium having recorded thereon instructions for performing the method of transmitting the message described above may be provided.

[0026] According to another aspect, a device may be provided that performs the method of transmitting the message described above.

[0027] According to another aspect, a processing device may be provided for controlling a device that performs the method of transmitting the message described above.

[0028] According to another aspect, a method for a mobility device to receive a message in a wireless communication system includes the steps of: transmitting a V2X (Vehicle-to-Everything) message including device information about the mobility device to a first device; receiving an object message including object information about a second device from the first device; and controlling driving based on the object information; wherein the object information may include a first state area, first state information, gap information, and gap rank information related to the second device based on the second device being in a first state.

[0029] According to one embodiment of the present invention, a message capable of providing a safety service in a wireless communication system can be transmitted and received more accurately and efficiently.

[0030] 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.

[0031] The drawings attached to this specification are intended to provide an understanding of the present invention, illustrate various embodiments of the present invention, and together with the description of the specification serve to explain the principles of the present invention.

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

[0033] Figure 2 shows the structure of the LTE system.

[0034] Figure 3 shows the structure of the NR system.

[0035] Figure 4 shows the structure of a radio frame of NR.

[0036] Figure 5 shows the slot structure of an NR frame.

[0037] Figure 6 shows a radio protocol architecture for SL communication.

[0038] Figure 7 shows a terminal performing V2X or SL communication.

[0039] Figure 8 shows resource units for V2X or SL communication.

[0040] Figure 9 is a drawing for explaining the ITS station reference architecture.

[0041] Figure 10 is an example structure of an ITS station that can be designed and applied based on a reference structure.

[0042] FIG. 11 and FIG. 12 are diagrams illustrating a method for a server to generate / transmit a message containing parking information for a mobility device.

[0043] Figure 13 is a block diagram briefly illustrating the configuration of a server and terminal included in a system providing mobility safety services.

[0044] Fig. 14 is a diagram for explaining the message structure of a V2X message that further includes parking status information.

[0045] FIG. 15 and FIG. 16 are diagrams for explaining how a terminal / mobility device configures an object field for notifying a parking status.

[0046] Figures 17 to 19 are drawings for explaining a method in which a server generates object information based on parking status information.

[0047] FIGS. 20 to 23 are diagrams for explaining a method in which the server transmits a parking message including object information about a mobility device in a parked state.

[0048] Figures 23 to 25 are drawings for explaining a method of exchanging messages between a server, a terminal, and an autonomous delivery robot.

[0049] FIG. 26 is a diagram for explaining a method for a server and a terminal to transmit and receive a parking message including object information or parking object information for a parked mobility device.

[0050] Figure 27 is a drawing illustrating how an autonomous delivery robot drives based on a parking message.

[0051] FIG. 28 is a diagram illustrating a method for transmitting an object message containing object information for a second device in which a first device is parked.

[0052] Figure 29 illustrates a communication system applied to the present invention.

[0053] Figure 30 illustrates a wireless device applicable to the present invention.

[0054] Figure 31 shows another example of a wireless device applied to the present invention.

[0055] Figure 32 illustrates a vehicle or autonomous vehicle to which the present invention is applied.

[0056] 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 code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), single carrier frequency division multiple access (SC-FDMA), and multi-carrier frequency division multiple access (MC-FDMA).

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

[0058] V2X (vehicle-to-everything) refers to a communication technology that exchanges information with other vehicles, pedestrians, and infrastructure-based objects 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 Uu interface.

[0059] Meanwhile, as more and more communication devices demand greater communication capacity, the need for improved mobile broadband communication compared to existing radio access technology (RAT) is emerging. Accordingly, communication systems that consider services or terminals sensitive to reliability and latency are being discussed. Next-generation wireless access technologies that consider improved mobile broadband communication, massive MTC, and URLLC (Ultra-Reliable and Low Latency Communication) can be called new radio access technology (RAT) or new radio (NR). NR can also support V2X (vehicle-to-everything) communication.

[0060] The following technologies 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, and 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.

[0061] 5G NR, the successor to LTE-A, is a new clean-slate mobile communications system featuring high performance, low latency, and high availability. 5G NR can utilize all available spectrum resources, from low-frequency bands below 1 GHz, mid-frequency bands between 1 GHz and 10 GHz, and high-frequency (millimeter wave) bands above 24 GHz.

[0062] For clarity, the description will focus on LTE-A or 5G NR, but the technical ideas of the embodiment(s) are not limited thereto.

[0063] Figure 2 illustrates the architecture of an applicable LTE system. This may be referred to as an Evolved-UMTS Terrestrial Radio Access Network (E-UTRAN) or a Long Term Evolution (LTE) / LTE-A system.

[0064] 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 referred to 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 referred to by other terms such as an evolved-NodeB (eNB), a base transceiver system (BTS), an access point, etc.

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

[0066] The EPC (30) consists of an MME, an S-GW, and a P-GW (Packet Data Network-Gateway). The MME holds information about terminal access and capabilities, and this information is primarily used for terminal mobility management. The S-GW is a gateway with the E-UTRAN as its endpoint, and the P-GW is a gateway with the PDN as its endpoint.

[0067] The layers of the radio interface protocol between the terminal and the network can be divided into L1 (Layer 1), L2 (Layer 2), and L3 (Layer 3) 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 Layer 1 provides an information transfer service using a physical channel, and the RRC (Radio Resource Control) layer located in Layer 3 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.

[0068] Figure 3 shows the structure of the NR system.

[0069] 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 eNB are connected to each other via an Xn interface. The gNB and eNB are connected to the 5th generation core network (5G Core Network: 5GC) via the NG interface. More specifically, the gNB is connected to the access and mobility management function (AMF) via the NG-C interface, and the gNB is connected to the user plane function (UPF) via the NG-U interface.

[0070] Figure 4 shows the structure of a radio frame of NR.

[0071] Referring to FIG. 4, radio frames can be used for 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 sub-frames (Subframes, SF). A sub-frame can be divided into one or more slots, and the number of slots within a sub-frame can be determined by the Subcarrier Spacing (SCS). Each slot can include 12 or 14 OFDM (A) symbols depending on the cyclic prefix (CP).

[0072] When normal CP is used, each slot can contain 14 symbols. When extended CP is used, each slot can contain 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).

[0073] Table 1 below shows the number of symbols per slot ((N)) depending on the SCS setting (u) when normal CP is used. slot symb ), number of slots per frame ((N frame,u slot ) and the number of slots per subframe ((N subframe,u slot ) is an example.

[0074] SCS (15*2 u )N slot symb N frame,u slot N subframe,u slot 15KHz (u=0)1410130KHz (u=1)1420260KHz (u=2)14404120KHz (u=3)14808240KHz (u=4)1416016

[0075] 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.

[0076] SCS (15*2 u )N slot symb N frame,u slot N subframe,u slot 60KHz (u=2)12404

[0077] In an NR system, OFDM(A) numerology (e.g., SCS, CP length, etc.) may be set differently between multiple cells that are merged into a single terminal. Accordingly, the (absolute time) interval 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.

[0078] In NR, multiple numerologies, or SCSs, can be supported to support various 5G services. For example, a 15 kHz SCS can support wide areas in traditional cellular bands, while a 30 kHz / 60 kHz SCS can support dense urban areas, lower latency, and wider carrier bandwidth. A 60 kHz or higher SCS can support bandwidths greater than 24.25 GHz to overcome phase noise.

[0079] 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 values ​​of the frequency ranges 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 the "sub 6 GHz range", and FR2 can mean the "above 6 GHz range" and can be called millimeter wave (mmW).

[0080] Frequency Range designationCorresponding frequency rangeSubcarrier Spacing (SCS)FR1450MHz - 6000MHz15, 30, 60kHzFR224250MHz - 52600MHz60, 120, 240kHz

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

[0082] Frequency Range designationCorresponding frequency rangeSubcarrier Spacing (SCS)FR1410MHz - 7125MHz15, 30, 60kHzFR224250MHz - 52600MHz60, 120, 240kHz

[0083] Figure 5 shows the slot structure of an NR frame.

[0084] Referring to Figure 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. Alternatively, 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.

[0085] 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 one complex symbol can be mapped to it.

[0086] 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 refer to a physical layer. Furthermore, for example, the L2 layer may refer to at least one of a MAC layer, an RLC layer, a PDCP layer, and an SDAP layer. Furthermore, for example, the L3 layer may refer to an RRC layer.

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

[0088] Figure 6 illustrates a radio protocol architecture for SL communication. Specifically, Figure 6 (a) illustrates the user plane protocol stack of NR, and Figure 6 (b) illustrates the control plane protocol stack of NR.

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

[0090] 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 and acquire synchronization using the S-PSS. For example, a terminal may acquire detailed synchronization and detect a synchronization signal ID using the S-PSS and the S-SSS.

[0091] PSBCH (Physical Sidelink Broadcast Channel) may be a (broadcast) channel that transmits basic (system) information that a terminal must know first before transmitting or receiving an SL signal. 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 NR V2X, for evaluating PSBCH performance, the payload size of PSBCH may be 56 bits, including a 24-bit CRC.

[0092] 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 the carrier, and the 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 the frequency to discover the S-SSB in the carrier.

[0093] 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.

[0094] 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.

[0095] 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.

[0096] Meanwhile, when the SCS is 60 kHz, two types of CP may 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 within 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 within the S-SSB transmitted by the transmitting terminal may be 7 or 6. For example, the PSBCH may be mapped to the first symbol within the S-SSB transmitted by the transmitting terminal. For example, the receiving terminal receiving the S-SSB may perform an Automatic Gain Control (AGC) operation in the first symbol section of the S-SSB.

[0097] Figure 7 shows a terminal performing V2X or SL communication.

[0098] Referring to FIG. 7, the term "terminal" in V2X or SL communication may primarily refer to a user's terminal. However, if a network device such as a base station transmits and receives signals 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).

[0099] For example, terminal 1 can select a resource unit corresponding to a specific resource within a resource pool, which represents a set 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 from terminal 1 within the resource pool.

[0100] 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.

[0101] 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.

[0102] Figure 8 shows resource units for V2X or SL communication.

[0103] Referring to Figure 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. Therefore, a total of NF * NT resource units can be defined within the resource pool. Figure 8 illustrates an example where the resource pool repeats with a cycle of NT subframes.

[0104] As illustrated in Figure 8, a single resource unit (e.g., Unit #0) may appear periodically and repeatedly. Alternatively, to achieve diversity effects in the time or frequency dimensions, the index of the physical resource unit to which a single logical resource unit is mapped may change over time in a predetermined pattern. In this resource unit structure, a resource pool may refer to a set of resource units that a terminal wishing to transmit an SL signal can use for transmission.

[0105] Resource pools can be subdivided into several categories. For example, based on the content of the SL signal transmitted from each resource pool, resource pools can be categorized as follows:

[0106] (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 refer to a resource pool in which SA is multiplexed with SL data and transmitted. SA may also be called an SL control channel.

[0107] (2) The 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 the SL data channel excluding SA information may be transmitted from the resource pool for the SL data channel. In other words, the REs (Resource Elements) that were 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, the transmitting terminal may transmit the PSSCH by mapping it to consecutive PRBs.

[0108] (3) A discovery channel may be a resource pool for transmitting terminals to transmit information such as their IDs. Through this, transmitting terminals can enable neighboring terminals to discover them.

[0109] Even if the content of the SL signal described above is the same, different resource pools may be used depending on the transmission and reception properties of the SL signal. For example, even if 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 for individual signals to individual transmitting terminals or whether individual transmitting terminals independently select individual signal transmission resources within the resource pool), the signal format (for example, the number of symbols 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.

[0110] Vehicular Communications for ITS

[0111] ITS (Intelligent Transport System) utilizing V2X (Vehicle-to-Everything) can be mainly composed of Access layer, Network & Transport layer, Facilities layer, Application layer, Security, and Management Entity. 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), and 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.

[0112] Figure 9 is a drawing for explaining the ITS station reference architecture.

[0113] 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.

[0114] Specifically, referring to FIG. 9, 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).

[0115] 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 is responsible for managing 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 a description of the abbreviations for the various interfaces.

[0116] MA: Interface between management entity and application layer

[0117] MF: Interface between management entity and facilities layer

[0118] MN: Interface between management entity and networking & transport layer

[0119] MI: Interface between management entity and access layer

[0120] FA: Interface between facilities layer and ITS-S applications

[0121] NF: Interface between networking & transport layer and facilities layer

[0122] IN: Interface between access layer and networking & transport layer

[0123] SA: Interface between security entity and ITS-S applications

[0124] SF: Interface between security entity and facilities layer

[0125] SN: Interface between security entity and networking & transport layer

[0126] SI: Interface between security entity and access layer

[0127] 도 10은 참조 구조에 기초하여 설계 및 적용 가능한 ITS 스테이션 (station)의 예시 구조이다.

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

[0129] ITS systems utilizing vehicle communication and networks are organically designed to support diverse use cases, taking into account various access technologies, network protocols, and communication interfaces. The roles and functions of each layer described below may change depending on the situation. The following briefly describes the key functions of each layer.

[0130] 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.

[0131] 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 / infrastructure through vehicle communication through the lower access layer, network & transport layer, and facilities layer. At this time, ITS applications can support various use cases, and generally, these use cases can be grouped and supported by 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 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).

[0132] 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.

[0133] The facilities layer basically supports the top three layers of the OSI model, i.e., the session layer, presentation layer, and 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.

[0134] Application support facilities (ASFs) support the operation of ITS applications (primarily generating ITS messages, transmitting and receiving messages with lower layers, and managing them). These ASFs include the Cooperative Awareness (CA) basic service and the Decentralized Environmental Notification (DEN) basic service. In the future, facility entities and related messages for new services, such as Cooperative Adaptive Cruise Control (CACC), Platooning, Vulnerable Roadside User (VRU), and Collective Perception Service (CPS), may be additionally defined.

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

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

[0137] Additionally, facilities can be divided into common facilities and domain facilities.

[0138] Common facilities are facilities that provide common services or functions required for the operation of various ITS applications and ITS stations, such as time management, position management, and services management.

[0139] Domain facilities are facilities that provide specialized services or functions required only by one or more ITS applications, such as the DEN basic service for Road Hazard Warning (RHW) applications. Domain facilities are optional and are not used unless supported by the ITS station.

[0140] 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 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 through NF (interface between networking & transport layer and facilities layer, or NF-SAP).

[0141] It plays a role in configuring a network for vehicle communication between homogenous 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 depending on the technology used in the access layer (access layer technology-dependent), or it can be designed or configured regardless of the technology used in the access layer (access layer technology-independent, access layer technology agnostic).

[0142] 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 those of the OSI Layer 3 (Network Layer) and Layer 4 (Transport Layer) and have the following characteristics.

[0143] 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). Its role is to manage the data sent by the application of the sending ITS station so that it accurately arrives at the application process of the destination ITS station. As shown in Figure OP5.1, 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.

[0144] The network layer determines the logical address and packet delivery method / route, and adds information such as the destination's logical address and delivery path / method to the network layer header of 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.

[0145] 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).

[0146] 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 exclusively for ITS.

[0147] The packet structure of a WSM (WAVE Short Message) generated according to WSMP consists of a 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.

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

[0149] 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.

[0150] The data link layer is a layer that converts a physical line between adjacent nodes (or between vehicles), which 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, a framing function that groups and divides data to be transmitted into packets (or frames) as transmission units, a flow control function that compensates for the speed difference between the sender and the receiver, and a function that detects transmission errors and corrects them (since errors and noise are likely to occur randomly due to the characteristics of the physical transmission medium) or detects transmission errors using a timer and ACK signal on the sender side using methods such as ARQ (Automatic Repeat Request) and retransmits 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 function of controlling the establishment, maintenance, disconnection, 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 constitute the data link layer of Figure OP6.1 are as follows.

[0151] The LLC sub-layer allows for communication independent of the network topology by allowing the use of various lower MAC sub-layer protocols. 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 RRC connections (establishment / maintenance / release) between UEs and E-UTRAN, mobility management (handover), transferring UE contexts between eNodeBs during handover, UE measurement reporting and its control, UE capability management, temporary assignment of cell IDs to UEs, security management including key management, and RRC message encryption. The PDCP sub-layer can perform IP packet header compression using compression methods such as ROHC (Robust Header Compression), and performs functions such as ciphering control messages and user data, ensuring data integrity, and preventing 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, improves data transmission reliability through transmission error and retransmission management, and performs order confirmation, reordering, and duplicate checks for received data. The MAC sub-layer performs the functions of controlling collision / contention occurrence between nodes, fitting packets transmitted from the upper layer to the physical layer frame format, assigning and identifying sender / receiver addresses, carrier detection, collision detection, and detecting obstacles on the physical medium for use of shared media by multiple nodes.The MCO sub-layer enables the 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, thereby minimizing collisions / competition of communication information between vehicles on each frequency channel.

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

[0153] 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, and transmits information on surrounding VRUs or vehicles based on the VRU message or PSM message, or analyzes the road conditions on which surrounding VRUs or vehicles are moving, and transmits a message to notify 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 movement flow of the VRU, etc. based on the received mobility information. Alternatively, the SoftV2X system may be configured in relation to V2N communication.

[0154] User equipment or pedestrian equipment (VRU) that has difficulty performing 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) that has difficulty performing direct communication (PC5, DSRC) can be protected from surrounding vehicles.

[0155] Parking environment guidance for assisted driving of autonomous delivery mobility devices

[0156] Unmanned autonomous vehicles, such as self-driving delivery robots and autonomous shuttles, rely on sensors such as cameras, lidar, and radar attached to their devices / terminals to determine and perceive the view along their route and drive accordingly. Due to the sensor-dependent nature of standalone devices, if the sensors are obscured by inclement weather or vehicles, these devices face limitations not only in ensuring safe driving but also in protecting pedestrians.

[0157] Hereinafter, a technology is described in detail for collecting information on vehicles / mobility devices parked around a driving lane to assist the driving of an autonomous delivery robot (or mobility device) connected to a connectivity mobility platform, and for providing information on parked vehicles to surrounding vehicles from a server. Meanwhile, the connectivity mobility platform can be formed based on the above-described SoftV2X system.

[0158] Furthermore, the autonomous delivery robot and the mobility device can correspond to powered driving devices such as cars, buses, and trucks. Furthermore, the autonomous delivery robot and the mobility device can directly perform wireless communication with peripheral devices or networks, or perform wireless communication with peripheral devices or networks through terminals connected to the network via wires or wireless connections. The mobility device can be defined as a terminal / communication device when it directly performs wireless communication with peripheral devices or networks. Hereinafter, even if the autonomous delivery robot and the mobility device are described as transmitting and receiving messages / signals, it can be assumed that this includes cases where messages / signals are transmitted and received through the terminals.

[0159] FIG. 11 and FIG. 12 are diagrams illustrating a method for a server to generate / transmit a message containing parking information for a mobility device.

[0160] Referring to FIG. 11, the server can identify a parked / stopped mobility device (or, a parked vehicle), generate parking / obstacle information for the mobility device identified as parked / stopped, and transmit the information to surrounding mobility devices.

[0161] Specifically, the mobility device can periodically transmit a V2X message (or V2N message), such as a BSM (Basic Safety Message), containing information about its location and status, through a smartphone or terminal connected to the mobility device via wired / wireless. In this case, the server can receive the V2X message periodically transmitted from the mobility device and transmit / forward the V2X message to surrounding mobility devices related to the mobility device.

[0162] Meanwhile, when the mobility device is out of operation due to parking, etc., transmission of the V2X message to the mobility device may be stopped. When the server does not receive the V2X message from the mobility device or a terminal included in the mobility device for a certain period of time, the server may determine that the mobility device has entered an Off state due to parking, etc. In this case, the server may obtain information on the location where the operation was stopped and the shape / type of the mobility device based on the last V2X message received from the mobility device / terminal, and may generate object information related to obstacles such as a parking area of ​​the mobility device based on the obtained information. The server may transmit an object message or a parking message including the object information generated on behalf of the mobility device in the parked state to the surrounding mobility devices. That is, the server performs an operation of forwarding a message periodically transmitted by the mobility device / terminal to the surrounding mobility devices, and if the mobility device / terminal does not transmit the message for a certain period of time, the server can directly generate object information about the mobility device and transmit it to the surrounding mobility devices.

[0163] Referring to FIG. 12, a connectivity platform server or server (210) may be connected to mobility devices (110, 310, 320) through a first base station (410) and may be connected to terminals (330, 340) through a second base station (420). Here, the mobility device (110) may be an autonomous delivery robot that drives autonomously. The mobility device (110) may receive mobility-related safety services from the server (210) through the base station (410) by utilizing a Uu interface method. The mobility devices (310, 320) may also receive mobility-related safety services from the server (210) through the base station (410) by utilizing a Uu interface method. Terminals (330, 340) in other regions may also receive safety services from the server (210) through other base stations (420).

[0164] Hereinafter, the configuration blocks between the server (210) and the terminal in the system in which the mobility safety service is provided are described in detail. Meanwhile, the terminal is a device that transmits a message (V2X message) to any one of the mobility devices (110, 310, 320), and can be connected to any one of the devices via wired / wireless within any one of the devices.

[0165] Figure 13 is a block diagram briefly illustrating the configuration of a server and terminal included in a system providing mobility safety services.

[0166] Referring to Fig. 13 (a), the terminal can periodically generate and periodically transmit V2X messages such as BSM for mobility devices as in the related art. As described above, the terminal can be connected wired / wirelessly within mobility devices (110, 310, 320) and transmit messages such as BSM (or V2X messages) containing device information (or vehicle information) for the mobility devices (110, 310, 320).

[0167] Specifically, the terminal can extract its own location information through a GNSS device such as GPS. The application block of the terminal can generate the V2X message including device information of the mobility device (or object information such as device type, size, shape, etc.) and the location information. The generated V2X message can be transmitted / transmitted to the server through a Uu interface modem.

[0168] In addition, the terminal may further include a driving state analysis block for providing parking information and an object generation block connected to a UX / UI block. The driving state analysis block may analyze state information on whether a mobility device / vehicle in which the terminal is mounted / included is in a driving state or a parked state based on speed, height, and impact amount related to the terminal. Alternatively, the UX / UI block may distinguish / analyze the parking state and driving state of the mobility device based on a user of the mobility device touching a parking button or a usage pattern, and whether or not connectivity (Bluetooth, USB, etc.) is connected with the mobility device. The object generation block may receive parking state information on the parking state or driving state of the mobility device analyzed from the driving state analysis block and the UX / UI block. When parking of the mobility device is confirmed based on the parking state information, the object generation block may stop transmission of the BSM, generate parking information of the mobility device, and transmit it to the server. In this case, the terminal can transmit a VRU message or PSM to the VRU or user (switched to VRU mode).

[0169] Referring to Fig. 13 (b), a server (or a mobility platform server) can provide a connectivity mobility service through a conventional modem, a V2X stack, and a platform application. The server can additionally be configured with an object management block and a parking DB, and can manage information on a parked mobility device based on the object management block and the parking DB. Specifically, the object management block can identify a parking object based on a message received from a terminal of a parked mobility device and register the identified parking object, which is a parked mobility device, in the parking DB. Alternatively, the object management block can modify the parking DB by excluding, from the parking DB, a parking object whose parking state is identified as having changed to a driving state (i.e., when the parked mobility device resumes transmitting the message, etc.) among the parking objects included in the parking DB.

[0170] Below, the message structure of a V2X message including device information for the mobility device, parking status information for whether the terminal is parked, and location information is described in detail.

[0171] Fig. 14 is a diagram for explaining the message structure of a V2X message that further includes parking status information. Here, the V2X message may be a BSM periodically transmitted from a vehicle, etc.

[0172] When the driving state of the mobility device is determined to be a parking state, the terminal of the mobility device can transmit a message (V2X message or BSM) including parking state information indicating the parking state to surrounding mobility devices (or surrounding terminals included in surrounding mobility devices) and / or a server. Here, the message can have one of two message types as illustrated in FIG. 14.

[0173] Referring to Fig. 14 (a), the message may further include parking status information by utilizing the Regional extension field of the conventional BSM message. The Regional extension field of the BSM message may include subfields for the parking status information. The subfields for the parking status information may include a MsgID subfield for distinguishing information of a parked mobility device, a time subfield for indicating a parked time, and a parking type subfield for including information on the parking status of the parked mobility device. In addition, the subfield for the parking status information may further include a path array subfield for indicating a movement status of the terminal that has left the mobility device and has been converted to a VRU (vulnerable road user / unit) state.

[0174] Alternatively, referring to FIG. 14 (b), a new type of message for transmitting parking status information of the mobility device may be defined. The new type of message may include a header and a payload. The header may include a MsgID field for distinguishing information of a parked mobility device, a time field for indicating a parked time, and a parking type field for including information on the parking status of the parked mobility device. The payload may include an object field for including object information on the parked mobility device, and a path array field for notifying a movement status of a VRU or a user when the mobility device is switched to a VRU state (i.e., when a wired or wireless connection with the mobility device is terminated).

[0175] Below, a method for configuring an object field in a new message according to Fig. 14 (b) is described in detail.

[0176] FIG. 15 and FIG. 16 are diagrams for explaining how a terminal / mobility device configures an object field for notifying a parking status.

[0177] The terminal of the above mobility device can configure an object field for the mobility device based on either the first method and / or the second method.

[0178] Referring to Fig. 15, the object field according to the first method may include a Pos subfield, a width subfield, a length subfield, a height subfield, a heading subfield, a Gap 1 subfield, and a Gap 2 subfield. The object field according to the second method may include a first Pos subfield, a second Pos subfield, a height subfield, a Gap 1 subfield, and a Gap 2 subfield.

[0179] Referring to Fig. 16 (a), the object field is the position of the center of the front row of the mobility device, which is the reference point in the case of the first method (POS UE1 ) containing information about the width of the parking area (or the area of ​​the mobility device) based on the reference point. UE1 ), length (length UE1 ) and height (not shown). In addition, the object field includes a width subfield, a length subfield, and a height subfield that indicate the distance (Gap) between the front of the mobility device and another mobility device obtained by an ADAS (Advanced Driver Assistance System) sensor included in the mobility device. 2 ) and the distance between the back of the above mobility device and another mobility device (Gap 1 ) and the Gap 1 and Gap 2 subfields and the heading direction (Heading UE1) may further include a heading subfield indicating the distance between the two sides of the mobility device. Meanwhile, if the mobility device is parked diagonally (i.e., if the parking type is the third or fourth type), the Gap 1 subfield and the Gap 2 subfield may indicate the distance between the two sides of the mobility device.

[0180] Referring to Fig. 16 (b), in the second method, the object field is located at both end points of the parked mobility device (one end point of the rear part and one end point of the front part as shown in Fig. 16 (b); , ) may include a Pos A subfield and a Pos B subfield that indicate the location of the mobility device. The server may obtain information about the length (and / or width) and parking angle of the mobility device through the Pos A subfield and the Pos B subfield. Meanwhile, in the case of the second method, the object field may include a height subfield, a Gap 1 subfield (Gap 1 ) and Gap 2 (Gap 2 ) may include subfields.

[0181] Hereinafter, a method for transmitting a message (or, a parking object message) containing object information about the mobility device to surrounding mobility devices of the mobility device when the server determines that the mobility device is in a parked state based on a message transmitted by the mobility device or a terminal related to the mobility device is described in detail.

[0182] Figures 17 to 19 are drawings for explaining a method in which a server generates object information based on parking status information.

[0183] Referring to FIG. 17, the server can set a risk level for the parked mobility device differently depending on whether the parking type field for the parking status information included in the message received from the terminal of the parked mobility device is the first type, the second type, the third type, or the fourth type.

[0184] The first type may be a case where the mobility device is parallel parked in a dedicated parking space, the second type may be a case where the mobility device is parked on a road other than a dedicated parking space, the third type may be a case where the mobility device is diagonally parked in a direction corresponding to the driving direction of the road, and the fourth type may be a case where the mobility device is pre-parked in a direction not corresponding to the driving direction of the road.

[0185] In this case, the server may set different risk levels depending on the type of the parking state. For example, the risk levels may increase in the order of the first type, the second type, the third type, and the fourth type. In the case of the first type, a mobility device that is parked in a dedicated parking space and is driving on the road has the lowest possibility of collision with a mobility device parked in the first type that has switched back to a driving state. In the case of the second type, a mobility device that is parked in a parallel manner on the road has a higher possibility of collision between a vehicle driving on the road and a parked mobility device compared to the first type. However, even if a mobility device parked in the second type switches back to a driving state, it only drives in the driving direction of the road, so the possibility of collision between a vehicle driving on the road and a parked mobility device is lower than in the case of the third type. In the case of the third type above, the possibility of collision between a road vehicle and a parked mobility device is higher than in the case of the second type above, as the vehicle is parked diagonally in the direction of travel of the road. However, since the turning radius of the parked mobility device is smaller than in the fourth type above, the risk level of the third type above may be lower than in the case of the fourth type above.

[0186] Furthermore, in the case of the third type, a mobility device (such as an autonomous delivery robot) driving on the road can easily recognize the movement of a user of the VRU between parked mobility devices, but in the case of the fourth type, it is difficult for a mobility device (such as an autonomous delivery robot) driving on the road to recognize the movement of a user of the VRU between parked mobility devices. Therefore, in the case of the fourth type, a relatively higher risk level may be set than in the other types because the possibility of collision with a VRU is higher than in the other types. The server may further include information about the risk level according to the parking type in the parking message.

[0187] Referring to FIG. 18, the path array field may include information about a movement path of a user of the terminal (hereinafter, VRU movement path) when the terminal is switched from mobility mode to VRU mode. Here, the mobility mode is a mode in which the terminal transmits BSM, etc. related to the mobility device as described above, and the VRU mode is a mode in which the terminal transmits a message as a VRU when the terminal leaves the mobility device (i.e., when the wired or wireless connection with the mobility device is disconnected).

[0188] The server can determine information about a gap, which is a distance between the mobility device and an adjacent mobility device, and gap rank information about the gap based on the VRU movement path included in the path array field. For example, the server can predict the existence and size of a space between parked mobility devices based on the VRU movement path through the space between parked mobility devices, and can determine the probability and risk of pedestrians, etc. appearing in the space based on the number of VRU movement paths passing through the space.

[0189] Additionally, the server can predict / estimate the size of the parked mobility device and the distance between the parked mobility devices based on the VRU movement path included in the path array field. The server can predict / estimate the size of the mobility device based on the movement path of the VRU that goes around the parked mobility device.

[0190] Specifically, referring to FIG. 19, the server may correct a parking area (or a first state area) of a mobility device related to a message (or a V2X message) of the terminal / mobility device based on a path array field included in the message. For example, after the server determines an initial parking area of ​​the mobility device based on driving state information included in the message of the terminal / mobility device, if a VRU movement path based on the array field passes through the initial parking area, the server may change / correct the initial parking area based on the VRU movement path. In this way, by changing / correcting the initial parking area based on the VRU movement path, it is possible to minimize the driving of surrounding mobility devices being disturbed (through false collision alarms, etc.) by an incorrect initial parking area.

[0191] FIGS. 20 to 23 are diagrams for explaining a method in which the server transmits a parking message including object information about a mobility device in a parked state.

[0192] The server (or mobility platform server) can collect information about a parked mobility device through messages received from a terminal associated with the mobility device as described above. In this case, the server can directly generate parking object information about the parked mobility device and transmit a parking message (or object message) containing the parking object information to surrounding mobility devices of the mobility device.

[0193] Referring to FIG. 20, the parking object message may include a header and a payload. The header may include a MsgID field, a time field indicating the parked time, a parking type field indicating the parking type of the parked mobility device, and a NumCar field indicating the number of at least one mobility device in a parked state. The payload may include at least one piece of parking object information generated for each of at least one mobility device in a parked state identified / determined by the server.

[0194] The above parking object information can be generated based on three methods as illustrated in Fig. 20. The parking object information according to the first method (Method1) and the second method (Method2) can include the same information as the object information of the first method and the object information of the second method for the message transmitted by the terminal described with reference to Fig. 15, except for the Gap subfield and the GapRank subfield.

[0195] Specifically, referring to FIG. 21, the server may generate parking object information based on the first method (see FIG. 21 (a)) or the second method (see FIG. 21 (b)) based on object information of a message received from a terminal of the parked mobility device (hereinafter, referred to as a parking mobility device). At this time, when another mobility device is identified in front of and behind the parking mobility device, the server may modify / update Gap 1 and Gap 2 information included in the message of the terminal and include them in the parking object information. The GapRank field may be an Integer field having 128 bits. As described above, the GapRank field may include a Rank value that increases by the number of times a VRU or a pedestrian has passed through the space in front of and behind the parking mobility device. In this case, the larger the Rank value of the GapRank field of the parking object information, the higher the probability that a VRU or a pedestrian will appear in the space in front of and behind the parking mobility device.

[0196] Referring to Fig. 22, parking object information based on method 3 can represent parked mobility devices as a group. Specifically, the server can group mobility devices parked in a predetermined area into a group and generate group object information for the group. For example, the group object information can indicate the parking area (location and size) of the group. and It may include information about. In addition, the group object information may include information about gaps between mobility devices included in the one group (Gap#1 to Gap#n), rank information of the gaps (GapRank#1 to GapRank#n), and offset information (Offset#1 to Offset#n) as information about the space between the mobility devices.

[0197] Below, a method for exchanging messages between a server, a terminal of a mobility device, and an autonomous delivery robot, which is a mobility device, is described in detail.

[0198] Figures 23 to 25 are drawings for explaining a method of exchanging messages between a server, a terminal, and an autonomous delivery robot.

[0199] Referring to FIG. 23, the nth terminal (UE#n) can periodically generate / transmit a BSM or V2X message to the mobility device from the mobility device (S231) (e.g., mobility mode). The server (or mobility platform server) can periodically receive the BSM or V2X message from the nth terminal (UE#n) and forward the received BSM or V2X message to a surrounding autonomous delivery robot (or surrounding mobility device).

[0200] Next, when the mobility device is switched to a parking state, the nth terminal (UE#n) may stop transmitting BSM or V2X messages, but may transmit a message including parking state information (in the case of FIG. 14 (b) further including object information) about the mobility device to the server (S232). The server may generate a parking message including parking object information based on the parking state information, and transmit the parking message to an autonomous delivery robot driving around the mobility device. At this time, the parking object information may include (parking) object information about not only the mobility device but also other mobility devices that are in a parking state. The autonomous delivery robot may identify a parking area (or a first state area) where the mobility device is parked based on the parking object information, and may perform safe driving, such as evasive driving, of the mobility device in the identified parking area.

[0201] Alternatively, the server may determine the parking status of the mobility device even if it does not receive a message including parking status information of the mobility device from the n-th terminal (UE#n). For example, the server may determine / decide that the mobility device is in a parking status if the BSM or V2X message is not received from the n-th terminal (UE#n) within a specific time (e.g., a time longer than the period of the BSM or V2X message). Alternatively, the server may determine / predict the parking location / parking time of the mobility device based on the start time and start position at which the reception of a VRU message (i.e., a message transmitted when the mobility device gets off and switches to VRU mode) from the n-th terminal (UE#n) begins. In this case, the server may generate parking object information for the mobility device based on the last BSM or V2X message received from the n-th terminal (UE#n), and transmit a parking message including the parking object information from the autonomous delivery robot.

[0202] Next, when the nth terminal (UE#n) is reconnected with the mobility device and the mobility device switches to a driving state, the nth terminal (UE#n) can resume transmitting BSM or V2X messages to the mobility device. In this case, the server can transmit the parking message with the parking object information corresponding to the mobility device deleted from the autonomous delivery robot (S233).

[0203] Meanwhile, the nth terminal (UE#n) may not resume transmission of the BSM or V2X message to the mobility device even if the mobility device changes to a driving state due to the boarding of the nth terminal (UE#n). Hereinafter, a method for the server to recognize that the mobility device has changed to a driving state and update the parking message when transmission of the BSM or V2X message to the mobility device is not resumed will be described in detail.

[0204] Referring to FIG. 24, the server can receive a BSM or V2X message from the nth terminal (UE#n) and forward the received BSM or V2X message to surrounding autonomous delivery robots (autonomous delivery robot #1, autonomous delivery robot #2).

[0205] Thereafter, when the mobility device enters a parking state, the nth terminal (UE#n) can transmit a message including parking state information about the parking state of the mobility device to the server. The server can update the parking message based on the parking state information (or, if the parking state information is not received, the last received V2X message) and transmit the updated parking message to autonomous delivery robots (autonomous delivery robot #1, autonomous delivery robot #2).

[0206] Next, the server may receive a request message requesting deletion of a parking object from at least one of the surrounding autonomous delivery robots (autonomous delivery robot #1, autonomous delivery robot #2), and may delete parking object information corresponding to the parking object for which deletion is requested. Specifically, the surrounding autonomous delivery robots (autonomous delivery robot #1, autonomous delivery robot #2) may request the server to delete the undetected mobility device (UE1) when the parked mobility device corresponding to the parking object information received from the server while driving is not detected by a sensor. Alternatively, the surrounding autonomous delivery robots (autonomous delivery robot #1, autonomous delivery robot #2) may request the server to delete the parked mobility device (UE1) that is missing from the parking object information received from the server while driving. n+1 ) is detected by a sensor, the mobility device (UE) n+1 ) can transmit a request message requesting addition of object information to the server. Here, the request message is transmitted to a mobility device (UE) n+1 ) may include detection information (information related to location, parking range).

[0207] Meanwhile, referring to FIG. 25, the server may request surrounding mobility devices to delete the parking object information of the mobility device (UE1) indicated in the request message through a separately defined deletion message. Specifically, the deletion message may include a header and a payload, wherein the header may include a ParkingType field set to '0', and the payload may include an object index field for the index of the object information to be deleted.

[0208] Below, the method by which the server and terminal operate based on the above-described method is described in detail.

[0209] FIG. 26 is a diagram for explaining a method for a server and a terminal to transmit and receive a parking message including object information or parking object information for a parked mobility device.

[0210] Referring to Fig. 26 (a), the terminal (wired or wirelessly connected to the mobility device) can periodically transmit a BSM or V2X message to the terminal-based mobility device (mobility mode; S262) when the system is initialized (S261).

[0211] The terminal can determine / judge whether the mobility device is in a parked state (S263). If the mobility device is in a driving state (S263, No) rather than a parked state, the terminal can maintain periodic transmission of the BSM. Conversely, if the mobility device is in a parked state (S263, Yes), the terminal can stop transmitting BSM or V2X messages to the mobility device. The terminal can generate an (object) message including parking state information for notifying the parking state of the mobility device and transmit the message to the server (S264).

[0212] Next, the terminal disconnected from the mobility device can periodically transmit a VRU message or a PSM (Personal Safety Message), which is a message for protecting VRUs or pedestrians, etc. (VRU mode; S265). At this time, the terminal can transmit a message including a path array field based on the path history of the VRU or a message for updating the parking location / parking area of ​​the mobility device to the server (S266).

[0213] Referring to Fig. 26 (b), the server can initialize the system when the system starts (S271). The server can periodically receive BSM or V2X messages for mobility devices related to the terminal from the terminal (S272).

[0214] When the server receives a message including the parking status information from the terminal, the server can add / register a mobility device corresponding to the parking status information to the parking DB (S725). The server can generate parking object information based on the scanning status information and update the parking DB by registering the parking object information. The server can periodically transmit a parking message based on the updated parking DB (S276).

[0215] The server may receive a VRU message or PSM for the protection of a VRU or a user from the terminal (S277-1), and update a Gap value and GapRank for the mobility device based on location information and information about a VRU movement path included in the PSM or the VRU message (S277-2). For example, the server may correct a parking area of ​​the mobility device based on the location information and the VRU movement path included in the PSM or the VRU message, and increase a Rank value for one of the two Gaps when the VRU movement path passes through one of the two Gaps for the mobility device. The server may update the parking DB based on the updated Gap value and GapRank for the mobility device (S275). The server may periodically transmit a parking message based on the updated parking DB (S276).

[0216] Alternatively, when a BSM or V2X message for a mobility device determined to be in the parked state is received again, the server may analyze the location of the mobility device (S278-1), determine to delete parking object information for the mobility device from the parking DB (S278-2), and update the parking DB by deleting parking object information related to the mobility device from the parking DB (S275). The server may periodically transmit a parking message based on the updated parking DB (S276). Meanwhile, when the mobility device is deleted, the server may reset / update the Gap value and / or GapRank for mobility devices parked around the mobility device.

[0217] Below, we describe in detail how autonomous delivery robots or mobility devices drive using / utilizing the above parking messages.

[0218] Figure 27 is a drawing illustrating how an autonomous delivery robot drives based on a parking message.

[0219] Referring to FIG. 27, the autonomous delivery robot can control the speed and the distance from the parked mobility device based on the GapRank value included in the parking message.

[0220] Specifically, the autonomous delivery robot can set a driving route to avoid parked mobility devices on the road based on the parking message. At this time, the autonomous delivery robot can additionally consider the location of the Gap and the GapRank value of the parking object information included in the parking message to set the driving route. For example, as illustrated in FIG. 25, the autonomous delivery robot can distinguish a plurality of driving blocks (a block, b block, c block, d block) on the driving route by considering the parking areas of the mobility devices determined based on the parking object information and the Gap between the mobility devices. In this case, the autonomous delivery robot can set the speed and the distance from the parking area for each driving block. For example, in the case of block a, the autonomous delivery robot can set the maximum speed to 10 km / h and the distance from the parking area to 2 m based on the GapRank for block a being 2. For b block, the autonomous delivery robot may set the maximum speed to 3 km / h and the distance from the parking area to 3 m based on the GapRank for b block being 10. For c block, the autonomous delivery robot may set the maximum speed to 8 km / h and the distance from the parking area to 2 m based on the GapRank for c block being 5. For d block, the autonomous delivery robot may set the maximum speed to 12 km / h and the distance from the parking area to 1 m based on the GapRank for d block being 0. That is, the autonomous delivery robot may set the lowest speed for b block having the highest GapRank, and may set the highest speed for d block having the lowest GapRank.

[0221] In this way, when a mobility device connected to a mobility platform server stops, the server can generate parking object information by utilizing the location information and / or object information included in the last message, and periodically transmit parking object information about the mobility device on behalf of the mobility device. Through this, even if a BSM or V2X message cannot be transmitted to the parked mobility device, parking object information about the parked mobility device can be periodically transmitted to surrounding mobility devices through the server. In this case, the surrounding mobility devices can drive more safely by setting a moving path based on the additional object information even in an environment where detection by sensors, etc. is difficult.

[0222] FIG. 28 is a diagram illustrating a method for transmitting an object message containing object information for a second device in which a first device is parked.

[0223] Referring to FIG. 28, a first device may receive a first V2X message for a second device from a first terminal (S281). The first V2X message may include device information for the second device, such as location, device type, device shape, and device size for recognition / recognition of the second device, as described above. For example, the first V2X message may be a BSM for a vehicle safety service including the vehicle information described above.

[0224] Here, the second device may be a mobility device, such as a vehicle or a driving device, as described in FIGS. 11 to 27, and the first terminal may be a communication device that is connected to the mobility device via wired or wireless means and transmits and receives BSM or V2X messages for the mobility device. In addition, the first device is the above-described mobility platform server or server, and may forward / transmit the V2X message for the second device received from the first terminal to devices (e.g., vehicles, mobility devices, autonomous delivery robots, etc.) located in an area related to the second device via a Uu interface.

[0225] Next, the first device can determine / determine whether the second device is in the first state based on whether the first V2X message or the periodic reception of the first V2X message is performed (S283). As described above, the first state may be a state in which the second device is parked on the road as described in FIGS. 11 to 27, and the second state may be a state in which the second device is driving on the road.

[0226] Specifically, the first device can determine the state of the second device as the first state, which is a parking state, when the Regional extension of the first V2X message includes fields (MsgID, Time, Parking Type, and Path array) indicating that the second device is in the first state, as described with reference to FIG. 14 (a). Alternatively, the first device can determine the state of the second device as the first state, which is a parking state, when the first V2X message includes parking state information, as described with reference to FIG. 14 (a).

[0227] Alternatively, the first device may estimate / determine that the second device is in the first state when it is determined that the periodic transmission of the first V2X message has been discontinued. For example, the first device may determine that the second device is in the first state when a V2X message for the second device is not received from the first terminal within a specific time period. This is because when the second device, which is a mobility device / vehicle, is turned off due to parking or the like, the second terminal also discontinues transmission of V2X messages for the second device due to a disconnection with the mobility device.

[0228] Next, the first device can directly generate parking object information for the second device based on the first V2X message when the state of the second device is determined to be the first state (S285). The first device can specify a first state area, which is a parking area related to the second device, based on the device information or parking state information included in the first V2X message, and can generate object information or parking object information including the first state area and first state information indicating that the second device is in a parking state.

[0229] The object information or the parking object information may include information for specifying the first state area based on the first method, the second method, or the third method, as described with reference to FIG. 20. Furthermore, the object information or the parking object information may further include information on gap information and gap rank, as described with reference to FIG. 20.

[0230] Meanwhile, as described with reference to FIGS. 20 and 22, when other devices are parked adjacent to the first state area where the second device is parked (or, when a parking group exists in an area adjacent to the first state area), the first device may group the second device and the other devices into one (parking) group. In this case, the first device may generate information on the first state area, which may include all parking areas for the devices included in the one group, as the object information, as illustrated in FIG. 22. In this case, as illustrated in FIG. 22, the object information on the one group may additionally include offset information, which is a distance between the second device and the other adjacent devices.

[0231] Next, the first device can transmit an object message (or parking message) including the generated object information to a third device (S287). That is, even if a V2X message for the second device in a parked state cannot be transmitted, the first device can periodically transmit an object message including object information, which is parking information for the second device, to peripheral devices on behalf of the second device. Here, the object message may be a parking message or a parking object message described with reference to FIGS. 11 to 27. The third device may be an autonomous delivery robot (or autonomous delivery robot, delivery mobility device) described with reference to FIGS. 11 and 27. In this case, the third device can obtain information about the location / area and range where the second device in the first state is parked through the object information included in the object message, and control / set the autonomous driving path and speed, etc. based on the obtained information.

[0232] In addition, the object information may further include information about a gap between the second device and another device as described above, and gap rank information about the gap. The gap rank information may include a value set according to the number of VRU movement paths passing through the gap based on a VRU message / PSM (a message including information about the VRU movement path) received from a VRU device / terminal located in the first state area related to the second device or adjacent to the first state area as described above. For example, the gap rank information may include a value counted / increased by the number of VRU movement paths passing through the gap. In this case, the third device may set / determine a path / driving speed when driving in an area adjacent to the first state area based on the information about the gap and the information about the gap rank as described with reference to FIG. 27.

[0233] Alternatively, the first device may correct / modify the first state area based on the VRU movement path included in the VRU message. For example, the first device may exclude a portion of the first state area that overlaps with the VRU movement path.

[0234] Alternatively, the first device may determine that the state of the second device has transitioned from the first state to the second state when a V2X message for the second device determined to be in the first state is retransmitted from the first terminal. In this case, the first device may stop generating object information for the second device and transmitting an object message including the object information to the second device. Alternatively, as described above, when an object message including object information for one group is transmitted according to the third method, the first device may update the object information for the one group (adjust / change at least one of an offset, a gap, and two position values ​​for excluding a first state area for the second device from a first state area for the one group) so that information related to the second device is deleted from the object information for the one group, and transmit the object message including the (group) object information for the updated one group.

[0235] Alternatively, the first device may receive a message from the third device requesting deletion of object information about the second device. In this case, the first device may stop generating object information that is periodically generated for the second device, or update object information about a group in which the second device is included so that object information about the second device is excluded from the object information about the group. For example, the third device may request the first device to delete object information about the second device when the second device corresponding to the first status area of ​​the second device is not detected / detected based on the object information.

[0236] Alternatively, the first device may receive a request message requesting addition of object information for a specific device from the third device. In this case, the first device may generate object information for the specific device based on the request message and transmit an object message including the object information. Alternatively, when object information for at least one device adjacent to the (parking) location of the specific device is generated, the first device may group the specific device and the at least one device into one group and transmit an object message including object information for the one group. Alternatively, when one group for the at least one device has already been formed, the first device may update object information for the one group so that object information for the already formed one group includes object information for the specific device.

[0237] As described above, the object information generated by the first device or the first terminal may be information regarding the parking area / parking type / parking status in which a specific device / mobility device is parked. Accordingly, the object information may be defined as parking area information or parking information.

[0238] In this way, in the mobility platform system, when a first device, which is a server, identifies a specific mobility device that is parked based on V2X messages, object information about the parking status of the specific mobility device is generated and transmitted on behalf of the specific mobility device, so that the surrounding mobility devices can significantly improve the recognition rate of the specific mobility device. Alternatively, the surrounding mobility devices can effectively perform evasive driving of the specific mobility device by recognizing the specific mobility device through a message that includes the object information of the first device. Alternatively, the first device can additionally include gap information and gap rank information about the gap between the parked mobility devices in the object information, thereby assisting the surrounding mobility devices to proactively respond to the movement of pedestrians, etc., through the gap.

[0239] Examples of communication systems to which the invention applies

[0240] 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 / connection (e.g., 5G) between devices.

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

[0242] Figure 29 illustrates a communication system applied to the present invention.

[0243] Referring to FIG. 29, a communication system (1) applied to the present invention includes a wireless device, a base station, and a network. Here, the wireless device refers to 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 Things) 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 an Unmanned Aerial Vehicle (UAV) (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. Mobile devices can include smartphone, smart pad, wearable device (e.g., smart watch, smart glass), computer (e.g., laptop, etc.), 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.

[0244] 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). In addition, IoT devices (e.g., sensors) can communicate directly with other IoT devices (e.g., sensors) or other wireless devices (100a to 100f).

[0245] Wireless communication / connection (150a, 150b, 150c) can be established between wireless devices (100a~100f) / base stations (200), and base stations (200) / base stations (200). Here, 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 wireless communication / connection (150a, 150b, 150c), wireless devices and base stations / wireless devices, and base stations and base stations can transmit / receive wireless signals to each other. For example, 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.

[0246] Examples of wireless devices to which the present invention is applied

[0247] Figure 30 illustrates a wireless device applicable to the present invention.

[0248] Referring to FIG. 30, the first wireless device (100) and the second wireless device (200) can transmit and receive wireless signals via 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. 29.

[0249] A first wireless device (100) includes one or more processors (102) and one or more memories (104), and may further include one or more transceivers (106) and / or one or more antennas (108). The processor (102) controls the memories (104) and / or the transceivers (106), and may be configured to implement the descriptions, functions, procedures, proposals, 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). In addition, 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 code including commands for performing the descriptions, functions, procedures, proposals, methods, and / or operation 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.

[0250] Specifically, the first wireless device or first apparatus (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. 11 to 28.

[0251] The processor (102) controls the transceiver (106) to receive a first V2X (Vehicle-to-Everything) message including device information for a second device from a first terminal, determine that the second device is in the first state based on a second V2X message not being received from the first terminal within a specific time after receiving the first V2X message, generate object information including a first state area and first state information related to the second device using the device information, and transmit an object message including the object information to a third device.

[0252] Alternatively, a processing device controlling a first device may include a processor (102) and a memory (104). The processing device may cause the first device to receive a first V2X (Vehicle-to-Everything) message including device information about a second device from a first terminal, determine that the second device is in the first state based on a second V2X message not being received from the first terminal within a specific time after reception of the first V2X message, generate object information including a first state area and first state information related to the second device using the device information based on the second device being in the first state, and transmit an object message including the object information to a third device.

[0253] The second wireless device (200) includes one or more processors (202), one or more memories (204), and may further include one or more transceivers (206) and / or one or more antennas (208). The processor (202) controls the memories (204) and / or the transceivers (206), and may be configured to implement the descriptions, functions, procedures, proposals, 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). Furthermore, 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 code including commands for performing the descriptions, functions, procedures, proposals, methods, and / or operation 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.

[0254] A second wireless device (200) or mobility device (or autonomous delivery robot) may include a processor (202) and a transceiver (206). The processor (202) controls the transceiver (206) to transmit a V2X (Vehicle-to-Everything) message including device information about the mobility device to a first device, receive an object message including object information about the second device from the first device, and control driving based on the object information. Here, the object information may include a first state area, first state information, gap information, and gap rank information related to the second device based on the second device being in a first state.

[0255] Hereinafter, the 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 operation 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 operation flowcharts disclosed in this document. One or more processors (102, 202) can generate signals (e.g., baseband signals) including PDUs, SDUs, messages, control information, data or information according to the functions, procedures, proposals and / or methods 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, proposals, methods and / or operational flowcharts disclosed herein.

[0256] One or more processors (102, 202) may be referred to as a controller, a microcontroller, a microprocessor, or a microcomputer. 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 one or more processors (102, 202). The descriptions, functions, procedures, proposals, 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 operation flowcharts disclosed in this document may be implemented using firmware or software configured to perform one or more processors (102, 202) or stored in one or more memories (104, 204) and executed by one or more processors (102, 202). The descriptions, functions, procedures, suggestions, methods and / or operation flowcharts disclosed in this document may be implemented using firmware or software in the form of codes, instructions and / or sets of instructions.

[0257] 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 configured as 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.

[0258] One or more transceivers (106, 206) can transmit user data, control information, wireless signals / channels, etc., as mentioned 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 mentioned in the descriptions, functions, procedures, proposals, methods and / or flowcharts of this document, from one or more other devices. For example, one or more transceivers (106, 206) can be connected 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, or the like, as referred to in the descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed herein, via one or more antennas (108, 208). In this document, one or more antennas may be multiple physical antennas or multiple logical antennas (e.g., antenna ports). One or more transceivers (106, 206) can 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 user data, control information, wireless signals / channels, etc. processed by one or more processors (102, 202) from baseband signals to RF band signals. For this purpose, one or more transceivers (106, 206) may include an (analog) oscillator and / or filter.

[0259] Examples of wireless devices to which the present invention is applied

[0260] Figure 31 illustrates another example of a wireless device applicable to the present invention. The wireless device may be implemented in various forms depending on the use case / service (see Figure 29).

[0261] Referring to FIG. 31, the wireless device (100, 200) corresponds to the wireless device (100, 200) of FIG. 30 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 additional elements (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. 31. For example, the transceiver(s) (114) may include one or more transceivers (106, 206) and / or one or more antennas (108, 208) of FIG. 30. The control unit (120) is electrically connected to the communication unit (110), the memory unit (130), and the additional elements (140) and controls the overall operation of the wireless device. For example, the control unit (120) may control the electrical / mechanical operation of the wireless device based on the program / code / command / 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).

[0262] 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. 29, 100a), a vehicle (Fig. 29, 100b-1, 100b-2), an XR device (Fig. 29, 100c), a portable device (Fig. 29, 100d), a home appliance (Fig. 29, 100e), an IoT device (Fig. 29, 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. 29, 400), a base station (Fig. 29, 200), a network node, etc. Wireless devices may be mobile or stationary depending on the use / service.

[0263] In FIG. 31, 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 a 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 a set of one or more processors. 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 graphics 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.

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

[0265] Figure 32 illustrates a vehicle or autonomous vehicle applicable to the present invention. The vehicle or autonomous vehicle may be implemented as a mobile robot, car, train, manned / unmanned aerial vehicle (AV), ship, etc.

[0266] Referring to FIG. 32, 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. 31, respectively.

[0267] 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.), and servers. 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, an illuminance 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.

[0268] 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 driving plan based on the acquired data. The control unit (120) can control the drive 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, during autonomous driving, the sensor unit (140c) can acquire vehicle status and surrounding environment information. The autonomous driving unit (140d) can update the autonomous driving route and driving plan based on newly acquired data / information. The communication unit (110) can transmit information regarding the vehicle location, autonomous driving route, driving plan, etc. to the external server. External servers can predict traffic information data in advance using AI technology or other technologies based on information collected from vehicles or autonomous vehicles, and provide the predicted traffic information data to the vehicles or autonomous vehicles.

[0269] Here, the wireless communication technology implemented in the wireless device (XXX, YYY) of the present specification may include not only LTE, NR, and 6G, but also 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, 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, 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.

[0270] 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 without being combined with other components or features. Furthermore, 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 self-evident that claims that do not have an explicit citation relationship in the patent claims may be combined to form an embodiment or may be incorporated as a new claim through a post-application amendment.

[0271] In this document, embodiments of the present invention have been described primarily focusing on the signal transmission and reception relationship between a terminal and a base station. This transmission and reception relationship is equally / similarly extended to signal transmission and reception between a terminal and a relay or a base station and a relay. Certain operations 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 multiple 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 by terms such as fixed station, Node B, eNode B (eNB), and access point. In addition, the terminal may be replaced by terms such as UE (User Equipment), MS (Mobile Station), MSS (Mobile Subscriber Station).

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

[0273] When implemented via firmware or software, an embodiment of the present invention may be implemented in the form of modules, procedures, functions, etc. that perform the functions or operations described above. The software code may be stored in a memory unit and executed by a processor. The memory unit may be located within or outside the processor and may exchange data with the processor via various known means.

[0274] 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 invention. Therefore, the above detailed description should not be construed as limiting in any respect, but rather as illustrative. The scope of the present invention should be determined by a reasonable interpretation of the appended claims, and all modifications within the scope of equivalents of the present invention are intended to be included within the scope of the present invention.

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

Claims

1. In a method for transmitting a message by a first device in a wireless communication system, A step of receiving a first V2X (Vehicle-to-Everything) message including device information for a second device from a first terminal; A step of generating object information including a first state area and first state information related to the second device using the device information based on the second device being in the first state; and A step of transmitting an object message including the object information to a third device; A method wherein the second device determines that the first device is in the first state based on the fact that no V2X message for the second device is received from the first terminal within a specific time after receipt of the first V2X message.

2. In paragraph 1, A method, characterized in that the object information includes information on a reference position value, length and width for specifying the first state area, or includes two position values ​​for specifying the first state area.

3. In paragraph 1, A step of receiving PSM (Personal Safety Message) or VRU messages including information on the movement path of a VRU (Vulnerable Road User) from second terminals located around the second device; and A method, characterized in that it further comprises a step of correcting the object information for the second device based on the VRU movement path.

4. In paragraph 3, The above object information further includes gap information and gap rank information related to the second device in the first state, A method, characterized in that the gap information includes information about a gap between the second device and another device, and the gap rank information includes a rank value that increases based on the number of VRU movement paths passing through the gap.

5. In paragraph 1, A method, characterized in that it further comprises the step of grouping the second device and at least one device adjacent to the second device into one group based on the location of the second device.

6. In paragraph 5, A method, characterized in that, based on the formation of said one group for said second device, a first state area related to said second device is specified as an area including both said second device and said at least one device included in said one group.

7. In paragraph 1, A method characterized in that the first device determines the state of the second device as a second state based on a V2X message for the second device in the first state being received from the first terminal, and stops generating the object information for the second device.

8. In paragraph 1, A method, characterized in that the first state is a parking state.

9. A computer-readable recording medium having recorded thereon a program for performing the method described in Article 1.

10. In a first device for transmitting a message 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 first V2X (Vehicle-to-Everything) message including device information about a second device from a first terminal, determines that the second device is in the first state based on the fact that no V2X message about the second device is received from the first terminal within a specific time after reception of the first V2X message, generates object information including a first state area and first state information related to the second device using the device information, and transmits an object message including the object information to a third device.

11. In a processing device controlling a first device transmitting a message 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 causing said first device to: A processing device configured to receive a first V2X (Vehicle-to-Everything) message including device information about a second device from a first terminal, determine that the second device is in the first state based on the fact that no V2X message about the second device is received from the first terminal within a specific time after reception of the first V2X message, generate object information including a first state area and first state information related to the second device using the device information based on the second device being in the first state, and transmit an object message including the object information to a third device.

12. A method for a mobility device to receive a message in a wireless communication system, A step of transmitting a V2X (Vehicle-to-Everything) message containing device information about a mobility device to a first device; A step of receiving an object message including object information for a second device from the first device; and A step of controlling driving based on the above object information; A method wherein the object information includes a first state area, first state information, gap information and gap rank information related to the second device based on the second device being in the first state.

13. In paragraph 12, The gap information includes information about a gap between the second device and another device, and the gap rank information includes a count value counted based on the number of VRUs (Vulnerable Road Users) passing through the gap. A method, characterized in that the mobility device sets a driving speed and a distance from the first state area based on the gap information and gap rank information.

14. A computer-readable recording medium having recorded thereon a program for performing the method described in Article 12.

15. In a mobility device receiving a message 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 transmit a V2X (Vehicle-to-Everything) message including device information about a mobility device to a first device, receives an object message including object information about a second device from the first device, and controls driving based on the object information. A mobility device, wherein the object information includes a first state area, first state information, gap information, and gap rank information related to the second device based on the second device being in the first state.

16. In a processing device for controlling a mobility device that receives a message 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 mobility device causes: Transmitting a V2X (Vehicle-to-Everything) message including device information about a mobility device to a first device, receiving an object message including object information about a second device from the first device, and controlling driving based on the object information; A processing device, wherein the object information includes a first state area, first state information, gap information, and gap rank information related to the second device based on the second device being in the first state.

Images