Re: LDPC encoding problem

[Ed Criscuolo]

In a "pure" layered system, the physical layer just transports a stream 
of bits. It knows nothing of the framing or packetization of the upper 
layers (Link, Transport, etc).  It is the job of those upper layers to 
find and align to whatever frame sync or packet header they are using 
(Rx), as well as provide any idle padding that may be necessary (Tx).

The beauty of this system is that it makes it easy to swap out one 
layer's protocol for another without affecting the other layers. The 
downside is that it makes the job of the upper layers harder.

However, to be fair, real-world systems often "cheat" in order to make 
the upper layer's job easier, and save a few header bits.  A prime 
example of this is the CCSDS suite of protocols, which has the physical 
layer's error-correcting-code frame sync word do double duty as the link 
layer's frame sync mark.  But, as you've found, coupling between layers 
complicates the framing structures, requiring either constraints on the 
upper layer's frame sizes, or additional work to handle splitting and 
reassembling link frames across multiple physical ECC frames, as well as 
padding short link frames. Error handling and recovery also becomes more 
complicated.  IN MY OPINION (others disagree),  these downsides more 
than make up for any gains.

So, to summarize, your link layer should have its own independent
framing and sync mechanism, and the interface between it and the 
physical layer should just be a stream of bits.

@(^.^)@  Ed



On 12/8/21 7:51 AM, ???????? via GNU Radio, the Free & Open-Source 
Toolkit for Software Radio wrote:
> Hi,
> I created a flow graph as shown in the attachment. It was modified based
> on gr-digital/examples/ofdm_tx.grc. I added LDPC encoding for error
> correction, but I have some problems. There are two places where data is
> lost.
> 1. If the length of my sent data is 822 bits, LDPC codeword n=8, k=4,
> rate=1/2 but 822%4=2, the remaining two bits will not be processed,
> which will cause My data cannot be sent completely
> 2. Because my label "packet_len"=100, therefore, the encoded data
> 820*2=1640, 1640/8=205, 205% 100=5, after going through "repack bits"
> with the label "packet_len"=100 The remaining data after the module is
> (205-5)=200 (of course multiply by 4)
> So there are two places that will cause the data to not be completely
> sent. I can think of zero padding to solve this problem, but how does
> the receiving end know how many 0s I have added (unless it knows what to
> send)?
> I mean how is this problem solved in an actual communication system?
> Maybe there is a higher-level agreement? After all, what I am doing here
> is only the function of the physical layer. Does the physical layer
> ignore these issues?
> Or is this just a problem with GNURadio?
> Best Regards,
> linge93