Published on

parking system

Published in: Career
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. 2007 International Conference on Intelligent Pervasive Computing A Hybrid Middleware for RFID-based Parking Management System using Group Communication in Overlay Networks∗ Louie F. Cervantes Institute of Information and Communications Technology West Visayas State University Luna St., Lapaz, Iloilo City, Philippines Young-Seok Lee, Hyunho Yang, and Jaewan Lee School of Electronic and Information Engineering Kunsan National University 68 Miryong-dong, Kunsan City, Chonbuk, 573-701, South Korea {lfcervantes, leeys, hhyang, jwlee} Abstract 1. Introduction Application-level multicast has gained popularity as an A hybrid middleware for RFID-based parking manage- active research area. Various algorithms and systems for ment system is presented in this paper. The publish- scalable group management and reliable group communi- subscribe approach is combined with group communica- cation can be found in the literature. Radio frequency iden- tion in overlay networks in the design of event monitors tification (RFID) systems are emerging as practical means and application service connectors to comprise the core of of auto-identification in a wide variety of applications from a hybrid middleware. In this paper, group communication access control to product tracking. The widespread adop- relevant to P2P networks is the focus of middleware tech- tion of RFID is already happening and many organizations nology development. A group of peer nodes provide an have begun using the technology in innovative ways. efficient abstraction to handle events from RFID readers Parking is an ever growing challenge in cities and town and vehicle identity detectors to be processed by services everywhere. Parking demand is routinely high at airports, and applications that run in the conventional IP networks. downtown areas, and around transit and ride facilities. In Programming abstractions for publish-substribe messag- this paper we present our design of an electronic parking ing (multicast and single) from the reference P2P systems management system based on RFID technology. We de- are used to build new extensions. The hybrid middleware signed a middleware based on group communication in P2P provides an efficient communication transport between the networks to handle the communication needs of a large peer-based networks and existing application services and number of RFID readers and presence detectors distributed mobile communication infrastructure that require conven- across a wide area in several parking facilities. tional IP-based networks. The simulation results show that the approach improved the performance of the P2P net- work. This paper provides an implementation model that 2. Related Works can significantly lower the infrastructure cost for building an electronic parking management system. 2.1. Peer-to-peer Middleware The term peer-to-peer (P2P) refers to a class of systems and applications that employ distributed resources to per- form a function in a distributed manner. The resources en- compass computing power, data storage and content, net- ∗ This research was supported by the Program for the Training of Grad- work bandwidth, and presence (computers, humans and uate Students in Regional Innovation which was conducted by the Ministry other resources) [1]. The distributed function can be com- of Commerce Industry and Energy of the Korean Government. puting, content, and collaboration or platform services. De-0-7695-3006-0/07 $25.00 © 2007 IEEE 521DOI 10.1109/IPC.2007.112
  2. 2. 2.3. Parking Management System Electronic parking management system (ePMS) main- tains a real-time parking space inventory across a set of par- ticipating facilities. The data can be used to generate park- Figure 1. Peer nodes and Group Overlay ing availability advisory presented to the public using elec- tronic display boards or similar means. ePMS helps drivers find parking lots quickly, thereby reducing frustration andcentralization may refer to data, algorithm, meta-data, or all enhancing their overall driving experience[11].of them. The main motivation for using RFID technology in our P2P applications such as the office collaboration suite design of ePMS is the significant lower infrastructure costGroove [2] and telephony service Skype [3] are widely of implementation compared to other approaches. An elec-used. However, few applications beyond file sharing are tronic parking system (EPS) is presented in [12]. Theirbeing built to take advantage of the capabilities of P2P net- design focused on automated ticketing and a charging sys-works [4]. Messaging based middleware like CORBA, EJB, tem that integrates with a toll collection facility called Elec-COM+ and SOAP ease the development of distributed ap- tronic Road Pricing (ERP). The system performance wasplications but their centralized model do not fully utilize reported as reliable and their work has been marketed as athe resources in decentralized environments. The first sig- mature product. In this work, we seek to achieve compa-nificant peer-to-peer middleware and platform is JXTA [5]. rable or better performance results in parking managementJXTA provides a general middleware useable for a variety while avoiding the use of costly infrastructure such as theof applications. Other P2P platforms include Microsoft’s case of the previous study. In another paper [13], wirelessPeer-to-Peer SDK [6], Pastry [7], Chord [8] and CAN [9]. sensors were used for the dual role of presence and iden-The current work is heavily influenced by Scribe [10]. tity detection. Their approach relied on IP multicast using Our approach focuses on group communication espe- flooding. The results obtained indicated limited success duecially relevant to P2P applications. The strength of the P2P to the significant communication cost incurred in transmit-approach lies in the collaboration of several peers, allowing ting data to the sink node.each peer to profit from the others. Collaboration in a grouprequires communication among its members, thus the needfor group communication.2.2. Peer-to-Peer Group Communication A group consists of several peers in a peer-to-peer net-work having a common interest in a specific topic. Thesepeers are subscribers of a topic in a publish/subscribe do-main. When a message of interest is sent, the peer-to-peernetwork can handle the delivery to each interested recipi-ent. However, this approach can be inefficient even if therouting is optimal. The bandwidth of non-subscribed peersis utilized even if they are not interested in the message.A group overlay network is created on top of the P2P net-work to provide a more efficient communication service in-dependent of the underlying network. We choose the ringtopology to build the overlay network. Rings are scalablein terms of bandwidth, because the workload of the nodesis independent of the total number of nodes. Backup andrepair procedures can be easily included due to the manage- Figure 2. Architecture of ePMSability and simplicity of the ring topology. Figure 1 showsthe group overlay created on top of the P2P nodes. 522
  3. 3. 3. Architecture of Hybrid Middleware for ing slot and LEAVING event occurs when it vacates the RFID-based ePMS parking slot. We define the overlay node as a data collection module Our hybrid middleware sits between the RFID hardware and parking event monitor. To make communication withand the enterprise applications or conventional middleware. the group more efficient, the group is create correspondingThe main goal of this middleware is to process the data to the set of detectors and RFID readers that are co-locatedfrom tags collected by the readers deployed in the RFID in- in a particular parking space. This optimizes the physicalfrastructure. Figure 2 shows the architecture of our hybrid proximity of group members ensuring the minimum num-middleware. In this work, group-based communication is ber of hops for multicast messages.achieved using the topic based publish-subscribe approach deliver(msg, key)in Scribe [14]. Scribe is a large- scale decentralized event switch (msg_type)notification infrastructure built upon Pastry [7], a scalable, case CREATE:peer-to-peer location and routing substrate. topics.add(msg.topic) invokeNotifyGroupManager(nodeID)3.1. Hybrid Middleware Components case JOIN: topics.children.add(msg.source) Peer Group Membership Manager - this node is used to invokeNotifyGroupManager(nodeID)create all the groups. All group related tasks including to case MULTICAST:create/destroy a group or to change group membership a for each node in topics.childrencorresponding notify message is send to this node. The pur- send(msg, node)pose is to enhance the management of group membershipmore efficient. if subscribed(msg.topic) Group Communication Coordinator - this node controls invokeEventHandler(msg.topic, msg)the rate of heartbeat messages that sends a multicast mes-sage to other member nodes. A heartbeat message ensures case LEAVE:that changes to parking status such as when a slot becomes topics.children.remove(msg.source)vacant after a vehicle has left, will be robustly detected with invokeNotifyGroupManager(nodeID)minimal delay even when the vehicle presence detector fails if topics[msg.topic].children = 0to detect the event. This behavior is based on the routing msg.source = thisNodeIDtree repair mechanism but in this case it is used to ensure send(msg, topics[msg.topic].parent)the accurate detection of the parking space status. Parking Event Manager - this node acts as the sink nodefor all parking events. The details for sending the parking Figure 3. Implementation of deliverevent data to the database service is handled by this node. Service Connectors - Specific nodes are tasked to per-form specialized roles in the peer groups such as provide 3.3 Group Communication Modelmanagement control of the individual nodes or a subset ofthe overlay group. In this paper, the design of a hybrid middleware pro- poses novel extensions to Scribe [10]. The group commu-3.2. Overlay Node nication approach in Scribe provided a suitable base for the design of the core functionality of our hybrid middleware. Each RFID reader is attached to a host. The detection re- Our innovation is focused on extending these mechanismsgion of the reader can span several parking slots. The pres- to create adapters between the P2P network and a central-ence detector in each slot provides the trigger that fires the ized database server and other application services. Thisparking event (entering or leaving) and activates the reader abstraction of peer nodes into a group permits a service towhich obtains the identification data from the RFID tag. interact with the group as if it is a single object. On theEach parking slot is associated with a peer node thus a park- other hand, peers within the group view the service as if iting event fired up by the presence detector is handled as a is another member peer.message by this node which acts as a parking event handler. The following relevant APIs in Scribe were modified andAll nodes within a single parking space form a group and extended with new functionality to satisfy the requirementsshare a common groupID. of this system: Our approach describes two types of parking events: EN- create(credentials, groupID) creates a group with theTERING event occurs when a vehicle comes into the park- specified groupID. Unlike the implementation in Scribe 523
  4. 4. which allows any node to create a new group, we assign Our design of the ePMS is based on the needs of thea node to handle group creation and maintain a record parking management in a university campus. Our systemof group membership. join(credentials, groupID, even- aims to provide the following application services for:tHandler) causes the local node to join the group. Allmessages for this group are received by this member node 1. Real-time monitoring to support enforcement of park-and events are handled by the specified event handler. ing space privileges for faculty and students;leave(credentials, groupID) causes the local node to leave 2. An on-demand search utility to locate a vehicle usingthe group and be removed from the group membership mobile phone or a web interface;record. multicast(credentials, groupID, event) causes theevent message to be delivered to all the members nodes that 3. A system for a campus-wide security log of parkingare subscribed to this group. send(msg, nodeID) causes the space occupancy; andlocal node to route the message to the node specified by 4. Automated ticket and parking fee collection is a futurenodeID. feature goal. However, the current implementation an- The deliver function handles message delivery events in ticipates this need by providing appropriate data fieldseach node. Figure 3 shows the implementation of deliver in compatible with a parking fee collection application.ePMS.4. Implementation of RFID-based Electronic Parking Management System The electronic PMS have the following basic hardwarefeatures: 1. The system should be able to detect occupancy of the individual parking slot, i.e., determine if the slot is empty or occupied. Figure 4. Parked Vehicle Identity Detection 2. Two types of events should be clearly distinguishable: ENTERING - the vehicle has moved into the slot, and As designed, ePMS consists of RFID sensors, vehicle LEAVING - the vehicle is exiting the slot. Proper de- presence detectors, host computers, communication/power tection thresholds should be configured to avoid false infrastructure, and Internet based applications for system detections when vehicles momentarily pass the detec- monitoring and user queries. Figure 4 shows our imple- tion region. mentation of identity detection using RFID technology in 3. Distinct mechanism for two types of detection is sup- ePMS. ported: presence detection and identity detection. Var- ious mechanisms of the practical implementation of presence detection is presented in the literature [12] [13]. This work is an implementation of parked ve- hicle identity detection using RFID as the underlying technology. 4. Each authorized vehicle is provided a passive RFID tag attach using a tamper proof mechanism in the front section of the vehicle placed in a location for optimal detection. Authorized vehicles are those that belong to faculty, staff and students. Similar tags are issued to visitors but can be mounted temporarily. 5. RFID readers are distributed in the parking spaces, in a manner that ensures adequate coverage of all parking Figure 5. Implementation Model slots. 6. Inexpensive mechanical presence detectors are in- The focus of the current work is on the hybrid middle- stalled per individual parking slot. ware to support group communication among peer nodes 524
  5. 5. that handle parking event messages and connect with con- tended roles and all other nodes are either nodes in a groupventional services. The implementation diagram is shown multicast tree (message forwarder) or message senders (ori-in figure 5. The P2P network and the overlay group of sen- gin of send messages).sor nodes provide the abstraction for the individual parking In mScribe, topic creation tasks were performed usingslots and a mechanism to efficiently manage the delivery one node (the Group Membership Manager) which then se-of parking events data generated when cars enter and leave lects certain nodes as the multicast tree roots (Group Com-parking slots. munication Coordinators) and maintains the record. This The mobile car location service is one of the key ser- means that each group has a rendezvous node just like in thevices of this system. Figure 6 shows the user interface of original design of Scribe but now a global record of all rootsa J2ME/MIDP mobile phone emulator as it connects to the is maintained to avoid the cost of routing across many nodescar location service. The car location service itself is a Java to locate the root. We also define one node to act as the sinkservlet that runs on a server connected to an IP-based net- node for the group to receive parking event messages fromwork. A similar interface is provided for the web browser, the member nodes. The sink node is any node other thanthus making the car location service accessible to an In- rendezvous node of the group. This ensures that commu-ternet kiosk in a designated place within the facility. A nication from member nodes to the sink node will alwaysglobal monitoring service provides real-time information be single hop. Otherwise the node will require multi-hopabout parking space availability for the entire system. This Pastry routing to send the message to the sink node.system can be easily extended to include online reservationand payment collection if later required. Figure 7. Average hops to reach sink node Figure 6. GUI of Mobile Car Location Service5. Experimental Results In this section we present the experimental results quan-tifying the performance of modified Scribe (mScribe) andstandard Scribe. The results were obtained using a Scribesimulation using 10 groups with varying group size of 10 to100 member nodes. The unmodified Scribe uses Pastry to manage topic orgroup creation, subscription and to build a per-topic mul- Figure 8. Average roundtrip delay between re-ticast tree used to disseminate the events published in the quest and replytopic. This approach is fully decentralized, all decisions arebased on local information, and each node has exactly iden-tical capabilities as the others. This means that every node In figure 7 we find that bigger group size helps improvecan be a publisher, a root of a multicast tree, a subscriber the performance of Scribe yet our approach to use the a sin-to a topic, a node within a multicast tree and any combi- gle hop send and not route through Pastry greatly reducenations of these. mScribe assigned certain nodes with ex- latency particularly for small group size. 525
  6. 6. In figure 8 we measured the round trip delay of a mul- [6] Microsoft. Microsoft Windows XP Peer-to-peerticast request from group coordinator node and the reply Software Development Kit (SDK). Available atfrom all node members. For Scribe we used Pastry routing both directions, and for mScribe only the request had to downloads/list/winxppeer.asp, 2003use standard Scribe multicast and the reply used the singlehop message send. [7] A. Rowston, and P. Druschel. Pastry: Scalable, Dis- tributed Object Location and Routing for Large Peer- to-peer Systems In Proc. of IFIP/ACM International6. Summary and Conclusions Conference on Distributed Systems Platforms (Mid- dleware), pp. 329-350, November 2001 The paper described a hybrid middleware for RFID- [8] I. Stoica, R. Morris, D. Karger, M.F. Kashoek, andbased electronic parking system using group communica- H. Balakrishnan. Chord: A Scalable Peer-to-peertion in overlay networks. The proposed hybrid middleware Lookup Service for Internet Applications.In Proc.consists of overlay group of peer nodes that serve as event SIGCOMM2001, August, 2001monitors and service connectors that bridge the P2P andconventional IP networks. Our simulation results indicate [9] S. Ratsanamy, P. Francis, M. Hadley, R. Karp, and S.that network performance in terms of reduced message hops Shenker. A Scalable Content Addressable Network. Inand round trip delay is improved by the proposed approach. Proc. SIGCOMM2001, August, 2001Our future work will focus on improving the communica-tion performance of our hybrid network and performing [10] A. Rowston, A.M. Kermarrec, M. Castro, and P. Dr-additional simulations to measure the efficiency of our ap- uschel. Scribe: The Design of a large-scale event no-proach in comparison to other related systems. We foresee tification infrastructure. In Proc. NGC’01, November,interesting research in the development of large-scale multi- 2001agent systems using the P2P networking. We continue the [11] Federal Highway Administration. Advanced Parkingdevelopment of our platform to define additional function- Management Systems: A Cross-Cutting Study. USality of hybrid middleware for general application areas. Department of Transportation, January, 2007 In conclusion, while our work is preliminary and muchimprovement of the platform remains to be done, we have [12] T. Obota, H. Ono, Y. Miyazaki, and M. Ando.demonstrated that a fresh approach, such as what was pre- Electronic Parking System for Singapore. Mitsubishisented in this paper, can spur more research in the de- Heavy Industries, Ltd. Teahnical Review, 40-3, June,sign and deployment of hybrid middleware to combine the 2003strengths of both P2P networks and the conventional IP net-work. [13] J. Benson, T. O’Donovan, P. O’Sullivan, U. Roedig, and C. Screenan. Car Park Management using Wire- less Sensor Networks.In Proc. of the 1st IEEE Int’l.References Workshop on Practical Issues in Building Sensor Network Applications (SENSEAPP2006), November, [1] D. Melojicic. Peer-to-Peer Computing, Tech- 2006 nical Report HPL-2002-57. Available at [14] M.Castro, P.Druschel, A.M. Kermarrec and A. Row- ston.Scribe: A large-scale and decentralized applica- 2002-57R1.pdf, 2002 tion level multicast infrastructure. IEEE Journal on Selected Areas in Communications, 20-6, October, [2] Groove Networks. Groove Networks Website. Avail- 2002 able at, 2007 [3] Skype. Skype Homepage. Available at, 2007 [4] M. Junginger and Y. Lee. Peer-to-Peer Middleware, In Proc. of Second International Conference on Peer-to- Peer Computing. pp.49-56, 2002 [5] Sun Microsystem. Project JXTA Homepage. Available at, 2007 526