Hello Mr. Beck,

I'm an area resident and a member of the Twin Cities Wireless Users Group
(www.tcwug.org).  I was reviewing the Minneapolis wireless RFP and had a
few comments/concerns and questions/suggestions:

Comments and Concerns:
1.) the state should not prohibit city-initiated wireless networks as
happened in Pennsylvania.  Cities should not need to get permission from
private companies in order to build infrastructure.
2.) ultimately, the city should own/control the system, although it may
make sense to contract the day-to-day operations out to a private company
(the system itself shouldn't become private property or be sold to a
private corporation).  This appears to be the case with the current RFP.

Questions and Suggestions:
3.) what about visitors to Minneapolis?  Some form of access should be
available to visitors (i.e. nonsubscribers).  Perhaps non-subscribers could
have a bandwidth limited connection (e.g. 128 kbps or 256kbps).
4.) what about people who want to contribute to/participate in the system
without requiring subscribing and monthly fees?  For this I suggest that
current broadband users could make their connections publicly available to
anyone authorized to use the Mpls system, and in return they would receive
authorization to use the Mpls system.  (For example, users with
Speakeasy.net DSL subscriptions are permitted and encouraged in their TOS
to share their connections.)  The authorization check could be handled by
contacting a central auth server.  The broadband users wishing to make this
kind of arrangement could pick up a customizable wireless device such as
the Linksys WRT54G that was preloaded with one of the free WRT54G
firmwares.  The preloaded firmware would be set up to handle the
authentication needs.  A WRT54G usually costs between $45-$75.  (I should
mention that part of this idea of users putting up an open AP and in return
getting access to other APs came from something I heard or read about a
year ago, but I don't recall where.  It may have been a Robert Cringely
article.)  (Other Linux based systems like the Soekris kits could be used).
5.) security: use a VPN over 802.11b/g instead of WEP/WPA.  Using the VPN
should be optional, but a captive portal that only permits HTTP/HTTPS
traffic could periodically (say every 10-15 minutes) remind users that they
are not using a VPN secured connection, and give them info how to use the VPN.
6.) How about roaming devices between access points? Something like SOWN's
TransparentMobility system would be very very nice
(http://www.sown.org.uk/index.php/TransparentMobility).  Using the SOWN
system, you can roam between access points without losing your open
connections.  This is very important for things like VPN, VOIP , or SSH
sessions.  The SOWN software is open source and freely available from
7.) it'd be good to have a way to allow wireless enthusiasts to participate
at a higher level in the system
8.) radio frequency coordination issues (using 802.11b/g for client
connections, and 802.11a or physical cabling for backbone links).
9.) bandwidth management software is necessary to prevent one client from
using too many resources.  Tools include Frottle, Wondershaper and others.
10.) Coverage testing: Pages 32-35 of the RFP are technical questions that
include the requirement of no dead spots.  One concern I have is the
existance of dead spots can vary based on tree foliage cover and client
card capabilities.  Winter coverage would likely be best, which could be a
problem if coverage tests are performed in the winter only to find that
summer coverage is spotty.  Also, a 100 mw Cisco 350 PCMCIA card will work
in many more locations than a cheap $10 after rebate SMC wireless card.  I
would hope that the coverage evaluation teams look at
run-of-the-mill/middle-of-the-pack wireless devices when they determine
coverage needs.  This would probably mean testing coverage with several
common PDAs (Palm/PocketPC), laptops with integrated wireless cards, and
common add-on PCMCIA cards.  Coverage testing with VOIP Wifi phones like
the Cisco CP-7920 would also be appropriate.
11.) the requirement for "No special client software required for service,
other than provided by the above standard operating systems."  SOWN's
system mentioned above could handle that and provide roaming capabilities
without disrupting active connections.

There is a discussion about some of these issues archived at:
along with a proposal for how to integrate "primary" Mpls-provided access
points with "participant" access points that addresses the issues of
support, billing, TOS, and quality of service:


Haudy Kazemi

Any questions regarding this RFP should be submitted in writing to the CITY
OF MINNEAPOLIS’ sole contact person:
Mr. William E. Beck
Director, BIS Business Development
350 South Fifth Street, Room 127
Minneapolis, MN 55415
Email: broadband at ci.minneapolis.mn.us
Fax: 612-673-2719
All questions are due no later than Monday, May 16, 2005, at 4:00 p.m.
Central Daylight Time. Questions will be answered in writing and published
on the CITY OF MINNEAPOLIS’ web site by Tuesday, May 31, 2005. The contact
person above is the only individual that can be contacted about the project
by Respondents before proposals are submitted. That contact MUST be in
writing. The department contact cannot vary the terms of the RFP.
---end of copy/paste---