Wireless Communication for the Internet of Things

On last Thursday 11 of March, the University of Surrey held an event called "Wireless Communications to Enable the Internet of Things". This event was organized by the Wireless Sensing Interest Group of the Sensors & Instrumentation KTN and the Electronics KTN. The sessions featured the view of industrialist, academics and reports on existing deployments. I attended this event as a researcher from the University of Cambridge.

The event was organized around four sessions. The first session introduced the three main technologies that are considered the future of cellular communications, namely GPRS, 3G and LTE. The first two were introduced by ST Ericsson, and the talk focused on the key considerations for a communication project. It concluded that 2G and 3G networks are now pervasive and will stay for many years, and that they are best suited for environments which do not require massive amounts of data transfer such as machine-to-machine (M2M) applications. The second talk was given by NEC, and introduced LTE as the next generation cellular technology that will enable the Internet of Things. LTE was compared against HSPA+, and some NEC's ICT solutions based on this and other technologies were also presented.

The second session focused on issues in communications and location based services. Two companies presented: Libelium, a Spanish wireless sensor network start-up, and HW Communications, a British company dealing with mobile wireless communications. Libelium compared the 2.4Ghz, 686Mgh and 900Mhz bands for chips running the ZigBee / IEEE 802.15.4. Some test results were presented and the best configurations for each band were outlined. HW communications talked about location services, and the pros and cons of technologies such as cellular network positioning, triangulation and GPS.

The third session presented two implementations of short-range wireless networks. The first implementation, from the company Zarlink semiconductors, dealt with health-care implants and how to solve problems related with wireless communications. A solution based on a double frequency, single antenna implementation was presented, where a 2.4 Ghz link is used to wake up the device and the medical band MICS at 402Mhz is used for data communications. The second implementation was more of an academic introduction to energy storage technologies by Imperial College London.

The fourth and final session focused on solutions for large scale Wireless Sensor Networks. The first talk in this session introduced the implications of embedded devices and the Internet of Things in urban environments. The concept of Web of Things was introduced as hyperlinks given by physical objects, which is somewhat different from what other initiatives understand by Web of Things. The seconds and final talk on this session was about security and key management in Wireless Sensor Networks.

In my opinion, this event brought much about technologies and applications but little about what the Internet of Things is. It is probably not a good idea to put "Internet of Things" in the tittle without defining what is understood by it. Obviously, the event was oriented to the believe that the IoT is the same as ubiquitous computing or similar terms, but I think is quite clear that both concepts should not be same, because otherwise there would be no need for a new term. Most of the talks were useful to understand the advances in technologies and how companies and academia are aligning towards the future of wireless communications, but I gained no new knowledge on how wireless communications are going to enable the IoT, which is the main title of the event. This is not a new feeling for me though, since so many times I am hearing people talking about the IoT when they either don't know what the IoT is or its implications, or they think that is understood that the IoT is a something that everybody knows (when obviously, they don't know or don't agree on the same definition). Therefore this events has reinforced my believe that a globally agreed definition of what the Internet of Things is should be realised, or we will go deeper and deeper in the buzword hole that I talked about a while ago.

Fun with port forwarding and SSH

No matter if your office computer has a public IP address, if you are part of a big organization, that computer will most likely be behind some big firewall, effectively isolating the internal network from external connections. In many occasions, however, the system administrators will not completely disable access, and will enable a gateway machine as the means for bridging connections from outside to the inside of the network. This gateway computer, nevertheless, tends to be quite limited, and most probable only allows secure connections via SSH (secure shell). Well, despair not, because giving you SSH access means that you could use that connection to piggyback other connections to other services inside any computer in the network, provided that the servers where those services are locates also have a SSH server. This is normally called tunnelling and port forwarding.

On the last couple of years I have lived with the inconvenience of having no access to my office computer. For some reason, I didn't care about this tunnelling business, or I thought they were rumours or that it would be too difficult to implement. How wrong I was. Obviously it has taken a couple of days, although probably I have only scratched the surface of what is possible. But now I am able to access not only my desktop computer remotely (with a display session and all), but also other services that I use inside my work's network that I normally need for my work (e.g database servers and subversion repositories). I will now briefly explain what it all boils down to.

Let's call the machines involved in this system client, gateway and target. We will use these names as addresses to those machines as well. Obviously, the first you need is an SSH client in client, and an SSH client/server in the other two machines. You also need an account in all those machines. First, lets make a key for the SSH connection between client and gateway so that you will not need to enter a password every time:

client:~$ ssh-keygen

Leave all the values to default and use no password (simply press enter). Now, copy the key to gateway:

client:~$ ssh-copy-id -i .ssh/id_rsa.pub user_gateway@gateway_address

Now you can just ssh to gateway without using a password. Next, you might want to connect directly to target without having to SSH in gateway and from gateway to target. For this, you can set up a simple rule at your ssh_config file (normally in /etc/ssh/ssh_config) to forward text directly to targer through bridge:

Host symbolicName

HostName target

User user_target

ProxyCommand ssh user_gateway@gateway netcat -w 1 %h %p

Now you can "SSH symbolicName" and you will directly be prompted for the password of your target machine. But how to forward service ports? Well, with a command like this:

ssh -L port_client:target:port_target user_gateway@gateway

That command will take any connection requested in client to port port_client and will forward it to target to port port_target, using gateway as bridge. So the key to getting basically anything to your target machine is using localhost as the destination address when requesting the service, using port_client as the port (which obviously doesn't need to be the same port where the service is actually running on target). Confused? Right, is confusing at the beginning. For example, let's say that you have a SVN repository inside your work network, and when you are at your office computer, you use something like svn+ssh://machine_with_service/path_to_svn_repos as the URL to your service. In your computer outside of the work network, you will use the following svn+ssh://localhost/path_to_svn_repos, taking into consideration, of course, that the target machine we have been talking about before is machine_with_service in the example. Other service you can run like this is, for example, NX client and server, so you can get a graphical session of your office machine at home. Isn't that great?

All this can be done in Windows if that happens to be the OS that you using in your client. For that, you can use Putty. Putty has an option called "tunnelling", and you need to add your client's port and the target:target_port on this option tab for each service that you want to be forwarded. Then you only need to connect to the gateway machine in the usual way and there you go. Of course, the Putty window needs to remain open while you need port forwarding. More here and many other places on the net.

And this is all. Have fun with port forwarding too!

Note: Many thanks to Hugo for teaching me most of this!

Buzzwords

Buzzwords are a disease. They take over beautiful concepts and contaminate them with fabricated hype and empty promises. They spread their influence, first as innocent curiosity about innovative ideas and then as viral gibberish eager to be ignored and forgotten. Buzzwords eventually kill the concept, flooding the public with excessive and misleading publicity, until nobody wants to know or cares what it all actually meant. And so dreams die, suffocated by the burden of what could, wasn't and was pretended to be.

Buzzwords are, however, necessary. They attract attention and make people care. Without attention and care there are no desires to know more. Without those desires there is no investment, and without investment there is no progress. Without progress, concepts eventually die and are forgotten.

In the world of information and communication technologies, buzzwords create a delicate balance between the increase interest about a new research area and the road to damnation of unreachable funding. Interestingly, it seem impossible to control the buzzword influence, and with the increase of the buzz, news, conferences, blogs, books and interest groups spring eager to get a piece of the hype pie, spinning off new publicity waves that retrofit in the system in an apparent infinite loop. Concerning about the buzzword effect seems, therefore, useless. If it shall kill, it will, and should you find yourself in the middle of the storm, there is little to be done rather than try to secure funding while you can. With luck, that will give you some experience, publications and even prestige, and will help you to move towards the next research in your academic career.

Although concern about the buzzed concept's destiny seems futile, one can venture in identifying certain attributes that signal a disaster to come. It is so that the most powerful but deadly buzzwords are those that are too general to actually mean anything, letting the public imagine what is the concept behind them. Wide abstract ideas may seem beneficial at first because they increase the interest base with hardly related imaginative concepts. However, this fuzziness will eventually dilute the original meaning, propelling a devastating wave of public disappointment, either because what they thought it was it was not, or because what they thought it was could never be realised, weakened by the adulteration of uncontrolled brainstorming. I would therefore advice caution: don't let yourselves be carried away by the excitement of the public using buzzwords related to your research. Maintain your pure vision of what you have imagined, and argue against those who attempt to throw everything into the same sack. Don't succumb to the temptation of adulterating your ideas aiming to gain traction in the community, for that will bring in the long run counter-productivity and eventual apocalypses.

Since I purposely avoided naming specific buzzwords that match my argumentation, I invite the reader to name some. Which are the ICT buzzwords that you have come to love and hate?

Attending DECOI 2009

From February 23 until February 27, another researcher and me attended the 2009 International Workshop on Collective Intelligence and Evolution (DECOI). The main reason to participate in DECOI 2009 was too gain some more insight in multi-agent systems regarding the SAHNE project in which we are both involved. The venue for this year's workshop was in the Lorentz Center in Leiden, The Netherlands. Leiden is a beautiful small town around 30 Km from Amsterdam. Unfortunately, the work was such that we couldn't make it to see the town in day light.

DECOI is more a “school” than what is traditionally understood as a workshop. The program was distributed in key-note presentations and work in projects. The project details were given on the first day of the workshop, and each group of 4-6 people had to choose one of such projects to work on for the rest of the week. My group chose the project titled “Learning, communication and establishment of norms in pedestrian crowds”. This project was first introduced by Anders Johansson and, for the time being, the slides can be found here. In his lecture, Dr. Johansson introduced a basic model of pedestrian behaviour in crowds. The objective of the project was to incorporate “smarter” behaviour in the pedestrians so they would negotiate better how to avoid getting stuck in groups of pedestrians that are trying to get to the same place at the same time. The project involved first to theorise how this intelligent behaviour could be accomplished, and then to develop a simulation that showed how smarter pedestrians (agents) could obtain better results.

The simulations were developed with NetLogo, which is a Java-based multi-agent simulation tool that deploys its own language. None of the team members had used this tool before, so we not only faced the challenge to first write the simplistic model that Dr. Johansson presented in order to build on top of it, but also how to do this using a programming tool that we didn't know. For this reason, we spent 3 days learning and building this basic model, and the last two days writing the new smart features and gathering results. The features that we implemented were:

• A grouping factor, that encourages groups of “friends” to get closer to each other on the search for the goal.

• A learning factor, that tries to remember which direction worked best in the past and use it in the decision making

• A rumour factor, which is spread by those pedestrians which are stuck in a crowd and that tries to prevent other pedestrians to go towards the direction of the crowd

The simulation takes place in a room with two entries and one exit. The entries and the exit are separated by doors whose position and size can be varied. The objective of every pedestrian in the simulation is to get to the exit door as soon as possible. In order to avoid overlapping with walls and other pedestrians, a set of “forces” in the form of vectors are implemented and sum to the gradient force that attracts pedestrians towards the exit. A naïve approach would generate a crowd that tries to approach the exit through the shortest path, getting stuck in the intermediary door. All the smart features that we implemented helped one way or another to increase the performance of the system. A summary of the strategies and results can be found here . A Java applet accessible here allows you to play the simulation directly from a web browser.

Aircraft management with multi-agent systems

Here at DIAL we have a project sponsored by The Boeing Company to develop a multi-agent system for emergent behavior in aircraft configuration control. In this project, codenamed SAHNE (Self-serving assets for higly networked environments), agents are the virtual counterparts of aircraft spare parts, and are autonomous in terms of decision making regarding their life-cycle. In SAHNE, we put special emphasis in the process of part replacement, and develop a fully autonomous system in which the agents detect when the parts need to be replaced (e.g. expiration date on life bests, worn out of mechanical components, etc) and initiate and coordinate the parts procurement. This later process involves finding suppliers, ask for quotes on the replacements and decide which supplier will better supply the needed part for an specific aircraft.

My main role in this project is to assess the integration of sensor data into the agent decisions. Until now, the development of the platform focused on creating a certain degree of functionality based on static data and software agents. For the second year of the project, we will use actual spare parts and capture technologies to feed real-time data into the software agents. The project is scheduled to run until 2010.

RFID and Caterpillar

I recently participated in the development of a demo scenario for a project proposal with Caterpillar. The idea of the project is to use RFID tags into CAT engine parts to ease the maintenance of the machines. When the engine of the vehicle is turned on, the ID of all the engine installed parts would be collected by means of RFID readers inside the engine casing. The installing time of the parts and its the number of hours of operation would be stored in a engine master-tag (EPCglobal Gen2 tag with extended user memory bank). The life part information at the vehicle start-up would
be compared with the information stored in the master tag. When a part is replaced, a discrepancy would be detected and the operator would be warned. A history of replaced parts would also be stored on the master tag. By means of this mechanism, we expect for vehicle maintainers to be able to know when parts have been replaced and how long the operation of a certain part has been. This mechanism is aimed to replace the current manual practices that are prone to human error and inaccurate information. Furthermore, even if the engine block is replaced, we still carry the information on the master tag, wherever that engine goes. That can help end-of-life part management. For example, we can know exactly which parts can be reused and which ones should be disposed.
To demonstrate these ideas, I helped to develop a software that simulates the engine start and then reads parts and mater tag. It then compares the information and warns the user about new parts installed, removed or replaced. It also updates the engine master tag. We then had a one-day field trip to a CAT research and development site nearby Cambridge (UK). There we installed tags and readers and tested the software in a real CAT tractor.




I must say that the trickiest part of all was to program the master tag update, because the tags we were using didn't have much memory to play around with.

Eclipse plug-in for WSN

Spring last year (2006) I was given the job to make an Eclipse-based IDE to program, download and debug Wireless Sensor Network nodes. At that time, I didn't know very well what Eclipse was. Well, to be fair, I had used it several times before, and I was starting to use it for my research for other things (a middleware monitor, which I will talk about in some other occasion). Anyway, I had certainly no idea about the Eclipse plug-in system. You see, the whole Eclise IDE is based on plug-ins that use and create extension points. With this extension points, you can do things such as adding an icon to the tool bar, creating a new code editor or just adding a new view with pretty much whatever you like.
Back then, other people have already done similar things. However, since we were (and are) building our own platform, prof. Kim felt that we had to have our own programming software to complement the kit (and, anyway, is not that the guys at ETRI were going to borrow us the Java code). The most interesting of all is that our laboratory did participate in 2004 in building this other platform. But anyway, that's another story. Nevertheless, it seems that prof. Kim also felt that I was the best option for coding the new IDE and make it look "good".
Summer past and I really didn't do much. I was into my research, and although I read some documentation to understand how the plug-in system works, I didn't really code anything. Eventually, pressure from some exhibition and others (such as prof. Kim :) made me take it seriously, and in less than one month and built a prototype that could do just that (well, more or less): program in C (CDT plug-in) and compile (winavr), download to the target board (avarice) and debug using a JTAG-ICE (also avarice and gdb). It looked (and still pretty much looks) like this:



It was quite tricky to get some of the functionality, and even now, the IDE is basically a prototype which just works with one kind of micro-controller and only downloads with a JTAG-ICE. I think I should mention that I was not free to do whatever I liked with the OS source (the WSN operating system that we are also developing), and whatever I did to the source tree, it had to be compatible with the "old" way of coding (namely, make a source file and use the command line to compile/upload the image to the sensor board) After the initial version, I tried to make some improvements. The first concern was that the current module selection system was based on a specific version of the OS. This is bad, because new boards and new chips bring the need for new drivers and the like. Also improvements on old modules need sometimes to be offered as a choice (eg. for testing). So my solution was to build a XML file for each main board and sensor board that we developed, specifying the name of the module and where the drivers in the source tree are located. Then, in the "new project" wizard, a user could choose first the main board, which will open the choice of associated sensor boards and so on. Unfortunately, although I began coding this, I had other more urgent things to do and finally I never completed it. Now it seems that a new post-Doc student will take care of my "creation". I hope he can understand my coding :)