J. Shanghai Jiaotong Univ. (Sci.), 2009, 14(5): 549-554

DOI: 10.1007/s12204-009-0549-6

Efficient Peer-to-peer File Sharing in 3G Networks

WANG Kai∗ (王 凯), LI Jian-hua (李建华)(School of Electronic, Information and Electrical Engineering, Shanghai Jiaotong University, Shanghai 200030, China)

Abstract: In 3G networks upgraded with high speed packet access (HSPA) technology, the high access bandwidthand advanced mobile devices make it applicable to share large files among mobile users by peer-to-peer applications.To receive files as quickly as possible is essential for mobile users in file sharing applications, since they are subject tounstable signal strength and battery failures. While many researches present peer-to-peer file sharing architecturesin mobile environments, few works focus on decreasing the time spent in disseminating files among users. In thispaper, we present an efficient peer-to-peer file sharing design for HSPA networks called efficient file sharing (EFS)for 3G networks. EFS can decrease the dissemination time by efficiently utilizing the upstream-bandwidth ofmobile nodes. It uses an adaptive rearrangement of a node’s concurrent uploading transfers, which causes thecount of the node’s concurrent uploading transfers to lower while ensuring that the node’s upstream-bandwidthcan be efficiently utilized. Our simulations show that, EFS achieves much less dissemination time than otherprotocols including Bullet Prime and a direct implementation of BitTorrent for mobile environments.Key words: peer-to-peer file sharing, file dissemination time, concurrent uploading rearrangement, 3G networks,upstream bandwidth utilizationCLC number: TP 393.09, TN 929.53 Document code: A

Introduction

The 3G network upgraded with high speed packetaccess (HSPA)[1-2] technology can provide 14.4 and5.8 Mb/s downlink and uplink bandwidth. Process-ing power and storage capacities of mobile devices haveincreased rapidly in recent years. All these improve-ments make peer-to-peer file sharing applicable in 3Gnetworks.

To receive files as quickly as possible is essential formobile users in file-sharing applications, since they aresubjected to unstable signal strength and battery fail-ures. However, existing applications in the Internet arenot suitable for a mobile environment, where the band-width of a user rapidly varies while churn is more dra-matic than in the Internet. Here churn means the rapidjoining and leaving of users in peer-to-peer networks.

We define the file dissemination process as that, aserver node with a complete file uploads the file to acertain number of nodes called “downloaders”. A down-loader has no datum of the file before the disseminationprocess starts. We define that the dissemination timebegins at the time when the server node starts to up-load and ends at that all the downloaders receive thewhole file.

Received date: 2008-05-11Foundation item: the National High Technology Re-

search and Development Program (863) of China(No. 2007AA01Z457) and the Science and Tech-nology Youth Qi-ming-xing Program of Shanghai(No. 07QA14033)

∗E-mail: www ken@tom.com

Some researches present peer-to-peer file-sharing ar-chitectures in mobile environments[3-5]. However, fewfocus on decreasing the dissemination time. Since theupstream-bandwidth of a node is much lower thanits downstream bandwidth in an HSPA network, theupstream-bandwidth of those nodes are usually the bot-tlenecks of transfer rates between nodes. Thus, we candecrease the dissemination time by efficiently utilizingthe upstream-bandwidths of nodes.

However, when the upstream-bandwidth of a nodeis fully utilized by its receivers, too many concurrentuploading transfers of the node delay the spread ofblocks[6] and lead to longer dissemination time. There-fore, we need to keep the count of the node’s concurrentuploadings at a low level. Bullet Prime[7] adjusts thecount of a node’s concurrent uploading by periodicallychecking the past changes of the node’s average upload-ing rate and count of concurrent uploadings. However,the algorithm cannot work properly with frequent churnsince it fails to consider the change of the count withinintervals.

We present an efficient peer-to-peer file-sharing de-sign for 3G networks, called efficient file sharing (EFS)for 3G networks. The simulations of comparing the per-formance of EFS with other algorithms show that, inmost cases EFS achieves the least dissemination time.

1 Efficient File Sharing Design

1.1 Architecture DescriptionIn the architecture of EFS, an index server tracks the

550 J. Shanghai Jiaotong Univ. (Sci.), 2009, 14(5): 549-554

online nodes that are downloading simultaneously afile. A newly joined node finds its peers with thehelp of the index server. Then it randomly connectsto a certain number of peers as its neighbors by TCPconnections, whereas it has only one connection to aneighbor. We set the maximum neighbor count of anode to 20 in EFS, which is the half of that in BT(http://www.bittorrent.org/).

The transfer of a file is block-based. A node can up-load a block to its peers only after it receives the com-plete replica of the block. Meanwhile, a node cannotdownload the same block from different senders simul-taneously. Here we refer to a node as a “sender” whenit is sending the data of files to its peers, and a node asa “receiver” when it is receiving the data from its peers.Besides, a node can download different blocks simulta-neously, but they must be from different senders. Thatis, the node should download blocks one by one froma sender instead of concurrently downloading multipleblocks from the sender, since concurrent downloadingsfrom a sender delay the spread of chunks[6]. We assumethat nodes are willing to upload blocks to their peersuntil all the nodes get the file.

A node reports to a neighbor what blocks it has, af-ter it connects to the neighbor. Whenever it receives anew block, it informs all its neighbors. Thus, a nodehas a table of the block information of all its neighbors.A node is interested in its neighbor if the neighbor hassome blocks that the node does not download any da-tum. When a node receives the block information froma neighbor for the first time, it responds with a messageabout whether it is interested in the neighbor. When anode changes its interest in its neighbor, it informs theneighbor.

The file transfer is block-driven. That is, after up-loading a complete block to a receiver, a sender endsthe uploading and starts a new uploading to anotherreceiver. The way for a sender to select receivers tostart new uploadings is random. The block selectionadopts the local-rarest-first (LRF) policy, which is thesame as that in BitTorrent (BT). That is, after a re-ceiver is selected by a sender to start new transfers, thereceiver selects the sender’s block that it needs and israrest among its neighbors.1.2 Adaptive Rearrangement of Concurrent

UploadingsThe core of EFS is an adaptive rearrangement of a

node’s concurrent uploading transfers. A sender has anadjustable upper bound on the count of its concurrentuploading transfers. We refer to the bound as the up-loading bound. When an uploading of a sender ends (ormultiple uploadings of a sender end at the same time),the sender adjusts the bound. Let u denote the in-stant count of the sender’s concurrent uploadings whenthe adjustment of the bound starts. Immediately afterthe adjustment, the sender rearranges its uploadings to

keep the count of its concurrent uploadings that areequal to the bound. That is, the sender will stop someongoing uploadings when u is higher than the bound, orsearch latent receivers to set up new uploadings whenu is lower than the bound, or keep current uploadingswhen u equals the bound.

The principle for the adjustment of the uploadingbound is that, firstly, the upstream-bandwidth of thesender should be fully utilized; secondly, the sendershould keep the count of its concurrent uploadings aslow as possible. The adjustment is based on the pastchanges of the sender’s counts of concurrent uploadingsand average uploading rates.

A sender maintains three main variables: up-load count, prev upload count and prev upload rateavg. We use the example shown in Fig. 1 to explainthese meanings of the variables. Let t1, t2 and t3 de-note the three consecutive instants when some of thesender’s uploadings end. No uploadings of the senderend in the interval (t1, t2) or (t2, t3). Meanwhile, t1, t2and t3 are the instants when three consecutive adjust-ments happen. At t3 the current adjustment happensimmediately after an uploading ends, whereas three up-loadings of the sender simultaneously end at t2. Conse-quently, when the current adjustment happens at t3, uof the sender is 3.

4

3

2

t1

u

t2 t3t'

t1 t2 t3t't

6

4

2

0

Prev_upload_countUpload_count

Upl

oad

boun

d

Fig. 1 An example for the upload count and prev uploadcount

We assume that, new uploadings can start immedi-ately after the adjustment of uploading bound whenthe sender can find new receivers. That is, we omit thetime that the sender spends in searching new receiversand setting up new uploadings. Why we can omit itis explained in the next section. Besides, the sendercannot find receivers to start new uploading after t2until t′ in the example. Therefore, the sender can startuploadings only at the instants t1, t

′ and t3.

We define the latest-constant-interval of a senderas the latest time interval that has constant countof the sender’s concurrent uploadings and is beforethe instant when the current adjustment of the boundstarts; define the previous-positive-interval of a sender

J. Shanghai Jiaotong Univ. (Sci.), 2009, 14(5): 549-554 551

as the latest time interval that is before the latest-constant-interval and has positive constant count ofthe sender’s concurrent uploadings. In the exam-ple, the intervals (t1, t2) and (t′, t3) are the previous-positive-interval and the latest-constant-interval of thesender. Then we define upload count as the count of thesender’s concurrent uploadings in the latest-constant-interval, and define prev upload count as the countof the sender’s concurrent uploadings in the previous-positive-interval. Therefore, variables upload countand prev upload count are constant in their intervals.

The prev upload rate avg is the average uploadingrate of the sender in the previous-positive-interval, i.e.,the total uploaded bits of the sender in the previous-positive-interval divided by the length of the previous-positive-interval. When the current adjustment starts,the sender calculates its upload rate avg, which is itstotal uploaded bits in the latest-constant-interval di-vided by the length of the latest-constant-interval.

Whenever stopping uploadings or starting new up-loadings, even when not doing the bound adjustmentor the rearrangement of uploadings, the sender up-dates the three variables. The prev upload count andprev upload rate avg are updated by the value of up-load count and upload rate avg when the upload countis positive, or they do not change. The upload countis always updated with the count of the sender’s con-current uploadings, when the sender has no new up-loading to start or after the sender starts all the newuploadings.

Algorithm 1 (Adjust a sender’s upload bound)

AdjustUploadBound() {if upload count = 0 then return //not adjust Bound

calculate upload rate avgif upload rate avg > prev upload rate avg then

if upload count > prev upload count thenIncreaseBound()//avg. upload rate increases after adding//uploadings, so add another

elseif upload count < prev upload count thenDecreaseBound() //losing an uploading//was not bad, to lose another

end ifelse

if upload rate avg < prev upload rate avg thenif upload count > prev upload count then

DecreaseBound()//adding uploadings was ineffective

else IncreaseBound()end if

elseif upload count != prev upload count then

DecreaseBound()else //the constant state already started

if constant state start = FALSE thenconstant state start = TRUE

const state begin instant =latest adjusting instant //record the instant//when the constant state started

end ifif (current-time -const state begin instantand constant state start) then

if upload count = 1 thenIncreaseBound()//to add new uploading

else DecreaseBound()end if

end ifend if

end ifend if

}IncreaseBound() {

if upload count < bmax thenb=upload count+1

}DecreaseBound() {

if upload count > 1 thenb = upload count−1

}

Algorithm 2 (Rearrangement of a sender’s upload-ings)

u=Upload count Now()

//get current count of concurrent uploadings

if u > b then

stop the slowest ongoing uploading-transfer

//the count of concurrent uploadings equals b now

else

if u < b then

search (b − u) receiver-candidates

and start new uploading-transfers to them

end if

if upload count != Upload count Now() then

constant state start = FALSE

if upload count > 0 then

prev upload count = upload count

prev upload rate avg = upload rate avg

end if //update the three variables

upload count = Upload count Now()

Algorithm 1 is the adjustment of the sender’s upload-ing bound, whereas Algorithm 2 is the rearrangementof the sender’s uploadings. Let b denote the uploadingbound for a sender. Let bmax denote the maximum forthe uploading bound. Then there is 1 � b � bmax.

As shown in Algorithm 1 and Algorithm 2, when theaverage uploading rate increases after adding extra up-loadings, or the rate decreases without extra upload-ings add, the sender increases the bound so that it canadd new uploadings. On the contrary, when the aver-age uploading rate increases after losing uploadings, or

552 J. Shanghai Jiaotong Univ. (Sci.), 2009, 14(5): 549-554

the rate decreases after adding extra uploadings, thesender decreases the bound. Consequently, the senderwill have less concurrent uploadings. After rearrangingits uploadings, the sender updates its three variables.

When upload count equals prev upload count whileupload rate avg equals prev upload rate avg, we judgethat the sender is in the constant state. When thetime elapsed in the constant state exceeds a thresholdtc, we try to break the constant state by changing theuploading bound. When upload count equals one, weincrease the bound and hope that more concurrent up-loadings can prevent the sender’s upstream-bandwidthfrom being underutilized. When upload count is largerthan one, we decrease the bound and hope that lessconcurrent uploadings can still fully utilize the sender’supstream-bandwidth.

We set a lower bound on the interval between twoconsecutive adjustments of the uploading bound, in or-der to avoid too frequent rearrangements of the sender’suploadings. Let td denote the lower bound. When anuploading ends whereas the time elapsed after the lastadjustment is lower than td, the sender updates its threevariables without adjusting its uploading bound or re-arranging its uploadings.

Besides the adjustment of the uploading bounddriven by the ends of uploadings, the sender adopts pe-riodical adjustment to avoid too long interval betweentwo consecutive adjustments. The sender resets a timerwhenever finishing an adjustment. When the timer ex-pires, the periodical adjustment starts. Let tp denotethe period of the timer. That is, tp is the upper boundon the interval between two consecutive adjustments.The routine of the periodical adjustment is the sameas the one driven by the ends of uploadings. Whenchoosing an uploading to stop, the sender selects theone with the slowest average uploading rate.

Our adjustment of the uploading bound differs fromthat used in Bullet Prime[7] mainly in three ways. Themost important one is that, in our algorithm a senderupdates its three variables whenever it stops or startsuploadings. Thus the sender’s count of concurrent up-loadings always matches the sender’s average upload-ing rate, which is not fulfilled in the algorithm in Bul-let Prime. Therefore, the algorithm in Bullet Primecannot work properly when a sender’s count of concur-rent uploadings frequently changes within short inter-vals. Secondly, our algorithm is driven by a hybrid ofthe periodical mode and the end-of-uploadings mode,whereas Bullet Prime is driven by the periodical mode.Thirdly, we add the adjustment to deal with the con-stant state of the sender.

The reason why we use the adaptive rearrangementof a sender’s concurrent uploadings is that, when theupstream-bandwidth of the sender can be fully utilized,to add additional concurrent uploadings slows down thespread of blocks[6]. Some receivers cannot receive new

rare blocks in time after their blocks are not needed bytheir peers. Thus, the upstream-bandwidths of thesereceivers cannot be utilized. Consequently, the dissem-ination time increases.1.3 Starting New Transfers

The sender selects the first l nodes from thecandidate-list and sends upload-request messages toeach of these candidates. The candidate respondswhether it is prepared to receive the block. If somecandidates refuse to be receivers, the sender then se-lects other nodes in the candidate-list to have enoughreceivers. After the session, the sender starts new up-loadings to each prepared receivers.

When one of the sender’s uploadings is close to fin-ish, the sender starts the adjustment of the uploadingbound in advance. Here “close” means that, the timeleft for the transfer of the block to finish is less thana precalculated threshold that depends on the round-trip-time (RTT). Thus, when the uploading actuallyends whereas the sender needs to start new uploadings,the sender already finished the sessions to the preparedreceivers and can immediately start transfers of blocks.By this mechanism we can mask most session-trafficlatency.

2 Simulations

2.1 Simulation SetupWe use a discrete-event simulator to model the ac-

tivities of nodes. Before the file dissemination processstarts, each node randomly connects to a certain num-ber of nodes as its neighbors. We use a fluid modelthat the concurrent uploadings or downloadings of anode equally share the upstream or downstream band-width of the node. Thus the rates of a node’s transfersvary with the count of the node’s concurrent uploadingsor downloadings. We also model the latency caused bythe slow start phase of a connection, which depends onthe RTT between a pair of nodes. The RTT is set as80 ms[8-9]. Table 1 shows the other parameters.

Table 1 The simulation settings

Parameter Value

Count of the downloaders 128

Count of the blocks in a file 100

Size of a block /KB 256

The initial value of b 2

tp/s 6

tc/s 8

Since too many concurrent uploadings leads to ex-pensive processing costs for mobile nodes, bmax can-not be high. Consequently, we set bmax as 8, whichis enough for the upstream-bandwidth of a node to befully utilized according to the measurement results[9].

J. Shanghai Jiaotong Univ. (Sci.), 2009, 14(5): 549-554 553

The rearrangements of a sender’s uploadings should notbe too frequent. Therefore we set td as 5 s.

We first conduct tests in a homogenous environmentwhere all the nodes have the same constant downstreamand upstream bandwidth as (1 460, 580) kb/s. Thissimulates the case where all the nodes are stationarywith abundant access bandwidth. We also introducetwo modes with varied bandwidth, where the down-stream and upstream bandwidth of an online down-loader periodically change whereas those of the servernode remain constant. In one mode, a downloaderstochastically changes its bandwidth according to agiven probability table shown in Table 2. There are fourvalues for the possible bandwidth of a downloader. Wecall this mode a freely-varied mode. In the other mode,a downloader changes its bandwidth between two givenvalues. We call this one a definitely-varied mode. Wechoose the bandwidth values (1 460, 580) and (730, 290)kb/s in the definitely-varied mode. In the two modeswith varied bandwidth, a downloader changes its band-width at a period of 10 s. When a downloader returnsonline, it restarts periodical change of bandwidth. Thebandwidth of the server node always remains (1 460,580) kb/s.

Table 2 The bandwidth and the correspondingprobabilities for a node changing to thebandwidth

ProbabilityBandwidth/(kb · s−1)

Downstream Upstream

0.3 1 460 580

0.3 730 290

0.2 292 116

0.2 146 58

The server node always remains online whereas allthe downloaders are online when the disseminationprocess starts. To model the churn phenomenon, attin seconds after the dissemination process starts, adownloader begins to periodically check whether itshould turn offline according to a fixed probability Poff ,whereas the period is 20 s. tin is a uniform randomnumber in the interval [0, 10) s. After a downloaderturns offline, it remains offline for a period of time toffand then turns online again. We set toff as 3.531 s sothat it equals one percent of the time that the servernode spends in finishing uploading the whole file.

We introduce a direct implementation of BT in a3G network based on the simulation codes of Ref. [10],whereas the neighbor count of a node is 40 and thebound of a node’s concurrent uploadings is fixed as 5[8].In Bullet Prime, the initial counts of concurrent upload-ings and downloadings of a node are both 2, whereasthe lower bound and the upper bound on the count of

concurrent uploadings are 1 and 8 respectively. Theneighbor count of a node is 20. The values of the otherparameters are unmodified and can be found in Ref. [7].2.2 Comparing EFS with BT and Bullet Prime

We compare the dissemination time of BT, BulletPrime and EFS in three scenarios: ① the homogeneousenvironment,② the definitely-varied mode, and③ thefreely-varied mode, as shown in Fig. 2. There is nochurn when the probability to turn offline equals zero.

Figure 2 shows that EFS achieves the least dissem-ination time almost in all the cases. The only excep-tion occurs in the definitely-varied mode with Poff = 0,where the dissemination time of EFS is longer than thatof Bullet Prime by 0.5%.

The difference in the dissemination time between BTand EFS is more dramatic than that between BulletPrime and EFS. Besides, the dissemination time of EFSis much less than those of BT and Bullet Prime with theincreasing Poff . Since EFS outperforms BT and Bullet

2.2

1.8

1.4

1.0

0.6

0.20 1.0 0.5 0.2 0

BTBullet PrimeEFS

BTBullet PrimeEFS

BTBullet PrimeEFS

Poff(a) The homogeneous environment

1.0 0.5 0.2 0Poff

(b) The definitely-varied mode

1.0 0.5 0.2 0Poff

(c) The freely-varied mode

Dis

sem

inat

ion

tim

e ×

10– 3

/s

2.4

2.0

1.6

1.2

0.8

0.4

0Dis

sem

inat

ion

tim

e ×

10– 3

/s

2.4

2.0

1.6

1.2

0.8

0.4

0Dis

sem

inat

ion

tim

e ×

10– 3

/s

Fig. 2 The dissemination time of BT, Bullet Prime andEFS in the three scenarios

554 J. Shanghai Jiaotong Univ. (Sci.), 2009, 14(5): 549-554

Prime much more with more frequent churn, EFS worksmuch better than BT and Bullet Prime in mobile envi-ronments.

In the three scenarios, the dissemination time of Bul-let Prime is quite close to that of EFS when there is nochurn, but is much longer than that of EFS with the in-creasing Poff . As we analyzed before, the rearrangementalgorithm of a node’s concurrent uploadings in BulletPrime is less effective than that in EFS, especially inthe cases of churn.

3 Conclusion

In this paper, we present an efficient peer-to-peer file-sharing design for 3G networks called EFS. EFS candecrease the dissemination time by an adaptive rear-rangement of a node’s concurrent uploadings. The sim-ulations show that, EFS outperforms Bullet Prime anda direct implementation of BT for HSPA networks indecreasing the dissemination time.

References

[1] 3GPP TS25.308(V7.0.0), HSDPA overall descrip-tion[S].

[2] 3GPP TS25.309(V6.6.0), FDD enhanced uplink; Over-all description[S].

[3] Hoßfeld T, Tutschku K, Andersen F U. Mappingof file-sharing onto mobile environments: Enhance-ment by UMTS [C]//Third IEEE International Con-ference on Pervasive Computing and Communications

Workshops (PerCom 2005 Workshops). USA: IEEE,2005: 43-49.

[4] Klemm A, Lindemann C, Waldhorst O P. Aspecial-purpose peer-to-peer file sharing system formobile ad hoc networks [C]//Proceedings of the Work-shop on Mobile Ad Hoc Networking and Computing(MADNET 2003). Sophia-Antipolis, France: IEEE,2003: 2758-2763.

[5] Rajagopalan S, Shen C C. A cross-layer decentral-ized BitTorrent for mobile ad hoc networks [C]//The3rd Annual International Conference on Mobile andUbiquitous Systems-Workshops. San Jose, CA: IEEE,2006: 1-10.

[6] Yang X, Veciana G D. Service capacity in peer-to-peer networks [C]//Proceedings of IEEE INFOCOM.Hong Kong, China: IEEE, 2004: 1-11.

[7] Kosti’c D, Braud R, Killian C, et al. Maintain-ing high-bandwidth under dynamic network conditions[C]//Proceedings of 2005 USENIX Annual TechnicalConference. CA: ACM, 2005: 14-29.

[8] Jurvansuu M, Prokkola J, Hanski M, et al.HSDPA performance in live networks [C]//IEEEInternational Conference on Communications(ICC ’07). Glasgow, Scotland: IEEE, 2007: 467-471.

[9] Derksen J, Jansen R, Maijala M, et al. HSDPAperformance and evolution [J]. Ericsson Review, 2006,83(3): 117-120.

[10] Bharambe A R, Herley C, Padmanabhan V

N. Analyzing and improving a BitTorrent network’sperformance mechanisms [C]//Proceedings of IEEEINFOCOM. Barcelona, Spain: IEEE, 2006: 1-12.