## 1 Introduction  
Wireless Sensor Networks (WSNs) are increasingly considered an essential means of gathering information in order to gain competitive advantages. Especially in industrial settings, where the cost of gathering data through retro-fitting sites and processes with traditional wired solutions is sky-high, the appeal of modern wireless alternatives is understandable. In this competitive landscape, the Internet Engineering Task-Force (IETF) defines a number of open protocol layers with the goal of providing easy integration into existing Internet Protocol (IP) infrastructure through end-to-end IP connectivity. Although many attempts at a consolidated IETF stack have been made, most recently resulting in the Internet Protocol (IP) Version 6 (IPv6) over the Time-Slotted Channel Hopping (TSCH) mode of IEEE 802.15.4e [1] (6 TiSCH) specification [2, 3], the Routing Protocol for Low-power and Lossy Networks (LLNs) (RPL) [4] has been a constant throughout these efforts. However, this status quo no longer reflects the capabilities of protocol layers below the routing layer, nor does it answer the threats facing present-day wireless deployments. On the Physical layer (PHY) level, advances in semiconductor manufacturing have made radio chips smaller, cheaper, and more energy efficient than ever, leading to off-the-shelf devices with multiple radios (i.e., multi-interfaced devices) and/or radios that support multiple PHYs. Moreover, as explained by [PERSON] and [PERSON] [5], distance-vector routing protocols such as RPL are susceptible to external stressors such as jamming (malicious) and interference (non-malicious) because of unfortunate properties of certain network repair mechanisms, which may leave the network in a state of convergence for extended periods of time. Given that cross-technology interference has quickly become a chief concern for anyone deploying WSNs, a concept called co-existence, it seems only appropriate to try and harness (at the network-layer level) the capabilities introduced by recent hardware advancements, and of multi-interfaced devices in particular, as a way to (amongst other things) mitigate the negative effects of external stressors on network performance. We shall refer to RPL routing solutions that enable switching between radios at runtime as multi-interface solutions. Single-interface solutions, on the other hand, imply that each RPL-enabled device has only one interface or, otherwise, uses the same radio for all communications. We are not the first to recognize the mismatch between traditional RPL routing configurations and hardware capabilities. According to [PERSON] et al. [6] (p. 611): \"Future research directions may investigate the management and coexistence of dual-band/dual-radio technologies and how the [RPL] management plane should address such capabilities\". In fact, others have come up with extensions to RPL that retain compliance with RFC 6550 [4], such that they may be used as a drop-in replacement for single-interface approaches in existing deployments. However, many of these multi-interface solutions are inconsiderate of their compatibility with adjacent protocol layers (i.e., they typically do not mention how they should operate in conjunction with IPv6 over Low-power Wireless Personal Area Network (6 LoWPAN) Neighbor Discovery (ND) [7,8]), do not consider downward traffic flows (Section 2.3), or are otherwise incomplete in their specification. A more in-depth discussion of related work is provided in Section 3. In an effort to address these shortcomings, we first identified (in literature) a promising multi-interface routing protocol extension in the form of an RPL Objective Function (OF) (Section 2.2) and, from it, derived a working implementation. From there, we designed our own OF and tested it against the aforementioned literature-derived multi-interface solution [9,10], as well as a common single-interface approach [11].