Bandwidth

When designing the schedule, the user must consider the bandwidth requirements for every device. The peak data rate of a specific connection can be determined from the number of allocated timeslots within the schedule. The diagram below illustrates a scenario where a device with the address 0xCD01 has 3 times more link bandwidth than the device at the address 0xAAAA (assuming equally sized payloads and equal timeslot durations).

figure not found: Wireless Core Data Rate

Figure 56: Wireless Core data rate

The timeslot duration and the schedule period itself are other factors that come into play for the bandwidth. The user must configure the duration of every timeslot when configuring the schedule.

The maximum datarate in kbps of a connection is given as :

\(datarate = \frac{nTs\times Ps \times 8}{Sl \times Tt \times 1000} kbps\)

where \(nTs\) is the number of timeslots allocated to the connection in the schedule, \(Ps\) is the maximum payload size in bytes of the connection, \(Tt\) is the timeslots duration in microseconds and \(Sl\) is the total schedule period.

Example:

\(nTs = 2\);

\(Ps = 120\);

\(Sl = 4\);

\(Tt = 250us\);

\(datarate = \frac{2 \times 120 \times 8}{4 \times 250us \times 1000} = 512kbps\)

Retransmission Margin

The retransmission margin consists of normally unused timeslots that can be used for retransmissions when the link starts to degrade. By accounting for a retransmission margin in the wireless schedule, we are in fact designing a link which allows for a higher throughput than what the application requires. A higher retransmission margin will increase the robustness of the link. The concept of retransmission margin only applies when the connection is using the Stop and Wait feature.

The retransmission margin is given as:

\(margin = \frac {cD - aD}{cD}\times100\)

where \(cD\) is the maximum data rate of the connection and \(aD\) is the data rate of the application for a given connection.

Example:

\(cD = 512kbps\);

\(aD = 384kbps\);

\(\frac {512kbps - 384kbps}{512kbps}\times100 = 25%\)

Sync Timeslot (Beacon)

The Sync Timeslot, or beacon, consists of a timeslot where the coordinator sends either a normal frame which contains a header and a payload or an empty frame which only contains a header. The maximal transmission period for this beacon is 10 ms. Having an interval greater than this will result in a loss of sync between the coordinator and the receiving node. If the coordinator does not have data to send at the time of the sync timeslot, the auto-sync feature can be used. The auto-sync feature lets the Wireless Core handle the transmission of the sync frame automatically. If the coordinator does not have data to send, its sync connection can have a FIFO size of 0. In a star or peer-to-peer network, this sync frame should be sent by the coordinator as a broadcast, eg with the address 0xFFFF.

Concurrency Considerations

The following figure shows 2 timeslots of a generic schedule operating with concurrency:

Figure not found: concurrency schedule

Figure 57: Generic concurrency schedule

During the first timeslot, the Network #1 transmitter executed CCA and determined that the air was free, so started to transmit on Channel #0. Network #2 transmitter also did a CCA, but slightly after Network #1 transmitter started to transmit, thus resulted in a failed CCA because Channel #0 was in use. Network #2 Transmitter then waited for a predetermined delay before retrying. At some point, its CCA succeeded, and it was able to transmit over Channel #0 because the other transmitter had completed its transmission.

During the second timeslot, both transmitters were able to transmit simultaneously as their CCA both succeeded. This is because the frequency separation (between Channel 3 and Channel 1) is high enough (at least 1 GHz separation). thanks to the random channel sequence mechanism managed by the Wireless Core.

In order to achieve proper concurrency, the following equations must be true:

\(T_{CCA} >= T_{AIR}\)
\(T_{SLOT} - (T_{CCA} * Retry_{COUNT}) - T_{AIR} - T_{PROC} >= 0\)

Where \(T_{CCA}\) is the CCA delay, \(Retry_{COUNT}\) is the number of times the CCA check is done, \(T_{AIR}\) is the air time of the frame, \(T_{SLOT}\) is the timeslot duration and \(T_{PROC}\) is the processing time required by the Wireless Core. The processing time can be measured using the Profiler Tool.

The number of links supported without any frame delivery degradation \(N\) is equal to the following, rounded down:

\(N = \frac {(T_{CCA} * Retry_{COUNT})}{T_{AIR}}\)

Latency Calculation

Here, we will look at latency and how it is affected by the 3 types of data transfer: best effort, limited retransmission and guaranteed delivery.

  • Best effort: There is only one attempt to transmit every frame. If the frame is not received correctly, it is dropped. This is done by configuring a connection without acknowledgement and Stop and Wait. Minimum latency (\(LatencyMin\)) and maximum latency (\(LatencyMax\)) for a successfully transmitted frame can be evaluated as follows:

    \(LatencyMin = (AirTime + CallbackDelay)\) \(\mu\)\(s\)
    \(LatencyMax = (AirTime + CallbackDelay + RefreshPeriod)\) \(\mu\)\(s\)

    where \(AirTime\) is the frame’s air time, \(CallbackDelay\) is the delay to trigger the RX callback and \(RefreshPeriod\) is the connection refresh period.

    The connection refresh period is the duration between data transfers for the maximum data rate case on a connection.

  • Limited retransmission: A frame is retransmitted until the frame is either successfully transmitted or dropped after a timeout period has expired. This is done by configuring a connection with acknowledgement and Stop and Wait with a timeout. Minimum latency and maximum latency for a successfully transmitted frame can be evaluated as follows:

    \(LatencyMin = (AirTime + CallbackDelay)\) \(\mu\)\(s\)
    “Retry count” mode (see Stop and Wait):
    \(LatencyMax = (AirTime + CallbackDelay + RefreshPeriod + RetxCount \times RefreshPeriod)\) \(\mu\)\(s\)
    “Deadline” mode (see Stop and Wait):
    \(LatencyMax = (AirTime + CallbackDelay + RefreshPeriod + DeadlineDelay)\) \(\mu\)\(s\)

    where \(RetxCount\) is the maximum number of retransmissions selected and \(DeadlineDelay\) is deadline time value selected.

  • Guaranteed delivery: A frame is retransmitted until it is successfully transmitted. This is done by configuring a connection with acknowledgement and Stop and Wait with timeout settings to 0. Minimum latency and maximum latency for a successfully transmitted frame can be evaluated as follows:

    \(LatencyMin = (AirTime + CallbackDelay)\) \(\mu\)\(s\)
    \(LatencyMax = infinite\)

Note

For real-time streaming applications, the connection’s TX and RX queue size will generally act as buffers and thus induce latency in the system. A greater queue size will allow for greater instantaneous PER spikes without interruption of service but will yield higher latency figures. The ideal buffering to put in place in an application varies depending on the schedule definition. As a rule of thumb, set the buffering length (latency) to a duration equal to 15 transmissions of the associated connection. In other words, a device needs to be able to transmit 15 packets in a period equal to the added latency. For example, if a buffer length of 5ms is used, the associated connection should be able to send packets at >3000 packets/second (15 packets/5 ms). The RX buffer of the receiver should have the same size as the TX buffer of the transmitter.

Case Study: Latency Evaluation of an Application

In this section, the Wireless Core latency is examined and the expected variations that can occur are explained. First, it must be understood that the interface between the Application and the Wireless Core is an asynchronous interface. A buffer (Queue) is implemented between the two interfaces. In a transmit scenario, data is written to the buffer (TX Queue) by the Application at the Application Rate, and data is read from the buffer (TX Queue) at the Wireless Core rate. The two rates are not synchronized with each other and are not usually the same frequency (Wireless Core frequency is typically higher than the Application frequency to allow for retransmissions). In such a scenario, there will be latency variations.

The latency introduced by the Wireless Core can be measured by toggling GPIOs on both the Transmitting and Receiving devices. The first GPIO is activated when the application writes data into the TX Queue and the second GPIO is activated when the Wireless Core writes data into the RX Queue (please refer to the Wireless Core Latency Representation. figure).

An oscilloscope can then be used to capture the IO state changes and compile a histogram of the handling time of the data by the Wireless Core including over-the-air (OTA) transmission time. Latency statistics such as minimum, maximum, average and standard deviation can then be obtained from that data to effectively qualify it.

In the example that follows, it is assumed that the application does not buffer data (application data is sent directly to the TX Queue); It is also assumed that all transmissions are successful (perfect RF link with no retransmissions). The figure below illustrates the signal path where the latency measurements are taken:

figure not found: Wireless Core Latency Representation

Figure 58: Wireless Core Latency Representation.

Latency variations depends on schedule and application timing. Let’s evaluate it for the following sample schedule:

figure not found: Example Schedule

Figure 59: Example schedule. Note that the schedule loops indefinitely.

Looking at the schedule, a single iteration of the schedule (every 1ms) can be seen, the Coordinator has four transmission opportunities whereas the Node has only one. The following section shows how timeslot allocation plays a major role in the latency jitter that occurs in practice. The amount of jitter depends on when the application data is yielded to the Wireless Core.

An important detail must be understood before diving in the analysis: the Wireless Core always prepares the action to be taken in the next timeslot (e.g.: timeslot #3) at the beginning of the preceding timeslot (e.g.: timeslot #2). This means that the application data is guaranteed to wait a little bit more than the timeslot’s duration (e.g.: timeslot #2 + air time). Here is a breakdown of the theoretical latency for both data stream directions.

Coordinator TX -> Node RX Latency

Starting with the best case scenario, one in which the application yields data to the Wireless Core at the perfect moment (just before timeslot #1), we can assume that the next transmission opportunity will occur in a little more than a timeslot’s duration (in timeslot #2), making ~200us the lowest expected transmission latency for the Coordinator. Note that it will be slightly higher than that due to the air time and data handling time which can vary. On the other hand, if the application provides data to the Wireless Core at the least convenient moment (during timeslot #3, just after missing the preparation for timeslot #4), the Wireless Core will not be able to send the data in the next timeslot (#4). Furthermore, because timeslot #5 is an RX timeslot, the next transmission opportunity will be in timeslot #6 (which is identical to timeslot #1). This means that the data will wait in the Wireless Core queue for a little more than three timeslots (#3 to #6), making the worst case theoretical latency ~600us (+ air time and data handling time).

Table 52: Coordinator TX Min/Max Latencies

Min

Max

~200us

~600us

Node TX -> Coordinator RX Latency

Starting with the best case scenario, one in which the application yields data to the Wireless Core at the perfect moment, we can assume that the next transmission opportunity will occur in a little more than a timeslot’s duration, making ~200us the lowest expected transmission latency for the Node. On the other hand, if the application provides data to the Wireless Core at the least convenient moment (during timeslot #4, just after missing the preparation for timeslot #5), the Wireless Core will not be able to send the data in the next timeslot (#5). Furthermore, because only timeslot #5 is dedicated for transmission, the next transmission opportunity will be in a complete schedule loop (which is equivalent to timeslot #10). This means that the data will wait in the Wireless Core queue for a little more than six timeslots (#4 to #10), making the worst case theoretical latency ~1.2ms (+ air time and data handling time).

Table 53: Node TX Min/Max Latencies

Min

Max

~200us

~1.2ms

Those results can be confirmed by using the method described at the beginning of this section. Generating a histogram of the latency value per frame with an oscilloscope will highlight the fact that those minimum and maximum latency values are corner cases. In practice, latencies between the minimum and maximum are far more likely to occur than the minimum or maximum themselves. In the end, the average latency can be obtained from the histogram and will generally sit somewhere between the expected minimum and maximum, with a low standard deviation.

Schedule Design Trade-off

There are always trade-offs between latency, maximum data rate and link budget for any schedule design.

From the Latency Calculation equations, frame air time and the connection refresh period should be decreased in order to reduce latency. However, decreasing those parameters can result in lower maximum data rate and/or link budget.

The 3 main factors that impact frame air time and connection refresh period are modulation, FEC ratio and payload size. For modulation and FEC ratio, there are 2 recommended configurations:

  • 2 bit PPM, FEC x1.334: This will yield better link budget but longer frame air time.

  • IOOK, FEC x1.667: This will yield lower link budget but shorter frame air time.

There are five main factors that impact frame air time and connection refresh period on the SR1120:

Refer to each of these factors for more in-depth explanations of their impacts on airtime. For modulation and FEC, the recommandation for SR1120 is:

  • IOOK, FEC x1.25: This will yield optimal link budget with shorter frame air time.

Increasing FEC, symbol averaging and ISI mitigation will also increase the link budget at the cost of higher frame airtime.

A large payload which minimizes PHY overhead results in higher application data rates at the expense of higher latency and lower link budget.

A smaller payload with shorter air-time results in lower latency and higher link budgets at the expense of lower application data rates due to higher PHY overhead.

The table below, summarizes the effects that payload size and Modulation/FEC have on Link Budget, latency and data rate.

Figure not found: Schedule design trade-offs

Figure 60: Schedule design trade-offs