iPTT: Peer-to-Peer Push-to-Talk for VoIPJiun-Ren Lin∗ and Ai-Chun Pang+∗

∗Department of Computer Science and Information Engineering+Graduate Institute of Networking and Multimedia

National Taiwan UniversityTaipei, Taiwan, R.O.C.

Email: jrlin@newslab.csie.ntu.edu.tw, acpang@csie.ntu.edu.tw

Abstract— This paper proposes iPTT, a peer-to-peer Push-to-Talk (PTT) service for Voice over IP (VoIP). In iPTT, a dis-tributed and mobile-operator independent network architectureis presented to accelerate the deployment of the PTT service.Based on the proposed architecture, the message flows for callestablishment/teardown are designed to show the feasibility ofiPTT. Also, we propose two mechanisms for real-time talk-burst determination, flooding-based floor control mechanism(FFC) and tree-based floor control mechanism (TFC). In termsof the determination latency and the number of floor-controlmessage exchanges, the performance of the proposed floor controlmechanisms is investigated through our analytical and simulationmodels.

I. I NTRODUCTION

With the explosive growth of the Internet subscriber popu-lation, supporting Internet telephony service, also known asVoice over IP (VoIP), is considered as a promising trendin the telecommunication business. In addition to globally-deployed wired Internet telephony services [1], [2], integratingVoIP into mobile/wireless systems (e.g., 3G/GPRS, IEEE802.11 and IEEE 802.16) is extensively studied/developed,and becomes an important issue [3], [4]. Particularly, 3GPPintroduced the IP Multimedia core network Subsystem (IMS)for Universal Mobile Telecommunications Systems (UMTS) toprovide real-time services such as VoIP over an all-IP networkarchitecture [5], [6], [7].

With various wireless-VoIP applications, a walkie-talkie likeservice, also called Push-to-Talk (PTT), is gaining significantinterest in the mobile telecommunications industry [8]. PTT isa half-duplex voice service that allows user-to-user and groupcommunications. Unlike conventional walkie-talkie systems,the PTT service is supported by ubiquitous wireless accessand thus not geographically restricted. A PTT session amonga group of users is easily initiated by pressing a button, and thegroup members take turns talking when they obtain the floor.With PTT, a group conversation is supported, and the radioresources consumed by a multi-user call session are greatlyreduced by the half-duplex voice transmission.

The existing PTT-over-cellular (PoC) solutions are providedby several mobile operators/venders [9], [10]. However, thelack of specifications and standards for PoC systems leadsto a difficulty in supporting inter-operator roaming and com-patibility between the user equipment of different vendors.To promote interoperability between different PTT equipmentand networks, the Open Mobile Alliance (OMA) is working

on developing the specifications of PoC [11]. The OMA PoCspecifications utilize Session Initiation Protocol (SIP) for callsignaling, and adopt a centralized architecture to support voicedata broadcasting and multi-user coordination. A lot of workhas been done to design and evaluate an OMA-based orproprietary PoC system [12], [13], [14], [15], [16], [17]. Inan OMA-based centralized PTT architecture, a core node, i.e.,PoC server, is responsible for call/floor control and voice relay.Such an architecture is intuitive and easy to implement, butthe following issues should be addressed.

Scalability: The capacity of a centralized PTT systemis limited to the capability of a server.

Cost: Maintenance of a standalone server incurs extracosts.

Reliability: The crash of the server results in the failureof an entire system. Also, the occurrence of con-gestion at the server significantly degrades systemperformance.

Different from the OMA-based design, a hierarchical Peer-to-Peer (P2P) service model is proposed to provide a scalable,cost-effective and robust PTT service, called iPTT. Our iPTT isimplemented based on standard SIP/RTP (Real-time TransportProtocol)/RTCP (Real-time Transport Control Protocol), anddoes not rely on any functionalities provided by the underlyingmobile networks. The network architecture and message flowsfor call establishment/teardown are presented to show thefeasibility of iPTT. Furthermore, in iPTT, whether the real-time voice communications could be achieved depends on theefficiency of the talk-burst determination (i.e., floor control).We develop two floor control mechanisms, i.e., flooding-basedfloor control mechanism (FFC) and tree-based floor controlmechanism (TFC), for real-time talk-burst determination overa distributed PTT system. The performance of the proposedmechanisms is investigated through our analytical and simu-lation models. A series of experiments are conducted to showthe capabilities of our FFC and TFC.

Note that in Skype [18], [19], a P2P voice conferencingservice is provided for multi-user communications. With thefull-duplex transmission in Skype, a voice mixer with high-performance computing is needed. The maximum number ofconferencing group members is bound by the computing power

of the voice mixer1. Also, more radio and network resourcesare consumed for a full-duplex voice conferencing session thanfor our iPTT group communications.

The rest of this paper is organized as follows: Section IIdescribes the iPTT network architecture and message flowsfor call establishment/teardown. Section III presents our floorcontrol mechanisms for iPTT and elaborates on the detailedflows based on the proposed mechanisms. Section IV presentsthe analytical and simulation models, and summarizes ourexperimental results to demonstrate the capability of our iPTT-based floor control mechanisms. Section V is the conclusion.

II. N ETWORK ARCHITECTURE ANDMESSAGEFLOWS FOR

IPTT

This section elaborates on our iPTT network architecturebased on the P2P service model. Also, the message flows forsignaling and voice transmission are presented to show thefeasibility of our iPTT system.

A. iPTT Network Architecture

Figure 1 shows an example of our iPTT network archi-tecture. In iPTT, a two-level hierarchical structure is adoptedto avoid excessive message exchanges among the peers. Inthis structure, high-level super nodes perform signaling/voicerelaying and handle group-member joining/leaving. Moreover,the floor during an iPTT session is determined by the supernodes that include the session members. On the other hand,there are a large number of ordinary nodes scattered over theInternet. Each ordinary node serves as a group member, andis supervised by a specific super node. Note that in iPTT, asuper node could be a member of iPTT groups, and equippedwith the functionalities of an iPTT caller/callee.

When an iPTT application is executed at an user equipment,the user equipment will be an ordinary node or a supernode based on its capabilities such as the bandwidth ofits network connection, power consumption restriction, andcomputing performance. The node initialization procedure isbriefly described as follows. If the node is qualified to be asuper node and no appropriate super node is nearby, it willbecome a super node and communicate with other super nodesvia Distributed Hash Tables (DHTs) [20], [21], [22], [23].Otherwise, the node will find a proper super node and connectto it. The communication protocols for iPTT node initializationadopt the specifications of P2P SIP defined by IETF (InternetEngineering Task Force) [24], [25]. As shown in Figure 1,we assume that there are six nodes of the same group in ouriPTT network:ON1, ON2, ON3, ON4, ON5, andON6. Theyare supervised respectively by three different super nodes:SNA, SNB , and SNC . ON1 and ON2 are supervised bySNA. ON3 is supervised bySNB . ON4, ON5 and ON6

are supervised bySNC . In this example, the ordinary nodeON1 initiates an iPTT call session. Suppose that the call hasbeen successfully established. The signaling procedures forcall establishment are described in the following subsection.

1Typically, the number is 5 to 10 in Skype

���

������

������

��

��

���

���

�������

�������������

Fig. 1. An Example of the iPTT Network Architecture

The arrows in this figure represent the voice transmission pathfrom the call originatorON1 to all group members (i.e.,ONs2, 3, 4, 5 and 6). The voice packets generated fromON1 aretransmitted to the destinations through the super nodesSNA,SNB andSNC . Specifically, the voice packets betweenSNA

andSNC are not duplicated even though there are three groupmembers under the supervision area ofSNC .

B. iPTT Signaling Message Flows

During an iPTT call session, signaling exchanges betweenordinary nodes and super nodes could be divided into threestages:

Stage I (Call Establishment).ON1 initiates an iPTTcall, and issues aSIP INVITE message to thegroup members. At the end of this stage, voicetransmission paths are established, andON1

broadcasts the voice message to the recipientsthrough the paths.

Stage II (Floor Determination). Then in Stage II,ON1 stops broadcasting, and releases the floor.The other group members that intend to talk pressthe button and contend for the floor via RTCP. Thefloor-control algorithm determines the next floorowner. One of the group members is granted thefloor, and begins to speak. The floor determinationprocess is repeatedly activated as the floor isreleased.

Stage III (Call Teardown). The call originator ON1

leaves the iPTT session by sending the SIPBYE message. The call terminates, and the voicetransmission path is disconnected. Note that anyother members’ leaving may lead to the voicepaths’ change, and will not result in the sessiontermination.

The detailed steps for call establishment/teardown are de-scribed in the remainder of this section. The real-time floorcontrol algorithms and the corresponding procedure are pre-sented in Section III.

��� ��� ��� ��� ��� ��� ��� ����

���������������������������������� ����������!����������"�������� ��!��#���

���$%$�&$�'

���$%$�&$�'

���$%$�&$�'���$%$�&$�'

���$%

$�&$�'

�����(!��

$�&$�'�����(!��$�&$�'

�����(!��$�&$�'

���$%$�)�

��*��%)+���,��������*��%)+�����-��

��*��%)+���

��-��.���� �����*�%/���� ��-���

������

���

���0���

�����++�

���

���������

���++�

.������������*�%/���� ��-����!

��� ������

.������������*�%/����

��-����!��� ������

��

���0���

�����++�

1�����(!��

$�&$�'����� �

���*��%)+���

��-��

��������������*�%/����

��-����!��� ������

������(!��$�)�

�������

�������

��$%

$�&$�'

�������(

!��$�&$�'

�����

������

2��$%$�)�2�����(

!��$�)�

Fig. 2. The Detailed Steps for Call Establishment

Figure 2 shows the call-establishment procedure, whereON1 is the iPTT call originator. Assume that all ordinarynodes registered with their super nodes and are authenticated.The message flow for call setup is described in the followingsteps:

Step 1: ON1 issues aSIP INVITE message to the supernode SNA. The SIP INVITE message includesthe group ID ofON1.

Step 2: Based on the group ID,SNA sends theSIPINVITE to those super nodes that include thegroup members. Then the super nodes forward theSIP INVITE to their ordinary nodes which belongto the group. Upon receipt of theSIP INVITE, theordinary nodes ring (the180 Ringing response isomitted in Figure 2).

In this phase, the RTP connections, i.e., the dashed lines inFigure 3 (a), are not completely established.

Step 3: Assume thatON5 is the first node to answerthe call. The200 OK is returned toON1 alongthe pathON5 → SNC → SNA → ON1. Asshown in the solid line in Figure 3 (b), the RTPconnections fromON5 to ON1 via SNC andSNA are constructed.

Step 4: A SIP INVITE message is sent fromSNC toSNB for the upcoming RTP/RTCP connectionestablishment.

���

������

������

��

��

���

���

�����

��������

���

������

������

��

��

���

���

�����

��������

���

������

������

��

��

���

���

�����

��������

���������� ����������

����������

�����������

���������������

Fig. 3. Three Phases for Call Establishment

Step 5: If tree-based floor control mechanism (TFC) isused in iPTT, a tree structure among the supernodes covering the group members is maintained.The super node of the call originator is responsi-ble for the tree maintenance. Upon receipt of the200 OK response fromSNC , SNA issues aSIPINFO message toSNC . In this SIP INFO mes-sage, the information for the parent node ofSNC

is included. In the example, the parent node ofSNC is SNA. Otherwise, if flooding-based floorcontrol mechanism (FFC) is used,SNA informsSNC of information about all participating supernodes by sendingSIP INFO.

Step 6: SNA grants the floor toON1 and then notifiesON5 that the floor has been taken byON1.

Step 7: At this moment,ON1 sends the voice packetsto ON5.

After Steps 3-7, the RTP connections are shown in Figure 3(b).

Step 8: In Phase 3 (see Figure 3 (c)),ON3 picks upthe phone. An RTP path connectingON3 toSNA through SNB is established so that thevoice of ON1 could be transmitted toON3. IfTFC is used,SNA then addsSNB to the treestructure , and informsSNB of its parent node(i.e.,SNA in this example) by sendingSIP INFO.Otherwise, if FFC is used,SNA informs SNB

of information about all participating super nodesby sending SIP INFO. Also, a voice link isconnected betweenSNB and SNC . OnceON3

obtains the floor, the voice messages could betransmitted toSNC via this voice link.

��� ��� ��� ��� ����� �

�����������

����������

�������������� !"����

��������

��������

������

!"����

������ !"����

��������

������

!"����

#�������

#�����

!"����

��� ��#

#�������

#�����

!"����

Fig. 4. The Detailed Steps for Call Teardown

In iPTT, if the call originator leaves the session, the sessionis terminated. The session will go on even if other nodesleave the session. As shown in Figure 4, whenON1 (i.e., calloriginator) terminates the call,ON1 sendsSIP BYE to SNA.SNA disconnects the RTP connection withON1, and respondswith 200 OK. SNA then sendsSIP BYE to all participatingsuper nodes of this session to inform them the end of thissession. Upon receivingSIP BYE from SNA, SNB andSNC

sendSIP BYE to group members in its division. Finally, theRTP paths to all group members are disconnected by usingSIP BYE.

III. R EAL-TIME FLOOR CONTROL

The procedure for talk-burst determination (i.e., floor con-trol) is performed when the call originatorON1 releases thefloor. The efficiency of the floor control has a great influenceon the performance of our iPTT system. A large determinationlatency makes the iPTT group communications “un-smooth,”and the conversations between group members are not real-time. Also, the fairness of the floor contention and the volumeof signaling message exchanges of the floor-control procedureare taken into account for designing a proper determinationmechanism. This section presents two talk-burst determinationmechanisms: flooding-based floor control (FFC) and tree-based floor control (TFC). The determination algorithms andthe corresponding message flows for these two mechanismare developed. The performance of these mechanism is inves-tigated through our analytical and simulation models, and aredescribed in Section IV.

Unlike an OMA-based centralized PTT network, the floordetermination for a P2P PTT system is much more challeng-ing. A considerable number of peer nodes are involved in thedetermination process, and an appropriate node is selected ina short period to obtain the floor. However, the complexityof the determination algorithms and the number of messageexchanges are slightly reduced with our two-level hierarchicaliPTT network architecture. The floor information is mostlyexchanged among the super nodes equipped with highercomputing/processing power. In our iPTT system, messageexchanging for floor information could be done by using RTCPor SIP. Without loss of generality, we assume that RTCP

messages are adopted for floor control in this paper. RTCP wasoriginally designed for quality feedback among voice/videosession users, and RTCP paths are basically the same as thosefor RTP. Thus it is natural to adopt RTCP for floor controlto determine the next talk-burst and the voice transmissiondirection.

To support our iPTT floor control, RTCP messages aremodified to accommodate some floor-control extensions [11].Five RTCP messages are defined for the support of floor con-trol: RTCP Floor Request, RTCP Floor Ack, RTCP FloorGranted, RTCP Floor Taken and RTCP Floor Release.When someone would like to contend for the floor, anRTCPFloor Request message is sent. Upon receipt of theRTCPFloor Request message, the iPTT node automatically replieswith RTCP Floor Ack if the user has not requested or is notwilling to request the floor. TheRTCP Floor Granted andRTCP Floor Taken messages are respectively used to informiPTT users that the floor is granted and taken by the otheruser. The floor owner announces the floor release to all groupmembers throughRTCP Floor Release.

In iPTT, the setting of the priorities for each floor requestdepends on the relative timestamp. A relative timestamp isthe length of the period between the time when theRTCPFloor Release is received and the subsequent time whenthe floor request is made. A small relative timestamp impliesthat the member is more eager to get the floor and hencea higher priority is set for that request. Each time aRTCPFloor request is issued, the relative timestamp is computedand included. Besides, in order to prevent the interferencefrom messages of different floor contention iterations, a runnumber is included in each floor control message. Each nodein an iPTT session maintains a run counter. Whenever the floorowner releases the floor, the run counter will be increased byone. If one node gets a floor-control message that has a smallerrun number than that recorded in the node, the message willbe ignored. Otherwise, the message is queued and will behandled.

Before describing our flooding-based (FFC) and tree-basedfloor-control mechanisms (TFC), we assume thatON2 andON5 both request the next talk-burst when call originatorON1 releases the floor and sendsRTCP Floor Release toall group members. Based on our iPTT hierarchical networkarchitecture, the floor contention is divided into two levels.The local floor-control is applied to the iPTT group membersresiding in a single super node. The super node makes its besteffort to filter unnecessaryRTCP Floor Request messages ofthe group members and to select a candidate for the upcomingupper-level global floor control. On the other hand, the globalfloor-control is executed among the super nodes, where floorinformation can be exchanged by flooding-based or tree-basedtransmissions. The execution steps for global floor-controlmechanisms are shown in Figure 5, and described below.

A. Flooding-based Floor Control

In flooding-based floor control, each of the super nodes thatcover floor-requesting members issuesRTCP Floor Request

����������� �����������������

�������������

���

���

���

���

���

���

���

���

���

� ������� �����������������

���

���

���

�

���

���

������

���

���� �

� �

�������������

���

���

���

���

���

���

��� ���

���

���

���

���

���

���

�

�

���

���

��������

� �

��!�

����

����

����

����

����

���

"

�

Fig. 5. The Floor Control Mechanisms

to the remaining super nodes. Whether the receiving supernodes respond withRTCP Floor ACK depends on the in-tention of their group members to request the floor. If thesuper node that has issued the floor request receives the floorrequests from other super nodes, the super node compares therelative timestamps of the requests to the one of the requestit sent before. If the timestamp of the request it sent before issmaller, this request is ignored. Otherwise,RTCP Floor ACKis sent back. The super node is gained the floor only whenthe acknowledgements (i.e.,RTCP Floor ACK) from all othersuper nodes are obtained. Figure 5 (a) shows the steps of FFC.

Step 1: ON5 presses the talk button, and issues theRTCP Floor Request message (with relativetimestampT5) to SNC .

Step 2: ON2 presses the talk button, and issues theRTCP Floor Request message (with relativetimestampT2) to SNA.

Step 3: SNC sendsRTCP Floor Request to SNA andSNB .

Step 4: SNA sendsRTCP Floor Request to SNB andSNC .

Step 5: Upon receipt of the request ofSNA, SNC

drops the request sinceT5 < T2.

Step 6: Upon receipt of the request ofSNC , SNA

sendsRTCP Floor ACK back toSNC .

Step 7: Since no group member ofSNB requests thefloor, SNB responds withRTCP Floor ACK afterreceiving the request fromSNC .

Step 8: SNB also sendsRTCP Floor ACK to SNA torespond to the request ofSNA.

Step 9: SNC collects the acknowledgements from allother super nodes,SNA andSNB .

Step 10: After collecting all acknowledgements,SNC

informs ON5 that the floor is obtained throughRTCP Floor Granted.

Step 11: SNC notifies the super nodes and their groupmembers (via the corresponding super nodes) thatthe floor is taken throughRTCP Floor Taken.

B. Tree-based Floor Control

In the tree-based floor control, a tree structure amongthe super nodes is established during the call-establishmentprocedure (see Step 5 in Figure 2). The floor-requestinginformation is delivered upward to higher-level super nodes(i.e., internal nodes) in the tree structure. Each super nodecompares the received requests, and discards the requests withlower priorities (i.e., larger relative timestamps). Finally, theroot of this tree (i.e., the super node of the call originator)determines the floor owner, and propagates this informationto all super nodes following the tree structure. We notice thatthe tree topology may affect the performance of our tree-basedfloor control. For a k-ary tree (k ≥2), a largek may lead to thesignaling congestion of the root. Conversely, whenk is small,the signaling propagation delay to the root could be large. Wesetk = 2 since the number of super nodes in our experimentsis small, and the super nodes may be portable devices withlimited computing hardware. As shown in Figure 5 (b), thesteps of tree-based floor control are described as follows.

Step 1: This step is similar to Step 1 in Section III-A.

Step 2: SNC sendsRTCP Floor Request to SNA.

Step 3: This step is similar to Step 2 in Section III-A.

Step 4: Upon receipt of the first floor request, the root(i.e.,SNA) starts to countdown a timer. The timeris set for the root to have sufficient time to collectthe floor requests from super nodes.

Step 5: When the timer ofSNA is over, SNA de-termines the floor owner based on the relativetimestamp of the collected requests.

Step 6: ThenSNA grants the floor toON5 by sendingthe RTCP Floor Granted message viaSNC .

Step 7: SNC also sendsRTCP Floor Taken to ON4

andON6.

Step 8: SNA informs ON1 and ON2 that the floor istaken.ON3 is notified bySNA throughSNB .

IV. PERFORMANCEEVALUATION

This section investigates the performance of our iPTTflooding-based and tree-based floor-control mechanisms. Ananalytical model and a discrete simulation model are devel-oped, and a series of experiments are conducted in this section.In terms of floor-determination latency and signaling-messagequantity, some numerical examples are shown to indicate thecapabilities of TFC and FFC.

A. Input Parameters and Output Measures

In the analytical and simulation models, a network archi-tecture withNs super nodes and several ordinary nodes isadopted. Each super nodep (1 ≤ p ≤ Ns) supervisesMp

ordinary nodes (Mp ≥ 1). Without loss of generality,Ns = 3is used in the experiments2. ONp,q (1 ≤ q ≤ Mp) denotesthe qth ordinary node supervised by the super nodep. Thepropagation delay (sp,i) of a connection between the supernodes p and i (1 ≤ p, i ≤ Ns and p 6= i) follows anexponential distribution with an averageS = 200 (ms). Thepropagation delay of a connection between a super node andits ordinary node can be ignored compared that that forsp,i.The reason is that in iPTT, super nodes are widely spread outover the Internet while the ordinary nodes normally reside neartheir super nodes.

At each run of floor determination in iPTT, an exponentiallydistributedrp,q denotes the relative time-stamp for each floorrequest issued by an ordinary nodeONp,q with an averagevalue R. The talk-burst time for the floor owner could be ageneral distribution, and does not have any influence on theperformance of our floor control mechanisms. When TFC isadopted for the floor determination mechanism,wp denotesthe time that the root super-nodep should wait for to collectthe floor requests from the otherNs − 1 super nodes at eachfloor-determination run. We assume thatwp is exponentialdistributed with an averageW = 200 (ms) or400 (ms). Notethat our simulation model will be extended to accommodateGamma distributedsp,i to investigate the effect of its variance.

As to the output measures, the average floor-determinationlatency is an important metric for our iPTT floor controlmechanisms (FFC and TFC). The latencyTl is defined as theaverage time that a floor owner goes through to obtain thefloor. In other words,Tl is the average duration between thetime that the owner pushes the button and the time that he/sheactually receives anRTCP Floor Granted message. Anotherimportant metric is the average signaling message quantityHM during the period of a floor contention run.

B. Analytical Modeling

This subsection elaborates on our developed analyticalmodel to investigate the performance of FFC and TFC. Specif-ically, the average waiting times (Tl) of the floor owner forour FFC and TFC are derived in the following subsections.

2In our iPTT system, the number of super nodes is much smaller than thatof the members in an iPTT group.

������������

������������

�����

��� ����

�������

��

���

� � � �

��������������������������

����

�

���������� ���

��� �

� ���

�������� � ���

���������

����� �

����

� �������

������������� �

��������������������� ���������

��������� �

��������

Fig. 6. An Example of the Timing Diagram of FFC

1) Derivation ofTl for FFC: Figure 6 shows an exampleof the FFC timing diagram of the floor owner for thekthdetermination run of an ongoing iPTT session. Assume thatONp,q releases his/her floor of the (k − 1)st run at the timeτ0, and ONi,m obtains the floor at the coming run. TheRTCP Floor Release message issued byONp,q is receivedby ONi,m at the timeτ1, wheretp,q represents the messagepropagation-delay fromONp,q to ONi,m. tp,q will be 0 ifp = i. If p 6= i, tp,q = sp,i. At the time τ2, ONi,m pushesthe button, and sends anRTCP Floor Request message withthe relative timestampri,m to the super nodei. Then thesuper nodei forwardsRTCP Floor Request to the other twosuper nodes, and receives the acknowledgements from thesesuper nodes at the timesτ3 and τ4. The random variablesdi,1 and di,2 respectively represent the delays for theRTCPFloor Request/ACK message exchange between the supernode i and the other two super nodes. Upon receipt of theacknowledgements from all super nodes involving in this iPTTsession, the super nodei forwardsRTCP Floor Granted toONi,m. Finally, ONi,m obtains the floor, and begins to talk tohis/her group members. As shown in Figure 6,ONi,m waitsfor a time period to be the floor owner after pushing the talkbutton, and the average waiting timeTl can be expressed as

Tl = E[max{di,1, di,2}]. (1)

Based on (1), the derivations ofE[max{di,1, di,2}] can bedivided into two cases. In CaseI (i.e., a normal case),di,1 anddi,2 are respectively the round-trip delays between the supernode i and the other two super nodes with the distributionfunctionsFdi,1(t) and Fdi,2(t), wheredi,1 = sp,i + si,p anddi,2 = si,v + sv,i. It is obvious that bothdi,1 anddi,2 followan Erlang distribution with the average value2S. We define arandom variabledI asmax{di,1, di,2} in this case, andE[dI ]can be expressed as

E[dI ] =∫ ∞

0

[1− Fdi,1(t)Fdi,2(t)]dt

=(

114

)S. (2)

On the other hand, an abnormal case (CaseII) occurs whenany of the two super nodes (denoted as an “abnormal supernode”) has not receivedRTCP Floor Release of the previousdetermination run upon receipt ofRTCP Floor Requestof the super nodei at the current floor-determination run.

���

���

��� ���

���

��� ���

���

���

��� �� ��

�� ��������

�������

�� ��������

�������

�� ��������

�������

�� ��������

�������

�� ��������

�������

�� ��������

�������

�� ����������

�� ��������

��

Fig. 7. An Example of the Scenario in CaseIIa

In this case, the “abnormal super node” has to wait forreceivingRTCP Floor Release from the floor owner of theprevious run. This wait operation avoids malicious iPTT usersto contend the floor by advancing their request transmissionbefore the end of the iPTT talk burst of the floor owner.To analyzeE[max{di,1, di,2}] in CaseII, the following twosituations are considered.

CaseIIa: p 6= i. As shown in Figure 7 (a), the supernodep issuesRTCP Floor Release to the supernodesi and v. Due to the varying propagationdelays of the connections, the message first ar-rives at the super nodei. Then in Figure 7 (b),ONi,m requests the floor, and the super nodeisendsRTCP Floor Request to the super nodesp andv. The super nodep responds to the supernode i once it receivesRTCP Floor Request.However, the super nodev does not acknowledgethe request of the super nodei until obtainingthe RTCP Floor Release message. Figure 7 (c)indicates that the super nodev obtains RTCPFloor Release, and sendsRTCP Floor Ack backto the super nodei. In this case,di,1 = sp,i+si,p,and di,2 is expressed assi,v + sv,i + trv . trv

represents the residual time for the super nodev to get the RTCP Floor Release messagefrom the super nodep upon receipt ofRTCPFloor Request of the super nodei. With anexponentially distributedsp,v, the residual timetrv will have the same distribution as that ofsp,v.Let dIIa be a random variablemax{di,1, di,2} inCaseIIa. Then the derivationE[dIIa] is similarto that in (2), and

E[dIIa] =(

5516

)S. (3)

Furthermore, the probabilityPIIa that CaseIIa

occurs is expressed as

PIIa = PcIIa

{(Mi∑Ns

j=1 Mj

)×

(Ns∑p=1

Mp∑Ns

j=1 Mj

− Mi∑Ns

j=1 Mj

)}, (4)

wherePcIIa denotes the conditional probabilitythat an abnormal event occurs given thatp 6= i.

���

���

��� ���

���

��� ���

���

���

��� �� ��

�� ��������

�������

�� ��������

�������

�� ���������������

�� ���������

������

�� ��������

��

�� ��������

��

�� ��������

�������

�� ���������

������

Fig. 8. An Example of the Scenario in CaseIIb

From Figure 7, we have

PcIIa = Pr[sp,v > (sp,i + txi+ si,v)], (5)

where txirepresents the period from the time

when the super nodei forwards RTCP FloorRelease to its ordinary nodes to the time whenthe firstRTCP Floor Request is received by thesuper nodei from one of its ordinary nodes. Thenwe havetxi

= min(ri,m), ∀m, 1 ≤ m ≤ Mi, andthe density functionftxi

(x) of txi will be

ftxi(x) =

(Mi

R

)e

(−Mix

R

). (6)

Based on (6),PcIIa can be rewritten as

PcIIa = Pr[sp,v > (sp,i + txi + si,v)]

=14

(MiS

MiS + R

). (7)

CaseIIb: p = i. In CaseIIb, the previous and currentfloor owners reside in the same super node. Thatis, the super nodep issues the release messagesto the super nodesu and v, and then the re-quest messages to these super nodes afterONi,m

pushes the talk button. If any of the super nodesvandu receivesRTCP Floor Request earlier thanRTCP Floor Release, it becomes an “abnormalsuper node”. As shown in Figure 8 (b), this ab-normal event occurs at the super nodev. Then theabnormal super nodev has to wait, and respondsto the super nodep immediately after receivingthe RTCP Floor Release message (see Figure 8(c)). Based on the scenario shown in Figure 8,di,1 = sp,u + su,p, anddi,2 can be expressed assp,v + sv,p + trv . Then we have

E[dIIb1 ] =(

5516

)S, (8)

where dIIb1 is the random variable ofmax{di,1, di,2} in the scenario of Figure 8.Furthermore, if the abnormal situation occursat both the super nodesu and v, di,1 will besp,u + su,p + tru . Then the averageE[dIIb2 ] ofdIIb2 can be calculated, and will be

E[dIIb2 ] =(

6316

)S. (9)

The probabilitiesPIIb1 and PIIb2 that CaseIIb

occurs are expressed as

PIIb1 = PcIIb1

(Mi∑Ns

j=1 Mj

)2 , (10)

PIIb2 = PcIIb2

(Mi∑Ns

j=1 Mj

)2 , (11)

From Figure 8, we have

PcIIb1 = {Pr[sp,v > (txp+ sp,v)]×

{1− Pr[sp,v > (txp + sp,v)]}}+{Pr[sp,u > (txp

+ sp,u)]×{1− Pr[sp,u > (txp + sp,u)]}} ,(12)

PcIIb2 = Pr[sp,v > (txp+ sp,v)]×

Pr[sp,u > (txp + sp,u)], (13)

ThenPcIIb1 andPcIIb2 can be rewritten as

PcIIb1 =(

MiS

MiS + R

)[1− 1

2

(MiS

MiS + R

)],

(14)

PcIIb2 =[12

(MiS

MiS + R

)]2

, (15)

Based on (2),(3),(4),(8),(9),(10),and (11) listed above, theaverage waiting timeTl can be derived as

Tl =

1−

3∑

j=1

(PIIa + PIIb1 + PIIb2)

E[dI ]

+{ 3∑

j=1

{PIIaE[dIIa] + PIIb1E[dIIb1 ]

+PIIb2E[dIIb2 ]}}

(16)

2) Derivation ofTl for TFC: Figure 9 shows an example ofthe TFC timing diagram of thekth floor owner for an ongoingiPTT session. Assume thatONp,q releases his/her floor of thek − 1st run at the timeτ0, and ONi,m obtains the floor atthe coming run. Without loss of generality, it is assumed thatthe super nodep plays the role of the root super node in thisexample. TheRTCP Floor Release message issued byONp,q

is received byONi,m at the timeτ1. ThenONi,m pushes thetalk button, and sendsRTCP Floor Request out at the timeτ2. Upon receipt ofRTCP Floor Request, the root supernodep starts its timerwp to count down. When the timeoutevent occurs atτ4, the super nodep has collected the floorrequests from the ordinary nodes, and determines thatONi,m

obtains the floor. At the timeτ5, ONi,m is informed of that,and begins to talk. To analyzeTl for TFC, the following twocases are considered. If the super node of the floor owner isroot, thenTl can be expressed asW . On the other hand, whenp 6= i (i.e., the floor of thekth run is granted to the ordinary

������������

������������

�����

��� ����

����

���

���

� � � �

��������������������������

���

�

���������� �

����� �

� ���

�������� � ���

���������

����� �������

�� �� �������

���������������

��������� �

����� ����

�������� �

����������

�����������

������� �

�������

���

�

��

�������� �

�����������

���������

��������

��������� �

��������

Fig. 9. An Example of the Timing Diagram of TFC

node that is not supervised by the root super nodep), then wehaveTl = 2S + W . The probabilityPa for the case ofp = iis derived as follows.

First, Vj is defined as the probability that the relativetimestamp of the request from the root super node is smallerthan the one of the request from the super nodej (2 ≤ j ≤NS). Then we have

Vj =Mp

Mp + Mj. (17)

It is obvious that the root super node will get the floor whenthe above event occurs. However, if the relative timestampof the root is larger than that of the super nodej, the rootsuper nodep can still get the floor when the request ofjcannot arrive the root super node before timeout. We defineQj as the probability that thej’s request with a smaller relativetimestamp can not arrive the root super nodep before timeout.Qj can be derived as

Qj = Pr[wp + txp < sj,p + txj + sp,j ,andtxp > txj ]

=MjMp

Mj + Mp

{[R

Mp

]+

[S2R

(S + W )(SMp + R)

]

−[

S3R2

W (S + W )(SMp + R)2

]

−[

S3R

(S + W )2(SMp + R)

]}. (18)

ThenPa can be

Pa =Ns∏

j=2

(Vj + Qj), (19)

Finally, Tl for our TFC can be expressed as

Tl = WPa + (2S + W )(1− Pa) (20)

C. Simulation and Numerical Results

This subsection develops a simulation model to investigatethe performance of our iPTT floor-control mechanisms. Oursimulation program follows the discrete-event model with theinput parameters and output measures presented in Section IV-A.

Figure 10 plotsTl obtained from our developed math-ematical analysis and simulation experiments for FFC andTFC. From this figure, the analytical and experimental results

0

0.2

0.4

0.6

0.8

1

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Tl (

sec.

)

1/R (1/sec.)

FFC SimulationFFC Analysis

TFC Simulation W=400msTFC Analysis W=400ms

TFC Simulation W=200msTFC Analysis W=200ms

Fig. 10. Effect of Request Rate on Average Waiting Time

are consistent, and our simulation has been validated againstthe mathematical analysis. Figure 10 shows the effect ofthe request arrival rate (1/R) on the floor determinationlatencyTl for our flooding-based and tree-based floor controlmechanisms. In this figure, we observe that as the request-rateincreases,Tl for TFC decreases andTl for FFC increases. ForTFC, a large request-rate for an ordinary node results in theincrease of the probability that the ordinary nodes superviseddirectly by the root obtain the floor. On the other hand, morefrequent floor-requesting in FFC leads to higher determinationoverhead, and thusTl increases. WhenW = 200ms, for allarrival rates under investigation, FFC has a largerTl than TFC.When W = 400ms, Tl of TFC is larger than that of FFCfor 1

R ≤ 0.8. However, an opposite result is observed for1R ≥ 0.8. Figure 10 also indicates that the decreasing rateof Tl for TFC is larger for a smallW than for a largeW ,which implies that the ordinary nodes directly supervised bythe root benefit by a short waiting timer and an unfair situationwould raise. Figure 11 shows the effect of the request rate(1/R) on the numberHM of signaling message exchangesfor FFC and TFC. This figure indicates that for all requestrates under investigation, TFC has a smallerHM than FFC.As the request rate increases, the total number of requestmessages increases, and henceHM of TFC andHM of FFCboth increase. To further investigate the effect of variancesof propagation delays between the super nodes on averagewaiting timeTl, a Gamma distributed random variablesp,i isadopted. Figure 12 indicates that the waiting timeTl of FFCincreases as the variancevs of sp,i increases. Specifically,the increasing rate is larger for a largervs than that for asmall vs. For FFC, each floor-requesting super node has towait for acknowledgements from all other super nodes beforeobtaining the floor. Asvs increases, there are more probablyextremely long propagation delay between the super nodes,which results in the increase ofTl in FFC. On the other hand,we observe that the waiting timeTl of TFC drops slightlywhen the variance is large. In TFC, the timer of the root super

16

18

20

22

24

26

28

30

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Hm

1/R (1/sec.)

TFC Simulation W=400msTFC Simulation W=200ms

FFC Simulation

Fig. 11. Effect of Request Rate on Average Number of Signaling-MessageExchanges

0

0.2

0.4

0.6

0.8

1

1.2

1.4

0.001 0.01 0.1 1 10 100 1000

Tl (

sec.

)

Vs (1/sp,i2)

FFC SimulationTFC Simulation with W=200msTFC Simulation with W=400ms

Fig. 12. Effect of Variance of Propagation Delays Between Super Nodes onAverage Waiting Time

node starts to count down at the time that the first requestarrives. A largevs implies that the first request arrives the rootin a very short period, and the timer can be quickly triggered.From this figure, TFC outperforms FFC when the network isin an unstable situation with much varying propagation delays.

V. CONCLUSION

In this paper, we proposed iPTT, a peer-to-peer Push-to-Talk (PTT) service for Voice over IP. In iPTT, a distributedand mobile-operator independent network architecture waspresented to accelerate the deployment of the PTT service.Based on the proposed two-level hierarchical architecture, themessage flows for call establishment/teardown were designedto show the feasibility of iPTT. Also, we presented twofloor control mechanisms, FFC and TFC, for real-time talk-burst determination. The performance of the proposed floorcontrol mechanisms was investigated through our analyticaland simulation models in terms of the determination latency

and the number of floor-control message exchanges. A seriesof experiments are conducted to show the capabilities of ourFFC and TFC.

REFERENCES

[1] Google, “Google Talk.” http://www.google.com/talk/.[2] Microsoft, “MSN Messenger.” http://messenger.msn.com.[3] Wang, X.-G., Min, G., And Mellor, J.E., “Improving VOIP application’s

performance over WLAN using a new distributed fair MAC scheme,”18th International Conference on Advanced Information Networking andApplications, vol. 1, pp. 126–131.

[4] Anjum, F., Elaoud, M., Famolari, D., Ghosh, A., Vaidyanathan, R.,Dutta, A., Agrawal, P., Kodama, T., And Katsube, Y., “Voice perfor-mance in WLAN networks - an experimental study,”Global Telecom-munications Conference, vol. 6, pp. 3504–3508, Dec. 2003.

[5] 3GPP, “3rd Generation Partnership Project; Technical SpecificationGroup Services and Systems Aspects; Service Requirement for theInternet Protocol (IP) Multimedia core network subsystem; Stage 1.”Technical Specification 3G TS 22.228 version 7.3.0 (2005-12), 2005.

[6] 3GPP, “3rd Generation Partnership Project; Technical SpecificationGroup Core Network and Terminals; Signalling flows for the IP multi-media call control based on Session Initiation Protocol (SIP) and SessionDescription Protocol (SDP); Stage 3.” Technical Specification GPP TS24.228 version 5.14.0 (2005-12), 2005.

[7] Lin, Y.-B. And Pang, A.-C.,Wireless and Mobile All-IP Networks. JohnWiley & Sons, Inc., 2005.

[8] DaSilva, L.A., Morgan, G.E., Bostian, C.W., Sweeney, D.G., Midkiff,S.F., Reed, J.H., And Thompson, C., “The Resurgence of Push-to-TalkTechnologies,”Communications Magazine, IEEE, vol. 44, pp. 48–55,Jan. 2006.

[9] Nextel, “Nextel Walkie-Talkie.” http://www.nextel.com.[10] Motorola, “Motorola Push-to-Talk over Cellular Solution.”

http://www.motorola.com/networkoperators/pdfs/new/PoC.pdf.

[11] OMA, “Push to Talk over Cellular (PoC) - Architecture.” OMA-AD-PoCV1 0-20060127-C Candidate Version 1.0 V 27 Jan 2006.

[12] Parthasarathy, A., “Push to talk over Cellular (PoC) Server,”Networking,Sensing and Control, 2005. Proceedings. IEEE, pp. 772–776, Mar. 2005.

[13] Kim, P., Balazs, A., van den Broek, E., Kieselimann, G., And Bohm, W.,“IMS-based push-to-talk over GPRS UMTS,”Wireless Communicationsand Networking Conference, vol. 4, pp. 2472–2477, Mar. 2005.

[14] Wu, L.-Y., Tsai, M.-H., Lin Y.-B., And Yang J.-S., “A Client-SideDesign and Implementation for Push to Talk over Cellular Service,”Accepted and to appear in Wireless Communications & Mobile Com-puting.

[15] Tsai, M.-H., And Lin Y.-B., “Performance Evaluation of PoC Talk BurstControl Mechanism,”Accepted and to appear in IEEE Transactions onMobile Computing.

[16] Balazs, A., “QoS in wireless networks: Push-to-talk Performance overGPRS,”Proceedings of the 7th ACM international symposium on Mod-eling, analysis and simulation of wireless and mobile systems, pp. 182–187, Oct. 2004.

[17] Raktale, S.K., “3PoC - An Architecture for Enabling Push to Talk Ser-vices in 3GPP Networks,”IEEE International Conference on PersonalWireless Communications, ICPWC, pp. 202–206, Jan. 2005.

[18] Gao, L. And Luo, J., “Performance Analysis of a P2P-Based VoIPSoftware,” International Conference on Internet and Web Applicationsand Services/Advanced International Conference on Telecommunica-tions, vol. 00, pp. 11–11, Feb. 2006.

[19] Baset, S.A. And Schulzrinne, H., “An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol,”Accepted and to appear in IEEEInfocom 2006.

[20] Dury, A., “Auto-adaptive Distributed Hash Tables,”Grid Computing,2005. The 6th IEEE/ACM International Workshop, November 2005.

[21] Landsiedel, O.; Lehmann, K.A.; Wehrle, K., “T-DHT: Topology-BasedDistributed Hash Tables,”Peer-to-Peer Computing, 2005. P2P 2005.Fifth IEEE International Conference, pp. 143–144, September 2005.

[22] Heer, T.; Gotz, S.; Rieche, S.; Wehrle, K., “Adapting DistributedHash Tables for Mobile Ad Hoc Networks,”Pervasive Computing andCommunications Workshops, 2006. PerCom Workshops 2006. FourthAnnual IEEE International Conference, March 2006.

[23] Araujo, F.; Rodrigues, L.; Kaiser, J.; Liu, C.; Mitidieri, C., “CHR: ADistributed Hash Table for Wireless Ad Hoc Networks,”DistributedComputing Systems Workshops, 2005. 25th IEEE International Confer-ence, pp. 407–413, June 2005.

[24] Shim, E.; Narayanan, S.; Daley, G., “An Architecture for Peer-to-PeerSession Initiation Protocol (P2P SIP).” IETF Internet Drafts, February2006.

[25] Willis - Ed., D.; Bryan, D.; Matthews, P.; Shim, E., “Concepts andTerminology for Peer to Peer SIP.” IETF Internet Drafts, June 2006.