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

"Velt, R. (Ronald) in 't" <Ronald.intVelt@tno.nl> Mon, 21 March 2022 09:14 UTC

Return-Path: <Ronald.intVelt@tno.nl>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789503A191C for <manet@ietfa.amsl.com>; Mon, 21 Mar 2022 02:14:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tno.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6syDQ2u9G0dz for <manet@ietfa.amsl.com>; Mon, 21 Mar 2022 02:14:42 -0700 (PDT)
Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780633A191A for <manet@ietf.org>; Mon, 21 Mar 2022 02:14:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tno.nl; l=12728; s=mta1; t=1647854082; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=Co4bRZsxqwpAt25s27Ob4YUkJYJlJBmJZOgaMK2RGvA=; b=jcDO3CVCrjAHjxxc6GM9zP9WWrWlQPcMolOSdcbG+hf3ai4kWmRFrWOm OOwVc1zY23hZMSysffeItwfiwt1pnFQgPdFbfGXU9PkLKcTguFBcPhT0q HGQaj5bqimSjyz5z9Z0WZra7Kb4pdmdaR4CnAqTODGvj77EQuFUyP63/K w=;
X-IronPort-AV: E=Sophos;i="5.90,198,1643670000"; d="scan'208";a="46823112"
Received: from UCP13.tsn.tno.nl (134.221.225.173) by UCP13.tsn.tno.nl (134.221.225.173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 21 Mar 2022 10:14:38 +0100
Received: from UCP13.tsn.tno.nl ([fe80::c142:976e:5281:8298]) by UCP13.tsn.tno.nl ([fe80::c142:976e:5281:8298%7]) with mapi id 15.01.2375.024; Mon, 21 Mar 2022 10:14:38 +0100
From: "Velt, R. (Ronald) in 't" <Ronald.intVelt@tno.nl>
To: Henning Rogge <hrogge@gmail.com>, "MATTY, Steven" <steven.matty@airbus.com>
CC: Justin Dean <bebemaster@gmail.com>, "manet@ietf.org" <manet@ietf.org>
Thread-Topic: [manet] Call for WG adoption of draft-rogge-manet-dlep-radio-band
Thread-Index: Adg1Jkhx/9waTkVqS4O+Q+DldD38nAD4MWSAABGFZgAAWtSEgACQ9Rzw///54ID//+u2cA==
Date: Mon, 21 Mar 2022 09:14:38 +0000
Message-ID: <96ce3cdf48354a53a6f60e345f585c3e@tno.nl>
References: <a5d13a83214e441ead6fe08f5d923291@tno.nl> <CAGnRvuqOT2+k+Jbdz77pxOeNhgM77v_EApSTMHFyy6gUBtiQsQ@mail.gmail.com> <CA+-pDCfXHN8NLofP-YqRe9TC9Ht791=_QRCr1BYSqUi_NrCDqA@mail.gmail.com> <CAGnRvuo9EU99t+NNkge+y6Q66ZV72Nh3-UbCm7RLAa0+oYffZA@mail.gmail.com> <d75d42be248d46c28b4581c08f538706@CD1-4DDAG05-P01.cdmail.common.airbusds.corp> <CAGnRvurnKFR+y2TVmeU0D5bO-sibBL1gVrAXYthFy9YXZgnnHg@mail.gmail.com>
In-Reply-To: <CAGnRvurnKFR+y2TVmeU0D5bO-sibBL1gVrAXYthFy9YXZgnnHg@mail.gmail.com>
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.221.225.191]
x-esetresult: clean, is OK
x-esetid: 37303A29B933ED536D7D6B
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/LMcLk9aBKxqsNkkQxvTRcQLrX_w>
Subject: Re: [manet] Call for WG adoption of draft-rogge-manet-dlep-radio-band
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Mar 2022 09:14:49 -0000

Hi,

> -----Original Message-----
> From: Henning Rogge <hrogge@gmail.com>
> Sent: maandag 21 maart 2022 09:57
> To: MATTY, Steven <steven.matty@airbus.com>
> Cc: Justin Dean <bebemaster@gmail.com>; manet@ietf.org; Velt, R. (Ronald)
> in 't <Ronald.intVelt@tno.nl>
> Subject: Re: [manet] Call for WG adoption of draft-rogge-manet-dlep-radio-
> band
> 
> 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 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 😊

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

Yes, that could be the case.

Ronald


> 
> Henning
> 
> On Mon, Mar 21, 2022 at 9:19 AM MATTY, Steven
> <steven.matty@airbus.com> wrote:
> >
> > &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:manet-bounces@ietf.org] On Behalf Of Henning
> Rogge
> > Sent: Friday, March 18, 2022 12:08 PM
> > To: Justin Dean <bebemaster@gmail.com>
> > Cc: manet@ietf.org; Velt, R. (Ronald) in 't
> > <Ronald.intVelt=40tno.nl@dmarc.ietf.org>
> > 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 <bebemaster@gmail.com>
> 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
> > manet@ietf.org
> > 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
> >
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.