MAX human centric searching of the physical world

MAX HUMAN-CENTRIC SEARCHING OF THE PHYSICAL WORLD YAP KOK KIONG NATIONAL UNIVERSITY OF SINGAPORE 2006 MAX HUMAN-CENTRIC SEARCHING OF THE PHYSICAL WORLD YAP KOK KIONG (B.Eng (Hons), NUS ) A THESIS SUBMITTED FOR THE DEGREE OF MASTER OF ENGINEERING DEPARTMENT OF ELECTRICAL & COMPUTER ENGINEERING NATIONAL UNIVERSITY OF SINGAPORE 2006 Name : Yap Kok Kiong Degree : Master of Engineering Supervisor(s) : Mehul Motani and Vikram Srinivasan Department : Department of Electrical & Computer Engineering Thesis Title : MAX Human-Centric Searching of the Physical World Abstract is a vision of searching the physical world in seconds, as we are searching the Internet today Built on the intuition that humans are powerful “sensors” that works well with landmark based information, we design the system to allow people to search for and locate objects as and when they need it, instead of organizing them a priori Location information are presented in a form natural to humans in the system, i.e., with reference to identifiable landmarks (e.g., on the dining table) rather than precise coordinates MAX was designed with three main objectives in mind: (i) humancentric operation, (ii) privacy, and (iii) efficient search of any tagged object In the system, all physical objects, from documents to clothing, can be tagged and people locate objects using an intuitive search interface In this thesis, we propose a hierarchical architecture consisting of tags (bound to objects), sub-stations (bound to landmarks) and base-stations (bound to localities), to facilitate an efficient search To optimize system performance, we present a methodology to design energy and delay optimal query protocols for a variety of device choices Also we provide privacy for the users of MAX Tags can be marked as either public or private, with private tags searchable only by the owner MAX also provides for privacy of physical spaces MAX requires minimal initial configuration, and is robust to reconfiguration of the physical space i We also present an implementation of MAX, providing search facility for the wide physical area We contend that a MAX-like search system will enable sharing (e.g., books on a college campus) and trading (e.g., buying and selling used books) of physical resources, and will be the engine for a host of new applications It is our thesis that the ability to efficiently search the physical world through MAX will provide unprecedented convenience to people Keywords : MAX, human-centric, sensor networks, search, optimal protocols ii Acknowledgment I would like to express gratitude for my supervisors, Dr Mehul Motani and Dr Vikram Srinivasan for their guidance, advices and support through these years The opportunities and recognition given by them has also been an important motivation for me during the course of research This thesis would not be possible without their ideas and contributions I would also like to express my appreciation for the work done by Huang Limei, Philip Lim Chern Sia and Tran Trong Tri Their hard work in developing the prototypes provided much experience for the development of MAX-Sesshoumaru I would also like to thank Yu Sern Hong for his artwork being used as the logo for MAX-Sesshoumaru Special thanks goes to Dr Tham Chen Khong, Yeow Wai Leong, Rob Hoes, Hoang Anh Tuan, Vineet Srivastava, Lawrence Ong Lee Chong, Chong Hon Fah, Wang Wei, Lim Yang Cherng and William Low for everything they have done for me and my work What I have done during the pursuit of this degree would not be possible with the concern and support given to me by my wife, Wang Huiyi Serene For this, I cannot say enough thanks I would also like to acknowledge the sponsorship from National University of Singapore under the Research Scholarship scheme Last but not least, I would like to thank anyone I have failed to mention here, that have made this work possible December 6, 2006 iii Contents Introduction 1.1 Searching the Physical World 1.2 Contributions 1.3 Organization of Thesis Literature Survey 2.1 Location Tracking Technologies 2.1.1 Localization 2.1.2 Urban Location Tracking 2.1.3 Radio Frequencies Identification Device Systems Smart Spaces 2.2.1 Location Support System 2.3 Location Aware Computing 2.4 Sensor Database 2.2 Architecture and Design 3.1 3.2 3.3 11 System Architecture in a Locality 11 3.1.1 Entities of the Architecture 12 Network Wide Architecture 15 3.2.1 Functions of Various Entities 17 System Operation 18 Optimal Query Protocols 4.1 4.2 20 Methodology 20 4.1.1 System Model 20 4.1.2 Illustration of System Model 22 Optimal Protocols 23 4.2.1 25 Parameters of Optimization iv 4.2.2 4.3 Results of Optimization 25 Design Choices 28 4.3.1 Customized versus Commercial Off-The-Shelf Tags 30 4.3.2 Distribution of Computational Burden 33 4.3.3 Maximally Relevant Result 35 4.3.4 Coverage – Degree of Overlap 36 4.3.5 Scalability – Number of Tags 37 Object and Space Privacy 5.1 5.2 5.3 39 Object Privacy 40 5.1.1 Cryptography for Object Privacy 40 5.1.2 Elliptic Curve Cryptography 41 Space Privacy 41 5.2.1 Notion of Private Spaces 42 5.2.2 Mechanism for Space Privacy 43 5.2.3 Privacy over the Wireless Channel 44 Summary of Privacy 44 Implementation – Sesshoumaru 6.1 47 MAX in a Locality 48 6.1.1 Tags 48 6.1.2 Sub-Station 49 6.1.3 Communication 51 6.2 Wide Area Search 51 6.3 Privacy 53 6.3.1 Secure Sockets Layer in Java 53 6.3.2 Elliptic Curve Cryptography in Java 54 What We Have Done 54 6.4 Reflections, Future Work and Conclusion 7.1 56 Reflections 56 7.1.1 RSSI is a Good Indicator of Proximity 56 7.1.2 Landmark Based Localization is Enough 57 7.1.3 Importance of Reliable Communication 57 7.1.4 Privacy is an Intrinsic Part of a System 58 7.2 Future Work 58 7.3 Conclusion 59 v A List of Publications 64 B List of Optimal Protocols 65 C MAXSesshourmaru – TinyOS Components 70 C.1 Tags 70 C.1.1 ReliableComm 70 C.1.2 SingleDescriptor 72 C.1.3 Query 72 C.2 Sub-Station 73 C.2.1 Inventory 73 C.2.2 Descriptor 74 C.3 Administrative Components 74 C.3.1 Radio433 74 C.3.2 ObjectId 75 C.3.3 NoQuery and NoDescriptorM 75 D MAXSesshourmaru – Java Components 76 D.1 MAX Server 76 D.2 Base Station 77 D.3 Query Terminal 77 D.4 Miscellaneous Components 79 vi List of Figures 3.1 Three-tiered Architecture of MAX in a Locality – The Base Station (BS) of the locality is connected to the various SubStation (SS), which in turns communicate with the tags to provide an efficient search within the locality 3.2 13 Architecture of MAX over the Backbone Network – An user in the system is co-located with the Query Terminal (QT) The QT communicates with the MAX Server (MS), and subsequently the localities The architecture at each locality is outlined For details, one can refer to Fig 3.1 One should note the background communication between the MS and localities 3.3 16 Screen Shot of a Browser accessing MAX-Sesshoumaru Search Engine 18 4.1 State and Graph Forming Algorithm 24 4.2 Graph yield for sample problem using algorithm described – The costless action a0 is shown in gray, while the other actions are described in Table 4.2 The primitive states are separately described in Table 4.1 4.3 24 Smart Tags to Dumb Tags – Both energy consumption and latency increases when the tags are disallowed from calculating and transmitting their match count 4.4 32 Centralized Decision to Distributed Decision – When the SS in a high overlap system are disallowed from deciding which results are to be returned, the energy consumed decreases slightly while the delay is decreased significantly vii 34 4.5 Heuristic Result to Maximally Relevant Result – To ensure maximally relevant results, the energy consumed increases slightly but the latency increases drastically 4.6 35 Increasing Degree of Overlap – Both energy consumption and latency increases with increased overlap, especially significant in systems using dumb tags 36 4.7 Scalability – Effects of increasing number of tags 38 5.1 Security Features within the MAX Architecture – An user in the system is co-located with the Query Terminal (QT), thus it is the “digital user” that communicates with the MAX Server (MS) and Base Station (BS) to perform a query 6.1 45 Connection Diagram for Tag – Connection diagrams for the sub-components can be found in Appendix C Section C.1 and Section C.3 6.2 49 Connection Diagram for Sub-Station – Connection diagrams for the sub-components can be found in Appendix C Section C.2 and Section C.3 6.3 50 Structure TinyOS Packet used – where the size of each part (in bytes) is indicated below the message Length refers to length of the payload WORD LENGTH and INVENTORY SIZE are constants defined in the applications, taking default values of 26 and 10 respectively Details can be found in [1] 52 6.4 Interactions between entities in a Wide Area Search 52 6.5 Background Processes Running for MAX – (i) MAX Server running and processing requests; (ii) SerialForwarder to access TOSBase; and (iii) the Base Station processing a user query 55 C.1 Connection Diagram for ReliableComm 71 C.2 Connection Diagram for SingleDescriptor 72 C.3 Connection Diagram for Query 73 C.4 Connection Diagram for Inventory 73 C.5 Connection Diagram for Descriptor 74 C.6 Connection Diagram for Radio433 74 D.1 Java Components used in MAX Server 77 viii Appendix B List of Optimal Protocols Protocol A 10 11 12 13 14 15 Substations perform inventory Query terminal queries base station Base Station sends query statment Substations send query for all descriptors Tags all reply Substations calculate match-count from descriptors Substations calculate match count vector Substations send match count vector Base Station sums all match count vectors Base Station decides approximated global match count Base Station sends globally decided approximate match count Substations filter for selected tag ids based on global approximate estimate Substations filter descriptors for globally selected ones (approx-match) Substations send globally selected tag descriptors (approx-match) Base Station filters sum of globally approximated tag descriptors 65 Protocol B 10 11 12 13 14 Substations perform inventory Query terminal queries base station Base Station sends query statment Substations send query for all descriptors Tags all reply Substations calculate match-count from descriptors Substations replies all match count-ids Base Station filters match count-ids pairs Base Station calculates net match count vector Base Station decided global accurate match count Base Station filters for globally selected tag ids Base Station send globally selected tag ids Substations filter descriptors for globally selected ones (accurate) Substations send globally selected tag descriptors (accurate) Protocol C 10 11 12 13 14 15 16 Substations perform inventory Query terminal queries base station Base Station sends query statment Substations send query statement Tags calculate match count Tags reply match count-id values Substations calculate match count vector Substations send match count vector Base Station sums all match count vectors Base Station decides approximated global match count Base Station sends globally decided approximate match count Substations filter for selected tag ids based on global approximate estimate Substations send query by globally selected ids (approx-match) Tags reply based on globally approximated selection (match) Substations send globally selected tag descriptors (approx-match) Base Station filters sum of globally approximated tag descriptors 66 Protocol D 10 11 12 13 14 15 Substations perform inventory Query terminal queries base station Base Station sends query statment Substations send query statement Tags calculate match count Tags reply match count-id values Substations replies all match count-ids Base Station filters match count-ids pairs Base Station calculates net match count vector Base Station decided global accurate match count Base Station filters for globally selected tag ids Base Station send globally selected tag ids Substations send query by globally selected ids (accurate) Tags send descriptors of globally selected ids (accurate) Substations send globally selected tag descriptors (accurate) Protocol E 10 11 12 13 14 15 Substations perform inventory Query terminal queries base station Base Station sends query statment Substations send query for all descriptors Tags all reply Substations calculate match-count from descriptors Substations calculate match count vector Substations calculate local match count Substations send locally decided match count Base Station approximates match count based on local ones Base Station sends globally decided approximate match count Substations filter for selected tag ids based on global approximate estimate Substations filter descriptors for globally selected ones (approx-match) Substations send globally selected tag descriptors (approx-match) Base Station filters sum of globally approximated tag descriptors 67 Protocol F 10 11 12 13 14 15 16 17 Substations perform inventory Query terminal queries base station Base Station sends query statment Substations send query statement Tags calculate match count Tags reply match count-id values Substations calculate match count vector Substations calculate local match count Substations filter for locally selected tags Substations send match count-id of locally selected tags Base Station filters locally selected tag match count-ids Base Station decides match count based on locally selected match-count ids Base Station filters locally selected match count-id for global approximate Base Station sends match count-id of globally selected tags (approx) Substations send query by globally selected ids (approx-id) Tags reply based on globally approximated selection (id) Substations send globally selected tag descriptors (approx-id) Protocol G 10 11 12 13 14 15 16 Substations perform inventory Query terminal queries base station Base Station sends query statment Substations send query statement Tags calculate match count Tags reply match count-id values Substations calculate match count vector Substations calculate local match count Substations send locally decided match count Base Station approximates match count based on local ones Base Station sends globally decided approximate match count Substations filter for selected tag ids based on global approximate estimate Substations send query by globally selected ids (approx-match) Tags reply based on globally approximated selection (match) Substations send globally selected tag descriptors (approx-match) Base Station filters sum of globally approximated tag descriptors 68 Protocol H 10 11 12 13 14 15 16 Substations perform inventory Query terminal queries base station Base Station sends query statment Substations send query for all descriptors Tags all reply Substations calculate match-count from descriptors Substations calculate match count vector Substations calculate local match count Substations filter for locally selected tags Substations send match count-id of locally selected tags Base Station filters locally selected tag match count-ids Base Station decides match count based on locally selected match-count ids Base Station filters locally selected match count-id for global approximate Base Station sends match count-id of globally selected tags (approx) Substations filter descriptors for globally selected ones (approx-id) Substations send globally selected tag descriptors (approx-id) Protocol I 10 11 12 13 14 15 16 17 Substations perform inventory Query terminal queries base station Base Station sends query statment Substations send query for all descriptors Tags all reply Substations calculate match-count from descriptors Substations calculate match count vector Substations replies all match count-ids Base Station filters match count-ids pairs Base Station calculates net match count vector Base Station decided global accurate match count Substations calculate local match count Substations filter for locally selected tags Substations filter descriptors for locally selected ones Substations send descriptors of locally selected tags Base Station filters locally selected tag descriptors Base Station filters for global approximate descriptors using match count (accurate) 69 Appendix C MAXSesshourmaru – TinyOS Components This appendix provides technical details of the implementation in TOS The design choices made during the development is also being justified and discussed C.1 Tags We will now discuss some of the components developed to implement the tags These components are later modified and extended to implement the SS C.1.1 ReliableComm The ReliableComm component provides reliable communication via extending the GenericComm1 in TOS distribution The reliability is provisioned by explicit acknowledgment packets for each unicast Acknowledgment packets are sent via broadcast, thus allowing for the original message structure of TOS to be retained Reliability for broadcast is not being provided, for complexity issue The connection diagram is shown in Fig C.1 The MoteIF Java class is also being overloaded by RMoteIF, to provide communication that is compatible with ReliableComm Details of RMoteIF ReliableComm extends GenericComm, providing the same parameterized interface The author failed to locate any reference on the manner to connect paramterised interfaces, and has done so through trial and error Interested reader may contact the author for the source code 70 Figure C.1: Connection Diagram for ReliableComm is referred to Section D.2 Retransmission Interval The retransmission interval should be at least the time needed for a transmission and its acknowledgment to be replied Figures will be extracted from [1] T OS OS Maximum transmission duration of packet, Pmax = LTmax ∗ 8/RT OS = ∗ (29 + + 18)/(38.4 × 103 ) = 11.25 ms, (C.1) OS consists of 29 bytes of payload, bytes of header and 18 bytes where LTmax of preamble; and RT OS = 38.4 kbps T OS OS Time duration of acknowledgment, Pack = LTack ∗ 8/RT OS = ∗ (3 + + 18)/(38.4 × 103 ) ≈ 10.4 ms, (C.2) OS consists of what LT OS has except that the payload is bytes since LTack max T OS T OS Maximum duration for reliable transmission = Pmax ∗ (15 + 15 + 1) + Pack ≈ 359.15 ms, (C.3) which includes a random delay of up to 15 transmission duration for each transmission initiated Thus, we set the retransmission interval to be about four times of this maximum interval, allowing for processing delay and for the contention in the wireless channel to “pass” It should be noted that most transmissions 71 Figure C.2: Connection Diagram for SingleDescriptor will not take this long, given that they will be completed by the reception of an acknowledgment C.1.2 SingleDescriptor We hold the descriptor of a tag using the SingleDescriptor component The component also provides interfaces to store the descriptor into the nonvolatile EEPROM2 and retrieve it The component used is the PageEEPROMC, after attempts to use Matchbox and ByteEEPROM results in loss of data after power-cycle We show the connection diagram in Fig C.2 Word Number and Length The number of words and the length of each word is a design parameter in the SingleDescriptor Each page in the EEPROM is 264 bytes long With a byte being used to store the number of words in the descriptor, we have 263 bytes left for the descriptor The number of words is thus set at 10, with each word being at most 25 bytes long3 , giving 261 bytes which is within the limit Delayed Startup The descriptor of the tag is being retrieved from the EEPROM at startup However, it is necessary for the components to initialize properly before this can be done Thus, the retrieval at startup is delayed by an arbitrary second when the Tag component is initialized C.1.3 Query The Query component stores a query descriptor that can be compared to tag descriptor The connection diagram is as shown in Fig C.3, with the connection to the SingleDescriptor to read the descriptor, is shown in Fig 6.1 We caution the reader that the hardware is really a flash memory, not an EEPROM Character array has to be terminated by the null character for the string functions to work properly 72 Figure C.3: Connection Diagram for Query Figure C.4: Connection Diagram for Inventory The number of words and maximum length of each word for the query descriptor is the same as SingleDescriptor, described in Section C.1.2 Comparison of Strings The strstr function is used to compare the descriptor with the query words This function allows for sub-strings to return a match, unlike the strcmp function It is worthwhile to mention that duplicate of words in the descriptor and query is not being performed This task is left to the BS, if required C.2 Sub-Station Having established the functionalities of the tags, we have established a major portion of code required for the SS By careful planning, we have allowed for code reuse and thus there is only two other components used by the SS left to be described C.2.1 Inventory Inventory is used to maintain the identity, RSSI and match count of the tags around the SS The connection diagram is shown in Fig C.4 We have chosen to maintain a list of 10 tags, given the limited memory and high overlap of the system 73 Figure C.5: Connection Diagram for Descriptor Figure C.6: Connection Diagram for Radio433 C.2.2 Descriptor Descriptor can be thought of as a reduced form of SingleDescriptor Its necessity is due to the singleton nature of TOS [29], disallowing the reuse of SingleDescriptor Thus, the component has a connection diagram shown in Fig C.5 Its sole function is to store the descriptor of tags in transit to the BS C.3 Administrative Components Finally due to administrative needs, we have provided several components They are outlined in the following for completeness C.3.1 Radio433 The Radio433 provide power control of the CC1000 radio, with communication messages over the radio The component will store the power setting the EEPROM The value then be retrieved upon initialization and set for the radio The connection diagram is as shown in Fig C.6 74 Independent Communication The communication for Radio433 is en- capsulated in the component itself, i.e., separated from the main application, to allow for clarity of the application code Again, ReliableComm is used to provide reliability of these control packets C.3.2 ObjectId The ObjectId object4 is necessary, since both tags and SS are done using similar hardware Thus the component provides an identity for each type, helping to differentiate them As a result, code reuse is made possible C.3.3 NoQuery and NoDescriptorM Both of the above mentioned components are provided to allow the reuse of Query in the SS Thus, all the appropriate interfaces of Query and SingleDescriptor are respectively provided ObjectId is a simple example of providing parameterized interface Interested readers can refer to its source code, available by request 75 Appendix D MAXSesshourmaru – Java Components This appendix provides technical details of the implementation in Java The design choices made during the development is also being justified and discussed D.1 MAX Server The MAX Server (MS) is a multi-threaded server, accepting SSL connections at port 1304 Its outline is shown in Fig D.1 From the figure, it can be seen that the MS is a multi-threaded SSLServer To complete its task, the MS access the list of users, their keys and password hashes through the Authenticator The passwords of the users are hashed using RSA Data Security MD5 Message-Digest Algorithm (MD5) and are only stored in their hashed form for security reasons The JECC keys are also stored in the same file A list of BS is also maintained in the memory This list is created through communcation with the BS The list serves as an lookup table for queries for QT While the role of the MS may be greater in an actual commercial system, we have minimized its function in the implementation due to the scale of our deployment At the same time, we not rule out the possibility of building MAX using a peer-to-peer system as backbone Therefore, the use of a centralized entity like the MS is minimized 76 max.security.ssl.SSLServer Connections from Query Terminals max.applications.server.Server (instance of max.comms.SocketMessageProcessor) Port 1304 max.applications.server.Authenticator MAX Users Connections from Base Stations List of Base Stations max.security.jecc.ECCSystem Port 1304 Figure D.1: Java Components used in MAX Server D.2 Base Station The Base Station (BS) is again a multi-threaded SSLServer, accepting connections at port 2603 Connections are accepted from QT, providing the query of a locality Meanwhile, SSL are made to the MS, for authentication of users and status reporting The various classes used are illustrated in Fig D.2 We note that the query authentication is handled by Authenticator, which will ensure that space privacy discussed in Section 5.2 However, we note that the user is also being authenticated using JECC, in which involves communication with the MS to retrieve the public key associated with the user Finally, the main function of the BS is delivered by QueryProcessor, which communicates with the BaseStation BaseStation in turn connects to SS through RMoteIF and a mote installed with TOSBase D.3 Query Terminal The Query Terminal (QT) is a lightweight, platform independent program that resides in the user’s device It connects to the MS and BS via SSL channels Fig D.3 presents a simple outline to represents its internal components We note that the QT can be presented in the form of a website, in which user can log in and search their spaces Alternatively, the search is defaulted 77 max.security.ssl.SSLServer Connections from Query max.applications.basestation.BSServer (instance of max.comms.SocketMessageProcessor) Terminals Port 2603 max.applications.basestation.BSComms max.security.ssl.SSLClient Connections to MAX Server max.applications.basestation.QueryProcessor max.applications.basestation.BaseStation max.tosmessage.RMoteIF TOSBase max.applications.basestation.Authenticator Figure D.2: Java Components used in Base Station max.applications.client.Client max.security.ssl.SSLClient Connections to Base Stations Port 2603 Connections to MAX Server Port 1304 User Information List of Base Stations Figure D.3: Java Components used in Query Terminal 78 to public spaces This will provide the equivalence of Internet search engine for the physical world This is the format we have chosen for the prototype A screen shot of the search engine running in a browser is shown in Fig 3.3 D.4 Miscellaneous Components There are other supporting Java classes that have been left out due to space constraint An appropriate starting point would be the class in the max.applications package Interested reader should note that the functions of programming the tags and SS are provided for in Writer It also allows control of transmit power, through Radio433 79 [...]... Specifically, the base-station could first transmit the query to the SS who in turn transmit 18 it to the tags The tags whose descriptors match one or more of the query words respond to the BS, through the SS The SS also compute the Received Signal Strength Indicator (RSSI) of these responses, and report them to the base-station The user then sees, at the query terminal, the results of the tags ranked by the. .. and design for the rest of the thesis, we will enumerate the design goals of the system here 1 MAX is short for Maxwell’s Demon, which was proposed by mathematician James Clerk Maxwell The imaginary creature is thought of to create order from disorder, allegedly violating the second law of thermodynamics 2 Human- centric Operation For MAX to be of use to the general public, the system must be simple... view is of particular interest here 1.1 Searching the Physical World It is the thesis of this dissertation that the ability to efficiently search the physical world will allow greater convenience to the current society This will allow humans to be more “disorganized” with their belongings without any loss of efficiency in finding them Hence we propose MAX1 , a system that allows information of a “chaotic”... the representative of the locality it is associated with Thus, for the location provided by the user or QT to make sense, the BS must provide similar information that is comparable Having said that, the function of processing query remains as the core function of the BS 17 Figure 3.3: Screen Shot of a Browser accessing MAX- Sesshoumaru Search Engine MAX Server (MS) is the central control entity of the. .. mechanisms of the query protocol Given the notorious nature of the wireless channel, one may be concerned by using RSSI values for estimating location We will discuss this issue and many other concerns in the rest of thesis 19 Chapter 4 Optimal Query Protocols Given the resource constraints of the devices in a locality, an efficient search within the area will be of importance to the overall efficiency of the. .. consider the resource constraints of the SS, in terms of energy Other critical design choices, such as the type of tags to use, are also of interest To perform a fair and objective comparison of these choices, we derive the optimal querying protocol within a locality We will take a look at the methodology used in the following section The problem of deriving the optimal querying protocols is then described,... is proposed This “bridge” between the physical world and the digital domain allows for efficiency, while maintaining simplicity 2 We also investigate the privacy requirements of MAX as an application From the investigation, we distill the notions of space and object privacy We then provision both forms of privacy in our system, including the new notion of privacy of physical spaces 3 A methodology for... that will be invaluable to future MAX systems 1.3 Organization of Thesis We begin the thesis with a survey of recent related work in the next chapter We proceed to describe the system architecture and design in Chapter 3 The methodology for deriving the optimal protocols and its resulting protocols are then discussed in Chapter 4 The privacy requirements of the system and the mechanism to achieve it is... determine the location of the user, if it is not provided by the user herself From the above, we can see that the primary function of the MS in a query is to maintain and provide this desired set of BS We should note that the MS can also provide another level of filtering to distill a set of BS that are most likely to provide positive response This can be done by having the MS periodically crawl the various... filter, the MS can determine the presence of the query words for the respective BS We should note that though false positive is possible with Bloom filter, it is fine as the QT would verify the list of BS provided by following up with an actual query 3.2.1 Functions of Various Entities We will now discuss in greater details the roles and functions of the various entities in the network wide architecture The ... Title : MAX Human- Centric Searching of the Physical World Abstract is a vision of searching the physical world in seconds, as we are searching the Internet today Built on the intuition that humans.. .MAX HUMAN- CENTRIC SEARCHING OF THE PHYSICAL WORLD YAP KOK KIONG (B.Eng (Hons), NUS ) A THESIS SUBMITTED FOR THE DEGREE OF MASTER OF ENGINEERING DEPARTMENT OF ELECTRICAL & COMPUTER... unnecessary This view is of particular interest here 1.1 Searching the Physical World It is the thesis of this dissertation that the ability to efficiently search the physical world will allow greater