July 1

Three things happening on July 1:

1. I'm heading to Boston for ISIT. I'm looking forward to it -- this will be my first ISIT since Seoul. Come see my paper in session S16.T9 (Information Theory in Biology). I'll blog more about the paper later, but in the meanwhile, Trailhead is cool. And as Anand notes, the unconnected papers might be the most interesting -- they're the ones bringing the new ideas.
2. My first sabbatical officially gets started. I'll be spending the year with a startup, Engage Biomechanics, focusing on wearable wireless sensors and body-area networks. The company is looking at applications in medical devices. I've never been an entrepreneur before, so it should be interesting and I'll blog when I get a chance.
3. It's the 20th anniversary of the day I reported to basic training and joined the Navy. With recruiting ads like this, how could I say no?

Video: Keynote at Research to Standards workshop

Here's the video of my keynote (joinly with Steve Bush) at the Research to Standards workshop on June 10, alongside ICC 2012 in Ottawa.

"Standards and Innovation in Emerging Technologies: Why Industry and Academia Need Each Other"

This is a playlist. You can also see it directly on YouTube.

Abstract and speaker bios after the jump.

The capacity of molecular communication: Molecular efficiency

Say you've got two genetically engineered bacteria, which you're using as a communication system. Maybe you've engineered the organism's quorum sensing abilities, or its calcium receptors, to do your bidding. Whatever way you're doing it, what you want to do is to send a message, encoded in a pattern of molecules, that propagate from one bacteria to the other. This is molecular communication.

So exactly how fast can you send information? In other words, what is the Shannon capacity?

Would you believe that it's infinite?

Sunday, Sunday, Sunday. Keynote, keynote, keynote.

I'm giving a keynote (well ... half of a keynote, the other half by Steve Bush) this Sunday at the Research to Standards workshop, held alongside next week's ICC in Ottawa. We'll be talking about the role standards play in emerging technologies, like nanonetworking. This is related to our own work in leading the IEEE 1906.1 nanonetworking standardization effort.

1906.1 is a new idea for the Communications Society. Historically, standards have been used to consolidate industrial interest around established technologies. Now, we're using the standardization process to get everyone talking the same language, get interest from industry, and avoid dilution of the idea at the beginning of the technology cycle. So far the project is a resounding success: we have academics from around the world, plus representatives from large industrial players, as well as several government research bodies.

We're speaking from 9:15 to 10:00 on Sunday. I don't have the location yet, but check here for the details. Hope to see you there.

CWIT 2013 etc.

I'm the general chair of CWIT 2013, which will be held in Toronto next May. We just issued the first Call for Papers [PDF]; submission deadline is February 1.

CWIT is not just for Canadians - it's more of a "Canadian showcase" than a "Canadian club". And Toronto is lovely in May. So please give some thought to a submission.

Meanwhile, congrats to my old PhD supervisor, Frank Kschischang, for winning the 2012 Canadian Award for Telecommunicaitons Research.

Eckford's Rules of North American Air Travel

1. Never connect through ORD. 
• If you must violate this rule, allow at least 4 hours for your connection.
• Add an additional 2 hours if you have to clear customs.
2. If you're flying to a final destination that is less than a three hour drive from a major northeastern hub (e.g. IAD, EWR), forget trying to connect and just drive from the hub. 
• Unless the driving route passes through a notorious traffic area.
3. Never fly codeshare. If an airline offers you a codeshare flight, make the booking directly with the codeshare airline.
• Avoid affiliate airlines (United Express, American Eagle) and fly on the mainline if possible.

I broke all three of these rules on a recent trip. Result: 14-hour overnight delay.

Ceiling function considered harmful

Often in my 4th year mobile communications class, I'll ask a question like the following:

A cellular telephone system is intended to cover an area of 36 square km. Suppose FDMA is used, where the total system bandwidth is 100 MHz, and each call occupies 30 kHz. The system should support 40,000 simultaneous calls in the entire coverage area. Assuming a cluster size of 7, how many cells are needed?

This is a very easy question to solve, and I ask it to get students thinking about radio resources. (Granted that circuit-switched telephony is now obsolete with LTE.) The solution looks like this: at 30 kHz per call, 100 MHz supports 3333 calls; to get 40,000 calls, you need 40,000/3333, or about 12 times the system bandwidth (i.e. 12 cell clusters); with 7 cells per cluster, that's 12 x 7 = 84 cells.

But the problem is that 40000/3333 is slightly more than 12; it's exactly equal to 12 + 4/3333, or 12.00120012... . Multiplying this number by 7, we get 84 + 28/3333, or 84.00840084... .

Since the number of cells must be an integer, a typical student reaction is to take the ceiling of the answer: ceil(84.00840084...) = 85.

But that's bonkers. We "need" an extra 0.0084 of a cell, so the answer is to build a completely new cell tower to satisfy this tiny demand. Cell towers are expensive. And in fact, 12 clusters can cover 39,996 users, so the extra cell would serve a grand total of four calls. The revenue from that -- and even, let's say, the possible contractual penalties for not hitting exactly 40,000 calls -- would never be worth it.

Instead of blindly using the ceiling function in response to these questions, we should encourage students to think about the assumptions behind the question. Allowing a bit of flexibility (e.g., slightly relaxing the "40,000 call" assumption) would lead to a much more realistic and useful answer, and better engineering.