WO2016161599A1

WO2016161599A1 - System, method, and apparatus for floor control in off-network mode of mission critical push to talk (mcptt)

Info

Publication number: WO2016161599A1
Application number: PCT/CN2015/076170
Authority: WO
Inventors: Yunxi LI; Mats Folke; Johnny KAROUT; Qianxi Lu; Xinghua SONG; Stefan Waenstedt
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2015-04-09
Filing date: 2015-04-09
Publication date: 2016-10-13

Abstract

A method is provided. The method includes entering offnetwork mode in a push to talk (PTT) communication session; generating a priority attributes table, each entry in the table associated with one of a plurality of UEs participating in the PTT communication session; receiving data to be transmitted to the other UEs participating in the PTT communication session; determining whether the floor is available based on the entries in the priority attributes table; upon determining the floor is available, transmitting the data to the other UEs in the PTT communication session; and upon determining the floor is not available, waiting for the floor to become available.

Description

SYSTEM, METHOD, AND APPARATUS FOR FLOOR CONTROL IN OFF-NETWORK MODE OF MISSION CRITICAL PUSH TO TALK (MCPTT)

TECHNICAL FIELD

The present invention relates tomethods for floor control in off-network mode of mission critical push to talk.

BACKGROUND

Device-to-device communication is a well-known and widely used component of many existing wireless technologies, including ad hoc and cellular networks. Examples include Bluetooth and several variants of the IEEE 802.11 standards suite, such as WiFi Direct. These systems operate in unlicensed spectrum.

SUMMARY OF THE INVENTION

A method is provided in the present application. According to an aspect of the present application, the method comprises entering offnetwork mode in a push to talk (PTT) communication session； generating a priority attributes table, each entry in the table associated with one of a plurality of UEs participating in the PTT communication session； receiving data to be transmitted to the other UEs participating in the PTT communication session； determining whether the floor is available based on the entries in the priority attributes table； upon determining the floor is available, transmitting the data to the other UEs in the PTT communication session； and upon determining the floor is not available, waiting for the floor to become available.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows an example according to present invention；

Figure 2 shows an example scenario 1 according to the present invention；

Figure 3 shows an example scenario 2 according to the present invention；

Figure 4 shows an example scenario 3 according to the present invention；

Figure 5 shows an example scenario 4 according to the present invention；

Figure 6 shows an example scenario 5 according to the present invention；

Figure 7 shows an example scenario 6 according to the present invention；

Figure 8 illustrates a wireless network comprising a more detailed view of network node 200 and wireless device (WD) 210, in accordance with a particular embodiment.

DETAILED DESCRIPTION

Recently, device-to-device (D2D) communications as an underlay to cellular networks has been proposed as a means to take advantage of the proximity of communicating devices and at the same time to allow devices to operate in a controlled interference environment. Typically, it is suggested that such device-to-device communication shares the same spectrum as the cellular system, for example by reserving some of the cellular uplink resources for device-to-device purposes. Allocating dedicated spectrum for device-to-device purposes is a less likely alternative as spectrum is a scarce resource and (dynamic) sharing between the device-to-device services and cellular services is more flexible and provides higher spectrum efficiency.

The transmission mode when sending data during D2D communication may be either:

·Unicast –a specific UE is the receiver

·Multicast (may also be denoted groupcast) –a group of UEs are receivers

·Broadcast –all UEs are receivers

Where there is no cellular network D2D communication, data can be sent from one device to another device without prior arrangement, thereby reducing the overhead and increasing the communication capacity, which is crucial in emergency situations. The source device transmits data to one (unicast) or more (multicast/groupcast/broadcast) other devices, without first ensuring that the recipients are available and ready to receive the data. Such communication may be used for one-to-one or one-to-many communication, but it is particularly effective for multicast and broadcast transmissions and thus well-suited for broadcast and group communication. The communication may be realized, e.g., via PHY unicast/multicast/groupcast/broadcast transmissions. With PHY broadcast transmissions, the transmissions may still be turned into unicast/groupcast/multicast at higher layers. For example, in the MAC layer, multicast or even unicast addresses may be used. Alternatively, if using broadcast on both PHY and MAC, multicast or unicast IP addresses may be used at the IP layer.

One of the ways to efficiently support D2D communication is to use a scheduling assignment (SA) followed by the data transmission. SAs are control messages used for direct scheduling of D2D communication. SAs are transmitted by the UE that intends to transmit D2D data and they are received by the UEs that are potentially interested in such data. The SAs are transmitted on dedicated resources characterized by time and frequency, and are typically a sparse resource. SAs provide useful information that can be used by the receiver, e.g., to correctly decode the D2D data transmission associated to the SA (e.g., the resources for data transmission, the modulation/coding parameters, timing information, identities for the transmitter and/or receiver, etc) . Typically, but not necessarily, SAs are transmitted prior to the actual data transmission, so that a receiver is able to selectively receive data based on the content of the SAs. We call the data transmissions scheduled by a SA a “transmission pattern” .

For the data transmission procedure from UE-A to UE-B, which both are outside network coverage at the time of data transmission both UE-A and UE-B need to be preconfigured with, e.g., resource pool information (time and frequency configuration) to be used later for data transmission. When UE-A needs to transmit data to UE-B it typically first sends a sync signal, which later is used as a time reference by UE-B. The next step is to transmit a scheduling assignment, followed by the actual data.

According to SA1 requirements ProSe communication should provide means to give some users and/or groups higher priority when transmitting data. Such priority may be either static or dynamic. Priority defines who gets to transmit first when there is a shortage of resources, e.g. when only one Tx at a time is allowed. Further, priority is used to decide if pre-emption is required in order to ensure that the correct Tx is allowed to transmit. The various types of priority are explained in more detail in this text excerpt from SA2 TR:

“The User Static Attributes include information categorizing the user, possibly by several criteria (e.g. first responder, second responder, supervisor, dispatcher, and administrator) as well as jurisdictional boundaries and possibly, a pre-configured system-wide individual priority level.

The Group Static Attributes include information about the nature/type of the group and the owning agency (ies) , the jurisdictional boundaries for transmitters and receivers within the group, the normal hours of operation for the group, pre-emption dispositions relative to other groups, and the default minimum priority of the group, i.e. the minimum priority characteristics that are guaranteed to all the participants in a group call associated with this group, regardless of their individual priority characteristics.

The User Dynamic Attributes include the user/participant's operational status (e.g. on/off duty) , his location, the type of incident (e.g. MCPTT Emergency or Imminent Peril) he might be involved in and whether or not he initiated it, whether or not he is individually involved in a formally managed incident and if yes, the boundaries of the incident area, the incident severity and his assigned role in the resolution of the incident.

The Group Dynamic Attributes include the type of incident (e.g. MCPTT Emergency or Imminent Peril) , if any, the group is currently handling and, in case of involvement in a formally managed incident, the boundaries of the incident area and the incident severity. ”

A group ID is to be used to identify the group the UE belongs and to ensure that communication is received (and decoded) by the correct users. Further, the group ID is used to set up encryption. Since all UEs will be configured with an ID, priority should be mapped to said IDs.

Mission-critical communication

Mission-critical communication is about communication in NSPS (National Security and Public Safety) operations. Such communication has the possibility to put extra requirements on the network, e.g., lower latency (including setup times) and more fine-grained prioritization function. Push-to-talk is the mode of communication used.

A Push To Talk service provides an arbitrated method by which two or more users may engage in communication. Users may request permission to transmit (e.g., traditionally by means of a press of a button) . The Mission Critical Push To Talk over LTE (MCPTT) service supports an enhanced PTT service, suitable for mission critical scenarios, based upon 3GPP Evolved Packet System (EPS) services. The requirements for Mission Critical Push To Talk (MCPTT) service defined within can also form the basis for a non-mission critical Push To Talk (PTT) service.

The MCPTT Service is intended to support communication between several users (a group call) , where each user has the ability to gain permission to talk in an arbitrated manner. The MCPTT Service builds on the existing 3GPP transport communication mechanisms provided by the EPS architectures to establish, maintain, and terminate the actual communication path (s) among the users.

The MCPTT Service allows users to request the permission to talk (transmit voice/audio) and provides a deterministic mechanism to arbitrate between requests that are in contention (i.e., Floor control) . When multiple requests occur, the determination of which user's request is accepted and which users' requests are rejected or queued is based upon a number of characteristics (including the respective priorities of the users in contention) . The MCPTT Service provides a means for a user with higher priority (e.g., emergency condition) to override (interrupt) the current talker. MCPTT Service also supports a mechanism to limit the time a user talks (holds the floor) thus permitting users of the same or lower priority a chance to gain the floor.

The users of an MCPTT Service may have more stringent expectations of performance than the users of a commercial PTT service. MCPTT is primarily targeting to provide a professional Push To Talk service to e.g., public safety, transport companies, utilities or industrial and nuclear plants. In addition to this a commercial PTT service for non-professional use (e.g., groups of people on holiday) may be delivered through an MCPTT system

The MCPTT service can operate in two modes: On-Network mode and Off-Network mode, respectively. With Off-Network mode MCPTT users employ a direct path for ProSe Discovery and ProSe Communication. With On-Network mode, MCPTT uses legacy cellular communication path without the use of ProSe Discovery and the ProSe Communication.

Floor control is an arbitration system that determines who has the authority to transmit (talk) at a point in time during a call.

Pre-emption is the act of terminating on-going calls in order to free up resources for a higher priority call request.

Floor control is requested to support MCPTT Off-Network mode, which will be based on ProSe technology. There are some solutions on floor control being discussed in 3GPP TR 23.779 Study on application architecture to support Mission Critical Push To Talk over LTE (MCPTT) services, (Release 13) , v060 (herein after “Ref [1] ” )

Distributed and control message based solution

The solution 6-1-1 in Ref [1] is an example. The overall procedure is as below:

Step 0) All UEs involved in a group call will maintain a list of UEs in its proximity, i.e. by reading its list, a UE can know which UE (s) are reachable to it. The list will be updated periodically with some mechanism based on the data received from other UEs.

Step 1) The TX UE (e.g. UE-1) sends an “Originate” message carrying information of its identity ( “UE-1” ) and priority.

Step 2) The RX UEs (e.g. UE2) receive the “Originate” will reply with an “Ack” message or some lower layer feedback indication, which carries the information of its identify (e.g. “UE2” ) and the identify of UE sending “Originate” message ( “UE1” ) .

Step 3) the TX UE can continue when and only when it receives “Ack” from some specific UEs in its list.

The problems with this solution include:

a.Control Messages

Before the UE starts transmitting traffic, it must transmit and receive some control messages ( “Originate” , “Ack” ) with other UEs. These messages will be transmitted via ProSe path. When the UE selected resource is used, these controlling messages may be lost, due to interference/collision among different transmitters. It may lead to floor control failure.

When the eNB scheduled resource is used, some delay may be introduced, as both TX UE and RX UE need to request resources from its serving eNB.

All RX UE need to transmit “Ack” once they receive “Originate” , which may lead to more than one RX transmitting “Ack” simultaneously； however, only one of them can be received by the TX. In a worse case, more than one RX may transmit “Ack” using the same time-frequency resources, which will lead to “Ack” reception failure due to interference. In this case, the UEs having send out “Ack” would assume the requesting UE will take the floor, but the requesting UE would assume floor request failure (as it did not receive the missing “Ack” ) . As a result, no one can have the floor, which leads to bad user experience. Some randomization may mitigate the potential problem but cannot resolve the risk of this happening entirely, and will lead to additional delay.

b.Signalling Overhead

Considering that all UEs need to transmit (either “Originate” or “Ack” ) during each floor control procedure, the signalling overhead would be significant, especially when there is a large number of UEs involved in the same group calls. When the system is fully loaded, the transmission success rate would decrease, i.e. the floor control message may not be transmitted sometimes. As a result, the UE has to retransmit floor control messages, which generates more traffic to the system and makes interference worse.

c.Mobility

When a UE (say UE1) having the floor moves out of the ProSe range, a new UE (say UE2) may have the floor and start transmitting. However, when UE1 and UE2 moving close to each other and both of them are transmitting, the floor control fails.

d.Override

Overide (how a higher priority transmitter gets floor from an ongoing low priority transmission) is not considered.

Centralized and control message based solution

The solutions 6-1-2 and 6-1-3 in Ref [1] are examples of this kind of solution. The overall idea is as below:

1) Some centralized node, called Floor Arbitrator (FA) needs to be selected before the call starts, but also during the call in case the FA is unreachable and a new FA needs to be selected.

2) All TX UEs communicate with FA with floor control messages to get floor.

These solutions share the same problems as the solution in the distributed system. Furthermore, it relies on a centralized FA, which leads to single point of failure problem. When the FA fails, or moves out of proximity range temporarily, floor control does not work. In this case, a FA reselection procedure can be triggered to select a new FA, but may lead to additional delay and resource consumption. Moreover, an FA selection/re-selection procedure would lead to significant complexity.

Certain embodiments of the solution proposed herein include where each transmitting UE will act as floor arbitrator to determine whether it has floor or not, based on the priority of itself and other UEs. The UE calculates the priority of itself and other UEs based on the priority calculation mechanism and corresponding information.

The UE involved in a group call may keep monitoring transmissions from other UEs when it is not transmitting. When the UE intends to transmit, it compares the priority of other transmitters and itself, and decides whether to transmit or to stop. This provides a distributed solution, which avoids the single failure problem. This solution also may utilize existing transmissions without introducing additional signaling, which is resource efficient. In particular, there is no additional floor control signaling among UEs prior to transmission, which reduces service delay and resource consumption. In addition, the solution provides for the ability to have an override capability.

Certain embodiments may take advantage of the analysis of received transmissions, which can handle ProSe based communication smoothly, where communication is connection-less and UE are moving:

Late entry: the UE which joins the call later can be handled smoothly.

Temporarily out of ProSe range: when the UE moves out of D2D range temporarily, other UEs can detect that and transmit if possible, which maximizes the possibility of transmission from group call perspective.

The WID for ProSe Rel-13 0 states the following objective

3) Define enhancements to D2D communication to enable the following features:

b) Priority of different groups support [RAN2, RAN1, RAN3] .

Herein we discuss how this prioritization mechanism can be used in the context of floor control. Floor control itself is a vital mechanism group communication, which in turn is the main application for ProSe Direct Communication.

The normal mode of operation in ProSe is that one user in a group is allowed to talk at a time. Floor control is in this context the process of selecting which user that is allowed to talk and notifying the user. Not all services require the use of floor control, therefore the floor control function will most likely reside on the application layer. This implies it is of limited concern to RAN2. However, some RAN2 involvement is required and therefore it is a good idea to describe the use of such RAN2 elements in a context i.e. exemplify how floor control can be implemented with ProSe.

It may be possible for this to be guaranteed in Rel-12 uncheduled solution e.g. in out of coverage？

·Through an application layer floor control mechanism.

·when override occurs, there can be more than one user speaking, if it is configured that the overridden user is allowed to speak.

According to (ref) :

“Floor control allows users of networked multimedia applications to utilize and share resources such as remote devices, distributed data sets, telepointers, or continuous media such as video and audio without access conflicts. Floors are temporary permissions granted dynamically to collaborating users in order to mitigate race conditions and guarantee mutually exclusive resource usage. ”

This basically means that a UE that attempts to transmit voice data needs to ask for and receive permission to transmit. As a part of the process it is necessary to make sure that the medium is free, i.e. no other UE is transmitting. We also think that the possibility to pre-empt or override an ongoing communication should be included as part of the floor control； when a UE with higher priority wants to transmit, any current transmission by a UE with lower priority needs to be stopped in order for the floor to be made available. Finally, the UE that is pre-empted has to be notified.

For MCPTT two new modes concerning operation have been proposed. Off-network group calls comprise calls using ProSe Direct Communication to realize the communication path. On-network group calls would use the legacy LTE instead.

On-network mode will use LTE infrastructure for group calls, with limited impact on RAN.

When UEs are involved in ProSe communication in on-network mode floor control is provided on the application layer. The implementation is quite straightforward since there is a central controlling entity, the ProSe Function, that can provide all important functionality. Hence, in the remainder of this contribution we discuss off-network mode operation.

Off-network mode will use ProSe for group calls, which is focus from RAN2 perspective when studying how to support MCPTT.

A user that wants to transmit presses the PTT button on the UE. If the UE is the first UE in the group to transmit no special procedure is needed； information on transmitting UE (its ID) is passed to the application layer of the receiving UE, e.g. by adding the information on priority to a MAC CE, together with time stamp showing when communication session started. To make the example a bit more readable we denote this first UE as UE1.

If there is an ongoing communication session the UE must behave differently. Since all UEs in a group listen to the ongoing communication in the group all UEs will know the identity (and the priority) of the transmitting UE1. If another user at this stage wants to transmit and presses the PTT button, this UE2 will transmit its SA during an SA period. The data part could contain a floor request.

A UE that is transmitting SAs and data can during the ongoing communication session receive and decode the SA and data from a second transmitting UE.

The transmitting UE1 decodes the SA from UE2 and optionally notes that UE2 has a lower priority； UE1 decodes the identity of UE2 and passes the information to the floor control (on application layer) .

Information needed to put UEs in queue is based on the time a UE requests the floor, the static priority of the UE within the group and the current situation, e.g. If the UE requests an emergency call or not.

As we have seen a centralized floor control can be used for UEs communicating in coverage. For ProSe communication a distributed floor control mechanism is desirable. There are some proposals for how to implement floor control for off-network operation in 0. A key function is the Floor Arbitrator (FA) . It can be a central node, which would be suitable for on-network operation, but it can also be a distributed function, split among the communicating UEs. For off-network operation a distributed implementation is more suitable as there is no central node in this case. This is also beneficial as there is no single point of failure too.

Floor control for is an application layer function. Floor control does not need to be standardized in RAN2, possibly only the input required from AS.

Although we propose that floor control is an application and as such does not need to be standardized in RAN2, an example of a floor control algorithm can be found with reference to figure 6 to simplify the understanding.

In section 0 we made the following observations:

Observation 1 On-network mode will use LTE infrastructure for group calls, with limited impact on RAN.

Observation 2 Off-network mode will use ProSe for group calls, which is focus from RAN2 perspective when studying how to support MCPTT.

Observation 3 A UE that is transmitting SAs and data can during the ongoing communication session receive and decode the SA and data from a second transmitting UE.

Observation 4 Information needed to put UEs in queue is based on the time a UE requests the floor, the static priority of the UE within the group and the current situation, e.g. If the UE requests an emergency call or not.

It is to be noted that any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to the other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, and drawings.

Generally, all terms used herein are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the element, apparatus, component, means, step, etc. " are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

Some of the embodiments contemplated by the inventors will now be described more fully hereinafter with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of this disclosure and should not be construed as limited to only the embodiments set forth herein； rather, these embodiments are provided by way of example.

1.1 General terms

Floor control for a group call may be used to decide which transmitter can transmit within a group call. For simplicity, the data targeting the concerned group call will be considered. In other words, the data targeting other groups will not impact the floor control of current group. L2 Destination ID specifies the group which the data belongs to.

An empty data/transmission may refer to that the transmitting UE transmits a packet including MAC PDU header and the corresponding Sidelink Control Information (SCI) without including any data. The empty data/transmission may enable the receiving UE decode the complete source ID and destination ID.

1.2 Priority

The UEs involved in a group call may have a priority calculation function deployed in such a way that all UEs with same input will calculate same priority.

1.2.1 Priority attributes

A UE may maintain a list of “Priority Attributes” , each element of the list corresponds to a UE, as shown in Table 1.

Table 1 Priority Attributes (Unpopulated)

UE identifier	Static Attributes &Dynamic Attributes
UE identifier	Static Attributes &Dynamic Attributes	UE1 (current UE)	…
UE2	…	UE1 (current UE)	…
UE2	…	UE3	…

“Priority Attributes” may include two parts:

1) Static Attributes, including, but not limited to；

(a) The role of the transmitter, e.g. first (second etc. ) responder, supervisor, dispatcher, administrator and etc.

(b) System-wide individual priority level, which can be pre-configured priority of the UE.

2) Dynamic Attributes, including, but not limited to；

(a) Whether the UE is waiting for the floor

(b) How long the UE is waiting (i.e. when the UE starts waiting)

(c) How long since latest hearing from the UE. If a UE was not receiving anything from the UE waiting for floor during a certain time, e.g. 2 minutes, it may consider the waiting UE stops waiting for floor.

In some embodiments, “Static Attributes” of “Priority Attributes” can be pre-configured in UE. The configuration can be updated from the network when the UE is in coverage, periodically, or when needed, e.g. upon calculating priority. “Dynamic Attributes” may updated in real time:

1) when a UE intends to transmit；

2) when a waiting UE gets floor；

3) when the UE is overridden and the overridden is not allowed to transmit

4) when UE receives an empty data (e.g., empty data set may be used to support queue in floor control)

1.2.2 Priority calculation

Based on the “Priority Attributes” information, the UE can calculate the priority of current UE (the data to be transmitted) and other UEs (data received) when needed. For example, a UE may maintain the priority result information of itself and other UEs in a table, such as Table 2 below.

Table 2 Priority Result

UE identifier	Priority Result	Calculation Time
UE identifier	Priority Result	Calculation Time	UE1 (current UE)	2	2015-03-25 11: 15: 00: 000
UE2	3	2015-03-25 11: 16: 00: 000	UE1 (current UE)	2	2015-03-25 11: 15: 00: 000
UE2	3	2015-03-25 11: 16: 00: 000	UE3	2	2015-03-25 11: 15: 03: 000

The column “Calculation Time” indicates the time when the corresponding priority was calculated, when the priority result may or may not change. The UE may consider recalculate the priority which was calculated long time ago. In some instances, the recalculation may be done after 2 seconds has elapsed since the last calculation.

In embodiments, the “Priority Result” column information may be updated upon triggering events, including, but not limited to:

(1) periodically, e.g. based on “Calculation Time” ；

(2) when there is a change in “Priority Attributes” ；

(3) when the UE receives a data and corresponding SCI from another UE, and the priority information of the UE is not stored yet, the priority result information of the transmitting UE is calculated and stored and/or the priority results for the other UEs is recalculated.

Depending on the scenario, the priority calculation function may be located in the UE, when the priority calculation algorithm is pre-configured in the UE or it may be configured by the network when the UE is in coverage. In some embodiments, the priority calculation function may be located in network and the UE makes a request to network to calculate the priority. In certain embodiments, the UE does not keep or calculate priority for all packets transmitted/received, which may save UEs power and resources.

1.3 Keep receiving when not transmitting

A UE involved in a group call may continue to receive transmissions targeting a current group from other UEs when possible, e.g. when it is not transmitting. Even for a UE with an ongoing transmission which uses the dis-contiguous timeslots to transmit, it may continue to receive other UEs during the non-transmitting timeslots. When receiving transmissions from other UEs, once the UE receives a MAC PDU successfully and the corresponding SCI, which enables the receiver to decode the complete source ID and destination ID of the transmission, it may stop receiving from this UE during the rest of the SCI (Sidelink Control) period of the transmitting UE, as shown in figure 1. This may save receiving power.

In the example shown in figure 1, UE2 is receiving data transmitted from UE1.

At T1: UE2 receives SCI#2 successfully.

At T2: UE2 receives Data #1 but fails, e.g. due to CRC check failure.

At T3: UE2 receives Data #2 successfully. So far, UE2 has received one SA and one SCI from UE1. UE2 can stop receiving from UE1 during the rest time of current SC period, i.e. during [T3 to T4]

In some embodiments, when the UE receives a transmission, the UE can update “Priority Attributes” (if needed) corresponding to the source identifiers of the transmission, e.g. “SRC” field in MAC PDU in 3GPP TS 36.321 EUTRAN； Medium Access Control (MAC) protocol specification, v12.5.0.

1.4 Occupying the floor

If it is configured that the overridden UE can continue transmitting, there can be more than one UE occupying the floor. A UE (say UE1) may consider the floor is being occupied by other UE (say UE2) , if during the last certain period, e.g. 3 seconds, or one SC period of UE2:

(1) UE1 received at least one non-empty transmission from UE2； AND

(2) UE2 was not overridden by other UE (s) .

In Example Scenario 1 shown in figure 2, the receiving UE (UE1) received non-empty data during the SC period #1 (SC period of transmitting UE, i.e. UE2) , but received nothing during SC period #2 and #3.

·At T1: UE1 considers UE2 is occupying the floor；

·At T2: UE1 considers UE2 is occupying the floor；

·At T3: UE1 considers UE2 is occupying the floor；

·At T4: UE1 considers UE2 is not occupying the floor.

A UE may consider it is occupying the floor, if during the last certain period, e.g. 3 seconds, or one SC period:

(1) it transmitted at least one non-empty data； AND

(2) it was not overridden by other UE (s) .

In Example Scenario 2 shown in figure 3, the transmitting UE transmits non-empty data during the SC period #1 (SC period of transmitting UE) , but does not transmit during SC period #2 and #3.

·At T1: transmitting UE considers it is occupying the floor；

·At T2: transmitting UE considers it is occupying the floor；

·At T3: transmitting UE considers it is occupying the floor；

·At T3: transmitting UE considers it is not occupying the floor.

1.5 Override

When the floor is being occupied by some UE (s) , if a UE starts transmitting data which is not emergency data and has higher priority than all the UEs occupying the floor, an override occurs. Depending on the configuration, it may be that the overridden UE can continue transmitting, the overriding UE and overridden UE (s) occupy the floor at the same time or the overridden UE cannot continue transmitting, the overriding UE occupies the floor and the overridden UE (s) lose the floor and the overridden UE should stop transmitting.

1.6 Emergency transmission

When a UE wants to transmit emergency messages (e.g. in the situation of emergency situation or imminent peril) , it starts transmitting regardless of floor control. The UE needs to select the resources which are not being used by the current ongoing transmission (s) .

1.7 Hold floor

When a UE (say UE1) occupying the floor does not transmit any data for some time, other UE (say UE2) may occupy the floor. If UE1 intends to transmit again and its priority is not higher than UE2, UE1 has to wait until UE2 releases floor, which increase service delay of UE1. In some cases, UE1 may intend to keep the floor even it has nothing to transmit to shorten the delay due to floor control. When a UE occupying the floor has nothing to transmit, but wants to keep the floor, the UE can transmit an empty data periodically.

1.8 Request floor

When a UE not occupying the floor intends to transmit, it needs to get the floor before it can transmit. When a UE waiting for a floor, detects a UE releasing its floor, i.e. changing from occupying the floor to not occupying the floor as described above, it tries to get floor. If there is no UE occupying the floor, and the calculated priority of the current UE is the highest among all UEs waiting for floor (section 1.2.1) , the current UE may conclude that it has the floor and starts transmission. If, on the other hand, the floor is occupied by other UE (s) , it compares the priority between the UE (s) occupying the floor and itself:

·If the UE has the highest priority, it occupies the floor and starts transmission.

·If the UE priority is not the highest, the UE transmits an empty data. The UE needs to select the resources which are not being used by the current ongoing transmission. The transmitted empty data may serve to put the UE in a queue for the floor.

A UE waiting for the floor can transmit an empty data periodically. Transmitting empty data periodically can secure all UEs, including the late entry UE know the information of waiting UE.

1.9 Re-transmission

When an override occurs, it is possible that during a short period, the overriding UE and the overridden UE transmit simultaneously. The overriding UE and the overridden UE may miss data from each other due to the half-duplex nature of PTT. Other receiving UEs also may not be able to receive the data from both the overriding UE and the overridden UE during the override period, due to the UEs capability. For the overridden UE, which stops ongoing transmission due to being overridden, it assumes that the data transmitted during the last certain time (e.g., the last SC period) before the override may be of been missed by the receiving UEs. This data may be re-transmitted once the UE gets the floor again.

In Example Scenario 3 shown in figure 4, UE1 is transmitting. During SC period #N+1, it was overridden. UE1 assumes the data transmitted during the overriding period (#N+1) , data4 and data5, was not received by the other UEs. When UE1 regains the floor, it can retransmit data4 and data5 if it is still desirable to transmit the data.

For the overriding UE, it assumes the data being transmitted during the beginning certain time after the override may not be received by other UEs and/or the overridden UE. The overriding UE can retransmit the data it transmitted during the beginning certain time (i.e. during the first SC period) . In Example Scenario 4 shown in figure 5, when UE1 overrides other UEs during SC period #N, it considers the data transmitted during the overriding period, data1 may be missed by the other UEs. In the succeeding SC period, data1 may be retransmitted. In some embodiments, the overriding UE may initially send nonce data (e.g., dummy data) during the overriding period knowing that it has likelihood of not being received and then transmit the actual data in the succeeding SC periods.

1.10 Limit the time of occupying floor

To avoid the UE with higher priority always controlling the floor, which makes it impossible for lower priority UEs to transmit, some embodiments may place a time limit on how long the UE may hold the floor. For example, in some instances, the UE having the floor may maintain two timers: Timer_Floor and Timer_Wait. The length of these two timers can be group specific and configured in each UE.

Timer_Floor: indicates the maximum time for a UE to have the floor.

(1) When the UE gets the floor, the timer restarts.

(2) When the UE loses or releases floor, the timer stops.

(3) When the timer expires, the UE releases the floor.

Timer_Wait: indicates how long a UE must wait before it can retry to get the floor after releasing the floor (e.g., due to Timer_Floor expiration) .

(1) When a UE releases the floor due to Timer_Floor expiration, the timer restarts.

(2) When the timer is running and there is other UE occupying the floor or waiting for the floor, current UE can not try to get the floor.

(3) When the timer is running and there is no other UE occupying the floor or waiting for the floor, current UE can try to get the floor.

(4) When the timer expires, the UE can try to get the floor.

1.11 Overall procedure

In Example Scenario 5 shown in figure 6, an overview is provided in which UE1, UE2, UE3 and UE4 are involved in a group call. The priority is UE1 > UE2 > UE3 > UE4. To make it simple, it is assumed that the SC periods of all UEs are the same and they are aligned. In this example, the overridden UE shall stop transmitting. Retransmission is not considered in this example.

·At T1: UE3 intends to transmit. No UE is occupying the floor. UE3 starts transmitting.

·After T1: All UEs know UE3 is occupying the floor.

·At T2: UE1 intends to transmit. UE3 is occupying the floor, but UE1 has higher priority. UE1 overrides and starts transmitting.

·After T2: All UEs know UE1 is occupying the floor and UE3 is waiting the floor.

·At T3: UE2 intends to transmit. UE1 is occupying the floor and has higher priority. UE2 cannot transmit.

·After T3, the priority information in UE2 will be different from that in other UEs:

(1) UE2 considers UE1 is occupying the floor and UE2&UE3 is waiting the floor；

(2) Other UEs considers UE1 is occupying the floor and UE3 is waiting the floor.

·At T4: UE1 has not transmitted for two SC periods. All UEs consider it releases the floor.

(1) From UE2’s perspective, it detects UE1 releasing the floor, and UE2 is the highest priority among all waiting UEs； it gets the floor and starts transmitting.

(2) From UE3 perspective, it detects UE1 releasing the floor and UE3 is the only waiting UE； it gets the floor and starts transmitting.

As a result, UE2 and UE3 are transmitting simultaneously. UE2 and UE3 hear from each other. UE2 has higher priority and will continue transmitting. UE3 receives transmission from UE2 and considers it is overridden by UE2 and will stop transmitting.

After T4: All UEs know UE2 is occupying the floor and UE3 is waiting the floor.

·At T5: UE2 has not transmitted for two SC periods. All UEs consider UE2 as releasing the floor. UE3 detects UE2 releasing the floor, gets the floor and starts transmitting.

·After T5: All UEs know UE3 is occupying the floor.

In Example Scenario 6 shown in figure 7, UE1, UE2, UE3 and UE4 are involved in a group call. The priority is UE1 > UE2 > UE3 > UE4. To make it simple, it is assumed that the SC periods of all UEs are same and aligned. In this example, overridden UE shall stop transmitting. Retransmission is not considered in this example.

·After T1: All UEs know UE3 is occupying the floor.

·After T2: All UEs know UE1 is occupying the floor and UE3 is waiting for the floor.

·At T3: UE2 intends to transmit. UE1 is occupying the floor and has a higher priority. UE2 cannot start transmission. UE2 transmits an empty data.

·After T3: All UEs know UE1 is occupying the floor and UE2&UE3 are waiting for the floor.

·At T4: UE1 has not transmitted for two SC periods. All UEs consider UE1 as having released the floor. UE2 detects UE1 releasing the floor, gets the floor and starts transmitting. UE3 also detects UE1 releasing the floor, but it cannot get the floor as there is a higher priority UE (UE2) waiting for the floor.

·After T4: All UEs know UE2 is occupying the floor and UE3 is waiting for the floor.

·At T5: UE2 has not transmitted for two SC periods. All UEs consider UE2 as having released the floor. UE3 detects UE2 releasing the floor, and UE3 then gets the floor and starts transmitting.

·After T5: All UEs know UE3 is occupying the floor.

Figure 8 illustrates a wireless network comprising a more detailed view of network node 200 and wireless device (WD) 210, in accordance with a particular embodiment. For simplicity, Figure 8 only depicts network 220,

network nodes

200 and 200a, and WD 210. Network node 200 comprises processor 202, storage 203, interface 201, and antenna 201a. Similarly, WD 210 comprises processor 212, storage 213, interface 211 and antenna 211a. These components may work together in order to provide network node and/or wireless device functionality, such as providing wireless connections in a wireless network and allowing for a change in estimated DL CC. In different embodiments, the wireless network may comprise any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, and/or any other components that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections.

Network 220 may comprise one or more IP networks, public switched telephone networks (PSTNs) , packet data networks, optical networks, wide area networks (WANs) , local area networks (LANs) , wireless local area networks (WLANs) , wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices.

Network node 200 comprises processor 202, storage 203, interface 201, and antenna 201a. These components are depicted as single boxes located within a single larger box. In practice however, a network node may comprises multiple different physical components that make up a single illustrated component (e.g., interface 201 may comprise terminals for coupling wires for a wired connection and a radio transceiver for a wireless connection) . Similarly, network node 200 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, a BTS component and a BSC component, etc. ) , which may each have their own respective processor, storage, and interface components. In certain scenarios in which network node 200 comprises multiple separate components (e.g., BTS and BSC components) , one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeB’s . In such a scenario, each unique NodeB and BSC pair, may be a separate network node. In some embodiments, network node 200 may be configured to support multiple radio access technologies (RATs) . In such embodiments, some components may be duplicated (e.g., separate storage 203 for the different RATs) and some components may be reused (e.g., the same antenna 201amay be shared by the RATs) .

Processor 202 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other network node 200 components, such as storage 203, network node 200 functionality. For example, processor 202 may execute instructions stored in storage 203. Such functionality may include providing various wireless features discussed herein to a wireless devices, such as WD 210, including any of the features or benefits disclosed herein.

Storage 203 may comprise any form of volatile or non-volatile computer readable memory including, without limitation, persistent storage, solid state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM) , read-only memory (ROM) , removable media, or any other suitable local or remote memory component. Storage 203 may store any suitable instructions, data or information, including software and encoded logic, utilized by network node 200. Storage 203 may be used to store any calculations made by processor 202 and/or any data received via interface 201.

Network node 200 also comprises interface 201 which may be used in the wired or wireless communication of signalling and/or data between network node 200, network 220, and/or WD 210. For example, interface 201 may perform any formatting, coding, or translating that may be needed to allow network node 200 to send and receive data from network 220 over a wired connection. Interface 201 may also include a radio transmitter and/or receiver that may be coupled to or a part of antenna 201a. The radio may receive digital data that is to be sent out to other network nodes or WDs via a wireless connection. The radio may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters. The radio signal may then be transmitted via antenna 201a to the appropriate recipient (e.g., WD 210) .

Antenna 201a may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In some embodiments, antenna 201a may comprise one or more omni-directional, sector or panel antennas operable to transmit/receive radio signals between, for example, 2 GHz and 66 GHz. An omni-directional antenna may be used to transmit/receive radio signals in any direction, a sector antenna may be used to transmit/receive radio signals from devices within a particular area, and a panel antenna may be a line of sight antenna used to transmit/receive radio signals in a relatively straight line.

WD 210 may be any type of wireless endpoint, mobile station, mobile phone, wireless local loop phone, smartphone, user equipment, desktop computer, PDA, cell phone, tablet, laptop, VoIP phone or handset, which is able to wirelessly send and receive data and/or signals to and from a network node, such as network node 200 and/or other WDs. WD 210 comprises processor 212, storage 213, interface 211, and antenna 211a. Like network node 200, the components of WD 210 are depicted as single boxes located within a single larger box, however in practice a wireless device may comprises multiple different physical components that make up a single illustrated component (e.g., storage 213 may comprise multiple discrete microchips, each microchip representing a portion of the total storage capacity) .

Processor 212 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in combination with other WD 210 components, such as storage 213, WD 210 functionality. Such functionality may include providing various wireless features discussed herein, including any of the features or benefits disclosed herein.

Storage 213 may be any form of volatile or non-volatile memory including, without limitation, persistent storage, solid state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM) , read-only memory (ROM) , removable media, or any other suitable local or remote memory component. Storage 213 may store any suitable data, instructions, or information, including software and encoded logic, utilized by WD 210. Storage 213 may be used to store any calculations made by processor 212 and/or any data received via interface 211.

Interface 211 may be used in the wireless communication of signalling and/or data between WD 210 and network node 200. For example, interface 211 may perform any formatting, coding, or translating that may be needed to allow WD 210 to send and receive data from network node 200 over a wireless connection. Interface 211 may also include a radio transmitter and/or receiver that may be coupled to or a part of antenna 211a. The radio may receive digital data that is to be sent out to network node 201 via a wireless connection. The radio may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters. The radio signal may then be transmitted via antenna 211a to network node 200.

Antenna 211a may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In some embodiments, antenna 211a may comprise one or more omni-directional, sector or panel antennas operable to transmit/receive radio signals between 2 GHz and 66 GHz. For simplicity, antenna 211a may be considered a part of interface 211 to the extent that a wireless signal is being used.

Although components for both WD 210 and network node 200 are depicted and described, in certain embodiments, WD 210 may be operating in an area in which it is out of range of any network node and is utilizing device to device communication to communicate directly with other wireless devices.

In some embodiments, the components described above may be used to implement one or more functional modules used in floor control for Off-Network mode of MCPTT. The functional modules may comprise software, computer programs, sub-routines, libraries, source code, or any other form of executable instructions that are run by, for example, a processor. In general terms, each functional module may be implemented in hardware and/or in software. Preferably, one or more or all functional modules may be implemented by processors 212 and/or 202, possibly in cooperation with storage 213 and/or 203. Processors 212 and/or 202 and storage 213 and/or 203 may thus be arranged to allow processors 212 and/or 202 to fetch instructions from storage 213 and/or 203 and execute the fetched instructions to allow the respective functional module to perform any features or functions disclosed herein. The modules may further be configured to perform other functions or steps not explicitly described herein but which would be within the knowledge of a person skilled in the art.

Certain aspects of the inventive concept have mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, embodiments other than the ones disclosed above are equally possible and within the scope of the inventive concept. Similarly, while a number of different combinations have been discussed, all possible combinations have not been disclosed. One skilled in the art would appreciate that other combinations exist and are within the scope of the inventive concept. Moreover, as is understood by the skilled person, the herein disclosed embodiments are as such applicable also to other standards and communication systems and any feature from a particular figure disclosed in connection with other features may be applicable to any other figure and or combined with different features.

The features and functions disclosed herein may be performed through a computer program product that may, for example, be executed by the components and equipment illustrated in Figure 8. For example, storage 203 may comprise computer readable means on which a computer program can be stored. The computer program may include instructions which cause processor 202 (and any operatively coupled entities and devices, such as interface 201 and storage 203) to execute methods according to embodiments described herein. The computer program and/or computer program product may thus provide means for performing any steps herein disclosed.

Certain aspects and embodiments have been described above however, as is readily appreciated by a person skilled in the art, embodiments other than the ones disclosed above are equally possible and within the scope of this disclosure. Similarly, while a number of different combinations have been discussed, all possible combinations have not been disclosed. One skilled in the art would appreciate that other combinations exist and are within the scope of this disclosure. Moreover, as is understood by the skilled person, the herein disclosed embodiments are as such applicable also to other standards and communication systems and any feature from a particular figure disclosed in connection with other features may be applicable to any other figure and or combined with different features.

Claims

A method, comprising:

entering offnetwork mode in a push to talk (PTT) communication session；

generating a priority attributes table, each entry in the table associated with one of a plurality of UEs participating in the PTT communication session；

receiving data to be transmitted to the other UEs participating in the PTT communication session；

determining whether the floor is available based on the entries in the priority attributes table；

upon determining the floor is available, transmitting the data to the other UEs in the PTT communication session；

upon determining the floor is not available, waiting for the floor to become available.
The method of 1 further comprising transmitting empty data.
The method of 1 wherein the priority attributes comprise static attributes and dynamic attributes；

and further comprising updating the dynamic attributes.
The method of 3 wherein the attributes are updated upon a triggering event comprising one or more of the following :

periodically；

when there is a change in priority attributes；

when there is a change in the priority calculation algorithm； and

wehn data is receved from a UE.
The method of 1 further comprising receiving data from other UEs
The method of 1 wherein determining whether the floor is available is further based on previous data transmissions,
The method of 6 wherein upon no higher priority UE transmitting non-empty data during a previous transmission period, the floor is determined available.
The method of 1 further comprising, transmitting an emergency transmission irrespective of whether or not the floor is available.
The method of 1 further comprising:

determining the floor was not available when transmitting the data to the other UEs in the PTT communication session； and

retransmitting the data upon determining that the floor has become available.
The method of 1 further comprising maintaining at least one timer to limit the amount of time the floor is held.
The method of 1 further comprising maintaining at least one timer to limit the amount of time before attempting to gain the floor.
The method of 1 further comprising maintain a queue of UEs waiting for the floor.
An apparatus comprising an interface, non-transitory computer readable media, and a processor, the apparatus configured to perform any of the methods listed above.
An apparatus comprising a processor and computer readable storage media, the storage media containing instructions executable by the processor, whereby the wireless device is operative to perform any of the method listed above.
An apparatus comprising a plurality of functional modules, each module configured to implement one or more of the methods listed above.