Hi Alexander, aahringo@xxxxxxxxxx wrote on Sun, 6 Nov 2022 20:30:48 -0500: > Hi, > > On Fri, Nov 4, 2022 at 2:17 PM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > > > Hi Alexander, > > > > aahringo@xxxxxxxxxx wrote on Thu, 3 Nov 2022 20:55:38 -0400: > > > > > Hi, > > > > > > On Wed, Nov 2, 2022 at 10:52 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > > > > > > > Hi Alexander, > > > > > > > > aahringo@xxxxxxxxxx wrote on Sun, 30 Oct 2022 22:20:03 -0400: > > > > > > > > > Hi, > > > > > > > > > > On Wed, Oct 26, 2022 at 5:35 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > > > > > > > > > > > Hello, > > > > > > These three patches allow the creation of coordinator interfaces, which > > > > > > were already defined without being usable. The idea behind is to use > > > > > > them advertizing PANs through the beaconing feature. > > > > > > > > > > > > > > > > I still don't know how exactly those "leaves" and "non-leaves" are > > > > > acting here regarding the coordinator interfaces. If this is just a > > > > > bit here to set in the interface I am fine with it. But yea, > > > > > "relaying" feature is a project on its own, as we said previously. > > > > > > > > > > Another mail I was asking myself what a node interface is then, > > > > > currently it is a mesh interface with none of those 802.15.4 PAN > > > > > management functionality? > > > > > > > > Not "none", because I would expect a NODE to be able to perform minimal > > > > management operations, such as: > > > > - scanning > > > > - requesting an association > > > > But in no case it is supposed to: > > > > - send beacons > > > > - manage associations > > > > - be the PAN coordinator > > > > - act as a relay > > > > > > > > > > perfect, thanks. But still there is something which I don't get. > > > > > > The split you mentioned about the functionality is for me being a > > > coordinator (IEEE spec) or pan coordinator (IEEE spec) which has the > > > additional functionality of "send beacons, manage assocs, act as > > > relay". > > > > I would expect any coordinator (IEEE spec) to be able to send beacons > > and relay (but in this case it only makes sense to send beacons if > > relaying is supported, IMHO). > > > > The PAN coordinator (IEEE spec) only has the following additional > > capability: managing assocs within the PAN. But in practice it is very > > likely that it is the one with the greater computational resources and > > the highest networking capabilities (it is usually the one which acts > > as a bridge with eg. the internet, says the spec). > > > > > So a coordinator (iftype) is a pan coordinator (IEEE spec) and a node > > > (iftype) is a coordinator (IEEE spec), but _only_ when it's > > > associated, before it is just a manually setup mesh node? > > > > Mmmh, actually this is not how I see it. My current mental model: > > - COORD (iftype) may act as: > > * a leaf device (associating with the PAN coordinator, sending data) > > * a coordinator (like above + beaconing and relaying) once associated > > * a PAN coordinator (like above + assoc management) if the device > > started the PAN or after a PAN coordinator handover. > > Note: physically, it can only be authorized on FFD. > > - NODE (iftype) may only be a leaf device no matter its association > > status, this is typically a sensor that sends data. > > Note: can be authorized on any type of device (FFD or RFD). > > > > If I understand correctly, your idea was to change the interface type > > depending of the role of the device within the network. But IMHO the > > interface type should only be picked up once for all in the lifetime of > > the device. Of course we can switch from one to another by quickly > > turning off and on again the device, but this is not a common use case. > > We must keep in mind that PAN coordinator handover may happen, which > > means the interface must stay on but stop acting as the PAN > > coordinator. Using two different interface types for that is not > > impossible, but does not seem relevant to me. > > > > Would you agree? > > > > Okay, I think that if you have a node then you never want to act as > any PAN coordinators functionality. And yes it seems complicated to > switch such functionality during runtime. I am fine with that. Great! > The > future will show if there are any "special" requirements and how we > could react here. Agreed. > > > I hope it's clear when meaning iftype and when meaning IEEE spec, but > > > for the manual setup thing (node iftype) there is no IEEE spec, > > > although it is legal to do it in my opinion. > > > > It's clear, no problem. In my previous e-mails, when talking about the > > interfaces I used the uppercase NODE and COORD keywords, while I used > > the plain english lowercase "[leaf] node", "coordinator" or "PAN > > coordinator" words when talking about the IEEE definitions. > > > > That is great, we should use those terms to make the difference. Ok, I'll do! Thanks, Miquèl
