Network Coding for Realtime Wireless Communication for Automation
Abstract
Realtime applications require latencies on the order of a millisecond with very high reliabilities, paralleling the requirements for highperformance industrial control. Current wireless technologies like WiFi, Bluetooth, LTE, etc. are unable to meet these stringent latency and reliability requirements, forcing the use of wired systems. This paper introduces a wireless communication protocol based on network coding that in conjunction with cooperative communication techniques builds the necessary diversity to achieve the target reliability. The proposed protocol is analyzed using a communication theoretic delaylimitedcapacity framework and compared to proposed protocols without network coding. The results show that for larger network sizes or payloads employing network coding lowers the minimum SNR required to achieve the target reliability. For a scenario inspired by an industrial printing application with nodes in the control loop, aggregate throughput of Mb/s, MHz of bandwidth and cycle time under ms, the protocol can robustly achieve a system probability of error better than with a nominal SNR less than dB under ideal channel conditions.
Cooperative communication, network coding, lowlatency, highreliability wireless, industrial control, diversity, Internet of Things
BIBcontrol \VerbatimFootnotes
1 Introduction
The Internet of Things (IoT) promises to enable many exciting new applications in healthcare, robotics, transportation and entertainment. In particular, for realtime applications that are interactive and immersive or involve machine control, reliable communication protocols with latencies around ms are crucial [1]. Techniques used by existing wireless standards are fundamentally illsuited for lowlatency and highreliability [2, 3].
Wireless channels are inherently unreliable as movements of objects in the environment cause the channel to change over time.
Diversity is the primary tool to overcome unreliable channels. The availability of a large number of nodes in the network naturally creates opportunities to harvest spatial diversity. Cooperative communication techniques have been well studied in the wireless literature.
Inspired by these cooperative communication techniques, our earlier works [4, 5] introduced a cooperative communication protocol (dubbed “Occupy CoW”) to meet the stringent QoS requirements.
In this paper
The protocol in this paper (“XORCoW”) targets a local wireless domain where nominally all nodes are in range, but fading might cause a pair of nodes to be unable to hear each other. The traffic patterns (referred to as “information topology”) considered are generic – any message ‘stream’ might have several destination nodes (called subscribers) and there are several such streams in a network. Within a short period of time (referred to as “cycle time”), every stream needs to deliver one packet reliably to each of its subscribers. The information topology can be arbitrary – something naturally centralized like a star topology as shown in Fig. 3 (e.g. with a central controller talking to many sensor/actuators collecting streams of measurements and sending streams of commands) or something more generic as in Fig. 3. The XORCoW protocol can support any arbitrary traffic but its performance peaks when the information topology is bidirectional (such as a star). This is due to the inherent twoway traffic that naturally facilitates opportunities for network coding.
The main contributions of this paper are as follows:

A new protocol framework, called XORCoW, for applications that require ultrareliable lowlatency communication that combines cooperative communication and network coding.

Analysis of the performance of XORCoW under a communication theoretic and delaylimited capacity framework.

Comparison of various schemes’ (with and without network coding) performance by comparing the minimum SNR required to meet the QoS requirements.

Optimization of the parameters of XORCoW to show that XORCoW is relatively insensitive to parameter choices. Most of the benefit comes from cooperative communication and network coding, so implementing more complicated schemes is not justified.
The rest of the paper is organized as follows. In Section 2 we first briefly review some of the recent trends in wireless communications, the evolution of communication for industrial control, cooperative communication, wireless diversity, and network coding techniques. For a more detailed treatment of the related work, please refer to [5]. Section 3 describes the resource assumptions and high level overview of Occupy CoW and XORCoW. Section 4 and Section 5 describe the design of XORCoW framework in detail for generic traffic and bidirectional traffic, respectively. Section 6 analyzes the performance of XORCoW and presents how it performs and compares it to hypothetical frequencydiversitybased scheme as well as cooperative communication scheme without network coding. Additionally, it presents how XORCoW protocol’s internal parameters can be optimized and discusses the implications for implementation. All the formulas used to generate the plots are derived in the Appendix.
2 Background
2.1 Recent development in G protocols
The current vision of G wireless standard not only focuses on increasing capacity and energy efficiency, but also on reducing latency. Tactile applications demanding latencies on the order of ms may be enabled by using mmWave frequencies [7, 8]. Recent works like [9] concentrate on the proposed 5GETLA radio interface and show that latencies below ms for payloads of size kb are achievable provided a bandwidth of 100MHz is available. Though the targeted latency is on the same order as required by industrial control, they do not consider reliability guarantees or retransmissions. The feasibility, requirements, and design challenges of an OFDM based 5G radio interface that is suitable for missioncritical MTC (machine type communication) is discussed in [10] where various modulation schemes as well as different MIMO configurations were considered. They concluded that for interference mitigation, multiple receive antennas were crucial. In similar spirit, the coverage and capacity aspects based on evaluations considering both noiselimited and interferencelimited operations for MTC were considered in [11]. Several works have studied the suitability of various signaling strategies for lowlatency applications. Specifically alternatives for OFDM have been considered to relax synchronization requirements and reduce outofband (OOB) transmissions such as Filter Bank Multicarrier [12], Universal Filtered Multicarrier [13] and Generalized Frequency Division Multiplexing [14]. In this paper, we do not consider explicit signaling strategies and push it for future work.
2.2 Industrial Control
Communication in industrial control is supported by wired fieldbus systems like HART, PROFIBUS, WorldFIP, Foundation Fieldbus, and SERCOS [15] meet these requirements. Several wireless extensions of these fieldbus systems such as [16, 17] (as well as WirelessHART [18] and ISA100 [19]) which are based on wireless sensor network (WSN) techniques have been developed. They have worstcase latencies on the order of hundreds on milliseconds [20] making them unsuitable for highperformance control applications. WISA [21] targeted wireless control by employing frequency hopping techniques but it achieves latency on the order of ms with a reliability of [22], which fails to meet the reliability achieved by wired fieldbuses.
2.3 Cooperative communication and multiuser diversity
In our prior work [5], we discussed some of the relevant references on cooperative communication and multiuser diversity in detail. Lowlatency applications that we target cannot use time diversity since the cycle time can be shorter than the coherence time. Additionally, TDMAbased schemes for industrial control considered in [23, 24] do not scale well with network size. Commonly used frequency diversity techniques in WSNinspired technologies [25] like channel hopping and contentionbased MACs aren’t sufficient to obtain the required diversity as they cause unbounded delays. As there are multiple nodes in the system, harvesting cooperative, multiuser diversity is a viable option. Cooperation amongst distributed antennas can provide full diversity without physical arrays [26]. Even with noisy interuser channels, multiuser cooperation increases capacity and leads to achievable rates that are robust to channel variations [27].
2.4 Network Coding
The seminal work of Ahlswede et al., [28] showed that regarding information to be multicast as a “fluid” to be routed or replicated in general is not optimal and employing coding at nodes can lead to efficient use of bandwidth. This idea was further studied in [29], where a forwarding architecture for wireless mesh networks to improve throughput by introducing a coding layer in between the IP and MAC layers was proposed. They provide a practical implementation of network coding into the current network stack, addressing the common case of unicast traffic, and dynamic and potentially bursty flows. Recent results in [30] show that using randomized spacetime block coding (RSTBC) in twoway relay networks improves throughput by exchanging data through a bidirectional relay network. Like most works using network coding, we aim to increase throughput which translates to lower latency. Fig. 4 illustrates how we use network coding combined with simultaneous retransmissions in our work. Essentially, if there is a natural viability for XORing then, only those nodes with the necessary packets help by broadcasting the XORed packet.
The proposed wireless communication system combines cooperative communication and network coding techniques to achieve the desired QoS requirements by exploiting multiuser diversity and distributed spacetime codes (such as those in [31, 32, 33], so that each receiver can harvest a large diversity gain) to achieve highreliability and low latency. The key idea here is that relays simultaneously broadcast coded packets (as long as they are coding the same set of packets).
3 Protocol Framework
The XORCoW protocol exploits multiuser diversity as well as side information at destination nodes by using simultaneous relaying combined with network coding to enable ultrareliable communication. The general setup considered is that the network consists of nodes and each message stream (size bits) must reach its possibly many destinations within a cycle of time . As we discussed in Section 1, the information topology can be arbitrary.
3.1 Resource assumptions
We make a few assumptions about the network, channel characteristics and hardware to abstract away some of the details and to support the exposition. These assumptions hold for all schemes discussed in this paper. The following assumptions are the same as the ones made in [5] for “Occupy CoW” protocol.

We assume a local domain – that while normally, the nodes are within range of each other, bad fading events can cause transmissions to fail. Errors are caused only by bad fades.

All nodes know the information topology. They share a universal addressing scheme and order. Messages are of the same size and they contain their destination addresses.

Channels are assumed to be reciprocal. All nodes are halfduplex, but can switch instantly between transmit mode and receive mode.

Channels are assumed to be quasistatic and remain the same during a cycle.

Channel sounding to aid channel estimation is assumed to take a constant fraction of the cycle time . All nodes are assumed to estimate channels that are being sounded. When multiple nodes simultaneously broadcast a message during the relaying phase, they would not need to spend time again sounding each channel and can do a short combined sounding as the intended receivers only need to identify which of the nodes that it can hear are transmitting.

Clocks on each of the nodes are perfectly synchronized in both time and frequency. One could achieve adequate synchronization with low overhead by adapting techniques such as [34]. Thus we can schedule time slots for specific nodes without significant overhead.

The protocol relies on time/frequency synchronization to achieve simultaneous retransmission of messages by multiple relays. We assume that if relays simultaneously (with consciously introduced timing jitter
^{2} ) transmit the exact same information, then all receivers can realize signal diversity .
3.2 Overview of Occupy CoW Protocol Framework
We briefly summarize the Occupy CoW protocol which would be the benchmark protocol for comparison purposes. For a detailed description, refer to [5]. The XORCoW protocol shares the same network setup and aims to meet the same requirements as Occupy CoW. In the Occupy CoW protocol, the source of different message streams transmit the message in a roundrobin fashion. After all messages have been transmitted once, each message is then retransmitted simultaneously by all the nodes which have the message (either the source or nodes that decoded the first transmission) using some appropriate distributed spacetime code (DSTC) again in a roundrobin fashion. Consider how this would play out for a star information topology as shown in Fig. 3. There is a downlink and uplink phase (corresponding to the first time the messages are transmitted) of length and respectively. This is followed by a scheduling phase where all “strong” nodes get to know the state of each message (whether it has reached the intended destination or not). This is followed by the relaying phases – first the downlink phases II (length ) and III (length ), where the controller and strong nodes alter the broadcast message to remove alreadysuccessful messages for the strong nodes and simultaneously broadcast the adapted packet. The unsuccessful nodes are listening. At the end of this phase, the nodes who received their messages from the controller have also received the global ACK information. which allows these nodes to participate as relays in the uplink phases. The uplink phases II (length ) and III (length ) are similar to their downlink counterparts. The protocol can either have two hops – such that there are only two downlink and uplink phases or three hops – where there are a total of three downlink phases and three uplink phases (as described above).
3.3 Overview of XORCoW Protocol Framework
Consider two nodes (say A and B) that have messages to each other i.e., node A has a message for B and node B has a message for A. If the direct channel exists (link AB), then A’s message to B as well as B’s message to A succeeds in reaching the destination. If there is no direct channel, then A’s message to B may succeed if there is at least one node (say C) that has connection to both A and B. If there exists such a node, then both A’s message to B and B’s message to A succeeds via the same node (or set of nodes). Essentially, when there is a bidirectional traffic, the paths of ‘success’ in both direction are the same. When we have such bidirectional traffic patterns, then relay nodes can ‘XOR’ the packets and broadcast the resulting packet simultaneously using a DSTC as shown in Fig. 4. This is what we leverage in XORCoW – opportunistically network code packets. Network coding also provides throughput benefits (and as a result reduction in latency or reduction in SNR needed) when the traffic patterns are multicast (messages need to reach multiple destinations). We consider this scenario in detail in Section. 4.
4 XORCoW for Generic Information Topology
The XORCoW scheme for a generic information topology can be summarized as follows. All nodes know the information topology – the origin and destinations of the messages. Therefore, all nodes know which messages can be XORed. The schedule of messages are determined and all nodes know the schedule. For the first phase, the schedule is simple: each message stream is allocated one slot. However, in the second phase (XOR phase), the schedule is different: whenever bidirectional traffic exists in the information topology, allocate one slot for those two messages in , else allocate one slot for that single message in (as shown in Fig. 7). In the first phase, nodes take turn according to the schedule to transmit the messages. All nodes listen when they are not transmitting. In the XOR phase, all nodes that can transmit a message (or an XORed message) transmit according to the XOR phase schedule simultaneously using a DSTC. In the following section, we focus on the star topology as network coding yields maximum benefits when the traffic is bidirectional [35, 36].
5 XORCoW for Bidirectional Information Topology
In this section, we consider bidirectional topologies wherein if a node A has information for node B, then node B also has information for node A. A simple case of bidirectional traffic is the star topology which we will consider here for exposition purposes. A centralized control system can be modeled as a star topology where the network consists of a central controller and client nodes. In each ‘cycle’ of time , the controller has distinct bits of message for each client node (downlink messages  DL) and each client node has distinct bits of message for the controller (uplink messages  UL). As in [5], we assume that while normally, the controller and all the nodes are inrange of each other, bad fading events can cause transmissions to fail. Successful nodes, namely those that have received both the downlink message from the controller and the uplink message for a client node in need, XOR the uplink and downlink messages together to form a single packet. They then broadcast the XORed packet simultaneously. The controller uses the XORed packet as well as the downlink information that it already has to decode the uplink packet. The destination node uses the XORed packet as well as the uplink information that it already has to decode its downlink packet.
This scheme has three phases: downlink phase, followed by uplink phase and then the XOR phase. Let the time allocated for the downlink phase be , the uplink phase be and the XOR phase be such that . We will describe the protocol with the aid of Fig. 8 where the network consists of one controller and nodes (S1  S4). To the left of the figure are the downlink buffers at each node (controller and clients) and to the right of the figure are the uplink buffers, also at each node. They get populated as messages are decoded. Initially, the controller’s downlink buffer is full as it is the origin of all downlink messages (shown by the striped buffers) and its uplink buffer is empty. S1  S4 start with their corresponding uplink buffer being full (shown by the striped buffers) and their downlink buffers are empty. The starred messages are those that each user is interested in receiving. The controller is interested in the uplink messages of nodes and the nodes are interested in receiving the specific downlink message intended for them.
Schedules:
There are two versions of the XORCoW protocol that can be employed: a) fixed schedule protocol and b) flexible schedule protocol. The difference between these two mainly lies in the relaying phase – do all nodes get another shot at getting their message across or only those in need? This is illustrated in Fig. LABEL:fig:starschedule.
1) Fixed schedule: In this scheme, time is allocated equally for all nodes in the XOR phase – such that they get another shot at sending their messages.
Since the schedule is predetermined, the time at which the message of a particular node is to be transmitted is also known to all users and there is no real need for a scheduling phase to determine the schedule for the XOR phase.
2) Flexible schedule: In this scheme, time is allocated equally only for the nodes which need help in the XOR phase (and no time is given for the messages that have already reached the destination).
This scheme requires a scheduling phase since the relays need to be told about the nodes that need help.
Keeping these schemes in mind, we describe the protocol under these schemes.
5.1 Downlink and Uplink Phases
During these phases, all the nodes are listening whenever they are not transmitting.
The downlink phase is common in both the fixed and flexible scheduling schemes.
The cycle starts with a downlink phase in which the controller broadcasts a single packet consisting of all bit messages to all nodes at rate .
In Fig 8 column 2, S1 and S2 successfully decode the entire downlink message. Their starred buffers are filled along with the downlink buffers corresponding to other nodes.
Fixed Schedule Scheme: This is followed by the uplink phase, in which the individual nodes transmit their messages to the controller one by one according to a predetermined schedule at rate by evenly dividing the time slots among all nodes.
In Fig 8 column 3, the controller successfully decodes the uplink messages of S1 and S2 and the starred uplink buffers of the controller corresponding to these nodes are filled. Since all nodes are listening whenever they are not transmitting, S1 receives the uplink messages of S3 and S4 while S2 receives the uplink message of S4.
The nodes which have successfully received the downlink message as well as successfully transmitted their uplink message to the controller are referred to as strong nodes. In Fig. 8, S1 and S2 are the strong nodes.
Flexible Schedule Scheme: In the uplink phase of the flexible scheduling scheme, the nodes also transmit a one bit ACK to the controller (indicating whether they’ve successfully received the downlink packet or not). Therefore, the individual nodes transmit their messages (including one bit for an ACK) to the controller one by one according to a predetermined schedule at rate by evenly dividing the time slots among all nodes.
5.2 Scheduling Phase
This phase is crucial when the flexible scheduling scheme is employed. In this phase the controller transmits acknowledgments to the strong nodes (at the same rate as the downlink phase). This is just bits of information per node for downlink and uplink. The commoninformation about the system’s state enables the strong nodes to share a common schedule for relaying messages for the remaining nodes. Note that the schedule only reaches the strong nodes but the nodes which need help do not know the schedule. How will they know which message is intended for them without the knowledge of the schedule? This can be addressed by building in identification of the destination node in the packet such that the nodes can figure out which packet was addressed to them while keeping the transmission rate the same. This approach has been discussed in detail in [37]. Thus, for the remainder of the paper we’ll assume that the nodes know which packet was meant for them.
5.3 XOR phase:
Depending on the scheduling scheme, the time allocated for this phase can either be equally divided among all nodes – corresponding to the rate of transmission is , or only those that need help – corresponding to the rate of transmission is where are the number of unsuccessful nodes. In either case, the strong nodes XOR the downlink and uplink messages of each of the unsuccessful nodes they’ve heard. During the slot of an unsuccessful node (say node ), all the strong nodes that have successfully heard node act as simultaneous broadcast relays and transmit the XORed packet using a DSTC.
In Fig. 8, S3 and S4 are the unsuccessful nodes. In the XOR slot allocated for S3 (Fig. 8 column 3), S1 XORs the downlink and uplink packet of S3 (represented by the purple packet) and broadcasts it. Using the downlink packet of S3, the controller can now recover the uplink packet. Using its own uplink packet, S3 can now recover the downlink packet. The process for S4 is similar and the difference lies in the fact that S1 and S2 simultaneously transmit the XORed packet for S4.
6 Analysis of XORCoW
In this section, we analyze the performance of XORCoW. The performance of XORCoW’s performance for a generic information topology is the same as the performance of Occupy CoW for a generic topology. Therefore, we refer the readers to [5] for the analysis and performance of XORCoW when the traffic is not strictly bidirectional. In this paper, we focus on the performance of XORCoW for star topology only as we reap maximum benefits in this case.
6.1 Behavioral assumptions for analysis
Our analysis depends on the following behavioral assumptions in addition to the resource assumptions in Sec. 3.1. We assume a fixed nominal SNR on all links with independent Rayleigh fading on each link. We also assume channel reciprocity. Our model assumes a singletap channel
A link with channel coefficient and bandwidth is deemed good (thus no errors or erasures) if the rate of transmission is less than or equal to the link’s capacity . Consequently, the probability of link failure is defined as .
As in [4], if there are simultaneous transmissions, then each receiver harvests perfect sender diversity of . For analysis, this is treated as independent tries that only fail in communicating the message if all the tries fail. We do not consider any dispersionstyle finiteblocklength effects on decoding. This can be justified in spirit by [40]. We assume that transmission related errors are always detected [41].
6.2 XORCoW probability of failure
The complete analysis of the performance of the XORCoW protocol is described in the 7. In this section we mainly present the results and state two theorems which are useful in understanding the results.
Theorem 1
If an instance of fixed schedule twohop Occupy CoW protocol (i.e., no rate adaptation in the relaying phases) with equal downlink and uplink phases () succeeds, then there is a common downlink and uplink success path for each node in the network.
If a node successfully decoded the downlink message in one hop, its uplink message also gets through successfully to the controller in one hop (due to channel reciprocity). If a node successfully decoded the downlink message in two hops via a relay , then the same relay helps uplink as well – again due to channel reciprocity.
Theorem 2
If an instance of fixed schedule twohop Occupy CoW protocol with equal downlink and uplink phase 1 () and a given SNR succeeds, then the fixed scheduling version of XORCoW with downlink and uplink phase lengths both equal to and XOR phase length also equals to succeeds at the same SNR.
From Theorem 1 we know that the paths for downlink and uplink success when are the same – i.e., either they directly succeed to the controller or they have the same relay helping in both downlink and uplink. These relays essentially have the capability the XOR the packets as they have both the packets as well as good links for transmission. Hence, as long as the rate in the XOR phase stays the same (this is ensured by ), the XORCoW protocol also succeeds at the same SNR. A corollary of Theorem 2 is that while twohop Occupy CoW would require time to succeed, XORCoW succeeds in time – i.e., a throughput improvement of .
6.3 Results and comparison
We explore the performance of XORCoW with parameters taken from a contemporary practical application, the industrial printer case described in [2]. The SERCOS III protocol [42] supports the printer’s cycle time of ms with system error probability of . We target the following system requirements for the application: moving printing heads that move at speeds up to m/s over distances of up to m. Every cycle lasts ms and in each cycle the controller transmits bytes of actuation data to each head and each of the sensors transmit bytes of sensory data to the controller. Assuming access to a single MHz wireless channel, this Mbit/sec throughput corresponds to an overall spectral efficiency of approximately bits/sec/Hz. SERCOS supports a reliability of and for our protocol we target a reliability of .
We define the cycle failure probability as the probability that any packet transmitted during the cycle did not reach at least one of its destinations. Following [4, 5] and the communicationtheoretic convention, we use the minimum SNR required to achieve reliability as our metric to compare XORCoW to other schemes. Fig. 9 compares the performance of the following protocols a) XORCoW, b) OccupyCoW (the cooperativecommunicationbased protocol not employing network coding), and c) Frequency hopping based protocols. We see that optimized version of Occupy CoW (the best performance that can be obtained without using network coding) and XORCoW with a simple equaltime allocation to different phases perform comparably for bits (the dotdashed lines). The advantage of XORCoW is clear for high aggregate rates and large networks as shown by the solid in Fig. 9. We see that XORCoW beats the performance of Occupy CoW for bits and network size while also being a simpler scheme. The dotted purple curves represent a hypothetical (nonadaptive) frequencyhopping scheme that divides the bandwidth MHz into subchannels that are assumed to be independently faded, for bits and bits. The curves are annotated with the optimal . As (and thus frequency hops) increases, the available diversity increases, but the added message repetitions force each link’s instantaneous data rate to be higher. For low the scheme prefers more frequency hops to exploit diversity benefits. The SNR cost of doing this is marginal because the throughput is low enough that we are still in the linearregime of channel capacity. For networks with fewer than nodes, this says that using frequencyhopping is great — as long as we can reliably count on about independently faded subchannels to repeat across, which is not always practical.
6.4 Optimization
Network Coding Optimization
XORCoW scheme only allows for the opportunity to XOR two packets and not more. Are we making suboptimal decisions by restricting to XORing only two packets? We are not and the reason is as follows. In undirected network (wireless networks considered here can be modeled as undirected networks) the throughput improvement that network coding provides when compared to routing only schemes is upper bounded at [43]. We showed in Sec. 6 that the throughput improvement for the best case i.e., the startopology is actually .
Furthermore, we can model the generic information topology as a multicast session. It has been shown that asymptotically network coding provides no benefits when compared to a pure routing schemes [44]. Additionally, even if we end up with a network realization which can provide significant network coding benefits (a rare event in itself), the coding points (which perform network coding operation) need to know the state of each packet and the network realization to compute the optimium code. The overhead of acquiring this network information state is significant (similar in spirit to why backpressure routing isn’t implemented asis in current networks).
Phase Length Optimization
We consider the XORCoW protocol and look at the optimal allocation of time which minimizes the SNR required to meet the performance specifications. Although the phase length allocations are uneven (as seen in the figure 12), we find that the SNR saving that we achieve by having different lengths is minimal (as seen in the figure 12). The complexity of building a system which can operate at variable rates is extremely difficult and ultimately negates out the small SNR savings achieved by optimization. The strength of the protocol lies in the fact that a simple scheme with equal time allocations with fixed schedule performs almost as good as the optimal scheme – thus paving the way for a practical system.
7 Conclusions & Future Work
In this work, we designed a network coding based wireless communication protocol framework for highperformance controllike systems. We have additionally shown that simple phase length allocations are sufficient and optimizations only provide marginal benefits. In the future, we aim to address the impact of modeling assumptions such as spatial independence, quasistatic behavior, etc., on cooperative communication protocols. Understanding the impact of imperfect sychronization as well as imperfect channel estimation would also be important in making these schemes practical.
We analyze the XORCoW protocol by looking at all the ways at least one of the messages did not reach the destination within the cycle as in [5, 4]. We achieve this by partitioning the nodes into various sets which depend on various aspects like downlink/uplink success and the state of nodenode as well as nodecontroller links in different phases. Before continuing with the analysis itself, we define some notation.
Notation
To effectively present the derived expressions, we provide a guide to the notation that will be used in the following sections. Let a transmission over a single link be an “experiment.” A binomial distribution with independent experiments, probability of success , and number of success will be referred to as
(1) 
Note that the probability is the probability of failure, not the probability of success. The probability of at least one out of independent experiments failing will be denoted as
(2) 
A link with fading coefficient and bandwidth is considered “good” (thus decodable) if the rate of transmission is less than or equal to the link’s capacity, . We assume that the nominal operating SNR is held consistent across the entire system. Consequently, for a rate , the assumption of Rayleigh fading tells us that the probability of an unsuccessful transmission is defined as
(3) 
We assume that if exceeds capacity, the transmission will surely fail (with probability 1). If is less than capacity, the transmission will surely succeed and decode to the right codeword.
Set Notation
We describe the various sets used in the analysis. Following general convention, the set itself will be represented in script font. The random variable representing the number of nodes in that set will be presented in uppercase letters. Finally, the instantiation of that random variable (the cardinality of the set), will be in lowercase letters. The sets being considered are:

: the set of nodes successful in the downlink phase. Further divided into disjoint sets and such that .

: the set of nodes which succeed in downlink as well as uplink phases. This is further partitioned into (the set which connects to the controller in the XOR phase) and (the set which cannot connect to the controller in the XOR phase).

: the set of nodes which do not succeed in uplink. This set is further partitioned into (which can connect to the controller in the XOR phase) and (which cannot connect to the controller in the XOR phase).


: the set of nodes that weren’t successful in downlink phase but were successful in uplink phase. Further partitioned into disjoint sets (has link to the controller in the XOR phase) and (doesn’t have link to controller in the XOR phase) such that .

: the set of nodes that succeed only in the XOR phase – both uplink and downlink successes happen in this phase. They can only succeed through relays.
Analysis of XORCoW:
Let the time allocated for the downlink phase be , the uplink phase be and the XOR phase be such that where is the given cycle time. If we chose to do fixed scheduling then the transmission rates for downlink, uplink and XOR phases are fixed at , and respectively. If adaptive scheduling scheme is employed, then the transmission rates for downlink, uplink and XOR phases are given by , and where is the number of nodes that succeeded in both uplink and downlink phases. These are called “strong nodes” and all the others need help. Without loss of generality we consider the flexible schedule scheme and proceed with the analysis. Depending on the time allocations for different phases and the number of strong nodes , we get the following theorem.
Theorem 3
Let the time allocated for downlink, uplink and XOR phases be , and respectively, the number of noncontroller nodes be , and message size be bits. The downlink and uplink transmission rates are given by and respectively. The corresponding probability of a single link failure, & , is given by Eq. (3). The XOR phase transmission rate is given by where is the number of “strong nodes” in both downlink and uplink phases and the corresponding probability of a single failure , is given by Eq. (3). The probability XORCoW failure is then
where,
is the probability of failure if the relationship between the rates is ,
is the probability of failure if the relationship between the rates is ,
is the probability of failure if the relationship between the rates is ,
is the probability of failure if the relationship between the rates is ,
are the probabilities of failure and success if the relationship between the rates is ,
are the probabilities of failure and success if the relationship between the rates is , where:
All potential relays get the schedules in the scheduling phase where the rate of transmission is the same as downlink rate as stated earlier in Sec. 3. This ensures that all potential relays (those that have the downlink information) know when to transmit. Additionally, all nodes that need help also know which packet is intended for them as their identity is built into the packet. We look at each case to understand the subtle effects that may arise.
Case 1:
The rates of transmission are as described earlier and the probabilities of a link succeeding in downlink, uplink and XOR phases are given by , and respectively. Fig. 15 shows the exhaustive list of ways to succeed in the first case of the XORCoW protocol.

A node can succeed directly to the controller in downlink – these nodes are in set . As the rate in downlink phase is greater than the rate in uplink phase , these nodes also succeed in uplink directly to the controller (so they are an overall success). In this case, as all of retain links in the uplink phase and they are potential relays.

A node can gain a link to the controller at the lower uplink rate of – these nodes are in set . They get their downlink message directly from the controller in the XOR phase as all of them retain the link to the controller in the XOR phase.

A node can have both downlink and uplink successes during the XOR phase, if they connected to in the uplink phase and as the rate in the XOR phase is less than , the links do not disappear.
To calculate the probability of error of the XORCoW protocol, we will unroll the state space and sum over all possible instantiations of the sets of interest that result in failure. The probability of depends on the point to point link to the controller which has a failure probability of (we use Eq. (3)). Thus we have . The probability that a node does not gain a link to the controller in the uplink phase given it did not have a link in the downlink phase is given by . Conditioned on the realization that , the probability that nodes gain links to the controller is given by .
Given and , the probability of a node in , failing in the XOR phase is the probability that it doesn’t connect to in the uplink phase. The probability of a single node failing is given by . Thus the overall probability of failure given and is . Thus we get that the probability of failure of the XORCoW protocol when the relationship between the rates is is given by
where,
Case 2:
The rates of transmission are as described earlier and the probabilities of a link succeeding in downlink, uplink and XOR phases are given by , and respectively. Fig. 15 shows the exhaustive list of ways to succeed in the third case of the XORCoW protocol.

A node can succeed directly to the controller in downlink – these nodes are in set . As the rate in the downlink phase is lower than the rate in the uplink phase, this set is further divided into two disjoint sets (which retains the connection to the controller in the uplink phase) and (which loses the connection to the controller in the uplink phase). The nodes in are the potential uplink message helpers in the XOR phase.

The nodes in succeed directly to the controller in the XOR phase as they have the downlink as well as uplink packets to XOR.

A node can have both downlink and uplink successes during the XOR phase, if they connected to in the uplink phase and as the rate in XOR phase is less than , the links do not disappear.
To calculate the probability of error of the XORCoW protocol, we will unroll the state space and sum over all possible instantiations of the sets of interest that result in failure. The probability of depends on the point to point link to the controller which has a failure probability of (we use Eq. (3)). Thus we have . Given , the probability that a node in loses its link to the controller in the uplink phase is given by . Thus we get the probability that (these do not lose the links) given is . Given and , the probability of a node in , failing in the XOR phase is the probability that it doesn’t connect to in the uplink phase. The probability of a single node failing is given by . Thus, the overall probability of failure given and is . Thus, we get that the probability of failure of the XORCoW protocol when the relationship between the rates is is given by
where,
Case 3:
The rates of transmission are as described earlier and the probabilities of a link succeeding in downlink, uplink and XOR phases are given by , and respectively. Fig. 18 shows the exhaustive list of ways to succeed in the second case of the XORCoW protocol.

A node can succeed directly to the controller in downlink – these nodes are in set . As the rate in downlink phase is greater than the rate in uplink phase , these nodes also succeed in uplink directly to the controller (they are an overall success). In this case as all nodes in retain links in uplink phase. All of these will be potential relays.

A node can gain a link to the controller at the lower uplink rate of – these nodes are in the set . Some of these nodes lose the link during the XOR phase as (since ). The nodes that retain the links constitute the set and the ones which lose the link constitute the set . The set get their downlink message directly from the controller in the XOR phase but the set doesn’t. They need to connect to at least one node in in the uplink as well as XOR phase to successfully receive their downlink message.

A node can have both downlink and uplink successes during the XOR phase, if they connected to in the uplink phase as well as in the XOR phase (similar to ).
To calculate the probability of error of the XORCoW protocol, we will unroll the state space and sum over all possible instantiations of the sets of interest that result in failure. The probability of depends on the point to point link to the controller which has a failure probability of (we use Eq. (3)). Thus we have . The probability that a node does not gain a link to the controller in the uplink phase given it did not have a link in the downlink phase is given by . Conditioned on the realization that , the probability that nodes gain link to the controller is given by . Given , the probability that a node in , loses the connection to the controller in the XOR phase is given by . Thus the probability that given is given by . Given , and the probability of a node in , failing in the XOR phase is the probability that it doesn’t connect to in the uplink and XOR phases. The probability of a single node failing is given by . Thus, the overall probability of failure given , and is . Thus, we get that the probability of failure of the XORCoW protocol when the relationship between the rates is is given by
where,
Case 4:
The rates of transmission are as described earlier and the probabilities of a link succeeding in downlink, uplink and XOR phases are given by , and respectively. Fig. 18 shows the exhaustive list of ways to succeed in the fourth case of the XORCoW protocol.

A node can succeed directly to the controller in downlink – these nodes are in set . As the rate in downlink phase is lower than the rate in uplink phase , this set is further divided into two disjoint sets (which retains the connection to the controller in the uplink phase) and (which loses the connection to the controller in the uplink phase).

The nodes in are further divided to (those that regain the link to the controller in the XOR phase) and (those that do not regain the link to the controller). The nodes in successfully transmit their own uplink message to the controller in the XOR phase as they have the downlink messages to XOR and the link to transmit.

The nodes in succeed only by connecting to in the uplink phase (the link back to them will automatically exist in the XOR phase since ).

Any other node can have both downlink and uplink successes during the XOR phase, if they connected to in the uplink phase and as the rate in XOR phase is less than , the links do not disappear.
To calculate the probability of error of the XORCoW protocol, we will unroll the state space and sum over all possible instantiations of the sets of interest that result in failure. The probability of depends on the point to point link to the controller which has a failure probability of (we use Eq. (3)). Thus we have . Given , the probability that a node in loses link to the controller in the uplink phase is given by . Thus we get the probability that (these do not lose the links) given is . Given and , the probability of a node in gaining a link to the controller in the XOR phase is given by . Thus, we get that nodes gain links to the controller in the XOR phase with probability .
Given , and , the probability of a node in failing in the XOR phase is the probability that it doesn’t connect to in the uplink phase. The probability of a single node failing is given by . Thus the overall probability of failure given and is . Thus we get that the probability of failure of the XORCoW protocol when the relationship between the rates is is given by
where,
Case 5:
The rates of transmission are as described earlier and the probabilities of a link succeeding in downlink, uplink and XOR phases are given by , and respectively. Fig. 21 shows the exhaustive list of ways to succeed in the fifth case of the XORCoW protocol.

A node can succeed directly to the controller in downlink – these nodes are in set . As the rate in downlink phase is lower than the rate in uplink phase , this set is further divided into two disjoint sets (which retains the connection to the controller in the uplink phase) and (which loses the connection to the controller in the uplink phase).

The nodes in are further divided to (those that retain the link to the controller in the XOR phase – thus can act as uplink message relays) and (those that lose the link to the controller). The set can still act a relays for downlink messages.

The nodes in succeed only if they connect to in the uplink phase.

The nodes in succeed only in the following way: they must connect to in the uplink phase (to convey their uplink message). They can receive their downlink message either by connecting to in the XOR phase (this is not guaranteed as the rate in the XOR phase is higher) or by connecting to in the uplink and XOR phase.
To calculate the probability of error of the XORCoW protocol, we will unroll the state space and sum over all possible instantiations of the sets of interest that result in failure. The probability of depends on the point to point link to the controller which has a failure probability of (we use Eq. (3)). Thus we have . Given , the probability that a node in loses link to the controller in the uplink phase is given by . Thus we get the probability that (these do not lose the links) given is . Given and , the probability that a node in loses link to the controller in the XOR phase is given by . Thus, the probability that is given by .
The probability that nodes in succeed is the probability that they connect to in the uplink phase which is given by . Thus the probability that all nodes in succeed is . For the rest of the nodes, let us calculate the probability of success. To succeed, a node must connect to in the uplink phase. Let us consider that the node is connected to nodes in . The probability of this event is . This is essential for uplink success. Downlink can succeed either by connecting to one of these nodes in in the XOR phase or by having a connection to in the uplink as well as XOR phases. Thus we have the probability of downlink success is . Combining the uplink and downlink success we get that a node in succeeds with a probability . Thus, probability of success in Case 5 is given by
(4) 
Thus we get that the probability of failure of the XORCoW protocol when the relationship between the rates is is given by
where,
Case 6:
The rates of transmission are as described earlier and the probabilities of a link succeeding in downlink, uplink and XOR phases are given by , and respectively. Fig. 21 shows the exhaustive list of ways to succeed in the second case of the XORCoW protocol.

A node can succeed directly to the controller in downlink – these nodes are in set . All the nodes in set succeed in uplink as the rate is less than . Thus, .

A node can gain a link to the controller at the lower uplink rate of – these nodes are in set . Note that these succeeded only at and not at and hence these nodes cannot help to get to the controller in the higher XOR phase rate of .

The nodes in are further divided to (those that retain the link to the controller in the XOR phase) and (those that lose the link to the controller in the XOR phase). Only can effectively relay the uplink messages of the nodes in need.

The nodes in succeed only in the following way: they must connect to in the uplink phase (to convey their uplink message). They can receive their downlink message either by connecting to in the XOR phase as well (this is not guaranteed as the rate in the XOR phase is higher) or by connecting to in the uplink as well as XOR phase.
To calculate the probability of error of the XORCoW protocol, we will unroll the state space and sum over all possible instantiations of the sets of interest that result in failure. The probability of depends on the point to point link to the controller which has a failure probability of (we use Eq. (3)). Thus we have . The probability that a node does not gain a link to the controller in the uplink phase given it did not have a link in the downlink phase is given by . Conditioned on the realization that , the probability that nodes gain link to the controller is given by . The probability that nodes in succeed is the probability that they connect to in the uplink phase which is given by . Thus the probability that all nodes in succeed is . Given , and , the probability that a node in loses its link to the controller in the XOR phase is given by . Thus, the probability that is given by .
For the rest of the nodes, let us calculate the probability of success. In order to succeed, a node must connect to in the uplink phase. Let us consider that the node is connected to nodes in . The probability of this event is . This is essential for uplink success. Downlink can succeed either by connecting to one of these nodes in in the XOR phase or by having a connection to in the XOR phase. Thus we have the probability of downlink success is . Combining the uplink and downlink success we get that a node in succeeds with a probability . Thus, probability of success in case 6 is given by
(5) 
Thus we get that the probability of failure of the XORCoW protocol when the relationship between the rates is is given by
where,
Acknowledgements
The authors would like to thank Venkat Anantharam and Sahaana Suri for useful discussions. We also thank BLISS and BWRC students, staff, faculty and industrial sponsors and the NSF for a Graduate Research Fellowship and grants CNS0932410, CNS1321155, and ECCS1343398.
Footnotes
References
 G. Fettweis, “The Tactile Internet: Applications and Challenges,” Vehicular Technology Magazine, IEEE, vol. 9, no. 1, pp. 64–70, March 2014.
 M. Weiner et al., “Design of a lowlatency, highreliability wireless communication system for control applications,” in IEEE International Conference on Communications, ICC 2014, Sydney, Australia, June 1014, 2014, 2014, pp. 3829–3835.
 M. Weiner, “Lowlatency, highreliability wireless networks for control applications,” Ph.D. dissertation, EECS Department, University of California, Berkeley, May 2015.
 V. Narasimha Swamy et al., “Cooperative communication for highreliability lowlatency wireless control,” in Communications (ICC), 2015 IEEE International Conference on, June 2015, pp. 4380–4386.
 ——, “Realtime cooperative communication for automation over wireless,” IEEE Transactions on Wireless Communications, vol. 16, no. 11, pp. 7168–7183, 2017.
 ——, “Network coding for highreliability lowlatency wireless control,” in 2016 IEEE Wireless Communications and Networking Conference, April 2016, pp. 1–7.
 J. Andrews et al., “What Will 5G Be?” IEEE Journal on Selected Areas in Communications, vol. 32, no. 6, pp. 1065–1082, June 2014.
 N. S. Networks, “2020: Beyond 4G: Radio Evolution for the Gigabit Experience,” 2011.
 T. Levanen et al., “Low latency radio interface for 5G flexible TDD local area communications,” in Communications Workshops (ICC), 2014 IEEE International Conference on, June 2014, pp. 7–13.
 O. N. Yilmaz et al., “Analysis of ultrareliable and lowlatency 5G communication for a factory automation use case,” in 2015 IEEE International Conference on Communication Workshop (ICCW). IEEE, 2015, pp. 1190–1195.
 N. Brahmi et al., “Deployment strategies for ultrareliable and lowlatency communication in factory automation,” in 2015 IEEE Globecom Workshops (GC Wkshps). IEEE, 2015, pp. 1–6.
 B. FarhangBoroujeny, “OFDM versus filter bank multicarrier,” IEEE signal processing magazine, vol. 28, no. 3, pp. 92–112, 2011.
 V. Vakilian et al., “Universalfiltered multicarrier technique for wireless systems beyond LTE,” in 2013 IEEE Globecom Workshops, 2013, pp. 223–228.
 N. Michailow et al., “Generalized frequency division multiplexing for 5th generation cellular networks,” IEEE Transactions on Communications, vol. 62, no. 9, pp. 3045–3061, 2014.
 R. Zurawski, Industrial Communication Technology Handbook. CRC Press, 2005.
 A. Willig, “An architecture for wireless extension of PROFIBUS,” in The 29th Annual Conference of the IEEE Industrial Electronics Society, vol. 3, Nov 2003, pp. 2369–2375 Vol.3.
 P. Morel et al., “Requirements for wireless extensions of a FIP fieldbus,” in 1996 IEEE Conference on Emerging Technologies and Factory Automation, vol. 1, Nov 1996, pp. 116–122 vol.1.
 International Electrotechnical Commission, Industrial Communication NetworksFieldbus Specifications, WirelessHART Communication Network and Communication Profile. British Standards Institute, 2009.
 “ISA100.11a, An update on the Process Automation Applications Wireless Standard,” in ISA Seminar, 2008.
 J. Akerberg et al., “Future research challenges in wireless sensor and actuator networks targeting industrial automation,” in Industrial Informatics (INDIN), 2011 9th IEEE International Conference on. IEEE, 2011, pp. 410–415.
 R. Steigmann et al., “Introduction to WISA: Wireless Interface for Sensors and Actuators ,” July 2006.
 A. Willig, “Recent and Emerging Topics in Wireless Industrial Communications: A Selection,” pp. 102–124, May 2007.
 ——, “How to exploit spatial diversity in wireless industrial networks,” Annual Reviews in Control, vol. 32, no. 1, pp. 49 – 57, 2008.
 S. Girs et al., “Increased reliability or reduced delay in wireless industrial networks using relaying and Luby codes,” in IEEE 18th Conference on Emerging Technologies Factory Automation, 2013, Sept 2013, pp. 1–9.
 P. Zand et al., “Wireless Industrial Monitoring and Control Networks: The Journey So Far and the Road Ahead,” J. Sensor and Actuator Networks, vol. 1, no. 2, pp. 123–152, 2012.
 J. Laneman et al., “Cooperative diversity in wireless networks: Efficient protocols and outage behavior,” IEEE Transactions on Information Theory, vol. 50, no. 12, pp. 3062–3080, Dec 2004.
 A. Sendonaris et al., “User cooperation diversity. Part I. System description,” IEEE Transactions on Communications, vol. 51, no. 11, pp. 1927–1938, Nov 2003.
 R. Ahlswede et al., “Network information flow,” IEEE Trans. Inform. Theory, vol. 46, no. 4, pp. 1204–1216, 2000.
 S. Katti et al., “XORs in the air: practical wireless network coding,” IEEE/ACM Transactions on Networking (ToN), vol. 16, no. 3, pp. 497–510, 2008.
 S. Bagheri et al., “Randomized decodeandforward strategies for twoway relay networks,” Wireless Communications, IEEE Transactions on, vol. 10, no. 12, pp. 4214–4225, 2011.
 F. Oggier et al., “Perfect spaceâtime block codes,” IEEE Trans. Inform. Theory, vol. 52, no. 9, pp. 3885–3902, 2006.
 P. Elia et al., “Perfect SpaceTime Codes for Any Number of Antennas,” IEEE Trans. Inform. Theory, vol. 53, no. 11, pp. 3853–3868, 2007.
 G. Wu et al., “Selective Random Cyclic Delay Diversity for HARQ in Cooperative Relay,” in IEEE Wireless Communications and Networking Conference (WCNC), 2010, April 2010, pp. 1–6.
 Q. Huang et al., “Practical Timing and Frequency Synchronization for OFDMBased Cooperative Systems,” IEEE Transactions on Signal Processing, vol. 58, no. 7, pp. 3706–3716, July 2010.
 C. Fragouli et al., “Network coding: an instant primer,” ACM SIGCOMM Computer Communication Review, vol. 36, no. 1, pp. 63–68, 2006.
 Z. Li et al., “Network coding in undirected networks.” CISS, 2004.
 T. S. Han et al., “New results in the theory of identification via channels,” IEEE transactions on information theory, vol. 38, no. 1, pp. 14–25, 1992.
 S. Hanly et al., “Multiaccess fading channels. II. Delaylimited capacities,” IEEE Transactions on Information Theory, vol. 44, no. 7, pp. 2816–2831, Nov 1998.
 L. Ozarow et al., “Information theoretic considerations for cellular mobile radio,” IEEE Transactions on Vehicular Technology, vol. 43, no. 2, pp. 359–378, May 1994.
 W. Yang et al., “QuasiStatic MultipleAntenna Fading Channels at Finite Blocklength,” IEEE Transactions on Information Theory, vol. 60, no. 7, pp. 4232–4265, 2014.
 G. D. Forney, “Exponential error bounds for erasure, list, and decision feedback schemes,” IEEE Transactions on Information Theory, vol. 14, pp. 206–220, 1968.
 “Introduction to SERCOS III with industrial ethernet.” [Online]. Available: http://www.sercos.com/technology/sercos3.htm
 Z. Li et al., “On achieving maximum multicast throughput in undirected networks,” IEEE/ACM Transactions on Networking (TON), vol. 14, no. SI, pp. 2467–2485, 2006.
 V. Narasimha Swamy et al., “An asymptotically optimal push–pull method for multicasting over a random network,” IEEE Transactions on Information Theory, vol. 59, no. 8, pp. 5075–5087, 2013.