Georgios Bouloukakis

Ajay Kattepur
email: ajay.kattepur@tcs.com

Nikolaos Georgantas
email: nikolaos.georgantas@inria.fr

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

Queueing Network Modeling Patterns for Reliable and Unreliable Publish/Subscribe Protocols

Keywords: Subscribe Middleware, Mobile Connectivity, Queueing Networks, Quality of Service

Mobile Internet of Things (IoT) applications are typically deployed on resource-constrained devices with intermittent network connectivity. To support the deployment of such applications, the Publish/Subscribe (pub/sub) interaction paradigm is often employed, as it decouples mobile peers in time and space. Furthermore, pub/sub middleware protocols and APIs consider the Things' hardware limitations and support the development of effective applications by providing Quality of Service (QoS) features. These features aim to enable developers to tune an application by switching different levels of response times and delivery success rates. However, the profusion of pub/sub middleware protocols coupled with intermittent network connectivity result in non-trivial application tuning. In this paper, we model the performance of middleware protocols found in IoT, which are classified within the pub/sub interaction paradigm -both reliable and unreliable underlying network layers are considered. We model reliable and unreliable protocols, by considering QoS semantics for data validity, buffer capacities as well as the intermittent availability of peers. Finally, we perform statistical analysis by varying these QoS semantics, demonstrating their significant effect on the rate of successful interactions. We showcase the application of our analysis in concrete scenarios relating to Traffic Information Management systems, that integrate both reliable and unreliable participants. The consequent PerfMP performance modeling pattern may be tailored for a variety of deployments, in order to control fine-grained QoS policies.

INTRODUCTION

Internet of Things (IoT) applications have proliferated multiple sectors including the Industrial Internet, Smart Cities and Mobile Communication Systems [START_REF] Atzori | The Internet of Things: A survey[END_REF]. While the sensecompute-actuate control flow functionality has received considerable attention [START_REF] Karagiannis | A survey on application layer protocols for the internet of things[END_REF], aspects such as resource limitations, intermittent network connectivity and suitable middleware paradigms for Quality of Service (QoS) dependent tasks are still under active study.

The underlying middleware of IoT applications tends to follow the Publish/Subscribe (pub/sub) interaction paradigm, that provides the advantages of space and time decoupling between peers [START_REF] Eugster | The many faces of publish/subscribe[END_REF]. Space decoupling implies that the peers are agnostic to each others addresses; time decoupling allows peers to be connected intermittently while still successfully receiving messages. This is particularly needed in the case of mobile IoT systems, where-in unreliability in the underlying network connectivity may be mitigated by message storage/retrieval from an intermediary broker. Multiple standards and toolkits based on the pub/sub paradigm have been proposed including MQTT [START_REF] Banks | MQTT Version 3.1. 1[END_REF], RabbitMQ [START_REF] Pivotal | RabbitMQ[END_REF] and Kafka [1].

As an illustration, consider popular traffic management systems [START_REF] Mohan | Nericell: rich monitoring of road and traffic conditions using mobile smartphones[END_REF][START_REF] Waze | [END_REF][START_REF] Xd | Traffic[END_REF][START_REF] Yoon | Surface street traffic estimation[END_REF] that consists of: 1) fixed-sensors (vehicle detectors, traffic cameras, Doppler radars) that have been installed on existing infrastructure -they ensure the fastest but not reliable message delivery [START_REF] Karagiannis | A survey on application layer protocols for the internet of things[END_REF][START_REF] Lee | Correlation analysis of MQTT loss and delay according to QoS level[END_REF] through the CoAP [START_REF] Shelby | The constrained application protocol[END_REF] "non-confirmable" delivery feature; 2) vehicledevices (on-board) with GPS-based systems -they produce notifications via the MQTT [START_REF] Banks | MQTT Version 3.1. 1[END_REF] protocol using the "fire-andforget" delivery feature; and, 3) smartphones with embedded sensors (accelerometer, gyroscope) that push/receive data via the reliable (built atop TCP) ZeroMQ [START_REF] Hintjens | ZeroMQ: messaging for many applications[END_REF] and AMQP [START_REF]Oasis advanced message queuing protocol (amqp) version 1.0[END_REF] middleware protocols. The combination of such intelligent systems can provide us an overall Traffic Information Management (TIM) system in order to accurately estimate traffic conditions. For a TIM system to be used reliably by mobile applications, the freshness of procured data must be ensured. The TIM system guarantees the freshness of provided information by applying a lifetime period to each message. However, messages may be delivered with delay because of disconnections. A unified framework is needed to analyze delivery message success rates as well as end-to-end response time for message reception.

The focus of this paper is to analyze IoT applications' QoS using the pub/sub abstraction layer. As the pub/sub paradigm allows control of publisher/subscriber timeout periods and message lifetimes at the broker, an intricate model that captures such properties would result in improved reliability, availability and performance of IoT applications. We model message passing and buffering at the application/middleware layers to analyze QoS constraints on message lifetimes as well as intermittent "ON-OFF" periods. We consider two varieties of applications -those that rely on reliable networking protocols (such as TCP) and those that rely on unreliable networking protocols (such as UDP). The nuances of sending messages over reliable/unreliable protocols are analyzed using Queuing Network Models [START_REF] Lazowska | Quantitative system performance: computer system analysis using queueing network models[END_REF]. We model the interactions in pub/sub protocols using continuous, ON-OFF, finite capacity and message expiration queueing centers. The detailed modeling provides a grounded foundation for QoS analysis of pub/sub interactions in the form of Performance Modeling Patterns (PerfMP), that may be composed with both reliable and unreliable messaging instances.

Experiments are conducted using the simulator we developed to study end-to-end response times and delivery success rates with reliable and unreliable communication patterns. We observe that even though there is a significant improvement in response time using the unreliable pattern, the delivery success rates cap at 64% despite increasing messaging lifetimes. This, however, is not in the case of reliable patterns, with increasing lifetimes resulting in guaranteed message reception with increased response times as the tradeoff. Such analyses are crucial for application developers of complex systems such as TIM to accurately set interacting middleware parameters.

The core contributions of this paper are:

(1) A joint analysis of pub/sub protocols with QoS modeling to ensure timely end-to-end message delivery. ( §2) (2) Queuing Network Modeling of publishers, subscribers and brokers using M/M/1, ON-OFF (with intermittent available servers), Finite Buffer and Limited Lifetime Queueing Centers. ( §3, §4) (3) Analysis of reliable and unreliable middleware protocols in conjunction with the underlying networking stack to provide a unified framework for pub/sub modeling. This generates a set of performance modeling patterns (PerfMP) that may be reused across applications. ( §5) (4) End-to-end analysis through simulation based experiments for studying end-to-end response times and delivery success rates for both reliable and unreliable messaging patterns. ( §6)

SYSTEM MODEL

The Publish-Subscribe interaction paradigm, is commonly used for content broadcasting/feeds. IoT middleware protocols such as MQTT [START_REF] Banks | MQTT Version 3.1. 1[END_REF] and AMQP [START_REF]Oasis advanced message queuing protocol (amqp) version 1.0[END_REF], as well as tools and technologies such as RabbitMQ [START_REF] Pivotal | RabbitMQ[END_REF], Kafka [1] and JMS [START_REF]JMS Specifications[END_REF] follow the pub/sub paradigm. In pub/sub, multiple peers interact via an intermediate broker. Publishers produce events (or messages) characterized by a specific filter to the broker. Subscribers subscribe their interest for specific filters to the broker, who maintains an up-to-date list of subscriptions.

The broker matches received events with subscriptions and delivers a copy of each event to each interested subscriber.

There are different types of subscription schemes: topic-based, content-based and type-based [START_REF] Eugster | The many faces of publish/subscribe[END_REF]. For instance, in a topicbased pub/sub, events are characterized with a topic and subscribers subscribe to specific topics for receiving events.

Pub/Sub QoS Features

A Quality of Service (QoS) feature is an agreement between a sender and a receiver defining the way that an event delivery is treated by the underlying communication infrastructure. We define the following QoS features that may be enabled in pub/sub messaging: -𝑄𝑜𝑆u: is the feature for enabling unreliable interactions. For such interactions, a sent event may or may not be received by the receiver.

-𝑄𝑜𝑆r: is the feature for enabling reliable interactions. For such interactions, this feature guarantees that the delivery of an event is verified using ACKs, and retransmissions.

Depending on the requirements of an IoT application, a system designer is able to select between the above QoS features, which are provided by middleware pub/sub protocols (MQTT, AMQP, etc) for guaranteeing the corresponding response times or delivery success rates. We define the above QoS features in pub/sub systems for two different interactions: i) the publisher -broker interaction; and ii) the broker -subscriber interaction. As depicted in Fig. 1, a publisher is able to set a QoS feature (𝑄𝑜𝑆u or 𝑄𝑜𝑆r) for publishing a particular event to the broker. Additionally, a subscriber subscribes using a specific QoS feature for receiving events by the broker. Accordingly, the QoS of an end-to-end interaction (from publisher to subscriber) can be downgraded if at least one of the two peers sets the lower QoS feature (e.g., the publisher publishes events with 𝑄𝑜𝑆r and the subscriber subscribes to receive events with 𝑄𝑜𝑆u). Additionally, for each event published the publisher may set lifetime period that represents the event's validity/availability in the pub/sub system (i.e., the broker or an application is responsible to delete an event when expires).

In what follows, we describe formally the proposed pub/sub system with QoS features and performance metrics.

Pub/Sub Formal Modeling

To mathematically represent the arrival rates of events, we use a topic-based subscription model, since it is efficient and simple in terms of event classification. Nevertheless, our approach can be used for any model where other classification techniques are applied. In content-based pub/sub systems, events are distinguished by the properties of the events instead of predefined criterion (i.e., topic name). Hence, our method must be modified based on the resulting probability distributions of the arrival rates after the filtering process in the broker node (possible via simulation based models).

Let 𝑉 be the set of all topics in the system. We model the connectivity of pub/sub peers as follows: let ON and OFF be the states where the peer is connected and disconnected, correspondingly. A given peer, is connected (ON state) for an exponentially distributed time period with parameter 𝜃 ON (𝜃 ON = 1/𝑇 ON ). Upon the expiration of this time, the peer disconnects (OFF state) and stops the transmission or reception of relevant events for an exponentially distributed time period with parameter 𝜃 OFF (𝜃 OFF = 1/𝑇 OFF ). Below we provide models representing our pub/sub system. Publisher Model. Let 𝑃 be the set of all publishers in the system. Each publisher (𝑝 ∈ 𝑃 ) forwards the published events to the broker when connected. 𝑝 is defined by the tuple:

𝑝 = ( 𝑖𝑑p, 𝑉p, 𝜆p, lifetime, 𝑞𝑜𝑠p, 𝑇 p ON , 𝑇 p OFF , 𝐾p
)

where 𝑖𝑑p is the publisher's identifier, 𝑉p ⊆ 𝑉 is the set of the topics on which 𝑝 publishes events according to a Poisson process for each topic, 𝜆p is the input rate of the published events which is also Poisson (sum of Poisson processes for the set of topics 𝑉p), lifetime is validity/availability time period of an event and is set upon its production, 𝑞𝑜𝑠p is the delivery method used by 𝑝 for sending a particular event to the broker (i.e., 𝑄𝑜𝑆u or 𝑄𝑜𝑆r), 𝑇 p ON and 𝑇 p OFF are the average periods where 𝑝 connects and disconnects, and 𝐾p is the maximum capacity for storing published events especially during the 𝑝's disconnection period (𝑇 𝑝 OFF ). Subscriber Model. Let 𝑆 be the set of all subscribers in the system. Each subscriber (𝑠 ∈ 𝑆) receives relevant events from the broker when connected. 𝑠 is defined by the tuple:

𝑠 = ( 𝑖𝑑s, 𝑉s, 𝜆s, 𝑞𝑜𝑠s, 𝑇 s ON , 𝑇 s OFF , 𝐾s
)

where 𝑖𝑑s is the subscriber's identifier, 𝑉s ⊆ 𝑉 is the set of the topics that 𝑠 has subscribed, 𝜆s is the input rate which is intermittent Poisson since 𝑠 receive events when connected (events match 𝑠's topics 𝑉s), 𝑞𝑜𝑠s is the delivery method used by 𝑠 for receiving events by the broker (i.e., 𝑄𝑜𝑆u or 𝑄𝑜𝑆r), 𝑇 s ON and 𝑇 s OFF are 𝑠's connection/disconnection periods, and 𝐾s is the maximum capacity for storing incoming events. Broker Model. The broker 𝑏 receives the published events to several topics from publishers and forwards them to the corresponding subscribers according to their connectivity status and QoS feature. 𝑏 is defined by the tuple:

𝑏 = ( 𝜆 b , 𝑁s, 𝐾 b , 𝑇 b ON , 𝑇 b OFF )
where 𝜆 b is the broker's input rate according to a Poisson process (dependent on the outputs of connected publishers), 𝑁s ⊆ 𝑆 is the set of subscribers subscribed to the broker 𝑏 and 𝐾 b is the maximum capacity for storing the published events to be delivered to the set of the subscribers subscribed (𝑁s). IoT middleware protocols are often lightweight, enabling the possibility of deploying software components on resource-constrained and mobile devices. Hence, broker components can be also deployed on such devices and thus, it is essential to consider their intermittent connectivity. 𝑇 b ON and 𝑇 b OFF are the average periods where 𝑏 connects and disconnects for receiving published events and forwarding events to subscribers.

In this paper, we analyze two specific QoS metrics -Response Time and Delivery Success Rate.

Pub/Sub QoS Analysis

End-to-end Response Time. To evaluate the end-to-end response time from 𝑝 to 𝑠, denoted by ∆ p s , it is essential to calculate the delay of the published events at every peer and the broker they pass through. Such delays can be calculated by taking into account: i) the applied QoS features to the As depicted in Fig. 2, a publisher 𝑝 publishes an event at 𝑡 publish timestamp. Independently of the publisher's connections/disconnections (𝑇 p ON /𝑇 p OFF ), events may occur at any timestamp. Upon the occurrence of an event, in case the publisher is disconnected (𝑇 p OFF ), events will be buffered for a maximum lifetime period until the publisher's next connection (𝑇 p ON ) that will be sent to the broker (see Fig. 2). On the other hand, a subscriber 𝑠 subscribes using a specific QoS feature (i.e., 𝑄𝑜𝑆𝑢 or 𝑄𝑜𝑆𝑟) for receiving events at 𝑡 subsribe timestamp. In case the selected feature is 𝑄𝑜𝑆𝑟, during the subscriber's disconnections (𝑇 s OFF ), events will be buffered at the broker for a maximum lifetime period -to be sent to the subscriber upon its next connection (𝑇 s ON ). From 𝑝 to 𝑠, delays occur due to event buffering in the following cases: 1. At the publisher's side, when events are produced at high rates (𝜆p) and disconnections occur (𝑇 p OFF ) at the same time. 2. At the publisher's side, when the 𝑄𝑜𝑆r feature is selected for publishing events and 𝑏 is disconnected (𝑇 b OFF ). 3. At the broker's side, when the 𝑄𝑜𝑆r feature is selected by 𝑠 for receiving events and 𝑠 is disconnected (𝑇 s OFF ). 4. At the subscriber's (𝑠) side, when receiving the incoming events in high rates (𝜆s).

In addition to the above cases, to calculate the end-to-end response time (∆ p s ), it is essential to consider the expiration of events due to the applied lifetime period at each event. Delivery Success Rate. The delivery success rate from 𝑝 to 𝑠 is denoted by Ξ p s . To identify successful or failed end-to-end interactions (from 𝑝 to 𝑠), it is essential to analyze every possible combination of connections/disconnections, selected QoS features and lifetime periods, which are involved in such interactions. As depicted in Fig. 2, we distinguish 4 traces, which are analyzed in the following: -trace 1 : the event is published using the 𝑄𝑜𝑆𝑢 feature; at the other side 𝑠 is subscribed to receive events using the 𝑄𝑜𝑆𝑟 feature. Upon the event's publication, 𝑝 and 𝑏 are at the ON state (𝑇 p ON and 𝑇 b ON ) and thus, the 𝑝-𝑏 interaction is successful. Then, the event is kept at 𝑏 for a maximum lifetime period and upon 𝑠's next connection (𝑇 s ON and 𝑠 employs 𝑄𝑜𝑆𝑟) the 𝑝-𝑠 interaction is successful.

-trace 2 : the event is published using 𝑄𝑜𝑆𝑢; at the other side 𝑠 is subscribed to receive events using 𝑄𝑜𝑆𝑟. Upon the event's publication, 𝑝 is OFF and thus the event is buffered for a maximum lifetime period. Upon 𝑝's next connection the event is transmitted independently of 𝑏's ON/OFF state (due to the employment of 𝑄𝑜𝑆𝑢 by 𝑝). 𝑏 is OFF and thus the 𝑝-𝑠 interaction is classified failed.

-trace 3 : the event is published using 𝑄𝑜𝑆𝑟; at the other side 𝑠 is subscribed to receive events using 𝑄𝑜𝑆𝑢. Upon the event's publication, 𝑝 is 𝑂𝑁 but 𝑏 is OFF and since the 𝑄𝑜𝑆𝑟 feature is employed for publishing, the event is buffered for a maximum lifetime period. Upon 𝑏's next connection the event is transmitted to the broker and the 𝑝-𝑏 is successful. Afterwards, the event must be transmitted immediately to 𝑠 (due to its 𝑄𝑜𝑆𝑢) and because of 𝑠's ON state, the 𝑝-𝑠 interaction is successful.

-trace 4 : the event is published using 𝑄𝑜𝑆𝑟; at the other side 𝑠 is subscribed to receive events using 𝑄𝑜𝑆𝑢. Similarly to trace 2, the event is buffered for a maximum lifetime period. Upon 𝑝's next connection (and if 𝑏 is ON) the event is transmitted to 𝑏 and the 𝑝-𝑏 interaction is successful. However, the event must be transmitted immediately to 𝑠 (due to 𝑠's 𝑄𝑜𝑆𝑢) and because of 𝑠's OFF state, the 𝑝-𝑠 interaction fails.

In addition to the above traces, we must consider failed interactions due to lifetime periods. For instance, in trace 1, if the events are kept to the broker for a period higher to its lifetime and 𝑠 is in the OFF state, then the 𝑏-𝑠 interaction will fail. Analyzing such traces in a formal way is not a trivial task. Additionally, we must take into account queueing delays for transmitting events through the underlying network infrastructure, as well as delays due to the high rate of event arrivals. Finally, we must distinguish between peers' disconnections occurred due to wireless network disconnections, or voluntary ones for energy saving purposes.

Pub/sub middleware protocols have been designed by taking into account the above limitations in order to facilitate developers building IoT applications. In this work, we particularly deal with the effect of mobility and network disconnections and the consequent effects on QoS. Our outputs are tuned taking into account lifetime and ON/OFF states. Note that aspects such as event duplication, ordered delivery or timely delivery [START_REF] Corsaro | Quality of service in publish/subscribe middleware[END_REF] are not dealt with explicitly in this work. Likewise, end-to-end performance using routing or flows [START_REF] Behnel | On quality-of-service and publish-subscribe[END_REF] [24] are also not evaluated. Further analysis of reliable/unreliable protocols is enunciated in the following.

RELIABILITY OF COMMUNICATION INFRASTRUCTURE

Middleware IoT protocols and APIs -such as MQTT [START_REF] Banks | MQTT Version 3.1. 1[END_REF], AMQP [START_REF]Oasis advanced message queuing protocol (amqp) version 1.0[END_REF], Kafka [1] and JMS [START_REF]JMS Specifications[END_REF], follow the pub/sub paradigm and they mainly support asynchronous interactions. For instance, let us consider the interaction of two mobile peers; we demonstrate in the following the effect of disconnections on QoS. In this interaction, a mobile publisher produces events through multiple applications (apps). Each app disconnects from the network from time to time (e.g., for energy saving purposes), and the produced events are buffered until the next connection, upon which they are forwarded to the middleware (mdw) layer. On the other side, a mobile subscriber is able to receive events from multiple publishers; the events are distributed to multiple apps, whenever each app's connectivity (app-layer connection) allows it. The mdw layer is responsible for handling and transmitting incoming events via the underlying network. Inside the network, additional disconnections may occur (defined as mdw disconnections) due to several reasons: i) broken session of the underlying protocol; ii) router crash/reboot; iii) wireless devices moving out of range; etc. Accordingly, event transmission may fail at the app/mdw layer. To enhance reliability, middleware protocols either rely on underlying protocol mechanisms, or they introduce additional ones, or in the case of pub/sub they incorporate broker nodes to decouple mobile peers. Thus, existing protocols can be categorized into: Unreliable middleware protocols: where guarantees for the delivery of events are missing. They typically build on top of the UDP unreliable transport protocol (e.g., CoAP nonconfirmable). In UDP, two middleware nodes do not set up an end-to-end connection (publisher → broker, or broker → subscriber), as it is the case in TCP. Additionally, there is no confirmation for event delivery, and hence no event re-transmission in case of unsuccessful delivery. Thus, a sent event may not be received. Reliable middleware protocols: where the delivery of each event is verified. They usually build atop the TCP reliable transport protocol [START_REF] Wright | TcP/IP Illustrated[END_REF]. Over TCP, two middleware nodes set-up or shut-down a reliable end-to-end connection (publisher → broker, or broker → subscriber) via 3-way or 4-way handshake, respectively. Based on TCP's mechanisms, the delivery of each event is verified using ACKs, timeouts and retransmissions. After the initial 3-way handshake, a session between the peers starts. During the session, intermediate routers can crash and reboot, wireless disconnections can occur, servers may shut down, and thus the session may break. There are several ways to detect such dropped connections in order to re-establish a TCP session. For instance, when sending out events without receiving ACKs; after several seconds the sender (e.g., publisher) considers the receiver (e.g., broker) is down and terminates the connection. In a different approach, some reliable protocols build atop UDP (e.g., CoAP/MQTT-SN) and add their own reliability mechanisms through additional acknowledgments (ACKs) or negativeacknowledgments (NACKs). Whether on top of TCP or on top of UDP, different levels of QoS may be provided (e.g., with MQTT, which adds its own reliability mechanisms on top of TCP). In our work, we correlate the intermittent ON/OFF periods of mobile peers, with the logical sessions of such reliable protocols. After taking into consideration the above assumptions, in next section we provide a comprehensive approach for evaluating end-to-end response times and delivery success rates by relying on queueing theory.

QUEUEING MODELS

To model end-to-end pub/sub interactions for performance analysis, we rely on queueing theory. In particular, we use simple inbound and outbound queues to estimate response times and event delivery success rates, as part of analytical or simulation models. Considering an end-to-end interaction between a sender and a receiver (e.g., publisher -broker), an inbound queue can be used to receive and process events (at the receiver's side) and an outbound queue to transmit them (at the sender's side). Each queue or queueing center serves events through a dedicated server. Each server supports a specific service rate (rate to process or transmit one event per time unit) denoted as 𝜇. All queueing centers apply a firstcome-first-served (FCFS) queueing policy. In this section, we define the individual queueing models used as part of the simulation queueing networks of Section 5. Continuous Queueing Center. This queueing center models uninterrupted serving (transmission, reception or processing) of events as part of an end-to-end pub/sub interaction. It corresponds to the most common M/M/1 queue [START_REF] Lazowska | Quantitative system performance: computer system analysis using queueing network models[END_REF] (see Fig. 3a), featuring Poisson arrivals and exponential service times. An M/M/1 queueing center is defined by the tuple:

𝑞 mm1 = ( 𝜆 in , 𝜆 out , 𝜇
)

(1) where 𝜆 in is the input rate of events to the queueing center, 𝜆 out is the output rate of events, and 𝜇 is the service rate for the processing of events. Let ∆ mm1 in be the mean response time. This is the time that an event remains in the system (corresponding to queueing time + service time). An analytical model for the mean ∆ mm1 in can be found in [START_REF] Lazowska | Quantitative system performance: computer system analysis using queueing network models[END_REF]. ON/OFF Queueing Center. To deal with the mobile peer's connections and disconnections we introduce the Intermittent (ON/OFF) queue, which is depicted in Fig. 3b. Events arrive according to a Poisson process with rate 𝜆 in , and are placed in a queue waiting to be "served" (see Fig. 3b) with rate 𝜇, which is exponentially distributed. We assume that the server is subject to an on-off procedure. That said, it remains in the ON-state for exponential time with parameter 𝜃 ON (𝜃 ON = 1/𝑇 ON ), during which it serves events (if any). Upon the expiration of this time the server enters the OFFstate during which it stops working (stops serving relevant events) for an exponentially distributed time period with rate 𝜃 OFF (𝜃 OFF = 1/𝑇 OFF ). Accordingly, an ON/OFF queueing center is defined by the tuple:

𝑞 onoff = ( 𝜆 in , 𝜆 onoff out , 𝜇, 𝑇 ON , 𝑇 OFF ) (2)
where 𝜆 in is the input rate of events to the queueing center, 𝜆 onoff out is the output rate of events, and 𝜇 is the service rate for the processing of events (if any) during 𝑇 ON . The output process 𝜆 onoff out is intermittent, because no event exits the queue during 𝑇 OFF intervals. Let ∆ 𝑜𝑛𝑜𝑓 𝑓 in be the the mean response time (the time that an event remains in 𝑞 onoff ). An analytical model for the mean ∆ 𝑜𝑛𝑜𝑓 𝑓 in is provided in [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]. Up to now, we have defined queueing models having buffers with infinite capacity and arriving events with infinite lifetime. This certainly affects the response time but also the rate of events successfully served over the total number of arriving events. However, modeling IoT protocols with such characteristics may not be realistic. For instance, upon a long disconnection period (e.g., 30 mins) of an IoT sensor, the produced data/events may exceed the sensor's buffer capacity and/or some of the oldest data may become obsolete for the receiving application/user. Accordingly, in this subsection we introduce the corresponding queueing model features that take into account the above constraints. These features can be applied on both continuous M/M/1 and ON/OFF queues. Queueing Network with Event Expirations. A queueing network is a network of connected queues which can be used to model the performance of a system. For instance, in the context of our work, we model pub/sub interactions by creating queueing networks which consist of queueing models presented in the previous subsections. As depicted in Fig. 4a, events arrive with a rate 𝜆 𝑖𝑛 in order to be processed in the first queue of the queueing network. An arriving event carries a lifetime period attributed to it upon its creation, which represents the event validity inside the queueing network. Hence, an event may enter the queueing network and as soon as its lifetime elapses, the event abandons the network and is considered as expired.

To consider an event as expired, we take into account the time the event spends in both queue and server at each queue. Assuming that a queueing network consists of a single M/M/1 queue, an event reneges if its service does not begin by a certain lifetime period (which includes its expected service demand as well). Based on the queueing theory literature, such a model is studied as an M/M/1 queue with reneging or impatient customers [START_REF] Montazer-Haghighi | On a multiserver Markovian queueing system with balking and reneging[END_REF][START_REF] Yue | Optimal performance analysis of an M/M/1/N queue system with balking, reneging and server vacation[END_REF]. In this work, we provide the simulation of the above M/M/1 model through our simulator. Furthermore, we enrich the ON/OFF queueing center to support reneging or impatient customers. Hence, system designers are able to create queueing networks that may include different queueing models (M/M/1 or ON/OFF) enriched with lifetime periods. Queueing Center with Finite Capacity. This is a well known queueing model feature, where a specific buffer size is applied to the queue that ensures having max 𝐾 events in the system (queue + server). This prevents from storing too many events for too long in devices with limited hardware capacity (memory, hard disk). In particular, as depicted in Fig. 4b, events arrive in the queue with 𝜆 in . Before an event enters the queue the following condition is checked: 𝑛𝑒𝑤_𝑞𝑢𝑒𝑢𝑒_𝑠𝑖𝑧𝑒 + 𝑒𝑣𝑒𝑛𝑡_𝑖𝑛_𝑠𝑒𝑟𝑣𝑖𝑐𝑒 > 𝐾. If the condition is true, the event is dropped. Otherwise, it enters the queue to be processed.

Based on the literature, an M/M/1 queue with finite capacity is notated as M/M/1/K [START_REF] Gross | Fundamentals of queueing theory[END_REF]. In our models, we represent M/M/1 and the ON/OFF queues presented in the previous subsections with finite capacity by adding the system size (𝐾) to the corresponding definition (see tuples 1 and 2). Reliable and Unreliable Protocol Queueing Models. We use the above queueing centers as part of larger queueing networks in order to represent and evaluate the application and middleware layer of pub/sub systems. Estimated response times can be derived using both analytical and simulated models after composing larger queueing networks. Hence, the above queueing models can be applied to our simulation models and the trade-off between response times and delivery success rates can be evaluated.

To model the event transmission of unreliable protocols, we use an intermittent queue (ON/OFF, see Fig. 3b) at the applayer of the mobile publisher representing its connectivity (e.g., voluntary disconnection). At the mdw layer we use continuous queueing centers (e.g., M/M/1, see Fig. 3a) with losses at the exit, for the processing of events regardless of the middleware/mobile broker's/subscriber's connection or disconnection. Either the event is successfully transmitted (in the former case) or it is lost (in the latter case).

To model the event transmission of reliable protocols, we use an intermittent queue at the app layer of the mobile publisher. To represent the end-to-end established session, we apply at the ON/OFF queue an overall connectivity pattern between the sender (e.g., publisher) and the receiver (e.g., broker). Determining such an overall pattern requires to take the intersection of the connectivity patterns of: i) the publisher's app; ii) the subscriber's app; and iii) the middleware. We illustrate this in Fig. 5. At the mdw layer we use continuous queueing centers to represent simply the processing/transmission times of events (end-to-end connectivity is represented by the above ON/OFF queueing center and there are no event losses).

PUB/SUB PerfMP

By following the assumptions presented in the previous sections, we now introduce performance models for both unreliable and reliable pub/sub interactions by using Queueing Network Models. We call these models performance modeling patterns (PerfMP), as they can be reused by system designers for evaluating the performance of IoT applications employing pub/sub protocols. In this section we provide the description of the pub/sub pattern. Description. In pub/sub, a publisher publishes events to the broker and the subscriber receives them (through the broker). We assume that the subscriber is already subscribed to a specific topic in a broker and the publisher publishes events characterized by the same topic. For instance, a reporter posting news for a football team, which are received by another user. The pub/sub pattern is depicted in Fig. 6; it is used to model a reliable/unreliable pub/sub end-to-end interaction. Such a model evaluates the end-to-end response time and event delivery success rate of events, from the moment they are sent by the publisher's app, then they are received by the broker and are forwarded to the subscriber, until they are finally received by the subscriber.

At the publisher's side, for the reliable or the unreliable models, multiple apps produce events at the publisher's side (app layer). Each app may be disconnected (OFF-state -e.g., for energy saving purposes) and until its next connection (ON-state) the produced events are buffered in an ON/OFF queueing center. For any produced event a lifetime period is applied, which represents the event validity inside the queueing network. Let 𝜆 𝑝-𝑖𝑛 app be the input rate of events to the app's ON/OFF queueing center. The publisher's mdw layer accepts events from the specific app and from multiple other apps. Let 𝜆 𝑝-𝑖𝑛 apps be the input rate of events from other apps to the mdw layer.

Regarding the unreliable model, the publisher's mdw layer does not verify the successful transmission of events to the broker. Events are sent continuously without any knowledge of the disconnections of the mdw or the broker, which may result in losses. Hence, an event transmission is modeled using a continuous queueing center at the publisher's mdw layer, where the applied service rate 𝜇 tr represents the transmission delay inside the network. Finally, additional event losses may occur due to event expirations at the app layer.

On the other hand, in the reliable model, the app's ON/OFF queueing center applies the overall end-to-end connectivity pattern (see Fig. 5). Thus, the app layer transmits events to the mdw as soon as an end-to-end connection (between the publisher and the broker) is established. Similarly to the unreliable model, an event transmission is modeled using a continuous queueing center at the publisher's mdw layer. In the reliable model the event reception is verified and, hence, event losses occur only in case of event expirations.

At the broker's side, for both the reliable/unreliable models, events arrive at the mdw layer through a continuous queueing center. These events may arrive from multiple publishers (see the additional flow 𝜆 𝑏 oth ). Dropping of events occurs at the exit of the broker's input queue, depending on the subscriptions or due to event expirations (based on the lifetime period). In case an event is not dropped, it is forwarded to an output queue for its transmission to the corresponding subscriber. In the unreliable model, the transmission of events to the subscriber is done through an ON/OFF queueing center, which represents the broker's app-layer disconnections. This is the case where the broker is deployed in a mobile device and the transmission of events must be done based on the device's disconnections. Nevertheless, losses may occur due to middleware disconnections or event expirations. In the reliable model, the transmission is done through an ON/OFF queueing center, which represents the overall end-to-end connectivity between the broker and the subscriber (broker's, middleware, and subscriber's app connectivity), and losses may occur only due to event expirations. In this work, we focus on the end-to-end dissemination of events through a single broker by adapting QoS constraints found in the IoT. Interactions through multiple brokers and event duplications are considered in our previous work in [START_REF] Bouloukakis | Timeliness Evaluation of Intermittent Mobile Connectivity over Pub/Sub Systems[END_REF]. Finally, at the subscriber's side, events arrive at the mdw layer through a continuous queueing center. These events may arrive from multiple other publishers (see the additional flow 𝜆 𝑠 oth ) and be destined to multiple apps. Let 𝜆 𝑠-𝑜𝑢𝑡 app be the flow destined to the subscriber of interest. For the subscriber's app, a continuous queueing center is used to process events and detect possible event expirations.

The pub/sub pattern can be used to model several IoT protocols and messaging technologies. AMQP [START_REF]Oasis advanced message queuing protocol (amqp) version 1.0[END_REF] and MQTT [START_REF] Banks | MQTT Version 3.1. 1[END_REF][START_REF] Karagiannis | A survey on application layer protocols for the internet of things[END_REF] support pub/sub interactions. System designers are able to compose the corresponding queueing network that represents a pub/sub interaction (i.e., publisher-broker or brokersubscriber link) based on the applied QoS feature. Applying 𝑄𝑜𝑆u in both interactions, results to the A → B → C queueing network (dotted arrows in Fig. 6). On the other hand, the D → E → F queueing network (solid arrows in Fig. 6) is used for 𝑄𝑜𝑆r in both interactions.

Such features can be defined by relying on API of the corresponding protocol or messaging technology. For instance, based on the JMS API a subscriber can be defined as "nondurable" or "durable". For a non-durable subscriber, event losses occur upon its disconnections (mdw or app layer disconnections). Thus, the broker-subscriber link is unreliable (the 𝑄𝑜𝑆u is applied upon subscription) and it can be evaluated using B → C queueing centers in Fig. 6. On the other hand, when a durable subscriber is disconnected, events are kept at the broker. Thus, the broker-subscriber link is reliable (the 𝑄𝑜𝑆r is applied upon subscription) and it can be evaluated using E → F queueing centers in Fig. 6. It is worth noting that our pattern can model only event dissemination between publishers/subscribers. In our future work, we intend to identify the corresponding queueing network for the modeling of subscriptions as well.

EVALUATION RESULTS

Our simulator, MobileJINQS 1 implements the queueing models presented in Section 4. We then leverage MobileJINQS for creating simulation models that represent our proposed pub/sub performance patterns, such as the pub/sub PerfMP (see Section 5). Using such models, we perform statistical 1 https://github.com/boulouk/mobile-jinqs analysis and evaluate the trade-off between response times and delivery success rates.

In what follows, we use MobileJINQS to evaluate: i) the interaction between a reliable publisher that publishes events to a reliable subscriber; ii) the interaction between a reliable publisher that publishes events to an unreliable subscriber; and iii) the previous interaction (𝑝 reliable to 𝑠 unreliable) with finite buffer capacities. We further show the applicability of our performance modeling for tuning the TIM system presented in the introduction.

Reliable 𝑝 to Reliable 𝑠

In Section 5, we defined the pattern that models the performance of pub/sub interactions by incorporating the queueing models defined in Section 4. The resulting end-to-end queueing network, is depicted in Fig. 6. Based on the selected QoS features (see Section 2) by a system designer, an end-to-end queueing network can be created for evaluation. For our experimental setup we set the 𝑄𝑜𝑆r for publishing events to the broker and the subscriber subscribes using the 𝑄𝑜𝑆r feature for receiving events by the broker (see Fig. 1 of Section 2). Accordingly, the end-to-end queueing network is reliable (i.e., D → E → F in Fig. 6) where losses occur only due to event expirations -i.e., there are no losses due to disconnections. Based on Section 5, the resulting queueing network represents and evaluates durable subscribers, that can be implemented in pub/sub systems using the JMS API.

At the input of the pattern's queueing network, events arrive with rate 𝜆 𝑖𝑛 app = 2 events/sec (publishing rate). Each event is valid for a deterministic lifetime period and then discarded by the queueing network. We alternate between values of 10, 30 and 60 sec for the lifetime parameter. Arrival rates from/to multiple other apps going through the various queueing centers at the middleware layer are isolated; we assume that they have already been taken into account in the utilization of the servers of the queueing centers.

We parameterize the queueing network as follows: as already defined, the app layer's ON/OFF queueing center represents the overall end-to-end connectivity between the publisher and the broker. We set the total average publisher's connected + disconnected period to be 𝑇 periods inside the 80 sec interval. To process the produced events and forward them to the mdw layer when connected, we apply a processing rate of 𝜇pr = 64 events/sec. The applied processing rate is very low, since the app layer's queue is used locally only to forward events to the mdw layer. To transmit events to the broker, we apply a transmission rate of 𝜇 tr = 32 events/sec. The applied transmission rate can vary, depending on the bandwidth of the connection between the publisher and the broker. To process the incoming events at the broker's side, we apply (at the continuous queue) a processing rate of 𝜇pr = 64 events/sec. At the subscriber's side, we consider that peers remain always ON for receiving the subscribed events. However, middleware-layer disconnections may occur, which depend on the type of user mobility. Based on [START_REF] Bajaj | Toward Enabling Convenient Urban Transit through Mobile Crowdsensing[END_REF], such connection/disconnection (ON/OFF) periods vary in the scale of 0.5-1.5 min for Traffic Information Systems. Accordingly, we set the subscriber's total average connected + disconnected period to be 𝑇 s ON + 𝑇 s OFF = 30 sec. We apply this 𝑇 s ON + 𝑇 s OFF period to the ON/OFF queue inside the broker transmitting events to the subscriber. Experiments are performed by varying the 𝑇 s ON and 𝑇 s OFF periods inside the 30 sec interval. During ON periods, events are transmitted to the subscriber with a transmission rate of 𝜇 tr = 32 events/sec (again this represents the network transmission delay based of the available bandwidth of the broker/subscriber link). Finally, at the subscriber's side we apply a processing rate of 𝜇pr = 64 sec for the processing of incoming events by the continuous queueing center. To simplify our experimental setup, the broker node is assumed to be always in the state ON (e.g., deployed on Cloud). Delivery Success Rates. In order to evaluate the effect of varying lifetime and connection/disconnection periods on delivery success rates (Ξ 𝑝 𝑠 ), we perform simulations after applying the above parameters to the queueing network of Fig. 6. At the publisher's ON/OFF queueing center, the 𝑇 p ON period varies from 10 to 70 sec, increased by 10 sec at each experiment. Thus, 𝑇 p OFF equals the remaining time from the 80 sec total. At the subscriber's side, connections (𝑇 s ON ) last 10, 15, 20 sec and disconnections (𝑇 s OFF ) equal to the remaining, 20, 15, 10 sec. The rates of successful interactions are shown in Fig. 7 for various values of lifetime, and 𝑇 ON /𝑇 OFF periods for both the publisher and the subscriber. Using our simulator, we perform around 700, 000 interactions for each experiment. As expected, increasing 𝑇 ON (of the publisher or of the subscriber) periods for individual lifetime values improves the success rate. On the other hand, the success rate is severely bounded by lifetime periods, especially for lower values. Hence, increasing lifetime periods from 10 sec to 30 sec is necessary to have a success rate of more than 73% for a connectivity of 𝑇 p ON = 50 sec and 𝑇 s ON = 20 sec. Response Time vs. Success Rate. In order to study the tradeoff between end-to-end response times (∆ 𝑝 𝑠 ) and delivery success rates (Ξ 𝑝 𝑠 ), we present cumulative response time distributions in Fig. 8. In comparison with the previous set of experiments, we keep the same intervals for the subscriber's connections/disconnections (𝑇 s ON /𝑇 s OFF ), while the publisher's connections (𝑇 p ON ) occur for 30, 40, 50 sec and disconnections (𝑇 p OFF ) equal the remaining, 50, 40, 30 sec. Fig. 8, shows response times for successful interactions (i.e., we plot only interactions having response times lower than the lifetime period). From Fig. 8, lower lifetime periods produce markedly improved response time. For instance, with lifetime = 10 sec and equal 𝑇 ON /𝑇 OFF periods, 60% of the interactions complete within 1 sec. Comparing this to Fig. 7, with lifetime 10 sec, 𝑇 p ON = 𝑇 p OFF = 40 sec and 𝑇 s ON = 𝑇 s OFF = 15 sec, the probability of response time being less than 10 sec is 1 while the success rate is 0.32. By increasing the lifetime to 30 sec, the probability of response time to be less than 10 sec is 0.58 and the success rate is 0.65. Generally, these trade-offs confirm that higher lifetimes give better success rates but with higher response times.

Reliable 𝑝 to Unreliable 𝑠

For this experimental setup we set the 𝑄𝑜𝑆r for publishing events to the broker and the subscriber subscribes using the 𝑄𝑜𝑆u feature for receiving events (see Fig. 1 of Section 2). Accordingly, the end-to-end queueing network connects the reliable part of the pub/sub pattern, to the unreliable one (i.e., D → B → C in Fig. 6) where losses occur due to both event expirations and middleware/subscriber disconnections. Based on Section 5, the resulting queueing network represents non-durable subscribers, that can be implemented in pub/sub systems using the JMS API. To parameterize this queueing network, we apply the same parameters as the ones applied in subsection 6.1. Since the subscriber uses the 𝑄𝑜𝑆u feature, during its disconnections (𝑇 s OFF ) events will be lost. As expected, the QoS of this end-to-end interaction is downgraded, which is illustrated in the following. Delivery Success Rates. The rates of successful interactions are shown in Fig. 9 for various values of lifetime, and 𝑇 ON /𝑇 OFF periods for both the publisher and the subscriber. Similarly to the results of Fig. 7, increasing 𝑇 ON (of the publisher or of the subscriber) periods for individual lifetime values improves the success rate. However, the success rate is severely bounded not only by lifetime periods, but also due the subscriber's disconnections (𝑇 s OFF ) -especially for lower values. For instance, increasing lifetime periods from 10 sec to 30 sec is necessary to have a success rate of more than 55% for a connectivity of 𝑇 p ON = 50 sec and 𝑇 s ON = 20 sec. It is worth noting that for higher values the success rate is severely bounded only by the subscriber's disconnections (𝑇 s OFF ). For instance, for 𝑇 p ON = 70 sec and 𝑇 s ON = 20 sec, the success rate in not more than 64%, even if we vary the lifetime period to 10, 30 and 60 sec. This is also the case for 𝑇 s ON = 15 sec and 𝑇 s ON = 10 sec, where the success rate in not more than 50% and 33%, respectively (𝑇 p ON = 70 sec). Response Time vs. Success Rate. Similar to subsection 6.1, we study the trade-off between end-to-end response times and delivery success rates by presenting cumulative response time distributions in Fig. 10. By using the same settings as the one used to plot the response time distributions of Fig. 8, Fig. 10 shows response times for successful interactions. These results show that lower lifetime periods in conjunction with higher 𝑇 s OFF (the subscriber's disconnection periods) produce markedly improved response time. This is due to the fact that during 𝑇 s OFF intervals, events are lost without causing queueing delays (due to the selected 𝑄𝑜𝑆𝑢 feature at the subscriber's side). For instance, with lifetime = 10 sec and equal 𝑇 ON /𝑇 OFF periods, 80% of the interactions complete within 1 sec. On the other hand, by selecting the 𝑄𝑜𝑆𝑟 feature at the subscriber's side, 60% of the interactions complete within 1 sec (see Fig. 8). Comparing the results of Fig. 10 to Fig. 9, with lifetime 10 sec, 𝑇 p ON = 𝑇 p OFF = 40 sec and 𝑇 s ON = 𝑇 s OFF = 15 sec, the probability of response time being less than 10 sec is 1 while the success rate is 0.3. By increasing the lifetime to 30 sec, the probability of response time to be less than 10 sec is 0.78 and the success rate is 0.38. Generally, these trade-offs confirm that higher lifetimes and lower 𝑇 s OFF periods give better success rates but with higher response times.

T ON p (sec)
By comparing Fig. 9 (𝑄𝑜𝑆𝑢 subscriber) to Fig. 7 (𝑄𝑜𝑆𝑟 subscriber), it is important to note that for lifetime = 10 sec, success rates are approximately the same for lower 𝑇 p ON values. For higher 𝑇 p ON values there is a difference of maximum 10%. Comparing these results to Figs. 10 (𝑄𝑜𝑆𝑢 subscriber) and 8 (𝑄𝑜𝑆𝑟 subscriber) for lifetime 10 sec, the selection of the 𝑄𝑜𝑆𝑢 feature at the subscriber side provide markedly improved response times.

Reliable 𝑝 to Unreliable 𝑠 with Finite Capacity

For this experimental setup we use the same end-to-end queueing network of the previous subsection (i.e., D → B → C in Fig. 6). In addition, we apply finite capacities (𝐾) at each queueing center. Hence, losses occur due to event expirations, middleware/subscriber disconnections and finite capacities.

To parameterize this queueing network, we apply the same processing and transmission rates (𝜇), as the ones applied in subsection 6.2. Then, we alternate between values of: i) 10 and 30 sec for the lifetime parameter; ii) ). We illustrate in the following the QoS trade-off when applying lifetime or 𝐾. Delivery Success Rates. For each experiment we apply the following parameters: 1) lifetime = 10 sec 𝐾 = ∞; 2) lifetime = 30 sec 𝐾 = ∞; 3) lifetime = ∞ 𝐾 = 10; and 4) lifetime = ∞ 𝐾 = 50. The rates of successful interactions are shown in Fig. 11a. As expected, increasing lifetime and 𝐾 values improves the success rate at any arrival rate. However, when increasing finite buffers for high 𝜆 𝑖𝑛 𝑎𝑝𝑝 , the success rate does not increase significantly. Generally, from Fig. 11a we notice that increasing: i) 𝐾 at lower 𝜆 𝑖𝑛 𝑎𝑝𝑝 and ii) lifetime at higher 𝜆 𝑖𝑛 𝑎𝑝𝑝 -improves the success rate. Response Time vs. Success Rate. In order to study the tradeoff between success rates and response times, we present the mean values of response time in Fig. 11b for the same set of experiments. As expected, higher 𝜆 𝑖𝑛 𝑎𝑝𝑝 rates provide higher mean response times when applying lifetime periods. On the other hand when applying 𝐾 values, low 𝜆 𝑖𝑛 𝑎𝑝𝑝 rates provide higher response times and high 𝜆 𝑖𝑛 𝑎𝑝𝑝 rates improves them. Generally, from Fig. 11b we notice that applying: i) 𝐾 at higher 𝜆 𝑖𝑛 𝑎𝑝𝑝 and ii) lifetime at lower 𝜆 𝑖𝑛 𝑎𝑝𝑝 -improves the response time. Applying 𝐾 at higher 𝜆 𝑖𝑛 𝑎𝑝𝑝 decreases the queueing delay in comparison to the application of lifetime values. By comparing Figs. 11a,11b, it is important to note that for high 𝜆 𝑖𝑛 𝑎𝑝𝑝 rates the response time is markedly improved when applying 𝐾 = 10 and the corresponding success rate is slightly better in comparison to both response time and success rate when applying lifetime = 10 sec.

Note that though we have considered reliable 𝑝 to unreliable 𝑠 in these experiments, patterns provided in Fig. 6 may be similarly simulated for unreliable 𝑝 to reliable 𝑠 (i.e., A → E → F in Fig. 6). Through these experiments, we confirm that our analysis provides general guidelines for setting the lifetime, finite capacities and connection/disconnection periods to ensure successful interactions.

Discussion: TIM System Parameter Tuning

Linking back these results to the Traffic Information Management (TIM) system, application and middleware developers require tuning parameters such that freshness of delivered events are guaranteed. The TIM system is assumed to compose of both smartphones, built atop reliable middleware protocols as well as vehicle-devices/ fixed-sensors, built atop unreliable middleware protocols. This follows the reliable 𝑝 to unreliable 𝑠 model provided in Section 6.2.

Taking a publishing rate of 𝜆 𝑖𝑛 app = 2 events/sec, vehicles may connect and disconnect according to their profiles, yet expect timely information about crowd-sourced traffic congestion. The following profiles of users may be observed through historical statistics: publishing smartphones (𝑇 p ON = 50 sec, 𝑇 p OFF = 30 sec) and subscribing vehicle-devices (𝑇 s ON = 20 sec, 𝑇 s OFF = 10 sec). By relying on our analysis, an application designer may configure the lifetime periods of user access to 30 sec -using the data from Figs. 9 and 10, this guarantees that the vehicle-device will receive on average 58% of the posted notifications, within at most 16 sec of response time with a probability of 0.9. If these values are insufficient and the designer re-configures the lifetime to 10 sec, this now guarantees that the user will receive on average 48% of the posted notifications, within at most 3 sec of response time with a probability of 0.9.

As already pointed out, the above values can be configured for a publishing rate of 𝜆 𝑖𝑛 app = 2 events/sec. Using the data from Fig. 11, we notice that by increasing the 𝜆 𝑖𝑛 app gradually up to 20 events/sec, the success rate of the subscriber decreases to 37% -for lifetime = 10 sec and 47% -for lifetime = 30 sec. On the other hand, the average response time of the subscriber increases to 2.1 sec -for lifetime = 10 sec and 9.49 sec -for lifetime = 30 sec. If these values are insufficient and the designer applies finite capacity buffers, i.e., 𝐾 = 10 and 𝐾 = 50, this guarantees that now the user will receive 42% of the posted notifications -for 𝐾 = 10 and 44% -for 𝐾 = 50. Furthermore, the average response time is now 0.43 sec -for 𝐾 = 10 and 1.8 sec -for 𝐾 = 50. Such marked improvement in response time, with a marginal deterioration in success rates is non-trivial to analyze, without the use of toolkits such as PerfMP and MobileJINQS. This technique can be extended to other scenarios, where varying such parameters would provide QoS improvements.

RELATED WORK

In this section, we present our survey concerning the recent efforts in the design and evaluation of pub/sub systems. We begin with the work of Gaddah et al. [START_REF] Gaddah | A pro-active mobility management scheme for publish/subscribe middleware systems[END_REF][START_REF] Gaddah | Extending mobility to publish/subscribe systems using a pro-active caching approach[END_REF] where authors focus on the users' mobility inside pub/sub systems for investigating a pro-active caching approach. To design new hand-off management solutions, they consider a fixed network topology where transfer/caching of events/subscriptions between brokers occurs prior to subscribers' movement. To evaluate this approach, it is necessary to simulate the network topology and estimate several performance metrics (throughput, in this work), in order to compare them with other approaches. Authors represent the subscriber's mobility with connections and disconnections for randomly generated exponentially distributed times. However, publishing an event during subscriber's disconnection (OFF period) is considered as loss and is not waiting to the broker until the subscriber's reconnection. Finally, they utilize continuous-time Markov chains (CTMC) to express the subscriber's mobility and obtain the expected number of subscribers depending on the state (connected, disconnected, hand-off) for each broker. Performance metrics are derived through numerical methods whose solution demands high computational cost.

In [START_REF] Kounev | A methodology for performance modeling of distributed event-based systems[END_REF][START_REF] Sachs | Performance modeling and analysis of message-oriented event-driven systems[END_REF], a methodology for workload characterization and performance modeling of distributed pub/sub systems is presented. In this study, authors use Queuing Petri Nets for accurate performance prediction. While this technique is applicable to a wide range of systems, it relies on monitoring data obtained from the system and it is therefore only applicable if the system is available for testing. Furthermore, for systems of realistic size and complexity, QPNs would not be analytically tractable. Mühl et al. [21] present an approach for stochastic analysis of pub/sub systems employing identitybased hierarchical routing. This paper only considers routing table sizes and message rates as metrics.

Behnel et al. [START_REF] Behnel | On quality-of-service and publish-subscribe[END_REF] provide an overview of QoS metrics and describe their applicability within the context of pub/sub systems. QoS metrics are related to latency, bandwidth and message priorities for subscriptions and single notifications, but also for end-to-end flows. Authors evaluate a number of existing pub/sub systems (Hermes, IndiQoS, Choreca, etc) with regard to their QOS support. Furthermore, [START_REF] Corsaro | Quality of service in publish/subscribe middleware[END_REF] [START_REF] Corsaro | Quality of service in publish/subscribe middleware[END_REF] study end-to-end QoS aspects for reliable message delivery, timely delivery and trust relationship.

Bellavista et al. [START_REF] Bellavista | Quality of Service in Wide Scale Publish-Subscribe Systems[END_REF] study state-of-the-art industrial and academic solutions focusing on their ability to support scalability and QoS requirements in smart city scenarios. Results show that different design and architectural details influence QoS in the presence of different event models, routing topologies, system scale and QoS parameters. By focusing on wide-scale topologies, Schroter et al. [START_REF] Schröter | Stochastic performance analysis and capacity planning of publish/subscribe systems[END_REF] provide analytical models for pub/sub systems employing different peer-to-peer and hierarchical routing schemes. The resulting analytical models address all the major performance metrics, such as notification delay, subscription delay and message rates. Authors present the exploitation of their models by performing performance prediction and capacity planning. In [START_REF] Bouloukakis | Timeliness Evaluation of Intermittent Mobile Connectivity over Pub/Sub Systems[END_REF], we provide analytical models for wide-scale pub/sub systems. In particular, we analyze the end-to-end response time between mobile publishers and subscribers by focusing on the wide-scale analysis of intermediate brokers.

In this paper, we provide realistic Pub/Sub models by integrating QoS characteristics found in IoT applications. A generic set of patterns are provided when reliable and unreliable messaging protocols may be composed to derive end-to-end QoS outputs. System designers are able to evaluate end-to-end response times and delivery success rates and tune their IoT applications accordingly.

CONCLUSIONS

With the proliferation of mobile Internet of Things (IoT) devices, the Publish/Subscribe (pub/sub) interaction paradigm has been well employed due to the advantages of space-time decoupling. An important aspect of the pub/sub paradigm is the ability to set parameters such as message lifetimes, message buffer sizes and connectivity intervals, that significantly affects the end-to-end Quality of Service (QoS). In this paper, we provide a Queuing Network Model that captures the application and middleware layers of the pub/sub paradigm. By employing this model, we demonstrate how the end-to-end response times and delivery success rates may be studied, both for the case of reliable (e.g. TCP) and unreliable (e.g. UDP) underlying communication protocols. Our model is developed as a performance modeling pattern (PerfMP) for pub/sub, that may be tailored for multiple applications. Using an example of a Traffic Information Management system, this analysis if shown to help in accurately setting parameters to ensure timely delivery of fresh messages. Simulations performed using our simulator shows strong correlation between increasing lifetimes and delivery success rates for both reliable and unreliable pub/sub patterns.

Figure 1 :

 1 Figure 1: Pub/Sub QoS Features.

  Intermittent (ON/OFF) queue.

Figure 3 :

 3 Figure 3: Continuous and intermittent queues.

  Applying a buffer size (𝐾).

Figure 4 :

 4 Figure 4: Queues with event expirations and finite capacity.

Figure 5 :

 5 Figure 5: Overall end-to-end connectivity pattern.

Figure 6 :

 6 Figure 6: PerfMP for Pub/Sub Interactions.

Figure 7 :

 7 Figure 7: Success rates for reliable to reliable interactions with varying 𝑇 ON /𝑇 OFF and lifetime.

Figure 8 :

 8 Figure 8: Response time distributions for reliable to reliable interactions with varying 𝑇 ON /𝑇 OFF and lifetime.

Figure 9 :

 9 Figure9: Success rates for reliable to unreliable interactions with varying 𝑇 ON /𝑇 OFF and lifetime.

Figure 10 :

 10 Figure 10: Response time distributions for reliable to unreliable interactions with varying 𝑇 ON /𝑇 OFF and lifetime.

Figure 11 :

 11 Figure11: Success rates and mean response times for reliable to unreliable interactions with varying 𝜆 𝑖𝑛 𝑎𝑝𝑝 , 𝐾 and lifetime.

  𝑇 ON and 𝑇 OFF ).

		ƚƌĂĐĞ ϭ	ƚƌĂĐĞ Ϯ	ƚƌĂĐĞ ϯ	ƚƌĂĐĞ ϰ
	ƉƵďůŝƐŚĞƌ ;ƉͿ	ƚ ƉƵďůŝƐŚ YŽ^Ƶ lifetime d KE Ɖ	d K&& Ɖ	lifetime YŽ^Ƶ ƚ͛ ƉƵďůŝƐŚ	d KE Ɖ	ƚ͛͛ ƉƵďůŝƐŚ lifetime YŽ^ƌ	ƚ͛͛͛ ƉƵďůŝƐŚ lifetime YŽ^ƌ d K&& Ɖ d KE Ɖ
	ďƌŽŬĞƌ ;ďͿ	d KE ď	YŽ^Ƶ lifetime d K&& ď	dž	YŽ^Ƶ d KE ď		d K&& ď	YŽ^ƌ lifetime	d KE ď	YŽ^ƌ lifetime
	ƐƵďƐĐƌŝďĞƌ ;ƐͿ	ƚ ƐƵďƐĐƌŝďĞ YŽ^ƌ	YŽ^ƌ		ƚ ƐƵďƐĐƌŝďĞ YŽ^Ƶ	YŽ^Ƶ	dž	YŽ^Ƶ
		d KE Ɛ	d K&& Ɛ		d KE Ɛ			d KE Ɛ	d K&& Ɛ
		Figure 2: Analysis of Pub/Sub Interactions.
	events sent by the publisher and received by the subscriber
	(i.e., 𝑄𝑜𝑆u or 𝑄𝑜𝑆r); and ii) every peer's (𝑝 and 𝑠), broker's
	(𝑏) connectivity (i.e.,

ACKNOWLEDGMENTS

This work was supported by the Inria@SiliconValley International Lab and the research associate teams MINES/ACHOR.