Sensing the city, update three sensing featured

Sensing the city, update three: sensing

Cities 21 January 2010 | 10.00am

This update is in three parts: ‘our approach’; ‘the hardware’; and ‘sensing’. This entry is continued from ‘the hardware’.

It turns out few people have Bluetooth turned on and visible by default. When my colleague at Arup Jason McDermott helped create an urban sensing installation in central Sydney (Smart Light Fields) they observed around 8% of passers-by had Bluetooth on and visible. A colleague in Barcelona reckons it’s more like 20-30% around La Ramblas (is Bluetooth more prevalent in Europe due to a more mature applications market?).

Either way, we can only see a sample of passers-by with Bluetooth. So our approach is to then move through a stack of sensing, moving on to wi-fi (on smart-phones and other connected devices like netbooks), GSM and so on.

Wi-fi is particularly interesting, as we’d initially thought it wouldn’t register much – as the phone needs to be configured to auto-connect to networks, and a network and router i.e. a wireless access point (WAP), needs to be present to enable that. Even if we could prime the environment with a router (leaving aside the provision of amenities and apps approach – see later), we’d assumed a very small percentage of phones would be detectable. If you know the MAC address of a device, you can ‘ping’ it – but how to discover the MAC address? Leaving aside issues of privacy and ethics momentarily, this was proving a challenge just on a technical basis alone.

Sensing the city, update three sensing 1

However, CRIN have been pursuing an approach called “packet injection” (which most wi-fi dongles don’t support, but some do). To cut a long story short, using this, you can prompt a wi-fi port to respond to and reveal its MAC address. It sounds somewhat scary – and there are those ethical issues to the fore about how we reveal the presence of this system, how to reveal its seams, and so on – but this could be extraordinarily powerful It would mean that all wi-fi-enabled devices i.e. most smartphones, all netbooks, could be triggered to reveal their MAC addresses. This initial process can take up to a minute – again, lending itself to environments where phones/devices are stationery or slow-moving, relative to movement at least – but once you have the MAC address, you can trigger it far more quickly.

A couple of sensors might be deployed here. One, in ‘wide range’ at an entrance, say, would be learning MAC addresses. The other might be tighter and more focused, pinging those addresses already discovered – this only takes a second or two once discovered.

GSM is more complex again, and we’ll report on that later (but in essence, unless you’re network provider you can’t trigger a phone to communicate (strictly speaking you can, but it’s illegal to), and so you rely on how often phone sends a ‘ping’, which it does when it’s crossing a cell location area boundary, when it’s on a call or SMSing, or every 2 hours 20 or so in Australia, depending on how the network configures such things.) With 3G the update periods are shorter, and there’s likely to be more data transfer occurring, which can also be detected. 4G, 3.5G (LTE/WiMAX etc.) are even more likely to be capable of being detected.

The next challenge then, other than refining both sensing processes, is to combine the Bluetooth and wi-fi sensing together to give an aggregate view of phones/devices across both. A lot of shuffling of pings and prompts and duplicates is required here. Beyond that, to get the hardware prototype to a state where we can test in a few environments – at UTS and perhaps at Arup, and then into the wild.

Sensing the city, update three sensing 2

So now we have significant process in both the sensing side (Bluetooth and wi-fi both delivering results, albeit independently at the moment, and the hardware side, with a ‘box of tricks’ coming together nicely.

One of the key questions this might be able to answer are those deceptively simple questions about how people use transport. “How many people get off the number 12 bus here and change to the number 34?”, for instance. Although answers are usually attempted via spot-surveys and manual tracking, this very simple analysis is actually difficult to get at in any systematic sense – particularly when scaled up to all buses, all bus-stops, and in real-time. (The shift to real-time data driving decision-making in urban planning is fundamental, and not without complexities, but will surely happen. This project is a prototype of some elements involved in that future.) Other questions might be: How many people switch from platform 3 to 4 at this time? How many people are on-board the next bus? And so on.

There are issues around how to scale up the data to an urban population. As Anne Galloway and others remind us, not everyone has a mobile phone, never mind a smart-phone. So although we’re investigating a mode of sensing mobility that would be far more wide-spread and real-time than current methods (leaving aside floating car data) we have to be careful about extrapolating the results. We also have to be careful about ethics and privacy too, and we’ll be investigating that shortly, covering both the visibility of the seams of the system, and the levels of aggregation necessary to preserve anonymity in visualisation. As Richard Sennett has said, the great promise of cities is that they enable both anonymity and community – we want to work with that balancing act, not against it.

All the above assumes a ‘passive’ sensing of what phones/devices are present in a space i.e. no direct intervention into the environment encouraging access. However, if there was a smart transit application built for these environments – say delivering real-time transit information, including arrival/departure times, connection times and possibilities, congestion levels, environmental data etc. – this would give people a reason to turn on Bluetooth and/or wi-fi on in the first place. If transit operators offer a good quality informational amenity to passengers, the passengers’ quality of service is improved, potentially leading to great patronage – but in addition, these users can then also be sensed, offering the kind of strategic data we’ve been discussing to transit operators.

As a side-line, we’re also looking at office environments, and how responsive environments could be enabled by these real-time feeds on presence. Many ideas there, which we’ll pick up in a subsequent post.