| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Ambroise, If there are 90 bits at the output of the
randomizer, then all the steps after the randomizer are correct. But I am not
clear on where does the additional 10 zeros tail come from. The original input
data is 80 bits. After randomizer, the randomized data will be also 80 bits,
and then we pad 8 zeros as a tail, creating 88 bit length of data. Where do the
additional two zeros come from? And which section of the standard specifies
such rule? By the way, you mentioned about the
corrigendum. May I know if that document is available publicly? Thank you very much. Regards, Ernest From: owner-stds-802-16@LISTSERV.IEEE.ORG [mailto:owner-stds-802-16@LISTSERV.IEEE.ORG]
On Behalf Of Ambroise Popper Ernest, This
example is correct, provided a slight amendment that has been made in the
corrigendum that makes it clear that there are 90 bits at the output of the
randomizer (and not 96). Ambroise De :
owner-stds-802-16@LISTSERV.IEEE.ORG [mailto:owner-stds-802-16@LISTSERV.IEEE.ORG]
De la part de #ERNEST KURNIAWAN# Hi all, Have any of you tried out the example in section 8.3.3.5.3?
The example pads more than 8 zeros on the Randomized bit in order to fit the
number of transmittable bit based on the allocated data block (5 symbol
duration and 1 subchannel), which does not comply with the statement in 8.3.3.1,
which says that if the amount of data to transmit does not fit the allocated
data block prior to randomization stage,
padding of one’s will be done at the
end of the block up to the amount of allocated data block minus one byte (which
is reserved for the tail zero byte). And also there is a confusion in the statement on section
8.3.3.2.1, which says “when the total number of data bits in a burst is
not an integer number of bytes, zero pad bits are added after the zero tail
bits”. Is it true that this statement is just to enable us to display the
data after randomization bit in terms of bytes? Because if we include this
additional zeros onto the convolutional coder, the number of bits generated
will be larger than the allocated data block. (In our case, since we use one
subchannel, we expect to get 12 subcarrier x 5 symbol duration x 2 bits per
symbol = 120 bits) But if we use additional zeros onto the convolutional coder,
it will force the input to the convolutional coder from 90 (which is equal to
3/4 * 120) to 96, and hence the convolutional coder output will be 128 bits,
which is definitely more than 120, because this will create problem if we feed
the 128 bit of data to the block interleaver, since the number of input bits is
not integer multiple of the block size. And are there any “tested” documents which
provide correct examples on the various cases (uplink, downlink,
subchannelization, etc.) for both OFDM and OFDMA mode of operation? Regards, Ernest. |