Patent Description:
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 MCPTT Service is intended to support communication between several users (a group call), where each user has the ability to gain access to the 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 also builds upon ProSe(Proximity-based Service) service enabler for off-network communications. While operating in off-network mode the MCPTT service uses a ProSe E-UTRA direct (UE-to-UE) Communication path (ProSe direct communication path) for transport. The ProSe direct communication path does not traverse the network infrastructure.

MCPTT employs a floor control mechanism for the MCPTT calls. In general, the MCPTT during usual operations, only one user is expected to transmit media. For e.g., to transmit media, an MCPTT user may request for floor transmission permission from the floor arbitrator or the floor control server. If the floor is available for transmission, the floor control server grants the permission to the requesting user. But, in-case the floor is already occupied by another MCPTT user and is not immediately available for transmission, the MCPTT server has <NUM> viable options: <NUM>. Deny the floor request, <NUM>. Queue the floor request and later grant when possible, or <NUM>. Override the current occupant of the floor and grant permission to the requesting user.

For option <NUM>, the floor arbitrator or the floor control server, needs to determine the priority and override capability of the floor request. Conventionally, there are techniques associated with the MCPTT call type, MCPTT user and the floor request that can play a role in determining the floor request priority and override capability of the floor request. However, these techniques fails to consider the priority of the current occupant prior to granting permission to the requesting user.

3GPP Technical Specification <NUM> (Version <NUM>. <NUM>) specifies the media plane control protocols and interactions with the media needed to support Mission Critical Push To Talk (MCPTT).

3GPP Technical Specification <NUM> (Version <NUM>. <NUM>) specifies requirements for an MCPTT service.

The above information is presented as background information only to help the reader to understand the present invention. Applicants have made no determination and make no assertion as to whether any of the above might be applicable as prior art with regard to the present application.

The principal object of the embodiments herein is to provide a method for managing a floor request in a mission critical communication system.

Another object of the embodiments herein is to provide a method to determine the effective priority of the floor requests based on a call type parameter and a floor priority.

Another object of the embodiments herein is to provide a method for managing, the floor request of the first floor participant based on an effective priority.

Another object of the embodiments herein is to provide a method for managing a floor request from a first floor participant in a mission critical communication system when the call type of the first floor participant is identical to the call type of the second floor participant, wherein the second floor participant is the current occupant of the floor.

A method of managing a floor request in a mission critical communication system is provided as defined in the appended claims.

A floor control server for managing a floor request in a mission critical communication system is provided as defined in the appended claims.

According to various exemplary implementations, a floor control server of a MCPTT system determines the effective priority of the floor requests based on a call type parameter or a floor priority parameter.

According to various exemplary implementations, the floor control server of the MCPTT system manages the floor request of the first floor participant based on an effective priority.

According to various exemplary implementations the floor control server of the MCPTT system manages a floor request from a first floor participant in a mission critical communication system when the call type of the first floor participant is identical to the call type of the second floor participant, wherein the second floor participant is the current occupant of the floor.

The embodiments herein will be better understood from the following detailed description with reference to the drawings, in which:.

Among the above listed figures, the embodiment of <FIG> corresponds to the claimed subject-matter, the other embodiments of <FIG> and <FIG> also being covered by the wording of the claims.

Embodiments herein provide a method for managing a floor request in a mission critical communication system. The method includes receiving a floor request message from a first floor participant, determining that a call type of the first floor participant is identical to a call type of a second floor participant, wherein a floor is currently occupied by the second floor participant, and managing the floor request of the first floor participant based on an effective priority of the floor request.

In an embodiment, the method for managing the floor request of the first floor participant based on the effective priority of the floor request message includes determining whether the user priority for the first floor participant and the second floor participant are available, and determining at least one of the participant type and the floor priority for the first floor participant and the second floor participant, in response to determining that the user priority for the first floor participant and the second floor participants are unavailable.

In an embodiment, the method for managing the floor request of the first floor participant based on the effective priority of the floor request includes determining whether the user priority for the first floor participant and the second floor participant is available and determining that the user priority for the first floor participant is greater than the second floor participant in response to determining that the user priority for both the first floor participant and the second floor participant is available. Further, the method includes managing the floor request of the first floor participant by overriding the floor occupied by the second floor participant in response to determining that the user priority for the first floor participant is greater than the second floor participant, and granting the floor request to the first floor participant in response to overriding the floor occupied by the second floor participant.

Further, the method also includes determining that the user priority of the second floor participant is greater than the user priority of the first floor participant and managing the floor request by performing one of queuing the floor request and denying the floor request.

Furthermore, the method also includes determining that the user priorities of the first floor participant and the second floor participant is same and detecting at least one of participant type and the floor priority for the first floor participant and the second floor participant.

In an embodiment, the method for managing the floor request of the first floor participant based on the effective priority of the floor request message includes determining whether the participant type for both the first floor participant and the second floor participant is available, and determining at least one of the user priority and the floor priority for the first floor participant and the second floor participant in response to determining that the participant type for both the first floor participant and the second floor participant is unavailable.

In an embodiment, the method for managing the floor request of the first floor participant based on the effective priority of the floor request message includes determining whether the participant type for the first floor participant and the second floor participant is available. Further, the method includes determining that the participant type is only available for the first floor participant and managing the floor request of the first floor participant by: overriding the floor occupied by the second floor participant in response to determining that the participant type is only available for the first floor participant, and granting the floor request to the first floor participant in response to overriding the floor occupied by the second floor participant. Further, the method also includes determining that the participant type is only available for the second floor participant and managing the floor request by performing one of queuing the floor request and denying the floor request. Further, the method also includes determining that the participant type for both the first floor participant and the second floor participant is available and determining a precedence of the first floor participant and the second floor.

In an embodiment, the method for determining the precedence of the first floor participant and the second floor participant includes detecting that the first floor participant precedes the second floor participant and managing the floor request message of the first floor participant by: overriding the floor occupied by the second floor participant in response to detecting that the first floor participant precedes the second floor participant, and granting the floor to the first floor participant in response to overriding the floor occupied by the second floor participant.

In an embodiment, the method for determining the precedence of the first floor participant and the second floor participant includes detecting that the second floor participant precedes the first floor participant and managing the floor request by performing one of queuing the floor request and denying the floor request.

In an embodiment, the method for determining the precedence of the first floor participant and the second floor participant includes detecting that the precedence of the first floor participant and the second floor participant is same and continuously monitoring to determine the user priority and the floor priority information associated with each of the first floor participant and the second floor participant.

In an embodiment, the method for managing the floor request of the first floor participant based on the effective priority of the floor request message includes determining whether the floor priority is available for both the first floor participant and the second floor participant. In response to detecting that the floor priority is available for both the first floor participant and the second floor participant, the method includes determining whether the floor priority of the first floor participant is greater than the floor priority of the second floor participant. Further, the method includes managing the floor request of the first floor participant by: overriding the floor occupied by the second floor participant in response to detecting that the floor priority of the first floor participant is greater than the second floor participant and granting the floor to the first floor participant in response to overriding the floor occupied by the second floor participant. Furthermore, the method includes detecting that the floor priority of the second floor participant is greater than the first floor participant and denying the floor request in response to detecting that the floor priority of the second floor participant is greater than the floor priority of the first floor participant.

In an embodiment, the method for managing the floor request of the first floor participant based on the effective priority of the floor request message includes determining the effective priority, i.e. minimum of available priority parameters such as participant type, user priority and floor priority for both the first floor participant and the second floor participant. Further, the method includes managing the floor request of the first floor participant by overriding the floor occupied by the second floor participant in response to determining that the effective priority of the first floor participant is greater than the effective priority of the second floor participant, and granting the floor request to the first floor participant in response to overriding the floor occupied by the second floor participant. Further, the method also includes determining that the effective priority is greater for the second floor participant than the first floor participant or greater for the second floor participant than the first floor participant and denying the floor request message of the first floor participant if queuing is disabled or queuing the floor request of the first floor participant if queuing is enabled.

Accordingly, embodiments herein provide a floor control server for managing a floor request in a mission critical communication system. The floor control server includes a memory and a processor configured to receive a floor request message from a first floor participant and determine that the call type of the first floor participant is identical to the call type of the second floor participant, wherein the floor is currently occupied by the second floor participant, and manage the floor request of the first floor participant based on the effective priority of the floor request, wherein the effective priority is determined based on at least one of user priority, participant type and floor priority.

Many changes and modifications may be made within the scope of the embodiments herein.

Various embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. In the following description, specific details such as detailed configuration and components are merely provided to assist the overall understanding of these embodiments of the present disclosure. Therefore, it should be apparent to those skilled in the art that various changes and modifications of the embodiments described herein can be made without departing from the scope of the present disclosure. In addition, descriptions of well-known functions and constructions are omitted for clarity and conciseness.

Herein, the term "or" as used herein, refers to a non-exclusive or, unless otherwise indicated.

As is traditional in the field, embodiments may be described and illustrated in terms of blocks which carry out a described function or functions. These blocks, which may be referred to herein as managers, units or modules or the like, are physically implemented by analog and/or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits and the like, and may optionally be driven by firmware and software. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like. The circuits constituting a block may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block. Each block of the embodiments may be physically separated into two or more interacting and discrete blocks without departing from the scope of the disclosure. Likewise, the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the disclosure.

The term "first" and "second" herein are used merely for labeling purpose and can be used interchangeably without departing from the scope of the embodiments.

The embodiments herein are adopted in <NPL>.

Accordingly the embodiments herein provide a method and system for managing a floor request in a mission critical communication system. The method includes receiving a floor request message from a first floor participant and determining that a call type of the first floor participant is identical to a call type of a second floor participant, wherein a floor is currently occupied by the second floor participant. Further, the method includes managing the floor request of the first floor participant based on an effective priority of the floor request message.

The proposed method allows the floor control server to manage the floor based on the effective priority of the user currently occupied with the floor and the effective priority of the second floor participant indicated in the floor request message.

<FIG> illustrates an architecture of a mission critical communication system <NUM> for managing the floor request, according to an embodiment as disclosed herein. The mission critical communication system <NUM> employs a floor control mechanism for managing the transmission of media i.e., MCPTT calls.

The mission critical communication system <NUM> includes a floor control server <NUM>, a first floor participant <NUM> and a second floor participant <NUM>.

In an embodiment, the first floor participant <NUM> and the second floor participant <NUM> can be for e.g., an electronic device, a User Equipment (UE), and the like.

In an embodiment the first floor participant <NUM> and the second floor participant <NUM> communicates with the floor control server <NUM> using one or more wireless network resources (<NUM>, LTE, 3GPP).

Referring to <FIG>, the floor control server <NUM> is configured to receive the floor request message from the first floor participant <NUM> requesting to grant the floor. Further, the floor control server <NUM>, upon receiving the floor request message, determines that the floor is already occupied by the second floor participant <NUM> and is not immediately available for transmission.

Furthermore, the floor control server <NUM> is configured to perform floor request management which includes multiple options as described below:.

In order to perform the option <NUM>, the floor control server <NUM> can be configured to determine the priorities of both the first floor participant <NUM> and the second floor participant <NUM>, and manage the floor request message accordingly. Accordingly, the proposed method can be used to determine the effective priority of both the first floor participant <NUM> and the second floor participant <NUM> based on multiple attributes associated with the mission critical communication system.

The attributes considered to determine the effective priority of the floor request are:.

<FIG> is a block diagram of a structure of a floor control server <NUM>, according to an embodiment as disclosed herein.

Referring to <FIG>, the floor control server <NUM> may include a memory <NUM>, a processor <NUM>, and a communicator <NUM>.

In an embodiment, the memory <NUM> may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory <NUM> may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the memory <NUM> is non-movable. In some examples, the memory <NUM> may be configured to store larger amounts of information than the memory. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache). In addition, the memory <NUM> may include storage locations configured to be addressable through the processor <NUM>.

In an embodiment, the communicator <NUM> can be configured to receive the floor request message from the first floor participant <NUM>, when the floor is currently occupied by the second floor participant <NUM>.

The processor <NUM> (for example; a hardware unit, an apparatus, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), etc.,) may be communicatively coupled to a memory <NUM>.

In an embodiment, the processor <NUM> may be configured to determine that the call type of the first floor participant <NUM> is identical to call type of the second floor participant <NUM>. Further, the processor <NUM> may be configured to manage the floor request of the first floor participant <NUM> based on the effective priority of the floor request (e.g., floor request message). The effective priority of the floor request is determined based on the attributes such as the user priority (as detailed in <FIG>), the participant type (as detailed in <FIG>) and the floor priority (as detailed in <FIG>).

<FIG> is a block diagram illustrating various units of a floor control server <NUM>, according to another embodiment as disclosed herein.

Referring to <FIG>, the floor control server <NUM> can include a communicator <NUM>, a floor control manager <NUM>, a processor <NUM> and a memory <NUM>.

In an embodiment, the communicator <NUM> can include the communicator <NUM> described in <FIG>. The communicator <NUM> can be configured to receive the floor request message from the first floor participant <NUM>, when the floor is currently occupied by the second floor participant <NUM>.

In an embodiment, the floor control manager <NUM> can be configured to determine that the call type of the first floor participant <NUM> is identical to call type of the second floor participant <NUM>. Further, the floor control manager <NUM> can be configured to manage the floor request of the first floor participant <NUM> based on the effective priority of the floor request (e.g., floor request message). The effective priority of the floor request is determined based on the attributes such as the user priority (as detailed in <FIG>), the participant type (as detailed in <FIG>) and the floor priority (as detailed in <FIG>).

The processor <NUM> (for example; a hardware unit, an apparatus, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), etc.,) communicatively coupled to a memory <NUM>(e.g., a volatile memory and/or a non-volatile memory); the memory <NUM> includes storage locations configured to be addressable through the processor <NUM>. In addition, as described in <FIG>, the floor control manager <NUM> and the processor <NUM> can be integrated into one hardware processor.

In an embodiment, the memory <NUM> may include the memory <NUM> described in <FIG>. In <FIG>, matters of the communicator <NUM> and the memory <NUM> that are the same as the described above with reference to <FIG> are not redundantly described.

<FIG> is a block diagram illustrating various units of a floor control manager <NUM>, according to an embodiment as disclosed herein.

Referring to <FIG>, the floor control manager <NUM> can include a call type identifier <NUM> and an effective priority detector <NUM>.

In an embodiment, the call type identifier <NUM> can be configured to determine that the call type indicated in the floor request message of the first floor participant <NUM> and the call type (i.e., current call type) of the second floor participant <NUM> is identical. There are multiple possible call types. In an embodiment, the following three types of calls are considered: Emergency call, Imminent Peril call and Basic call (or, Normal call).

Imminent Peril: An urgent MCPTT group call that highlights the potential of death or serious injury, but is less critical than an MCPTT Emergency Call. For example, a call prioritized in the event of immediate threat to any human life such as resulting from the MCPTT User's observation of or engagement in a situation involving imminent peril to the general public (e.g., a forest fire about to encircle campers, a tanker truck ready to explode near a school, casualties at the scene of a car bombing).

Emergency Call: An urgent MCPTT group call that highlights a grave situation like, death or serious injury. It is the most critical MCPTT call.

Effective Priority: The priority decision determined by the floor control server <NUM> based on multiple input parameters like floor priority, participant type, type of call etc. of the current floor request and of the current participant to which floor is granted if any and the local policy.

In an embodiment, the effective priority detector <NUM> may include a user priority identifier 124a, a participant type identifier 124b and a floor priority identifier 124c.

In an embodiment, the user priority identifier 124a is configured to determine the user priority of the first floor participant <NUM> and the second floor participant <NUM> which includes:.

In an embodiment, the participant type identifier 124b is configured to determine if the participant type is available for the first floor participant <NUM> and the second floor participant <NUM> which includes:.

In an embodiment, the floor priority identifier 124c of the effective priority detector <NUM> is configured to determine the floor priority of the first floor participant <NUM> and the second floor participant <NUM>, which includes:.

<FIG> is a flow diagram for managing the floor request in the mission critical communication system based on the user priority, according to an embodiment as disclosed herein.

Referring to <FIG>, at step <NUM>, the floor control server <NUM> receives the floor request message from the first floor participant <NUM>. For example, in the floor control server <NUM> as illustrated in the <FIG>, the communicator <NUM> can be configured to receive the floor request message from the first floor participant <NUM>.

At step <NUM>, the floor control server <NUM> determines that the call type of the first floor participant <NUM> is identical to the call type of the second floor participant <NUM>, where the floor is currently occupied by the second floor participant <NUM>. For example, in the floor control server <NUM> as illustrated in the <FIG>, the processor <NUM> can be configured to determine that the call type of the first floor participant <NUM> is identical to the call type of the second floor participant <NUM>.

At step <NUM>, the floor control server <NUM> determines whether the user priority is available for both the first floor participant <NUM> and the second floor participant <NUM>. On determining that the user priority is not available for both the first floor participant <NUM> and the second floor participant <NUM>, at step <NUM>, the floor control server <NUM> can be configured to detect the participant type and the floor priority information associated with the first floor participant <NUM> and the second floor participant <NUM>.

On determining that the user priority for the first floor participant <NUM> and the second floor participant <NUM> is available, at step <NUM>, the floor control server <NUM> determines whether the user priority of the first floor participant <NUM> is greater than the user priority of the second floor participant <NUM>. On determining that the user priority for the first floor participant <NUM> and the second floor participant <NUM> are the same, the floor control server <NUM>, at step <NUM>, determines at least one of participant type and floor priority for the first floor participant <NUM> and the second floor participant <NUM>.

On determining that the user priority of the first floor participant <NUM> is greater than the user priority of the second floor participant <NUM>, the floor control server <NUM>, at step <NUM>, over rides the floor occupied by the second floor participant <NUM> and grants the floor to the first floor participant <NUM>. On determining that the user priority for the first floor participant <NUM> is not greater than the second floor participant <NUM>, the floor control server <NUM>, at step <NUM>, determines whether queuing is enabled. On determining that queuing is enabled at, at step <NUM>, the floor control server <NUM> queues the floor request received from first floor participant <NUM>. On determining that queuing is not enabled at, at step <NUM>, the floor control server <NUM> denies the floor request of the first floor participant <NUM>.

<FIG> is a flow diagram for managing the floor request in the mission critical communication system based on the participant type, according to an embodiment as disclosed herein.

At step <NUM>, the floor control server <NUM> determines that the call type of the first floor participant <NUM> is identical to the call type of the second floor participant <NUM>. For example, in the floor control server <NUM> as illustrated in the <FIG>, the processor <NUM> can be configured to determine that the call type of the first floor participant <NUM> is identical to the call type of the second floor participant <NUM>. In an embodiment, the floor is currently occupied by the second floor participant <NUM>.

At step <NUM>, the floor control server <NUM> determines whether the participant type hierarchy is available for at least one of the first floor participant <NUM> and the second floor participant <NUM>. On determining that the participant type hierarchy is not available for at least one of the first floor participant <NUM> and the second floor participant <NUM>, the floor control server <NUM>, at step <NUM>, can be configured to detect the user priority and the floor priority information associated with the first floor participant <NUM> and second floor participant <NUM>.

On determining that the participant type hierarchy is available for at least one of the first floor participant <NUM> and the second floor participant <NUM>, the floor control server <NUM>, at step <NUM>, determines if the participant type hierarchy is available for both the first floor participant <NUM> and the second floor participant <NUM>. On determining that the participant type is available only for the second floor participant <NUM>, the floor control server <NUM>, at step <NUM> queues the floor request received from the first floor participant <NUM> if queuing is enabled, or denies the floor request received from the first floor participant <NUM> if queuing is not enabled. On determining that the participant type hierarchy is available only for the first floor participant <NUM>, the floor control server <NUM>, at step <NUM> over rides the floor occupied by the second floor participant <NUM> and grants the floor to first floor participant <NUM>.

On determining that the participant type hierarchy is available for both the first floor participant <NUM> and the second floor participant <NUM>, the floor control server <NUM>, at step <NUM>, determines the precedence of the first floor participant <NUM> and the second floor participant <NUM>. On determining that the second floor participant <NUM> precedes the first floor participant <NUM>, the floor control server <NUM>, at step <NUM>, queues the floor request received from the first floor participant <NUM> if queuing is enabled, or denies floor request received from the first floor participant <NUM> if queuing is not enabled. On determining that the first floor participant <NUM> precedes the second floor participant <NUM>, the floor control server <NUM>, at step <NUM>, overrides the floor occupied by the second floor participant <NUM> and grants the floor to the first floor participant <NUM>.

On determining that the precedence of the first floor participant <NUM> and the second floor participant <NUM> are the same, the floor control server <NUM>, at step <NUM>, can be configured to detect the user priority and the floor priority information associated with the first floor participant <NUM> and the second floor participant <NUM>.

<FIG> is a flow diagram for managing the floor request in the mission critical communication system based on the floor priority, according to an embodiment as disclosed herein.

At step <NUM>, the floor control server <NUM> determines that the call type of the first floor participant <NUM> is identical to the call type of the second floor participant <NUM>. For example, in the floor control server <NUM> as illustrated in the <FIG>, the processor <NUM> can be configured to determine that the call type of the first floor participant <NUM> is identical to the call type of the second floor participant <NUM>.

At step <NUM>, the floor control server <NUM> determines whether the floor priority is available for both the first floor participant <NUM> and the second floor participant <NUM>. On determining that the user priority is not available for both the first floor participant <NUM> and the second floor participant <NUM>, at step <NUM>, the floor control server <NUM> can be configured to detect the user priority and the participant type information associated with the first floor participant <NUM> and second floor participant <NUM>.

On determining that the floor priority for the first floor participant <NUM> and the second floor participant <NUM> is available, at step <NUM>, the floor control server <NUM> determines whether the floor priority of the first floor participant <NUM> is greater than the floor priority of the second floor participant <NUM>. On determining that the floor priority for the first floor participant <NUM> is same as the floor priority of the second floor participant <NUM>, the floor control server <NUM>, at step <NUM>, can be configured to detect the user priority and the participant type information associated with the first floor participant <NUM> and second floor participant <NUM>.

On determining that the floor priority of the first floor participant <NUM> is greater than the floor priority of the second floor participant <NUM>, the floor control server <NUM>, at step <NUM>, overrides the floor occupied by the second floor participant <NUM> and grants the floor to the first floor participant <NUM>. On determining that the floor priority of the first floor participant <NUM> is not greater than the floor priority of the second floor participant <NUM>, the floor control server <NUM>, at step <NUM>, determines whether queuing is enabled. On determining that queuing is enabled, at step <NUM>, the floor control server <NUM> queues the floor request from first floor participant <NUM>. On determining that queuing is not enabled at, at step <NUM>, the floor control server <NUM> denies the floor request of the first floor participant <NUM>.

<FIG> and <FIG> are flow diagrams for managing the floor request in the mission critical communication system using user priority, participant type and floor priority, according to an embodiment as disclosed herein.

Referring to <FIG>, the various attributes and the precedence order of the different attributes that can be used in determining the effective priority of the floor request are provided.

At step <NUM>, the floor control server <NUM> receives a floor request message from the first floor participant <NUM>. For example, in the floor control server <NUM> as illustrated in the <FIG>, the communicator <NUM> is configured to receive the floor request message from the first floor participant <NUM>.

At step <NUM>, the floor control server <NUM> determines whether the call type indicated in the floor request message sent by the first floor participant <NUM> is emergency. For example, in the floor control server <NUM> as illustrated in the <FIG>, the processor <NUM> is configured to determine whether the call type indicated in the floor request message sent by the first floor participant <NUM> is emergency.

On determining that the call type indicated in the floor request message is not emergency, at step <NUM>, the floor control server <NUM> determines if the call type indicated in the floor request message is imminent peril. On determining that the call type in the floor request message is not imminent peril, at step <NUM>, the floor control server <NUM> determines the call type of the second floor participant <NUM>. On determining that the call type of the second floor participant <NUM> is one of emergency or imminent peril, the floor control server <NUM>, at step <NUM>, queues the floor request from first floor participant <NUM> if queuing is enabled, or denies floor request from first floor participant <NUM> if queuing is not enabled.

On determining that the call type indicated in the floor request message is emergency, at step <NUM>, the floor control server <NUM>, determines whether the call type of the second floor participant <NUM> is emergency. On determining that the call type of the second floor participant <NUM> is not emergency, the floor control server <NUM>, at step <NUM>, overrides the second floor participant <NUM> and grants the floor to the first floor participant <NUM>.

At step <NUM>, step <NUM> and step <NUM>, on determining that the call types of both the first floor participant <NUM> and the second floor participant <NUM> are the same, the floor control server <NUM> checks for other attributes i.e., the user priority, participant type and floor priority to decide the effective priority of the floor requests.

At step <NUM>, the floor control server <NUM> determines if participant type hierarchy is available for at least one of the first floor participant <NUM> and the second floor participant <NUM>. On determining that the participant type hierarchy is not available for the first floor participant <NUM> and the second floor participant <NUM>, the floor control server <NUM> is configured to detect the user priority and the floor priority information associated with the first floor participant <NUM> and the second floor participant <NUM>.

On determining that the participant type hierarchy is available for at least one of the first floor participant <NUM> and the second floor participant <NUM>, the floor control server <NUM>, at step <NUM>, determines whether the participant type hierarchy is available for both the floor participants. On determining that the participant type hierarchy is available only for the first floor participant <NUM>, the floor control server <NUM> overrides the second floor participant <NUM> and grants the floor to first floor participant <NUM>. On determining that the participant type hierarchy is available only for the second floor participant <NUM>, the floor control server <NUM> queues the floor request from first floor participant <NUM> if queuing is enabled, or denies the floor request if queuing is not enabled.

On determining that the participant type hierarchy is available for both the floor participants, at step <NUM>, the floor control server <NUM>, compares the participant type hierarchy of both the first floor participant <NUM> and the second floor participant <NUM>. On determining that the second floor participant <NUM> precedes first floor participant <NUM>, the floor control server <NUM> queues the floor request from first floor participant <NUM> if queuing is enabled, or denies the floor request if queuing is not enabled. On determining that the first floor participant <NUM> precedes second floor participant <NUM>, the floor control server <NUM> overrides the second floor participant <NUM> and grants the floor to the first floor participant <NUM>. If the floor control server <NUM> determines that the participant type hierarchy of both the first floor participant <NUM> and the second floor participant <NUM> are the same, the floor control server <NUM> is configured to detect the user priority and the floor priority information associated with the first floor participant <NUM> and second floor participant <NUM>.

Referring to <FIG>, at step <NUM>, the floor control server <NUM> determines whether the user priority is available for the first floor participant <NUM>. On determining that the user priority is available for the first floor participant <NUM>, at step <NUM>, the floor control server <NUM> determines whether the user priority is available for the second floor participant <NUM>. On determining that the user priority is not available for the second floor participant <NUM>, the floor control server <NUM>, at step <NUM>, overrides the second floor participant <NUM> and grants the floor to the first floor participant <NUM>. On determining that the user priority is available for both the first floor participant <NUM> and the second floor participant <NUM>, the floor control server <NUM>, at step <NUM>, compares the user priority of both the floor participants. On determining that the user priority of the first floor participant <NUM> is lower than the user priority of the second floor participant <NUM>, the floor control server <NUM>, at step <NUM>, queues the floor request from the first floor participant <NUM> if queuing is enabled, or denies the floor request if queuing is not enabled.

On determining that the user priority of the first floor participant <NUM> is higher than the user priority of the second floor participant <NUM>, the floor control server <NUM>, at step <NUM>, overrides the second floor participant <NUM> and grants the floor to the first floor participant <NUM>. On determining that the user priority of the first floor participant <NUM> is same as the user priority of the second floor participant <NUM>, the floor control server <NUM>, can be configured to detect the participant type and the floor priority information associated with the first floor participant <NUM> and second floor participant <NUM>.

At step <NUM>, the floor control server <NUM> checks if the floor request message sent by the first floor participant <NUM> has the floor priority field. On determining that the floor request message doesn't have the floor priority field, the floor control server <NUM>, at step <NUM>, queues the floor request message from the first floor participant <NUM> if queuing is enabled, or denies the floor request if queuing is not enabled. On determining that the floor request message has the floor priority field, the floor control server <NUM>, at step <NUM>, determines whether the floor priority of the first floor participant <NUM> is greater than the floor priority of the second floor participant <NUM>. On determining that the floor priority of the first floor participant <NUM> is greater than the floor priority of the second floor participant <NUM>, the floor control server <NUM>, at step <NUM>,overrides the second floor participant <NUM> and grants the floor to the first floor participant <NUM>. On determining that the floor priority of the first floor participant <NUM> is not greater than the floor priority of the second floor participant <NUM>, the floor control server <NUM>, at step <NUM>, queues the floor request from the first floor participant <NUM> if queuing is enabled, or denies the floor request if queuing is not enabled.

As seen in <FIG>, <FIG>, <FIG>, <FIG>, and <FIG>, the order of the attributes i.e., user priority, participant type and floor priority can be altered. In another embodiment, the floor control server <NUM> can select the least attribute (or, the attribute having the least value) among the attributes to determine the effective priority.

<FIG> illustrate various scenarios for managing the floor request based on the effective priority, according to an embodiment as disclosed herein.

Referring to <FIG>, an example consider a scenario wherein the floor request is received from the first floor participant <NUM> i.e., MCPTT User-<NUM> when the second floor participant <NUM> has already engaged the floor i.e., MCPTT User-<NUM> is the current floor arbitrator.

In an embodiment, the MCPTT User-<NUM> makes the floor request to the floor arbitrator (i.e., the floor control server <NUM>). Firstly, the floor arbitrator determines the type of call of MCPTT User-<NUM> as imminent peril as indicated in the floor indicator field of the floor request message. Secondly, the floor arbitrator determines the type of call of MCPTT User-<NUM> as emergency. On determining that the ongoing call of MCPTT User-<NUM> is emergency call, the floor arbitrator either queues up the floor request from MCPTT User-<NUM>, if queuing is enabled, or denies the floor request to MCPTT User-<NUM> if queuing is not enabled.

Referring to <FIG>, an example consider a scenario wherein the floor request is received from MCPTT User-<NUM> when MCPTT User-<NUM> has already engaged the floor i.e., MCPTT User <NUM> is the current floor arbitrator.

The various input parameters of MCPTT User-<NUM> and MCPTT User-<NUM> are presented in Table <NUM>:.

In an embodiment, the MCPTT User-<NUM> makes the floor request to the floor arbitrator (i.e., the floor control server <NUM>). Firstly, the floor arbitrator determines the type of call of MCPTT User-<NUM> as emergency. Secondly, the floor arbitrator determines the type of call of MCPTT User-<NUM> also as emergency. On determining that the type of call of both the users is the same i.e., emergency, the floor arbitrator checks for other attributes like user priority, participant type and floor priority. On determining that user priority and participant type are also equal for both the MCPTT users, the floor arbitrator checks for the floor priority attribute. Further, the floor arbitrator determines that the floor priority of MCPTT User-<NUM> is <NUM> and the floor priority of MCPTT User-<NUM> is <NUM>. On determining that the floor priority of MCPTT User-<NUM> is greater than that of MCPTT User-<NUM>, the floor arbitrator either queues the floor request of MCPTT User-<NUM> if queuing is enabled or denies the floor request of MCPTT User-<NUM> if queuing is not enabled. The MCPTT User-<NUM> with greater floor priority continues to use the floor.

Referring to <FIG>, an example consider a scenario wherein the floor request is received from MCPTT User-<NUM> when MCPTT User-<NUM> has already engaged the floor i.e., MCPTT User-<NUM> is the current floor arbitrator.

In an embodiment, the MCPTT User-<NUM> makes the floor request to the floor arbitrator (i.e., the floor control server <NUM>). The floor arbitrator determines the type of call of MCPTT User-<NUM> is emergency and the type of call of MCPTT User-<NUM> also is emergency. On determining type of call of both the users is the same i.e., emergency, the floor arbitrator checks for other attributes like user priority, participant type and floor priority. On determining that user priority and participant type are also equal for both the users, the floor arbitrator checks for the floor priority attribute. The floor priority of MCPTT User-<NUM> is determined to be <NUM> and that of MCPTT User-<NUM> is <NUM>. On determining that the floor priority of MCPTT User-<NUM> is greater than that of MCPTT User-<NUM>, the floor arbitrator overrides the current call of MCPTT User-<NUM>, and grants the floor to MCPTT User-<NUM>, as the floor priority of MCPTT User-<NUM> is greater than the floor priority of MCPTT User-<NUM>.

The exemplary implementations disclosed herein can be implemented using at least one software program running on at least one hardware device and performing network management functions to control the elements.

Claim 1:
A method of managing, by a floor control server (<NUM>), a floor request in a Mission Critical Push To Talk, MCPTT, service, the method comprising:
receiving a floor request message from a first floor participant (<NUM>);
determining an effective priority of the floor request message based on at least one of input parameters of the floor request message and at least one of input parameters of a second floor participant (<NUM>) to which a floor is currently granted, wherein the input parameters of the floor request message and the input parameters of the second floor participant comprise at least one of a floor priority parameter, or a call type parameter; and
determining whether to grant a floor to the first floor participant (<NUM>) based on the call type parameter,
wherein the floor request is granted in case that the call type parameter of the floor request message indicates an emergency call type and the call type parameter of the second floor participant (<NUM>) indicates an imminent-peril call type or a normal call type,
wherein the floor request is queued or denied in case that the call type parameter of the floor request message indicates the normal call type and the call type parameter of the second floor participant (<NUM>) indicates the imminent-peril call type or the emergency call type,
wherein the floor request is granted in case that the call type parameter of the floor request message indicates the imminent-peril call type and the call type parameter of the second floor participant (<NUM>) indicates the normal call type,
wherein the floor request is queued or denied in case that the call type parameter of the floor request message indicates the imminent-peril call type and the call type parameter of the second floor participant (<NUM>) indicates the emergency call type, and
wherein, in case that the call type parameter of the floor request message and the call type parameter of the second floor participant (<NUM>) are same, the floor priority parameter of the floor request message and the floor priority parameter of the second floor participant (<NUM>) are compared to determine the effective priority of the floor request message.