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. The future will show if there are any "special" requirements and how we could react here. > > 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. Thanks. - Alex
