| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Jouni, On this point of the sequence number, Timestamps and SOF bit, we have actually been looking at a slightly different solution here so let me throw that into the mix for the discussion. As we see it, the current proposal has one overwhelming issue which is that the SOF bit says nothing about where in the packet this frame boundary is placed so as it is now, the frame and packets must be aligned. I think this would seriously reduce the flexibility of the protocol and also create a link between traffic management on the Ethernet layer and this protocol which seems like an unnecessary complication. So with this in mind, we went about trying to find some better way of using these fields. I have attached a word document which summarizes the relevant parts of the spec as it is now and how we would prefer to do it. Our solution actually questions the need for a start bit but it does also make a few assumptions and pose some other questions which we would love some comments to as well. 1. Why not just define sequence numbers in such a way that they always wrap around at a frame boundary (Could be N*Frames) thereby making the start of frame bit redundant? This is already the approach taken in the 2 mappers defined so far. 2. The way sequence numbers are defined right now would make it impossible for us to recover from a loss until the next SOF since there is no definition that every packet must be of the same size. We could therefore impossibly know the alignment of all subsequent packets. 3. In the case of using timestamps and there being TOD on the RRH, do we even need to transmit a SOF? Surely the Air Frame is a derivative of Time of Day in the first place so couldn't we just send information about how the Air Frame is aligned to TOD? Best regards Yasser Kilde Bajwa IP Core Product Manager MTI Mobile An MTI Company Krakasvej 17, 3400 Hilleroed, Denmark T: +886 908161200 E: Yasser.Bajwa@xxxxxxxxxxxx W: www.mti-mobile.com / www.mtigroup.com -----Original Message----- From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx] On Behalf Of Jouni Korhonen Sent: 10. oktober 2015 09:27 To: stds-1904-3-tf@xxxxxxxx Subject: Alternating timestamp and sequence number Folks, Another detail that we have discussed at some point of time but never put text down. The case when one wants to use both timestamps and sequence numbers with the same flow. That deserves some guidance IMHO. For example, how will an occasional timestamp affect sequence number counting? What I intend to write text about is to combine the use of S-flag with occasional timestamps. That fits to cases where one needs to send the timestamp seldom like every 10ms (LTE radio frame timing example). So at the start of each 10ms radio frame send timestamp (if so needed) with set S-flag and other times use just sequence number. The receiver & sender know that the combination of timestamp and S-flag equals the next sequence number that would be the start of frame packet sequence number. Obviously this fits only to few cases but at least clarifies those.. - Jouni -- Jouni Korhonen, CTO Office, Networking, Broadcom Corporation O: +1-408-922-8135, M: +1-408-391-7160 === MICROELECTRONICS TECHNOLOGY INC. === This message (and any attachments) may contain information that is confidential, proprietary, privileged or otherwise protected by law. The message is intended solely for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please destroy the message or delete it from your system immediately and notify the sender.
Attachment:
1904_SequenceNumber_proposal.docx
Description: 1904_SequenceNumber_proposal.docx