Flexible, jitter resistant voting system (16-Jan-2010)
Provide mechanism for adaptable jitter compensation buffering: Every payload packet sent from CM to the BR would contain additionally timestamp in the form of 4 byte integer value carrying millisecond time at the time packet is sent. For broadcasted voice/data every LDU/PDU would contain such information embedded with the payload when there is no payload sent on the channel then keep alive messages (sent using multicast to keep data consistent) would be used for such purpose BR when receiving such packet will compare timestamp value in the incoming packet (independent on the SS num) with the current time which should be synchronized to the sender?s time. Computed time difference represents time packet was traveling in the network. BR will compute mean value of the last ?n? (say 20) values and will do analysis providing minimum and maximum values of such. That analysis could include for example removing values that are errors (for example negative travel time or values that are just measurement errors of any kind). BR will compare computed statistic with already established data. When it is sending uplink data then to each xDU it is attached additional information carrying computed statistical values (like mean, maximum and minimum value). Packets are also carrying timestamp of the arrival of the data to the BR over the air (wave front timestamp) that will be used in the recipient to detect current uplink delay and jitter and self assign to the voting window. When it is not sending uplink data and statistical data are stable then computed statistical value are sent together with link keep alive packets. Such packets will carry also current timestamp that would be used to control uplink delay and jitter at the time when there is no uplink transmission. When the BR will notice that with the current trend of change in the delay or jitter, system could go out of operation (or start loosing frames) BR would send information to the CM immediately (for example as stand alone message). CM would receive BR sent statistical information about timing and would use such data to compute optimal delay / buffering that would be enough to compensate of the jitter/delay in the transmission path. Such information would be permanently stored in CM so after restart system could not loose computed data.
INFORMATION SHEET
FOR DEFENSIVE PUBLICATION
Date: 19 November 2009
Title: Flexible, jitter resistant voting system
Docket No.: CM13220 (59902)
Author #1
Name: Waldemar Dworakowski
12072235
Author #2
Name: Przemysław Kryger
12065533
Author #3
Name: Robert Mrowiec
12030039
Measurement of transmission delay and jitter in multicast, asymmetric and multipath networks using precise time of the transmission and synchronized time of reception as a mean to provide more robust voting and simulcast system
By Waldemar Dworakowski, Przemysław Kryger, Robert Mrowiec
Motorola, Inc.
GP&S Business
ABSTRACT
Paper describes means that could improve resilience to variable transmission delay time and jitter in signal delivery over flexible, asymmetric, multicast, multipath networks when delivering payload requiring near just-in-time delivery. Such payload is for example VoIP, TVoIP or measurements / process control data. Paper shows how using modified protocols that use embedded transmission time and synchronized components we could do time delay measurements. When such measurement is communicated to the transmitter we cam build in real time optimally sized buffers with minimal overhead both on the protocol and on the transmitter and receiver.
PROBLEM
In real live communication systems where ‘on-time-delivery’ of the payload is required there is manifesting a need for proper buffering to cover jitter and delays in the transmission path. As current networks migrate from previously used ‘point-to-point’ paradigm to ‘point to cloud’ approach we have to understand how this change is modifying network behavior. Longer, more time dependent delivery time with wider jitter is usually expected in this situation. To make situation worse as the load on such network is getting higher delays expected are also getting higher what makes difficult to ‘tune’ buffering when system is initially set up. Other factor which we must take into account is that payload delivery mechanism is usually different then used for most common measurement in network measurements. Also we must take into account that network is usually asymmetrical in such configurations – both as it comes to the delays per direction and load in each direction.
SOLUTION
Presented idea is to use...
Find More Documents Like This
Download this Disclosure
Click here if you want to sign-in now.
