Explicit Context Matching in Content-Based Publish/Subscribe Systems

Although context could be exploited to improve performance, elasticity and adaptation in most distributed systems that adopt the publish/subscribe (P/S) communication model, only a few researchers have focused on the area of context-aware matching in P/S systems and have explored its implications in domains with highly dynamic context like wireless sensor networks (WSNs) and IoT-enabled applications. Most adopted P/S models are context agnostic or do not differentiate context from the other application data. In this article, we present a novel context-aware P/S model. SilboPS manages context explicitly, focusing on the minimization of network overhead in domains with recurrent context changes related, for example, to mobile ad hoc networks (MANETs). Our approach represents a solution that helps to efficiently share and use sensor data coming from ubiquitous WSNs across a plethora of applications intent on using these data to build context awareness. Specifically, we empirically demonstrate that decoupling a subscription from the changing context in which it is produced and leveraging contextual scoping in the filtering process notably reduces (un)subscription cost per node, while improving the global performance/throughput of the network of brokers without altering the cost of SIENA-like topology changes.


Introduction
Despite potentially featuring large numbers of nodes, most sensor networks currently work as isolated islands, and most of the sensed valuable data is not yet shared. In the last few years, some attempts have been made to share data with the global community, but they focus on sharing across multiple wireless sensor networks (WSNs), spatially deployed in different locations (i.e., bridging WSNs on the Internet). Indeed, most of this research comes under the Large-Scale Wireless Sensor Networks umbrella [1]; it continues to address application-specific, static-sensor deployments, and does not tackle sensed-data sharing across different applications that could exploit the data outside the sensor network. Unless sensed data are shared across different application domains, the most important feature of ubiquitous computing-namely context awareness-will not easily reach its full potential.
With the advent of the Internet of Things (IoT), we can envision ubiquitous next-generation sensor networks that are connected to the Internet for publishing, sharing and searching sensed data across a wider range of IoT-enabled applications. The availability of advanced middleware functionalities to gather, process, exchange and exploit such data on a massive scale will be the cornerstone of the development of smart (customized, personalized and enriched) context-aware applications and services outperforming any available on the current Internet [2], thus fostering the creation of new business models and opportunities.
There is therefore an urgent need for a comprehensive solution that helps to share and use sensed data coming from ubiquitous WSNs across a plethora of applications intent on using these data to build context awareness. IoT-enabled cloud infrastructures, which are evolving to support ubiquitous and context-aware computation and information integration, could then leverage valuable sensed data to enable distributed applications to take into account the situation and context in which the information is produced or consumed. For example, services providing data could restrict the dissemination of their outputs to certain consumers based on their context, and any entity could subscribe to information whose provider matches a contextual scope.
The publish/subscribe (P/S) model in general, and its content-based form in particular, is poised as one of the most plausible approaches for achieving this goal, insofar as, traditionally, it has been the communication paradigm of choice for most WSNs. Moreover, the publisher and/or subscriber context (e.g., location information, environmental data, operating data, user preferences, etc.) could, if available, be relevant metadata for the routing process in a large fraction of the application domains in which the P/S model has been adopted as a smart solution for spreading information across a sizeable group of users or applications. This means that context has to be added to the P/S model and shared by publishers and subscribers.
In the IoT-enabled Internet, both generic data and context elements (i.e., sensed data) are available for consumption through the same P/S interface. This will require a novel approach to the P/S model that explicitly deals with sensed data (i.e., context) as a separate, first-class component to coherently offer context-awareness. In short, context has to be natively added to the classic P/S model, i.e., considered explicitly in the routing and forwarding processes and shared by publishers and subscribers. Unfortunately, despite many promising proposals [3][4][5], a powerful, fully-fledged context-aware P/S model is yet to be created. Precisely, the research community has predominantly focused on the wireless sensor network (WSN) field, where sensed data can arguably be regarded as context [6,7], but none of the most widely adopted content-based publish/subscribe (CBPS) middleware coherently offers context-awareness, as we will see in the analysis of current solutions. For example, it is not unusual to find context merely encoded into published notifications and subscriptions and handled as generic data, an approach which, as we argue in this paper, leads to major inefficiencies. Context-awareness radically changes the way both routing and matching needs to be performed in CBPS middleware to achieve efficiency. There are two orthogonal aspects in CBPS: matching and routing. Matching matches messages minimizing a metric, usually time, whereas routing routes the messages to other network elements, where the metrics are distance and energy [8][9][10].
In this article, we present a novel context-aware CBPS model, SilboPS, in which the context is managed explicitly. The focus is on the minimization of network overhead by improving the matching algorithm in domains with recurrent context changes related, for example, to WSNs, MANETs and IoT-enabled applications. Examples of contexts that have high or varying, "bursty" update rates include inventorying, stock portfolios, people or vehicle locators and proximity networks. We then evaluate our solution and compare it to SIENA [11,12], which is generally considered the reference implementation for a scalable CBPS service with a relatively low reconfiguration cost [13,14], and designed to maximize both expressiveness and scalability. Specifically, we empirically demonstrate the following: Decoupling a subscription from the changing context in which it is produced and leveraging contextual scoping in the filtering and routing processes in CA-CBPS systems notably reduces (un)subscription cost per node, while improving the global performance/throughput of the network of brokers without altering the cost of SIENA-like topology changes. Section 2, in particular, reviews the solutions and proposals of context-aware P/S models. Section 3 presents a use case highlighting the shortcomings of current approaches. In Section 4, we describe a set of design principles conceived to deal with the above issues. Section 5 further details our design decisions for implementing the proposed design principles. Next, Section 6 explains how our model behaves in comparison with SIENA in the proposed scenario and provide evidences supporting the affirmation stated above. Finally, in Sections 7 and 8, we conclude our proposal, and present future work in this area.

Background
As we are exploring how to exploit context to improve P/S systems as common mechanism for sensor networks, this section will briefly introduce key aspects of context management and, especially, context-aware CBPS systems.
Context-aware models are usually defined by how they react to context changes: passively or actively [15]. When passive models learn about a context change, they simply store the context or prompt the user before applying any change, whereas active models manage changes without user interaction, enabling automatic contextual reconfiguration. Another way of classifying these models is by how a context-aware application realizes the context has changed, i.e., either by sensing the environment or by being notified. Notification has the advantage of reducing communication overhead but at the risk of missing changes.
Syntactically, context can be transmitted using different message structures and syntaxes. The most widespread structures and syntaxes are in increasing order of complexity [2]: key-value pairs, markup scheme models, graphical models, object-oriented models, logic-based models, and ontology-based models. The flexibility/meaning trade-off differs from one representation to another. Key-value pairs are the best option for integration with CBPS systems since it is their canonical representation and, at the same time, has a rich internal representation for context modeling.
To deal with context [16] in CBPS systems, context information has to be processed from the viewpoints of both the subscriber and the publisher. Subscriber contextual information provides for filtering according to user location, device, preferences, etc. in order to get relevant, useful and appropriate information within the context. Publisher contextual information provides for message adaptation according to location or other context factors to get relevant, useful and appropriate information. Routing algorithms should bridge the gap, while leveraging both context scopes to reduce network overhead.
Context-awareness is a recent research line in the CBPS field, where most proposals are simply context agnostic. Within the context-aware approaches, most of the work has focused on implicitly context-aware strategies [17], which do not differentiate the context from the rest of application data and simply piggyback context on notifications or communicate context at subscription time. The shortcomings of these approaches are discussed in Section 3.
Most recent approaches have explored explicit context representation through an extended API to set the context that the broker network uses for notification routing and topology shaping [7]. However, these approaches have context-coupled subscriptions since both context and content filters are entangled making difficult them to manage independently.
Several middleware solutions have been designed to transparently implement context management and provisioning. The core assumption in [18] is that only effective and efficient context data distribution can pave the way to the deployment of truly context-aware services. This assumption is the basis for a unified architectural model and a new taxonomy for context data distribution. Similarly, a high-level software architecture for context data management and distribution suitable for m-commerce applications is presented in [19], but there is no detailed analysis of how the matching and the routing algorithms could be improved by using such contextual information. The comparison with other architectures is based on response time instead of throughput, being the latter the focus of this article.
Regarding the consideration of context in the filtering process, a major shortcoming of existing approaches and techniques is that they are very inefficient if profiles refer to values of context entity attributes that are subject to frequent changes (context updates). Recent research proposes the use of context-aware information filters (CIF) in addition to traditional information filters routing the input stream of messages in order to manage an input stream of context updates that are relevant to the routing process because the routing rules (a.k.a. profiles) refer to values in a context data store.
For example, [20] emphasizes the idea that information filtering systems and, therefore, their corresponding indexes must be context-aware and present AGILE (Adaptive Generic Indexing with Local Escalations), a set of extensions to existing index structures for information filtering systems aimed at dynamically adapting the index structure to the frequency of context changes. The key idea of AGILE is to dynamically adjust internal structure depending on the messages received, changing scope and accuracy accordingly. AGILE focuses on adaptive index structure management and applies to traditional database workloads, e.g., transaction processing and the TPC-C benchmark. Performance experiments showed that AGILE can improve the message throughput of a context-aware information filter by as much as one order of magnitude, compared with traditional approaches to implementing information filtering systems (No Index, Eager full indexing, Partial indexing, and Lazy Updates, GBU). Nevertheless, AGILE does not separate the context function from the subscription. Although this allows their matching function to outperform ours when the context changes slowly compared with the notification rate, it is a shortcoming when compared with our solution in highly changing context scenarios, as we will explain later.
Finally, systems can vary in terms of the aspects considered as context information. Most mature projects largely equate context with location management and are known as location-based services (LBS). L-ToPSS [21] is a LBS system based on a P/S middleware that adds an extra location processing module to a typical event broker to manage possible spatial events and subscriptions. The system is designed to support window queries and N-nearest queries. Based on L-ToPSS, Xu and Jacobsen [22] propose efficient algorithms for location constraint evaluation. CAMEL [23] is a push-based middleware construct based on a database. Like L-ToPSS, the system is designed to support window queries and N-nearest queries. Most of the research investigates how the constraints or predicates in subscriptions can be evaluated more efficiently, but little progress has been made with respect to enhancing the expressiveness of spatial subscriptions [24].

Shortcomings of Implicit Context Management
Taking into account roles, notifications and subscriptions, the problem is necessarily strongly affected by the entity context, in particular, their location. A nave application of CBPS to such a scenario would be to merge content and context in both messages and filters, making it implicitly context-aware. Although this paper focuses on the matching problem, an in-depth analysis unveils several shortcomings both related to the routing and the matching problem that are discussed in this section.
• Matching inversion. Classic CBPS systems model messages as key-value sets, m ∈ {K × V}, where K is the attribute name and V is its value. Those messages can be matched by filters issued by subscribers, f ∈ F ⊆ {K × V}. If m is in the scope of a filter f , we can state that f covers m or f m. The purpose of the message is to encode data, whereas the filter represents the interests in this information. Applying CBPS to context-aware scenarios violates this separation of concerns: subscriber filters contain constraints over the context mixed with constraints over the notification; symmetrically published notifications include constraints for subscribers that are enforced by brokers. As a result, there is the potential of the message and context being confused and semantically ambiguous. By mixing context and content, the application misses out on the benefits stated in [25]. In addition, this can lead to aliasing errors if mixed context-aware and context-unaware entities use the same P/S system. Only a few CBPS systems, which implement filtering using Turing-complete languages, can afford this out-of-the-box change. Anyway, such systems are difficult to optimize and exploit in the first place.
• Message flooding in changing environments. Published messages bundle the notification content with contextual information (K = K content ∩ K ctx ), for example, the events detected by cameras include the camera location. This approach has a comparatively small overhead with respect to a context-agnostic scenario since the rate of change of the context is small compared with the rate of publication. If as in Figure 1 that assumption is not met, constant context updates will create a massive overhead because existing subscription filters ( 1 ) are constantly invalidated ( 2 ) and then updated ( 3 ). In terms of messages, this implies a waterfall of unsubscriptions and new updated subscriptions flooding the whole network as illustrated. In our scenario, driver subscriptions pose this problem since their position changes constantly, and they are encoded as part of the filter. • Unrealized potential performance. If properly exploited, contextual information can improve efficiency by minimizing networking overhead in two senses: (a) messages could be efficiently routed; (b) the overlay network topology could be optimized. For instance, it is of no use to cluster drivers interested in nearby traffic alerts (same interest) without considering the context that permeates their interest. Similarly, clustering drivers at nearby locations (same context) is plagued by the same problem, since it ignores their interests. Using implicit context, however, the broker will have to handle more complexity in the form of bigger routing tables and longer routing computation. Finally, any advantage from context exploitation requires explicit context management. Implicit context-aware solutions require the broker to parse both messages and filters, which is an additional overhead. • Separation of concerns within entities. Context management and subscription or publication are very different concerns that must be handled by different components at the architectural level. Implicit context-awareness favors coupling and forces rigid designs in which the P/S component is also responsible for detecting, managing and communicating context changes.
For instance, drivers can use a mobile application in which location context is managed by a GPS component decoupled from the subscriber component in charge of handling incoming notifications.
• Undermined publisher/subscriber decoupling. The main property of CBPS systems is decoupling in terms of space, time and synchronization between publisher and subscriber. The only thing that the subscriber needs to know is how the events of interest are represented. Subscribers and publishers are obliged to share a unified and homogeneous representation of context, as context is embedded in notifications for implicitly context-aware systems. In the example scenario, location is represented uniformly as a coordinate point for all entities. A more flexible approach, such as ontology-based mediation, is beyond the scope of the scheme.

Proposed Design Principles
There is a clear motivation to overcome the weaknesses of implicit context-aware management, which degrade as the application scenario context becomes more changeable.
Our approach is to decouple context and content throughout the CBPS with the aim of spatially, temporally and synchronously decoupling publishers from subscribers within a contextual scope.
The design principles that guide our vision of a context-aware content-based publish/subscribe (CA-CBPS) system are as follows: 1. Explicit separation of context and content. The scope of both messages and their filters must be restricted and deal exclusively with content. Therefore, m ∈ {K content × V}. 2. Generalized P/S model for contextual scoping. The reversal of the matching procedure demonstrates an impedance mismatch between content-based filtering and any other type of filtering that does not fit the content-based model. Symmetric context-scoping filters will be attached to both subscriptions and publications, restricting publisher contexts and subscriber contexts, respectively. Such filters will be attached (||) to publications, m|| f cs , f cs ∈ F ctx , and to subscriptions f || f cp , f cp ∈ F ctx given F ctx ⊆ {K context × V}. Note how publisher and subscriber can restrict their actions symmetrically through each other's contextual scope. This scoping mechanism can be seen as a role-based access control by the publisher [26] and as a new filtering dimension by the subscriber. 3. Context-invariant subscriptions and advertisements. Subscriptions will be context-invariant to avoid context change flooding. Context variable references will be used instead of embedding context values (cv) as part of the filters. In fact, a subscription f s defined as f || f cp can be regarded as a function on the context in which the filter f cp is the context-aware part: Such functions become regular filters when applied to a given context ctx ∈ C within the brokers. Figure 2 illustrates how flooding is avoided as subscriptions ( 1 )   To apply context update and bind it to its correct filters, a subscriber-unique UUID, created by the broker, is added to filters and to context messages. This is necessary to distinguish the same filter if issued by different subscribers and to bind the filter to its correct context when the context function is called. This does not clash with the decoupling offered by P/S systems since it is used only internally by brokers and is comparable to the procedure enacted by other systems that use a multipath topology to resolve the duplicate message problem [27,28].

Proof of Concept: Proposed CA-CBPS Applied to the Use Case
This section shows the application of our proposal to the domain problem presented in Section 3. Our scenario includes a set of cameras sending traffic information (publishers) and a set of cars receiving relevant (context-aware) information (subscribers). Cameras are automatically connected to the brokers thanks to the infrastructure in which they are installed whereas cars can connect to brokers using the access points deployed along the road. This is an instance of a V2I scenario and is a simple sub-problem covering all the relevant details. At the same time this example fits the paper assumptions about environments with highly changeable context. Let us examine the state of the routing tables and the messages exchanged when adding publishers and subscribers to the network. Figure 3 shows the network of brokers, each of which has its own contextManager.

Adding Publishers with Changing Context
A camera is connected to the broker network, specifically to broker B 1 whose advertisement and subscription tables are initially empty (see Figure 4). This camera establishes its initial context, namely its position, by invoking setContext(CamPos) with CamPos ≡ cv p = x p = CamPos.x, y p = CamPos.y . However context updates from Cam 1 will not be sent to the broker since their value is meaningful only when bound to a notification. Instead the last context will be held by the local API and appended to the sending message on each publish method invocation. As a matter of fact, our assumption in this scenario is that context changes are more frequent than notification/subscription messages.  • A is an advertisement filter as in traditional CBPS systems. Cam 1 can notify accidents: • A cp models the context of the publisher, x p and y p , and shows what contextual information could be exploited by subscribers to enrich their subscriptions. Cam 1 has a location context: This advertisement is propagated throughout the broker network to B 2 , B 3 and B 4 , producing changes in all their advertisement tables: • B 1 , advertisement  publish(m, cxt), where m is the notification, which is context-free content, and cxt, is the last context sent by Cam 1 . B 1 queries the subscription table to forward the message. Since it is empty, B 1 drops the message m until it receives a subscription following the path marked by previous advertisements. If the traffic camera is a mobile sensor and changes its position, it will use setContext to set the new position, but this will not be sent to broker B 1 until publish is invoked. Although for this scenario the context could be directly passed at publication time, interaction is cleaner if the API offers two different methods because there is no need for clients (publishers or subscribers) to remember the last context.

Adding Subscribers with Changing Contexts
Now a first-time subscriber joins the scenario (as in Figure 5). The subscriber is a vehicle, V 1 , using a context-aware mobile device to receive alerts created within a 20 km radius of its position, which, for simplicity's sake, we model as a square with 40 km sides. Initially, V 1 s location will be in the range of Cam 1 .  First of all, V 1 accesses the P/S network as a client of B 2 and sends its initial context, setContext(CarPos). B 2 receives this information as a context message, extracts the cv s values and creates a UUID (V id 1 ) for V 1 , which it stores to its contextManager table as V id 1 ; x s = CarPos.x, y s = CarPos.y . Then B 2 checks, using the subscription table, to see if V 1 context needs to be forwarded. In this case, no action is taken since the table is empty.
Next, B 2 receives the subscription of V 1 to nearby traffic alerts, subscribe( f, f cp ), which is mandatory since it has sent a setContext(CarPos) call, where f is a content-based filter f ≡ {msg = accident} and f cp is a function that models a filter based on restrictions about publisher context, and receives dynamic subscriber context values: x p ≤ this.x + 20 y p ≥ this.y − 20 y p ≤ this.y + 20} The broker first adds V id 1 to the new subscription f , which is then stored into B 2 's subscription table as V 1 ; f , f cp . The next step is to check if there is any advertisement that matches the subscription. To do this, B 2 queries its advertisement table, which contains row B 1 ; A, A cp and then checks if there exists an A f ∧ A cp f cp . Given that A and f contain msg = accident and that A cp is ∃x p ∧ ∃y p and f cp uses exactly x p and y p as the publisher context, the match is positive, and B 2 sends first the context message, if needed, and then the subscription message to B 1 . To send the context message, B 2 checks whether the subscription table already contains an outbound entry for V id 1 . If it does not, it sends the context message, namely context(cv s ) with cv s the context value containing V id 1 ; x s = CarPos.x, y s = CarPos.y , to B 1 . Then it sends a subscription message with subscribe ( f, f cp ).
When B 1 receives both messages, it adds the subscriber's context cv s to the contextManager as V id 1 , cv s and modifies its subscription table with the subscriber's data, writing row B 2 ; f , f cp . B 2 and B 1 then stop propagating the subscription because there are no more entries in their advertisement tables.

Notification Delivery
To illustrate how new publications are to be delivered to interested subscribers, imagine that there is an accident close to Cam 1 . Cam 1 sends a new publish(m, cv p ), where m ≡ {msg = accident}. The publication includes the contextual information because the previous setContext called by publisher did not actually send the changes to the broker. B 1 's subscription table contains row B 2 ; f , f cp and therefore B 1 must check if the publish message matches these filters, dropping it otherwise. Because m f , B 1 must check the contextual filter. This is a lazy process led by usually more restrictive and relevant content filters.
At this point, the context-invariant filter f cp , which is the key component of our proposal, must be evaluated using the values fetched from the contextManager table. In particular, B 1 uses V id 1 that searches f to look up context information of the associated cv s ≡ x s = CarPos.x , y s = CarPos.y and then passes both context (cv s and cv p ) to evaluate f cp : CamPos.x ≤ CarPos.x + 20 CamPos.y ≥ CarPos.y − 20 CamPos.y ≤ CarPos.y + 20} Note that the use of contextual values to evaluate context-aware restrictions has been delayed until now, improving performance in scenarios like this where context changes (car positions) occur at a faster rate than new notifications (traffic accidents). In addition, the context function is more expressive than the one available in subscriptions since it is able to perform simple computations and is not confined only to comparison.
In this case, the car is close enough to the camera, and the result of evaluating f cp is a positive match. Since both filters are satisfied, the message is sent to B 2 as the subscription table prescribes. To do so, B1 generates an internal publish message publish (m, cv p ) with the contextual variables of the publisher used in the previous step, namely cv p ≡ {x p = CamPos.x, y p = CamPos.y}. Note again that the contextual data, in this case information about the publisher, is not propagated until strictly necessary. This publication reaches B 2 . First, B 2 accesses the subscription table and checks that the publication matches row V 1 ; f , f cp . This process is identical to the above: m f so f cp must be evaluated as f cp (cv p , cv s ) → f cp . B 2 ultimately obtains the same contextual filter, and so will still match.
As the publication matches V 1 's range, the message m carrying information about the nearby traffic incident is finally delivered to car V 1 .

Subscriber Context Update
First, let us consider that V 1 is driving along the highway and changes its context (see Figure 6) by sending setContext(CarPos). B 2 processes this change of context with the help of the context manager, which replaces the values of x s and y s previously stored in the contextManager table.  Subsequent publications by Cam 1 will be subject to a new contextual match, using the new data. f cp may no longer match, thus no messages will reach B 2 . This way, tables are updated elsewhere in the broker network for every context they receive.

Publisher Context Update
Now camera position changes. Again, Cam 1 invokes the local API with setContext(CamPos) but no message is sent to the broker; instead the new values cv p ≡ x s = CamPos.x , y s = CamPos.y are held locally and sent together with the following publish call.

Prototype Evaluation
SilboPS evolved from our Java implementation of SIENA [12] and extends its interface by adding context functionality. In this way we were able to test the two systems in the same environment and match their differences without incurring in any semantic mismatch API penalization. As usual for P/S systems, our prototype does not support transactional messages, but offers FIFO channels with reliable delivery. This implies that no message loss will be observed unless there is a link failure; however both channel endpoints are aware of such failure. Messages are processed in the same order as they arrive at broker irrespectively of their sending time.
We ran our experiment under Linux 3.2 and OpenJDK 7u3 on an Intel ® i7 860 @ 2.80 GHz machine equipped with 4 GB of RAM. Due to our scenario assumption, the focus is on context reconfiguration cost, rather than notification delivery performance. Nevertheless we ran a notification delivery performance test to verify the overhead introduced by this extension.
To assure that our results were meaningful, we used the same distribution parameters as in [12], adding the context part as an attribute of notifications and subscriptions for the SIENA version, and as a context function/context message in SilboPS. We used a uniform distribution applied on a square with 1,000 km sides to generate position values. The choice of this distribution gives SIENA a slight edge since it can exclude filters that do not match the notification position value, whereas SilboPS has to wait the context function result.
Thus, a context change in SIENA requires two messages to be sent: one message to remove the old filter, if any, and the second message to add the new filter. This is necessary because otherwise subscriptions will pile up leading to poor router performance and, above all, the delivery of unwanted messages. The first experiment is meant to compare the context change cost for the two systems. It performs 50 changes per subscriber on a single broker previously loaded with 10,000 subscriptions (equivalent to 1250 connections). As shown in Figure 7, the operation has a fixed cost in both systems. However, SilboPS outperforms SIENA by three orders of magnitude. The reason is that SIENA has to modify its index entries (removing and adding the filters), instead of updating only the subscriber's context, whereas SilboPS only updates context values. Figure 8 shows the total time taken by our prototype to perform context changes when it is loaded with an increasing number of connections. The router is loaded with a maximum of 10,000 subscriptions in the top chart and a maximum of 100,000 in the bottom chart. Each connection has an average of 10 subscriptions, that is, a load of 1,200 and 12,000 connections per router respectively. This highlights how processing time is proportional to the number of context changes and depends on neither the number of connections nor the number of subscriptions.  Figure 9 shows the cost of one context change with respect to the number of subscriptions issued by a single subscriber. It stands to reason that the cost increases linearly for SIENA, whereas it is constant in SilboPS. In addition to a faster processing time, this will reduce the number of messages sent in the network by a linear factor. So, the more subscriptions that are loaded to the broker, the bigger the saving will be. As a matter of fact, SilboPS behaves like SIENA when there is only one subscription per subscriber, but, even so, has the advantage of sending one instead of two messages, and the message size is smaller.
Note that the data in Figures 7 and 9 are consistent: the time required for a single context change in SIENA at 50 subscriptions per connection is equal to the value shown in Figure 7, that is, 10 ms. In this test SilboPS performance for a single context change appeared to be equal to its performance rate for 50 context changes. This is because, even though it has nanosecond precision, the available API does not guarantee nanosecond accuracy (As described in [29]). Even so we were able to calculate the slope for SIENA version and to get an estimate for the cost of a single context change of 105 µs/msg. For SilboPS we can either use Figure 7 where the time is high enough to be measured accurately, or use Figure 8 to calculate the slope, which is a fairly straight line. Thus we estimated an upper-bound of 0.2 µs/msg.  Figure 10 reports the time to process context change messages in a network of five brokers each with one publisher and 100 subscribers, where each subscriber sends on average 10 subscriptions for a total of 1,000 subscriptions per broker.
Our implementation is clearly about five times faster than SIENA. However, network transport protocol overhead reduces the three-order-of-magnitude gain shown earlier. Another network effect is buffering introduced by sockets. Note that the slope of the two curves changes at around 200 and 1000 context changes for SIENA and our prototype respectively; this is due to selected channel socket buffer filling. As a matter of fact, both systems use a queue to hold and then a single thread to process incoming messages in the broker. Consequently, incoming sockets do not slow down the routing since they each have their own thread. However, outgoing sockets do slow down the process because they use the broker's thread.  Context changes Context changes -Network SIENA SilboPS Figure 11 shows notification throughput when the broker is loaded with 10,000 subscriptions in the top chart, and with 80,000 subscriptions in the bottom chart. It is clear that SilboPS introduces a small overhead with respect to SIENA and that maintains the same shape through all the range; this proves our first assumption, stating that filters applied to notifications are stricter than the ones applied to context. As expected, the more notifications we send, the more stable the value is, since the broker queue always has an element and thus the broker saturation point can be reached.
These data are useful for calculating the matching time difference between the two systems. This reveals the trade-off point between the number of notifications and the number of changing subscriptions in the system, namely when it is convenient to switch from SIENA to our approach. We chose these values (see Table 1) because they represent the biggest difference between the two system's throughputs above the broker saturation point.
which is solved with respect to the ratio of X's: and substituting the above values, we found as trade-off point: Consequently, if the ratio between X noti f ication and X context is greater than 1.23, the SIENA processing time is better, whereas SilboPS performs better when the number of context changes is greater than the number of notifications. Note, additionally, that X noti f ication and X context represent the total number, so the more subscribers in the system there are, the more likely our system is to perform better. Moreover, this supports our assumption for the scenario described in this paper, where the number of notifications (traffic issues) is lower than the number of context changes (car's position updates).

Future Work
Of the design principles presented in Section 4, we will focus now on the generalized P/S model for contextual scoping. According to this model, symmetric context-scoping filters are attached to both subscriptions and publications. This allows publishers to restrict notification delivery to subscribers (i.e., by checking subscriber filter validity) based on both contexts. This scoping mechanism can be seen as role-based access control by the publisher [26,30] and as a new filtering dimension by the subscriber.
This design principle will be accomplished in two stages. First, a third parameter A cs (i.e., advertise(A, A cp , A cs ) will be added to the advertisement advertise(A, A cp ) sent by the publisher (Cam 1 ), see Figure 12), where A cs models the context information that the publisher is going to exploit to restrict the dissemination of published messages, resembling the above role-based access control.  This advertisement is propagated through the broker network to B 2 , B 3 and B 4 , leading to changes in all their advertisement tables, which now manage the publisher advertisement context for subscribers, A cs : • B 1 , advertisement The second stage is concerned with enhancing the publish message, changing context values with a contextual scope filter F cs (i.e., a function of the subscriber context) that publishers (i.e., cameras) use to restrict the propagation of m, and second context values in a similar way as for subscribers with setContext(CamPos) message. As Cam 1 does not restrict the scope, F cs = ∅.
This way, Cam 1 can send notifications to the P/S infrastructure. B 1 receives publish(m, F cs ) where m is the notification, which is context-free content, and F cs is a contextual scope filter that the camera uses to restrict the propagation of m.
If the traffic camera is a mobile sensor and changes position, it will send new setContext messages to B 1 . The context manager of this broker will just update its local variables x p and y p with the new data and forward the message to its neighbors (see Figure 13). Further evaluation is needed regarding whether filter removal should be applied at each context change, either timed or advertisement-based.  The next steps are to evaluate the overall system performance overhead introduced by this approach, and the trade-off between this overhead and benefits for publishers that intend to take advantage of the added functionalities.

Conclusions
In this article, we have presented a novel context-aware P/S model in which the context is managed explicitly. Our model adds a new dimension to CBPS flexibility: context scoping based on context-invariant filters, i.e., the notification filtering is separated from context filtering, allowing SIENA-like forwarding index to be updated only on new subscriptions and at the same time enabling a quick subscriber's context update without rebuilding the whole structure, thanks to the indirection provided by our context functions and the contextManager table.
Our experiments have shown that the approach presented in this article introduces a small overhead with respect to SIENA in terms of notifications throughput, but at the same time outperforms SIENA by three orders of magnitude on subscriber context updates. In addition, using our solution, clients do not have to hold the whole list of sent filters and manage filter life cycle (unsubscribe previous subscriptions, create filters with the new context and send the new subscriptions).
We have also demonstrated that our solution is extremely valuable in domains where context is highly dynamic and the number of context changes exceeds the number of notifications, such as inventorying, stock portfolios, people or vehicle locators that have with high or "bursty" context update rates.
Finally, note that the reported research is being developed and applied as part of the 4CaaSt platform-as-a-service (PaaS) project (http://4caast.morfeo-project.org), where P/S is offered as both a value-added service to hosted applications and a key internal platform asset.