Loading web-font TeX/Math/Italic
Latency Analysis of Wireless Networks for Proximity Services in Smart Home and Building Automation: The Case of Thread | IEEE Journals & Magazine | IEEE Xplore

Latency Analysis of Wireless Networks for Proximity Services in Smart Home and Building Automation: The Case of Thread


Analytical and experimental results on the probability distribution of the latency of Thread mesh network.

Abstract:

Proximity service (ProSe), using the geographic location and device information by considering the proximity of mobile devices, enriches the services we use to interact w...Show More
Topic: Proximity Service (ProSe) Challenges and Applications

Abstract:

Proximity service (ProSe), using the geographic location and device information by considering the proximity of mobile devices, enriches the services we use to interact with people and things around us. ProSe has been used in mobile social networks in proximity and also in smart home and building automation (Google Home). To enable ProSe in smart home, reliable and stable network protocols and communication infrastructures are needed. Thread is a new wireless protocol aiming at smart home and building automation (BA), which supports mesh networks and native Internet protocol connectivity. The latency of Thread should be carefully studied when used in user-friendly and safety-critical ProSe in smart home and BA. In this paper, a system level model of latency in the Thread mesh network is presented. The accumulated latency consists of different kinds of delay from the application layer to the physical layer. A Markov chain model is used to derive the probability distribution of the medium access control service time. The system level model is experimentally validated in a multi-hop Thread mesh network. The outcomes show that the system model results match well with the experimental results. Finally, based on an analytical model, a software tool is developed to estimate the latency of the Thread mesh network, providing developers more network information to develop user-friendly and safety-critical ProSe in smart home and BA.
Topic: Proximity Service (ProSe) Challenges and Applications
Analytical and experimental results on the probability distribution of the latency of Thread mesh network.
Published in: IEEE Access ( Volume: 7)
Page(s): 4856 - 4867
Date of Publication: 23 December 2018
Electronic ISSN: 2169-3536

Funding Agency:


SECTION I.

Introduction

Proximity service (ProSe) exploits proximity of the mobile devices by utilizing information such as geographic location and physical devices data, changing the way we interact with people and things [1]. ProSe has been considered having a good potential usage in mobile social networks in proximity (MSNP). MSNP is a wireless peer-to-peer (P2P) opportunistic network using geo-proximity in addition to nowadays mobile social networks such as Facebook a and Linkedin [2]. However, ProSe is also playing an important role in other areas, such as smart home and BA, containing the interacting services between people and people, people and things and things and things [3]. In smart home and BA, ProSe has become increasingly prosperous with the advancement of new technologies such as big data, artificial intelligence and wireless networks. For examples, Apple Homepod, Amazon Echo and Google Home utilize the above technologies to provide seamless proximity services for users by using geographic location, physical devices data and other information. Importantly, these ProSe and application scenarios need stable support from network protocols and communication infrastructures with different requirements, like latency, reliability, bandwidth and so on.

To ensure a satisfactory user experience of ProSe, one important factor is network latency [4]. ProSe generally uses IP-based networks, which introduce extra latency due to the IP stack. However, users need to have smooth user experience without long waiting time when interacting with other people or things. Also, some other services in smart home and BA require quality of service (QoS) guarantees [5]. Safety-critical applications in smart home and BA, such as healthcare systems for elderly people, fire alarms, require reliability and time predictability. Google Home fully utilizes Thread protocol as network protocol and communication infrastructure to provides various use scenarios and products such as thermostats, cameras, and alarm systems. Thread protocol, mainly introduced for smart homes and BAs [6], is a new WSN protocol developed by Thread Group to connect and control IoT products. To better understand and develop ProSe, it is crucial to investigate wireless network protocols with improved responsiveness for ProSe such as the Thread protocol.

To the best of our knowledge, this paper is the first work that investigates the latency of the Thread protocol through an experimental study, though security [7] and energy [8] respectively, have been investigated. We propose practical methods and guidelines to study the latency of Thread as an IoT protocol used in ProSe of smart home and BA. The deep understanding of the latency of Thread protocol facilitates designing and developing ProSe because developers can precisely analyze and guarantee QoS in smart home and BA systems. To this end, we propose a Markov chain-based system-level model to theoretically analyze the latency of the Thread mesh network and verify the model results through an experimental study. Based on the proposed analytical model, we developed a software tool for ProSe developers to estimate the latency of the Thread mesh network. The evaluation of the model in the multi-hop Thread mesh network shows that the model results match well with the experimental results.

The rest of the paper is organized as follows. In Section II, related work on latency of WSNs and mathematical models for WSNs are presented. In Section III, an overview of the Thread protocol is introduced. In Section IV, a system level model for the latency of the Thread mesh network is proposed considering the latency introduced at different network layers, from the application layer to the physical layer. The accuracy of the model is experimentally validated in Section V. Section VI concludes the paper and proposes our future-work.

SECTION II.

Related Work

A. Latency of WSNs

Latency of WSNs is critical in many applications such as industrial automation, healthcare systems and safety-critical applications in BA, such as fire alarm detections [9]. Many works have investigated the latency of WSNs in these areas. In [10], the latency of asynchronous MAC protocols has been surveyed in delay-sensitive wireless sensor networks. The work [11] pointed out that it is hard to predict the accurate latency introduced by WSNs when the MAC implements CSMA/CA. Instead, the work applied a Time-Division Multiple Access (TDMA)-based protocol to a slightly modified IEEE 802.15.4 to assure that the transmission latency of sensors is not more than 10 ms. Sahoo et al. [12] proposed a new channel access mechanism for IEEE 802.15.4e-based low latency deterministic network shared slots. Also based on 802.15.4e, Daneels et al. [13] came up with recurrent low-latency scheduling in Time-Slotted Channel Hopping networks. However, when modeling the latency of WSNs, practical hardware limitations may cause significant differences between theoretical models and real tests [14]. In fact, the work [15] mentioned that the latency of multi-hop networks is increased significantly by packet relaying. Despaux [16] proposed an approach for modeling and estimating the end-to-end delay for WSNs considering the protocol implementation and hardware limitations. In [17], a blue probability generation function (PGF) was proposed to derive the delay of successfully received packets. However, in practice, understanding the latency of WSNs requires experimental studies combined with the theoretical analysis. Deep understanding of the distribution latency of WSNs together with experimental studies can guarantee the QoS in smart home and BA. It also provides practical guidelines for developers to design user-friendly ProSe when developing applications.

B. Mathematical Models of WSN MAC

Recently, several analytical studies for the latency of IEEE 802.15.4 have been proposed, e.g., [18]–​[21], inspired by Bianchi’s work [22]. Due to the stochastic nature of MAC protocols, these models are mainly based on Markov Chains. Park et al. [17] and [19] have proposed a model with the Markov chains considering the retry limit, acknowledgments and unsaturated traffic. Effective and simple approximation of delay, reliability and energy consumption have been proposed in these works. Furthermore, in [17], based on [19] and [23], a PGF method has been applied to estimate the delay introduced in packet delivery. However, only the star topology was considered in these works. Hence, delay is estimated in a one-hop fashion, whereas the analysis verification is based on simulation rather than experimental results. According to the work in [14], the gap between mathematical modeling and measurement of WSNs cannot be neglected. Although the hardware factors related to delay and experiment results were considered in [19], a more comprehensive statistical characterization of latency has not been provided. Marco et al. [24] have proposed an analytical model considering a multi-hop IEEE 802.15.4 network with hidden terminals. Wang et al. [25] have worked with multi-hop networks and estimated the end-to-end delay. The work considered the carrier sense multiple access with the collision avoidance (CSMA/CA) protocol for nodes running the TinyOS operating system. However, both of the works above only focused on modeling MAC protocol logic, without considering the implementation factors in the network, i.e., the impact of hardware delay between processors and transceivers in WSNs. Yan et al. [26] proposed a mathematical model for MAC access delay. The model was based on the queuing theory and an easy-to-use tool in package level simulation was developed. Nevertheless, that work only focused on the slotted MAC. The unslotted MAC, multi-hop communication and experimental validation were not considered in that work.

In [20], a Markov chain model was proposed to analyze the slotted CSMA/CA in both saturated and unsaturated conditions in the ACK mode. However, the proposed model did not consider retransmissions. Faridi et al. [21] proposed a modified Markov model in an attempt to model the slotted CSMA/CA mechanism in the ACK mode. The model also includes retransmissions with finite retry limits.

The packet delay, throughput and power consumption about IEEE 802.15.4 MAC have been analyzed in [27]. However, none of the papers mentioned above considered the following aspects altogether: the unslotted or beaconless MAC, multi-hop scenarios, implementation factors, system level models and software tools for latency estimation. These characteristics make the modeling and validation of the latency of the Thread mesh network different from the results available in the literature.

The contributions of this paper are the following:

  1. A thoroughly study of the latency of a new IoT protocol, Thread stack, theoretically based on the model in [18], adding real measurement factors and multi-hop communication.

  2. An experimental study of the Thread mesh network through real testbed in BA and validating the proposed analytical model.

  3. The specification and implementation of an easy-to-use software tool, which gives clear guidelines to the ProSe developers to guarantee a certain level of QoS and develop user-friendly applications.

SECTION III.

Overview of the Thread Protocol

In this section, we describe the protocol stack of Thread as the delay generated by each layer needs to be considered. Specifically, we describe the mechanism of non-beacon enabled IEEE 802.15.4 CSMA/CA with the backoff process. Understanding the Thread protocol and the non-beacon enabled IEEE 802.15.4 CSMA/CA backoff process helps us to propose the system level model in the subsequent sections.

A. Protocol Stack

Thread is a new IP-based wireless networking protocol established in July 2014 by companies such as Google Nest, ARM, and Samsung [6]. The Thread protocol combines the solutions of several standards to fit the needs of typical BA applications. As Fig. 1 shows, Thread does not standardize the application layer. This provides the supplier with the freedom to use proper application layers according to their needs. In our paper, the constrained application protocol (CoAP) is used, which is a constrained web transfer protocol (similar to HTTP) intended for resource-constrained devices. The feature that supports IP networking allows Thread to easily interconnect with other IP-based mobile devices. At the network layer and transport layers, Thread uses User Datagram Protocol (UDP) on top of IP routing and IPv6 over Low power WPAN (6LoWPAN). In MAC and PHY layers, Thread uses the IEEE 802.15.4 wireless specifications, supporting mesh network with a maximum speed of 250 kb/s over the 2.4 GHz band [6]. IEEE 802.15.4 wireless specification has been used in many other protocols such as WirelssHART, Zigbee and Internet Engineering Task Force (IETF) IoT stack.

FIGURE 1. - Thread protocol stack [6] (authorized by Thread Group).
FIGURE 1.

Thread protocol stack [6] (authorized by Thread Group).

There are five types of devices in the Thread network: border routers (BR), routers, router-eligible end device, end devices, and sleepy end devices. The Thread stack supports full mesh connectivity between all routers in the Thread network. The number of routers will decide which kind of topology it will form. If there is only one router or border router, then a basic star topology is formed. If there is more than one router then a mesh topology is automatically formed. The details can be found in [6].

B. IEEE 802.15.4 MAC

In this section, the non-beacon enabled IEEE 802.15.4 CSMA/ CA used in the Thread protocol is summarized. Fig. 2 depicts the flowchart of the non-beacon enabled IEEE 802.15.4 CSMA/CA channel access mechanism. We denote the MAC parameters by W_{0} = 2^{macMinBE} , m_{0} = macMinBE , m_{b} = macMaxBE , m = macMaxCSMABackoffs , and n = macMaxFrameRetries . For the Thread protocol, the default parameters are m_{0} = 5 , m_{b} = 8 , m = 4 , and n = 3 . Upon transmitting packets, the MAC layer performs the following (initialize retransmission counter R to 0, the number of backoff (NB) to 0 and backoff exponential (BE) to macMinBE).

  1. Before sending the packets, wait for a random period of time in the range [{0, 2^{BE} -1 }] backoff time unit S_{b} to avoid collisions. The backoff time unit S_{b} is 20~T_{s} with T_{s} = 16~ \mu s .

  2. Perform Clear Channel Assessment (CCA) to check if the channel is busy or idle. If channel is idle, go to Step 4, else go to Step 3.

  3. Busy channel: increase the value NB and BE by one. However, the maximum value of BE is macMaxBE . At this time, if NB is less than the value of macMaxCSMABackoffs , the process returns to step one (Otherwise, the process ends with the channel access failure).

  4. Idle channel: the MAC layer sends out the packet and waits for the ACK. If the ACK is received within maximum macAckWaitDuration , the packet is successfully sent. Otherwise, the packet has collided and needs to be retransmitted with retry counter incrementation ( R = R + 1 ). If R exceeds macMaxFrameRetries , the algorithm terminates with collision fail and the packet is discarded (otherwise the algorithm initializes the NB and BE again and returns to Step 1).

FIGURE 2. - The unslotted IEEE 802.15.4 CSMA/CA channel access mechanism considering packet transmissions and retransmissions, adapted from [28].
FIGURE 2.

The unslotted IEEE 802.15.4 CSMA/CA channel access mechanism considering packet transmissions and retransmissions, adapted from [28].

SECTION IV.

Mathematical Model of the Thread Mesh Network

In this section, we propose a system level model for the latency of the Thread mesh network. We analyze the system model considering the implementation of the Thread protocol, from the application layer to the physical layer. In a WSN for BA, we define the round trip time (RTT) as the time duration from the node (border router) sending out a message from the application layer (e.g., CoAP request) until receiving the response from the destination (e.g., CoAP ACK). The parameters used in this paper and a short description of each parameter are provided in Table 1.

TABLE 1 Main Symbols Used in the Paper
Table 1- 
Main Symbols Used in the Paper

A. System Model of Latency of Multi-Hop Thread Mesh Network

The system level model is based on the packet transmission path in the Thread mesh network. Without loss of generality, in Fig. 3, the three-hop round trip procedures are reported. The source node is the border router while the destination node is the end device. The RTT can be separated into two parts: the sending route and the receiving route. The sending route begins at the border router’s application layer and then goes through the network layer, the MAC layer and the physical layer where the transceiver transmits the message. Then the packet will be in the routing path which consists of the over-the-air (OTA) time and the relay nodes’ processing time. When the packet reaches the physical layer of the destination, the destination node starts processing the packet and sending this packet from the physical layer to the application layer. At this point, the sending route is finished while the receiving route begins. The destination node sends back the ACK command following the same route as the sending route.

FIGURE 3. - System level model of the latency of Thread mesh network.
FIGURE 3.

System level model of the latency of Thread mesh network.

Based on the description above, RTT is the sum of three terms: the first is the propagation time from the application layer to the physical layer, denoted as \mathrm {T_{0}} ; the second is OTA time (send and return paths) plus the relay nodes’ processing time \mathrm {T_{1}} ; and the third is the propagation time from the physical layer to the application layer \mathrm {T_{2}} . The whole RTT is defined as:\begin{equation*} T_{\text {RTT}} = 2 \times T_{0} + T_{1} + 2 \times T_{2}\,.\tag{1}\end{equation*}

View SourceRight-click on figure for MathML and additional features. Now, we define in details the components of the previous equation. \mathrm {T_{0}} consists of the processing time from the application layer to the MAC layer, denoted as IP stack (IPS) processing time \mathrm {T_{\text {IPS0}}} , the MAC layer processing time \mathrm {T_{\text {MAC0}}} and the physical layer processing time \mathrm {T_{\text {PHY0}}} , such that:\begin{equation*} T_{0} = T_{\text {IPS0}} + T_{\text {MAC0}} + T_{\text {PHY0}}.\tag{2}\end{equation*}
View SourceRight-click on figure for MathML and additional features.
\mathrm {T_{1}} includes the OTA time and the processing time in the relay nodes. The OTA time can be neglected as the speed of the wireless waveform in the air is the speed of light. Therefore, \mathrm {T_{1}} depends on the relay nodes’ routing time. When relay nodes are forwarding the message, the packets are firstly entering the physical layer, the MAC layer and then the 6LowPAN layer where the next forwarded nodes are decided. Then forwarded messages will go through the MAC layer and the physical layer to transmit to the next node. Once this node receives the MAC ACK back from the next relay node, the forwarding process of this node is finished. The forwarding processing time of one relay node can be defined as \mathrm {T_{\text {ROUTE}}} :\begin{equation*} T_{\text {ROUTE}} = T_{\text {MAC2}} + T_{\text {PHY2}} + T_{\text {PHY0}} + T_{\text {MAC0}}.\tag{3}\end{equation*}
View SourceRight-click on figure for MathML and additional features.
In the Thread mesh network, we indicate the number of hops by h . The total routing time is related to h . Considering the total routing time in multi-hop networks:\begin{equation*} T_{1} = 2 \times (h-1) \times T_{\text {ROUTE}}.\tag{4}\end{equation*}
View SourceRight-click on figure for MathML and additional features.
Similarly, \mathrm {T_{2}} also consists of the processing time of the physical layer \mathrm {T_{ \text {PHY2}}} , MAC layer \mathrm {T_{\text {MAC2}}} and the MAC to application layer time \mathrm {T_{\text {IPS2}}} when receiving the messages. Therefore, \begin{equation*} T_{2} = T_{\text {IPS2}} + T_{\text {MAC2}} + T_{\text {PHY2}}.\tag{5}\end{equation*}
View SourceRight-click on figure for MathML and additional features.

In conclusion, the \mathrm {T_{\text {RTT}}} in Eq. (1) is related to the time \mathrm {T_{ \text {PHY0}}} , \mathrm {T_{\text {MAC0}}} , \mathrm {T_{\text {IPS0}}} , \mathrm {T_{\text {PHY2}}} , \mathrm {T_{ \text {MAC2}}} , \mathrm {T_{\text {IPS2}}} and the number of hops {n} . \mathrm {T_{ \text {PHY0}}} , \mathrm {T_{\text {IPS0}}} , \mathrm {T_{\text {PHY2}}} , \mathrm {T_{\text {MAC2}}} , and \mathrm {T_{\text {IPS2}}} are decided by the hardware factors and the implementation of the Thread protocol. \mathrm {T_{\text {MAC0}}} is the MAC layer service time that is not fixed because of the exponential back-off process in the CSMA/CA mechanism. This random back-off time depends on the traffic rate and the number of nodes in the network. Usually, PGF is used to get the distribution of MAC layer service time. To derive the PGF, two other parameters, the probability of busy channel assessment and packet collision rate need to be calculated as well, which will be discussed in the next two sections.

B. Busy Channel and Collision Probability

In Fig. 2, two probabilities are involved in the channel access and data transmission process, the probability of busy channel assessment (\alpha _{busy} ) and packet collision rate ( p_{col} ). In [18], a Markov chain is proposed to model the MAC traffic in a single-hop IEEE 802.15.4 consisting of N devices that communicate with a PAN coordinator. By considering the slotted version of CSMA/CA with retransmission and ACKs, a three dimension Markov chain is proposed to calculate \alpha _{busy} and p_{col} . The acquired results in [18] provide ground work for our system model considering the un-slotted version of IEEE 802.15.4 with retry limits, ACK and single CCA instead of double CCAs.

According to the stochastic process mechanism, the Markov chain model is described by a three dimensional (3D) {s(t), c(t), r(t)} process as depicted in Fig. 4. {s(t), c(t), r(t)} respectively represent the back-off stage, the state of the back-off counter and the state of the retransmission counter at time {t} . We assume the probability of nodes starting sensing the channel is independent. Therefore, the stationary probability \tau that the node attempts carrier sensing is constant and independent from the other nodes. The protocol MAC parameters are denoted by \mathbf {V} = {(m_{0}, m, n)} , {m_{b}}= \text {macMaxBE} , {W_{0} = 2^{m_{0}}} , {W_{m} =2^{\min (m_{0}+m,m_{b})}} . The states from {(i, W_{m}-1, j)} to {(i, W_{0}-1, j)} are the back-off states. States {(i, 0, j)} represent CCA. State {(-1, k, j)} and {(-2, k, j)} represent the successful transmission and the packet collision state, respectively.

FIGURE 4. - Markov chain model of unslotted IEEE 802.15.4 CSMA/CA revised from [18].
FIGURE 4.

Markov chain model of unslotted IEEE 802.15.4 CSMA/CA revised from [18].

With the help of derived transition probabilities and stationary probability in the Markov chain model, \alpha _{busy} and p_{col} are obtained. They are the essential aspects of the delay analysis of CSMA/CA because they determine the likelihood of CSMA backoffs and retransmission. The term \alpha _{busy} consists of the busy channel access probability due to data transmission (\alpha _{1} ) and ACK transmission (\alpha _{2} ).\begin{align*} \alpha _{busy}=&\alpha _{1} + \alpha _{2}. \tag{6}\\ \alpha _{1}=&L(1-(1-\tau )^{N-1})(1-\alpha _{busy}). \tag{7}\\ \alpha _{2}=&L_{ack} \times \frac {N \tau (1-\tau )^{N-1}}{1-(1-\tau )^{N}} \times \frac {\alpha _{1}}{L}.\tag{8}\end{align*}

View SourceRight-click on figure for MathML and additional features. The collision probability p_{col} is expressed with Eq. 9.\begin{equation*} p_{col} = 1 - (1-\tau )^{N-1}.\tag{9}\end{equation*}
View SourceRight-click on figure for MathML and additional features.
This part rounds off the necessary parameters to derive the probability distribution function of the MAC layer service time. For further details about the terms and the derivation of the equations, the reader can refer to [18] and the original contributor of the Markov Chain [22].

C. Delay Analysis of CSMA/CA Mechanism

In this section, we derive the distribution of MAC layer service time T_{MAC0} . In [23], the PGF of MAC layer service time of IEEE 802.11 was introduced while its revised version adapting to slotted IEEE 802.15.4 was presented in [17]. These two works provide ground works for us to derive the PGF for MAC layer service time of un-slotted IEEE 802.15.4. The MAC layer service time starts at the instant when nodes begin to contend for the transmission and ends at the instant when either the packets are successfully transmitted or the packets are discarded due to channel access failure or retry limits. The distribution is discrete as the back-off interval time is the basic time unit S_{b} . The PGF B(Z) of T_{MAC0} is first derived in order to get the distribution of MAC layer service time. The moment of T_{MAC0} of any degree can be obtained by derivation of B(Z). Below is the mean and variance of T_{MAC0} .\begin{align*} E(T_{MAC0})=&B'(1). \tag{10}\\[4pt] E[(T_{MAC0}-E[T_{MAC0}])^{2}]=&B''(1) + B'(1) - \{{B'(1)}\}^{2}. \\ {}\tag{11}\end{align*}

View SourceRight-click on figure for MathML and additional features. where the prime denotes the derivative with respect to Z. Therefore, we derive the PGFs of T_{MAC0} in the following.

First, we give some definitions as follows:

We denote S_{t}(Z) as the PGF of the time period for successful transmission, C_{t}(Z) the PGF of the time period for collision with acknowledgment, S_{c}(Z) the PGF of the sensing time, and G_{i}(Z) the PGF of time period of fail sensing due to busy channel. The S_{t}(Z) and C_{t}(Z) can be written as:\begin{align*} S_{t}(Z)=&Z^{L_{s}}. \tag{12}\\[4pt] C_{t}(Z)=&Z^{L_{c}}.\tag{13}\end{align*}

View SourceRight-click on figure for MathML and additional features. the symbols L_{s} = L + t_{ack} + L_{ack} + IFS and L_{c} = L_{L+t_{m,ack}} are the time periods for successful packet transmission and packet collision, listed in Table. 1. Therefore, the time period for successful transmission and packet collision are decided by the transmission rate, the packet length and the overhead, and the specific transmission scheme i.e., DATA/ACK scheme.

From Fig. 4, the PGF of the random back-off process H_{i} (Z) can be derived by the production from 0 to {i} -th stage as \begin{equation*} H_{i}(Z) = \prod _{k=0}^{i}W_{k}(Z).\tag{14}\end{equation*}

View SourceRight-click on figure for MathML and additional features.W_{k}(Z) is the PGF of the back-off time at the {i} -th:\begin{align*} W_{k}(Z)=&\begin{cases} \Sigma _{l=0}^{2^{i}W_{0}-1} \dfrac {M_{d}(Z)^{l}}{2^{i}W_{0}} & \text {if $ i\leq m_{b} - m_{0} $}\\[7pt] \Sigma _{l=0}^{2_{m_{b}}-1} \dfrac {M_{d}(Z)^{l}}{2^{m_{b}}} & \text {otherwise}. \end{cases} \tag{15}\\[4pt]=&\begin{cases} \dfrac {1-Z^{2^{i}W_{0}}}{2^{i}W_{0}(1-Z)} &\text {if $ i\leq m_{b} - m_{0} $}\\[7pt] \dfrac {1-Z^{2^{m_{b}}}}{2^{m_{b}}(1-Z)} & \text {otherwise}. \end{cases}\tag{16}\end{align*}
View SourceRight-click on figure for MathML and additional features.

It is assumed that M_{d}(Z) = Z as the decrement of the backoff counter happens with probability 1. Then the signal transfer function of i sensing fail due to busy channel condition G_{i}(Z) is \begin{equation*} G_{i}(Z) = \sum _{k=1}^{i}S_{c}(Z)^{i}.\tag{17}\end{equation*}

View SourceRight-click on figure for MathML and additional features. where S_{c}(Z) = Z is the sensing time. The next step is to derive the PGF of Ts :

Proposition 1:

Let B(Z) be the probability generating function of the MAC layer service time; then, \begin{align*} B(Z)=&S_{t}(Z) \sum _{j=0}^{n}\Pr (\mathcal {S}_{j} | \mathcal {U}_{t})C_{t}(Z)^{j} \\&\times \left ({S_{c}(Z) \times \sum _{i=0}^{m}C_{i}(Z)H_{i}(Z) }\right )^{j+1} + \sum _{j=0}^{n}\Pr (\mathcal {C}_{j} | \mathcal {U}_{t}) \\&\times \left ({\! C_{j}(Z)S_{c}(Z)\sum _{i=0}^{m}G_{i}(Z)H_{i}(Z)\!}\right ) ^{j} G_{m+1}(Z)H_{m+1}(Z) \\&+\, \Pr (\mathcal {F}_{j} | \mathcal {U}_{t}) \left ({C_{t}(Z) \times S_{c}(Z)\sum _{i=0}^{m}G_{i}(Z)H_{i}(Z)}\right )^{n+1}. \\ {}\tag{18}\end{align*}

View SourceRight-click on figure for MathML and additional features. where \begin{align*} \Pr (\mathcal {S}_{j} | \mathcal {U}_{t})=&\frac {P_{c}^{j}(1-P_{c})(1-\alpha _{busy}^{m+1})^{j+1}}{Pr(\mathcal {U}_{t})}. \tag{19}\\ \Pr (\mathcal {C}_{j} | \mathcal {U}_{t})=&\frac {P_{c}^{j}(1-\alpha _{busy}^{m+1})^{j}\alpha _{busy}^{m+1}}{Pr(\mathcal {U}_{t})}. \tag{20}\\ \Pr (\mathcal {F}_{j} | \mathcal {U}_{t})=&\frac {P_{c}^{n+1}(1-\alpha _{busy}^{m+1})^{n+1}}{Pr(\mathcal {U}_{t})}.\tag{21}\end{align*}
View SourceRight-click on figure for MathML and additional features.
with, \begin{align*}&\hspace {-0.5pc}Pr(\mathcal {U}_{t}) = \frac {1-(P_{c}(1-\alpha _{busy}^{m+1}))^{n+1}}{1-P_{c}(1-\alpha _{busy}^{m+1})} (1-P_{c}+P_{c}\alpha _{busy}^{m+1}) \\& \qquad \qquad \qquad \qquad \qquad \qquad{ +\,P_{c}^{n+1}(1-\alpha _{busy}^{m+1})^{n+1}.} \tag{22}\end{align*}
View SourceRight-click on figure for MathML and additional features.
and G_{i} (Z) is given by Eq. (17).

Proof:

The PGF of MAC layer service time is derived from the Markov chain model shown in Fig. 4. A transmission commences whenever the node performs CCA successfully. When a packet transmits in the channel, it has the probability P_{c} of collision. If collision happens, the node initials the new backoff procedure until reaching maximum retransmission time after C_{t}(Z) . The node also has a probability 1 - P_{c} to finish the transmission after S_{t}(Z) . \mathcal {S}_{j} and \mathcal {C}_{j} denote the event of successful transmissions and discarded packet due to channel access failure after j collisions, respectively. \mathcal {F} is the event of discarded packets due to retry limits and \mathcal {U}_{t} means all the possible events \mathcal {S}_{j} , \mathcal {C}_{j} , and \mathcal {F} . the probabilities \Pr (\mathcal {S}_{j} | \mathcal {U}_{t}) , \Pr (\mathcal {C}_{j} | \mathcal {U}_{t}) , and \Pr (\mathcal {F}_{j} | \mathcal {U}_{t}) are given by Eqs. (19), (20), and (21), with the normalization of Pr(\mathcal {U}_{t}) . Since a packet transmits after successfully performing one CCA, the probability for successful channel access is 1-\alpha _{busy}^{m+1} . H_{m+1}(Z) considers the random backoff process while G_{m+1} (Z) is the sensing delay for discarded packets because of channel sensing fails. Now it is possible to derive B(Z) for the packet transmission process shown in Fig. (4). B(Z) is simply the signal transfer function from the start state to the end state as a function of P_{c}, \alpha _{busy}, m, n and Z . Therefore, B(Z) consists of three parts: the first is the successful packet transmission, and the second and third parts consider the time period of the discarded packet due to channel access failure and retry limits. Combing with Eq. (16)–​(17) and (19)–​(22), Eq. (18) follows. This concludes the proof.

As B(Z) is a smooth function of Z , it can be written as power series:\begin{equation*} B(Z) = \sum _{i=0}^{\infty }\Pr (T_{MAC0} = i)Z^{i}.\tag{23}\end{equation*}

View SourceRight-click on figure for MathML and additional features. Therefore, the mean and the variation of the MAC service time T_{MAC0} can be obtained from B(Z) by using Eq. (10) and (11). For further details about the terms and derivation of equations, the reader needs to refer to the works [17] and [18].

Once T_{MAC0} is known, we can also learn the probability distribution of T_{RTT} according to the Eq. (1)–​(5). In the next section, we will experimentally validate the probability distribution of T_{RTT} .

SECTION V.

Numerical Results and Experimental Validation

First, we present the numerical results of the distribution of MAC service time we derived in the previous section by observing the number of nodes in the network and the effect of traffic conditions. Then, to quantify the system level model, the hardware related latencies are further considered in the experimental results. Finally, to validate the system level model we presented in the previous section in Eq. (1), we perform experiments which allow us to confirm the analysis. Details are described in the following.

A. Statistical Probability Distribution of MAC Service Time

By calculating the analytical equations of the model above, the distribution of MAC service time is presented with respect to the node number N and the network traffic conditions \lambda . According to the parameters used in the Thread mesh network, the settings are as follows: m_{0}=5, m=4 , and n=3 . A fixed packet length of L=7 is used in calculations. Fig. 5 (a) shows the probability distribution of MAC service time as a function of different nodes N = 2,5,10,20,30,40,50 with given \lambda = 0.5 , which is drawn by MATLAB. It can be easily observed that with the increase of the node number N , the side lobes of the distribution function also increase and the probability of low latency trapezoid area decreases. The reason is that the increase of node number N will make the network traffics heavier and thus increase both the busy channel probability \alpha _{busy} and collision probability P_{c} . Fig. 5 (b) presents the relationship between network traffic condition \lambda and the probability distributions with node number N = 10 . The heavier the traffic situation in the network, the heavier the tail. This is because increasing traffic rate will also increase the failures in channel sensing and packet transmitting. Besides, node number N has a stronger influence on the probability distributions than \lambda . For N=2 , probability distribution is similar to a deterministic one.

FIGURE 5. - Numerical results of MAC layer service time distribution. (a) shows the relationship between the probability distributions and the node number N with 
$ \lambda$
 = 0.5. (b) shows the relationship between the probability distributions and 
$ \lambda$
 with N = 10.
FIGURE 5.

Numerical results of MAC layer service time distribution. (a) shows the relationship between the probability distributions and the node number N with \lambda = 0.5. (b) shows the relationship between the probability distributions and \lambda with N = 10.

B. Latency Related to Hardware and Software Implementation

In this section, the latency of other layers besides the MAC layer is experimentally investigated, which is closely related to the hardware aspects and implementation of the software stack. First, the hardware platform and the software stack for experimental study are introduced. Second, the experimental tests are presented to understand the latency introduced by hardware and software implementation.

In the experimental study, the hardware board FRDM-KW24D512 and Thread 1.0.0 preview software stack from NXP are used. FreeRTOS is used as the operating system, which may introduce extra latency. Reminding the equation \mathrm {T_{\text {RTT}}} in Eq. (1), \mathrm {T_{\text {PHY0}}} , \mathrm {T_{\text {MAC0}}} , \mathrm {T_{\text {IPS0}}} , \mathrm {T_{\text {PHY2}}} , \mathrm {T_{\text {MAC2}}} , and \mathrm {T_{\text {IPS2}}} need to be known in order to calculate the total RTT . \mathrm {T_{\text {MAC0}}} is the MAC layer service time distribution with respect to node number N and traffic condition \lambda . The other parameters will be gained from the experimental evaluation on the test bed.

In the software stack, the time stamps are added to get the time interval of each layer as shown in Fig. 6. At first, the packet length of 10 Bytes is applied in the test. The results are shown in Table 2. Then the packet length with the varying application layer loads of 20 Bytes, 30 Bytes, 40 Bytes, 50 Bytes, and 60 Bytes are tested in turns. The results show that delays of IPS TX and PHY TX are proportional to packet length. Therefore, linear regression is used to estimate latency in IPS TX and PHY TX states, as shown in Fig 7. Here the data length counts only the payload of the application layer, e.g., CoAP’s payload. The linear regression model fits well with the testing data both in the physical and IPS TX layers. For the physical layer, the delay comes from the packet copying between the micro-controller and radio transceivers through the serial peripheral interface (SPI), where \begin{equation*} T_{\text {PHY0}} = \bigg \lceil \dfrac {L}{vS_{b}}\bigg \rceil.\tag{24}\end{equation*}

View SourceRight-click on figure for MathML and additional features. For IPS TX, it is decided by the copying speed inside the micro-controller in software stack implementation from the application layer to the network layer. The delay of PHY RX, MAC RX, and IPS RX are constant in our test case as the ACK length is fixed, as shown in Table 2.

TABLE 2 Experimental Data of the Thread Latency in Different Layers With Data Length 10 Bytes
Table 2- 
Experimental Data of the Thread Latency in Different Layers With Data Length 10 Bytes
FIGURE 6. - Latency of different layers in Thread network.
FIGURE 6.

Latency of different layers in Thread network.

FIGURE 7. - Experimental test results of physical layer latency and IP stack layer latency.
FIGURE 7.

Experimental test results of physical layer latency and IP stack layer latency.

C. Experimental Validation of Thread Mesh Network

In this section, we experimentally implement a testbed in a real building environment to test the latency of the Thread mesh network and compare experimental results with analytical results.

To establish the Thread multi-hop mesh network, 23 nodes are deployed in four floors, as shown in Fig. 8. The top left side of the figure shows the experimental parameters settings in the test bed. Each node has the ID from 0 to 22. Node 0 is the BR which sends the RTT packets. Nodes 1 to 12 are the active routers while nodes 13 to 22 are the end nodes (ED). In the graph, the red circle in the third floor denotes Thread BR, the root of mesh networks, connecting to our desktop computer. Other nodes are spreading in the building from the base floor to the third floor, mainly in the meeting rooms, lounges and corridors. When the test begins, BR starts sending CoAP GET messages to each node from node 1 to 22. The BR uses its hardware clock to calculate the time interval between sending the message and receiving the ACK. BR sends 300 packets to each node and also records how many hops to reach that node. All the RTT data are divided into six groups according to the hops. For each hop, the cumulative distribution function (CDF) curves are drawn to represent the RTT based on hop counts.

FIGURE 8. - Parameters set-up for the testbed and deployment of nodes in the building.
FIGURE 8.

Parameters set-up for the testbed and deployment of nodes in the building.

Fig. 9 shows the experimental CDF results of the latency of six hops in the Thread mesh network. The probabilities of RTT within 200 ms from one to six hops are near 0.99. In general, RTT increases with the number of hops. The CDF curve interval between their neighbors are close to each other. As the red square shapes note, there exists stair effects in the CDF curve because of CoAP retransmissions. When the first packet drops, CoAP retransmissions are trigged after roughly two seconds and can be trigged up to four times. Fig. 9 shows a small number of packets that experience very long latency once CoAP retransmission is triggered due to packet loss in the lower layers (caused by the negative factors like fading, interference, and path loss). There are more CoAP retransmissions for high number of hops, such as six hops. These long latency packets count less than one percent in the total experiment packets. Note that our proposed analytical model does not consider the application layer retransmission. Thus, we regard these long latency packets as dropout packets.

FIGURE 9. - Experimental results on Cumulative Distributed Function versus Round Trip Time for Thread mesh network.
FIGURE 9.

Experimental results on Cumulative Distributed Function versus Round Trip Time for Thread mesh network.

Recall that the latency of the Thread mesh network can be calculated using the Eq. (1). For h -hop networks, the transmitting delay in MAC layer of all nodes can be obtained using mathematical convolutions of a single hop probability distribution of MAC service time (T_{MAC0} ) by h times. The other delays besides MAC TX can be referred in Section V. Thus, combining the delay of MAC layer and other layer delays, the results of the system model are showing in Fig. 10, both analytical and experimental results on the probability distribution of the latency of the Thread mesh network. It should be noticed that the packets with long latency caused by CoAP retransmission were not plotted in Fig. 10 for the sake of keeping the focus of the modeling part. If these packets were plotted, we would see a few dots with very low amplitude at the far right end of the X axis. The limitation of not considering the application layer retransmission will be investigated in the future work. With such constraint of the model, the latency model fits well with the testing result with respect to different hops. It can be noticed that the distribution of RTT is mainly decided by MAC back-off time.

FIGURE 10. - Analytical and experimental results on the probability distribution of the latency of Thread mesh network.
FIGURE 10.

Analytical and experimental results on the probability distribution of the latency of Thread mesh network.

D. Software Tool to Estimate the Latency of Thread Mesh Network

In this section, a software tool to estimate the latency of the Thread mesh network is implemented using MATLAB R2015B. As Fig. 11 shows, the parameters N, \lambda , m, m_{b}, m_{0}, L, Ls , and Lc can be configured according to the setup of the Thread mesh network. The right side is the figure of the estimation of RTT according to the parameter configuration. It depicts the probability distribution of RTT from one to six hops.

FIGURE 11. - Software tool to estimate the latency of Thread mesh network. Left side is used to configure the parameters and the right side shows the analytical results.
FIGURE 11.

Software tool to estimate the latency of Thread mesh network. Left side is used to configure the parameters and the right side shows the analytical results.

Characterizing latency in smart home and BA applications is an essential aspect of a sound engineering design. Therefore, one important goal is to guarantee QoS in terms of message latency, such as switching the lights or door control within 200 milliseconds (ms). ProSe developers generally lack the information of network delays when developing services, which significantly increases the cost of development and time to market [29]. This tool can solve the issue above. First, this tool reveals the relationships between MAC parameters setting and the latency of the Thread mesh network. Second, this tool gives guidelines for developers to design high quality services and develop user-friendly ProSe.

SECTION VI.

Conclusion and Future Works

In this paper, we investigated the wireless network protocol called Thread for ProSe in smart home and BA, and proposed a theoretical system level model to investigate its latency. Markov chain process and generating functions are used to model the behavior of backoff process in CSMA/CA and to derive the probability distribution of the MAC layer service time. In addition, an experimental validation of the model is carried out showing a good match with the system level model. Based on system level model, we have developed a friendly software tool for estimating latency of Thread mesh network so that the developers can have more information about the communication infrastructures, especially latency, when developing user-friendly ProSe.

However, the system model and experiment results have some limitations. The model does not consider the application layer retransmissions. The future work will include considering this factor in the model. Investigating latency of the multicast communication will also be part of the future work. Also, more complete survey about wireless networks with improved responsiveness for ProSe will also be the future job.

References

References is not available for this document.