Hi Pat,

Thanks! I see your concerns.

Let us hope we will have advanced IoT controllers, similar to WLAN controllers,
which manage and provide a deterministic and efficient 6tisch network!

Anand


On Tue, 9 Jun 2015, Pat Kinney wrote:

Anand;

You raise valid points and in a professionally installed system, the installers 
would have made sure that the transmit power levels were appropriate.  My 
concerns are for non-professionally installed systems and/or systems with low 
duty cycle mobile end nodes.  Normally, in professional installations we ensure 
a 20 dB signal margin for end nodes, and populate routers to minimize ?choke? 
points and maximize spectrum reuse.  However, in non-professional installs, we 
cannot assume these nodes will be properly set up.  Also, I am concerned that 
the IEEE 802.15.4 standard for the O-QPSK PHY in the 2450 MHz band does not 
require transmit power leveling nor multiple power set points, so any use of 
transmit power control would depend upon proprietary capabilities.  Finally, 
although phyTxPower is not marked as a read-only attribute, it is not described 
as an attribute that actively controls transmit power, hence its use as such 
would be proprietary.

Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email protected] <mailto:[email protected]>

On 9, Jun2015, at 2:50, S.V.R.Anand <[email protected]> wrote:

Hi Pat,

Thanks a lot for the insightful comments!

The main theme of my mail is to use transmit power control is to enable better
spatial re-use of the channels, managed by an external controller. The focus is
not much on the power savings. With respect to the effect of power control on
CSMA behaviour for the shared timeslots, one comes across literature that talks
about optimal power control that trades-off between hidden node and exposed
node problems. The latter is for better spatial re-use. As Michel pointed out
in his mail, the  nodes can use different output power levels. Left to them,
this could lead to unpredictable the contention regions, and all the associated
unfairness issues as well.

A well provisioned power levels managed by a centralized controller can also
help support more "deterministic"  tracks that use dedicated TX timeslots. For
reasons I cited in my earlier mail, don't you think a handle to transmit power
control helps in managing the network better, at least in the case of non-CSMA
timeslots ?

Anand




On Monday 08 June 2015 10:49 PM, Pat Kinney wrote:
Reducing transmit power may
     seem like a great idea but it creates havoc in many systems due to
     the hidden node problem.  A reduction in transmit power will
     often degrade the effectiveness of the CSMA mechanism which is
     used in shared timeslots.  The reduced effectiveness frequently
     appears as lost packets, requiring retransmissions, requiring more
     energy than that saved by reduction of transmit power.  However,
     since the CSMA is not required for TX only timeslots, changing TX
     power in these timeslots may be done with fewer ill effects.

     >

     > Pat

     > Pat Kinney

     > Kinney Consulting LLC

     > IEEE 802.15 WG vice chair, TG chair

     > ISA100.11a WG chair

     > O: +1.847.960.3715

     > [email protected] 
<mailto:[email protected]>

     >

     >

     >

     >

     >

     >

     > On 8, Jun2015, at 10:33, Michel Veillette
     <[email protected]> 
<mailto:[email protected]> 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.

     >

     >

     >

     > <image001.jpg>

     >

     >

     > Michel Veillette

     > System Architecture Director

     >

     > Trilliant Inc.

     > Tel: 450-375-0556 ext. 237

     > [email protected] 
<mailto:[email protected]>

     >

     > www.trilliantinc.com <http://www.trilliantinc.com/>

     >

     >

     >

     >

     >

     > From: 6tisch [mailto:[email protected] 
<mailto:[email protected]>] On Behalf Of
     Qin Wang

     > Sent: 8 juin 2015 11:08

     > To: [email protected] <mailto:[email protected]>; Kris Pister

     > Cc: [email protected] <mailto:[email protected]>

     > 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, "[email protected]" 
<mailto:[email protected]>
     <[email protected]> <mailto:[email protected]> 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

     > [email protected] <mailto:[email protected]>

     > https://www.ietf.org/mailman/listinfo/6tisch 
<https://www.ietf.org/mailman/listinfo/6tisch>

     >

     > _______________________________________________

     > 6tisch mailing list

     > [email protected] <mailto:[email protected]>

     > https://www.ietf.org/mailman/listinfo/6tisch 
<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

     > [email protected] <mailto:[email protected]>

     > https://www.ietf.org/mailman/listinfo/6tisch 
<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
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to