Hi Michel,
Yes, I agree with you.
Thanks!
Anand
On Tue, 9 Jun 2015, Michel Veillette wrote:
Hi Anand
About "Does it make sense to use the BEACON IE approach when the node joins the
network and let an external centralized controller (NME), use the 6top MIB interface to
subsequently manage the phyTXPower ?"
Sound good to me.
The value received during the joining process in a beacon IE is more about not
exceeding the output power allowed by the local regulation. This feature
probably make more sense for IEEE 802.15.4g which support multiple RF bands
with lot of regional variations for the allowed maximum output power. This is
certainly also applicable for the different bands supported by IEEE
802.15.4-2011 (868-868.6 MHz, 902-928 MHz and 2400-2483.5 MHz bands).
The configuration of the phyTXPower after joining is more about performance
optimization (e.g. enable better spatial re-use).
[cid:image001.jpg@01C868D8.BF0BB7E0]
Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
michel.veille...@trilliantinc.com<mailto:michel.veille...@trilliantinc.com>
www.trilliantinc.com<http://www.trilliantinc.com/>
From: S.V.R.Anand [mailto:an...@ece.iisc.ernet.in]
Sent: 9 juin 2015 03:03
To: Michel Veillette; Qin Wang; Kris Pister
Cc: 6tisch@ietf.org
Subject: Re: [6tisch] 6top and transmit power control
Hi Michel,
The idea is very interesting since the nodes are provisioned with the right
value upfront via BEACON IE so that they start using the power that is
appropriate, as determined by the PAN coordinator. In the absence of this, the
nodes might start-off with arbitrary power levels that can potentially result
in unpredictable network behaviour for the existing flows. I would assume, the
coordinator will have an ability to manage these power levels by
re-provisioning them depending on the state of the network in a way that the
hidden and exposed node problems are avoided.
One more thought. Does it make sense to use the BEACON IE approach when the
node joins the network and let an external centralized controller (NME), use
the 6top MIB interface to subsequently manage the phyTXPower ? The assumption
is that the interface provides the output power limit of the node as well.
Am I missing something here ?
Anand
On Monday 08 June 2015 09:03 PM, Michel Veillette wrote:
> Hi Anand and Qin
>
>
>
> Ill like to introduce the idea of supporting the option of
adding the phyTXPower value in an IE within BEACON frames.
>
> Provisioning the phyTXPower can be an issue when targeting
multiple markets with different output power limits.
>
> Including the phyTXPower within BEACON frames will enable
joining nodes to adjust dynamically their output power based on a
value managed at the PAN coordinator.
>
>
>
> cid:image001.jpg@01C868D8.BF0BB7E0
>
>
> Michel Veillette
> System Architecture Director
>
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
>
michel.veille...@trilliantinc.com<mailto:michel.veille...@trilliantinc.com>
>
> www.trilliantinc.com<http://www.trilliantinc.com>
>
>
>
>
>
> From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of
Qin Wang
> Sent: 8 juin 2015 11:08
> To: an...@ece.iisc.ernet.in<mailto:an...@ece.iisc.ernet.in>; Kris Pister
> Cc: 6tisch@ietf.org<mailto:6tisch@ietf.org>
> Subject: Re: [6tisch] 6top and transmit power control
>
>
>
> Hi Anand,
>
>
>
> Regarding to power management, there is a parameter in the
IEEE802.15.4 PIB, i.e. phyTXPower. You can control the
transmitting power by changing its value. Is that what you want?
If so, I think 6tisch MIB will provide the interface to access
phyTXPower, which will be defined in the 6tisch-interface draft.
>
>
>
> Thanks
>
> Qin
>
>
>
>
>
>
>
> On Saturday, June 6, 2015 2:50 PM,
"an...@ece.iisc.ernet.in"<mailto:an...@ece.iisc.ernet.in>
<an...@ece.iisc.ernet.in><mailto:an...@ece.iisc.ernet.in> wrote:
>
>
>
> Hi Kris,
>
> Thanks!
>
> I was not sure if and how such a parameter can be
accommodated in the
> current scheme of things, although it could be a useful
control parameter
> from the operator's perspective.
>
> Anand
>
>
>
> > seems like a good idea.
> >
> > ksjp
> >
> > On 6/4/2015 4:15 AM, SVR Anand wrote:
> >> Dear All,
> >>
> >> A slight digression from the ongoing ML discussions.
Hope the timing
> >> is OK!
> >>
> >> As we all know, transmit power control is one of the
powerful knobs
> >> that can be
> >> used to minimize the interference and thereby
improve the wireless
> >> network
> >> performance and also provide deterministic network.
Cell breathing
> >> technique
> >> used in WLANs comes to our mind. When it comes to
6tisch, one might
> >> argue that
> >> with 16 channels at our disposal, the interference
can be avoided
> >> through smart
> >> 6top cell management interface without worrying much
about transmit
> >> power
> >> control. However, there can be scenarios where
transmit power control
> >> might be
> >> required, for instance, (i) large scale dense
deployments with heavy
> >> traffic
> >> demands (ii) Co-existing WiFi reducing available
non-overlapping
> >> channels for
> >> 15.4 (iii) prevent wireless leaks beyond the
periphery of the
> >> deployement
> >> region and (iv) OTF scheduling where nodes make
local decisions for
> >> managing
> >> cells, may be more.
> >>
> >> One possibility is to leave the power management to
the nodes. We are
> >> then
> >> leaving this to implementors to device their own
algorithms to handle
> >> interference. Alternatively, a centralised
controller (NME) knowing the
> >> information about conflicting links can adaptively
and optimally
> >> adjust the
> >> operating transmit power of the nodes to avoid the
interference and
> >> maximize
> >> the wireless network performance.
> >>
> >> If we treat transmit power as one of the
controllable parameters along
> >> with the
> >> cell management parameters, wondering if 6tisch 6top
interface MIB is
> >> the place
> >> to define this. Or this parameter is beyond the
scope of 6tisch.
> >>
> >> Any suggestions ?
> >>
> >> Anand
> >>
> >
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org<mailto:6tisch@ietf.org>
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org<mailto:6tisch@ietf.org>
> https://www.ietf.org/mailman/listinfo/6tisch
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch