The 2013 Allied Media Conference MagicNet, powered by Digital Stewards and Commotion
Blog Post
July 17, 2013
At this year’s Allied Media Conference, the Open Technology Institute partnered with local Detroit Digital Stewards and Red Hook Digital Stewards from Brooklyn to construct a conference-wide mesh wireless network, MagicNet. MagicNet provided network and Internet access to conference attendees, provided a training opportunity for the Detroit and Red Hook Digital Stewards, and served as a field test for the most recent developer release of the Commotion Wireless project, version 1.1.
Detroit Digital Steward Monique Tate and Red Hook Digital Steward Kathy Ortiz install a Commotion wireless node at the 2013 Allied Media Conference.
Connectivity is crucial at the annual Allied Media Conference (AMC) as participants use the Internet and local applications for collaborative note-taking during sessions, to share their experiences at the conference, to download presentation materials, and other online activities. Previous years’ conferences demonstrated that the wireless network provided by Wayne State University can be cumbersome to log into, unreliable in its availability, and unable to handle the large number of simultaneous connections from the conference’s 1,600+ participants. The conference sessions are spread over five buildings on the Wayne State University campus. Combined with the participatory zeal of the conference attendees, these conditions make the AMC a great opportunity for a Commotion field trial.
Network details:
|
We drew a number of lessons from both the network installation process and from our assessment of the software’s performance throughout the conference. We demonstrated that a mesh network can be set up in a very short amount of time, and can extend network and Internet access to buildings without wired connections to the Internet. In addition, this can be done by a team of participants with varying levels of technical background and still achieve solid network performance.
Key Advances from the 2012 MagicNet
This was the second iteration of the AMC MagicNet powered by Commotion. In 2012, OTI set up a network using a previous version of the Commotion software, Pre-Release 3, which covered just the main conference venue. A report on the 2012 MagicNet can be found on the OTI blog. Drawing on lessons from that installation process, OTI organized an even larger conference network for 2013, incorporating non-OTI staff in the process and achieving one of the largest Commotion networks to date.
Key changes we made to the process from the previous year include:
- Better coordination of the team members installing the software and wireless nodes led to less confusion about the state of each device, especially when it came time to test. This involved a “walk through” of the conference sites with the Digital Stewards and OTI staff, so everyone knew where to install devices at each site.
- A worksheet listing the name, location, settings, and status for each device allowed the network coordinators to test and troubleshoot the network faster when issues arose. In previous deployments, we lacked a single area where such information was collected.
- The Commotion installation served as a training opportunity, which is a general best practice for network construction. OTI involved the Digital Stewards from both Detroit and Red Hook from the start, to provide more hands-on experience installing and using the software. The Stewards participated in troubleshooting and were able to explore the use of mesh networks for a temporary setting like a conference, while being able to share their experiences from their neighborhoods with each other.
- Increased the length of time a single user would be logged in to an access point on the network before having to pass through the splash page again. At the 2012 AMC, we used the default setting of one hour for this function and participants gave us feedback that they would be “bumped” off the network too frequently. For 2013, we increased the amount of time the would be logged on to 24 hours.
Detroit Digital Steward Ulysses Jones extends the MagicNet with a wireless node on the interior of the McGregor Conference Center.
Network Installation
Prior to the conference, the local Detroit Digital Stewards installed the Commotion software on 12 wireless nodes for use in the deployment. We conducted the installation on the first day of the conference, which is the day for AMC “network gatherings,” essentially mini-pre-conferences or day-long meetings for national networks whose members are attending the main conference activities. This scheduling arrangement meant the installation was complete before most conference participants arrived the following morning when regular sessions began.
Fourteen people participated directly in the deployment, including Detroit Digital Stewards, Red Hook Digital Stewards, and OTI staff. First, the entire group reviewed the installation plan and walked through the site. The group then divided into teams by buildings, making sure that each team had members from OTI, Detroit, and Red Hook. OTI’s Field Engineer led the process and coordinated across the teams.
The McGregor team installed four nodes to provide coverage to the central conference area: two wireless nodes on the second floor, one in the media lab on the first floor and one on the lower level. They installed a fifth node on the outside window of the building to provide a mesh connection to the three nearby buildings where conference sessions were also held. The other teams each installed two nodes in the three other buildings: the College of Education, the Art building, and the Hilberry student center. Additionally, the team working in the Art building also installed a single wireless node in the Community Arts auditorium to provide coverage for the events and conference sessions held there. (See node map, below.)
The AMC 2013 MagicNet provided wireless coverage to five conference buildings. Nodes were located inside the buildings or affixed to the outside of a window.
We mounted the exterior window node with a suction cup mount, available for approximately $20 from Ubiquiti. For the remaining nodes we used tape or simply placed them on a shelf. These mounting solutions worked perfectly for the duration of the conference.
Since the McGregor conference center had working Ethernet ports, the nodes there meshed over the Ethernet network, each providing a gateway connection to the Internet. The other three buildings received their Internet connections through mesh wireless links to the node attached to the outside of the McGregor conference center. This single node was the sole pathway to the Internet for those buildings. Internet connections in those buildings proved fast and reliable, even with many connections through a single node.
The diagram above shows the quality of mesh links between nodes in the MagicNet. The closer the link’s rating is to 1.000, the better the quality of the wireless connection between those two nodes. Nodes that are connected by Ethernet have a rating of 0.100 and are more reliable and better quality than wireless links.
We gave each access point a unique name based on the room where we installed it. From any point in the conference area, users could see many access points. This naming scheme encouraged them to choose the one in the room closest to them. Based on our review of the conference area, network service was available in all official conference rooms and gathering spaces except for some sections of the Education building. One session space on the second floor of the Education building was on the interior of the building and lacking windows, the wireless signals were unable to provide coverage in that room.
Deployment Challenges
The team encountered two major challenges during the construction and testing of MagicNet. One was a software issue and the other was an environmental factor.
We discovered a major bug in a software component of Commotion when both Ethernet and wireless mesh connections run concurrently on any node. The node outside of McGregor had both Ethernet and wireless meshing enabled to bridge the networks of McGregor and the neighboring buildings. This caused extremely long latencies and dropped connections when clients and other mesh nodes connected. The bug disappeared when we disabled the component and Commotion developers were able to produce a patch for the software within two weeks.
A second obstacle was an environmental factor, not related to Commotion. We planned to provide the wireless links from McGregor to the neighboring buildings with nodes mounted inside windows, attached to the glass with suction cups. The line of sight between buildings was clear, but after we initialized the nodes on each end, the signal between buildings was surprisingly low and the connection was intermittent. It took some troubleshooting before the team determined that the glass in the windows contained a tint that blocked the Wi-Fi signals. Digital Stewards confirmed this when a wireless node was temporarily moved outside with a very long Ethernet cable, and the mesh connections became very strong. The team then affixed the wireless node to the outside of the building with suction cups.
Despite these challenges, the network construction was very successful, and the team of Digital Stewards and OTI staff learned valuable lessons that we will incorporate into the future development of Commotion. Overall, the experience was positive for OTI, the Digital Stewards, and the conference participants who provided valuable feedback on the network.
The Application Portal
The 2013 AMC was the public premiere of the Commotion application portal, which was added in Developer Release 1.0. This portal gives users a simple web interface where they can browse services or “apps” that are locally hosted on the mesh network or available via the Internet. This provides an opportunity to promote local area network applications that can differentiate a Commotion network from Internet-only network connections.
The MagicNet gave users a choice of general Internet access or locally relevant content and applications.
When users at the AMC connected to the MagicNet, a captive portal was used to give them a choice between connecting to the Internet or going to the application portal. The purpose of this information architecture is to promote local uses of a network alongside general purpose access to the Internet.
At the AMC this year, those local uses included the conference session browser and the custom Tidepools instance OTI set up for the conference [http://tidepools.co/amc]. For more discussion of how Tidepools was used at the AMC and the release of Tidepools mobile beta, see “Tidepools is Mobile Ready!”
The application portal functioned as expected, successfully providing users with a simple interface for relevant services at the conference. With the version in this deployment, someone had to add information about each application to every node manually. In future versions, local applications added to any node’s portal will automatically be announced to other nodes on the mesh network and presented to users at all of those access points.
Lessons for Future Conference MagicNets
This deployment shows that a Commotion mesh network can distribute Internet access for an extended period of time across a campus area without major changes or additions to buildings, even when access to rooftops or wiring closets is not available. While skilled developers and engineers are still needed to resolve unexpected challenges, the right procedures can effectively involve people with basic networking skills in the deployment.
With the 2013 AMC MagicNet, OTI has identified key improvements to our deployment procedures, in particular to how we evaluate network performance and how people with varying skill levels can conduct installations with less OTI support. The steps below will help drive adoption of Commotion among both event organizers and end users.
Technical performance metrics and standardized user data – OTI is in the process of setting up router-based diagnostics and online forms to capture network use information. This information will include the number of simultaneous users, their distribution across different wireless nodes, the number of users on local applications, and qualitative user feedback.
Refined installation worksheet and checklist – Using a step-by-step worksheet for setting up and recording information about each node was a great improvement over previous conference deployments. To further streamline the process, OTI is revising the worksheet to include online and paper versions, and looking into the ability to track updates and changes to wireless nodes.
Software bug fix – The patch to the bug we identified in this deployment should prevent that problem from arising again in the future, potentially decreasing the need for software development skills among the installation team.
Shielded windows – OTI has identified this as an engineering challenge to incorporate into our training modules, specifically by teaching the procedure we used in this instance to isolate the problem. This should decrease the required engineering skill level for the installation team, though we also see that each new deployment presents a new wireless engineering challenge that is not specific to Commotion or mesh.
Provide more local applications – For the 2013 AMC deployment, the locally relevant content available via the application portal were all hosted on the Internet. Commotion can also support applications hosted on the local network. In future deployments, for example, we plan to put Tidepools on a local server and provide a local service running MediaGrid, a distributed file-sharing server and secure chat application. The Etherpads for conference notes could also run on a local server. These steps would reduce reliance on the Internet gateways, increase speeds for users, and limit users’ risks of interception and surveillance that is pervasive on Internet infrastructure.
The stability of Commotion Developer Release 1.1 means that future deployments can be advertised to users as a reliable – though still experimental – solution to specific connectivity needs. In the case of conference deployments, the installation team can work in coordination with conference organizers to promote the MagicNet to attendees and to document use and impacts. This would increase adoption of the network and of local applications like TidePools and decrease confusion among users. Organizers should encourage use of the #Commotion, #Tidepools, or #MagicNet hashtag on social media, along with other standard feedback mechanisms, for this purpose.