IP2P: A PEER-TO-PEER SYSTEM FOR MOBILE DEVICES

Client (IP_a:Port_a) User A

Private IP network A C.1 C.2 C.3

A

CCEPTED FROM

O

PEN

C

ALL

I

NTRODUCTION

Peer-to-peer (P2P) communication has become one of the major trends in wireless Internet. In a P2P system, a participating peer plays the roles of both client and server. Logically, the peers estab-lish P2P connections directly with each other without passing through network servers. An Internet-based P2P communication session con-sists of two phases: the identification phase and the communications phase. In the identification phase, the calling peer identifies the transport address of the called peer (i.e., the Internet Proto-col [IP] address and the port number). In the communications phase, the calling peer directly connects to the called peer based on the transport address 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 to maintain the mapping between the identifications and the transport addresses of the participating peers. The P2P connection procedure of a hybrid P2P system consists of the following steps:

Step A.1To join the system, a peer starts the P2P application, which attaches the peer to the IP network.

Step A.2The peer registers to the centralized server by providing its identification and the transport address.

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

retrieve the transport address of the called peer.

Step A.4Upon receipt of the transport address of the called peer, the calling peer establishes a P2P connection directly to the called peer without 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.3 executes the identification phase, and the commu-nications phase starts with Step A.4. A hybrid P2P example is the conventional Session Initiation Pro-tocol (SIP) system, where the peers are SIP user agents (UAs), and the centralized server is a SIP registrar server that maps the SIP uniform resource identifier (SIP-URI) to the transport address (IP address and port number) for each registered UA. A hybrid P2P system provides effi-cient query at the cost of maintaining the address mapping in a centralized server (i.e., Steps A.1 and A.2), which may incur a scalability problem.

In contrast, the identification mechanism of a pure P2P system is distributed among the partic-ipating peers. Depending on how the peers com-municate in the identification phase, a pure P2P system can be unstructured or structured. In an unstructured P2P system, a query for identifying the transport address of a participating peer is flooded through the network. Unstructured P2P is not required to maintain centralized mapping between the identifications and the transport addresses at the cost of expensive flooding query. In contrast, in a structured P2P system, the iden-tification phase is achieved by a peer querying other peers in a specific routing structure (e.g., a ring, 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 transport address registration and query. Structured P2P provides efficient query in a decentralized fash-ion at the cost of maintaining the distributed mapping tables among the participating peers.

To implement a P2P system for mobile devices that have the capability to access mobile telecom-munications networks, such as the universal mobile 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

C

-C

H

-F

Y

-B

L

, N

C

T

U

H

C

-H

R

, F

E

T

T

C

., L

.

A

BSTRACT

Peer-to-peer communications is a major trend in wireless Internet. In a P2P system, the calling peer must identify the network address of the called peer before establishing a P2P connection. This article proposes iP2P, a hybrid P2P system for mobile devices. iP2P utilizes the short mes-sage service as the control protocol to identify the address of the called peer. Our approach provides an efficient identification mechanism without the requirement for the maintenance of a centralized registrar server in a hybrid P2P system. We also show how iP2P can integrate effectively with the existing Network Address Translation traversal mechanisms to solve the private IP address issue.

I

P2P: A P

EER

-

TO

-P

EER

S

YSTEM FOR

M

OBILE

D

EVICES

The authors propose

iP2P, a hybrid P2P

system for mobile

devices. iP2P utilizes

the short message

service as the control

protocol to identify

the address of the

called peer.

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

I

P2P S

YSTEM

A

RCHITECTURE

In the iP2P system, a participating peer utilizes its mobile station ISDN number (MSISDN; the telephone number) as the peer identification, which is globally unique. The iP2P control mes-sages are encapsulated in the short mesmes-sages. As illustrated in Fig. 1, the SMS delivery procedure consists of the following steps: when the calling peer (Fig. 1 (1)) sends a short message to the called peer (Fig. 1 (9)), this message is delivered to the source mobile-switching center (MSC; Fig. 1 (3)) through the base station subsystem (BSS; Fig. 1 (2)). The source MSC passes this message to 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 gateway MSC (SMS GMSC; Fig. 1 (5)). The SMS GMSC identifies the target MSC of the called peer by interrogating the home location register (HLR; Fig. 1 (6)). Then the GMSC forwards the mes-sage to the target MSC that delivers the mesmes-sage to 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 number to the location of the called peer.

In iP2P, we assume that the mobile devices can communicate with each other through the SMS 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 and the WCDMA BW networks are accessed through the same base stations. We separate them in Fig. 1 for the purposes of description.

With the background knowledge of SMS, we describe the iP2P modules in a mobile device. When a client application (e.g., a Telnet or File Transfer Protocol [FTP] client; Fig. 2 (1)) is exe-cuted, a connection process is invoked for estab-lishing a connection to the server application in another mobile device (Fig. 2 (2)). The iP2P con-trol function (Fig. 2 (3)) is responsible for access-ing the iP2P control messages through the SMS API (Fig. 2 (4)) and controlling the connection through the iP2P socket API (Fig. 2 (5)). The iP2P socket API is the standard socket API with minor modifications. Specifically, the domain name system (DNS) resolution procedure within the iP2P socket API is capable of recognizing the MSISDN format. If the domain name for DNS resolution is an MSISDN, the iP2P socket API does not follow the standard procedure to query the DNS server in the IP network. Instead, it directly passes the MSISDN to the iP2P control function. The iP2P control function then queries the transport address of the called peer through SMS (Fig. 2 (6) and path (a)→(b)→(c)→(d)→(e) in Fig. 1). After the calling peer has identified the transport address of the called peer in the identification phase, a BW module (Fig. 2 (7)) is activated to deliver user data in the communica-tions phase (path (f) in Fig. 1).

A BW module provides high-speed access to the IP network at a cost of consuming much more power than the SMS module. For example, the power consumption of Cisco PCM-350 is 390 mW in the idle mode and 1600 mW in the active mode, whereas the power consumption of the global sys-tem for mobile communications (GSM) module is about 10mW in the idle mode [4]. Therefore, in a mobile device, the BW modules are typically turned off, and only the SMS module (and the voice module) is turned on to receive the signals from the outside world. In iP2P, we assume that the called peer only turns on the SMS module in the identification phase. After the called peer receives the iP2P control message through SMS, its BW module is turned on to attach the called peer to the IP network. Then, the P2P connection can be established in the communications phase.

In most mobile telecom operations, the mobile devices are not assigned static IP addresses. There-fore, this article assumes that an iP2P peer can reside in the public (or private) IP network in which the IP address is dynamically allocated, for example, through the Dynamic Host Configuration Protocol (DHCP). Furthermore, when a calling peer in the private IP network connects to a called peer outside its local network, a network address translation (NAT) server is required to translate the private transport addresses to a public trans-port address. For User Datagram Protocol (UDP) applications (e.g., Voice over IP) implemented in iP2P, the NAT traversing issue is solved by the interactive-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 monitor the TCP connection state or the sequence number in the TCP header to screen illegal packets. We focus on the TCP connection set up in this article.

I

P2P C

ONNECTION

S

ETUP FOR

P

UBLIC

IP N

ETWORK

Figure 2 illustrates the TCP connection estab-lishment between two iP2P users residing in the public 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 8 e d c b a f

BSS Source MSC _{SMS network} Target MSC BSS SMSC

Calling peer networkBW Called peer

BW network IP network

SMS GMSC

involved. Assume that the SMS modules of both peers are activated, and the BW modules are turned off to save power (and therefore, are detached from the IP network).

Step B.1User A activates the BW module, attaches to the IP network, and obtains the public IP address IPAthrough the DHCP.

Using User B’s MSISDN, User A starts the client application (called App-A) and executes the DNS resolution procedure with User B’s MSISDN. In DNS resolution, the iP2P socket API detects that the destination domain name is an MSISDN. Instead of querying an exter-nal DNS server, the iP2P socket API reserves a local port (i.e., PortA) for App-A and passes

the application name and the App-A transport address (i.e., IPA:PortA) to the iP2P control

function.

Step B.2User A’s iP2P control function sends an iP2P control message including the App-A transport address (IPA:PortA) and the

applica-tion name (e.g., FTP) to user B through SMS. User A’s iP2P control function then listens on PortA.

Step B.3Upon receipt of the iP2P control mes-sage, user B activates the BW module, attach-es to the IP network, and obtains the public IP address IPBthrough the DHCP. Then, user

B starts the corresponding server application (called App-B) and listens on PortB.

Step B.4User B’s iP2P control function sends the App-B transport address (IPB:PortB) and

the application name to user A’s iP2P control function through the BW and the IP networks. Upon receipt of user B’s response, user A’s iP2P socket API maps user B’s MSISDN to its transport address.

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

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

I

P2P C

ONNECTION

S

ET

U

P FOR

P

RIVATE

IP N

ETWORKS

: STUNT #2

Suppose that the calling and the called peers reside in different private IP networks. To resolve the NAT traversing issue for TCP, iP2P must adopt a NAT traversal mechanism [6–8] to establish the P2P connection. In this section, we use the STUNT #2 approach [6] as an example to illustrate how iP2P solves the NAT traversing issue for a P2P application.

First we describe the STUNT mechanism when both the server and the client applications already 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 the NAT server NAT-A, and user B (the STUNT server) resides in another private IP network B behind the NAT server NAT-B. The P2P con-nection set-up procedure is described as follows:

Step C.0At the beginning, both the user A client application App-A and the user B server appli-cation App-B establish TCP connections (called ConnectionAand ConnectionB, respectively) to

a proxy server in the public IP network and then register their identifications to the proxy server through these TCP connections. Con-nectionAand ConnectionB are always

main-tained so that App-A and App-B can access the public IP network through the proxy server.

Step C.1To inform user B to establish a P2P connection, user A sends a connection request to the proxy server with user B’s identification through 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.1 B.2 B.2 B.5 B.3 B.4 B.2 B.4 B.3 B.5 B.4 B.4 B.4 B.5 Client User A User B 1 Server 2

iP2P Control function iP2P Control function

3

SMS API SMS API

4

iP2P Socket API iP2P Socket API

SMS module

SMS Network

BW Network Public IP_network BW Network

BW module 5 SMS module 6 BW module 7

relays this connection request to user B through ConnectionB.

Step C.2If user B accepts the connection request, it replies with an acknowledgment to user A through the same path in the reverse direction.

We note that ConnectionAand ConnectionB

are not used for P2P data transfer to avoid the scalability problem in the proxy server. Therefore, to establish a P2P connection directly between users A and B, STUNT utilizes a port prediction server to find the public transport addresses for the private transport addresses of the peers at Steps C.3 and C.4 (described below). Then, the corresponding mapping entries are created in NAT-A and NAT-B, respectively, at Steps C.7 and C.8. Then, the P2P connection can be estab-lished directly between App-A and App-B.

Step C.3Upon receipt of user B’s acknowledg-ment through ConnectionA, App-A reserves a

local 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]. The port prediction server predicts a public trans-port address (IPA:PortA) that will be assigned

by NAT-A to map to the private transport address (IPa:Porta) of the P2P connection.

Step C.4Similarly, App-B reserves a local port (i.e., Portb) for the P2P connection and

queries the port prediction server to predict public transport addresses (IPB:PortB) to be

assigned by NAT-B.

Step C.5App-A sends the mapping of its public and the private transport addresses (IPa:Porta

↔ IPA:PortA) to App-B through ConnectionA

and ConnectionB.

Step C.6Similarly, App-B sends the mapping of its public and the private transport addresses (IPb:Portb↔ IPB:PortB) to App-A through the

same path in the reverse direction.

Step C.7Upon receipt of App-A’s mapping of its public and the private transport addresses, App-B sends a synchronize (SYN) packet from App-B’s private transport address (IPb:Portb) to App-A’s public transport

address (IPA:PortA). This SYN packet is sent

with a time-to-live (TTL) parameter large enough to enable the SYN packet to pass through NAT-B so that the corresponding mapping entry can be created in NAT-B. On the other hand, the TTL value must be suffi-ciently small such that the packet is dropped before it arrives at NAT-A. If this SYN packet arrives at NAT-A before NAT-A has created



Figure 3. Connection setup of STUNT #2 approach.

Private IP network B Client (IP_a:Port_a)

User A

Server (IP_b:Port_b) User B

NAT-A NAT-B

Private IP

network A Proxy server

Public IP network

(I) Steps C.1-C.4 Port prediction server C.1 C.1 C.1 C.2 C.3 C.4 C.2 C.2 C.3 C.4 C.2 C.1 Private IP network B Client (IP_a:Port_a)

User A

Server (IP_b:Port_b) User B NAT-A NAT-B Private IP network A Proxy server Public IP network (II) Steps C.5-C.8 C.5 C.5 C.5 C.6 X C.6 C.6 C.8 C.8 C.7 C.6 C.5 C.7 C.8

iP2P effectively

reuses the UMTS

mobility

management

mechanism and

short message

service (SMS) as the

control protocol in

the identification

phase and saves the

power of the mobile

devices significantly.

the corresponding mapping entry (which is performed at Step C.8), NAT-A might regard it as an attack packet and block PortAin

NAT-A. When this SYN packet passes through NAT-B, NAT-B creates the mapping entry as illustrated in Table 1a. We assume that the SYN packet passes through NAT-B and is dropped before it arrives at NAT-A.

Step C.8App-A waits for a period (so that the corresponding mapping entry in NAT-B has been created at Step C.7), and sends a SYN packet from its private transport address (IPa:Porta) to App-B’s public transport

address (IPB:PortB). Upon receipt of the SYN

packet, NAT-A creates the mapping entry as illustrated in Table 1b. This SYN packet pass-es through NAT-B because NAT-B already has the corresponding mapping entry. Upon receipt of the SYN packet, App-B executes the 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 assume that the SMS modules of both peers are activat-ed, and the BW modules are turned off to save power. The following steps are executed.

Step D.1User A activates the BW module, attaches to the IP network, and obtains the private IP address IPathrough the DHCP.

User A then starts the client application App-A and executes the DNS resolution procedure with user B’s MSISDN. The iP2P socket API reserves a local port (i.e., Porta) for App-A,

queries the port prediction server to obtain a predicted public transport address (IPA:PortA), and passes the application name

and the App-A mapping of its public and the private transport addresses (IPa:Porta↔

IPA:PortA) to the iP2P control function.

Step D.2User A’s iP2P control function sends an iP2P control message with the App-A map-ping of its public and the private transport addresses (IPa:Porta↔ IPA:PortA) and the

application name to user B through SMS.

Step D.3Upon receipt of the iP2P control mes-sage, user B activates the BW module, attach-es to the IP network, and obtains the private IP address IPbthrough the DHCP. User B

then starts the server application App-B, which listens on Portb. User B uses the private

transport address (IPb:Portb) to query the port

prediction server to obtain a predicted public transport address (IPB:PortB).

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



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

Private IP network B Private IP network A BW network Private IP network D.6 _D.1 D.6 D.1 D.2 D.4 D.2 D.4 D.2 D.3 D.6 D.6 D.5 D.4 D.4 D.2 D.3 D.2 D.4 D.3 D.5 D.6 D.2 D.4 D.3 D.5 D.6 D.4 D.1 NAT-A NAT-B SMS network D.1 User A User B

Client iP2P Control function iP2P Control function Server

iP2P Socket API SMS API SMS API iP2P Socket API

BW module SMS module SMS module BW module

D.1 D.3

D.5 Port prediction server

Public IP network



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

replies with an iP2P control message with the App-B public transport address (IPB:PortB)

and the application name to user A through SMS.

Step D.5App-B sends a SYN packet with a proper TTL value from the App-B private transport address (IPb:Portb) to the App-A

public transport address (IPA:PortA). When

this SYN packet passes through NAT-B, a mapping entry is created in NAT-B as shown in Table 1a. We assume that the SYN packet is dropped before it arrives at NAT-A.

Step D.6App-A waits for a period (so that the corresponding mapping entry in NAT-B has been created at Step D.5) and sends a SYN packet from its private transport address (IPa:Porta) to the App-B public transport

address (IPB:PortB). This SYN packet results

in the mapping entry creation in NAT-A as shown in Table 1b. Upon receipt of this SYN packet, App-B executes the standard TCP three-way handshake procedure, and the P2P connection is established.

Clearly, iP2P, with the STUNT #2 approach, can solve the NAT traversing issue for TCP as the conventional STUNT #2 approach without the maintenance of the centralized proxy server (see Step C.0), and both ConnectionAand

Con-nectionBare eliminated. Furthermore, the called

peer is not required to attach to the IP network before the iP2P connection is initiated. Note that the STUNT solution may pose problems. First, setting an appropriate TTL value of the SYN packet (at Step C.7 and Step D.5) might not be trivial. Furthermore, the port prediction server cannot guarantee to provide the precise mapping of the public and the private transport addresses for all the NAT servers. For example,

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

I

P2P C

ONNECTION

S

ET

U

P FOR

P

RIVATE

IP N

ETWORKS

: UP

N

P

Universal plug and play (UPnP) [10] provides another solution to solve NAT traversing for TCP. Usually, a UPnP system consists of several UPnP clients and an Internet gateway device (IGD), which provides Internet connectivity for the protected local area network (LAN). UPnP is a network protocol for automatic discovery and configuration when a device (i.e., a UPnP client) is online. Therefore, the mapping of the public and the private transport addresses in both 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 iP2P peer, the iP2P socket API must include the UPnP API functionalities, and the iP2P control function on the mobile device is a UPnP client. In Fig. 5, suppose that both NAT-A and NAT-B support the IGD functionalities. The steps of iP2P connection set up are described as follows:

Step E.1User A activates the BW module, attaches to the IP network, and obtains the private IP address IPathrough the DHCP.

User A starts the client application App-A and executes the DNS resolution procedure with user B’s MSISDN. Because user A resides in a private IP network, its iP2P socket API issues a UPnP multicast M-SEARCH request to iden-tify the IGD (i.e., NAT-A). Then, it sends a UPnP GetExternalIPAddress request to



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

BW network

E.1 E.4

E.5 E.2

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

E.1 _E.4 E.5 E.2 E.4 E.2 E.1 User A Client Public IP network Private IP network A

BW network _{network B}Private IP

E.1

iP2P Control function

iP2P Socket API SMS API

BW module SMS module E.3 E.5 E.2 E.4 E.3 E.5 E.2 E.4 SMS network _E.4 E.3 E.3 E.5 E.2 User B

iP2P Control function E.4

Server

SMS API iP2P Socket API

SMS module BW module

NAT-A to retrieve the NAT-A public IP address IPA. The iP2P socket API reserves a

local port Portafor App-A and sends a UPnP

AddPortMapping request to NAT-A for establishing the mapping entry in NAT-A (i.e., IPa:Porta↔ IPA:PortAillustrated in Table 1b).

The iP2P socket API passes the public trans-port address (IPA:PortA) and the application

name to the iP2P control function.

Step E.2User A’s iP2P control function sends an iP2P control message with its public trans-port address (IPA:PortA) and the application

name to user B through SMS. The iP2P con-trol function then listens on Porta.

Step E.3 Upon receipt of user A’s iP2P control message, user B activates the BW module, attaches to the private IP network, and obtains the private IP address IPbthrough the DHCP.

User B’s iP2P control function then starts the corresponding server application App-B, which listens on Portb. Because user B resides in a

pri-vate IP network, it establishes the mapping entry in its IGD NAT-B (i.e., IPb:Portb↔ IPB:PortB

illustrated in Table 1a) following the UPnP mes-sage exchange as described in Step E.1.

Step E.4User B’s iP2P control function sends its public transport address (IPB:PortB) and the

application name to user A through the IP network by using user A’s public transport address (IPA:PortA). This message can pass

through NAT-A because the corresponding mapping entry (IPa:Porta↔ IPA:PortA) has

already been created in NAT-A at Step E.1. Upon receipt of user B’s response, user A’s iP2P control function passes the App-B public transport address (IPB:PortB) to the iP2P

sock-et API. Then, the iP2P socksock-et API maps user B’s MSISDN to its public transport address.

Step E.5Because the corresponding mapping entry (IPb:Portb↔ IPB:PortB) was created in

NAT-B at Step E.3, App-A can establish the P2P connection with 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 before the iP2P connection is initiated. Also, no cen-tralized server is required.

C

ONCLUSIONS

This article proposed an innovative P2P system called iP2P, which reuses the UMTS mobility management mechanism and SMS as the control protocol. We implemented the iP2P system on the Windows Mobile 6.0 Professional operating system. The measured data from 200 experi-ments indicates 21.724 seconds for the average connection set-up time, 2.637 seconds for the average SMS delivery time, and 9.428 seconds for the average WiFi network attachment time.

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

signifi-cantly save power consumption in the mobile devices. Third, iP2P allows more flexible IP address allocation because the called peer is not required to attach to the IP network until it receives the SMS-based iP2P control message in the identification phase.

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

ACKNOWLEDGMENT

This 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 MoE ATU.

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 Multiple Radio 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-Based Approach 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, “NAT

Traversing Solutions for SIP Applications,” J. Wireless

Commun. Net., 2008.

BIOGRAPHIES

CHIEN-CHUNHUANG-FU(jjfu@cs.nctu.edu.tw) received his B.S.CSIE and M.S.CSIE degrees from National Chiao Tung University (NCTU), Taiwan, in 1999 and 2001, respectively. He is currently a Ph.D. candidate in the Department of Computer Science, NCTU. His current research interests include peer-to-peer networks, design and analysis of per-sonal communications services networks, and mobile ad hoc networks.

YI-BINGLIN[F] (liny@csie.nctu.edu.tw) is Chair Professor and Dean of the College of Computer Science, NCTUn. His current research interests include mobile computing and cellular telecommunications services. He is the co-author of the books Wireless and Mobile Network Architecture (with Imrich Chlamtac; Wiley, 2001), Wireless and Mobile All-IP

Networks (with Ai-Chun Pang; Wiley, 2005), and Charging for Mobile All-IP Telecommunications (with Sok-Ian Sou;

Wiley, 2008). He is a Fellow of ACM, AAAS, and IET. HE R M A NRA O(hrao@fareastone.com.tw) has a B.S. in mechanical engineering from National Taiwan University and a doctorate in computer science from the University of Arizona. He is currently the executive vice president of the Network & Technology Division at Far EasTone Telecommu-nications Co., LTD, Taiwan. Prior to joining Far EasTone, he worked at Bell Labs as a senior researcher and at AWS as a research director for 10 years. In addition to extensive industry experience in telecommunication and data com-munication, he was an associate professor at National Tsing-Hua University and National Chung-Cheng University.

iP2P can integrate

easily with the

existing NAT-traversal

mechanisms to

support mobile

devices residing in

the private IP

networks. The

mechanism of iP2P

is pending U.S. and

Republic of China

(R.O.C.) patents.