Method for transmitting and receiving data and device performing same in wireless communication system

Abstract

A method for a first apparatus related to a vehicle to transmit data in a wireless communication system according to at least one of various embodiments includes: acquiring monitoring data for a user of the vehicle and the internal environment of the vehicle via a monitoring system including at least one of a camera or a sensor; detecting an emergency event related to the safety of the user on the basis of the monitoring data; generating a message including a first data field for the detected emergency event; and transmitting the generated message to a second apparatus, wherein the generation of the message may include a pre-processing process for excluding monitoring data related to personal information about the user from the first data field for the emergency event.

Description

Method for transmitting and receiving data in a wireless communication system and device for performing the same

[0001] This specification relates to a wireless communication system, and more specifically, to a method for transmitting and receiving vehicle-related data in an intelligent transport system (ITS) and a device for performing the same.

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

[0003] Intelligent Transport Systems (ITS) utilize wireless communication technologies to manage transportation systems more efficiently and improve safety. ITS systems can monitor traffic conditions in real time and collect and process data using CCTV, sensor networks, GPS devices, and wireless communication systems. ITS systems can also support inter-vehicle communication, allowing vehicles to communicate with each other and share information about their surroundings to enhance autonomous driving and traffic safety.

[0004] The technical challenge is to transmit and receive data more accurately and efficiently in wireless communication systems.

[0005] The technical challenges are not limited to those mentioned above, and other technical challenges not mentioned can be derived from the description below.

[0006] In a wireless communication system according to one aspect, a method for transmitting data by a first device related to a vehicle comprises: obtaining monitoring data on a user of the vehicle and an environment inside the vehicle through a monitoring system including at least one of a camera and a sensor; detecting an emergency event related to the safety of the user based on the monitoring data; generating a message including a first data field for the detected emergency event; and transmitting the generated message to a second device, wherein the generation of the message may include a preprocessing step for excluding monitoring data related to personal information of the user from the first data field for the emergency event.

[0007] According to another aspect, a computer-readable recording medium having recorded thereon a program for performing the above-described data transmission method may be provided.

[0008] In another aspect, a first device related to a vehicle in a wireless communication system includes a memory for storing commands; and a processor for performing operations by executing the commands, wherein the operations of the processor include obtaining monitoring data on a user of the vehicle and an environment inside the vehicle through a monitoring system including at least one of a camera and a sensor; detecting an emergency event related to the safety of the user based on the monitoring data; generating a message including a first data field for the detected emergency event; and transmitting the generated message to a second device, wherein the generation of the message may include a pre-processing step for excluding monitoring data related to personal information of the user from the first data field for the emergency event.

[0009] The above pre-processing step may include determining an event code for the detected emergency event from among a plurality of predefined emergency event codes.

[0010] The first data field for the above emergency event may include the determined event code.

[0011] The above monitoring system may include at least one of a Driver Monitoring System (DMS) or an In-Cabin Monitoring System (ICMS).

[0012] The above message may include at least one of a Basic Safety Message (BSM) or a Cooperative Awareness Message (CAM).

[0013] The above message may be generated based on an aggregation of a first data field and at least one second data field for the emergency event.

[0014] The at least one second data field aggregated with the first data field may be determined based on urgency or importance.

[0015] The above message may include a message header containing information about the aggregation.

[0016] The above message is composed of a plurality of data fields including the first data field, and all of the plurality of data fields constituting the message may have an urgency or importance that is greater than or equal to a reference value.

[0017] Based on the fact that all of the plurality of data fields constituting the message have an urgency or importance greater than a reference value, the message can be transmitted directly from the first device to the second device.

[0018] A message comprising a plurality of data fields having an urgency or importance level lower than the above-mentioned threshold value can be transmitted to the second device via a network server or cloud.

[0019] The above first device may be a vehicle, a terminal, an RSU (road side unit), or a server.

[0020] According to one embodiment of the present disclosure, data transmission and reception in a wireless communication system can be performed more accurately and efficiently.

[0021] The effects that can be obtained in various embodiments are not limited to the effects mentioned above, and other effects not mentioned can be derived from the description below.

[0022] Figure 1 is a diagram for explaining V2X communication.

[0023] Figure 2 shows a radio protocol architecture for SL communication.

[0024] Figure 3 shows a terminal performing V2X or SL communication.

[0025] Figure 4 illustrates a flowchart of a method for transmitting a V2X message containing in-vehicle emergency / danger information using an ICMS / DMS system.

[0026] Figure 5 illustrates V2X Message Exchange using Uu-interface.

[0027] Figure 6 is a drawing for explaining the addition of header information.

[0028] Figure 7 is a diagram for explaining the V2X Message aggregation concept.

[0029] Figure 8 illustrates an example of classification of V2X Message data fields.

[0030] Figure 9 illustrates an example of distributed transmission and reception restoration of data fields of a single V2X message.

[0031] Figure 10 illustrates an example of a distributed transmission unit form of a data field of a high-importance Aggregation V2X message.

[0032] Figure 11 illustrates an example of a distributed transmission unit form of a data field of a low-importance Aggregation V2X message.

[0033] Figure 12 shows a procedure for restoring the distributed transmission and reception of data fields according to the importance of V2X messages.

[0034] FIG. 13 illustrates a flowchart of a method for transmitting data in a wireless communication system according to one embodiment.

[0035] Figure 14 illustrates a communication system applicable to the present disclosure.

[0036] Figure 15 illustrates a wireless device applicable to the present disclosure.

[0037] Figure 16 illustrates another example of a wireless device applicable to the present disclosure.

[0038] Figure 17 illustrates a vehicle or autonomous vehicle applicable to the present disclosure.

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

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

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

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

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

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

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

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

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

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

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

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

[0051] Figure 3 shows a terminal performing V2X or SL communication.

[0052] Referring to FIG. 3, the term "terminal" in V2X or SL communications 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).

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

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

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

[0056] Meanwhile, the sensor data sharing service is a service that shares surrounding environment information captured by sensors installed in vehicles and RSUs using V2X communication.

[0057] Vehicles and RSUs can expand the detection area of ​​service users by sharing information about the current driving environment (road users, obstacles, etc. that do not support V2X communication) detected by their own sensors (Radar, LiDAR, infrared, Camera, Fusion Data, etc.) and can improve traffic safety by increasing the awareness of road conditions, including blind spots.

[0058] To support sensor data sharing services using V2X communication technology, SAE International defined SDSM (Sensor Data Sharing Message) in the J3224 standard document, and the European Telecommunications Standards Institute (ETSI) defined CPM (Collective Perception Message) in the TS 103 324 standard document.

[0059] [Emergency / hazard information transmission inside the vehicle]

[0060] The vehicle interior and driver monitoring systems currently under development can be broadly divided into the Driver Monitoring System (DMS) and the In-Cabin Monitoring System (ICMS), which monitors the vehicle interior space.

[0061] Driver Monitoring System (DMS) is a technology that monitors driver behavior and attention while driving, utilizing various sensors and cameras. It typically involves in-vehicle cameras that track the driver's eye movements, head position, and facial expressions. The purpose of DMS is to detect signs of drowsiness, lack of concentration, or other risky behaviors that could lead to accidents. It can provide real-time driver warnings or enable automated safety features such as lane departure warning or adaptive cruise control.

[0062] On the other hand, ICMS is a comprehensive system that goes beyond driver monitoring. It involves monitoring the entire cabin and its occupants using cameras and sensors installed inside the vehicle. ICMS can detect and analyze a variety of factors, including occupant presence, seatbelt use, posture, and even emotional state. The goal of ICMS is to provide insight and warnings to the driver or initiate appropriate actions to enhance the safety, security, and comfort of all occupants.

[0063] DMS / ICMS systems are increasingly being integrated into modern automotive technology requirements as part of advanced driver assistance systems (ADAS) and autonomous driving technologies. They aim to improve road safety, prevent accidents, and enhance the overall driving experience by monitoring and analyzing in-vehicle behavior and conditions.

[0064] Representative use cases of DMS / ICMS systems may include (i) to (vi) below. However, various other use cases may exist in addition to (i) to (vi) below. Related technologies are continuously evolving, and new use cases are being developed to enhance safety, security, and comfort inside vehicles.

[0065] (i) Driver fatigue and distraction detection: The DMS can detect signs of drowsiness or distraction by monitoring the driver's eye movements, head position, and facial expressions. The DMS can alert the driver or activate safety features, such as seat vibration or audible warnings, to prevent accidents caused by driver fatigue or inattention.

[0066] (ii) Occupant Safety: ICMS can monitor the presence of passengers and ensure they are wearing their seat belts. It can also detect unsafe postures, such as leaning out of the window or sitting improperly. This information can be used to issue warnings or adjust safety systems, such as airbags and seatbelt tensioners, accordingly.

[0067] (iii) Child and Pet Detection: ICMS can detect the presence of children or pets left unattended in vehicles. This can alert drivers or authorities to prevent accidents or heat-related emergencies.

[0068] (iv) Security and theft prevention: ICMS can identify unauthorized individuals inside a vehicle and trigger an alarm or notify the owner. It can also detect suspicious activity or intrusions and alert the driver or authorities.

[0069] (v) Insurance and fleet management: Insurance companies and fleet managers can use DMS and ICMS data to evaluate driver behavior, identify risky patterns, and provide feedback or incentives for safe driving practices. This can help reduce accidents and insurance premiums.

[0070] (vi) Personal preference and convenience settings: ICMS can analyze driver preferences and automatically adjust various interior settings, such as seat position, temperature, and music preferences. This can enhance the overall driver experience and provide personalized comfort.

[0071] The various types of DMS / ICMS systems described above operate based on scenarios in which problems occur within the vehicle and are resolved by utilizing the available functions within the vehicle to resolve the problem.

[0072] The background of this action is that, considering the situation in which the service performed by the system is inside the vehicle, where personal information collection occurs, it is expected that the purpose is to provide safety and convenience through the service while minimizing the leakage of personal information related to the driver and passengers.

[0073] However, it is necessary to consider situations where system measures do not resolve the situation, or where the severity of the emergency / danger situation makes it difficult or impossible to prevent or minimize the leakage of collected personal information inside the vehicle and on the driver while ensuring safety and convenience. Examples of such situations include the following:

[0074] - When the driver / passenger loses consciousness and the vehicle interior and driver monitoring system cannot provide proper warnings / measures to the subject.

[0075] - If the driver / passenger intentionally ignores the application of lawful warnings / actions from the vehicle interior and driver monitoring systems.

[0076] - When an event occurs outside the vehicle (e.g., intrusion by outsiders, natural disaster, etc.) and the vehicle interior and driver monitoring system cannot provide proper warnings / measures to the affected subjects.

[0077] In situations like the above, emergency / dangerous situations must be reported through surrounding / external intervention, and the problem must be resolved through external entities or infrastructure. For this purpose, V2X messaging can be considered.

[0078] However, the transmission information of Data Frame and Data Element included in V2X messages (e.g. BSM, CAM) that transmit vehicle information developed to date does not include content collected from or related to the vehicle's internal and driver monitoring systems.

[0079] This specification proposes a method for transmitting emergency / risk information, rather than personal information, as V2X messages via the DMS / ICMS system. This allows for the notification of emergency / risk situations occurring within a vehicle to surrounding vehicles, RSUs, road operators, etc., thereby preventing / minimizing damage and enabling external intervention such as cooperation / rescue.

[0080] Below, we propose a method and implementation example for transmitting emergency / risk information, rather than personal information / privacy, as V2X messages through the DMS / ICMS system.

[0081] When the DMS / ICMS system is in operation, it collects information about the inside of the vehicle and the driver / passenger through various sensor function devices, and when the DMS / ICMS system recognizes an emergency / dangerous situation, it performs the warning / action implemented in the system.

[0082] For example, the DMS / ICMS system determines whether to include additional information in an existing V2X message being transmitted based on situational conditions such as whether to apply a warning / action, whether to terminate, etc., and activates or links with devices capable of transmitting all types of V2X messages.

[0083] Devices capable of transmitting V2X messages can generate and update V2X message Data Frame and Data Element information related to risk / emergency situations based on information determined by the DMS / ICMS system and transmit them, or if direct V2X message transmission is not possible, an external device / terminal capable of transmission can request an update of the corresponding content in the V2X message being transmitted.

[0084] 1. In-vehicle and driver monitoring system (DMS & ICMS)

[0085] A DMS / ICMS system architecture typically includes a combination of hardware and software components. A typical configuration is as follows:

[0086] (1) DMS / ICMS hardware configuration

[0087] (i) Camera: Multiple cameras can be strategically placed within the vehicle to capture the driver's face, eye movements, head position, and other relevant data. These cameras may be infrared or RGB cameras, depending on system requirements.

[0088] (ii) Sensor: Additional sensors such as audio sensors, seat occupancy sensors, seat belt sensors or temperature sensors may be included to collect more data about vehicle occupants and the environment.

[0089] (iii) Processing: May include a processor or microcontroller that handles data processing tasks such as image recognition, facial analysis, and tracking algorithms utilizing deep learning, machine learning, etc.

[0090] (iv) Connectivity: ICMS / DMS may have connectivity options supporting various communication protocols such as wired, V2X (DSRC, PC5, ITS-G5, C-V2X), Wi-Fi, Bluetooth or Cellular, mobile network to transmit data to other systems or external devices.

[0091] (2) DMS / ICMS software components

[0092] (i) Sound, image processing and analysis;

[0093] Images and video streams captured by the camera are processed using computer vision algorithms. These algorithms analyze facial features, eye movements, head position, and other relevant data to detect the driver's actions and state.

[0094] In addition to images and videos, the collected audio data can be used to detect and determine the status of drivers and passengers.

[0095] (ii) Machine learning and AI

[0096] ICMS / DMS can also use machine learning and artificial intelligence techniques to train models that can accurately identify and classify various driver states, such as fatigue, distraction, or drowsiness.

[0097] (iii) Algorithms and rules

[0098] Various algorithms and rules can be implemented to interpret data and determine the driver's condition. For example, if the driver closes their eyes for an extended period of time, they may be drowsy, triggering a warning or intervention.

[0099] For example, the algorithm and rules can determine whether to transmit a V2X message based on the situation conditions for whether to apply the type of warning / action proposed in this specification, whether to terminate, etc., and can be linked to or activate the function of a device capable of transmitting all types of V2X messages. A device capable of transmitting a V2X message can create / update / transmit V2X message Data Frame, Data Element information related to a risk / emergency situation based on information determined by the vehicle's internal and driver / passenger monitoring system, or, if V2X message transmission is impossible, can request an external device / terminal capable of V2X message transmission to create / transmit a V2X message including the corresponding information.

[0100] (iv) User interface

[0101] ICMS / DMS may have a user interface that displays real-time information about driver status, alerts, and warnings. This interface may be integrated into the vehicle's dashboard or a separate display.

[0102] (3) Integrated components

[0103] ICMS / DMS can be integrated or linked with existing vehicle systems, such as the central control unit, safety systems, and infotainment systems. This integration can enable real-time monitoring, alerts, and interaction with other vehicle functions.

[0104] ICMS / DMS architectures can vary depending on the manufacturer, system requirements, and level of integration with the vehicle. These ICMS / DMS systems can accurately monitor driver behavior and ensure safety inside the vehicle.

[0105] 2. Determining whether to send V2X message updates

[0106] Transmitting V2X message updates is one of several measures that ICMS / DMS systems can apply, and the purpose of transmitting V2X message updates is to notify surrounding vehicles, RSUs, road operators, etc. of an emergency / dangerous situation that the system vehicle is in if the emergency / dangerous situation has not ended inside the vehicle, so as to prevent / minimize damage and enable external intervention activities for cooperation / rescue, etc.

[0107] To determine whether to send a V2X message update, the system must analyze situational conditions, such as whether to apply a warning / action and whether to terminate the operation. While the criteria for determining whether to update a V2X message may vary depending on the manufacturer, system requirements, and other factors, the following are examples of criteria proposed in this specification.

[0108] - When collision / damage to surrounding road users, RSU, or other infrastructure structures is expected due to at least one of the following reasons: an emergency / dangerous situation in which the system vehicle is in, a situation in which the driver cannot drive normally, a situation in which the driving system cannot operate normally, or a driving pattern that deviates from the driver's operation or the system's intended driving pattern is detected.

[0109] - If it is determined that the emergency / dangerous situation facing the vehicle in question can only be resolved through external intervention via the road (e.g. road operator, police, medical, fire department, government / public agency, etc.)

[0110] 3. V2X message additional update Contents

[0111] Examples of emergency / dangerous situation information included in V2X messages by ICMS / DMS systems are as follows. Emergency / dangerous situation information can be added in Data Frame, Data Element Format, or added to an existing similar Data Format.

[0112] - Whether the vehicle interior and driver monitoring system is used and activated.

[0113] - Medical emergency situation

[0114] - Crime emergency situation

[0115] - Fire / explosion emergency situation

[0116] - Device failure emergency situation occurs

[0117] - Misbehavior Emergency situation occurs

[0118] - Rescue request emergency situation occurs

[0119] However, depending on future legislation and various standardization discussions, personal information may be included in emergency / risk situation information.

[0120] 4. V2X message transmission standards and methods

[0121] The V2X message standards for transmitting emergency / dangerous situation information by the ICMS / DMS system can consider BSM (Basic Safety Message, SAE), CAM (Cooperative Awareness Message, ETSI), DENM (Decentralized Environmental Notification Message, ETSI), etc., and the standard transmission method supported by the V2X message can be used as a basic method.

[0122] In addition, a transmission method using the Uu Interface should be supported, so that when commercial C-ITS services are fully implemented in the future, each V2X terminal can provide services regardless of the WAVE / 5G / LTE communication method, and a Hybrid V2X operation system should be considered.

[0123] 5. Terminate V2X message transmission

[0124] The ICMS / DMS system can also record or display the V2X message transmission status / history for the current emergency / dangerous situation using the user interface.

[0125] Example

[0126] Table 1 presents an example of adding in-vehicle emergency / hazard information to the BSM using the ICMS / DMS system. In Table 1, DE_DrivingMonitoringReport (Optional) represents the new data format added.

[0127] BSMpartIIExtension PARTII-EXT-ID-AND-TYPE ::SupplementalVehicleExtensionsDE_BasicVehicleClass OPTIONAL...DE_DrivingMonitoringReport OptionalNotInUseOrNotEquipped (0),MedicalEmergency (1), -- Medical emergency in vehicleCriminalEmergency (2), -- Criminal emergency in vehicleFireExplosiveEmergency (3), -- Fire or explosion emergency in vehicleDefectEmergency (4), -- Vehicle defect emergencyMisbehaviorEmergency (5), -- Vehicle misbehavior emergencyRescueEmergency (6), -- Rescue call emergencyregional SEQUENCE (SIZE(1..4)) OFRegionalExtension {{Reg-SupplementalVehicleExtensions}} OPTIONAL,...SpecialVehicleExtensions...VehicleSafetyExtensions...

[0128] Table 2 presents an example of adding in-vehicle emergency / hazard information to a CAM using the ICMS / DMS system. In Table 2, DE_DrivingMonitoringReport (Optional) represents the new data format added.

[0129] BasicVehicleContainerLowFrequencyDE_DrivingMonitoringReport OptionalNotInUseOrNotEquipped (0),MedicalEmergency (1), -- Medical emergency in vehicleCriminalEmergency (2), -- Criminal emergency in vehicleFireExplosiveEmergency (3), -- Fire or explosion emergency in vehicleDefectEmergency (4), -- Vehicle defect emergencyMisbehaviorEmergency (5), -- Vehicle misbehavior emergencyRescueEmergency (6), -- Call emergency in vehicleDE_VehicleRole...DE_ExteriorLights...DF_PathHistory...

[0130] In the DE_DrivingMonitoringReport in Tables 1 and 2, NotInUseOrNotEquipped indicates that the vehicle does not have an ICMS / DMS system or that it is disabled. The remaining items indicate the type of emergency / hazard situation: MedicalEmergency relates to medical situations, CriminalEmergency to criminal situations, FireExplosiveEmergency to fire situations, DefectEmergency to defect situations, MisbehaviorEmergency to malfunction situations, and RescueEmergency to rescue situations.

[0131] Figure 4 illustrates a flowchart of a method for transmitting a V2X message containing in-vehicle emergency / danger information using an ICMS / DMS system.

[0132] Referring to Fig. 4, monitoring is performed through the ICMS / DMS system in the vehicle (401).

[0133] The ICMS / DMS system can recognize / detect emergency / dangerous situations through monitoring (402).

[0134] The ICMS / DMS system can apply warnings / actions implemented / set in the ICMS / DMS system based on recognized / detected emergency / hazardous situations (403).

[0135] The ICMS / DMS system may determine whether to update and transmit the V2X message to include information about the emergency / hazard situation (404). For example, if the emergency / hazard situation facing the vehicle has not yet been resolved within the vehicle, the ICMS / DMS system may decide to update and transmit the V2X message.

[0136] The ICMS / DMS system may connect to a device capable of transmitting V2X messages or activate the transmission function based on which it decides to transmit the updated V2X message (405).

[0137] Afterwards, the ICMS / DMS system can transmit the generated V2X message (406).

[0138] [Distributed transmission for V2X message transmission efficiency]

[0139] The distributed transmission of V2X messages, which will be discussed below, can be implemented together with the transmission of information on emergency / dangerous situations through the previously proposed ICMS / DMS system, or can be implemented separately.

[0140] Figure 5 illustrates V2X Message Exchange using Uu-interface.

[0141] In V2X message exchange using the Uu Interface, message transmission paths can vary. For example, messages can be transmitted directly from a single terminal / server to a server / terminal, or messages sent by multiple terminals can be aggregated by the server and transmitted to C-V2X system components through a single or multiple servers or directly.

[0142] At this time, due to the nature of long range communication, the uplink message must be transmitted back to the endpoint via downlink according to established rules.

[0143] And at this time, a series of transmission processes occur through various Network Interface Layer structure conversions according to the basic principle of transmission and control, and as the Layer is converted from logical properties to physical properties, a series of additional information data is added. And among the information added at this time, Header information must also be added every time the Layer property is converted. An example of this process is as shown in Fig. 6, and this is the same as the additional information data that must be added when a V2X message is transmitted from a server, RSU, etc. through the Uu Interface.

[0144] The transmission cycle of V2X messages may vary depending on the type and purpose of the message, and there are messages that are broadcast periodically at all times. For example, the Basic Safety Message (BSM) is typically transmitted 10 times per second under conditions where the transmission speed is not reduced through a congestion control algorithm. The size of the V2X message may also vary depending on the type and purpose. The data field types are divided into mandatory fields that must be included and optional fields that can be optionally included, and the size may vary depending on whether the transmitted V2X message includes optional fields.

[0145] It is understood that the V2X messages (e.g. BSM, PSM, VAM) that are periodically generated from various terminals can have a data size of approximately 27 bytes (e.g. PSM, Mandatory field only) to 47 bytes (e.g. VAM, Mandatory + optional field in high frequency container) or much larger, and it is expected that these types of messages will be collected the most on the server.

[0146] In addition, the trend of C-ITS-linked data V2X message standards that are currently being used or are scheduled to be used domestically is considering a domestic standardization method of additionally defining specialized additional information for specific regions / services (e.g., weather information, national standard node link) in the Regional Extension field in addition to the already defined message fields. As such, the C-V2X transmission and reception system may need to consider a situation where the size of a single V2X message may gradually increase to reflect service requirements regardless of the transmission technology method.

[0147] When conventional V2X messages are exchanged as a single V2X message unit / individually between surrounding vehicles or VRUs through the Uu Interface in a C-V2X environment, there is a problem that congestion is greatly aggravated. For example, if the size of the V2X message is small, there may not be a problem, but if the size increases due to the inclusion of various existing data standard Contents information data fields and additional information data fields, additional information of the transmission protocol layer to process this may be added, and the amount of data that the server must process when V2X messages are transmitted at a cycle of seconds or less may increase exponentially.

[0148] As a possible solution to the issue of increasing V2X message data, a method is proposed to parse and aggregate received V2X messages into an array format and add a V2N Header containing attribute information for each message.

[0149] Figure 7 illustrates the V2X Message aggregation concept.

[0150] Referring to Figure 7, header information that should be attached to each individual message can be transmitted at once through aggregation, thereby reducing protocol headers (e.g., TCP / IP / MQTT, etc.).

[0151] However, each time it is transmitted to the server, latency occurs as much as the message transmission cycle waiting to create the array structure, and when the sizes of the received V2X messages are different, the layer where aggregation is performed may need to read the different message size information of the facility layer, which is the lower layer, to process the non-constant V2X message aggregation array size, which may cause inefficiency problems or increase the complexity of the implementation.

[0152] Even if we try to improve efficiency by using a modified form of V2X message aggregation to improve the above method, if the size of a single V2X message is large, it may be difficult to expect the effectiveness of the aggregation method itself.

[0153] In this specification, in order to improve the problems mentioned above when transmitting a large single V2X message to the server via the Uu Interface only once or transmitting it as an Aggregation in DL form, a method is proposed in which the message transmitting terminal / server classifies the data fields by distinguishing the urgency / importance of each message data information, individually distributes and transmits them in a combined form, and then restores them in the receiving terminal / server system. Through this, the efficient transmission of large V2X messages can be improved.

[0154] Figure 8 illustrates an example of classification of V2X Message data fields. Referring to Figure 8, a V2X Message includes multiple data fields, and each data field may have different urgency / importance.

[0155] In one embodiment of the present specification, a new V2N message transmission / reception method is proposed, in which data is classified by determining the urgency and importance regardless of whether the message data fields of a large size are Mandatory / Optional and are included in the message, and each message segment is combined to create it, and then the transmitting subject, the terminal / server, selects an entity / interface that matches the high urgency / importance (e.g., urgency / importance higher than a reference value) and directly downlink-transmits the corresponding message segment to the receiving terminal / server system with the highest priority, and for message segments with low urgency / importance, selects an entity / interface that matches it and transmits the corresponding message segment to another proxy receiving entity. The server transmission unit form of the proposed method may be one message segment or a combination (aggregation) of multiple message segments.

[0156] At this time, the sending server transmits message segments, consisting of metadata information necessary for message data restoration and data fields classified by importance, in single or aggregated form without using existing data specifications. The receiving terminal / server must be able to receive and acquire each message segment and restore the transmitted message data. In addition, the restored message must be completely identical to the data included in the transmitted message.

[0157] This message transmission method allows a single large message to be divided into message segments of reduced size according to urgency or importance, and information that needs to be transmitted first can be transmitted through a Uu interface-based network. In addition, information that does not require new updates for transmission according to the original data specifications in the application layer can be transmitted separately without having to transmit it all, resulting in an efficient transmission structure. In addition, since the receiving system can utilize various interfaces for receiving messages rather than relying on just one, it is possible to effectively improve the restoration of received V2X message data by utilizing the performance of the receiving terminal / server system. As another example, it can be considered that the receiving system parses message segments that were transmitted first as needed (or in urgent cases) and utilizes them for services.

[0158] Figure 9 illustrates a simple example of distributed transmission and reception restoration of data fields of a single V2X message. Referring to Figure 9, a transmitting device directly transmits Meta data #1 with high urgency / importance in a V2X message to a receiving device, and provides Meta data #2 with low urgency / importance to the receiving device via the cloud / another device. The receiving device can first receive Meta data #1 and then receive Meta data #2 to restore the original V2X message generated by the transmitting device.

[0159] 1. Transmitting server / ITS-Station

[0160] 1.1 - Determining urgency or other importance by transmission message data field

[0161] When the single size of a V2X message is limited in order to transmit directly from a single terminal / server to a terminal / server, or to aggregate single or multiple messages sent by multiple terminals and transmit the V2X message to C-V2X system components through the server or directly, it is possible to consider classifying data fields based on conditions and situations that require priority transmission by data frame field or other unit included in the V2X message.

[0162] While the criteria for determining the urgency and importance of data field information may vary depending on system conditions, service requirements, and other factors, one approach is to consider categorizing information data fields by assigning weights (%) based on high and low values, using the following attributes as baseline indicators. Furthermore, data fields can be classified by assigning weights (%) based on a combination of two or more criteria, rather than a single one.

[0163] - Urgency (volatility): When timely supply and real-time guarantees are required.

[0164] - Situational conditions: If necessary, taking into account the current situation / location of the service user (recipient).

[0165] - Data format: If it exists in the service processing request format

[0166] - Reliability: When the information is judged to be highly reliable

[0167] For example, if the Traveler Information Message (TIM) information format specification defined in C-ITS Specification Part 2: V2X Information Linking distributed by ITS-K is proposed and weights are assigned based on the urgency or importance of each data field, it can be configured in a format as in Table 3.

[0168] Table 3 shows an example of weight classification of TIM message data fields.

[0169] TravelerInformation Message Data Frame / Element DescriptionWeightmsgCntSequence number90timeStampUTC time90packetIDOther message connection ID90urlBValid Internet string type90TravelerDataFramesspTimRightsService rights90frameTypeTIMType (warning, sign, advertisement, etc.)90msgIdDetailed information about the sign appearance / location90startYearYear of message created90startTimeTimeDuration of message created (minutes)90durationTimeDuration of message created (minutes)90priorityTIMPriority of display in message90sspLocationRightsService rights90regionsDetailed geographic route information90contentDetailed event information (IT IS Code, Work zone, speed limit, sign content, exit information, etc.)90Regional (extended information field for domestic services)msgIDMessage ID90textMultipurposeField1_ExtendedDataFrame90subtextMultipurposeField2_ExtendedDataFrame40zipcodeZipcode40linkIDNodeLinkID40stopIDBusStopID40fromLaneIDBusStopStartingLaneID40toLaneIDBusStopEndingLaneID40alarmBoarding / AlightingNotification40weatherWeatherInformationsuchAsTemperature,Precipitation,Humidity,WindSpeed90serviceAreaGasStationType / PriceandOtherRelatedInformation40

[0170] 1.2 - Combining / Transmitting Urgent / Important Message Data Fields

[0171] 1.2.1 - Example of a combination of urgent / high-importance message data fields

[0172] The message data fields corresponding here can be considered as information with high priority for message transmission based on the weight value determined in Section 1.1.

[0173] First, by combining message information data fields deemed critical for transmission with metadata information required for message data recovery, a message segment structure can be constructed that does not utilize existing data standards. While the metadata information may vary depending on the communication system or protocol used, the following information may be considered.

[0174] - Total number of MSG Segments: Total number of message segments

[0175] - Total number of MSG Aggregation: Number of Message Aggregations

[0176] - The sequence of MSG Segments: Current message segment sequence information

[0177] - MSG Segments ID: Current message segment ID

[0178] - V2X Message Type (Message ID): V2X message type (e.g. BSM, PSM, TIM … …)

[0179] - V2X Message Version Info: V2X message distribution version used

[0180] - The Access Info of the next MSG Segments: Information on requesting acquisition of the next message segment

[0181] For example, when utilizing Table 3 (example of weight classification of TIM message data fields), a combination of data fields with high importance can be configured in a form as shown in Table 4. Table 4 shows an example of weight classification of TIM message data fields that require priority transmission.

[0182] TravelerInformation Message Data Frame / Element DescriptionWeightMeta DataTotal number of MSG SegmentsTotal number of message segments100Total number of MSG AggregationsNumber of message aggregations (if 2 or more, considered as message aggregation)100The sequence of MSG SegmentsCurrent message segment sequence information100MSG Segments IDCurrent message segment ID100V2X Message Type (Message ID)V2X message type (e.g. BSM, PSM, TIM...)100V2X Message Version InfoV2X message distribution version in use100The Access Info of the next MSG SegmentsRequest to acquire the next message segment100msgCntSequence number90timeStampUTC time90packetIDOther message connection ID90urlBValid internet string type90TravelerDataFramesspTimRightsService rights90frameTypeTIMType (warning, sign, advertisement) etc.)90msgIdDetailed information about the sign appearance / location90startYearYear of the message created90startTimeTime of the message created (minutes)90durationTimeDuration of the message created (minutes)90priorityTIMPriority of display in the message90sspLocationRightsService rights90regionsDetailed information about geographic routes90contentDetailed information about events (IT IS Code, Work zone, speed limit, sign content, exit-related information, etc.)90Regional(Extended information field for domestic service)msgIDMessage ID90textMultipurpose field1_Extended data frame90weatherWeather information such as temperature, rainfall, humidity, and wind speed90

[0183] 1.2.2 - Example of transmitting urgent / high-importance message data fields

[0184] The server, which is the transmission entity, must be able to directly downlink the classified message segments to the receiving terminal / server system with the highest priority using the Uu interface in order to match the high urgency / importance.

[0185] The unit format transmitted by the server can be a single message segment or a combination of multiple message segments (aggregation).

[0186] Referring to Fig. 10, an exemplary embodiment of a transmission unit for Aggregation message Segments will be described. Fig. 10 illustrates an example of a data field distribution transmission unit form of a high-importance Aggregation V2X message. The transmitting server / terminal can determine Meta data #1 with high urgency / importance and Meta data #2 with low urgency / importance from each of V2X messages 1, 2, and 3, and perform segmentation. The transmitting server / terminal can select Meta data #1 with high urgency / importance from each of V2X messages 1, 2, and 3, compose a new message, and add a message header to the newly composed message. The transmitting server / terminal can transmit the message with the added message header to the receiving terminal / server.

[0187] Message headers can include information about urgency / importance and V2X message segmentation. That is, the data structure must include header information to distinguish between multiple combined message segments. For example, the following information can be included in the header field:

[0188] - Total number of MSG Aggregation: Number of Message Aggregations (if there are 2 or more, they are considered Message Aggregation)

[0189] - Number of Message segments: Total number of message segments

[0190] - Message segments Offset - 1st (2nd, 3rd …): The offset point position of the corresponding message segment

[0191] - Message segments Length - 1st (2nd, 3rd …): Size of the corresponding message segment length

[0192] 1.3 - Combining / Transmitting Urgent / Low Importance Message Data Fields

[0193] 1.3.1 - Example of combining urgent / low-importance message data fields

[0194] The message data fields corresponding here may be considered as information with low priority for message transmission based on the weight value determined in Section 1.1.

[0195] By combining message information data fields corresponding to low importance and metadata information required for message data restoration, a message segment structure can be constructed that does not use existing data standards.

[0196] For example, when using Table 3 (example of weight classification of TIM message data fields), a combination of data fields with low importance can be configured in the following form.

[0197] Table 5 shows an example of a weighted classification of TIM message data fields that require priority transmission.

[0198] TravelerInformation Message Data Frame / Element DescriptionWeightMeta DataTotal number of MSG Segments100Total number of MSG AggregationsMessage Aggregation count (when 2 or more, considered as Message Aggregation)100The sequence of MSG SegmentsCurrent message segment sequence information100MSG Segments IDCurrent message segment ID100V2X Message Type (Message ID)V2X message type (e.g. BSM, PSM, TIM ...)100V2X Message Version InfoV2X message distribution version used100Regional (extended information field for domestic service)subtextMultipurpose field2_extended data frame40zipcodeZIP code40linkIDNode link ID40stopIDBus stop ID40fromlaneIDBus stop starting lane ID40tolaneIDBus stop ending lane ID40alarmBoarding / alighting notification40service areaGas station fuel type / price and other related Information 40

[0199] 1.3.2 - Example of transmitting low-urgency / low-importance message data fields

[0200] The terminal / server, which is the transmitting entity, must be able to selectively transmit the corresponding message segment by selecting the entity / interface that the receiving system may prefer.

[0201] Here, the same as the transmission of the high-priority message data field data, it can be transmitted directly to the receiving terminal / server system via downlink at regular intervals, or the message segment information can be uploaded to an external cloud or server environment, and then the receiving system can directly request and acquire the message segment by using metadata to obtain the message segment through the request information.

[0202] Methods utilizing these servers can include leveraging message brokers or Open APIs. For example, the message segment acquisition request information data field may include the following information:

[0203] - External Cloud, server IP address, port number, topic information, message protocol type, distribution version

[0204] - Opan API call data link, call specifications, call method, etc.

[0205] The unit format transmitted by the server can be a single message segment or a combination of multiple message segments (aggregation), as in Section 1.2.2.

[0206] Referring to Fig. 11, an exemplary transmission unit embodiment for Aggregation message Segments will be described. Fig. 11 illustrates an example of a data field distribution transmission unit form of a low-importance Aggregation V2X message. The transmitting server / terminal can determine Meta data #1 with high urgency / importance and Meta data #2 with low urgency / importance from each of V2X messages 1, 2, and 3, and perform segmentation. The transmitting server / terminal can select Meta data #2 with low urgency / importance from each of V2X messages 1, 2, and 3, compose a new message, and add a message header to the newly composed message. The transmitting server / terminal can transmit the message with the added message header to the receiving terminal / server. The message header can include information about urgency / importance and information about V2X message segmentation. For example, as in Section 1.2.2, header information for distinguishing information from multiple combined message segments may be included in the data structure.

[0207] 1.4 - Generating a unique Magic Key value for the original V2X message

[0208] In the above manner, the transmitting server / terminal can classify data fields by urgency / importance and transmit the corresponding message in a distributed manner. In order to determine whether the restored V2X message by the receiving server / terminal matches the original V2X message, the original V2X message data can be used to generate unique information, such as a Magic Key. When the receiving terminal / server transmits the generated Magic Key Value after restoring the V2X message to the transmitting server, the transmitting server can compare the Magic Key Value it generated with the received Magic Key Value and transmit the result to the receiving terminal / server.

[0209] For example, a transmitting server / terminal can issue a Hash code generated using the corresponding V2X message data, and then compare it with the Hash Code generated by restoring the message at the receiving terminal / server.

[0210] 2. Receiving server / terminal (ITS-Station)

[0211] 2.1 - Receiving / Parsing Urgent / High Importance Message Data Field Information

[0212] When the number of received message units is 1, the receiving server / terminal can use the information contained in the metadata field to parse. When the number of received message units is 1, the receiving server / terminal can use the metadata field and header information to parse. For example, the original V2X message can be restored by parsing data from the message segment through the following procedure.

[0213] (1) When there is one message unit

[0214] - Check the total number, current part order, and unique ID from the metadata of the received message segment.

[0215] - Check the original V2X message type and distribution version information from the metadata of the received message segment.

[0216] - Check data specifications based on V2X message type and distribution version information, and input the received message data field name and value by parsing them according to the specifications.

[0217] (2) When the message unit is multiple Aggregations

[0218] - Check the total number of message segments, offset delimiter, and length size from the header of the received message segment, and move to the Nth message segment.

[0219] - Check the total number, current part order, and unique ID from the metadata of the received message segment.

[0220] - Check the original V2X message type and distribution version information from the metadata of the received message segment.

[0221] - Check data specifications based on V2X message type and distribution version information, and input the received message data field name and value by parsing them according to the specifications.

[0222] - When parsing is complete, move to the N+1th message segment.

[0223] 2.2 - Receiving / Parsing Information on Low-Urgency / Low-Importance Message Data Fields

[0224] If the receiving terminal / server system receives directly from the transmitting server / terminal at regular intervals, parsing can be performed using the contents and examples defined in Section 2.1.

[0225] If you need to check the information in the data field of the next message segment acquisition request information by referring to the metadata included in the previously received high-priority message segment from the sending server / terminal, you can use the Subscribe function of the message broker of the proxy receiving entity (e.g., Cloud, On-Premise server, etc.) by referring to the checked information, or you can use an Open API request to receive the remaining low-priority message segments.

[0226] For example, the original V2X message can be restored by parsing data from the message segment using the following procedure.

[0227] (1) When there is one message unit

[0228] - Check the request information for acquiring the next message segment from the metadata of the first received message segment.

[0229] - Receive low-importance message segment after requesting message segment acquisition

[0230] - Check the total number, current part order, and unique ID from the metadata of the received message segment.

[0231] - Check the original V2X message type and distribution version information from the metadata of the received message segment.

[0232] - Check data specifications based on V2X message type and distribution version information, and input the received message data field name and value by parsing them according to the specifications.

[0233] (2) When the message unit is multiple Aggregations

[0234] - First, check the request information for acquiring the remaining Aggregation Message Segments from the metadata of the entire Aggregation Message Segment received.

[0235] - Receive low-priority full message segments after requesting acquisition of remaining Aggregation message segments.

[0236] - Check the total number of message segments, offset delimiter, and length size from the header of the received message segment, and move to the Nth message segment.

[0237] - Check the total number, current part order, and unique ID from the metadata of the received message segment.

[0238] - Check the original V2X message type and distribution version information from the metadata of the received message segment.

[0239] - Check data specifications based on V2X message type and distribution version information, and input the received message data field name and value by parsing them according to the specifications.

[0240] - When parsing is complete, move to the N+1th message segment.

[0241] 2.3 - Verifying message data is restored

[0242] The receiving terminal / server receives and acquires each message segment, parses the transmitted message data, and when the restoration process is complete, it generates a Magic Key using the restored V2X message as described in Section 1.4 and transmits it to the transmitting server. Examples of the Magic Key include hash code generation, as in the example in Section 1.4, and the transmitting server / terminal must transmit the Magic Key verification result to the receiving terminal / server to notify it of the success / failure of the transmission.

[0243] If the restoration result is a failure, the receiving server / terminal system must also transmit the restoration and reception failure results to the sending server / terminal.

[0244] In the case where a mobile-based V2X service using the Uu Interface uses a C-ITS-based service from an RSU, or multiple users use a V2V service or V2P (Pedestrian) service between V2X terminals, the proposed message transmission method can improve server-terminal (server) transmission efficiency.

[0245] Figure 12 shows a procedure for restoring the distributed transmission and reception of data fields according to the importance of V2X messages.

[0246] Referring to FIG. 12, the transmitting server / terminal can determine at least one V2X message to transmit (1201).

[0247] The transmitting server / terminal can determine the urgency / importance for each data field of at least one V2X message decided to be transmitted (1202).

[0248] A transmitting server / terminal can transmit a message composed of data fields with high urgency / importance to a receiving server / terminal (1203). The receiving server / terminal can parse the message composed of data fields with high urgency / importance (1204).

[0249] Thereafter, the transmitting server / terminal can directly / indirectly transmit a message composed of data fields with low urgency / importance to the receiving server / terminal (1205). The receiving server / terminal can parse the message composed of data fields with low urgency / importance (1206).

[0250] Meanwhile, the transmitting server / terminal can generate a unique Magic Key value for the original V2X message before it is reconstructed according to urgency / importance, i.e., at least one V2X message that was decided to be transmitted in 1201 (1207).

[0251] The receiving server / terminal can restore at least one V2X message based on parsing (1204) / parsing (1206), and check / verify the restoration of message data based on the Magic Key (1208). The receiving server / terminal can transmit the Magic Key for the restored V2X message to the transmitting server / terminal. The transmitting server / terminal can compare the received Magic Key with the Magic Key it generated to verify whether the V2X message restoration of the receiving server / terminal was performed correctly, and notify the receiving server / terminal of the result.

[0252] FIG. 13 illustrates a flowchart of a method for transmitting data in a wireless communication system according to one embodiment.

[0253] Referring to FIG. 13, a first device related to a vehicle according to one aspect can obtain monitoring data on a user of the vehicle and an environment inside the vehicle through a monitoring system including at least one of a camera or a sensor (1301).

[0254] The first device can detect an emergency event related to the user's safety based on the monitoring data (1302).

[0255] The first device may generate a message (1303) including a first data field for the detected emergency event. The generation of the message may include a preprocessing step for excluding monitoring data related to the user's personal information from the first data field for the emergency event.

[0256] The first device can transmit the generated message to the second device (1304).

[0257] The above pre-processing step may include determining an event code for the detected emergency event from among a plurality of predefined emergency event codes.

[0258] The first data field for the above emergency event may include the determined event code.

[0259] The above monitoring system may include at least one of a Driver Monitoring System (DMS) or an In-Cabin Monitoring System (ICMS).

[0260] The above message may include at least one of a Basic Safety Message (BSM) or a Cooperative Awareness Message (CAM).

[0261] The above message may be generated based on an aggregation of a first data field and at least one second data field for the emergency event.

[0262] The at least one second data field aggregated with the first data field may be determined based on urgency or importance.

[0263] The above message may include a message header containing information about the aggregation.

[0264] The above message is composed of a plurality of data fields including the first data field, and all of the plurality of data fields constituting the message may have an urgency or importance that is greater than or equal to a reference value.

[0265] Based on the fact that all of the plurality of data fields constituting the message have an urgency or importance greater than a reference value, the message can be transmitted directly from the first device to the second device.

[0266] A message comprising a plurality of data fields having an urgency or importance level lower than the above-mentioned threshold value can be transmitted to the second device via a network server or cloud.

[0267] The above first device may be a vehicle, a terminal, an RSU (road side unit), or a server.

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

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

[0270] Fig. 14 illustrates a communication system applicable to this embodiment.

[0271] Referring to FIG. 14, a communication system (1) applicable to the present embodiment 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.

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

[0273] 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 disclosure.

[0274] Figure 15 illustrates a wireless device applicable to the present disclosure.

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

[0276] 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 this specification, wireless device may also mean a communication modem / circuit / chipset.

[0277] Specifically, the UE may include a processor (102) and a memory (104) connected to the RF transceiver. The memory (104) may include at least one program capable of performing operations related to the embodiments described in FIGS. 14 to 27.

[0278] Alternatively, a chipset may be configured that includes a processor (102) and a memory (104). In this case, the chipset may include at least one processor and at least one memory operably connected to the at least one processor and, when executed, causing the at least one processor to perform operations.

[0279] 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 this specification, a wireless device may also mean a communication modem / circuit / chip.

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

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

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

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

[0284] Figure 16 illustrates another example of a wireless device applicable to this embodiment. The wireless device may be implemented in various forms depending on the use case / service (see Figure 27).

[0285] Referring to FIG. 16, the wireless device (100, 200) corresponds to the wireless device (100, 200) of FIG. 15 and may be composed of various elements, components, 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. 16. For example, the transceiver(s) (114) may include one or more transceivers (106, 206) and / or one or more antennas (108, 208) of FIG. 15. 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).

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

[0287] In FIG. 16, 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 one or more processor sets. For example, the control unit (120) may be composed of a set of a communication control processor, an application processor, an electronic control unit (ECU), a 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.

[0288] Figure 17 illustrates a vehicle or autonomous vehicle applicable to this embodiment. The vehicle or autonomous vehicle may be implemented as a mobile robot, car, train, manned / unmanned aerial vehicle (AV), ship, etc.

[0289] Referring to FIG. 17, 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. 15, respectively.

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

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

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

[0293] The embodiments described above are combinations of components and features of the present disclosure 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 embodiments of the present disclosure by combining some components and / or features. The order of operations described in the embodiments of the present disclosure 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 embodiments or incorporated as new claims through post-application amendments.

[0294] In this document, the embodiments of the present disclosure 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 a fixed station, a Node B, an eNode B (eNB), an access point, etc. The terminal may also be replaced by terms such as a User Equipment (UE), a Mobile Station (MS), or a Mobile Subscriber Station (MSS).

[0295] Embodiments according to the present disclosure 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 disclosure 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.

[0296] When implemented via firmware or software, one embodiment of the present disclosure may be implemented in the form of a module, procedure, function, or the like that performs 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.

[0297] It will be apparent to those skilled in the art that the present disclosure may be embodied in other specific forms without departing from the technical features described herein. 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.

[0298] The embodiments of the present disclosure as described above can be applied to various devices of an intelligent transportation system.

Claims

1. In a method for transmitting data by a first device related to a vehicle in a wireless communication system, Obtaining monitoring data about the user of the vehicle and the environment inside the vehicle through a monitoring system including at least one of a camera or a sensor; Detecting an emergency event related to the user's safety based on the above monitoring data; Generate a message including a first data field for the detected emergency event; and Including transmitting the generated message to a second device, The creation of the above message is: A method comprising a pre-processing step for excluding monitoring data related to personal information of the user from the first data field for the above emergency event.

2. In paragraph 1, The above preprocessing step includes determining an event code for the detected emergency event among a plurality of predefined emergency event codes, A method wherein the first data field for the above emergency event includes the determined event code.

3. In paragraph 1, The above monitoring system includes at least one of a Driver Monitoring System (DMS) or an In-Cabin Monitoring System (ICMS), A method wherein the above message includes at least one of a Basic Safety Message (BSM) or a Cooperative Awareness Message (CAM).

4. In paragraph 1, The message is generated based on an aggregation of a first data field and at least one second data field for the emergency event, A method wherein at least one second data field aggregated with the first data field is determined based on urgency or importance.

5. In paragraph 4, A method wherein the message comprises a message header containing information about the aggregation.

6. In paragraph 1, The above message is composed of a plurality of data fields including the first data field, A method wherein all of the plurality of data fields constituting the above message have an urgency or importance greater than a reference value.

7. In paragraph 1, A method in which the message is transmitted directly from the first device to the second device based on all of the plurality of data fields constituting the message having an urgency or importance greater than a reference value.

8. In paragraph 7, A method in which a message composed of a plurality of data fields having an urgency or importance level lower than the above-mentioned reference value is transmitted to the second device via a network server or cloud.

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

10. In a first device related to a vehicle in a wireless communication system, memory that stores commands; and A processor that performs operations by executing the above instructions, The operations of the above processor are: Obtaining monitoring data about the user of the vehicle and the environment inside the vehicle through a monitoring system including at least one of a camera or a sensor; Detecting an emergency event related to the user's safety based on the above monitoring data; Generate a message including a first data field for the detected emergency event; and Including transmitting the generated message to a second device, The creation of the above message is: A first device comprising a pre-processing step for excluding monitoring data related to personal information of the user from the first data field for the above emergency event.

11. In paragraph 10, The first device is a first device that is a vehicle, a terminal, an RSU (road side unit) or a server.

12. In paragraph 10, The above preprocessing step includes determining an event code for the detected emergency event among a plurality of predefined emergency event codes, A first device, wherein the first data field for the above emergency event includes the determined event code.

13. In paragraph 10, The above monitoring system includes at least one of a Driver Monitoring System (DMS) or an In-Cabin Monitoring System (ICMS), A first device, wherein the above message includes at least one of a Basic Safety Message (BSM) or a Cooperative Awareness Message (CAM).

14. In paragraph 10, The message is generated based on an aggregation of a first data field and at least one second data field for the emergency event, A first device, wherein at least one second data field aggregated with the first data field is determined based on urgency or importance.

15. In paragraph 14, A first device, wherein the message comprises a message header containing information about the aggregation.

Images