GB2383725A

GB2383725A - Data decoding with Cyclic Redundancy Check

Info

Publication number: GB2383725A
Application number: GB0130973A
Authority: GB
Inventors: Timothy Fisher-Jeffes
Original assignee: Ubinetics Ltd
Current assignee: Aeroflex Cambridge Ltd
Priority date: 2001-12-27
Filing date: 2001-12-27
Publication date: 2003-07-02
Also published as: GB0130973D0

Abstract

A received signal comprises transport blocks each containing a data block and a cyclic redundancy check (CRC) sum. For each transport block, the CRC check occurs simultaneously with the decoding process (<I>eg</I>. Trellis decoding using a Viterbi/Max Log MAP algorithm) of the data block via the use of a reverse CRC generation process. First and second sections of a sequence are identified as the CRC and data block respectively, and the reverse CRC generation process checks the second section at the same time the second section is decoded, in order to compare the check sum calculated by said process to the contents of the first section. The checking means and the decoding means operate in parallel.

Description

PI03S0SGB DATA DECODING The invention relates to decoding encoded signals. In particular, the invention relates to decoding sequences which comprise a cyclic redundancy check sum (CRC) and a data block upon which the CRC has been established.

When a train of binary information, i. e. a data block, needs to be transmitted, the data block is first encoded before modulation onto a carrier signal, the encoding process serving to add redundancy to the signal being transmitted to help reduce the effect of errors introduced during the transmission of the modulated signal to a receiver. At the receiver, the transmitted signal is demodulated and decoded to recover the data block. Even though the redundancy added to the transmitted signal provides for the detection and correction of certain errors, it is possible that the decoded data block may still contain errors. In order to detect residual errors in the data block, it is known to append a CRC to the data block before it is encoded for transmission. Thus, when the signal is decoded in a receiver, the appended CRC can be checked to determine whether it matches the decoded data block. If the CRC does not match the decoded data block then either the CRC or the data block has been decoded incorrectly at the receiver.

A CRC can be established on a data block by applying the data block to a CRC generator.

Then, to determine whether a CRC and a data block decoded from a received signal match, the decoded data block can be applied to a CRC generator of the same construction as that used to establish the CRC included in the received signal. The CRC generated from the decoded data block is then compared with the CRC decoded from the received signal to determine if the CRCs match. If they match, it suggests that the received signal was decoded correctly.

A generic CRC generator 10 is shown in Figure 1. The generator 10 comprises a shift register 12 comprised of a number of shift elements, e. g. 14. Each shift element provides its output to an XOR gate, e. g. 16. The XOR gate 18 following the last element 20 of the register 12 is also supplied with the generator input uk. The generator input U) c is the train

of bits constituting the data block for which a CRC is to be produced. The output of XOR gate 18 is a feedback signal which is supplied to the first element 22 of the register 12 as a register input. The XOR gates following the shift elements other than the last each receive an input from a corresponding AND gate, e. g. 24. Each AND gate receives a respective selection signal, e. g. b3, and the feedback signal from XOR gate 18 as its inputs. The selection signals control the delay polynomial used in the CRC generation process. Taken together, the selection signals'bits form a word describing this polynomial. In use, the generator is clocked until all of the Uk have been processed at which time, the content of the shift register is the CRC for the data block as characterised by the delay polynomial of the generator 10.

One object of the invention is to improve the manner in which received signals are, on one hand, decoded and, on the other hand, subjected to error checking techniques.

According to one aspect, the present invention provides a method decoding a sequence comprising a CRC and a data block, the method comprising performing decoding on the

sequence to recede'the data of the block and at the same ur."r, 'r- : i ; '..''.".,,'.' on the data of the block.

The invention also consists in apparatus for decoding a sequence comprising a CRC and a data block, the apparatus comprising decoding means for decoding the sequence to recover the data of the block and checking means for performing a CRC check on the data of the block, wherein the checking means and the decoding means operate in parallel.

Accordingly, the invention provides that a CRC check can be ongoing during the process of decoding a received signal.

According to another aspect, the invention provides a method of decoding a sequence comprising a CRC and a data block, the method comprising provisionally identifying first and second sections of the sequence as the CRC and the data block respectively, performing decoding on the sequence to recover the second section and at the same time

performing a CRC check on the second section to determine if the first section corresponds to a CRC established on the second section.

The invention also consists in apparatus for decoding a sequence wherein first and second sections have been provisionally identified as a CRC and a data block respectively, the apparatus comprising decoding means for decoding the sequence to recover the second section and checking means for performing a CRC check on the second section to determine if the first section corresponds to a CRC established on the second section, wherein the checking means and the decoding means operate in parallel.

Accordingly, the invention provides a way in which a CRC check for the dual purposes of determining if the received signal has been decoded properly and of determining if the boundaries of the first and second sections of the received sequence have been properly allotted, can be begun whilst the decoding process is underway.

The CRC check may be made by, for example, performing a CRC generation process or a reverse CRC generation process on the recovered data or, as the case may be, on the second section.

In a CRC generation process, the recovered data or, as the case may be, the second section of the received signal is used to drive a CRC generator to produce a CRC for comparison with the CRC decoded from the received signal or, as the case may be, for comparison with the first section of the received signal as decoded.

In a reverse CRC generation process, the CRC contained in the received signal or, as the case may be the first section of the received signal as decoded is loaded in a reverse generator which is then iterated backwards to an initial state using the data recovered from the decoded signal or, as the case may be, using the second section of the received signal as decoded. If the initial state thus reached is an appropriate one, then a determination can be made as to whether the CRC decoded from the received sequence or, as the case may be the first section of the received signal as decoded corresponds to a CRC established on the

data block of the received signal or, as the case may be, the second section of the received signal.

Reverse generation may be particularly useful where the data in the received sequence is being decoded in the order opposite to that in which it was used to produce the CRC in the received signal prior to transmission.

Preferably, the decoding process employs a trellis decoding technique. In one embodiment, the decoding process involves following trace back data produced in the decoding process. For example, the decoding process can employ the Viterbi algorithm. In another embodiment, the decoding process employs a soft-output decoding technique. For example, the decoding process may be a turbo decoder using, for example, the Max Log-MAP algorithm.

From another perspective, the invention relates to a program for causing data processing apparatus to perform a method according to the invention. Such a program can be embodied in various ways as is well known to those skilled in the art. For e\ample. the program could be embedded in a read only memory.

The combined decoding and error checking according to the invention may take place in the context of, for example, a signal received in a telecommunications network. Alternatively, the context could be, for example, that of a computer receiving a signal conveying data being transferred to the computer from a disk drive.

Certain embodiments of the invention will now be described with reference to the accompanying drawings, in which : Figure 1 is a block diagram of a conventional CRC generator; Figure 2 is a block diagram of a UMTS receiver according to an embodiment of the invention;

Figure 3 illustrates various transport block formats ; Figure 4 illustrates some transport blocks lengths; Figure 5 illustrates convolutional decoding with blind transport format detection (BTFD); and Figure 6 is a block diagram of a reverse CRC generator.

The UMTS receiver 100 of Figure 2 comprises an antenna 110 for receiving signals for analysis by demodulator 112. The demodulator 112 provides a demodulator signal comprising a convolutionally encoded transport block to decoding and checking unit 114.

As transmitted to the receiver, the transport block contained a data block and a CRC established on the data block. The main function of unit 114 is to perform two operations in parallel on the transport block received from demodulator 112. The first operation is convolutional decoding of the transport block and the second operation is the performance of a CRC check on the data from the transport block as it is decoded. The decoded data from the transport block is provided by unit 114 to subsequent processing section 116, indicative of that portion of the receiver 100 which is responsible for performing any necessary remaining operations on the decoded data from the transport block, e. g. in order to produce an audible signal representing speech data contained in the received signal. In practice, the received signal will contain a succession of transport blocks and the receiver 100 operates upon them sequentially. Of course, the skilled person will appreciate that only the elements of the receiver 100 pertinent for the description of the decoding process are represented in Figure 2.

Figure 3 illustrates the various possibilities for the transport blocks handled by the receiver 100. Given that the horizontal axis represents time, the earliest received portion of a transport block shown in Figure 3 is to the left. In transport blocks 118 and 124 the data block is received first followed by the appended CRC. In transport blocks 120 and 122 the CRC is received first followed by the appended data block. Figure 3 also shows, for each transport block, the direction in which the data block has been applied to a CRC generator

to establish the CRC. Taking transport block 118 as an example, the first received bit of its data block is the first bit used to generate the attached CRC and the last received bit of its data block is the last bit used to generate the attached CRC. Transport block 120 provides an example where the order of receipt of the bits of the data block is opposite to the order in which the data bits were used to create the attached CRC, i. e. the last received bit of its data block is the first bit used to generate the attached CRC and the first received bit of the data block is the last bit used to generate the attached CRC.

As mentioned above, one of the tasks of unit 114 is to decode transport blocks received from demodulator 112. Where the error correction coding scheme used to encode the block is symmetric, decoding of the transport block can begin at either end of the transport block. However, where the error correction coding scheme is not symmetric, the block must be decoded commencing from a specific end. Also, other processes done in conjunction with the coding, such as blind transport format detection (BTFD, to be described in more detail later) in a UMTS context, may also dictate that the decoding of a transport block commences at a certain end. Convolutional encoding and turbo encoding can be made symmetric by ensuring that the encoding process is"terminated", i. e. the encoding process begins at, and ends at, the all-zero state, through the addition of extra tail or termination bits to the ends of the transport block being encoded.

When the unit 114 receives a demodulated transport block from unit 112, it proceeds to decode the transport block. During the decoding process, the data block of the transport block will be decoded starting at one end of the data block and finishing at its other end.

The direction in which the decoding process proceeds through the data block depends upon the direction chosen or dictated for the decoding process. In any case, the decoding process decodes the bits of the data block sequentially. As soon as decoded bits of the data block begin to be output by the decoding process, they can be supplied to a CRC checking process within unit 114. Thus, the process of performing a CRC check can be in progress whilst the decoding operation is on-going. The CRC checking process will now be described.

If the direction of the decoding of the data block corresponds to the direction in which the data in the data block was used to generate the CRC of that transport block, then as each bit of the data block is decoded, it can be supplied to a CRC generating process equivalent to that used to produce the CRC contained in the received transport block. Once all the decoded bits of the data block have been supplied to the CRC generating process, the resulting CRC can be compared with the CRC decoded from the transport block. Clearly, if the two CRCs match, then the transport block passes the CRC test and accordingly there is a high probability that the data block within the transport block has been received, demodulated and decoded correctly.

Of course, it is possible that the direction in which the data block is decoded is opposite to the direction in which the data within the data block was used to generate the CRC contained in the transport block. In this case, as each bit of the data block is decoded, it is supplied to a reverse CRC generation process. Essentially, the reverse CRC process involves loading the CRC contained in the transport block into a reverse CRC generator and applying the decoded bits of the data block in an order which is opposite to that in which the data block bits were applied to generate the CRC of the transport block. As will be appreciated, since, in the present case, the direction in which the data block is decoded is opposite to the direction in which the data block bits were used to generate the CRC of the transport block, the order in which the bits of the data block are decoded is naturally correct for application to the reverse CRC generation process. Once all the bits of the decoded data block have been applied to the reverse CRC generator, the CRC value within the reverse generator is compared with the initial state that would have occupied the CRC generator used to generate the CRC of the transport block. If these two initial values match, then the decoded data block passes the CRC check.

It will be appreciated that for a reverse CRC generator to be employed in parallel with the decoding process, then the CRC of the transport block must be decoded first and loaded into the reverse CRC generator before decoded bits of the data block are supplied to the reverse generator. Clearly, this imposes a limitation on the decoding direction in that it must begin from the end of the transport block at which the CRC resides. The structure and operation of an example of a reverse CRC generator will be described later.

We will now consider the example of a transport block convolutionally encoded using the Viterbi algorithm with proper termination of the encoding process, i. e. the transport block can be decoded from either end. For the purposes of this example, we will initially assume that the transport block has the format of transport block 118 in Figure 3. The decoding process is arranged so that trace back data is produced for the transport block and is followed from the left hand end of the transport block. Thus, the bits of the data block are decoded in the same order in which they were used to generate the CRC contained in the transport block so the decoded bits can be presented to a CRC generation process in unit 114 in the same order in which they are decoded. When the last bit of the data block is decoded, the result in the CRC generation process is held whilst the decoding process continues by decoding the CRC at the right hand end of the transport block. Then, the CRC decoded from the transport block is compared with the result of the CRC generation process performed in unit 114 and if these values match then the decoded data block passes the CRC check.

It is useful now to consider a case where the bits of the data block in the transport block were applied in the opposite order to produce the CRC contained in the transport block, i. e. the case where the transport block has the format of block 124 in Figure 3. Here, the decoding process is arranged so that trace back data is followed from the right hand end of the transport block. Initially, the CRC is decoded, the decoding process then proceeding to decode the data block in the same direction in which it was used at the transmitter to generate the CRC of the transport block. Therefore, as the data block is decoded, its bits can be supplied directly to a CRC generation process. When the decoding process reaches the end of the data block, the result held in the CRC generation process can be compared with the CRC decoded from the transport block to determine if the data block passes the CRC check. Note that it would not be possible in this example to begin decoding at the left hand end of the transport block and rely on reverse CRC generation. This is because the CRC must be decoded from the transport block first in order for reverse CRC generation to be used in parallel with decoding.

Briefly reviewing Figure 3, some cases where it will possible to use reverse CRC generation can be identified. For example, reverse CRC generation can be used where the

transport block has the format of block 118 and trace back data is followed from the right hand end of the transport block. Similarly, reverse CRC generation can be used where the transport block has the format of block 120 and trace back data is followed from the left hand end of the transport block.

In the examples given above, Viterbi coding/decoding was employed. Of course, other types of encoding/decoding schemes can be used. For example, a turbo coding scheme could be used, wherein decoding takes place via the calculation of a and metrics to produce decoded output in the form of a series of soft decisions representing the transport block. In this case, the output soft decisions would need to be"hardened"prior to their use in the CRC check and this could be achieved by merely considering the sign bits of the soft decisions.

The invention can be deployed with advantage in situations requiring blind transport format detection (BTFD). BTFD is used where the boundaries of the transport blocks are not signalled in a received communication. Figure 4 illustrates a scheme using three different transport block lengths A, B and C, exemplified by transport blocks 126,128 and 130 respectively. When BTFD is used, it is necessary to ascertain where the transport blocks in a received signal begin and end, given that the transport blocks may each have one of three possible lengths. Tentative assignments of transport block lengths need to be made, these assignments being tested using a CRC check to determine if they are correct. As indicated in Figure 4, each transport block is received in the order of its data block followed by its CRC. Again, Viterbi decoding is employed and, as shown in Figure 4, the trace back direction is opposite to the direction in which the data block bits are used to generate the CRCs of the transport blocks.

In Figure 5, the three possible block lengths of Figure 4 are superimposed to better illustrate the BTFD process. Figure 5 shows a stream of demodulated data 132 received by unit 114 for decoding and CRC checking. From a known transport format position 134 in stream 132, the next transport block to be decoded extends to length A, B or C. In the decoding process, trace back data is followed back from the position that denotes the end of length C to decode the bits of stream 132 extending back towards known transport

format position 134. Three CRC checking processes can be performed in parallel with this decoding process.

As soon as the portion of stream 132 corresponding to the CRC of a transport block of length C is decoded, a reverse CRC generation process can be begun using the bits subsequently decoded. If the reverse CRC generation process provides the correct initial state when known transport format position 134 is reached, then the conclusion is that the length of the transport format block being decoded is C.

When the trace back process reaches the position in the stream that denotes the end of length B, a second putative CRC can be extracted and tested using a reverse CRC process on the bits subsequently decoded. If this reverse CRC generation process indicates the correct initial state when known transport format position 134 is reached, then the conclusion is that a transport block of length B is being used.

When the trace back process reaches the position denoting the end of block length A, a third putative CRC is decoded and used in a third reverse CRC generation process employing the bits subsequently decoded. If this reverse CRC generation process indicates the correct initial state when known transport format position 134 is reached, then the conclusion is that the transport block being used is of length A.

Thus, several CRC checks can be performed in parallel with the decoding process. In the present example, tests were made against three possible block lengths, although it will be apparent that the number of block lengths tested can be varied arbitrarily.

In Figure 6, a block diagram of a reverse CRC generator, also called a reverse-iterator, is shown. The design and operation of the reverse-iterator will now be described, initially with reference to Figure 1.

With reference to generator 10 in Figure 1, the CRC produced upon application to the generator of the kith bit of the data sequence Uk is Wk. The register 12 has N shift elements (the right most being the first and being numbered N = 0) so the CRC bit in any element is W,, k, where i is an index identifying the shift element and ranges from i=0 to N-l. The selection bits bi to bl controlling the AND gates constitute a vector B specifying the generator's delay polynomial with the exception of its first (1) and last (DN) terms.

The delay polynomials Gon specified in the 3GPP Telecommunications Standard are:

for which B = [b1...bN-1]T = [1011001]T;

for which B = [11100000001]T;

for which B = [000010000001000]T; and

for which B = [10001100000000000000001 y. In state space, a generator can be expressed as :

where A = [o I I I B

where I is the identity matrix and where A. wkis considered multiplication over GF (2).

and subject to the initial condition wo = [00... 0] This can be rearranged to the format :

and it has been realised that

By inspection, C and D can be rewritten as:

Given the equation for Wk in terms of wk, and the value of Wk for the k value equal to the end of the data block passed to the generator, one can calculate wo.

A block diagram of the resulting reverse-iterator 26 for CRCs is shown in Figure 6. As will be apparent, the types of component used in the reverse-iterator 26 are the same as those used in generator 10 of Figure 1, albeit interconnected in a different manner. In reverse-iterator 26 the input Uk to the reverse iterator 26 is combined in an XOR operation with the output of the shift register 28 to produce an input for shift register 28. The register output is also supplied to the XOR gates between the shift elements under the control of the vector B.

In use, a CRC is initially loaded into the shift register 28. The bitsukof a data block are then supplied in reverse order to the input of the reverse iterator 26, each bit causing one backward iteration of the CRC. That is, the presentation of a bit Un to the input will cause the CRC X in the register to be changed into a CRC Y, where X and Y are related such that application of the bit Un to Y in the CRC generation process would produce X. In this manner, the CRC initially loaded in the shift register 28 will be iterated back to a CRC Z after application of the final bit Uo (being the first bit in the block). If Z is not equal to the initial state used in the generation of a CRC from a data block (in this case Wo = [000... 0]1) then the CRC initially loaded into register 28 does not match the data block.

Claims

CLAIMS 1. A method of decoding a sequence comprising a CRC and a data block, the method comprising performing decoding on the sequence to recover the data of the block and at the same time performing a CRC check on the data of the block.
2. A method according to claim 1, wherein the CRC check is made by performing a CRC generation process on the recovered data.
3. A method according to claim 1, wherein the CRC check is made by performing a reverse CRC generation process on the recovered data.
4. A method of decoding a sequence comprising a CRC and a data block, the method comprising provisionally identifying first and second sections of the sequence as the CRC and the data block respectively, performing decoding on the sequence to recover the second section and at the same time performing a CRC check on the second section to determine if the first section corresponds to a CRC established on the second section.
5. A method according to claim 4, wherein the CRC check is made by performing a CRC generation process on the second section.
6. A method according to claim 4, wherein the CRC check is made by performing a reverse CRC generation process on the second section.
7. A method according to any one of claims 1 to 6, wherein the decoding process is via a trellis decoding technique.
8. A method according to claim 7, wherein the decoding process is via following trace back data produced in the decoding process.
9. A method according to claim 7, wherein the decoding process is via a soft-output decoding technique.

<Desc/Clms Page number 15>
10. Apparatus for decoding a sequence comprising a CRC and a data block, the apparatus comprising decoding means for decoding the sequence to recover the data of the block and checking means for performing a CRC check on the data of the block, wherein the checking means and the decoding means operate in parallel.
11. Apparatus according to claim 10, wherein the CRC check is made by performing a CRC generation process on the recovered data.
12. Apparatus according to claim 10, wherein the CRC check is made by performing a reverse CRC generation process on the recovered data.
13. Apparatus for decoding a sequence wherein first and second sections have been provisionally identified as a CRC and a data block respectively, the apparatus comprising decoding means for decoding the sequence to recover the second section and checking means for performing a CRC check on the second section to determine if the first section corresponds to a CRC established on the second section, wherein the checking means and the decoding means operate in parallel.
14. Apparatus according to claim 13, wherein the CRC check is made by performing a CRC generation process on the second section.
15. Apparatus according to claim 13, wherein the CRC check is made by performing a reverse CRC generation process on the second section.
16. Apparatus according to any one claims 10 to 15, wherein the decoding means is arranged to perform decoding via a trellis decoding technique.
17. Apparatus according to claim 16, wherein the decoding process is via following trace back data produced in the decoding process.

<Desc/Clms Page number 16>
18. Apparatus according to claim 16, wherein the decoding process is via a soft-output decoding technique.
19. A program for causing data processing apparatus to perform a method according to any one of claims 1 to 9.
20. Apparatus for decoding a sequence, the apparatus being substantially as hereinbefore described with reference to the accompanying Figures.
21. A method of decoding a sequence, the method being substantially as hereinbefore described with reference to the accompanying Figures.