Project

General

Profile

Actions

Feature #5437

open

brainstorm about making protocol even more efficient

Added by laforge about 2 years ago. Updated about 2 years ago.

Status:
New
Priority:
Low
Assignee:
Category:
protocol-spec
Target version:
-
Start date:
01/30/2022
Due date:
% Done:

0%


Description

Right now in the PoC protocol of laforge/e1oip we still send something in the order of 8000/(32..40) = 200 .. 250 UDP packets per second even if there are no active timeslots at all.

This really only serves the following purpose:
  • theoretical ability for a receiver without GPS-DO (client) to re-construct timing based on the averaged recorvered packet timing
  • ability of receiver to quickly detect lost frames (network problems or the like)
  • keep-alive of any NAT mapping/bindings

But at least in the current icE1usb hardware with GPS-DO, timing recovery is not really needed. And whether or not it is required to detect outages as fast as 50ms after they happen is somewhat disputable.

So why not introduce a mode in which we suppress idle packet transmission even further? For example, if we went down into a "1 PPS" mode during periods of quiescence, we would drastically reduce the network load / bandwith use, while still providing the peer to determine the alive-status of the network connection. Basically something like DTX (discontinuous transmission) in GSM, where transmissions are reduced to the SACCH only, if no [voice] activity is detected.

Any kind of alarms (TS0 processing) could of course trigger instantaneous transmission of packets.

Am I missing something here?

Actions #1

Updated by laforge about 2 years ago

The current 16bit timestamp covers more than 8s, so the 1PPS would still allow proper counting of frames and start to re-insert them at the right frame number.

In order to cover longer (accidential, not intentional) outages without loosing alignment, we could introduce an optional IE containing a longer (32bit == 149 hours) sequence number which could be added by the sender e.g. every time the 16bit number wraps. But the question is whether or not that matters at all...

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)