View source for MayFirst2012NYCCrateDeployment

[crate open photo with word wrap]

As a technical experiment and outreach project, some New York City FNF members
used existing [[FreedomTower]] equipment to deploy a free and open mobile
"internet-in-a-suitcase" WiFi access point at march/demonstration sites in
mid-Manhattan on May 1st, 2012. This was something of a last-minute deployment
using the equipment on hand, with backhaul over a regular 4G service provider
without any tunneling or encryption, and does not represent the ultimate
topology or (fixed) infrastructure of a Free Network, but was a lot of fun and
a great way to get hands on experience in an extremely crowded radio
environment.

We experimented with a rolling "basestation crate" (which contained a commercial
4G modem, pfSense router, and seperate 2.4GHz and 5GHz WiFi radios all powered
by battery) and a smaller "repeater unit" (dual-band commercial router powered
by a battery).

(bryan has many more photos of this event, but not online ATM)

= Equipment =

[crate predeployment photo]

=== Basestation Crate ===

 - Rolling Pelican Suitcase/Crate
 - 1x 5GHz Ubiquity NanoStation ("N5")
 - 1x 2.4GHz Ubiquity NanoStation ("N2")
 - Intel Atom x86 router (running pfSense)
 - Ethernet switch
 - 12v sealed lead-acid battery (absorbed glass mat)
 - 120v AC alternator and power strip

The basestation/crate was pretty heavy with the battery; care was taken to make
sure the battery wouldn't rattle too much, everything was secured with
adhesive-backed velcro to the inside of the case. Lifting the case up and down
stairs we a bit of a pain, but it was easy to roll, and only suffered a bit of
wear being rolled more than a mile over endless curbs, potholes, and
cobblestones. 

[electrical block diagram]

Total crate electrical draw coming out of the alternator (as measured with a
Kill-a-Watt device) was about 25 watts idle. We chose to use a lead-acid
battery because they are simple and (relatively) easily available.
Unfortunately they are very large and heavy (for the desired capacity),
somewhat dangerous (high current), and more expensive for the sealed "absorbed
glass mat" (AGM) style required for safety. Regular car batteries have sloshing
liquid acid and should not be left at an angle, can leak or spray acid, are
damaged by deep discharges, and are generally unsafe for mobile deployment
(though they do have large capacity and are cheap if found used; might be
appropriate for towers neading DIY large capacity battery backup). AGM
batteries cost around $100 for the capacity needed and can be found at marine
supply stores or in the marine/recreation section of car supply stores. We got
a smallish AGM battery new from AutoZone (was able to return it a week later)
which had a 19 amp-hour capacity. Large batteries usually don't list an
amp-hour capacity, they list "Reserve Capacity" (RC); in our case we wanted at
least an RC of 40 (messy units, see wikipedia). 

No special efforts were taken to reduce power consumption via software settings
("sleep modes").

[network block diagram]

Above is the network structure block diagram. The nanostations operate as
"dumb" radios, all DHCP is handled by the central router.

The 2.4GHz Nanostation was configured to only use 802.11bg (not 802.11n), on
the wild guess that high throughput speeds would be an impossibility and that
sticking to the older protocols supported by all devices would reduce
complexity.

Otherwise the router and NanoStations were configured the same way as a regular
[FreedomTower], see documentation elsewhere.

[radio coverage]

The above diagram (from NanoStation documentation) shows the expected RF signal
strength. The radios were mounted to the front of the case facing forward
vertically, such such that the bubble of WiFi coverage was directed forwards as
if the case was a large speaker. The "squashed cone" of coverage was about 50
degrees "wide" and 30 degrees "tall" according to the above diagram. 

Obviously the overall functionality of the basestation could be replicated with
a tiny cheap off-the-shelf battery powered WiFi hotspot and a 4G USB dongle.
Our equipment and software was much higher performance, but if we wanted to
scale out this kind of deployment the package size could be reduced
significantly.

=== Repeater ===

The motivation for the repeater was to test extended range using the
(relatively clean and reliable) 5GHz band as backhaul and making shorter-hop
2.4GHz connections to users with 2.4GHz-only devices.

Equipment:

 - Netgear WNDR2700v2 ("N600") WiFi gateway/router running OpenWRT
 - Small sealed lead-acid battery (12v)

The battery was connected directly (with a fuse inline) to the router's barrel
jack power connector by canibalizing the wall-wart cabling; this router takes
12v DC input, so not conversion was necessary. The router pulled 6-11watts of
AC power (measured with Kill-a-Watt).  No special software efforts were taken
to reduce power consumption.

The router was configured to use the 5GHz radio as uplink (WAN) and to provide
general connectivity via the 2.4GHz radio (LAN), with mostly default settings.
This means the router ran an internal DHCP server (dnsmasq?) and handled all
aspects of client configuration locally, instead of forwarding request packets
on to the primary router in the basestation. A seperate SSID ("The Free Network
Repeater") was used.


= Narrative =

[bandwidth chart through the day]

''Chart of 4G network uplink bandwidth throughout the day. Measured by pfSense
router, this is traffic to the internet from the basecrate, including that from
the repeater, but not including "local" traffic, eg serving up the chart
itself. Time is UTC, so "16:00" is noon EDT (rough start of deployment), grey
lines are 10minutes. Maroon in download, grey is upload.''

We started the day with fully charged batteries at Bryant Park, where a series
of stationary events were taking place and a crowd had gathered. The crate was
powered up at '''11:40am EDT''' right next to a row of television vans (with their
own radio equipment). The crate was on the sidewalk at street level at 41st St
and 6th Ave; the park itself is elevated about 2 meters, with a broad
stairwell leading up.

By '''12:05''' we had tested and found "good signal" for the main SSID around the
entire park lawn. Some users had trouble connecting directly to the basestation
using iPhones; other phones had no trouble connecting. The bandwidth chart
shows very low usage for a period here, there may have been a misconfiguration?

At '''13:20''' (17:20 in chart) we turned on the repeater; it's battry voltage was
12.44v. The repeater's 2.4GHz radio was set to channel #1 to avoid interference
with the basestation radio. There was another strong station on channel 1
(SSID: "warroom"), and we may have been clobbering that. Around this time we
moved the crate up into the park itself and stood it on folding chair to get it
off the ground by a foot or two; this greatly improved signal strength. The
bandwidth charts show mostly intermitant download.

Around '''14:23''' (18:23 in chart) we began marching/rolling down 5th Ave to Union
Sq, which took about 40 minutes. We saw pretty heavy upload traffic during this
period. Bryan rolled the case on the opposite side of the street from the march
and monitored uplink connectivity while Pablo took the repeater in the crowd
and told marchers that connectivity was available.

By '''15:00''' we had arrived at Union Sq and took a break at the north end of the
plaza for some food. We opened the crate and powered down for a few minutes at
'''15:15''' (19:15 in the chart, note "gap"). Crate battery voltage was 12.00v open
circuit (no load).

After about 40 minutes we made our way south in the square. The repeater
battery died at about '''16:00''' (with 11.90v), so it ran about 2.5 hours. 

At around '''16:30''' we made a few signal strength measurements across about 15
meters of very dense crowd (in front a concert stage just north of 14th St and
Broadway) and got poor signal and throughput. At this point the batteries died
in the smartphone being used for testings, so the signal quality measurement
could be due to low power. Chart shows we had some strong down/up usage during
this period. We had the crate up off the ground at about chest height on a
stone wall, but not above heads or with clear lines of sight to the crowd,
which may have diminished signal propagation. After about 40 minutes the crate
was moved south of the crowd to a new location before the start of a large
organized march, and the batteries probably died shortly after that.

The pfSense logs indicate no traffic after '''17:30''', and we have notes of only
"questionable connection quality" at '''17:00''' (checked with a borrowed phone).
It was discovered that the batteries were dead and inverter was in alarm at
'''17:55'''. This means the batteries held out for almost 6 hours, which is pretty
good. 

The final basestation battery voltage was 11.10v, which is very low ("deep
cycle", would cause damage a regular non-AGM lead-acid battery).

= Conclusions =

Healthy use of the network while "on the move" around 16:30 was surprising.
Providing mobile/roaming connectivity isn't a short-term priority for the FNF,
but might be possible in certain situations.

We did little to promote the existance or goals of the network to users,
because we thought a captive portal would be frustrating and not in the spirit
of open access. Using a domain or short URL as the SSID would have allowed
curious users to look us up.

It is (obviously) important to get the radios up above head height for this
sort of deployment, thus the usual "tower" structure. It was equally important
to keep the mobile directional antennas at least relatively fixed with respect
to users; rotating the crate even a small angle could cut off many connected
devices in a crowd, which is a very frustrating user experience.

It seems like the OpenWRT router was more accessible to user's mobile devices
compared to the 2.4GHz NanoStation; this may have been due to accidental
misconfiguration or confusion, more lab testing to confirm is called for. 

Overall, in a very crowded chaotic environment, we provided about 250MB of up
and down data transfer, averaging to around 100kbps up and down throughput. It
is encouraging that users made relatively symmetric use of the network!