[manet] Re: Review of draft-ietf-manet-dlep-radio-quality-02

On Mon, Oct 27, 2025 at 11:29 AM Velt, R. (Ronald) in 't
<[email protected]> wrote:
> > > Major
> > > -------
> > > Section 3: I have a problem with the Bit Error Rate DI being specified
> > > as mandatory, whereas the other DIs related to radio quality are made
> > optional.
> > > I know of radios ("modems") out there that will not be able to provide
> > > (through their current proprietary management interface, but
> > > presumably neither via DLEP, should they support that interface in
> > > future) a BER value (before FEC), but can provide a value for SNR/SINR
> > > and/or RSSI and/or Noise level. My suggestion would be to treat all
> > > four indicators of radio quality as equal. In fact, I would go so far
> > > as to allocate a separate DLEP Extension Type to each of them. This
> > > would allow a modem to signal during Session Initialization which types of
> > Radio Quality indication it supports.
> > > (It is not as if we would exhaust the Extension Type space any time soon).
> >
> > I talked about this a LOT with a few radio vendors...
> >
> > - First, I think we need to make one of the TLVs mandatory...
> > otherwise we could get into the situation where a radio supports the extension
> > but doesn't deliver anything. Yes, splitting the extension might also resolve this
> > issue.
>
> Different radio manufacturers appear to have different ideas about the radio parameters they can or are willing to make available across a management interface or via DLEP. It seems to me that having different extension types instead of one type with one mandatory Data Item and a few optional ones would be the most flexible solution.

Yes... main issue is that a lot of radio vendors don't like to export
anything...

> > - Second, I think your worry about SNR available but biterror-rate not is
> > overestimating the issues with biterror-rate. As far as I can tell for each
> > modulation-coding-scheme the radio vendor should have a curve (I SNR is
> > often called "E0/N0" in this diagrams) that maps biterror-rate of the channel
> > against SNR budget... these curves can be stored in the radio to easily
> > calculate the biterror-rate from the SNR.
>
> Such a mapping would be based on statistics and would not necessarily reflect the current BER at the time the Data Item is sent to the router, right?

Maybe that would be a solution, stating that it is 100% fine to
calculate the BER from SNR and modulation via (vendor-known)
E0/N-to-BER curves.

> > - third, I have met at least two radio vendors who considered the exact SNR
> > measured in the radio as "company secret", because it would provide details
> > about the receiver in the radio. In both cases they felt more "at easy" with
> > providing biterror-rate instead.
>
> In a strictly controlled test environment, providing the SNR might give away some implementation details, perhaps. Other radio manufacturers don't seem to be worried about this. (I know of at least one counter-example). Customers may even demand to have this information. Hence my remark on your first point about different views from different manufacturers and making the case for maximum flexibility.

There was also a fourth reason I forgot to mention... BER is easier to
compare between different radios than SNR (which is highly waveform
specific).

Henning Rogge

_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]