CiComm: A Communication Protocol to Facilitate Ad Hoc Context Resources and Services Discovery

Transcription

1 CiComm: A Communication Protocol to Facilitate Ad Hoc Context Resources and Services Discovery Qi Liu and Nigel Linge Q.Liu@pgr.salford.ac.uk, N.Linge@salford.ac.uk Informatics Research Institute, University of Salford Abstract In this paper, a novel context communication protocol (CiComm) is presented in order for each device within an ad hoc network to exchange context information stored within a Context information Database (CiB). The CiComm separates the process of communication into two phases such that context attributes and service parameters can be advertised proactively and retrieved on demand. A platform containing both CiB and CiComm is constructed in the NS2 environment; the simulation results of a particular scenario are analysed demonstrating the functionality of the CiComm. The CiComm, working with/underneath the CiB module offers a new approach to the discovery of context information in an ad hoc network. Index Terms Context Awareness, Services Discovery Protocol, Mobile Ad Hoc Networks C I. INTRODUCTION ONTEXT awareness has been under development since 1990s and applied in computer science relevant research areas, e.g. Human Computing Interface (HCI), Guidance applications, Pervasive Network Computing [1 4], etc. Different approaches are presented to recognise and represent context information including profiles [3], structured tuples [5], web semantic languages such as XML, OWL and RDF [6], abstract ontology representation [7,8], etc. Ad hoc networks have identical characters to traditional wireless networks (e.g. infrastructure-less), and therefore require specific needs on context storage, maintenance and exchange; these include a generic definition and a common model for context information in each node of an ad hoc network, as well as a protocol for the communication between these nodes. In this paper, a Context Communication Protocol (CiComm) is introduced along with the context information base (CiB) module [7, 8] to construct a platform for managing and sharing of context information in an ad hoc network. The next section of this paper reviews related literature relevant to the proposed protocol. In section 3, the details of the CiComm protocol are discussed, followed by the experimental results produced using the simulation tool, NS2 [12] in section 4. A conclusion and areas of further work are presented at the end. A. Context information Base II. RELATED WORK Context information Base (CiB) is an information base designed for the containment and management of context information in Mobile Ad Hoc Networks (MANET). The concept of CiB was first presented in [7] where a CiB retrieves, maintains and provides both local context information and remote information obtained from its direct neighbours. The introduction of CiB aims to offer rich information to nodes in an ad hoc network such that more appropriate decisions can be made under certain circumstances. Figure 1 supposes that two nodes in an ad hoc network have the same applications loaded. Their behaviour will be exactly the same in response to a common event. However, based on their own CiB, these nodes can now make their own independent decisions depending upon the context in which they are operating. Applications CiB x Figure 1: Nodes with CiBs integrated [7]. CiB y Direct calls CiB-referred calls Ad Hoc Environment Within a CiB, a generic table is designed where context information is defined as parameters and organised using reference numbers. Equally, every context parameter is indexed using more than one digit separated by one or more dot marks, e.g. the parameter Time has the reference number 2.1. In this way, all context parameters will be unique from others and together form a hierarchical tree to make grouping and tracing the context information convenient. The single-table design, however, suffers from disadvantages with regard to the redundancy of the table, the size of ISBN: PGNet

2 transmitted context information, and the complexity of maintenance of the table. Two Tables are therefore designed in a refined CiB model, CiSchma and CiData [8]. The former is used to maintain the structure of the context information; while the latter is used to store particular values of the context information. The separation of values of context information from their syntax and relations reduces the seriousness of the weaknesses in the single-table design. The schemas of the two tables are shown in Table 1. TABLE I SCHEMAS OF CIDATA AND CISCHEMA Tables Fields Description CiSchema CiData Refno (PK) Name Syntax Refno (PK) Value Reference number of the context information; the primary key of the table; Name of the context information; Data type of the context information; Same as in CiSchema; Actual values of the context information; B. Services Discovery Architecture and Protocols The development of the Internet has motivated the progress of conventional network services, which now focus on the provision of shared resources from a server, involving identification (allocation of IP addresses in DHCP servers, for example), authentication, services, etc. Additionally, with the emergence of wireless networks, new network protocols, technologies and architectures on services discovery and provision have been introduced to concentrate on the relationship between services and clients, and on the process of services sharing. Jini Network Technology [9] is a representation of network technologies that provide an open network environment for creating distributed services and/or components based on JAVA and JVM environments. As one of the core services, Lookup Service is designed in the Jini technology as the registrar of other services. It gets the proxies from Jini service providers and stores them in an internal directory. When a client requires a particular service, it seeks it in all connected Lookup Services. The Lookup Service that maintains the registration of the service will reply to the client. The process of the Lookup Service is shown in the Figure 2. The service proxy (Marked as P ) in this figure represents an instance of a network service, which contains the service s attributes, its communication parameters, methods, etc. A Look-up Service is designed as a network service directory or a service proxy table, where service proxies of network services can be registered and categorised. Once a client finds the preferred service proxy in the Look-up Service, he/she downloads this proxy and communicates with the original service directly. 4 Network Service 1 P Network Client Look-up Service Figure 2: The work flow diagram of Jini Lookup Service (source: Jini [9]) A Distributed Service Discovery Protocol (DSDV) is proposed in [12] to simulate a service discovery architecture in an ad hoc network. Two phases are designed involving Backbone Management phase (BBM) and Distributed Service Discovery phase (DSD). In the BBM phase, some of the ad hoc network nodes are selected as backbone nodes which have responsibilities to maintenance of topology changes, relationship with other backbone nodes, as well as the management of a Neighbourhood information Table (NIT) and a routing table. The definition of backbone nodes designates directories for other nodes so they can register their services (as servers) or request services (as clients) during the DSD phase. Other network technologies or models for services provision being researched include an Agent Network for Bluetooth Devices (ANBD) system, which has been built, where services are regarded as the smallest entities within an ANBD framework [10]. E-government services are also adapted in an ad-hoc manner [11], through which three-tier views have been designed to separate the existing e-government services and adapt the ubiquitous government services. III. CICOMM: THE CONTEXT COMMUNICATION PROTOCOL A. Protocol Position and its Relationship to others The CiComm protocol provides a new approach to communication of context information between nodes in an ad hoc network. As shown in Figure 3, it resides in the upper data link layer providing interfaces to the CiB module and the Logic Link Control (LLC) layer only. P 3 1. Register services 2. Look-up services 3. Download proxy 4. Communication 2

3 Figure 3: position of CiB and CiComm and relation to other protocols B. Packet Format Every packet transmitted in CiComm can be divided into a packet header and packet body. The length of a packet header is fixed to 13 bytes; its structure is shown as Figure bytes IP LL CiB_src CiB_dst Flag Figure 4: Packet header of CiComm UPPER APP MAC PHY CiB CiComm Packet Body cctype bctype cftype bits CiB_src and CiB_dst are 6 bytes respectively; they are the source and destination address of the device which initially sends and receives CiComm packets. In the implementation of CiB and CiComm in NS2, MAC addresses are employed as appropriate CiB addresses; therefore both addresses, though they are in different packet headers, match to each other in certain cases. Yet, CiB addresses differ from MAC addresses. First of all, CiB addresses are the identifier of context which is integrated within ad-hoc network nodes, so any form of addressing schemes, as well as MAC addressing, can be manipulated. Furthermore, the CiB address of a particular packet does not always match to the MAC one. If a CiComm packet is forwarded, its MAC source address will be replaced with the intermediate node s, whereas the CiB source will be kept the same. Also, if context information of a neighbour in a node is distributed through UPGRADE packets, the MAC source address is taken from the node, while the CiB source address is from the neighbour. The Flag field is a byte to carry necessary attributes of a CiComm packet, shown in Table 2. Full functionalities of each type of packets will be discussed in the Operation section. - cctype: identify the frame type of CiComm packets set by 4 bits; - bctype: identify the beacon type of CiComm packets, i.e. the Beacon_HeartBeat and the Beacon_Request; - cftype: identify if a packet is directly sent by the original node, or forwarded through an intermediate node. Flag Type cctype bctype cftype C. Operations TABLE II FLAG OF CICOMM PACKETS Packets Type Hexadecimal Value BEACON 0x1000 SHARE 0x0001 REQUEST 0x0010 REPLY 0x0011 UPGRADE 0x0100 Beacon_Heart_Beat 0x01 Beacon_Request 0x10 Direct 0x01 Forward 0x10 The process of communication of context information using the CiComm protocol has two phases; the Deployment Phase and the Retrieval Phase. No strict dependencies are set on either of the phases; that is either of two phases can be started without the completion of the other one. However, partial completion of the Deployment Phase in a node can cause its neighbours to fail to retrieve values of the node because of insufficient provision of the context information. The, Beacon_RQ and SHARE packets are transmitted in the Deployment Phase. A has no packet body and is generated periodically (e.g. the interval is set to once per second in NS2). When a is received, the host checks if the transmitter has been recorded in the local CiB; a Beacon_RQ will be replied if it has not. Once a Beacon_RQ packet is received, a SHARE packet containing all local context information and those of registered neighbours will be sent. By the end of Deployment Phase, each node will receive its active neighbour s sharing information. The Retrieval Phase aims to get exact values of particular context information from specified nodes and to then distribute this to other nodes. A REQUEST packet is generated to acquire detailed context information. In NS2, this enquiry can be raised by a Tcl script, an upper application or a random code based on the content of the local CiB. A REPLY packet is then generated with the requested value. The reception of the REPLY packet will update the CiB and generate UPGRADE packets to the nodes other neighbours. Figure 5 depicts a scenario in which two nodes have their context information deployed, retrieved and upgraded by a third node. Although the nodes are started and prepared at different times, the timeout interval ensures neighbours can hear from the host in time so as to start the Deployment Phase. In the Retrieval Phase, node A s context is requested and its value is returned to node B. This information is not only recorded in the CiData and CiSchema of node B, but sent to the third node as well.

4 Preparation Timeout Interval :: B :: {B} DEPLOYMENT RETRIEVAL CiB A A Beacon_RQ SHARE ({B} 3.1.1) Beacon_RQ SHARE ({A} 1.1.1, ) REQUEST ({A} ) CiB B B Preparation Beacon_RQ SHARE ({B} 3.1.1) :: A :: {A} 1.1.1, rd Device Preparation :: B :: {B} REPLY ({A} :75) CiSchema Upgraded: 1.3.1:: A :: A :: {A} 1.1.1, :: 75 UPGRADE ({A} ) :: B :: {B} 3.1.1, {A} Figure 5: CiComm Packets and the process of communication D. Platform Construction in NS-2 The CiB and CiComm protocol are simulated using NS2 [12]. A schematic of mobile nodes in an ad hoc network environment with the CMU monarch s wireless extensions is shown in Figure 6, where the platform of CiB and CiComm (though it s shown as CiB only) is integrated. As the figure demonstrates, the platform offers its interface (cib_) to the Logic Link only; meanwhile it gets instances from the Mobile Node, the Logic Link and the Mac for the purposes of context collection and addressing resolution. The platform applies the full features of CiB and CiComm to NS2 involving the construction of CiB in each node and both Deployment and Retrieval phases of CiComm. Additionally, more configuration settings are performed by the platform for the better integration to the NS2 environment; these include construction of the CiComm packet header, registration of the CiComm packet type, and initial parameters in CiB and CiComm. IV. EXPERIMENT RESULTS AND ANALYSIS A. Randomness in CiB & CiComm Simulations To present a fair simulation pattern and prevent simulation results from certain circumstance settings, randomness is employed in CiB and CiComm simulations; it includes: - random position and movement of nodes The positions of all nodes are designated randomly within a given area. Their movements during the simulation time also follow no order and are unpredictable. - random CiB loading and releasing time

5 Upper Apps Routing Model Entry_ Mobile Node target_ mhost_ Logic ll CiB mac_ Link cib_ Upper Apps Routing Model Entry_ Mobile Node target_ mhost_ ll Logic CiB cib_ Link mac_ IFq mac_ mac_ IFq MAC NetIF The CiB in each node is loaded and stopped at a different time. This exposes the potential problem that later switched/joined nodes may find it difficult or unable to share and request context information. - random selection of local context information and requirement of remote context information This setting prevents simulations on narrow scenarios (e.g. same context information requested, etc.). Furthermore, choosing the local context information by chance reduces the complexity in the process of preparing distinct information for every single node. B. Particular Scenario Simulation Radio Propagation Model Figure 6: Implementation of CiB and CiComm in NS2 Channel In this section, a CiB-integrated ad hoc network is simulated where 11 nodes are randomly placed in a 20 X 20 metre area. All nodes have the same communication range of 10 metres. Ten of them (numbered 1 to 10) are static at their initial positions; while Node 0 ([17.22, 19.62]) acts as a visitor getting through the network to the specified destination ([1.59, 1.35]) with continuous requirement of its neighbours positions (reference number 3.1.1). Figure 7 depicts the movement of Node 0 and the consequence changes in its CiB. In (a), the initial topology of the network is shown. Curved circles are drawn to show nodes communication range. The dashed line with an arrow at the end illustrates the moving trace of Node 0 and its destination. Six critical points are selected from the simulation based on the movement of Node 0; the alteration of the network topology and content of CiSchema in Node 0 at these moments is shown in Figure 7 (b) and (c). MAC Radio Propagation NetIF Model (a) (6.3s) (7.1s) (10.2s)

6 (12.5s) (14.1s) (16.1s) (b) (6.3s) (10.2s) (7.1s) (12.5s) (14.1s) (16.1s) (c) Figure 7: Simulation on a particular scenario with one wandering node. (a) initial topology; (b) changes at critical points; (c) changes of CiSchema in Node 0 at critical points. Through these snapshots, the process of Deployment and Retrieval Phase, as well as the removal of context information in Node 0 is demonstrated. At 6.3s, 7.1s and 10.2s, Node 0 enters the range of Node 3, Node 8, and Node 9 and 10 respectively, so their relevant context information is added correspondingly. Then at the moment of 12.5s, Node 6 and 7 are out of the range of Node 0 and therefore removed from the CiSchema of Node 0. After that, at 14.1s and 161s, Node 8 and Node 5 are removed from Node 0 since it leaves from them respectively. The context of Node 0 has been updated with its movement and the consequent change of its neighbours. V. CONCLUSION In this paper, a context information communication (CiComm) protocol is presented realising context discovery/provision in a CiB-based ad hoc network. As a protocol located in the Logic Link Control Layer, the CiComm has a common packet header through which key attributes of a packet are identified, including the source and destination address at CiB level, the type of a packet, etc. Two processing phases, Deployment Phase and Retrieval Phase, are defined for the communication of context information. The CiComm provides similar functionalities to a service discovery protocol (e.g. Jini). Both protocols focus at the information/data processing and aim to adapt to changes within a dynamic networking environment. However, they are also contrasted with each other. Jini has an infrastructure supported architecture (Lookup Service) and therefore is centralised. The CiComm on the other hand is infrastructure-less and purely distributed. The CiComm protocol, together with the CiB model is implemented in the NS2 simulation environment. According to the simulation results, the platform of CiComm and CiB offers the abilities of maintaining, advertising and acquiring context information. The completion of the simulation and its results also proves that the CiComm can provide an alternative way to share context information. The performance of the platform in terms of its response times and consumption of network bandwidth will be measured and evaluated as the next task. REFERENCES [1] Dey A., Understanding and Using Context, Personal Ubiquitous Comput. Vol 5, Issue 1, pp 4-7, [2] Abowd, G., et. al., Cyberguide: A mobile context-aware tool guide, ACM Wireless Networks, Vol 3, Issue 5, pp , [3] Battazzi, D., et al, Context Aware Middleware Solutions for Anytime and Anywhere Emergency assistance to elderly people. Communications Magazine, IEEE,Vol 44, Issue 4, pp 82-90, [4] Anind K. Dey, Masayasu Futakawa, Daniel Salber, and Gregory D. Abowd. The Conference Assistant: Combining Context-Awareness with Wearable Computing. In Proceedings of the 3 rd International Symposium on Wearable Computers (ISWC '99), pages 21-28, San Francisco, CA, October [5] Julien, C. and Roman, G., EgoSpaces: Facilitating Rapid Development of Context Aware Mobile Applications, Software Engineering, IEEE, Transactions on, Vol 32, Issue 5, pp , [6] Gold, R. and C. Mascolo. Use of context-awareness in mobile peer-to-peer networks. in Distributed Computing Systems, FTDCS Proceedings. The Eighth IEEE Workshop on Future Trends of [7] Liu, Q. and Prof. Linge, N., Context-Driven Ad-Hoc Networks, doctoral consortium of the 12th international Conference on Natural Language Applications to Information Systems, [8] Liu, Q. and Prof. Linge, N., Context-Driven Ad-Hoc Networks, PGNET 2007, 8 th Postgraduate Symposium on the Convergence of Telecommunication, Networking and Broadcasting, June [9] Jini Network Technology, last access: 20 April [10] Chiu, D. K. W., et al., Towards Ubiquitous Government Services through Adaptations with Context and Views in a Three-Tier Architecture, in the System Sciences, HICSS th Annual Hawaii International Conference on, p94, [11] Yu, Z., et al., Supporting Context-Aware Media Recommendations for Smart Phones, Pervasive Computing, IEEE, Vol 5, Issue 3, pp68 75, [12] The Network Simulator 2, last access: 21 April 2008.