Cloud camera edge-based video storage system
Patent Information
- Authority / Receiving Office
- KR · KR
- Patent Type
- Patents
- Current Assignee / Owner
- NEXUS SYSTEM CO LTD
- Filing Date
- 2025-12-26
- Publication Date
- 2026-08-03
Smart Images

Figure 112025147064036-PAT00006_ABST
Abstract
Description
Technology Field
[0001] The present invention relates to an edge-type video storage system for a cloud camera, and provides a system that safely stores camera video in the event of a network failure and ensures continuity and integrity by selectively uploading missing segments upon recovery. Background Technology
[0002] Cloud camera systems feature a structure where video captured by network-connected cameras is directly transmitted and stored on a cloud server via the Internet, allowing users to remotely manage multiple cameras in an integrated manner through the web or applications. While this structure offers the advantage of centralized video monitoring, storage, search, and analysis without the need to install separate recording devices or servers on-site, network failures or internet disconnections can prevent video data from being transmitted to the cloud server, resulting in storage gaps. This can lead to serious security vulnerabilities, such as the loss of critical evidence in the event of intrusions or incidents. Although temporary storage using SD cards is sometimes applied to individual cameras to mitigate this, operational efficiency drops significantly in environments where a large number of cameras are managed centrally due to limited capacity and difficulties in replacement and inspection. Furthermore, embedding high-capacity storage devices directly into the cameras increases the unit cost and complexity of each individual camera; consequently, economic feasibility deteriorates as the number of cameras increases, while the burden of installation and maintenance grows.
[0003] At this time, a method has been researched and developed to store data in internal memory or upload it only when an event occurs in the event that the network is disconnected in a cloud camera system. In this regard, prior art Korean Published Patent No. 2022-0110963 (published on August 9, 2022) and Korean Registered Patent No. 10-2643330 (published on March 5, 2024) disclose a configuration in which, so as not to lose video even when the network is disconnected in a cloud-based video security system, video before and after the network disconnection is backed up and stored in the camera's internal memory, and upon network recovery, this backup video and backup list are transmitted to a cloud server to seamlessly restore the entire video, and an edge device connected to the camera generates metadata from the video and transmits it to a cloud server, and the cloud server analyzes the metadata and additionally requests the original video only when an event occurs.
[0004] However, in the former case, as mentioned above, embedding a high-capacity storage device within the camera itself increases the unit cost and complexity of individual cameras; consequently, economic feasibility deteriorates as the number of cameras increases, and the burden of installation and maintenance grows. Furthermore, in the latter case, since the original footage is not stored on the cloud server, it becomes impossible to locate evidence or sequences of scenes due to the absence of the source video. Additionally, the method of configuring a cloud system using a separate recorder leads to complex functional configurations and high initial setup costs. Moreover, because the structure involves collecting camera footage from the recorder first and then relaying it to the server, there is a disadvantage that if an error occurs in the recorder, video transmission from all cameras connected to that recorder is simultaneously halted. Therefore, research and development of a platform capable of saving and recovering video without loss, even if the network connection is interrupted in a cloud camera system, is required. The problem to be solved
[0005] One embodiment of the present invention can provide an edge-type video storage system for a cloud camera that monitors the network connection status, enters a local storage mode when the network connection status is determined to be disconnected, receives and encrypts video from at least one camera and stores it on a local storage medium, and when the network connection status is switched to a connection, enters a recovery mode to compare the data stored on the local storage medium with the data stored on the cloud server and uploads only the missing segments to perform synchronization. However, the technical problem that the present embodiment aims to solve is not limited to the technical problem described above, and other technical problems may exist. means of solving the problem
[0006] As a technical means for achieving the aforementioned technical problem, one embodiment of the present invention comprises an image storage device including at least one camera for capturing an image, a cloud server for uploading the image, a detection unit for detecting a network connection status, an entry unit for entering a local storage mode when the network connection status is determined to be disconnected, a receiving unit for receiving an image from at least one camera, a local storage unit for encrypting the received image and storing it on a local storage medium, and a recovery synchronization unit for selectively uploading only the missing segments by comparing the data stored on the local storage medium with the data stored on the cloud server when the network connection status is switched to a connected state. Effects of the invention
[0007] According to any one of the means for solving the problem of the present invention described above, continuous video recording without gaps in video storage is possible even in situations of network failure or internet disconnection that inevitably occur in a cloud camera system, thereby substantially resolving the core vulnerability of the direct cloud transmission method. Furthermore, by directly collecting, encrypting, and storing video at an edge terminal rather than a camera, the capacity limitations, management inefficiency, and high cost of cameras associated with SD card-based temporary storage methods can be simultaneously resolved. Additionally, the structural risk of video from all cameras being interrupted in the event of a failure in a central collection device, such as an NVR (Network Video Recorder), can be eliminated. Moreover, upon network recovery, only missing segments are selectively uploaded and integrity is verified through time and hash-based comparison between locally stored video and cloud stored video, thereby ensuring the reliability of cloud stored video while minimizing data duplication and upload costs. Brief explanation of the drawing
[0008] FIG. 1 is a drawing for explaining an edge-type image storage system for a cloud camera according to one embodiment of the present invention. FIG. 2 is a block diagram for explaining an image storage device included in the system of FIG. 1. FIGS. 3 and 4 are drawings for illustrating an embodiment in which an edge-type image storage solution for a cloud camera according to an embodiment of the present invention is implemented. FIG. 5 is an operation flowchart illustrating a method for providing an edge-type image storage solution for a cloud camera according to an embodiment of the present invention. Specific details for implementing the invention
[0009] Embodiments of the present invention are described below with reference to the attached drawings so that those skilled in the art can easily implement the invention. However, the present invention may be embodied in various different forms and is not limited to the embodiments described herein. Furthermore, in order to clearly explain the present invention in the drawings, parts unrelated to the explanation have been omitted, and similar parts throughout the specification are denoted by similar reference numerals.
[0010] Throughout the specification, when a part is described as being "connected" to another part, this includes not only cases where they are "directly connected" but also cases where they are "electrically connected" with other elements interposed between them. Furthermore, when a part is described as "including" a component, this means that, unless specifically stated otherwise, it does not exclude other components but may include additional components, and it should be understood that this does not preclude the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.
[0011] Terms such as “about,” “substantially,” etc., used throughout the specification, are used to mean at or near the stated value when inherent manufacturing and material tolerances are presented in the stated meaning, and are used to prevent unscrupulous infringers from unfairly exploiting the disclosure in which precise or absolute values are mentioned to aid in understanding the invention. Terms such as “step” or “step of” used throughout the specification of the invention do not mean “step for”.
[0012] In this specification, the term "part" includes a unit realized by hardware, a unit realized by software, and a unit realized using both. Additionally, one unit may be realized using two or more pieces of hardware, and two or more units may be realized by one piece of hardware. Meanwhile, "part" is not limited to software or hardware, and "part" may be configured to reside in an addressable storage medium or configured to run on one or more processors. Accordingly, as an example, "part" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and "parts" may be combined into a smaller number of components and "parts" or further separated into additional components and "parts." In addition, the components and '~parts' may be implemented to play one or more CPUs within the device or secure multimedia card.
[0013] Some of the operations or functions described herein as being performed by a terminal, device, or device may instead be performed by a server connected to said terminal, device, or device. Likewise, some of the operations or functions described as being performed by a server may also be performed by a terminal, device, or device connected to said server.
[0014] In this specification, some of the operations or functions described as mapping or matching with a terminal may be interpreted as meaning mapping or matching the terminal's unique number or personal identification information, which is the terminal's identifying data.
[0015] The present invention will be described in detail below with reference to the attached drawings.
[0016] FIG. 1 is a drawing for explaining an edge-type image storage system for a cloud camera according to an embodiment of the present invention. Referring to FIG. 1, the edge-type image storage system (1) for a cloud camera may include at least one camera (100), an image storage device (200), and at least one cloud server (400). However, since the edge-type image storage system (1) for a cloud camera of FIG. 1 is merely an embodiment of the present invention, the present invention is not to be interpreted as being limited through FIG. 1.
[0017] At this time, each component of FIG. 1 is generally connected through a network (Network, 300). For example, as shown in FIG. 1, at least one camera (100) can be connected to an image storage device (200) through the network (300). And, the image storage device (200) can be connected to at least one camera (100) and at least one cloud server (400) through the network (300). Also, at least one cloud server (400) can be connected to the image storage device (200) through the network (300).
[0018] Here, a network refers to a connection structure capable of exchanging information among individual nodes, such as multiple terminals and servers. Examples of such networks include Local Area Networks (LANs), Wide Area Networks (WANs), the World Wide Web (WWW), wired and wireless data networks, telephone networks, and wired and wireless television networks. Examples of wireless data communication networks include, but are not limited to, 3G, 4G, 5G, 3GPP (3rd Generation Partnership Project), 5GPP (5th Generation Partnership Project), 5G NR (New Radio), 6G (6th Generation of Cellular Networks), LTE (Long Term Evolution), WIMAX (World Interoperability for Microwave Access), Wi-Fi, Internet, LAN (Local Area Network), Wireless LAN (Wireless Local Area Network), WAN (Wide Area Network), PAN (Personal Area Network), RF (Radio Frequency), Bluetooth network, NFC (Near-Field Communication) network, satellite broadcasting network, analog broadcasting network, DMB (Digital Multimedia Broadcasting) network, etc.
[0019] In the following, the term "at least one" is defined as a term including both singular and plural forms, and it will be obvious that even if the term "at least one" does not exist, each component may exist in a singular or plural form and may mean singular or plural. Furthermore, whether each component is provided in a singular or plural form may be changed according to the embodiment.
[0020] At least one camera (100) may be a device that transmits video to a cloud server (400) using a web page, app page, program, or application related to an edge-type video storage solution for a cloud camera. In this case, the camera (100) may be a device that transmits video to a video storage device (200) when the network connection status is determined to be disconnected.
[0021] Here, at least one camera (100) refers to a CCTV camera capable of connecting to a remote server or terminal via a network (200). The CCTV camera may be an IP camera or an analog camera including an IP encoder, or may be implemented in a hybrid form of both methods, and is based on including a function to transmit video. The CCTV camera may be implemented as a terminal capable of connecting to a remote server or terminal via a wired or wireless network.
[0022] The image storage device (200) may be a server that provides an edge-type image storage solution web page, app page, program, or application for a cloud camera. Additionally, the image storage device (200) may be a device that detects the network connection status, receives and encrypts video from the camera (100) when it is determined to be disconnected, stores it on a local storage medium, and then uploads only the missing segments to the cloud server (400) when the network connection status is restored. Here, the image storage device (200) may be implemented as a computer capable of connecting to a remote server or terminal via a network. Here, the computer may be, for example, a dedicated embedded device and may include a navigation system, a laptop equipped with a web browser, a desktop, a laptop, etc.
[0023] At least one cloud server (400) may be a server that receives video from a camera (100) using a web page, app page, program, or application related to an edge-type video storage solution for a cloud camera, and receives and synchronizes missing segments from a video storage device (200) when the network connection is restored after being disconnected. Here, at least one cloud server (400) may be implemented as a computer capable of connecting to a remote server or terminal via a network. Here, the computer refers to, for example, a computing server for cloud CCTV camera management and may include a laptop, desktop, laptop, etc. equipped with navigation and a web browser.
[0024] FIG. 2 is a block diagram for explaining an image storage device included in the system of FIG. 1, and FIG. 3 and FIG. 4 are drawings for explaining an embodiment in which an edge-type image storage solution for a cloud camera according to an embodiment of the present invention is implemented.
[0025] Referring to FIG. 2, the image storage device (200) may include a detection unit (210), an entry unit (220), a receiving unit (230), a local storage unit (240), a recovery synchronization unit (250), a management interface unit (260), a control unit (270), and an independent operation unit (280).
[0026] When an image storage device (200) according to one embodiment of the present invention or another server (not shown) operating in conjunction with it transmits an edge-type image storage solution application, program, app page, web page, etc. for a cloud camera to at least one camera (100) and at least one cloud server (400), the at least one camera (100) and at least one cloud server (400) may install or open an edge-type image storage solution application, program, app page, web page, etc. for a cloud camera. Additionally, a service program may be operated on at least one camera (100) and at least one cloud server (400) using a script executed in a web browser. Here, a web browser refers to a program that enables the use of web (WWW: World Wide Web) services and receives and displays hypertext described in HTML (Hyper Text Mark-up Language), and includes, for example, Chrome, Microsoft Edge, Safari, Firefox, Whale, UC Browser, etc. In addition, "application" refers to an application on a terminal, and includes, for example, an app running on a mobile terminal (smartphone).
[0027] Referring to FIGS. 2 and 3, the detection unit (210) can detect the network connection status. The detection unit (210) can determine the basic connection quality by periodically scanning the network connection status through ICMP Ping, TCP Handshake, Netstat, and eBPF-based network monitoring. Additionally, the detection unit (210) can check the response status between the cloud server (400) and the camera (100) by sending an HTTP / HTTPS Keep-Alive request using HTTP Keep-Alive, gRPC Health Check, and REST API Ping. Furthermore, the detection unit (210) can check the connection quality of the RTSP / ONVIF session between the camera (100) and the video storage device (200) and measure the packet loss rate and delay through RTSP OPTIONS / Ping, ONVIF Device Management, FFmpeg RTP Stats, and WebRTC ICE status analysis.
[0028] The detection unit (210) evaluates the possibility of network disconnection by integrating and analyzing collected signals (delay, packet loss, response failure) using EWMA (Exponentially Weighted Moving Average), a hysteresis-based thresholding algorithm, or a state machine. Additionally, the detection unit (210) may determine a disconnection only when a certain time accumulation condition is satisfied, using sliding window analysis, threshold debouncing, adaptive timeout algorithm, etc., to prevent false positives caused by temporary delay or packet loss. Then, the detection unit (210) transmits an event signal to the control unit (270) when the network is finally determined to be disconnected using MQ (RabbitMQ / MQTT), gRPC Event Push, internal Event Bus (Redis Pub / Sub), etc., and causes the control unit (270) to activate the local storage mode. In addition, the detection unit (210) can continue to monitor the network status and repeatedly check for reconnection using a continuous monitoring Daemon (Go / Python), Prometheus Node Exporter, Netdata Agent method, etc.
[0029] <EMWA 기반 알고리즘>
[0030] At this point, let us assume that network determination is based on EWMA (Exponentially Weighted Moving Average), among hysteresis-based thresholding algorithms or state machines. An EWMA-based algorithm for network disconnection determination may be structured to generate a stable disconnection judgment value that reflects recent trends by calculating network quality signals, such as Round Trip Time or Packet Loss, using EWMA. The EWMA mathematical formula is as follows.
[0031]
[0032] Here, Xt is the delay value (RTT) or packet loss rate at time t, St is the EWMA score at time t, St-1 is the previous EWMA score, and α represents the weight (0.1 to 0.3 recommended).
[0033] The disconnection determination rule is as follows: ① If the EWMA score exceeds the threshold and continues to exceed it for T seconds, it is determined to be a network disconnection.
[0034]
[0035] θ is the disconnection threshold, T is the minimum duration that must be maintained continuously, and Disconnect = 1 means network disconnection.
[0036] In summary, the system can be configured to check the network status of both directions—the edge device (200) and the cloud server (400), and the camera (100) and the image storage device (200)—by comprehensively checking the network status, eliminate false positives caused by temporary delays and losses using an EWMA-based algorithm, and then switch to local storage mode only when disconnected under stable conditions. Of course, it is obvious that various algorithms can be used in addition to the EWMA-based algorithm described above.
[0037] The entry section (220) can enter local storage mode when the network connection status is determined to be disconnected. At this time, local storage mode refers to an operation mode in which, when the network connection status is determined to be disconnected, the video storage device (200) connects to the camera (100) and directly circulates the received video to a local storage medium (HDD / SSD, etc.), while also managing metadata such as time information and hash information together for synchronization with the cloud server (400) when the network is restored later. In other words, it can be described as a mode in which the video storage device (200) acts as a temporary recorder instead of the cloud server (400).
[0038] At this time, basically, camera video transmission is performed by connecting the camera (100) to the cloud server (400) and then transmitting the camera video to the cloud server (400). When the network is disconnected, transmission between the two devices, namely the cloud server (400) and the camera (100), is naturally stopped, and the structure is such that the video storage device (200), which recognizes the disconnection, connects to the camera (100) to receive the video. Later, when the network connection is restored, the cloud server (400) connects to the camera (100) again to receive the video, and the video storage device (200) disconnects from the camera (100), connects to the cloud server (400), and sends the backed-up video.
[0039] The receiver (230) can receive video from at least one camera (100). At least one camera (100) can capture video. The receiver (230) operates to establish and maintain sessions for each camera (100) using video transmission protocols such as RTSP (Real-Time Streaming Protocol), HTTP (HyperText Transfer Protocol), and ONVIF (Open Network Video Interface Forum) for multiple cameras (100) in a video storage device (200) that has entered local storage mode. The receiver (230) is configured to divide the video stream received from each camera (100) into frames or GOP (Group of Pictures) units using a streaming library such as FFmpeg or GStreamer, store them in an internal buffer, and perform conversion between different codecs and formats such as H.264 and H.265 when necessary. Additionally, the receiver (230) aligns the times of frames flowing in from multiple cameras (100) by utilizing Network Time Protocol (NTP)-based time synchronization or timestamps within the stream, and performs time synchronization processing to match frames corresponding to the same point in time, thereby enabling frame consistency between cameras (100) to be maintained during the subsequent local storage and recovery synchronization stage.
[0040] In this context, H.264 is an Advanced Video Coding (AVC) standard widely used for efficiently compressing and transmitting video data, while H.265 is a High Efficiency Video Coding (HEVC) standard designed to transmit the same image quality at a lower bitrate with higher compression efficiency than H.264.
[0041] The local storage unit (240) can encrypt the received video and store it on a local storage medium. The local storage unit (240) records the video from the camera (100) received after the local storage mode is activated due to network disconnection in a circular manner on a local storage medium composed of an SSD (Solid State Drive), HDD (Hard Disk Drive), NVMe (Non-Volatile Memory Express), RAID (Redundant Array of Independent Disks), etc., and securely stores the data by applying symmetric key encryption such as AES-256 during the storage process, and the encryption key can be received and used from a separate key management module or secure storage. The local storage unit (240) uses FFmpeg, a file system driver, etc. to divide and store the video into files in frame or segment units, and for each segment, generates index information and a manifest file, such as SQLite, NoSQL, JSON, or Protobuf, together to manage the camera ID, time interval, hash value, etc., thereby enabling the rapid identification of missing time intervals (segments) during recovery.
[0042] <Creating and Recording Indexes>
[0043] At this time, when the video is stored in frame or segment units, the local storage unit (240) can generate index information based on the metadata of each segment and structure and record it on a local storage medium. The index information includes a camera identifier (ID), segment start time and end time, data offset, segment size, encryption status, hash value (SHA-256, etc.), storage priority, transmission status flag (not uploaded / uploaded / to be deleted), etc., and such index information can be stored in a table or Key-Value structure using SQLite, RocksDB, LevelDB, or a lightweight time-series database.
[0044] During the index creation process, the local storage unit (240) can normalize the timestamp of the original frame received from the receiving unit (230) to correct network delay or time error between cameras, and can automatically create index entries according to segment boundaries such as GOP units or fixed time units. The created index is sorted in chronological order and synchronized with a metadata file (manifest file) within the local storage medium, and is configured so that the recovery synchronization unit (250) can quickly identify missing segments when compared with the cloud server (400). Additionally, the index DB can apply Write-Ahead Logging (WAL) or memory buffering to reduce write delay, and is managed to automatically delete the oldest index entry or update the status flag when the storage capacity of the local storage medium exceeds a threshold.
[0045] Meanwhile, the local storage unit (240) monitors the storage capacity and applies a circular storage policy (similar to LRU (Least Recently Used) policy) that automatically overwrites the oldest segments first. It also dynamically determines which camera video to prioritize based on setting values such as camera priority and storage quality (bitrate / resolution). If necessary, it additionally stores video from a certain section prior to the disconnection point through a buffer or camera re-request to prevent missing sections on the time axis. Furthermore, it continuously exchanges this storage status and capacity information with the control unit to control the overall system operation.
[0046] Dynamic Determination of Storage Priority
[0047] At this time, prioritizing storage means determining the storage capacity and bitrate (bandwidth) by calculating a priority score for each camera (100) at every point in time and allocating storage capacity and bitrate (bandwidth) starting from the camera (100) with the highest priority score. For example, it may be as shown in Equation 3 below.
[0048]
[0049] At this time, Scorei is the priority score of camera i, and Pi is the default priority of the camera (100) set by the administrator, for example, grade 1 to grade 5. Qi is the storage quality level (a numerical value of the resolution, frame rate, and bitrate grades) assigned to the camera (100), Ei is the event importance score (intrusion detection, motion detection, alarm linkage status, etc.), Bi is the storage and bandwidth burden currently used by the camera (100) (a penalty value reflecting the capacity or bitrate already in use), and wp, wq, we, and wb represent weights for each item (coefficients tuned according to the characteristics of the workplace). Based on this priority score, the higher the priority score of the camera (100), the longer the section is saved with better quality.
[0050] process 1. Configuration value collection phase - On the administrator page, set the "Importance Grade (Entrance, Warehouse, Parking Lot, etc.)," default resolution (e.g., FHD, HD), default bitrate, minimum retention period, etc. for each camera. - These values become the default values for Pi and Qi in Equation 3. 2. Real-time event reflection - When motion is detected, an intrusion alarm is triggered, or a specific area event occurs on the camera, the corresponding camera's Ei value increases momentarily. - e.g., Ei is set to 0 when there is no movement, and Ei to 5 upon an intrusion alarm. 3. Reflect resource status -Based on current local storage usage and total bitrate limits, the burden when additional camera i is stored is calculated as Bi. -If the same camera is already storing a large amount of high-quality data, the design can be made to set Bi high to give other cameras a chance. 4. Calculation of Priority Score - Calculate Scorei for each camera i periodically (e.g., every 1 or 5 seconds). - At this time, wp, wq, we, and wb are adjusted according to policy. ▶ Set we high for security-focused sites. ▶ Set wp high for VIP areas. ▶ Set wb high for environments with tight storage capacity. 5. Determine storage priority and image quality - Allocate storage resources in order of highest priority score ▶ Top group: Save at original quality ▶ Middle group: Save with reduced resolution or bitrate ▶ Bottom group: Set to save only keyframes or save only when an event occurs - This automatically determines "which camera, at what quality, and for how long" to save. 6. Apply policy when capacity is insufficient - When the storage capacity of the local storage medium approaches a threshold, measures such as deleting old segments first (LRU policy), lowering image quality by one level, and reducing the retention period are applied first, starting with cameras with lower scores.
[0051] For example, in the case of a camera (100) that illuminates an entrance, Pi is high (important area) and events (people entering and exiting) occur frequently, so Ei increases frequently. Accordingly, the score is always maintained high, making it eligible for high-quality and long-term storage. On the other hand, in the case of a camera (100) that illuminates a small window at the end of a hallway, Pi is low and there are almost no events, so Ei is close to 0, and it can be controlled to basically be low-quality and short-term storage or stored only when an event occurs.
[0052] In summary, the priority of each camera (100), storage quality, event importance, and current resource burden are combined into a single priority score, and resources are allocated in the order of that priority score, thereby dynamically determining which camera (100)'s video to save first.
[0053] Encryption
[0054] Prior to storage according to the process described above, the local storage unit (240) is responsible for the entire process from the generation of encryption keys to storage, distribution, and decryption permission control in order to safely store and recover the video. For example, it generates and securely protects symmetric encryption keys such as AES-256 using a Hardware Security Module (HSM), TPM-based key storage, or software-based Key Management Service (KMS), and restricts access rights so that the generated encryption keys are used only within the video storage device (200). When a segment of the video is stored, the local storage unit (240) performs real-time encryption using encryption libraries such as FFmpeg, OpenSSL (Secure Sockets Layer), and Libsodium, and decryption is allowed restrictively according to internal policies (FSM (Finite State Machine), permission check, authentication token verification) only when a valid decryption request occurs within the local storage unit (240), thereby fundamentally blocking acts of direct access to or modification of the video from the outside.
[0055] In addition, the local storage unit (240) can continuously guarantee the security of the stored image by generating and managing hash values such as SHA-256 to verify the integrity of the encrypted segment, and by controlling the key to maintain compatibility between the previous key and the new key while periodically updating the key according to the key rotation policy. Of course, it is obvious that encryption and decryption can be performed in various ways other than the method described above.
[0056] The recovery synchronization unit (250) can selectively upload only the missing segments by comparing the data stored on the local storage medium with the data stored on the cloud server (400) when the network connection status is switched to a connected state. The cloud server (400) can receive the uploaded video. After selectively uploading the missing segments to the cloud server (400), the recovery synchronization unit (250) receives an integrity verification result for the uploaded segments from the cloud server (400), and can delete the segments for which integrity verification is complete from the local storage medium or move them to a backup area. The cloud server (400) can classify and store the data by at least one camera (100), identify the missing segments by referring to the hash index information of the local storage medium, and verify the integrity of the uploaded segments.
[0057] That is, when the network is restored, the recovery synchronization unit (250) first calls the metadata API of the cloud server (400) to query the index information (camera ID, start / end time, hash value, file ID, etc.) of the video segment (stored data) stored in the cloud server (400), and simultaneously reads the stored data built on the local storage medium, e.g., index / manifest (DB: SQLite, PostgreSQL, RocksDB, etc.), sorts it according to the same criteria, and then compares the two indices to calculate only the list of missing segments based on the time interval and hash value. In this way, the recovery synchronization unit (250) performs sequential or parallel uploads for the identified missing segments using an HTTPS-based REST API (Representational State Transfer Application Programming Interface), gRPC (Google Remote Procedure Call), or S3 (Simple Storage Service) compatible storage protocol, and controls the upload process to minimize network load and transmission failure by applying bandwidth control such as token bucket or transmission window adjustment and retry logic such as exponential backoff.
[0058] At this time, Token Bucket is a traffic control algorithm that limits the overall average bandwidth while allowing instantaneous bursts by filling tokens at a certain rate and consuming tokens when transmitting packets, and Transmission Window Control is a flow and congestion control method that reduces packet loss and efficiently uses bandwidth by detecting network congestion and dynamically increasing or decreasing the amount of data (window size) that can be transmitted at once. Exponential Backoff is an algorithm that attempts retransmission stably without overloading the network or cloud server (400) by retrying with the retry interval gradually increasing, such as 2 times, 4 times, and 8 times, when a transmission failure or error occurs.
[0059] When the upload is completed in this way, the cloud server (400) recalculates the hash for each segment using SHA-256 or the like to check whether it matches the original hash value recorded in the local index, and responds the verification result to the recovery synchronization unit (250). The recovery synchronization unit (250) can process the segments by linking with the control unit (270) to delete the segments from the local storage medium or move them to a backup partition, NAS, or object storage for long-term storage according to the policy, only for the segments for which verification was successful.
[0060] Referring to FIG. 4, the management interface unit (260) can monitor and display the network connection status, local storage media storage capacity, synchronization progress to the cloud server (400), and the connection status of at least one camera (100). That is, the management interface unit (260) is a front-end and back-end interlocking module that allows a system operator or cloud user to view status information such as the network connection status, local storage media storage capacity, synchronization progress to the cloud server (400), and connection status of each camera (100) through a web browser or mobile application, and to issue control commands.
[0061] At this time, the frontend is implemented as a web UI framework such as React, Vue.js, Angular, or an iOS / Android native or Flutter-based app, and the backend is configured as a REST API or gRPC server (Spring Boot, Node.js / NestJS, FastAPI, etc.) to communicate with the control unit (270) and collect and display real-time status data (Prometheus, WebSocket, Server-Sent Events, etc.). When a user inputs commands such as manual synchronization execution, storage schedule (backup time, retention period), or storage policy change per camera (100) into the interface, the management interface unit (260) transmits these commands to the control unit (270) to trigger operations such as the local storage unit (240) and the recovery synchronization unit (250), and at the same time, by applying security technologies such as OAuth 2.0, OpenID Connect, and RBAC for authentication and authorization management, only users who have remotely accessed the cloud server (400) or the video storage device (200) can safely perform monitoring and control functions.
[0062] The control unit (270) can perform uploads according to the preset priority, bandwidth, and retention period of at least one camera (100) when selectively uploading only the missing segments from the recovery synchronization unit, and can control the amount of recovery processing based on the network bandwidth by measuring the network bandwidth in real time. That is, the control unit (270) is a central processing unit of the image storage device (200) and can be configured to collect and manage real-time events such as network disconnection, local storage medium storage capacity warning, and recovery completion, and to control signal flow and state transitions between each component, such as the detection unit (210), entry unit (220), receiving unit (230), local storage unit (240), recovery synchronization unit (250), and management interface unit (260), in a Finite State Machine structure.
[0063] Additionally, the control unit (270) uses an internal event bus (Redis Pub / Sub, gRPC, message queue, etc.) to route events between each component and uses a Quartz or Cron-based task scheduler to perform periodic status checks, synchronization tasks, and capacity checks. During the recovery process, it calculates a priority score based on the priority, retention period, and set storage quality information for each camera (100), and then determines which camera's segment to upload first according to the priority score. Additionally, the control unit (270) uses a network measurement library and a system API to measure the current upload / download bandwidth, latency, and packet loss rate in real time, and dynamically instructs the recovery synchronization unit (250) to allow the number of simultaneous uploads, segment size, and transmission speed upper limit according to the previously calculated priority score and network status, thereby automatically adjusting the recovery throughput without overloading the network line or cloud server (200).
[0064] The independent operation unit (280) can ensure that when the network connection status is connected, the video of at least one camera (100) is transmitted directly to the cloud server (400) without acting as a relay between at least one camera (100) and the cloud server (400). That is, when the independent operation unit (280) determines from the detection unit (210) that the network connection status is [connected], the video storage device (200) does not relay or proxy video streams such as RTSP (Real-Time Streaming Protocol), HTTP (HyperText Transfer Protocol), or ONVIF (Open Network Video Interface Forum) between the camera (100) and the cloud server (400), but instead directly sets and maintains the stream destination address of the camera (100) as an endpoint such as the RTSP / HTTPS ingest URL of the cloud server (400) through a provisioning API (REST API, gRPC, etc.) and a camera (100) configuration interface (ONVIF Device Management, vendor-specific CGI / API (Common Gateway Interface / Application Programming Interface)).
[0065] At this time, the video storage device (200) collects only minimal metadata and health check information for status monitoring when necessary and configures network routing, firewall, and VPN (Virtual Private Network) settings (SDN (Software-Defined Networking) switch, IP routing table, TLS (Transport Layer Security) tunnel, etc.) so as not to intervene in the actual video path, so that in a normal connection state, it operates as a direct transmission structure between the camera (100) and the cloud server (400).
[0066] Basically, as described above, the camera (100) is in a state of constant standby for connection, and after the cloud server (400) connects to the camera (100), the video from the camera (100) is transmitted to the cloud server (400). When the network is disconnected, transmission between the two devices is naturally stopped, and at this time, the video storage device (200), having recognized the disconnection, connects to the camera (100) to receive the video. Subsequently, when the network connection is restored, the cloud server (400) connects to the camera (100) again to receive the video, and the video storage device (200) disconnects from the camera (100), connects to the cloud server (400), and sends the backed-up video. That is, the image storage device (200) is an independent device from the camera (100) or the cloud server (400), and can perform this function if it only knows the IPs of the camera (100) and the cloud server (400), and can be implemented without complex processing such as separate camera (100) control or routing configuration. Since the original purpose is to apply it without major changes to the general existing camera (100) or cloud server (400), the configuration of the independent operation unit (280) is an example of a case where the image storage device (200) takes the lead in managing the connection function of the camera (100) in detail.
[0067] Network Routing Structure
[0068] A network routing structure according to one embodiment of the present invention is configured such that a camera (100) establishes a basic path to transmit video to an RTSP / HTTP ingest endpoint of a cloud server (400) by directly connecting to the internet through a gateway of a local network, and a video storage device (200) communicates with the camera (100) and the cloud server (400) using only a separate management IP range and port (for health check, configuration / monitoring), thereby ensuring that the video storage device (200) does not intervene as a router, bridge, or NAT device in the video traffic path of the [camera (100) → cloud server (400)] section during normal operation. To this end, the control unit (270) fixes the network path so that video stream packets of the camera (100) are transmitted directly to the cloud server (400) without passing through the video storage device (200) through routing tables, SDN policies of the switch / router, firewall and VLAN settings, etc., and at the same time, within the video storage device (200), it disables transparent proxy or reverse proxy functions for RTSP / HTTP / ONVIF traffic and restricts the video to establish a direct session with the camera (100) only in local storage mode when the network connection is disconnected, thereby allowing the video storage device (200) to perform only network status monitoring and subsequent recovery functions without operating as a relay / proxy device such as an NVR in a normal state.
[0069] A system according to one embodiment of the present invention can minimize image loss of the camera (100) by having the image storage device (200) store the image of the camera (100) on a local storage medium even when the network is disconnected, automatically transmitting and recovering only the missing sections after the network is restored, and securing images from a certain period prior to the disconnection. In addition, when the network is normal, the image is transmitted directly between the camera (100) and the cloud server (400), so the image storage device (200) does not perform separate relay and transmission, thereby providing a missing recovery function without placing an additional load on the existing installed camera (100) and network. Furthermore, since the system according to one embodiment of the present invention has a structure for installing an edge-type device independent of the existing cloud system, it can be easily installed and applied without changing the configuration of the existing camera (100) or cloud server (400). It is designed with a simple structure specialized for storage functions, making it easy to expand storage capacity and storage-based functions, and allows for economical operation by selecting only the necessary functions without complex settings.
[0070] Furthermore, the system according to one embodiment of the present invention significantly improves the efficiency of storage usage and network transmission volume by selectively transmitting only the missing segments during recovery, and enables an economical image storage and recovery environment without expanding the storage devices of individual cameras (100) by managing multiple cameras (100) in an integrated manner in a single image storage device (200). This reduces the maintenance costs of the entire system and increases operational efficiency. In the future, it is advantageous to expand into an integrated storage and analysis platform by storing and linking not only image data but also metadata, artificial intelligence analysis results, and event data from other security systems. Additionally, the operation of the image storage device (200) can be easily controlled remotely through cloud server (400) side settings and a web / mobile application-based management interface.
[0071] As for the details regarding the method of providing an edge-type image storage solution for a cloud camera shown in FIGS. 2 to 4 that are not described, they are identical to or can be easily inferred from the details described above regarding the method of providing an edge-type image storage solution for a cloud camera shown in FIG. 1, so further explanation will be omitted.
[0072] FIG. 5 is a diagram illustrating the process of transmitting and receiving data between each component included in the edge-type image storage system for a cloud camera of FIG. 1 according to an embodiment of the present invention. Hereinafter, an example of the process of transmitting and receiving data between each component will be described through FIG. 5, but the present invention is not to be interpreted as being limited to such an embodiment, and it is obvious to those skilled in the art that the process of transmitting and receiving data illustrated in FIG. 5 may be changed according to various embodiments described above.
[0073] Referring to FIG. 5, the image storage device detects the network connection status (S5100).
[0074] And, when the network connection status is determined to be disconnected, the video storage device enters local storage mode (S5200) and receives video from at least one camera (S5300).
[0075] Additionally, the video storage device encrypts the received video and stores it on a local storage medium (S5400), and when the network connection status is switched to a connected state, it compares the data stored on the local storage medium with the data stored on the cloud server and selectively uploads only the missing segments (S5500).
[0076] The order of the steps described above (S5100~S5500) is merely an example and is not limited thereto. That is, the order of the steps described above (S5100~S5500) may vary, and some of these steps may be executed simultaneously or deleted.
[0077] As for the details regarding the method of providing an edge-type video storage solution for a cloud camera shown in Fig. 5 that are not described, they are identical to or can be easily inferred from the details described above regarding the method of providing an edge-type video storage solution for a cloud camera shown in Figs. 1 to 4, so further explanation will be omitted.
[0078] The method for providing an edge-type image storage solution for a cloud camera according to one embodiment described through FIG. 5 may also be implemented in the form of a recording medium containing computer-executable instructions, such as an application or program module executed by a computer. The computer-readable medium may be any available medium accessible by a computer and includes both volatile and non-volatile media, and both removable and non-removable media. Additionally, the computer-readable medium may include all computer storage media. The computer storage medium includes both volatile and non-volatile, removable and non-removable media implemented by any method or technique for storing information such as computer-readable instructions, data structures, program modules, or other data.
[0079] The method for providing an edge-type image storage solution for a cloud camera according to one embodiment of the present invention described above may be executed by an application basically installed on a terminal (which may include a program included in a platform or operating system, etc., basically installed on the terminal), or may be executed by an application (i.e., a program) directly installed by a user on a master terminal through an application providing server, such as an application store server, an application, or a web server related to the service. In this sense, the method for providing an edge-type image storage solution for a cloud camera according to one embodiment of the present invention described above may be implemented as an application (i.e., a program) that is basically installed on a terminal or directly installed by a user, and may be recorded on a computer-readable recording medium such as a terminal.
[0080] The foregoing description of the present invention is for illustrative purposes only, and those skilled in the art will understand that other specific forms can be easily modified without altering the technical spirit or essential features of the present invention. Therefore, the embodiments described above should be understood as illustrative in all respects and not restrictive. For example, each component described as a single unit may be implemented in a distributed manner, and components described as distributed may likewise be implemented in a combined form.
[0081] The scope of the present invention is defined by the claims set forth below rather than by the detailed description above, and all modifications or variations derived from the meaning and scope of the claims and equivalent concepts thereof should be interpreted as being included within the scope of the present invention.
Claims
Claim 1 An edge-type video storage system for a cloud camera comprising: at least one camera for capturing video; a cloud server for receiving uploaded video; and a video storage device comprising: a detection unit for detecting a network connection status; an entry unit for entering a local storage mode when the network connection status is determined to be disconnected; a receiving unit for receiving video from the at least one camera; a local storage unit for encrypting the received video and storing it in a local storage medium; a recovery synchronization unit for selectively uploading only missing segments by comparing the data stored in the local storage medium with the data stored in the cloud server when the network connection status is switched to a connected state; and a control unit for performing the upload according to the preset priority, bandwidth, and retention period of the at least one camera when the recovery synchronization unit selectively uploads only the missing segments, and controlling the amount to be recovered based on the network bandwidth by measuring the bandwidth of the network in real time. Claim 2 An edge-type video storage system for a cloud camera according to claim 1, wherein the recovery synchronization unit selectively uploads the missing segment to the cloud server, receives an integrity verification result for the uploaded segment from the cloud server, and deletes the segment for which the integrity verification is completed from the local storage medium or moves it to a backup area. Claim 3 An edge-type video storage system for a cloud camera according to claim 1, wherein the video storage device further comprises a management interface unit that monitors and displays the network connection status, the storage capacity of the local storage medium, the synchronization progress to the cloud server, and the connection status of at least one camera. Claim 4 delete Claim 5 An edge-type video storage system for a cloud camera according to claim 1, wherein the cloud server classifies and stores the storage data by at least one camera, identifies missing segments by referring to the hash index information of the local storage medium, and verifies the integrity of the uploaded segments. Claim 6 An edge-type image storage system for a cloud camera according to claim 1, further comprising: an independent operation unit that, when the network connection state is connected, does not act as a relay between the at least one camera and the cloud server and allows the image of the at least one camera to be directly transmitted to the cloud server.