Adaptive low density parity check (LDPC) decoder architecture

Abstract

The invention relates to an adaptive low density parity check (LDPC) decoder architecture. An LDPC decoder architecture is provided for adaptively adjusting an LDPC control input for successfully decoding a corresponding received code block. The architecture supports a machine learning based process that facilitates learning the optimal LDPC control input required for a given channel condition and deployment scenario, such as log-likelihood (LLR) term scaling. This is accomplished by an unused LDPC decoder accelerator collecting posterior decoding metrics as a background process, the function of the accelerator being to process a tagged LLR dataset of different LDPC control input values. This optimal LDPC control input estimate may then be applied to real-time LDPC decoding based on previous learning under UE / channel conditions.

Description

Technical Field

[0001] The disclosure described herein generally relates to the use of an adaptive low-density parity-check (LDPC) decoder architecture, and more specifically to the use of an adaptive learning architecture that supports the improvement of the LDPC decoder control input over time using a posteriori decoding metric from an unused LDPC decoder accelerator. Background Technology

[0002] LDPC decoder algorithms use nonlinear iterative decoding algorithms, which makes their performance directly dependent on the precise scaling of the provided input log-likelihood ratio (LLR) term. For example, Figure 1 This illustrates how under- or over-scaling of the LLR term manifests in wireless performance degradation. The magnitude of this degradation varies across different variants of the LDPC decoder algorithm, potentially reaching the order of ~1.0 dB. Therefore, while an optimal scaling of the LLR term exists for LDPC decoding, achieving this optimal scaling is difficult in practice, which in turn leads to further wireless performance degradation. Consequently, LLR scaling algorithms (and more broadly, LDPC decoding algorithms) are insufficient to meet industry and consumer needs. Summary of the Invention

[0003] One aspect of this disclosure provides a wireless device comprising: a low-density parity-check (LDPC) decoder; and a processor configured to execute instructions stored in a memory to: train an LDPC decoder control input model to predict LDPC decoder control inputs using: (i) training data based on a previous log-likelihood ratio (LLR) term used by the LDPC decoder, and (ii) performance measurements of the LDPC decoder using the previous LLR term; and, using the trained LDPC decoder control input model, calculating the predicted LDPC decoder control inputs based on estimated channel parameters corresponding to when the code block is received, during inference for a code block received after the previous LLR term, wherein the LDPC decoder is configured to decode the code block using the predicted LDPC decoder control inputs, and wherein the processor is configured to train the LDPC decoder control input model during an inactive decoding period of the LDPC decoder.

[0004] One aspect of this disclosure provides a wireless device comprising: a low-density parity-check (LDPC) decoder; and a processor configured to execute instructions stored in a memory to: train a log-likelihood ratio (LLR) scaling model to predict an LLR scaling factor using: (i) training data based on previous LLR terms used by the LDPC decoder, and (ii) performance measurements of the LDPC decoder using the previous LLR terms; and, using the trained LLR scaling model, calculating the predicted LLR scaling factor based on estimated channel parameters corresponding to when the code block was received, during inference for a code block received after the previous LLR terms, wherein the LDPC decoder is configured to decode the code block using a set of scaled LLR terms generated using the predicted LLR scaling factor. Attached Figure Description

[0005] The accompanying drawings, which are incorporated herein and form part of this specification, illustrate this disclosure and, together with the specification, further serve to explain the principles and enable those skilled in the art to make and use the implementations described herein.

[0006] Figure 1 A graph showing the sensitivity of an LDPC decoder variant as an LLR scaling function is presented;

[0007] Figure 2 A block diagram of an adaptive LDPC decoding architecture according to this disclosure is shown;

[0008] Figure 3 A timeline associated with decoding operations performed by an LDPC decoder according to this disclosure is shown;

[0009] Figure 4 The timeline shown is associated with the decoding operations performed by the LDPC decoder and the training process of the LDPC decoder controlling the input model according to this disclosure;

[0010] Figure 5 The device according to this disclosure is shown; and

[0011] Figure 6 The process flow according to this disclosure is shown.

[0012] This disclosure will be described with reference to the accompanying drawings. Elements that first appear in the drawings are generally indicated by the leftmost numeral in the corresponding reference numerals. Detailed Implementation

[0013] Numerous specific details are set forth in the following description to provide a thorough understanding of this disclosure. However, those skilled in the art will appreciate that implementations of this disclosure, including structures, systems, and methods, can be practiced without these specific details. The descriptions and representations herein are common means used by those experienced or skilled in the art to most effectively communicate the substance of their work to others skilled in the art. In other instances, well-known methods, procedures, components, and circuits have not been described in detail to avoid unnecessarily obscuring this disclosure.

[0014] I. Technical Overview of Low-Density Parity-Check (LDPC) Decoders

[0015] Receiver error correction systems detect errors introduced during wireless signal transmission and reconstruct the original data free of these errors. These systems typically operate using error-correcting codes (ECC), which are encoded as part of the data transmission. The error-correcting code targets each bit of a block of code that forms part of the coded codeword. The receiver then decodes the received code block to generate the "most likely" transmitted data. Such code is designed so that, if correctly decoded, an extremely large (i.e., highly unlikely) amount of noise would be required to mislead the receiver. One such ECC technique is called low-density parity-check (LDPC) code. LDPC codes include error-correcting codes, which improve the efficiency of transmitting data over noisy channels. Although LDPC and other error-correcting codes do not guarantee a perfect reconstruction of the transmitted signal, their use significantly reduces the probability of information loss.

[0016] Therefore, the LDPC decoder is used to decode the encoded LDPC code (also referred to herein as a codeword, comprising several code blocks) for error verification purposes. To this end, the LDPC decoder receives a set of LLR (log-likelihood ratio) terms, each LLR term representing the encoded value of any suitable number (e.g., 8 bits). Each LLR term indicates the corresponding probability that each bit in the code block of the received message is either "1" or "0". A scaling factor is then applied to each LLR term in the received code block, and this process is repeated on consecutively received code blocks to reconstruct the codeword used by the transmitter when sending the encoded data.

[0017] For example, each code block can have a corresponding sequence of LLR terms, each LLR term corresponding to an individual bit within the code block. A scaling factor can represent the scalar value of a set of scaled LLR terms applied to the entire sequence to produce a set of scaled LLR terms received by the LDPC decoder and used in the decoding process. The LDPC decoder can perform an iterative process for a specific code block using each scaled LLR term to decode the code block. A codeword can represent a concatenation of all code blocks for a specific encoded data transmission. Therefore, the scaling of the LLR terms affects the probability that each bit in the received code block represents a "1" or a "0", and thus (e.g., by increasing or decreasing the number of iterations required to decode each code block) affects the efficiency of the LDPC decoder.

[0018] As is well known, the numerical generation of the LLR term is typically calculated in the demapper based on the estimated channel noise and the distance between IQ demodulated data constellation points. Therefore, the accuracy of LLR scaling is directly related to the accuracy of the noise variance estimate after minimum mean square error (MMSE) / maximum likelihood detector (MLD). Consequently, real-world wireless performance is sensitive to the accuracy of LLR scaling and depends on different signal processing algorithm variants. In practice, optimal scaling depends on channel and UE conditions, receiver gain implementation, and LDPC decoder algorithm variants. However, even with maximum effort, conventional estimates of LLR scaling cannot be guaranteed to be optimal for all channel conditions. Therefore, conventional methods focus on improving the efficiency and accuracy of the receiver LDPC decoder algorithm itself, a very challenging process that requires consideration of all practical use cases.

[0019] Another traditional approach involves considering a version of the LDPC decoder algorithm that is less sensitive to scaling errors. However, this approach only mitigates the problem at the cost of a slight performance degradation (a trade-off in wireless performance for optimal scaling). Therefore, this only slightly addresses the issue, as all decoding algorithm options suffer performance degradation due to scaling (see...). Figure 1 And due to the associated trade-offs, this prevents the use of the optimal LDPC decoder implementation.

[0020] This disclosure addresses these issues by providing an architecture that supports a machine learning-based process that facilitates adaptation to channel conditions by learning the optimal scaling required for various given channel conditions and deployment scenarios. This is achieved by collecting posterior decoding metrics as a background process using an unused LDPC decoder accelerator that processes labeled LLR datasets with varying scaling values. This optimal scaling estimate can then be applied to real-time LDPC decoding based on prior learning under a large number of UE / channel conditions.

[0021] Although this disclosure discusses various techniques in the context of wireless communication, this is a non-limiting and illustrative scenario. The adaptive LDPC decoder architecture discussed in further detail herein can be implemented for any suitable type of communication for implementing the LDPC decoding process. These communications can include wireless or wired communications, such as communication within any suitable type of network, the use of Internet Protocol (IP) data transmission, etc.

[0022] II. Adaptive LDPC Decoding Architecture

[0023] Figure 2 A block diagram of an adaptive LDPC decoding architecture according to this disclosure is shown. Figure 2 The various blocks shown can be identified by the execution of software, hardware components, or any suitable combination of these components. Alternatively, some blocks of architecture 200 can be identified by hardware accelerators, as discussed further in detail herein. Architecture 200 can be implemented as part of any suitable device configured to wirelessly receive data transmissions according to any suitable number and / or type of communication protocols. Therefore, for the purpose of providing some non-limiting and illustrative scenarios, architecture 200 can be implemented as part of a base station, user equipment (UE) (such as mobile devices, laptops, etc.).

[0024] To provide various non-limiting and illustrative scenarios, the architecture 200 further discussed herein can be implemented to facilitate communication based on any suitable communication network, protocol, standard, radio access technology (RAT), etc., which may include any suitable type of cellular standard, such as 3GPP standards, including the New Radio (NR) standard, the latest version of which at the time of writing is 3GPP R16 released in June 2019, and may include communication protocols currently and commonly referred to as "5G," the Long Term Evolution (LTE) protocol, LTE / LTE-A, Wi-Fi 802.11 standards, etc. Alternatively or additionally, the architecture further discussed herein can be implemented to facilitate communication including other communication standards, such as Open Radio Access Network (O-RAN), or communication utilizing the Wired Data Service Interface Specification (DOCSIS), the latest version of which at the time of writing is DOCSIS 4.0 released in October 2017.

[0025] For the sake of brevity, the various components of a device that can implement architecture 200 are not shown. To provide some non-limiting and illustrative scenarios, the device may include components configured to provide... Figure 2 The demodulated data shown refers to one or more components. These components may include analog-to-digital converters, amplifiers, filters, demodulators, etc. In any case, Figure 2The demodulated data shown may correspond to the demodulated data of a code block that the transmitting device has already used LDPC encoding on, which is subsequently received by a device implementing architecture 200.

[0026] The upper branch of architecture 200 includes demapper 202, LLR item block 204, LLR scaling block 206, and LDPC decoder block 208, which can be identified by the configuration and / or operation of a typical LDPC decoder process. This LDPC decoder process is configured to operate in real-time on demodulated data received for a specific code block. The LDPC decoder process operates by continuously receiving code blocks that form codewords, each code block being encoded as a portion of the received demodulated data. LDPC decoder block 208 attempts to decode the codeword by successfully decoding each code block, and these code blocks can then be concatenated to reconstruct the codeword used by the transmitter. For each code block, this may or may not succeed in several iterations, with success determined by an error checking process (i.e., CRC or other pass / fail schemes discussed herein).

[0027] Therefore, to perform the LDPC decoding process, architecture 200 implements demapper 202, which functions to generate LLR entries from demodulated data identified by specific code blocks. Demapper 202 can utilize any suitable configuration and / or functionality (including known algorithms, hardware components, and / or techniques) to implement this function. The LLR entries are then provided to LLR block 204, which can represent any suitable type of memory configured to store the LLR entries before use, as discussed in further detail below.

[0028] Then, according to known techniques, the LLR items are scaled by applying a common scalar term to the LLR item. This process can be performed on each received code block, causing the decoding process to be performed at the code block decoding level. LLR item scaling is performed in this manner via LLR scaling block 206 using any suitable technique (including known techniques).

[0029] Therefore, the LDPC decoder 208 can include any suitable type of decoder configured to decode the received code block using the received scaling LLR term, such as Figure 2As shown, the received scaled LLR term is received as input data. The LDPC decoder 208 can be implemented according to any suitable components and / or architecture, including components and architectures implemented for known LDPC decoder designs. In one non-limiting and illustrative scenario, the LDPC decoder 208 can be configured as a hardware accelerator and thus can be implemented as one or more hardware components configured to perform a predetermined operation on the received scaled LLR term. As another non-limiting and illustrative scenario, the LDPC decoder 208 can be implemented as a software component by executing LDPC decoder instructions, programs, etc., stored in the memory 506 of the device implementing architecture 200. In any case, the LDPC decoder 208 can be implemented as any suitable component, which can form part of architecture 200 or as a separate component thereof, configured to perform block-level decoding using the LLR scaled term. Therefore, the LDPC decoder 208 and / or architecture 200 can include application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), logic components, processing circuitry, etc., or form part of them.

[0030] Therefore, it should be noted that although LLR scaling block 206 is in Figure 2 While shown as a separate component, this is for ease of explanation; LLR term scaling can be performed independently or as part of the operation of the LDPC decoder 208. In various illustrative and non-limiting scenarios, this can include hardware-based LLR term scaling of the LDPC decoder 208 based on an adjustable scalar gain or via software by scaling the input data stream. Regardless of the component performing the LLR term scaling, scaling is typically performed by selecting the LLR scaling factor to be applied to the LLR term to generate the scaled LLR term. The LDPC decoder 208 then operates on these scaled terms to perform LDPC decoding as part of an iterative decoding process to attempt to successfully decode code blocks (such as...). Figure 2 The decoded output is shown. Successful decoding can be confirmed by any appropriate error checking process, such as cyclic redundancy check (CRC), syndrome pass / fail error check, etc.

[0031] Different LDPC decoder variants employ different techniques to select the LLR scaling factor in an attempt to minimize the number of iterations. However, traditional LDPC decoding schemes still have drawbacks. For example, optimal LLR scaling often depends on current channel conditions, and these traditional LDPC decoders cannot adapt to channel conditions over time. Furthermore, traditional LDPC decoders cannot adapt the LLR scaling factor selection process to changes in channel conditions.

[0032] Architecture 200 addresses this issue by adaptively adjusting LLR scaling over time using the existing processing resources of the device implementing Architecture 200. LLR scaling can be adaptively adjusted in this way based on specific channel heuristics identified by the channels used to transmit code blocks. For this purpose, Architecture 200 implements an LDPC decoder control input model 250. The functionality of the LDPC decoder control input model 250 is described herein primarily in relation to the prediction of scaling factors used to provide scaled LLR terms to the LDPC decoder 208 during inference to perform real-time processing of received control blocks, as described above. However, this paper provides a non-limiting and illustrative scenario using the LDPC decoder control input model 250 to predict LLR scaling factors, in which case the LDPC decoder control input model 250 can represent an adaptive scaling model. However, the LDPC decoder control input model 250 can additionally or alternatively predict any suitable type of control input for the LDPC decoder 208, such as LLR scaling, LLR saturation, decoder offset variants, etc. This will be discussed in more detail in Section III.

[0033] The LDPC decoder control input model 250 can be implemented as any suitable type of machine learning model that is adaptively adjusted over time to improve the selection of one or more control inputs (such as an LLR scaling factor) subsequently provided to the LDPC decoder 208 during inference. Similarly, as a non-limiting and illustrative scenario, the LDPC decoder input predicted in this way by the LDPC decoder control input model 250 includes an LLC scaling factor. Therefore, in various non-limiting and illustrative scenarios, the LDPC decoder control input model 250 can be implemented as a machine learning (ML) model that is implemented as any suitable type of processor executing machine-readable instructions stored in appropriate memory. This can include processing circuitry 502 executing instructions associated with the LDPC decoder control input model 250, which is represented by a corresponding module 508 stored in memory 506, such as... Figure 2 and Figure 5 As shown. Processing circuitry 502 and memory 506 can be identified as components of a device implementing architecture 200. Processing circuitry 502 can perform any of the functions discussed herein with respect to architecture 200, either alone or in combination with software and / or hardware components, as referenced herein. Figure 5 Further detailed discussion is needed.

[0034] Therefore, the LDPC decoder control input model 250 can be implemented as a supervised learning ML model, an unsupervised learning ML module, a semi-supervised learning ML mode, a self-supervised ML mode, a reinforcement learning ML mode, etc. The processing circuitry 502 for executing the ML model can also perform various functions related to the overall training and inference capabilities of the LDPC decoder control input model 250. These functions may include generating training data, predicting the LDPC decoder control input during inference, evaluating various performance metrics of the training process, and adjusting the LDPC decoder control input model 250 over time to adapt and provide better predictions, etc.

[0035] In any case, a set of training data can be used to train the LDPC decoder control input model 250, which is derived from a channel heuristic measured via channel heuristic block 210. Channel heuristic block 210 can be configured to estimate and / or measure any suitable number and / or type of channel parameters using any suitable technique (including known techniques), which can subsequently be associated with the channel conditions at the time of receiving each code block. Channel heuristic block 210 can form part of the hardware and / or software of a device implementing architecture 200, such as various receiver components capable of acquiring such information when data is received and / or by periodically performing wireless channel measurements. Such channel measurements can be performed as part of a channel estimation process typically performed by a wireless receiver. To provide various non-limiting and illustrative scenarios, channel heuristic block 210 can measure and / or estimate channel parameters such as multipath power delay profile, delay spread, Doppler spread, interference level, transmitter location, numberology, rank, modulation and coding scheme (MCS) index, etc.

[0036] The input to the LDPC decoder controls the training data of input model 250 (in Figure 2The training block (represented as training block 250.1) is generated by labeling the LLR terms output by the demapper 202 for each code block. Furthermore, the LLR terms provided by the demapper 202 for each code block can be stored in any suitable memory location, such as memory 506. Therefore, previously generated LLR terms can be accessed and then labeled to generate training data for training the LDPC decoder control input model 250. By referencing channel labels, this training enables the LDPC decoder control input model 250 to predict the LDPC control inputs for future code blocks during inference, where these channel labels indicate one or more channel parameters of the channel when the future code block is received. For this purpose, in various non-limiting and illustrative scenarios, LLR terms can be labeled with any combination and / or subset of channel parameters measured and / or estimated by the channel heuristic block 210. In other words, the training data for the LDPC decoder control input model 250 is generated by labeling previous LLR terms based on the corresponding channel parameters corresponding to when these previous LLR terms were received.

[0037] Therefore, as additional code blocks are received and additional LLR terms are stored, the training data can be continuously updated over time to provide a robust and extensive dataset for optimizing the predictions of the LDPC decoder control input model 250. It is noteworthy that the LDPC decoder control input model 250 can be initially trained using a default or pre-defined labeled training dataset (e.g., at initial power-on, during manufacturing, etc.) to enable the LDPC decoder control input model 250 to initially perform LDPC control input predictions. This default labeled training data can be generated using standard channel modeling techniques, knowledge of the operation of the device to be deployed with architecture 200, known information about the correlation between channel conditions and specific types of LDPC decoder control inputs, etc. This default training data can then be overwritten as architecture 200 continues to operate and collects additional posterior information, where the training process described herein is used to update the default training data. Alternatively, the LDPC decoder control input model 250 can be configured to output default LDPC decoder control inputs for a predetermined period of initial operation until a predetermined number of code blocks, etc., have been processed. For the LLR scaling factor, this can include the initial output default prediction "1", which corresponds to no scaling. Then, once the LDPC decoder is considered to be sufficiently trained, it can switch to an operating mode that performs predictions at inference time, as discussed in further detail in this paper.

[0038] It is worth noting that, due to the highly processor-intensive computation and speed required for receiving and decoding code blocks, architecture 200 may include multiple LDPC decoders 208, each associated with a separate component (e.g., a hardware accelerator). In other words, the LDPC decoder 208 may be part of a set of LDPC decoders, each decoding a corresponding code block according to a corresponding set of scaling LLR terms. Each LDPC decoder within this set can operate in parallel in such a way that multiple code blocks are decoded simultaneously as data is received.

[0039] As a result, when used as part of a Time Division Duplex (TDD) communication protocol, there may be time periods during which some or all of the LDPC decoders 208 in a set are inactive. These time periods may correspond to time slots where the wireless device is not expected to decode code blocks. Therefore, now referring to Figure 3 This illustrates a timeline associated with the decoding operations performed by the LDPC decoder according to this disclosure. Figure 3 As shown, TDD scheduling includes an uplink slot "U" during which code blocks are received, and a downlink slot "D" during which data can be sent but not received. TDD scheduling also includes a special slot "S" during which data can be sent or received, but not during which code blocks used for decoding are received. Therefore, since the LDPC decoder is only used during the time period associated with the uplink slot, in some architectures (where uplink communication occurs less frequently than others), the LDPC decoder is free and idle most of the time.

[0040] Considering the significant idle time of LDPC decoders, it is advantageous to perform operations when one or more of the LDPC decoders in a group are inactive or idle. Figure 2 The components shown in the dashed boxes represent the time periods during which the LDPC decoder controls the training process of the input model 250. It should be noted that the communication scheduling for uplink communication can also be known in advance by the device implementing architecture 200, for example, through synchronous communication that occurs as part of typical wireless communication. Furthermore, the time periods required for the demapper 202 to generate LLR terms and the maximum time required for the LDPC decoder 208 to decode the corresponding code blocks can be known in advance based on the configuration of architecture 200. As a result, the time periods during which the LDPC decoder does not expect to receive code blocks can be predicted in advance, and therefore the time periods during which the LDPC decoder controls the training process of the input model 250 can be freely used, with the training process occurring as a background process during these time periods.

[0041] This is Figure 4 The text further details this process. Figure 4A timeline is shown relating the decoding operations performed by the LDPC decoder 208 and the training process of the LDPC decoder control input model 250 according to this disclosure. The use of the trained LDPC decoder control input model 250 is discussed in more detail below, but... Figure 4 The timeline shown illustrates how the LDPC decoder can be used at inference time to control the input model 250 to provide a scaling factor for the predictions of the LPDC decoder 208, enabling real-time decoding of code blocks, as... Figure 2 As shown.

[0042] Therefore, as Figure 2 As shown, the operations of the upper branch of architecture 200 include: real-time demapping of demodulated data to generate LLR items, scaling of LLR items, and decoding of code blocks. Figure 4 As shown, these processes are all performed during uplink time slot U, i.e., in real time during each uplink time slot. The LLR scaling factor used during each uplink time slot is predicted by the trained LDPC decoder control input model 250, which is subsequently further trained during idle time slots to improve future predictions over time. Therefore, the training process of the LDPC decoder control input model 250 can be performed as a background training process, using free or otherwise idle LDPC decoder resources.

[0043] Figure 4 The training process timeframes are shown in more detail. Figure 4 A non-restrictive and illustrative scenario is discussed for LDPC control inputs that include LLR term scaling factors. In this scenario, the training process is performed iteratively over the illustrated time period to perform the same decoding using labeled training data across a range of scaling values. This allows for the retrospective collection of information about previously used scaling factors for a given UE / channel characteristic. It should be noted that this background processing can be exposed on a lower-priority queue of Architecture 200 so as not to affect real-time processing within the same LDPC decoder group.

[0044] Furthermore, it should be noted that the training process includes the generation of training data as described above. That is, the generation of training data includes labeling those LLR terms of the code block with channel parameters corresponding to the channel conditions when the previous code block was received. The training data is then used as part of a training process that generates multiple scaling factor candidates for a given set of labeled LLR terms. Each of these multiple scaling factor candidates is applied to the same set of labeled LLR terms to provide multiple scaled LLR candidates. The training process also includes providing each of the multiple scaled LLR candidates to the LDPC decoder 258 to decode the corresponding code block, with the output metric used as feedback on the decoding results of the LDPC decoder 258. Therefore, it is noteworthy that although LDPC decoders 208 and 258 are described using different reference numerals herein, these LDPC decoders may include the same LDPC decoders as the LDPC decoder group or different LDPC decoders, depending on which LDPC decoders are idle during the execution of the training process.

[0045] In any case, LDPC decoders 208 and 258 can operate in the same manner, such that the training process mirrors the real-time processing of LDPC decoder 208 using alternative scaling factors. To this end, the training process involves comparing the output metrics produced by LDPC decoding (by LDPC decoder 258) of the same set of labeled LLR terms using different scaling factors, each decoding process being performed sequentially by LDPC decoder 258. Through this comparison, the training process aims to optimize the scaling factor for a specific set of LLR terms and channel parameters by preserving the scaling factors of previously used LLR terms (which produce the best output metrics). By continuously executing this training process in the background over time, the LDPC decoder control input model 250 is improved to predict, at inference time, an optimized (or at least improved) scaling factor for each received code block based on the channel parameters and LLR terms.

[0046] This allows the LDPC decoder to control the input model 250 to benefit from machine learning scaling, continuously collecting data on LLR terms processed based on different scaling values. Thus, the training process involves scaling LLR terms in the background based on the same data without incurring any significant cost in terms of software processing, capacity, or impact on real-time processing requirements. This enables the collection of information (based on channel parameter labels) on the optimal LLR scaling choice for a given channel condition and continuous improvement of the scheme in the background.

[0047] Thus, the LDPC decoder control input model 250 is trained to predict the LDPC decoder control input using training data, which is also generated based on the labeled previous log-likelihood ratio (LLR) terms used by the LDPC decoder 208. Additionally, the LDPC decoder control input model 250 is trained to predict the LDPC decoder control input using performance measurements (i.e., output metrics) of the previous LLR terms, which were scaled and provided as input to the LDPC decoder 208 during previous code block transmissions.

[0048] Once trained in this manner, the trained LDPC decoder control input model 250 is subsequently used during inference to compute the control input for the LDPC decoder 208 for the LLR terms associated with the currently received code block (i.e., the code block received in real time, following the code block used to perform the training process described herein). The trained LDPC decoder control input model 250 can perform this prediction at inference using channel condition labels that have been generated and associated with channel heuristics, which can also be identified by various channel parameters measured and / or estimated by the channel heuristic block 210 relative to the current channel conditions.

[0049] The trained LDPC decoder control input model 250 can use labels associated with the current channel conditions to predict the control input for the LDPC decoder 208 against the LLR term. This can include using any suitable correlation and / or matching process that predicts the control input for the LDPC decoder 208 against the current channel conditions based on previous control inputs identified by similar past channel conditions. This process can be performed using any suitable techniques, including those known to be implemented as part of the operation of a trained ML model for performing predictions using a labeled training dataset at inference time.

[0050] The channel conditions of the currently received code block may differ from those at the time of the previous LLR term reception, as described above, these previous LLR terms were used to train the LDPC decoder control input model 250. Therefore, the trained LDPC decoder control input model 250 is configured to predict the LDPC decoder control input during inference based on the measured and / or estimated channel parameters corresponding to when the current code block was received. The LDPC decoder 208 then uses the predicted LDPC decoder control input to decode the (current, i.e., real-time received) code block.

[0051] Therefore, as Figure 2As shown, the predicted LDPC decoder control input includes an LLR term scaling factor, although this is a non-restrictive and illustrative scenario. Using the scaling factor as an illustrative scenario, the trained LDPC decoder control input model 250 includes an LLR scaling model. Once trained as described above, the LLR scaling model is configured to predict the predicted LLR scaling factor (in this case, as the predicted LDPC decoder control input) for code blocks received after previously received LLR terms (which are then used in the training process described above) during inference. Figure 2 As shown in LLR scaling block 206, the predicted scaling factor is used to scale the LLR terms. LDPC decoder 208 is configured to decode the currently received code block using a set of scaled LLR terms as input data (in real time), which, as described herein, are generated using the predicted LLR scaling factor provided by LDPC decoder control input model 250.

[0052] Furthermore, the training process for the trained LDPC decoder control input model 250 includes testing several LDPC decoder control inputs. Then, based on performance measurements of the LDPC decoder 258 for each control input tested in this manner, the optimal LDPC decoder control input is determined for a specific set of labels and LLR terms. Therefore, using LLR scaling factors as LDPC control inputs as an illustrative and non-limiting scenario, as part of the training process, several scaling factors are selected and applied to a single set of LLR terms, and performance measurements are observed. Each set of LLR terms previously received according to the corresponding code block and channel conditions is then tested.

[0053] The number of LLR scaling factors, their specific values, and / or the granularity of the LLR scaling factors can be selected in this way for training in any suitable manner. This can include scaling factor selection using a set of predetermined rules, based on known, default, or predetermined scaling factors for various channel conditions, scaling factor selection based on a predetermined variance previously used (i.e., the one used by the LDPC decoder 208 for the same LLR term), predetermined variance of the predetermined scaling factors, etc. To provide some non-limiting and illustrative scenarios, the values ​​of the scaling factors can be in the range of around 1.0, such as between 0.7 and 2.0. Therefore, for each previously received LLR term, the training process involves iteratively applying different scaling factors to decode the same code block to generate a corresponding set of scaled LLR terms. Then, for each iteration (i.e., each different scaling factor), performance measurements of the LDPC decoder 258 when decoding the same code block using each set of scaled LLR terms are determined.

[0054] In other words, the choice of scaling factor affects the performance of the LDPC decoder 258 in decoding the corresponding code block. Therefore, this process can produce an optimal scaling factor, thereby maximizing the decoding performance of the LDPC decoder 258. Performance measurements of the scaling factor used to drive the training process to optimize for specific channel conditions can include any suitable performance metrics that indicate the probability of successfully decoding the control block and / or reducing (e.g., minimizing) the block error rate (BLER). Thus, the training process causes the trained LDPC decoder control input model 250 to predict the LDPC decoder control input in real-time for the current channel conditions when each code block is received. This LDPC decoder control input causes the LDPC decoder 208 to maximize (or at least increase) the probability of successfully decoding the corresponding code block. Additionally, for the current scenario, this LDPC control input can include an LLR term scaling factor. According to this scenario, the trained LDPC decoder control input model 250 predicts, in real-time for the current channel conditions when each code block is received, an LLR term scaling factor that causes the LDPC decoder 208 to maximize (or at least increase) the probability of successfully decoding the corresponding code block.

[0055] Therefore, it is worth noting that the LDPC decoding process itself is typically performed in multiple iterations using the same scaling factor for the LLR terms. Thus, the number of iterations required to successfully decode a code block for a specific LLR scaling factor and a set of LLR terms indicates the probability of successfully decoding the control block. Therefore, the number of iterations required for the LDPC decoder 258 to successfully decode a code block for each different scaling factor can be used as a performance metric indicating the optimization of the scaling factor under specific channel conditions. That is, the performance measurement of the LDPC decoder 258 can include the number of LDPC decoder iterations required to successfully pass the error checking process for a corresponding code block using the appropriate set of scaling LLR terms. The error checking process can include any suitable type of process to verify that the coded block has been successfully decoded by the LDPC decoder 258. For the purpose of providing some illustrative and non-limiting scenarios, this might include Cyclic Redundancy Check (CRC) or checksum pass / fail error checking.

[0056] Advantageously, the LDPC decoder control input model 250 can benefit from continuous learning of optimal scaling to adapt to the best scheme for a given deployment location and channel conditions. In parallel with the training process, the LDPC decoder control input model 250 also provides an optimal scaling factor for predictions used in real-time processing based on previous learning. For example, returning to... Figure 4It is worth noting that, as part of the background learning process, the LLR items that have already been processed in a specific U-slot are subsequently processed iteratively with different scaling factors. The processing then performed during the next U-slot is for new LLR data and new labels, but still benefits from the previous learning as described above.

[0057] III. Variations of LLR saturation

[0058] Additionally, the LDPC decoder control input model 250 can be trained to predict any suitable control input to the LDPC decoder 208 at inference time. The LLR scaling factor is described above as an illustrative and non-restrictive scenario for the predicted LDPC decoder control input. However, as another non-restrictive and illustrative scenario, using the same architecture 200 as described herein, the LDPC decoder control input model 250 can be trained to predict LLR saturation alternatively or additionally at inference time. Therefore, architecture 200 enables the LDPC decoder control input model 250 to provide optimal LLR scaling as well as optimal LLR saturation. Generally speaking, to provide a non-restrictive and illustrative scenario, as part of the LDPC decoder processing, LLR saturation is adjusted by truncating a specific number of bits from the MSB of the LLR saturation. Other non-restrictive and illustrative scenarios may include using other forms of LLR saturation or adjusting LLR saturation at a lower granularity of x = max(-s, min(xms)).

[0059] For example, under certain channel conditions, it is known that the receiver might provide a large LLR amplitude under erroneous hard decisions, which could have a significant adverse effect on the LDPC decoder. In such cases, reducing the range of the LLR term may be advantageous regardless of the actual value provided by the receiver. Therefore, the same LDPC decoder control input model 250 can be implemented to predict (using the channel conditions described herein based on the labeled LLR term) which conditions, in addition to LLR scaling, might lead to LLR saturation being tuned to achieve the optimal LLR representation for the channel and receiver chain, thus avoiding this drawback. Traditionally, LLR saturation has been coarsely controlled, but no suitable tuning scheme exists to optimize this control input.

[0060] IV. Wireless devices implementing adaptive learning architecture

[0061] Figure 5 An apparatus according to this disclosure is shown. Apparatus 500 can be implemented as a standalone device or component for any suitable type of wireless communication application. Therefore, apparatus 500 can alternatively be referred to as a communication device or a wireless device. For the purpose of providing various non-limiting and illustrative scenarios, apparatus 500 can be implemented as described above regarding… Figure 2The base station or UE may be part of or include a base station or UE, or any other suitable device implemented to wirelessly receive data (such as transmitted code blocks) from other devices. Device 500 may include one or more components configured to transmit and / or receive wireless signals. Device 500 may perform any of the functions discussed herein regarding the generation of training data, training the LDPC decoder control input model 250, and performing prediction of LDPC control inputs during inference via the LDPC decoder control input model 250.

[0062] For this purpose, device 500 may include processing circuitry 502, transceiver 504, one or more LDPC decoders 505, memory 506, a transmit antenna array 510 including any suitable number of transmit antennas of Ntx, and a receive antenna array 511 including any suitable number of receive antennas of Nrx. Figure 5 The components shown are for ease of explanation, and device 500 can implement them. Figure 5 The additional, fewer, or alternative components shown. Therefore, in various non-limiting and illustrative scenarios, the computing device 500 may include one or more power supplies, display interfaces, peripherals, ports, etc. Furthermore, although... Figure 5 The transmitting antenna array 510 and receiving antenna array 511 shown are separate arrays, but they can be combined into a single antenna array that can be controlled by device 500 to receive and / or transmit signals at different times.

[0063] Processing circuitry 502 can be configured as any suitable number and / or type of computer processors, processing circuitry, hardware circuitry, etc., which can be used to control computing device 500 and / or other components of computing device 500. Processing circuitry 502 can be identified by one or more processors (or suitable portions thereof) implemented in device 500. Processing circuitry 502 can be identified by one or more processors, such as a central processing unit (CPU), host processor, digital signal processor, one or more microprocessors, graphics processor, baseband processor, microcontroller, application-specific integrated circuit (ASIC), part (or all) of a field-programmable gate array (FPGA), etc.

[0064] In any case, processing circuitry 502 can be configured to execute instructions to perform arithmetic, logical, and / or input / output (I / O) operations, and / or control the operation of one or more components of device 500 to perform the various functions described herein. Processing circuitry 502 may include one or more microprocessor cores, memory registers, buffers, clocks, etc., and may generate electronic control signals associated with the components of device 500 to control and / or modify the operation of those components. Processing circuitry 502 may communicate with and / or control the functions associated with transceiver 504, LDPC decoder 505, memory 506, transmit antenna 510, and / or receive antenna 511.

[0065] Transceiver 504 can be implemented as any suitable number and / or type of components configured to transmit and / or receive data (such as code blocks) and / or wireless signals according to any suitable number and / or type of communication protocol. Transceiver 504 may include any suitable type of components to facilitate this functionality, including components associated with the operation, configuration, and implementation of known transceivers, transmitters, and / or receivers. Although in Figure 5 While depicted as a single transceiver, transceiver 504 can represent any suitable number of transceivers, transmitters, receivers, or combinations thereof that can be integrated into a single transceiver or as multiple transceivers or transceiver modules. Transceiver 504 may include components typically identified as RF front-ends and includes antennas, ports, power amplifiers (PAs), RF filters, mixers, local oscillators (LOs), low-noise amplifiers (LNAs), up-converters, down-converters, channel tuners, etc.

[0066] Therefore, transceiver 504 can be configured as any suitable number and / or type of components configured to facilitate the reception and / or transmission of data and / or signals according to one or more communication protocols. Transceiver 504 can be implemented as any suitable number and / or type of components to support wireless communication, such as analog-to-digital converters (ADCs), digital-to-analog converters, intermediate frequency (IF) amplifiers and / or filters, modulators, demodulators, baseband processors, etc. Data received through transceiver 504, data provided to transceiver 504 for transmission, and / or data used in conjunction with data transmitted and / or received through transceiver 504 (such as beamforming weights) can be processed by processing circuitry 502 and LDPC decoder 505, as described herein.

[0067] LDPC decoder 505 can be identified by any suitable number and / or type of LDPC decoders that attempt to control input decoding code blocks according to received LDPC decoders, as described herein. LDPC decoder 505 can also be identified by a set of LDPC decoders implemented by device 500, including LDPC decoders 208, 258, as described herein.

[0068] Memory 506 is configured to store data and / or instructions such that, when executed by processing circuitry 502, the instructions cause device 500 to perform any of the various functions described herein. Memory 506 can be implemented as any suitable volatile and / or non-volatile memory, including read-only memory (ROM), random access memory (RAM), flash memory, magnetic storage media, optical disk, erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), etc. Memory 506 can be non-removable, removable, or a combination of both. Memory 506 can be implemented as a non-transitory computer-readable medium storing one or more executable instructions (e.g., logic, algorithms, code, etc.).

[0069] As discussed further below, the instructions, logic, code, etc., stored in memory 506 are represented by various modules illustrated, which enable the functional implementation of the functions disclosed herein. Alternatively, Figure 5 The module associated with memory 506 shown may include instructions and / or code to facilitate control and / or monitoring of the operation of hardware components implemented through computing device 500. In other words, it provides... Figure 5 The modules shown are for ease of explanation regarding the functional relationships between hardware and software components. Therefore, processing circuitry 502 can be combined with one or more hardware components to execute instructions stored in these respective modules to perform any of the various functions described herein. Although shown as separate modules, this is for ease of explanation, and it should be understood that memory 506 can store computer-readable instructions in any suitable format as an executable data instruction set, so that any of the functions described herein can be performed by executing the instructions stored in memory 506.

[0070] The executable instructions stored in the training data generation module 507 can be combined with execution via the processing circuitry 502 to facilitate the generation of any training data described herein by the device 500. This training data can then be used to perform training of the LDPC decoder control input model 250 as discussed herein. This can include generating labeled training data, such as labeling LLR terms with labels corresponding to various channel parameters, as discussed above regarding architecture 200. Therefore, the training data generation module 507 can be combined with the execution of instructions via the processing circuitry 502 to facilitate the device 500 in implementing all or part of the functionality of architecture 200.

[0071] The LDPC decoder control input model 508 can be represented as described above. Figure 2 The LDPC decoder control input model 250 shown and discussed is identified by the executable instructions for its functional implementation and operation. Therefore, the LDPC decoder control input model 508 can be combined with instructions executed via processing circuitry 502 to facilitate the implementation of all or part of the architecture of any suitable type of machine learning model by device 500.

[0072] V. Process Flow

[0073] Figure 6 The process flow according to this disclosure is shown. (Refer to...) Figure 6 Process 600 can be a computer-implemented method executed by and / or otherwise associated with one or more processors (processing circuitry), other hardware components, and / or storage devices. These processors, other hardware components, and / or storage devices can be associated with one or more computing components identified by any suitable device (such as device 500, a device implementing architecture 200, etc.). One or more processors can execute instructions stored on any suitable computer-readable storage medium, which may or may not be shown in the figure. For brevity, process 600 may include... Figure 6 Alternative or additional steps not shown in the text, and may be used in conjunction with Figure 6 The steps shown are executed in a different order.

[0074] Process 600 may begin by determining whether training can be started as a background process (block 602). In a non-limiting and illustrative scenario, this may include determining whether one or more LDPC decoders are inactive. As described herein, this may include determining a time period based on TDD scheduling during which data can be sent but not received, or determining when a block of code for decoding is not expected to be received. Alternatively or concurrently, this determination (block 602) may be based on any other suitable factor, such as a priority queue that establishes higher priority for processing to be performed in real time and lower priority for background or other non-real-time processing tasks. Thus, this determination (block 602) may be performed such that the training process does not interfere with or otherwise affect higher-priority processing (which may include real-time LDPC decoding or any other suitable processing deemed to have higher priority). If not, process 600 may proceed to waiting (block 603) until a period in which one or more LDPC decoders are inactive and / or the training process can be performed in another manner.

[0075] Once it is determined (block 602, yes) that the background training process can begin, process 600 can proceed to generating (block 604) training data. This may include generating training data by labeling LLR entries from previous code block processing with one or more channel parameter labels identified by the channel conditions at the time the LLR entries are received. This may include accessing LLR entries from a stored memory location for this purpose, as discussed above regarding architecture 200. This may include adding and / or overwriting previous training data when additional code blocks are received and decoded.

[0076] Process 600 may include performing (block 606) LDPC decoder control input model training. This training process may be the process described above with respect to architecture 200. For example, the training process may include: training the LDPC decoder control input model 250 using training data to iteratively test multiple control input values, and measuring the LDPC decoder's performance metrics for each iteration. This training process aims to optimize the LDPC decoder control input model predictions for a specific set of channel conditions and LLR terms.

[0077] Process 600 may include receiving a subsequent code block (block 608) after receiving the code block used to generate (block 604) training data. This may include receiving uplink transmissions during uplink time slots, as discussed above regarding architecture 200.

[0078] Process 600 may include predicting (block 610) LDPC decoder control inputs during inference. This may include generating predicted LDPC decoder control inputs, such as scaling factors, which are subsequently used by the LDPC decoder in real time to perform LDPC decoding on subsequently received code blocks.

[0079] Process 600 may include LDPC decoding of subsequently received code blocks using the LDPC decoder control input predicted by (block 612) of (block 610). This may include LDPC decoder 208 performing LDPC decoding on the code blocks using LLR terms and the predicted LDPC decoder control input of (block 610). Additionally, this LDPC decoder control input may include an LLR scaling factor, such that LDPC decoder 208 performs LDPC decoding using an LLR term (which has been scaled according to the predicted scaling factor output by the trained LDPC decoder control input model 250), as discussed above regarding architecture 200.

[0080] VI. General Operation of the First Wireless Device

[0081] A first wireless device is provided. The first wireless device includes a low-density parity-check (LDPC) decoder; and a processor configured to execute instructions stored in memory to: train an LDPC decoder control input model to predict LDPC decoder control inputs using (i) training data based on previous log-likelihood ratio (LLR) terms used by the LDPC decoder and (ii) performance measurements of the LDPC decoder using previous LLR terms; and, using the trained LDPC decoder control input model, compute the predicted LDPC decoder control inputs based on estimated channel parameters corresponding to the time the code block was received, during inference for a code block received after the previous LLR terms. The LDPC decoder is configured to decode the code block using the predicted LDPC decoder control inputs, and the processor is configured to train the LDPC decoder control input model during inactive decoding periods of the LDPC decoder. In addition to, or as alternatives to, and in any combination thereof, the optional features previously described in this paragraph, the trained LDPC decoder control input model includes an LLR scaling model configured to predict a predicted LLR scaling factor as the control input to the predicted LDPC decoder when inference for a code block received after a previous LLR term, and the LDPC decoder is configured to decode the code block using a set of scaled LLR terms generated using the predicted LLR scaling factor. In addition to, or as alternatives to, and in any combination thereof, the processor is configured to generate training data by labeling previous LLR terms. In addition to, or as alternatives to, and in any combination thereof, the previous LLR terms are labeled based on the corresponding channel parameters corresponding to when the previous LLR term was received. In addition to, or as alternatives to, and in any combination thereof, the channel parameters include one or more of the following: multipath power delay distribution, delay spread, Doppler spread, interference level, location of transmitting equipment, parameter set, rank, or modulation and coding scheme (MCS) index. In addition to, or as alternatives to, and in any combination thereof, the processor is configured to train the LDPC decoder control input model by: for each previous LLR term, iteratively applying different scaling factors to decode the corresponding code block, thereby generating a corresponding set of scaled LLR terms; and for each iteration, determining the performance measurement results of the LDPC decoder when decoding the corresponding code block using each corresponding set of scaled LLR terms. In addition to, or as alternatives to, and in any combination thereof, the performance measurement results of the LDPC decoder include the number of LDPC decoder iterations required to successfully pass the error checking process for the corresponding code block using the corresponding set of scaled LLR terms.In addition to, or as alternatives to, and in any combination thereof, the optional features previously described in this paragraph, the predicted LDPC decoder control input includes a predicted LLR scaling factor for providing a corresponding set of scaled LLR terms, which causes the LDPC decoder to maximize the successful decoding probability of the corresponding code block. In addition to, or as alternatives to, and in any combination thereof, the error checking process includes Cyclic Redundancy Check (CRC) or checksum pass / fail error checking.

[0082] VII. General Operation of Non-Transient Computer-Readable Media

[0083] A non-transient computer-readable medium is provided. The non-transient computer-readable medium has instructions stored thereon that, when executed by a processor of a wireless device, cause the wireless device to: train an LDPC decoder control input model to predict the LDPC decoder control input using (i) training data based on a previous log-likelihood ratio (LLR) term used by the LDPC decoder and (ii) performance measurements of the LDPC decoder using the previous LLR term; and, using the trained LDPC decoder control input model, compute the predicted LDPC decoder control input based on estimated channel parameters corresponding to the time the code block was received, during inference for a code block received after the previous LLR term. The LDPC decoder is configured to decode the code block using the predicted LDPC decoder control input, and the processor is configured to train the LDPC decoder control input model during inactive decoding periods of the LDPC decoder. In addition to, or as alternatives to, and in any combination thereof, the optional features previously described in this paragraph, the trained LDPC decoder control input model includes an LLR scaling model configured to predict a predicted LLR scaling factor as a predictive LDPC decoder control input during inference for a code block received after a previous LLR term, and the LDPC decoder is configured to decode the code block using a set of scaled LLR terms generated using the predicted LLR scaling factor. In addition to, or as alternatives to, and in any combination thereof, the optional features previously described in this paragraph, these instructions, when executed by the processor, cause the wireless device to generate training data by labeling the previous LLR terms. In addition to, or as alternatives to, and in any combination thereof, the optional features previously described in this paragraph, the previous LLR terms are labeled based on the corresponding channel parameters at the time the previous LLR term was received. In addition to, or as alternatives to, and in any combination thereof, the channel parameters include one or more of the following: multipath power delay distribution, delay spread, Doppler spread, interference level, transmitter location, parameter set, rank, or modulation and coding scheme (MCS) index. In addition to, or as alternatives to, and in any combination thereof, the instructions, when executed by the processor, cause the wireless device to train the LDPC decoder control input model by: iteratively applying different scaling factors to decode the corresponding code block for each previous LLR term, thereby generating a corresponding set of scaled LLR terms; and for each iteration, determining the performance measurement results of the LDPC decoder when decoding the corresponding code block using the corresponding set of scaled LLR terms. In addition to, or as alternatives to, and in any combination thereof, the performance measurement results of the LDPC decoder include the number of LDPC decoder iterations required to successfully pass the error checking process for the corresponding code block using the corresponding set of scaled LLR terms.In addition to, or as alternatives to, and in any combination thereof, the optional features previously described in this paragraph, the predicted LDPC decoder control input includes a predicted LLR scaling factor for providing a corresponding set of scaled LLR terms, which causes the LDPC decoder to maximize the successful decoding probability of the corresponding code block. In addition to, or as alternatives to, and in any combination thereof, the error checking process includes Cyclic Redundancy Check (CRC) or checksum pass / fail error checking.

[0084] VIII. General Operation of the Second Wireless Device

[0085] A second wireless device is provided. The second wireless device includes a low-density parity-check (LDPC) decoder; and a processor configured to execute instructions stored in memory to: train a log-likelihood ratio (LLR) scaling model to predict an LLR scaling factor using (i) training data based on previous LLR terms used by the LDPC decoder and (ii) performance measurements of the LDPC decoder using previous LLR terms; and, using the trained LLR scaling model, calculate the predicted LLR scaling factor based on estimated channel parameters corresponding to the time the code block was received, when inferring for a code block received after a previous LLR term. The LDPC decoder is configured to decode the code block using a set of scaled LLR terms generated using the predicted LLR scaling factor. In addition to, or as alternatives to, and in any combination thereof, the processor is configured to train the LLR scaling model by: for each previous LLR term, iteratively applying a scaling factor to decode the corresponding code block, thereby generating a set of scaled LLR terms; and for each iteration, determining the performance measurement of the LDPC decoder when decoding the corresponding code block using the corresponding set of scaled LLR terms.

[0086] Example

[0087] The following examples illustrate various techniques disclosed herein.

[0088] An example (e.g., Example 1) relates to a wireless device including: a low-density parity-check (LDPC) decoder; and a processor configured to execute instructions stored in memory to: train an LDPC decoder control input model to predict LDPC decoder control inputs using (i) training data based on previous log-likelihood ratio (LLR) terms used by the LDPC decoder and (ii) performance measurements of the LDPC decoder using previous LLR terms; and, using the trained LDPC decoder control input model, compute the predicted LDPC decoder control inputs based on estimated channel parameters corresponding to when the code block is received, during inference for a code block received after the previous LLR terms, wherein the LDPC decoder is configured to decode the code block using the predicted LDPC decoder control inputs, and wherein the processor is configured to train the LDPC decoder control input model during inactive decoding periods of the LDPC decoder.

[0089] Another example (e.g., Example 2) relates to the previously described example (e.g., Example 1), wherein the trained LDPC decoder control input model includes an LLR scaling model configured to predict a predicted LLR scaling factor as the predicted LDPC decoder control input when inference for a block of code received after a previous LLR term, and wherein the LDPC decoder is configured to decode the block of code using a set of scaled LLR terms generated using the predicted LLR scaling factor.

[0090] Another example (e.g., Example 3) relates to the previously described examples (e.g., one or more of Examples 1 to 2), where the processor is configured to generate training data by labeling previous LLR terms.

[0091] Another example (e.g., Example 4) relates to the previously described examples (e.g., one or more of Examples 1 to 3), wherein the previous LLR entry is tagged based on the corresponding channel parameters when the previous LLR entry was received.

[0092] Another example (e.g., Example 5) relates to the examples described above (e.g., one or more of Examples 1 to 4), wherein the channel parameters include one or more of the following: multipath power delay distribution, delay spread, Doppler spread, interference level, location of transmitting device, parameter set, rank, or modulation and coding scheme (MCS) index.

[0093] Another example (e.g., Example 6) relates to the examples described above (e.g., one or more of Examples 1 to 5), wherein the processor is configured to train the LDPC decoder control input model by: for each previous LLR term, iteratively applying different scaling factors to decode the corresponding code block, thereby generating a corresponding set of scaled LLR terms; and for each iteration, determining the performance measurement of the LDPC decoder when decoding the corresponding code block using the corresponding set of scaled LLR terms.

[0094] Another example (e.g., Example 7) relates to the examples described above (e.g., one or more of Examples 1 to 6), where the performance measurement of the LDPC decoder includes calculating the number of LDPC decoder iterations required for the corresponding code block to successfully pass the error checking process using a corresponding set of scaled LLR terms.

[0095] Another example (e.g., Example 8) relates to the examples described above (e.g., one or more of Examples 1 to 7), wherein the predicted LDPC decoder control input includes predicted LLR scaling factors for providing a corresponding set of scaled LLR terms, which cause the LDPC decoder to maximize the success rate of decoding the corresponding code block.

[0096] Another example (e.g., Example 9) relates to the examples described above (e.g., one or more of Examples 1 to 8), where the error checking process includes Cyclic Redundancy Check (CRC) or checksum pass / fail error checking.

[0097] One example (e.g., Example 10) is directed to a non-transient computer-readable medium having instructions stored thereon that, when executed by a processor of a wireless device, cause the wireless device to: train an LDPC decoder control input model to predict LDPC decoder control inputs using (i) training data based on a previous log-likelihood ratio (LLR) term used by the LDPC decoder and (ii) performance measurements of the LDPC decoder using the previous LLR term; and, using the trained LDPC decoder control input model, compute the predicted LDPC decoder control inputs based on estimated channel parameters corresponding to when the code block was received, during inference for a code block received after the previous LLR term, wherein the LDPC decoder is configured to decode the code block using the predicted LDPC decoder control inputs, and wherein the processor is configured to train the LDPC decoder control input model during inactive decoding periods of the LDPC decoder.

[0098] Another example (e.g., Example 11) relates to the previously described example (e.g., Example 10), wherein the trained LDPC decoder control input model includes an LLR scaling model configured to predict a predicted LLR scaling factor as a predicted LDPC decoder control input when inference for a block of code received after a previous LLR term, and wherein the LDPC decoder is configured to decode the block of code using a set of scaled LLR terms generated using the predicted LLR scaling factor.

[0099] Another example (e.g., Example 12) relates to the examples described above (e.g., one or more of Examples 10 to 11), where instructions, when executed by the processor, cause the wireless device to generate training data by labeling previous LLR terms.

[0100] Another example (e.g., Example 13) relates to the previously described examples (e.g., one or more of Examples 10 to 12), wherein the previous LLR entry is tagged based on the corresponding channel parameters when the previous LLR entry was received.

[0101] Another example (e.g., Example 14) relates to the examples described above (e.g., one or more of Examples 10 to 13), wherein the channel parameters include one or more of the following: multipath power delay distribution, delay spread, Doppler spread, interference level, location of transmitting device, parameter set, rank, or modulation and coding scheme (MCS) index.

[0102] Another example (e.g., Example 15) relates to the examples described above (e.g., one or more of Examples 10 to 14), wherein the instructions, when executed by the processor, cause the wireless device to train the LDPC decoder control input model by: for each previous LLR term, iteratively applying different scaling factors to decode the corresponding code block, thereby generating a corresponding set of scaled LLR terms; and for each iteration, determining the performance measurement of the LDPC decoder when decoding the corresponding code block using the corresponding set of scaled LLR terms.

[0103] Another example (e.g., Example 16) relates to the examples described above (e.g., one or more of Examples 10 to 15), where the performance measurement of the LDPC decoder includes calculating the number of LDPC decoder iterations required for the corresponding code block to successfully pass the error checking process using a corresponding set of scaled LLR terms.

[0104] Another example (e.g., Example 17) relates to the examples described above (e.g., one or more of Examples 10 to 16), wherein the predicted LDPC decoder control input includes a predicted LLR scaling factor for providing a corresponding set of scaled LLR terms, which causes the LDPC decoder to maximize the success rate of decoding the corresponding code block.

[0105] Another example (e.g., Example 18) relates to the examples described above (e.g., one or more of Examples 10 to 17), where the error checking process includes Cyclic Redundancy Check (CRC) or checksum pass / fail error checking.

[0106] One example (e.g., Example 19) relates to a wireless device including: a low-density parity-check (LDPC) decoder; and a processor configured to execute instructions stored in memory to: train a log-likelihood ratio (LLR) scaling model to predict an LLR scaling factor using (i) training data based on previous LLR terms used by the LDPC decoder and (ii) performance measurements of the LDPC decoder using previous LLR terms; and, using the trained LLR scaling model, compute the predicted LLR scaling factor based on estimated channel parameters corresponding to when the code block was received, during inference for a code block received after a previous LLR term, wherein the LDPC decoder is configured to decode the code block using a set of scaled LLR terms generated using the predicted LLR scaling factor.

[0107] Another example (e.g., Example 20) relates to the example described above (e.g., Example 19), wherein the processor is configured to train an LLR scaling model by: for each previous LLR term, iteratively applying a scaling factor to decode the corresponding code block to generate a set of scaled LLR terms; and for each iteration, determining a performance measurement of the LDPC decoder when decoding the corresponding code block using the corresponding set of scaled LLR terms.

[0108] One example (e.g., Example 21) relates to a wireless device, comprising: a low-density parity-check (LDPC) decoding device; and a processing device for executing instructions stored in a memory to: train an LDPC decoder control input model to predict LDPC decoder control inputs using (i) training data based on previous log-likelihood ratio (LLR) terms used by the LDPC decoding device and (ii) performance measurements of the LDPC decoding device using previous LLR terms; and, using the trained LDPC decoder control input model, compute the predicted LDPC decoder control inputs based on estimated channel parameters corresponding to when the code block is received, during inference for a code block received after the previous LLR terms, wherein the LDPC decoding device decodes the code block using the predicted LDPC decoder control inputs, and wherein the processing device trains the LDPC decoder control input model during inactive decoding periods of the LDPC decoding device.

[0109] Another example (e.g., Example 22) relates to the previously described example (e.g., Example 21), wherein the trained LDPC decoder control input model includes an LLR scaling model configured to predict a predicted LLR scaling factor as the predicted LDPC decoder control input when inferring a block of code received after a previous LLR term, and wherein the LDPC decoding device decodes the block of code using a set of scaled LLR terms generated using the predicted LLR scaling factor.

[0110] Another example (e.g., Example 23) relates to the previously described examples (e.g., one or more of Examples 21 to 22), in which the processing device generates training data by labeling previous LLR terms.

[0111] Another example (e.g., Example 24) relates to the previously described examples (e.g., one or more of Examples 21 to 23), wherein the previous LLR entry is tagged based on the corresponding channel parameters when the previous LLR entry was received.

[0112] Another example (e.g., Example 25) relates to the examples described above (e.g., one or more of Examples 21 to 24), wherein the channel parameters include one or more of the following: multipath power delay distribution, delay spread, Doppler spread, interference level, location of transmitting device, parameter set, rank, or modulation and coding scheme (MCS) index.

[0113] Another example (e.g., Example 26) relates to the previously described examples (e.g., one or more of Examples 21 to 25), wherein the processing device trains the LDPC decoder control input model by: for each previous LLR term, iteratively applying different scaling factors to decode the corresponding code block, thereby generating a corresponding set of scaled LLR terms; and for each iteration, determining the performance measurement results of the LDPC decoding device when decoding the corresponding code block using the corresponding set of scaled LLR terms.

[0114] Another example (e.g., Example 27) relates to the examples described above (e.g., one or more of Examples 21 to 26), where the performance measurement results of the LDPC decoding device include calculating the number of LDPC decoder iterations required for the corresponding code block to successfully pass the error checking process using a corresponding set of scaled LLR terms.

[0115] Another example (e.g., Example 28) relates to the examples described above (e.g., one or more of Examples 21 to 27), wherein the predicted LDPC decoder control input includes a predicted LLR scaling factor for providing a corresponding set of scaled LLR terms, which causes the LDPC decoding apparatus to maximize the success rate of decoding the corresponding code block.

[0116] Another example (e.g., Example 29) relates to the examples described above (e.g., one or more of Examples 21 to 28), where the error checking process includes Cyclic Redundancy Check (CRC) or checksum pass / fail error checking.

[0117] One example (e.g., Example 30) is for a non-transient computer-readable medium having instructions stored thereon that, when executed by a processing device of a wireless device, cause the wireless device to: train an LDPC decoder control input model to predict LDPC decoder control inputs using (i) training data based on previous log-likelihood ratio (LLR) terms used by the LDPC decoding device and (ii) performance measurements of the LDPC decoding device using the previous LLR terms; and, using the trained LDPC decoder control input model, compute the predicted LDPC decoder control inputs based on estimated channel parameters corresponding to when the code block was received, during inference for a code block received after the previous LLR terms, wherein the LDPC decoding device decodes the code block using the predicted LDPC decoder control inputs, and wherein the processing device trains the LDPC decoder control input model during inactive decoding periods of the LDPC decoding device.

[0118] Another example (e.g., Example 31) relates to the previously described example (e.g., Example 30), wherein the trained LDPC decoder control input model includes an LLR scaling model configured to predict a predicted LLR scaling factor as the predicted LDPC decoder control input when inferring a block of code received after a previous LLR term, and wherein the LDPC decoding device decodes the block of code using a set of scaled LLR terms generated using the predicted LLR scaling factor.

[0119] Another example (e.g., example 32) relates to the previously described examples (e.g., one or more of examples 30 to 31), wherein the instructions, when executed by the processing device, cause the wireless device to generate training data by labeling previous LLR terms.

[0120] Another example (e.g., Example 33) relates to the previously described examples (e.g., one or more of Examples 30 to 32), wherein the previous LLR entry is tagged based on the corresponding channel parameters when the previous LLR entry was received.

[0121] Another example (e.g., Example 34) relates to the examples described above (e.g., one or more of Examples 30 to 33), wherein the channel parameters include one or more of the following: multipath power delay distribution, delay spread, Doppler spread, interference level, location of transmitting device, parameter set, rank, or modulation and coding scheme (MCS) index.

[0122] Another example (e.g., Example 35) relates to the examples described above (e.g., one or more of Examples 30 to 34), wherein the instructions, when executed by the processing device, cause the wireless device to train the LDPC decoder control input model by: for each previous LLR term, iteratively applying different scaling factors to decode the corresponding code block, thereby generating a corresponding set of scaled LLR terms; and for each iteration, determining the performance measurement of the LDPC decoding device when decoding the corresponding code block using the corresponding set of scaled LLR terms.

[0123] Another example (e.g., Example 36) relates to the examples described above (e.g., one or more of Examples 30 to 35), where the performance measurement of the LDPC decoding device includes calculating the number of LDPC decoder iterations required for the corresponding code block to successfully pass the error checking process using a corresponding set of scaled LLR terms.

[0124] Another example (e.g., Example 37) relates to the examples described above (e.g., one or more of Examples 30 to 36), wherein the predicted LDPC decoder control input includes a predicted LLR scaling factor for providing a corresponding set of scaled LLR terms, which causes the LDPC decoding apparatus to maximize the success rate of decoding the corresponding code block.

[0125] Another example (e.g., Example 38) relates to the examples described above (e.g., one or more of Examples 30 to 37), where the error checking process includes Cyclic Redundancy Check (CRC) or checksum pass / fail error checking.

[0126] One example (e.g., Example 39) relates to a wireless device including: a low-density parity-check (LDPC) decoding device; and a processing device for executing instructions stored in a memory to: train a log-likelihood ratio (LLR) scaling model to predict an LLR scaling factor using (i) training data based on previous LLR terms used by the LDPC decoding device and (ii) performance measurements of the LDPC decoding device using previous LLR terms; and, using the trained LLR scaling model, calculate the predicted LLR scaling factor based on estimated channel parameters corresponding to when the code block was received, when inference is performed for a code block received after a previous LLR term, wherein the LDPC decoding device decodes the code block using a set of scaled LLR terms, the set of scaled LRR terms being generated using the predicted LLR scaling factor.

[0127] Another example (e.g., Example 40) relates to the example described above (e.g., Example 39), in which the processing device trains the LLR scaling model by: for each previous LLR term, iteratively applying a scaling factor to decode the corresponding code block, thereby generating a set of scaled LLR terms; and for each iteration, determining the performance measurement of the LDPC decoding device when decoding the corresponding code block using the corresponding set of scaled LLR terms.

[0128] The device is shown in the figure and described.

[0129] The figure shows the method described.

[0130] in conclusion

[0131] The foregoing description will fully reveal the general nature of this disclosure, enabling others to readily modify and / or adapt it to various applications by applying knowledge within the scope of the art, without excessive experimentation and without departing from the overall concept of this disclosure. Therefore, based on the teachings and guidance set forth herein, such adaptations and modifications are intended to be within the equivalent meaning and scope of the disclosed embodiments. It should be understood that the wording or terminology used herein is for descriptive and not limiting purposes, and that the terminology or terminology of this specification will be interpreted by those skilled in the art based on the teachings and guidance.

[0132] References to phrases such as "an implementation," "implementation method," and "exemplary implementation method" in the specification indicate that the described implementation method may include specific features, structures, or characteristics, but not every implementation method necessarily includes specific features, structures, or characteristics. Furthermore, these phrases do not necessarily refer to the same implementation method. Moreover, when a specific feature, structure, or characteristic is described in conjunction with an implementation method, it is understood that those skilled in the art would recognize that it is feasible to influence these features, structures, or characteristics by combining other implementation methods (whether explicitly described or not).

[0133] The implementations described herein are provided for illustrative purposes and are not intended to be limiting. Other implementations are possible, and modifications can be made to the described implementations. Therefore, this specification is not intended to limit this disclosure. Rather, the scope of this disclosure is defined only by the following claims and their equivalents.

[0134] The implementations described herein can be implemented in hardware (e.g., circuitry), firmware, software, or any combination thereof. Implementations can also be implemented as instructions stored on a machine-readable medium that can be read and executed by one or more processors. Machine-readable media can include any mechanism for storing or transmitting information in a machine-readable form (e.g., a computing device). For example, machine-readable media can include read-only memory (ROM); random access memory (RAM); disk storage media; optical storage media; flash memory devices; electrical, optical, acoustic, or other forms of propagation signals (e.g., carrier waves, infrared signals, digital signals, etc.). Furthermore, firmware, software, routines, and instructions may be described herein as performing certain actions. However, it should be understood that such descriptions are merely for convenience, and such actions are actually caused by the execution of firmware, software, routines, instructions, etc., by a computing device, processor, controller, or other device. Furthermore, any variation of the implementation can be executed by a general-purpose computer.

[0135] For the purposes of this discussion, the term "processor circuit" or "processor circuit" should be understood as one or more circuits, one or more processors, logic, or combinations thereof. For example, a circuit may include analog circuits, digital circuits, state machine logic, other structured electronic hardware, or combinations thereof. A processor may include a microprocessor, a digital signal processor (DSP), or other hardware processor. A processor may be "hard-coded" with instructions to perform corresponding functions according to the implementation described herein. Alternatively, a processor may access internal and / or external memory to fetch instructions stored in memory that, when executed by the processor, perform one or more corresponding functions associated with the processor and / or one or more functions and / or operations related to the operation of components containing the processor.

[0136] In one or more implementations described herein, the processing circuitry may include memory storing data and / or instructions. The memory may be any known volatile and / or non-volatile memory, including, for example, read-only memory (ROM), random access memory (RAM), flash memory, magnetic storage media, optical disk, erasable programmable read-only memory (EPROM), and programmable read-only memory (PROM). The memory may be non-removable, removable, or a combination of both.

Claims

1. A wireless device, comprising: Low-density parity-check (LDPC) decoder; as well as The processor is configured to execute instructions stored in memory to: The LDPC decoder control input model is trained to predict the LDPC decoder control input using the following: (i) training data based on the previous log-likelihood ratio (LLR) term used by the LDPC decoder, and (ii) performance measurements of the LDPC decoder using the previous LLR term; and The predicted LDPC decoder control input is calculated based on the estimated channel parameters corresponding to when the code block was received, using a trained LDPC decoder control input model during inference for a code block received after the previous LLR term. The LDPC decoder is configured to decode the code block using the predicted LDPC decoder control input, and The processor is configured to train the LDPC decoder control input model during the inactive decoding period of the LDPC decoder.

2. The wireless device according to claim 1, wherein, The processor is configured to generate the training data by labeling the previous LLR terms.

3. The wireless device according to claim 2, wherein, The previous LLR entry is tagged based on the corresponding channel parameters when the previous LLR entry was received.

4. The wireless device according to any one of claims 1 to 3, wherein, The trained LDPC decoder control input model includes an LLR scaling model, which is configured to predict a predicted LLR scaling factor as the predicted LDPC decoder control input when inference is performed on the code block received after the previous LLR term. The LDPC decoder is configured to decode the code block using a set of scaled LLR terms, which are generated using the predicted LLR scaling factor.

5. The wireless device according to any one of claims 1 to 3, wherein, The channel parameters include one or more of the following: multipath power delay distribution, delay spread, Doppler spread, interference level, location of transmitting device, parameter set, rank, or modulation and coding scheme (MCS) index.

6. The wireless device according to any one of claims 1 to 3, wherein, The processor is configured to train the LDPC decoder control input model through the following processes: For each of the previous LLR entries, different scaling factors are iteratively applied to decode the corresponding code block, thereby generating a corresponding set of scaled LLR entries; as well as For each iteration, determine the performance measurement results of the LDPC decoder when decoding the corresponding code block using the corresponding set of scaling LLR terms.

7. The wireless device according to claim 6, wherein, The performance measurement results of the LDPC decoder include the number of LDPC decoder iterations required to successfully pass the error checking process for the corresponding code block using a corresponding set of scaled LLR terms.

8. The wireless device according to claim 7, wherein, The error checking process includes cyclic redundancy check (CRC) or checksum pass / fail error checking.

9. The wireless device according to any one of claims 1 to 3, wherein, The predicted LDPC decoder control input includes a predicted LLR scaling factor, which is used to provide a corresponding set of scaled LLR terms, causing the LDPC decoder to maximize the success rate of decoding the corresponding code block.

10. A non-transient computer-readable medium storing instructions thereon, the instructions, when executed by a processor of a wireless device, causing the wireless device to: The LDPC decoder control input model is trained to predict the LDPC decoder control input using the following: (i) training data based on the previous log-likelihood ratio (LLR) term used by the LDPC decoder, and (ii) performance measurements of the LDPC decoder using the previous LLR term; and The predicted LDPC decoder control input is calculated based on the estimated channel parameters corresponding to when the code block was received, using a trained LDPC decoder control input model during inference for a code block received after the previous LLR term. in, The LDPC decoder is configured to decode the code block using the predicted LDPC decoder control input, and The processor is configured to train the LDPC decoder control input model during the inactive decoding period of the LDPC decoder.

11. The non-transient computer-readable medium according to claim 10, wherein, When executed by the processor, the instructions cause the wireless device to generate the training data by labeling the previous LLR terms.

12. The non-transient computer-readable medium according to claim 11, wherein, The previous LLR entry is tagged based on the corresponding channel parameters when the previous LLR entry was received.

13. The non-transient computer-readable medium according to any one of claims 10 to 12, wherein, The trained LDPC decoder control input model includes an LLR scaling model, which is configured to predict a predicted LLR scaling factor as the predicted LDPC decoder control input when inference is performed on the code block received after the previous LLR term. The LDPC decoder is configured to decode the code block using a set of scaled LLR terms, which are generated using the predicted LLR scaling factor.

14. The non-transient computer-readable medium according to any one of claims 10 to 12, wherein, The channel parameters include one or more of the following: multipath power delay distribution, delay spread, Doppler spread, interference level, location of transmitting device, parameter set, rank, or modulation and coding scheme (MCS) index.

15. The non-transient computer-readable medium according to any one of claims 10 to 12, wherein, When executed by the processor, the instructions cause the wireless device to train the LDPC decoder control input model through the following processes: For each of the previous LLR entries, different scaling factors are iteratively applied to decode the corresponding code block, thereby generating a corresponding set of scaled LLR entries; as well as For each iteration, determine the performance measurement results of the LDPC decoder when decoding the corresponding code block using the corresponding set of scaling LLR terms.

16. The non-transient computer-readable medium according to claim 15, wherein, The performance measurement results of the LDPC decoder include the number of LDPC decoder iterations required to successfully pass the error checking process for the corresponding code block using a corresponding set of scaled LLR terms.

17. The non-transient computer-readable medium according to claim 16, wherein, The error checking process includes cyclic redundancy check (CRC) or checksum pass / fail error checking.

18. The non-transient computer-readable medium according to claim 10, wherein, The predicted LDPC decoder control input includes a predicted LLR scaling factor, which is used to provide a corresponding set of scaled LLR terms, causing the LDPC decoder to maximize the success rate of decoding the corresponding code block.

19. A wireless device, comprising: Low-density parity-check (LDPC) decoder; as well as The processor is configured to execute instructions stored in memory to: The following terms are used to train the log-likelihood ratio (LLR) scaling model to predict the LLR scaling factor: (i) training data based on the previous LLR terms used by the LDPC decoder, and (ii) performance measurements of the LDPC decoder using the previous LLR terms; and Using a trained LLR scaling model, when inferring about a code block received after the previous LLR term, the predicted LLR scaling factor is calculated based on the estimated channel parameters corresponding to when the code block was received. The LDPC decoder is configured to decode the code block using a set of scaled LLR terms, which are generated using the predicted LLR scaling factor.

20. The wireless device according to claim 19, wherein, The processor is configured to train the LLR scaling model through the following processes: For each of the preceding LLR terms, a scaling factor is iteratively applied to decode the corresponding code block, thereby generating a set of scaled LLR terms; and For each iteration, determine the performance measurement results of the LDPC decoder when decoding the corresponding code block using the corresponding set of scaling LLR terms.

Images