A Full-distributed Architecture for PoC Application in Data Packet Voice Communication

Qi Wang1, 3, Hai Jiang1, 3, Albert K. Wong2, Jun Li1, Zhongcheng Li1

1 Institute of Computing Technology, Chinese Academy of Sciences, Beijing, China 2 Hong Kong University of Science and Technology, Hong Kong, China 3 Graduate University of Chinese Academy of Sciences, Beijing, China

{wangqi08, jianghai}@ict.ac.cn, eealbert@ust.hk, {lijun, zcli}@ict.ac.cn

Abstract—Push-to-Talk over Cellular (PoC) is a “walkie-talkie” like voice communication service over mobile wireless networks, based on Voice over IP (VoIP) technology. The traditional PoC defined in the Open Mobile Alliance (OMA) specification is a centralized architecture. In this architecture, servers need to be deployed for the PoC service to work and be widely available, presenting a substantial cost to ISPs. Meanwhile, the problem of network congestion and one point failure existing in the centralized architecture may degrade system performance and cause the failure of an entire system. In addition, the traditional floor control based on the centralized architecture, also suffers from the drawbacks of using a centralized controller. In this article, we propose a full-distributed architecture for PoC application (FDPoC) in data packet voice communication. In the full-distributed architecture, we propose an ALM-based distributed data packet transmission mechanism and a distributed floor control (DFC) algorithm to alleviate the above issues. In terms of average end to end delay, average max end to end delay and average floor determination delay, the performance of the proposed FDPoC and DFC algorithm are investigated through our analytical model.

Keywords—Push-to-Talk over Cellular (PoC); full-distributed; voice communication; floor control; Voice over IP (VoIP)

I. INTRODUCTION Push-to-Talk over Cellular (PoC) [1] is a “walkie-talkie”

like voice communication service over mobile wireless networks, based on Voice over IP (VoIP) technology. The PoC application which allows one-to-one and one-to-many voice communications, offers attractive features distinguished from traditional phone cells, such as ease-to-use and always-on. Due to half duplex of the communication, only one participant can speak at a time, while the others can listen. In this mechanism, one may speak only after the right to the floor is obtained, by pressing a “talk” button on their terminals.

The traditional PoC defined in the Open Mobile Alliance (OMA) specification is a centralized architecture. In this architecture, as shown in Fig.1 (a), servers for forwarding data packets and floor control need to be deployed. However, in the extreme environment that no servers can be deployed, the traditional PoC may fail to communicate successfully. Besides, servers need to be deployed for PoC service to work and be widely available, which presents a substantial cost of ISPs. Meanwhile, more serious shortcomings existing in the centralized architecture, such as server with high load, network

congestion and one point failure, may degrade system performance and cause the failure of an entire system. In addition, the traditional floor control based on the centralized architecture, also suffers from the drawbacks of using a centralized controller. In all these scenarios, PoC may be reflected badly in the application performance, and eventually the overall user experience will be affected.

Thus, we propose a full-distributed architecture for PoC application (FDPoC) to alleviate the problems above. As shown in Fig.1 (b), data packets can be relayed not by servers but by PoC nodes. In the architecture, we also propose a distributed data packet transmission mechanism based on application-layer multicast (ALM) and a distributed floor control (DFC) algorithm. The performance of our FDPoC and DFC algorithm is investigated analytically in the paper.

The rest of this paper is organized as follows: In section II, a summary of related work is provided. The full-distributed architecture for PoC is described in section III followed by the demonstration of our DFC algorithm in section IV. After that, in section V, we analytically evaluate our FDPoC and DFC algorithm. Section VI presents our simulation and numerical results, and finally, section VII provides the conclusions.

II. RELATED WORK The PoC service over cellular networks has received

significant interests in the research field. In [2] and [3], the design and implementation of a client and a server for the PoC service based on the OMA specification have been described, respectively. In [4], system architecture is proposed and evaluated for efficient implementation of PoC services in 3G packet switched network. In [5], a PoC service for packet-switched networks accessed via GPRS/UMTS or WLAN technology, which is compliant with the OMA specification, is provided. The performance evaluation and optimization of PoC applications are also broadly studied in [6], [7], [8], [9] and [10]. To our knowledge, most of the studies for PoC service focuses on the OMA-based centralized architecture, however, there has been a rise of research in distributed architecture in recent years. In [11], a distributed PTT system for the intelligent transportation systems environment is proposed in which group communication is performed through distributed learning interaction unlike the OMA central arbitrator approach. In [12], a distributed and mobile-operator independent network architecture, which mainly alleviates the low scalability and

2011 11th IEEE International Conference on Computer and Information Technology

978-0-7695-4388-8/11 $26.00 © 2011 IEEE

DOI 10.1109/CIT.2011.21

231

2011 11th IEEE International Conference on Computer and Information Technology

978-0-7695-4388-8/11 $26.00 © 2011 IEEE

DOI 10.1109/CIT.2011.21

231

(a) OMA_Based PoC (b) FDPoC

Figure 1. Examples of OMA_Based and FDPoC Network Architecture

high cost issues existing in the centralized architecture, is proposed. In this mechanism, a super node is used for signaling, voice relaying, member joining/leaving and floor control. It is noteworthy that this network architecture is half-distributed that suffers from the following issues:

� Existence: Some capabilities such as high bandwidth, low power consumption and high computing performance are necessary for super nodes. If the super node does not exist, the ordinary node cannot relay a large amount of data packet or realize the floor control.

� Reliability: The crash of the super node results in the failure of the entire system. Also, the occurrence of congestion at the super node degrades system performance significantly.

� Limited scenario: PC is usually chosen to complete the function of the super node. However, in the PoC application, PC as the user equipment is infrequent. So it limits the applied scenarios.

Thus, the design of full-distributed architecture for PoC application is necessary to combat with the problems above.

III. FULL-DISTRIBUTED ARCHITECTURE FOR POC In our full-distributed architecture, there are no servers or

super nodes for data packets transmission or floor control. Only the ordinary PoC clients are used for forwarding the voice/signaling data packets and handling floor control. The features of our full-distributed architecture supported in PoC are as follows:

� Ease-of-deployment: There is no need to deploy servers for the PoC service to work.

� Low service charge: The users only needs to pay for the Internet connection service, not pay for the PoC service. It will be the most attractive advantage to users.

� High reliability: It avoids one point failure problem because of no servers. Moreover, load balancing increases the robust of the PoC system and eliminates the network congestion problem.

In this section, we will present our full-distributed architecture in two parts: registration procedure, data packet transmission mechanism.

A. Registration Procedure In the traditional PoC architecture, PoC clients have to

register with a server before conducting any conversation. However, in our full-distributed architecture, there will be no servers to complete the registration procedure. Thus, we need to register in a distributed fashion.

When a PoC client (e.g. 0C ) wants to join a communication group, it should know at least one communication member’s address and then sends REGISTER message to that member(e.g. 1C ). After the REGISTER message has been received and authenticated by 1C , 1C adds 0C to the group membership list and then sends OK message with group member list to 0C . Similarly, the registration procedure for many PoC members will be completed in the same way.

After the register procedure, each group member maintains a complete group membership list to achieve high degree of robustness. Since PoC is usually targeted towards small to medium sized groups, maintaining the complete group membership list does not bring lots of overhead [14]. Every group membership list needs to be updated when a new member joins or an existing member leaves.

B. Data Packet Transmission Mechanism In the traditional PoC architecture, data packets need to be

forwarded to the group members by servers. However, in our full-distributed architecture, we need to forward data packets by PoC clients. Considering flexibility and ease-of-deployment, Application-layer multicast (ALM) is a compelling group-communication technique. We use ALM [14] to construct the source-based voice/signaling transmission paths. Furthermore, the transmission paths need to be adjusted to adapt to network dynamics.

1) Path construction of the source-based voice/signaling transmission

232232

The process of the implementation can be divided into two steps. Firstly, we construct an overlay structure among participating group members. The overlay network is represented by a connected graph � �,G V E� , consisting of a set of PoC nodes � �1 2, , , NV C C C� � , N is the total number of group members. All the link paths among group members are described as � �, ,ijE l i j V� � , ijl is the overlay link between

iC and jC . Secondly, we construct per-source degree-bounded minimum delay spanning trees for voice/signaling delivery.

Based on a communication model in [13], we define the delay ( , )d u v experienced by a message that travels from node u to node v as being composed of two elements: Transmission delay ( , )t u v -which represents the delay of transmission through the unicast path between u and v . Processing delay ( )p u -which represents the delay of data packets duplication and relaying at node u . Consequently, the delay ( , )d u v can be computed as ( , ) ( , ) ( )d u v t u v p u� .

The tree topology will affect the performance of the voice/signal transmission and floor control mechanism directly. Our aim is to decrease the data transmission delay and processing delay. Thus we use degree-bounded minimum maximum delay spanning trees to construct the transmission path for each node.

Hence, the problem of degree-bounded minimum maximum delay spanning trees is formulated as follows:

Target function: ( , ) ( , )

min max ( ( ) ( , ))im n P r C

p m t m n �

�

Subject to: max( ) ( )T i id C d C�

Variables: iC V �

r : is the root of the tree;

( , )iP r C : is a paths’ set containing all the paths form node r to node iC .

After the path construction procedure, each node has a self-rooted multicast tree. The advantages of this approach are that it minimizes the voice/signal delay and increases the robustness of the entire system.

2) Adaptive to network dynamics When a member joins/leaves or the communication delay is

greater than the maximum tolerant time mT , the multicast tree should be adjusted directly or reconstructed when the root node does not speak.

� Member Joining

After the registration and authentication procedures, the joining member will receive a group membership list. Then it chooses any group member with residual degrees from each multicast tree to send joining request. Finally, the joining member attaches to each multicast tree through its access nodes. Meanwhile, the new member constructs a self-source degree-bounded Minimum delay spanning trees.

� Member Leaving

Member leaving without notification should be detected locally and notified to the rest of the group members. In [14-16], many distributed failure detection algorithms have been proposed. We only concern with the case that a member notifies its neighbors before leaving.

The leaving of leaf nodes may not impact the multicast, however, the leaving of branch nodes may bring partitions of the multicast tree. Thus, we employ a fast repair scheme to remerge these partitions. We choose one of the children of the leaving node, which has minimum delay from the parent of the leaving node, to replace the position of the leaving node. If there is another child node of the leaving node, it will be attached to the node with available degrees.

� Communication Delay

In cellular network, if a node suffers from poor channel condition, its descendants will suffer from long delay. Besides, the new node insertion, the branch node leaving or the node moving could also make the multicast tree suboptimal with respect to the delay. In order to maintain optimality, the reconstruction process will be initiated according to the delay. The details of the initiation of the reconstruction can be described as follows. When the member detects that the communication delay is greater than mT by sending detecting packets periodically, it will notify the root node to reconstruct the multicast tree. The root node initiates the reconstruction process when it does not speak, thus the reconstruction will not interrupt the communication.

IV. DISTRIBUTED FLOOR CONTROL When the call originator releases the floor, other group

members who wish to talk can compete for the next floor by pressing the button. To adapt our Full-distributed PoC Architecture, we propose a distributed floor control (DFC) algorithm based on our multicast tree.

In [12], the author defined a relative timestamp and a run number. A relative timestamp is the length of the time from when Floor Release is received to the subsequent time that the Floor Request is made. A run number included in each floor control messages is a sequence number for identifying the floor in order to prevent the interference from messages of different floor contention iterations. Every client needs maintaining a run counter. The run number will be increased by one when the floor owner releases the floor. We adopt these two definitions to our DFC algorithm.

In DFC algorithm, the requesting clients send Floor Request to all the other clients through the self-rooted multicast trees. The receiving clients who do not want to speak in this session will reply with Floor ACK to the requesting clients. The receiving client who has issued the Floor Request compares the relative timestamps of the requests with the request it sent before. If the received timestamp of the request is smaller, it will send Floor ACK to the requesting client. Otherwise, it will send Floor Reject to the requesting client. The requesting client could gain the floor only when the reply messages from all the other nodes are obtained.

233233

In DFC algorithm, if a client has received a Floor Request message before sending a floor Request message, it cannot send Floor Request at this floor contention session. Before describing the algorithm, we define ( )iTree C as the multicast tree rooted iC , max ( )iT C as the maximum delay from the root

iC to the leaf node, iT as the relative time stamp of iC and iF as the run number of iC .

Algorithm DFC ( iC ) Begin

1. For each node in the PoC group 2. If iC requests for the floor

3. Send Floor Request Re ( , , )i iquest F T i to all the other group

members through ( )iTree C and set timer 2 max ( )iT C

4. While 0timer � 5. If iC has obtained Floor ACK messages from all the

other nodes in the ( )iTree C

6. iC gains the floor 7. Breaks 8. End if 9. timer � � 10. End While 11. iC sends heartbeat messages to the nodes who haven’t replied

12. If iC has received all the Reply Active messages

13. iC will not gain the floor in this session 14. Else 15. The node without replying is down, iC needs to notify it

to all the other nodes and reconstruct the multicast tree. 16. End If 17. Else If iC has received Re ( , , )j jquest F T j

18. If iC doesn’t want to speak in this session

19. Send Floor ACK to jC through ( )jTree C

20. Else 21. _ _ ( , ; , )i j i jFloor control compare F F T T

22. End if 23. End if 24. End For

End

_ _ ( )Floor control compare run numbers relative time stamps Begin

1. If i jF F� and i jT T�

2. iC sends Floor Reject to jC through ( )jTree C

3. Else if i jF F� and i jT T�

4. iC sends Floor ACK to jC through ( )jTree C

5. Else if i jF F� and i jT T�

6. iC and jC should re-request for the floor

7. Else if i jF F�

8. iC sends Floor ACK to jC through ( )jTree C 9. Else 10. iC discards this Re ( , , )j jquest F T j 11. End if

End

Figure 2. The Pseudo-code of DFC Algorithm

Considering the network congestion there may be outdate messages that traverse on the network or the situation that clients did not participate in the last PoC conservation session. If the client receives the floor control messages with smaller run number than its own run number, it means that the messages traversing on the network are outdated, then the messages will be discarded. Otherwise, it means that the clients didn’t participate in the last conservation. Therefore, floor control will be handled in the normal way and the run number of the client will be adjusted. The DFC algorithm is presented in Fig.2.

V. PERFORMANCE EVALUATION In this section, we focus on the performance analysis of our

proposed full-distributed architecture for PoC and DFC algorithm. An analytical model is constructed based on end-to-end delay model [18][19] for PoC traffic. Fig. 3 illustrates the end to end delay for one-to-one PoC voice communication. Similarly, the end to end delay for one-to-many PoC voice communication can be analysed.

Figure 3. End to End Delay Model for PoC Traffic

In order to evaluate the performance of FDPoC and DFC, we use the following metrics: average end to end delay, average max end to end delay and average floor determination delay.

A. Average End to End Delay End-to-End delay is defined as the length of the period

between the time when one side begin to speak and the subsequent time when the other side hear the corresponding voice. Notations and definitions used in our performance model are shown in Table 1.

On the basis of [19], the end to end delay from the root node to the i-th node in multicast tree can be derived as

21( ) ( 2)

iRi m

e e enc pack mnet que i relay dejit decm

T T T T T l T T T�

� � � (1)

Judging from the delay characteristics, the end-to-end delay can be divided into two parts: fixed parts and variable parts. The fixed delay contains encT , decT , packT , mnetT , relayT and dejitT . We assume relayT and dejitT are fixed, since relayT has a small variation compared with the end to end delay. Meanwhile, we are not interested in dejitT delay in this paper, thus we can use fixed playout delay [20] to simplify the end to end delay. m

queT is a variable delay and follows an exponential distribution [20].

234234

Table1. Notations and Definitions for Performance Evaluation

Notation Definition

2i

e eT End-to-end delay from the root node to the i-th node in multicast tree

encT Voice encoding delay

packT Packetization delay

mnetT Total minimal network delay in each network router/gateway

iR The number of routers from the root node to the i-th node in multicast tree

mqueT Queueing delay in the m-th router/gateway

relayT Relay delay of the relay node (PoC node)

dejitT Dejittering delay (playout delay)

decT Voice decoding delay

N

Total number of PoC clients in the session

i.e.,1

1i

m

il

N n�

� �

m Depth of the multicast tree

Hence, 2i

e eT follows a hypoexponential distribution [20][21], for it is composed of R exponential distributions with different rates in series. Then 2

ie eT is expressed as

21

( )iR

i me e que fix i fix

mT T T Hypo R T

�

� � � (2)

where fixT is a fixed delay given by

1

( 1)iR

fix enc pack mnet i relay dejit decm

T T T T l T T T�

� � � (3)

Based on the above analysis, the average end to end delay 2e eT can be computed as

1 1

2 21 1

1 1 ( ( ) )1 1

N Ni

e e e e fixi i

T T Hypo R TN N

� �

� �

� � � �� � (4)

B. Average Max End to End Delay Average max end to end delay denotes that average max

delay from the root to leaf node in the multicast tree. It can be computed as 2max( )i

e eT .

C. Average Floor Determination Delay Average floor determination delay is average waiting time

of the Floor Request that is granted or rejected. Notations and definitions used in this section are shown in Table 2.

In wireless communication system, basal time unit is the time that a cell or a packet transmits from sender to receiver, which we call a slot. We assume floor control messages are transferred reliably over the network, Floor Request issues as a probability of p at each time slot, and no Floor Request issues as a probability of 1 p� at each time slot. Different time slots are independent of each other. Thus, relative time stamp T for each floor request is a geometric distributed.

Table2. Notations and Definitions for Performance Evaluation

Notation Definition

il The layer of the i-th node in multicast tree i.e., 1il �

in Number of the i-th layer nodes in the multicast tree

N

Total number of PoC clients in the session

i.e.,1

1i

m

il

N n�

� �

m Depth of the multicast tree

GT Waiting time of obtaining the floor, i.e., the average waiting time between when a PoC client issues a request and when it is granted to speak

DT Average waiting time of the floor request rejected

wT Floor determination delay, i.e., average waiting time of the floor request that is granted or rejected

T Relative timestamp of the floor request

p Average request issue probability per slot of a PoC client

GP Probability that the request of a PoC client is granted

, iD lP Probability that the request of a PoC client is rejected by the il -th layer nodes of root in the multicast tree

DP Probability that the request of a PoC client is rejected

1{ } (1 )kP T k p p�� � � (5)

A client requests the floor will wait for 22max ie eT before

the request is granted. Thus, GT can be derived as

22max( )iG e eT T� (6)

It is clear that the floor request of a PoC client will be granted only when its timestamp is smallest of all the requests. We assume the one PoC client’s relative timestamp is k . The client can obtain the floor only when other clients don’t send request in the period time k . So, GP can be computed as

� �� �11

1

(1 ){ }1 (1 )

NNG N

k

p pP P T k P T kp

� ��

�

�� � � �

� �� (7)

The floor request of a PoC client will be rejected only in the following situation: The client is rejected by the second layer nodes in a time period of 2 ( 2)i

e e iT l � , or by the third layer

nodes 2 i( 3)ie eT l � in multicast tree and so on. The probability

that the request of a PoC client is rejected by the i-th layer nodes , iD lP can be divide into two cases, that is 2il � and 2il � , it can computed respectively as

� �1,

11 { } { }

in

D lk

P P T k P T k�

�

� � � �� ( 2il � ) (8)

� �1 2 1,

1{ } 1 { } { }i i

in n n n

D lk

P P T k P T k P T k��

�

� � � � �� �

1 2 1 1 2

1 2 1 1 21 1(1 ) (1 )

1 (1 ) 1 (1 )

i i

i i

n n n n n n

n n n n n np ppp p

�

�

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

� �

� � ( 2il � ) (9)

235235

Therefore, the probability that the request of a PoC client is rejected DP is

1

,2

(1 )11 (1 )i

i

m N

D D l Nl

p pP Pp

�

�

�� � �

� �� (10)

Based on (9) and (10), the average waiting time of the floor request rejected DT can be expressed as

, 22

2i

i

mi

D D l e el

T P T�

� � (11)

Based on above analysis, the average floor determination delay wT can be computed as

w G G D DT T P T P� 1 1

2 , 22

(1 ) (1 )2max( ) 2 (1 )1 (1 ) 1 (1 )i

i

mN Ni i

e e D l e eN Nl

p p p pT P Tp p

� �

�

� �� �

� � � �� (12)

VI. SIMULATION RESULT In this section, we design a simple simulation scenario

using MATLAB to evaluate performance of FDPoC and DFC. To illustrate the advantage of our proposed architecture for PoC, we compare the FDPoC with OMA_based PoC. The experiments for both architectures run 100 times.

We created PoC nodes located randomly in the square area of 5000 5000� square meters following a uniform distribution, and connected them randomly. The link delay mainly consists of service time of routers and link transmission delay. We consider the number of routers for each link set between 2 and 10 randomly, meanwhile the service time of each router follows a Gaussian distribution with average 1/ r� which varies from 2 to 10ms [18]. The link transmission delay is 5 microseconds per kilometer. We assume the processing delay for each PoC node is 20ms and the max degree of node is 3.

We consider two different scenarios for OMA_based PoC: high load and low load. In the high load scenario, we assume that the processing delay of PoC server with high load is 50ms. In the low load scenario, it is setted to 5ms. The impact of different parameters on the key metrics will be illustrated in following subsections.

A. Average End to End Delay To analyze the effect of N on average end to end delay,

we vary N from 5 to 30. As shown in Fig.4, the average end to end delay of FDPoC is much smaller than that of OMA_based PoC with high load and not too much lager than that of OMA_based PoC with low load. As a result, compared to OMA_based high load, FDPoC reduces the average end to end delay by about 37.2% .

B. Average Max End to End Delay To analyze the effect of N on the max end to end delay,

we let the parameter N varies from 5 to 30. As show in Fig.5, the average end to end delay of FDPoC is smaller than that of OMA_based PoC with high load and not too much lager than that of OMA_based PoC with low load. In addition, the curves

Figure 4. Average End to End Delay for Different N

Figure 5. Average Max End to End Delay for Different N

Figure 6. Average Floor Determination Delay for Different N

236236

for OMA_based PoC with low load and high load increase notably, but there is a little effect on FDPoC. This case shows that max end to end delay is not influenced much by the number of PoC clients in our FDPoC.

C. Average Floor Determination Delay To analyze the effect of p and N on the average floor determination delay, we let the parameter p vary from 0.1 to 1. We set 5N � , 10N � , 15N � , 20N � , 25N � and 30N � , respectively. As show in Fig.6, wT decreases with the increases of parameter p . That is, when p increases, the average waiting time of the floor rejected will be much less. Therefore, the average floor determination delay decreases. This means that if most of the PoC clients are more eager to speak (e.g., the PoC clients are having discussing), the average floor determination delay will be much less. Apparently, we can also see that wT decreases with N . The reason is that the larger the number of clients is, the larger the rejected probability will be.

VII. CONCLUSION In this paper, the full-distributed architecture is proposed for PoC application in data packet voice communication to alleviate the issues of the centralized architecture based on OMA standard. Our contributions are threefold. Firstly, in our full-distributed architecture, the data packet transmission mechanism based on ALM is proposed. Secondly, we present our DFC algorithm for floor control mechanism to fit our full-distributed architecture. Thirdly, we evaluate the performance and present the numerical results, to show the advantage and capabilities of our FDPoC and DFC algorithm. As analyzed earlier, compared to OMA_based high load, FDPoC reduces the average end to end delay by about 37.2% . Meanwhile the max end to end delay is not influenced much by the number of PoC clients in our FDPoC. Thus, our full-distributed architecture for PoC application is feasible and efficient. Furthermore, it can be a supplement to OMA_based PoC with high load.

ACKNOWLEDGMENT This work is supported by the National High-Tech

Research and Development Plan of China under Grant No.2009AA01A344 and the National Natural Science Foundation of China under Grant No.61003266.

REFERENCES [1] OMA (Open Mobile Alliance), “Push to Talk over Cellular (PoC)

Architecture,” OMA-AD-PoC-V2_1-20090317-C, Candidate Version 2.1, Mar. 2009.

[2] Lin-Yi Wu, Meng-Hsun Tsai, Yi-Bing Lin, and Jen-Shun Yang, “A client-side design and implementation for Push to Talk over cellular service,” Wireless Communications and Mobile Computing, Jun. 2007.

[3] Parthasarathy, “A.Push to talk over cellular (PoC) server,” IEEE Proceedings of Network, Sensing and Control, pp.772-776, Mar. 2005.

[4] Paktale, S.K, “3PoC: An architecture for Enabling Push to Talk Services 3GPP Networks,” IEEE International Conference on Personal Wireless Communications (ICPWC’05), pp.202-206, Jan. 2005.

[5] Kim P., Balazs A., Broek E., Kieselmann G., and Bohm W., “ IMS-based Push-to-Talk over GPRS/UMTS,” IEEE Wireless Communications and Networking Conference, Mar. 2005.

[6] Wei-Peng Chen, licking S., Ohno T., et al. “Peroformance Measurement, Evaluation and Analysis of Push-to-Talk in 3G networks,” IEEE International Conference on Communications (ICC’07), pp. 1893-1898, Jun. 2007.

[7] EO’Regan, D Pesch, “Performance Estimation of a SIP based Push-to-Talk Service for 3G Network,” Fifth Europen Wireless Conference (EW’04), Feb. 2004.

[8] Tsaur, D.-J. , Chia-Lung Liu, “Efficiency Analysis and Improvement of SIP-based Push-to-Talk over Cellular,” 2010 Fourth International Conference on Genetic and Evolutionary Computing (ICGEC), Dec. 2010.

[9] M.T. Alam, Z. D. Wu, ‘Dimensioning and optimization of Push-to-Talk over celluar server,” International Journal of Network Management, Vol. 18, No.1, pp. 47-63, Mar. 2007.

[10] Zhou Xing and Lu Meilian, “Performance Evaluation of IMS-Based Push-to-Talk Service over Multiple Wireless Access Networks,” Wireless Communications, Networking and Mobile Computing, Sep.2009.

[11] Chai-Hien Gan and Yi-Bing Lin, “Push-to-Talk Service for Intelligent Transportation Systems,” IEEE Transactions on Intelligent Transportation Systems, Sep. 2007.

[12] Jiun-Ren Lin, Al-Chun Pang, et al. “iPTT: peer-to-peer push-to-talk for VoIP,” Wireless Communication and Mobile Computing, Vol.8, N0.10, pp.1331-1343, Dec. 2008.

[13] I.Cidon, I.Gopal, and S.Kutten, “New models and algorithms for future networks,” IEEE Transaction on Information Theory, vol.41, no.3,769-780, May 1995.

[14] Y. Chu, S. G. Rao, S. Seshan, H. Zhang, “A Case for End System Multicast,” in the Proceedings of ACM SIGMETRICS, Jun. 2000.

[15] Y. Chawathe, “Scattercast: An Architecture for Internet Broadcast Distribution as an Infrastructure Service,” PhD. Thesis, University of California, Berkeley, Dec. 2000.

[16] B. Zhang, S. Jamin, and L. Zhang, “Host multicast: A framework for delivering multicast to end users,” In Proc. of IEEE INFOCOM, New York, NY, Jun. 2002.

[17] Meng-Hsun Tsai, Yi-Bing Lin, “Talk Burst Control for Push-to-Talk over Celluar,” IEEE Transcations on Wireless Communications, Vol.7, No. 7, pp. 2612-2618, Jul. 2008.

[18] Hyun-Ho Choi, Jung-Ryun Lee, Dong-Ho Cho, “On the use of a Power-Saving Mode for Mobile VoIP Devices and Its performance Evaluation,” IEEE Transactioins on Consumer Electronics, vol. 55, no. 3, Aug. 2009.

[19] J.Janssen, D. De Vleeschauwer, M. Buchli, and G. H. Petit, “Assessing voice quality in packet-based telephony,” IEEE Internet Computing, vol. 6, no. 3, pp.48-56, May-Jun. 2002.

[20] Trevor Yensen, Jeffrey P. Lariviere, Ioannis Lambadaris, Rafik A. Goubram, “HMM Delay Prediction Technique for VoIP,” IEEE Transactioins on Multimedia, vol. 5, no.3, pp.444-457, Sep. 2003.

[21] B. Kao, H. Garcia-Molina, and D. Barbara, “Aggressive transmissions of short messages over redundant paths,” IEEE Transactioins on Parallel and Distributed System, Vol 4, pp.102-109, Jan. 1994.

237237