Friday, May 25, 2012
The event is supposed to promote IPv6 transition, and hopefully, to start a chain reaction. I think that everything has been already said about IPv6 and its adoption process, but I'll repeat once more, that it has to be done. The sooner the better. There are many technologies waiting just around the corner, which can be developed only with larger address pool and end-to-end connectivity provided by IPv6.
The action has a very nice badge and catchphrase, but it doesn't describe the titanic amount of work that has to be done by network engineers, webmasters, programmers, and help-desk employees. The costs of this transition might be enormous. But still it has to be done.
Thursday, November 17, 2011
Recently I've made some tests how to connect to 6LoWPAN nodes in home LAN environment, using ordinary PCs. I've been using Grinch Border Router described in previous entries. The main aim was to use no static routes to send traffic to wireless nodes - I've tried to use only Router Discovery.
In general, avoiding manual configuration of networks is a hot topic nowadays - not only in Wireless Sensor Networks. There are many problems to solve:
- Prefix delegation
- Service discovery
- Interaction with sleeping or mobile nodes
The problems above are also present for the home LANs. The basic RFC4861 Neighbor Discovery is quite limited and it's hard to achieve a fully functional LAN with Internet connection using only that (without DHCP). However most new solutions are not supported by common everyday devices found in LANs (like PCs or smartphones). Grinch Border Router is no exception to that - it is a very basic device, and with 8kb of RAM it is not capable of any complicated techniques.
LAN physical setup
I've assembled a simple Home LAN as a testbed. Physical setup of the testbed is shown on a picture below - as you can see it is not very realistic (for a typical household) - as it includes a separate switch and wireless router - I'll explain that below:
The testbed contains two PCs, D-Link 5-port switch, Grinch Border Router, Atmel Raven board and a D-Link DIR-600 wireless router. Test LAN is based entirely on the switch. The wireless router is used only for IPv6 tunnel. At the beginning I planned to use the router for my LAN instead of switch (it would be a more realistic setup). However I decided to add a separate switch because of two reasons:
- IPv4 traffic - wireless router is used for my primary IPv4 internet connection - and Grinch has no hardware packet filtering.
- D-Link DIR-600 has some undocumented IPv6 ability. In theory it's IPv4 only, but it sends Router Advertisements, and I was concerned that it would disturb the experiment.
LAN logical setup
Logical setup of the testbed is shown on a picture below - it is much more realistic than the physical one:
LAN contains one host (one of the laptops) and two routers - one connected to the IPv6 Internet and one connected to Wireless Sensor Network. On the WSN side there is a single node with HTTP webserver (Raven) and RPL is used for routing. For the IPv6 Internet connection Freenet6 GoGo Client is used - I have no public IP therefore normal tunnel won't work. Through GoGo client /56 prefix is received. LAN uses the first /64 subnet in the prefix, WSN uses the second one.
When aiming for a zero-configuration connection to WSN nodes in home LAN, one of the main problems is choosing the right router for outgoing transmissions. In LAN like above, a host gets Router Advertisements from both WSN and Internet routers, and saves their addresses in Default Router List. When IPv6-enabled host has more than one router in its Default Router List, it selects the router for outgoing traffic in round-robin fashion (RFC4861). In typical IPv6 operation it's not a problem - if host chooses non-optimal router, the router sends a Redirect message to the host. Redirect tells the host to use other router for that particular destination. Host saves this information in its Destination Cache and next time it sends the traffic to the correct router. Routers need to know about each other and about accessible routes to send Redirects. Normally routers use some kind of dynamic routing protocol to inform each other about known routes (e.g., RIPng).
Contiki OS (used by Grinch border router) doesn't support redirects, or any typical routing protocols. It's not a big technical problem, as the simplest routing protocol - RIPng can be certainly operated by a router like Grinch (maybe with 16kb of RAM). However it's not the only problem. Typical IPv4 home routers don't support any kind of routing protocol - they are simple gateways which send traffic to a default route. There are no "typical IPv6 home routers" on the market yet - only "IPv6 enabled routers", but existing guidelines for home routers don't contain routing protocol support as a mandatory functionality (RFC6024). Windows operating system also doesn't support any dynamic routing protocols in Home Edition. At the moment probably the only IPv6 home router solution with RIPng support are special OpenWRT and DD-WRT builds. It might in a couple of years lead to a situation where Internet of Things home deployment is hampered by lack of proper router functionality.
Partial solution - Route Information OptionsI've decided to look for another solution and found a nice candidate. RFC4191 contains an extension of original Neighbor Discovery which allows adding Route Information Option to Router Advertisements. Router can use this option to inform hosts on a network about routes it knows about. However the router should not use Route Information Option to send its whole routing table to all hosts - it should only advertise specific, important routes. The WSN border router is exactly such case - it should include the route to the WSN in its RAs.
- doesn't require any configuration on hosts
- allows hosts to send traffic to the best router straight away, without waiting for a redirect.
- no need for a dynamic routing protocol
- doesn't provide WSN-to-Internet connectivity (for that routing protocol is required)
- not supported in most systems (see below)
Route Information Options for Grinch
Adding RFC4191 support to Grinch was quite trivial - the router only has to send Router Advertisements with an additional bit flag, and Route Information Option. The implementation is compatible with multiple interfaces extension added to Grinch earlier. I've added another structure that holds all information necessary for RIOs (uip_ds6_route_info). Because of that the code is not very well optimized for RAM usage. It is possible to implement a more efficient approach, that would use pointers to prefixes held in Prefix Table or Routing Table, but Routing Table doesn't contain lifetime necessary for the RIO, so still some kind of additional structure is necessary. Other solution is to change Contiki Routing Table to contain route lifetime - it's used by RPL anyway.
Modified code is available in Git repository::
I've run some tests with RFC4191 enabled Grinch. The border router was set to send Router Advertisements with Prefix Information Option containing LAN prefix, and Route Information Option containing WSN prefix. The LAN prefix was also advertised by the laptop running freenet6 client ("Internet router"). Grinch was tested with four kinds of devices - results below:
- Laptop with Windows XP - IPv6 has to be enabled on the laptop before any experiments. Laptop receives modified Router Advertisements from Grinch correctly and adds a route to WSN to its routing table. It's immediately possible to ping Raven board after that. However Windows XP doesn't support IPv6 DNS, so it's impossible to connect to ipv6.google.com even after adding DNS server manually. Fail.
- Laptop with Ubuntu 11.04 - Internet connectivity works after adding DNS manually. However there is no RFC4191 support in Ubuntu. Fail.
Update (April 3, 2012)
Ubuntu 11.10 has RFC4191 support in default build. Route Information Option support is disabled by default. To enable it you need to add two lines to your /etc/sysctl.conf:
net.ipv6.conf.eth0.accept_ra_rt_info_max_plen = 64
- Android 2.2 - for that test I modified the LAN physical setup, and used wireless router instead of switch. Then I connected the phone to WLAN using WiFi. My phone received IPv6 address but it had no applications that could use IPv6 - even ping!!! Also it didn't support RFC4191. Android really needs better IPv6 support. Fail.
- Laptop with Windows 7 - Internet connectivity works after adding DNS manually. Also laptop receives Router Advertisements with RIO from Grinch correctly and adds a route to WSN to its routing table. However the network is not very stable - pings are sometimes lost for no reason.
Further tests with Windows 7
After playing with the network a bit more I've determined that two more details in Grinch software had to be changed:
- Neighbor Advertisement Router Flag - in Grinch NAs it was set to zero (default for Contiki). That caused the laptop to remove all entries related to Grinch from the Routing Table. It caused periodic "flapping" of the routing table - sometimes pings worked, and a while later they didn't. After changing the Router Flag to 1, the flapping behavior disappeared.
- Router Advertisement Router Lifetime - any non-zero value made Grinch to be added to Default Router List on the laptop. It sometimes caused the Internet traffic to be directed to Grinch (with no Redirect ability). This could totally break down Internet connectivity for the laptop. After changing Router Lifetime in Grinch RAs to zero, it is no longer considered a candidate for a Default Router, but Route Information Options still work.
With these changes the solution can be considered successful - I've tested it with my wife's new Windows 7 laptop (with vanilla OS), and it connected to Raven without any problems. Connection to ipv6.google.com required manual DNS setup. Both changes are included in the Git code above.
Thursday, September 29, 2011
In my last post devoted to Grinch Border Router I described how to forward pings through the router. However the router wasn't capable of sending much more than standard size pings. It wasn't possible to route any IPv6 packet larger than 152 bytes. I blamed it on Zigbit's limited memory, and decided to get a new module with Atmega128RFA1.
However in the meantime I had some problems with my DSLR and decided to try, and repair it myself. I failed miserably and damaged the power board of the camera, and had to send it to the professionaI support. I had to pay for the new power board, and had no cash for the RFA1 modules, so I decided to work on the Zigbit a little bit more :) . It quickly turned out, that Zigbit has enough memory for everything. I just had to turn off the webserver, and I managed to fit the full 1280-byte buffer for the packets. I also had to correct some bugs:
- Debug comments - debug comments in AVR can be put either into flash memory, or RAM memory. RAM is faster, but very limited, so I was using primarily flash comments. This significantly slowed down the microcontroller, so that it was not possible to send 6lowpan fragmented packets. After turning off all debug comments the border has enough processing power to forward packets that need fragmentation.
- ENC28J60 driver bug - the driver has a config parameter MAX_FRAMELEN which limits maximum packet size. In my first build it was set to 500 bytes. It made HTTP communication impossible.
- In my first build the interrupts were turned off when receiving packets from ENC28J60. I changed it to turn off interrupts also when sending packets. The stability of the Grinch Border Router increased greatly (works for several hours without freezing).
After these changes the Grinch has become quite usable as a border router. It is possible to access Raven webserver from the PC almost every time. Also large 1232 byte pings are forwarded without problems. The router is still not ready for the deployment, but it's perfectly ready for testing of wireless sensor networks.
Next thing to do is the automatic discovery of Grinch in the network. For that Router Advertisements are needed. I still haven't modified this part of Contiki to support multiple interfaces, but it shouldn't be hard. I also plan to run some long tests of the router to see how stable it is.
Wednesday, June 8, 2011
Contiki OS does not currently support multiple interfaces, but it is possible to deploy a border router on Contiki with serial interface for uplink. Depending on the hardware platform it can be done in two ways: either with special software called tunslip6, or with RNDIS device driver. Both solutions need a running PC with Linux or Windows, which makes them inconvenient for simple home automation solutions.
Because of that I decided to develop a simple border router with Ethernet interface. After asking on Contiki mailing list I discovered that nobody is actively working on a multiple interfaces support, so I decided to add it myself. First results of ping tests are presented below - I wrote a simple tutorial in a spirit of Contiki Atmel Raven Tutorial.
HardwareI assembled a quick prototype board with 15.4 and Ethernet interfaces. I called it "Grinch" (I did most of the soldering during last Christmas). The board is based on the Zigbit module. Zigbits contain Atmega 1281 microcontroller and AT86RF230 radio transceiver that communicate over SPI. For Ethernet I chose Microchip ENC28J60, very simple Ethernet controller with SPI interface.
Last year I designed and ordered some breakout boards for the Zigbits with goldpin connectors, and ENC28J60 is sold in DIP packages, so I chose not to use any SMD components in my project. I used simple prototype board with greenwire connections. I soldered the components ad-hoc without a schematic, but later I made some simple drawing in Eagle to document the project (link). Below is the photo of the board. Zigbit has a serious drawback - it has only 8kb of RAM, and it limits the number of neighbors and routes that can be maintained. Also it leaves very little room for the webserver (which is very useful for debugging). Also 6lowpan fragmentation is not possible - there is no space for buffers. For any future border router projects I strongly recommend Redwire MC13224 or Dresden Elektronik Atmega128RFA1 modules.
Working Grinch Border Router is shown on a picture below: After assembling the board it is good to test it using some simple IPv4 AVR software unrelated to Contiki. Tuxgraphics is a very good page with test examples.
SoftwareThe mod contains the following additions to the github contiki-mirror repo:
- ENC28J60 driver for AVR microcontrollers
- Multiple interfaces support
Multiple interfaces support is implemented in a very straightforward way - all interface-describing structures defined in /core/net/uip-ds6.h are changed into arrays of structures instead. All functions are modified to get along with this change. The modification is not very complicated, but code needs to be fixed in numerous places. Most code changes are located in the /core/net directory. The more serious code changes are:
- Initialization - contiki-conf has to be changed to support two interfaces
- Link-layer Address Option construction - Ethernet and 802.15.4 link-layer addresses have different length
- Periodic processing - to keep the code simple single timer is used for all interfaces
- Common functions operate on the interface, which id is saved in a uip_last_active_interface variable (current name is not very good). The value of this variable is changed whenever a packet is received or meant to be sent. For example ping reply is always sent to the interface where the request came from.
- Interface specific functions operate on hardcoded interface identifiers - for example RPL packets are always sent to IF_RADIO interface, and ENC28J60 driver operates only on IF_FALLBACK interface.
Test overviewThis demo is based entirely on pings - with no application data transfer. I tried a simple test with HTTP, but it failed completely - the reason for that is probably the limited capability of Zigbit to fragment IPv6 HTTP communications (they are normally too big). I plan to use CoAP later but I have no working code for Raven yet. However the ping test can verify most of the properties of the new multiple interfaces capability.
Compiling the codeBinaries can be compiled using the following commands:
All examples have proper Makefile.target files - there is no need to specify target from command line. Note that AVR Raven is also compiled with multiple interfaces support, but number of interfaces is set to 1. Installing the software on Raven is shown in the Contiki Atmel Raven Tutorial. Installing the software on Grinch is similar - but it is dependent on the physical layout of the board.
Addressing and Windows setupThe example uses RPL routing on the 802.15.4 side and static routes on the Ethernet side. Ethernet IPv6 prefix and RPL prefix are both hard-coded inside rpl-border-router-eth.c file. Handling of these two prefixes is different - IPv6 prefix makes the node assume, that all addresses with the same prefix are on link. Because of that, this type of prefix doesn't work well for radio links, where some nodes with a matching address can be out of range. Inside rpl-border-router-eth.c file there is a quick hack which adds the IPv6 prefix only for IF_FALLBACK interface. To run the test it's necessary to add a Global IPv6 Address for the PC Ethernet interface (otherwise pings from Raven to PC won't work), and to add a static route to Raven. Here are the necessary commands for Windows 7:
First you have to find the name of the Ethernet interface on a PC. It can be checked under Network->Properties->Network connections: As you can see on my PC there are two network interfaces - one of them is WiFi and the other one is Ethernet. The name of Ethernet interface is "Połączenie lokalne" (I have a Polish version of Windows 7 - don't worry your name will be normal :) ). Now it's good to right-click the Ethernet connection and uncheck all fields except IPv6:
Windows displays the information about interfaces. The result below: As you can see, "Połączenie lokalne" has no IPv4 addresses and one IPv6 address fe80::21e:33ff:feae:63a8%11 . This is a link-local address, and it's not enough for the test. We have to add a Global IPv6 Address. We will use a prefix aaaa::/64 and host address the same like the link local interface. You can use a different address but you will have to set it in:
in a next line after
(otherwise you won't be able to ping PC from Raven). To add an address we will issue a command:
netsh interface ipv6 add address interface="Połączenie lokalne" aaaa::21e:33ff:feae:63a8
After address is added we can use ipconfig once again to verify the address. Next we have to add a route - otherwise the PC won't know that it can reach Raven through border router. We will use a following command:
netsh interface ipv6 add route interface="Połączenie lokalne" aaaa:0:0:1::/64 fe80::aa:bbff:fecc:ddee
By using this command we inform our PC that to send packets to all addresses with aaaa:0:0:1::/64 prefix, it needs to send packets to a MAC address which matches the link-local address fe80::aa:bbff:fecc:ddee (it is a link-local address of the Grinch). To resolve the MAC address, PC automatically sends Neighbor Solicitation packet (it's part of IPv6 stack). The outcome of the add operation can be verified with the command:
netsh interface ipv6 show route
Running the test
CMD FilesWindows command line throughly sucks. It doesn't remember previous commands like in Linux, and it's tedious to enter all the commands from keyboard each time. To speed up the testing I suggest saving individual commands in text files with .cmd extension (for example pngr.cmd), inside your user directory. This way after your command line starts up, you are in your user directory, and you just have to type the name of the file, not the full command.
Pinging the Grinch from PCYou can ping both global and link-local address of the Grinch - it should reply in both cases. Plug in the power and Ethernet cable and type:
ping -6 fe80::aa:bbff:fecc:ddee
ping -6 aaaa::aa:bbff:fecc:ddee
My typical response time is 4ms. First ping almost always hits timeout - during this time PC performs address resolution.
Pinging the Raven from the PCAfter powering the Raven up it will play some tune - funny, but not when you're coding at 2AM :) . To succesfully ping the Raven we need to know, that Grinch has an RPL route to it. The route should be established in 15-20 seconds after starting the Raven. We can check it using webserver on Grinch. Open your web browser and type in address of the Grinch, like on the picture below. If the route exists it will be displayed on the webpage. After that you can issue a ping command:
ping -6 aaaa::1:1:2:3:4
The Raven will cheerfully beep after receiving ping, so you will immediately know if you're successful. My typical response time is 17ms.
Pinging PC from the RavenTo ping the PC from the Raven we also need an RPL route to Grinch. Ping is initialized from Raven LCD menu - basically you have to click the little joystick switch twice to the right. Successful pings will also be confirmed with a beep.
- DAD packets for Ethernet interface are not really sent, because Ethernet link needs a second to initialize, therefore uIP always considers DAD as successful. I don't have a good idea yet how to fix this bug, but it's almost harmless. DAD for 802.15.4 are sent properly
- Some comments don't include interface ID - it's not really a bug, just an inconvenience when using RS232 debug.
- When Grinch Border Router is turned off and turned on again, it doesn't register a route to Raven - it is some RPL issue and not a purpose of this tutorial. Remember to power up both Grinch and Raven simultanously before running the test.
Tuesday, March 29, 2011
First lecture was given by Carsten Bormann, a co-author of "6LowPAN The Wireless Embedded Internet". The presentation contained many slides from that book actually. Prof. Bormann briefly explained the 6LowPAN Header Compression, Packet Fragmentation and Neighbor Discovery. These techniques are essential for running IP over 802.15.4. There are still substantial changes going on in these areas - for example early methods of Header Compression (described in the book) were obsoleted because of inability to compress global prefixes (the biggest part of the network traffic).
Second lecture was on routing in low-power and lossy networks (LLNs). It was delivered by JP Vasseur, the chair of IETF Roll group. The main topic was RPL protocol - new, specially designed protocol for routing in WSNs. The protocol looks completed at the moment, with no bigger issues to resolve. However the relationship between the RPL and normal 6LowPAN Neighbor Discovery looks very shady to me - both techniques seem to overlap in great deal. Even now Contiki RPL implementations run with ND switched off.
Third lecture, by Zach Shelby was devoted to Constrained Application Protocol. CoAP also slightly evolved since I first learned about it in Finland. For example SUBSCRIBE method was changed into an optional observation mechanism. What surprised me the most was the lack of enthusiasm of some of the participants (presumably other IETF members) about introducing a new protocol. It seems that IETF "rough consensus" is really rough sometimes.
Fourth lecture was done by Apple researcher Stuart Cheshire. He was talking about IP networks used to replace other short range connections (like USB) with no configuration necessary (service discovery performed through new technique - multicast DNS). The lecture included simple technological demo, that clearly shown Apple's philosophy in design: it worked instantly, with no user configuration.
Fifth lecture was given by Adam Dunkels from SICS. Adam explained some Contiki concepts - protothreads, and Contiki MAC, and he did it in great style. It was fascinating to listen about the operating principle of protothreads (almost as if it wasn't some high level C concept).
The last lecture was presented by Robert Cragie - ZigBee Alliance researcher. It was really interesting, as the ZigBee Alliance was recently forced (by some US energy related department) to adopt IP in its design. To accomplish that, ZigBee Alliance plans to develop new ZigBee IP "superstandard" based on 6LowPAN, RPL, and other IoT related technologies. Cragie pointed out current weaknesses of that approach - such as overlapping standards, and lots of optional parameters, that can prevent two devices from different vendors from communicating with each other. ZigBee Alliance wants to address these problems by describing exactly which standards and options to use. In my opinion, by developing a uniform IP-based communication stack ZigBee IP can become a real leader in the area in a couple of years.
The meeting was my first opportunity to see how IETF works (although the real IETF 80 meeting started on Monday). Some of the IETF members are true geeks, who remember some long lost Internet technologies, and dispute about every detail and usecase of the protocols. In today's money driven world, this organization seems strangely out of place. But I think that because of that the future of the Internet is in good hands.
Sunday, September 12, 2010
I started by reading tutorials about writing games. In general it's very hard to find a good tutorial about game writing. Game development, like any other technical activity is about layers of knowledge - you begin with some simple functions that do only one thing, but you organize them into bigger structures that can provide complicated results. Most tutorials contain only the basic steps, but tell you nothing about the upper layers. The best tutorial about game writing I found is Philip Hanna's CSC207. It's a university course, and contains many good examples, as well as the game engine written in Java. The engine is written in a very generic way. It allows you to start your own project, but it's never optimized for it - so sooner or later it forces you to write your own engine - but at that time you already know what you want and how to achieve it. Very good teaching trick Mr Hanna!
I started my game using Philip Hanna's engine. At the beginning I really liked writing in Java. It was much faster to write than in C or C++. But after a while I became fed up with it - I had to create getter/setter methods for every variable, and the code was hard to change or read. Later I learned some tricks in the Eclipse IDE which helped a lot - automated refactoring and getter/setter creators. But I still wasn't happy with it. Then I found Python.
Python is probably the best language for hobbyists out there - it's fun to use, reasonably fast (at least I think so), and with quite good support. At the beginning Python webpage scared me off because there is some new version of Python 3.0 coming out, and no library works with it. But then I realised that nobody uses it yet, and everything works with Python 2.6 (it's a risky idea to make language backward incompatible).
I decided to start with Pygame - a library which is basically a binding to SDL library written in C. I read some basic tutorials, and started to port my earlier Java code to Python - mostly that meant holding DEL button for a long, long time. Python code is much shorter and easier to read than Java code (however some things are longer - like always including "self" as the first argument to a class method).
Below is a main class of my game - its temporary nickname is Towers :) :
- #File: game.py
- #Author: MW
- import pygame, sys,os
- from pygame.locals import *
- from map import Map
- from input import Input
- # Uncomment the lines below to enable profiling
- #import profile
- #import pstats
- if not pygame.font: print 'Warning, fonts disabled'
- if not pygame.mixer: print 'Warning, sound disabled'
- class Game:
- def __init__(self,width=800,height=600):
- self._running = True
- self.screen = None
- self.screen_width = width
- self.screen_height = height
- def game_init(self):
- self.screen = pygame.display.set_mode((self.screen_width, self.screen_height))
- self.input = Input()
- self.map = Map(self,self.input,100,100)
- self.clock = pygame.time.Clock()
- def game_input(self):
- if self.input.get_event(QUIT):
- def game_update(self):
- def game_render(self):
- def main_loop(self):
- while True:
- self.time_passed = self.clock.tick(60)
- if __name__ == "__main__":
- towers = Game()
- # Comment 1 line above and uncomment the lines below to enable profiling
- #profile.run('import game; towers.main_loop()', 'profile.tmp')
- #p = pstats.Stats('profile.tmp')
Python allows for both object-oriented and procedure-oriented programming, but my code is rather oo-way. The object of the Game class is created in the if statement at the end of the file. After that the main_loop method is called. At first it calls game_init method and initializes Pygame objects: display and clock. It also creates input object which is a wrapping over Pygame's event module, and map object which contains the rest of the game. Then it loops infinitely through three methods: game_input, game_update and game_render. Such design separates game logic (game_update) from gathering player input and displaying the game on the screen.
So much writing and code still does nothing, but that's the beauty of the OOP - you don't need to know what's inside the object (the implementation) to write a proper code.
Sunday, June 13, 2010
The main focus of the IP-based WSN workshop wasn't 6LoWPAN (as one could expect), but CoAP - Constrained Application Protocol. CoAP is an application protocol (ISO OSI layer 7) designed for WSN operation - it's RESTful, it features subscribe/notify mechanism and service discovery and it has a very small header. HTTP has neither of these. CoAP is still only an IETF draft, but taking into consideration the absence of open standards in the area it might really catch on.
I've got to admit that two weeks ago I didn't know what REST really was, but I like the RESTful approach very much - it's not based on some complicated messages, but rather on availability and state of resources. I find this philosophy coherent with Unix/Linux systems, where every device, or process is represented by a file in a system tree.
Other features of CoAP: subscription and discovery are even more interesting. Subscription is a must for communication with WSN nodes that are asleep most of the time. Service discovery makes application deployment for such nodes much easier - and it also makes maintenance and network expansion a lot more simple (maybe someday google will start to index your WSN nodes too :) ).
According to other participants of the UBI school the REST way is the only way for WSN (except one guy who did research into SOAP and EXI, but stupid airlines lost his luggage, and he was forced to leave the school before he could show us the results). But some of the people weren't convinced that new protocol is really necessary - people will still use old and clumsy (but more diverse and supported) protocols, and not a specialized thing like CoAP. Being more of a hardware guy I still can't present my own opinion in the area. Time will tell.