Abstract
Public safety organizations around the world started migrating toward Long-Term Evolution (LTE) networks to support the increasing needs for video and data. To address the unique voice communication requirements of first responders, the 3rd Generation Partnership Project (3GPP) introduced new capabilities that aim at providing similar functionalities as the traditional Land Mobile Radio (LMR) systems, namely, Direct Mode communication and mission critical push-to-talk (MCPTT). Direct Mode communication, also called Proximity Services (ProSe), allows public safety users to communicate directly with each other regardless of the network status. MCPTT was the first mission critical service, and first application, standardized by 3GPP to provide both on- and off-network voice capability. Assessing the performance of those capabilities is critical to accelerate their deployment and adoption by first responders. In this study, we evaluate the performance of an off-network mode MCPTT device over ProSe by focusing on the access time, a measure of the delay incurred before a user can talk. We develop analytical models for various types of calls and verify the accuracy of the predicted access time using ns-3 simulations. We perform sensitivity analysis to show the validity of the models for various scenarios. Finally, we show how the models can be used to guide parameter configuration for both MCPTT and ProSe to optimize the performance.
1. Introduction
Public safety agencies require real-time applications, and voice communication remains the most important means of communication for first responders in emergency situations. While most existing push-to-talk (PTT) communication is carried over Land Mobile Radios (LMRs) to achieve public safety grade voice quality and reliability, first responders have already adopted broadband technology, including 3rd Generation Partnership Project (3GPP) Long-Term Evolution (LTE), to access video and data. Thanks to the effort of public safety organizations around the world, 3GPP has extended LTE’s capabilities to support many of the situations faced by first responders and increase the network’s reliability. In particular, extensions were made to fulfill the mission critical voice communication requirements defined by the public safety community [1, 2]. Those requirements include PTT, which is the standard means of communicating amongst first responders (similar to walkie-talkie), and Direct Mode, which allows first responders to communicate unit-to-unit without using the network. Also included is the ability to talk to multiple units at once (i.e., group call), the identification of the person speaking, and notification of emergency situations.
PTT is not new, and a lot of research has been done on the Open Mobile Alliance (OMA) PTT over Cellular (PoC) services [3] in recent years. Early evaluations of PoC were done over 3G technologies and the results showed significant setup delays [4] and talking wait time on the order of seconds [5, 6]. Even over LTE, PoC is far from being able to provide the performance needed by first responders. For example, Kuwadekar and Al-Begain evaluated PoC using a real network under different conditions [7]. The call setup delay was measured in the testing, which is the time from when the PTT button was pressed to the time when all the UEs were connected so that the user could speak. The results showed that if the network was not loaded, the call setup delay ranged from 0.7 s to 4.6 s, and that the average call setup delay was 2.556 s, which is higher than what is seen in LMR systems. Kuwadekar and Al-Begain also showed that PTT call setup delay increased roughly linearly with respect to the amount of emulated background calls that they injected into the network, and the call setup delay exceeded 10 s once the number of simultaneous background calls exceeded 700. Tests of PTT during a festival, when the local network was being used by up to around 10,000 people, resulted in a 100% call failure rate. Those high delays are attributed to the Session Initiation Protocol (SIP) used by PoC and provided by the Internet Protocol (IP) Multimedia Subsystem (IMS). An enhanced version of PoC for public safety, called Push-to-Communicate for Public Safety (PCPS) [8], was developed and aligned with 3GPP efforts to standardize a PTT application capable of meeting public safety needs in terms of features and performance. This Mission Critical Push-to-Talk (MCPTT) application was introduced in LTE Release 13 and further enhanced in later releases [9]. The current efforts to evaluate MCPTT mainly focus on on-network scenarios, where the devices are connected to the network via a base station. In [10], Kim et al. proposed an algorithm to shorten the time of the initial uplink transmission in order to reduce the control plane latency. In [11], Solozobal et al. looked at using mobile edge computing to provide a flexible architecture in 5G networks where the user plane can be deployed closer to the users, thus improving performance. The proposed solution would also allow the network operator to deploy the control plane at the edge of the network to provide a standalone service if the evolved NodeB (eNodeB) is disconnected from the core network.
To support Direct Mode capability in LTE, 3GPP introduced Proximity Services (ProSe) capability in Release 12 and has continued to enhance ProSe in subsequent releases [12]. ProSe allows a piece of User Equipment (UE), such as a laptop or a phone, to discover and communicate with other UEs. ProSe supports both one-to-one and one-to-many transmissions, thus allowing for efficient group communication. The research on ProSe communication has primarily focused on the coverage and capacity aspect of this new feature. Wang and Rouil evaluated the expected device-to-device (D2D) coverage using ProSe [13] for various channel conditions and conducted a sensitivity analysis to determine the main factors impacting coverage. This work considered only a single link and did not capture the effects of multiple users accessing the same resources. Griffith et al. developed analytical and simulation models to evaluate the probability that a control packet reaches a certain number of devices assuming a particular control channel resource pool configuration [14]. In this work, multiple devices were considered but conservative assumptions were made regarding the channel effects. A follow-up work by Griffith et al. was done to evaluate data transmissions over the shared channel [15] and a similar work was completed by Cipriano and Panaitopol [16]. The results of those contributions can help operators allocate resources based on a desired performance target but do not consider end-to-end performance metrics such as latency.
To the best of our knowledge, this is the first work that evaluates the performance of off-network MCPTT over ProSe. Using the MCPTT access time as the key performance indicator (KPI), we propose analytical models to estimate the access time under different scenarios. The models can be used to guide parameter configuration, and to better understand the interaction between MCPTT and ProSe. We have also developed a ns-3 model for simulating MCPTT over ProSe [17], which we used to validate the predicted delays. Major functions of the simulation model include floor control, call control, call type control, and emergency alert. All protocol operations are based on 3GPP MCPTT specifications [18, 19]. We designed test cases and used them to check the correctness of the protocol models that we implemented in the simulator [20].
The rest of the paper is organized as follows. In Section 2, we describe D2D communication over ProSe and our baseline model to estimate the transmission delay. In Section 3, we leverage the ProSe model to develop a set of theoretical models to estimate the MCPTT access time for the various types of calls. We included simulation results to compare with our analytical estimates. In Section 4, we conduct a sensitivity analysis of the ProSe and MCPTT parameters. Section 5 concludes the paper and outlines future work.
2. Modeling of Message Transmission Time over ProSe
2.1. D2D Communication over ProSe Sidelink
The need for wireless communication among public safety users while out-of-coverage can be met by utilizing Mode 2 of D2D communications supported by 3GPP LTE [12]. In Mode 2, UEs operate without any network supervision, which is the case when the UEs are out of coverage of any base stations, and voice and data communications are carried over the air interface referred to as the ProSe sidelink, or “sidelink” for short. D2D communication over sidelink is performed over periodically repeating sets of sidelink resources in the time domain, where a single set of sidelink resources compose a sidelink period. Each sidelink period contains instances of two channels that are separated in the time domain: the Physical Sidelink Control Channel (PSCCH) and the Physical Sidelink Shared Channel (PSSCH), as depicted in Figure 1. Each channel is defined by a resource pool, whose elements are defined by a combination of certain Resource Block (RB) indexes in the frequency domain, and certain subframe indexes in the time domain. The transmitting UE uses the PSCCH to send a Sidelink Control Information (SCI) message to indicate to which UEs its subsequent data messages are addressed, where and when the data transmissions on the PSSCH will occur (i.e., resource assignment in the time and frequency domains), and how (i.e., the modulation and coding scheme). Upon successful reception of the SCI message, any receiving UEs can tune to the corresponding resources in the PSSCH. Transmissions in the PSSCH use a Time Resource Pattern (TRP), which is a subframe indication bitmap of a fixed length NTRP (e.g., 8 subframes for LTE in Frequency Division Duplex (FDD) mode) repeated in the time domain through the length of PSSCH, to identify which subframes are used by a transmitting UE. Each TRP is identified by an index ITRP corresponding to the predefined subframe indication bitmap established in [21]. Every data transmission on the PSSCH is performed with four HARQ transmissions. In addition, if outgoing data is to be scheduled for transmission in a given occurrence of the PSSCH, the data has to be available at least 4 ms before the beginning of the corresponding sidelink period. In this paper, we identify this gap as the scheduling cutoff time. Sidelink communication is considered half duplex, which means that a device is not able to receive messages if it is transmitting in the same subframe.
2.2. One Way Transmission Time
Let X be a message that a transmitting UE must send and let the one-way transmission time of message X over the sidelink, denoted as , be the duration from when the message becomes available at the transmitting UE to the time when message is received successfully by the receiving UE. The calculation of considers the packet error rate (PER) of each transmission attempt, the random occurrence of PTT button push timing, and ProSe configuration parameters. To be more specific, can be written as a function that has the form:where(i) is the duration of a sidelink period;(ii) is the duration of the control channel (PSCCH) of a sidelink period;(iii) is the transmission plus propagation delays from the sending UE to the targeted receiving UE;(iv), , is the PER of the -th transmission attempt within a sidelink period, with being the total number of transmission attempts of a packet in one sidelink period;(v) represents the distribution of the PTT button push timing;(vi) and are ProSe time resource pattern related parameters;(vii) is an integer between 1 and , with , and the MCPTT message is included in the -th Transmission Block (TB) of the sidelink period data channel (PSSCH).
Since remains the same for all MCPTT messages discussed in this paper and thus does not depend on , we refer to it as for short.
The minimum value of that one message may experience occurs when the following three conditions are met, as shown in Figure 2(a):(1)the message becomes available for transmission right before the scheduling cutoff time of the upcoming sidelink period (i.e., 4 ms ahead of the start of sidelink period );(2)the message is scheduled to be transmitted in the first subframe of the data channel of the sidelink period (e.g., ); and(3)the first transmission attempt of the message is successfully received by the targeted UE.
(a) Minimum case
(b) Maximum case
Thus, the minimum value for in units of milliseconds isThe maximum value of that one message may experience, assuming that only the last transmission attempt is successfully received by the targeted UE, is shown in Figure 2(b). The message transmission time can be even larger if none of the transmission attempts in one sidelink period succeed, and we will discuss this situation in Section 4. When both of the following two conditions are met, the maximum value of shown in Figure 2(b) occurs:(1)the message becomes available for transmission right after the scheduling cutoff time of the upcoming sidelink period , so it must wait for the full length of the sidelink period K and is scheduled to be transmitted in the subsequent sidelink period ;(2)the last transmission attempt of the message is scheduled to be transmitted in the last subframe of the data channel of the sidelink (e.g., ) period.
Thus, the maximum value of in units of milliseconds isAssume the -th TB is the TB in which message X is assigned to be transmitted. Let denote the time between the moment the PTT button at the transmitting UE is pushed and the beginning of the sidelink period in which the message is transmitted. There are four components of the message transmission time : (1) ; (2) the control channel duration ; (3) the time offset of the -th TB from the beginning of the current instance of the data channel PSSCH which equals ; and (4) the duration from the beginning of the -th TB to the time that message X is sent out successfully within the -th TB. Note that for a message to be transmitted with ProSe parameters and assuming the message is transmitted successfully in the -th attempt initially, component (4) equals . This is because for each failed transmission attempt, an additional ms delay will be added, and within each round of transmission attempt, there is ms time offset introduced for a message transmitted with TRP bitmap parameter . Therefore, the average of component (4) shall be calculated by conditioning on the possible values and, given , by additionally conditioning on the index number of the first successful transmission attempt . Also, since we are looking at the delay associated with a successful message transmission, we use the law of total probability and condition the value of component (4) on the event that the message transmission succeeds in exactly attempts for ; the probability of this event is . Furthermore, the probability of message transmission failure is the probability of transmission attempt failures, which is . Thus, the message transmission success probability is , and the average value of iswhere .
2.3. Roundtrip Transmission Time
The roundtrip message transmission time over the sidelink, denoted as , is defined as the duration from when message is available at UE A until UE A receives the response message from the corresponding UE (denoted as UE B for simplicity) successfully over the sidelink channel, thenwhere is the time between when message is received by UE B and the time when the response message is available at UE B as defined by the protocol (e.g., backoff timers); and is the time that a message has to wait before the beginning of the sidelink period in which the message is transmitted. This overhead time is due to the sidelink period boundary restriction.
Note that is not the simple summation of , , and . This is because the available timing of message is dependent on the available timing of message and , which is no longer the independent PTT push timing that is assumed for UE B when calculating .
The minimum that UE A may expect isas shown in Figure 2(a) by assuming .
As can be seen from (6), and thus is always greater than .
The maximum that UE A may experience isas shown in Figure 2(b) by assuming .
The calculation of average starts from rearranging (5) into mutually indepenedent components: where is one less than the number of sidelink periods from the sidelink period in which message X is transmitted successfully to the sidelink period in which message Y is transmitted successfully, so . Similar to component (4) in (4), the average of shall be calculated considering both possible values and possible numbering of the first successful transmission attempts . In addition, the randomness introduced by needs to be included as well. where ; and = is the maximum possible for a given . By combining (8) and (9), the average value of iswhere is calculated by (4);
2.4. Baseline Configuration Parameters for Evaluation
Analytical estimates and simulation results presented in Sections 3 and 4 assume the baseline configuration shown in Table 1 unless otherwise noted. Note that the PER of a single transmission attempt is set at 0.1 at most, since 0.1 is the common design assumption of LTE PER when Hybrid automatic repeat request (HARQ) Acknowledegment (ACK)/Negative Acknowledgement (NACK) is in use. Given that there is no HARQ ACK/NACK over the ProSe PSSCH meaning that all four HARQ transmissions always occur, the PER should not be set to a more aggressive value higher than 0.1.
We assume in the simulations that the timing of a PTT button push is uniformly distributed within a sidelink period , and (i.e., the message is transmitted in the first TB of the sidelink, which is reasonable given the importance of public safety related communication). It is also assumed that ProSe TRP parameters are configured as and . This means that only one of the 8 subframes in a TRP will be used to send data and . Then (4) is simplified asin units of ms.
We also assume that the MCPTT user only needs to push the PTT button to initiate the request to speak and is not required to follow up the request with any further actions, such as acknowledgement. In addition, since there are some variations in MCPTT message sizes (e.g., call announcement message is long) and the size of resource allocated to each UE (e.g., the resource allocated for a voice message may be small to start with), our modeling assumes that MCPTT messages are not piggybacked, in order to get the conservative estimates/results. When piggybacking is allowed, the access time may be further reduced.
3. Modeling of MCPTT Access Time
3.1. Overview
According to 3GPP LTE specifications, “The MCPTT access time is defined as the time between when an MCPTT User requests to speak (normally by pressing the MCPTT control on the MCPTT UE) and when this user gets a signal to start speaking.” [9]. Based on protocol details, the MCPTT access time () can be further divided into two components as illustrated in Figure 3: call control access time () and floor control access time (). Call Control Access Time () is the time from when the MCPTT user presses the PTT button to when the MCPTT UE establishes a call successfully. This component occurs only when the call which the MCPTT UE wants to join/start does not exist yet. Floor control access time () is the time from when the MCPTT UE establishes a call successfully (if not already in a call) or when the MCPTT user presses the PTT button (if in a call already), whichever is later, to when the MCPTT UE becomes the floor arbitrator. In MCPTT off-network mode group call operation, the floor arbitrator is the current speaker who is the only group member that is allowed to speak to the group and that also arbitrates the floor in case other members of the group call (i.e., other floor participants) request that they be granted the floor so that they can talk.
MCPTT off-network mode supports the following three categories of calls: basic group call, broadcast group call, and private call. The analytical modeling of MCPTT access time associated with basic group call is analyzed first in Section 3.2, because the call control procedures and floor control procedures of the basic group call are very comprehensive. Then the analytical modeling of MCPTT access time associated with broadcast group call and private calls is presented in Sections 3.3 and 3.4, respectively, which reuses a subset of the modeling of basic group call procedures. We obtain simulation results assuming two users for all three call categories and compared these results with their analytical estimate counterparts in the corresponding sections. Simulation results presented throughout this paper are generated by running the ns-3 model for MCPTT over ProSe [17], especially the call control module and floor control module. Parameters configuration and simulation setup follow the description in Section 2.4, unless otherwise noted.
3.2. Basic Group Call
From the viewpoint of MCPTT access time performance evaluation, the various situations that an MCPTT client faces when pushing the PTT button to talk in a basic group call (with group ID ) can always be categorized into one of the five scenarios summarized in Table 2.
In Sections 3.2.1 and 3.2.2, we explain the call control and the floor control access procedures, and access time models are described. In Section 3.3 we derive the total access time experienced by an MCPTT client under Scenarios A through E from different combinations of and . Note that the value of may be 0 for certain scenario(s), as will be analyzed in Section 3.2.2.
3.2.1. Call Control Access Time
When an MCPTT client (UE A) wants to join/establish a basic group call with MCPTT group ID by pushing the PTT button, it has to go through either procedure “C1: Initiate a new group call” or procedure “C2: Join an existing group call,” which are shown in Figure 4. In the figure, the colors of the message name and the corresponding arrows are consistent with the color of the sending UE.
The call control access procedure we defined above has incorporated the call probe procedure, call setup procedure, and periodic group call announcement procedure specified in [18]. The decision to go through procedures C1 or C2 is made by UE A (the UE with the PTT button pushed) itself based on its own observation and may not be the correct decision. To be more specific, UE A always chooses C1 under Scenario A, which is the right decision. However, under Scenarios B or C, UE A might make the correct decision, C2, or the wrong decision, C1, depending on how soon UE A hears back from other UEs with respect to the configuration of timer TFG1.
When UE A executes the C1 procedure,where is the value of “wait for call announcement” timer .
When UE A executes the C2 procedure,where is given by (5) and where messages X and Y are the Call Probe and Call Announcement messages, respectively. In (5), , where is the number of MCPTT UEs in the group call capable of sending out a Call Announcement message in response to receiving a Call Probe message from another UE. Here reflects the time that it takes for at least one UE of the group to respond to a Call Announcement message after receiving the Call Probe message from UE A. It is a random variable that is the minimum of random variables, each of which is uniformly distributed between 0 seconds and (1/12) seconds (83.3 ms). Therefore,The minimum, maximum, and average of can be obtained by plugging configuration values into (6), (7), and (10) accordingly.
The simulation study of call control access time in this section focuses on Scenarios B and C, i.e., Procedure C2. This is because there is no uncertainty in Scenario A (i.e., Procedure C1), since always equals when the MCPTT UE establishes a new group call.
Figure 5 shows that, for all sidelink periods defined by 3GPP for LTE ProSe, the analytical model provides good estimates of the minimum, average, and maximum for the call control access time experienced by an MCPTT client who goes through procedure C2. The 95% Confidence Interval for the average values obtained from simulation is also shown and is very tight. The minimum and maximum values are observed over all simulations and therefore do not have a Confidence Interval. This is true for all the figures shown in this document. As can be seen from the figure, increases as increases and ranges from as small as 52 ms to more than 680 ms. The timer value in the simulation is configured to max (1 sec, ) and the timer value is configured to ; thus UE A will make the correct decision because neither timer will expire prematurely.
3.2.2. Floor Control Access Time
When an MCPTT client wants to talk and thus pushes the PTT button on UE A, the UE will go through one of the “F0: new call,” “F1: No Response,” or “F2: Response Received” procedures depending on the feedback that it receives from other UEs.
After the MCPTT client (UE A) establishes a group call (i.e., C1 procedure), UE A sends out a Floor Granted message and may start talking, so the corresponding floor control access procedure is as follows.
F0. Send out Floor Granted message to grant the floor to oneself.
After an MCPTT client (UE A) joins an existing group call (i.e., C2 procedure), or if UE A is already a part of an ongoing group call, UE A sends out a Floor Request message. Depending on whether a response is received within a configured time window, UE A may perform the F1 or F2 procedure as illustrated in Figure 6. In the figure, the colors of the message name and the corresponding arrows are consistent with the color of the sending UE. Depending on the relative priority of the floor request and the queueing capability of the current floor arbitrator, procedure F2 may be further divided into three cases:
F2.1 (preemptive floor request). UE A’s floor request has pre-emptive priority, so UE B must grant the floor to UE A immediately;
F2.2 (floor request denied). UE B is busy and does not support queueing requests, so UE B denies the floor to UE A;
F2.3 (floor request queued). UE B is busy but supports queueing of requests, so UE A’s floor request is placed in queue and will be handled later.
It is worth pointing out that the time it takes for UE A to receive a response is the same for F2.1, F2.2, and F2.3. However, the 3GPP definition of MCPTT access time focuses on the case of “when this user gets a signal to start speaking” [2]. Therefore, in the following analytical model and simulation study, among the three cases of procedure F2, we focus on procedure “F2.1: preemptive floor request”. It is because procedure F2.2 or F2.3 will not grant the floor to UE A, and thus UE A’s access procedures are not successful. The model and results can be easily generalized if the MCPTT access time definition is rewritten as “when this user gets a signal whether he/she can start speaking”.
The floor control access procedure we defined above has incorporated several state transition procedures specified in [19]. The decision to go through procedure F0, F1, or F2 is made by UE A (the UE with the pushed PTT button) based on its own observation, and this decision may or may not be the correct one. To be more specific, UE A always chooses F1 under Scenario A, which is the right decision. However, under Scenarios B or D, UE A might make the correct decision (F2) or the wrong decision (F1), depending the time until UE A receives a response message from the floor arbitrator UE B and the configuration values of the timer and counter. The floor control access time of each of the three procedures are as follows:
When F0 procedure is executed,When F1 procedure is executed,where is the “Floor Request Retransmission” timer and is the “Floor Request Retransmission” counter. The 3GPP default settings of these two parameters are and 3, respectively.
When the F2.1 procedure is executed,again using (5), where . The minimum, maximum, and average of can be obtained by plugging configuration values into (6), (7), and (10) accordingly.
The simulation study of floor control access time in this section focuses on either Scenario B or D, i.e., procedure F2.1. This is because there is no uncertainty associated with for Scenarios A, C or E: for Scenarios C & E (i.e., procedure F1), and for Scenario A (i.e., procedure F0). Also, we focus on the case when UE A’s floor request is of preemptive priority, i.e., F2.1, as explained in Section 2.4. In the simulation, it is assumed that the incumbent floor arbitrator UE B does not generate Real-time Transport Protocol (RTP) packets during UE A’s access time. This assumption will not impact UE A’s access time when UE A makes the right decision. We make this assumption to get a conservative estimate of the likelihood of UE A’s making the wrong decision, which leads to an undesirable situation where there are multiple floor arbitrators. More detailed definition and analysis of the multiple floor arbitrator situation are given in Section 4.3.
Figure 7 shows that for all sidelink period lengths defined by LTE, the analytical model provides good estimates of the minimum, average and maximum floor control access times experienced by an MCPTT client who goes through procedure F2.1. The timer value in the simulation is configured to , so that UE A will make the correct decision.
Comparing Figure 7 with Figure 5, it shows that although the minimum call control access time and floor control access time are very similar, the average and maximum values of are smaller than those of for short sidelink periods (small values). This is because of the extra delay introduced by timer to the round-trip time during the call control procedure. When is large, however, the impact of becomes negligible.
3.2.3. Group Call MCPTT Access Time
The analytical model of the overall access times for scenarios A through E can be obtained by the proper combination of the analytical models of and derived in previous sections, as shown in Table 3. It is worth pointing out that for Scenario A, is 0 as was explained in Section 3.2.2.
It is worth pointing out that, for Scenarios B, C, and D, UE A may make the correct decision or the wrong decision, depending on the MCPTT parameters’ configuration and the one-way or roundtrip message transmission time over the sidelink. When UE A makes the correct decision, the analytical models presented in Section 3 align quite well with the MCPTT access time observed in our simulations. When UE A makes wrong decisions, the simulation results deviate from the analytical estimates, which we analyze in Section 4, together with the discussion of potential negative impacts from incorrect decisions.
3.3. Broadcast Group Call
A broadcast group call is a special group call where the initiating MCPTT user expects no response from the other MCPTT users, so that when the initiator’s transmission is complete, so is the call. Therefore, the UE that initiated the broadcast group call is the only MCPTT UE acting as the floor arbitrator. Consequently, only one scenario needs to be evaluated to examine the access time required to establish a new broadcast group call:
Scenario F. UE A establishes a new broadcast group call by pushing the PTT button.
The value of under Scenario F is zero, because the UE can initiate a broadcast group call without waiting for timer expiration or messages from other UEs. Similarly, the value of is also zero, because the UE that initiates a broadcast group call becomes the floor arbitrator immediately. Consequently, the overall access time is:
3.4. Private Call
A private call takes place between two MCPTT UEs. For the private call scenarios, a MCPTT UE is in one of two possible states: it is in a private call already or needs to start a new private call; a UE cannot join an existing private call. Consequently, there are only two scenarios that need to be evaluated to obtain the access time of a private call:
Scenario G. UE A establishes a new private call by pushing the PTT button.
Scenario H. UE A is already in a private call and wants to talk by pushing the PTT button.
For Scenario G, the possible call control procedures that UE A may experience are depicted in Figure 8. In the figure, the colors of the message name and the corresponding arrows are consistent with the color of the sending UE. To establish a private call successfully, procedure CP2.1 is the only path, and then UE A becomes the floor arbitrator automatically. Therefore, the overall access time for Scenario G iswhich uses (5) to evaluate . The minimum, maximum, and average of can be obtained by plugging configuration values into (6), (7), and (10), respectively, with
Under Scenario G, when the time for UE A to receive a response is greater than , UE A will make the conclusion that the other UE (UE B) cannot be reached and stop trying to establish the call, i.e., procedure CP1.
For Scenario H, the floor control procedure that UE A may experience is very similar to the F2.1 procedure, and the overall access time for Scenario H is from (18)The simulation study of private call access time in this section focuses on Scenario G, i.e., procedure CP2.1. This is because the access time of Scenario H can use the results for F2.1 presented in Section 3.2.2. Figure 9 shows that, for all sidelink period lengths defined by 3GPP, the analytical model provides good estimates of the minimum, average, and maximum for access times experienced by an MCPTT client going through procedure CP2.1. We observe that the access time and the spread between the minimum and the maximum values increases as increases, for both analytical estimates and simulation results.
4. Impact of MCPTT Parameters on MCPTT Access Time
As already mentioned briefly in Section 3, several important observations can be made based on the analytical and simulation modeling of MCPTT access time.
Observation 1. An MCPTT UE needs more than one sidelink period to send a message and get the response message back over the sidelink.
As can be seen from (6), and thus is always longer than . However, the default 3GPP settings of several MCPTT retransmission timers, e.g., and , is one only. Such a small timer value may lead to unnecessary retransmissions of certain MCPTT messages and may have negative impacts as illustrated in Sections 4.1 and 4.3.
Observation 2. An MCPTT UE may make wrong decisions about the existence of call and/or floor arbitrators, under some scenarios and with certain parameter configurations.
As summarized in Table 3, UE A’s decision may go wrong for Scenarios B, C, and D. These wrong decisions may lead to undesirable situations such as a multiple calls situation or a multiple floor arbitrators situation, both of which are further analyzed in Sections 4.2 and 4.3, respectively.
Motivated by the above observations, in the remainder of this section, we study the impact of various MCPTT parameters to evaluate the benefits and drawbacks of different configurations on MCPTT access time performance.
4.1. Impact of “Call Probe Retransmission” Timer
To evaluate the impact of , we look at the call control access time for Scenarios B and C (group calls). Figure 10 shows the results using the same assumptions as for Figure 5 but with configured at the 3GPP default setting instead of .
It appears that varying from to produces no significant difference in the call control access time experienced by an MCPTT client. To further investigate the impact of , we define two other performance metrics called “multiple occupancy” and “single occupancy” to capture the impact of the half duplex effect, which can lead to packet losses at the receiving UE. “Multiple occupancy” refers to a situation in which multiple UEs try to send messages over the air during the same sidelink period, while “single occupancy” refers to a situation in which only one UE tries to send messages over the air during a sidelink period. The half-duplex effect will not occur with “single occupancy” but may occur with “multiple occupancy”. As shown in Table 4, the negative impact of ’s configuration value’s being too small can be seen in the higher ratio of “multiple occupancy” vs “single occupancy,” which may lead to more frequent occurrences of the half duplex effect. This is mainly due to unnecessary retransmissions of the “Call Probe” message. The negative impact of ’s being too small is also shown through the nonzero ratio of samples discarded. Note that a sample is discarded if both SCI message transmissions in the control channel (PSCCH) fail or all four HARQ transmissions in the data channel (PSSCH) fail, due to either half-duplex effect or channel PER. Given PER = 0.1, 0.1, 0.1, 0 as a simulation assumption, all samples discarded are always the consequence of the half duplex effect. The fraction of samples discarded is dependent on the size of the resource pools allocated to sidelink communication. The positive impact of a small is that the “Call Probe” message may be retransmitted sooner if it is lost.
It is worth pointing out that the occurrence of “multiple occupancy” and thus the half-duplex effect are expected to be more frequent when the number of participating UEs in the group call increases. Therefore, although we do not see any noticeable difference in access time when changing value in the 2-UE system, the impact of will become more obvious for multiple-UE systems. In addition, the occurrence of the half-duplex effect can be reduced by adapting resource pool configuration to the number of participating UEs (e.g., extending the pool in the time domain), which is an interesting research topic by itself.
4.2. Impact of “Wait for Call Announcement” Timer
When we run the simulation with the same assumptions as for Figure 5 but with configured at the 3GPP default setting of 150 ms instead of , we can see from Figure 11 that the maximum access times experienced by an MCPTT client are reduced and capped at 150 ms, and thus the average access time is reduced. As we explained in Section 3.2.1, when expires, UE A assumes that the call of interest does not exist and will establish a new group call by itself, which marks the end of the MCPTT access time duration. However, given that the scenario simulated is B or C, i.e., group call exists already, these expirations are premature, and the capped maximum access time might not be an improvement. Indeed, the MCPTT client, UE A, makes the wrong decision when establishing a new group call instead of joining the existing call. Consequently, the MCPTT client is not aware of the existing call, and multiple calls of the same group ID coexist. This undesirable situation of multiple calls with the same group ID will be referred to as the “multiple calls situation” for the remainder of this paper. The multiple calls situation will persist until the call merging procedure is triggered. After taking into account the extra delay introduced by the necessary call merging procedure, the average effective call control access time is very close to the results that we obtained when is large, as seen in Figure 11, so the analytical model gives a good prediction of the effective call control access time after the call merge procedure. Simulation results with a sidelink period longer than 120 ms are not included in Figure 11 because UE A always makes the wrong decision in that case and, thus, the call merging procedure is always triggered to fix the multiple calls situation.
The disadvantages of the multiple calls situation include not only the extra delay due to the call merging procedure, but also the potential false impression/feedback to the MCPTT client. The MCPTT user, who is very likely a first responder on an urgent task, might think that no teammate is within communication range, although some teammates may be deployed nearby. Similarly, the MCPTT user may try to switch groups if he/she is notified wrongly that the group does not have an existing call. As another example, a first responder may decide to take actions at a higher risk, instead of waiting for support/backup from other teammates when in a time-sensitive or life-threatening situation. Therefore, although a smaller configuration may reduce the wait before establishing a new call if the call does not exist, the 3GPP default setting of = 150 ms is worth further discussion to reduce the occurrence of the multiple calls situation, and it may be desirable to take into account when configuring .
The negative impact of the multiple calls situation becomes more pronounced when the channel conditions degrade. Figure 12 compares the impact of channel loss on the call control access time when timer is configured with the 3GPP default setting. When the channel PER of the fourth transmission attempt, , in the Sidelink Shared Channel increases from 0 (lossless) to 0.1 (lossy), remains similar. This is because the potential long delay due to message loss is mostly absorbed by the expiration of . However, the value of discussed above is only the nominal access time and does not consider that the MCPTT client might make the wrong decision to establish a new group call when expires. When comparing the effective access time experienced by the MCPTT client, i.e., considering the extra delay introduced by the call merging procedure wherever applicable, the average effective value has increased considerably due to the channel loss. The extra delay observed, which is quite large, is mainly due to the slow periodicity of the Call Announcement transmission cycle when the MCPTT UE is not responding to a Call Probe. When a Call Probe message is lost, or the responding Call Announcement message is lost, a UE is more likely to wait for the periodic Call Announcement to trigger a call merging procedure, which is slower.
Table 5 shows the probability of the “multiple calls situation” occurrence if is set to 150 ms. Because of the potential packet loss due to the unnecessary retransmission of MCPTT messages, an error situation is more likely to occur when is set to than when it is set to . When the channel condition is worse, the occurrence rate of the “multiple calls situation” also increases, as shown in the last two lines of Table 5.
4.3. Impact of Floor Request Retransmission T201
The impacts of a smaller value for the Floor Request Retransmission Timer, , such as the 3GPP default setting , are multifold. On the positive side, if there is no floor arbitrator present, a smaller value for enables the MCPTT user to declare the floor sooner, with the access time equal to T201C201, than when is larger (e.g., ) as shown in Figure 13(a), or when ’s value is based on the provision of the near worst case as shown in Figure 13(b). In the case shown in Figure 13(b), , where is the smallest integer which is greater than , which can be calculated based on (18). By comparing Figures 13(a) and 13(b), we can see that the channel loss makes the positive impact of a small configuration more pronounced. Note that we obtained the results in Figure 13(a) by running the simulation with the same assumption as for Figure 7, except that we configured at the 3GPP default setting instead of at . We obtained the results of Figure 13(b) by running the simulation with the same assumption as for Figure 7, except that we set PER to 0.1, 0.1, 0.1, 0.1 instead of 0.1, 0.1, 0.1, 0, and we configured at either or .
(a) Access time when , PER = 0.1, 0.1, 0.1, 0 with 95% Confidence Intervals for the average values from the simulations
(b) Access time when , PER = 0.1, 0.1, 0.1, 0.1 with 95% Confidence Intervals for the average values from the simulations
However, on the negative side, the decision made by the MCPTT client (e.g., assume the floor is idle) with a smaller value might be premature, and it may lead to an undesirable situation in which there are multiple floor arbitrators, which we will refer to as the “multiple floor arbitrators situation”. Note that this situation is neither easy nor quick to resolve, given the current procedures. Table 6 shows the increase in ratio of “wrong decision” vs “correct decision” when comparing small settings with large settings. It is also clear from comparing Table 6(a) to Table 6(b) that the channel loss makes the negative impact of a small configuration even more evident. Note that the results in Table 6 show the worst case outcome because we assumed that the incumbent floor arbitrator UE B does not generate RTP packets during UE A’s access time. If the current floor arbitrator UE B is actively sending RTP packets, the counter C201 at UE A is reset every time an RTP packet is received. Therefore, it will take more time and will be less likely for UE A’s to reach the threshold and make a wrong decision when UE B is talking.
We encounter the “multiple floor arbitrators situation” when there is more than one floor arbitrator simultaneously in the same off-network group call, although the correct behavior is that there should be at most one floor arbitrator at any time. There are several circumstances that may lead to the “multiple floor arbitrators situation,” such as a premature timer expiration or the hidden node problem. The potential disadvantages of the multiple floor arbitrators situation are as follows:(i)The lack of resolution procedure for “multiple floor arbitrators situation.” This is in contrast to the “multiple group calls situation,” for which the call merging procedure is already defined in the call control protocol as a remedy.(ii)The MCPTT client who takes the floor prematurely is not aware of the situation and might start talking while not knowing that no one is listening;(iii)The incumbent floor arbitrator is not aware of the situation either and does not know that one or more group members are not listening.
As was the case in the call control study, the negative impact of the Floor Request Retransmission Timer being configured too small can be noticed in Table 7 and is mainly due to the unnecessary retransmissions of the Floor Request message.
When comparing the same performance metrics of the case in Table 4 with the case in Table 7, the call control procedure seems to perform slightly better than its floor control counterpart. This is because the timer adds a random delay to the transmission timing of the responding Call Announcement message. Consequently, the transmission of the Call Announcement message does not always compete with the retransmission of a Call Probe message for resources in the same sidelink period.
4.4. MCPTT Access Time with 3GPP Default Settings
Table 8 summarizes the simulation results of the average MCPTT access time in milliseconds for different scenarios when the MCPTT parameters are configured according to the 3GPP default settings.
We obtained the values in the table assuming no hardware or software processing time. In addition, we obtained the access times when UE A makes the correct decision as described in Table 3. However, wrong decisions are not uncommon occurrences with the 3GPP default settings, which might lead to the “multiple floor arbitrators situation” and/or the situation of multiple calls with the same group ID.
5. Conclusions and Future Work
We developed the analytical models and simulation tools described in this paper to estimate and evaluate the performance and user experience of MCPTT off-network mode operations over ProSe in LTE, with a focus on access time when an MCPTT UE is out of coverage. We defined performance metrics and application scenarios for the access time analysis. Our analytical models provide good estimates of the minimum, average, and maximum for both call control and floor control access times experienced by an MCPTT client under various scenarios, as shown by our simulation results. We summarize our main observations with respect to parameter configurations in Table 9. These observations may be used to understand the tradeoff and provide configuration guidelines for MCPTT and ProSe.
The sensitivity analysis results show that preventive solutions, such as proper parameters configuration and/or modified procedures, need to be investigated to reduce the possibility of an MCPTT UE’s making wrong decisions. In addition, 3GPP may re-evaluate the default setting of timers TFG1, TFG3, and T201 due to the undesirable occurrence of the ‘multiple floor arbitrators situation,’ the coexistence of multiple group calls with the same group ID, and the relatively high probability of the half duplex effect.
Our future work includes enhancing the access time analysis to consider more aspects related to ProSe, such as a probability model of the half duplex effect in the PSCCH. In addition, we will evaluate the MCPTT access time performance for the scenarios when multiple active UEs try to talk at nearly the same time, or there are multiple ongoing group calls competing for radio resources over ProSe.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that they have no conflicts of interest.