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?
> 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.
Thanks,
Miquèl
