10 Jul
2013
10 Jul
'13
9:46 a.m.
Hi,
The treillis scan is very similar in all cases. The only thing to
support is the puncturing during the scan (I wanted to avoid having
the de-puncture first).
It also currently supports progressive decoding (i.e. you can start
decoding a message before you have all of it if you want, you just
feed it chunk by chunk and it can resume where it left off).
Most of the changes between variations come from the way the
termination is handled but since that's always only a few symbols,
that could be left alone unoptimized (assuming the internal state is
compatible enough).
Cheers,
Sylvain
This was the issue I was trying to raise. The patch
(that doesn't
exist) for the API change on osmo-bts alone is huge. I don't like any
API breaking changes, and I have limited interest in making changes to
osmo-bts. I do like compatibility layers though.
Yes, both adapting the code and/or adding compatibility layer are no issue.
Ideally the code should just end up in libosmocore, (being compiled if
supported), and
just "work" with any code that previously worked, possibly fallbacking
to the reference
impl at runtime if something weird is not supported.
And all in all be completely transparent to the user, just
accelerating it if possible.
Also, it
should be obvious but any change in libosmocore must stay
compatible with all codes that have been supported until now and not
just a subset of GSM/LTE specific codes.
Aside from testing all the various combinations, I'm less concerned
about structural (non-API) compatibility. The convolutional codes are
defined by the trellis structure or, equivalently, shift register and
generator polynomials. The Viterbi algorithm is fundamentally the same
in all cases. Unless there are some truly bizarre cases, which you
would know more about than I do, I see this as less of an issue.