@kitz
Those numbers started to do my head in! I couldn't work out how they could manage B=0 ... because that would imply that the entire frame was overhead.
If I try to read them logically, it seems to be saying
B=0 -> zero bytes in MUX data frame
M=2 -> two MUX data frames in RS codeword
R=16 -> sixteen bytes of parity overhead in RS codeword
N=32 -> thirty two bytes in an RS codeword
Would this be
a) N = R + (M*B)
or
b) N = M * (R+B)
Using the English language, I'd assume (a) was more correct. But (b) appears to pan out in real use. I guess these framing parameters are from Bearer 1. Perhaps the rules are slightly different there.
But back in bearer 0, with N=B+R+1, I couldn't honestly figure out why the "+1" should be there.
More thinking needed. I suspect I'll feel the need to dig out the spec again. I recall from last time that G.INP tied the base VDSL2 spec down to using more limited framing options.
Although I have this information listed on the linestat errors page, because of the alphabetical layout, it perhaps doesnt make it quite so clear the relationship between those particular figures.
On reflection and after seeing wombats post, it may be a good idea for me to also add this on the interleaving page, where its not lost amongst other things like LoF or LoS.
I can see that it would be useful to see that relationship, at least for those wanting to dive into the depths.
@ wombat - Yes those other stats were g.inp bearer 1.
I attempted to do a little bit of digging last night, at first I was wading through some very heavy documentation that had lots of horrible equations that didn't quite seem relevant to the info we wanted. TBH some of them made my head hurt & my eyes blur, so I packed in.
I started to do a break down summary of what we knew and then I stumbled across a much more reader friendly power point presentation by Tim Clark of the VDSL consortium. A copy can be downloaded
here. Ive not finished digesting all the info in that ppt yet but thought I'd post how far Ive got with my summary.
Reed Solomon ParametersMSGc = Number of bytes in overhead channel message
K = Number of bytes in the DMT Frame
B = Number of bytes in the data frame
N = NFEC = Length of codeword (N = K + R)
R = RFEC = RS check bytes / Amount of redundancy
S = Symbols per codeword
T = Number of dataframes in an OH subframe/ Data frames over sync bytes
Q = Number of RS codewords per DTU (g.inp)
V = Number of padding octets per DTU (g.inp)
Interleaving ParametersI = Number of Interleaver branches / The interleaver block size in bytes. Should be a sub-multiple of N
M = Incremental delay / Number of Mux Data Frames in FEC Data Frame/RScodeword
D = Interleave Depth (D = M * I + 1)
L = LSYMB = Number of bits per symbol in the latency path / Number of bits in PMD data frame
Interleaving introduces a delay of M * I * (I-1)
Actual delay - ADSL shown in ms = [S x D]/4
Actual delay - If retransmission is used this specifies the actual value of the time independent component of the delay due to retransmission only.
Statements & snippetsT-REC G.998.4 Section 9.2 FEC
The interleaving used on Latency path #1 shall be a block interleaving. The interleaving block shall have a size of D1 × NFEC bytes, with NFEC being the length of the RS codeword, and D1 being the interleaving depth. If D1=1, then an interleaving block equals an RS codeword. If D1=Q (the number of RS codewords per DTU) then an interleaving block equals a DTU. Each byte Bk within an interleaving block (input at position k, with index k in the interval 0 to D1 × NFEC – 1) shall be located at the output of the interleaving function at position l given by l = i × D1 + j, where i = k MOD NFEC and j = floor(k / NFEC).
VDSL MCM SimulationNote the relevant equations:-
N = K + R
D = M * I + 1
delay = M * I * (I-1)
We dont have a K value, but it does at face value appear it could to be related to B?
