Kyle E Benson
email: kebenson@ics.uci.edu

Georgios Bouloukakis

Casey Grant
email: cgrant@nfpa.org

Valérie Issarny
email: valerie.issarny@inria.fr

Sharad Mehrotra
email: sharad@ics.uci.edu

Ioannis Moscholios

Nalini Venkatasubramanian
email: nalini@uci.edu

FireDeX: a Prioritized IoT Data Exchange Middleware for Emergency Response

Keywords: Publish/Subscribe Middleware, Event Prioritization, Utility Functions, Emergency Response, Queueing Networks, SDN

come

INTRODUCTION

As we move further into a future full of connected devices, the Internet of Things (IoT) promises to revolutionize societal-scale operations and influence our daily lives. It integrates pervasive sensing/actuation, dynamic data analytics, and communications. Domains such as transportation, home automation, healthcare, and emergency response are becoming increasingly IoT-enabled; this provides data-driven insights to improve situational awareness. This is particularly useful in mission critical applications, e.g. to enable effective and timely emergency response. Recent smart city efforts such as the SmartAmerica Challenge and Global City Teams Challenge have showcased the integration of IoT into a variety of community settings and application domains [START_REF] Benson | SCALE: Safe community awareness and alerting leveraging the internet of things[END_REF][START_REF] Inoue | Nerve Net: A Regional-Area Network for Resilient Local Information Sharing and Communications[END_REF][START_REF] Zander | Cyber-physical Systems can Make Emergency Response Smart[END_REF].

A distributed data exchange solution that manages the flow of relevant data to/from devices, systems and individuals (data producers and consumers) is a critical centerpiece of IoT deployments. In this paper, we adopt a publish/subscribe (pub/sub) model for IoT data exchange based on our previous experiences with such systems and the popular use of pub/sub (e.g. MQTT [START_REF] Oasis | [END_REF]) in IoT implementations. In mission critical emergency scenarios, IoT devices can forward raw sensor data to interested recipients (e.g first responders and emergency management agencies) through a data exchange broker to help coordinate the response effort. We consider IoT sensors as publishers, all manner of data as events, and interested entities (i.e. human stakeholders or other IoT devices and services) as subscribers. Data exchange brokers route information to actuators (e.g. alarms), data analytics services that detect new events, or to a local logging database for post-incident analysis and forensics. Key challenges arise when enabling timely data exchange to a diverse set of recipients including: managing heterogeneous information with varying size, format, relevance, urgency, etc.; seamless integration of new IoT data sources with pre-existing sources and information on the fly; supporting reliable and timely communication over constrained networks (e.g. due to lossy channels and failed components).

To overcome these challenges, we propose FireDeX, an integration middleware that unifies (a) smartspace IoT data and infrastructure (e.g. a Smart Building Management System (BMS)) with (b) programmable network infrastructure (e.g. through Software-Defined Networking (SDN)) and (c) domain specific applications (e.g. smart fire fighting systems and apps brought onsite by emergency responders). FireDeX aims to support timely and reliable delivery of the most critical data to relevant subscribers despite challenging network conditions. It utilizes the cross-layer (i.e. application and network-aware) approach for IoT data exchange shown in Fig. 1 and described here. It leverages edge computing (i.e. data exchange brokers at the network edge) and SDN to bridge critical application requirements with network state. This approach facilitates platform and device independent adaptation of IoT communication at the middleware layer. Using SDN, FireDeX configures the underlying physical network to prioritize messages according to the requirements (i.e. subscriptions with utility functions that quantify situational awareness) and underlying network resource constraints (e.g. bandwidth, error). Through the use of priority queues and carefully tuned packet drop rates (i.e. for bandwidth allocation), it ensures timely delivery of the most important data possible. To this end, we construct an extensible queueing theoretic model to abstract the cross-layer flow of data. We present our formal analysis that our proposed novel algorithms leverage to configure the data exchange. These algorithms manage active subscriptions by separately assigning priorities to each and then allocating bandwidth to them. Our simulation-based experiments validate our model/analysis, demonstrate the FireDeX approach's efficacy, and compare its core algorithms with alternatives.

The FireDeX middleware combines several novel capabilities and design features, notably the following key contributions:

• Applying a cross-layer approach (application, middleware, networking) to prioritizing mission critical IoT data exchange during a fire response scenario in an IoT-enhanced smart building with SDN-enabled edge infrastructure. ( §2) • Formulating an extensible formal model of these three layers based on the unified framework of queueing theory. This model includes our new multi-class priority queueing model. We use it here to represent an SDN switch, but it is generally suitable for use in other queueing networks. ( §3) • Leveraging the above queueing model to explore the configuration parameter space and derive novel algorithms that prioritize IoT events and tune notification delivery/delay. FireDeX leverages SDN to configure the underlying physical network with priority queueing disciplines and carefully tuned packet drop rates (i.e. for bandwidth allocation). ( §4)

THE FIREDEX APPROACH

To motivate the need for prioritized IoT data exchange, the challenges involved, and our proposed approach, we begin with an IoT-enhanced structural fire scenario.

A Driving Scenario: Fire Fighting with IoT

During a fire, an occupant or automated system activates an emergency dispatch process. A local fire department(s) responds by sending a team of fire fighters (FFs). An Incident Commander (IC) coordinates the effort from an Incident Command Post (ICP) set up onsite. To effectively manage the dynamic response and minimize casualties, injuries, and property damage, the IC requires up-to-date situational awareness information. Today the IC still derives much of this information from non-digital sources (e.g. human-initiated reports via voice and/or FF radio, paper records) and collates it in an ad-hoc manner to guide operations. However, smartspaces equipped with IoT devices enable access to live data feeds that can generate actionable information in real-time through proper filtering, prioritizing, and analysis. Such a data-driven approach to improving FF outcomes fuses sensor data producers with consumers (e.g. analytics) and actions (e.g. device actuations, alerts). This improves the efficacy of the classical fire response workflow, thereby driving the emergence of Smart Fire Fighting (SFF) technologies.

In 2015, the US National Institute of Standards and Technology (NIST) and National Fire Protection Association (NFPA) published the Research Roadmap for Smart Fire Fighting (Res. Roadmap) [START_REF] Hamins | NIST Special Publication 1191 Research Roadmap for Smart Fire Fighting[END_REF] that "establishes the scientific and technical basis" of SFF. This interdisciplinary collaboration brought together members of industry, government, the fire science practice, and academia to identify technologies and key challenges in SFF.

Maintaining up-to-date situational awareness for SFF requires the integration and enrichment of static and dynamic data from buildings and IoT infrastructure. Static information such as building floor plans, inspection histories, and presence of hazardous material can be gathered apriori. Dynamic information published by IoT devices (in the building and brought by FFs) must be delivered to relevant subscribers (e.g. analytics services) and combined with contextual knowledge to generate situational awareness. Different data types vary in importance to responders depending on the situation (e.g. "smoke" > "water pressure" when initially sizing up the event and vice versa during active fire suppression).

Stakeholders (e.g. IC, FFs, residents) request data and visualize it using e.g. dashboards, heads-up displays, mobile alerts. The IC assesses building occupancy for coordinating evacuations, tracks the locations and biometrics of FFs to ensure their safety and effectiveness, and detects environmental hazards within the building such as high temperature or smoke levels. A key challenge for SFF is delivering mission-critical data for "timely, targeted decision making" in an unreliable, partially available, and congested network environment [START_REF] Hamins | NIST Special Publication 1191 Research Roadmap for Smart Fire Fighting[END_REF]. Given the heterogeneous value of events and limited resources for delivering notifications, we believe event prioritization is necessary in such mission-critical settings. To this end, we propose the FireDeX data exchange middleware to manage the flow of situational awareness information. It assigns and enforces event priorities according to the requirements and capabilities of three middleware layers: application, data exchange, network.

Background on IoT Data Exchange

Several research challenges for mission-critical IoT data exchange arise from the above driving SFF scenario.

Heterogeneity of devices and information: Heterogeneous IoT devices in buildings/structures (e.g. sensors, cameras) produce data that varies in size, frequency (periodic samples vs. asynchronous alerts), type, and importance to individual subscribers [START_REF] Behnel | On quality-of-service and publish-subscribe[END_REF][START_REF] Salehi | PopSub: Improving resource utilization in distributed content-based publish/subscribe systems[END_REF][START_REF] Zhang | Subscription covering for relevance-based filtering in content-based publish/subscribe systems[END_REF][START_REF] Zhang | Efficient covering for top-k filtering in content-based publish/subscribe systems[END_REF]. In existing structures, this complexity is handled by a BMS that locally manages devices and data. Recent work on smart buildings includes ontologies [START_REF] Balaji | Brick: Towards a Unified Metadata Schema For Buildings[END_REF] and protocols to support building automation [START_REF] Bushby | NISTIR 6392 GSA Guide to Specifying Interoperable Building Automation and Control Systems Using ANSI/ASHRAE Standard 135-1995[END_REF], techniques to preserve privacy [START_REF] Mehrotra | TIPPERS: A privacy cognizant IoT environment[END_REF], enabling energy efficiency [START_REF] Weng | BuildingDepot 2.0: An Integrated Management System for Building Analysis and Control[END_REF], programmable building operating system services [START_REF] Dawson-Haggerty | BOSS: Building Operating System Services[END_REF], context aware IoT management via SDN [START_REF] Kathiravelu | Cassowary: Middleware Platform for Context-Aware Smart Buildings with Software-Defined Sensor Networks[END_REF], and accurate positioning for location based apps [START_REF] Chen | BearLoc: A Composable Distributed Framework for Indoor Localization Systems[END_REF].

To manage both scale and heterogeneity, we design FireDeX as an edge middleware that leverages existing IoT infrastructure and services managed by a third-party BMS. Its pub/sub approach integrates capabilities of new devices/tools brought on scene by responders, while separating operational and ownership concerns. Note that external entities often lack the knowledge, access, and expertise to reconfigure local devices. This might conflict with existing configurations customized by building IoT administrators.

Managing smart spaces at scale in real time: Tuning data collection parameters at each device (e.g sampling rate, resolution) for individual subscribers is not always viable, especially as the number and diversity of devices scales. FireDeX's edge broker approach naturally supports scalability; geographically-dispersed subscribers interconnect through a distributed network of data exchange brokers. This network may be hierarchical: top-level brokers running in cloud data centers serve a large region with many local brokers running in edge data centers to serve a smaller local area (e.g. one or a few buildings, a campus). FireDeX can leverage work in large-scale pub/sub systems [START_REF] Bellavista | Quality of Service in Wide Scale Publish-Subscribe Systems[END_REF][START_REF] Salehi | PopSub: Improving resource utilization in distributed content-based publish/subscribe systems[END_REF][START_REF] Zhang | Efficient covering for top-k filtering in content-based publish/subscribe systems[END_REF] as well as research into managing data exchange configurations according to data processing workload characteristics [START_REF] Mayer | Predictable low-latency event detection with parallel complex event processing[END_REF][START_REF] Thalheim | Sieve: actionable insights from monitored metrics in distributed systems[END_REF]. Other related research proposes similar centralized control of IoT data exchange [START_REF] Jararweh | SDIoT: a software defined based internet of things framework[END_REF][START_REF] Zhang | SDN-like: The Next Generation of Pub/Sub[END_REF].

Managing unreliable IoT networks: Communications are often constrained in crisis scenarios. FireDeX leverages SDN to manage networking for IoT deployments by offloading network configuration tasks from constrained devices and network hardware.

SDN APIs (e.g. OpenFlow [START_REF] Mckeown | OpenFlow: Enabling Innovation in Campus Networks[END_REF], P4 [START_REF] Bosshart | P4: Programming Protocol-independent Packet Processors[END_REF]) provide a unified view of and control over the underlying network infrastructure. An SDN controller (e.g. ONOS [START_REF] Berde | ONOS[END_REF]) observes the underlying network by querying switches for various statistics e.g. packets sent/received, loss rates, etc. SDN provides a variety of abstractions to represent the underlying physical network. These include authorized access to directly manage physical switches, control over virtual (softwarebased) switches [START_REF] Pfaff | The Design and Implementation of Open vSwitch[END_REF] (e.g. running alongside the broker), network virtualization [START_REF] Blenk | Survey on Network Virtualization Hypervisors for Software Defined Networking[END_REF] to reserve "slices" of the physical infrastructure, etc. Recent research into SDN-enabled 5G cellular architectures [START_REF] Khan | Resource allocation in SDN based 5G cellular networks[END_REF] supports the potential for such interfaces that connect emergency responder devices to the building's internal network.

SDN-based approaches have been used in general IoT networks to: configure QoS-enabled routing [START_REF] Lin | A QoS-aware routing in SDN hybrid networks[END_REF][START_REF] Qin | A software defined networking architecture for the internetof-things[END_REF]; differentiate pub/sub subscriptions at the network level and prioritize them separately to provide bounded queueing delays [START_REF] Wang | Pursuing Differentiated Services in a SDN-Based IoT-Oriented Pub/Sub System[END_REF]; manage wireless IoT sensor networks [START_REF] El-Mougy | Software-defined wireless network architectures for the Internet-of-Things[END_REF]; for meet real-time data flow processing delays through prioritization [START_REF] An | Dynamic priority-adjustment for real-time flows in software-defined networks[END_REF]. Recent research [START_REF] Benson | Ride: A Resilient IoT Data Exchange Middleware Leveraging SDN and Edge Cloud Resources[END_REF][START_REF] Bhowmik | High performance publish/subscribe middleware in software-defined networks[END_REF][START_REF] Muhammad | PLEROMA: A SDN-based high performance publish/subscribe middleware[END_REF] used SDN to enable high performance pub/sub through network-level multicast. FireDeX's extensible design can easily integrate such techniques.

Research on Network Utility Maximization (NUM) [START_REF] Yi | Stochastic network utility maximisation -A tribute to Kelly's paper[END_REF] aims to tune the underlying network according to application-level requirements. NUM configures a network (e.g. assigns bandwidth) to serve nodes in a manner that maximizes utility functions that capture a user's degree of satisfaction with the network's performance. Few prior researchers have investigated discrete priority classes, which we leverage in our approach, within the context of NUM. The authors of [START_REF] Nguyen | How to Maximize User Satisfaction Degree in Multi-service IP Networks[END_REF] propose assigning more bandwidth to users (i.e. via weighting their requests higher) based on their requested priority levels. Similarly, [START_REF] Samie | Distributed QoS Management for Internet of Things Under Resource Constraints[END_REF] manages IoT devices to maximize utility by allocating bandwidth and offloading processing, but the authors do not use SDN or consider the data exchange middleware and prioritized application requirements. Our cross-layer approach and consideration of utility functions sets apart our work from most related SDN research referenced above.

Modeling cross-layer data exchange interactions: To analyze IoT data exchange performance we must consider all three layers' characteristics and their effects on each other. However, existing efforts typically focus on each layer in isolation. Therefore, we model cross-layer interactions by composing and extending previous work at each layer through the unified framework of queueing theory [START_REF] He | Formal analysis of publish-subscribe systems by probabilistic timed automata[END_REF][START_REF] Schröter | Stochastic performance analysis and capacity planning of publish/subscribe systems[END_REF]. Queueing Petri Nets (QPNs) enable accurate performance prediction in pub/sub systems [START_REF] Kounev | A methodology for performance modeling of distributed eventbased systems[END_REF][START_REF] Sachs | Performance modeling and analysis of message-oriented event-driven systems[END_REF]. Alternatively, [START_REF] Bouloukakis | Timeliness Evaluation of Intermittent Mobile Connectivity over Pub/Sub Systems[END_REF][START_REF] Bouloukakis | Performance Modeling of the Middleware Overlay Infrastructure of Mobile Things[END_REF] model and analyze the performance of pub/sub and middleware protocols using Queueing Networks (QNs). While QPNs have an advantage over QNs in representing parallelism, QNs provide convenient primitives to construct well-formed performance models for efficient analysis [START_REF] Vernon | A comparison of performance Petri nets and queueing network models[END_REF]. Furthermore, QNs have been extensively applied to model network infrastructure performance [START_REF] Cory | Prioritization of emergency network traffic using ticket servers: A performance analysis[END_REF][START_REF] Heng Foh | Optimized cross-layer design for scalable video transmission over the[END_REF][START_REF] Gill | Network information flow in network of queues[END_REF][START_REF] Halabian | Network capacity region of multi-queue multi-server queueing system with time varying connectivities[END_REF] and more recently SDN infrastructure [START_REF] Faraci | A building block to model an SDN/NFV network[END_REF][START_REF] Singh | Modelling Software-Defined Networking: Switch Design with Finite Buffer and Priority Queueing[END_REF][START_REF] Sood | Performance analysis of softwaredefined network switch using M /Geo/1 model[END_REF].

Enabling Event Prioritization

We now overview how the FireDeX middleware addresses the above challenges. We frame our discussions in terms of the three layers depicted in Fig. 1: mission-critical applications, abstractions representing the physical network infrastructure, and the data exchange middleware that bridges these two to manage the overall system configuration and flow of information. As shown in Fig. 2, FireDeX integrates other middleware technologies: data APIs for interfacing with IoT data (i.e. through the BMS), a local pub/sub broker, a thin client middleware running on each subscribing IoT device, Figure 2: FireDeX middleware architecture and SDN APIs for managing local network infrastructure. It implements the proposed algorithms and provides middleware APIs for our data prioritization and network management approach. To ensure delivery of the most important events despite network resource constraints (e.g. failures, poor signal strength, limited bandwidth), it prioritizes events and allocates available network bandwidth according to application requirements.

Application layer: FireDeX subscriber devices run a client middleware to establish broker connections, retrieve a list of event topics, subscribe to relevant ones, and report data exchange/network channel statistics. Because different data vary by importance, we propose prioritizing events according to their relative importance to the emergency response effort. To configure this, subscribers register utility functions with their FireDeX subscriptions. These functions capture a quantified measure of value for varying rates of event delivery performance. Our proposed algorithms consider these utility functions when configuring the data exchange and network to maximize users' utility (i.e. situational awareness).

Data exchange layer: FireDeX prioritizes subscriptions according to their subscriber-specified utility functions. It leverages the queueing theoretic analysis we present in §3 to estimate system performance under a given configuration. This analysis drives the algorithms presented in §4 that assign discrete priority classes and allocate available network bandwidth. FireDeX connects subscriber clients and the BMS data APIs with the pub/sub broker, which performs the actual routing of events.

While some existing data exchange implementations and protocols support priorities, configuring them requires specific APIs [START_REF] Pivotal | RabbitMQ[END_REF]. Furthermore, many popular options (e.g. the MQTT [START_REF] Oasis | [END_REF] protocol and associated broker implementations) do not support priorities and so require equal treatment of all events transmitted to the same subscriber. To decouple FireDeX from the underlying data exchange broker, which may be specific to the site's BMS, we do not employ application-layer (i.e. in-broker) prioritization. Rather, we propose enforcing priorities at the network layer through unified APIs provided by SDN. This approach accounts for both applicationlevel requirements (e.g. utility functions) and network-level state information (e.g. available bandwidth) without mandating (or extensively modifying) specific broker technologies. Hence, FireDeX essentially extends the data exchange broker/protocol with network and application-aware prioritization.

Network layer: FireDeX manages network infrastructure through APIs provided by an SDN controller that likely runs alongside the BMS (i.e. at the edge). It gathers network state information to derive resource constraints. It combines these with the subscribers' information requirements to drive its management algorithms. The authors of [START_REF] Zhang | SDN-like: The Next Generation of Pub/Sub[END_REF] previously advocated a similar approach of centrally gathering a global view of a pub/sub system's state to simplify its management. They refer to this central control approach as SDNlike because it separates the pub/sub control and data plane. They further propose integrating SDN with the data exchange middleware, which this centralization cleanly enables. We advocate for this approach in IoT settings where offloading device management and data processing from constrained devices typically leads to centralized (i.e. cloud-centric) designs. For simplicity of discussion, we consider the big switch model shown in Fig. 1 that abstracts the entire local physical network into a single virtual SDN switch. This provides a simplified single-network view of the whole distributed system that may span multiple physical heterogeneous networks (e.g. building Wi-Fi and local cellular) and different locations.

To enforce event priorities at the network layer, FireDeX leverages SDN APIs. It configures priority queueing disciplines for packets matching the different subscriptions. However, for the network to distinguish the data exchange-layer concept of subscriptions, we must first translate it to a network-level concept. As shown in Fig. 3, we accomplish this through the SDN concept of network flows. SDN switches match incoming packets of a particular network flow according header information. For example, OpenFlow considers OSI Layer 2-4 fields: IP/MAC address, UDP/TCP port, VLAN, etc. To differentiate subscriptions as belonging to different network flows, a FireDeX subscriber maintains multiple network connections with the pub/sub broker (e.g. over different Layer 4 port numbers). This may represent different applications running on the same device and/or one application opening multiple connections. The latter case enables the network to distinguish and manage individual groups of subscriptions based on their assigned connection. The data exchange middleware layer dictates this assignment of (possibly multiple) subscriptions to one network connection and its corresponding unique network flow. Subscribers initiate multiple connections and then register each subscription to avoid directly configuring the underlying data exchange broker. FireDeX also assigns each network flow a priority level by considering subscriber requirements. It configures the SDN switches to forward packets matching these network flows through the proper priority queue.

To manage available network resources, FireDeX also allocates bandwidth to each network flow. It applies preemptive packet drop rates that consider the utility of each network flow's subscriptions. We propose dropping lower-priority packets before switch buffers fill up to prevent high delays and dropping of higherpriority packets. §4.3 discusses this concept further and proposes our optimization-based algorithm for setting these drop rates. This algorithm is partly inspired by the aforementioned research in Network Utility Maximization (NUM). However, in FireDeX subscribers actually define the utility functions according to their information needs, and so they indirectly cooperatively control the assignment of bandwidth. Furthermore, our proposal leverages discrete priority

FIREDEX FORMAL MODEL

From the above scenario, we formulate a generalized model for prioritized data exchange in mission-critical settings. FireDeX combines queueing theoretic approaches from both the middleware and network layers to construct the representative and extensible 3-layer queueing network shown in Fig. 4. The data exchange middleware bridges the network infrastructure and application layers to enable a novel cross-layer end-to-end performance model. We derive this analytical model to estimate a particular configuration's expected performance.

Queueing Network Performance Modeling

Refer to Table 1 for the notations used throughout this section.

3.1.1 Application Modeling. Let V p i ⊆ V be the set of topics each p i publishes to e.g. "smoke". Let λ pub p i ,v j be the publication rate of events with topic v j published by p i per unit time. Assumption 1. λ pub p i ,v j is based on a Poisson process.

We define each subscription as a tuple r j = (s i , v j , U r j ) where utility function U r j quantifies the information value for subscriber s i receiving events with topic v j . Let R s i = {r j ∈ R : s i ∈ r j } be the set of prioritized information requests (i.e. subscriptions) for each subscriber s i . Let λ sub r j be the incoming rate of events matching subscription r j received per unit time by subscriber s i .

Let Ξ r j be the success rate of delivering events matching subscription r j = (s i , v j , U r j ) to subscriber s i . By Assumption 1, we can estimate Ξ r j (i.e. by summing Poisson process rates to produce the rate of an aggregate Poisson process) as:

E Ξ r j = λ sub r j p i ∈P λ pub p i ,v j
Let ∆ r j be the response time: the average end-to-end delay of events matching subscription r j = (s i , v j , U r j ) from the moment they are published until s i receives them. Below we calculate this metric, which includes event processing times, network delays, etc.

Data Exchange

Modeling. The data exchange layer represents a network of broker nodes B. We assume that each publisher/subscriber connects with a single broker that we refer to as its home broker: b p i is the broker that p i publishes to and b s i is the broker that subscriber s i receives events from. Furthermore, we define the set of publishers connected with b k as

P b k = {p i ∈ P : b k = b p i },
R b k = ∪ s i ∈S b k R s i .
A broker b k forwards events with rate λ as the sum of all (post-network transformation) event publication/forwarding rates over all publishers/brokers:

λ in b k = p i ∈P b k v j ∈V p i Γ λ pub p i ,v j , p i , b k + b i ∈B,b i b k Γ λ f wd b i ,b k , b i , b k
Note that Γ, which we define in §3.1.3, represents network-layer traffic shaping due to error rates, administrative policies, etc.

Forwarding, replication, or dropping of events based on current subscriptions occurs at the exit of

Q in b k . Let µ in b k be Q in b k
's service rate for analyzing an incoming event and determining where to forward it (e.g. based on a topic routing tree). We assume µ in that captures the time it takes to map an event matching subscription r j to the corresponding connection of s i . It forwards these publications into the network layer with rate λ not if y b k ,r j . Hence, we calculate the per-subscriber forwarding rate as:

λ not if y b k ,s i = r j ∈R s i λ not if y b k ,r j
FireDeX Configuration Parameters: The data exchange layer also represents the FireDeX configuration service. FireDeX associates each subscription with one of the network flows f j ∈ F in order to manage subscription traffic in a network-aware manner. Recall from §2.3 that network flows represent multiple connections between a subscriber and its home broker. We define the set of network flows for a particular subscriber s i as F s i ⊆ F. Additionally FireDeX defines a set of unique priority classes y j ∈ Y . It assigns each network flow to a priority class for managing network traffic in an application-aware manner. Note that y j has higher priority than y k for j < k, i.e. y 0 = 0 is the highest priority.

To configure the end-to-end data exchange interactions across all 3 layers, FireDeX employs the following functions:

w x k ,h j ∈ W , w x k ,h j ∈ N bandwidth between x k and h j G v j ∈ Z >0 serialized packet size for topic v j z h j ,h i ∈ Z , z h j ,h i ∈ [0, 1] packet error rate Γ : N × H × H → N
transforms event departure to arrival rates (e.g. packet errors)

f j ∈ F network flows y j ∈ Y unique priority classes
Ψ : R → F is the function mapping subscriptions (i.e. events matching them) to the corresponding subscribers' network flows. Note that we denote Ψ(s i , v j ) = Ψ(r j ) as the network flow for subscription r j = (s i , v j , U r j ) and so Ψ : S × V → F. As described in §2.3, this mapping allows the SDN data plane to distinguish packets containing events from each other based on their topics. Φ : F → Y is the function mapping network flows to priority classes. This defines which priority class (i.e. priority queue) the SDN infrastructure uses for a packet transmitted on network flow f j . This packet contains event(s) matching subscriber s i 's subscription r j where f j = Ψ(r j ). Hence Φ • Ψ(r j ) is subscription r j 's priority.

Ω : F → [0, 1] is the function mapping network flows to preemptive packet drop probabilities. By dropping some packets on a network flow, FireDeX more accurately tunes the data exchange configuration than through priority assignment alone. Somewhat akin to network traffic policing, this technique lowers the bandwidth usage of a network flow so that the aggregate bandwidth needs of all flows does not exceed that available. By dropping packets in the lower-priority flows, this prevents switch buffers from filling up and dropping higher-priority packets.

Network Modeling.

Publications forwarded to the network layer are encapsulated in packets for transmission by the SDN infrastructure. To simplify the analysis used in our queueing model, we leverage the following: Assumption 2. The data exchange and applications encapsulate each event in a single packet for transmission through the network.

Let X be the set of SDN switches that connect with the various hosts H. A host h j may have multiple physical network interfaces/connections to one or more switches and packets between two hosts may traverse multiple routes. However, SDN abstractions support the following assumption that simplifies our analysis: Assumption 3. We consider multiple switches/routes between two hosts as aggregated into a single virtual SDN switch/link that captures the underlying physical network topology and characteristics.

By Assumption 3, we need only to model a single big switch serving a publisher or subscriber. Hence, we refer to x s i as the FireDeX-managed SDN switch that controls traffic between b s i and s i . We refer to x p i as the unmanaged SDN switch that exposes the network characteristics (defined below) of the network channel between b p i and p i . Note that FireDeX does not manage the latter switch because this might conflict with deployment-specific IoT device configurations. To model multiple hosts sharing the same network medium (e.g. a wireless channel), we apply Assumption 3 and model such a channel as one switch serving multiple hosts. We therefore define the set of subscribers served by switch x k as S x k = {s i ∈ S :

x s i = x k }, all of their subscriptions as R x k = {∪ s i ∈S x k R s i },
and and all of their network flows as F x k . Similarly, let P x k = {p i ∈ P : x p i = x k } be the set of publishers served by x k .

Let Q um x i be the queue modeling the unmanaged switch x i that encompasses a publisher-broker or broker-broker link. By Assumption 2, we have the packet arrival rate for publications and forwarded events at switch x i as λ pub p i ,v j and λ f wd b i ,b k ,v j respectively. We model Q um

x i as a multi-class queue, which enables us to calculate the average transmission delay of a packet (∆ t x r j ) based on its size. Each class corresponds to the topic of an event encapsulated within a packet. Hence, we define the expected serialized size (e.g. in bytes) of a packet that, by Assumption 2, contains a single event published to topic v j as G v j ∈ Z >0 . By Assumption 3, we have w x k ,h j as the bottleneck bandwidth available between two hosts (i.e. from the switch x k serving them to the destination host h j ). Therefore, we can define a per-topic packet transmission rate as:

µ um x i ,v j = w x i ,b k G v j
This enables calculating the average transmission delay ∆ um x i of packets in Q um x i . We apply Γ to packets departing the switch queue Q um

x i in order to transform event departure rates from a host h j to event arrival rates at the destination host h i . To simplify our analysis, we leave retransmission of packets for future work and instead consider only packet error rates. Let z h j ,h i ∈ [0, 1] be this packet error rate that, by Assumption 3, allows us to model packet drops at the single switch between these hosts. We have the arrival rate of publications (on topic v j from publisher p i at broker b k ) as:

Γ λ pub p i ,v j , p i , b k = 1 -z p i ,b k λ pub p i ,v j
We define the transformed arrival rate of events forwarded from broker b i to b k similarly.

FireDeX: a Prioritized IoT Data Exchange Middleware for Emergency Response Middleware '18, December 10-14, 2018, Rennes, France

We model each managed SDN switch encompassing a brokersubscriber link as two different queues: 1) an M/M/1 queue Q in x k that feeds into 2) our newly-proposed queueing model: a nonpreemptive priority and multi-class queue Q out x k . By Assumption 2, we therefore have the arrival rate at switch x k of event-encapsulating packets within a network flow f j as λ in x k , f j .

Q in

x k processes each incoming packet by matching its header contents to a corresponding network flow f j and determining the assigned priority (i.e. Φ(f j )). Let µ in

x k be the service rate at Q in x k that captures the time required to perform this matching (e.g. an SDN switch TCAM lookup), assign the given priority, and route the packet to the appropriate output port. Note that this might actually capture delays from forwarding packets along a multi-switch route. Before enqueueing the packet at the correct output port, the switch first applies the dropping policy to each flow according to the FireDeX-computed function Ω(f j ). Because our model does not consider further packet drops in Q in x k or before Q out x k , we have the per-subscription arrival rate at Q out x k as:

λ t hr u x k ,r j = 1 -Ω • Ψ r j λ not if y b k ,r j (1)
Multi-class priority queue Q out x k separates the departure rates of each packet according to its serialized size and the switch's available bandwidth. Note that the assigned priority class affects the response time but not the departure rates of these packets. By Assumption 2, we therefore have the service (i.e. transmission) rate of packets encapsulating events that match subscription r j = (s i , v j , U r j ) from SDN switch x k to subscriber s i as:

µ out x k ,r j = w x k ,s i G v j
We have the departure rate from Q out x k as: λ out x k ,r j = λ thru x k ,r j . We then apply Assumption 2 and Γ to packets departing switch queue Q out

x k . Considering packet error rates, we have the arrival rate of events at subscriber s i matching subscription r j = (s i , v j , U r j ) as:

Γ λ out x k ,r j , b s i , s i = λ sub r j = 1 -z b s i ,s i λ out
x k ,r j

End-to-end Analytical Model

We now leverage the above queueing network to derive theoretical performance results. This analysis, the accuracy of which we validate in §5.2, enables FireDeX to tune the data exchange performance characteristics of end-to-end event response time and delivery success rate. To calculate ∆ r j , the end-to-end response time of events for subscription r j , we calculate the propagation and queueing delays at each layer. Note that the queueing delay in our model captures the real-world processing and network transmission delays.

To simplify our analysis, we exploit the local nature of our target scenario and consider only a single broker (b k ) in the remainder of this section. Future work will explore relaxing this assumption and extending this analysis to include the more general scenario of a distributed broker network enabled by our queueing network model above. By the above assumption, we calculate the per-subscription end-to-end response time metric as:

∆ r j = E ∆ pr op p i ,b k + ∆ um x p i + ∆ b k + ∆ pr op b k ,s i + ∆ x s i (2)
where ∆ pr op b k ,h j ∈H is the propagation delay (i.e. physical network latency) between the broker and another host h j (b k or s i ). ∆ um x p i and ∆ x s i are the transmission delays of packets passing through switches x p i and x s i respectively. ∆ b k is the processing delay of events passing through b k .

We must estimate the heterogeneous propagation delays for this subscription's events from each possible publisher on topic v j i.e. {p i ∈ P b k : v j ∈ V p i }. By our single broker assumption, we have this as the expected delay from any such publisher to broker b k . In the same manner, we estimate the queueing delay at the intermediate switch x p i . Therefore, we have:

E ∆ pr op p i ,b k + ∆ um x p i = {p i ∈P b k :v j ∈V p i } ∆ pr op p i ,b k + ∆ um x p i |{p i ∈ P b k : v j ∈ V p i }|
The average response time of (2) includes queueing delays at each layer of FireDeX. Based on the queueing network representing FireDeX (see Fig. 4), we identify the type of each queueing model and their arrival/processing/transmission rates.

At the data exchange layer we use M/M/1 queues. Based on standard solutions for M/M/1 queues [START_REF] Lazowska | Quantitative system performance: computer system analysis using queueing network models[END_REF], we have the time that an event remains in the system (i.e. queueing time + service time; also called average delay) given by:

∆ Q mm1 (µ, λ) = 1 (µ -λ) (3)
At the network layer, we use three different types of queueing models: i) the M/M/1 queue (Q in x k ); ii) the multi-class queue (Q um x i ) and iii) the non-preemptive priority and multi-class queue (Q out x k ). As already pointed out, we model the transmission of packets inside the unmanaged switch queue (Q um x i ) using a multi-class queue (each class corresponds to the topic of an event encapsulated within a packet). Based on standard solutions [START_REF] Lazowska | Quantitative system performance: computer system analysis using queueing network models[END_REF], the average delay for a particular subscription r k is given by:

∆ Q mcl (µ, λ, r k ) = 1 µ r k -µ r k r j ∈R λ r j /µ r j (4)
where λ = {λ r j : r j ∈ R } and µ = {µ r j : r j ∈ R }.

Finally, the SDN switch is modeled using the non-preemptive priority and multi-class queue (Q x k ). Hence, the average delay of packets for r k assigned with y j is given by:

∆ Q mcl pr (µ, λ, r k , y j ) = L r k ,y j (λ, µ) λ r k (5)
where λ = {λ r j : r j ∈ R }, µ = {µ r j : r j ∈ R } and L r k ,y j is the number of events matching subscription r k with assigned priority y j (where Φ • Ψ(r k ) = y j ) in the system (queue + server) of Q mclpr . We omit the proof of (5) due to space constraints, but the analysis is similar to that of Section 3.4.2 in [START_REF] Gross | Fundamentals of queueing theory[END_REF]. By relying on the above analytical models, we calculate the average delay of events for any subscription r j at each node and layer of the FireDeX queueing network according to [START_REF]AMQP Working Group 0-9-1[END_REF].

Data Exchange: at this layer the average delay at b k (∆ b k ) is given by calculating the queueing delay of events matching r j at both

inbound (Q in b k ) and outbound (Q out b k ,s i ) queues -i.e., ∆ b k = ∆ Q in b k + ∆ Q out b k , s i
∆ b k = ∆ Q mm1 µ in b k , λ in b k + ∆ Q mm1 µ out b k ,r j , λ t hr u b k ,s i (6)
Network: at this layer the average delay (∆ um

x i ) at the unmanaged switch x i (publishers-broker link) is given by calculating the queueing delay of packets matching r k at the multi-class Q um x i queue. Hence, using the analytical model of ( 4) such a delay is given by:

∆ um x i = ∆ Q mcl {µ um x i ,v j : v j ∈ V}, {λ pub p i ,v j : p i ∈ P x i , v j ∈ V p i }, r k
At the SDN switch x k (broker-subscribers link) the average delay (∆ x k ) is given by estimating the queueing delay for packets matching r j at both inbound (Q in x k ) and outbound (Q

out x k ) queues - i.e., ∆ x k = ∆ Q in x k + ∆ Q out x k
. In the M/M/1 queue Q in x k packets arrive at a per-flow rate λ in x k , f j and are served with rate µ in x k . Hence, by

applying (3), ∆ Q in x k = ∆ Q mm1 µ in x k , λ in x k , f j .
The outbound queue (Q out x k ), a multi-class and non-preemptive priority queue, has a per-subscription packet arrival rate λ thru x k ,r j . Its service rates µ out x k ,r j capture the specific event/packet size of the corresponding r k = (s i , v j , U r j ). Hence, we apply (5) to find:

∆ Q out x k = ∆ Q mcl pr {µ out x k ,r j : r j ∈ R x k }, {λ t hr u x k ,r j : r j ∈ R x k }, r k , Φ • Ψ(r k ) (7)

DATA EXCHANGE CONFIGURATION ALGORITHMS

The core algorithms of FireDeX leverage the above analytical model to configure the SDN-enabled data exchange. Considering current system state and information requirements, they assign priorities and preemptive drop rates to subscriptions (i.e. via Φ • Ψ, Ω) in order to maximize subscriber-defined utility functions.

Utility Functions

To capture the relative value of information for different subscriptions, we propose using utility functions. Subscribers include a utility function with their subscriptions. They depend on the rate of successful event delivery Ξ r j . The overall utility for a subscriber depends on each of its subscriptions' utilities and is defined as:

U s i = r j ∈R s i U r j (Ξ r j )
Let U r j be a subscription's maximum achievable utility: delivering the maximum number of events under ideal network conditions (i.e. no loss, minimal latency, no other traffic to contend with).

To further capture the relative value of information between each subscriber, we consider an overall utility of all subscribing first responders. Each subscriber may define different utility functions to capture the fact that each of their needs vary (e.g. the IC may require more situational awareness than individual FFs). We define the overall utility of the configuration for all subscribers as a sum over each individual subscriber's utility:

U = s i ∈S U s i
To model heterogeneous information requirements in our experiments, we generate different utility functions for each subscription. We define the base utility function as:

U r j (Ξ r j ) = α r j log(1 + Ξ r j ) (8)
Where the utility weight α r j is varied for each subscription.

Priority Assignment Algorithm

FireDeX leverages the above quantified utility metrics to assign priorities for each data flow in a manner that aims to maximize the overall utility. We decouple the assignment of priorities from that of drop rates for two reasons. Prioritization ensures the most important events get through first, but it does not necessarily provide guarantees about how much data is delivered. Hence, we first assign the priorities and then optimally set the preemptive drop rates to tune bandwidth usage for the network flows in each priority class. Second, this decoupling allows us to explore different policies in these two spaces independently.

Because the assignment of discrete priorities to maximize utility is non-trivial, we propose a heuristic to approximate a solution. It first ranks subscriptions according their maximum utility U r j scaled by the corresponding required bandwidth. This metric essentially measures information value per unit bandwidth and lets FireDeX consider that some high-value subscriptions may consume a lot of network resources. We define this metric as:

U r j G v j λ not if y b k ,r j (9)
To approximate a solution to the priority-assignment problem, we propose the following greedy approach for each subscriber s i :

(1) Sort the subscriptions r j ∈ R s i by ( 9 This priority assignment ensures delivery of the highest-priority events if possible. However, an overloaded system will fill switch buffers and lead to high delay and loss of lower-priority events. Hence, we apply preemptive drop rates to avoid such a case.

Ensuring Queue Stability via Preemptive Drop Rates

Given the above priority assignment, FireDeX further fine-tunes the subscriptions' successful notification rate Ξ r j . Based on requested subscription utility functions and current network state (e.g. bandwidth constraints), it applies a preemptive packet dropping policy. This improves overall utility of the system's configuration by essentially allocating available bandwidth to the network flows. Crucially, this bandwidth allocation also ensures queue stability throughout the network. That is, if packets arrive at the switches' inbound queues too quickly, the forwarding queues will grow in size until the buffers fill up and packets are dropped. To prevent the dropping of high-value events, FireDeX preemptively drops lower-priority packets. The algorithms presented here determine with what probability packets of each network flow should be dropped (Ω(f j )) to improve situational awareness while ensuring queue stability. Not only does ensuring queue stability improve system performance, it also satisfies conditions necessary for our analytical model's results to prove accurate. Let ρ Q = λ µ be the server utilization (i.e. probability that the server is busy) of the corresponding queue (e.g. Q out

x k ). By [START_REF] Gross | Fundamentals of queueing theory[END_REF] the system remains unsaturated (i.e. queue stability is ensured) when ρ Q < 1. For FireDeX's

M/M/1 queues (i.e., Q in b k , Q out b k ,s i , Q in x k ) we define: ρ Q in b k = λ in b k µ in b k , ρ Q out b k , s i = λ t hr u b k , s i µ out b k , r j and ρ Q in x k = λ in x k , f j µ in x k
. FireDeX's multi-class queues Q um x i and Q out x k have per-topic and per-subscription arrival and service rates respectively. We have their server utilization as:

ρ Q um x i = P x i v j ∈V p i λ pub p i ,v j µ um x i ,v j (10) ρ Q out x k = r j ∈R x k λ t hr u x k ,r j µ out x k ,r j (11)
To improve successful delivery rate while ensuring queue stability, we propose several algorithms of increasing sophistication below. Note that these algorithmic formulations currently only consider the outbound queue of the SDN switches for this constraint as tuning the drop rates only affects

ρ Q out x k
. Also recall that this queue captures the bottleneck bandwidth of the network route from broker to subscriber. Future work will explore simultaneously balancing the load across data exchange brokers to also ensure stability of their queues within our model.

Each algorithm makes use of a parameter ρ in tuning the system's tolerance to approaching, but never exceeding, the queue saturation point of ρ Q out x k = 1. Clearly, to satisfy the strict inequality ρ Q out x k < 1 we must have ρ > 0. Setting ρ even higher provides ample buffer within the SDN switch queues for resilience to temporary notification rate spikes that might otherwise lead to queue saturation. Even if this condition is just barely satisfied (e.g. ρ = 10 -10 ), queues will still grow quite large and thereby cause high delay.

Therefore, the following drop rate policies set Ω such that:

ρ Q out x k = 1 -ρ (12)
Flat drop rates: this simple naive policy sets all drop rates equal to satisfy Eq. ( 12) by solving Eq. ( 11) for a parameter β such that:

Ω(f j ) = β (13)
Linear drop rates: this more information value-aware policy sets the drop rates for each network flow according to its assigned priority level. It solves Eq. ( 11) for a parameter β that satisfies Eq. [START_REF] Blenk | Survey on Network Virtualization Hypervisors for Software Defined Networking[END_REF] with drop rates set to:

Ω(f j ) = βΦ(f j ) (14)
Exponential drop rates: similar to Linear, this policy sets drop rates according to priority level. It solves Eq. ( 11) for a parameter β that satisfies [START_REF] Blenk | Survey on Network Virtualization Hypervisors for Software Defined Networking[END_REF] with drop rates set to:

Ω(f j ) = 1 -β -Φ(f j ) (15)
Optimized drop rates: the following convex optimization formulation assigns drop rates to maximize overall utility. Given the previously-assigned priorities as input, FireDeX assigns drop rates by solving the following convex optimization problem:

maximize U subject to Ω(f j ) ∈ [0, 1], ∀f j ∈ F ρ Q out x k ≤ 1 -ρ, ∀x k ∈ X (16)
Note that the second constraint ensures available bandwidth constraints are met (i.e. queue stability) according to the ρ parameter.

As long as the chosen utility functions are concave (e.g. logarithm) within the feasible domain of assigned drop rates, then ( 16) can be expressed as a convex optimization problem and efficiently solved. Hence, we define such a utility function, such as that given in [START_REF] Benson | SCALE: Safe community awareness and alerting leveraging the internet of things[END_REF], that takes as input our analytical model for determining λ sub r j . Because this is an affine function over the drop rates, we can optimally solve for drop rates that maximize the overall system utility. We used CVXPY [START_REF] Diamond | A Rewriting System for Convex Optimization Problems[END_REF][START_REF] Diamond | CVXPY: A Python-Embedded Modeling Language for Convex Optimization[END_REF] to implement this approach in the FireDeX middleware.

EXPERIMENTAL RESULTS

FireDeX uses the analytical model given in §3.2 to estimate endto-end response times and success rates for event notifications to interested subscribers. We validate this analysis by using and extending an open source queueing simulator to represent our proposed system. We compare the subscribers' end-to-end response times given by the analytical model with those given by the simulation. Note that we omit the trivial results for validating success rates. In order to improve the figures' legibility, we did not include error bars in our plots as the simulation results' confidence intervals are very small (less than two orders of magnitude from the corresponding mean values presented in the plots). We further validate the model's accuracy under greater numbers of subscribers.

After validating our model, we then use it in combination with the simulator to evaluate the FireDeX approach for a given configuration. In particular, we compare our approach's efficacy with that of an unprioritized system and evaluate the trade-off between response times and success rates. We use our proposed priorityassignment algorithm, which we call bandwidth-adjusted-prio, and the exponential drop rate policy. Subsequently, we utilize the analytical model only to compare different algorithms' ability to maximize the overall value of information captured.

Experimental Setup

We developed a Python-based framework that models the realworld scenario given in §2.1 and provides input data for our simulations. We configure it to consider two classes of topics that represent events: sensor telemetry readings published periodically and asynchronously-published notifications that indicate real-world phenomena detected from analysis of raw sensor readings. This framework leverages the probability distributions and parameters given in Table 2 to generate random configurations for each publisher, subscriber, the broker, and the network. For example, it selects the publication rate and packet size of events from the given distributions. Note that we bound these values to maintain more realistic parameters by redrawing a new one when it lies outside the given range. Note that the actual topics published and subscribed to are chosen uniformly at random from those available. The model presented in §3 generically captures a very wide range of scenarios and system configurations. To reduce the number of variables we explore in our experiments, we only simulate a single (i.e. last-hop) SDN switch between the broker and subscriber. Recall that this represents the bottleneck bandwidth and transmission delays. Also note that propagation delay and error rates are typically modeled as constant values. Hence, we ignore them for these experiments to focus instead on the variable delays our model aims to capture. Furthermore, we consider only 9 priority classes due to practical limitations of many existing network traffic and data exchange management systems. For example, Linux TC [START_REF]Linux TC[END_REF] and AMQP 0.9.1 [START_REF]AMQP Working Group 0-9-1[END_REF] only support 8 and 10 priority queues respectively. Queueing network simulator: after generating these configuration parameters for a single instance of a scenario, the above framework feeds them into a simulator to drive its pseudo-random number generators. That is, these parameters correspond to the expected values of the probability distributions from which the simulator draws the actual individual publications' arrival times and packet sizes. Note that we use exponential distributions in order to maintain our assumption of Poisson arrival/service rates. This simulator extends JINQS [START_REF] Field | JINQS: An extensible library for simulating multiclass queueing networks[END_REF], a Java simulation library for multiclass queueing networks. JINQS provides a suite of primitives that allow developers to rapidly build simulations for a wide range of queueing networks. We leverage this power and extend JINQS to: i) represent the queueing network introduced in Fig. 4; ii) implement our new multi-class and non-preemptive priority queueing model; iii) simulate pub/sub interactions using a set of configuration parameters provided by our Python-based framework. To evaluate FireDeX, we generate parameters and run the simulator 10 times for each configuration and then average across these. Each run generates approximately 6,500,000 publications to accurately calculate per-subscription response times and success rates. ).

Validating our Queueing Network Model

To prove the accuracy of the theoretical analysis we developed in §3.2, we now compare its estimated performance metrics with those calculated from the aforementioned simulator.

Varying traffic loads.

Recall that the SDN switch's outbound queue (shown in Fig. 4) captures the bottleneck bandwidth of the network route from broker to subscriber. FireDeX uses the corresponding server utilization (ρ

Q out x k
) to decide the bandwidth tuning by assigning drop rates. Therefore, we parameterize the simulated queueing network to vary the system's network traffic load: [START_REF] Bellavista | Quality of Service in Wide Scale Publish-Subscribe Systems[END_REF]. Note that the saturated case (3rd) corresponds to the default parameters in Table 2. To achieve the medium-load (1st) and high-load (2nd) cases, we set the number of subscriptions for each topic class respectively: i) 21,15; and ii) 42,24.

a) medium-load conditions (ρ Q out x k = 0.6); b) high-load conditions (i.e. close to saturation -ρ Q out x k = 0.95); c) overloaded conditions (i.e. saturated -ρ Q out x k = 1.
Fig. 5 shows the results of these experiments according to assigned priority class and averaged across all topics, subscribers, etc. Comparing the curves of both the simulated measurements and the analytical results obtained by Eq. (2) reveal our model's high accuracy. We notice small differences for events with lower priority levels. In particular, note priority level 8's differences: 0.35 ms in and5c, we deem these results acceptable. In Fig. 5c, FireDeX uses our drop policy mechanism to drop packets at the SDN switch and return the system to below saturation (i.e. ρ Q out

x k = 0.9 by using ρ = 0.1).

5.2.2

Scaling up number of subscribers. We now validate our analytical model's accuracy under varying numbers of subscribers: |S | = 1, 10, 20, 50, 100. To maintain the same degree of system saturation (i.e. ρ Q out x k = 1.7), we increase the bandwidth proportional to the number of subscribers: w x k ,s i = 8Mbps. We keep all other parameters according to Table 2. According to these parameters, we measure the simulated mean response times and plot them vs. those calculated using (2) in Fig. 6. Note the curve for each number of subscribers that shows response time increasing with the priority class. From this comparison, we see that the absolute deviation between the two curves does not exceed 10 ms across all priority levels. Therefore, our model remains accurate even with higher numbers of subscribers.

Evaluating the FireDeX Approach

We now compare our approach's efficacy with that of an unprioritized system and a system without preemptive packet drops.

We apply a buffer capacity of k packets for the simulator's SDN switch outbound queue. This models a real-world switch dropping packets when the buffer fills up. It drops the incoming packet if its priority class is less than or equal to the lowest priority class of those in the buffer. Otherwise, it evicts lower-priority packets to make space in the buffer. We set k = 2000 based on reported buffer sizes of various real-world SDN switches [START_REF]Buffer requirements[END_REF]. Additionally, we configure this queue in 3 different ways: i) No priority assignment or drop policy features (i.e. a simple switch that treats all packets identically and only drops incoming ones when its buffer has filled up) ii) Priority assignment only (i.e. no drop rates) iii) Both priorities and drop rates (i.e. the complete FireDeX approach)

These experiments use the parameters given in Table 2. Figs. 7 and 8 show the success rates and end-to-end response times, respectively. Configuration (i) results in a 58% average success rate and 0.9 sec average response time regardless of assigned priority. End-to-end response time (sec) k=2000 packets without priorities k=2000 packets with priorities k=2000 packets with priorities and drop policy The configuration (ii) experiments used the algorithm we proposed in §4.2, which we call bw-adjusted-prio, for assigning priorities to each network flow (i.e. to their contained subscriptions and associated packets). The results demonstrate that priority assignment significantly improves both response times and success rates for higher priority subscriptions. In particular, subscriptions with priorities 0-4 have a response time less than 4 ms and 100% success rate. However, the success rate of lower priority subscriptions suddenly decreases while the response time increases to the order of seconds. For instance, those with priority 6 have a 45% success rate and 11 sec. response time. Additionally, subscriptions with priorities 7,8 have very low success rates (almost all packets dropped), while those events successfully delivered have a high response time of 20 sec.

The results for configuration (iii) demonstrate how applying drop rates further improves response time to the order of milliseconds. Specifically, priority 0-6 subscriptions have a response time under 6 ms, whereas those with priority 8 have a response time of 647 ms. The most important subscriptions (i.e. priority 0) have 100% success rate. The FireDeX exponential drop rate policy smoothly decreases the success rate proportional to the priority level. This demonstrates our approach to controlling the success rate based on a subscriber's available bandwidth in order to achieve lower response times. Next, we compare the level of overall utility achieved using the various priority assignment and drop rate algorithms that base their configurations on the subscriptions' utility functions.

Comparing Prioritization & Drop Rate Algorithms for Situational Awareness

We now compare different algorithms' ability to maximize the value of information captured for a given configuration. We measure this as the achieved utility rate: the ratio of a subscription's max utility ( U r j ) to achieved utility averaged over all subscriptions. Fig. 9 compares our proposed priority-assignment algorithm (named bw-adjusted-prio) with: no priorities (i.e. a single queue; named no-prio), randomly-assigned priorities (i.e. to show the poor performance resulting from inaccurate priority assignment; named random-prio), and a naive version of the proposed greedy algorithm that, when ranking subscriptions, considers only max utility without scaling by the bandwidth requirement (named info-prio). This figure shows how leveraging network awareness when assigning priorities improves the achieved utility rate by 12% vs. the naive version and 36% vs. no prioritization. Note that we do not assign drop rates for the priority algorithms comparison. Instead, we configure the simulator to drop packets once the buffers fill up in order to compare the priority-assignment algorithms only. With drop rates, FireDeX improves the value of exchanged data by 42% vs. prioritization only and 94% vs. no prioritization.

We then compare the four drop rate-assignment algorithms outlined in §4.3 in conjunction with the best-performing bw-adjustedprio algorithm. To demonstrate FireDeX's ability to improve situational awareness for heterogeneous data and information requirements, our experiments varied the utilities of each topic class relative to the other. We increase the random variable distribution parameters used to generate the utility weights (α r j ) of one topic class relative to the other (i.e. telemetry data vs. the higherutility higher-bandwidth lower-publication frequency asynchronous events). Fig. 10's x-axis shows the factor we scale up the asynchronous event class's α r j by as compared with the Table 2 defaults. These results demonstrate the optimization-based algorithm's superiority in capturing the most overall utility (i.e. it maximizes situational awareness) given particular network conditions.

CONCLUDING REMARKS

In this paper we presented FireDeX: an extensible middleware for managing mission-critical IoT data exchange. Our proposed SDNenabled 3-layer approach bridges application-specified information requirements, generic data exchange capabilities, and physical network characteristics. Its algorithms assign priorities to subscriptions and tune their bandwidth allocation (i.e. via packet drop rates) to maximize overall situational awareness. Our experimental results showed that this approach greatly improves the performance in terms of information value captured as well as end-to-end delays.

The cross-layer queueing theoretic model serves as a sound theoretical framework underpinning the FireDeX middleware and enables the analysis used to drive its algorithms. Its modular design supports composition of alternative queueing models. Hence it lays the groundwork for many potential extensions and alterations, some of which we will address in future work. For example, we aim to relax some of the Assumptions in §3: considering multiple switches and physical network routes in managing subscriber data flows; considering non-Poisson arrival and service rates by using e.g. G/G/1 queues; converting larger events into many packets (or many events into one packet) by applying the queueing theoretic concept of batch arrivals [START_REF] Dn Shanbhag | On infinite server queues with batch arrivals[END_REF]; configuring an entire broker network rather than just the BMS's local broker.

To study performance issues arising from a real-world implementation, we are currently developing a Python-based middleware prototype. It incorporates the algorithm implementations with RESTful services for managing an MQTT-SN [START_REF] Ibm | MQTT For Sensor Networks (MQTT-SN)[END_REF] data exchange broker and clients through interactions with an SDN controller. We are also developing a SFF situational awareness dashboard. Upon completion of this prototype, we will deploy it in a smart building on the UCI campus and integrate it with our existing IoT testbed privacypreserving smart building system [START_REF] Benson | SCALE: Safe community awareness and alerting leveraging the internet of things[END_REF][START_REF] Mehrotra | TIPPERS: A privacy cognizant IoT environment[END_REF]. This will enable studies into: how closely our analysis models a real-world system; managing dynamic conditions such as subscriber churn; considering SDN overhead (e.g. flow table space required, delay for configuration changes and statistics collection); conducting IoT-enhanced demonstration drills with fire fighters.

Figure 1 :

 1 Figure 1: The FireDeX cross-layer middleware.

Figure 3 :

 3 Figure 3: FireDeX differentially prioritizes subscriptions at the SDN layer using multiple connections per subscriber.

Figure 4 :

 4 Figure 4: FireDeX queueing network model. classes to drive priority queueing disciplines and calculates the best priority assignments rather than assuming them as a given input.

  the set of subscribers connected with b k as S b k = {s i ∈ S : b k = b s i }, and the set of subscriptions handled by b k as

  f wd b k ,b i to another broker b i ∈ B for eventual consumption by one of the latter's subscribers. As depicted in Fig. 4, we model each broker b k using a single inbound M/M/1 queue Q in b k and multiple outbound M/M/1 queues Q out b k ,s i . By Assumption 1 and the exponentially distributed service rate of Q in b i , ∀b i ∈ B -{b k }, we know that λ f wd b k ,b i is Poisson. Hence, we can define the arrival rate of events at Q in b k

  b k is constant (or averaged) across all topics and independent of current subscriptions. Events not matching subscriptions R b k are dropped with rate λ nosub b k . For each of broker b k 's subscribers s i ∈ S b k , it forwards events matching a subscription r j ∈ R s i to Q out b k ,s i with rate λ thru b k ,s i for transmission to s i . Recall that each broker maintains multiple connections (network flows) with each subscriber. Let µ out b k ,r j be the service rate at Q out b k ,s i

.

  Both queues are of M/M/1 type. For Q in b k , the incoming rate of events is λ in b k and its service rate is µ in b k ; for Q out b k ,s i the incoming rate of events is λ t hr u b k ,s i and the service rate is µ out b k ,r j . Hence, we apply (3) to determine:

) ( 2 )

 2 Split this list into |F s i | sub-lists of approximately equal size (3) Assign Ψ(r j ) = F s i (k) for each r j ∈ sub-list number k (4) Split the list of flows F s i into approximately |Y | sub-lists of approximately equal size (5) Assign Φ(f j ) = y k for each f j ∈ sub-list number k Note that this splitting up of lists handles unequally-sized splits (e.g. |F s i | > |Y |) by preferring higher priorities first.

Figure 5 :

 5 Figure 5: Analytical vs. simulation end-to-end response times for varying traffic loads (ρ Q out x k

7 Figure 6 :

 76 Figure 6: Analytical vs. simulation end-to-end response times for varying numbers of subscribers.Fig. 5a, 13.98 ms in Fig. 5b and 8.24 ms in Fig. 5c. Because the system approaches saturation in Figs.5b and 5c, we deem these results acceptable. In Fig.5c, FireDeX uses our drop policy mechanism to drop packets at the SDN switch and return the system to below saturation (i.e. ρ Q out

  priorities k=2000 packets with priorities and drop policy

Figure 7 :

 7 Figure 7: Comparing success rates for no priorities (i.e. single switch buffer), priorities only, and an added drop policy.

Figure 8 :

 8 Figure 8: Comparing response times for no priorities (i.e. single switch buffer), priorities only, and an added drop policy.

Figure 9 :

 9 Figure 9: Comparing priority-assignment algorithms with other naive approaches.

Figure 10 :

 10 Figure 10: Comparing drop rate policies by varying the utility of one subscription class relative to the other.

Table 1 :

 1 Notations of the parameters in our cross-layer data exchange model

	Application Layer		Data Exchange Layer		Network Layer
	Notation Description	Notation	Description	Notation	Description
	v j ∈ V	event topics	b k ∈ B	brokers	x k ∈ X	SDN switches
	s i ∈ S r j ∈ R	subscribers subscriptions	λ	not if y b k ,r j	rate r j 's notification	h
	p i ∈ P λ pub p i ,v j λ sub r j	publishers publication rate r j 's delivery rate	Ψ : R → F Φ : F → Y	network flow for a subscription priority for a net-work flow
	Ξ r j	r j 's success rate	Ω : F → [0, 1] packet drop rate
	∆ r j	r j 's end-to-end			for a network
		response time			flow

j ∈ H, H = P ∪ S ∪ B network hosts

Table 2 :

 2 Default parameters for our experimental configurations.

	DX params	Telemetry data	#topics (|V|) pub rate (λ 140 Exp( 1 6 ) ∈ [4,7] pub p i ,v j )	event size (G v j ) Exp( 1 110 ) ∈ [90,500]	#subscriptions (|R s i |) utility weight (α r j ) 70 Exp( 1 0.5 ) ∈ [0.01,2]
		Async events	60	Exp( 1 4 ) ∈ [3,5]	Exp( 1 800 ) ∈ [500,1100]	42	Exp(1) ∈ [0.1,4]
	Net	#subscribers (|S |) #publishers (|P |)	#flows (|F s i |)	#priorities (|Y |)	bandwidth (w s i )	ρ tolerance ( ρ )
	params	10	160		9		9	80 Mbps	0.1

ACKNOWLEDGMENTS

This work was supported by: NSF award CNS 1450768, NIST Award # 70NANB17H285, DARPA agreement # FA8750-16-2-0021, the Inria@SiliconValley International Lab, and the research associate team MINES. The authors of this paper also thank the authors of the Res. Roadmap for their valuable contributions to identifying key technological and operational research challenges for SFF.


W L Wei

K Mahdjoubi
email: kouroch.mahdjoubi@univ-rennes1.fr

C Brousseau

O Emile

A Sharaiha

Enhancement of Directivity of an OAM Antenna by Using Fabry-Perot Cavity

Keywords: orbital angular momentum, Fabry-Perot cavity, circular antenna array, patch antenna. I

The circular phased antenna array is a common way to generate waves bearing Orbital Angular Momentum (OAM) in the radio frequency band, but the directivity of this antenna is relatively low. To overcome this drawback, in this paper, we use a Fabry-Perot cavity to enhance the directivity of an OAM antenna based on a circular phased array of patch antennas. The Fabry-Perot cavity consists of a ground plane, an air cavity and a partially reflecting surface (PRS) made of metallic strips. Simulation results show that the OAM antenna achieves a directivity of 16.2 dB with an enhancement of 9.2 dB in E and H planes.

INTRODUCTION

Orbital angular momentum (OAM) has been proposed to improve spectral efficiency [START_REF] Mohammadi | Orbital angular momentum in radio -a system study[END_REF][START_REF] Tamburini | Encoding many channels on the same frequency through radio vorticity: first experimental test[END_REF][START_REF] Wang | Terabit free-space data transmission employing orbital angular momentum multiplexing[END_REF][START_REF] Yan | High-capacity millimetre-wave communications with orbital angular momentum multiplexing[END_REF] in radio communications, by creating multiple sub-channels of propagation corresponding to the twisting degree of the electromagnetic wave.

Whereas the phase of a usual plane wave is constant on the wave front, the phase α of OAM waves undergoes a linear variation along the angular coordinate ϕ (roll angle): α = lϕ, where l is an integer called the "topological charge" or the order of the OAM mode.

In the radio frequency band, a circular phased array is a common technique for generating OAM waves [START_REF] Mohammadi | Orbital angular momentum in radio -a system study[END_REF][START_REF] Thidé | Utilization of photon orbital angular momentum in the low-frequency radio domain[END_REF]. It is generally composed of N antennas, where each one is fed by the same signal with a ±2πl/N phase shift compared to its neighbor. Some practical constructions are proposed in [START_REF] Bai | Experimental circular phased array for generating OAM radio beams[END_REF][START_REF] Wei | Generation of OAM waves with circular phase shifter and array of patch antennas[END_REF][START_REF] Tennant | Generation of OAM radio waves using circular time-switched array antenna[END_REF].

In this paper, we present a method to enhance the directivity of an OAM antenna by using the Fabry-Perot (FP) cavity. A circular phased array of four patch antennas is used to generate waves bearing an OAM mode l = 1. This OAMwave generator is embedded inside the FP cavity and works at a frequency of 2.5 GHz.

II. MODEL OF FABRY-PEROT CAVITY

The model of the FP cavity is shown in Fig. 1. It is composed of a ground plane which eliminates the back radiation, a primary source (patch antenna) and a partially reflecting surface (PRS). When the internal wave rays emitted by the primary source arrive at the upper PRS, they are partially reflected back to the cavity and partially transmitted out. Then, when the reflected rays arrive at the bottom ground plane, they are reflected again towards the cavity. Here we use a PEC ground plane and suppose that the rays are totally reflected at this surface.

To obtain a maximal directivity, the transmitted rays should all be in phase so that they can make a constructive interference. According to [START_REF] Mahdjoubi | An overview on the design and properties of EBG antennas[END_REF], the thickness of the FP cavity should meet the following requirement:

( ) ( ) 0 2 1 4 cos c D n f β π π θ = + +     ( 1
)
where c is the speed of the light in free space, f 0 is the working frequency, β is the phase of the reflection coefficient of the PRS, n is an integer corresponding to the cavity mode number, θ is the incidence angle of the rays (see Fig. 1).

A. Phased Patch Array

Here we intend to use a circular phased array of patch antennas to generate the OAM wave [START_REF] Wei | Generation of OAM waves with circular phase shifter and array of patch antennas[END_REF]. For creating an OAM mode l = 1 with N = 4 antennas, the phase step between each element should be 2πl/N = π/2 radians = 90°. The configuration of the OAM antenna is shown in Fig. 2. The length and width of single patch antenna are 36.5 and 27.4 mm, respectively. The patch array is manufactured on a FR4 substrate with a thickness of 1.6 mm and a relative permittivity of 4.4. All the patch antennas are probe fed using the same signal but with an incremental phase shift between each patch. Fig. 3 presents the reflection coefficient of a single patch antenna, we can see that it is well matched around 2.5 GHz. When the radius of the patch array is 50 mm, the magnitude and phase patterns of the generated wave, observed on a circular area with a radius of 150 mm lying 50 mm above the patch array, are presented in Fig. 4 for the main polarization E x (see Fig. 2). We can observe that the magnitude at the centre is much smaller than the surroundings and the phase rotates around the centre with a 2π phase shift in one turn. This shows indeed that both the amplitude and the phase of the generated wave correspond to a wave bearing an OAM mode l = 1. To show the influences of the array radius on the antenna directivity, Fig. 4 presents the E-plane radiation patterns with different array radiuses of 50, 80 and 110 mm. It can be observed that the OAM waves become more directive as the array radius increases, but naturally some side lobes appear. When the array radius keeps increasing, the side lobe becomes even comparable with the main lobe, which means a strong loss of energy.

B. Phased Patch Array in Fabry-Perot Cavity

It has been demonstrated that the FP cavity is able to enhance the directivity of an antenna [START_REF] Akalin | A highly directive dipole antenna embedded in a Fabry-Perot type cavity[END_REF][START_REF] Boutayeb | Directivity of an antenna embedded inside a Fabry-Perot cavity: Analysis and Design[END_REF]. Along this way, we would like to embed the OAM antenna inside the FP cavity to improve its directivity of the main lobe, as shown in Fig. 6. Because the OAM waves are more directive with a bigger array radius, here we choose an array radius of 110 mm.

To realize a good directivity, the wave rays need to be reflected enough times inside the FP cavity, therefore the dimension of the ground plane and the PRS should be large enough. In our design, the ground plane and the PRS both have a dimension of 600 mm × 600 mm. The PRS is made of a set of periodic metallic strips which are manufactured on a FR4 substrate with a thickness of 1.6 mm and a relative permittivity of 4.4. The period and width of the strips are 20 and 4 mm, respectively. According to (1), the cavity thickness depends on the working frequency, the phase of the reflection coefficient of the PRS and the incidence angle of the wave rays. From Fig. 5 we can see that when the array radius is 110 mm, the angle value corresponds to the maximum directivity is at ±15° for the main lobe, so the value of the incidence angle here is 15°. We simulated the PRS alone and found that the magnitude and phase of its reflection coefficient were respectively 0.944 and 0.9π. By substituting these values into (1), we can calculate that the thickness of the FP cavity for the cavity mode n = 0 is equal to 59 mm at a working frequency of 2.5 GHz.

We have varied the cavity thickness to optimize the antenna directivity, the results are shown in Table I. We can observe that the maximum directivity of the OAM antenna changes slightly with the cavity thickness, while the angle value corresponding to the maximum directivity maintains at 11°; the OAM antenna achieves a best directivity of 16.2 dB with a cavity thickness of 58 mm, which is the final value we have used. 15. 5 11 Fig. 7 presents the 3D radiation patterns of the patch antenna array (array radius equals to 110mm) with and without FP cavity. We can observe a null in the center which is one of the characteristics of the OAM waves. In addition, with the use of the FP cavity, the antenna directivity is enhanced and the side lobes are significantly suppressed at the same time.

To give a better view of the influence of the FP cavity on the OAM antenna directivity, we make a comparison of the Eplane radiation patterns in Fig. 8. It can be seen that with the use of the FP cavity, the antenna directivity increases in Eplane, from 7 to 16.2 dB. The maximum directivity is obtained for angle of 11°.

IV. CONCLUSIONS

In this paper, we have presented a method to enhance the directivity of an OAM antenna by embedding it inside a FP cavity. This OAM antenna is based on a 4-element circular phased patch array with an array radius of 110 mm and works at 2.5 GHz. Influences of the FP cavity thickness on the antenna directivity are studied. The OAM antenna finally achieves a directivity of 16.2 dB with an optimized cavity thickness of 58 mm.

Fig. 1 .

 1 Fig. 1. Model of the FP cavity with PRS

Fig. 2 .

 2 Fig. 2. Configuration of the OAM antenna

Fig. 3 .Fig. 4 .

 34 Fig. 3. Reflection coefficient of single patch antenna

Fig. 5 .

 5 Fig. 5. E-plane radiation patterns with different array radiuses

Fig. 6 .

 6 Fig. 6. Configuration of the OAM antenna & FP cavity

Fig. 7 .Fig. 8 .

 78 Fig. 7. 3D radiation patterns of the OAM antenna (array radius equals to 110mm): (a) without FP cavity; (b) with FP cacity

TABLE I

 I

	.	MAXIMUM DIRECTIVITY VALUE AND POSITION OF OAM
	ANTENNA WITH DIFFERENT CAVITY THICKNESSES
	Cavity Thickness (mm)	Max Directivity (dB)	Position (°)
	59		14.6	11
	58.5	15.7	11
	58		16.2	11
	57.5

ACKNOWLEDGMENT

The authors would like to thank China Scholarship Council (CSC) (No. 201306090101) for scholarship support.


W L Wei

K Mahdjoubi
email: kouroch.mahdjoubi@univ-rennes1.fr

C Brousseau

O Emile

A Sharaiha

Two Monopole Antennas for Generating Radio OAM Waves in Circular Waveguide

Keywords: orbital angular momentum, circular waveguide, monopole antenna. I

We present a novel way to generate waves bearing Orbital Angular Momentum (OAM) in a circular waveguide by using two monopole antennas. The OAM mode l = 1 is generated by a combination of the classical TM01 and TE21 modes of the circular waveguide. Two printed monopole antennas are used to create these two modes. The design procedure of this novel "OAM antenna" is presented. The resulting electrical field distribution and the radiation and phase patterns evidence the properties of waves bearing OAM.

INTRODUCTION

Orbital angular momentum (OAM) has been proposed to improve spectral efficiency [START_REF] Mohammadi | Orbital angular momentum in radio -a system study[END_REF][START_REF] Tamburini | Encoding many channels on the same frequency through radio vorticity: first experimental test[END_REF][START_REF] Wang | Terabit free-space data transmission employing orbital angular momentum multiplexing[END_REF][START_REF] Yan | High-capacity millimetre-wave communications with orbital angular momentum multiplexing[END_REF] in radio communications, by creating multiple sub-channels of propagation corresponding to the twisting degree of the electromagnetic wave.

Whereas the phase of a usual plane wave is constant on the wave front, the phase α of OAM waves undergoes a linear variation along the angular coordinate  (roll angle): α = l, where l is an integer called the "topological charge" or the order of the OAM mode.

Up to now, in radio frequency bands, two main families of antennas have been proposed to generate OAM waves: circular phased arrays [START_REF] Mohammadi | Orbital angular momentum in radio -a system study[END_REF][START_REF] Thidé | Utilization of photon orbital angular momentum in the low-frequency radio domain[END_REF][START_REF] Bai | Experimental circular phased array for generating OAM radio beams[END_REF][START_REF] Wei | Generation of OAM waves with circular phase shifter and array of patch antennas[END_REF] and plane wave transformers (spiral reflector, spiral phase plate and flat phase plate) [START_REF] Tamburini | Encoding many channels on the same frequency through radio vorticity: first experimental test[END_REF][START_REF] Turnbull | The generation of free-space Laguerre-Gaussian modes at millimeterwave frequencies by use of a spiral phaseplate[END_REF][START_REF] Niemiec | Characterization of an OAM flat plate antenna in the millimeter frequency band[END_REF].

In contrast, at optical frequencies different techniques are used to generate OAM beams [START_REF] Padgett | Light with a twist in its tail[END_REF]. As an example, a helical phased Laguerre-Gaussian mode LG01 (l = 1 or -1) is obtained by combining two high-order Hermite-Gaussian modes of HG01 and HG10 [START_REF] Allen | Orbital angular momentum of light and the transformation of Laguerre-Gaussian laser modes[END_REF]. Along this way, a rectangular silicon waveguide is already used to generate optical OAM beams by combining the E x 21 and E x 12 modes [START_REF] Zhang | Generating in-plane optical orbital angular momentum beams with silicon waveguides[END_REF]. In the same manner, by combining some proper modes of a metallic waveguide we can create OAM waves in radio frequency bands.

In this paper, we combine the classical TM01 and TE21 modes of a circular metallic waveguide to generate radio OAM waves bearing a mode l = 1. Two printed monopole antennas are introduced inside the circular waveguide to create the desired modes of TE21 and TM01.

II. MODAL ANALYSIS

The electrical field distributions of the TM01 and TE21 modes are reminded in Fig. 1.

A. TM01 Mode

The magnitude and phase patterns of Ex and Ey components for the TM01 mode are shown in Fig. 2. One can see that the magnitude of the Ex component is minimal at the centre and in this respect; it is similar to an OAM wave. In fact, the beam of an OAM wave has a vortex with a minimum value of the field intensity in the centre and a linear phase rotation against the roll angle. For the TM01 mode, the phase of the Ex component can be divided into two parts. For each part, the phase is constant on the wave front, and the phase difference between the two parts equals π. Due to the symmetrical distribution of the electrical field, the Ey component has an identical distribution compared to the Ex component, the only difference is that both the magnitude and phase patterns rotate π/2.

B. TE21 Mode

The magnitude and phase patterns of Ex and Ey components for the TE21 mode are shown in Fig. 3. We can observe that there is quite a similar distribution compared to the TM01 mode. The main difference is that for each component, there is a π/2 rotation of both magnitude and phase patterns.

C. Combination of TM01 and TE21 Modes

To create the OAM guided wave, we simultaneously excite the TM01 and TE21 modes with a π/2 phase difference. The resulting magnitude and phase patterns of Ex and Ey components are shown in Fig. 4. We can observe that the magnitude patterns have a null at the center and the phases have a linear variation along the roll angle  with a 2π phase shift in one turn. This shows indeed that for each component, both the amplitude and the phase correspond to a wave bearing an OAM mode l equal to 1.

A. Design Procedure

We introduce two printed monopole antennas inside a circular metallic waveguide to generate the OAM waves. The configuration of the proposed "OAM antenna" is shown in Fig. 5. The empty waveguide has a diameter of 4 cm and a height of 5 cm, the corresponding cut-off frequencies of the TM01 and TE21 modes are respectively 5.7 and 7.3 GHz. We choose a working frequency of 8.3 GHz to allow the propagation of the TM01 and TE21 modes and to prevent other high-order modes existing. From the electrical field distributions of the TM01 and TE21 modes (see Fig. 1); we can find that to create these two modes, the two monopole antennas should be placed on the same line and be out of phase. To this purpose, the two monopole antennas are connected with a single transmission line which is back-fed at the centre point with a 50 Ω coaxial cable. In addition, since the field intensity of the TE21 mode is maximal at  = ±45° and ±135° (see Fig. 1b), the monopole antennas should also be placed at the corresponding positions. In our design, we place the monopole antennas at  = 45° and -135°.

The monopole antennas and the transmission line are both manufactured on FR4 substrates with a thickness of 1.6 mm and a relative permittivity of 4.4. The substrate totally has 4 parts. The 1 st substrate is placed at the bottom of the waveguide with the same diameter and the 2 nd one, in the middle of the waveguide. The 3 rd and 4 th substrates are placed along the side wall of the waveguide and are used to connect the 1 st and 2 nd substrates. The transmission line has a width of 0.7 mm and an impedance of 100 Ω. To satisfy the working frequency and the impedance matching, the length and width of each monopole antenna are optimized at 12 and 4.5 mm, respectively.

B. Simulation Results

As depicted in Fig. 6, the antenna is well matched around 8.3 GHz.

The magnitude and phase patterns of the generated wave, observed on a plane perpendicular to the direction of propagation, are shown in Fig. 7. The observation window is a circular area with a radius of 3 cm, lying 1 cm above the waveguide aperture. It can be seen that for both Ex and Ey components, the magnitude at the centre is much smaller than the surroundings and the phase rotates around the centre with a 2π phase shift in one turn. This shows indeed that for each component, both the amplitude and the phase of the generated wave correspond to an OAM bearing wave with l = 1.

At a working frequency of 8.3 GHz, the TE11, TM01 and TE21 modes are able to propagate in the waveguide. However, the monopole antennas are out of phase and due to this fact, the TE11 mode is eliminated. Thus, we can conclude that the OAM wave is generated by a combination of the TM01 and TE21 modes.

IV. CONCLUSIONS

In this paper, we have presented a method to generate radio OAM waves in a circular metallic waveguide by a combination of TM01 and TE21 modes. An antenna using two printed monopoles and a single transmission line is designed to create these two modes and hence, to generate an OAM wave with a topological charge l = 1. Both the 2D magnitude & phase patterns of the electrical field and the 3D radiation & phase patterns confirm the generation of an OAM bearing wave.

Fig. 1 .

 1 Fig. 1. Electrical field distributions of the classical modes in a circular waveguide: (a) TM01 mode; (b) TE21 mode

Fig. 2 .

 2 Fig. 2. Magnitude (left) and phase (right) patterns of the TM01 mode: (a) Ex component; (b) Ey component

Fig. 3 .

 3 Fig. 3. Magnitude (left) and phase (right) patterns of the TE21 mode: (a) Ex component; (b) Ey component

Fig. 4 .

 4 Fig. 4. Magnitude (left) and phase (right) patterns of the combined TM01 and TE21 modes: (a) Ex component; (b) Ey component

Fig. 5 .

 5 Fig. 5. Configuration of the proposed OAM antenna

Fig. 6 .

 6 Fig. 6. Reflection coefficient of the OAM antenna

Fig. 8 .

 8 Fig. 8. 3D radiation and phase patterns of the OAM antenna: (a) magnitude; (b) phase

ACKNOWLEDGMENT

The authors would like to thank China Scholarship Council (CSC) (No. 201306090101) for scholarship support.