torstai 22. maaliskuuta 2012

Smart Igloos

Smart igloo


Surely the Eskimos need home networking, too. If the rest of us are setting up our homes for Internet connectivity, smart power, entertainment, and surveillance, shouldn't they need it too? Of course they do. This is why we set out to build igloos with state of the art networking facilities:

Cool housing

  • Your igloo becomes your friend on Facebook, so that when you are out fishing you can keep checking on your smartphone how warm the family is inside the igloo.
  • The network becomes one with snow; snow is important. We need to know whether the walls of the igloo are melting. This is why the igloos are constructed from a mixture of snow, tiny sensors, and Snowcat 5 cabling.
  • Understanding what the snow is doing is also important for mountaineers and skiers. The same technology can be used to determine how much new snow is accumulating and what kind of temperatures are developing in the snow pack. This helps in predicting avalanche risk.
  • The networking architecture is designed for low-power, intermittent connectivity from remote locations.
  • Everything can be constructed from lowest cost parts with widely available, mature technology.


Igloo from the inside. Note sensor hanging from the roof.
It is used for measuring inside temperature.

Igloos! Eskimos! Are You Guys Serious?

Obviously, the igloos are only an example application for the kind of technology that we'd like to develop. It is an example that we personally care about, as many of the people behind this spend a lot of their free time on the mountains and in snowy conditions.

But we are actually very serious about the technology. We need example applications so that we can gather experience and improve our designs. We are not the kind of researchers that produce only streams of Powerpoint presentations. We like to test our ideas in practice, because it tends to give a more honest view into how well they actually work. And once the igloo test is over, we move the sensors back home to measure things like snow cover on our roofs.

More on the technology later, but first we want to talk about snow and mountains.

Building a snow tower to improve reception to the cellular network


What Wouldn't We Do for Science?

The video below shows a time lapse of the village coming together. We are building it in the Swiss alps, as a part of the ExtremeCom 2012 conference. This conference series is dedicated to developing and testing new communication technologies in difficult environments. On previous years they've met in the jungles of Amazon and far up north in Sweden, for instance.




 Sledge, with the sensor
stick on the side
These igloos were not built in any suburb backyard either. Reaching the conference site (Berggasthaus Waldspitz, at the altitude of 1903 meters) from Zurich took three different trains, a gondola, sledging down one mountain, and hiking up another one. From the conference site there was still an hour's hike to the igloo site. With our the demo gear on sledges.

On the site five igloos were built but two never made it to laying down the keystone. Luckily the one with our sensor equipment -- tens of meters of cable with 31 temperature sensors attached -- survived. The sensor wire was installed inside the igloo walls, with some additional sensors inside and outside. The last meters of the cable were free, with a sensor at the end ready to be tucked inside a sleeping bag for the night -- what wouldn't a research scientist do for the sake of science.

One (1) well-deserved after-hike beer
The sensors measured temperatures at the different parts of the igloo over the night and the following day, and the changes in temperature can be seen in the graphs below. It turned out to be surprisingly warm in an igloo and a proper sleeping bag: the inside temperature of the igloo remained close to or over zero throughout the night and temperatures up to 30 degrees Celsius were measured inside the sleeping bag during the night; so warm that one had to open the sleeping bag during the night to cool down.

Below you will find some screenshots from our Facebook and web-based user interface:


Facebook screenshot. Even the discussion bot got excited about the high temperatures in igloo

Sleeping bag temperatures
Summary of the sensor readings inside and outside the igloo.
Wall readings are averages over all the sensors inside the wall.


Key Technologies

Some of the technologies involved in our demo are well established, others are still in research stage. We believe that networking in general benefits from all of these technologies. Particularly when the world moves towards connecting everything -- not just computers but also all other kinds of devices and objects.


Sensor and DTN router

  1. Cellular networks for data transmission. Setting up the smart igloos would not have been possible without some kind of communication network. In the real world, these networks can not be dedicated to specific applications, because building new applications would be prohibitively expensive. The extensive coverage of cellular networks provides a convenient and reasonably priced networking even in fairly remote locations.
  2. Delay- and disruption-tolerant networking (DTN). However, not all places will have always-on network connectivity, and to save power in battery-operated devices not all devices can be connected at all times even if there was connectivity. We need a communications model that allows intermittent connectivity. DTN networking, as the name implies, is very robust against these kind of conditions and can utilize any available connectivity and at any time.
  3. Social web of things. Our team has been experimenting with different types of user interfaces for the "Internet of Objects". In our experience, a natural way to think about these user interfaces is to have relationships ("friendship") to the objects that we care about. And interact with these objects in similar ways as we already interact with out human friends in social networks.
  4. Social web-of-things interface to the igloo
      Power-efficient network architectures
      . While we can expect a constant improvement in electronics over time, the biggest energy savings come from rethinking 
      A 1-wire sensor
      application models and network architectures. Devices should be able to behave in a manner that is natural for them. For instance, a sensor that has very little power should not be required to stay up at all times just in case someone happens to ask something from it. It would be far better to let the sensor report changes at an interval that is natural to it, and have another entity store the results.
    1. Mature, widely available, and low-cost technology.  We like to use technology that is mature enough to be widely available from multiple sources. The cheapest, most commonly available wire, for instance. Or employing the most economic cellular modem from a range a technologies (GSM, 3G, LTE) and different vendors. Or using open source software to interact with sensors that can be acquired commercially and in quantity.
    2. IP. With the exception of some legacy sensors, all our designs are based on IP and IPv6. This is the only logical choice for systems that can connect everywhere. For us this made it possible to place the intelligence and server components back in our homes and offices, and only bring the minimal amount of components to the mountain.

    One single, simple wire connects the sensors

    Developing Sensors for Snow

    We developed two kinds of sensor equipment: snow sticks and a sensor wire. The snow sticks were used to measure the snow pack and the wire could be used to measure any structure made out of snow, in our case the igloo.

    A snow stick, measuring snow depth
    The sticks use two types of measurements. First, they measure incoming light at different points in the stick, making it possible to track what parts of the stick are under snow. Second, they measure temperature at different points, making it possible to track temperatures in different parts of the snow pack. Understanding the temperature history and temperature gradients within the snow is important for predicting avalanches, for instance.

    The sensor wire was simply a long cable with sensors attached to it; 20 meters of cable with sensors and another 20 meters to reach the DTN router. A group of three sensors were placed every couple of meters in the wire so that each group could measure temperatures in the middle of the wall as well as towards the inner and outer edges of the wall. The cable was laid out in a spiral fashion to the igloo wall, rising from the ground up to the apex of the igloo so that readings from different sides and heights could be obtained.


    Wall sensor layout

    Real Challenge Is Cost

    Obviously we could develop these sensors with arbitrary sophistication. However, we also wanted to show that they can be constructed from the cheapest possible components and with minimal expertise.

    The cabling used to connect the tubes into the DTN router was standard Cat 5 cable and any two-wire cable could be used for the sensor wire. Both types of cables are available from any decent hardware store.

    For sensors, we used 1-wire sensors. The sensor wire used temperature sensors that cost just a couple of Euros each and are just a few millimeters across. A large number of 1-wire sensors can share the same cable and still be individually identified with their unique 64-bit identifiers.

    The snow-proof sensors were rigorously tested.
    In a coffee cup filled with snow.
    Manufacturing the cable was easy, just cut the cable and connect the two ends and the pins of the sensor together.

    The only complication is making the wire waterproof. The sensors and the wire at the cable ends were put inside a heat shrink sleeve with just the sensor head sticking out. The terminal blocks were treated with silicone-like sealing compound leaving just the sensor head exposed to the snow.

    The snow sticks needed a slightly different type of sensor to be able to measure incoming light. We used ready-made 1-wire sensor devices from Hobby Boards, measuring both light and temperature. Still, they needed to be attached to the stick somehow. We bought standard 1.5 inch transparent plastic tube from the hardware store for a couple of Euros, stripped the sensor devices to their bare circuit boards, added some lubricant, and pushed the sensors to the right place in the tube along with the cables connecting them.

    If electronics do not fit, add some lubricant

    Silicone sealing was added to both ends to create a completely sealed structure. The stick was attached to a metal rod with the help of duct tape. This helped keep the stick straight and enabled the stick to be planted to the ground. The most expensive part of the snow sticks were the ready-made sensors (25€) but they could also have been manufactured from components that cost just a couple of Euros.

    The 1-wire sensors can be easily monitored from an attached computer via a USB/1-wire converter and the One-Wire File System (OWFS) open source software package. The DTN router sleeps for 30 minutes, wakes up to poll the data from all the sensors, sends it forward to the Internet using the DTN bundle protocol, and then goes back to sleep to conserve batteries. From the DTN back-end server our application server retrieves the data and shows it on a set of web pages, send urgent alarms with SMS and instant messages, and posts information on Facebook. The server also monitors Facebook in order to respond to any questions or discussions; a simple discussion bot was used to accomplish this.

    Switzerland mountain simulation, testing sensors on the 7th floor balcony


    Discussion bot in action

    Detailed sensor value readings from the discussion bot.
    The bot has access to the sensor readings database.

    The bot has limited vocabulary, particularly in Finnish

    Further Reading

    Our igloo networking demo was jointly developed with Stephen Farrell, Kerry Hartnett, and Elwyn Davies, all researchers from the Trinity College in Dublin. The original description of the demo is in our paper, and the conference slides can be found here. Our team built only one igloo and instrumented some of the surroundings, you can read more about the technologies prototyped in the rest of the conference here. You can also find more information social web of things here.

    By the way, if this article got you excited about building igloos, be sure to check the instructions for building one! It is fun. Finally, if you always thought that snow is just frozen ice crystals, you'd be amazed how detailed and complex the physics of snow are. We recommend The Avalanche Handbook for an in-depth look at the weather, physics, and safety issues around snow.

    Ari Keränen
    Jari Arkko
    Ericsson Research, Finland

    Researcher with a view

    Fondue from a snow table


    Igloos with a view

    Assembling the igloo with wires in place

    Photos (c) 2012 by Ari Keränen and Jari Arkko, video (c) 2012 by Bernhard Distl

    torstai 15. maaliskuuta 2012

    Keep Your ABNF Clean

    For the last six years, I've been a part of the IESG, the IETF's steering group. I've loved every day in this job, particularly because it gives you such a grand tour of the different changes and challenges the Internet is going through. And it has been a wonderful opportunity to work with many very smart people around the world.

    But new challenges are good for anyone now and then, and last year I decided that I would step down from this role and do something else instead. You will still see me around in the IETF, among other things I'll be working on many technical things as well as joining in the Internet Architecture Board (IAB). You've probably seen me work on various gadgets and the Internet of Things technology. I will also continue that. The next thing that we'll be organizing on that is a workshop on Smart Object Security, to be held in Paris on March 24th.

    Today is my last IESG telechat. A telechat is a conference call -- or occasionally a Second Life meeting -- where we go through the specifications coming out of the IETF and try to ensure that they are correct. We have a telechat every two weeks, and there are usually from ten to twenty documents to read. The fifteen steering group members try to check everything from ensuring that the right process was followed to small technical details. Most comments that we make are that -- just comments. Occasionally if we detect a problem that would prevent correct implementation or interoperability we will file what is called a "Discuss". This is a blocking comment that needs to be resolved somehow before the document can become an RFC.

    By the way, while these end-of-the-RFC-process reviews are quite visible in the IETF, it is still a small part of our job. I takes roughly a day or at most two for me on a two-week cycle. And in many ways, the issues that we discover are details. Some of the other things that we do are potentially more significant, like starting up new working groups to address a problem in the Internet.

    In any case, I wanted to put some extra effort to how I formulate my comments and Discusses in my last telechat. One of the things that I always want to be careful about is that if there is any formal language (ASN.1, XML, BNF) that it is correctly formulated and unambiguous. This ensures that people can build implementations by feeding the language to a compiler and get correct output. One of the formats IETF documents often use is called ABNF, or Augmented Backus-Naur Form, specified in RFC 5234. Unfortunately, not all specifications we receive use the formal language correctly. It may have been carefully checked at some point, but sometimes a late change causes an error to creep in.

    Normally, comments and Disusses are just e-mails, but today I chose to use video format to complain about ABNF problems. In fact, I've had to use this Discuss already three times for today's telechat:



    Some of our documents had ABNF syntax errors, failed to tell the reader which other RFCs contained the rest of the productions, mixed RFC 2616 and RFC 5324 ABNF syntax, etc. The errors were in all cases minor, as the IETF document authors are usually established experts in their field, and careful. However, even a small error can be annoying, particularly with a formal definition of syntax because due to an error you can not be certain what the actual intent was.

    Please check your ABNF, XML, and ASN.1 carefully before you submit a document for publication!