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?
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:
- 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.
- Incrementing the sequence number based on a particular K-character belies the “agnostic” nature of this mapper.
- 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.
- Not supporting any K-characters other than K28.5 is also pretty CPRI-specific assumption as well.
Alternative proposal:
- Like we discussed last October at the FTF, we could keep any special K-characters in the payload, provided we do the following:
- Use the 8-bit representation for that K-character so that we can distinguish between multiple K-characters
- 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)
- This assumes the K-characters are spaced out enough that there is no more than 1 K-character per packet
- This proposal allows implementations to use any payload size (fixed or variable) and would preserve the location of the K-character
- This proposal does not require the agnostic mode to understand any CPRI-specific packet meanings
- 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
Thoughts?
--kb