Re: [manet] Call for WG adoption of draft-rogge-manet-dlep-radio-band

[Henning Rogge <[e-mail]>]

On Wed, Mar 16, 2022 at 5:47 PM Justin Dean <[e-mail]> wrote:
>
> A few comments since you asked so nicely.  This isn't my direct area of expertise so take them with a grain of salt.

Thank you...

> An optional "width" field would add to usefulness.  Although if included it should specify some known threshold like 20 or 50% of max usage.  (not my area so whatever is most useful to those who do know).  Optionally if we all don't know then have a field which includes what that width indicates in terms of max power.

I am not sure what you mean with the threshold value I must admit...

the idea of the "width" field is a semantics like this:

"Center 300 MHz, Bandwidth 100 kHz, Hoping-Bandwidth 2 MHz" means "the
radio uses a frequency channel that is 100 kHz width. Its center
frequency is changing within an interval 1 MHz wide around 300 MHz,
which means it can be between 299 MHz and 301 MHz".

This allows the router to judge the "used frequencies" of the radio,
despite an (unknown) random hopping pattern.

> The introduction is a bit light.  I would like it to contain a little bit about what the problem/issue is that this draft attempts to address.  Some of that information is contained in the "Radio Band Data Item" section.  The draft is short and to the point (as much as an RFC can be) but is lacking a bit on details for my liking, specifically there are a few too many "can" and "usually" without explanations of "how" and "if otherwise".

Yes, I hope feedback like this can point out the places where I need
to improve it. It's often difficult to see the gaps in your own
explanation, because you have the "full picture" in mind.

>
> Just going to include the "Radio Band Data Item" section and comment inline below.
>
> Radio Band Data Item contains information which radio frequency
>    resources are being used.  These values are usually interface
>    specific and static during the DLEP session.
>
> JWD: this deserves to be separated out and explained upon a little bit.

Most radios have ONE configured frequency and bandwidth which never
changes and is used for all users (e.g. Wifi)

> What happens if they are not static or not interface specific?

A "non-interface specific" might be something like LTE or "subcarrier
Wifi 6"... a radio that allocates a part of its frequency bandwidth to
a single user.

Non-static would mean that the radio was reconfigured and the values
are now different. It's not typical for consumer-tech like Wifi,
because changes like this must be synchronized with the other radios
(otherwise you lose contact).

> Can these cases be handled by this extension or not?

Yes, the TLV can easily be used in Session-Update (for changed
interface wide configuration) or in Destination-Up/Update messages
(for user specific subcarriers).

I think we should specify that a destination-specific TLV should
always be within the interface specific TLV's range (the interval of
[center-bandwidth/2, center+bandwidth/2]).

> If yes then how? If not then it needs to be said. (and possibly discussed in the WG)

>    The Radio Band Data Item can be used multiple times to represent
>    multiple radio bands.
>
> JWD: Is there a limit?  (assuming no) What happens if the information contained is "similar"

Maybe we should add that there should be one TLV for each independent
transmitter/receiver that can choose its own frequency range.

Normal Wifi would announce one or two of these TLVs (depending on if
its dual-band or not), LTE would have one for its "upstream" frequency
range and one for its "downstream" one.

> (off by one Hz for example) but not the same frequency.  Should that be disallowed? If changes do occur does

> an update suffice or does a new dlep session need to happen?
>
>    The Item can be used in a neighbor specific message if the radio use
>    dedicated subcarriers to talk to neighbors.
>
> JWD: Assuming this is only regarding outgoing messages to the neighbor in question and not any freq

also incoming messages. A radio receiver must know the
frequency/bandwidth to listen on to incoming signals, so the radio can
announce this.

> that may be used in the reverse direction.
>
>    The information in this Item gives the router an easy way to
>    calculate the spectral efficiency of a radio link, how much bandwidth
>    is used for the current data-rate reported by DLEP.  This can be
>    integrated into the routing metric to focus traffic on links that use
>    the spectrum efficiently.
>
> JWD: Not my area of expertise, I'd find a simple example to be informative.

Simple example..

Radio 1 announces 1 MBit/s data-rate and a bandwidth of 20 MHz, Radio
two announces 1 MBit/s data-rate and a bandwidth of 100 MHz.

While both radios offer the same speed, the first one uses up less
electromagnetic spectrum for the same data-rate (measured in
bit/s/Hz), so it is more spectral efficient.

>    The Item can also be used as an interface to a cognitive radio
>    controller on the router, analyzing the correlation of transmission
>    disruptions with the frequency bands and could (together with the
>    Request Link Characteristics message) be used to change the frequency
>    of the radio in a standardized way.
>
> JWD: How would the change of frequency work with the assumption that it's static over a dlep session?

Most radios might not allow dynamic reconfiguration of
frequency/bandwidth... but the ones that do could allow these
modification over DLEP.

Henning Rogge