METHOD AND APPARATUS FOR HANDLING MISSION CRITICAL SERVICES IN A WIRELESS COMMUNICATION NETWORK

Abstract

The present disclosure relates to a communication method and system for converging a 5th-Generation (5G) communication system for supporting higher data rates beyond a 4th-Generation (4G) system with a technology for Internet of Things (IoT). The present disclosure may be applied to intelligent services based on the 5G communication technology and the IoT-related technology, such as smart home, smart building, smart city, smart car, connected car, health care, digital education, smart retail, security and safety services. The present disclosure relates to a wireless communication network, and more specifically related to method and apparatus for handling mission critical service (MCS) in the wireless communication network.

Claims

1. A method for handling a mission critical service (MCS) in a wireless communication network performed by a mission critical push to talk (MCPTT) server, the method comprising: receiving, from a first MCPTT client, a floor queued cancel request message to cancel at least one queued floor request, wherein the at least one queued floor request is associated with at least one second MCPTT client; determining whether the at least one queued floor request associated with the at least one second MCPTT client is cancelled based on the received floor queued cancel request message; and performing, one of: sending a first notification to the at least one second MCPTT client that the at least one queued floor request is cancelled, or sending the first notification and a second notification to the at least one second MCPTT client that the at least one queued floor request is not cancelled.

2. The method of claim 1, further comprising: sending, to the first MCPTT client, a response message corresponding to the floor queued cancel request message based on at least one of the first notification or the second notification, wherein the response message comprises at least one of floor control queue cancel information, information for the at least one second MCPTT client, or a state of the response message, wherein the state of the response message comprises at least one of a floor taken state, a pending floor revoke state, a not-permitted and floor taken state, a not-permitted and floor idle state, or a permitted state, and wherein at least one of the first notification or the second notification comprises at least one bit indicator, the at least one bit indicator representing a message type field set value, a source field set value, an operation of a timer, information of the first MCPTT client, or a state of the at least one second MCPTT client.

3. The method of claim 1, wherein determining that the at least one queued floor request associated with the at least one second MCPTT client is cancelled based on the received floor queued cancel request message comprises: determining that the at least one queued floor request meets a predefined threshold; determining that the first MCPTT client is an authorized client, wherein the authorized client is at least one of a dispatcher, a dispatch supervisor, or a mission critical (MC) service administrator; and determining that the at least one queued floor request associated with the at least one second MCPTT client is cancelled in response to determining that the at least one queued floor request meets the predefined threshold and the first MCPTT client is the authorized client, and wherein, when the first MCPTT client is not an authorized client, further comprising performing at least one of: sending a response message comprising a response state field and a value indicating that the first MCPTT client is not the authorized client, sending the response message comprising a track information field, when the floor queued cancel request message includes the track information field, and setting a bit indicator in a response to the floor queued cancel request message, the bit indicator corresponding to an acknowledgment message.

4. The method of claim 2, wherein sending, to the first MCPTT client, the response message to the floor queued cancel request message comprises: determining whether an active floor request queue is empty; and performing at least one of: sending the response message comprising at least one of a response state field and a value indicating that the active floor request queue is empty in response to determining that the active floor request queue is empty, setting a bit indicator in the response message to the floor queued cancel request message in response to determining that the active floor request queue is empty, the bit indicator corresponding to an acknowledgment message, sending the response message comprising at least one of a response state field and a value indicating that removal of a queued floor request is success in response to determining that the active floor request queue is not empty, and sending the response message comprising a track information field, when the received floor queued cancel request message includes the track information field.

5. The method of claim 1, wherein the floor queued cancel request message comprises at least one of an identity field of the first MCPTT client, a floor queued cancel message type field, or a floor queue cancel response state field in a synchronization source (SSRC) filed.

6. The method of claim 1, wherein the floor queued cancel request message is used in an on-network mode, and wherein the floor queued cancel request message is used over a unicast bearer in the on-network mode.

7. The method of claim 1, wherein an identity field of the first MCPTT client is added when the floor queued cancel request message is originated by the first MCPTT client, wherein the identity field of the first MCPTT client is not added when the floor queued cancel request message is originated by the MCPTT server.

8. A method for handling a mission critical service (MCS) in a wireless communication network performed by a first mission critical push to talk (MCPTT) client, the method comprising: sending, to an MCPTT server, a floor queued cancel request message to cancel at least one queued floor request associated with at least one second MCPTT client; and receiving, from the MCPTT server, a response message corresponding to the floor queued cancel request message based on the floor queued cancel request message.

9. The method of claim 8, wherein the response message comprises at least one bit indicator, the at least one bit indicator representing a message type field set value, a source field set value, operation of a timer, and a state of the first MCPTT client, and wherein the state of the first MCPTT client comprises at least one no-permission state.

10. The method of claim 8, wherein receiving, from the MCPTT server, the response message corresponding to the floor queued cancel request message comprises: starting a timer indicating a period for which the floor queued cancel request message is cancelled; determining that the at least one queued floor request associated with the second MCPTT client is not cancelled upon expiry of the timer; resending the floor queued cancel request message to cancel at least one queued floor request associated with at least one second MCPTT client to the MCPTT server; and receiving the response message corresponding to the floor queued cancel request message from the MCPTT server.

11. A mission critical push to talk (MCPTT) server for handling a mission critical service (MCS) in a wireless communication network, the MCPTT server comprising: a transceiver; and a processor coupled with the transceiver and configured to: receive, from a first MCPTT client, a floor queued cancel request message to cancel at least one queued floor request, wherein the at least one queued floor request is associated with at least one second MCPTT client, determine whether the at least one queued floor request associated with the at least one second MCPTT client is cancelled based on the received floor queued cancel request message, and perform, one of: sending a first notification to the at least one second MCPTT client that the at least one queued floor request is cancelled, or sending the first notification and a second notification to the at least one second MCPTT client that the at least one queued floor request is not cancelled.

12. The MCPTT server of claim 11, wherein the processor is further configured to send, to the first MCPTT client, a response message corresponding to the floor queued cancel request message based on at least one of the first notification or the second notification, and wherein the response message comprises at least one of floor control queue cancel information, information for the at least one second MCPTT client, or a state of the response message, wherein the state of the response message comprises at least one of a floor taken state, a pending floor revoke state, a not-permitted and floor taken state, a not-permitted and floor idle state, and a permitted state, and wherein at least one of the first notification or the second notification comprises at least one bit indicator, the at least one bit indicator representing a message type field set value, a source field set value, an operation of a timer, information of the first MCPTT client, or a state of the at least one second MCPTT client.

13. The MCPTT server of claim 11, wherein the processor is further configured to: determine that the at least one queued floor request meets a predefined threshold, determine that the first MCPTT client is an authorized client, wherein the authorized client is at least one of a dispatcher, a dispatch supervisor, or a mission critical (MC) service administrator, and determine that the at least one queued floor request associated with the at least one second MCPTT client is cancelled in response to determining that the at least one queued floor request meets the predefined threshold and the first MCPTT client is the authorized client, and wherein, when the first MCPTT client is not an authorized client, the processor is further configured to at least one of: send a response message comprising a response state field and a value indicating that the first MCPTT client is not the authorized client, send the response message comprising a track information field, if the floor queued cancel request message included the track information field, and set a bit indicator in a response to the floor queued cancel request message, the bit indicator corresponding to an acknowledgment message.

14. The MCPTT server of claim 12, wherein the processor is further configured to: determine whether an active floor request queue is empty, and at least one of: send the response message comprising at least one of a response state field and a value indicating that the active floor request queue is empty in response to determining that the active floor request queue is empty, set a bit indicator in the response message to the floor queued cancel request message in response to determining that the active floor request queue is empty, the bit indicator corresponding to an acknowledgment message, send the response message comprising at least one of a response state field and a value indicating that removal of a queued floor request is success in response to determining that the active floor request queue is not empty, and send the response message comprising a track information field, if the received floor queued cancel request message includes the track information field.

15. The MCPTT server of claim 11, wherein the floor queued cancel request message comprises at least one of an identity field of the first MCPTT client, a floor queued cancel message type field, and a floor queue cancel response state field in a synchronization source (SSRC) filed.

16. The MCPTT server of claim 11, wherein the floor queued cancel request message is used in an on-network mode, and wherein the floor queued cancel request message is used over a unicast bearer in the on-network mode.

17. The MCPTT server of claim 11, wherein an identity field of the first MCPTT client is added when the floor queued cancel request message is originated by the first MCPTT client, and wherein the identity field of the first MCPTT client is not added if the floor queued cancel request message is originated by the MCPTT server.

18. A first mission critical push to talk (MCPTT) client for handling a mission critical service (MCS) in a wireless communication network, the first MCPTT client comprising: a transceiver; and a processor coupled with the transceiver and configured to: send, to an MCPTT server, a floor queued cancel request message to cancel at least one queued floor request associated with at least one second MCPTT client, and receive, from the MCPTT server, a response message corresponding to the floor queued cancel request message based on the floor queued cancel request message.

19. The first MCPTT of claim 18, wherein the response message comprises at least one bit indicator, the at least one bit indicator representing a message type field set value, a source field set value, an operation of a timer, and a state of the first MCPTT client, and wherein the state of the first MCPTT client comprises at least one no-permission state.

20. The first MCPTT of claim 18, wherein the processor is further configured to: start a timer indicating a period for which the floor queued cancel request message is cancelled, determine that the at least one queued floor request associated with the second MCPTT client is not cancelled upon expiry of the timer, resend the floor queued cancel request message to cancel at least one queued floor request associated with at least one second MCPTT client to the MCPTT server, and receive the response message corresponding to the floor queued cancel request message from the MCPTT server.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The embodiments disclosed herein are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:

[0041] FIG. 1 illustrates a wireless communication network for handling a MCS, according to embodiments as disclosed herein;

[0042] FIG. 2 illustrates various hardware components of a MCPPT server, according to embodiments as disclosed herein;

[0043] FIG. 3 illustrates various hardware components of a MCPPT client, according to embodiments as disclosed herein;

[0044] FIG. 4 is a flow chart illustrating a method, implemented by the MCPTT server, for handling the MCS in the wireless communication network, according to embodiments as disclosed herein;

[0045] FIG. 5 is a flow chart illustrating a method, implemented by the MCPTT client, for handling the MCS in the wireless communication network, according to embodiments as disclosed herein;

[0046] FIG. 6 is a sequence flow diagram illustrating step by step operations for handling the MCS in the wireless communication network, according to embodiments as disclosed herein;

[0047] FIG. 7 illustrates a format of a floor queued cancel message type field, according to embodiments as disclosed herein;

[0048] FIG. 8A illustrates a format of a list of user identifiers (IDs) field, according to embodiments as disclosed herein;

[0049] FIG. 8B describes an augmented Backus-Naur form (ABNF) syntax of string values of a user ID value, according to embodiments as disclosed herein;

[0050] FIG. 9 illustrates a format of a response state field, according to embodiments as disclosed herein; and

[0051] FIG. 10 illustrates a content of a floor queued cancel message, according to embodiments as disclosed herein.

DETAILED DESCRIPTION

[0052] FIGS. 1 through 10, discussed below, and the various embodiments used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged system or device.

[0053] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein can be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

[0054] The terms “floor queued cancel request message,” “floor queued cancel message,” “floor request cancel message” and “floor release message” are used interchangeably in the patent disclosure. The terms “floor control server,” “floor arbitrator,” and “MCPTT server” are used interchangeably in the patent disclosure.

[0055] The embodiments herein achieve methods for handling a MCS in a wireless communication network. The method includes receiving, by a MCPTT server, a floor queued cancel request message, to cancel at least one queued floor request, from a first MCPTT client. The at least one queued floor request is associated with at least one second MCPTT client. Further, the method includes determining, by the MCPTT server, whether the at least one queued floor request associated with the at least one second MCPTT client is cancelled based on the received floor queued cancel request message. Further, the method includes performing, by the MCPTT server, at least one of: sending a first notification to the at least one second MCPTT client that the at least one queued floor request is cancelled, or sending the first notification and a second notification to the at least one second MCPTT client that the at least one queued floor request is not cancelled.

[0056] The method can be used for canceling the queued floor requests of other MCPTT users from the floor control queue (i.e., floor request queue) and notifying the users of floor request being removed from the queue. The terminology “floor control queue” and “floor request queue” are used interchangeably in the patent disclosure. This allows an authorized user associated with the MCPTT client to intervene and clear the floor requests if the MCPTT server is reaching a threshold limit set by a service provider or a user of the service provider and if the MCPTT server and the authorized user associated with the MCPTT client want to hear from a particular important user who is in the queue and need immediate assistance in the wireless communication network. Hence, the method can be used to improve the user experience.

[0057] In an example, based on the provided method, once the call is established in the wireless communication network, multiple users associated with the one or more MCPTT client can request for the floor. If the floor is already granted to one user and at the same time, other users also request for the floor then the floor requests get queued and added to a floor control queue. Once the granted floor of a user request for a floor release or completes the granted time, then the next user's floor request from the queue is granted the permission to send a data (e.g., text, audio, video, media or the like). This continues until the floor queue is completely served. If an authorized user would like to clear the queued request of other users, then the request of the authorized user may be sent to remove all the stored floor requests from the queue of all the other users. The users whose queued request are being removed from the floor control queue may be notified about their removal from the queue.

[0058] Various embodiments of the provided method are adopted in the 3GPP TS 24.380.

[0059] Referring now to the drawings, and more particularly to FIGS. 1 through 10, where similar reference characters denote corresponding features consistently throughout the figures, there are shown at least one embodiment.

[0060] FIG. 1 illustrates a wireless communication network (300) for handling a MCS, according to embodiments as disclosed herein. The wireless communication network (300) can be a MCPTT network. In an embodiment, the wireless communication network (300) includes a MCPTT server (100) and one or more MCPTT client (200a-200n). The one or more MCPTT client (200a-200n) can be, for example, but not limited to a cellular phone, a smart phone, a smart watch, a personal digital assistant (PDA), a tablet computer, a laptop computer, a virtual reality device, an immersive system, an Internet of Things (IoT), a smart sensor, a drone, a vehicle or the like. The one or more MCPTT client (200a-200n) is communicated with the MCPTT server (100) and a network entity (not shown). The network entity may also include or be referred to by those skilled in the art as a base station, a base transceiver station, a radio base station, an access point, a radio transceiver, an eNB, a gNodeB (GNB), a fifth generation (5G) eNB, or the like. The one or more MCPTT client (200a-200n) communicates with the wireless communications network (300) through the network entity. The MCPTT network defines a concept of shareable MCPTT client (200a-200n). In an embodiment, the shareable MCPTT client (200a-200n) can be considered as a pool of MCPTT clients, where each MCPTT client being interchangeable with any other MCPTT responders/users (public safety (PS) agent), and MCPTT users/responders/PS agent randomly choosing one or more MCPTT client from the pool.

[0061] In general, once the call is established, multiple users associated with the one or more MCPTT client (200a-200n) can request for the floor. In an example, the MCPTT client (200n) sends a first queued floor request to the MCPTT server (100). A third MCPTT client (200c) sends a second queued floor request to the MCPTT server (100). A second MCPTT client (200n) sends a third queued floor request to the MCPTT server (100). Now, the first queued floor request, the second queued floor request and the third queued floor request are in the floor queue. Based on the present disclosure method, if an authorized user associated MCPTT client (200a) would like to clear the queued request of other users (e.g., MCPTT client (200b-200n)), then the floor queued cancel request message of the authorized user may be sent to the MCPTT server (100) to remove all the stored floor requests from the queue of all the other users. The users whose queued request are being removed from the floor control queue may be notified about their removal from the queue.

[0062] In an embodiment, the MCPTT client (200a) starts a timer (as shown in the FIG. 3) indicating a period for which the floor queued cancel request message may be cancelled. The MCPTT client (200a) determines whether the one or more queued floor request associated with the MCPTT client (200b-200n) is cancelled before expiry of the timer. If the one or more queued floor request associated with the MCPTT client (200b-200n) is not cancelled before expiry of the timer then, the MCPTT client (200a) resends the floor queued cancel request message to cancel the one or more queued floor request associated with the one or more MCPTT client (200b-200n) to the MCPTT server (100).

[0063] If the one or more queued floor request associated with the MCPTT client (200b-200n) is cancelled before expiry of the timer then, the MCPTT server (100) sends the response to the floor queued cancel request message to the MCPTT client (200a).

[0064] In an embodiment, the MCPTT server (100) sends a first notification indicated that the at least one queued floor request is cancelled to the MCPTT client (200b-200n). In another embodiment, the MCPTT server (100) sends the first notification and the second notification indicated that the at least one queued floor request is not cancelled to the MCPTT client (200b-200n).

[0065] In an embodiment, the authorized user associated with the MCPTT client (200a) instructs a floor requesting user (i.e., target user) to initiate a floor request cancel message or a floor release message. The authorized user instruction to the floor requesting user could be in-band new media burst release message (MBCP) message that is unicast relayed by the MPCTT server (100) (i.e., floor control server) to the target user or out-of-band message (e.g., via session initiation protocol (SIP) message outside of MBCP session). Further, the target user initiates the floor request cancel message or the floor release message in order to get removed from the floor request queue.

[0066] Following depicts the behavior and captures a flow of the floor queued cancel request message for better understanding in the wireless communication network (300).

[0067] According to the 3GPP TS 24.380, a list of floor control messages is listed in the table 1. In the table 1, the subclauses as referred to herein can be from existing specification (TS 3GPP 24.380 specification) or from the current document (wherever applicable).

[0068] In the table 1, for some messages, the first bit (marked as x in the subtype) can be used to indicate if a sender (e.g., MCPTT client (200a-200n)) wants to have an acknowledgment. The x is coded as follows: “0”—acknowledgment is not required, “1”—acknowledgment is required.

[0069] Whether the message needs to be acknowledged or not is described herein. If an acknowledgment is required, a floor acknowledgement message can be used to acknowledge the message.

TABLE-US-00001 TABLE 1 Message name Subtype Reference Direction Floor Request 00000 Subclause 8.2.4 Client .fwdarw. server Floor Granted x0001 Subclause 8.2.5 Server .fwdarw. client Floor Deny x0011 Subclause 8.2.6 Server .fwdarw. client Floor Release x0100 Subclause 8.2.7 Client .fwdarw. server Floor Idle x0101 Subclause 8.2.8 Server .fwdarw. client Floor Taken x0010 Subclause 8.2.9 Server .fwdarw. client Floor Revoke 00110 Subclause 8.2.10 Server .fwdarw. client Floor Queue Position 01000 Subclause 8.2.11 Client .fwdarw. server Request Floor Queue Position Info x1001 Subclause 8.2.12 Server .fwdarw. client Floor acknowledgement 01010 Subclause 8.2.13 Server .fwdarw. client (Ack) Client .fwdarw. server Floor Release Multi 01111 Subclause 8.2.14 Server .fwdarw. client Talker Floor Queued Cancel x1110 Subclause 8.2.15 Server .fwdarw. client Client .fwdarw. server The floor control server is the MCPTT server, and the floor participant is the MCPTT client.

[0070] According to the 3GPP TS 24.380, the subclause describes the floor control specific data fields. The terminology “floor queued cancel,” “floor request queue cancel,” “floor queued request cancel,” “floor queued request,” “queued floor request” cancel and any other similar terminology are used interchangeably in the patent disclosure without departing the scope of the present disclosure. The floor control messages can include floor control specific data fields contained in the application-dependent data of the floor control message. The floor control specific data fields follow the syntax specified in Table 2 lists the available floor control specific data fields including the assigned field ID.

TABLE-US-00002 TABLE 2 Field ID Field name Decimal Binary Reference Floor Priority 000 00000000 Subclause 8.2.3.2 Duration 001 00000001 Subclause 8.2.3.3 Reject Cause 002 00000010 Subclause 8.2.3.4 Queue Info 003 00000011 Subclause 8.2.3.5 Granted Party's Identity 004 00000100 Subclause 8.2.3.6 Permission to 005 00000101 Subclause 8.2.3.7 Request the Floor User ID 006 00000110 Subclause 8.2.3.8 Queue Size 007 00000111 Subclause 8.2.3.9 Message Sequence- 008 00001000 Subclause 8.2.3.10 Number Queued User ID 009 00001001 Subclause 8.2.3.11 Source 010 00001010 Subclause 8.2.3.12 Track Info 011 00001011 Subclause 8.2.3.13 Message Type 012 00001100 Subclause 8.2.3.14 Floor Indicator 013 00001101 Subclause 8.2.3.15 SSRC 014 00001110 Subclause 8.2.3.16 List of Granted Users 015 00001111 Subclause 8.2.3.17 List of SSRCs 016 00010000 Subclause 8.2.3.18 Functional Alias 017 00010001 Subclause 8.2.3.19 List of Functional 018 00010010 Subclause 8.2.3.20 Aliases Location 019 00010011 Subclause 8.2.3.21 List of Locations 020 00010100 Subclause 8.2.3.22 Floor Queued 021 00010101 Subclause 8.2.3.23 Cancel Message Type List of Users 022 00010110 Subclause 8.2.3.24 Response State 023 00010111 Subclause 8.2.3.25

[0071] In the table 2, alternatively, “list of users” field can be renamed to “list of users queued floor request” which can be further used in the floor queue cancel message. The terminology “list of users,” “list of queued users,” “cancel queued request list of users,” “list of users queued floor request,” and any other similar terminology are used interchangeably in the patent disclosure without departing the scope of the present disclosure.

[0072] The terminology “response state,” “replay state,” “notification state,” “result,” and any other similar terminology are used interchangeably in the patent disclosure without departing the scope of the present disclosure.

[0073] Floor queued cancel message type field: according to the 3GPP TS 24.380, the floor queued cancel message type field contains the type of the message requested i.e., request to cancel, cancel notification and response of request to cancel. FIG. 7 illustrates the format of the floor queued cancel message type field. The <floor queued cancel message type field ID> value is a binary value and is set (as depicted in table 2). The <floor queued cancel message type length> value is a binary value and has the value “2” indicating the total length in octets of the <floor queued cancel message type> value item. The <floor queued cancel message type> value is a 16-bit binary value with the following values: [0074] 1. “1”—cancel request, [0075] 2. “2”—response of cancel request, [0076] 3. “3”—cancel notification, and [0077] 4. All other values are reserved for future use.

[0078] List of users field: according to the 3GPP TS 24.380, the list of users field contains a list of MCPTT IDs of MCPTT users. FIG. 8a describes the format of the list of user IDs field. The <list of users field ID> value is a binary value and is set (according to the table 2). The <list of user ID length> value is a binary value and includes the value indicating the length in octets of the <list of user ids>. The <number of users> value is a binary value and includes the number of user ID entries in the list. The <user ID length> value is a binary value and includes the value indicating the length in octets of the <user ID> value item except padding. The <user ID> value is coded (as described in FIG. 8B, which describes the ABNF syntax of string values of the <User ID> value). If the length of the sum of all <user ID length> values and all <user ID> values is not (1+multiple of 4) bytes, then the sum may be padded to (1+multiple of 4) bytes. The value of the padding bytes is set to zero. The padding bytes are ignored by the MCPTT client (200a-200n).

[0079] The response state field indicates cancelation of floor requests of other MCPTT users, whose floor requests are in the floor control queue. FIG. 9 describes the format of the response state field. The <response state field ID> value is a binary value and may be set (according to table. 2). The <response state length> value is a binary value and may have the value “2” indicating the total length in octets of the <response state> value item. The <response state> value is a 16-bit binary value with the following values: [0080] 1. “0”—success, [0081] 2. “1”—fail—not authorized, [0082] 3. “2”—fail—queue is empty, [0083] 4. “3”—fail—floor request does not exist for the specified user, [0084] 5. “4”—fail—unknown reason, and [0085] 6. All other values are reserved for future use.

[0086] The floor queued cancel message is a request from a floor participant as the authorized user (If the participant type is a dispatcher, dispatch supervisor and a MC service administrator or based on configuration) to cancel the queued request of other MCPTT users. Similarly, the floor queued cancel request message is used to notify other MCPTT users of the queued request is being cancelled and to the MCPTT client (200a) (i.e., originator) of the request to indicate the status of cancelation of queued request.

[0087] The floor queued cancel message is used in an on-network mode. In the on-network mode, the floor queued cancel message is only used over a unicast bearer. FIG. 10 depicts a content of the floor queued cancel message.

[0088] With the exception of the three first 32-bit words the order of the fields is irrelevant. Subtype: the subtype is coded according to the table 1. Length: the length is coded as specified in the 3GPP TS 24.380.

[0089] Synchronization source (SSRC): A SSRC field carries the SSRC of the floor participant/floor control server/floor arbitrator. If the message is for cancelling of the queued floor request then, the SSRC may be of floor participant who is requesting for cancellation. If the message is for notifying the cancelling of queued floor request to the other floor participants or response to the message for cancelling of the queued floor request originated by a floor participant then the SSRC may be of the floor control server/floor arbitrator. The SSRC field is coded as specified in IETF RFC 3550.

[0090] Functional alias: The field may be included if the message is for cancelling of the queued floor request from the floor participant or response to the message for cancelling of the queued floor request originated by floor participant. The functional alias field is coded as described in the 3GPP TS 24.380.

[0091] Track information (info): the track Info field is included when the MCPTT call involves a non-controlling MCPTT function. The coding of a track Info field is described in the 3GPP TS 24.380

[0092] List of users queued floor request: the list of user s field is used only in sending message for cancelling of queued floor request of other MCPTT user's scenario. The list of user's field is coded as specified in the list of user's field and indicates the list of users whose request for permission to send media is queued.

[0093] Requested party's identity field: the requested party's identity field may be added only when the floor queue cancel request is originated by the floor participant user. This field may not be added if the floor queue cancel request message is originated by the floor control server (due to local policies). The field is also included in the messages for response to the message for cancelling of the queued floor request originated by floor participant. The requested party's identity field is coded as specified in the 3GPP TS 24.380.

[0094] Floor queued cancel message type field: The floor queued cancel message type field is coded as specified in the 3GPP TS 24.380.

[0095] Response state field: the response state field is included only when sending response to the message for cancelling of the queued floor request originated by floor participant. The response state field is coded as specified in the 3GPP TS 24.380.

[0096] As an alternative embodiment, a new floor queue cancel response message can be defined to send a response state and other related information back to the requester.

[0097] Send floor queued cancel request message (S: send floor queued cancel request): Upon receipt of an indication from the MCPTT client (200a) to cancel the floor requests of other MCPTT users, whose floor requests are in the floor control queue, the floor participant (i.e., first MCPTT client (200a)): [0098] 1. May send the floor queued cancel request message; [0099] 2. May start timer T134 (floor queued cancel request); and [0100] 3. Remain in the “U: has no permission” state.

[0101] It is an implementation option to handle the receipt of the floor acknowledge message and what action to take if the floor acknowledge message is not received.

[0102] Timer T134 (floor queued cancel request) expired:

[0103] On expiry of timer T134, the floor participant (i.e., first MCPTT client (200a)): [0104] 1. May provide a floor queued cancel request timeout to the first MCPTT client (i.e., 200a); [0105] 2. May remain in the “U: has no permission” state.

[0106] It is an implementation option to handle the receipt of the timer expiry event and what action to take.

[0107] Receive response to floor queued cancel request message (R: response to floor queued cancel request).

[0108] Upon receiving a response to the floor queued cancel request message, the floor participant: [0109] 1. If the first bit in the subtype of the response to the floor queued cancel request message is set to “1” (Acknowledgment is required) as described in the 3GPP standard specification, may send the floor acknowledge message. The floor acknowledge message: [0110] a. May include the message type field set to “14” (floor queued cancel request); and [0111] b. May include the source field set to “0” (the floor participant is the source); [0112] 2. May provide the result of request message to the MCPTT user; [0113] 3. May stop the timer T134 (Floor queued cancel request), if running; and [0114] 4. May remain in the “U: has no permission” state.

[0115] Send floor queued cancel request message (S: send floor queued cancel request).

[0116] Upon receipt of an indication from the MCPTT client (200a) to cancel the floor requests of other MCPTT users, whose floor requests are in floor control queue, the floor participant (i.e., MCPTT client (200a)): [0117] 1. May send the floor queued cancel request message; [0118] 2. May start timer T134 (floor queued cancel request); and [0119] 3. Remain in the “U: has permission” state.

[0120] It is an implementation option to handle the receipt of the floor acknowledge message and what action to take if the floor acknowledge message is not received.

[0121] Timer T134 (floor queued cancel request) expired:

[0122] On expiry of timer T134 (floor queued cancel request), the floor participant: [0123] 1. May provide a floor queued cancel request timeout to the MCPTT client; and [0124] 2. May remain in the “U: has permission” state.

[0125] It is an implementation option to handle the receipt of the timer expiry event and what action to take.

[0126] Receive response to floor queued cancel request message (R: response to floor queued cancel request).

[0127] Upon receiving a response to floor queued cancel request message, the floor participant: [0128] 1. If the first bit in the subtype of the response to the floor queued cancel request message is set to “1” (acknowledgment is required), may send the floor acknowledgment message. The floor acknowledgment message: [0129] a. May include the message type field set to “14” (floor queued cancel request); and [0130] b. May include the source field set to “0” (the floor participant is the source); [0131] 2. May provide the result of request message to the MCPTT user; [0132] 3. May stop the timer T134 (floor queued cancel request), if running; and [0133] 4. May remain in the “U: has permission” state.

[0134] Send floor queued cancel request message (S: send floor queued cancel request).

[0135] Upon receipt of the indication from the MCPTT client (200a) to cancel the floor requests of other MCPTT users, whose floor requests are in floor control queue, the floor participant: [0136] 1. May send the floor queued cancel request message; [0137] 2. May start timer T134 (floor queued cancel request); and [0138] 3. Remain in the “U: queued” state.

[0139] It is an implementation option to handle the receipt of the floor acknowledgment message and what action to take if the floor acknowledgment message is not received.

[0140] Timer T134 (floor queued cancel request) expired:

[0141] On expiry of timer T134, the floor participant: [0142] 1. May provide a floor queued cancel request timeout to the MCPTT client (200a); and [0143] 2. May remain in the ‘U: queued’ state.

[0144] It is an implementation option to handle the receipt of the timer expiry event and what action to take.

[0145] Receive response to floor queued cancel request message (R: response to floor queued cancel request).

[0146] Upon receiving the response to the floor queued cancel request message, the floor participant: [0147] 1. If the first bit in the subtype of the response to the floor queued cancel request message is set to “1” (acknowledgment is required), may send the floor acknowledgment message. The floor acknowledgment message: [0148] a. May include the message type field set to “14” (floor queued cancel request); and [0149] b. May include the source field set to “0” (the floor participant is the source); [0150] 2. May provide the result of request message to the MCPTT user; [0151] 3. May stop the timer T134 (floor queued cancel request), if running; and [0152] 4. May remain in the “U: queued” state.

[0153] Receive floor queued cancel notification message (R: floor queued cancel notification):

[0154] Upon receiving the floor queued cancel notification message, the floor participant: [0155] 1. If the first bit in the subtype of the floor queued cancel notification message is set to “1” (acknowledgment is required), may send the floor acknowledgment message. The floor acknowledgment message: [0156] a. May include the message type field set to “14” (floor queued cancel request); and [0157] b. May include the source field set to “0” (the floor participant is the source); [0158] 2. May provide floor queued cancel notification to the MCPTT user based on the response state field; [0159] 3. May display the user who has cancelled the floor queued request to the user using information in the requested party's identity field; [0160] 4. May stop timer T104 (floor queue position request), if running; and [0161] 5. May enter the “U: has no permission” state.

[0162] Receive floor queued cancel request message (R: floor queued cancel Request).

[0163] Upon receiving the floor queued cancel request message from the associated floor participant, the floor control arbitration procedure in the floor control server (100): [0164] 1. If the active floor request queue is empty: [0165] a. May send the response to floor queued cancel request message to the associated floor participant. The response to the floor queued cancel request: [0166] i. May include in the response state field and value as “2” (fail—queue is empty); [0167] ii. If the floor request included a track info field, may include the received track info field; [0168] b. May set the first bit in the subtype of the response to the floor queued cancel request message to “1” (Acknowledgment is required) (it is an implementation option to handle the receipt of the floor acknowledgment message and what action to take if the floor acknowledgment message is not received); and. [0169] c. May remain in the “G: floor taken” state. [0170] 2. If the active floor request queue is not empty the floor control server (100): [0171] a. May remove the queued floor request of the users identified in the list of user IDs field from the active floor request queue; [0172] b. May send the floor queued cancel notification message to the associated floor participants whose floor request has been removed from the queue and message is generated. [0173] c. May send a response to floor queued cancel request message to the associated floor participant. The response to floor queued cancel request: [0174] i. May include in the response state field and value as “0” (Success); [0175] ii. If the floor request included a track info field, may include the received track info field; [0176] d. May send a floor queue position information message to the remaining users in the active floor request queue if any, if negotiated support of queueing of floor requests. The floor queue position info message: [0177] i. May include the queue position and floor priority in the queue info field; and [0178] ii. If the floor request message included a track info field, may include the received track info field; and [0179] e. May remain in the “G: floor taken” state.

[0180] Receive floor queued cancel request message (R: floor queued cancel request).

[0181] Upon receiving the floor queued cancel request message from the associated floor participant, the floor control arbitration procedure in the floor control server (100): [0182] 1. If the active floor request queue is empty: [0183] a. May send the response to floor queued cancel request message to the associated floor participant. The response to floor queued cancel request: [0184] i. May include in the response state field and value as “2” (fail—queue is empty); [0185] ii. If the floor request included a track info field, may include the received track Info field; [0186] b. May set the first bit in the subtype of the response to the floor queued cancel request message to “1” (acknowledgment is required); and. [0187] It is an implementation option to handle the receipt of the floor acknowledgment message and what action to take if the floor acknowledgment message is not received. [0188] c. May remain in the “G: pending floor revoke” state. [0189] 2. If the active floor request queue is not empty the floor control server (100): [0190] a. May remove the queued floor request of the users identified in the list of user IDs field from the active floor request queue; [0191] b. May send the floor queued cancel notification message to the associated floor participants whose floor request has been removed from the queue and message is generated. [0192] c. May send a response to floor queued cancel request message to the associated floor participant. The response to floor queued cancel request: [0193] i. May include in the response state field and value as “0” (success); [0194] ii. If the floor request included a track info field, may include the received track info field; [0195] d. May send the floor queue position info message to the remaining users in the active floor request queue if any, if negotiated support of queueing of floor requests. The floor queue position info message: [0196] i. May include the queue position and floor priority in the queue info field; and [0197] ii. If the floor request message included a Track Info field, may include the received track info field; and [0198] e. May remain in the “G: pending floor revoke” state.

[0199] Receive floor queued cancel request message (R: floor queued cancel request).

[0200] Upon receiving the floor queued cancel request message from the associated floor participant: [0201] 1. If the MCPTT ID of the associated floor participant is authorized user (If participant type is dispatcher, dispatch supervisor and MC service administrator) to cancel the floor request of other MCPTT users, whose floor requests are in floor control queue, the floor control interface towards the MCPTT client in the floor control server (100): [0202] a. May forward the floor queued cancel request message to the floor control server arbitration procedure; and [0203] b. May remain in the “U: not permitted and floor taken” state. [0204] 2. If the MCPTT ID of the associated floor participant is not authorized user (If participant type is not dispatcher, dispatch supervisor and MC service administrator) to cancel the floor request of other MCPTT users, whose floor requests are in floor control queue, the floor control interface towards the MCPTT client in the floor control server (100): [0205] a. May send a response to floor queued cancel request message to the associated floor participant. The response to floor queued cancel request: [0206] i. May include in the response state field and value as “1” (fail—Not authorized); [0207] ii. If the floor request included a track info field, may include the received track info field; [0208] b. may set the first bit in the subtype of the response to floor queued cancel request message to “1” (acknowledgment is required); and. [0209] It is an implementation option to handle the receipt of the Floor acknowledgment message and what action to take if the Floor acknowledgment message is not received. [0210] c. may remain in the “U: not permitted and floor taken” state.

[0211] Send response to floor queued cancel request message (S: response to floor queued cancel request).

[0212] When receiving the response to floor queued cancel request message from the floor control server arbitration procedure in the MCPTT server (100), the floor control interface towards the MCPTT client in the floor control server (100): [0213] 1. May forward the response to floor queued cancel request message to the floor participant; and [0214] 2. May remain in the “U: not permitted and floor taken” state.

[0215] Send floor queued cancel notification message (S: floor queued cancel notification).

[0216] When the floor queued cancel notification message is received from the floor control arbitration procedure in the MCPTT server (100), the floor control interface towards the MCPTT client in the MCPTT server (100): [0217] 1. May forward the floor queued cancel notification messages to the associated floor participant; [0218] 2. May set the first bit in the subtype of the floor queued cancel notification message to “1” (acknowledgment is required); and

[0219] It is an implementation option to handle the receipt of the Floor acknowledgment message and what action to take if the Floor acknowledgment message is not received. [0220] 3. May remain in the “U: not permitted and floor idle” state.

[0221] Receive floor queued cancel request message (R: floor queued cancel request).

[0222] Upon receiving a floor queued cancel request message from the associated floor participant: [0223] 1. If the MCPTT ID of the associated floor participant is authorized user (If participant type is dispatcher, dispatch supervisor and MC service administrator) to cancel the floor request of other MCPTT users, whose floor requests are in floor control queue, the floor control interface towards the MCPTT client in the floor control server (100): [0224] a. May forward the floor queued cancel request message to the floor control server arbitration procedure; and [0225] b. May remain in the “U: permitted” state. [0226] 2. If the MCPTT ID of the associated floor participant is not authorized (If participant type is not dispatcher, dispatch supervisor and MC service administrator) to cancel the floor request of other MCPTT users, whose floor requests are in floor control queue, the floor control interface towards the MCPTT client in the floor control server (100): [0227] a. May send a response to floor queued cancel request message to the associated floor participant. The response to floor queued cancel request: [0228] i. May include in the response state field and value as “1” (fail—not authorized); [0229] ii. If the floor request included a track info field, may include the received track info field; [0230] b. May set the first bit in the subtype of the response to floor queued cancel request message to “1” (acknowledgment is required); and.

[0231] It is an implementation option to handle the receipt of the floor acknowledgment message and what action to take if the floor acknowledgment message is not received. [0232] c. May remain in the “U: permitted” state.

[0233] Send response to floor queued cancel request message (S: response to floor queued cancel request).

[0234] When receiving the response to floor queued cancel request message from the floor control server arbitration procedure in the MCPTT server (100), the floor control interface towards the MCPTT client in the floor control server (100): [0235] 1. May forward the response to floor queued cancel request message to the floor participant; and [0236] 2. May remain in the “U: permitted” state.

[0237] Send floor queued cancel notification message (S: floor queued cancel notification):

[0238] When the floor queued cancel notification message is received from the floor control arbitration procedure in the MCPTT server (100), the floor control interface towards the MCPTT client in the MCPTT server (100): [0239] 1. May forward the floor queued cancel notification messages to the associated floor participant; [0240] 2. May set the first bit in the subtype of the floor queued cancel notification message to “1” (acknowledgment is required); and

[0241] It is an implementation option to handle the receipt of the Floor acknowledgment message and what action to take if the floor acknowledgment message is not received. [0242] 3. May remain in the “U: permitted” state.

[0243] Timers in the on-network floor participant are as following table 3.

TABLE-US-00003 TABLE 3 Timer Timer value Cause of start Normal stop On expiry T100 Configurable as When the floor Reception of a If the counter is less than (Floor Release) specified in participant sends a Floor Idle message the upper limit of C100, a 3GPP TS 24.483. Floor Release or when the floor new Floor Release message (NOTE 1) message. participant detects is sent and counter is the receipt of RTP incremented by 1. media. When the limit in C100 is reached, the floor participant stops sending the Floor Release message. T101 Configurable as When the floor Reception of a Floor When T101 expires, a (Floor Request) specified in participant sends a Granted message, a new Floor Request 3GPP TS 24.483. Floor Request message. Floor Taken message, message is sent. (NOTE 2) T101 is also started a Floor Deny message, when the application a Floor Queue layer and signaling Position Info message plane initiates a or when the floor session as an implicit participant receives floor request using the RTP media from “mc_implicit_request” another floor as specified in participant. clause 14. T103 Should be equal Reception of a Floor The reception of a When T103 expires the (end of RTP to T1. Taken message or an Floor Idle message. floor control client media) Configurable as RTP media packet. concludes that the RTP specified in T103 is reset and media, which it was 3GPP TS 24.483. started again every started for, has time an RTP media completed. packet is received. T104 Configurable as When the floor Reception of a If the counter is less than (Floor Queue specified in participant sends a Floor Queue Position the upper limit of C104, a Position Request) 3GPP TS 24.483. Floor Queue Position Info message. new Floor Queue Position T104 shall only Request message. Leaving the ‘U: Request message is sent permit a certain queued’ state. and counter is incremented number of by 1. retransmissions When the limit in C104 is of the Floor reached, the floor Queue Position participant stops sending Request the Floor Queue Position message. Request message. T132 Default value: When the floor When a floor The floor participant (Queued granted 2 seconds. participant receives a participant in ‘U: sends a Floor Release user action) Configurable as Floor Granted queued’ state pushes message and may specified in message for a queued PTT button. indicate to the user that 3GPP TS 24.483. request. the floor is no more available T134 Default value: When the floor On receiving the Shall indicate to the user (Floor Queued 2 seconds. participant sends the response to the Floor and action can be Cancel Request) Shall be Floor Queued Cancel Queued Cancel implementation specific. implementation Request message. Request message. specific and based on local policies NOTE 1: The total time during which the floor participant retransmits the Floor Release messages shall be less than 6 seconds. NOTE 2: The total time during which the floor participant retransmits Floor Request messages should be less than 6 seconds

[0244] FIG. 2 shows various hardware components of the MCPPT server (100), according to embodiments as disclosed herein. In an embodiment, the MCPTT server (100) includes a MCS controller (110), a communicator (120), a memory (130), and a processor (140). The processor (140) is operated with the MCS controller (110), the communicator (120), and the memory (130). The MCS controller (110) is physically implemented by analog or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware.

[0245] The MCS controller (110) is configured to receive the floor queued cancel request message, to cancel the one or more queued floor request from the MCPTT client (200a). The at least one queued floor request is associated with at least one second MCPTT client (200b-200n). Based on the received floor queued cancel request message, the MCS controller (110) is configured to determine whether the one or more queued floor request associated with the one or more second MCPTT client (200b-200n) is cancelled. Based on the determination, the MCS controller (110) is configured to send the first notification to the one or more MCPTT client (200b-200n) that the one or more queued floor request is cancelled and send the first notification and the second notification to the one or more MCPTT client (200b-200n) that the one or more queued floor request is not cancelled.

[0246] In an embodiment, based on the first notification and the second notification, the MCS controller (110) is configured to send the response to the floor queued cancel request message to the MCPTT client (200a).

[0247] Further, the processor (140) is configured to execute instructions stored in the memory (130) and to perform various processes. The communicator (120) is configured for communicating internally between internal hardware components and with external devices via one or more networks. The memory (130) also stores instructions to be executed by the processor (140). The memory (130) 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 (130) 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 (130) is non-movable. 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).

[0248] Further, at least one of the plurality of modules/controllers may be implemented through an Artificial intelligence (AI) model. A function associated with AI may be performed through the non-volatile memory, the volatile memory, and the processor (140). The processor (140) may include one or a plurality of processors. At this time, one or a plurality of processors may be a general purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an AI-dedicated processor such as a neural processing unit (NPU).

[0249] The one or a plurality of processors control the processing of the input data in accordance with a predefined operating rule or artificial intelligence (AI) model stored in the non-volatile memory and the volatile memory. The predefined operating rule or artificial intelligence model is provided through training or learning.

[0250] Here, being provided through learning means that a predefined operating rule or AI model of a desired characteristic is made by applying a learning algorithm to a plurality of learning data. The learning may be performed in a device itself in which AI according to an embodiment is performed, and/o may be implemented through a separate server/system.

[0251] The AI model may comprise of a plurality of neural network layers. Each layer has a plurality of weight values, and performs a layer operation through calculation of a previous layer and an operation of a plurality of weights. Examples of neural networks include, but are not limited to, convolutional neural network (CNN), deep neural network (DNN), recurrent neural network (RNN), restricted Boltzmann machine (RBM), deep belief network (DBN), bidirectional recurrent deep neural network (BRDNN), generative adversarial networks (GAN), and deep Q-networks.

[0252] The learning algorithm is a method for training a predetermined target device (for example, a robot) using a plurality of learning data to cause, allow, or control the target device to make a determination or prediction. Examples of learning algorithms include, but are not limited to, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning.

[0253] Although the FIG. 2 shows various hardware components of the MCPPT server (100) but it is to be understood that other embodiments are not limited thereon. In other embodiments, the MCPPT server (100) may include less or a greater number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the present disclosure. One or more components can be combined together to perform same or substantially similar function in the MCPPT server (100).

[0254] FIG. 3 shows various hardware components of the MCPPT client (200), according to embodiments as disclosed herein. In an embodiment, the MCPTT client (200) includes a MCS controller (210), a communicator (220), a memory (230), a processor (240), and a timer (250). The processor (240) is operated with the MCS controller (210), the communicator (220), the memory (230) and the timer (250).

[0255] The MCS controller (210) is configured to send the floor queued cancel request message to cancel the one or more queued floor request associated with the one or more MCPTT client (200b-200n) to the MCPTT server (100). In an embodiment, after sending the floor queued cancel request message, the MCS controller (210) is configured to start the timer (250) indicating the period for which the floor queued cancel request message may be cancelled. The MCS controller (210) is configured to determine that the one or more queued floor requests associated with the MCPTT client (200b-200n) is not cancelled upon expiry of the timer (250). Based on the determination, the MCS controller (210) is configured to resend the floor queued cancel request message to cancel the one or more queued floor request associated with the one or more MCPTT client (200b-200n) to the MCPTT server (100). Based on the floor queued cancel request message, the MCS controller (210) is configured to receive the response to the floor queued cancel request message from the MCPTT server (100).

[0256] Further, the MCS controller (210) is configured to notify the transition from the first state to the second state to the MCPTT server (100) based on the response. The MCS controller (210) is physically implemented by analog or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware.

[0257] Further, the processor (240) is configured to execute instructions stored in the memory (230) and to perform various processes. The communicator (220) is configured for communicating internally between internal hardware components and with external devices via one or more networks. The memory (230) also stores instructions to be executed by the processor (240). The memory (230) 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 (230) 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 (230) is non-movable. 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).

[0258] At least one of the plurality of modules may be implemented through an Artificial intelligence (AI) model. A function associated with AI may be performed through the non-volatile memory, the volatile memory, and the processor (240). The processor (240) may include one or a plurality of processors. At this time, one or a plurality of processors may be a general purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an AI-dedicated processor such as a neural processing unit (NPU).

[0259] The one or a plurality of processors control the processing of the input data in accordance with a predefined operating rule or artificial intelligence (AI) model stored in the non-volatile memory and the volatile memory. The predefined operating rule or artificial intelligence model is provided through training or learning.

[0260] Here, being provided through learning means that a predefined operating rule or AI model of a desired characteristic is made by applying a learning algorithm to a plurality of learning data. The learning may be performed in a device itself in which AI according to an embodiment is performed, and/o may be implemented through a separate server/system.

[0261] The AI model may comprise of a plurality of neural network layers. Each layer has a plurality of weight values, and performs a layer operation through calculation of a previous layer and an operation of a plurality of weights. Examples of neural networks include, but are not limited to, convolutional neural network (CNN), deep neural network (DNN), recurrent neural network (RNN), restricted Boltzmann Machine (RBM), deep belief network (DBN), bidirectional recurrent deep neural network (BRDNN), generative adversarial networks (GAN), and deep Q-networks.

[0262] The learning algorithm is a method for training a predetermined target device (for example, a robot) using a plurality of learning data to cause, allow, or control the target device to make a determination or prediction. Examples of learning algorithms include, but are not limited to, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning.

[0263] Although the FIG. 3 shows various hardware components of the MCPPT client (200) but it is to be understood that other embodiments are not limited thereon. In other embodiments, the MCPPT client (200) may include less or a greater number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the present disclosure. One or more components can be combined together to perform same or substantially similar function in the MCPPT client (200).

[0264] FIG. 4 is a flow chart (400) illustrating a method, implemented by the MCPTT server (100), for handling the MCS in the wireless communication network (300), according to embodiments as disclosed herein. The operations (402-408) are performed by the MCS controller (110).

[0265] At 402, the method includes receiving the floor queued cancel request message, to cancel the one or more queued floor request associated with the one or more MCPTT client (200b-200n), from the MCPTT client. At 404, the method includes determining whether the one or more queued floor request associated with the one or more MCPTT client (200b-200n) is cancelled based on the received floor queued cancel request message. At 406, the method includes sending the first notification to the one or more MCPTT client (200b-200n) that the one or more queued floor request is cancelled. At 408, the method includes sending the second notification to the one or more MCPTT client (200b-200n) that the one or more queued floor request is not cancelled.

[0266] FIG. 5 is a flow chart (500) illustrating a method, implemented by the MCPTT client (200a), for handling the MCS in the wireless communication network (300), according to embodiments as disclosed herein. The operations (502 and 504) are performed by the MCS controller (210).

[0267] At 502, the method includes sending the floor queued cancel request message to cancel the one or more queued floor request associated with the one or more MCPTT client (200b-200n) to the MCPTT server (100). At 504, the method includes receiving the response to the floor queued cancel request message from the MCPTT server (100) based on the floor queued cancel request message.

[0268] The various actions, acts, blocks, steps, or the like in the flow charts (400 and 500) may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some of the actions, acts, blocks, steps, or the like may be omitted, added, modified, skipped, or the like without departing from the scope of the present disclosure.

[0269] FIG. 6 is an example sequence flow diagram illustrating step by step operations for handling the MCS in the wireless communication network (300), according to embodiments as disclosed herein. In general, once the call is established, multiple users associated with the one or more MCPTT client (200a-200n) can request for the floor. In an example, at 602a, the MCPTT client (200n) sends the first queued floor request to the MCPTT server (100). At 602b, the third MCPTT client (200c) sends the second queued floor request to the MCPTT server (100). At 602c, the second MCPTT client (200n) sends the third queued floor request to the MCPTT server (100). Now, the first queued floor request, the second queued floor request and the third queued floor request are in the floor queue. At 604, the MCPTT client (200a) sends the floor queued cancel request message to the MCPTT server (100).

[0270] At 606, the MCPTT server (100) determines that the first MCPTT client (200a) is the authorized client. At 608, the MCPTT client (200a) starts the timer (250) indicating the period for which the floor queued cancel request message may be cancelled. At 610, the MCPTT client (200a) determines whether the one or more queued floor request associated with the MCPTT client (200b-200c) is cancelled before expiry of the timer (250). If the one or more queued floor request associated with the MCPTT client (200b-200c) is not cancelled before expiry of the timer (250) then, at 612, the MCPTT client (200a) resends the floor queued cancel request message to cancel the one or more queued floor request associated with the one or more MCPTT client (200b-200c) to the MCPTT server (100).

[0271] If the one or more queued floor request associated with the MCPTT client (200b-200c) is cancelled before expiry of the timer (250) then, at 614, the MCPTT server (100) sends the response to the floor queued cancel request message from the MCPTT server (100).

[0272] At 616a, the MCPTT server (100) sends the first notification to the MCPTT client (200n). At 616b, the MCPTT server (100) sends the second notification to the MCPTT client (200c). At 616c, the MCPTT server (100) sends the third notification to the MCPTT client (200b). At 618, the MCPTT server (100) indicates the state of server (100). At 620, the MCPTT client (200a) indicates the state of client (200a).

[0273] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the elements. The elements can be at least one of a hardware device or a combination of hardware device and software module.

[0274] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of at least one embodiment, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.

[0275] Although the present disclosure has been described with various embodiments, various changes and modifications may be suggested to one skilled in the art. It is intended that the present disclosure encompass such changes and modifications as fall within the scope of the appended claims.