2018 Baker to Vegas (B2V) Relay Race Broadband Mesh Support
The Challenge Cup / Baker to Vegas Relay race (B2V race) covers over 120 miles of pavement across the California and Nevada desert. This annual event attracts 270 teams of law enforcement officers from around the world. Over 8,000 runners, guests, family members and support staff will be on the course on March 17 & 18, 2018.
Communications Support For the Race
While cellular phone coverage is available in Baker, CA, Pahrump, NV and Las Vegas, NV, there is no cellular phone coverage over the rest of the course. Therefore race communications support consists of ham radio operators stationed at Race Central, at Medical Basecamp and at each of the twenty Stages. The communications network utilized temporary and existing ham repeaters and relied on licensed ham radio operators at each of the Stages to handle communications. The City of Los Angeles provided communications planning, frequency co-ordination, temporary repeaters and support for the event. On occasion, there were medical emergencies, which required consultation and coordination between the medics at the Stage points, the Medical Director and the ambulance or helicopter dispatchers. Last year, the race utilized commercial business band radios to support a separate medical net but the equipment was difficult to use and in some places the coverage was poor.
Broadband Mesh Support for the 2018 B2V Race
In 2018, the ham radio voice network will continue as before. However, the race organizers are considering the use of VOIP phones over a broadband mesh network to support the medical personnel. The use of VOIP phones permits two-way conversations and is user-friendly for the medical personnel. In addition to the VOIP phones for the medical personnel, the race organizers would like use the mesh network to transfer race data from each Stage relay point to Race Central. The race data will include a time-stamped photo of each team as they pass the baton to their next runner. In the past, the race data was stored on a laptop computer and was not available until the laptop was brought to Race Central and the data was downloaded to the race database. Use of a broadband mesh network would provide the race data in a more timely manner. To fulfill these two requirements, the Baker to Vegas Communications Support Team intends to establish a broadband mesh network. However, the final decision on the use of a broadband mesh network is subject to an on-site test and evaluation, which is scheduled to take place at the racecourse on October 13-15, 2017. The broadband mesh network would connect 23 sites over the length of the 120-mile course and would require 8 to 10 backbone nodes on high ground near the course to connect the sites to each other. Because of the large amount of race data, the design of the mesh network should consider using redundant backbone sites, separate bands or channels and VLANs to load balance the traffic between the different Stages and Race Central.
Broadband Mesh Equipment
Because of the potential use of broadband mesh networks and VOIP phone communications during a disaster, the City of Los Angeles’ Information Technology Agency has requested funds to acquire equipment to support broadband mesh networking during the Baker to Vegas race. A successful demo of broadband mesh capabilities during the B2V relay race may lead the City of Los Angeles to develop a broadband mesh backbone plan for disaster communications purposes. In the event that funds are not available or insufficient to provide all of the equipment needed for the race, I would hope that the Southern California AREDN community could provide the equipment.
Volunteers Needed
The City of Los Angeles is seeking volunteers from the AREDN community to help plan, design, implement and support a broadband mesh network to support the 2018 Baker to Vegas Relay Race. Volunteers receive no pay, must undergo a background check and must sign a volunteer agreement with the City. The race organizers have a limited amount of funds and have offered to reimburse the volunteers for meals, travel and lodging expenses while supporting the broadband mesh project.
Volunteers will conduct an onsite survey of mesh backbone sites from October 13-15, 2017. We will set up backbone nodes at 8 to 10 sites on high ground near the course and test connectivity between the Stage relay sites, Medical Base and Race Central. In most cases, the backbone sites will require a hike of up to a mile from the nearest road to set up the equipment, test coverage and if necessary, relocate to a more favorable location. Medical Base, Race Central and all of the Stage sites are located on paved roads. In February 2018, we will return to the area to set up a dry run of the entire mesh network to include a test of the mesh services. During the week of the race in March, 2018 we will set up the mesh network and support the network during the race.
If you wish to volunteer for this project and are in good physical condition (we have to hike to the hilltop sites to set up the backbone nodes) please send me a message using the forum private message contact form (click on my callsign at the top of this post to bring up my profile and then click on the contact tab). Include your e-mail address and contact information and I will send you a City of Los Angeles Volunteer Application packet.
If you have questions or comments about this project, post up in this discussion thread or use the forum private message contact form.
You are here
Baker to Vegas 2018 Broadband Mesh Support
Wed, 10/04/2017 - 22:54
#1
KI6MLU
Baker to Vegas 2018 Broadband Mesh Support
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Don,
The Stages on the California side of the course south of Ibex Pass are located on relatively flat, desert terrain and can be reached from backbone sites located on nearby hills between Stages 1 & 2 and on the ridgeline east of Ibex Pass. The Stages between Ibex Pass and the California-Nevada State line are located along dry washes among low, rolling hills. Finding mesh backbone sites are more difficult in that area so I have identified several potential secondary sites for the backbone nodes. In Nevada, the course runs through the broad, flat Pahrump Valley, across Mountain Springs Pass, and into Las Vegas. A relay node located at the summit of Mt. Potosi could probably reach all of the Nevada stages but I plan to place relay sites along the eastern side of the Pahrump Valley and on Blue Diamond Ridge. Also, I would like to place a node on the side of Kingston Peak to provide an alternate route for mesh traffic between the first four stages and Race Central. Because these are temporary sites and will require a short hike and portable masts (because there are no roads to these hilltops, except to the summit of Mt. Potosi), I have modeled these sites using airlink.ubnt.com with an 8 meter antenna height. My experience with airlink and with radio mobile online is that they are not very accurate when your antenna is so close to the ground; we will verify the connectivity and coverage of these sites during the onsite survey on October 13-15. Will you be able to join us?
Primary Sites:
Supplemental Sites:
Russ
I updated the map on the ocmesh.org website with your proposed nodes/sites.
Have you considered mobile nodes that would travel down the roadway with the chase vehicles?
I am assuming that all of these nodes would need to be powered by batteries, right?
Where is the Medical Basecamp? Is that the "Triage" on the map?
I would be available on Oct 13-15, 2018.
Don
Yes, the medical base camp is the site marked as “Triage” on the map.
The reason that I propose to use so many backbone relay sites is that we have to hike to those sites while carrying the equipment. This effectively limits us to carrying telescoping masts of approximately 25-30 feet (8-10 meters) in length. I have found that unless we have a very high site (such as at Mt. Potosi or a 100 foot tower) we can only expect 15-20 miles of reliable range. In Nevada we have Mt Charleston, Mt Potosi and Blue Diamond Peak which should provide good broadband mesh coverage. But in California, we have a lot of Wilderness areas along the race course and Kingston Peak, which is a good site for a relay has no road to the top, so the available and/or accessible sites are less optimal and have smaller coverage areas.
My goal is to have two or three teams, each team would set up two backbone sites on Friday afternoon and the remaining sites on Saturday. Meanwhile we would drive along the race route and test connectivity from each Stage site.
The broadband mesh network that we have discussed in the previous posts is intended to provide communications for the medical teams and for submission of race data. I suspect that some hams might plan to set up local mesh networks to support Stage operations, such as connecting the "mile out" and "100 yard" posts with webcams so that teams could see their approaching runners.
If you think you MIGHT set up a local broadband mesh network, please post up.
I have two concerns, so please comment if you think I am unnecessarily worried about these (or other) potential problems:
1. The local mesh could be using a different but adjacent frequency, channel width or SSID that could cause interference with the backbone mesh network,
2. The local mesh is using the same frequency, channel width and SSID, therefore their webcam traffic would be broadcast to and accessible from the entire mesh. If too many users at a distant location such as Las Vegas, connect to the webcam, the traffic could affect the throughput on the backbone.
There is a formal mechanism to co-ordinate frequency conflicts but I prefer to rely on voluntary co-operation and a sense of fairness to make sure we don't interfere with or overload the backbone. Comments??
On Friday, October 13 the Baker to Vegas (B2V) Communications Team met in Barstow, CA and proceeded to Baker, CA where we stopped for lunch. The team consisted of about 20 volunteers. Most of the volunteers were there to test voice communications over ham and commercial voice bands but five of us were there to test the AREDN mesh network. The mesh team consisted of Claude Parker KE6DXJ, Ted Schultz N6RPG, Don Hill KE6BXT, Andre Hansen K6AH and myself KI6MLU. After lunch, we planned to set up two backbone nodes; one on a hilltop about 27 miles north of Baker and one on Ibex Pass about 11 miles north of the the first backbone node. Each node would require a 5GHz node with a directional antenna for the backbone link and a 2GHz node with an omni antenna for links to the Stage relay sites, a mast, guy ropes, batteries, ethernet cables, and POEs. The hilltop site would need a wi-fi access point so we could administer the nodes from a smartphone. But first, we had to sort through the equipment that each of us had brought and assemble the pieces that we would need at each site. The site a Ibex Pass was accessible by vehicle, but the hilltop site would require a hike of about a mile each way. Here we are in the parking lot of Dennys as we gathered the equipment we would need to take to each site. Left to right: Claude, Ted, Don and Andre:
After we loaded up the equipment we would need at each site, we split into two teams. Andre and I would hike to the hilltop site and set up the nodes while Don, Ted and Claude would proceed to Ibex Pass and set up the nodes adjacent to the communications tower at the pass.
Claude, Ted and Don had their site up and running by 3:30 pm
Meanwhile, Andre and I were having difficulty reaching the hilltop where we would place the other backbone node. We had planned to park at the base of the hill but the area around the hill was closed to motorized vehicles and we would have to hike over a mile before we would reach the start point for our climb to the top. We drove around to the north side of the hill where we chose a different route to the top of the hill. We parked, loaded the equipment in our back packs and began the ascent. We discovered that the hillside was steep and had plenty of loose rock which made the hike very difficult. After an hour, we were about 2/3 of the way to the top and we decided that since we had a clear line-of-sight to Ibex Pass and to Stages 2, 3 and 4, we would set up the backbone node at that location. Although the site did not have clear line-of-sight to the Start line, I decided that we would deal with that problem some other time. After setting up the equipment and establishing a connection to the Ibex backbone site, I discovered that my cell phone battery had died, so I could not log in and check the mesh status for myself, nor could I take any pictures of the site. I had one of Don Hill's Go Kits, so I attempted to contact the other team via the IP phone but we were unable to establish IP voice communications. It was getting late, so the team at Ibex dismantled the equipment, packed up and left for the hotel in Pahrump. The hillside site was hard to get to, so we felt safe in leaving the equipment on the hillside. We returned to our vehicles and departed just before sunset for dinner and the hotel in Pahrump.
That night at the hotel, we installed two nodes in Ted's RV to test mesh tunneling. We tried to use the hotel's wi-fi connection to get to the internet but we ended up using Don's mi-fi to establish a successful tunnel to nodes in Las Vegas and Southern California. This test meant that we did not have to establish a continuous backbone over the entire race course; if we had internet access, we could segment the backbone and connect the segments with mesh tunneling. (continued)
On Saturday morning, October 14, John Emig W6CYS and Gary Stevens joined the mesh team. We returned to Ibex Pass, re-established the backbone node and resumed testing coverage and throughput between backbone nodes and Stage relay sites.
The hillside site was no longer on the air, and we guessed that the battery had run down. John and I returned to the hillside with a replacement battery and a Go Kit while the rest of the team planned to drive to each Stage relay site, set up a node and test communications. I had recharged my iPhone so I took some pictures of the backbone node we had set up on the hillside.
Andre and Ted drove to the location of Stages 2, 3 and 4 and successfully sent and received IP phone calls with our Go Kit on the hillside, but neither of us were able to make a successful IP phone call to the rest of the team who were at Ibex Pass. We tried to troubleshoot the problem until mid afternoon, when the battery that powered the nodes and the Go Kit on the hillside died. That effectively terminated any further testing, so John and I packed up the equipment, returned to our vehicles and drove back to Pahrump.
We were disappointed that we could not get better range from the backbone node at Ibex Pass and that we did not have time to set up and test backbone sites further north along the course. (continued)
John set up the node using a 25 foot telescoping mast while I set up a Nanostation M2 on the back of my Jeep.
With the backbone node at the new location, we were successful in transferring a 50K data file between Ibex Pass and my Jeep parked at Stage 3 (7.5 miles) but the signal was too weak to transfer the data file when I parked my Jeep at Stage 2 (11 miles). I believe that with a higher gain omni antenna on the backbone node (the antenna we used has 8 db gain) and a higher mast on the Jeep we would be able to transfer that file between Stage 2 and Ibex Pass.
In conclusion, we were able to send VOIP phone calls to/from Stages 2 through 5 and send 50k data files from Stages 3 and 4 to Ibex Pass. More testing will be needed to test connectivity and throughput over the rest of the course.
Baker to Vegas
October 13-15, 2017 AREDN Mesh Network Test
October 13-15, 2017 Test Objectives:
Executive Summary
The tests on the weekend of October 13-15, 2017 were a partial success. Due to technical difficulties and limited resources, the mesh team was able to establish mesh backbone nodes at two sites and conduct successful VOIP phone tests from Stages 2 through 5 and conduct successful file transfer tests between computers located at Stages 3, 4 and Ibex Pass.
Because the mesh backbone was incomplete, the test of mesh tunneling was limited to a successful test of mesh tunneling from nodes located at the Stagecoach West Hotel in Pahrump NV to nodes located in Las Vegas NV and in Southern California.
The weekend tests proved that an AREDN mesh network is able to provide the VOIP and data transfer capabilities to support the Baker to Vegas Race but more work must be done to verify that the AREDN mesh network can be extended to those sites that have yet to be tested.
Objectives and Scope of AREDN Mesh Network for the Baker to Vegas Race
The primary objective of the AREDN Mesh Network is to provide a reliable, easy to use voice communications system for use by physicians stationed along the course from Stage 2 to Stage 9 and at Med Base. To meet this objective, the mesh network will provide a VOIP based phone system and a PBX, which will be capable of interfacing to the public switched telephone system (to include the San Bernardino County 911 system) if desired. This system will be in addition to the Medical/Doctor’s Radio Network that has been used during previous races.
The secondary objective of the AREDN Mesh Network is to provide a reliable means of transferring race data from Stages 2 through 9 to Race Central. To meet this objective, the mesh network will establish a TCP/IP network to connect computers located at Stages 2 through 9 to a server located at Race Central.
AREDN Mesh Network Test Team Members:
Russ Chung, KI6MLU
John Emig, W6CYS
Andre Hansen, K6AH
Don Hill, KE6BXT
Claude Parker, KE6DXJ
Ted Shultz, N6RPG
Gary Stevens
Findings and Recommendations:
Finding #1. Backbone site #1 was difficult to reach due to steep terrain and loose rock. It appears that an alternate, more accessible site can provide the necessary coverage to Stages 2 through 4.
Recommendation #1a. Conduct a test to determine if Stage 2 can be served from the backbone node at Ibex Pass using higher gain antennas. If it cannot be served from Ibex Pass, then establish a backbone node at a more accessible site on the side of the hill below site #1.
Finding #2. Backbone site #2 (Ibex Pass) had limited range. The expected range of the backbone site was less than predicted. The RF environment and the low antenna height could be factors in the poor performance of the equipment at that site.
Recommendation #2a. Move the backbone site #2 to a hill approximately 1900 feet east of the communications tower at Ibex Pass
Recommendation #2b. Use a taller mast at backbone site #2.
Recommendation #2c. Use a 2GHz node with a dual polarity antenna (Nanostation or Rocket) at site #2 instead of a node with a single polarity antenna.
Finding #3. AREDN mesh tunneling can reduce the number of required backbone node sites. Use of a mesh tunnel instead of an RF link between Shoshone and the Chicago Valley would eliminate the need for a backbone node at the south end of the Chicago Valley and would allow the Shoshone node to be located at a more accessible site.
Recommendation #3a. Plan and configure tunnel clients and tunnel servers to connect the backbone sites and Stage sites along CA-127 with the backbone site and Stage sites in the Chicago Valley.
Finding #4. Batteries at backbone site #1 did not last longer than a few hours. Small (10 Ah and 7 Ah) batteries were used due to the need to carry the equipment a considerable distance. Previous tests of the current draw for the node radios did not account for the need to support additional equipment such as Ethernet switches, access points and IP phones.
Recommendation #4a. Run tests to determine the current draw to include additional equipment such as switches, access points, IP phones, webcams, etc. and size the batteries accordingly.
Recommendation #4b. Deploy solar panels with appropriate capacity to recharge the batteries.
Finding #5. Valuable time was wasted in assembling equipment kits such as nodes, masts, batteries, cables, POE, switches, access points etc. in order to have a fully functioning node.
Recommendation #5a. Detailed planning and coordination for ancillary equipment such as cables, batteries, masts, switches and access points must be done as part of the test plan.
Next Steps
Can you share any insight on planting nodes "in the wild"?
Is this public land?
Private land? How did you approach the owner to get permission?
Who cares, it's in the middle of nowhere, no one's going to hike 2 hours on foot to investigate?
The California side of the race goes through U.S. Bureau of Land Management (BLM) land. The BLM rules are:
1. The public can hike anywhere unless it's posted as "closed" (usually due to active mines or hazmat sites)
2. Vehicles must stay on designated roads. That's why we had to park and hike to the sites. Some areas such as Dumont Dunes are open areas where you can drive anywhere, but for the most part, you must stay on designated roads.
3. The race organizers must obtain a Special Use Permit from the BLM. The permit specifies where the Stage relay points, voice repeaters and mesh nodes will be located. The purpose of this weekend's trip was to determine the sites we will be using to support the race, so we didn't get a permit because we didn't know where we were going to put the sites. Once we finalize the sites, we will apply for the permit. Under the National Environmental Protection Act (NEPA), the BLM will conduct an Environmental Assessment (EA) before giving us a permit (and charging us for the permit). Since this is an annual event, the EA should go quickly but if you are doing this for the first time, expect a lengthy review process.
Similar rules apply to U.S. Forest Service, National Park Service and California State Parks land.
On Monday, I went back out to Stage 2 and to Ibex Pass to test connectivity between the two sites using a 2 GHz Rocket with a 13 db omni antenna to connect to a 2 GHz Nanostation, 11 miles apart. The iPerf test results were a surprise to me, so instead of posting the report in this discussion thread, I started a new discussion thread:
https://www.aredn.org/content/unexpected-iperf-test-results
I believe that this test shows that we can set up an AREDN mesh between Stages 2, 3, 4 and Ibex Pass. Because I was beginning to run out of daylight and my iPhone battery was running down, I'd like to resume testing to determine the best combination of channel and channel width to get the best iPerf throughput.
The next on-site tests are scheduled for December 8, 9 and 10, 2017. We will conduct site surveys and iPerf tests to find the best locations for the nodes to connect Stages 5 through 9 and Med Base. I will be working with the Comms Team to develop a test plan for that weekend. Right now, it appears that we will need 3 or 4 mesh volunteers on Friday, and 5 or 6 mesh volunteers on Saturday and Sunday. Please let me know if you are available to join us that weekend.
When I started planning an AREDN mesh network for the Baker to Vegas Relay Race, I thought that we would need to plan a mesh backbone that would link all 20 Stages, the Start and Finish Lines, and Med Base. This implied 8 to 10 backbone nodes in order to provide reliable coverage over the entire route (see Post #4 in this discussion).
Since the initial plan, I have some new information which makes the task of implementing a reliable mesh network much easier.
1. We only need to link Stages 2 through 9 to Med Base; we do not need links to the Start Line nor to any of the stages in Nevada.
2. We can segment the mesh network into "mesh islands" and use mesh tunneling to connect the mesh islands.
3. We can expect to have internet access at Ibex Pass, at Medical Base and at Stage 9.
Based on this new information, we can plan for three mesh islands that would be linked by mesh tunnels:
1. Mesh Island #1 - Stages 2, 3, 4 and Ibex Pass
2. Mesh Island #2 - Stages 5, 6, 7 and Medical Base
3. Mesh Island #3 - Stages 8 and 9
Base on the mesh islands and tunneling, we would need backbone nodes at Ibex Pass (to serve Mesh Island #1) and in the Shoshone area (to serve Mesh Island #2). No backbone node would be required for Mesh Island #3.
We conducted another mesh network test the weekend of December 8, 9 & 10, 2017.
Following the October, 2017 test, the mesh networking requirements changed. The primary requirement became providing internet connectivity for the race timers at Stages 2 through 9 and Stages 15 through 18. The secondary requirement became providing a VOIP phone network to backup the Doctors Radio Network at Stages 2 through 9.
Based on the revised requirements and the test results from the October mesh network tests, we developed a revised mesh network plan consisting of three mesh islands that would be linked by mesh tunnels and internet gateways:
1. Mesh Island #1 - Stages 2 through 7 and Med Base, with an internet gateway located near Ibex Pass
2. Mesh Island #2 - Stages 8 & 9 (Chicago Valley) with an internet gateway co-located with Stage 9
3. Mesh Island #3 - Stages 15 through 18 with mesh relays located at Mt. Potosi and near Mountain Spring with an internet gateway located at Stage 16 or possibly Stage 17.
Test Objectives:
In the interest of learning from your experiences, care to share any comments following the race two weeks ago? The mesh network was briefly introduced in the HamRadioNow episode about the race (link). We're interested to hear how things went!
The goal was to provide internet access to stages 2 through 7 so the timers at those stages could upload their timing data to the internet in real time.
We set up the following nodes:
At Ibex pass we had internet access into an AirRouter (KM6DYY-IBEX.TRLR-ARHP), then a (dtd) link to an M5 Nanostation (KM6DYY-IBEX-TRLR-M5NS).
The M5 Nanostation pointed to two M5 Nanobridges, One at Ibex south to service stages 2, 3, and 4 and the other at Ibex north to service stages 5, 6, and 7.
At both Ibex south and Ibex north the M5 Nanobridge was (dtd)ed to an M2 Nanostation aimed either South or North as needed.
Each of the stages has an M2 Nanostation pointed toward either Ibex south or Ibex North as needed.
To improve the reliability to stage 2 we also added M5 nodes at stage 2 and stage 3 and (dtd)ed them to the M2 Nanostations at those stages.
Each stage had an AirRouter at the timer's table connected to the timer's computer by cat5e cable and connected to the M2 Nanostation via an RF link.
When we arrived at stage 7 to install our nodes we found that Verizon had already set up a satellite internet connection so our nodes were not needed at stage 7.
We also set up a computer and node at Ibex to monitor network status (KM6DYY-MESHCONTROL-ARHP).
In addition to providing internet access for the timers, we also set up VOIP phones at several of the stages. We used two types of VOIP phones. The first type auto registered to a PBX on the internet. The second type were analog phones and Grandstream ATAs. We also used the Linphone app to make VOIP calls to the Grandstream ATA phones.
We also set up a tunnel server at Ibex and then went down to stage 8 (which had an internet connection provided by Verizon) and set up a node with a tunnel client that 1) accessed the tunnel server at Ibex and 2) accessed a tunnel server in Orange County. We were able to make VOIP calles back to Ibex from stage 8 through the tunnel connection.
We also met other HAMs at stage 8 that were also using AREDN mesh networking and they were tunneled into Pasadena.
Attached is a screen capture that was taken as we were bring up some of the nodes.