Newsletters - MATLAB Digest
Bluetooth Control Logic Design with Stateflow
The Bluetooth Voice Transmission article in the November 2001 edition of MATLAB Digest described how Simulink could be used to design and simulate the physical layer of this new ad-hoc wireless networking technology. It described a Simulink model of one-way voice transmission from a master device to a slave device for three different packet types. This follow-up Bluetooth article focuses on designing the control logic aspects of Bluetooth using Stateflow, the MathWorks tool for designing event-driven control logic. It presents an expanded Simulink and Stateflow model (downloadable from MATLAB Central) that simulates two-way transmission of voice and data with an acknowledgement scheme, plus a new IEEE proposed voice packet type that is resistant to interference.
Bluetooth Physical Layer
The Simulink model described in the previous article modeled transmission of Synchronous Connection Oriented (SCO) voice packets HV1, HV2, and HV3. It covered the signal processing characteristics of the baseband section of the Bluetooth specification (part B), and some of the radio section (part A). This included typical physical layer components, such as speech processing, framing, coding, modulation, and frequency hopping, which are implemented in digital hardware or DSP software. The physical layer of a communication system is ideally represented as a block diagram and this is why Simulink is an appropriate tool for developing this model.
| Figure 1: Two-way Bluetooth Simulink model. |  |
The Bluetooth specification [1], and communication links in general, comprise much more than the physical layer. In particular, the control logic components present in acknowledgment schemes, protocols, and higher layers (2 and 3) are a large part of the design challenge. These components are usually implemented in software on a microcontroller or programmable DSP. Such functionality is difficult to model as a block diagram but easy to model as a finite state machine (FSM). We will demonstrate several examples of designing such algorithms with Stateflow and incorporating them into a larger two-way Simulink Bluetooth model as shown in Figure 1.
Control logic
Control logic algorithms are present in call processing and hand-off schemes in cell phones, the Media Access (MAC) layer in wireless local area networks (LANs), and data link layer functionality in general in all communication systems. The specifications for these algorithms are often given as state machines such as the Bluetooth logical link control state machine shown in Figure 2.
 |
Figure 2: Logical link control state machine. |
With such algorithms, a device is defined to be in one of a finite number of states such as "idle", "transmitting", "training", or "synchronizing". The device's state changes are event-driven in nature and typically triggered by events in the physical layer. Examples of such control logic functionality in Bluetooth include data acknowledgement schemes, link manager protocol (part C of the Bluetooth specification), and logical link control (part D).
Stateflow, the MathWorks finite state machine design tool, lets you graphically design states and the transitions between them. The Stateflow block, which is placed in a Simulink model with other blocks, has its trigger ports, input ports, and output ports connected to other Simulink signals. The Stateflow block only executes on trigger events (i.e., rising or falling edges of triggering signals). This enables the state machine to be triggered by events in the physical layer, make decisions based on other physical layer signals, and trigger or enable other parts of the system. The Stateflow chart executes in zero simulation time, and is disabled between events.
 |
| Figure 3: CRC being added to the transmit packet payload. |
Typically, the way to interface between the physical layer and these control logic algorithms is to perform a cyclic redundancy check (CRC). CRC bits are computed from the transmitted data bits and are appended to them as shown in Figure 3. The General CRC Generator block from the Communications Blockset, performs this task, taking the 144 payload bits and adding the 16-bit payload CRC, resulting in 160 bits.
On reception, the payload CRC is compared to a CRC generated locally from the received data by the CRC Syndrome Detector block. If they do not match, this shows that the payload or the CRC have been corrupted. This signals a failed packet transfer to the state machine. Voice packets protect only the header with CRC bits. For data transmission, CRC bits are added to the payload also.
In this article, we will look at the design of the control logic algorithm of Bluetooth's data transmission acknowledgement scheme as used by the DM1 packet and a new IEEE-proposed voice packet type called SCORT [2], which uses control logic.
Data Transmission
Data transmission which used asynchronous connection-less (ACL) packets, differs from voice transmission in a number of ways. One key difference is that data transmission has to be perfect (i.e., not one error is allowed). If an error is detected, the data has to be retransmitted. There are a number of different ways to achieve this in communication system design. In Bluetooth, packets are sent repeatedly by the transmitter until it receives an acknowledgement back from the receiver notifying it that the packet was received correctly. The receiver tests the incoming packet's CRC to determine correct reception. In data transmission, it is the throughput, in bits per second, that needs to be estimated rather than the bit error rate (BER). The throughput is reduced if packets need to be resent.
The receiver sends acknowledgments back to the transmitter by setting the ARQN status bit in the header info of the return path packet. Figure 4 shows the ARQN status bit being inserted as the nineth bit of the 10-bit header info. The value of this bit signals to the transmitting device if the last packet was received correctly. ARQN=1 signifies a successful transmission, ARQN=0 signifies unsuccessful transmission.
 |
Figure 4: Setting ARQN status bit in header info of packet. |
If data needs to be communicated only from the master to the slave, the slave sends back a dummy NULL packet with no payload in the next slot. Figure 5 shows the DM1 packet being transmitted in the first slot, and the slave replying with a NULL packet containing the acknowledgment in the immediately following slot. The master then transmits again in the next slot.
| Figure 5: DM1 and NULL packet timing. |  |
To model two-way communication, we need to design two identical devices, each with a transmitter and receiver. Figure 1 shows such a Simulink model (downloadable from MATLAB Central) comprising two identical Bluetooth devices. The only difference between them is that one should be designated the master and one the slave. Additionally, a device ID or address is required for each.
Section 5.3 of the Bluetooth specification states the acknowledgment scheme is as follows: "With an automatic repeat request scheme, DM, DH, and the data field of DV packets are transmitted and retransmitted until acknowledgement of a successful reception is returned by the destination (or timeout is exceeded). The acknowledgement information is included in the header of the return packet..." We will now look at how this simple algorithm is implemented in the transmitter and receiver.
Data Acknowledgement in Transmitter
The first step in designing such an algorithm is to identify the different states the device could be in. When transmitting ACL packets, the transmitter can be in either of two states: "Transmitting a new packet" or "Re-transmitting a packet", labeled "Transmit_blank_Packet" and "Re_Transmit_Packet" respectively in the state diagram chart in Figure 6. The figure shows the transmitter controller state machine. The "ACL_Packets" substate is entered when the packet is of DMI type, checked by the "[Packet_Type==4]" condition on the transition.
On entering the "ACL_Packets" state, the device first transitions to the default substate which is "Transmit_blank_Packet". The state actions of "Enable_Audio=0" and "Get_blank_Packet=1" send signals outside the state chart to disable the audio and generate a new packet of bits respectively. The transmitter stays in this state until the next slot that it is due to transmit at. At that time, it "wakes up" and looks at the status of the ARQN bit in the packet that was returned from the receiving device in the previous slot. If the transmitter is in the "Transmit_blank_Packet" state and the return ARQN=1, it stays in that state and transmits another new packet. This is implemented in Stateflow by placing the conditions "[ARQN==0]" or "[ARQN==1]" on the transitions exiting the states. If the return ARQN=0, it transitions to the "Re_Transmit_Packet" state. When the transmitter is in the "Re_Transmit_Packet" state, and the return ARQN=1, it transitions back to the "Transmit_blank_Packet. "Otherwise it stays in the "Re_Transmit_Packet". This algorithm can more clearly be represented as a state chart shown below.
 |
| Figure 6: Transmitter state machine. |
Although the events are asynchronous, they happen only on slot boundaries. As a result, the execution of the state machine can be simplified to be discrete-time, executing only at the slot rate and when an edge trigger is detected.
