Glasses end content delivery and local confirmation method in private network environment

Abstract

This invention belongs to the field of communication technology, specifically relating to a method for content delivery and local confirmation for glasses in a private network environment. The method includes the following steps: Step 1: The content delivery server assigns a task identifier to each task content data and sends it to the glasses terminals within the private network via a User Datagram Protocol (UDP) broadcast channel; Step 2: Each glasses terminal receives the UDP broadcast data until it recovers the complete task content data and registers it in its local task table; Step 3: When a glasses terminal executes task content data in the registered state, it triggers a voice confirmation module to collect the wearer's confirmation-type command voice to generate a task confirmation event. The content delivery server then parses the Bloom filter digest bit array to obtain the set of completed tasks and updates the task management record. This invention significantly improves the efficiency, reliability, and controllability of task management in a private network environment.

Description

Technical Field

[0001] This invention belongs to the field of communication technology, specifically relating to a method for content delivery and local confirmation on glasses in a private network environment. Background Technology

[0002] Sending task content data to wearable devices in a dedicated network environment and confirming it locally has become an increasingly common technical requirement in industrial site management, security inspection, equipment inspection, and training execution in recent years. In traditional solutions, task content data is typically sent from the server to each terminal device one by one via Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) unicast. After the terminal device completes the task, it reports the execution result to the server one by one through a synchronous connection. This type of solution can basically meet the requirements in public network environments or stable enterprise LAN environments. However, its shortcomings become increasingly apparent in scenarios with limited coverage in dedicated networks, unstable network link quality, a large number of terminals, and limited uplink and downlink bandwidth.

[0003] In traditional content delivery technologies, unicast delivery using Transmission Control Protocol (TCP) provides reliability guarantees, but its reliance on connection establishment, maintenance, and independent acknowledgment by each terminal leads to significant additional resource consumption in dedicated networks with multiple terminals online simultaneously. For example, when a task's content data needs to be delivered to dozens or even hundreds of glasses terminals, the server typically needs to create an equal number of connection channels, each handling retransmission, window control, and handshake acknowledgments. If the links in the dedicated network experience momentary fluctuations, numerous connection timeouts or interruptions can occur, significantly reducing the overall efficiency of task content data distribution. To reduce the connection pressure on the server side, some solutions use User Datagram Protocol (UDP) broadcasting to simultaneously send task content data to multiple terminals. However, UDP broadcasting itself does not provide reliability guarantees. In wireless dedicated networks or temporary networks with frequent packet loss, some basic data fragments often fail to reach the terminals successfully via broadcast, resulting in incomplete task content data recovered by the terminals. The traditional approach is to add a rebroadcast strategy or additional acknowledgment steps to the broadcast channel. For example, the server repeatedly broadcasts the task content data at a fixed frequency, or the terminal sends a retransmission request to the server when data is missing. However, repeated broadcasts consume additional limited broadcast bandwidth, and if retransmission requests are not accurate enough, they can easily cause the server to send a large amount of redundant data, further affecting the data transmission of other applications in the network. Summary of the Invention

[0004] Therefore, the main objective of this invention is to provide a method for content delivery and local confirmation for glasses in a dedicated network environment. This method uses fountain coding broadcasting to simultaneously deliver task content data to multiple glasses terminals in a dedicated network environment. At the terminal side, fountain decoding and precise retransmission request messages (NACK) are used to efficiently compensate for missing basic data segments, ensuring reliable recovery of task content data even in the presence of network jitter and packet loss. During task execution, the terminal collects and identifies voice confirmation commands issued by the wearer to generate task confirmation events, updating the task status to a local confirmation status. This ensures that task completion is user-initiated and auditable. After multiple tasks are completed, a Bloom filter summary bit array is constructed to batch-return the task status to the content delivery server in a highly compressed format. Additionally, for critical tasks, an execution result summary and voice confirmation template identifier are returned, enabling the server to accurately verify critical tasks. Thus, without relying on a stable public network, this method achieves highly reliable distribution of task content data, natural interactive confirmation, and efficient and traceable centralized return, significantly improving the efficiency, reliability, and controllability of task management in a dedicated network environment.

[0005] The technical solution adopted in this invention is as follows:

[0006] The method for content delivery and local confirmation on the glasses in a private network environment includes the following steps:

[0007] Step 1: The content delivery server assigns a task identifier to each task content data, executes fountain coding to generate fountain broadcast data packets, and sends them to the glasses terminals in the private network through the User Datagram Protocol broadcast channel;

[0008] Step 2: Each glasses terminal receives the fountain broadcast data packet, establishes the basic data segment reception status and recovery status based on the fountain encoding header, calls the fountain decoding module to recover the task content data, and generates a precise retransmission request message NACK when the basic data segment recovery is incomplete and sends it through the uplink compensation channel. The content delivery server generates a compensation fountain broadcast data packet based on the precise retransmission request message NACK and broadcasts it again until the glasses terminal recovers the complete task content data and registers it in the local task table.

[0009] Step 3: When the glasses terminal executes task content data in the registered state, it triggers the voice confirmation module to collect the wearer's confirmation command voice to generate a task confirmation event, updates the task status to the local confirmation state, and constructs a Bloom filter summary bit array after completing multiple task content data in the local confirmation state. The Bloom filter summary bit array, along with the key task execution result summary and voice confirmation template identifier, is written into a batch return message and sent to the content delivery server via the return link. The content delivery server parses the Bloom filter summary bit array to obtain the set of completed tasks and updates the task management record.

[0010] Furthermore, before generating the fountain-encoded group stream, the content delivery server also includes: establishing a task record for each piece of task content data to be delivered, assigning a unique task identifier to each piece of task content data, dividing each piece of task content data into multiple basic data segments according to a preset data length, assigning a basic data segment number to each basic data segment, and writing the task identifier, basic data segment number, and storage location of the basic data segment in the storage medium into a task basic data segment table. The task basic data segment table is used by the fountain encoding module and the compensation fountain encoding generation module to read the corresponding basic data segment according to the basic data segment number during subsequent encoding and compensation.

[0011] Furthermore, when generating the fountain-coded packet stream, the content delivery server calls the fountain coding module. The fountain coding module generates multiple basic data fragment numbers based on the task identifier, the current coding round information, and the internal pseudo-random seed. It sequentially reads the corresponding basic data fragments from the task basic data fragment table, performs a bitwise XOR operation on all basic data fragments at the same byte position to obtain the encoded data of the fountain-coded packet, records the set of basic data fragment numbers that participated in generating the fountain-coded packet as the fountain coding description information, combines the fountain coding description information with the task identifier to form the fountain coding header, and concatenates the fountain coding header with the encoded data to generate a fountain broadcast datagram. The content delivery server sequentially encapsulates multiple fountain broadcast datagrams into User Datagram Protocol (UDP) broadcast messages and broadcasts them to the glasses terminals in the private network through the UDP broadcast channel.

[0012] Furthermore, when managing the fountain broadcast data packets in the receiving buffer, the glasses terminal performs the following steps: The glasses terminal parses the fountain encoding header from each fountain broadcast data packet, extracts the task identifier and the set of basic data segment numbers, establishes a basic data segment receiving status table locally for the task identifier, sets a receiving flag field and a recovery flag field for each basic data segment number in the basic data segment receiving status table, and when a fountain broadcast data packet is received, the glasses terminal sets the receiving flag field corresponding to the basic data segment number involved in the fountain broadcast data packet to the received state, keeps the receiving flag field corresponding to the basic data segment number that has not yet appeared in any fountain broadcast data packet to the pending receiving state, and stores the fountain encoding header and encoded data of the fountain broadcast data packet in the local receiving buffer for subsequent fountain decoding.

[0013] Furthermore, when the glasses terminal performs fountain decoding based on the basic data segment reception status, the specific steps include: first, counting the number of basic data segment numbers in the basic data segment reception status table whose reception flag field is in the received state; when the number reaches a preset decodeable threshold, calling the fountain decoding module; the fountain decoding module searches in the reception buffer for a fountain broadcast data packet whose fountain encoding header contains only a single basic data segment number; directly writing the encoded data of the fountain broadcast data packet into the recovery buffer of the corresponding basic data segment number; and setting the recovery flag field of the corresponding basic data segment number in the basic data segment reception status table to the recovered state; subsequently, the fountain decoding module searches in the reception buffer for a fountain encoding header containing multiple basic data segment numbers, where at least one of the basic data segment numbers is in the recovered flag field. For each fountain broadcast data packet found in the recovered state, the fountain decoding module reads the byte sequence from the encoded data and sequentially reads the byte sequence of all recovered basic data segments from the recovery buffer. It performs a bitwise XOR operation on the encoded data at the same byte position with the contents of all recovered basic data segments byte by byte to obtain the byte sequence of the remaining basic data segment. The byte sequence is written into the recovery buffer corresponding to the basic data segment number, and the recovery flag field of the corresponding basic data segment number in the basic data segment reception status table is set to the recovered state. The fountain decoding module repeatedly traverses the fountain broadcast data packets in the reception buffer until the recovery flag field of all basic data segment numbers in the basic data segment reception status table is in the recovered state, forming complete task content data.

[0014] Furthermore, when the fountain decoding module has traversed all fountain broadcast datagrams in the receive buffer, and there are still basic data fragment numbers in the basic data fragment receive status table with the recovery flag field in a pending recovery state, the glasses terminal performs precise retransmission request message (NACK) generation and compensation fountain broadcast datagram reception processing. Specifically, this includes: the glasses terminal extracting all basic data fragment numbers with the recovery flag field in a pending recovery state from the basic data fragment receive status table, forming a list of missing basic data fragment numbers, writing the task identifier, the number of missing basic data fragment numbers, and the list of missing basic data fragment numbers into the message body of the precise retransmission request message (NACK), and sending it to the content delivery server through the uplink compensation channel; after receiving the precise retransmission request message (NACK), the content delivery server reads the basic data fragments corresponding to the missing basic data fragment number list from the task basic data fragment table according to the task identifier, forming a set of missing basic data fragments, and... A portion of the non-missing basic data fragments are read from the task's basic data fragment table to form an auxiliary basic data fragment set. At least one basic data fragment is selected from the missing basic data fragment set, and several basic data fragments are selected from the auxiliary basic data fragment set. The selected basic data fragments are then subjected to a bitwise XOR operation byte by byte according to byte alignment to generate the encoded data of the compensation fountain code group. The missing basic data fragment number is combined with the auxiliary basic data fragment numbers participating in the compensation to form the compensation fountain code description information and written into the compensation fountain code header. The content delivery server concatenates the compensation fountain code header and the encoded data to generate a compensation fountain broadcast datagram, which is encapsulated as a User Datagram Protocol (UDP) broadcast message and sent through the UDP broadcast channel. After receiving the compensation fountain broadcast datagram, the glasses terminal updates the basic data fragment reception status table and calls the fountain decoding module again until the recovery flag field of all basic data fragment numbers is in the recovered state.

[0015] Furthermore, the process of triggering the voice confirmation module for voice confirmation after the glasses terminal recovers the complete task content data includes: collecting the wearer's voice signal within a preset time window, dividing the continuously collected voice signal into multiple continuous audio frames according to a preset duration, calculating the short-time energy and zero-crossing rate for each audio frame, marking audio frames with both short-time energy and zero-crossing rate greater than a preset voice threshold as voice frames, combining continuous voice frames into voice segments, marking audio frames with both short-time energy and zero-crossing rate less than or equal to the preset voice threshold as silence frames and using them as boundaries of voice segments, and generating a voice segment sequence for subsequent voice feature extraction.

[0016] Furthermore, the voice confirmation module will sequentially perform pre-emphasis processing, frame segmentation processing, and windowing processing on each voice segment, and perform filtering and discrete transformation processing on each windowed frame to obtain multiple Mel-frequency cepstral coefficients. The Mel-frequency cepstral coefficients corresponding to each frame will be arranged in frame order to form a voice command feature sequence. The voice confirmation module will pre-store multiple command voice templates in the local storage area. Each command voice template contains a template feature sequence corresponding to the preset command statement and is marked as a confirmation command template or a non-confirmation command template.

[0017] Furthermore, the voice confirmation module establishes a two-dimensional alignment grid between the current voice command feature sequence and each template feature sequence. At the starting unit of the grid, the cumulative difference value is set as the difference value between the starting voice frame and the starting template frame. Starting from the starting unit, each unit in the grid is processed sequentially along the time sequence. For each unit, the difference value between the corresponding voice frame and the template frame is calculated first. Then, the three cumulative difference values ​​of the upper unit, the left unit, and the upper left unit are read. The minimum value of the three cumulative difference values ​​is selected and added to the current difference value. The result is written into the grid as the cumulative difference value of the current unit. At the end unit of the grid, the total cumulative difference value corresponding to the template is read. The total cumulative difference value is used as the matching result of the current template. The template with the smallest total cumulative difference value is selected as the template corresponding to the recognition result among all command voice templates. When the template corresponding to the recognition result is marked as a confirmation command template and the total cumulative difference value is less than the preset confirmation threshold, the voice confirmation module generates a task confirmation event and writes it into the local task status table. The task status field corresponding to the task identifier is updated to the local confirmation status, and the template identifier of the template corresponding to the recognition result and the timestamp of the current voice segment are recorded in the local task status table.

[0018] By adopting the above technical solutions, this invention achieves the following beneficial effects: By combining fountain-coded broadcasting of task content data, a precise retransmission request message (NACK) compensation mechanism, wearer-triggered voice confirmation, and batch back transmission based on Bloom filter digest bit groups in a dedicated network environment, this invention realizes a highly reliable content delivery and auditable task confirmation process for glasses terminals, significantly improving upon the shortcomings of existing technologies in several key indicators. Because fountain coding allows the content delivery server to simultaneously deliver coded data to all glasses terminals via continuous broadcast, each glasses terminal only needs to receive a sufficient number of fountain broadcast datagrams to recover complete task content data. This avoids resource consumption caused by establishing a large number of connections and network congestion caused by unicast retransmission, maintaining high stability in the content delivery process even when network quality fluctuates. The precise retransmission request message (NACK) is only sent when the basic data segment is incompletely recovered, explicitly indicating the number of the unrecovered basic data segment. This enables the server to generate compensating fountain broadcast datagrams and emphasize the coded structure overlay on the missing positions, thus avoiding redundant retransmission and significantly shortening the time for terminals to recover task content data. Voice confirmation records the wearer's actual confirmation behavior without manual operation and leaves a voice confirmation template identifier and timestamp in the local task table, making each task confirmation traceable. This is suitable for high-level scenarios requiring manual confirmation and auditing records. The Bloom filter summary bit array allows the completion status of multiple tasks to be compressed and expressed with a fixed space occupation, preventing data bloat even with a large number of tasks. This allows the glasses terminal to transmit a large number of task statuses at once when the network recovers. Furthermore, for critical tasks, this invention can include a summary of the critical task execution results and a voice confirmation template identifier in batch transmissions, enabling the content delivery server to accurately verify critical tasks even with a small possibility of false alarms in the bit array. This invention achieves efficient broadcasting under high concurrency, highly robust content recovery, natural interactive local confirmation, and high-compression, auditable result transmission, comprehensively improving the reliability, security, and manageability of the task content data delivery and confirmation system in a dedicated network environment. Attached Figure Description

[0019] Figure 1 A schematic diagram of the XOR combination principle of basic data fragments for fountain encoding provided in an embodiment of the present invention;

[0020] Figure 2 A schematic diagram illustrating the principle of voice command matching based on Dynamic Time Warping (DTW) provided in an embodiment of the present invention;

[0021] Figure 3 This is a memory layout diagram of a hybrid data structure for batch message return provided in an embodiment of the present invention. Detailed Implementation

[0022] All features disclosed in this specification, or all steps in all disclosed methods or processes, may be combined in any way, except for mutually exclusive features and / or steps.

[0023] Any feature disclosed in this specification (including any appended claims and abstract) may be replaced by other equivalent or similar features, unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is merely one example of a series of equivalent or similar features.

[0024] The method for content delivery and local confirmation on the glasses in a private network environment includes the following steps:

[0025] Step 1: The content delivery server assigns a task identifier to each task content data, executes fountain coding to generate fountain broadcast data packets, and sends them to the glasses terminals in the private network through the User Datagram Protocol broadcast channel;

[0026] Step 2: Each glasses terminal receives the fountain broadcast data packet, establishes the basic data segment reception status and recovery status based on the fountain encoding header, calls the fountain decoding module to recover the task content data, and generates a precise retransmission request message NACK when the basic data segment recovery is incomplete and sends it through the uplink compensation channel. The content delivery server generates a compensation fountain broadcast data packet based on the precise retransmission request message NACK and broadcasts it again until the glasses terminal recovers the complete task content data and registers it in the local task table.

[0027] Step 3: When the glasses terminal executes task content data in the registered state, it triggers the voice confirmation module to collect the wearer's confirmation command voice to generate a task confirmation event, updates the task status to the local confirmation state, and constructs a Bloom filter summary bit array after completing multiple task content data in the local confirmation state. The Bloom filter summary bit array, along with the key task execution result summary and voice confirmation template identifier, is written into a batch return message and sent to the content delivery server via the return link. The content delivery server parses the Bloom filter summary bit array to obtain the set of completed tasks and updates the task management record.

[0028] In one specific implementation, the content delivery server is deployed at the central node of a dedicated network to deliver task content data to multiple glasses terminals within the dedicated network. After receiving the task content data submitted by the upper-layer business system, the content delivery server first performs task content data registration and task identifier generation, then performs fountain coding to generate fountain broadcast data packets, and sends them to the glasses terminals within the dedicated network through the User Datagram Protocol (UDP) broadcast channel, enabling the same task content data to simultaneously cover a large number of glasses terminals within the dedicated network in a single broadcast.

[0029] During the task content data registration and task identifier generation process, the content delivery server establishes a task record for each piece of task content data. Task content data can be structured text, image data, combinations of operation instructions, or any combination of the above. The content delivery server converts the task content data into a continuous byte sequence and records the total length of the byte sequence. The content delivery server assigns a task identifier to each piece of task content data. The task identifier can be a 16-byte string, where the first 8 bytes are a timestamp encoding, and the last 8 bytes are an incrementing sequence number encoding under the current timestamp. This method ensures that task identifiers generated on the same content delivery server remain unique over a relatively long period, facilitating the identification of different task content data by the glasses terminal within the private network during subsequent processing and enabling the aggregation of execution status by task identifier during the feedback phase.

[0030] After generating the task identifier, the content delivery server performs fragmentation processing on each task content data. The server divides the byte sequence corresponding to the task content data into multiple basic data segments of fixed length. Each basic data segment can be set to 1024 bytes. For the last basic data segment, if the remaining bytes are less than 1024 bytes, all remaining bytes are added to the last basic data segment, and the actual length is recorded in the task basic data segment table. The reason for setting the basic data segment length to 1024 bytes is that Ethernet data frames in private networks typically have a maximum transmission unit (MTU) limit. After deducting the network protocol header, a single broadcast message in a User Datagram Protocol (UDP) broadcast channel leaves approximately 1400 bytes of space for the payload. Setting the basic data segment length to 1024 bytes allows sufficient space for the fountain code header and protocol control fields without fragmentation, thereby reducing the probability of fragmentation in the underlying network and reducing reassembly overhead.

[0031] The content delivery server assigns a basic data fragment number to each basic data fragment. The basic data fragment numbers can start from 0 and increment sequentially until all basic data fragments are covered. For example, when a task's content data is divided into 100 basic data fragments, the basic data fragment numbers range from 0 to 99. The content delivery server writes the task identifier, basic data fragment number, starting offset of the basic data fragment within the task content data, basic data fragment length, and storage location of the basic data fragment in the storage medium into the task's basic data fragment table. The task's basic data fragment table provides an index for quickly retrieving the corresponding basic data fragment by its basic data fragment number during subsequent fountain encoding, avoiding the need to re-parse the original task content data each time encoding is performed.

[0032] During the fountain coding phase, the content delivery server generates a fountain-coded packet stream for a specific task content data. The fountain-coded packet stream consists of a variable number of fountain-coded packets, each corresponding to the payload portion of a fountain broadcast datagram. The content delivery server maintains a coding round counter for this task content data, incrementing from 0. Each time a fountain-coded packet is generated, the content delivery server generates an intermediate value based on the task identifier and the current coding round counter. This intermediate value is obtained by combining the byte values ​​in the task identifier with the coding round counter, for example, by adding each byte value in the task identifier to the current intermediate value in byte order and then performing a left or right shift operation on the result to obtain a new intermediate value. After completing the task identifier traversal, the content delivery server performs a modulo operation between the intermediate value and the total number of basic data fragments to obtain the first basic data fragment number. The content delivery server can perform addition and shift operations on the intermediate value, and then perform a modulo operation with the total number of basic data fragments to obtain the second and third basic data fragment numbers in sequence, thus forming a set of basic data fragment numbers containing multiple basic data fragment numbers.

[0033] The set of basic data fragment numbers obtained through the above method is related to the task identifier and the coding round counter. The combinations of basic data fragment numbers generated in different coding rounds are diverse, ensuring even coverage of different basic data fragments in the fountain-coded packet stream. This reduces recovery difficulties caused by some basic data fragments being selected too infrequently. The content delivery server reads the corresponding basic data fragments from the task's basic data fragment table based on the set of basic data fragment numbers. The read basic data fragments are arranged according to byte alignment, and a bitwise XOR operation is performed byte-by-byte on all basic data fragments at the same byte position to generate the encoded data of the fountain-coded packets. Since the encoded data in the fountain-coded packets is a combination of multiple basic data fragments obtained through bitwise XOR operations, if any basic data fragment is missing, as long as there are enough fountain-coded packets containing that basic data fragment, the missing basic data fragment can be restored through step-by-step elimination, thereby improving the recoverability of task content data in the event of packet loss in the user datagram protocol broadcast channel.

[0034] After completing the encoding data calculation, the content delivery server records the set of basic data fragment numbers that participated in generating the fountain encoding group as fountain encoding description information. The fountain encoding description information includes the number of basic data fragment numbers and the specific value of each basic data fragment number. The content delivery server combines the fountain encoding description information with the task identifier to form the fountain encoding header. The fountain encoding header can be organized according to a fixed field order; for example, the first 16 bytes are the task identifier field, the next 4 bytes are the basic data fragment number field, and the following bytes are the fixed byte length occupied by each basic data fragment number. The purpose of writing the task identifier into the fountain encoding header is to allow the glasses terminal within the private network to distinguish different task content data based solely on the fountain encoding header after receiving the fountain broadcast data packet, and to establish the basic data fragment reception status and recovery status based on the set of basic data fragment numbers.

[0035] During the construction of the fountain broadcast datagram, the content delivery server concatenates the fountain code header with the encoded data of the fountain code packet to form a complete fountain broadcast datagram. The total length of the fountain broadcast datagram does not exceed the payload limit allowed by the User Datagram Protocol (UDP) broadcast channel. For example, with a base data segment length of 1024 bytes and a fountain code header length of 64 bytes, the total length of the fountain broadcast datagram is 1088 bytes, which is far below the payload limit corresponding to the maximum transmission unit (MTB) of common Ethernet networks. This allows it to be transmitted as a single message in a dedicated network without generating underlying fragmentation.

[0036] refer to Figure 1 , Figure 1 This diagram illustrates the principle of XOR combination of basic data fragments for fountain encoding, showing the complete technical process by which the content delivery server performs fountain encoding on task content data to generate fountain broadcast datagrams. For example... Figure 1As shown, the content delivery server maintains multiple basic data segments that have undergone fragmentation processing in the basic data segment storage area, including basic data segment 0, basic data segment 1, basic data segment 2, and basic data segment 3. Each basic data segment has a length of 1024 bytes and is stored as a continuous byte sequence. Specifically, the byte sequence corresponding to basic data segment 0 is D0, represented as "101100110100110011010101..."; the byte sequence corresponding to basic data segment 1 is D1, represented as "110010101011000100101110..."; the byte sequence corresponding to basic data segment 2 is D2, represented as "010101011111000010101010..."; and the byte sequence corresponding to basic data segment 3 is D3, represented as "001111000101010111001100...". These basic data fragments are indexed in the task basic data fragment table according to their basic data fragment numbers, facilitating quick retrieval by number during subsequent fountain coding. The content delivery server maintains a coding round counter n for each task content data, incrementing from 0. When generating the nth round of fountain coding groups, the content delivery server generates an intermediate value based on the task identifier and the current coding round counter n. This intermediate value is then calculated by combining the byte value in the task identifier with the coding round counter and performing a shift operation to obtain a hash calculation result. This hash result is then moduloed by the total number of basic data fragments to sequentially obtain multiple basic data fragment numbers, thus forming a set of selected fragment numbers. For example... Figure 1As shown, in the processing of encoding round n, the set of basic data fragment numbers selected by hashing the task identifier with round n is {0,1,3}, indicating that the fountain encoding group in this round will use basic data fragment 0, basic data fragment 1, and basic data fragment 3 for combined encoding. The content delivery server reads the corresponding basic data fragments D0, D1, and D3 from the basic data fragment storage area based on the selected fragment number set {0,1,3}, and enters the byte-by-byte bitwise XOR operation area. In this operation area, the content delivery server performs a bitwise XOR operation byte-by-byte on all selected basic data fragment contents at the same byte position. Specifically, for the first byte position, the first byte "10110011" is read from D0, the first byte "11001010" is read from D1, and the first byte "00111100" is read from D3. A bitwise XOR operation is performed on these three bytes: the first bit 1⊕1⊕0=0, the second bit 0⊕1⊕0=1, and so on, ultimately yielding the result "01000101". Similarly, for the second byte position, the second byte "01001100", the second byte "10110001" of D0, and the second byte "01010101" of D3 are XORed, yielding the result "00111000". The same bytewise XOR operation is used for the third byte position and all subsequent byte positions until all 1024 bytes are processed, generating complete encoded data. After completing the encoded data calculation, the content delivery server constructs a fountain-coded packet n. This fountain-coded packet consists of two parts: a fountain-coded header and encoded data. The fountain-coded header is organized in a fixed field order. The first 16 bytes are a task identifier field, used to identify the task content data to which this fountain-coded packet belongs; the following 4 bytes are a basic data fragment number field, recorded as 3 here, indicating that 3 basic data fragments were used in this encoding; the next part is a fixed byte length for each basic data fragment number, recorded as fragment number 0, 1, 3 in sequence. The encoded data part is the byte sequence obtained by the aforementioned byte-by-byte XOR operation, i.e., "010001010011100000110011...". The fountain-coded header is 64 bytes long, the encoded data is 1024 bytes long, and the total length of the fountain broadcast datagram is 1088 bytes, which is far lower than the effective payload limit of 1400 bytes corresponding to the maximum transmission unit of common Ethernet, enabling transmission in a dedicated network as a single packet without generating underlying fragmentation. The content delivery server encapsulates the generated fountain broadcast datagram into a User Datagram Protocol (UDP) broadcast message, specifies the broadcast address of the private network as the destination address, specifies the preset broadcast port number as the destination port number, and sends it to all glasses terminals within the private network through the UDP broadcast channel.With this fountain encoding method, any glasses terminal can recover the complete task content data by receiving a sufficient number of fountain broadcast data packets, without having to establish an independent connection for each terminal. This significantly reduces the connection management overhead of the content delivery server and improves the efficiency of task content data distribution in multi-glass terminal scenarios.

[0037] After generating fountain broadcast datagrams, the content delivery server encapsulates them into User Datagram Protocol (UDP) broadcast messages, specifying the private network's broadcast address as the destination address and a preset broadcast port number as the destination port number. The content delivery server can send fountain broadcast datagrams at fixed time intervals, such as one every 10 milliseconds, to balance the speed of task content data delivery with the bandwidth usage of the private network. When the fountain-coded packet stream corresponding to a certain task content data has not yet been fully recovered by the glasses terminals within the private network, the content delivery server can continuously generate subsequent fountain-coded packets and continuously encapsulate them into fountain broadcast datagrams, sending them through the UDP broadcast channel. At any given time, as long as a glasses terminal joining the private network receives a sufficient number of fountain broadcast datagrams, it can recover the complete task content data based on the fountain-coded header and coded data, avoiding the need to establish an independent connection and retransmit separately for each glasses terminal. This reduces the connection management overhead on the content delivery server side and improves the efficiency of task content data distribution in multi-glass terminal scenarios within the private network.

[0038] In one optional implementation, the content delivery server can adjust the length of the basic data fragments and the number of basic data fragment numbers in the fountain coding group based on the importance of the task content data. For example, for critical task content data that needs to be delivered quickly and ensures a high probability of recovery, the content delivery server can use a smaller basic data fragment length and a larger number of basic data fragment numbers. This allows the encoded data of each fountain broadcast datagram to cover more basic data fragments, thereby increasing the probability that any basic data fragment is included in multiple fountain coding groups when the same number of fountain broadcast datagrams are delivered. This facilitates the recovery of complete task content data by the glasses terminal within the private network under packet loss conditions through a small amount of compensation broadcast. For task content data that is large in size but has low timeliness requirements, a configuration of a basic data fragment length of 2048 bytes and a number of basic data fragment numbers in the fountain coding group can be used to reduce the number of records in the task basic data fragment table and reduce the number of bitwise XOR operations during fountain coding, thus reducing the computational burden on the content delivery server.

[0039] In one specific implementation, each glasses terminal listens for messages carrying fountain broadcast datagrams in the User Datagram Protocol (UDP) broadcast channel via a network interface. When a glasses terminal receives a fountain broadcast datagram, it first parses the header of the datagram, reading the task identifier and the set of basic data fragment numbers from the fountain encoded header. The glasses terminal then checks locally whether a corresponding basic data fragment reception status table already exists based on the task identifier. If not, it creates a new basic data fragment reception status table and allocates a separate buffer area in its local receive buffer for that task identifier to store the fountain broadcast datagram corresponding to that task identifier and its recovery result.

[0040] The basic data fragment reception status table contains multiple records, each corresponding to a basic data fragment number. Each record includes at least a receive flag field and a recovery flag field. The receive flag field indicates whether the glasses terminal has received the fountain broadcast datagram containing the basic data fragment number, and the recovery flag field indicates whether the glasses terminal has recovered the byte content corresponding to the basic data fragment during the fountain decoding process. When creating a new basic data fragment reception status table, the glasses terminal can create a record for each basic data fragment number in the table based on the number of task basic data fragments synchronously obtained from the content delivery server, and initialize the receive flag field and recovery flag field to the "not received" and "not recovered" states, respectively.

[0041] When a fountain broadcast datagram arrives, the glasses terminal stores the fountain encoding header and encoded data of the datagram in the receive buffer according to the task identifier. Then, based on the set of basic data fragment numbers in the fountain encoding header, the glasses terminal accesses the basic data fragment receive status table one by one, setting the receive flag field of the corresponding basic data fragment number to "received". In this way, even if the encoded data is a combination of multiple basic data fragments, the basic data fragment receive status table can reflect whether each basic data fragment appears in at least one fountain broadcast datagram. After each update of the receive flag field, the glasses terminal can count the number of basic data fragment numbers in the "received" state and compare it with the total number of basic data fragments in the task. When the number of received basic data fragments reaches a preset decodable threshold, the fountain decoding module is triggered to begin recovering the task content data. For example, when the total number of basic data fragments in the task is 100, the decodable threshold can be set to 110. This means that when the receive buffer contains fountain broadcast datagrams covering at least 110 basic data fragment numbers, it is considered to have a high probability of successful recovery, thus initiating the fountain decoding process.

[0042] When the glasses terminal invokes the fountain decoding module to perform fountain decoding, it first searches the receive buffer for fountain broadcast data packets whose fountain encoding header contains only a single basic data segment number. The encoded data of these fountain broadcast data packets is directly equivalent to the original content of the corresponding basic data segment, thus recovery can be completed without relying on other fountain broadcast data packets. The fountain decoding module directly writes this encoded data into the recovery buffer corresponding to the basic data segment number and sets the recovery flag field of the corresponding basic data segment number in the basic data segment receive status table to the recovered status. This step provides known basic data segment content for subsequent bitwise XOR elimination. If these fountain broadcast data packets containing a single basic data segment number are not processed first, the known portion of all subsequent fountain broadcast data packets containing multiple basic data segment numbers cannot be eliminated, significantly slowing down the recovery process.

[0043] After processing fountain broadcast datagrams containing only a single basic data segment number, the fountain decoding module continues to search the receive buffer for fountain broadcast datagrams whose fountain encoded header contains multiple basic data segment numbers and whose recovery flag field for at least one basic data segment number is in a recovered state. For each matching fountain broadcast datagram, the fountain decoding module reads the complete byte sequence from the encoded data and sequentially reads the byte sequences in the recovery buffer corresponding to all recovered basic data segment numbers. The fountain decoding module performs a bitwise XOR operation on the encoded data and the content of each recovered basic data segment at the same byte position. Since the fountain encoding stage obtains the encoded data by combining multiple basic data segment contents through bitwise XOR, the receiving end, knowing some of the basic data segment contents, can gradually eliminate the influence of these known basic data segments by performing a bitwise XOR operation on the encoded data and the known basic data segment contents again, ultimately obtaining the byte content of the remaining basic data segment. The fountain decoding module writes this byte content into the recovery buffer corresponding to the basic data segment number and sets the recovery flag field of that basic data segment number to a recovered state.

[0044] The fountain decoding module repeats the above process, traversing the fountain broadcast datagrams in the receive buffer multiple times. In each traversal, it uses the currently recovered basic data fragment number set to process the fountain broadcast datagrams containing those numbers, restoring as much new basic data fragment content as possible. As the number of recovered basic data fragment numbers increases, the number of unknown encoding combinations that can be eliminated in subsequent traversals also increases, resulting in faster recovery speeds. When the recovery flag field for all basic data fragment numbers in the basic data fragment receive status table is set to the recovered status, it indicates that all basic data fragments of the task content data have been successfully recovered, and the fountain decoding process ends.

[0045] If, after traversing all fountain broadcast datagrams in the receive buffer, the fountain decoding module finds that the recovery flag field for some basic data fragment numbers in the basic data fragment receive status table is still in an unrecovered state, then the basic data fragment recovery is considered incomplete. This situation typically arises because the linear independence between the combination of basic data fragment numbers in existing fountain broadcast datagrams in the receive buffer and the set of recovered basic data fragment numbers is insufficient; that is, it is no longer possible to generate new basic data fragment content through simple bitwise XOR elimination. In this case, if the system continues to wait for new fountain broadcast datagrams to arrive randomly, the recovery process becomes unpredictable. Therefore, when the glasses terminal detects incomplete basic data fragment recovery, it proactively generates a Precise Retransmission Request (NACK) message and sends it to the content delivery server via the uplink compensation channel to explicitly inform which basic data fragments have not yet been recovered.

[0046] During the generation of the Precise Retransmission Request Message (NACK), the glasses terminal collects all basic data segment numbers whose recovery flag field is still in an unrecovered state from the basic data segment reception status table and adds these basic data segment numbers to the missing basic data segment number list. Simultaneously, the glasses terminal writes the task identifier and the number of missing basic data segment numbers into the Precise Retransmission Request Message (NACK). In this way, after receiving the Precise Retransmission Request Message (NACK), the content delivery server can accurately determine which task's content data to compensate for and which basic data segment numbers need to be prioritized for coverage, without performing a large number of redundant retransmissions, thus saving dedicated network bandwidth.

[0047] The glasses terminal sends a Precise Retransmission Request Message (NACK) to the content delivery server via an uplink compensation channel. This uplink compensation channel can be a unicast channel based on the User Datagram Protocol (UDP) or a reliable channel based on the Transmission Control Protocol (TCP). In one specific implementation, to reduce connection establishment overhead, a long-term uplink compensation channel can be established between the glasses terminal and the content delivery server upon startup, used to send multiple Precise Retransmission Request Messages (NACK) throughout the entire task cycle. To improve compensation response speed, the glasses terminal can send a Precise Retransmission Request Message (NACK) immediately after detecting incomplete recovery of the underlying data segment, or it can send it only after multiple consecutive fountain decoding attempts have failed, to avoid misjudgments due to brief packet loss.

[0048] After receiving a NACK (Near Acknowledgement of Acknowledgement) message, the content delivery server reads the corresponding basic data segment content from the missing basic data segment number list in the task basic data segment table based on the task identifier, forming a set of missing basic data segments. Additionally, the content delivery server can select some basic data segments that have been successfully recovered on most glasses terminals from the task basic data segment table as an auxiliary set of basic data segments. This approach is based on the consideration that the compensating fountain broadcast datagram still uses a bitwise XOR combination to generate encoded data. If only missing basic data segments are used for encoding, each compensating fountain broadcast datagram may contain only a very small number of basic data segment numbers, reducing the randomness and fault tolerance of the fountain encoding. By simultaneously adding at least one missing basic data segment and several auxiliary basic data segments to each compensating fountain broadcast datagram, it can maintain the concentrated coverage of missing basic data segments while preserving the diversity of the encoding structure, facilitating decoding by different glasses terminals at their varying recovery progress.

[0049] When selecting the combination of basic data fragment numbers for each compensating fountain broadcast datagram, the content delivery server can employ either a fixed or random strategy. For example, in one implementation, the content delivery server combines each missing basic data fragment number with two auxiliary basic data fragment numbers in the order of their occurrence to form a basic data fragment number set, which is then used to generate a compensating fountain broadcast datagram. In this way, the missing basic data fragment number appears only once in each compensating fountain broadcast datagram, while the auxiliary basic data fragment numbers can appear repeatedly in multiple compensating fountain broadcast datagrams, thus ensuring that each missing basic data fragment is covered in at least one compensating fountain broadcast datagram. In another implementation, when generating each compensating fountain broadcast datagram, the content delivery server randomly selects one missing basic data fragment number and multiple auxiliary basic data fragment numbers to form a basic data fragment number set. This makes the combinations of compensating fountain broadcast datagrams received by different glasses terminals more diverse, improving the overall decoding success rate.

[0050] After selecting the set of basic data fragment numbers, the content delivery server reads the byte content of the corresponding basic data fragment from the task's basic data fragment table in the same way as the initial fountain encoding. It then performs a bitwise XOR operation on all basic data fragment contents at the same byte position to obtain the encoded data of the compensation fountain broadcast datagram. The content delivery server writes the missing basic data fragment number and the auxiliary basic data fragment number into the compensation fountain encoding description information, and combines the compensation fountain encoding description information with the task identifier to form the compensation fountain encoding header. Subsequently, the content delivery server concatenates the compensation fountain encoding header with the encoded data to generate the compensation fountain broadcast datagram, encapsulates it into a User Datagram Protocol (UDP) broadcast message, and broadcasts it again to all glasses terminals within the private network through the UDP broadcast channel.

[0051] After receiving the compensated fountain broadcast datagram, the glasses terminal writes it to the receive buffer in the same way as the initial fountain broadcast datagram, updates the basic data segment receive status table, and calls the fountain decoding module again when the decodeable quantity threshold is met. During this process, previously recovered basic data segments do not need to be recovered repeatedly; they are only used to remove encoded data from the compensated fountain broadcast datagram during the fountain decoding process. Through the new basic data segment number combinations introduced by the compensated fountain broadcast datagram, the fountain decoding module can obtain more linearly independent encoding equations, gradually recovering the previously unrecoverable basic data segments, ultimately setting the recovery flag field of all basic data segment numbers in the basic data segment receive status table to the recovered state.

[0052] Once the glasses terminal confirms that all basic data fragments of the task content data have been recovered, and has assembled the basic data fragment content from the recovery cache into complete task content data according to the basic data fragment number order, the glasses terminal creates a task record for the task identifier in the local task table. This record includes the task identifier, the storage location of the task content data in the local storage medium, and the current task status field. After this step, the task status field can be set to a registered state, indicating that the task content data needs to be executed and confirmed via voice in subsequent steps. By registering in the local task table, the glasses terminal can reliably retrieve the task content data despite multiple power-ups or changes in network status, and associate it with subsequently generated task confirmation events and batch feedback messages, ensuring data tracking consistency throughout the entire task lifecycle.

[0053] In one alternative implementation, to avoid congestion of the uplink compensation channel caused by frequent sending of exact retransmission request messages (NACK), the glasses terminal can introduce a wait timer. After the fountain decoding module determines that the basic data segment recovery is incomplete, a wait timer with a duration of, for example, 200 milliseconds is started. During the wait timer's duration, the glasses terminal continues to receive new fountain broadcast datagrams and attempts to decode the fountain. If all basic data segments are successfully recovered before the wait timer expires, the exact retransmission request message (NACK) is no longer sent; only when the basic data segment recovery is still incomplete when the wait timer expires is the exact retransmission request message (NACK) generated and sent. In this way, temporary recovery failures caused by short-term broadcast jitter can be filtered out, allowing the exact retransmission request message (NACK) to be mainly used to handle continuous packet loss problems, which is more in line with the usage requirements of dedicated network scheduling resources.

[0054] In one specific implementation, after the glasses terminal completes the fountain decoding of the task content data and sets the task status field to the registered state in the local task table, the local task scheduling logic initiates the execution of the task content data according to a preset strategy. The task content data may correspond to an operation prompt, an inspection step, a training content playback, or a set of operations that the wearer needs to complete in sequence. The glasses terminal displays images or text related to the task content data on the screen, and simultaneously plays task prompt voice through the speaker to guide the wearer to complete the actual actions according to the task content data.

[0055] During task execution, to prevent tasks from being unintentionally marked as complete, the glasses require the wearer to verbally confirm that they have completed the corresponding data operations for the task. The glasses are pre-configured with a voice confirmation module designed to detect and recognize when the wearer consciously utters phrases like "task completed," "execution finished," or similar fixed sentences. Voice confirmation is used instead of gestures or automatic judgment because wearers' hands are often occupied in work scenarios; voice commands do not require additional physical movement resources, and the voice content has a clear time point and semantics, which can be used for auditing and tracking in the backend.

[0056] When the task scheduling logic determines that data for a specific task has entered the execution phase, it invokes the voice confirmation module to begin voice acquisition. The voice confirmation module controls the microphone to continuously acquire the wearer's voice within a preset time window, such as 10 or 30 seconds. During acquisition, the voice confirmation module divides the continuous sound signal into multiple audio frames of fixed length, for example, each audio frame corresponds to a 20-millisecond duration. For each audio frame, the voice confirmation module calculates the short-time energy and zero-crossing rate to determine whether the current audio frame contains speech components.

[0057] Short-time energy reflects the overall amplitude of an audio frame, while the zero-crossing rate reflects the frequency of signal changes within the audio frame. Silence or background noise typically has low short-time energy and a relatively stable zero-crossing rate; however, when the wearer speaks confirmation commands, the short-time energy increases significantly, and the zero-crossing rate fluctuates noticeably. The voice confirmation module pre-sets a set of voice thresholds locally. When both the short-time energy and the zero-crossing rate exceed these thresholds, the audio frame is marked as a voice frame; otherwise, it is marked as a silence frame. Consecutive voice frames are concatenated into voice segments, with silence frames serving as boundaries between these segments. This allows for the separation of multiple candidate voice segments during long-term acquisition, avoiding the treatment of entire noise segments as a single command.

[0058] For each speech segment, the speech confirmation module further performs speech feature extraction to obtain a compact representation suitable for matching confirmation commands. Specifically, the speech confirmation module pre-emphasizes each speech segment, highlighting high-frequency components to improve speech clarity, and then re-frames it according to a fixed length, applying a window function to each frame to reduce frame boundary discontinuities. Next, the speech confirmation module extracts a set of Mel-frequency cepstral coefficients from each frame through a series of filtering and transformation operations. This set of coefficients can well describe the energy distribution characteristics of human speech in the auditory frequency band and is not easily affected by changes in overall volume, thus being suitable for expressing the pronunciation features of phrases such as "task completed" or "task finished." The speech confirmation module combines the Mel-frequency cepstral coefficients corresponding to each frame in chronological order to form a speech command feature sequence, which serves as candidate features for the current confirmation command speech.

[0059] To identify whether the wearer has issued a confirmation voice command, the voice confirmation module pre-collects several confirmation phrases spoken by multiple users in quiet environments during the device manufacturing or deployment phase. These phrases include phrases such as "task completed," "this session completed," and "operation finished." The collected voice samples undergo the same feature extraction process to generate multiple command voice templates. Each command voice template is saved as a template feature sequence and associated with a unique voice confirmation template identifier. Simultaneously, in the local configuration, each command voice template is marked as either a confirmation command template or a non-confirmation command template to distinguish between commands that trigger task confirmation events and commands used only for other functions.

[0060] In actual operation, after obtaining the current voice command feature sequence, the voice confirmation module performs dynamic time warping matching on the template feature sequence corresponding to each command voice template. The purpose of dynamic time warping matching is to find the most reasonable alignment path between the current voice command feature sequence and the template feature sequence, allowing for differences in speaking speed and slight syllable scaling, and to provide the overall degree of difference accordingly. In the two-dimensional alignment grid, starting from the beginning, the voice confirmation module calculates the difference value for each pair of frames, then selects the path with the lowest cumulative difference from the three possible path sources, adds the current difference value to it, and finally obtains the total cumulative difference value corresponding to each command voice template at the end of the grid. The smaller the total cumulative difference value, the closer the current voice command feature sequence is to the template.

[0061] refer to Figure 2 , Figure 2 This is a schematic diagram illustrating the principle of voice command matching based on a dynamic time warping algorithm provided in this invention. The diagram details how the voice confirmation module of the glasses terminal compares the input voice command feature sequence collected on-site with a preset template voice feature sequence, and determines whether the wearer has issued a valid confirmation command based on the comparison result. As shown in the figure, the horizontal axis of the coordinate system represents the input voice command feature sequence Q, which is obtained by the glasses terminal after collecting the wearer's voice and undergoing steps such as endpoint detection, pre-emphasis, frame windowing, and Mel-frequency cepstral coefficient extraction. The total length of the input feature sequence is M frames; for example, in the embodiment shown in the figure, M is 24. The vertical axis of the coordinate system represents the template voice feature sequence C pre-stored locally on the glasses terminal. This template corresponds to a standard confirmation command phrase, such as "complete task" or "confirm execution," and its total length is N frames; in the embodiment shown in the figure, N is 20. Due to differences in speaker speed, the length M of the input sequence and the length N of the template sequence are usually not equal, and the duration of the same syllable can also undergo non-linear scaling changes, therefore, direct linear point-to-point comparison is not possible.

[0062] Figure 2The central region of the graph displays an N x M cost matrix. Each grid point in the matrix represents the distance metric between the i-th frame of the template sequence and the j-th frame of the input sequence, typically calculated using Euclidean or cosine distance. The graph uses a grayscale heatmap to represent the magnitude of local distances; darker colors indicate higher matching degrees, i.e., smaller distances. A thick solid line across the matrix represents the optimal warping path. The core of the dynamic time warping algorithm is to find a path that starts at the lower left corner of the matrix (where the input aligns with the template's starting frame) and extends to the upper right corner (where the input aligns with the template's ending frame). This path must satisfy boundary, continuity, and monotonicity constraints. During path search, the algorithm calculates the cumulative distance at each step and selects the direction with the minimum cumulative distance for extension. The shape of the optimal warping path reflects the temporal distortion of the input speech relative to the template speech. For example, nearly horizontal line segments in the path indicate elongation of certain syllables in the input speech, while nearly vertical line segments indicate a faster speech rate.

[0063] exist Figure 2 The right-hand side of the diagram illustrates the final logic of the matching determination. Based on the found optimal regularized path, the system calculates the sum of distances between all corresponding frames along the entire path, i.e., the total cumulative distance D. In this embodiment, the calculated total cumulative distance D is a specific numerical value. The system presets a confirmation threshold T, which is set according to the environmental noise level and the degree of security stringency. The logic diagram shows that when the calculated total cumulative distance D is less than the confirmation threshold T, it indicates that the input voice command feature sequence and the template feature sequence are highly similar within the allowable time scaling range. The system determines that the match is successful, considering that the wearer has issued a valid confirmation command, thus triggering a task confirmation event. Conversely, if the total cumulative distance D is greater than or equal to the threshold T, the match is determined to have failed, and the voice segment is ignored. Through this matching mechanism based on dynamic time regularization, the present invention can effectively overcome the recognition interference caused by changes in speech rate under different levels of fatigue or tension, significantly improving the robustness and accuracy of handsless voice confirmation.

[0064] After completing dynamic time warping matching of all templates, the voice confirmation module selects the template with the smallest total cumulative difference value as the template corresponding to the recognition result. Next, the voice confirmation module determines whether the template corresponding to the recognition result is marked as a confirmation command template and compares the total cumulative difference value with a locally configured confirmation threshold. For example, the confirmation threshold can be set between 1000 and 3000 based on the ambient noise level. If the template corresponding to the recognition result is a confirmation command template and the total cumulative difference value is less than the confirmation threshold, it is considered that the wearer has clearly issued a confirmation command voice. In this case, the voice confirmation module generates a task confirmation event and submits it to the task management logic. The task management logic reads the current task identifier from the task confirmation event, updates the task status field of the record corresponding to that task identifier in the local task table from the registered status to the local confirmation status, and records the voice confirmation template identifier of the template corresponding to the recognition result, as well as the timestamp of the current voice segment under the local time base, in the local task table to provide a basis for subsequent batch transmission and backend auditing.

[0065] This voice confirmation method eliminates the unilateral determination of task status by the device's internal logic, instead linking it to the wearer's active confirmation behavior. The wearer only issues confirmation commands when they genuinely believe the task data has been completed, significantly reducing the risk of false confirmations due to accidental touches, automatic task progression, or temporary interruptions. Furthermore, saving the voice confirmation template identifier and timestamp allows for backend reconstruction of the specific confirmation phrase used and the time of occurrence, providing foundational data for subsequent issue tracing and behavior analysis.

[0066] As multiple tasks are executed sequentially and task confirmation events are generated via the voice confirmation module, the local task table will display multiple records with a task status field indicating local confirmation and an execution status field indicating completion. To centrally report the completion status of these tasks to the content delivery server upon network recovery, instead of uploading each task identifier individually, the glasses terminal uses a Bloom filter digest bit array to compress and represent the set of completed tasks. The Bloom filter digest bit array is a fixed-length bit array where each bit has only two values: 0 or 1, indicating whether a task identifier is included in the set of completed tasks. By mapping task identifiers to several positions in the bit array using multiple different hash functions and setting the values ​​of these positions to 1, a large set of task identifiers can be represented with relatively little space. The characteristic of the Bloom filter is that it avoids false positives; for tasks that are actually completed, the corresponding position in the bit array will definitely be set to 1. However, a small number of false positives may occur, meaning that some tasks that are not actually completed may be judged as completed by the bit array. To reduce the impact of false positives, the glasses terminal also uploads separate execution result summaries and voice confirmation template identifiers for critical tasks as a basis for accurate verification.

[0067] When constructing the Bloom filter digest bit array, the glasses terminal first filters records from the local task table that have a task status field indicating local confirmation and an execution status field indicating completion, forming a set of tasks to be sent back. Then, the glasses terminal selects a fixed length for the Bloom filter digest bit array, such as 4096 bits (512 bytes), and uses this length as the standard configuration for the device. During bit array initialization, all 4096 bits are set to 0. Next, the glasses terminal internally stores the implementation logic of several hash functions, for example, four hash functions. Each hash function takes the task identifier string as input, generates an intermediate integer value through sequential traversal of the character encoding value, addition operations, and left or right shift operations, and then performs a modulo operation on the intermediate integer value divided by 4096 to obtain an integer index between 0 and 4095. This integer index is used as the subscript of the Bloom filter digest bit array, indicating the bit position that needs to be set to 1.

[0068] For each task identifier in the set of tasks to be returned, the glasses terminal sequentially calls all hash functions. Each time a hash function is called, an integer index is obtained. The glasses terminal then accesses that index position in the Bloom filter digest bit array and sets its bit value to 1. Since the same task identifier will generate multiple different integer indices through multiple hash functions, multiple positions in the bit array associated with that task identifier will be set to 1. If the index positions obtained by different task identifiers through hash calculation overlap, the corresponding bit value will still be 1, indicating that these tasks share these bit positions. This process is repeated until all task identifiers in the set of tasks to be returned have been processed, and multiple tags in the bit array are applied to all task identifiers, ultimately resulting in the Bloom filter digest bit array. Because the bit array length is fixed, the size of the bit array will not increase as the number of tasks increases, effectively controlling upload bandwidth and storage consumption.

[0069] Meanwhile, the glasses terminal can also mark several key tasks in the set of tasks to be returned based on their importance. Key tasks can be defined by the content delivery server during the task delivery phase through task attribute fields, such as tasks related to safety operations, critical process steps, or tasks that require documentation under regulatory requirements. For each key task, the glasses terminal not only marks it in the Bloom filter summary bit array but also generates a key task execution result summary locally. The key task execution result summary can include brief information such as whether the task was successfully executed, the task completion time, and task-related exception markers. Furthermore, the glasses terminal records a corresponding voice confirmation template identifier for each key task, allowing the backend to determine which confirmation command was used for voice confirmation. Thus, even if there is a small risk of misjudgment in the Bloom filter summary bit array, key tasks can still be verified using accurate task execution result summaries and voice confirmation template identifiers.

[0070] When preparing to send batch backhaul messages, the glasses terminal constructs a unified data structure, including a Bloom filter summary bit array, task identifiers for multiple key tasks, a summary of the execution result for each key task, a voice confirmation template identifier for each key task, and a batch backhaul timestamp. The glasses terminal encodes this data according to a predetermined format, for example, writing the bit array length first, then the bit array content, then the number of key tasks, and finally, writing the fields related to each key task in sequence. After encoding, the glasses terminal sends the batch backhaul messages to the content delivery server via the backhaul link. The backhaul link can use the same long-lived connection as the exact retransmission request (NACK) message, or a separate connection can be established for batch backhaul. When network quality is good, the glasses terminal can immediately clear the locally confirmed upload status tasks after each batch backhaul, freeing up storage space; when network quality is poor, the batch backhaul messages can be cached locally and sent all at once when the backhaul link becomes available.

[0071] After receiving batch return messages, the content delivery server first parses the Bloom filter digest bit array and loads it into memory in the same length and index order. Then, the content delivery server sequentially reads all task identifiers it maintains from the task management record. For each task identifier, the content delivery server calls the same set of hash functions in the exact same way as the glasses terminal, performing character traversal, addition, and shift operations to generate multiple integer indices. For each integer index, the content delivery server reads the bit value at the corresponding position in the Bloom filter digest bit array. When all the bits at the corresponding integer index positions of the task identifier are 1, the content delivery server adds the task identifier to the completed task set; when any bit value at any of the corresponding integer index positions is 0, the content delivery server keeps the task identifier in the pending or unconfirmed task set. Through this traversal process, the content delivery server does not need to receive each task identifier individually, but completes the determination of a large number of task statuses through a single bit array parsing, significantly reducing the amount of data returned.

[0072] refer to Figure 3 , Figure 3This diagram illustrates the memory layout of a hybrid data structure for batch backhaul messages in a private network environment, as provided by an embodiment of the present invention. From the perspective of computer memory address space, the diagram details the data packet structure constructed by the glasses terminal during network recovery or periodic reporting, progressing from low to high addresses. The core design of this data structure balances the limited bandwidth of the private network with the integrity of critical task auditing, employing a hybrid encoding method combining Bloom filter digests and critical task details. As shown, the entire data structure is stored contiguously in memory, facilitating direct serialization and transmission to the content delivery server via the backhaul link. At the top of the memory layout, in the low-address region, is the message header. This section contains the message type identifier, the total length of the entire data packet, and the timestamp when the batch backhaul was generated. Following the message header is the Bloom filter digest bit array region, the core component for achieving high compression ratio backhaul in this invention. As shown by the shaded area in the diagram, this region occupies a fixed memory space, for example, 512 bytes, or 4096 bits. Regardless of how many ordinary tasks the glasses terminal completes while offline, as long as these tasks are non-critical routine operations, their completion status is recorded in these 4096 bits using a hash mapping. The annotation on the right side of the diagram indicates that this fixed-length structure is used for efficient confirmation of massive amounts of ordinary tasks. Although there is a very low probability of false positives, it can save a significant amount of bandwidth resources in large-scale task scenarios, avoiding the transmission of hundreds or thousands of specific task identifier strings. Following the Bloom filter digest bit array is a critical task counter, used to indicate the number of subsequent critical task records; in the example in the diagram, N equals 2. This design reflects the invention's refined management strategy for high-value data. For critical tasks involving security, quality control, or regulatory oversight, it is not sufficient to rely solely on a Bloom filter with the potential for false positives; complete execution details must be transmitted back. Therefore, multiple critical task record structures are arranged sequentially in the lower area of ​​the memory layout. Taking critical task record 1 as an example, the diagram shows in detail the memory allocation of its internal fields. First, there's a 16-byte task identifier field, used to uniquely index the task. Second, there's an execution result summary field, recording the specific status code and exact completion time. Most importantly, there's a 4-byte voice confirmation template ID field, which clearly records which voice command template the wearer used to confirm the critical task, such as whether they used "task complete" or "emergency termination." Additionally, a variable-length area is reserved at the end of the structure for storing potential anomalies or audit notes. Figure 3The arrows on the left clearly illustrate the technical advantages of this hybrid memory layout. The upper area represents coarse-grained verification, trading space for efficiency to achieve high compression ratio transmission; the lower area represents fine-grained traceability, ensuring complete records and providing an impeccable audit trail. Upon receiving the data packet, the content delivery server parses it sequentially. First, it reads the Bloom filter bit array and quickly updates the status of ordinary tasks in batches through bitwise operations; then, based on the critical task count, it extracts detailed records and voice template information for each critical task, performing precise verification and archiving. This hierarchical data structure design perfectly suits the application requirements of private network environments that are both bandwidth-sensitive and have extremely high reliability requirements for critical business data.

[0073] For critical tasks included in batch message returns, the content delivery server searches for the corresponding task identifier in the completed task set and extracts a summary of the critical task execution result and a voice confirmation template identifier from the message. The content delivery server can compare the summary of the critical task execution result with the configuration information when the task was created, such as comparing the expected completion status with the actual completion status, and comparing the expected execution time with the actual completion time interval. If obvious anomalies are found, an alarm marker can be added to the task management record to prompt operations personnel for further investigation. The voice confirmation template identifier is used to confirm which confirmation phrase the wearer used when performing this critical task, helping to determine whether on-site usage habits are consistent with the preset process. In scenarios requiring a complete audit chain, the content delivery server can also perform more granular log analysis based on the voice confirmation template identifier and timestamp information, in conjunction with backend voice logs.

[0074] Through the above processing, the content delivery server obtains the set of completed tasks based on the Bloom filter summary bit array, verifies the completion status of key tasks based on the key task execution result summary and voice confirmation template identifier, and finally writes this information into the task management record, updating the task status field of the record corresponding to each task identifier. For tasks determined to be completed, the task status field in the task management record can be updated to complete; for tasks still in the pending execution or pending confirmation task set, the task status field in the task management record remains unchanged, awaiting subsequent batch feedback messages or other supplementary information. In this way, the glasses terminal in the dedicated network implements voice-driven task confirmation locally, and achieves centralized feedback of task completion information with high compression ratio, high efficiency, and still auditable capability through the Bloom filter summary bit array, key task execution result summary, and voice confirmation template identifier.

[0075] While specific embodiments of the present invention have been described above, those skilled in the art should understand that these specific embodiments are merely illustrative. Those skilled in the art can omit, substitute, and modify the details of the above methods and systems in various ways without departing from the principles and essence of the present invention. For example, combining the above method steps to perform substantially the same function and achieve substantially the same result according to substantially the same method falls within the scope of the present invention. Therefore, the scope of the present invention is defined only by the appended claims.

Claims

1. A method for content delivery and local confirmation at the glasses end in a private network environment, characterized in that, Includes the following steps: Step 1: The content delivery server assigns a task identifier to each task content data, executes fountain coding to generate fountain broadcast data packets, and sends them to the glasses terminals in the private network through the User Datagram Protocol broadcast channel; Step 2: Each glasses terminal receives the fountain broadcast data packet, establishes the basic data segment reception status and recovery status based on the fountain encoding header, calls the fountain decoding module to recover the task content data, and generates a precise retransmission request message NACK when the basic data segment recovery is incomplete and sends it through the uplink compensation channel. The content delivery server generates a compensation fountain broadcast data packet based on the precise retransmission request message NACK and broadcasts it again until the glasses terminal recovers the complete task content data and registers it in the local task table. Step 3: When the glasses terminal executes task content data in the registration state, it triggers the voice confirmation module to collect the wearer's confirmation command voice to generate a task confirmation event, updates the task status to the local confirmation state, and constructs a Bloom filter summary bit array after completing multiple task content data in the local confirmation state. The Bloom filter summary bit array, along with the key task execution result summary and voice confirmation template identifier, is written into a batch return message and sent to the content delivery server via the return link. The content delivery server parses the Bloom filter summary bit array to obtain the set of completed tasks and updates the task management record. Before generating the fountain-encoded group stream, the content delivery server also includes: establishing a task record for each piece of task content data to be delivered, assigning a unique task identifier to each piece of task content data, dividing each piece of task content data into multiple basic data segments according to a preset data length, assigning a basic data segment number to each basic data segment, and writing the task identifier, basic data segment number, and storage location of the basic data segment in the storage medium into a task basic data segment table. The task basic data segment table is used by the fountain encoding module and the compensation fountain encoding generation module to read the corresponding basic data segment according to the basic data segment number during subsequent encoding and compensation.

2. The method according to claim 1, characterized in that, When generating the fountain-coded packet stream, the content delivery server calls the fountain coding module. The fountain coding module generates multiple basic data fragment numbers based on the task identifier, the current coding round information, and the internal pseudo-random seed. It sequentially reads the corresponding basic data fragments from the task basic data fragment table, performs a bitwise XOR operation on all basic data fragments at the same byte position to obtain the encoded data of the fountain-coded packet, records the set of basic data fragment numbers that participated in generating the fountain-coded packet as the fountain coding description information, combines the fountain coding description information with the task identifier to form the fountain coding header, and concatenates the fountain coding header with the encoded data to generate a fountain broadcast datagram. The content delivery server sequentially encapsulates multiple fountain broadcast datagrams into a User Datagram Protocol (UDP) broadcast message and broadcasts it to the glasses terminal in the private network through the UDP broadcast channel.

3. The method according to claim 2, characterized in that, When managing fountain broadcast data packets in the receive buffer, the glasses terminal performs the following steps: The glasses terminal parses the fountain encoding header from each fountain broadcast data packet, extracts the task identifier and the set of basic data segment numbers, establishes a basic data segment reception status table locally for the task identifier, sets a receive flag field and a recovery flag field for each basic data segment number in the basic data segment reception status table, and when a fountain broadcast data packet is received, the glasses terminal sets the receive flag field corresponding to the basic data segment number involved in the fountain broadcast data packet to the received state, keeps the receive flag field corresponding to the basic data segment number that has not yet appeared in any fountain broadcast data packet to the pending reception state, and stores the fountain encoding header and encoded data of the fountain broadcast data packet in the local receive buffer for subsequent fountain decoding.

4. The method according to claim 3, characterized in that, When the glasses terminal performs fountain decoding based on the reception status of basic data segments, the specific steps include: First, counting the number of basic data segment numbers in the reception status table whose reception flag field is in the received state. When the number reaches a preset decodeable threshold, the fountain decoding module is invoked. The fountain decoding module searches the reception buffer for fountain broadcast data packets whose fountain encoding header contains only a single basic data segment number. The encoded data of the fountain broadcast data packet is directly written into the recovery buffer of the corresponding basic data segment number, and the recovery flag field of the corresponding basic data segment number in the basic data segment reception status table is set to the recovered state. Subsequently, the fountain decoding module searches the reception buffer for fountain encoding headers containing multiple basic data segment numbers, where at least one of the basic data segment numbers is in the recovered state in the recovery flag field. For each fountain broadcast data packet found, the fountain decoding module reads the byte sequence from the encoded data and sequentially reads the byte sequences of all recovered basic data segments from the recovery buffer. It then performs a bitwise XOR operation on the encoded data at the same byte position with the contents of all recovered basic data segments byte by byte to obtain the byte sequence of the remaining basic data segment. This byte sequence is written into the recovery buffer corresponding to the basic data segment number, and the recovery flag field of the corresponding basic data segment number in the basic data segment reception status table is set to the recovered state. The fountain decoding module repeatedly traverses the fountain broadcast data packets in the reception buffer until the recovery flag field of all basic data segment numbers in the basic data segment reception status table is in the recovered state, forming complete task content data.

5. The method according to claim 4, characterized in that, When the fountain decoding module has traversed all fountain broadcast datagrams in the receive buffer, and there are still basic data fragment numbers in the basic data fragment receive status table with the recovery flag field in a pending recovery state, the glasses terminal performs precise retransmission request message (NACK) generation and fountain broadcast datagram reception processing. Specifically, this includes: the glasses terminal extracting all basic data fragment numbers with the recovery flag field in a pending recovery state from the basic data fragment receive status table, forming a list of missing basic data fragment numbers, writing the task identifier, the number of missing basic data fragment numbers, and the list of missing basic data fragment numbers into the message body of the precise retransmission request message (NACK), and sending it to the content delivery server via the uplink compensation channel; after receiving the precise retransmission request message (NACK), the content delivery server reads the basic data fragments corresponding to the missing basic data fragment number list from the task's basic data fragment table according to the task identifier, forming a set of missing basic data fragments, and then... A partial set of auxiliary basic data fragments is formed by reading some non-missing basic data fragments from the basic data fragment table. At least one basic data fragment is selected from the missing basic data fragment set, and several basic data fragments are selected from the auxiliary basic data fragment set. The selected basic data fragments are then subjected to bitwise XOR operations byte by byte according to byte alignment to generate the encoded data of the compensation fountain code group. The missing basic data fragment number is combined with the auxiliary basic data fragment numbers participating in the compensation to form the compensation fountain code description information and written into the compensation fountain code header. The content delivery server concatenates the compensation fountain code header and the encoded data to generate a compensation fountain broadcast datagram, which is encapsulated as a User Datagram Protocol (UDP) broadcast message and sent through the UDP broadcast channel. After receiving the compensation fountain broadcast datagram, the glasses terminal updates the basic data fragment reception status table and calls the fountain decoding module again until the recovery flag field of all basic data fragment numbers is in the recovered state.

6. The method according to claim 5, characterized in that, After the glasses terminal recovers the complete task content data, it triggers the voice confirmation module to perform voice confirmation. The process includes: collecting the wearer's voice signal within a preset time window; dividing the continuously collected voice signal into multiple continuous audio frames according to a preset duration; calculating the short-time energy and zero-crossing rate for each audio frame; marking audio frames with both short-time energy and zero-crossing rate greater than a preset voice threshold as voice frames; combining continuous voice frames into voice segments; marking audio frames with both short-time energy and zero-crossing rate less than or equal to the preset voice threshold as silence frames and using them as the boundaries of voice segments; and generating a voice segment sequence for subsequent voice feature extraction.

7. The method according to claim 6, characterized in that, The voice confirmation module will also perform pre-emphasis processing, frame segmentation processing, and windowing processing on each voice segment in sequence. After windowing, it will perform filtering and discrete transformation processing on each frame to obtain multiple Mel-frequency cepstral coefficients. The Mel-frequency cepstral coefficients corresponding to each frame will be arranged in frame order to form a voice command feature sequence. The voice confirmation module will pre-store multiple command voice templates in the local storage area. Each command voice template contains a template feature sequence corresponding to the preset command statement and is marked as a confirmation command template or a non-confirmation command template.

8. The method according to claim 7, characterized in that, The voice confirmation module establishes a two-dimensional alignment grid between the current voice command feature sequence and each template feature sequence. At the starting unit of the grid, the cumulative difference value is set as the difference value between the starting voice frame and the starting template frame. Starting from the starting unit, each unit in the grid is processed sequentially along the time sequence. For each unit, the difference value between the corresponding voice frame and the template frame is calculated first. Then, the three cumulative difference values ​​of the upper unit, the left unit, and the upper left unit are read. The minimum value of the three cumulative difference values ​​is selected and added to the current difference value. The result is written into the grid as the cumulative difference value of the current unit. At the end unit of the grid, the total cumulative difference value corresponding to the template is read. The total cumulative difference value is used as the matching result of the current template. The template with the smallest total cumulative difference value is selected as the template corresponding to the recognition result among all command voice templates. When the template corresponding to the recognition result is marked as a confirmation command template and the total cumulative difference value is less than the preset confirmation threshold, the voice confirmation module generates a task confirmation event and writes it into the local task status table. The task status field corresponding to the task identifier is updated to the local confirmation status. The template identifier of the template corresponding to the recognition result and the timestamp of the current voice segment are recorded in the local task status table.

Images