I wanted to write about my master thesis for some time. Mostly because it was written in Turkish which makes it inaccessible to few people that could be interested in it at all. I couldn’t decide where to start. So, I though maybe a q&a format will be easier to write. Here we go.
Oh, before I start here is my thesis in Turkish. It has pictures. And here is a paper (in English) I’ve written on the communication stack if you don’t have much time.
What was it about?
I’ve implemented a multi purpose wireless communication module for use in a medical tracking device using 802.15.6 protocol.
Why did you do this?
I wasn’t alone. This device was developed as part of a bigger project (funded by Tubitak) in KTU Electrical Eng. Dep. A remote patient tracking service. From scratch. We implemented many aspects of such a system. From sensors to the server infrastructure and signal processing. It covered a lot of area. Maybe too much.
My responsibility was to create a wireless module as a platform to implement patient monitoring sensors. And I got a thesis out of it.
What is 802.15.6?
This is a relatively new but obscure, probably dead on standardization, wireless communication standard by IEEE that is targeted at wearable sensors and medical implants. It’s called “Wireless Body Area Network” standard. It is most comparable to Bluetooth and ZigBee (802.15.4). You could say it was developed to solve problems with these 2 technologies. Its main aim is to be way more reliable than existing technologies and make it possible to implement cheap and trustworthy wireless medical equipments and patient tracking devices.
Why 802.15.6, what’s wrong with Bluetooth or ZigBee?
These protocols are still looked suspiciously when arrival of data is a must, especially in streaming cases. This lead us to look into alternatives. 802.15.6 was the perfect candidate to base a wireless communication protocol implementation for body worn sensor devices. It’s right there in the name. But the truth is we never had a chance (resource and time wise) to experiment or show strengths of the 802.15.6.
At this point I can only say: flexibility. But how do you leverage this flexibility is what matters.
What does the standard actually define?
It defines the Wireless MAC and PHY layers. I’ve only worked on implementing the MAC though. Implementing a PHY for battery powered application is only possible at IC level. So we decided to use a 802.15.4 transceiver for the PHY layer. That’s why I say “based on/using 802.15.6”.
Which 802.15.4 transceiver did you use?
We used Atmel AT86RF233 transceiver. We chose this one for 2 reasons. It was possible to use this as a simple transceiver only, no MAC features. It’s operating frequency range included 2360-2400MHz band which is allocated for medical use cases in USA, and maybe in other countries in the future. We also had some antenna work for this band but I wasn’t involved in it.
What else was in the hardware?
Not much if we don’t count the obvious sensor circuitry. As main processor we used ST STM32F407 microcontroller. RF circuitry was nonexistent because we used a module for AT86RF233 which included even the antenna on board. There was a voltage regulator and charging IC for lithium battery. And some LEDs of course. There wasn’t any sensor ICs on the communication board which connected to actual sensor circuitry via a pin header. That was because we implemented different measurement equipment which shared the same communication module.
Why STM32F407?
I already had some experience with this MCU. Tutorials and hello world stuff.. Running at 168MHz with 192KB RAM, 1MB Flash, featuring peripherals such as Ethernet, DCMI camera interface etc, it is actually overkill for a project of this type. But I wanted to make sure I had adequate firepower at hand. I didn’t know what I was getting into. My plan was to make it work first then optimize. Also this being a multi device protocol, I decided to use an RTOS. A first for me. I knew this would bring extra overhead.
Why ChibiOs?
ChibiOs is a real time operating system. It also comes with a nicely designed HAL API. It supports various architectures, mostly ARM based ones. There were 2 reasons that drawed me to Chibios:
1. Tickless operation mode
2. Very well designed and comprehensive HAL for STM32 MCUs
“Tickless” operation mode, meant that our code would run swiftly without unnecessary interruptions from the OS. In regular (ticky?) operation mode, OS needs to periodically stops everything to do its “thing”. In a tickless operation mode, OS only takes matters into its hand when it needs to. That means its more efficient, quick and even more predictable. It is somewhat similar to “cooperative” multi tasking.
Best part, ChibiOs API and HAL is so superbly designed, you don’t feel like you are using an operating system at all. It’s simple and intuitive yet powerful. It’s one of these libraries that you can use for quick prototyping tasks with ease. For example see this SPI receive routine that uses DMA and puts your thread automatically to sleep.
spiReceive(&SPID1, size, data);
Maybe I’m making too much out of it, but whole library is like this. Documentation could be a little better though, and I wish there were more tutorials. But since it’s open source and so well written you can always open up the code an figure it out yourself!
Tell me more about 802.15.6?
802.15.6 is based on a relatively simple star network architecture. It supports 1-hop relays but that’s it. All devices, “nodes” in a network are connected to the “hub”. Hub is like the wi-fi router or ZigBee coordinator or your BlueTooth phone.
802.15.6 standard is divided in to 2 main parts. PHY and MAC. PHY, physical layer standard, defines the frequencies and modulation features that is used. MAC, medium access control, in short defines “who speaks when”. It defines the rules and methods that allow many devices to share the same frequency and establish a network with no (or as few as possible) collisions.
I will keep the PHY part relatively short. There are 3 different PHYs defined.
1. Narrow band
2. Ultra Wide Band
3. Human Body Communications
Narrow band uses your traditional GMSK and QPSK based modulation in various bands. Most importantly and widely, in 2.4GHz ISM and 2.36-2.4GHz MBAN (M stands for medical) frequencies. I won’t get into the UWB and HBC. But to be honest I suspect these will be the bands that might make 802.15.6 “a product”.
We wanted to implement narrow band PHY in our system but unfortunately there are no 802.15.6 PHY that is commercially available even today, after 5 years of its standardization. It looked promising when this project was drafted more than 3 years ago, but today not so much. So we decided to go with closest thing. An 802.15.4 based transceiver.
MAC on the other hand deserves its own section.
What it’s like the MAC layer of 802.15.6?
Well, just like its PHY, 802.15.6 defines various methods for its MAC. These could be summarized as 3 different access modes.
1. superframes with beacons
2. superframes with no beacons
3. no superframes
In first mode, time is divided into superframes. At the beginning of each superframe a “beacon” frame is sent by the hub. This frame carries important information about the established network and hub. Such as its ID, access mode, superframe structure and timing information. It’s role is important for nodes that wants to connect to the network and are already connected nodes as well. Rest of the superframe is divided into different phases. Each phase allows for a different style of communication. I will explain these phases later.
In second mode, there are still superframes but no beacon frames. Honestly, the purpose of this mode isn’t clear to me. Maybe I don’t remember it now.
In 3rd mode, there are no superframes at all. In this mode communication is mainly carried out by poll frames sent by the hub. For example to establish a new connection, a new node should catch a poll frame from the hub.
What’s the difference between these modes?
In short mode 1 is more suitable for TDMA (Time Division Multiple Access) style communication and mode 3 is more suitable for polling and contented allocation style communication.
But, mode 1 is very interesting because it isn’t just a TDMA based method. It also features contended allocation features. It’s quite flexible.
Tell me more about flexibility of 802.15.6 access mode 1?
For this I need to talk about “phases” of the superframe. A superframe can be divided in to these phases (in order).
1. EAP1 : Emergency Access Phase
2. RAP1 : Random Access Phase
3. MAP1 : Managed Access Phase
4. EAP2 : Emergency Access Phase
5. RAP2 : Random Access Phase
6. MAP2 : Managed Access Phase
7. CAP : Contended Access Phase
Any of these phases are optional and can be of various sizes. By the way, even smaller then the phases, superframes are divided in to allocation slots. This is a relatively (comparable to duration of a small data frame) small time duration that makes sense in case of allocations. I can’t give a number off the top of my head but think something like ~500us is the smallest value. This duration is also adjustable and chosen by the hub. Length of the superframe and phases are given in terms of number of allocation slots. For example we could design a superframe like this:
Allocation slot size: 500us
Length of EAP1: 5 slots
Length of RAP1: 10 slots
Length of MAP1: 30 slots
Length of RAP2: 5 slots
Length of MAP2: 30 slots
Length of superframe (total): 80 slots = 40ms
As you can see we decided not to have an EAP to or CAP phase in our superframe.
Tell me more about phases?
“Emergency Access Phase”, as the name clearly implies is specifically left for emergency data frames. It is supposed to be used by devices that needs to transfer vital medical information as quickly as possible. It uses contended allocation mode.
“Random Access Phase”, can be used by connected or unconnected nodes. In this node contended allocation methods are employed. Basically nodes race each other to talk to the hub. And they occasionally (randomly) take voluntary (but calculated) breaks to allow other nodes to talk. If they detect a collision, they wait longer to reduce and control the number of collisions. Because -most of the time- collisions means wasted time. Time means precious bandwidth. Random access phase is somewhat easier to implement. Maybe harder. I can’t decide at the moment. It has a self balancing nature. But on the other hand it has potential to be less power efficient compared to other modes.
“Managed Access Phase”, is strictly managed by -you guessed it- the hub. It’s divided and allocated to the nodes as allocation slots upon their requests. When an allocation is requested (and accepted) it’s direction is also determined. It can be uplink, downlink or bi-link. In case of an “uplink” allocation, a node has right to transfer its frame to the hub as it sees fits. No other node has right to speak at that moment. It’s free of collisions you might say. In downlink, it is similar but flow of information is reversed. It’s from hub to a specific node. In bi-link mode, frames can be sent either way. Due it’s ambiguity, in this type of allocations hub has to issue polling frames for node to be able to send its frames. As you can see this type of access is what gives 802.15.6 TDMA features.
“Contention Access Phase” is very similar to RAP. Unfortunately I couldn’t ever figure out its difference. There is one thing though; beginning of the CAP is marked with transfer of a B2 frame. This is like a second beacon frame. It carries information about hub co-operation. This led me to think that CAP is also expected to be used by other hubs (or nodes of other BANs).
What access mode did you use?
We decided to use access mode 1. Mainly because of its TDMA like features. Our aim was to implement a reliable and efficient communication channel to be used by streaming nodes which were constantly transmitting data. To make it more efficient we had to get rid of conflicts. System was designed to be used in a *free* channel anyway. So we only had to make sure our nodes didn’t conflict with each other.
What kind of superframe structure did you use then?
To keep things simple at the beginning we designed a superframe structure that consists of a RAP and a MAP. Just RAP1 and MAP1. No EAP, or other fancy stuff. Once you implement these two, implementing others is a means of superframe structure optimization. I believe this is an area that should be throughly researched. And maybe there are ways to handle this in an adaptive manner. Unfortunately due to time constraints we could never experiment with superframe structure.
What else does 802.15.6 has?
MAC layer isn’t just about timing. 15.6 also defines the security of the communication. This was another thing we couldn’t work on. I intentionally stayed away from it because I didn’t have any experience with secure communication and encryption in general. But I knew that it’s quite easy to implement a flawed security layer that doesn’t actually provide any security. So I decided not to touch it until I had enough time to do it properly.
Another unique feature of 15.6, is the “hub co-operation” features. This allows a node to share it’s frequency with another hub. There are various ways of doing that. But clearest and most obvious method was superframe sharing. In this mode a hub allows another hub to use its superframes for its own purposes. Superframes are utilized alternately by each hub.
Another interesting feature is the acknowledgments. Each frame has a bit field in its header that marks if this frame requires an acknowledgment. Some frames never does. Such as the beacon frame. On the other hand management frames always require acknowledgment. There are different types of acknowledgements.
1. I-Ack : Immediate Acknowledgment
2. B-Ack : Block Acknowledgment
3. G-Ack : Group Acknowledgment
I-Ack should be obvious. When a frame requires I-Ack, it’s acknowledgment frame is sent immediately after reception. B-Ack is sent after a block of frames sent by the same node. Each frame is marked with B-Ack request. Receiver sends the acknowledgment when the last frame is received. If there are any missing frames these are noted in the B-Ack frame itself. This allows a more efficient usage of the channel bandwidth and even battery. When you have a relatively clean channel and most if not all frames are arriving peacefully it might make more sense to use group acknowledgment. This can be used for frames from nodes to hub. When frames are marked with G-Ack request, hub doesn’t send individual acknowledgment frames, it doesn’t even send them after a block of frames. But instead it relays the acknowledgment to the nodes in the B2 frame. All at once. That’s why its called a “group” acknowledgment.
Before you ask, we only used I-Ack in our work. B-Ack should have been definitely utilized though.
Another feature is the priorities. 7 (i think) priority levels are defined in order by the standard. I won’t list them all but included were medical data, video data, and voice data. Each data frame has a priority marked in its MAC header. Priority level is used during contended allocation. When a node has to “back out” after a frame collision, how long is should back out is effected by transmitted frame’s priority level. This ensures higher priority frames have better chance of passing through. MAP allocations also have priorities. Behavior for this case isn’t very well defined by the standard. But I would assume that a well behaving hub should cancel allocations (or resize them, yes that’s possible) in case a higher priority allocation is requested and there aren’t any free allocations slots left.
How did you implement the firmware?
Our code had a quite modular structure. I wanted to depict it as layers, but it just doesn’t sound right that way. In summary we had a PHY code to talk to the transceiver. MAC code that implemented the 802.15.6 MAC. Something we called MTL that simplified packet creation and parsing and in general interfacing sensors to the host device. It’s a whole thing of its own that I will describe later. Separate modules for each sensor we implemented. Such as a module for reading data from ADS1294 which is a glorified ADC for ECG applications. Or a motion sensor, battery level sensor etc. Then we had a relatively simple “main” for each device we implemented, hub and sensor nodes.
Tell me about PHY first?
This was relatively simple because it was just an interface for the actual PHY chip (AT86RF233). Chip was controlled via SPI. PHY layer had functions such as phy_transmit and phy_receive that would transmit a given frame to the transceiver and receive frames from it. AT86RF233 is a relatively simple TRX to use. Trickiest part of this code was to control the timing. Interrupts and a dedicated timer was utilized obviously.