A Robust Push-to-Talk Service for Wireless Mesh Networks∗

Yair Amir, Raluca Musaloiu-Elefteri, Nilo Rivera

Technical Report CNDS-2009-1 - January 2009http://www.dsn.jhu.edu

Abstract

Push-to-Talk (PTT) is a useful capability forrapidly deployable wireless mesh networks usedby first responders. PTT allows several users tospeak with each other while using a single, half-duplex, communication channel, such that onlyone user speaks at a time while all other users lis-ten. Furthermore, enabling regular PSTN phoneusers (e.g., cell phones) to seamlessly participatein the wireless mesh PTT session is key to sup-porting the heterogeneous environment commonlyfound in such settings.

This paper presents the architecture and proto-col of a distributed PTT service for wireless meshnetworks. The architecture supports any 802.11client with SIP-based VoIP software and enablesthe participation of regular phones. Collectively,the mesh nodes provide the illusion of a single thirdparty call controller, enabling clients to participatevia any reachable mesh node. Each PTT groupinstantiates its own logical floor control managerthat is highly available and resilient to mesh con-nectivity changes such as node crashes and recov-eries and network partitions and merges.

Experimental results on a fully deployed meshnetwork consisting of 14 mesh nodes and tens ofemulated clients demonstrate the scalability androbustness of the system.

1 Introduction

Push-to-Talk (PTT) is a well known service inthe law enforcement and public safety communi-ties, where coordination and spectral efficiency are

∗This work was partially supported by grant 0430271from the National Science Foundation. Its contents aresolely the responsibility of the authors and do not necessar-ily represent the official view of Johns Hopkins Universityor the National Science Foundation.

key for efficient communication. Some cell phonecompanies offer a similar service in the commer-cial world. However, core differences in motivationdrive these two sectors. Cellular phone systems aredesigned for the busiest hour, as outages impactrevenue, while public safety systems are designedfor worst case scenarios, as outages impact lives.

Unfortunately, first responders cannot alwaysrely on pre-existing ground communication infras-tructure. For example, the White House reporton hurricane Katrina [3] states that 1,477 cell tow-ers were incapacitated, leaving millions unable tocommunicate. The report concludes that “Thecomplete devastation of the communications in-frastructure left emergency responders and citizenswithout a reliable network across which they couldcoordinate.”

Wireless mesh networks have emerged as a vi-able technology that allows for rapid deploymentof instant infrastructure [22]. In these networks,mobile clients can roam throughout the area cov-ered by the mesh and seamlessly handoff betweenaccess points while utilizing real-time applicationssuch as VoIP [5, 11]. These attributes make wire-less mesh networks an appealing technology forfirst responders. While centralized solutions forproviding PTT service exist (e.g., POC [4]), thereare currently no solutions for a robust and efficientPTT service that can be applied in the much moredynamic environment of wireless mesh networks.

Building a robust and practical Push-to-Talksystem for the wireless mesh environment is chal-lenging for several reasons. First, it requires theability to coordinate communication between userseven when part of the infrastructure is unavail-able (mesh node crashes) or when there is inter-mittent connectivity between nodes (network par-titions and merges). This rules out traditional ap-proaches such as POC, where arbitration is assured

Figure 1: System overview.

by a centralized point. Second, it must operatecorrectly when users join and leave the network,when they are partitioned away, lose their con-nectivity, or move from one access point to an-other. Third, it must use the wireless mediumefficiently and should provide low transfer timesbetween users’ requests. Last but not least, an im-portant property for first responders is the abilityto integrate regular PSTN (Public Switched Tele-phone Network) and cellular phone users, allowingthem to seamlessly participate in the PTT sessionsconducted by the wireless mesh PTT service at adisaster site.

This paper presents the first architecture andprotocol of a robust distributed PTT service forwireless mesh networks. Collectively, the meshnodes provide the illusion of a single third partycall controller (3pcc), enabling clients to partic-ipate via any reachable mesh node. Mesh userswith SIP-based VoIP phones participate by con-necting to an IP address that corresponds to thevirtual 3pcc server address. In addition, regularphone and cell phone users dial a phone numberthat connects to the mesh network through a SIPgateway that routes the call to the mesh (Figure 1).

In our approach, each PTT group (also referredto as a PTT session) instantiates its own logicalfloor control manager that is responsible for keep-ing track of the floor requests of the participantsand for issuing Permission-to-Speak when a par-ticipant releases the floor. Any of the mesh nodesin the network can play the controlling role for asession. To maintain high availability, each con-troller node is continuously monitored by everymesh node with a participating PTT client andis quickly replaced if it becomes unavailable due toa crash or network partition. The controller relin-quishes its role to another mesh node upon deter-mining that this node is better situated (network-wise) to control the PTT session, based on the

current locations of the clients participating in thesession. In addition to improved performance, thismigration increases the availability of the service inthe face of network partitions because it keeps thecontroller in the “center of gravity” of the clientsin the PTT session.

The main contributions of this paper are:

• The first robust Push-to-Talk service for wire-less mesh networks that can withstand con-nectivity changes such as node crashes, net-work partitions, and network merges.

• Efficient separation of control and dissemina-tion, such that control migrates to the mostsuitable node in the network, while dissemina-tion is conducted through source-based multi-cast trees.

• An architecture that allows regular phonesusers (e.g., cell phone users) to seamlessly par-ticipate in wireless mesh PTT sessions.

We implemented the proposed Push-to-Talk ar-chitecture and protocol within the SMesh opensource wireless mesh system [2] and evaluated it ina 14-node testbed deployed across 3 buildings. Inour tests, users experienced less than 150 ms inter-ruption while the system switches between speak-ers. We show how the system scales to tens ofclients, with an overhead of under 1 Kbps per clientwith 42 clients in the mesh. Then, we show that inour testbed, the system scales to 18 simultaneousPTT groups when dual-radio and packet aggrega-tion are used. Lastly, an elaborate scenario with40 clients divided among 10 different PTT sessionsdemonstrates that the system remains highly avail-able during mesh network connectivity changes.

2 Background and Related Work

PTT allows half-duplex communication betweenmultiple participants which request to speak bypressing a button. On a PTT group only one useris granted Permission-to-Speak at a time, whileall the other users listen. DaSilva et al. [9] pro-vide a good survey about PTT technologies. Floorcontrol, an integral part of PTT, has been stud-ied extensively over the years [10, 13, 15]. Someapproaches to decentralized floor control are pre-sented in [8]. A basic level of fault tolerance is

2

Mes

h N

ode

Client Control Group

PTT CMonitor

Group

PTT Data Group

PTT Controller

Group

PTT ControllerMobile, Fault-Tolerant

Monitor Floor management

Mobile Client State sip_call_id, sip_cseq, rtp_port, ptt_group,

ptt_state

PTT Session Manager

RTP Proxy

DTMF Voice

DistributedSIP 3PCC

Mobile Client with VoIP Software

SIP RTP

Routing Daemon (Discovery, Topology Management, Group Management)

Wireless Mesh Network

Figure 2: Architecture.

built into some of these protocols to enable crashrecovery.

PTT is commonly used by law enforcement andpublic safety communities to efficiently communi-cate between multiple users. Public safety agen-cies usually rely on trunked networks, known asLand Mobile Radio (LMR) systems, for voice anddata communication [21]. The two major LMRsystems are Project-25 [1], which is deployed overNorth America, and Terrestrial Trunked Radio(TETRA), which is deployed over Europe. Strin-gent guidelines for PTT, such as 500 ms one-waydelay for voice packets to all listeners of a group,ensure that the system operates with acceptableperformance.

Cell phone users also benefit from PTT typeservices that are now offered by telecommunica-tion companies. A common standard, known asPush-to-Talk over Cellular (PoC) [4], allows PTTfrom different cellular network carriers to inter-operate with one another. PoC uses VoIP proto-cols (SIP, RTP, etc) between clients and the PoCserver. A floor control mechanism, referred to asTalk Burst Control Protocol, arbitrates communi-cation in each group. The performance require-

ments of PoC are less demanding than those inLMR systems. For example, the standard speci-fies that end-to-end delay should typically be nomore than 1.6 seconds and that the turnaroundtime from the time a user releases the floor untilit hears another user speak should be no longerthan 4 seconds. An initial evaluation on a GPRScellular network is shown in [7].

Balachandran et al. show a unifying systemfor bridging LRM and commercial wireless accesstechnologies [6]. Both LMR and commercial PTTsolutions (PoC) rely on a central point of arbitra-tion and send a separate unicast voice stream toeach member of the PTT group. On these net-works, the inefficiency inherent in using multipleunicast streams is not that costly over the wiredbackbone medium. Such a design would yield amulti-hop wireless mesh network useless with justa few users, and therefore is not a good fit in ourcase.

A decentralized approach with a full-mesh con-ferencing model is presented by Lennox andSchulzrinne in [14]. Florian Maurer [16] shows adecentralized scheme for PTT. Both approachesrely on all-to-all communication of control and

3

voice packets between users. While adequate forsmall conferences or PTT sessions, this approachdoes not scale well and does not provide the ro-bustness necessary to support node crashes andnetwork partitions and merges, as presented in thispaper.

3 Architecture

We consider a two-tier wireless mesh network withtwo classes of participants: mesh nodes and meshclients. Mesh nodes communicate with each other,possibly using multiple hops, to effectively extendthe coverage area of a single access point. Meshclients, on the other hand, connect directly to meshnodes, each of which serves as an access point.

The mesh topology changes when wireless con-nectivity between the mesh nodes changes, whenmesh nodes crash or recover, or when additionalmesh nodes are added to expand the wireless cover-age. These changes may create network partitionsand merges in the wireless mesh.

Mesh clients are unmodified 802.11 devices. Wedo not assume any specific drivers or hardware ca-pabilities present on the clients. Clients connectto the mesh by associating with the wireless-mesh802.11 SSID. A client should be able to participatewith any compliant VoIP application. Therefore,any regular unmodified mobile device should beable to connect to the mesh and use our PTT ser-vice transparently.

Regular phones from the Public Switched Tele-phone Network (PSTN) such as home phones, andcell phones, connect to the mesh by dialing a regu-lar phone number, in our case 1-877-MESH-PTT.The call is routed by the PSTN to a SIP gatewaythat is connected to the Internet (Figure 1). Nor-mally, a regular VoIP client registers with the SIPgateway in order to receive incoming calls. In ourarchitecture, the mesh Internet gateway registersas an end-client with the SIP gateway and routesmessages between the mesh and the phones in thePSTN. We do not make any changes to SIP, there-fore our protocol integrates with already deployedSIP gateways without any changes.1

Figure 2 illustrates the software architecture ofour PTT system. It includes the interface with the

1For the SIP gateway we used a service provided byVitelity (http://vitelity.com), which redirects the packetsfrom the telephone network to our mesh gateway.

mobile client, the mesh PTT session manager forthe mobile client, and the mesh PTT controller foreach PTT session in the wireless mesh network.Various multicast groups, over which communica-tion takes place, are shown. An underlying rout-ing daemon manages the routes in the mesh andprovides us with overlay group management to ef-fectively communicate on a group-based abstrac-tion. Multicast trees are calculated in a way sim-ilar to MOSPF [17]. Each of these components isdescribed in detail in the next sections.

4 Interface with Mobile Clients

A mobile client should be oblivious to the heavy-weight protocols employed in the mesh network.Further, we want to allow any 802.11 client, aswell as PSTN clients, to use the PTT service with-out changing any of the standards. To do so, ourarchitecture interacts with clients by using well es-tablished VoIP protocols.

VoIP applications use the Session Initiation Pro-tocol (SIP [19]), to establish, modify, and ter-minate a VoIP session. During the SIP sessionestablishment, the Session Description Protocol(SDP [12]) is used to describe the content of thesession (i.e., voice), the underlying transport pro-tocol (i.e., RTP), the media format, and how tosend the data to the client (address, port, etc).Data is then sent using the designated transportprotocol between the parties.

A third party call control (3pcc) server is nor-mally used to inter-connect multiple parties to-gether through a rendezvous point. Conferencecall managers are one type of 3pcc. Good prac-tices for SIP-based VoIP 3pcc servers are specifiedin RFC 3725 [18]. In essence, from an end-clientpoint of view, the 3pcc server looks exactly thesame as another end-client.

In our architecture, all mesh nodes act as a single3pcc server and share the state of the SIP connec-tion with every other mesh node in the vicinity ofthe client (between mesh nodes that can hear theclient). This is key for the system to scale as itefficiently shares information only between nodesthat can potentially need the state of the SIP con-nection as the client moves throughout the mesh,or in case the client’s mesh node crashes.

To participate in the mesh PTT session,the user specifies in its VoIP application the

4

IP address of our virtual SIP server (i.e.,“sip:ptt@192.168.1.10”). This IP is the samethroughout the mesh. Every mesh node interceptspackets sent to this address and follows the SIPprotocol to connect the client to the mesh. There-fore, the mesh network provides the illusion of asingle 3pcc to the client.

Once a SIP connection is established, the usercan start using the mesh PTT service by simplydialing the PTT group that it wishes to join. Eachdialed key generates a Dial-Tone Multi-Frequency(DTMF [20]) signal that is sent over the RTP chan-nel (by default, this signal is repeatedly sent overmultiple RTP packets to ensure that the end-nodereceives it). In our approach, we intercept DTMFsignals for control purposes between the end-clientand the mesh. For example, a client dials “#12#”to join PTT group 12. In the same way, everytime a user wishes to speak, pressing “5” or anypre-defined key combination will be interpretedas a “Request-To-Speak” control message. Oncethe system determines that it is the user’s turn,it sends an audio signal (“beep-beep”) to let theuser know that it can start to speak. While othermeans for signaling control information are possi-ble, DTMF is supported by most communicationnetworks such as PSTN, allowing us to seamlesslysupport users from these networks.

RTP data is then sent from the client to the3pcc virtual IP address through the client’s accesspoint (mesh node), which forwards the packets toevery mesh node that has a PTT client on thatgroup using a source-based multicast tree. Finally,each receiving mesh node forwards the packets toits corresponding end-clients.

5 Push-to-Talk Protocol

Providing a robust and scalable way to coordinateclient communication is the essence of the Push-to-Talk protocol. There are several ways to approachit. One possibility is to have a unique point ofmanagement in the network that every mesh nodeneeds to contact in order to register a request andget permission to speak. Such a protocol is easyto design and implement and is appropriate for de-ployment in certain environments. However, thisapproach is not a good choice for networks thatrequire high availability. For example, if a parti-tion occurs in the mesh, all the clients connected

to nodes that cannot reach the arbitration pointwill be left out of service. At the opposite ex-treme is the approach of total decentralization inwhich there is no unique entity that arbitrates thecommunication. Instead, the nodes in the meshmust coordinate and collectively decide on the or-der of serving the clients. While more complex,such a protocol is very resilient to infrastructurefailures, at the expense of a continuous communi-cation overhead in order to maintain a consistentview between the mesh nodes in the network.

For our PTT architecture, we choose a hybridprotocol that shares characteristics with both ap-proaches. As in the centralized approach, eachPTT session is managed by a controller node whichis responsible for keeping track of floor requestsand for issuing Permission-to-Speak after a partic-ipant releases the floor. However, each PTT ses-sion has is own controller node and any of the meshnodes in the network can play the controlling rolefor any session. The controller node is continuouslymonitored by other nodes and rotated when a moresuitable node (i.e., a node with a better geograph-ical position in the network) becomes available.

In addition, we completely separate floor con-trol from data dissemination. While the arbitra-tion is left to the best node to be the controller, thedata is routed optimally to all participants throughsource-based multicast trees. This allows the sys-tem to be efficient and scalable.

The details of our protocol are presented below.We start by describing how a mobile client is man-aged by a mesh node and how a PTT session ismanaged by a controller. We then present the floorarbitration mechanism. Finally, we show how theprotocol withstands node crashes and connectivitychanges such as network partitions and merges.

5.1 Client management

In order to service a client, the system requiresinformation such as the SIP call identifier, SIP se-quence number, RTP port, PTT group, PTT state(e.g., the client requests permission to speak, orhas permission to speak). Our protocol maintainsa client’s state locally, at the mesh nodes in thevicinity of the client. We choose to do so for sev-eral reasons. First, there is no single node respon-sible for the state. Instead, any node that can hearthe client maintains a state for it. Thus, the stateis preserved even when the client’s access point

5

Figure 3: Client and PTT session multicast groups.

crashes. Second, as the state is maintained in thevicinity of the client, the overhead is localized inthe part of the network where the client is located.Finally, the client state is decoupled from the con-troller node, allowing the clients’ requests to berecovered when the controller node crashes (or ispartitioned away), as we discuss below.

Client Control Group. To share the client statebetween mesh nodes that can reach a client, we as-sociate with each client an overlay multicast group.Specifically, any node that can hear the client (thatis, not only its current access point) joins and pe-riodically advertises the client state on the ClientControl Group (Figure 3). In our experiments, weshare this information every four seconds. Notethat the system is not synchronized and differentnodes may see different states for a client at a giventime. We use a combination of client timestamps(available in the SIP and RTP packets) and con-troller logical timestamps to correctly identify themost recent state of a client.

Using a localized multicast group per client hasanother benefit: The client is mobile and it canfreely move from one access point to another.When the client is granted permission to speak,the controller node uses this group to reach andnotify the client, without actually having to keeptrack of its current access point (a node can senda message to a multicast group without being amember of the group).

5.2 PTT session management

A client joins a PTT session by initiating a VoIPconversation with the virtual 3pcc server as de-scribed in Section 4, independently of its networklocation. In our protocol a PTT session is coor-

dinated by a controller node, whose presence iscontinuously monitored by other nodes. The con-troller relinquishes its role to another mesh nodeupon determining that this node is better situated(network-wise) to control the PTT session, basedon the current location of the clients participatingin the session. Three multicast groups are used tomanage a PTT session in a distributed manner.

PTT Controller Group (PTT_CONTROLLER). Foreach PTT session, there is a single mesh node —the controller — responsible for managing the floorat a given moment in time. It receives and arbi-trates requests and grants the right to speak. Inour architecture, when a node becomes the con-troller for a PTT session, it joins an overlay multi-cast group associated with that session. Maintain-ing an overlay multicast group with the controlleras the only member allows any mesh node in thenetwork to reach the controller node without actu-ally knowing its identity. Unicast communicationwith the controller is used by the protocol, how-ever, only in response to a message previously re-ceived from the controller. All client floor requestsare sent by their access points (mesh nodes) to thisgroup and are stored by the controller in a FIFOqueue. Periodically, the controller checks whetheranother mesh node is more appropriate to man-age the PTT session. In such a case, it initiates aprocedure to migrate the control to that node.

PTT Controller Monitoring Group(PTT_CMONITOR). This overlay multicast groupis used to monitor the controller node. A meshnode joins the monitoring group of a PTT sessionif it is the access point of a client that participatesin that session. In addition, the controller joinsthis group to detect the presence of another con-troller during a network merge. A ping message isperiodically sent by the controller to this group,allowing its members to monitor controller’spresence and take action if the controller is nolonger available.

PTT Data Group (PTT_DATA). This multicastgroup is used to deliver the actual voice data to theclients. A mesh node joins the PTT Data Group ofa session if it is the access point of a client in thatsession. Thus, we completely separate floor arbi-tration — coordinated by a single controller node— from data dissemination. This allows us to op-timally route data from the sender node to all theparticipants in a PTT session.

6

PTT node Controller node

Receive floor requestfrom a client

Queue the request

REQUEST_FLOOR (client)PTT_CONTROLLER group

REQUEST_ACK (client)

unicast

timeoutretry

Receive floor releasefrom a client

Handle the next request from the queue

RELEASE_FLOOR (client) ortime exceededPTT_CONTROLLER group

RELEASE_ACK (client)

unicast

timeoutretry

Permission-to-Speak

client CONTROL group

Send PTS voicesignal to the client PTS_ACK (client)unicast

timeoutretry [3 times]

Client unreachableHandle next client in the queue

Figure 4: Handling user requests.

To simplify the management of names for thesethree multicast groups, we generate their IP mul-ticast addresses using a hash function of the PTTsession identifier, such that any mesh node in thenetwork knows which groups are associated witheach PTT session without coordination. Similarly,the Client Control Group is generated as a hash ofthe client IP address.

5.3 Floor control

5.3.1 Requests handling

Figure 4 describes how the controller arbitrates thefloor such that only one user speaks at a time, whileall other users listen.

When a PTT client requests the floor, aREQUEST_FLOOR message is sent by its access point tothe PTT_CONTROLLER group. The controller queuesthe request and sends back an acknowledgment.Since the messages are not reliable, the accesspoint will retransmit the request until it receivesan acknowledgment from the controller, or untilthe client cancels its request.

Release floor requests are sent to the controllerin a similar manner. When a RELEASE_FLOOR isreceived, the controller node grants the right tospeak to the next client in the queue by sending

a PTS (Permission-to-Speak) message. This mes-sage is sent to the client using the Client Controlgroup. If the client is no longer available, a simpletimeout mechanism allows the controller to moveto the next request in its queue.

5.3.2 Migrating the controller

While there is a single controller node for a PTTsession at a given time, the system may change thecontroller over time, depending on participants’placement in the network. The idea is to avoidsituations such as when a majority of the clients ina PTT session are localized in some part of the net-work while the controller node is in another. Plac-ing the controller closer to where most participantsare reduces the latency and the amount of controltraffic in the network. In addition to improved per-formance, this migration increases the availabilityof the service in the face of network partitions be-cause it keeps the controller in the “center of grav-ity” of the clients in the PTT session. Specifically,the system computes the cost that each node wouldincur if it was the controller as the sum of the coststo reach each member of PTT_DATA group. By costwe refer to a wireless metric that may incorporatelatency or the number of hops, for example2. Notethat any node in the mesh network can be cho-sen to be a controller, regardless if it services PTTclients.

The sequence of steps performed for migratingthe controller are as follows: First, the current con-troller enters a block state, in which it does notrespond to any floor requests or releases and doesnot grant the right to speak to any client. Next,the controller sends an INVITE message to the se-lected node — the one with the lowest cost to be acontroller — which includes the queue of the pend-ing requests. Upon receiving such a message, theinvited node joins the PTT_CMONITOR group — incase it was not already a member — and also joinsthe PTT_CONTROLLER group. It now has the queue ofrequests and can safely begin controlling the ses-sion, queuing new requests and issuing PTS. An ac-knowledgment is sent back to the initial controllerso that it can leave the PTT_CONTROLLER group. In

2Additional functionality from that provided by SMeshwas added to retrieve topology and membership informationfrom the link-state and group-state updates, which in turnallows a controller to compute the euclidean distance fromevery node to a given PTT group.

7

case of a timeout during this process, the originalcontroller unblocks and continues to manage thePTT session.

5.4 Protocol robustness

Due to the inherent instability of the wireless en-vironment, it is possible for the network to parti-tion and merge. While in a well-established meshnetwork this should rarely happen, a rapidly de-ployed network during an emergency is likely toexperience such problems. In addition, any nodein such a network can crash. The PTT servicemust continue to operate even if it experiences afew seconds of interruption. Below we explain howthe protocol is resilient to these conditions.

To operate correctly, there must be a controllerand a sending node (that is, a node with a clientwith permission to speak) for each PTT session. Ifone of these is missing, either there is nobody toarbitrate the floor or nobody is currently speakingas the system waits for a node which is no longeravailable. Thus, we introduce the following mech-anisms to monitor the operation of each of thesetwo nodes (Figure 5).

5.4.1 Controller node monitoring

The controller node periodically sends a keep-alivemessage (PING_CMON) to the PTT_CMONITOR group,allowing other nodes that service PTT clients forthat session to monitor its presence. When thecontroller crashes or is partitioned away, the nodewith the lowest IP address on the PTT_CMONITOR

group volunteers to be the controller by joiningthe PTT_CONTROLLER group. However, its queue ofrequests is empty. We use a special flag in the sub-sequent PING_CMON messages to notify everybodythat a new controller was instantiated. All thenodes with pending PTT requests must re-sendtheir requests as if they were new. Thus, the con-troller’s queue is reconstructed in a best-effort way,with the requests from the current partition. Note,however, that the order of the requests in the newqueue may be different than the one from the origi-nal controller. With minimal changes, the protocolcan be adapted to recover part of the original orderestablished by the previous controller.

Another situation from which we have to re-cover is when there are multiple controllers in thenetwork. This occurs after a network merge but

Controller(lower IP address)

Controller(higher IP address)

Another controller is available

Stop queueing and handling requests

Leave PTT_CMONITOR (if needed) and PTT_CONTROLLER groups

LEAVE_REQUEST_ACK (group)unicast

LEAVE_REQUEST (Queue)

PTT_CONTROLLER

timeout Attempt to leave failed

Start queueing and handling requests

Merge queues

PING_CMONPTT_CMONITOR group

Figure 6: Detecting and recovering from multiplecontrollers.

also when the controller is lost and multiple nodesdecide to control the session (unlikely but possi-ble, as the nodes can temporary have a differ-ent view of the network’s topology). Figure 6shows the mechanism to recover from this situa-tion. Since the controller node is the only onesending keep-alive messages on the PTT_CMONITOR

group, receiving a keep-alive that is not its own in-dicates to the controller that there is at least oneadditional controller in the network. Once this sit-uation is detected, the node with the lowest IPaddress remains the controller, while the other(s)must leave the controller’s group. A redundantcontroller sends a LEAVE_REQUEST message to thePTT_CONTROLLER group with the content of its queueas it leaves the group. Upon receiving such a mes-sage, the controller with the lowest IP appends thequeue to its own, removing duplicate requests ifnecessary, and acknowledges the leave.

5.4.2 Sending node monitoring

While the members of PTT_CMONITOR group monitorthe controller, the controller in turn is responsiblefor monitoring the sending node (Figure 5). Thesending node periodically issues a keep-alive mes-sage (PTS_PING - Permission-to-Speak Ping) on thePTT_CONTROLLER group. This allows the controllerto quickly move to the next client in the queue incase of a timeout. An alternative to this approachwould be to simply wait for the maximum allottedtime per speaker to expire; however, system re-sponsiveness is important in emergency situations,

8

Network ControllerPING_CMON

PTT_CMONITOR group

Controller lost

Join PTT_CONTROLLER (if lowest IP)

Start queueing and handling requests

timeout

PTS_PING (client)

PTT_CONTROLLER groupSending node

Sending node lost

Handle the next clientin the queue

timeout

Sending clientVoice

Client not respondingSend RELEASE

timeout

monitors monitors monitors

Figure 5: Protocol robustness.

Type Sent by Sent to WhenREQUEST_FLOOR mesh node PTT_CONTROLLER group client requests floorRELEASE_FLOOR mesh node PTT_CONTROLLER group client releases floorREQ_REL_ACK controller mesh nodePTS controller CLIENT_CONTROL groupPTS_ACK node controllerINVITE controller mesh node controller changesINVITE_ACK node controllerLEAVE_REQUEST controller controller multiple controllersLEAVE_REQUEST_ACK controller controller multiple controllersREVOKE controller node multiple speakersPING_CMON controller PTT_CMONITOR group every secondPTS_PING node PTT_CONTROLLER group every second when client has PTS

Table 1: Types of messages handled by the controller node.

ruling this option out.When two or more network partitions merge,

there will be multiple controllers, but also multiplesending nodes in the network. The controller of thenewly established network withdraws the right tospeak to all additional clients by sending a REVOKE

message to their access points (mesh nodes), whichin turn notify their associated clients.

Table 1 presents a summary of the messages han-dled by the controller node.

6 Experimental results

6.1 Setup

We implemented our protocol within our opensource SMesh wireless mesh system [2] and eval-uate it in a testbed of 14 Linksys WRT54G wire-less routers deployed across several floors in threebuildings at Johns Hopkins University. Other thanour PTT system executables that implement theprotocol described throughout this paper, no otherchanges were made to SMesh.

Each of the mesh nodes is equipped with one ra-dio configured in ad-hoc mode. The data rate was

set to 18 Mbps, the transmission power to 50 mW,and the 802.11 link-layer retransmission limit to7. Unless specified, the topology of the mesh, de-picted in Figure 7, was stable.

In all experiments, when a client is granted per-mission to speak it transmits a 64 Kbps VoIPstream as 160 bytes UDP packets every 20 ms.Some experiments require a large number of si-multaneous clients. To support such experiments,we implemented a client emulator that generatedthe appropriate control and data traffic associatedwith the emulated client. From the 802.11 networkand from the PTT system perspective, there wasno difference between an emulated client and a realclient in terms of control and data traffic.

6.2 Measurements

We present four types of experiments. First, wedemonstrate the PTT system’s normal operationwith a small number of clients. Second, we demon-strate the ability of the system to scale with thenumber of clients in a PTT group. Third, wedemonstrate the ability of the system to scale withthe number of PTT groups. Last, we demonstrate

9

Figure 7: Wireless mesh network testbed.

the robustness of the system through its abilityto handle network partitions and merges correctlywhile PTT sessions are in progress.

Normal operation

This experiment involves four mobile clients, eachof them connected to a different mesh node in thenetwork (nodes 1, 2, 12, and 14 in Figure 7). Allfour clients join a PTT session and continuouslyrequest to talk. When a client is granted the floor,it immediately speaks for 20 seconds, releases thefloor, and then renews its request. Thus, the PTTsession’s queue of requests is never empty.

Figure 8 depicts the VoIP data throughputand our protocol overhead, as seen by Node 1.The overhead includes the control traffic of thePTT protocol as well as the SMesh traffic associ-ated with maintaining the mesh and the multicastgroups. This overhead ranges between 1.5 Kbpsand 5.8 Kbps, with an average of 3.4 Kbps, whichis reasonable considering that each VoIP session is64 Kbps.

Figure 8 also includes a zoom view with the ar-rival time of each VoIP packet. The figure shows aturnaround time of 137 ms from the moment thelast packet from a client is received to the momentthe first packet from the next client’s voice streamarrives. This demonstrates that only a small partof the time is consumed for synchronizing the PTTclients.

Scaling with the number of clients in a PTTsession

To test the scalability of our system, we graduallyincrease the number of clients participating in asingle PTT session. Each client connects to oneof the 14 mesh nodes in the network according toa round-robin order of their identifiers (i.e., thefirst client connects to Node 1, the second to Node

2, . . . , the 14th to Node 14, the 15th to Node 1,etc.) and requests to speak. Upon acquiring thefloor, each client speaks for 10 seconds, releases thefloor, waits for another 10 seconds, and requests tospeak again. Therefore, at any point, some clientis authorized to speak.

We consider three scenarios: (1) Each meshnode is equipped with a single radio. (2) Eachmesh node is equipped with dual radios such thatthe mesh traffic does not interfere with the mesh-to-client traffic, as the radios can be set on non-interfering channels. We emulated this dual-radioscenario in our single-radio environment by gen-erating the client’s messages locally on the corre-sponding mesh nodes and by avoiding sending datapackets from the mesh nodes towards the clients.(3) Each mesh node is equipped with a single radioand the mobile clients have no PTT support3.

For the case where clients have no PTT support,there are two main disadvantages that consider-ably affect performance. First, such clients contin-uously send VoIP packets, even when not havingthe floor. These packets are dropped by the meshnode serving the client, except for the durationswhen the client has acquired the floor. This caseincurs considerable overhead as clients send unnec-essary packets in their vicinity. The second disad-vantage is that a node needs to send individualpackets to all the clients directly connected to it,even if they are on the same PTT session. In con-trast, with PTT support clients can use the samemulticast address and local port, allowing a singlestream of multicast packets to be sent by the meshnode to all of them.

Figure 9 and 10 present the latency and loss rateof the VoIP packets received by the mesh nodes,in each of the above three scenarios, averaged over10-minute tests. With 42 clients (three clients con-nected to each mesh node), the average latency ofthe received packets was 28.42 ms for a single ra-dio and 25.52 ms for dual radio. For the thirdscenario the system can scale only up to 28 clients(114 ms latency) before the loss rate goes above5%. The experiment shows how the system scalesand demonstrates that when utilizing a PTT en-abled phone or a dual-radio configuration, the sys-tem can scale to at least 42 clients in the meshnetwork with minimal impact on latency and loss

3In our system, one can simply participate in a PTTsession using a standard VoIP phone or application.

10

0

20

40

60

80

100

0 10 20 30 40 50 60 70 80

Thr

ough

put (

Kbp

s)

Time (s)

Sender node 2Sender node 14Sender node 12

Overhead

21.7 21.8 21.9 22 22.1 22.2 22.3

Packet arrival time (s)

Source node 2Source node 12

Figure 8: 14 nodes, 4 clients, 1 PTT group. Nor-mal operation.

rate.Figure 11 presents the Cumulative Distribution

Function (CDF) of the latency for each mesh nodein the experiment with 14 clients, in a single ra-dio scenario. We can see that 95% of the packetsare received within 50 ms. Note that the num-bers for end-to-end client communication will besomewhat higher as each client is one wireless hopaway from a mesh node. The experiment showsthat there is almost no variation in latency any-where on the mesh, and that all nodes receivedmost packets within 50 ms. Note that for PTTapplications, latencies as high as 400 ms are con-sidered acceptable in PTT systems built for firstresponders [1].

Figure 12 presents the overhead traffic, as seenby a single mesh node (Node 1 in Figure 7). Thisoverhead depends on the distribution and the den-sity of the clients in the network. For betteranalysis, we separate the overhead into three dis-tinct components: (1) mesh control traffic (i.e.,link state updates generated by topology changesand control traffic for managing multicast groups).The amount of this traffic is very small, less than1 Kbps. (2) Control traffic generated by our PTTprotocol (e.g., requests, releases, ping messages,acknowledgments, etc.) Since the size of thesemessages is very small, this overhead is also low,less than 1 Kbps on average in our experiments.(3) Traffic required to locally share clients’ PTTstate (i.e., traffic on the Client Control groups).This represents the majority of the overhead, in-

creasing from 1.3 Kbps for 2 clients to 27 Kbps for42. This overhead depends on the density of themesh (how many mesh nodes can hear a client)and the number of clients. The experiment showsthat the overhead of the system as the number ofclients grows is minimal, below 1 Kbps per client.

Scaling with the number of PTT sessions

To test the scalability of our system in anotherdimension, we gradually increase the number ofsimultaneous PTT sessions in the system. EachPTT session includes four clients connected to ran-dom mesh nodes in the network. Each PTT sessioncontributes a single VoIP stream (50 packets persecond, total of 64 Kbps).

Figures 13 and 14 show the latency and loss rateas the number of PTT groups increases. With asingle radio, the system scales to 6 PTT groups,while with dual-radio, the system scales to 8 PTTgroups. Noting that the scalability of the systemwas impaired by the high overhead associated withsending small packets in 802.11 networks, we testedthe same two scenarios with packing 160 ms ofVoIP packets into one network packet at the meshnode. This approach allows us to trade some la-tency (20 ms x 7 packets = 140 ms) for an 8 fold re-duction in the number of packets in the mesh. Notethat PTT systems used by first-responders [1] em-ploy a slightly higher packing scheme of 180 ms.Packet aggregation allowed us to support up to18 PTT sessions before the latency jumped to over500 ms. The experiment shows that it pays totrade some latency with scalability in order to sup-port a larger number of PTT groups.

Robustness test

This experiment demonstrates the system’s behav-ior when there is a partition and a merge in thewireless mesh network.

We first present a small-scale scenario with 4clients (A, B, C and D) joining the network in 4different places (Node 1, Node 5, Node 9 and Node10), with A and B in one “side” of network, andC and D in the other side, as illustrated by Figure15. In the beginning, the controller of the PTT ses-sion is Node 1 and client A is granted permissionto speak. We then partitioned the network, suchthat Node 9 and Node 10 became unreachable fromNode 1 and Node 5’s side of the network. Figure

11

0

20

40

60

80

100

120

2 4 8 14 28 42

Late

ncy

(ms)

Number of clients

Single radioDual radio

Single radio - no PTT support

Figure 9: 14 nodes, 1 PTT group. Averagelatency.

0

0.2

0.4

0.6

0.8

1

1.2

2 4 8 14 28 42

Loss

(%

)

Number of clients

Single radioDual radio

Single radio - no PTT support

Figure 10: 14 nodes, 1 PTT group. Averageloss rate.

Figure 11: 14 nodes, 14 clients, 1 PTT group,single radio. Latency CDF per receiving node.

0

5

10

15

20

25

30

35

40

2 4 6 8 14 28 42

Ove

rhea

d (k

bps)

Number of clients

Mesh control trafficPTT control trafficPTT state sharing

Figure 12: 14 nodes, 1 PTT group. Averageoverhead.

15 shows the voice traffic as received by client Bin the first partition and by client D in the secondone. We can see that in the first partition the datapackets are generated by client A, and this does notchange, as expected, even after the partition occurs(around second 60). However, the right side of thepartition lost the controller. After approximately7 seconds, a new controller is generated (Node 9),the requests are recovered, and client C is grantedpermission to speak, as shown by the second par-tition’s view in Figure 15. This demonstrates thatthe system gracefully handles network partitions.

Next, we started with the network partitioned,with Node 1 and Node 5 in one partition and Node9 and Node 10 in the other, as shown in Figure 16.Each of the partitions has its own controller, Node1 and Node 9, respectively. We then merged thenetwork by connecting a mesh node that is the onlyconnection between the two sides of the network.We analyze the voice data received by clients B andC (Figure 16, partition views). We can see that be-fore the merge the data is sent by client A in the

first partition and by client D in the second. As thenetwork begins to merge, both B and C start get-ting voice traffic from both senders. Shortly afterthe network routes became stable, the controllersdetected each other and client A’s right to speakis revoked by Node 9, the newly established con-troller. Thus, the one-to-many communication isreinforced. Clients’ voice traffic was corrupted —due to multiple voice streams — for about 686 ms(35 packets). This demonstrates that the systemgracefully handles network merges, quickly elimi-nating redundant controllers.

Finally, we benchmark the system in a largescale partition and merge scenario, with 40 partic-ipants in 10 simultaneous PTT sessions. Similarto the scalability experiment, the sending client ineach group changes every 10 seconds. Figure 17shows the overall traffic in the vicinity of Node1 (as observed by setting Node 1 in promiscuousmode and counting all the packets in its vicinity).To better understand the system’s behavior, wepresent in the top graph both the data and over-

12

0

500

1000

1500

2000

2500

3000

0 2 4 6 8 10 12 14 16 18 20

Late

ncy

(ms)

Number of PTT groups

Single radioDual radio

Single radio + PackingDual radio + Packing

Figure 13: 14 nodes, 4 clients per PTT group.Average latency.

0

2

4

6

8

10

12

14

16

18

20

0 2 4 6 8 10 12 14 16 18 20

Loss

(%

)

Number of PTT groups

Single radioDual radio

Single radio + PackingDual radio + Packing

Figure 14: 14 nodes, 4 clients per PTT group.Average loss rate.

Mesh node

Controller

Mobile client

Sending client

Mesh Network

1

5

10

9

A

B

C

D

A B D CQueue

0

20

40

60

80

100

0 20 40 60 80 100

Rec

eive

d D

ata

(kbp

s)

Time (s)

Partition 1

Source: client ASource: client C

0

20

40

60

80

100

0 20 40 60 80 100

Rec

eive

d D

ata

(kbp

s)

Time (s)

Partition 2

Source: client ASource: client C

Figure 15: 14 nodes, 4 clients, 1 PTT group. Network partition.

Mesh node

Controller

Mobile client

Sending client

Mesh Network

1

5

10

9

A

B

C

D

D CQueueA BQueue

0

20

40

60

80

100

0 20 40 60 80 100

Rec

eive

d D

ata

(kbp

s)

Time (s)

Partition 1

Source: client ASource: client D

0

20

40

60

80

100

0 20 40 60 80 100

Rec

eive

d D

ata

(kbp

s)

Time (s)

Partition 2

Source: client ASource: client D

Figure 16: 14 nodes, 4 clients, 1 PTT group. Network merge.

head traffic, and separately, in the bottom graph,two components of the overhead traffic: routingcontrol traffic (link state, multicast group man-agement) and PTT protocol control traffic. Forclarity, we do not show the overhead traffic asso-ciated with sharing the state of a client within hisvicinity, as it was already shown in Figure 12.

Following the overhead traffic, we can see theroute updates that are generated when clients jointhe network (point A), as well as the overhead re-lated to clients joining a PTT group and asking forpermission to speak (point B). The system oper-ates normally until second 265 (point D), when thenetwork partitions. Then, many of the sessions inNode 1’s partition lose their speaker or their abilityto route to some PTT members. When the con-

nectivity stabilizes, new speakers are granted per-mission to speak (point E). Note that the amountof VoIP traffic is smaller, as some PTT sessionsno longer have members in the current partition,or do not have to route through Node 1’s vicin-ity PTT session messages. Around second 310(point F), the network merges, causing a spike inboth data and overhead traffic. Shortly after that,network routes stabilize and normal operation isresumed. Lastly, around second 380 (point G), allthe clients stop speaking and the data rate drops tozero. Since clients did not leave their PTT groups,the overhead associated with maintaining PTT ses-sions remains constant through the end of the ex-periment. This elaborate scenario demonstratesthe robustness of the system to network connec-

13

0

500

1000

1500

2000

2500

0 50 100 150 200 250 300 350 400 450

Tra

ffic

(kbp

s)

Time (s)

A

B

C D

E

FG

(a) Data and overhead traffic.

0

20

40

60

80

100

0 50 100 150 200 250 300 350 400 450

Tra

ffic

(kbp

s)

Time (s)

A

B C D

E

F

G

(b) Overhead traffic.

Figure 17: 14 nodes, 40 clients on 10 PTT groups. Network partition and merge: (A) clients joins,(B) clients request to speak, (C) regular operation, (D) network partitions, (E) network stabilizes afterthe partition, (F) network merges, (G) clients stop speaking.

tivity changes while supporting a large number ofdistinct PTT sessions.

7 Conclusion

In this paper we presented a robust Push-to-Talkprotocol for wireless mesh networks. The architec-ture seamlessly integrates standard VoIP phonesas well as regular phones and cell phones fromthe PSTN network to support heterogeneous envi-ronments. The protocol provides high availabilitywhile efficiently arbitrating the PTT sessions andefficiently disseminating voice traffic. We imple-mented our protocol within an open source wirelessmesh system and evaluated it in a 14 node testbed.Experimental results demonstrate the scalability ofour system and its operation in the presence of net-work connectivity changes such as partitions andmerges.

8 Acknowledgements

We thank Wyatt Chaffee for his help in interfacingwith a VoIP phone via SIP and intercepting DTMFsignals. His help is greatly appreciated. We alsothank Pratibha Mallya for helping us understandthe problem in more detail, and Professor JasonYi-Bing Lin for introducing us to PTT during hisvisit to Johns Hopkins University.

References

[1] Project 25, Association of Public-Safety Communications Officials.http://www.apco911.org/frequency/project25.

[2] The SMesh wireless mesh network.http://www.smesh.org.

[3] The federal response to hurricane katrina:Lessons Learned, February 2006. Washington,DC: Office of the Assistant to the Presidentfor Homeland Security and Counterterrorism.

[4] Open Mobile Alliance. Push-to-talk over cel-lular (poc), release 1.0, 2005.

[5] Yair Amir, Claudiu Danilov, Michael Hilsdale,Raluca Musaloiu-Elefteri, and Nilo Rivera.Fast handoff for seamless wireless mesh net-works. In MobiSys 2006, pages 83–95, NewYork, NY, USA, 2006. ACM Press.

[6] K. Balachandran, K.C. Budka, T.P. Chu,T.L. Doumi, and J.H. Kang. Mobile respon-der communication networks for public safety.Communications Magazine, IEEE, 44(1):56–64, Jan. 2006.

[7] Andras Balazs. Push-to-talk performance overgprs. In MSWiM ’04: Proceedings of the 7thACM international symposium on Modeling,analysis and simulation of wireless and mobile

14

systems, pages 182–187, New York, NY, USA,2004. ACM.

[8] S.M. Banik, S. Radhakrishnan, Tao Zheng,and C.N. Sekharan. Distributed floor controlprotocols for computer collaborative applica-tions on overlay networks. Collaborative Com-puting: Networking, Applications and Work-sharing, 2005 International Conference on,pages 10 pp.–, 19-21 Dec. 2005.

[9] L.A. DaSilva, G.E. Morgan, C.W. Bos-tian, D.G. Sweeney, S.F. Midkiff, J.H. Reed,C. Thompson, W.G. Newhall, and B. Wo-erner. The resurgence of push-to-talk tech-nologies. Communications Magazine, IEEE,44(1):48–55, Jan. 2006.

[10] Hans-Peter Dommel and J. J. Garcia-Luna-Aceves. Floor control for multimedia confer-encing and collaboration. Multimedia Syst.,5(1):23–38, 1997.

[11] S. Ganguly, V. Navda, K. Kim, A. Kashyap,D. Niculescu, R. Izmailov, S. Hong, and S.R.Das. Performance optimizations for deploy-ing voip services in mesh networks. SelectedAreas in Communications, IEEE Journal on,24(11):2147–2158, Nov. 2006.

[12] M. Handley and V. Jacobson. SDP: SessionDescription Protocol. RFC 2327, April 1998.

[13] Petri Koskelainen, Henning Schulzrinne, andXiaotao Wu. A sip-based conference controlframework. In NOSSDAV ’02: Proceedings ofthe 12th international workshop on Networkand operating systems support for digital au-dio and video, pages 53–61, New York, NY,USA, 2002. ACM.

[14] Jonathan Lennox and Henning Schulzrinne.A protocol for reliable decentralized confer-encing. In NOSSDAV ’03: Proceedings ofthe 13th international workshop on Networkand operating systems support for digital au-dio and video, pages 72–81, New York, NY,USA, 2003. ACM.

[15] Radhika Malpani and Lawrence A. Rowe.Floor control for large-scale mbone seminars.In MULTIMEDIA ’97: Proceedings of the fifthACM international conference on Multimedia,

pages 155–163, New York, NY, USA, 1997.ACM.

[16] Florian Maurer. Push-2-talk decentralized.2004.

[17] J. Moy. Multicast extensions to OSPF. RFC1584, IETF, March 1994.

[18] J. Rosenberg, J. Peterson, H. Schulzrinne,and G. Camarillo. Best Current Practices forThird Party Call Control (3pcc) in the SessionInitiation Protocol (SIP). RFC 3725, April2004.

[19] J. Rosenberg, H. Schulzrinne, G. Camarillo,A. Johnston, J. Peterson, R. Sparks, M. Han-dley, and E. Schooler. SIP: Session InitiationProtocol. RFC 3261, June 2002.

[20] H. Schulzrinne and S. Petrack. RTP Payloadfor DTMF Digits, Telephony Tones and Tele-phony Signals. RFC 2833, May 2000.

[21] D.S. Sharp, N. Cackov, N. Laskovic, QingShao, and L. Trajkovic. Analysis of pub-lic safety traffic on trunked land mobile ra-dio systems. Selected Areas in Communi-cations, IEEE Journal on, 22(7):1197–1205,Sept. 2004.

[22] Michael R. Souryal, Johannes Geissbuehler,Leonard E. Miller, and Nader Moayeri. Real-time deployment of multihop relays for rangeextension. In MobiSys ’07: Proceedings of the5th international conference on Mobile sys-tems, applications and services, pages 85–98,New York, NY, USA, 2007. ACM.

15