New proposal - Local Access Frequencies by District



See: 
Why Move Frequency (by John Martin KF8KK) for a PowerPoint presentation describing
 why a single Flat network is not scalable over a large geographic area.


Date: Sun, 30 Oct 2005 15:06:59 -0500 (EST)
From: Jay Nugent 
To: Digital Radio Group 
Subject: [DRG] Moving away from a "Flat Topology" network

Greetings all!
   Wow!  Did the emails start flying.  On the State ARPSC net (3.932 5pm
Sunday Oct. 16th) I announced work on a proposed packet frequency plan to
place each of the Districts on their own "Local Access" frequency in an
effort to relieve the already congested use of 145.09 and 145.76.  Those
Districts having larger geographic areas or with higher Amateur
populations may need to be subdivided into two or more "Local Access"
frequencies.  Idealy, each *county* should have its own Local Access
frequency, but that is not a scalable solution at this point in time.

   Having a solid network doesn't come without its price.  This plan
*will* require that your network Guru's deploy multi-ported "Gateway"
nodes in various parts of the network.  But more on that later...

   Periodically through this document I will inject "Training Note:"
followed by a definition of a term or a tidbit of information.  Please do
not take these training notes to be condescending.  They are intended to
help those on this list who may not be as well versed as others.  We each
come from differing levels of knowledge and experience.  And of course,
I'm not perfect, so if you find that I've described something incorrectly,
please DO correct me!


   Training Note:  "Local Access" frequency is the frequency used by your
                   local community of Hams to access one another directly.
                   It is also used to access one or more Gateway nodes.

   Training Note:  "WAN" is Wide Area Network.  It denotes a network
                   covering a wide area, generally this would mean a town
                   or city, but can extend to cover a county, or several
                   counties.  It uses your "Local Access" frequency.

   Training Note:  A "Gateway" is a station having two or more radios and
                   some form of hardware/software that allows for the
                   routing of packets between the seperate networks.
                   A "Gateway" allows you to connect to neighboring local
                   access frequencies, or to connect through a Backbone
                   network to far distant locations.

   Training Note:  "Flat Topology" is a network of stations or nodes that
                   all use just ONE frequency.  The network has no
                   heirarchy.  Flat topologies lend themselves well to
                   only very small coverage areas.



   The dividing up of the current "Flat Topology" network into regional
networks will help to aleviate the "Hidden Transmitter" problem that
cripples our current networks.  We can improve our statewide network by
reducing the geographic "RF footprint" of each region by creating more
managable sized "WANs".  Each WAN will then be able to have any amount of
Packet activity within it, without affecting the neighboring WAN.  This
allows your neighbors WAN to have activity without bothering *your* WAN.
With our current FLAT topology, so long as only one or two users are using
the network simultainiuosly, things work *reasonably* well.  Add that
third of forth user and the network falls in on itself due to packet
collisions.  This is not very scalable and will likely fail in an
emergency when perhaps dozens of stations are online passing traffic.


   Training Note:  "Collision" is when two stations transmit at the same
                   time and their packets collide.  The collision results
                   in neither stations packet being copied by the intended
                   recipient because it has become garbled.  Each station
                   must now re-transmit their packets.
                   If these two stations can never hear one another, as
                   they may be counties apart, they will continue to bang
                   heads and never get their traffic through.

   Training Note:  "CSMA/CD"  - The Packet AX.25 protocol is designed to
                   use a technique called CSMA/CD or Carrier Sense
                   Multiple Access / Collision Detection.
                   This means that each station will listen before
                   transmitting to determine if it hears another packet on
                   the air (Data Carrier Detect - DCD), "Carrier Sense".
                   It will hold off transmitting until the channel is
                   clear.  Garbled packets due to collisions will not be
                   acknowledged by the recipient.  The sending station
                   after a predetermined timeout will re-transmit any
                   unacknowledged packets.


   This network collapse happens quite often here in the Southestern
quadrant of the state on 145.76.  And I confirmed recently with a trip to
the Kalkaska area that it also happens all across the 145.09 network in
the Northern lower penninsula.  It stands to reason this is systemic and
occurs everywhere in the state.  It is time that we move forward and
divide our FLAT topology into more managable segments and begin the
deployment of "Gateway" nodes to tie the WANs together where needed.

   A couple weeks ago I sent everyone an email containing a paper written
by Dr. Tom Clark entitled "The Trouble with Digipeaters".  I hope everyone
had a chance to read it.  It is important to understand all the issues
involved when designing dependable Packet networks, particularly Hidden
Transmitters, but also understand the issues concerning RF footprints,
collision domains, how Nodes and Gateways work, frequency re-use,
co-interference issues when using multiple radios at the same site,
antenna patterns and antenna placement, etc.  It is not as simple as just
plug it in and go!  Networks need planning and coordination to be
effective.  THAT is one of the purposes of the DRG.  Let's pool our
resources and get the ball rolling towards building a *better* network.

   Now is a good time to go take a look at the "Proposed Local Access
Frequencies by District" image on the opening page of the WWW.MI-DRG.ORG
website. You will find this image in the right-hand column down near the
bottom of the page.  This plan is *NOT* cast in stone and is subject to
good engineering suggestions by you folks.  By all means please involve
your area Packet Guru's as they are the *builders* of your networks. This
effects them the most!  If you see a problem, speak up.  We need to catch
any errors early on so we don't paint ourselves into any corners.

   NOTE:  It is *NOT* our intention to dismantle the existing MEDN/QMN
          network on 145.76.  These networks are managed outside the
          control of the DRG and still serve a usefull purpose.
          It is also not our intention to upset the DXcluster network on
          145.09.  DXclusters have often run their own networks because of
          the high traffic loads they present.


   In the following text I will try to describe what this plan entails.
Put on your Engineering caps guys, here we go!


   By splitting up the "Flat" topology into a "Multi-Layered" one,
combined with the move to the new Local Access frequencies it will require
a coordinated effort to build "Gateway" nodes to tie neighboring WANs
together.  Secondly it will be beneficial to establish dedicated trunk
connections that would tie the Gateway nodes together (on their own
frequencies i.e. 220/440) forming a "Backbone Network".  A Backbone will
allow traffic from any of the WANs to flow to any other WANs *without*
having to traverse anyone's Local Access WAN to get there.  The purpose of
a Backbone is to *NOT* burden the local nets with transient or "thru"
traffic.  With just a few well engineered and well placed multi-ported
Gateways, this becomes relatively easy to do.

   After my announcement of the Proposed Frequencies by District plan, the
emails started coming in right away asking what frequencies each District
should move to.  At the time the plan was still just a work in progress,
so no definitive answers could be provided.  Several revisions later, we
believe we may have a workable distribution of frequencies that will allow
for the greatest seperation of frequencies between Districts so that
"desense" issues can be more easily controlled at the "gateway" nodes.


   Training Note:  "Multi-Layered" network uses different 'layers' for
                   each function of the network.  A "Local Access" layer
                   where end users access the network.  A "Gateway"
                   function that switches or routes traffic between
                   different Local Access layers.  A "Backbone" layer that
                   carries only the long-haul traffic of the network.
                   These can be compared to an on-ramp, a highway, and
                   an expressway, respectively.

   Training Note:  "Desense" is when a receivers front end RF amplifier
                   becomes swamped with so much RF energy from a nearby
                   transmitter that the receiver becomes de-sensitized, or
                   becomes deaf.  Generally transmitters farther away in
                   frequency from the receiver frequency result in less
                   desense.
                   Repeaters use hundreds of dollars worth of band-pass
                   and notch "cavities" to isolate their receiver from
                   other transmitters at the same site.


   The need to move away from a "Flat" topology and develop and deploy a
well engineered "Multi Layered" topology is nothing new, we discussed it
at each of the three DRG meetings held to date.  At the latest meeting, it
became clear that we need to get the ball rolling and begin the process of
making frequency assignments.  We also determined that we need to hold
training sessions to bring our membership (as well as the Packet community
at large, those who actually build the networks) up to speed on just
exactly how Multi-Layered networks work, and how to plan and deploy them.

   Many times over the last nine months the question was asked "What
frequencies are currently in use in your County or District".  Most
recently it was an agenda item at the Sept. 24th meeting and was again
asked in an email to the group sent out on Sept. 4th.  This was done as a
fact finding effort to determine where networks were already entrenched.
Sadly, there was not an overwhelming amount of input to this question.

   So, with some personal trips into different regions of the state,
portable packet station in tow, I was able to 'map' (I use that term
rather loosly) what our current topologies look like. From that data I was
able to attempt connections to all areas of the state and ascertain what
problems we have with our current network deployment.  Briefly, here is
some of what what I've found:

   --> We have far too much dependency on digipeaters
      -  See Tom Clarks paper on why this is bad
      -  This is particularly prevelent in S.E. Michigan

   --> NetROM, WILD, and K-nodes are not well integrated
      +  There is a strong deployment of NetROM, WILD, and K-nodes
         throughout the Northern Lower Penninsula
      -  Many nodes do not exchange routes with one another
      -  Many nodes cannot reach nodes they list in their route tables
      -  Over half the routes listed are not reachable (day or night)
      -  Stale routes never get dropped from the route tables, even when
         they have not been heard from in over 30 days!
      -  Some routes exist but are NOT listed in the route tables
      -  The .09 network "dies" when there is DXcluster traffic

  --> Statewide, the "collision domain" is far too large.  Just *one*
      station can use the network but it can become near impossible for a
      second station to use the network at the same time.  This is
      particularly bad when the stations are two or three counties apart
      and are trying to use a common resourse between them.

  --> With carefully picked routes, it *IS* possible to get from the
      Southeast area of the state to the Northwest (namely Ypsilanti to
      East Jordan and Traverse City), but I wouldn't want to do it every
      day.
      Because of the HamGates in both the S.E. and N.E., interconnectivity
      between these networks is quite simple.
      I could find no 'dependable' routes into the West and Southwest
      areas of the state.  Not that they don't exist, I just wasn't able
      to find them.

  --> At all areas of the state, crossing from East to West and vice-versa
      was not easily accomplished.  We need more nodes and/or better paths
      across the middle of the state.


   With real-world testing it becomes evident that we need to move away
from the "single collision domain", i.e Flat one-frequency topology, and
move on to much smaller "Local Access" WANs and build Gatways that link
them together.  This, complimented by a "Backbone" that links the Gateways
and Local Access WANs together.  This will leave us with a network that
reduces collisions, allows for more simultainious users, and provides a
means to reach any area of the state via a coordinated backbone.

   So there, stated simply, is our goal.  The steps to accomplishing it
are time consuming and likely will not happen without serious effort.  It
is very hard to convince folks to switch frequencies after they have been
there for awhile.  But we have to try.

   Briefly, here are the steps neccessary:

   1) Move stations off the single frequency networks (145.09 & 145.76)
      and onto the proposed "Local Access" frequncies.

   2) At the same time create multi-ported Gateways that tie neighboring
      Local Access WANs together.

   3) Begin a coordinated effort to tie the Gateway nodes together on a
      statewide multi-frequency backbone.  This can be supplemented with
      nodes that mearly tie the Backbone to just one Local Access WAN.
      Use of Internet tunnels to supplement the Backbone and carry
      longer-haul or larger payload traffic, is also possible.


   The reasoning behind the selection of frequencies for each District or
region is simple.  Because "Gateway" nodes will need to be placed where
one WAN joins a neighboring WAN, they will have two or more radios.
Close proximity of *same band* transmitters and receivers lends itself to
the "desense" problem.  Packet traffic on one WAN will likely desense the
receiver of the radio on the 'other' WAN.  The further apart in frequency
these WANs are, the less the desense.

   By examining the "Proposed Local Access Frequencies by District" map
you will note that 'most' of the WANs are 2 to 2-1/2 MHz apart.  This is
not true in the Southeast where many of the WANs are only seperated by
100KHz or so.  We are addressing that problem by building Gateway stations
that are linked on the 220 and 440 bands thus seperating the 2-meter
radios by great distances.  This eliminates the need for more than one
2-Meter radio per site while at the same time helps in the development of
our "Backbone".

   The following are the 2-meter frequencies reserved for Packet use.  You
can find more information about Packet frequencies used in Michigan in the
"Frequency Coordination" Working Group section of the DRG website.


 144.91 144.93 144.95 144.97 144.99 145.01 145.03 145.05 145.07 145.09
 145.51 145.53        145.57   (.59 -- .61)145.63 145.65 145.67
 145.71 145.73   (.75 -- .77)                   ^
             ^                                  |
             |__________________________________+__ Everything ending in x3
                                                    are Keyboard ONLY!
 147.54 147.56 147.58
            ^
            |______________ TCP/IP ONLY!

  Note: 145.75 and .77 have been wasted by the use of 145.76 by MEDN/QMN
  Note: 145.59 and .61 have been wasted by the use of 145.60 by D-Star


   There you have it.  Please share this document with all your EC's and
AEC's.  Also share it with your Packet community.  The end users and those
that have put up nodes are the ones most effected by this change.  We
encourage comments and input from all sources.



NOTE:   I have not forgotten the fine folks in the Upper Penninsula.
        I just haven't completed the graphics showing the U.P.
        The U.P. may select any frequency that best suits them, but I
        recommend it be in the 144 portion of the band.  Perhaps 144.95
        144.97 or 144.99?



  "Okay Professor, I've completed my Thesis.  Now may I have my diploma?"

      --- Jay Nugent  WB8TKL
          Chair, ARRL Michigan Section "Digital Radio Group" (DRG)
          [www.MI-DRG.org]

"Those that sacrifice essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."  -- Ben Franklin (1759)
+------------------------------------------------------------------------+
| Jay Nugent   jjn@nuge.com    (734)484-5105    (734)544-4326/Fax        |
| Nugent Telecommunications  [www.nuge.com]     (734)649-0850/Cell       |
|   Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller |
| ISP Monitoring [www.ispmonitor.net] ISP & Modem Performance Monitoring |
| Web-Pegasus    [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts|
| LinuxNIC, Inc. [www.linuxnic.net]   Registrar of the .linux TLD        |
+------------------------------------------------------------------------+
  2:01am  up 217 days,  4:06,  5 users,  load average: 0.07, 0.06, 0.01