Re: Buffer length with K28.5 removed
Kevin,
See inline.
3/23/2016, 7:02 PM, Bross, Kevin kirjoitti:
All,
Thinking through the current expectations for the agnostic mapper, I
believe the expectation is that the K28.5 character used at the start
of the hyperframe would be excluded, right?
Nope. The current text regarding the agnostic mapper does not say that
and I never introduced the agnostic mapper in that way either. The K28.5
character would be included in the payload in its 8 bit representation
format.
Doing the math on the 9.8304 Gbps rate:
* Hyperframe is every 10 ms = 0.01 seconds
* 9,830,400,000 bits per second * 0.01 seconds = 98,304,000 bits per HFN
* At 10 bits per symbol, this comes out to 9,830,400 symbols =
9,830,400 bytes
* This could 24,576 packets of even 400-byte payloads, for
example—or 19,200 packets of even 512-byte payloads—or (several
other even payload sizes)
* If we remove the K28.5 symbol, we’re left with 9,830,399 bytes of data
* The only reasonable packet-length divisors of 9,830,399 are 311
and 433; other CPRI rates may have similarly odd divisors
Several concerns:
1. This limits evenly-sized payloads if the sequence number has to
increment at the start of each hyperframe and the K28.5 character
is omitted.
1. Incrementing the sequence number based on a particular K-character
belies the “agnostic” nature of this mapper.
1. If there was anything that went further and expected the q portion
of the sequence to match a BFN, that would further make this a
CPRI-specific implementation.
Currently the working assumption is "structure agnostic CPRI mapper".
3. Not supporting any K-characters other than K28.5 is also pretty
CPRI-specific assumption as well.
Agree.
Alternative proposal:
1. Like we discussed last October at the FTF, we could keep any
special K-characters in the payload, provided we do the following:
1. Use the 8-bit representation for that K-character so that we can
distinguish between multiple K-characters
To my understanding this is the expected behaviour of the current
"structure agnostic CPRI mapper".
1. Add a field at the beginning of the payload (2 bytes) to indicate
the location of the K-character (this would be <0.5% efficiency
impact to 400-byte payloads and less for larger payloads)
Okay.. we are coming back to use cases where the "extended header" would
actually have been useful..
1. This assumes the K-characters are spaced out enough that there is
no more than 1 K-character per packet
2. This proposal allows implementations to use any payload size
(fixed or variable) and would preserve the location of the K-character
3. This proposal does not require the agnostic mode to understand any
CPRI-specific packet meanings
4. This proposal does not require the agnostic mode to start or stop
the payload based on any symbol received in the data stream—it is
truly agnostic
I like the idea of "proper agnostic" behaviour. On the other hand I am
really not happy to tear the existing format apart again. I need to
think this a bit more.
- Jouni
Thoughts?
--kb