RFC 6330 RaptorQ FEC scheme (not 3GPP-mandated, offered as reference work) - #64
Open
jordijoangimenez wants to merge 3 commits into
Open
Conversation
This was referenced Aug 11, 2026
Closed
jordijoangimenez
marked this pull request as draft
August 14, 2026 10:28
jordijoangimenez
force-pushed
the
feature/raptorq-support
branch
from
August 22, 2026 12:57
7bbb1e1 to
77b7f86
Compare
jordijoangimenez
changed the title
jordijoangimenez
changed the base branch from
development
to
feature/raptor-raptorq-fec
August 22, 2026 12:59
jordijoangimenez
force-pushed
the
feature/raptorq-support
branch
from
August 22, 2026 13:16
77b7f86 to
61ae0ae
Compare
jordijoangimenez
force-pushed
the
feature/raptor-raptorq-fec
branch
from
August 22, 2026 13:16
5e2e338 to
f43eca6
Compare
github-project-automation
Bot
moved this from In Progress
to Done
in MBMS: Support for FLUTE
jordijoangimenez
changed the base branch from
feature/rfc5053-raptor-fec
to
development
August 22, 2026 13:24
jordijoangimenez
changed the title
jordijoangimenez
changed the base branch from
development
to
feature/raptor-raptorq-fec
August 22, 2026 15:25
jordijoangimenez
marked this pull request as ready for review
August 22, 2026 15:38
jordijoangimenez
force-pushed
the
feature/raptor-raptorq-fec
branch
from
August 22, 2026 15:50
f43eca6 to
aa36087
Compare
jordijoangimenez
force-pushed
the
feature/raptorq-support
branch
from
August 22, 2026 15:51
61ae0ae to
9ae681a
Compare
jordijoangimenez
force-pushed
the
feature/raptor-raptorq-fec
branch
from
August 22, 2026 16:03
aa36087 to
2007684
Compare
jordijoangimenez
force-pushed
the
feature/raptorq-support
branch
from
August 22, 2026 16:04
9ae681a to
3d25c37
Compare
jordijoangimenez
force-pushed
the
feature/raptor-raptorq-fec
branch
from
August 22, 2026 18:51
7e84d2c to
f9e1bc2
Compare
jordijoangimenez
force-pushed
the
feature/raptorq-support
branch
from
August 22, 2026 18:53
85cda93 to
1035bb2
Compare
jordijoangimenez
force-pushed
the
feature/raptor-raptorq-fec
branch
from
August 22, 2026 19:08
f9e1bc2 to
ee706fd
Compare
jordijoangimenez
force-pushed
the
feature/raptorq-support
branch
2 times, most recently
from
August 22, 2026 19:45
cb7942e to
472cdcd
Compare
jordijoangimenez
force-pushed
the
feature/raptor-raptorq-fec
branch
from
August 22, 2026 19:53
2621a6b to
4f0fe34
Compare
jordijoangimenez
force-pushed
the
feature/raptorq-support
branch
from
August 22, 2026 19:54
472cdcd to
a34419d
Compare
jordijoangimenez
force-pushed
the
feature/raptor-raptorq-fec
branch
2 times, most recently
from
August 22, 2026 20:05
c22c465 to
9f9087e
Compare
jordijoangimenez
force-pushed
the
feature/raptorq-support
branch
from
August 22, 2026 20:06
a34419d to
36ed59d
Compare
jordijoangimenez
force-pushed
the
feature/raptor-raptorq-fec
branch
from
August 22, 2026 20:45
9f9087e to
050f116
Compare
jordijoangimenez
force-pushed
the
feature/raptorq-support
branch
from
August 22, 2026 20:46
36ed59d to
bdac74e
Compare
jordijoangimenez
force-pushed
the
feature/raptor-raptorq-fec
branch
from
August 22, 2026 21:16
050f116 to
25094a6
Compare
jordijoangimenez
force-pushed
the
feature/raptorq-support
branch
from
August 22, 2026 21:17
bdac74e to
a8b2cf2
Compare
jordijoangimenez
force-pushed
the
feature/raptor-raptorq-fec
branch
from
August 23, 2026 07:08
25094a6 to
6e55625
Compare
jordijoangimenez
force-pushed
the
feature/raptorq-support
branch
from
August 23, 2026 07:10
a8b2cf2 to
470df62
Compare
jordijoangimenez
force-pushed
the
feature/raptor-raptorq-fec
branch
from
August 23, 2026 07:36
6e55625 to
f9ad94d
Compare
jordijoangimenez
force-pushed
the
feature/raptorq-support
branch
from
August 23, 2026 07:45
470df62 to
db452b7
Compare
jordijoangimenez
force-pushed
the
feature/raptor-raptorq-fec
branch
from
August 23, 2026 12:11
f9ad94d to
bf6b1a9
Compare
jordijoangimenez
force-pushed
the
feature/raptorq-support
branch
from
August 23, 2026 12:13
db452b7 to
5252e03
Compare
jordijoangimenez
force-pushed
the
feature/raptor-raptorq-fec
branch
from
August 23, 2026 12:22
bf6b1a9 to
ee01d44
Compare
jordijoangimenez
force-pushed
the
feature/raptorq-support
branch
from
August 23, 2026 12:25
5252e03 to
d25ff1d
Compare
jordijoangimenez
force-pushed
the
feature/raptor-raptorq-fec
branch
from
August 23, 2026 12:37
ee01d44 to
929741f
Compare
jordijoangimenez
force-pushed
the
feature/raptorq-support
branch
from
August 23, 2026 12:38
d25ff1d to
59d12c7
Compare
jordijoangimenez
force-pushed
the
feature/raptor-raptorq-fec
branch
from
August 23, 2026 14:31
929741f to
3d5abc0
Compare
…ecific OTI layout Change type New feature, not 3GPP. This branch is the RaptorQ delta on top of the Raptor branch and nothing else. Basis RaptorQ is outside the set of FEC schemes 3GPP references, which is why it lives here and not on the compliant branches. TS 26.346 V18.2.0 clause L.4.7: "Regarding Application Layer FEC support, the two FEC schemes referenced in this specification, the Compact No-Code FEC scheme as specified in RFC 3695 [13], and the Raptor FEC scheme as specified in RFC 5053 [91] are optional to implement by the BM-SC and mandatory to support by the UE." RaptorQ and RFC 6330 appear nowhere in TS 26.346: zero occurrences. Not forbidden, just outside the referenced set. RFC 6330: "This document describes a Fully-Specified Forward Error Correction" scheme "corresponding to FEC Encoding ID 6", so its Codepoint value is 6 under the identity mapping the rest of this library uses. Corrected while reinstating it The previous version of this branch was an unexplained revert of the removal commit, and it brought back the three invented FDT attribute names the Raptor branch had already replaced with the schema-defined FEC-OTI-Scheme-Specific-Info. Reinstating it that way would have undone a conformance fix. Worse, it shared one encoder between the two schemes, which is wrong: the same four octets carry DIFFERENT field widths, with Z and N the opposite way round, so encoding one scheme with the other's layout silently corrupts both values. RFC 5053 clause 3.2.3, Raptor: "a 4-octet field consisting of the parameters Z (2 octets), N (1 octet), and Al (1 octet)" RFC 6330 clause 3.3.3, RaptorQ, the Scheme-Specific parameter list: "The number of source blocks (Z): 8-bit unsigned integer." "The number of sub-blocks (N): 16-bit unsigned integer." Change Reinstates RaptorQCodec, RaptorQMath, RaptorQTables and GF256LinearSystem with their headers and test binary, and the FecScheme::RaptorQ dispatch branches. Replaces the single encoder with one that selects the octet layout from the scheme, on both the encode and decode sides and at both the FDT-Instance and File levels, keeping the schema-defined attribute the Raptor branch introduced. Rebuilt on the Raptor branch rather than on the old lineage, so it is exactly one delta above it and the two non-3GPP features, this and FLUTE version 2, are now separate from each other as well as from the compliant core. Verification T1: builds clean, ctest at the build root 35/35, the 25 from the Raptor branch plus the RaptorQ suite and 2 new cases. The layout difference is asserted rather than assumed: identical inputs Z=1, N=0x0203, Al=4 encode to AQIDBA== under RaptorQ and AAEDBA== under Raptor, and each is checked absent from the other's output. A round trip with N=0x0140, a value a shared one-octet layout would truncate, recovers all three parameters. Quotations checked with tools/verify-citations.py in --strict mode. Not in this change No claim that RaptorQ is 3GPP conformant, because it is not in the referenced set at this baseline. The Raptor paths below are untouched. Carries its own repair-symbol coverage rather than leaving it to a follow-up, for the reason given on the Raptor commit this builds on: a fountain code that transmits no repair symbol protects nothing, and the object-level tests that pull every symbol in one call cannot see it. RaptorQRepairTransmissionTest drives one datagram at a time and acknowledges each, and two of its four cases fail if the completion condition is reverted, emitting 79 symbols instead of 90 and no repair symbol instead of 11. T2 for this scheme: an object recovered byte-identically over real multicast at a 7.6% datagram loss rate, where Raptor with its smaller default budget does not.
Problem The example transmitter drove one FDT schema, one FEC scheme and a fixed redundancy level, so the profiled-schema, Raptor and RaptorQ paths could not be exercised against a real receiver over a real socket without editing and rebuilding it. Code-derived, no spec claim. Raised by looking for a way to drive the FEC and FDT schema paths end to end Change Adds -S/--fdt-schema (draft2005, rfc3926, profiled), -F/--fec (compact, raptor, raptorq) and -L/--fec-redundancy-level, each mapping its argument onto the enumeration or value the Transmitter constructor already accepts. Defaults reproduce the previous behaviour, so an existing command line is unaffected. Verification T2: used to capture the FDT off the wire per schema, and to run Raptor and RaptorQ end to end over multicast including under datagram loss. The RaptorQ run's FDT carries FEC-OTI-FEC-Encoding-ID="6" and the RaptorQ scheme-specific layout, captured by a sniffer that links no library code. Not in this change Any library behaviour. This only exposes choices the library already offered.
Problem A caller could select RaptorQ for a session running the MBMS Download Profile. The profile names the FEC schemes it admits and RaptorQ is not one of them, so a receiver operating the profile has no obligation to decode it and in general will not. The session would transmit and no receiver would recover anything. [source-derived] Basis TS 26.346 V18.2.0 clause L.4.7: "Regarding Application Layer FEC support, the two FEC schemes referenced in this specification, the Compact No-Code FEC scheme as specified in RFC 3695 [13], and the Raptor FEC scheme as specified in RFC 5053 [91] are optional to implement by the BM-SC and mandatory to support by the UE." RaptorQ is RFC 6330, which TS 26.346 does not reference at any point. Raised by reading the authority during this work Change Transmitter holds the profile and the content FEC OTI, so the check belongs there. Under Profile::Mbms3gpp a content FEC OTI naming RaptorQ is refused at construction. Raptor and Compact No-Code are unaffected, and RaptorQ stays available outside the profile, which is what this branch offers it for. The end-to-end test that drives a real RaptorQ transfer over a socket was relying on the default profile, so it now asks for Profile::GeneralFlute explicitly. That is the correct description of what it exercises: a RaptorQ session is by definition not an MBMS Download Profile session. Verification T1: 96 cases pass, 3 new. ProfileFecSchemeTest covers refusal of RaptorQ under the profile, its acceptance outside it, and that Raptor is still accepted under the profile. The RaptorQ end-to-end case still passes and now says which profile it runs under. Not in this change Nothing on the receive side. A receiver decodes whatever scheme the FDT declares, which is correct regardless of profile: refusing to decode a scheme a sender chose would lose data for no gain.
jordijoangimenez
force-pushed
the
feature/raptorq-support
branch
from
August 23, 2026 14:34
59d12c7 to
e8adab8
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses part of #1.
Dependencies and issues
Depends on: #61, and is based on its branch; #61 in turn depends on #62. Merge order is #62, then
#61, then this one.
Paired with: #65, #68 and #98, independent of this one, either order.
Closes on merge: nothing on its own. Completes #1 together with #61. #1 needs closing by hand once both are in, since neither pull request delivers it alone.
What is in this pull request
Three commits, and the diff shows only those: this pull request is based on #61's branch, not on
development, so #62's and #61's work does not appear here.fec: reinstate RaptorQ as this branch's delta— RaptorQ alongside Raptor, sharing the same codecinterface, with its own scheme-specific OTI layout, which differs from Raptor's for the same values.
Its repair-symbol coverage is in this commit rather than a follow-up, for the reason given on RFC 5053 Raptor FEC scheme: codec, FLUTE integration, and the missing-symbol accessor #61.
examples: select the FDT schema, the FEC scheme and the redundancy level— adds-S,-Fand-Lto the example transmitter, which is how both schemes and the profiled schema were driven against a
real receiver.
Not mandated by 3GPP
TS 26.346 V18.2.0 clause L.4.7 names Compact No-Code and Raptor for the MBMS Download Profile. RaptorQ is
neither required nor forbidden there. It is not the default, and nothing in the profile path selects it.
Verification
T1: 110 cases passing. T2: an object received byte-identical over real multicast with
FEC-OTI-FEC-Encoding-ID="6", and recovered at a 7.6% datagram loss rate where Raptor's smaller defaultbudget does not.
Merge order
After #62, then #61.