sunnuntai 3. tammikuuta 2016

Revenge of the Electronic Shower

If it has electronics, it can break. Like the my teenage son's shower unit...

Oras Ventura is a battery operated shower controller than has a display and drives the water controls via electronic motors. I have two of these in the house, and they generally have given very little grief in their soon 10 years of existence.

The units display temperature, and strength of shower can be controlled via up/down buttons, as well as choosing hand/top shower. Not a big deal as such, and other than looking great they don't add that much functionality. One potentially useful function is that there's an automatic 5-minute cut-off for the shower, if it is left accidentally on. Possibly useful for people like me who worry if they left shower/oven/iron on when they leave the house :-)

The downsides are that this brings more parts that could break, and the potential for battery changes. Also, the Venture seems like a first-generation product. The response to inputs is sluggish. And you can't load any shower apps :-) And there's no touch screen or WiFi. WTF?

But the four D20 batteries last a long time, in the order of five years even with daily use. However, now one of the units is acting up. Not turning on the display, making a constant noise, and not responding to inputs. It first displayed E10 (per unreliable teenager reports) and now displays nothing, even with good batteries.

Revenge of the Things?

tiistai 8. syyskuuta 2015

More Health Gadgets - Withings BPM

Yay, another gadget arrived today! For a long time, I've been a Withings weight scale user, and have liked the device a lot. But now I got a blood pressure meter from Withings. This is a review of the device, based on my initial experiences.

The Good

First things first, the design is quite cool, the hardware is sturdy, the finish is perfect. The overall idea is great, your measurements sent to the Internet over Bluetooth. The user interface for looking at the measurements is easy and looks great. Furthermore, Withings allows you to download their data easily, as well as upload other measurements to their database. This makes moving your data to your own storage or other providers easier; it avoids the customer lock problem.

And, most importantly, two days have passed with this device and I have made more measurements than I made with the previous equipment all summer. I need to take measurements and have an idea later what numbers I have seen. Having to open a computer to take notes is make-work.

History graphs show developments over longer period of time. Like in this case where (sadly) my weight keeps increasing:

The Bad

There are some complaints, as well, however. A practical issue was that it took half an hour for me to get the device to work with my iPad. Android phones, iPhones, and iPads are all listed as supported devices, and the connection instructions are simple - pair the Bluetooth device, then push the start button and wait instructions from the application.

Except that in my case the application did not react in any way. Nothing. The device was paired, but not recognised by the application. The instruction booklet said nothing useful about this case.

After some googling it turned out that there's a bug that prevents the measurements to start, if the application is already running. But exiting it didn't help; the application did not start when I pressed the button the device.

Some more googling revealed that while iPads are supported, there is no iPad application. One has to download an iPhone application, and only that application supports running the measurements, even if the iPad application supports showing all measurements. And that was the one that I had used for the weight scale as well.

The software installation initiated by Bluetooth pairing was also cumbersome. The pairing takes you automatically to Appstore for loading the application, but to a place that finds no applications and offers just wrong choices for what to do next (like redeeming a voucher). The instruction booklet says that you should either install the application or update it, but nothing about the case where the application is already installed and most recent version. And that is of course the likely situation if you already own a previous Withings product.

The silly thing is that all this could have been easily avoided if the pairing process would have downloaded the right application or if the instruction booklet would have included separate instructions for iPad users.

The other annoying this is that the meter has a "Start" button. But that button doesn't actually start the measurement -- it just starts the application, and then you have to press the real Start button in the application.

Internet of Things Architecture Thoughts

This is just one of the many examples where we buy things that are bonded to our smartphones. You cannot operate them without your phone. Granted, you are not likely to stop carrying your phone around any time soon. And the ability to see the measurements on high-quality user interface is very helpful.

That being said, I cannot help wonder if there's a better way to do this. In particular, there are many devices that are not designed to be used on a person; they could not rely on a smartphone in any case. And even for the blood pressure monitor, I would just like to take a measurement, and not have to press buttons on my iPad.

What the smartphones are useful for is the initial configuration, and the user interface when you need it. So perhaps instead of being a mandatory part, a forced hop on the path of packets, maybe the smartphone could be the way to configure these devices to use the relevant mobile network or wireless LAN, and then use them for the user interface when they are present? And when they are not present, the devices could just work, and connect to the Internet directly. Like this:

This would also be a great way to configure devices that you do not carry around, e.g., home appliances. Configure once, let them do their thing on the Internet on their own.


This is an overall nice product, well produced and easy to use once you get going. I keep wondering if there would be a way to make it similar to my weight scale; no iPads or iPhones or anything needed. Just the Wireless LAN connection.

You can buy the BPM from the Withings webshop (but be careful to choose the right webshop, there are different ones for different continents).

Photos (c) 2015 by Jari Arkko.

lauantai 18. heinäkuuta 2015

Fast Cars and Networks

How fast can you make a 23-year old Volvo 740 go? Turns out that you can make it go pretty fast... at least 200 mbit/s, maybe more.

I recently got interested in maintaining my old car. Well, it was either maintain it or take it to the scrapper. I chose maintenance, and decided to make two important actions: first, get rid of the rust and repaint the car. And second, add high-speed Internet. With IPv6, of course.

I acquired an LTE Advanced subscription from my local operator (DNA) and a router that can support fast connections. LTE Advanced is a new variant of the 4G LTE standards, capable of speeds up to 300 or 450 mbit/s, using techniques such as carrier aggregation.

To be clear, these are some very fast speeds. My current ADSL connection at home is 18 mbit/s, so there is potential for 10-20x improvements. But the deployment of this technology is just beginning, so it is available only in select areas, and of course, carrier aggregation works best when there's enough spare capacity in the network and not too many other users. I do not yet have a lot of experience about this, but in most places I get 50-80 mbit/s easily, and saw also speeds approaching 200 mbit/s. Cool!

Someone asked what I use the network for. Well, to be honest I don't know. Once the technology is there, ideas for applications can come. What Internet function would you like to see in a car?

Details: I am using Huawei E5186 as a router, and have generally good experiences with this device. It is easy to setup and both IPv4 and IPv6 just work. Some configuration is possible, but isn't strictly speaking needed - the system works out of the box.

For IPv6, the DNA service provides IPv6 for all customers, and as long as the router supports this, devices attached to the router get it too.

On the network side, I believe DNA uses Ericsson network equipment.

For fast connections, the internal network in the car needs to be fast too; I'm using 802.11ac, so the router and devices need to support that.

All this equipment is of course mostly made for non-car use. The router draws 2A of 12V. I'm a bit reluctant to use the car's electricity directly, as the voltage tends to vary quite a bit. Unfortunately, voltage regulators for 12V to 12V weren't in the stock for the local electronics store, so I went for an inverter to 220V and then back to 12V. Not pretty, and uses too much electricity, but it is a temporary solution.

Photos (c) 2015 by Jari Arkko.

maanantai 29. syyskuuta 2014

Making Networking Easier for Users

One of my pet peeves is how hard it is to connect to various networks. I am on a trip today, and my first stop was at the Helsinki-Vantaa airport. A modern airport that prides itself on efficiency and good infrastructure. Their Wi-Fi has worked very well for me. I came to the airport, launched my browser, and confirmed my connection to the network with one click. The network is fast, has no time limits, and is available everywhere within premises. (It would probably work even in the newly opened airport sauna, if my tablet could take the heat and humidity.)

And, having travelled a lot in recent years, this network really is one of the best airport Wi-Fi networks in the world. So all is well, right?


Many people, me included, have data subscriptions on their devices. This allows cellular networks to be used when no Wi-Fi is available. So I can get Skype messages, send photos, and do anything I like everywhere, or at least within my home country. There is only one place in Finland where my smartphone stops working: the Helsinki-Vantaa airport. The device sees the Wi-Fi, connects, and stops, waiting for the user to make that one click.

Of course, if I need to use the Internet I will notice all this and make that one click. However, I believe we are increasingly in an always-connected world, and information flows when it needs to. I do not want my devices to stop, I want them to keep on working. Even that one click is too much. And it is unclear what value that click brings anyone, me or the airport.

But the Helsinki-Vantaa network is one of the best. My next stop was a large hub airport in northern Europe. I checked if there was local Wi-Fi, and there was. My browser told me that I could use either the free or the paid network. I decided to try the free one first. A screen comes up that requires me to register. But the amount of information that they ask is... at least tiresome, if not privacy insensitive. The e-mail address and password I can understand. Maybe the phone number, because some airport networks send a password over on SMS. But I also had to fill in birth date and country. Why?

But this was just the start of my failed attempt to use the network. I got an error message that my chosen e-mail or password was invalid - without any explanation of why they were invalid. I guessed that perhaps I had entered an e-mail address that I had used on my previous visit, and entered another one. Not wanting to fill all information for the second time, I used the browser back button to get to the registration page. Big mistake! After changing my information and pressing register, I got an error.  I should have started again from the beginning.

I gave up and decided to try the paid network instead. I clicked on the payment page, but had to stop for a few minutes to walk to my gate. At the gate, I entered the required information. Including my mother's maiden name. Why? Having fulfilled all information, I later realised that my walk had made it impossible to complete the transaction, whether or not I was revealing all my personal information. I got a "your session is no longer valid" error message.

I could go on, but you get the point. The problems with these networks are very wide spread, and in my opinion, unnecessary. Earlier this summer I was waiting for my delayed flight at a major North American airport, and had trouble getting more than a few packets exchanged via their local network. Not enough to download any e-mails, for instance. Later a friend posted a picture of what his wireless network analyser showed at that airport: all the airport's access points were on the same three channels, making the radio environment in practice unusable.

Couple of years ago we had a large meeting in a hotel in Paris, and our network engineers ended up redesigning the hotel network to work much better, in a situation that was similar to what we saw at the above airport.

You might argue that I am talking about a first world problem. Travel. Airports. Hotels. But take the airport Wi-Fi situation as just one example of a more general problem. We all use networks, in developed and developing world. And many of those networks are often in shopping malls, coffee shops, and bus stations. We need to improve their usability.

The smartphone revolution that we have seen last couple of years was initiated largely thanks to the new, easier to use touchscreen phones and operating systems. Perhaps we need a similar revolution in wireless networking. And I think we have had a lot of the technology around but now it is time to put it into use. Examples of this include Hotspot 2.0, 802.11u, EAP, and various network connectivity checkers in our devices. (I worked on EAP at the IETF over ten years ago, but it is only now that it is getting more widespread adoption. A long time!)

And this problem is not limited to Wi-Fi. Again that is just an example. I also have a lot of experience of trying to acquire SIM cards in various places. I've had great experience in some countries and with some operators. Others struggle in providing a service. Some operators sell SIM cards and the needed data allowance package in different shops. Why? And the top-up process can be difficult. An operator in Europe requires a local phone number for the process to complete. Not particularly useful for tourists, is it? An Asia-Pacific operator uses a web-page process that only works on some browsers, not all. Many countries require proof of identity before you can use a network. Perhaps I can understand that, but it does not stop there. I was once asked for a formal proof of my address within the country. How can I produce such a proof, when staying at a hotel?

Here are my guidelines for providing an effective Internet access product:
  • If you want to provide an open network, make it truly open.
  • If your network is for subscribers, employ an automatic authentication mechanism that does not require the user to perform a web login.
  • If you charge for the use of the network, make it easy to provide the credit card information
  • If you sell cellular access, make the right size SIM cards available to everyone easily.  Do not force users to go through extra steps to "enable" the SIM card. You sold it, it can be enabled automatically.
  • Any web-based purchase, top-up, or login process needs to be tested with all browsers and in different conditions.
  • Do not collect information that you do not need.
  • Radio networks need to be tested and configured properly.

In short, people want your service. Make it easy to buy and use it!

Jari Arkko

Photo credits (c) Jari Arkko and Joe Abley

keskiviikko 27. kesäkuuta 2012

IP for Smart Objects

At Ericsson's Lab web site, Jan Höller and myself have published an article. This article deals with the general architecture for the "Internet of Things", and how we must break the current application-specific silos, and move to a model that employs general-purpose network access technology, IP & IPv6, and web technology. The link to the article is here.

perjantai 20. huhtikuuta 2012

Home networks. By magic.

The routers in my automatically configured IPv6 home network

I wanted to talk about personal home networks on IPv6. I have built a prototype of some cool new technology and my first network is now up and running, having configured itself completely automatically. My implementation is a hack, and only works in very limited cases. Nevertheless, I think it is the first implementation of this technology, currently under development at the IETF's new HOMENET working group. And I believe this technology might have an impact on how people set up their home networks in the future. Hence this article.

(Note that the blog is not about finding an ISP that supports IPv6. And not about home gateway products that are IPv6 capable. Of course those are important issues, but there has been enough discussion about those topics in various forums already. See the end of the article for further details on those.)

What I want to talk about is your home network itself. Can you have any type of network? Any number of nodes? What kind of network architecture should you choose? Is there a lot of configuration effort? The simple case is easy, when there is one router and network behind it -- RFC 6204 has the details. And we all know how to handle this and even the little bit more complex cases on IPv4; it is far from perfect but the technology is well understood.

I Have a Dream

The dream is that you can have any number of routers and hosts and connect them in any way you see fit. And the network comes alive automatically, all parts of the network shall have address space, routers shall know where to send packets, and names get resolved to addresses. And all this should happen without any human touch. (Especially by my mother. Bless her, she is a wonderful person. But she is not that good in configuring IPv6 routing entries.)

"One Subnet Should Be Enough for Everybody"

The simple case with one subnet is easy to deal with. There is already plenty of equipment out in the market that does that. There is an argument that says going beyond this model leads to problems, and that it would be prudent to stick with the simple model. I just don't know if the simple model is sufficient. I can offer a few example cases where it is clearly not sufficient, however:
  • Network separation through policy. Many of today's wireless routers have by default a "Guest" and "Private" networks. It is expected that upcoming applications -- such as smart energy networking for power companies -- may increase requirements for having multiple networks in homes.
  • Heterogeneous network technology. Some types of link layer technologies can not be bridged together, leaving routing or NATting as a the only option. Other technologies may be bridgeable, but their speed differences are too big to make it wise. For instance, bridging together Gigabit Ethernet and some low-speed sensor networking technology may lead to the latter being overcome by the multicast and broadcast traffic of the former.
  • Organic growth of networks. People who have, for instance, insufficient wireless coverage in their houses often end up buying a new device and adding it to their networks. More often than not, these new devices have been routers/NATs in the IPv4 world.
My dream came with a nightmare as well; we might get this wrong. The biggest danger is that IPv6 will be seen as hard to use, leading people to adding more NAT devices into their networks instead. Another danger is causing similar problems as chained NATs already do in the IPv4 side in an organic growth scenario. For instance, difficulties in communicating between devices within the same home. And I really do not want to see the NAT66 solution used for connecting two different parts of an IPv6 network.

The HOMENET WG is trying to address these requirements, by creating a solution that supports multiple routers, multiple subnets, automatic prefix-configuration, automatic routing, and across-the-home name resolution. The working group is currently designing the architecture and various proposals for solutions exist as individual proposals. The group is focused on recommending the use of existing tools, as things like DHCP-based prefix delegation and prefix announcements via Router Advertisements are the right thing to do. And if routing is needed, the existing routing protocols can certainly handle the task. However, the group will have to create a few extensions in some cases where fully automatic configuration is not possible otherwise.

HOMENET WG meeting in Paris, France

The group is looking at a number of different solutions. There are routing protocol designs based on OSPFv3, RIPng, RPL, and even simple routing extensions for Neighbor Discovery options. For prefix assignment, the group has two alternate designs, one based on hierarchical DHCP prefix delegation and another one based on distributed operation over a routing protocol.

The picture below shows the architecture for an OSPFv3-based design, providing both routing and prefix assignment capabilities.

OSPF-based home routing architecture

Example Network

The below figure shows my home network, a good example of a network that would benefit from the HOMENET technology. The network has over 200 Gigabit Ethernet ports, 4 kilometers of Cat6 cable, and enables things like my laundry talking to me via Facebook. In other words, it does all the usual geek network things.

One home network

But the important point from the perspective of the actual network architecture is that I had to create a dozen different subnets within my network. I obviously needed my primary internal subnet, but also had to create other subnets for visitor networks, NAT64 networks (these consume two prefixes), and some of my home automation and utility networks were in their own address space for various reasons.

Subnets in the above home network

I'm a geek, and at the beginning I thought I could easily handle all this manually. Then I realized that I had to run a routing protocol to keep the route entries correct. And a tool to monitor what devices I have in my network, as I had lost count. And then I forgot what prefixes were assigned where. It was too hard to keep all those numbers in my brain.

And this was only the beginning of my problems. A couple of months ago I woke up one morning to realize that my ISP had renumbered my entire network. I had to start over. The moral of the story is that even us geeks need automation, let alone our mothers and other people who have no expertise in networking technology.

Implementing HOMENET

I created a prototype to test the ideas of HOMENET. The primary goal was to understand what the real needs were, find out the missing pieces, as well as to see if our specifications for the OSPFv3 extensions were on the right track. I now have a small implementation. The code is unreadable, the design is a hack, and it still misses large parts of the necessary functionality. But it has already given me an opportunity to see if the ideas work in practice.

First off, the technology seems to be working as intended. I'm writing this article in a network configured by the prototype, so it works. And it feels like the natural way of doing things. If we get the technology fully specified, I'd expect other networks to want to use it as well. Corporate networks, for instance, would probably find it useful.

The implementation is capable of automatic configuration of OSPFv3 itself, generating router identifiers for all involved routers, assigning address space in an optimal manner to the entire network, discovering all available DNS servers, and configuring Router Advertisement daemon to advertise the assigned prefixes and DNS server addresses. And since this week, the prototype also automatically configures Ericsson NAT64 devices by making an assignment for the address space that those devices need.

Logs showing how router IDs, prefixes, RAs, DNS,
and NAT64 have been configured automatically

I've learned a number of detailed lessons about the protocols necessary to do this; those lessons will be fed back to the IETF working group. But the main lesson for me was how connected the routing protocol based auto-configuration software is to other parts of the system. Obviously, an OSPF router talks to other OSPF routers. But in this case it has several other interactions as well, illustrated in the below figure.


The first group of interactions relates to where the system gets the usable address space it needs. The preferred source for address space is your ISP, and DHCP prefix delegation is the best way to retrieve address space from your ISP. However, not all ISPs support this protocol, and some users may have to manually configure their address space in one of the routers. From there on the HOMENET technology can distribute the address space to all other routers in the network. Finally, when the home routers are coming up for the first time and if no connection to the ISP has been set up yet, they are in a difficult position. There is no address space to be used, but communication between the different nodes in the network is going to be difficult without addresses that can be used across the entire home network. At this point it might be useful to generate some Unique Local Address space -- a feature of IPv6 -- that can be used until actual ISP connectivity comes online.

Another set of interactions relates to where the address space is used: the address space needs to be configured to interfaces, advertised in Router Advertisements, given to the use of a NAT64 implementation, and so on. In my network I also need some address for servers that represent legacy sensor networks on IPv6.

Finally, even when addresses have been assigned and packets are routed correctly, the end user will not be happy unless hosts can resolve names to addresses. For this to happen, the hosts need to be told where the DNS servers are. This can be done via adding DNS server addresses in options to Router Advertisement messages. But the auto-configuration system still has to figure out where the DNS servers are! There are couple of different approaches to this. One straightforward approach would be to run a server on each router, resolving names through the global DNS root system. I have chosen to use a different approach, where I attempt to discover existing DNS servers from my ISP or from my own network. I use the DNS Discovery Daemon (DDD) for this task. There is an interesting complication, however, in that IPv6-only and dual-stack networks are different in some respects. First of all, in a dual stack network the configuration of IPv6 DNS servers is often not absolutely necessary, as the IPv4 DNS servers can serve IPv6 content. But things get more complicated with network tools like NAT64, because they involve translation of DNS results through a technique called DNS64. Given this, a name server that acts as a DNS64 is something that you want to use behind a NAT64 device, but not elsewhere in the network. DDD uses an advanced technique for probing the name servers to determine whether it is performing normal or DNS64 operations.

Some of these interactions have interesting aspects that require further work. The assignment of DNS servers is one such area. Timing the start of the ULA generation process is another one. We will be addressing these issues in the coming months.

Implementation Experiences

The OSPFv3 auto-configuration parts were very simple to implement. The prefix assignment was not as trivial to implement, but still relatively easy. These new extensions of OSPFv3 are in the order of two thousand lines of code, so they should be relatively easily be added to any OSPFv3 implementation. Assuming the implementation has been made reasonably extensible.

However, OSPF itself is a very complex and difficult protocol to implement. I chose to implement it from scratch. How hard could it be? It turned out that it is very hard. I do not yet have a full implementation, among other things the actual route computation is still missing even if the flooding process is complete. In any case, any sane person would start from an existing implementation and would just add the new parts. Oh well. I have learned a lot from routing protocols with this exercise, which was part of my goals.


HOMENET is an interesting piece of technology that has promise to make the configuration of home and other networks much simpler in IPv6. The working group at the IETF is in an active design phase; the participation of all interested parties would be welcome there. There are also several implementation efforts under way, not just mine. I would say, however, that we are still in the exploration phase as we keep discovering what this technology could do. The specifics of the protocols will for sure keep changing. If you have feedback on what kinds of things should be auto-configured in networks or how we should go about it, let me or the working group know!


This blog entry is based on my presentation at RIPE-64, Ljubljana, Slovenia, on April 19th, 2012. See the slides for more information, or go the web page for the HOMENET working group at the IETF. I'd also like to thank my colleagues and various IETF people for interesting discussions in this problem space: Mark Townsley, Ray Bellis, Michael Richardsson, Ari Keränen, Lorenzo Colitti, Fred Baker, Lee Howard, Wassim Haddad, Joel Halpern, Jan Melen and others: thank you. I'd also like to thank Ericsson for letting me work on this (among the thousand other things :-)

HORD, my routing daemon is not open source, at least not at this time. But DDD, the DNS discovery part is. Look here for the details.

IPv6-capable ISPs and Routers

Note: Regarding IPv6-capable ISPs: there are plenty, check out Comcast in US, Nebula in Finland, or Mobitel in Slovenia for instance.

There are also plenty of IPv6-capable routers, my personal preference is Linux-based small PCs but you can also check out commercial models from Netgear, Cisco, and others.

Start of the HOMENET implementation effort in Christmas 2011

Photo credits (c) 2010-2012 by Jari Arkko

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