<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
When you propose elimination of the 5MHz and 20MHz channel widths,
are you referring to their central frequency spacings (staggering)
or to the bandwidths themselves? There is a 3dB gain of 5MHz
bandwidth over 10MHz, which really helps some of our weaker clients:<br>
<br>
[eo@Baldi-S1] /interface wireless> registration-table print<br>
# INTERFACE RADIO-NAME
MAC-ADDRESS AP SIGNAL-STRENGTH TX-RATE UPTIME<br>
0 wlan1-gateway WE7X/Baldi
D4:CA:6D:7A:B8:81 no -83dBm 4.8M... 19h38m30s<br>
<br>
[eo@CapitolPark-S2] > /interface wireless registration-table
print<br>
# INTERFACE RADIO-NAME
MAC-ADDRESS AP SIGNAL-STRENGTH TX-RATE UPTIME<br>
0 wlan1 KU7M/Newcastl...
D4:CA:6D:9D:5C:07 no -86dBm 3.2M... 9h21m7s<br>
<br>
[eo@SnoDEM-S2] > /interface wireless registration-table print<br>
# INTERFACE RADIO-NAME
MAC-ADDRESS AP SIGNAL-STRENGTH TX-RATE UPTIME<br>
0 wlan1 AE7Q/MillCree...
D4:CA:6D:54:B4:F5 no -87dBm 2.2Mbps 18h25m26s<br>
<br>
I can't foresee us taking 3dB away from these folks. So as far as
the bandwidth is concerned, I think 5MHz bandwidth is here to stay
because:<br>
<br>
1) it's the highest power spectral density we can achieve with
the hardware, and<br>
2) we don't have throughput saturation on our sectors,<br>
3) which means we also use 5MHz to increase reliability (reduce
retransmits) of the service.<br>
<br>
Now, about the interference between 5MHz and 10MHz plans. The PSDR
group here recognized this would be an issue if we wanted to run
some sectors @ 10MHz bandwidth, so we migrated the network onto a
5MHz bandwidth / 10MHz staggering plan. This gives us the ability
to run an arbitrary mix of 5MHz and 10MHz bandwidths without any
self-interference, since the radiation angle for each sector is the
same in both bandwidths. This provides an easy next-gen upgrade
path without further spectral changes. This upgrade would only take
place once we hit saturation on a given sector and we'd have to
weigh the impact to the marginal users vs. benefits to the high
speed users.<br>
<br>
To support this new 5MHz bandwidth / 10MHz stagger combination we
simply pushed an update to all the client modems with an additional
channel plan, and updated our client setup docs to include the new
channel plan. This doesn't mean we had to retire the original 5MHz
plan, though. That can stay programmed into client modems for any
areas that wish to use it. It's still the tightest packing of the
channels for areas that have very limited access to Part 15
frequencies and therefore need to use the rest of the Part 97 5.9GHz
segment to run their PtPs.<br>
<br>
Any new useful channel plans can simply be added to the official
list (BTW: we need to publish an official list) without the need to
kill existing channel plans. For the sake of reducing search time
in the clients, we can prune the official list down to a "known
active" list. Maybe still uploading all the channels, but in a
disabled state for the unused ones. This optimization would reduce
client modem compatibility when new networks come up, so there's
pros and cons here. I'm fine with recommending the widest list by
default, and if the user so chooses, they can self-optimize their
local channel list.<br>
<br>
Now, given this client flexibility, the new b-channels you propose
look like a fine idea, and I can appreciate your argument with very
nearby sites not having perfect directional shielding. We'd likely
have the exact same situation if our Council House site came on the
air, since it would be very close to the Capitol Park site. Capitol
Park also uses gen 1 antennas, so their directional shielding is
poor.<br>
<br>
There will be added complexity if 2+ HamWAN networks using different
channelization start to share a border or a region. In those cases,
they'd have to work together to only use compatible channels in the
overlapping regions. I don't even wanna touch on what'd be
compatible among all the possible channel plans. Sounds like a
headache. The clients should remain unaffected in such cases
though, provided they have the full channel list uploaded.<br>
<br>
The use of omni channels is a very complicated issue. Can you tell
me more about how you're using them today without causing
self-interference? I'm facing the same design challenge on the
900MHz front.<br>
<br>
The use of MIMO is a fully compatible upgrade, so there's no
problems there. I don't think this has any impact on the standards
other than maybe updating the "recommended hardware" section.<br>
<br>
--Bart<br>
<br>
<div class="moz-cite-prefix">On 12/25/2015 12:43 AM, Ryan Turner,
K0RET wrote:<br>
</div>
<blockquote
cite="mid:CACHX6g9VDq9fmXt6gY+L=sOBa_EibmhJuu6ZgHB3=+3Vx-W+LA@mail.gmail.com"
type="cite">
<div dir="ltr">Netops, members, and interested parties of PSDR and
Memphis,
<div><br>
</div>
<div>I propose the following changes to our official band plan
for point to multipoint:</div>
<div>
<ul>
<li>Elimination of the 5 MHz and 20 MHz channel width
standards</li>
<li>Introduction of a second set of sector channels</li>
<li>Introduction of channels specifically to be used for
omni use in areas where sectors are not feasible (user
density, space, budget)</li>
<li>Adoption of dual chains, horizontal and vertical, for
the last mile</li>
</ul>
<div>
<div>See a chart of the proposed band plan here: <a
moz-do-not-send="true"
href="https://jsfiddle.net/ryan_turner/n13cy7ot/4/embedded/result/"><a class="moz-txt-link-freetext" href="https://jsfiddle.net/ryan_turner/n13cy7ot/4/embedded/result/">https://jsfiddle.net/ryan_turner/n13cy7ot/4/embedded/result/</a></a></div>
<div><br>
</div>
<div>I propose these changes in order to address a number of
issues:</div>
<div>
<ol>
<li>5 MHz channel width is not particularly beneficial;
its performance improvements are only marginal over 10
MHz, and it is a rare scenario for this to be useful
in a last mile situation. Frequently signals that
benefit from 5 vs 10 MHz would be much further
improved by instead better client antenna positioning.
5 MHz channels may be reasonable temporarily should we
place them somewhere within an unoccupied 10 MHz
channel, but today as the two 5 mhz and 10 mhz plans
coexist, they overlap and interfere.</li>
<li>20 MHz channel width is not likely to be adopted
locally due to marginal nature of all of our links and
the limited benefit from the afforded bandwidth. I do
anticipate hardware limitations may drive us to
eventually use 20 mhz channels, however.</li>
<li>Since our antenna systems are not ideal radiators,
inter-cell interference remains a problem for sites
that have LOS between eachother; two of our sites
today are able to see eachother entirely -- that is to
say, each sector on one can see all five other
sectors; introducing more channels for this scenario
would greatly help</li>
<li>In dense urban areas and areas where towers and tall
buildings are specifically banned, in order to reach
our users we need more frequent, smaller points of
presence</li>
<li>Dual chain radios have already been deployed at
multiple sites and found to be better performing than
the slightly higher output power mikrotik metals; cell
site sector antennas already support dual polarity,
and with Mikrotik's mANT30 dish the end-user cost
difference is about $40 over our current day
recommended solution.<br>
</li>
</ol>
<div>Please share your thoughts and opinions.</div>
</div>
<div><br>
</div>
<div>Thanks,</div>
-- <br>
<div class="gmail_signature">
<div dir="ltr"><span style="font-size:12.8px">Ryan Turner,
K0RET</span><br style="font-size:12.8px">
<span style="font-size:12.8px">+1.901.300.0039</span><br
style="font-size:12.8px">
<div dir="ltr" style="font-size:12.8px"><img
moz-do-not-send="true"
src="http://memhamwan.org/wp-content/uploads/2014/02/hamwan-logo-blue.png"><br>
<a moz-do-not-send="true"
href="http://www.memhamwan.org/" target="_blank">HamWAN
Memphis Metro</a> - Memphis' Amateur Radio
Multi-Megabit IP Network</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Netops mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Netops@hamwan.org">Netops@hamwan.org</a>
<a class="moz-txt-link-freetext" href="http://mail.hamwan.net/mailman/listinfo/netops">http://mail.hamwan.net/mailman/listinfo/netops</a>
</pre>
</blockquote>
<br>
</body>
</html>