Method for data processing in intelligent transportation system, and device for performing same

Abstract

A method by which a first network node transmits information to a second network node in an intelligent transportation system (ITS), according to various embodiments, may comprise: processing information on first objects moving in a first area monitored by the first network node; on the basis of the processing result, obtaining first prediction information on a processing load expected to be caused by the first objects in a second area at least partially contacting the first area; and transmitting the first prediction information to the second network node monitoring the second area.

Description

Method for data processing in intelligent transportation systems and device for performing the same

[0001] This specification relates to an intelligent transport system (ITS), and more specifically, to a method for processing data related to a moving object in an intelligent transport system and a device for performing the same.

[0002] Edge computing is a key topic in vehicle-to-everything (V2X) use cases, as many ultimately require low latency and high reliability. These use cases process and transmit large amounts of data from nearby local computing resources, rather than connecting to remote cloud services over the Internet. This enables efficient, large-scale data processing. Multi-access Edge Computing (MEC), used for this purpose, is a general framework that enables MEC applications to be implemented as software-only entities running on virtualized infrastructure located at or near the network edge.

[0003] Future MEC-based V2X services will need to ensure availability across all time and conditions. This requires sufficient MEC resources to be allocated in a timely manner to meet computing resource requirements. Failure to do so could pose significant risks when using MEC-based V2X services in safety-related solutions. Furthermore, MEC resource allocation should be designed to minimize the operating costs associated with idle resources from an economic perspective.

[0004] The MEC architecture for V2X services will be Server-MEC-Client, rather than the traditional Server-Client architecture. The Server here refers to a Far Server or remote server, and the MEC can be a Near Server or a hybrid cloud architecture that combines an on-premise architecture with a multi-cloud. For governments, public institutions, and others that require critical data management, certain types of data must be stored on physical servers rather than in the cloud. In this case, a hybrid cloud architecture allows the use of public clouds for workflows other than data management. It prevents the exposure of servers requiring high security, and users can benefit from Auto-Scaling (a service that automatically adjusts server size by monitoring the values ​​of system resources such as CPU, memory, disk, and network traffic) or dynamically allocate resources. This allows users to effectively respond to unexpected service loads and achieve cost savings.

[0005] In terms of MEC-based V2X services, the key variables to consider for predicting dynamic resource allocation are the number of Connected Objects that need to be connected or processed by MEC, and the variability of this demand mainly occurs when vehicles move from one area to another over time, reflecting the overall traffic density that varies both spatially and temporally.

[0006] Considering the variables above, dynamic resource allocation is based on the accuracy of the number of objects that need to be analyzed for V2X service, and it takes approximately several minutes (e.g., 10 minutes) to apply the scale up / down of computing resources to reflect the derived results. Therefore, rather than a real-time resource allocation (reactive allocation) method, a resource allocation technology that predicts the number of objects that need to be connected or processed in advance using a machine learning algorithm and monitors the service status to respond proactively is required.

[0007] MEC-based V2X service environments must allocate resources and deploy services based on location information to reduce transmission delay. For example, configuring service chains with computing resources in different locations can lead to performance issues. Therefore, MEC / RSU computing environments for V2X services should be structured into short-range service clusters based on location, and service flows entering a cluster should be guided to receive services within the same cluster as much as possible. If a service function cannot be performed within the same cluster, resources should be allocated to the closest cluster to enable handover of service flows.

[0008] The above-mentioned behavior is currently being developed as a standardization of the Mobile Edge Computing (MEC) framework by the European Telecommunications Standards Institute (ETSI), which adds edge computing capabilities to 5G mobile communication systems. Referring to Figure 1, the MEC framework can be divided into general entities such as system-level MEC entities, host-level MEC entities, and network-level MEC entities.

[0009] Here, the Host level MEC entity consists of the MEC platform manager and the virtualization infrastructure manager, and the virtualization infrastructure manager is responsible for the following functions: (i) allocating, managing, and releasing virtualized (compute, storage, and networking) resources of the virtualization infrastructure; (ii) preparing the virtualization infrastructure for software image execution: preparation includes infrastructure configuration and may include receiving and storing the software image; (iii) collecting and reporting performance and error information about the virtualized resources; and (iv) performing application relocation when supported: for application relocation to and from an external cloud environment, the virtualization infrastructure manager interacts with the external cloud manager to perform application relocation.

[0010] In this way, MEC-based V2X services are performed on a basis that provides support for functional operations such as virtualization infrastructure managers, and in this process, dynamic allocation and release of computing resources may occur frequently.

[0011] The technical challenge is to perform more accurate and efficient data processing related to moving objects in intelligent transportation systems (ITS).

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

[0013] A method for transmitting information from a first network node to a second network node in an intelligent transportation system (ITS) according to one aspect may include: processing information about first objects moving in a first area monitored by the first network node; obtaining, based on a result of the processing, first prediction information about a processing load expected to be caused by the first objects in a second area at least partially adjacent to the first area; and transmitting the first prediction information to the second network node monitoring the second area.

[0014] The first network node can receive second prediction information from the second network node.

[0015] The second prediction information may be about a processing load that second objects moving in the second area are expected to cause in the first area.

[0016] Based on the second prediction information, the processing resources of the first network node can be adjusted.

[0017] The above processing resources may include at least one of a central processing unit (CPU), random access memory (RAM), network speed, or storage access speed for cloud computing.

[0018] The processing load that the second objects are expected to cause in the first area can be calculated based on at least one of the position, direction, speed, or detection priority of each of the second objects obtained through the second prediction information.

[0019] The above first prediction information may relate to a processing load that the first objects are expected to cause within a time period less than a threshold from the present.

[0020] The above first objects may include at least one of a terminal, a vehicle, or a road side unit (RSU) moving in the first area.

[0021] Monitoring of the first area by the first network node may be disabled based on the fact that no first event related to object detection has occurred in the first area for a certain period of time.

[0022] The first network node can receive sensing information related to the first area from an external device after the monitoring of the first area is disabled.

[0023] Based on the detection of a second event through the sensing information, monitoring of the first area by the first network node can be resumed.

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

[0025] According to another aspect, a first network node operating in an intelligent transportation system (ITS) includes a memory storing instructions; and a processor performing operations by executing the instructions, wherein the operations of the processor may include processing information about first objects moving in a first area monitored by the first network node; obtaining, based on a result of the processing, first prediction information about a processing load expected to be caused by the first objects in a second area at least partially adjacent to the first area; and transmitting the first prediction information to the second network node monitoring the second area.

[0026] The first network node may be a server that monitors a terminal, vehicle, or road side unit (RSU) moving in the first area.

[0027] According to one embodiment of the present disclosure, data processing for moving objects in an intelligent transportation system (ITS) can be performed more accurately and efficiently.

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

[0029] Figure 1 illustrates an example of a structure for MEC (Mobile Edge Computing).

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

[0031] Figure 3 shows a radio protocol architecture for SL communication.

[0032] Figure 4 shows a terminal performing V2X or SL communication.

[0033] Figure 5 is a diagram for explaining the performance of general Auto Scaling.

[0034] Figure 6 illustrates an example of sharing the entire object status monitoring metric structure.

[0035] Figure 7 illustrates the overall object status monitoring Metric database structure.

[0036] Figure 8 illustrates a prediction object status monitoring metric structure.

[0037] Figure 9 illustrates the structure of a prediction object status monitoring metric database.

[0038] Figure 10 illustrates the moving average value versus the number of occurrence objects.

[0039] Figures 11 and 12 are examples of cases where the number of objects is increasing enough to reduce the load compared to the maximum number of objects currently allowed by the computing resources.

[0040] Figure 13 illustrates data processing based on load prediction for moving objects.

[0041] Figure 14 illustrates detection data including video.

[0042] Figure 15 illustrates a method for a first network node to transmit information to a second network node in an intelligent transportation system (ITS).

[0043] Figure 16 illustrates a communication system applicable to the present disclosure.

[0044] Figure 17 illustrates a wireless device applicable to the present disclosure.

[0045] Figure 18 shows another example of a wireless device applicable to the present disclosure.

[0046] FIG. 19 illustrates a vehicle or autonomous vehicle applicable to the present disclosure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0061] Figure 4 shows a terminal performing V2X or SL communication.

[0062] Referring to FIG. 4, 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).

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

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

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

[0066] Predicting the processing load required between infrastructure areas due to object terminal movement

[0067] This paper describes the MEC / RSU Dynamic Resource Management information and application method for predicting the processing load required between infrastructure areas due to movement of V2X object terminals.

[0068] In order to identify factors that may affect the load, the RSU / MEC must analyze the dynamic status information (number, location, speed, etc. of moving service request objects and services being processed (e.g. object detection, message exchange, event warning notification, etc.)) of all V2X service objects currently occurring in its own RSU / MEC sensing / cluster area or objects predicted to be moving to adjacent areas within a short period of time, to create a categorized visual metric information structure, update it in real time, and share it in real time with adjacent surrounding RSU / MECs.

[0069] The RSU / MEC derives the total number and movement trend of objects passing through the point (boundary, certain distance outside the boundary) expected to move into its area from the adjacent surrounding RSU / MECs from the shared Metric table information and reflects this in the system Metric index of the RSU / MEC Auto-Scale Platform for monitoring the Auto-Scaling execution conditions.

[0070] During monitoring, in response to system metrics exceeding certain thresholds, Auto Scaling dynamically increases or decreases server instance resources in advance by setting the desired change compute resource capacity (or minimum and maximum sizes as the case may be) as a policy of the current RSU / MEC Auto-Scale Platform.

[0071] 1. System Metric for determining general Auto-Scaling occurrence criteria

[0072] Auto-Scaling (Auto Scaling) is a technology that monitors the system metric values, which are cloud resource usage information for system resources such as CPU, memory, disk, and network traffic, and automatically adjusts the server size when the system metric values ​​of a virtual server included in an Auto-Scaling group exceed a specified threshold.

[0073] Examples of system metric indicators for determining the criteria for auto-scaling occurrence are shown in Table 1.

[0074] Monitoring Items Detailed Item Criteria Example CPU Usage (%) When load reaches 60%, Scale-Out. When less than 40%, Scale-In RAM Usage (%) When load reaches 60%, Scale-Out. When less than 30%, Scale-In Network In / Out (Bytes or Packets) When each processed packet exceeds 1 Gbps, Scale-Out. When less than 100 Mbps, Scale-In Disk I / O Read / Write (Bytes or Operation) When each access exceeds 100,000,000, Scale-Out. When less than 1,000, Scale-In Average Load Maintenance Time Minutes, Hours When continuous for 10 minutes or more, Scale-Out. When load occurs 4 or more times, Scale-Out.

[0075] CPU utilization can be measured as a percentage, while network utilization can be determined by the number of bytes input / output or packet size. Additionally, the average load maintenance period can be set to, for example, 5, 10, or 15 minutes. Disk performance metrics can be measured not by percentage, but by the number of bytes actually read and written to disk and the number of disk access operations, providing a basis for precise performance evaluation.

[0076] There are two types of auto-scaling methods: auto-scale up / down and auto-scale in / out. Auto-scale up / down refers to upgrading (downgrading) existing computing servers to higher (lower) specifications (e.g. adding (removing) disks to servers or upgrading / downgrading CPUs or memory) (i.e. vertical scaling), and auto-scale in / out refers to improving (downgrading) performance by additionally adding (removing) servers with similar specifications to the existing computing servers to share the data capacity and load that can be processed (i.e. horizontal scaling).

[0077] For simple speed and accuracy improvements, the auto-scale up / down method that simply adjusts specifications may be effective, but in application environments that require analytical processing such as object detection or machine learning, the auto-scale in / out configuration may be effective because a significant amount of data processing and complex queries occur.

[0078] This auto-scale configuration essentially involves a Load Balancer, which is responsible for distributing incoming service requests to multiple servers within the computing resources.

[0079] Recently, various vendor platforms (e.g., Amazon Web Service, Google Cloud Platform, Microsoft Azure) that provide cloud service functions provide such Auto-Scaling, and when you set an Auto-Scaling policy using the resource management function, this policy is applied to the allocated cloud servers, and if the system metric value is below the threshold for a certain period of time, the number of servers is kept to a minimum, and when a load occurs, the number is increased to the maximum to implement a stable and flexible service.

[0080] When an Auto-Scaling request occurs, the cloud infrastructure allocates additional resources based on your configured policies and configuration. This process typically takes several minutes, during which time existing resources can continue to be used. Once the new resources are allocated, the application or system begins using them to handle the increased workload. New resources can be added incrementally or in batches, depending on the policies and implementation details. The exact behavior of Auto-Scaling may vary depending on the specific implementation and the cloud provider used. For more information on how Auto-Scaling works in your environment, please refer to the documentation and support resources provided by your cloud provider.

[0081] Figure 5 is a diagram for explaining the performance of general Auto Scaling.

[0082] Referring to Figure 5, Auto Scaling can be performed as follows.

[0083] 0) Set Auto Scaling Policy - Specifies the desired change compute resource capacity (or minimum and maximum size, as the case may be) through Auto Scaling in response to a system metric exceeding a certain threshold.

[0084] 1) Collects network information of Load Balancer and system resource metric indicator information of server as monitoring service at specific intervals.

[0085] 2) If something is detected that exceeds the threshold conditions specified in the monitoring service set in Step 0 (e.g., above / below / exceeds / below), the Auto-Scaling policy is initiated.

[0086] 3) Increase or decrease the number of virtualized server instances (increase / decrease ratio algorithm varies depending on the service support vendor)

[0087] 4) Start the server instance allocation task that matches the set policy setting value. Typically, the image shape SPEC is set to the same as the current computing resource for fast provisioning allocation.

[0088] 5) Verify that the instances associated with the Auto Scaling group are functioning properly. This includes checking whether the instances exist and are accessible (e.g., HTTP Ping Test, 200 OK response, etc.) or whether the instances exist and are serving with the associated Load Balancer.

[0089] 6) Once the server status check is complete, add the server to the Load Balancer and start processing request traffic in the same way as other servers.

[0090] 2. Reflection of the number of sensing / clustering objects in the current RSU / MEC system metric

[0091] 2.1 Count the number of objects moving in a short period of time that can affect the load.

[0092] As mentioned above, the main variable to consider for predicting dynamic resource allocation in terms of MEC-based V2X services is the number of Connected Objects that are connected to or need to be processed by the MEC. Here, Connected Objects refer to terminal devices capable of exchanging V2X messages based on Short / Long Range communication, or objects that carry functions (e.g., vehicles, scooters, bicycles, kickboards, pedestrians, etc.) that are currently receiving services from the RSU / MEC or are expected to receive services soon. These Connected Objects can be recognized as objects by the MEC / RSU not only through V2X message exchange based on Short / Long Range communication, but also through data fusion between information sensed using the object detection function equipped in the RSU / MEC and V2X messages. However, if the matching rate between the movement and status information included in the V2X messages of these objects and the movement and status information sensed through the object detection function is below or below the standard value set by the system, they may not be included in the load factor due to low accuracy.

[0093] While not as critical as Connected Objects, the number of Unconnected Objects that can impact the service purpose and type of the MEC / RSU can also be considered. While these Unconnected Objects do not have the ability to exchange information with the RSU / MEC, they can utilize V2X messages generated by neighboring Connected Objects sensing them, or information sensed using the object detection function of the RSU / MEC. This information is then relayed to the MEC / RSU and recognized as an object (e.g., vehicle, scooter, bicycle, kickboard, pedestrian, etc.).

[0094] In summary, in order to identify the main factors affecting the MEC / RSU load, current statistical data such as V2X messages based on Short / Long Range communication of Connected Objects in the current MEC / RSU area, object detection sensing results, V2X messages created based on sensed information of Unconnected Objects, and object detection sensing results must be transmitted to the adjacent MEC / RSU. However, providing the entire aggregated statistical data in this way may require excessive data size, so it should be possible to visually structure the metrics by classifying them based on measured values ​​such as the total number of Connected Objects and Unconnected Objects for service processing, service priority, location, direction, and movement speed, and grouping them into the same item group.

[0095] Table 2 below is an example of the metric structure for monitoring the status of objects within the RSU / MEC area. The categorization example in Table 2 is "Object Type > Source (data source) > Priority (service priority) > Location (location information) > Direction (movement direction) > Speed ​​". If the source of the data is Object Detection or V2X, the values ​​obtained through each source are displayed. If there are multiple sources of the obtained values, all can be displayed. This categorization method or data format can be changed for various attributes depending on the purpose or type of supported service, and ultimately, it must be able to display information on the number of categorized objects.

[0096] ObjectTypeSourceObjectPriorityLocation <msg>Direction <msg>Speed <msg>Location(Sensing)Direction(Sensing)Speed(Sensing)CountsConnectedObjectV2XMSGVehicleHighZone1South East80 ~ 90---10VehicleLowZone2South East80 ~ 90---20ObjectDetection W / V2 9015ScooterHighZone2South East40~50Zone2South East40~503Un-ConnectedObjectProxyV2XMSGVehicleHighZone1South East70~80---30e-BikeHighZone1North East20~30---20ObjectDetectionVehicleHigh---Zone1South East90~ 10010PedestrianHigh---Zone1North East0~1025

[0097] As seen above, using the Metric table information of the current object occurrence status within the visually structured area, all RSUs / MECs should be able to categorize and update object information that has occurred in their area in real time and share it in real time with adjacent RSUs / MECs.

[0098] There are various ways to share the above data structure in real time and data specifications. Representative linkage methods include message protocol broker linkage and open API linkage, and data specifications such as JSON and XML can be considered. In addition, if sharing between non-adjacent areas is not necessary, linkage may not be performed.

[0099] The primary purpose of an RSU / MEC categorizing and updating object information generated in its own area in real time and utilizing this information to transmit it to adjacent RSUs / MECs is to predict changes in objects that will move within a short period of time. For this purpose, examples such as Case 1 and Case 2 below are possible for objects included in the object status monitoring structure metric within the received RSU / MEC area, and accordingly, the method for predicting objects that will move within the own area within a short period of time can vary.

[0100] (Case 1)

[0101] Figure 6 illustrates an example of sharing a metric structure for monitoring the overall object status based on Case 1.

[0102] Referring to Figure 6, the monitoring device in the relevant area receives overall object status monitoring metric structure information from the adjacent area. Using this information, it directly predicts objects that will move from the adjacent area to its own area.

[0103] Figure 7 illustrates the entire object status monitoring Metric database structure based on Case 1.

[0104] When the monitoring device receives all the information, the data size may increase depending on the number of adjacent MECs / RSUs and the number of objects generated, but there is no need to consider the network link delay time factor for prediction.

[0105] (Case 2)

[0106] Figure 8 illustrates a prediction object status monitoring metric structure based on Case 2.

[0107] Using the object status monitoring metric structure information of the current area, objects that will move from the current area to an adjacent area within a short period of time are predicted, and only these results are extracted and transmitted as object status monitoring metric structure information. The RSU / MEC of the received area does not need to perform the short-term moving object prediction process.

[0108] Figure 9 illustrates a Metric database structure for monitoring the status of predicted objects based on Case 2.

[0109] In the case of Fig. 9, the processing data size is reduced, but the network link delay time factor for prediction may need to be considered.

[0110] 2.1.1 Criteria for judging moving objects within a short period of time in the overall object status monitoring metric structure

[0111] Using the overall object status monitoring metric structure information received from adjacent areas, criteria are needed to determine which objects will move into the target area in a short period of time. This disclosure proposes the following criteria examples, and if the criteria are met, the object is considered to be moving within the target area. These criteria can be further quantified and refined depending on the service purpose and type.

[0112] 1) Location of the object from the current area - whether it is in the boundary area (1) or near the boundary area (2), and weighting of object reliability by distance deviation compared to the boundary or near the boundary area.

[0113] Example: Over 20km: 10% / 5~20km: 50% / Under 5km: 80%

[0114] 2) Object's Direction from the current area - Whether the object is moving in the direction of the current area, and weighting of object reliability according to the direction error angle.

[0115] Example: Over 180 degrees (opposite direction): 10% / 90~30 degrees: 50% / 30~0 degrees: 80%

[0116] 3) Speed ​​of object from current area - When an object moves toward the current area, if the object speed is high, the target object identification confidence weight is given.

[0117] Example: Under 30km / h: 10% / 30~80km / h: 50% / Over 80km / h: 80%

[0118] 4) Object Detection Priority - Weighting of target object identification confidence by High / Low

[0119] Example: Low: 10% / Middle: 50% / High: 80%

[0120] Example of final judgment criteria: When the average of all reliability items is 70% or higher

[0121] The criteria examples below are the criteria for excluding short-term moving objects from the target.

[0122] 1) If the standard value is not met

[0123] 2) When there is inconsistency in data obtained from multiple sources (e.g. V2X Message, Object Detection)

[0124] 2.1.2 Short-term moving object judgment criteria of the predicted object status monitoring metric structure

[0125] Using the object status monitoring metric structure information acquired from the current area, criteria for determining objects that will move to an adjacent area in a short period of time are also required. In this disclosure, if an object satisfies criteria that are identical or similar to the examples proposed in 2.1.1 (e.g., the object's location, direction, speed, object detection priority from the adjacent area, etc.), the object is considered to be moving to an adjacent area. Similarly, these criteria can be quantified and subdivided as much as desired depending on the service purpose and type, and the criteria for excluding short-term moving objects proposed above can be applied to the prediction.

[0126] 2.2 Adding System Metric indicators for moving predicted objects for auto-scaling occurrence

[0127] Based on whether the conditions of the above items are satisfied and a high weight result is obtained, the RSU / MEC-based V2X service infrastructure entity must determine the load objects moving into the current area, and must constantly know the maximum number of objects allowed by the current computing resources for comparison, and calculate the moving average value to determine the increase or decrease trend of the number of objects determined in this way. Figure 10 is an example of the moving average value versus the number of objects that occurred.

[0128] The calculation results should be dynamically included in the system metric indicator of the RSU / MEC Auto-Scale Platform along with the number of objects scheduled to move within a short period of time to be used as a value for determining the criteria for Auto-Scaling occurrence.

[0129] Table 3 is an example of an Auto-Scaling system metric that includes information related to moving objects.

[0130] Monitoring Items Detailed Item Criteria Example CPU Usage (%) Scale-Out when load reaches 60%. Scale-In when load falls below 40%. RAM Usage (%) Scale-Out when load reaches 60%. When less than 30%, Scale-In. Network In / Out (Bytes or Packets) When each processed packet exceeds 1 Gbps. Scale-Out. When less than 100 Mbps. Scale-In. Disk I / O. Read / Write (Bytes or Operation) When each access exceeds 100,000,000 times. Scale-Out. When less than 1,000 times. Scale-In. Average load maintenance time. Minutes, Hours. When it lasts for more than 10 minutes. Scale-Out. Number of load occurrences. Number of occurrences. When it occurs 4 or more times. Scale-Out. Moving average value of objects occurring in adjacent areas. Moving average value of objects occurring in adjacent areas. When the moving average value of objects occurring in adjacent areas increases by 5 or more times, and the number of objects occurring in adjacent areas also increases by 5 or more times. When the sum of the number of objects currently being processed and the number of objects occurring in adjacent areas exceeds the maximum number of objects allowed by the current computing resource. Scale-Out. Number of objects occurring in adjacent areas. Number of objects occurring in adjacent areas.

[0131] 2.3 When moving objects exceed the threshold for auto-scaling to occur

[0132] When updating the number of objects in the system metrics, the RSU / MEC must determine at what point in time the identified number of objects poses a high risk of impacting the load. Below are examples of points in time when the number of objects is increasing sufficiently to increase the load compared to the maximum number of objects allowed by the current computing resources, and the types of points in time when this can be considered high risk.

[0133] Figure 11 shows the slope of the moving average of the number of target objects and the case where the point at which the number of objects increases is the RSU / MEC boundary point adjacent to the RSU / MEC itself.

[0134] If the number of objects occurring on the border of the current RSU / MEC sensing / cluster area and the entire area adjacent to it is judged to exceed the maximum number of objects allowed by the computing resource when entering the current area, thereby affecting the load, Auto-Scaling is performed.

[0135] In this case, there is a disadvantage that Auto-Scaling may be performed at that point and the time required for allocating new resources may be insufficient, but there is an advantage that dynamic computing resources can be allocated only for the load that will occur because the change in the number of objects expected to affect the load is small.

[0136] To enable Auto-Scaling based on the boundary of the area, the object status monitoring metric structure must set the object's location judgment criterion to the boundary area when determining whether an object is expected to move within a short period of time.

[0137] Figure 12 shows the slope of the moving average of the number of target objects and the case where the point at which the number of objects increases is a point a certain distance (e.g., 10 km) outside the RSU / MEC boundary line adjacent to the RSU / MEC itself.

[0138] If the number of objects occurring in an area outside a certain distance from the boundary of the entire area adjacent to the current RSU / MEC sensing / cluster area exceeds the maximum number of objects allowed by computing resources when entering the current area and is judged to affect the load, Auto-Scaling is performed.

[0139] In this case, the expected increase in the number of objects impacting the load can be significant, which can lead to inaccurate allocation of dynamic computing resources to meet the expected load. However, the advantage lies in the ability to auto-scale beyond the boundary, allowing for more time until new resources are allocated.

[0140] To enable Auto-Scaling based on a certain distance from the boundary of the area, when determining whether an object is expected to move within a short period of time in the object status monitoring metric structure, the object's location determination criteria must be set to a location a certain distance outside the boundary area.

[0141] 3. Policy update for RSU / MEC sensing / cluster auto-scaling

[0142] If the threshold condition violation monitoring items are updated by reflecting the system metric of the number of sensing / clustering objects of the current RSU / MEC, an auto-scaling policy that should be activated in response to this must be configured in the RSU / MEC auto-scale platform. This process defines the number of virtual servers to increase when auto-scale-out occurs, and conversely, the number of virtual servers to decrease when scale-in occurs. The method can be defined in various ways, such as logarithmically or by ratio, depending on the operating system conditions. Note that scaling can be configured in various ways, such as manual, automatic, on-demand, and predictive, depending on the vendor. However, the content proposed in this specification is a dynamic scaling method that pre-allocates auto-scaling server instance capacity according to changes in traffic due to the increase or decrease in the number of V2X objects, which cannot be fixed. Therefore, a variable policy update method is required, rather than a scaling policy within a fixed instance capacity range. For example, integration with a script-based automation platform using a CLI (Command Line Interface) method can be considered.

[0143] To help you understand, we provide an example of a scale-out policy setting below.

[0144] - Number of basic compute server instances = 4

[0145] - Maximum number of objects allowed per basic compute server instance = 12

[0146] - Object exchange ratio for computing resources = 1:3

[0147] - Number of compute server instances for increased request = (number of objects currently being processed + number of remaining additional objects) / 3

[0148] Example: If the number of objects currently being processed + the number of remaining additional objects = 18, the number of compute server instances requested to increase is 18 / 3 = 6, which requires an additional Scale-Out allocation request of 2 compared to the default number of compute server instances (4).

[0149] For example, if a large number of objects are predicted to move from the current RSU / MEC sensing / cluster area to an adjacent RSU / MEC sensing / cluster area in a short period of time, information such as the number, location, and speed of service request objects moving to the adjacent area and information related to the service being processed (e.g., object detection, message exchange, event warning notification, etc.) can be transmitted to the adjacent RSU / MEC to hand over the service flow through resource allocation.

[0150] Figure 13 illustrates data processing based on load prediction for moving objects.

[0151] 0) Setting Auto Scaling Policy - Specify the desired change in compute resource capacity (or minimum and maximum size as the case may be) to the RSU / MEC Auto-Scale Platform through Auto Scaling in response to system metrics exceeding certain thresholds - See "3. Policy Update for Sensing / Cluster Auto-Scaling of RSU / MEC"

[0152] 1) After the RSU / MEC analyzes object information in real time for its own area, it updates the metric table information on the occurrence status of objects scheduled to move to the entire area or adjacent areas within a short period of time and shares it in real time with adjacent RSU / MECs.

[0153] 2) From the information in each shared Metric table, the total number and moving average of objects passing through the point (boundary, certain distance outside the boundary) expected to move to their own area from the adjacent RSU / MEC are derived, and reflected in the system Metric indicator of the RSU / MEC Auto-Scale Platform.

[0154] 3) Collect network information of Load Balancer and system resource metric indicator information of server as monitoring service at specific intervals.

[0155] 4) If the threshold conditions specified in the monitoring service set in step 0 are detected to be exceeded (e.g. above / below / exceeding / below), the Auto-Scaling policy is initiated.

[0156] 5) Increase or decrease the number of virtual server instances.

[0157] 6) Start the server instance allocation task that matches the set policy setting value. Typically, the image shape SPEC is set to the same as the current computing resource for fast provisioning allocation.

[0158] 7) Verify that the instances associated with the Auto Scaling group are functioning properly. This includes checking whether the instances exist and are accessible (e.g., HTTP Ping Test, 200 OK response, etc.) or whether the instances exist and are serving with the associated Load Balancer.

[0159] 8) Once the server status check is complete, add the server to the Load Balancer and start processing request traffic in the same way as other servers.

[0160] Object detection processing method for specific image area recognition by priority

[0161] Object detection is a function that performs classification and localization for all categories within an input image. This type of object detection is used in areas requiring traffic safety, such as smart CCTV and smart RSU, to detect and identify moving pedestrians or vehicles using camera sensors, collect vehicle driving information, and predict collisions.

[0162] These object recognition functions have recently seen a dramatic improvement in the performance of image analysis technologies such as object and scene recognition due to the advancement of deep learning technology, and most of these technologies require a structure based on a high-performance GPU server application environment.

[0163] Machine learning-based object detection technology is broadly divided into two-stage and single-stage methods depending on its structure.

[0164] The two-stage method performs object detection in two steps: finding candidate regions of interest (ROIs) in an image using Selective Search, Region Proposal Networks, etc., and performing class classification and bounding box regression on the found candidates. A representative technology is Faster R-CNN.

[0165] Single-stage methods perform object detection using a single deep learning model that performs classification and bounding box regression directly from predefined anchor boxes, without the step of finding object candidate regions. In the mobile and embedded fields, single-stage methods are primarily used due to speed issues, and a representative technology is YOLO (You Only Look Once).

[0166] In the case of services based on server application environments in the C-ITS system, there is an increasing demand for optimization technology to reduce response delay (latency) time as multiple servers are passed through from object detection to endpoint. In addition, service performance quality can be distinguished according to service purpose (low response delay & low detection accuracy Vs. high response delay & high detection accuracy) so that customers can select the optimization level.

[0167] In the C-ITS system, the processing sequence structure of service responses based on the server application environment largely proceeds in three steps: "1. Object Detection & Result Analysis Delivery, 2. Request Service Processing Delivery, 3. Service Reception." Although it varies depending on the service type and purpose, example structures such as those in Table 4 exist. Table 4 exemplifies the CCTV and RSU related service server-infrastructure structure.

[0168] Case #1. Object Detection & Result Analysis Delivery 2. Request Service Processing Delivery 3. Service Reception 1. CCTV Filming / Object Recognition Result (Wired or Wireless) → LDM Server (BSM / PSM Message Creation) → Soft RSU Cloud Server (Cloud RSU) → SoftV2X Server SoftV2X Terminal (Smartphone) 2. CCTV Filming / Object Recognition Result → Soft RSU (BSM / PSM Creation - Wired or Wireless) → SoftV2X Server *Depending on whether a camera is installed in the RSU, V2X message processing can be selected from 1) Server Creation (Camera Installed) or 2) RSU Creation (Camera Not Installed) SoftV2X Terminal (Smartphone) 3. CCTV Filming / Object Recognition Result Video Information Storage and Analysis (Cloud) Service Provision (Smartphone) 4. CCTV Filming / Object Recognition Result Video System (On-Premise Server) Remote Monitoring (Smartphone / PC)

[0169] Object detection time may be affected by the function implementation method, number of processing objects, number of linked server points, etc., but as the number of processing objects with these properties and data sizes increases, the delay in processing object detection data and traffic load will also increase. This can be resolved by optimizing the function implementation method or number of linked server points, and various technologies are being researched and developed to reduce the detection time in order to optimize the function implementation method.

[0170] In order to optimize the implementation of functions, object detection and scene segmentation require low latency, low power, and optimization of computational amount. To achieve this, the following requirements must be satisfied.

[0171] First, it is necessary to reduce the weight of the feature extraction layer, which is used as the basic structure for extracting image features in deep learning models.

[0172] Second, optimization is necessary from the perspective of deep learning model structure for object detection or object / scene segmentation. For example, object detection requires a lightweight structure for determining object location and type, while object / scene segmentation requires a lightweight structure for segmentation. Object detection in typical real-world services typically takes less than one second. For example, when video recording and object recognition are processed on the same device, object recognition detection for a single video frame can take approximately 200 ms.

[0173] Also, depending on the object detection implementation method, when used in a typical transportation system or C-ITS system, the object detection function must output detection data and detection video, such as Fig. 14, which determine the time and physical property information of the detected object. In conclusion, load factors that must be considered in services utilizing object detection in typical ITS systems may include object detection delay time, detection data processing time, data size, and transmission bandwidth.

[0174] The types of data included in the detection results can be confirmed through an example such as Figure 14.

[0175] Meanwhile, assuming that a service utilizing object detection is operated in an ITS system environment, a system equipped with such a function must consider load factors (e.g., detection data processing time, data size, and transmission bandwidth) to minimize their impact on the ITS service quality (QoS).

[0176] The load generated by object detection processing is a problem that must be resolved in terms of the system's physical resources (e.g., processing speed, memory resources, power consumption, heat generation, etc.), but the structure in which the problem-solving process is processed after the load generation problem occurs inevitably affects the ITS service quality when the load problem first occurs, and if the ITS service being processed or scheduled is a safety-related service, it may lead to unexpected damage.

[0177] Therefore, systems equipped with object detection functions operating in these ITS system environments must be structurally designed or equipped with operational process functions to prevent overload even during normal times. For example, to prevent or minimize overload, the system's object detection function can be implemented by efficiently activating / deactivating the object detection function itself under specific conditions and priorities, or by implementing the system so that object detection is processed only in specific areas of the video frame.

[0178] In the object detection processing process led / executed by roadside devices or their associated systems in a V2X environment, priority conditions and processing methods for the conditions are proposed to prevent meaningless, continuous object detection processing operations and to process them efficiently.

[0179] The proposed methods can be expected to ensure ITS service quality and improve the lifespan of the system by keeping the load on the object detection system to a minimum.

[0180] In the existing Intelligent Transportation System (ITS) or Cooperative-ITS (C-ITS) system, when an intelligent CCTV or RSU capable of video sensing object detection processes a moving object detection function in conjunction with a surrounding Smart RSU or server, performing constant object detection may, as mentioned above, generate a load and may not be efficient.

[0181] Accordingly, the following processing priority conditions and processing methods for the conditions are proposed so that the object detection-equipped system can prevent meaningless, constant object detection processing operations and maintain a state in which the load due to object detection / processing is minimized.

[0182] - If no object detection result event occurs for a certain period of time, disable the object detection function or change the object detection parameters (e.g. increase the detection cycle (e.g. every frame => 1 sec, 10 sec, 60 sec, ..)) / relax the conditions

[0183] - When an event is confirmed to occur through external input (sensor information, V2X message reception, accidents, road conditions, Internet information crawling, and weather information reception, etc.), object detection is performed in the area where the event occurred.

[0184] - If object detection cannot be performed for a certain period of time, camera screenshot information is transmitted to the road operator and accident collection / processing center at a certain interval.

[0185] Priority Object Detection System Requirements

[0186] The proposed object detection system performs object detection on-demand by first recognizing priorities and conditions and then making judgments, rather than operating continuously, thereby operating efficiently and blocking load.

[0187] Although a system typically involves multiple components working together to identify and locate objects in an image or video, the requirements for a system with object detection capabilities to address the requirements proposed in this specification are as follows:

[0188] (1) Input

[0189] Object detection entities (e.g. CCTV, RSU, etc.) should be able to use images and video frames from areas where detection priority exists as input, regardless of whether objects support V2X Communication.

[0190] When an object detection subject receives a V2X message from a V2X transmitting or receiving terminal object capable of supporting V2X Communication from its surroundings, the message must include physical attribute information (e.g., positioning, speed, direction, vehicle length, vehicle width, etc.) among the essential data fields that must be transmitted. This physical attribute information can be detected with the same information values ​​during the object detection function execution process, and the similarity can be confirmed by comparing it with the information detected from the message.

[0191] The above V2X transmitting or receiving terminal refers to a terminal that transmits or receives a message in a specific V2X use case (Ex. basic safety, sensor sharing, maneuver coordination, etc.) including the V2X use cases described below. Even if the same terminal operates multiple use cases, the transmitting / receiving operation may be different for each use case.

[0192] In addition to V2X messages, the object detection subject must be able to collect various sensor information (e.g. LiDAR, Radar, ultrasonic sensors, etc.) that can be received from the outside, and Internet information (e.g. accidents, road conditions, Internet information crawling, and receiving weather information, etc.) so that they can be used for detection.

[0193] (2) Preprocessing

[0194] Preprocessing of input data may be required to improve image quality, such as resizing, normalizing, and applying filters.

[0195] Object (re)occurrence can also be detected through image preprocessing, such as background removal and image subtraction, from the input image. From the preprocessed image, it's also possible to determine whether to set a region of interest (ROI) and / or perform object detection only in specific regions or regions, or to (re)activate the object detection function. For example, one could consider performing detection in the following manner.

[0196] - When performing a detection function: By recognizing the presence of a moving object through a differential image in the area of ​​interest (entire area or priority processing area), object detection can be performed for the relevant recognition area.

[0197] - When the detection function is not being performed: Preprocessing (background removal and / or image difference) is performed to detect moving objects to trigger the detection function.

[0198] (3) Feature extraction

[0199] Typical object detection systems extract relevant features from preprocessed images using techniques such as convolutional neural networks (CNNs) or other feature extraction methods. These features are used to capture important patterns and characteristics of objects.

[0200] For objects that can support V2X Communication, they must be located in a Cover area where they can sense the location, movement, status information, etc. of the object (e.g. VRU, vehicle, etc.) that transmitted the received V2X message, as well as a certain distance around it. In this case, V2X message detection can be collected through a short-range (e.g. DSRC, PC5, etc.) communication method in the Cover area, as well as a long-range (e.g. Uu IF) communication method.

[0201] The object detection subject can use the detected location or installed location as a reference point for relative positioning, and when the object is detected from the data of the sensor installed in the object detection subject, the relative location of the object can be determined through preset information, etc.

[0202] In the same sense, by combining the location of the reference point and the relative location information of the object, the location information of the object can be obtained. By comparing the similarity between the movement attribute information of the object detected and obtained in this way and the movement attribute information of the object received through the V2X message, the recognition information and movement attribute information of the object can be detected, and features can be extracted based on the information.

[0203] For objects that cannot support V2X Communication, the detection subject system must be able to detect information such as the type, location, size, and direction of the object within the image / video frame and the surrounding area at a certain distance by combining the detection algorithm equipped with the detection subject system and relative positioning information such as the example mentioned above.

[0204] According to the priority processing method proposed in this specification, in the process of searching for an object candidate region of interest (ROI) in an image area, there may be two or more cases where there are regions that need to be searched first and regions that need to be searched second. Therefore, it may be necessary to perform object detection by dividing computing resources among the regions in order of priority.

[0205] In the above process, if feature extraction for an object does not work well at a specific point or area, attempting image detection may be meaningless or may result in incorrect detection results. For example, if a V2X Communication-supported object is transmitting a V2X message at a specific location but is occluded by an obstacle, etc., the (related or matching) image for the object may not be detected for a certain period of time. If this phenomenon continues to occur in the same area due to multiple V2X Communication-supported objects, the area may be determined to be an undetectable area. More specifically, if a certain number (e.g., 100) or more different object detections have occurred (or passed) at a specific point or area and image detection (creation of bounding boxes for images of related objects) fails at a certain rate or higher (e.g., 90%), it is recognized as a situation in which image detection is not possible in that area.

[0206] The above-mentioned point or area information can be combined to form a specific undetectable / excluded area within the camera sensor coverage area. These undetectable / excluded areas can be assigned the lowest detection priority, and for processing efficiency, detection can be omitted or abandoned for areas corresponding to that priority.

[0207] These undetectable / excluded areas may partially or completely change due to changes in the camera installation environment, such as the removal of undetectable elements (e.g., demolition or deformation of structures, terrain features, etc.) or other reasons, making detection possible again. This may not be information that is updated in real time over a short period of time, but may be information that changes over a long period of time. In this case, as described above, the changed information on the undetectable / excluded areas must be reflected to determine whether to perform detection, the detection priority, etc. In addition, even in areas where detection is excluded due to very low detection priority, intermittent detection attempts may be made to check for changes, or detection tests may be performed during the management and calibration of RSU CCTV / camera sensors, etc. For example, even in the case of the above detection exclusion area, if detection is attempted to check the update status periodically every T hours (eg T=1), it can be done by waiting for a certain period of time (eg t0 + mT, where m is an integer greater than 0) for each cycle based on the start time of the operation (eg t0) until a certain number (eg k=10) of objects (UE) occur and checking whether images related to the objects (UE) are detected. In this process, the updated area information is reflected in the next operation, and from then on, image detection is attempted in a new area configuration and priority setting state.

[0208] In a situation where the properties of an area, such as detection priority, are (re)determined or detection is resumed by counting objects detected during the above-mentioned period of time, the threshold for the counted value may be different depending on the type of area, as in the example below.

[0209] - High priority (e.g. high risk area) k = 3

[0210] - Low priority (e.g. low risk area, pedestrian only area) k = 10

[0211] For example, even if a high-priority detection area temporarily becomes a non-detection area / detection exclusion area due to reasons such as object failure or undetectable object, it is still necessary to detect objects in that area without missing them as much as possible. Therefore, in such areas, even if only a small number of objects are detected within a set period of time while in the detection exclusion state, normal detection can be resumed (re)configured.

[0212] The detection agent or target system may skip or abandon the detection of certain objects if it determines that the expected objects to be detected in the detection area are of low importance. For example, if it is necessary to continuously track and update information on already detected objects rather than detecting a specific area, or to maintain detection while assuming the same attribute information, detection may be stopped for objects of low importance to ensure the efficiency of the distributed computing structure, or the detection priority may be lowered for areas where such objects are highly distributed.

[0213] The above-mentioned non-detectable areas and detection-excluded areas may have the same detection priority, but may also have different or independent detection priorities. In other words, detection-disabled and detection-excluded may or may not be synonymous.

[0214] For example, if an area is (temporarily) determined to be undetectable due to the surrounding environment, but object detection in that area is critical for traffic safety, etc., information about the object should be obtained as much as possible and transmitted, such as by utilizing information through the V2X communication mentioned above. Alternatively, even if detection by CCTV is impossible, information from other remaining sensors can be integrated and considered as a substitute.

[0215] (4) Object Localization

[0216] The extracted features are used to identify the presence and location of objects within the image. This is typically done by applying a bounding box around each detected object.

[0217] (5) Classification

[0218] Once the presence of an object is identified, the system must classify it into various categories or classes. This step may involve assigning labels to detected objects, such as "person," "car," or "cat." This can be accomplished using machine learning algorithms such as support vector machines (SVMs) or deep learning models.

[0219] (6) Post-processing

[0220] The object detection system may perform additional post-processing steps to refine the object detection results. These may include filtering out false positives, adjusting bounding box coordinates, and applying non-maximum suppression techniques to eliminate duplicate detections.

[0221] After analyzing the similarity of the physical attribute information of the detected object from the two paths of message reception and remote sensing object detection, if it is determined to be similar, it moves to the process of generating and transmitting the detection result data, and if it is determined to be not similar, it can add a re-detection opportunity and compare again. However, if an object recognition re-detection opportunity is added every time an error occurs, a delay may occur, and this must be considered in the overall processing time.

[0222] Object detection time varies greatly depending on the number of detection targets, applied object detection algorithm, and HW performance, but the evaluation target detection time set in research projects related to mobile detection (urban road autonomous cooperative driving safety & infrastructure research project, development of intersection mobile object information collection technology / mobile object detection performance evaluation) is 200 ms, which means that a delay effect of several hundred ms to several seconds can be expected even with just a few re-detections allowed. In areas with high detection priority, the allowable value for delay time may be set higher than in areas with low detection priority, and detection can be considered successful even if a specific object is detected or identification information (e.g. ID value, location information, etc.) for the object is successfully obtained through combining information acquired from V2X communication information, other sensors, other network entities, etc.

[0223] (7) Output

[0224] The final output of an object detection system may include detected objects and their labels and bounding box coordinates.

[0225] Priority Processing Proposal Structure & Method

[0226] The priority conditions and methods for preventing constant object detection processing and efficiently processing object detection are as follows.

[0227] (1) If no object detection result event occurs for a specific period of time or if the object detection exclusion area is determined, the object detection function is disabled or the object detection parameters are changed.

[0228] After the initial system operation, object detection is performed, and if there is no result of obtaining meaningful event detection information from the detection result for a certain period of time or if it does not occur more than a certain number of times, the object detection subject must be able to disable the object detection function or change it to Sleep Mode to prevent consumption of physical resources of the system due to unnecessary processing.

[0229] Alternatively, object detection parameters can be adjusted / relaxed to prevent exhaustion of the system's physical resources. For example, increasing the detection cycle (e.g., every frame => 1 sec, 10 sec, 60 sec, etc.) can be considered to make object detection less frequent.

[0230] (2) When an event is confirmed to occur through external input (sensor information, V2X message reception, accidents, road conditions, Internet information crawling, and weather information reception, etc.), the event occurrence area is focused on detecting objects.

[0231] The object detection subject must be able to collect external input information other than object detection, and extract features from images and video frames centered on the location where the event occurred and surrounding geographic information through event confirmation and judgment of the need for object detection from the collected information.

[0232] Examples of the types and processing methods of external input information are as follows.

[0233] (i)LiDAR (Light Detection and Ranging)

[0234] LiDAR sensors use laser beams to measure distances and create high-resolution 3D maps of their surroundings. They can also accurately detect objects and their distances.

[0235] Using LiDAR information, events such as vehicle collisions and road departures can be predicted.

[0236] (ii) Radar (Radio Detection and Ranging)

[0237] Radar sensors use radio waves to detect objects and measure distance, speed, and direction. They can predict events such as vehicle collisions and road departures.

[0238] (iii) Ultrasonic sensor

[0239] It uses sound waves to detect objects and measure distances. It can also predict blind spot events.

[0240] (iv) Audio / noise sensor

[0241] Collect noise and audio data and predict risks when noise events exceed a certain standard dB occur.

[0242] (v) V2X messages

[0243] It enables communication between vehicles and infrastructure using Short Range (e.g., WAVE, DSRC, PC5) or Cellular (e.g., Uu IF) networks. This allows vehicles to exchange information about their location, speed, and intentions, as well as collect information on direct accident risks, road events (e.g., RSA, TIM, etc.), vehicle emergencies, and vehicle status, along with physical attribute information, enabling accurate predictions for object detection.

[0244] (vi) Other Internet-collected information

[0245] By using Open API, Rest API, message protocol, Web Crawling, etc., events occurring in the area covered by the object detection subject system can be acquired in real time to predict risks.

[0246] If the above external input confirms that no more events are occurring, the area can be re-enabled as an exclusion area. In other words, external input information can be used complementarily with existing detection information to determine whether an event has occurred, determine whether to set an exclusion area, and more.

[0247] (3) If object detection cannot be performed for a specific period of time, camera screenshot information is transmitted to the road operator and accident collection / processing center at specific intervals.

[0248] For example, in a Cellular-based ITS system environment, in a situation where CCTV or RSU equipped with object detection function for a specific service purpose based on a server application environment is installed, if it is necessary to improve the efficiency of unnecessary object detection processing processes, the activation / deactivation of the object detection processing process is controlled only by priority conditions without a process for load balancing.

[0249] Through this, problems in terms of the system's physical resources (e.g. processing speed, memory resources, power consumption, heat generation, etc.) are resolved, and indirect effects due to load generation problems are prevented.

[0250] Table 5 is an example of a method for processing object detection by recognizing a specific image area by priority.

[0251] 1. Perform object detection. 2. If no object detection result event occurs for a specific period of time, disable the object detection function (or change the object detection parameter / relax the conditions). 3. Receive external event input to confirm the occurrence of an event. 4. Perform object detection focused on the event occurrence area. 5. If object detection cannot be performed for a specific period of time, transmit camera screenshot information to the road operator or accident collection / processing center at specific intervals.

[0252] Figure 15 illustrates a method for a first network node to transmit information to a second network node in an intelligent transportation system (ITS).

[0253] Referring to FIG. 15, a first network node can process information about first objects moving in a first area it monitors (1505).

[0254] Based on the processing result, the first network node can obtain first prediction information about the processing load expected to be caused by the first objects in a second area at least partially in contact with the first area (1510).

[0255] The first network node can transmit the first prediction information to the second network node monitoring the second area (1515).

[0256] The first network node can receive second prediction information from the second network node.

[0257] The second prediction information may be about a processing load that second objects moving in the second area are expected to cause in the first area.

[0258] Based on the second prediction information, the processing resources of the first network node can be adjusted.

[0259] The above processing resources may include at least one of a central processing unit (CPU), random access memory (RAM), network speed, or storage access speed for cloud computing.

[0260] The processing load that the second objects are expected to cause in the first area can be calculated based on at least one of the position, direction, speed, or detection priority of each of the second objects obtained through the second prediction information.

[0261] The above first prediction information may relate to a processing load that the first objects are expected to cause within a time period less than a threshold from the present.

[0262] The above first objects may include at least one of a terminal, a vehicle, or a road side unit (RSU) moving in the first area.

[0263] Monitoring of the first area by the first network node may be disabled based on the fact that a first event related to object detection has not occurred in the first area for a certain period of time.

[0264] The first network node can receive sensing information related to the first area from an external device after the monitoring of the first area is disabled.

[0265] Based on the detection of a second event through the sensing information, monitoring of the first area by the first network node can be resumed.

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

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

[0268] Figure 16 illustrates a communication system applicable to this embodiment.

[0269] Referring to FIG. 16, 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.

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

[0271] 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 base station-to-base station communication (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.

[0272] Figure 17 illustrates a wireless device applicable to the present disclosure.

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

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

[0275] 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. 16 to 27.

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

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

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

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

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

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

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

[0283] Referring to FIG. 18, the wireless device (100, 200) corresponds to the wireless device (100, 200) of FIG. 17 and may be composed of various elements, components, units / units, and / or modules. For example, the wireless device (100, 200) may include a communication unit (110), a control unit (120), a memory unit (130), and additional elements (140). The communication unit may include a communication circuit (112) and a transceiver(s) (114). For example, the communication circuit (112) may include one or more processors (102, 202) and / or one or more memories (104, 204) of FIG. 18. For example, the transceiver(s) (114) may include one or more transceivers (106, 206) and / or one or more antennas (108, 208) of FIG. 17. 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).

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

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

[0286] Figure 19 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.

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

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

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

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

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

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

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

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

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

[0296] The embodiments of the present disclosure as described above can be applied to various devices of an intelligent transportation system.< / msg> < / msg> < / msg>

Claims

1. In a method for transmitting information from a first network node to a second network node in an intelligent transportation system (ITS), Processing information about first objects moving in a first area monitored by the first network node; Based on the processing result, first prediction information is obtained about the processing load expected to be caused by the first objects in a second area at least partially in contact with the first area; and A method comprising transmitting the first prediction information to the second network node monitoring the second area.

2. In paragraph 1, Further comprising receiving second prediction information from the second network node, A method according to claim 1, wherein the second prediction information is about the processing load that the second objects moving in the second area are expected to cause in the first area.

3. In paragraph 2, A method further comprising adjusting processing resources of the first network node based on the second prediction information.

4. In paragraph 3, A method wherein the processing resources include at least one of a central processing unit (CPU), random access memory (RAM), network speed, or storage access speed for cloud computing.

5. In paragraph 1, A method in which a processing load expected to be caused by the second objects in the first area is calculated based on at least one of the position, direction, speed, or detection priority of each of the second objects obtained through the second prediction information.

6. In paragraph 1, A method wherein the first prediction information relates to a processing load that the first objects are expected to cause within a time period less than a threshold from the present.

7. In paragraph 1, A method wherein the first objects include at least one of a terminal, a vehicle, or a road side unit (RSU) moving in the first area.

8. In paragraph 1, A method wherein monitoring of the first area by the first network node is disabled based on the fact that a first event related to object detection has not occurred in the first area for a specific period of time.

9. In paragraph 8, A method wherein the first network node receives sensing information related to the first area from an external device after deactivation of monitoring of the first area.

10. In paragraph 9, A method in which monitoring of the first area by the first network node is resumed based on the detection of a second event through the sensing information.

11. A computer-readable recording medium recording a program for performing the method described in paragraph 1.

12. In a first network node operating in an intelligent transportation system (ITS), memory for storing commands; and A processor that performs operations by executing the above instructions, The operations of the above processor are: Processing information about first objects moving in a first area monitored by the first network node; Based on the processing result, first prediction information is obtained about the processing load expected to be caused by the first objects in a second area at least partially in contact with the first area; and A first network node comprising transmitting the first prediction information to the second network node monitoring the second area.

13. In paragraph 12, The first network node is a server that monitors a terminal, vehicle, or RSU (road side unit) moving in the first area.

Images