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

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Fri, 11 Mar 2022 09:12:11 +0000

MANET WG participants,

This is the announcement of a WG adoption call for draft-rogge-manet-dlep-radio-band, starting today and running for two weeks, i.e. until the end of IETF-113. Please express your support for or objections to the adoption of this draft as a WG document by means of a post to the MANET WG mailing list. (Please do not remain silent). Comments and questions are of course very welcome.

Thanks,
Don & Ron(ald)
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 16 Mar 2022 09:25:47 +0100

I would really like to hear about ANY opinion on the "frequency
hopping" matter... Does an optional additional "frequency range" value
resolve this for most people?

If the group thinks "yes", I can create and upload an additional
revision of my draft.

Henning

On Fri, Mar 11, 2022 at 10:12 AM Velt, R. (Ronald) in 't
<Ronald.intVelt=[email-masked]> wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Justin Dean <[email-masked]>
Date: Wed, 16 Mar 2022 12:47:28 -0400

A few comments since you asked so nicely.  This isn't my direct area of
expertise so take them with a grain of salt.

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.

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".

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.

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

Can these cases be handled by this extension or not?

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"

(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

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.

   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?

If my assumption is wrong then clarity of static or not would be appropriate.

On Wed, Mar 16, 2022 at 4:28 AM Henning Rogge <[email-masked]> wrote:

> > This is the announcement of a WG adoption call for
> draft-rogge-manet-dlep-radio-band, starting today and running for two
> weeks, i.e. until the end of IETF-113. Please express your support for or
> objections to the adoption of this draft as a WG document by means of a
> post to the MANET WG mailing list. (Please do not remain silent). Comments
> and questions are of course very welcome.
> >
> >
> >
> > Thanks,
> >
> > Don & Ron(ald)
> >
> >
> >
> > This message may contain information that is not intended for you. If
> you are not the addressee or if this message was sent to you by mistake,
> you are requested to inform the sender and delete the message. TNO accepts
> no liability for the content of this e-mail, for the manner in which you
> use it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
> >

---

From: Henning Rogge <[email-masked]>
Date: Fri, 18 Mar 2022 13:08:13 +0100

On Wed, Mar 16, 2022 at 5:47 PM Justin Dean <[email-masked]> 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.
>

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)

> 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

> 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.

> 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.

> 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

---

From: "MATTY, Steven" <[email-masked]>
Date: Mon, 21 Mar 2022 08:19:14 +0000

&nbsp;
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:[email-masked]] On Behalf Of Henning Rogge
Sent: Friday, March 18, 2022 12:08 PM
To: Justin Dean <[email-masked]>
Cc: [email-masked]; Velt, R. (Ronald) in 't <Ronald.intVelt=[email-masked]>
Subject: Re: [manet] Call for WG adoption of draft-rogge-manet-dlep-radio-band

Thank you...

"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 B…

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.

> 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]).

> 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.

> 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.

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.

> 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
[email-masked]
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

---

From: Henning Rogge <[email-masked]>
Date: Mon, 21 Mar 2022 09:56:53 +0100

especially when it comes to frequency hopping we will never get all
usecases... unless we just enumerate all used center frequencies...
while their sequence might be random, the enumeration should be
limited.

Which leads me to another problem I found over the weekend...

some of the TLVs in the other Drafts could be easily frequency-band
specific... HMM...

Henning

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Mon, 21 Mar 2022 09:14:38 +0000

Hi,

> From: Henning Rogge <[email-masked]>
> Sent: maandag 21 maart 2022 09:57
> To: MATTY, Steven <[email-masked]>
> Cc: Justin Dean <[email-masked]>; [email-masked]; Velt, R. (Ronald)
> in 't <[email-masked]>
> while their sequence might be random, the enumeration should be limited.

Which is why I proposed to have a simple flag to indicate whether the (single) frequency field in the Data Item contains valid information or not. Or maybe we need subTLVs 😊

> some of the TLVs in the other Drafts could be easily frequency-band

Yes, that could be the case.

Ronald

> > 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
> >
> 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.
> >
> > "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".
> >
> > > 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.
> >
> > >
> > 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).
> >
> > 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]).
> >
> > 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.
> >
> electromagnetic spectrum for the same data-rate (measured in bit/s/Hz), so
> it is more spectral efficient.
> >
> frequency/bandwidth... but the ones that do could allow these modification
> over DLEP.
> >
> > Henning Rogge
> >
> > 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-
> > Airbus Defence and Space Limited, Registered in England and Wales No.
> > 2449259 Registered Office: Gunnels Wood Road, Stevenage,
> > Hertfordshire, SG1 2AS, England
> >

---

From: Henning Rogge <[email-masked]>
Date: Mon, 21 Mar 2022 15:36:50 +0100

> Which is why I proposed to have a simple flag to indicate whether the (single) frequency field in the Data Item contains valid information or not. Or maybe we need subTLVs 😊

I am not really a fan of subtlvs, they make a parser a mess...

and "some information" about the frequency being used is better than
"no information" at all.

> Yes, that could be the case.

so we either need a way to "attach" different TLVs talking about the
same channel with each other... or need subtlvs... or something
else... **sigh**

Henning Rogge