Announcements‎ > ‎

Protocol evolution

posted Jun 29, 2013, 1:12 AM by Daniel Berenguer   [ updated Jun 29, 2013, 1:13 AM ]

SWAP was created some time ago with the primary goal to provide M2M interoperability between simple wireless devices. In order to simplify its adoption and usability in MCU's with little flash and memory, SWAP was unprovided with some functionality included in some other protocols (dhcp, mesh, ...). Instead, SWAP relies on the natural long-distance capability of CC11XX radios and also on an initial manual configuration at the moment of deploying wireless networks. All this makes SWAP implementable in just a few kilobytes of flash (the current panStamp stack takes around 7 KB).

The above said, SWAP needs to progress in some way. Even if we give the possibility to keep the bare minimum implementation and basic functionality, users need a way to optionally enable new features on the protocol and stack. The following is a list of features that are being taken as a reference for future developments:

1. Formal adoption of swapstream as our "official" way to transmit non-fixed length streams of data between nodes. We shouldl be able to implement some other subprotocols on top of it

2. Self-discovery and resource identification of devices. With this feature, nodes wouldn't need to rely on an external XML repository to know about the features and resources provided by any node in a SWAP network.

3. Dynamic address allocation. Some kind of DHCP for SWAP, instead of having to set addresses manually. One of the challenges around this implementation will be how to uniquely identify each unallocated node since proprietary MAC numbers are usually used by this kind of functionality.

4. Over the air (OTA) programming, most probably on top of swapstream.

5. Standard recommendation of start-up sequence for all nodes and sample applications (time in reception mode before going to sleep, sequence of messages, etc).

6. Standard recommendation to periodically enter SYSTATE_SYNC to be able to reconfigure panstamps that are physically inaccessible.

7. Optional 2-byte addresses instead of 1-byte. This will let us deploy "smart-city" capable networks.

Indeed, we have a huge challenge in front of us. We will try to work on the above list of features, step by step, along with the development of our new family of panStamps and carrier boards.