Andras Kalmar, Rolland Vida, Markosz Maliosz. Inter-University Centre for Telecommunications and Informatics, 4028 Debrecen, Kassai lit 26. High Speed ...
Cog l nfoCom 2013· 4th I E E E I ntern ational Conference on Cogn itive I nfoco m m u n ications' December 2-5, 2013, Budapest, H u ngary
Context-aware Addressing in the Internet of Things using Bloom Filters Andras Kalmar, Rolland Vida, Markosz Maliosz
Inter-University Centre for Telecommunications and Informatics, 4028 Debrecen, Kassai lit 26. High Speed Networks Laboratory (HSNLab) Department of Telecommunications and Media Informatics, Budapest University of Technology and Economics, Hungary { kalmar,vida,maliosz } @tmit.bme.hu
Abstract
-
From another point of view, the Internet of Things means that the physical world itself is becoming a type of information system. Physical objects embedded with sensors and actuators are connected to the Internet through wired and wireless communication channels. Large amount of data will be created and circulated inside this information system in order to create smart and proactive environments. If objects can both sense their environment and are capable of communicating, they can be tools for understanding complexity and responding to it rapidly [1] [2].
There is a consensus today among researchers that
the Future Internet will be characterized by a significant shift towards the Internet of Things. Experts expect more than 50
billion devices connected to
the
2020 (sensors,
Internet by
smartphones, laptops, cars, clothes, wristwatches, etc.). To ensure
communication among these smart "things", first we need a proper addressing scheme. However, while in the traditional Internet (of People) usually an end-user communicated with another user identified by a specific (IP) address, in the Internet of Things
it
will
be
a
common
scenario
to
see
that
the
communication targets a specific set of "things", identified by the current status or values of their resources, interfaces, or other context parameters. For receive
some
traffic
example,
information
Concepts such as pervasive computing and the Internet of Things build on the idea that the user is surrounded by an intelligent environment that closely monitors a large set of context parameters and supports value-added applications and services that can take into account this context information. A system is called context-aware if it can extract, interpret and use context information and is able to adapt its functionality to the actual context [3].
imagine that we want to from all the
sensor
nodes
embedded in cars or smartphones that are on a certain street, have moved at least once in the last 5 minutes, and have their
batteries charged at more than 20 % . Or, we want to send some
targeted advertisements to all the devices that are in the close
neighborhood of our restaurant, have a video screen to display the ad, and have allowed in their profile the reception of ads. Multicast
groups
could
be
used
for
that,
but
traditional
In the traditional Internet, also called today the Internet of People, context information is not really taken into account by the communication paradigm. End-users usually communicate with other end-users, even if the real data packets are sent by their machines (computers, tablets, phones, etc.). The only context information that drives this communication is the name and the associated IP address of our counterpart. Recently emerging location-based services represent a step ahead, as they involve location information as an important driver of the communication. However, on the Internet of Things the list of context information that can characterize a given smart object is much wider. We might want to communicate with a set of objects that have embedded thermometers, attached screens, run a given operating system, have a certain amount of memory, and enough battery lifetime to operate safely.
multicasting is not scalable for such a large number of groups, as multicast addresses cannot be aggregated. In this paper we propose
therefore
a
context-aware
addressing
and
routing
solution based on Bloom filters, to supplement the traditional IPv6. This is a proof-of-concept paper that does not address all the fine details of such a solution; it just aims to show that Bloom filters could be very efficiently used to summarize context information, identify groups
of things
with
certain similar
characteristics, and make rapid routing decisions to reach these devices. Keywords:
context-aware
addressing,
routing,
Bloom
filters,
Internet of Things.
I.
INTRODUCTION
The straightforward question is then the following: how can The traditional solution would be to build a multicast group for all the devices that comply with the given request. However, as the list of possible combinations of context values is virtually infinite, it would be impossible to associate a separate multicast address for any possible request.
Due to the recently seen intense development of sensing and communication technologies, the so called Internet of Things (loT) concept is now turning from vision to reality. According to this concept we assign unique identifiers to everyday objects, enhance them with some (wireless) communication capabilities, and connect them through an Internet-like structure. Most of these devices will be mobile, or at least unwired, to be as unobtrusive as possible. They will be also highly heterogeneous regarding their energy supplies, processing, communication and sensing possibilities.
978- 1-4799- 1546- 0/13/$31. 00©2013 I E E E
we identity, and communicate with this set of "things"?
The solution we propose in this paper aims therefore at using the context information to form a specific group identifier based on the theory of Bloom filters (BF). These filters will then be used to efficiently summarize the context
487
A. Kalmar et al.
•
Context-aware Add ressi n g in the I nternet of T h i n g s using Bloom Fi lters
embedded sensors it has, etc. There are basically an unlimited number of possible combinations of these context parameters that can provide the membership criteria of a given group. For example, we might want to address all the sensors that are embedded on a given road segment, have at least three neighbors in their radio range, and a battery capacity above 60%. Or we might need to address all the devices that belong to members of a given department, are currently located on the third t100r of the university building, and have at least a 3.5 inch display to be able to play a video message of a given resolution.
information of loT devices attached to a given access point or edge router, and make fast routing decisions without necessitating long look-up operations in large (multicast) routing tables. The rest of this paper is organized as follows. In section II we explain in more details the concept of context-aware addressing, explaining why traditional IP multicasting cannot support such a service. Then, in section III we present briefly the basic operation of Bloom filters, what are the advantages and drawbacks of this solution. In section IV we provide then a detailed description of how BFs could solve the case of context-aware addressing, providing a very simple proof-of concept example. Conclusions are drawn and future work is presented in section V. II.
The traditional solution to address this problem would be to define globally unique IPv6 multicast addresses to each such possible group, and build corresponding multicast trees over the internet to handle data delivery to group members. However, while multicasting is a very efficient and scalable data dissemination solution for very large groups, a large set of recipients being identified by a single multicast address to be handled by the intermediate routers, one of its most important drawbacks is that it is not scalable for a very large number of groups, no matter their size.
C ONTEXT-AWARE ADDRESSING
The "IPv6 over Low-Power W ireless Personal Area Networks" (6LoWPAN) IETF group aims to make the IPv6 protocol compatible with low capacity devices. In order to do this it defines header compression and encapsulation that makes it possible for the IPv6 packets to be sent to and received from IEEE 802.15.4 based networks. By using the 6LoWP AN protocols low-power devices with limited processing capabilities can be integrated into the IPv6 networks. Core protocols of the 6LOWP AN architecture have been already specified; moreover some recently launched commercial products already implement this protocol suite. According to these we can say that using IPv6 on low capacity devices is a problem we can already deal with.
The problem comes from the fact that multicast addresses cannot be aggregated in the routing tables, as in the case of unicast addresses. All unicast addresses from the same subnet will have a single entry in the routing tables of the intermediate routers, an entry that provides the outgoing interface to use in case the destination address matches any of the addresses of that given subnet. However, in case of multicast addresses aggregation is not possible, since any two adjacent multicast addresses from the address space reserved for multicasting will correspond to multicast groups that might have completely different members, in different parts of the network, so the corresponding multicast trees will have different shapes as well. In this case, each multicast group has thus to have a separate entry in the routing tables of the intermediate routers, and if the number of these groups grows large, as in the case of the context-related groups in the Internet of Things, the burden on the routers will be too large and the solution will not be scalable anymore.
The 128-bit long IPv6 addresses provide an unthinkably large address space that will solve the address scarcity issues that characterized IPv4. In IPv6 there is the possibility to assign trillions of addresses to each square centimeter on the surface of the Earth, so it is hard to envision any future scenario that would necessitate a larger number of addresses. However, in certain cases, size does not matter, or at least it is not the only thing that matters. The question is rather how can you use those addresses, how large will grow the routing tables, or how fast and how efficient can be the subsequent routing protocols and communication schemes in general. In the near future there will be a very large number of "smart" devices around us. Let's just take the example of sensors embedded in the walls, the pavements and our clothes, or all the electric devices from our home, our office or in the city streets. Giving a unique IPv6 identifier to all these "things" will not be a problem, as we mentioned above. However, we will probably very rarely use those addresses as is, as we will not address for example a given sensor individually, but rather a group of sensors, or a group of smart "things" in general, the elements of this group having in common some context-related characteristics.
W hat we want to explore instead is the possibility to use Bloom filters to define context-aware groups in the loT. A Bloom filter is a space-efficient probabilistic data structure that can be used to test whether a given element is a member of a set or not. BFs were widely used in database applications since the 1970 ' s, but in the last decade they became important in the networking literature as well [4]. W ith BFs, false positives are possible, but false negatives are not. If we want to use them for multicasting this means that packets might be also directed in areas with no valid group members, but all the members will be ensured to receive the multicast data. The false positives might correspond thus to unnecessary messages being sent over certain network links, but on the other hand the multicast group information can be stored in a much more scalable way in the routers.
In the Internet of Things of the future, all the intelligent devices will be characterized by a context that can contain an undefined number of parameters: who is the owner of the device, what is its absolute and/or relative location, who are its neighbors, what is the status of its battery, what kind of communication technologies it supports (Zigbee, Bluetooth, W iFi, 3G, etc.), what is its moving speed, what kind of
In the next section we present in more details the operation of Bloom filters. In this paper we do not propose any novelty to the theory of BFs as such, but rather a new possible application area of these filters. However, we thought that a brief
488
Cog l nfoCom 2013• 4th I E E E I ntern ational Conference on Cogn itive I nfoco m m u n ications
introduction on the general theory of these filters is useful for those not familiar with this area, to understand the proposed approach. III .
BLOOM FILTERS
In order to determine the probability of false positives based on the parameters k, Ill, and n, we assume the following criteria: . k x n < In; • hash functions select each array position with equal probability. After all elements x of S are mapped into the BF, the probability that a specific bit is still 0 is: p' =
Elements can be easily added to the set, but the added elements cannot be removed. (However, this issue can be solved by using counting Bloom filters, as we explain later). As the number of the added elements increases , the probability of the false positives becomes larger.
kxn � e
- �n
k.>m 1 1 - 1 - -:;;J,t"'" � 1 - e--.n
-
(
In order to determine the probability of a false positive, we test the membership of an element that is not in the set. Each of the k array positions (identical to the random numbers) computed by the hash functions is 1 with a probability as above. Thus, the probability that all of them are 1 (which would mean that this element is in the set) is [5]:
A set S {x I , Xz, . . , xn } can be represented as a so-called B loom filter by mapping each of its elements to an m bit long array, in which every bit is set to 0 at the beginning. This mapping procedure is done by using k independent hash functions h J , . . , hk• Each of these has functions has a range {I, . . . m} and they map each item of S to a random number, uniformly in this range. ,
1 _
( �)
Therefore, the probability that a specific bit is 1 is:
Theory of Bloom filter s
.
=
December 2-5, 2013 , Bud apest, H u ngary
is not. In the application areas where BFs are used the false positives can be acceptable if their probability is sufficiently low (what "sufficiently" means depends on the requirements of the specific applications).
A Bloom filter is a data structure designed to answer the following simple question rapidly and in a memory-efficient way: does a set contain a specific element, or not? The price of the efficiency is the probabilistic nature of the structure: it tells us that the element either is definitely not in the set, or it may be in the set. In other words, it allows false positives, but the space savings often worth this drawback, especially when the probability of an error is low enough.
A
•
..
( 1 - (1 - ;�rxnr (1 -� ) �
_
e
xn
k
A nice property of BFs is that the union function of set theory can be easily implemented with them. For instance, if we have two BFs representing sets SI and S2, with the same number of bits and with the same hash functions, then a B F that represents the union o f the two sets can be created by taking the OR of the two bit vectors of the original BFs. X
4
Fig. l . An example of a B loom filter. The Xj , .. ,X3 elements are " into the m-bit long binary array, while � is not contained
" mapped
by the array
To be more specific, for each element of S (x) (x e S) , the hash functions hj(x) ( l ::s i ::s k) assign k random numbers. After this, in the m-bit long array those bit positions which are identical to these random numbers are set to 1. B its in different positions can be set to 1 several times; however, only the first modification has an effect. If we are interested in whether an element y is included in the set S or not, we use the hash functions hj(x) ( l ::s i ::s k) to assign k random numbers to y and then we check these bit positions in the BF. If any of them is not set to 1 , then y is definitely not included in S. If all of the bits are set to 1, Y is probably included in S, but there is a non-zero probability that it is still not. We call this case a false positive, which means that a BF suggests that an element y is in set S, even though it
F i g . 2 . T h e false positive probability p as a function of t h e number o f elements n inserted into the filter. F o r k, the optimal number of hash functions k= (mln)*ln 2 i s used [4]
489
A. Kalmar et al.
IV.
A
U
•
Context-aware Add ressi n g in the I nternet of T h i n g s using Bloom Fi lters
S ING
B
F LOOM ILTERS FOR C ONTEXT- AwARE ADDRESS ING
the assigned bit in the bit-vector is set. Analogously, when a counter changes from one to zero, the corresponding bit in the bit-vector is set to O. However, when the counter value is incremented or decremented from a non-zero value to another non-zero value, the bit array is not modified. In the bit array every bit represents one of the context categories. (For instance if we classify the status of the battery into three categories (low, medium, high) then the first bit may represent the low category, the second the medium category and so on.
Communication at the edge of the loT domain
According to the loT vision, most of the objects in the loT domain will be low capacity devices, regarding their energy supplies, processing and communication capabilities. From a communication perspective we should therefore send and receive as few messages as possible to and from these devices. Moreover, these messages should be as short as possible, in order to ensure a long lifetime. As BFs are space-efficient data structures, they can be an optimal solution for the latter aspect.
The bit array and the counter array are used to aggregate the context information of all the loT objects that are connected to the Internet through the same edge-node. In this sense, these nodes are very similar to multicast routers that store up-to-date information about the multicast groups their directly connected local nodes wish to follow. However, the way this information is refreshed is very different, and rightly so.
We assume that every loT object will have a default Bloom filter with predefined parameters and hash functions. This filter is used to represent the current context of the object. Some of the context parameters have a low number of discrete possible values; e.g., the type of the operating system, or the screen resolution (assuming the device does have a screen which is another context parameter that can be described with a Boolean variable). On the other hand, some of the context parameters have a continuous value range. For these parameters, a limited number of discrete intervals (categories) on the value range have to be set.
At this point we have to differentiate two types of loT objects:
Take for example the case of the battery status. If we classify its values into three categories (low, medium, high), then these categories can be easily mapped into a Bloom filter. Long BFs will represent however a significant burden to the resource-constrained loT devices. Therefore, the length of the Bloom filter should be defined according to the maximum number of elements, which can be inserted (i.e., the number of the context parameters) and the induced resource consumption of the loT objects.
•
objects of the first type (type1) possess large and re chargeable batteries and most of them are mobile (smartphones, tablets, cars, laptops, etc . . . )
•
objects of the second type (type2) have small and/or non-rechargeable energy supplies. Therefore, it is important to provide them a long life time. Usually these objects are very static from the mobility point of view.
In the case of the loT edge nodes, every connected object sends its context information to them when:
The current context parameter states of an loT object are hashed into its BF, and this filter is kept up-to-date all the time. Thus, if one of the context parameters changes - for instance the state of the battery is changed from high to medium - then the BF is recalculated from scratch. If we assume that most of the context parameters of a device will never change (e.g., its screen resolution, operating system, or even its location - in case of a wall-mounted sensor for example) and that calculating the hash functions and the resulting BF is a very fast and resource-sparing operation, than these seldom updates will not put a significant burden on the loT devices.
•
an loT object connects for the first time through an edge node (when it is turned on for example);
•
its own BF is recalculated from scratch(because at least one of its context parameters was changed recently)
•
or it performs a handoff to an edge-node with a better signal strength (for instance because its mobility).
In the first case a type1 loT object sends its context data in a key-value pair message, while a type2 object sends it by using a Default Bloom Filter (DBF). The edge-node integrates this message - whatever type it is - into its counter array. The integration process means it extracts the context categories from the message, and it increments the proper counter values. The extraction is trivial from the key-value pair message; for the message containing the DBF it has to query most of the possible categories. (Not all of them, because for instance if a query for a battery status category gives a positive result, then we do not have to query the other battery status categories anymore. The same stands for all the other context parameters. )
On the other hand, the most important question to answer is how can be the context data aggregated, spread and kept updated in the network, so as to let the interested users and applications know what kind of objects are available in the different parts of the loT domain. Most of these objects will communicate in wireless manner, and will reach the Internet through a WiFi access point or a mobile base station. In the following we will call these attachment points "edge nodes". These edge-nodes will maintain a simple bit array (BA) and a counter array (CA) with the same size. These are linked to each other. W hen a counter value changes from zero to one,
In the second case, when the context information of an loT objects changes, the object sends the former and the new states of the changed context parameter (only). This is done with a key-value pair message (KVM), independently of the type of
490
Cog l nfoCom 2013• 4th I E E E I ntern ational Conference on Cogn itive I nfoco m m u n ications
the loT object. The edge-node decreases the proper counter value according to the former state and increases another counter value according to the new state.
•
December 2-5, 2013 , Bud apest, H u ngary
multicast tree, and will attract that multicast flow to the local network. Consequently, a procedure called host suppression is used by the MLD (Multicast Listener Discovery) protocol [9] to reduce the redundant traffic in the network; if one of the local nodes announces its interest in a given group, all the other local nodes interested in the same group will suppress their reports, as they would be worthless to send - the router will subscribe anyhow to the group. This host suppression has however the drawback that the local multicast router will not know how many interested receivers are present, making the accounting and charging process also a lot harder. Therefore, most of the implementations disable the host suppression on the host side and implement counters on the router side, even though this is not required by the MLD standards.
Finally, in the third case, if the handoff can be foreseen in advance (by a continuously decreasing signal strength towards the old edge-node and a continuously increasing signal strength towards the new edge), a Delete operation is performed at the old node and an Add operation at the new one. If the old connection is broken instead suddenly, due to a network failure for example, then the old edge-node should be alerted through the new edge about the changed situation, in order to perform the Delete operation. In this case, similarly to the first one, the two different types of loT objects send different types of messages.
B.
W ith this communication process between the loT objects and the edge-nodes, we can say that most of the time the bit arrays of the edge-nodes represent the aggregated context information of those loT objects which are connected to the Internet through them in the current moment. W hy aren't we using Bloom filters in the edge nodes instead of the simple bit array? Because Bloom filters are efficient when we would like to represent randomly a small subset of elements from a much larger set . As the edge nodes handle aggregated context information, such an aggregated Bloom filter has to contain a large number of possible context parameter categories, which would make its false positive rate unacceptably high. Moreover, the context information stored in the edge-nodes will be aggregated further, as described in the next section. This would make the use of Bloom filters even less efficient.
Communication scheme inside the network
We can say that the previously defined edge-nodes can be considered as border nodes between the wireless and the wired part of the access network. We showed that the bit arrays of these edge nodes represent the aggregated context information of the loT objects connected to them currently. However, our aim is to propose a communication scheme that supports context-aware addressing at a wider level, making the routing process simpler and more efficient inside the entire network, or at least at the level of a given Autonomous System (AS). Let us suppose that a context-aware addressing request arrives to a central server of the AS - wishing to get in contact for example with all the sensors from the city that measured today a temperature above 25 C and have a high battery life. The request should b e forwarded just t o those areas o f the network where there is at least one loT object which fulfills the conditions of the request. Each intermediate router in the AS will have to know for each of its outgoing interfaces whether it is worth forwarding the request on that interface or not, i.e., a routing decision should be made. Bit arrays should be used again to facilitate that decision. In the case a request reaches an edge node, the node creates a Bloom filter according to the request. This BF will be broadcasted to every loT object assigned to this edge node. After receiving it, the objects compare this BF with their own filter, and if they are identical, the objects build up a connection with the user or the application which created the request. .
Obviously, one of the major advantages of using counter arrays in the edge-nodes is that if one of the context parameters of a given attached loT node is changed, then only that node should send a message about this change to the edge. Otherwise, if a counter array would not be used all the objects attached to that edge-node should send a message to that node, which would put an unnecessary burden on their scarce resources. Note that this operation mode corresponds to the traditional hard-state operation, when state information is updated only through explicit messages (e.g., a node is added to a group only following an explicit Join message, and it deleted only upon an explicit Leave message). However, most of the communication protocols in the traditional Internet are soft state, i.e., state information is linked to timers, and it dies out if not refreshed periodically. IP multicast operates in this way, both at the level of the local network, where soft-state group management protocols are used, and the level of the global network, where soft-state multicast routing protocols are predominant.
We propose therefore to create in every AS a spanning tree, rooted at a central server. In this tree the leaves will be the edge nodes inside the AS to which loT objects are connected. Every edge node maintains a bit array (BA) synchronously with its counter array (CA). By applying the OR operation on the bit arrays of neighboring edge nodes, the BF information can be spread upwards in the hierarchy, reaching eventually the central server. Intermediate nodes will only maintain bit arrays, as explained later.
Finally, it is interesting to note also that that a concept similar to the counter arrays is also used in traditional IP multicast, although not in a standardized way. In IP multicast the multicast router in the local network is only interested to know whether a specific group has at least one subscriber in its network, or not. If it does, it will join the corresponding
To illustrate this, take a look at Fig. 2. In this picture a simple spanning tree can be seen. Node F is the root of this tree, while A, B and C represent edge nodes. At the bottom of the figure we see the loT domain, including different objects
491
A. Kalmar et al.
•
Context-aware Add ressi n g in the I nternet of T h i n g s using Bloom Fi lters
the approach, and show its feasibility on a simple, proof-of concept example. However, there is a long way to go in order to analyze also its efficiency on topologies of arbitrary sizes, with a large number of nodes.
(sensors, smartphones, vehicles, home entertainment applian ces, etc.) connected to these edge nodes.
Another topic for future work is the handling of context parameters that have a nearly infinite value range; the most prominent examples are the precise geographical location (e.g., GPS coordinates) of a given object, and the identity of its owner. It is clear that we cannot represent these parameters as is in the Bloom filters, as they would require a very large number of bits. Depending on the specific needs of the applications we could use however some restricted value ranges. For example, if we are not interested in the very precise location of the object, we might give specific values only to describe given streets in a city district, and then aggregate the rest of the city in one single val ue, the rest of the country in another value, and so on. Similarly, we might have a restricted set of friends with whom we are in contact, so only these object owners will be individually represented in the user ID value range. All other people from the city might have a unique, aggregated ID, all the people from the country might have a different ID, and so on.
Fig. 3 . Aggregating context information inside an AS
Node D can be used to reach edge-nodes A and B, and thus attached loT devices described by their bloom filters. We can aggregate this information in node D by applying the OR operation to the DBFs of nodes A and B. By doing so, we will generate the (default) Bloom filter of node D. On the other hand, since node C is the only child of node E, the content of its BF can be simply copied to E. To aggregate all loT-related status information in this network, we should apply the OR operation on the BFs of nodes D and E, generating the (default) Bloom filter of node F.
As a final comment, we should also mention that this context-aware addressing scheme is not intended to replace the traditional IPv6 addressing, but rather to complement it, in case some loT applications would benefit from it. ACKNOWLEDGMENT
This work was supported partially by the TAMOP-4.2.2.C11/l/KONV-2012-000l (FIRST - Future Internet Research, Services and Technology) project. The project has been supported by the European Union, co-financed by the European Social Fund.
If a change occurs in the bit array of any of the child nodes, at any level, the new filter will be sent upwards, making the parent node to ask all its children to send their current bit array information once again. Based on these, the parent node recalculates its own bit array from scratch, and informs its own parent about it. The process continues like this until the entire tree is refreshed.
[I]
This operation has the good property that if a new set element appears somewhere at the bottom of the network topology, this information spreads quickly inside the network. However, if a set element disappears (is deleted), some Bloom filters of the network may still include this element until the refresh procedure is not finalized. This is the consequence of not using counting arrays in the higher hierarchical levels of the network topology. However, if we would use them on every level, the number of bits used for representing a counter on the higher hierarchical levels would be quite large, and maintaining the large counter array at these levels would be problematic. V.
[2]
[3]
[4] [5] [6]
[7]
C ONCLUSION AND FUTURE W ORK [8]
In this paper we presented a solution on how context aware addressing and routing can be supported in the Internet of Things. This paper intends just to describe the main idea of
[9]
492
R EFERENCES
M. Chui, M . LOfiler, R . Roberts, 'The Internet o f Things", McKinsey Quarterly, March 20 1 0. Luigi Atzori, Antonio Iera , Giacomo Morabito: The Internet of Things : " A survey" Computer Networks, Volume 54, Issue 1 5 , 28 October 2010, Pages 2787-2805. S. Paj ares Ferrando, E. Onaindia, "Context-Aware Multi-Agent Planning in Intelligent Environnlents", Elsevier Journal on Information Sciences, 227 (20 1 3), p. 22-42. Andrei Broder, Michael Mitzenmacher, "Network Applications of Bloom Filters : A Survey", Internet Mathematics Vol. 1, NO. 4: 485 -509 Compressed Bloom Filters", in IEEE!ACM M. Mitzenmacher, " Transactions on Networking 1 0 : 5 (2002), 604---6 1 2 1. Fan, P. Cao, J. Almeida, and A. Z. Broder. "Summary Cache: A Scalable Wide-Area Web Cache Sharing Protocol." IEEE!ACM Transactions on Networking 8 : 3 (2000), 2 8 1 -293 Gerd Kortuem, Fahim Kawsar, Daniel Fitton, Vasughi Sundramoorthy, Smart Obj ects as Building Blocks for the Internet of Things", IEEE " Internet Computing - Internet of Things Track, 20 1 0, January February, p. 30-37 Dharmapurikar, Sarang, et al. "Deep packet inspection using parallel Bloom filters . " High Performance Interconnects, 2003. Proceedings. 1 1 th Symposium on. IEEE, 2003. R. Vida, L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", IETF RFC 3 8 1 0, June 2004.
