Recently, rates of vehicle ownership have risen globally, exacerbating problems including air pollution, lack of parking, and traffic congestion. While many solutions to these problems have been proposed, carpooling remains one of the most effective approaches. Recently, several carpooling platforms have been built on cloud computing systems, with originators posting online list of departure/arrival points and schedules from which participants can search for rides that match their needs. However, it can be difficult to make matches quickly and the systems are subject to privacy concerns in that they may disclose private information such as names, registration data, and departure/arrival schedules. This paper proposes a dynamic matching method for car/taxi pools for use in mobile devices via ad hoc Wi-Fi networks. The proposed method also preserves user privacy including names and departure/arrival schedules. Moreover, the system does not require the user to register any personal data, so such data cannot be leaked. The system was implemented on the Android mobile platform, allowing users to immediately and securely access the system via their smart phones.
1. Introduction
In recent years, car ownership has exploded globally, exacerbating the negative side effects of driving, including depletion of fossil fuels and the production of carbon dioxide and other emissions; thus driving accelerates the development of air pollution, acid rain, and climate change. In addition, increased car ownership has increased traffic congestion [1–4], strained the availability of existing parking facilities [5–12], and reduced economic performance [13]. Scholars have proposed many solutions to these issues, including carpooling [14–20], which remains one of the most effective solutions.
In 1983 Fagin and Williams [14] first proposed a sharing mechanism, while other scholars [15–18] have also proposed various carpooling methods. In these methods, group members take turns serving as drivers. However, this approach is difficult to promote or apply widely because it only works if group members already know each other and agree ahead of time to organize a carpool.
In recent years, increases to network speeds have prompted scholars [19, 20] to propose the establishment of networked platforms [21–29] as a mechanism for organizing carpools. Di Martino et al. [19] proposed the Lift4U platform, a carpool matching algorithm based on cloud and positioning systems. The platform uses Bing Maps and GPS modules to provide access to car sharing, bike sharing, and public transport on mobile platforms. Lalos et al. [20] also describe a dynamic framework for car and taxi pool services through the use of positioning systems on mobile devices to determine the location of carpool members. These positions are then shown directly on the mobile device interface, helping carpool drivers to arrange pickups.
These systems use Internet and cloud computing technologies [30] to provide access to information required to participate in carpooling schemes; thus group members need not know each other or organize the carpool ahead of time. However, initiating a carpool or finding carpool originators entails a process of online registration, login, search, and comparison, thus producing a match between rider demand and driver availability. Therefore, in addition to being ineffective in helping carpoolers to coordinate in real time, these methods require originators to expose their personal information including name, location, destination, driving time, and expose participants’ personal information including name and telephone number.
This paper proposes a carpooling matching method deployed on mobile devices, wherein users can instantly initiate or participate in carpools via smartphones or tablet PCs via ad hoc Wi-Fi networks. The proposed method also protects user privacy, using a private matching method [31, 32] to protect the privacy of participants on both sides of the transaction, including name, origin, destination, and driving time.
The proposed system was implemented on Android smartphones, allowing users to directly, immediately, and securely find carpoolers. The implementation can be used directly to find rides from private carpools or taxi pools. For example, imagine a group of strangers emerging from a subway station and arriving at the adjacent bus stop immediately after their intended bus had pulled away, leaving them to wait another 20 minutes for the next bus. These individuals can access the proposed system via their smartphones to arrange for a taxi pool, thus saving time and money, while protecting their personal information.
The remainder of this paper is organized as follows. Section 2 discusses security issues and solutions for the proposed method and describes the research methods. Section 3 describes the proposed method, while Section 4 presents the analysis methods used, including accuracy analysis, locational error, and security analysis, and provides a comparison with other related methods. Section 5 introduces the implementation of the proposed system on Android phones and the final section presents concluding remarks.
2. Related Work
Most research into carpooling focuses on scheduling algorithms and matching algorithms, which are briefly introduced here.
2.1. Carpool Scheduling Algorithms
Fagin and Williams [14] and others [15–18] have proposed fair carpool scheduling algorithms wherein the participants take turns to drive the rest of the group. Here, we introduce four approaches including simple rotation, simple tokens, subsets, and fair carpool. Among these, simple rotation has a fixed set of N members, where person i is responsible for driving on the ith day and every N driving days. This approach is simple to describe and it is easy to determine who drives next. However, inconsistencies (e.g., if a driver cannot drive and has to swap days) can disrupt the schedule and make it difficult to determine who drives next.
In the simple tokens approach, a participant P pays a driver D one “ride token” each time P rides with D. The person with the fewest tokens would be the next driver. However, external conditions may render the designated driver unable to drive on a given day without warning.
In the subset approach, each of the 2N-(N+1) subsets of carpool members for N persons can drive particular groups. Drivers get “subset ride tokens” from that subset to determine who drives next. However, this approach is very complex given the large number of subsets.
In fair carpool [14], each participant pays U/k tokens to the driver in each carpool, where U is a constant value and k is the number of participants in each carpool time. However, this approach is unbalanced.
2.2. Carpooling Matching Algorithm
Many studies have proposed carpooling matching algorithms. Here, we review Di Martino et al.’s Lift4U platform [19], which uses Bing Maps and GPS modules to provide a range of carpooling applications (see Figure 1(a)). This method includes registration and data matching phases as follows.
Lift4U system.
The framework of Lift4U
Set the search radius to find others with the same destination
Plot potential routes
Select carpoolers
(1) Registration Phase. In this stage, the user registers online. The user’s identity is confirmed, using information including the user’s name, gender, date of birth, and telephone number.
(2) Data, Matching Phase. This stage includes four steps through which the user is matched with a ride.
Step 1.
The user accesses Bing Maps to establish points of departure and destination.
Step 2.
The user sets a search radius around the departure point to search for other people seeking the same destination (see Figure 1(b)).
Step 3.
The user finds other potential carpoolers within the search area (see Figure 1(c)), plots routes, and calculates the distances.
Step 4.
The user determines the shortest route and invites potential carpoolers to join based on which pickups result in the shortest route (see Figure 1(d)).
3. Proposed Scheme
We use the error-tolerable private matching to achieve private carpool matching. This method not only allows the user to directly use mobile devices to find potential carpoolers with similar points of origin and destinations in real time but also allows the user to expand the search range using a quantifier, for which the quantification space can be autonomously selected (see Figure 2), thus finding more potential carpoolers.
Carpooling schematic.
This paper uses the symbols listed in Notations Section, where Q(x,y) represents x quantized as x(q)∈{ip∣i=0,1,2,…,p=2y} s.t. -y<x(q)-x≤y. Map(·) is the transformed longitude and latitude function. For example, Map(x) represents the transformed longitude and latitude for map message x. Using Google Maps, the map message DstA is thus transformed into the longitude and latitude message LLA, and LLA=Map(DstA).
Figures 3 and 4 illustrate the operation process (using a taxi pool as an example). Figure 3 provides a detailed flow chart of the system operations, providing a detailed understanding or point of reference for programmers. Figure 4 provides a simplified schematic flow diagram for the system. In this system, “originator” is the car owner inviting others to join a carpool or is an initial taxi passenger inviting others to share the ride, and “participant” is a person who wants to join a car or taxi pool. The process goes through the following steps.
System programming flow chart.
System flow diagram.
Step 1.
A user can either select “Listen” to determine whether someone has already initiated the carpool matching service (go to Step 2) or directly acts as the originator of a car or taxi pool (go to Step 3).
Step 2.
After Listening, if the user receives a “Taxipool” or “Carpool” message, he/she can then elect to act as participant or originator. Otherwise if a “Taxipool” or “Carpool” message is not received and the participant option is not available, the user can still elect to act as originator, or return to Step 1.
Step 3.
If the user elects to act as originator, an appropriate (i.e., “Carpool” or “Taxipool”) message is broadcast.
Step 4.
If the user elects to act as participant, once he/she receives a “Taxipool” or “Carpool” message, he/she agrees to the match by sending a “GoMatch” message to the originator. Otherwise, go to Step 1.
Step 5.
The originator receives the “GoMatch” message and inputs his/her own destination DstA and search range RngA. He/she computes LLA=Map(DstA), which uses Map(·) to transform DstA into the latitude and longitude message LLA and uses the quantizer to calculate LLA(q)=Q(LLA,RngA), thus using LLA to obtain the quantized LLA(q). He/she then uses the adjustment function to calculate AdjA=LLA-LLA(q). Finally he/she transmits AdjA and RngA to the participant.
Step 6.
The participant inputs his/her own destination DstB and calculates LLB=Map(DstB). After receiving AdjA and RngA from the originator, the participant uses the adjustment function to calculate LLB′=LLB-AdjA and then computes LLB′(q)=Q(LLB′,RngA). Finally, the participant calculates hB=H(LLB′(q))and transmits hB back to the originator.
Step 7.
After the originator receives hB, he/she calculates H(LLA(q)) and determines whether it matches hB. If it matches, he/she transmits an “OK” message to the participant.
Step 8.
Finally, when the participant receives the “OK” message, he/she begins to negotiate the taxi pool or carpool arrangement with the originator.
4. System Analysis and Comparison4.1. Match Correctness
In this system, matching will only succeed if the distance between DstA and DstB falls within RngA. That is to say matching is only successful when
(1)-RngA<LLA-LLB≤RngA.
Theorem 1.
In this system, if -RngA<LLA-LLB≤RngA, matching will be successful.
Proof.
Since AdjA=LLA-LLA(q) and LLB′=LLB-AdjA, we have
(2)LLA-LLB=LLA(q)-LLB′.
From the assumption -RngA<LLA-LLB≤RngA, we get
(3)-RngA<LLA(q)-LLB′≤RngA.
Also from the definition of Q(x,y), we know that -RngA<LLB′(q)-LLB′≤RngA since LLB′(q)=Q(LLB′,RngA). We can get
(4)-RngA≤LLB′-LLB′(q)<RngA.
From (3) and (4), we get -2RngA<LLA(q)-LLB′(q)<2RngA. Because both LLA(q) and LLB′(q) belong to {ip∣i=0,1,2,…,p=2RngA}, we can conclude that LLA(q)=LLB′(q).
Conversely, if (1) does not hold, matching fails. That is, if LLA-LLB>RngA or LLA-LLB≤-RngA, matching fails.
Theorem 2.
In this system, if -RngA<LLA-LLB≤RngA does not hold, matching fails.
Proof.
(1) If LLA-LLB>RngA, from (2), we get
(5)LLA(q)-LLB′>RngA.
From (4), we know that
(6)LLB′-LLB′(q)≥-RngA.
From (5) and (6), we conclude that LLA(q)-LLB′(q)>0. Therefore, LLA(q)≠LLB′(q).
(2) If LLA-LLB≤-RngA, from (2), we get
(7)LLA(q)-LLB′≤-RngA.
From (4), we know that
(8)LLB′-LLB′(q)<RngA.
From (7) and (8), we conclude that LLA(q)-LLB′(q)<0. Therefore, LLA(q)≠LLB′(q).
4.2. Obtaining Latitude/Longitude Values and Quantified Scopes and Regulating Pairing Errors
Google Maps features different coordinate formats and GPS modes, requiring conversion for interoperability. The conversion formula is as follows:(9)XdegreesYminutesZseconds(GPSmode)=X+Y60+Z3600(GoogleMapsdecimaldegrees).
Longitude and latitude have different relationships to distance. In latitude, one degree is equivalent to 111.19 km, while one degree of longitude is equivalent to 101.35 km. Therefore, an input range with an error value of 1 km can be used to obtain a quantized interval of 2 km, which is converted to approximately 2/111.19 degrees latitude and 2/101.35 degrees longitude. This produces a set of quantized values.
If the quantized values for latitude and longitude are obtained, a restriction exists that the matching range can produce a square-shaped “square pairing” area, two km on each side (see Figure 2), rather than a circular range with a diameter of two km for “circular pairing.” Thus, the distance from the point of departure to the four corners of the square pairing area exceeds RngA, but matching is successful (see red stripped ball in Figure 5(a)), while the maximal error distance is +(2-1)RngA (or the maximal distance error rate is +41.4%), and the average false acceptance rate (FAR) is 21.46% and false rejection rate (FRR) is zero. However, one can also adjust the determination method for control of maximal error distance in -(1-(2/2))RngA (approximately −29.29% with FAR being zero and FRR being 36.34%) (see Figure 5(b)) or ±(3-22)RngA (approximately ±17.16% with FAR being 4.57% and FRR being 16.62%) (see Figure 5(c)). Herein, Figure 5(c) is a relatively acceptable option. That is, for the user’s input error range of 1 km (1000 m), the worst-case scenario would be (1) successful matching at a distance of 1171.5 meters (see point A in Figure 5(c)) or (2) unsuccessful matching at a distance of 828.5 meters (see point B in Figure 5(c)).
Pairing error.
4.3. Security Analysis
When using the program, users may be concerned that others may be able to access their departure or destination point information. The proposed protocol ensures user privacy, allowing users to engage with the system without fear that their personal information may be leaked to unauthorized parties. In the proposed scheme, attackers are unable to obtain a plain text message through analyzing the transmitted information. Moreover, after finishing this protocol, neither the originator nor participant is aware of each other’s information unless they share a common destination. We analyze possible means of attack as follows.
(1) Participant Attempts to Eavesdrop on the Privacy of Originator. In the proposed protocol, the participant is only able to receive AdjA and RngA messages and is unable to access private information related to the originator such as intended destination.
(2) Originator Attempts to Eavesdrop on the Privacy of Participant. In the proposed protocol, the originator is only able to receive the participant’s hB message. If matching fails, the originator is unable to access private information related to the participant such as intended destination.
(3) Third Party Attackers Attempt to Eavesdrop on the Privacy of Originator or Participant. In the proposed protocol, although an attacker can eavesdrop on the AdjA, RngA, and hB messages, he/she is unable to access private information, such as the intended destination of either the originator or participant.
Thus, if the originator and participant have different intended destinations, neither is aware of the other. In addition, if an attacker eavesdrops on these messages, the messages cannot be compromised thus preserving the privacy of both parties.
In addition, if the negotiated content is subject to eavesdropping concerns, one of the following two advanced steps can be taken.
The originator (in Step 7) calculates SKAB=H(LLA(q)+1) and the participant (in Step 8) calculates SKBA=H(LLB′(q)+1), thus obtaining a secret protocol key SKAB=SKBA. This key can be used for encryption and decryption, thus allowing participants to negotiate carpool details.
After the originator receives the “GoMatch” message (in Step 5), he/she can conduct a Diffie-Hellman key exchange of the key SKAB with the participant, and this key can then be used to encrypt the following message.
4.4. Comparison
Table 1 presents a comparison of our proposed system with scheduling algorithms (e.g., Fagin and Williams [14]) and carpooling matching algorithms (including Lift4U [19] and Lalos et al.’s algorithm [20]). All the algorithms can provide carpool functions, while [19, 20] require GPS for the comparison. In terms of scheduling algorithms, because the system requires prior communication to coordinate matching, the users must know each other prior to using the system. In addition, because scheduling algorithms are planned ahead of time and Lift4U relies on a networked platform for matching, therefore it is unable to provide real-time, spur-of-the-moment carpooling. Most methods require prior registration or login and use networked platforms to run their matching algorithms, thus requiring Internet access. Also, most methods fail to consider privacy concerns. However, the proposed method provides all of these functions, while providing privacy protection.
Comparison.
Function
Fagin and Williams [14]
Lift4U [19]
Lalos et al. [20]
Proposed system
Carpool
v
v
v
v
Does not require GPS for matching
v
v
Users do not need to know each other
v
v
v
Spur-of-the-moment matching
v
v
Does not require registration
v
Does not require Internet access
v
v
Privacy protection
v
5. Implementation
To validate the proposed method, we used the Android development platform to implement the matching program on a NEXUS S smartphone and used the SHA-1 hash algorithm as the hash function for the matching process. Using Wi-Fi as the transmission medium, we conducted actual tests of the privacy-enabled carpool matching system on a smartphone running Android.
As the flow chart shows in Figure 3, after the user initiates the program (see Figure 6(a)), the program first engages the “Listen” (i.e., “search”) mode (see Figure 6(b)). If it fails to find a ride, it organizes a new carpool (see Figure 6(c)). We assume that Alice initiates a new carpool. She then inputs her approximate intended destination (e.g., city) and uses Wi-Fi to broadcast a carpool or taxi pool message to find potential carpoolers. When multiple users (i.e., participants) receive the carpool or taxi pool message through the “Listen” mode, (see Figure 6(d)), willing parties which match the originator’s query specifications (in this case “Bob”) transmit back a “GoMatch” (i.e., “Join”) message. Alice receives the “GoMatch” message and then decides whether to approve the match (see Figure 6(e)).
Implementation.
Next Alice can opt to use a Diffie-Hellman key exchange (i.e., the “DH receiver”) (see Figure 6(f)). If so, both parties will use the Diffie-Hellman key exchange to establish a session key (see Figures 6(g) and 6(h)). Next, Alice inputs her own destination DstA and error range RngA (see Figure 6(i)), using map to transmit the converted coordinates, longitude, and latitude (see Figure 6(j)) and generate the resulting adjustments AdjA with RngA for transmission to Bob.
Once Bob receives AdjA and RngA, he inputs his own destination DstB (see Figure 6(k)), using map to transmit the converted coordinates (see Figure 6(l)). The calculated hB is then transmitted to Alice who then compares whether H(LLA(q)) and hB are identical (see Figure 6(m)). If the match is successful, Alice sends the “OK” message to Bob. When Bob receives the successful match message (see Figure 6(n)), he and Alice begin to proceed to the carpool negotiation (see Figures 6(o) and 6(p)).
6. Conclusion
In this paper, we propose a protocol by which mobile devices can be used to provide instant matching for carpools and taxi pools in a way that protects the information privacy of all parties (e.g., names, telephone numbers, travel times, origins, and destinations). We review previous similar schemes and compare their various features and properties, for example, whether they require the use of GPS, whether the users need to know each other in advance, whether they are required to register, whether they can protect the user’s personal information, and whether they can be used to arrange spontaneous carpools instantly. We also perform a security analysis to illustrate the privacy controls of the proposed scheme. We discuss how to obtain the quantification space and quantized values from the longitudes and latitudes, explain methods for arranging matches within a given error range, and make recommendations for actual system implementation. We also show that matching will succeed as long as the distance between the two parties falls within a set error distance range and will fail if this distance is exceeded. Finally, we describe the implementation of the proposed scheme on an Android smartphone to demonstrate feasibility. Future work will focus on developing a more accurate method for producing “circular pairing” rather than “square pairing” to reduce error values or error ratios arising from the determination of coordinates.
NotationsLLA:
Latitude and longitude of A
LLA(q):
Quantified latitude and longitude of LLA
AdjA:
Adjustment value of A
DstA:
Destination input for A
RngA:
Destination range for A
SKAB:
Session key for A and B
Carpooling:
Carpool match initiating message
GoMatch:
Match agreement message
H(·):
One-way hash function
Q(x,y):
x(q)∈{ip∣i=0,1,2,…,p=2y}s.t.-y<x(q)-x≤y
Map(·):
Latitude and longitude conversion function.
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgments
This work was partially supported by the NSC under Grant NSC 102-2221-E-182-038. The authors also gratefully acknowledge the helpful comments and suggestions of the reviewers, which have improved the presentation.
QiH.-S.WangD.-H.ChenP.Formation and propagation of local traffic jam201320131274852910.1155/2013/748529MR3037764ZhangX.GongH.XuZ.TangJ.LiuB.Jam eyes: a traffic jam awareness and observation system using mobile phones20122012992120810.1155/2012/921208FozzaC.LonginottiM.T-cell traffic jam in Hodgkin's lymphoma: pathogenetic and therapeutic implications2011201192-s2.0-7834929043610.1155/2011/501659501659FukuyamaJ.A probabilistic protocol for multihop routing in VANETs20102010112-s2.0-8485692543610.1155/2010/185791185791ZhuJ.FengY.LiuB.PASS: parking-lot-assisted carpool over vehicular ad hoc networks20132013949175610.1155/2013/491756ChenZ.(Cecilia) XiaJ.IrawanB.Development of fuzzy logic forecast models for location-based parking finding services20132013647347110.1155/2013/473471ZhangZ.LiX.YuanH.YuF.A sreet parking system using wireless sensor networks201320131010797510.1155/2013/107975JiY.TangD.GuoW.BlytheP. T.RenG.Detection of outliers in a time series of available parking spaces201320131241626710.1155/2013/416267LiuY.WangW.DingC.GuoH.GuoW.YaoL.XiongH.TanH.Metropolis parking problems and management planning solutions for traffic operation effectiveness20122012667895210.1155/2012/678952ZhaoH.LuL.SongC.WuY.IPARK: location-aware-based intelligent parking guidance over infrastructureless VANETs201220121228051510.1155/2012/280515MeiZ.TianY.LiD.Analysis of parking reliability guidance of urban parking variable message sign system20122012102-s2.0-8485813598910.1155/2012/128379 MR2874591128379MeiZ.ChenJ.Modified motor vehicles travel speed models on the basis of curb parking setting under mixed traffic flow20122012142-s2.0-8485638126910.1155/2012/351901351901NingG.ZhenZ.WangP.LiY.YinH.Economic analysis on value chain of taxi fleet with battery-swapping mode using multiobjective genetic algorithm201220121517591210. 1155/2012/175912FaginR.WilliamsJ. H.A fair carpool scheduling algorithm19832721331392-s2.0-0020721997CoppersmithD.NowickiT.PaleologoG.TresserC.WuC.The Optimality of the On-line greedy algorithm in carpool and chairman assignment problems2005RC23721 (W0509-015)http://domino.watson.ibm.com/library/cyberdig.nsf/papers/057648E1F532E47C852570830050B106/$File/rc23721.pdfSelkerT.SaphirP. H.TravelRole: a carpooling / physical social network creatorProceedings of the International Symposium on Collaborative Technologies and Systems (CTS '10)20106296342-s2.0-7795447353210.1109/CTS.2010.5478453VargasM. A.SefairJ.WalterosJ. L.MedagliaA. L.RiveraL.Car pooling optimization: a case study in Strasbourg (France)Proceedings of the IEEE Systems and Information Engineering Design Symposium (SIEDS '08)200889942-s2.0-5174909263810.1109/SIEDS.2008.4559691YanS.ChenC.-Y.A model and a solution algorithm for the car pooling problem with pre-matching information20116135125242-s2.0-8005318877410.1016/j.cie.2011.04.006di MartinoS.GalieroR.GiorioC.FerrucciF.SarroF.A Matching-algorithm based on the cloud and positioning systems to improve carpoolingProceedings of the 17th International Conference on Distributed Multimedia Systems (DMS '11)20119095LalosP.KorresA.DatsikasC. K.TombrasG. S.PeppasK.A framework for dynamic car and taxi pools with the use of positioning systemsProceedings of the Computation World: Future Computing, Service Computation, Cognitive, Adaptive, Content, Patterns (COMPUTATIONWORLD '09)November 20093853912-s2.0-7795100543010.1109/ComputationWorld.2009.55CAR2GETHERhttp://www.car2gether.comAutostrade Carpoolinghttp://www.autostradecarpooling.it/NuRidehttp://www.nuride.comOpenID Foundationhttp://www.openid.netCarpooling Kinghttp://www.carpoolking.com/tw/zh-tw/CarpoolingWorldhttp://www.qcar.org.tw/carpooling.com, http://www.carpooling.com/us/Taxi poolhttp://www.ucl.be/en-283417.htmleRideShare.com, http://www.erideshare.com/MellP.GranceT.200915ChiouS. Y.HuangY. H.Mobile common friends discovery with friendship ownership and replay-attack resistance20131981839185010.1007/s11276-013-0577-xChiouS.-Y.Secure method for biometric-based recognition with integrated cryptographic functions201320131262381510.1155/2013/623815