Patent Description:
Embodiments of the present invention, although not limited to this, relate to channel coding optimizations in networks such <NUM>. In the following, some consideration concerning CRC attachment for smaller TBs are given by referring to reference [<NUM>]: R1-<NUM> "CRC attachment for Smaller TBs" Nokia, Alcatel-Lucent Shanghai Bell.

In Ran1 NR Ad-Hoc #<NUM> meeting, two LDPC base graphs were agreed to support data channel in <NUM>. The way those are used agreed as the following.

To be checked how the receiver knows in each case the code rate of the initial transmission, and how exactly it is defined.

FFS whether some UE capabilities may be possible that do not require the implementation of both base graphs.

For CRC attachment, LDPC codes have inherent error detection capability and could be used to reduce the CRC overhead. In Ran1 #88bis meeting, an agreement was made on attaching <NUM> CRC bits for the TB when the TB is larger than a threshold. However, the threshold was not agreed. In particular, agreement in Ran1 #88bis is,.

On MCS table, LTE uses <NUM> bits to indicate MCS in the control payload. All these would use Turbo code and there is no relation with the MCS table and the use of the coding scheme. For NR, how to utilize this MCS field needs more discussion as the base graph that is used can be different.

In order to optimize the performance is necessary to consider the use of two base graphs when defining other details of NR.

Embodiments of the present invention address this situation and aim to overcome the above-described problem and to optimize the performance on a coding channel.

According to some aspects, there is provided the subject matter of the independent claims. Some further aspects are defined in the dependent claims.

These and other objects, features, details and advantages will become more fully apparent from the following detailed description of embodiments of the present invention which is to be taken in conjunction with the appended drawings, in which:.

In the following, description will be made to embodiments of the present invention. It is to be understood, however, that the description is given by way of example only, and that the described embodiments are by no means to be understood as limiting the present invention thereto.

In the following, some concerns relating to CRC attachment and generating the MCS table for NR of the inventors are described.

Concerning the CRC attachment, it is noted that in general, the majority of uplink and downlink traffic operate with the smaller TB sizes and good performance is important. Also, the transmission resources are limited, and the number of info bits and CRC bits decides the code rate that the transmission operates. Reducing CRC overhead helps to improve the spectrum efficiency and thus performance, but it should be done without sacrificing the error detection capability of the TB. LDPC codes are capable of providing an extra support on the error detection that can eventually reduce the CRC overhead. In reference [<NUM>] described above, the impact of CRC bits on the effective code rate is investigated, where it is observed that CRC bits make a significant change in the effective code rate up to <NUM> bits. But, it is noted that some UEs may not implement both base graphs and having an arbitrary number as the threshold could cost the UE implementations. For example, if the UE only operates with Base graph #<NUM>, the max TBS that would support with that is <NUM> bits (including CRC). So having something like <NUM> bits as the boundary create requirements to implement two CRC shift registers at the UE for the same Base graph.

Concerning the MCS field, it is noted that, when finalizing the MCS table for NR, it is needed to make sure that both base graphs #<NUM> and #<NUM> may be operated independently from one another. For example, some UEs may only implement base graph #<NUM> while some may implement only base graph #<NUM>. It can be predicted that ultra reliable low latency communication would use base graph #<NUM> and good granularity in terms of spectral efficiency is required in the MCS table. Having random MCS table without thinking of the use of base graphs could lead to some inefficiencies in the NR operation.

In the following, a general overview of an embodiment of the present invention is described by referring to <FIG>.

In particular, <FIG> shows a UE or gNB <NUM> as an example for a first apparatus according to the present embodiment. The apparatus <NUM> comprises at least one processor <NUM> and at least one memory <NUM> including computer program code. The at least one processor <NUM>, with the at least one memory <NUM> and the computer program code, is arranged to cause the apparatus to at least perform generating a code block including information bits and parity bits, the parity bits being generated by performing a cyclic redundancy check on the information bits, determining the number of parity bits used in generating the code block on the number of the information bits and may be based on the applied linear error correcting code base graph, and encoding the code block by using the applied linear error correcting code base graph.

In other words, by referring to the flowchart shown in <FIG>, in step S1 the number of parity bits for generating the code block is determined, namely based on the number of the information bits and may be based on the applied linear error correcting code base graph. In step S2, the code block is generated, and in step S1, the code block is encoded using the linear error correcting code base graph.

The linear error correcting code is a LDPC code. Hence, the number of parity bits used for CRC differs based on the number of information bits and optionally based on the applied LDPC base graph. In this way, performance on the channel can be optimized.

Moreover, when determining the number of parity bits used in generating the code block based on the applied linear error correcting code (e.g., LDPC) base graph, it can be referred to an MCS table based on linear error correcting code base graph. That is, for example the MCS table may contain an indication how many parity bits should be used depending on the applied LDPC base graph.

The apparatus <NUM> may further comprise input/output (I/O) units or functions (interfaces) <NUM> connected to the processor <NUM>, in order to provide connections to other elements in a network or the like.

Moreover, in the apparatus <NUM>, the at least one processor <NUM>, with the at least one memory and the computer program code, may also be to cause the apparatus to at least perform providing a modulation and coding scheme [MCS] table including information on modulation and coding schemes, wherein the table specifies information on modulation and coding schemes which comprises a nested structure, in which different modulation and coding schemes are referred to by to by respective indices, wherein the indices are constructed by a number of bits, and the indices indicating modulation and coding schemes relating to a second linear error correcting code base graph are indicated by a number of bits which is smaller than the number of bits of indices indicating modulation and coding schemes relating to a first linear error correcting code base graph.

It is noted that the above procedures may also be carried out by another apparatus than the apparatus <NUM>, i.e., another apparatus than a UE or a gNB.

Hence, according to some embodiments of the present invention, CRC and MCS table(s) are considered for the <NUM> LDPC code. That is, different length CRC's are used depending on the selected base graph and number of info bits. A second aspect considers an organization of modulation and coding sets (MCS). Here the MCS is "nested", i.e. the methods are not consecutive, and may be overlapping. Thus, according to embodiments of the present invention, a method of defining a threshold for CRC length and MCS table are provided.

In this way, performance can be optimized.

In the following, some more details of embodiments of the present invention are described.

According to some embodiments of the present invention, CRC attachment is different for different base graphs and it will be defined based on the TBS threshold.

Furthermore, the MCS table will contain a nested structure that provides good granularity in the spectral efficiency for both base graph #<NUM> and base graph #<NUM>.

In the following, some further detailed embodiments are described.

First, the CRC attachment is described, wherein it is assumed that the maximum code block size supported by the LDPC paragraph #<NUM> is <NUM>.

In this example, the input bits to the CRC computation are denoted by a<NUM>,a<NUM>,a<NUM>,a<NUM>,. ,aA-<NUM>, and the parity bits are denoted by p<NUM>,p<NUM>,p<NUM>,p<NUM>,. ,pL-<NUM>, where A is the size of the input sequence and L is the number of parity bits. The parity bits are generated by one of the following cyclic generator polynomials: <MAT> or <MAT> <MAT>.

The encoding is performed in a systematic form, which means that in GF(<NUM>), the polynomial: <MAT> yields a remainder equal to <NUM> when divided by the corresponding CRC generator polynomial.

The bits after CRC attachment are denoted by b<NUM>,b<NUM>,b<NUM>,b<NUM>,. ,bB-<NUM>, where B = A + L. The relation between ak and bk is: <MAT> <MAT>.

If A is no larger than the <NUM> - L<NUM>, a CRC sequence of L=L<NUM> bits is attached to the TBS. For example, L1 = <NUM>. Otherwise, a CRC sequence of L = <NUM> bits is attached to the TBS.

In the following embodiment, a more detailed example concerning the MCS table is described.

An MCS table for URLLC or UEs that uses BG#<NUM> can use <NUM> bit MCS index such that it is nested inside the big MCS table. Redefining TBS sizes or keeping spate tables may not need in such cases.

<FIG> shows a corresponding example, wherein the left part shows a <NUM> bit MCS table, whereas the right part shows a <NUM> bit table. The <NUM> bit MCS table is nested within the <NUM> bit MCS table. Hence, a UE (or gNB) which only supports BG #<NUM> can refer to the <NUM> bit MCS table within the <NUM> bit MCS table by setting the leading bit to zero.

The invention is defined by the appended claims and is not limited to the specific embodiments described above, and various modifications are possible.

For example, in the above embodiments, specific numbers are given. However, the invention is not limited on these. That is, for example the maximum code block size supported by the LDPC base graph #<NUM> is not limited to <NUM> and can be any suitable number.

Moreover, according to the above embodiments, the number of LDPC base graphs, of which the applied LDPC base graph is to be selected, is two. However, in an example not falling under the scope of the claimed invention, the number can be higher.

Furthermore, in the above embodiments, an LDPC code was used for channel coding. However, in examples not falling under the scope of the claimed invention, any other suitable linear error correcting code can be applied, for example a Polar code.

Moreover, it is also possible in further examples not falling under the scope of the claimed invention to use different coding schemes, for example Polar coding for short blocks and LDPC for large blocks. The CRC attachment may not require to be different due to different inherent error detection (LDPC has inherent detection. Polar code does not). However, it is possible to match the CRC lengths in order to simplify the implementation. In this way, the same error detection capability can be provided across the operating regions. For example, it is possible to append <NUM> CRC parity bits for polar codes and use the same size for LDPC codes.

Furthermore, in the above embodiments it was described that in case of using the LDPC base graph #<NUM>, no segmentation is applied. However, the invention is not limited to this. That is, according to an alternative embodiment, a transport block including the information bits may be segmented into at least two code blocks when the second linear error correcting code (e.g. LDPC) base graph is used. In this case, the same number of parity bits is used for each code block as in case no segmentation is applied. That is, the CRC attachment is kept equal for TB and CB level, so that the implementation is simplified.

Moreover, when using segmentation with BG #<NUM>, CRC overhead may be considered when determining the number of CBx. For this, the number of CBs may be determined as follows:
For example, if the TB size is B and CRC attachment we need for TB and CB is L, the number of CBs can be found as follows:
Number of <MAT>.

It is noted that the operation "Ceil()" indicates the smallest integer greater than or equal to the given number.

Moreover, a threshold can be used for deciding whether to apply segmentation or not. In this case, the maximum size that Base graph #<NUM> supports should be the threshold. For example, TB + CRC = <NUM> should be the threshold, when <NUM> is the maximum size that Base graph #<NUM> supports.

Claim 1:
An apparatus for encoding, the apparatus comprising:
means for generating a code block including information bits of a transport block and parity bits, the parity bits being generated by performing a cyclic redundancy check on the information bits,
means for selecting a linear error correcting code base graph out of a first linear error correcting code base graph and a second linear error correcting code base graph based on the number of information bits,
wherein the first linear error correcting code base graph is selected for an initial transmission and subsequent re-transmissions of the same transport block when a code block size is larger than a first threshold X or a code rate of the initial transmission is larger than a second threshold;
wherein the second linear error correcting code base graph is selected for the initial transmission and subsequent re-transmissions of the same transport block when the code block size is smaller or equal than the first threshold X and the code rate of the initial transmission is smaller or equal than the second threshold;
wherein the first threshold X is equal to a maximum code block size supported by the second linear error correcting code base graph;
means for determining the number of parity bits used in generating the code block based on the number of the information bits, wherein determining the number of parity bits comprises a comparison of the number of the information bits with a further threshold, the further threshold being defined by the maximum code block size X supported by the second linear error correcting code base graph; and
means for encoding the code block by using the selected linear error correcting code base graph, wherein the selected linear error correcting code base graph is a low density parity check base graph.