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

["MATTY, Steven" <[e-mail]>]

 
Hi, 

I'm by no means an expert on Frequency Hopping radios, but I believe there are some solutions out there that could hop over multiple areas (i.e .segments)  of a frequency band and are not constrained to a single 'centred on frequency X with hopping bandwidth Y'.

Regards

Steve

-----Original Message-----
From: manet [mailto:[e-mail]] On Behalf Of Henning Rogge
Sent: Friday, March 18, 2022 12:08 PM
To: Justin Dean <[e-mail]>
Cc: [e-mail]; Velt, R. (Ronald) in 't <Ronald.intVelt=[e-mail]>
Subject: Re: [manet] Call for WG adoption of draft-rogge-manet-dlep-radio-band

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

_______________________________________________
manet mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/manet
This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Airbus Defence and Space Limited disclaims any and all liability if this email transmission was virus corrupted, altered or falsified.
-o-
Emails to Airbus Defence and Space Limited may be processed, recorded and monitored outside the UK.
-o-
Airbus Defence and Space Limited, Registered in England and Wales No. 2449259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England