Surfing the Luminiferous Ether

Last week, I learned about the Wi-Fi service on the downtown corridor for BART. I’ve been riding BART all week, in part due to the collapse of the freeway that runs between my home and the office. As a result, I’ve used the service quite a bit this week.

Wi-Fi Rail claims to cover the platforms at the four stations in the downtown corridor (Civic Center, Powell, Montgomery, and Embarcadero), plus the tunnel between Civic Center and Powell. To put this in proper context, consult the BART system map.

After using for the network for a week, here’s a few notes on how to use it to its best advantage:

• Stay on the platform side of the train. In the downtown corridor, all the stations have a center platform, so the doors on the left side of the train open. I have sat on both the left side and the right side of the train, and I have noticed that the network performs better when I sit on the left, presumably because it it closer to the access points covering the platform, and it is closer to the metal walls of the train.
• Sit on the first car of the train. If you’re in the lead car of the train, your 802.11 device can look for the access point as the train enters the station, not as it finishes pulling in to the station. There may also be an advantage to sitting in the first car because the signal only needs to penetrate the front of one car and not multiple cars, but that’s a speculative theory without knowing more about the placement of access points.
• Don’t count on the network when moving. I’m not sure where the access points are, but I doubt they are on the train. There are no new devices that are apparent on the trains themselves, and the signal strength fluctuates wildly enough that it seems like the the access points are placed along the train line and not on the train cars. 802.11 doesn’t do vehicular speeds between devices all that well, unless you’ve engineered a wide area network.
• Don’t expect anything in the tunnels. Although Wi-Fi Rail has specifically stated that they tried to cover the tunnel between Civic Center and Powell stations, I don’t see a qualitative difference between it and the other two tunnel segments. I’m able to use the network to get work done by paying attention to when the signal is good and sending data, or by queuing up data to go when a connection is restored.

Coverage is not great once you leave the platform, which restricts the buyers to BART riders who have a long wait on the platform at one of the four stations. A passenger like me who rides through the stops would hardly notice, since it’s scheduled as a five-minute trip. (Are business travelers riding to the airport a big market for Wi-Fi services?)

From a practical perspective, it seems like the only people who would be willing to spend the money are those waiting for a train, not those getting off. If you are getting off because you live close and were willing to pay the high price, a broadband connection is probably a few minutes away at home. If you’re transfering to a bus, there are hot spots at street level. If you’re transfering to the to the Muni Metro subway, forget about using electronic devices at rush-hour because the trains are so crowded.

I’ll stick with my unlimited cell data plan from T-Mobile, which offers continuous EDGE service through the downtown tunnels, and adds the ability to use any T-Mobile hot spot in the country.

I’ve been out of the country, so I can only watch from afar, but Glenn ran a story about getting 802.11 on BART, provided by a company called Wi-Fi Rail.

I was interested, so I clicked through to find out more about the network. According to the WiFi Rail site, the network covers “Embarcadero, Montgomery Street, Powell Street, and Civic Center, and the the tubes between Civic Center and Powell Street.” That’s not quite as good as the existing area covered by the cellular network between Civic Center and Embarcadero that I have been using with my T-Mobile data subscription. (I certainly hope that the speeds are better.)

Wi-Fi Rail is asking a hefty amount ($10/day, $30/month, or $300/year). For just four stations (and the tube link between only two of them), there’s no point in buying the service a higher price than my T-Mobile HotSpot subscription. For one subscription, I would prefer to work continuously through the hour-long train ride. The cell data connection is available in the downtown corridor and in the above-ground areas of the East Bay, so it covers a bit more than half of my journey. To pry open my wallet, WiFi Rail will need to get coverage for more than half of the journey, perhaps by partnering with other hot spot networks. (They will also need a better roll-out schedule than was promised in this November 2005 San Francisco Chronicle story on the cellular network.)

The big problem for the train deployments is how to connect train riders to the Internet as they move. Typically, a train deployment will use Wi-Fi on the inside, linked up to one of a variety of backhaul technologies. The WiFi Rail web site doesn’t talk about how the train riders are linked up. My guess, given that I haven’t seen antennas in the trains, is that in-train service is provided by the APs on the platform, perhaps with antennas to get coverage down the tunnel. Spacing between the downtown stations is about half a mile, and the tunnel is nice and straight. If WiFi Rail is using the APs to provide service in tunnels, they will probably use a a fancy antenna (either a distributed antenna system or a “leaky coaxial” antenna) to get good-size coverage from a single AP.

Service is apparently free during the trial period. When I tried to sign-up, here’s what I saw when I handed over an e-mail address:

I hope the service is provided more robustly than the sign-up…

There are multiple wireless networks at the Hong Kong International Airport, but most of them cost money. If you want free access, go to gate 2, which is right underneath The Wing, the Cathay Pacific business-class lounge. You can hop on the free network without being in the lounge, and the signal strength is very good since it’s not walled in on the level above.

Two months ago in London, the IEEE 802.11 working group sent out a new 802.11n draft out for a vote.

The ballot closed on Friday. I’m sitting in the opening plenary for this week’s IEEE 802.11 meeting in Orlando, and the results of the ballot have just been reported. The short of it is that draft 2.0 did receive a 75% supermajority. Due to the interest in the draft, Stuart Kerry, the 802.11 working group chair, announced that the 2.0 draft would be made available for sale by the IEEE.

For the curious, here are the facts:

• 325 voters were eligible to participate in the ballot. 306 (94.2%) did. (There is a floor on the return ratio which must be met before a ballot result is followed.)
• 231 voters approved of the draft, which at 83.4% handily surpassed the 75% threshold required to move forward. From this point on, the 802.11n draft will go through what’s called a “recirculation” ballot. Subsequent drafts will go back to the same set of voters from January as long the approval rate stays above 75%.
• There were 46 votes (16.6%) not in favor of approving, and 28 abstensions (9.2%). Four votes were invalid and not counted.
• There is likely to be some minor change to the draft going forward. It received 3,163 comments (including duplicates). The task group leadership did some basic comment processing, and reported that there are 1,441 unique editorial comments and 1,635 unique technical comments.

It’s not quite correct to say that the draft has “passed,” since it’s not yet moving on to the next stage of the IEEE process (called a “sponsor ballot”). However, it’s clear from the results that the draft is technically solid. While there may be some minor changes to the existing text before ratification, it seems almost certain that the major features have taken shape, especially since draft 2 is going to be used as the basis for Wi-Fi certification efforts.

Ryan McIntyre wrote about watching TV from a taxi on the way to the airport. (Parenthetically, I’ll note that Dulles is possibly my least favorite airport. I grew up in Chicago, so O’Hare was the formative airport of my youth. Let’s face it, I have really low standards for airports. Dulles is just bad.)

I’ve always been intrigued by the idea of a Slingbox, though I haven’t felt the need to run out and buy one. My TV is captured with a MythTV system, so I have full access to the recordings I make with it. I can either get a full-resolution video stream right away, or transcode videos down to a reasonable size for transport (a process which looks more attractive after my recent upgrade). The choice that I make tends to depend on how much video I need; when I was traveling throughout Asia in 2005, I tended to wait for the 300 MB/hour video so I could carry a huge amount with me on the plane. If I just want something to occupy my train ride between home and the office, I’ll take the uncompressed version.

The dependence of the Slingbox on a network connection has kept it from being useful to me, since my travels involve lots of airplane time, where there is no wireless WAN coverage, or international destinations, where the data roaming charges are far too high to spend the money on video transfer. With this sort of a usage, though, I can understand why it might be cool to have one. Transcoding takes a bunch of CPU time before the compressed video is prepared. Generally, when I want to pick up the transcoded video, I’m traveling internationally, so it’s not particularly onerous to wait the couple of hours it takes to prepare. However, if I were to travel to places that have smaller time-zone shifts, I might want the video faster than I could get it transcoded down to a small size.

I’m not ready to race out and buy one. My international travels keep me firmly entrenched in the GSM world, where the mobile data rates are a bit lower than the systems that are widely deployed in the U.S., and in any case, the charge for a high-speed mobile data link would result in a monster roaming charge.

I wonder how much longer this type of application will be possible. Though they are easier to add users to, and far easier to be in motion while connected to, wireless networks can be harder to expand in terms of capacity. The temptation with any shared last-hop type network is to sell as many subscriptions as possible, and to figure out the minimum required service level by managing the subscriber churn rate. I doubt that very few people will drop the service over a data rate that “only” reaches 400 kbps and is useful for everything but streaming video.

Another note: this type of story is why I have spent much of my career as what I affectionately describe as a “network plumber.” If you build the pipes, people always figure out how to use them.

On February 12, I went to check up on the status of the OpenMoko project. With my likely disappointment on the iPhone, I’ve been looking for a replacement for my aging four-year-old Nokia 6600. Based on my set of ideal features for an 802.11 phone, I’ve been looking seriously at the Nokia E series, but they are quite expensive. The recent announcement of the “i” models in the E series lineup (E61i, etc) has shifted my allegiance slightly. I’ve been working with an E series, but it has limited battery life and a flaky SIP stack. My thoughts increasingly turn towards OpenMoko, since it would embrace SIP and open telephony in a way that is still alien to the telcos and their big suppliers. Unfortunately, the project has been delayed a short while. There are good reasons for this, namely that the team is dedicated to having a completely open system from hardware specs up through the toolchain before finally getting to the phone software itself. All commendable, but it doesn’t make it sting any less.

One of the curses of OSS is that you must live your life in full view of the world with a transparency that is a bit jarring for those accustomed to hiding delays and flaws in commercial software. (I’ve come to the conclusion that big government IT projects are no worse than their corporate counterparts, just much easier to see. A similar analogy would seem to hold for open source projects.) I’d like to than Sean Moss-Pultz for his honesty. I still want the phone just as badly as I did before the delay was announced. Touching the phone last week at the Emerging Telephony conference only made my desire worse.

I’m writing this from the Red Carpet Club at the San Francisco airport, waiting for my first hop flight on a trip to Abu Dhabi. I’ve been invited to speak at the Education Without Borders conference on networking and access to technology. Here’s the abstract for my talk, which was inspired by Stewart Brand’s book How Buildings Learn:

Pervasive communication networks greatly increase our ability to share information, but this can sometimes come at a great cost. In physical architecture, the imperceptible slow change of the site and structure dominate the more fast-moving familiar processes that are easily visible to the users of building. The same is true in communication networks, where the social environment of a network’s users and its basic technology steer its future development path. Network engineering is mainly a technical discipline that attempts to optimize for the technology of today while remaining open to tomorrow’s developments. Defining what is optimal and should be maximized, however, is a social question that drives those engineering decisions.

We are in the midst of one of the most fundamental changes in the physical architecture of the Internet, with potential profound changes in its social effect. Most of the technology that underlies traditional Internet access is based on “fixed” networks built from expensive and inflexible cables. The physical architecture constrains network services to areas where the infrastructure is easy to build, keeping access concentrated in densely populated areas. Newer wireless technologies free network builders from technological dependence on cables, and from the financial constraints of needing to pay for costly infrastructure. These technologies enable the network to reach into remote locations that would have previously been considered “off-limits” to traditional technologies.

The resulting flexibility from wireless technologies is shifting the focus of innovation and use away from traditional markets for new technology towards emerging markets that benefit more from its advantages. Instead of importing designs and their implicit social models from existing networks, network builders need to ensure that these new technologies are used within the correct social context and are made broadly available.

The conference is doing a/v recording. I’ll definitely post my slides, and with luck, the audio and video.

One of the most annoying facets of the current market in the U.S. for mobile telephones is that the carriers control the market in a self-serving way. They build closed systems to extract as high an economic rent as possible. You want to be a bookmark on the default WAP screen? That’ll cost you. Phones are sold at a huge discount to get you hooked on the service, and then “locked” to that carrier so they can’t be used elsewhere. I’m assuming that the iPhone will be no different, especially since Apple has shown a willingness to trade away freedom on previous consumer electronics products.

In theory, the lock is supposed to be temporary until the carrier has recouped their subsidy. In practice, I find that most carriers use it as a way to keep you hostage. When I was a Cingular subscriber five years ago, I was told that I had bought the GSM phone to use with the “Cingular service,” and it was Cingular policy never to unlock phones. I’m sure that the then-current world roaming rate of $4.99/minute had nothing to do with the policy.

(Fortunately, it was a Nokia phone, so the unlock procedure is well understood and there are many unlocking tools available.)

The “control your customers and force feed them” model cuts against my entire experience, which is based on open systems and architectures. Innovation in entire handset business is constrained by the fact that the cell phone companies buy and promote the phones, not the manufacturers. Anything that does VoIP is a big threat to per-minute pricing, and therefore won’t be bought or actively promoted by the carrier.

With the carriers strangling new services and innovation in an attempt to ensure they are stillborn, there is one obvious way around it. If consumers were to purchase phones that were compatible with the carrier network, there is very little that a carrier can do about it. I had hoped that Apple would sell the iPhone directly to customers (in addition, perhaps, to the carrier channel). Apple is the one company that can build a product that people would head to the stores for, and perhaps shine a little bit of the light of open systems on to the mobile telephony world.

I’m not surprised Apple didn’t take on the telcos. They can still demonstrate their famous focus on usability by showing off the integrated voice mail system they developed with Cingular’s voice mail vendor. Using the carrier sales channel is going to move a lot more phones in the short-term, even though there is a much more diffuse long-term benefit of breaking the innovation choke-hold.

For the record, this is a bit of a wish on my part. I would love to have an iPhone, but Cingular’s mobile data plans ($79.99/month for unlimited) can’t touch the price of my T-Mobile plan ($30/month, for unlimited hot spot and EDGE). I can’t afford the service to move over to Cingular, but if the phone were made available in a non-locked model, I would be in the store on the first day with cash in hand. Fortunately for me, there is a true open mobile phone platform still to come.

This is an idea that’s been percolating for a while, but Dameon’s recent rant about how VoIP hardware is boring has triggered two responses.

One is that I have started explaining what I do with VoIP to the rest of the world as, “I have become my own telco.” If I want a service, I can define and implement it myself, without needing to wait for a big market to develop and catch the eye of the telco. (I did this recently to make Asterisk handle incoming telephone calls in a time-aware fashion for my international travels.)

But, more on point, I’m also excited by the proliferation of wireless LAN phones. The dual-mode phone is a way of communicating traditionally (with the cell side of the device) as well as with services that I can define myself (with the 802.11 side). Unfortunately, most of the phones on the market are hardly interesting. Here’s my “hit list” of features that you have to implement to make me pay attention:

1. WPA(2). This shouldn’t even be hard at this point. We’ve worked out all of the kinks from these protocols, and there are multiple open-source implementations. There is no excuse for bringing any wireless LAN device to market that doesn’t support good security in 2007.
2. WMM. Last year at Interop, I was able to demonstrate that WMM can give you voice quality, even with significant background traffic. There are plenty of reference designs from hardware vendors that do WMM. Selecting only WMM phones drops you to just eight Wi-Fi Certified devices.
3. PMK caching. This is an under-appreciated feature that was part of the 802.11i amendment. It’s a way of saving master keys to cut down on roaming times. Combined with the “opportunistic” version that establishes master keys on APs before it’s needed, you can get some impressive handoff times between APs, and you’re hard pressed to hear a difference.
4. U-APSD. This is an acronym for Unscheduled Automatic Power Save Delivery. Anybody who’s used an early 802.11 phone has undoubtedly noticed that the battery life is, to put it nicely, awful. U-APSD works keep the 802.11 radio powered down when it’s not used, so that almost all of the 802.11 radio (and power) usage is devoted to transmitting voice. Anecdotally, it can extend battery life by 50-100%, but there are so few implementations I can’t speak from a wealth of data.

Naturally, even after you get to the end of this list, there’s a lot more that can be done, but it’s relatively small potatoes compared to the big four. There are some further quality of service parameters that can be used to help an 802.11 phone in a big network select the right AP to go to, and there are some features that help further smooth out handoffs. To be honest, there are so few phones that can get to #2 on the list that I’m not worried about writing up #5 through #10.

Three and a half years ago, I used a simple model to calculate the maximum throughput of 802.11 networks. Recently, a reader wrote to me and asked me how the use of the short preamble would affect the throughput numbers. The answer is that using the short preamble increases throughput by more than 20%.

The re-calculations aren’t particularly complicated. The short preamble is only 96 microseconds instead of 192. The initial slow component of the preamble is shorter, and the second and final component is transmitted at a faster data rate. This affects the model by making any frame transmitted with 802.11b data rates take 96 fewer microseconds in the air.

In the 802.11b model, that savings exists on four frames (the initial data frame with the TCP payload, the 802.11 ACK, the second data frame with the TCP ACK, and the final 802.11 ACK). Therefore, the simple TCP+ACK transaction the model is based on is 384 microseconds shorter.

In the 802.11g with CTS-to-self protection, the short preamble saves on just two frames. In CTS-to-self protection, the frames transmitted at 802.11b data rates are the two CTS frames used to lock up access to the medium. Therefore, the TCP+ACK transaction unit in the model is 192 microseconds shorter.

Finally, in the 802.11g with RTS-CTS protection, there are once again four frames with a preamble saving. Both of the two 802.11 data frames carrying a TCP payload are protected by an RTS and a CTS frame, so the TCP+ACK transaction unit is once again 384 microseconds shorter.

Throw it into a spreadsheet, and you get the following table, where the short preamble rows are new.

It’s also important to note that the equipment on the market rarely uses the full RTS-CTS protection. It is an option on most equipment, but it is rarely used.