12 Oct
2016
12 Oct
'16
2:47 p.m.
On Wed, Oct 12, 2016 at 10:51 AM, Vadim Yanitskiy <axilirator(a)gmail.com> wrote:
I think the
puncturing code should be part of the library (otherwise
every user will have to reimplement the same thing again and again).
I am agree with you. We recently discussed this question with Tom Tsou.
He said, that there was some performance related reasons to perform
puncturing inside both gsm0503_pdtch_encode() / gsm0503_pdtch_decode(). From an API standpoint, it makes no difference and
makes sense to move
the puncturing into the library. Regarding the implementation,
there
is a significant difference.
Puncturing and convolutional coding are inherently discrete steps. It
is possible, as in the library, to reconstruct the non-punctured bit
vector while feeding into the Viterbi at same time, but the downside
of this approach is reduced optimization (or potential optimization).
The reason is that the Viterbi always runs at the full non-punctured
rate and can be implemented with well known trellis coding
optimizations. Puncturing is a completely separate algorithm from the
Viterbi, and integrating them together provides no performance benefit
at best and degradation at worst.
That said, the one advantage to puncturing inside the Viterbi is for
handling continuous non-fixed length codes. But, those codes are not
used by GSM or 3GPP in general, so they are not relevant here.
In summary, my concern is about the implementation and not the API.
Perhaps we could pull the puncturing into the library as Max suggests.
Then, separately, consider performance changes to the internal
puncturing and Viterbi implementations.
-TT