DESC:FORM 2
THE PATENTS ACT, 1970
[39 of 1970]
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(Section 10; Rule 13)

METHOD OF MANAGING FLOOR REQUESTS IN MISSION CRITICAL PUSH TO TALK OFF-NETWORK AND A DEVICE THEREOF

SAMSUNG R&D INSTITUTE INDIA – BANGALORE Pvt. Ltd.
# 2870, ORION Building, Bagmane Constellation Business Park,
Outer Ring Road, Doddanekundi Circle,
Marathahalli Post,
Bangalore -560037, Karnataka, India
Indian Company

The following Specification particularly describes the invention and the manner in which it is to be performed

FIELD OF THE INVENTION

The present invention generally relates to wireless communications, and more particularly relates to a method of managing floor requests in mission critical push to talk (MCPTT) off-network.

BACKGROUND OF THE INVENTION

In Mission Critical push to talk (MCPTT) off-network scenario, a MCPTT device uses a floor control protocol to control access to the floor. The floor here is the permission to transmit media. The MCPTT off-network is of ad-hoc in nature and comprise of plurality of MCPTT devices with no central floor control server. In the absence of the central floor control server, if any of the MCPTT devices wants to transmit media, the MCPTT device should assume the role of the server and control the floor. Such an MCPTT device is called as a floor arbitrator. Thus, only the floor arbitrator should be able to transmit the media. Meanwhile, if any other MCPTT devices wants to transmit media, then floor request messages will be send to the floor arbitrator. The floor arbitrator may put the floor request in queue until it completes the transmission, and once transmission is complete, the floor arbitrator grants the floor to the next device in queue.

The MCPTT off-network communication is illustrated in Figure 1A and 1B. As shown in Figure 1A, the MCPTT off-network comprises of a MCPTT device 102A, plurality of MCPTT devices B-N. At this stage, the state of all the MCPTT devices in the MCPTT off-network are in “O: Silence” state. The other states of the MCPTT device such as “O: has no permission”, “O: pending request”, and “O: has permission” are shown in Figure 3. Now assume that MCPTT device 102A wants to transmit media and sends a floor request message to all other MCPTT clients 102B-N, at step 104. The state of the MCPTT device 102A is changed to O: pending request”. The MCPTT device 102A also enables a timer T201 so as to resend the request upon the expiry of the timer T201 if no response is received from any of the other MCPTT clients 102B-N. When timer T201 expires, the MCPTT device 102A resends the floor request message and restarts the timer T201 at step 106. At step 108, the MCPTT client 102A again resends the floor request. The step of restarting the timer to resend the request is repeated for a pre-configured number of times. A counter is enabled along with the timer to calculate the number of times the timer T201 was to be restarted. The pre-configured number can have any value ranging from 1 to N. When the MCPTT device 102A does not receive any response on the expiry of the last iteration of the timer T201, the MCPTT device 102A sends a floor taken message to all other MCPTT devices at step 110 and assumes the role of the floor arbitrator. Accordingly, the state of the MCPTT device 102A is changed to “O: has permission state”. The same is illustrated in Figure 1A.

In case, if the floor arbitrator is present, the MCPTT device A will perform the steps as shown in Figure 1B. As shown in Figure 1B, the floor arbitrator is another MCPTT device 102B present in the MCPTT off-network. The MCPTT device A receives a “floor request queue status” message from the floor arbitrator 102B in response to the floor request message at step 156. Accordingly, the state of the MCPTT device A is changed from ‘pending request’ to ‘queued’. At step 158, the floor arbitrator 102B grants the floor to the MCPTT client 102A. Once the floor is granted, the MCPTT device 102A changes to the state ‘has permission’ and starts transmitting the media to all other MCPTT devices in the MCPTT off-network at step 160.

Figure 2A and 2B illustrate exemplary problem scenarios where floor request mechanism leads to plurality of floor arbitrators in a MCPTT network, according to the existing art. For example, consider that a floor request message sent by a MCPTT device 202A gets lost before it reaches to a floor arbitrator 202B, at step 204. Since, there was no response from the floor arbitrator 202B, the MCPTT device 202A resends the request for the pre-configured number of times, three times in this example. When the timer T201 expires for the last time, the MCPTT device 202A acquires the floor and becomes floor arbitrator. The MCPTT device 202A also starts transmitting the media to other MCPTT clients. Thus, the situation leads to multiple arbitrators and may results in transmission loss. The same is illustrated in Figure 2A. Similarly, a “floor request queue status” message sent by the floor arbitrator 252B may get lost before it reaches the MCPTT device 252A. Since, the MCPTT device 252A is not aware of the loss of the floor request queue status message it resends the request again. When the response is not received after making certain pre-configured attempts, the MCPTT device 252A assumes the role of floor arbitrator, leading to multiple arbitrators. The same is shown in Figure 2B.

However, there exists no solution, which avoids multiple arbitrators in the MCPTT off-network. In view of the foregoing, there is a need for a mechanism to make a more robust floor request providing better performance and reliability to the protocol.

The above mentioned shortcomings, disadvantages and problems are addressed herein and which will be understood by reading and studying the following specification.

SUMMARY OF THE INVENTION

Embodiments of the present invention are to address at least the above-mentioned problems and/or disadvantages and to provide at least the advantages described below. The various embodiments herein describe a method of managing floor requests in mission control push to talk (MCPTT) off-network. In one embodiment, the method comprising: sending, by a first MCPTT device, a floor request message for a grant of floor to a plurality of second MCPTT devices in the MCPTT off-network, wherein the first MCPTT device enables a counter to keep a track of number of times the floor request message is re-sent to the plurality of second MCPTT devices, receiving, by the first MCPTT device, media from one of the plurality of second MCPTT devices, determining, by the first MCPTT device, presence of a floor arbitrator in the MCPTT off-network when the media is received, resetting, by the first MCPTT device, value of the counter upon receiving the media so as to send floor request messages for extra number of times than the preconfigured number of times.

According to one embodiment, the floor request message is re-sent upon expiry of a timer.

According to one embodiment, the floor request is re-sent when the first MCPTT device does not receive any response from the floor arbitrator.

According to one embodiment, the counter value is initially set with a pre-configured number and decreases by 1 every time a new floor request message is sent.

According to one embodiment, the counter value is initially set with number 1 and increases by 1 every time a new floor request message is sent.

According to one embodiment, the method further comprises of increasing, by the first MCPTT device, the counter value by one whenever the floor request message is sent, determining, by the first MCPTT device, whether a floor is available when the counter value reaches a maximum value, and acquiring, by the first MCPTT device, the floor after the counter value reaches the maximum value.

Various embodiments herein further describe a mission critical push to talk device for managing floor request in a MCPTT off-network. The MCPTT device comprises of a memory unit; a timer for resending floor request message when no response is received; a counter for tracking number of times the floor request message is sent; and a processing unit operatively coupled to the memory is adapted for: sending a floor request message for a grant of floor to a plurality of MCPTT devices in the MCPTT off-network, wherein the processing unit enables a counter to keep a track of number of times the floor control request is re-sent to a plurality of MCPTT devices, receive media from one of the plurality of second MCPTT devices, determine presence of a floor arbitrator in the MCPTT off-network when the media is received, reset a counter value of the counter upon receiving the media so as to send floor request messages for extra number of times than the preconfigured number of times.

The foregoing has outlined, in general, the various aspects of the invention and is to serve as an aid to better understanding the more complete detailed description which is to follow. In reference to such, there is to be a clear understanding that the present invention is not limited to the method or application of use described and illustrated herein. It is intended that any other advantages and objects of the present invention that become apparent or obvious from the detailed description or illustrations contained herein are within the scope of the present invention.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

The other objects, features and advantages will occur to those skilled in the art from the following description of the preferred embodiment and the accompanying drawings in which:

Figure 1A and 1B are schematic diagrams illustrating exemplary communications in mission control push to talk off-network, according to the existing art.

Figure 2A and 2B illustrate exemplary problem scenarios where floor request mechanism leads to plurality of floor arbitrators in a MCPTT network, according to the existing art.

Figure 3 is a schematic diagram illustrating exemplary states of a MCPTT device, according to the existing art.

Figure 4 is a flow diagram illustrating a method of managing floor request in mission control push to talk off-network, according to one embodiment.

Figure 5 is a block diagram illustrating one or more components of a MCPTT device, according to one embodiment.

Although specific features of the present invention are shown in some drawings and not in others, this is done for convenience only as each feature may be combined with any or all of the other features in accordance with the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention describes a method of managing floor requests in mission control push to talk off-network. In the following detailed description of the embodiments of the invention, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims.

The specification may refer to “an”, “one” or “some” embodiment(s) in several locations. This does not necessarily imply that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments.

As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless expressly stated otherwise. It will be further understood that the terms “includes”, “comprises”, “including” and/or “comprising” when used in this specification, specify the presence of stated features, integers, steps, operations, elements and/or components, but do not preclude the presence or addition of one or more other features integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any and all combinations and arrangements of one or more of the associated listed items.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

The present invention provides a state machine and relevant procedures for making a more robust floor request in the MCPTT off-network. The present invention also enables a MCPTT device to determine whether there is a floor arbitrator in the MCPTT off-network before transmitting any media. This determination step is necessary to avoid multiple MCPTT clients to transmit media at the same time. Also, the existence of multiple MCPTT client results in noise and ineffective communication. Hence to address these issues, the present invention:
1. Enables a MCPTT device to re-transmit the floor request message multiple times; and
2. Enables the MCPTT device to re-transmit the floor request message for extra number of times in case presence of a floor arbitrator is determined but response to the floor request message is not received.

The present invention includes a counter C in relation to a timer T201 for keeping a check on number of floor request messages sent. Once the floor request message is sent, the state of the MCPTT client is changed to “O: pending request” and counter C is increased by a value one, every time the floor request message is sent. The counter can have a maximum value, say N, which represents minimum required number of continuous requests sent without receiving any response from other MCPTT clients. While the counter value is below N, every time media is received, the counter value resets to zero. It is also possible that the counter value is set to a preconfigured number and decreases by 1 Here, the reception of media indicates the presence of a floor arbitrator, as only floor arbitrator is supposed to transmit the media. Therefore, the floor request messages are sent repeatedly if a response to the floor request is not received thereby making the protocol more reliable.

Once the counter value reaches maximum value N, meaning that the request was sent for N times, without any response or reception of any media from the floor arbitrator, the MCPTT device assumes that there is no other device acting as floor arbitrator currently, and takes the role of the floor arbitrator. In case, if the MCPTT device receives a floor request queue status message from the floor arbitrator, the MCPTT client stops the timer T201 and changes the state to “O: queued”. On the other hand, if the MCPTT device receives a media, then MCPTT device assumes that floor arbitrator is present and waits for the reply from the Floor arbitrator. The other states of the MCPTT device are shown in Figure 3.

Figure 4 is a flow diagram illustrating a method of managing floor request in mission control push to talk off-network, according to one embodiment. As shown in Figure 4, consider that a floor arbitrator (MCPTT device 402B) is present in the MCPTT off-network and operates in a state “O: has permission”. Under this state, the floor arbitrator 402B alone is able to transmit media. Thus, no other MCPTT client including MCPTT device 402A has permission to transmit any media. Let us assume that MCPTT device A 402 wants to transmit media and sends floor request message to the floor arbitrator 404 at step 408. Automatically, the state of MCPTT device 402A moves to state O: pending request and a timer T201 is enabled.

While in the “O: pending request” state, the MCPTT device 402A checks whether a response is received upon the expiry of the timer T201. If no response is received, the MCPTT device 402A increases the counter value (T) by one, restarts timer T201 and resends the request.

In one embodiment, it is possible that a response to the floor request message that is a floor request queue status message sent by the floor arbitrator gets lost before it reaches the MCPTT device 402A. In another embodiment, the floor request message may get lost when the MCPTT device 402A sends the request, upon the expiry of timer T201. The MCPTT device 402A, not aware of the above scenarios, keeps on sending the request until the counter value (T) reaches the predetermined maximum value. Hence, the MCPTT device A resends the floor request message when the timer T201 expires, at step 410.

In one embodiment, if the MCPTT device 402A receives a media in the MCPTT off-network, then the MCPTT client determines the presence of a floor arbitrator. In some embodiments, the media received is a real time protocol (RTP) media. In other embodiments, the received media is a RTP control protocol (RTCP). Upon receiving the media, the UE resets counter C associated with Timer T201. The action of resetting the counter C enables the MCPTT device 402A to send floor request messages for extra number of times than configured number of times. This also avoids the situation of having multiple arbitrators simultaneously and helps in providing effective communication. On the contrary, if no response is received till the expiry of timer T201 for a pre-configured number of times, the MCPTT device 402A assumes that there is no floor arbitrator 402B available currently and takes the role of the floor arbitrator and acquires the floor.

In case, if the MCPTT device 402A receives a floor request queue status message 414 as response to the floor request message, the MCPTT device 402A changes the state to “O: Queued” and stops the timer T201. The MCPTT device 402A then waits for a floor grant message from the floor arbitrator 402B. In one embodiment, the MCPTT device 402A presses a push to talk button (PTT) for sending floor request messages to all other MCPTT devices in the MCPTT off-network.

Figure 5 is a block diagram illustrating one or more components of a MCPTT device 402A, according to one embodiment. As shown in Figure 5, the PTT device 500 includes a user interface 512, a communication module 506, a timer 508, a counter 510, a memory unit 504, that all are communicatively coupled to a processing unit 502. The user interface 512 includes an input unit 514 and an output unit 516. In some embodiments, the input unit 514 includes a microphone and push buttons. The output unit 516 includes a speaker and a touch screen. In some embodiments, the touch screen, for example, may form part of the input 514 and output 516.

The communication module 506 is coupled to an antenna 518 for wireless communication. The communication module 506 comprises a receiver (not shown) is configured to receive communications from the other MCPTT devices in a MCPTT off-network. The communication module 506 is further configured to receive communication from the user interface 512 and communicate information to the user interface 512 via the processing unit 502.

The particular operations/functions of processing unit 502N is determined by an execution of software instructions and routines that are stored in the memory unit 504. The memory unit 504 may be a random access memory (RAM), a dynamic random access memory (DRAM), and/or a read only memory (ROM) or equivalents thereof, that store data and programs that may be executed by the processing unit 502. The processing unit 502 also connected to the timer 508 and counter 510 in the MCPTT device 500 wherein the timer 508 is used to resend the floor request for a configured number of times when no response is received. The counter 510 is adapted to keep a track of number of times the floor request is sent to the other MCPTT devices. The processing unit 502 also monitors reception of media and resets the counter value after receiving the media. Thus, the processing unit 502 enables the MCPTT device to send floor request messages for extra number of times than the configured number of times. Thus, the current architecture of the MCPTT device 402A along with other components solves the problem of having multiple arbitrators at a single time and helps in providing effective communication.

Although the invention of the method and system has been described in connection with the embodiments of the present invention illustrated in the accompanying drawings, it is not limited thereto. It will be apparent to those skilled in the art that various substitutions, modifications and changes may be made thereto without departing from the scope and spirit of the invention.

,CLAIMS:We claim:

1. A method of managing floor requests in mission control push to talk (MCPTT) off-network, the method comprising:
sending, by a first MCPTT device, a floor request message for a grant of floor to a plurality of second MCPTT devices in the MCPTT off-network, wherein the first MCPTT device enables a counter to keep a track of number of times the floor request is re-sent to the plurality of second MCPTT devices;
receiving, by the first MCPTT device, a media from one of the plurality of second MCPTT devices;
determining, by the first MCPTT device, presence of a floor arbitrator in the MCPTT off-network when the media is received;
resetting, by the first MCPTT device, a counter value (T) of the counter upon receiving the media so as to send floor request messages for extra number of times than the preconfigured number of times.

2. The method as claimed in claim 1, wherein the floor request message is re-sent upon expiry of a timer.

3. The method as claimed in claim 1, wherein the floor request message is re-sent when the first MCPTT device does not receive any response from the floor arbitrator.

4. The method as claimed in claim 1, wherein the counter value (T) = 1. .

5. The method as claimed in claim 4, further comprising:
incrementing, by the first MCPTT device, the counter value by one whenever the floor request message is sent;
determining, by the first MCPTT device, whether a floor is available when the counter value reaches a predetermined maximum value; and
acquiring, by the first MCPTT device, the floor if the floor is available after the counter value reaches the predetermined maximum value.

6. A mission control push to talk (MCPTT) device for managing floor request in a MCPTT off-network, comprising:
a memory unit;
a timer for resending floor request message when no response is received;
a counter for tracking number of times the floor request message is sent; and
a processing unit that implements a device application function is adapted to:
send a floor request message for a grant of floor to a plurality of MCPTT devices in the MCPTT off-network, wherein the processing unit enables a counter to keep a track of number of times the floor request message is re-sent to a plurality of MCPTT devices;
receive a media from one of the plurality of second MCPTT devices;
determine presence of a floor arbitrator in the MCPTT off-network when the media is received;
reset a counter value of the counter upon receiving the media so as to send floor request messages for extra number of times than the preconfigured number of times.

Dated this the 22nd day of June 2016

Signature

KEERTHI J S
Patent agent
Agent for the applicant