IP2P: a peer-to-peer system for mobile devices

IEEE Wireless Communications • April 200930 1536-1284/09/$25.00 © 2009 IEEE

Client (IPa:Porta)

User A

Private IPnetwork A

C.1 C.2 C.3

AC C E P T E D F R O M OP E N CALL

INTRODUCTIONPeer-to-peer (P2P) communication has becomeone of the major trends in wireless Internet. In aP2P system, a participating peer plays the roles ofboth client and server. Logically, the peers estab-lish P2P connections directly with each otherwithout passing through network servers. AnInternet-based P2P communication session con-sists of two phases: the identification phase andthe communications phase. In the identificationphase, the calling peer identifies the transportaddress of the called peer (i.e., the Internet Proto-col [IP] address and the port number). In thecommunications phase, the calling peer directlyconnects to the called peer based on the transportaddress retrieved in the identification phase.

Existing IP-based P2P systems can be catego-rized into two types: hybrid P2P and pure P2P.Hybrid P2P systems utilize centralized servers tomaintain the mapping between the identificationsand the transport addresses of the participatingpeers. The P2P connection procedure of a hybridP2P system consists of the following steps:Step A.1 To join the system, a peer starts the

P2P application, which attaches the peer tothe IP network.

Step A.2 The peer registers to the centralizedserver by providing its identification and thetransport address.

Step A.3 To initiate a P2P connection, the call-ing peer queries the centralized server to

retrieve the transport address of the calledpeer.

Step A.4 Upon receipt of the transport addressof the called peer, the calling peer establishesa P2P connection directly to the called peerwithout involving the centralized server.In this procedure, Steps A.1 and A.2 are exe-

cuted to maintain the mapping between the identi-fication and the transport address. Step A.3executes the identification phase, and the commu-nications phase starts with Step A.4. A hybrid P2Pexample is the conventional Session Initiation Pro-tocol (SIP) system, where the peers are SIP useragents (UAs), and the centralized server is a SIPregistrar server that maps the SIP uniformresource identifier (SIP-URI) to the transportaddress (IP address and port number) for eachregistered UA. A hybrid P2P system provides effi-cient query at the cost of maintaining the addressmapping in a centralized server (i.e., Steps A.1and A.2), which may incur a scalability problem.

In contrast, the identification mechanism of apure P2P system is distributed among the partic-ipating peers. Depending on how the peers com-municate in the identification phase, a pure P2Psystem can be unstructured or structured. In anunstructured P2P system, a query for identifyingthe transport address of a participating peer isflooded through the network. Unstructured P2Pis not required to maintain centralized mappingbetween the identifications and the transportaddresses at the cost of expensive flooding query.In contrast, in a structured P2P system, the iden-tification phase is achieved by a peer queryingother peers in a specific routing structure (e.g., aring, a grid, or a tree). A structured P2P exam-ple is the peer-to-peer SIP system [1] that uti-lizes the distributed hash table for transportaddress registration and query. Structured P2Pprovides efficient query in a decentralized fash-ion at the cost of maintaining the distributedmapping tables among the participating peers.

To implement a P2P system for mobile devicesthat have the capability to access mobile telecom-munications networks, such as the universalmobile telecommunications system (UMTS) [2,3], we propose a hybrid P2P system called iP2P.iP2P effectively reuses the UMTS mobility man-agement mechanism and short message service

CHIEN-CHUN HUANG-FU AND YI-BING LIN, NATIONAL CHIAO TUNG UNIVERSITYHERMAN CHUNG-HWA RAO, FAR EASTONE TELECOMMUNICATIONS CO., LTD.

ABSTRACT

Peer-to-peer communications is a major trendin wireless Internet. In a P2P system, the callingpeer must identify the network address of thecalled peer before establishing a P2P connection.This article proposes iP2P, a hybrid P2P systemfor mobile devices. iP2P utilizes the short mes-sage service as the control protocol to identify theaddress of the called peer. Our approach providesan efficient identification mechanism without therequirement for the maintenance of a centralizedregistrar server in a hybrid P2P system. We alsoshow how iP2P can integrate effectively with theexisting Network Address Translation traversalmechanisms to solve the private IP address issue.

IP2P: A PEER-TO-PEER SYSTEM FORMOBILE DEVICES

The authors proposeiP2P, a hybrid P2Psystem for mobiledevices. iP2P utilizesthe short messageservice as the controlprotocol to identifythe address of thecalled peer.

HUANG-FU LAYOUT 4/9/09 12:57 PM Page 30

IEEE Wireless Communications • April 2009 31

(SMS) as the control protocol in the identifica-tion phase and saves the power of the mobiledevices significantly. This article describes theiP2P system and shows how it works when thepeers are assigned private IP addresses.

IP2P SYSTEM ARCHITECTURE

In the iP2P system, a participating peer utilizesits mobile station ISDN number (MSISDN; thetelephone number) as the peer identification,which is globally unique. The iP2P control mes-sages are encapsulated in the short messages. Asillustrated in Fig. 1, the SMS delivery procedureconsists of the following steps: when the callingpeer (Fig. 1 (1)) sends a short message to thecalled peer (Fig. 1 (9)), this message is deliveredto the source mobile-switching center (MSC; Fig.1 (3)) through the base station subsystem (BSS;Fig. 1 (2)). The source MSC passes this messageto a short message service center (SMSC; Fig. 1(4)), which then forwards the message to the tar-get MSC (Fig. 1 (7)) through the SMS gatewayMSC (SMS GMSC; Fig. 1 (5)). The SMS GMSCidentifies the target MSC of the called peer byinterrogating the home location register (HLR;Fig. 1 (6)). Then the GMSC forwards the mes-sage to the target MSC that delivers the messageto the called peer (Fig. 1 (9)) through the BSS(Fig. 1 (8)). In this system, the HLR is the cen-tralized server that maps the telephone numberto the location of the called peer.

In iP2P, we assume that the mobile devicescan communicate with each other through theSMS network (path (a) → (b) → (c) → (d) →(e) in Fig. 1) or through the broadband wireless(BW) network (e.g., WiFi, WiMAX, or wide-band code division multiple access [WCDMA];path (f) in Fig. 1). In UMTS, both the SMS andthe WCDMA BW networks are accessed throughthe same base stations. We separate them in Fig.1 for the purposes of description.

With the background knowledge of SMS, wedescribe the iP2P modules in a mobile device.When a client application (e.g., a Telnet or FileTransfer Protocol [FTP] client; Fig. 2 (1)) is exe-cuted, a connection process is invoked for estab-lishing a connection to the server application inanother mobile device (Fig. 2 (2)). The iP2P con-trol function (Fig. 2 (3)) is responsible for access-ing the iP2P control messages through the SMSAPI (Fig. 2 (4)) and controlling the connectionthrough the iP2P socket API (Fig. 2 (5)). TheiP2P socket API is the standard socket API withminor modifications. Specifically, the domainname system (DNS) resolution procedure withinthe iP2P socket API is capable of recognizing theMSISDN format. If the domain name for DNSresolution is an MSISDN, the iP2P socket APIdoes not follow the standard procedure to querythe DNS server in the IP network. Instead, itdirectly passes the MSISDN to the iP2P controlfunction. The iP2P control function then queriesthe transport address of the called peer throughSMS (Fig. 2 (6) and path (a)→(b)→(c)→(d)→(e)in Fig. 1). After the calling peer has identifiedthe transport address of the called peer in theidentification phase, a BW module (Fig. 2 (7)) isactivated to deliver user data in the communica-tions phase (path (f) in Fig. 1).

A BW module provides high-speed access tothe IP network at a cost of consuming much morepower than the SMS module. For example, thepower consumption of Cisco PCM-350 is 390 mWin the idle mode and 1600 mW in the active mode,whereas the power consumption of the global sys-tem for mobile communications (GSM) module isabout 10mW in the idle mode [4]. Therefore, in amobile device, the BW modules are typicallyturned off, and only the SMS module (and thevoice module) is turned on to receive the signalsfrom the outside world. In iP2P, we assume thatthe called peer only turns on the SMS module inthe identification phase. After the called peerreceives the iP2P control message through SMS,its BW module is turned on to attach the calledpeer to the IP network. Then, the P2P connectioncan be established in the communications phase.

In most mobile telecom operations, the mobiledevices are not assigned static IP addresses. There-fore, this article assumes that an iP2P peer canreside in the public (or private) IP network inwhich the IP address is dynamically allocated, forexample, through the Dynamic Host ConfigurationProtocol (DHCP). Furthermore, when a callingpeer in the private IP network connects to a calledpeer outside its local network, a network addresstranslation (NAT) server is required to translatethe private transport addresses to a public trans-port address. For User Datagram Protocol (UDP)applications (e.g., Voice over IP) implemented iniP2P, the NAT traversing issue is solved by theinteractive-connectivity-establishment (ICE)mechanism [5]. On the other hand, for the Trans-mission Control Protocol (TCP) applications (e.g.,HTTP and FTP), the NAT server must monitorthe TCP connection state or the sequence numberin the TCP header to screen illegal packets. Wefocus on the TCP connection set up in this article.

IP2P CONNECTION SETUP FORPUBLIC IP NETWORK

Figure 2 illustrates the TCP connection estab-lishment between two iP2P users residing in thepublic IP network. In this case, no NAT is

�� Figure 1. Wireless and mobile service network architecture.

3

1 9

4 5

7

6

HLR

2 8e

dc

b

a

f

BSS BSSSMS networkSource MSC Target MSC

SMSC

Calling peer Called peerBW

networkBW

networkIP network

SMSGMSC


IEEE Wireless Communications • April 200932

involved. Assume that the SMS modules of bothpeers are activated, and the BW modules areturned off to save power (and therefore, aredetached from the IP network).Step B.1 User A activates the BW module,

attaches to the IP network, and obtains thepublic IP address IPA through the DHCP.Using User B’s MSISDN, User A starts theclient application (called App-A) and executesthe DNS resolution procedure with User B’sMSISDN. In DNS resolution, the iP2P socketAPI detects that the destination domain nameis an MSISDN. Instead of querying an exter-nal DNS server, the iP2P socket API reservesa local port (i.e., PortA) for App-A and passesthe application name and the App-A transportaddress (i.e., IPA:PortA) to the iP2P controlfunction.

Step B.2 User A’s iP2P control function sendsan iP2P control message including the App-Atransport address (IPA:PortA) and the applica-tion name (e.g., FTP) to user B through SMS.User A’s iP2P control function then listens onPortA.

Step B.3 Upon receipt of the iP2P control mes-sage, user B activates the BW module, attach-es to the IP network, and obtains the publicIP address IPB through the DHCP. Then, userB starts the corresponding server application(called App-B) and listens on PortB.

Step B.4 User B’s iP2P control function sendsthe App-B transport address (IPB:PortB) andthe application name to user A’s iP2P controlfunction through the BW and the IP networks.Upon receipt of user B’s response, user A’siP2P socket API maps user B’s MSISDN to itstransport address.

Step B.5 App-A establishes a TCP connection toApp-B through the IP network.

In this procedure, the identification phaseconsists of Steps B.1–B.4, and the communica-tions phase starts with Step B.5.

IP2P CONNECTION SET UP FORPRIVATE IP NETWORKS: STUNT #2

Suppose that the calling and the called peersreside in different private IP networks. Toresolve the NAT traversing issue for TCP, iP2Pmust adopt a NAT traversal mechanism [6–8] toestablish the P2P connection. In this section, weuse the STUNT #2 approach [6] as an exampleto illustrate how iP2P solves the NAT traversingissue for a P2P application.

First we describe the STUNT mechanismwhen both the server and the client applicationsalready have attached to the private IP networks.As shown in Fig. 3, user A (the STUNT client)resides in the private IP network A behind theNAT server NAT-A, and user B (the STUNTserver) resides in another private IP network Bbehind the NAT server NAT-B. The P2P con-nection set-up procedure is described as follows:Step C.0 At the beginning, both the user A client

application App-A and the user B server appli-cation App-B establish TCP connections (calledConnectionA and ConnectionB, respectively) toa proxy server in the public IP network andthen register their identifications to the proxyserver through these TCP connections. Con-nectionA and ConnectionB are always main-tained so that App-A and App-B can accessthe public IP network through the proxy server.

Step C.1 To inform user B to establish a P2Pconnection, user A sends a connection requestto the proxy server with user B’s identificationthrough ConnectionA. The proxy server then

�� Figure 2. iP2P connection setup (public-to-public).

B.5

B.5

B.2

B.1 B.2

B.3

B.1 B.4

B.1B.2

B.2

B.5B.3B.4

B.2B.5B.3B.4

B.4

B.4 B.4 B.5

Client

User A User B

1 Server2iP2P Control function iP2P Control function3

SMS API SMS API4

iP2P Socket API iP2P Socket API

SMS module

SMS Network

BW Network BW NetworkPublic IPnetwork

BW module

5

SMS module6

BW module7



relays this connection request to user Bthrough ConnectionB.

Step C.2 If user B accepts the connectionrequest, it replies with an acknowledgment touser A through the same path in the reversedirection.We note that ConnectionA and ConnectionB

are not used for P2P data transfer to avoid thescalability problem in the proxy server. Therefore,to establish a P2P connection directly betweenusers A and B, STUNT utilizes a port predictionserver to find the public transport addresses forthe private transport addresses of the peers atSteps C.3 and C.4 (described below). Then, thecorresponding mapping entries are created inNAT-A and NAT-B, respectively, at Steps C.7and C.8. Then, the P2P connection can be estab-lished directly between App-A and App-B.Step C.3 Upon receipt of user B’s acknowledg-

ment through ConnectionA, App-A reserves alocal port (i.e., Porta), and uses private trans-port addresses (IPa:Porta) to query a port pre-diction server in the public IP network [9]. Theport prediction server predicts a public trans-port address (IPA:PortA) that will be assignedby NAT-A to map to the private transportaddress (IPa:Porta) of the P2P connection.

Step C.4 Similarly, App-B reserves a local port(i.e., Portb) for the P2P connection andqueries the port prediction server to predictpublic transport addresses (IPB:PortB) to beassigned by NAT-B.

Step C.5 App-A sends the mapping of its publicand the private transport addresses (IPa:Porta↔ IPA:PortA) to App-B through ConnectionAand ConnectionB.

Step C.6 Similarly, App-B sends the mapping ofits public and the private transport addresses(IPb:Portb ↔ IPB:PortB) to App-A through thesame path in the reverse direction.

Step C.7 Upon receipt of App-A’s mapping ofits public and the private transport addresses,App-B sends a synchronize (SYN) packetfrom App-B’s private transport address(IPb:Portb) to App-A’s public transportaddress (IPA:PortA). This SYN packet is sentwith a time-to-live (TTL) parameter largeenough to enable the SYN packet to passthrough NAT-B so that the correspondingmapping entry can be created in NAT-B. Onthe other hand, the TTL value must be suffi-ciently small such that the packet is droppedbefore it arrives at NAT-A. If this SYN packetarrives at NAT-A before NAT-A has created

�� Figure 3. Connection setup of STUNT #2 approach.

Private IPnetwork B

Client (IPa:Porta)

User A

Server (IPb:Portb)

User B

NAT-A NAT-B

Private IPnetwork A

Proxy server

Public IP network

(I) Steps C.1-C.4

Port prediction server

C.1

C.1 C.1C.2

C.3 C.4

C.2

C.2 C.3 C.4 C.2 C.1

Private IPnetwork B

Client (IPa:Porta)

User A

Server (IPb:Portb)

User B

NAT-A NAT-B

Private IPnetwork A

Proxy server

Public IP network

(II) Steps C.5-C.8

C.5

C.5 C.5C.6

X

C.6

C.6 C.8 C.7 C.6 C.5C.8

C.7C.8

iP2P effectivelyreuses the UMTS

mobility management

mechanism andshort message

service (SMS) as thecontrol protocol inthe identification

phase and saves thepower of the mobiledevices significantly.



the corresponding mapping entry (which isperformed at Step C.8), NAT-A might regardit as an attack packet and block PortA in NAT-A. When this SYN packet passes throughNAT-B, NAT-B creates the mapping entry asillustrated in Table 1a. We assume that theSYN packet passes through NAT-B and isdropped before it arrives at NAT-A.

Step C.8 App-A waits for a period (so that thecorresponding mapping entry in NAT-B hasbeen created at Step C.7), and sends a SYNpacket from its private transport address(IPa:Porta) to App-B’s public transportaddress (IPB:PortB). Upon receipt of the SYNpacket, NAT-A creates the mapping entry asillustrated in Table 1b. This SYN packet pass-es through NAT-B because NAT-B alreadyhas the corresponding mapping entry. Uponreceipt of the SYN packet, App-B executesthe standard TCP three-way handshake proce-

dure, and the P2P connection is established.Figure 4 illustrates the connection set-up pro-

cedure of iP2P with the STUNT #2 approach.As described in the previous section, we assumethat the SMS modules of both peers are activat-ed, and the BW modules are turned off to savepower. The following steps are executed.Step D.1 User A activates the BW module,

attaches to the IP network, and obtains theprivate IP address IPa through the DHCP.User A then starts the client application App-A and executes the DNS resolution procedurewith user B’s MSISDN. The iP2P socket APIreserves a local port (i.e., Porta) for App-A,queries the port prediction server to obtain apredicted public transport address(IPA:PortA), and passes the application nameand the App-A mapping of its public and theprivate transport addresses (IPa:Porta ↔IPA:PortA) to the iP2P control function.

Step D.2 User A’s iP2P control function sendsan iP2P control message with the App-A map-ping of its public and the private transportaddresses (IPa:Porta ↔ IPA:PortA) and theapplication name to user B through SMS.

Step D.3 Upon receipt of the iP2P control mes-sage, user B activates the BW module, attach-es to the IP network, and obtains the privateIP address IPb through the DHCP. User Bthen starts the server application App-B,which listens on Portb. User B uses the privatetransport address (IPb:Portb) to query the portprediction server to obtain a predicted publictransport address (IPB:PortB).

Step D.4 According to the content of user A’siP2P control message, user B knows that userA is in a different private IP network. User B

�� Figure 4. iP2P connection setup with STUNT (private-to-private).

Private IPnetwork B

Private IPnetwork A

BWnetwork

Private IPnetwork

D.6 D.1

D.6 D.1

D.2D.4

D.2D.4 D.2 D.3 D.6

D.6

D.5D.4

D.4 D.2

D.3

D.2 D.3 D.6D.5D.4

D.2 D.3 D.6D.5D.4

D.4D.1

NAT-A NAT-B

SMS network

D.1

User A User B

Client ServeriP2P Control function iP2P Control function

iP2P Socket API iP2P Socket APISMS API SMS API

BW module BW moduleSMS module SMS module

D.1 D.3

D.5Port prediction server

Public IPnetwork

�� Table 1. The mapping entries in NAT servers.

(a) The mapping entry in NAT-B

Source address Alias address Destination address

IPb:Portb IPB:PortB IPA:PortA

(b) The mapping entry in NAT-A

Source address Alias address Destination address

IPa:Porta IPA:PortA IPB:PortB



replies with an iP2P control message with theApp-B public transport address (IPB:PortB)and the application name to user A throughSMS.

Step D.5 App-B sends a SYN packet with aproper TTL value from the App-B privatetransport address (IPb:Portb) to the App-Apublic transport address (IPA:PortA). Whenthis SYN packet passes through NAT-B, amapping entry is created in NAT-B as shownin Table 1a. We assume that the SYN packetis dropped before it arrives at NAT-A.

Step D.6 App-A waits for a period (so that thecorresponding mapping entry in NAT-B hasbeen created at Step D.5) and sends a SYNpacket from its private transport address(IPa:Porta) to the App-B public transportaddress (IPB:PortB). This SYN packet resultsin the mapping entry creation in NAT-A asshown in Table 1b. Upon receipt of this SYNpacket, App-B executes the standard TCPthree-way handshake procedure, and the P2Pconnection is established.Clearly, iP2P, with the STUNT #2 approach,

can solve the NAT traversing issue for TCP asthe conventional STUNT #2 approach withoutthe maintenance of the centralized proxy server(see Step C.0), and both ConnectionA and Con-nectionB are eliminated. Furthermore, the calledpeer is not required to attach to the IP networkbefore the iP2P connection is initiated. Notethat the STUNT solution may pose problems.First, setting an appropriate TTL value of theSYN packet (at Step C.7 and Step D.5) mightnot be trivial. Furthermore, the port predictionserver cannot guarantee to provide the precisemapping of the public and the private transportaddresses for all the NAT servers. For example,

some NAT servers randomly assign the mappingports, which cannot be predicted.

IP2P CONNECTION SET UP FORPRIVATE IP NETWORKS: UPNP

Universal plug and play (UPnP) [10] providesanother solution to solve NAT traversing forTCP. Usually, a UPnP system consists of severalUPnP clients and an Internet gateway device(IGD), which provides Internet connectivity forthe protected local area network (LAN). UPnPis a network protocol for automatic discoveryand configuration when a device (i.e., a UPnPclient) is online. Therefore, the mapping of thepublic and the private transport addresses inboth the UPnP client and the IGD can be estab-lished automatically by the UPnP protocol.UPnP can be integrated easily with iP2P to sup-port NAT traversal for the peers in different pri-vate IP networks. To support UPnP in an iP2Ppeer, the iP2P socket API must include theUPnP API functionalities, and the iP2P controlfunction on the mobile device is a UPnP client.In Fig. 5, suppose that both NAT-A and NAT-Bsupport the IGD functionalities. The steps ofiP2P connection set up are described as follows:Step E.1 User A activates the BW module,

attaches to the IP network, and obtains theprivate IP address IPa through the DHCP.User A starts the client application App-A andexecutes the DNS resolution procedure withuser B’s MSISDN. Because user A resides in aprivate IP network, its iP2P socket API issuesa UPnP multicast M-SEARCH request to iden-tify the IGD (i.e., NAT-A). Then, it sends aUPnP GetExternalIPAddress request to

�� Figure 5. iP2P connection setup with UPnP (private-to-private).

BW network

E.1 E.4E.5E.2

NAT-A (IGD) NAT-B (IGD)

E.1 E.4E.5 E.2

E.4 E.2E.1

User A

Client

Public IPnetwork

Private IPnetwork ABW network Private IP

network B

E.1

iP2P Control function

iP2P Socket API SMS API

BW module SMS module

E.3E.5E.2

E.4

E.3 E.5E.2

E.4

SMS network E.4

E.3

E.3

E.5E.2

User B

iP2P Control function

E.4

Server

SMS API iP2P Socket API

SMS module BW module

E.5



NAT-A to retrieve the NAT-A public IPaddress IPA. The iP2P socket API reserves alocal port Porta for App-A and sends a UPnPAddPortMapping request to NAT-A forestablishing the mapping entry in NAT-A (i.e.,IPa:Porta ↔ IPA:PortA illustrated in Table 1b).The iP2P socket API passes the public trans-port address (IPA:PortA) and the applicationname to the iP2P control function.

Step E.2 User A’s iP2P control function sendsan iP2P control message with its public trans-port address (IPA:PortA) and the applicationname to user B through SMS. The iP2P con-trol function then listens on Porta.

Step E.3 Upon receipt of user A’s iP2P controlmessage, user B activates the BW module,attaches to the private IP network, and obtainsthe private IP address IPb through the DHCP.User B’s iP2P control function then starts thecorresponding server application App-B, whichlistens on Portb. Because user B resides in a pri-vate IP network, it establishes the mapping entryin its IGD NAT-B (i.e., IPb:Portb ↔ IPB:PortBillustrated in Table 1a) following the UPnP mes-sage exchange as described in Step E.1.

Step E.4 User B’s iP2P control function sends itspublic transport address (IPB:PortB) and theapplication name to user A through the IPnetwork by using user A’s public transportaddress (IPA:PortA). This message can passthrough NAT-A because the correspondingmapping entry (IPa:Porta ↔ IPA:PortA) hasalready been created in NAT-A at Step E.1.Upon receipt of user B’s response, user A’siP2P control function passes the App-B publictransport address (IPB:PortB) to the iP2P sock-et API. Then, the iP2P socket API maps userB’s MSISDN to its public transport address.

Step E.5 Because the corresponding mappingentry (IPb:Portb ↔ IPB:PortB) was created inNAT-B at Step E.3, App-A can establish theP2P connection with App-B by using the App-B public transport address (IPB:PortB).Compared with the traditional UPnP

approach, iP2P does not require the called peer(i.e., user B) to attach to the IP network beforethe iP2P connection is initiated. Also, no cen-tralized server is required.

CONCLUSIONS

This article proposed an innovative P2P systemcalled iP2P, which reuses the UMTS mobilitymanagement mechanism and SMS as the controlprotocol. We implemented the iP2P system onthe Windows Mobile 6.0 Professional operatingsystem. The measured data from 200 experi-ments indicates 21.724 seconds for the averageconnection set-up time, 2.637 seconds for theaverage SMS delivery time, and 9.428 secondsfor the average WiFi network attachment time.

iP2P has several advantages over the existingP2P systems. First, by reusing the UMTS mobili-ty management mechanism, iP2P provides effi-cient query without a requirement to implementits own centralized server. Because the UMTSnetwork typically supports millions of users,there is no scalability problem in our approach.Second, iP2P utilizes the SMS push mechanismto establish P2P connections, which can signifi-

cantly save power consumption in the mobiledevices. Third, iP2P allows more flexible IPaddress allocation because the called peer is notrequired to attach to the IP network until itreceives the SMS-based iP2P control message inthe identification phase.

We also showed that iP2P can integrate easilywith the existing NAT-traversal mechanisms to sup-port mobile devices residing in the private IP net-works. The performance of these mechanisms canbe found in [11]. The mechanism of iP2P is pend-ing U.S. and Republic of China (R.O.C.) patents.

ACKNOWLEDGMENTThis work was sponsored in part by NSC 97-2221-E-009-143-MY3, NSC 97-2219-E009-016,Far Eastone Telecom, Chung Hwa Telecom,ITRI/NCTU Joint Research Center, and MoEATU.

REFERENCES[1] D. Bryan et al., “Concepts and Terminology for Peer to

Peer SIP,” IETF Internet draft, Mar. 2007.[2] Y.-B. Lin and I. Chlamtac, Wireless and Mobile Network

Architectures, Wiley, 2001.[3] Y.-B. Lin and A.-C. Pang, Wireless and Mobile All-IP Net-

works, Wiley, 2005.[4] T. Pering et al., “CoolSpots: Reducing the Power Con-

sumption of Wireless Mobile Devices with MultipleRadio Interfaces,” Proc. 4th MobiSys, 2006.

[5] J. Rosenberg, “Interactive Connectivity Establishment(ICE),” IETF Internet draft, Oct. 2007.

[6] S. Guha, Y. Taked, and P. Francis, “NUTSS: A SIP-BasedApproach to UDP and TCP Network Connectivity,” Proc.SIGCOMM ‘04 Wksps., Aug. 2004, pp. 43–48.

[7] A. Biggadike et al., “NATBlaster: Establishing TCP Con-nections between Hosts behind NATs,” Proc. ACM SIG-COMM ASIA Wksp., Apr. 2005.

[8] J. Rosenberg, “TCP Candidates with Interactive Connec-tivity Establishment (ICE),” IETF Internet draft, Nov.2007.

[9] S. Guha and P. Francis, “Characterization and Measure-ment of TCP Traversal through NATs and Firewalls,”Proc. 2005 Internet Measurement Conf., Oct. 2005.

[10] UPnP Forum, “Internet Gateway Device (IGD) Stan-dardized Device Control Protocol,” v. 1.0, 2001.

[11] W.-E. Chen, Y.-L. Huang, and H.-C. Chao, “NATTraversing Solutions for SIP Applications,” J. WirelessCommun. Net., 2008.

BIOGRAPHIESCHIEN-CHUN HUANG-FU ([email protected]) received hisB.S.CSIE and M.S.CSIE degrees from National Chiao TungUniversity (NCTU), Taiwan, in 1999 and 2001, respectively.He is currently a Ph.D. candidate in the Department ofComputer Science, NCTU. His current research interestsinclude peer-to-peer networks, design and analysis of per-sonal communications services networks, and mobile adhoc networks.

YI-BING LIN [F] ([email protected]) is Chair Professorand Dean of the College of Computer Science, NCTUn. Hiscurrent research interests include mobile computing andcellular telecommunications services. He is the co-author ofthe books Wireless and Mobile Network Architecture (withImrich Chlamtac; Wiley, 2001), Wireless and Mobile All-IPNetworks (with Ai-Chun Pang; Wiley, 2005), and Chargingfor Mobile All-IP Telecommunications (with Sok-Ian Sou;Wiley, 2008). He is a Fellow of ACM, AAAS, and IET.

HERMAN RAO ([email protected]) has a B.S. inmechanical engineering from National Taiwan Universityand a doctorate in computer science from the University ofArizona. He is currently the executive vice president of theNetwork & Technology Division at Far EasTone Telecommu-nications Co., LTD, Taiwan. Prior to joining Far EasTone, heworked at Bell Labs as a senior researcher and at AWS as aresearch director for 10 years. In addition to extensiveindustry experience in telecommunication and data com-munication, he was an associate professor at NationalTsing-Hua University and National Chung-Cheng University.

iP2P can integrateeasily with the existing NAT-traversalmechanisms to support mobiledevices residing inthe private IP networks. Themechanism of iP2Pis pending U.S. andRepublic of China(R.O.C.) patents.


Documents

IP2P: a peer-to-peer system for mobile devices