Re: [WIRELESS-LAN] Managing static power/channel assignments?

[Kevin McCormick]

I have not look in to this too much myself, but leaky feeder cable may 
work in the shaft. They use this type of cable in mines for radio 
communication. I don't see why WiFi would be much different. Works by 
leaking signal from the coax every so many feet. Only place I would even 
consider using leaky feeder would be in a low population and difficult 
to cover space like an elevator shaft.


https://www.networkworld.com/article/2307514/network-security/is-leaky-coax-ok-for-distributing-wi-fi-signals-.html

On 12/3/2017 11:53 AM, Mike King wrote:
I don't know if anyone is doing this, but I was proposed by a VAR 
about 10 years ago to put highly directional antenna's in the bottom 
and the top of the elevator shafts, with the connector cable coming 
back to a "safe to work in" room.  It does depend on the size of the 
elevator shaft (at the time we topped out at 6 floors).  We never 
actually went forward with this, but we discussed placing a highly 
directional antenna on the top of the shaft and placing the AP inside 
the Elevator room that was on the top of the shaft.


We did discuss putting the AP in the car, but at the time, we had no 
way of getting Ethernet into the elevator Cab, and the lack of a 
stranded cable of that length turned us off of pursuing it further.


On Fri, Dec 1, 2017 at 10:00 PM, Joachim Tingvold 
mailto:joac...@tingvold.com>> wrote:


On 1 Dec 2017, at 16:16, Jeffrey D. Sessler wrote:

I'm curious about what's driving the need for two AP's in each
elevator, or to have them there in the first place? Even in
medical/hospital settings, I typically see an AP placed on
each floor in the elevator lobby. Given how sticky clients are
today, it seems to work very well even for latency sensitive
services like VoIP.


Hospital, where each floor is almost double the height of normal
floors (where almost half of it is above the ceiling, containing
nothing but metal, pipes, and other non-RF-friendly stuff). Each
elevator has it's own shaft of concrete, and then you can add all
the metal in the elevator cab on top of that. We did some tests,
and there's no way clients will be able to have a stable
connection going between floors; at least not when traversing
multiple floors in rapid succession (i.e. going from 1st to 8th
floor without stopping in the other floors). We have APs outside
the elevators on each floor, but that's not enough.

The reasoning behind two APs is merely for redundancy when an AP
or the Cat6/6A elevator cable fails (they /will/ fail,
eventually); the elevators are in high traffic, making it hard to
"just stop one" for hours to fix a broken cable or exchange a
broken AP. We also try to cable "every other AP" to different
IDFs, giving redundancy in case of outage of a single IDF, or for
maintenance cases (where we can software upgrade all equipment in
an IDF, without affecting wireless coverage).


It also reduces problems with location-based services because
the AP isn't changing elevation all the time.


Yeah, I'm not really looking forward to that part. But coverage >
location-based services for this particular scenario.



-- 
Joachim


**
Participation and subscription information for this EDUCAUSE
Constituent Group discussion list can be found at
http://www.educause.edu/discuss .


** Participation and subscription information for this 
EDUCAUSE Constituent Group discussion list can be found at 
http://www.educause.edu/discuss.





**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.

Re: [WIRELESS-LAN] Managing static power/channel assignments?

[Mike King]

I don't know if anyone is doing this, but I was proposed by a VAR about 10
years ago to put highly directional antenna's in the bottom and the top of
the elevator shafts, with the connector cable coming back to a "safe to
work in" room.  It does depend on the size of the elevator shaft (at the
time we topped out at 6 floors).  We never actually went forward with this,
but we discussed placing a highly directional antenna on the top of the
shaft and placing the AP inside the Elevator room that was on the top of
the shaft.

We did discuss putting the AP in the car, but at the time, we had no way of
getting Ethernet into the elevator Cab, and the lack of a stranded cable of
that length turned us off of pursuing it further.

On Fri, Dec 1, 2017 at 10:00 PM, Joachim Tingvold 
wrote:

> On 1 Dec 2017, at 16:16, Jeffrey D. Sessler wrote:
>
>> I'm curious about what's driving the need for two AP's in each elevator,
>> or to have them there in the first place? Even in medical/hospital
>> settings, I typically see an AP placed on each floor in the elevator lobby.
>> Given how sticky clients are today, it seems to work very well even for
>> latency sensitive services like VoIP.
>>
>
> Hospital, where each floor is almost double the height of normal floors
> (where almost half of it is above the ceiling, containing nothing but
> metal, pipes, and other non-RF-friendly stuff). Each elevator has it's own
> shaft of concrete, and then you can add all the metal in the elevator cab
> on top of that. We did some tests, and there's no way clients will be able
> to have a stable connection going between floors; at least not when
> traversing multiple floors in rapid succession (i.e. going from 1st to 8th
> floor without stopping in the other floors). We have APs outside the
> elevators on each floor, but that's not enough.
>
> The reasoning behind two APs is merely for redundancy when an AP or the
> Cat6/6A elevator cable fails (they /will/ fail, eventually); the elevators
> are in high traffic, making it hard to "just stop one" for hours to fix a
> broken cable or exchange a broken AP. We also try to cable "every other AP"
> to different IDFs, giving redundancy in case of outage of a single IDF, or
> for maintenance cases (where we can software upgrade all equipment in an
> IDF, without affecting wireless coverage).
>
>
> It also reduces problems with location-based services because the AP isn't
>> changing elevation all the time.
>>
>
> Yeah, I'm not really looking forward to that part. But coverage >
> location-based services for this particular scenario.
>
>
>
> --
> Joachim
>
> **
> Participation and subscription information for this EDUCAUSE Constituent
> Group discussion list can be found at http://www.educause.edu/discuss.
>

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.

Re: [WIRELESS-LAN] Managing static power/channel assignments?

[Joachim Tingvold]

On 1 Dec 2017, at 16:16, Jeffrey D. Sessler wrote:
I'm curious about what's driving the need for two AP's in each 
elevator, or to have them there in the first place? Even in 
medical/hospital settings, I typically see an AP placed on each floor 
in the elevator lobby. Given how sticky clients are today, it seems to 
work very well even for latency sensitive services like VoIP.


Hospital, where each floor is almost double the height of normal floors 
(where almost half of it is above the ceiling, containing nothing but 
metal, pipes, and other non-RF-friendly stuff). Each elevator has it's 
own shaft of concrete, and then you can add all the metal in the 
elevator cab on top of that. We did some tests, and there's no way 
clients will be able to have a stable connection going between floors; 
at least not when traversing multiple floors in rapid succession (i.e. 
going from 1st to 8th floor without stopping in the other floors). We 
have APs outside the elevators on each floor, but that's not enough.


The reasoning behind two APs is merely for redundancy when an AP or the 
Cat6/6A elevator cable fails (they /will/ fail, eventually); the 
elevators are in high traffic, making it hard to "just stop one" for 
hours to fix a broken cable or exchange a broken AP. We also try to 
cable "every other AP" to different IDFs, giving redundancy in case of 
outage of a single IDF, or for maintenance cases (where we can software 
upgrade all equipment in an IDF, without affecting wireless coverage).



It also reduces problems with location-based services because the AP 
isn't changing elevation all the time.


Yeah, I'm not really looking forward to that part. But coverage > 
location-based services for this particular scenario.



--
Joachim

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.

Re: [WIRELESS-LAN] Managing static power/channel assignments?

[Joachim Tingvold]

On 1 Dec 2017, at 16:18, McClintic, Thomas wrote:
> RF Group and RF Profile are different.
> Group is a controller thing and Profile is an AP thing.

Ah, of course. Now I just feel stupid; thanks for clearing that up (-:

-- 
Joachim

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.

RE: [WIRELESS-LAN] Managing static power/channel assignments?

[Dennis Xu]

Hi Joachim,

The document you were referring to is about RF group, not AP group. Aps will 
not treat other Aps from a different AP group as rogues. But if from a 
different RF group, then yes they will be rogues. See this link for more 
information about RF group:
https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-1/mobility_express/b_RRM_White_Paper/b_RRM_White_Paper_chapter_011.html


Dennis Xu | Analyst III, Network Infrastructure
Computing and Communications Services (CCS) | University of Guelph
University Centre | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56217 | d...@uoguelph.ca 
www.uoguelph.ca/ccs | twitter.com/ccsnews | facebook.com/CCSUofG

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Joachim Tingvold
Sent: Friday, December 1, 2017 10:10 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Managing static power/channel assignments?

On 1 Dec 2017, at 15:31, McClintic, Thomas wrote:
> It won't see them as rogues so you need not be concerned there. It is 
> common practice to create a RF Profile variant for multiple AP Groups 
> and those groups be within RF range of each other on the same 
> controller.

Yeah, that was my assumption on the matter as well, but this [1] document might 
disagree with that, as it states the following;

“[…] the access points will then select the beacon/probe-response frames in 
neighboring access point messages to see if they contain an authentication 
information element (IE) that matches that of the RF group. If the select is 
successful, the frames are authenticated. 
Otherwise, the authorized access point reports the neighboring access point as 
a rogue, records its BSSID in a rogue table, and sends the table to the Cisco 
WLC […]”.

[1] 
<https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/config-guide/b_cg83/b_cg83_chapter_011000.html>


> I'm confused on the DCA being one channel, you may want to reevaluate 
> that. It would cause you to have separate RF Profiles per channel 
> which sounds daunting. May want to just set the channel statically or 
> change the DCA interval/time.

The point was to avoid having to fiddle with manually configuring 
several static parameters per AP, that essentially would be identical 
for each deployment. Hence the idea to “simulate” static assignments 
via the RF Profiles, solely so that we can assign such static 
configurations through just AP Groups assignment. This is easier than 
manual configuration of each parameter (less things to configure), and 
also less prone to human errors (compared to manual assignments).

I’m not entirely convinced yet; it was more of a shower thought (-:

-- 
Joachim

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.

RE: [WIRELESS-LAN] Managing static power/channel assignments?

[McClintic, Thomas]

RF Group and RF Profile are different. 

Group is a controller thing and Profile is an AP thing. 

TJ McClintic


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Joachim Tingvold
Sent: Friday, December 1, 2017 9:10 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Managing static power/channel assignments?

On 1 Dec 2017, at 15:31, McClintic, Thomas wrote:
> It won't see them as rogues so you need not be concerned there. It is 
> common practice to create a RF Profile variant for multiple AP Groups 
> and those groups be within RF range of each other on the same 
> controller.

Yeah, that was my assumption on the matter as well, but this [1] document might 
disagree with that, as it states the following;

“[…] the access points will then select the beacon/probe-response frames in 
neighboring access point messages to see if they contain an authentication 
information element (IE) that matches that of the RF group. If the select is 
successful, the frames are authenticated. 
Otherwise, the authorized access point reports the neighboring access point as 
a rogue, records its BSSID in a rogue table, and sends the table to the Cisco 
WLC […]”.

[1] 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.cisco.com_c_en_us_td_docs_wireless_controller_8-2D3_config-2Dguide_b-5Fcg83_b-5Fcg83-5Fchapter-5F011000.html&d=DwIFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=rYfqH_8oTvcXxRxUI3x3m3Y7Nwgir7tnuoGbdZsrUM4&m=L_8PZZQ_qdS8kDvMR3EYVv3wUD7hocNJ-WqqJDA_k7U&s=Dq-rWq0PzUBr0rmN_ZxwTVl6rCKreIupVd9-nlZA2R8&e=
 >


> I'm confused on the DCA being one channel, you may want to reevaluate 
> that. It would cause you to have separate RF Profiles per channel 
> which sounds daunting. May want to just set the channel statically or 
> change the DCA interval/time.

The point was to avoid having to fiddle with manually configuring 
several static parameters per AP, that essentially would be identical 
for each deployment. Hence the idea to “simulate” static assignments 
via the RF Profiles, solely so that we can assign such static 
configurations through just AP Groups assignment. This is easier than 
manual configuration of each parameter (less things to configure), and 
also less prone to human errors (compared to manual assignments).

I’m not entirely convinced yet; it was more of a shower thought (-:

-- 
Joachim

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.educause.edu_discuss&d=DwIFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=rYfqH_8oTvcXxRxUI3x3m3Y7Nwgir7tnuoGbdZsrUM4&m=L_8PZZQ_qdS8kDvMR3EYVv3wUD7hocNJ-WqqJDA_k7U&s=hoa7pEzHsQEOngtEvd_cqOhShAvW_7L45uAVTx45y7c&e=
 .

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.

Re: [WIRELESS-LAN] Managing static power/channel assignments?

[Jeffrey D. Sessler]

I'm curious about what's driving the need for two AP's in each elevator, or to 
have them there in the first place? Even in medical/hospital settings, I 
typically see an AP placed on each floor in the elevator lobby. Given how 
sticky clients are today, it seems to work very well even for latency sensitive 
services like VoIP. It also reduces problems with location-based services 
because the AP isn't changing elevation all the time. 

Jeff 


On 12/1/17, 7:10 AM, "Joachim Tingvold"  wrote:

On 1 Dec 2017, at 15:31, McClintic, Thomas wrote:
> It won't see them as rogues so you need not be concerned there. It is 
> common practice to create a RF Profile variant for multiple AP Groups 
> and those groups be within RF range of each other on the same 
> controller.

Yeah, that was my assumption on the matter as well, but this [1] 
document might disagree with that, as it states the following;

“[…] the access points will then select the beacon/probe-response 
frames in neighboring access point messages to see if they contain an 
authentication information element (IE) that matches that of the RF 
group. If the select is successful, the frames are authenticated. 
Otherwise, the authorized access point reports the neighboring access 
point as a rogue, records its BSSID in a rogue table, and sends the 
table to the Cisco WLC […]”.

[1] 




> I'm confused on the DCA being one channel, you may want to reevaluate 
> that. It would cause you to have separate RF Profiles per channel 
> which sounds daunting. May want to just set the channel statically or 
> change the DCA interval/time.

The point was to avoid having to fiddle with manually configuring 
several static parameters per AP, that essentially would be identical 
for each deployment. Hence the idea to “simulate” static assignments 
via the RF Profiles, solely so that we can assign such static 
configurations through just AP Groups assignment. This is easier than 
manual configuration of each parameter (less things to configure), and 
also less prone to human errors (compared to manual assignments).

I’m not entirely convinced yet; it was more of a shower thought (-:

-- 
Joachim

**
Participation and subscription information for this EDUCAUSE Constituent 
Group discussion list can be found at http://www.educause.edu/discuss.



**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.

Re: [WIRELESS-LAN] Managing static power/channel assignments?

[Joachim Tingvold]

On 1 Dec 2017, at 15:31, McClintic, Thomas wrote:
It won't see them as rogues so you need not be concerned there. It is 
common practice to create a RF Profile variant for multiple AP Groups 
and those groups be within RF range of each other on the same 
controller.


Yeah, that was my assumption on the matter as well, but this [1] 
document might disagree with that, as it states the following;


“[…] the access points will then select the beacon/probe-response 
frames in neighboring access point messages to see if they contain an 
authentication information element (IE) that matches that of the RF 
group. If the select is successful, the frames are authenticated. 
Otherwise, the authorized access point reports the neighboring access 
point as a rogue, records its BSSID in a rogue table, and sends the 
table to the Cisco WLC […]”.


[1] 




I'm confused on the DCA being one channel, you may want to reevaluate 
that. It would cause you to have separate RF Profiles per channel 
which sounds daunting. May want to just set the channel statically or 
change the DCA interval/time.


The point was to avoid having to fiddle with manually configuring 
several static parameters per AP, that essentially would be identical 
for each deployment. Hence the idea to “simulate” static assignments 
via the RF Profiles, solely so that we can assign such static 
configurations through just AP Groups assignment. This is easier than 
manual configuration of each parameter (less things to configure), and 
also less prone to human errors (compared to manual assignments).


I’m not entirely convinced yet; it was more of a shower thought (-:

--
Joachim

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.

RE: [WIRELESS-LAN] Managing static power/channel assignments?

[McClintic, Thomas]

It won't see them as rogues so you need not be concerned there. It is common 
practice to create a RF Profile variant for multiple AP Groups and those groups 
be within RF range of each other on the same controller.

On the TPC we use a 3db shift up from the power used in surveying. This allows 
APs to expand their cells, we also have manipulated some RF neighbor settings 
to help with this. 

I'm confused on the DCA being one channel, you may want to reevaluate that. It 
would cause you to have separate RF Profiles per channel which sounds daunting. 
May want to just set the channel statically or change the DCA interval/time.

TJ McClintic

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Joachim Tingvold
Sent: Friday, December 1, 2017 8:14 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Managing static power/channel assignments?

Hi,

How are people managing their static assignments of channel and power?

We’ve used DCA/TPC on all our deployments, and any tweaking/fine tuning has 
been done in either of those. However, we probably need to have some static 
assignments now that we’re deploying APs in our elevators (to limit cascading). 
I know the current DCA/TPC algorithms somewhat mitigates cascading, but there 
will still be some that we hope to avoid by having static assignments on the 
APs in the elevators (and maybe the closest AP outside the elevators on each 
floor). There should be no scenarios where the APs in the elevators ever needs 
to change their power level, nor their channels, so it makes no sense to have 
TPC or DCA on them.

I haven’t had time to test this yet, but I’m thinking of using RF Profiles;

  * Specify TPC max/min power levels in such a way that it essentially is a 
static power level assignment
  * Specify DCA with only one channel available, essentially making it a static 
channel assignment

We have two APs in each elevator, so we’d create two RF Profiles; the TPC would 
be configured equally, but the DCA would have two different channels between 
the two profiles.

The plan is then to assign these RF Profiles to AP Groups, and then we can just 
assign APs to those AP Groups. This would make it easy to change APs in the 
future, without having to manually configure each AP.

My only concern thus far, is that it seems as if the WLCs will consider APs 
with different RF Profiles as “rogues”. Is that the case, even if the APs are 
on the same WLC? I cannot find anything in the documentation that confirms nor 
denies this.

--
Joachim

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.educause.edu_discuss&d=DwIDaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=rYfqH_8oTvcXxRxUI3x3m3Y7Nwgir7tnuoGbdZsrUM4&m=u-EBB7IKmD1Pw3UZWk8yk3VdPY_PSWsAtly21i38LpY&s=663IIq5k4x9Zr8-i-whxY2RgTE-bcL96DZ-4Tjxeeuw&e=
 .

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.