Campus video call machine cloud device centralized remote monitoring configuration platform

Abstract

The present application belongs to the technical field of communication monitoring, and discloses a centralized remote monitoring configuration platform for a cloud device of a campus video call machine, comprising: obtaining a cloud configuration task, analyzing a device identification set and a configuration package, calculating a batch threshold, and dividing an ordered batch queue; establishing a multiplexing channel, segmenting and encoding the configuration package, and adding an identification and a check code, forming a segment sequence and pushing the segment sequence to each device in parallel; receiving segment confirmation information returned by the device, independently tracking the receiving progress and constructing a mapping table, recording the missing device and segment sequence into a set of to-be-supplemented transmission, generating a supplementary transmission instruction after the pushing is completed, and retransmitting the missing segment through the multiplexing channel, triggering a write operation after the device completely receives, collecting the confirmation information and updating the batch state; releasing the channel resource after the batch is completed and polling the next batch until all tasks are completed, and generating a report and pushing the report to the cloud; and greatly improving the overall management and control efficiency of the campus video call machine device cluster.

Description

Technical Field

[0001] This invention relates to the field of communication monitoring technology, and more specifically, to a centralized remote monitoring and configuration platform for campus video call devices in the cloud. Background Technology

[0002] With the continuous advancement of smart campus construction and the increasing demand for home-school communication, campus video call devices, as important terminal equipment for students and parents to communicate remotely, have been deployed on a large scale in various schools. These devices are usually distributed in multiple locations on campus, providing students with convenient video call services. To ensure the normal operation of the device group, school administrators need to rely on the cloud management backend to remotely monitor, configure parameters, and maintain the faults of the dispersed video call devices.

[0003] Existing cloud-based management systems for campus video intercom devices have technical deficiencies in handling concurrent processing and synchronizing configuration data across multiple devices. This issue is particularly pronounced in campus deployments with large-scale equipment. Specifically, when the management backend needs to send configuration update commands to multiple video intercom devices simultaneously, the cloud server needs to establish an independent data transmission channel for each target device and maintain the connection until the configuration is written. As the number of concurrent devices increases, the server's connection resource consumption and data processing load increase exponentially, leading to a significant increase in the response latency of configuration commands and making the response order unpredictable. More importantly, due to the differences in the time points at which each terminal device completes the configuration update, the cloud management backend cannot accurately determine the overall completion status of a batch of configuration tasks. When some devices experience configuration reception interruptions due to network jitter, the management backend lacks an effective mechanism for resuming interrupted transmissions and coordinating retrying failures. Often, maintenance personnel need to check the actual configuration version of each device to discover synchronization discrepancies. This uncertainty in configuration status means that subsequent batch management operations are based on unreliable data, increasing the workload of maintenance personnel and affecting the overall management efficiency and configuration consistency assurance capabilities of the campus video intercom device cluster.

[0004] In view of this, the present invention proposes a centralized remote monitoring and configuration platform for campus video call devices in the cloud to solve the above problems. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art and to achieve the above objectives, the present invention provides the following technical solution: a centralized remote monitoring and configuration platform for campus video call devices in a cloud environment, comprising: Batch partitioning management module: Obtains configuration task requests from the cloud management backend, parses the set of device identifiers to be configured and the configuration data packet, calculates the batch capacity threshold based on the size of the device identifier set and the current load status of the cloud server, and divides the device identifier set into an ordered configuration batch queue based on the batch capacity threshold. Parallel push encoding module: For the current batch in the configuration batch queue, a batch-level multiplexing transmission channel is established. The configuration data packet is segmented and encoded, and a segment sequence identifier and check code are added to form a configuration segment sequence. The configuration segment sequence is pushed to each device in the batch in parallel through the batch-level multiplexing transmission channel. Receive tracking and recording module: Receive segment reception confirmation information returned by each video call device, independently track the reception progress of each device according to the segment sequence identifier, build a batch reception progress mapping table, and when a device is found to have missing segment reception confirmation information, the device and its missing segment sequence are recorded in the set to be retransmitted. Missing segment retransmission module: After the configuration segment sequence of the current batch is pushed, a retransmission instruction is generated according to the set to be retransmitted. The missing segment sequence is retransmitted through the batch-level multiplexed transmission channel. After each device has completed receiving all configuration segments, the configuration write operation on the device side is triggered. The write completion confirmation returned by the device is collected and the batch configuration status record is updated. Channel release polling module: If the batch configuration status record of the current batch reaches the completion condition, release the batch-level multiplexing transmission channel resources, move the pointer of the configuration batch queue to the next batch, and repeat the operation of parallel push encoding module to missing direction supplementary transmission module until the entire configuration batch queue is processed, generate configuration task completion report and push it to the cloud management backend.

[0006] The technical effects and advantages of this invention's centralized remote monitoring and configuration platform for campus video call devices on the cloud: The invention dynamically calculates the batch capacity threshold based on the size of the device identifier set and the current load status of the cloud server, dividing the devices to be configured into ordered configuration batch queues. This achieves reasonable distribution of configuration tasks, avoiding server connection resource exhaustion and processing overload due to an excessive number of concurrent devices, and effectively controlling the response latency of configuration commands. By establishing a batch-level multiplexed transmission channel and segmenting and encoding the configuration data packets, each configuration segment is assigned a segment sequence identifier and a checksum, ensuring both the integrity verification capability of data transmission and providing accurate positioning basis for subsequent reception progress tracking. The reception progress of each device is independently tracked based on the segment sequence identifier, and a batch reception progress mapping table is constructed, enabling the cloud management backend to monitor the configuration reception status of each device within the batch in real time, solving the problem that existing systems struggle to accurately determine the overall completion status of batch configuration tasks. When a device is detected... When a segment reception confirmation is missing, the device and its missing segment sequence are added to the retransmission set and retransmitted in a targeted manner. This achieves a segment-level breakpoint resumption mechanism, avoiding the need for overall retransmission due to network jitter-induced configuration reception interruptions, significantly reducing network resource consumption and configuration synchronization time. After each device completes the reception of all configuration segments, a unified configuration write operation is triggered and a write completion confirmation is collected to ensure the consistency of configuration versions within the batch. Through the completion condition judgment of the batch configuration status record and the timely release of channel resources, the orderly rotation processing of configuration batches is realized. Finally, a configuration task completion report containing the total number of successful tasks, the total number of failures, and a failure details table is generated, providing maintenance personnel with a complete view of configuration execution results. This eliminates the manual burden of checking the configuration version of each device and improves the overall management efficiency and configuration consistency assurance capability of the campus video call device cluster. Attached Figure Description

[0007] Figure 1 This is a schematic diagram of the centralized remote monitoring and configuration platform for campus video call devices in the cloud, as described in this invention. Detailed Implementation

[0008] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Example

[0009] Please see Figure 1 As shown, the centralized remote monitoring and configuration platform for campus video call devices in this embodiment includes: Batch partitioning management module: Obtains configuration task requests from the cloud management backend, parses the set of device identifiers to be configured and the configuration data packet, calculates the batch capacity threshold based on the size of the device identifier set and the current load status of the cloud server, and divides the device identifier set into an ordered configuration batch queue based on the batch capacity threshold.

[0010] When campus administrators initiate a configuration update operation through the cloud-based management backend, the backend generates a configuration task request and sends it to the cloud server. The configuration task request includes fields such as a task identifier, a set of device identifiers to be configured, a configuration data package, and a task priority. Each device identifier in the device identifier set corresponds to a registered video call device on campus; device identifiers are typically the device's factory serial number or an internal campus number. The configuration data package is a binary configuration file containing all configuration items that need to be updated and their target values.

[0011] Existing systems typically employ a full-scale concurrent approach to establish connections and distribute configuration data to all target devices simultaneously when handling large-scale device configuration tasks. This approach quickly exhausts the connection pool resources of the cloud server when dealing with a large number of devices. Furthermore, the massive concurrent data transmission causes server network bandwidth congestion, ultimately resulting in significantly prolonged configuration response latency and even connection timeouts for some devices. This solution dynamically calculates batch capacity thresholds and divides the device set into ordered batch queues to achieve batch processing of configuration tasks, effectively controlling the number of concurrent connections and data processing load on the server at any given time.

[0012] Preferably, in some possible implementations of the embodiments of the present invention, the method for calculating the batch capacity threshold includes: The available connection pool capacity and the current number of active connections of the cloud server are obtained, and the difference between the available connection pool capacity and the current number of active connections is used as the remaining connection quota. The connection pool capacity of the cloud server is determined by the server hardware configuration and operating system parameters. In this embodiment, the available connection pool capacity of the cloud server is set to 1000 concurrent connections. This value is determined according to the hardware specifications used by the server, and the range is usually between 500 and 2000 connections. The current number of active connections is obtained in real time through the server's connection management component, reflecting the connection resources occupied by other tasks currently being processed by the server. For example, if the current number of active connections is 150, then the remaining connection quota is 1000 minus 150, which equals 850.

[0013] The total number of bytes in the configuration data packet is obtained and compared with the preset single-device transmission bandwidth allocation value. The ratio of the total number of bytes to the single-device transmission bandwidth allocation value is used as the estimated transmission time for a single device. The total number of bytes in the configuration data packet is obtained by reading the configuration file size. The single-device transmission bandwidth allocation value is a preset parameter, set to 50KB / s in this embodiment. This value is determined based on the average uplink bandwidth of the campus network environment and the device's receiving capability, and its range is from 20KB / s to 100KB / s. If the configuration data packet size is 500KB, then the estimated transmission time for a single device is 500 divided by 50, which equals 10 seconds.

[0014] The remaining connection quota is multiplied by a preset connection security factor to obtain the number of secure connections. The connection security factor is a preset parameter, set to 0.8 in this embodiment. This factor is used to reserve some connection resources to cope with sudden requests and system maintenance needs, and its value ranges from 0.6 to 0.9. If the remaining connection quota is 850, then the number of secure connections is 850 multiplied by 0.8, which equals 680.

[0015] The number of secure connections is correlated with the estimated transmission time per device. When the estimated transmission time per device exceeds a preset threshold, the number of secure connections is proportionally reduced, and the reduced value is used as the batch capacity threshold. In this embodiment, the preset threshold is set to 15 seconds. This value is determined based on the user's expectations for configuration response speed and network timeout settings, and ranges from 10 to 30 seconds. When the estimated transmission time per device exceeds 15 seconds, it indicates that the configuration data packet is large, and each device occupies a connection for a long time. Therefore, the number of devices processed in a single batch needs to be reduced to avoid prolonged occupation of connection resources. The reduction ratio is calculated as the ratio of the preset threshold to the estimated transmission time per device. For example, if the estimated transmission time per device is 20 seconds, the reduction ratio is 15 divided by 20, which equals 0.75. The batch capacity threshold is 680 multiplied by 0.75, which equals 510 connections. When the estimated transmission time per device is less than or equal to the preset threshold, the number of secure connections (680) is used as the batch capacity threshold.

[0016] Based on the original order of the device identifiers in the device identifier set, the device identifier set is sequentially divided into several subsets according to the batch capacity threshold. Each subset is then numbered in the order of division and forms a configuration batch queue. For example, if the total number of devices to be configured is 200 and the batch capacity threshold is 80, the device identifier set is divided into three subsets: the first subset contains the identifiers of devices 1 to 80, the second subset contains the identifiers of devices 81 to 160, and the third subset contains the identifiers of devices 161 to 200. Each subset is numbered in the order of division as Batch 1, Batch 2, and Batch 3, forming the configuration batch queue.

[0017] Through the batch division mechanism described above, this solution achieves reasonable distribution of configuration tasks, avoids server resource overload caused by full concurrency, and ensures the predictability of device processing order, laying the foundation for subsequent configuration status tracking.

[0018] Parallel push encoding module: For the current batch in the configuration batch queue, a batch-level multiplexing transmission channel is established. The configuration data packet is segmented and encoded, and a segment sequence identifier and check code are added to form a configuration segment sequence. The configuration segment sequence is pushed to each device in the batch in parallel through the batch-level multiplexing transmission channel.

[0019] Existing systems typically establish independent transmission channels for each device when distributing configuration data to multiple devices. This approach leads to a linear increase in channel establishment and maintenance overhead with the number of devices. This solution introduces the concept of batch-level multiplexed transmission channels, allowing all devices within the same batch to share a single logical transmission channel. Sub-channel identifiers distinguish the data streams of different devices, significantly reducing channel management overhead. Simultaneously, configuration data packets are segmented and encoded, with each segment appended a sequence number and checksum, making the transmission process traceable and verifiable, providing technical support for breakpoint resume functionality.

[0020] Preferably, in some possible implementations of the embodiments of the present invention, the method for establishing a batch-level multiplexed transmission channel includes: Based on the number of devices in the current batch and the cloud server's port allocation strategy, a set of consecutive port ranges is selected as the channel port group. A unified batch-level multiplexed transmission channel is established on the channel port group, and a unique channel identifier is assigned to each channel. The cloud server pre-configures available port ranges; in this embodiment, the available port range is 10000 to 20000. The port allocation strategy adopts a sequential allocation method, with each batch-level multiplexed transmission channel occupying a number of consecutive ports. The number of ports is determined based on the number of devices in the batch, calculated at a ratio of 1 port for every 10 devices, with a minimum allocation of 2 ports and a maximum allocation of 20 ports. For example, if the current batch contains 80 devices, then 8 consecutive ports are allocated. If the smallest available port number is 10050, then the channel port group is 10050 to 10057. The channel identifier is generated using UUID format to ensure global uniqueness.

[0021] The configuration data packet is sequentially divided according to a preset segment length upper limit to obtain several configuration data segments, and each configuration data segment is assigned an incremental segment number. The preset segment length upper limit is set to 4KB in this embodiment. This value is determined based on the optimal data packet size for network transmission and the device's receive buffer capacity, and ranges from 2KB to 8KB. For example, if the configuration data packet size is 500KB, it will be divided into 125 configuration data segments, with the first 124 segments each being 4KB in size, and the last segment being 500 - 124 multiplied by 4 equal to 4KB. The segment numbers for each configuration data segment are 1, 2, 3, up to 125.

[0022] For each configuration data segment, a cyclic check value is calculated for its content and appended to the end of the configuration data segment. The segment sequence number and channel identifier are encapsulated into a segment header and appended to the beginning of the configuration data segment, forming a complete encoded configuration segment. The cyclic check value is calculated using the CRC32 algorithm, generating a 4-byte checksum used by the device to verify the integrity of the received data. The segment header contains a 2-byte segment sequence number field, a 16-byte channel identifier field, and a 2-byte segment length field, totaling 20 bytes. The structure of the encoded configuration segment is: 20-byte segment header information + configuration data segment content (maximum 4096 bytes) + 4-byte cyclic check value; the maximum length of a single encoded configuration segment is 4120 bytes.

[0023] All coded configuration segments are arranged in ascending order of segment number to form a configuration segment sequence, and the total number of segments and channel identifiers in the configuration segment sequence are recorded. The configuration segment sequence serves as the data source for subsequent pushes to the device, and the total number of segments is used by the device to determine whether the configuration data has been received completely.

[0024] Preferably, in some possible implementations of the embodiments of the present invention, the method of pushing configuration segment sequences to each device in a batch in parallel includes: On the batch-level multiplexed transmission channel, each video call device in the batch is assigned a unique device sub-channel identifier, and the correspondence between the device identifier and the device sub-channel identifier is recorded in the channel mapping table. The device sub-channel identifier is in 2-byte integer format, starting from 1 and incrementing. For example, if there are 80 devices in the batch, the device sub-channel identifiers will be 1 to 80. The channel mapping table is stored in a key-value pair structure, where the key is the device sub-channel identifier and the value is the corresponding device identifier.

[0025] Encoded configuration segments are sequentially extracted from the configuration segment sequence. A target device sub-channel identifier field is appended to the header information of each encoded configuration segment to form a directional configuration segment. The target device sub-channel identifier field occupies 2 bytes, and after appending, the header information of the directional configuration segment becomes 22 bytes long.

[0026] The same coded configuration segment is copied into directional configuration segment copies equal to the number of devices in the batch, and the corresponding device sub-channel identifiers are filled in for each copy. For example, the data segment with coded configuration segment number 1 needs to be copied 80 times, and device sub-channel identifiers 1 to 80 are filled in respectively to form 80 directional configuration segment copies.

[0027] All targeted configuration segment copies are grouped according to segment sequence number. Targeted configuration segment copies with the same sequence number are sent in parallel, and the corresponding targeted configuration segments are simultaneously pushed to each video call device within the batch through a batch-level multiplexed transmission channel. Parallel sending employs a multi-threaded scheduling method, with each thread responsible for sending the targeted configuration segment with the current sequence number to one device. After each group of targeted configuration segment copies is sent, a sending timestamp is recorded, and an acknowledgment waiting timer corresponding to that sequence number is started. The timeout period for the acknowledgment waiting timer is set to 5 seconds in this embodiment. This value is determined based on the average round-trip latency of the campus network and the allowed retransmission waiting time, ranging from 3 to 10 seconds.

[0028] Through the above-mentioned segmented encoding and parallel push mechanism, this solution achieves fine-grained transmission management of configuration data. Each data segment can be tracked and verified independently, providing a technical foundation for subsequent reception progress monitoring and missing segment retransmission.

[0029] The receiving tracking module receives segment reception confirmation information returned by each video call device, independently tracks the reception progress of each device according to the segment sequence identifier, constructs a batch reception progress mapping table, and when a device is found to have missing segment reception confirmation information, records the device and its missing segment sequence into the set to be retransmitted.

[0030] Existing systems lack a full-link tracking mechanism for the configuration distribution process, making it impossible to accurately identify which devices have successfully received configuration data and which devices have experienced reception interruptions. This solution addresses this by establishing an independent reception progress record for each device, tracking the reception confirmation status of each data segment in real time, and precisely locating the devices and specific segment sequences where reception is missing, thus providing accurate data support for targeted retransmission.

[0031] Preferably, in some possible implementations of the embodiments of the present invention, the method for constructing the batch receiving progress mapping table includes: For each video call device within a batch, an independent reception progress record is created. This record includes the device identifier, the set of confirmed segment sequences, and the last confirmation timestamp. The set of confirmed segment sequences is initialized to an empty set, and the last confirmation timestamp is initialized to the start time of the current batch. The reception progress record is stored in a structured data format for easy retrieval and updating.

[0032] After receiving the directional configuration segment, the video call device first verifies the data integrity based on the cyclic checksum at the end of the segment. If the verification passes, the configuration segment is cached locally, and a segment reception confirmation message is returned to the cloud server. The segment reception confirmation message includes the device sub-channel identifier, the received segment sequence number, and the reception timestamp.

[0033] When a segment reception confirmation message is received from a video call device, the device sub-channel identifier and the received segment sequence number are extracted from the confirmation message. The device sub-channel identifier is then converted to a device identifier based on the channel mapping table. The channel mapping table lookup operation uses a hash index to ensure efficient conversion.

[0034] In the corresponding receiving progress record, the received segment number is added to the confirmed segment set, and the current time is updated to the last confirmation timestamp. The confirmed segment set is stored using a bitmap structure, where each segment number corresponds to a binary bit. After receiving confirmation, the corresponding bit is set to 1. This structure can efficiently support subsequent segment sequence comparison operations.

[0035] All receiving progress records within a batch are aggregated into a batch receiving progress mapping table, which also indicates the total number of configuration segment sequences. This batch receiving progress mapping table serves as the core data structure for batch configuration status, allowing operations and maintenance personnel to view the configuration receiving progress of each device in real time.

[0036] Preferably, in some possible implementations of the embodiments of the present invention, the method for generating the set to be supplemented includes: For each receiving progress record in the batch receiving progress mapping table, the set of confirmed segment numbers is compared with the complete segment number set of the configured segment sequence to obtain the set of unconfirmed segment numbers. The comparison operation is implemented through bitmap XOR operation. All bitmaps corresponding to the complete segment number set are set to 1. After XORing with the bitmap of the confirmed segment number set, the positions with a value of 1 in the resulting bitmap correspond to the unconfirmed segment numbers.

[0037] For a reception progress record item whose unconfirmed segment sequence number set is not empty, check whether the interval between its last confirmation timestamp and the current time exceeds a preset confirmation timeout threshold. In this embodiment, the confirmation timeout threshold is set to 30 seconds. This value is determined based on the maximum round-trip latency of the campus network and a reasonable waiting tolerance, ranging from 15 to 60 seconds. If the interval exceeds the confirmation timeout threshold, it indicates that the device has not returned any new segment reception confirmation within the timeout period, suggesting a reception interruption or network anomaly. In this case, the device identifier corresponding to the reception progress record item is combined with the unconfirmed segment sequence number set to form a retransmission entry, and the retransmission entry is added to the retransmission set. If the interval does not exceed the confirmation timeout threshold, continue waiting for the device's reception confirmation information.

[0038] After all devices in the batch have completed the comparison and timeout determination, the retransmission entries in the retransmission set are merged and organized according to the device identifier to ensure that all missing segments of the same device are merged into one retransmission entry.

[0039] Through the aforementioned reception tracking mechanism, this solution achieves precise monitoring of the configuration distribution process, enabling timely detection of devices with reception anomalies and specific missing data segments. This provides accurate target information for subsequent targeted retransmission, avoiding the inefficient processing methods of existing systems that require overall retransmission or manual verification.

[0040] Missing segment retransmission module: After the configuration segment sequence of the current batch is pushed, a retransmission instruction is generated according to the set to be retransmitted. The missing segment sequence is retransmitted through the batch-level multiplexed transmission channel. After all configuration segments are received by each device, the configuration write operation on the device side is triggered. The write completion confirmation returned by the device is collected and the batch configuration status record is updated.

[0041] Existing systems lack an effective mechanism for resuming interrupted configuration reception when some devices experience interruptions due to network jitter. This often necessitates retransmitting complete configuration data packets to the interrupted devices, resulting in wasted network resources and prolonged configuration time. This solution addresses this by accurately identifying missing data segments and performing targeted retransmission, only retransmitting the actually lost segments. This significantly reduces the amount of data to be retransmitted and the consumption of network resources, thereby improving configuration synchronization efficiency.

[0042] Preferably, in some possible implementations of the embodiments of the present invention, the method for performing targeted retransmission includes: Iterate through each retransmission entry in the set to be retransmitted, extract the device identifier and the set of unacknowledged segment numbers, and look up the corresponding device sub-channel identifier in the channel mapping table based on the device identifier. Since the batch-level multiplexing transmission channel remains active during batch processing, the retransmission operation can directly reuse the established channel resources without re-establishing a connection.

[0043] The coded configuration segments corresponding to the segment numbers in the unconfirmed segment sequence are retrieved from the configuration segment sequence, and the device sub-channel identifier is filled into the segment header information of each coded configuration segment to form a targeted retransmission segment. The data structure of the targeted retransmission segment is exactly the same as that of the targeted configuration segment pushed for the first time, and the device can use a unified receiving and processing logic.

[0044] All targeted retransmission segments from the same device are arranged in ascending order of segment number to form the retransmission segment queue for that device. Arranging them in ascending order of segment number ensures that the device receives the retransmission data in sequence, which facilitates merging with the buffered data segments.

[0045] Directed retransmission segments are sent to the corresponding video call devices in the order of the retransmission segment queue through the batch-level multiplexing transmission channel. An independent retransmission confirmation timer is started after each directed retransmission segment is sent. In this embodiment, the timeout period for the retransmission confirmation timer is set to 8 seconds, slightly longer than the confirmation waiting time for the initial push, to accommodate potential network fluctuations. Upon receiving the segment reception confirmation information, the confirmed segment sequence set for the corresponding device in the batch reception progress mapping table is updated.

[0046] If the retransmission segment does not receive an acknowledgment within the timeout period, the segment will be retransmitted again, with a maximum of 3 retries. If the maximum number of retries is reached and the transmission is still unsuccessful, the device will be marked as a retransmission failure.

[0047] Preferably, in some possible implementations of the embodiments of the present invention, the method for triggering the configuration write operation includes: Iterate through the batch reception progress mapping table, filter for reception progress records where the confirmed segment sequence set equals the complete segment sequence number set, and add the corresponding device identifier to the device set to be written. An equal confirmed segment sequence set indicates that the device has successfully received all configuration data segments.

[0048] A configuration write trigger command is sent to each video call device in the set of devices to be written to. This command includes the channel identifier and the total number of configuration segment sequences. The configuration write trigger command is sent using a reliable transmission method to ensure that the devices can receive the write trigger notification.

[0049] After receiving the configuration write trigger command, each video call device first verifies whether the number of encoded configuration segments in the local cache is equal to the total number of segments in the command. If they are equal, all encoded configuration segments are concatenated in sequence according to the segment number. After stripping the header information and checksum of each segment, the device restores the complete configuration data packet and performs the configuration write operation to write the configuration data to the device storage area.

[0050] After completing the configuration write operation, each video call device returns a write completion confirmation message to the cloud server. The write completion confirmation message includes the device identifier and the write result status code. The write result status code uses numerical encoding: 0 indicates write success, 1 indicates write failure (insufficient storage space), 2 indicates write failure (data verification error), and 3 indicates write failure (device busy).

[0051] The cloud server receives the write completion confirmation message and records the write result status code in the status field of the corresponding device identifier in the batch configuration status record. The batch configuration status record fully records the configuration processing results of each device in the batch, providing a data source for subsequent status statistics and report generation.

[0052] Through the aforementioned targeted retransmission and write triggering mechanism, this solution achieves reliable transmission and consistent writing of configuration data, ensuring that the configuration versions of each device within a batch are updated synchronously, thus eliminating the potential risks of inconsistent configuration versions in the existing system.

[0053] Channel release polling module: Determines whether the batch configuration status record of the current batch has met the completion conditions. If it has, it releases the batch-level multiplexing transmission channel resources, moves the pointer of the configuration batch queue to the next batch, and repeats the operation of the parallel push encoding module to the missing targeted supplementary transmission module until the entire configuration batch queue has been processed. Then, it generates a configuration task completion report and pushes it to the cloud management backend.

[0054] To ensure efficient utilization of cloud server resources, it is necessary to release the occupied channel resources promptly after batch processing is completed so that subsequent batches or other tasks can use them. Simultaneously, it is necessary to summarize and statistically analyze the overall execution results of the configured tasks, generating a structured completion report for administrators to review.

[0055] Preferably, in some possible implementations of the embodiments of the present invention, the method for determining batch completion conditions and releasing channels includes: The number of devices whose status field in the batch configuration status record is "written successfully" (status code 0) is counted, and this number is compared with the total number of devices in the current batch.

[0056] When the number of devices successfully updated equals the total number of devices in the current batch, it indicates that all devices in the batch have successfully completed the configuration update, and the batch configuration status record for the current batch has met the completion condition.

[0057] When the number of devices that successfully completed the write operation is less than the total number of devices in the current batch, check the devices in the batch configuration status record whose status field indicates a write failure (status code 1, 2, or 3) or timeout failure. Record the device identifiers of these devices in the batch's abnormal device list. The batch abnormal device list records information about devices in this batch that failed to complete the configuration update successfully, for subsequent analysis and processing.

[0058] For devices in the batch's list of abnormal devices, a decision is made on whether to re-push the entire batch based on the preset maximum number of retries. In this embodiment, the maximum number of retries is set to 2, but this value is determined based on the timeliness requirements of the configuration task and the stability of the network environment, ranging from 1 to 3 times. If a device's cumulative retries have reached the maximum number of retries, the device is marked as having failed configuration and will not be retried. If all abnormal devices in the batch have been marked as having failed configuration or have successfully retried, the current batch is considered to have met the completion conditions.

[0059] After determining the completion conditions, all device sub-channels on the batch-level multiplexing transmission channel are closed, the port resources occupied by the channel port group are released, and the channel identifier is removed from the active channel list. The release of port resources makes these ports available for subsequent batches, preventing port resource leakage.

[0060] Move the pointer of the configuration batch queue to the next batch and check if there are any unprocessed batches. If so, repeat the operation of parallel push encoding module to missing direction retransmission module for the next batch; if all batches in the configuration batch queue have been processed, proceed to the generation stage of configuration task completion report.

[0061] Preferably, in some possible implementations of the embodiments of the present invention, the method for generating a configuration task completion report includes: Iterate through all batch configuration status records in the batch configuration queue, and count the number of devices that were successfully configured and the number of devices that failed to be configured in each batch. The number of successfully configured devices is the number of devices whose status field indicates successful write, and the number of devices that failed to be configured is the number of devices whose status field indicates write failure or timeout and no response, and the maximum number of retries has been reached.

[0062] The total number of successfully configured devices across all batches is the task-level success count, and the total number of failed configuration devices across all batches is the task-level failure count. For example, if the configuration batch queue contains 3 batches, with 78, 80, and 38 successfully configured devices in each batch, and 2, 0, and 2 failed configuration devices in each batch, then the total task-level success count is 78 + 80 + 38 = 196, and the total task-level failure count is 2 + 0 + 2 = 4.

[0063] Extract the device identifiers and corresponding failure reason codes from the batch list of abnormal devices for each batch. Combine the device identifiers and failure reason codes into detailed failure entries, and aggregate all detailed failure entries into a task-level failure details table. The format of each detailed failure entry is device identifier plus failure reason code plus failure batch number, which facilitates maintenance personnel in locating specific failed devices and analyzing the causes of failure.

[0064] The configuration task completion report encapsulates the task identifier of the configuration task request, the version number of the configuration data package, the total number of successful tasks, the total number of failed tasks, the detailed list of failed tasks, and the start and end timestamps of the task execution. The configuration task completion report is organized in JSON format for easy parsing and display by the management backend. The report is pushed to the management backend via a message interface in the cloud. Upon receiving the report, the management backend updates the task status display interface, allowing operations personnel to visually view the execution results of the configuration task, including the success rate, the list of failed devices, and the specific reasons for failure.

[0065] The aforementioned channel release and report generation mechanism provides maintenance personnel with a clear view of configuration execution, eliminating the manual burden of checking the configuration version of each device, and significantly improving the overall management efficiency and configuration consistency assurance capability of the campus video call device cluster.

[0066] It should be noted that the specific values ​​of each preset parameter in this embodiment are recommended configurations for typical application scenarios. Implementers can adjust them according to factors such as the actual campus size, network environment, and server configuration. This solution is applicable to various application scenarios that require batch configuration management of distributed terminal devices. In addition to campus video call machines, it can also be applied to the centralized configuration management of campus access control equipment, intelligent broadcasting terminals, and other devices.

[0067] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A centralized remote monitoring and configuration platform for campus video call devices, characterized in that: include: Batch partitioning management module: Obtains configuration task requests from the cloud management backend, parses the set of device identifiers to be configured and the configuration data packet, calculates the batch capacity threshold based on the size of the device identifier set and the current load status of the cloud server, and divides the device identifier set into an ordered configuration batch queue based on the batch capacity threshold. Parallel push encoding module: For the current batch in the configuration batch queue, a batch-level multiplexing transmission channel is established. The configuration data packet is segmented and encoded, and a segment sequence identifier and check code are added to form a configuration segment sequence. The configuration segment sequence is pushed to each device in the batch in parallel through the batch-level multiplexing transmission channel. Receive tracking and recording module: Receive segment reception confirmation information returned by each video call device, independently track the reception progress of each device according to the segment sequence identifier, build a batch reception progress mapping table, and when a device is found to have missing segment reception confirmation information, the device and its missing segment sequence are recorded in the set to be retransmitted. Missing segment retransmission module: After the configuration segment sequence of the current batch is pushed, a retransmission instruction is generated according to the set to be retransmitted. The missing segment sequence is retransmitted through the batch-level multiplexed transmission channel. After each device has completed receiving all configuration segments, the configuration write operation on the device side is triggered. The write completion confirmation returned by the device is collected and the batch configuration status record is updated. Channel release polling module: If the batch configuration status record of the current batch reaches the completion condition, release the batch-level multiplexing transmission channel resources, move the pointer of the configuration batch queue to the next batch, and repeat the operation of parallel push encoding module to missing direction supplementary transmission module until the entire configuration batch queue is processed, generate configuration task completion report and push it to the cloud management backend.

2. The centralized remote monitoring and configuration platform for campus video call devices in the cloud as described in claim 1, characterized in that, Based on the size of the device identifier set and the current load status of the cloud server, a batch capacity threshold is calculated. Then, the device identifier set is divided into ordered configuration batch queues according to the batch capacity threshold, including: Obtain the available connection pool capacity and the current number of active connections of the cloud server, and use the difference between the available connection pool capacity and the current number of active connections as the remaining connection quota; Obtain the total number of bytes in the configuration data packet and the preset single-device transmission bandwidth allocation value, and use the ratio of the total number of bytes to the single-device transmission bandwidth allocation value as the estimated transmission time for a single device; The remaining connection quota is multiplied by the preset connection security factor to obtain the number of secure connections. The number of secure connections is then correlated with the estimated transmission time of a single device. When the estimated transmission time of a single device exceeds the preset time threshold, the number of secure connections is reduced proportionally, and the reduced value is used as the batch capacity threshold. When the estimated transmission time of a single device is less than or equal to the preset time threshold, the number of secure connections is used as the batch capacity threshold. Based on the original arrangement order of the device identifiers in the device identifier set, the device identifier set is sequentially divided into several subsets according to the batch capacity threshold. Each subset is numbered according to the division order and formed into a configuration batch queue.

3. The centralized remote monitoring and configuration platform for campus video call devices in the cloud as described in claim 2, characterized in that, Establish a batch-level multiplexed transmission channel, segment and encode the configuration data packets, and attach segment sequence identifiers and check codes to form a configuration segment sequence, including: Based on the number of devices included in the current batch and the port allocation strategy of the cloud server, a set of continuous port ranges is selected as the channel port group. A unified batch-level multiplexed transmission channel is established on the channel port group, and a unique channel identifier is assigned to the channel. The configuration data packet is sequentially divided according to the preset segment length limit to obtain several configuration data segments, and each configuration data segment is assigned an incrementing segment number. For each configuration data segment, calculate the cyclic check value of its content and append the cyclic check value to the end of the configuration data segment. Encapsulate the segment number and channel identifier into segment header information and append it to the beginning of the configuration data segment to form a complete coded configuration segment. Arrange all encoding configuration segments in ascending order of segment number to form a configuration segment sequence, and record the total number of segments and channel identifiers in the configuration segment sequence.

4. The centralized remote monitoring and configuration platform for campus video call devices in the cloud as described in claim 3, characterized in that, The configuration segment sequence is pushed in parallel to each device in the batch through a batch-level multiplexed transmission channel, including: On the batch-level multiplexing transmission channel, assign an independent device sub-channel identifier to each video call device in the batch, and record the correspondence between the device identifier and the device sub-channel identifier in the channel mapping table; The coded configuration segments are extracted sequentially from the configuration segment sequence. The target device sub-channel identifier is appended to the segment header information of each coded configuration segment to form a directional configuration segment. Copy the same coded configuration segment into a number of targeted configuration segments equal to the number of devices in the batch, and fill in the corresponding device sub-channel identifiers for each segment. All targeted configuration segment copies are grouped according to segment number. Targeted configuration segment copies with the same segment number are sent in parallel and scheduled. The corresponding targeted configuration segments are pushed to each video call device in the batch simultaneously through the batch-level multiplexing transmission channel. After each group of targeted configuration segment copies is sent, the sending timestamp is recorded and the acknowledgment waiting timer corresponding to that segment number is started.

5. The centralized remote monitoring and configuration platform for campus video call devices in the cloud as described in claim 4, characterized in that, The reception progress of each device is tracked independently based on the segment sequence identifier, and a batch reception progress mapping table is constructed, including: Establish an independent reception progress record for each video call device in the batch. The reception progress record includes the device identifier, the set of confirmed segments, and the last confirmation timestamp. When a segment reception confirmation message is received from a video call device, the device sub-channel identifier and the received segment sequence number are extracted from the segment reception confirmation message, and the device sub-channel identifier is converted into a device identifier according to the channel mapping table. In the corresponding receiving progress record, the received segment number is added to the confirmed segment sequence set, and the current time is updated to the last confirmed timestamp; All receiving progress records within a batch are aggregated into a batch receiving progress mapping table, and the total number of segments in the configuration segment sequence is marked in the progress mapping table.

6. The centralized remote monitoring and configuration platform for campus video call devices in the cloud as described in claim 5, characterized in that, When a device is found to have a missing segment reception acknowledgment, the device and its missing segment sequence are added to the retransmission set, including: For each receiving progress record in the batch receiving progress mapping table, the set of confirmed segment numbers is compared with the complete set of segment numbers in the configured segment sequence to obtain the set of unconfirmed segment numbers. For a non-empty receiving progress record in the unacknowledged segment sequence number set, check whether the interval between its last acknowledgment timestamp and the current time exceeds the preset acknowledgment timeout threshold. If the interval exceeds the acknowledgment timeout threshold, combine the device identifier corresponding to the receiving progress record with the unacknowledged segment sequence number set into a retransmission entry, and add the retransmission entry to the retransmission set. If the interval does not exceed the acknowledgment timeout threshold, continue to wait for receiving acknowledgment information until the interval exceeds the acknowledgment timeout threshold or the unacknowledged segment sequence number set becomes empty. After all devices in the batch have completed comparison and timeout determination, the retransmission items in the retransmission set are merged and organized according to the device identifier.

7. The centralized remote monitoring and configuration platform for campus video call devices in the cloud as described in claim 6, characterized in that, Based on the set of segments to be retransmitted, a targeted retransmission instruction is generated, and the missing segments are retransmitted through a batch-level multiplexed transmission channel, including: Iterate through each retransmission entry in the set to be retransmitted, extract the device identifier and the set of unacknowledged segment numbers, and query the corresponding device subchannel identifier in the channel mapping table based on the device identifier; Retrieve the coded configuration segment corresponding to each segment number in the unconfirmed segment number set from the configuration segment sequence, and fill the device sub-channel identifier into the segment header information of each coded configuration segment to form a directional supplementary transmission segment; All directional retransmission segments of the same device are arranged in ascending order by segment number to form a retransmission segment queue for the device. The directional retransmission segments are sent to the corresponding video call device in the order of the retransmission segment queue through the batch-level multiplexing transmission channel. An independent retransmission confirmation timer is started after each directional retransmission segment is sent, and the batch reception progress mapping table is updated after receiving the segment reception confirmation information.

8. The centralized remote monitoring and configuration platform for campus video call devices in the cloud as described in claim 7, characterized in that, After each device completes the reception of all configuration segments, a configuration write operation is triggered on the device side. The write completion confirmations returned by the devices are collected, and the batch configuration status record is updated, including: Traverse the batch reception progress mapping table, filter the reception progress record items where the confirmed segment sequence set is equal to the complete segment sequence number set, and add the corresponding device identifier to the device set to be written; send a configuration write trigger command to each video call device in the device set to be written, the command containing the channel identifier and the total number of segments in the configuration segment sequence; After receiving the configuration write trigger command, each video call device reassembles all the encoded configuration segments in the local cache into a complete configuration data packet according to the segment number sequence, and then performs the configuration write operation. After each video call device completes the configuration writing operation, it returns a write completion confirmation message to the cloud server. The write completion confirmation message includes the device identifier and the write result status code. The cloud server receives the write completion confirmation message and records the write result status code in the status field of the corresponding device identifier in the batch configuration status record.

9. The centralized remote monitoring and configuration platform for campus video call devices in the cloud as described in claim 8, characterized in that, If the batch configuration status record for the current batch meets the completion conditions, release the batch-level multiplexed transmission channel resources, including: The number of devices whose status field in the batch configuration status record is successfully written is compared with the total number of devices in the current batch. When the number of devices successfully written to equals the total number of devices in the current batch, the batch configuration status record for the current batch is deemed to have met the completion condition. When the number of devices that have successfully written is less than the total number of devices in the current batch, check the devices whose status field in the batch configuration status record is "write failed" or "timeout unresponsive", and record the device identifiers of these devices in the batch abnormal device list. For devices in the batch abnormal device list, determine whether to re-push the entire batch based on the preset maximum number of retries. If the maximum number of retries has been reached, mark the abnormal device as a configuration failure and determine that the current batch has met the completion conditions. After determining the completion conditions, close all device sub-channels on the batch-level multiplexing transmission channel, release the port resources occupied by the channel port group, and remove the channel identifier from the list of active channels.

10. The centralized remote monitoring and configuration platform for campus video call devices in the cloud as described in claim 9, characterized in that, Generate a configuration task completion report and push it to the cloud management backend, including: Iterate through all batch configuration status records in the configuration batch queue and count the number of devices that were successfully configured and the number of devices that failed to be configured in each batch. The total number of successfully configured devices in all batches is the total number of successfully configured devices at the task level, and the total number of successfully configured devices in all batches is the total number of successfully configured devices at the task level. Extract the device identifiers and corresponding failure reason codes of the devices that failed to configure from the batch abnormal device list of each batch, combine the device identifiers and failure reason codes into failure detail entries, and aggregate all failure detail entries into a task-level failure detail table. The configuration task completion report is encapsulated by the task identifier of the configuration task request, the version number of the configuration data package, the total number of successful tasks, the total number of failed tasks, the task-level failure details table, and the start and end timestamps of the task execution. The configuration task completion report is then pushed to the management backend through the message interface of the cloud management backend.

Images