Method and apparatus for processing mission-critical services in a wireless communication network

Abstract

The present disclosure relates to a communication method and system for integrating a fifth generation (5G) communication system supporting higher data rates than a fourth generation (4G) system and Internet of Things (IoT) technology. The present disclosure can be applied to smart services based on 5G communication technology and IoT-related technologies, such as smart homes, smart buildings, smart cities, smart cars, connected cars, healthcare, digital education, smart retail, and safety and security services. A method for processing mission-critical services (MCS) in a wireless communication network, performed by a mission-critical push-to-talk (MCPTT) server, is provided. The method includes receiving a voice queue cancellation request message from a first MCPTT client to cancel at least one queued voice request, wherein the at least one queued voice request is associated with at least one second MCPTT client; determining whether the at least one queued voice request associated with the at least one second MCPTT client is canceled based on the received voice queue cancellation request message; and performing one of the following operations: sending a first notification to the at least one second MCPTT client that the at least one queued voice request is canceled, or sending a first notification and a second notification to the at least one second MCPTT client that the at least one queued voice request is not canceled.

Description

Technical Field

[0001] The present disclosure relates to wireless communication networks, and more particularly, to methods and apparatus for handling mission critical services (MCS) in wireless communication networks. Background Art

[0002] In order to meet the increased demand for wireless data traffic since the deployment of 4G communication systems, efforts have been made to develop improved 5G or pre-5G communication systems. Therefore, 5G or pre-5G communication systems are also referred to as 'beyond 4G networks' or 'post-LTE systems'. 5G communication systems are considered to be implemented in higher frequency (millimeter wave) bands (e.g., 60 GHz bands) in order to achieve higher data rates. In order to reduce the propagation loss of radio waves and increase the transmission distance, beamforming, massive multiple-input multiple-output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive antenna technology are discussed in 5G communication systems. In addition, in 5G communication systems, system network improvements are being developed based on advanced small cells, cloud radio access networks (RANs), ultra-dense networks, device-to-device (D2D) communications, wireless backhaul, mobile networks, collaborative communications, coordinated multi-point (CoMP), receiving-end interference cancellation, etc. In 5G systems, hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) have been developed as advanced coded modulation (ACM), and filter bank multi-carrier (FBMC), non-orthogonal multiple access (NOMA), and sparse code multiple access (SCMA) as advanced access technologies.

[0003] The Internet, a human-centric connected network where humans generate and consume information, is evolving into the Internet of Things (IoT), in which distributed entities (such as things) exchange and process information without human intervention. The Internet of Everything (IoE), which combines IoT technology with big data processing technologies through connection to cloud servers, has emerged. Due to the technological elements required to implement the IoT, such as sensing technology, wired / wireless communication and network infrastructure, service interface technology, and security technology, sensor networks, machine-to-machine (M2M) communication, and machine-type communication (MTC) have recently been studied. Such an IoT environment can provide intelligent Internet technology services that create new value for human life by collecting and analyzing data generated between connected things. Through the convergence and integration of existing information technology (IT) and various industrial applications, the IoT can be applied in a variety of fields, including smart homes, smart buildings, smart cities, smart cars or connected vehicles, smart grids, healthcare, smart appliances, and advanced medical services.

[0004] In line with this, various attempts have been made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, machine-type communications (MTC), and machine-to-machine (M2M) communications can be implemented through beamforming, MIMO, and array antennas. Cloud radio access networks (RAN), as an application of the aforementioned big data processing technologies, can also be considered an example of the convergence between 5G and IoT technologies. Summary of the Invention

[0005] Technical issues

[0006] As the telecommunications industry continues to grow and develop, having floor handling for calls has become important to first responders. Such calls typically involve communications between multiple parties, where a single or multiple users may sometimes request the floor, and this requires appropriate handling.

[0007] In one example, a call is used with the highest priority MCS, and multiple parties may sometimes request the floor and enter a floor control queue. Sometimes, an authorized Mission Critical Push-to-Talk (MCPTT) user may request to cancel the floor requests of one or more floor participants, whose floor requests need to be removed from the floor control queue. MCS is considered critical to operations, and therefore any interruption or failure in data reception associated with this service could be catastrophic and potentially result in death, as MCS is known to prevent loss of human life and property.

[0008] As specified in the Third Generation Partnership Project Technical Specification (3GPP TS) 23.379, an MCPTT user can be an authorized user who has the right to cancel the speech requests of other MCPTT users whose speech requests are in the speech control queue, and all users are notified that their queued speech requests are being removed from the queue. Currently, there is no defined process for canceling the queued speech requests of other MCPTT users in the speech control queue and notifying the users.

[0009] Problem Solution

[0010] Therefore, an embodiment of the present invention discloses a method for processing MCS in a wireless communication network. The method includes: receiving, by an MCPTT server, a speech right queue cancellation request message from a first MCPTT client to cancel at least one queued speech right request. The at least one queued speech right request is associated with at least one second MCPTT client. In addition, the method includes, by the MCPTT server, determining whether the at least one queued speech right request associated with the at least one second MCPTT client is canceled based on the received queued speech right cancellation request message. In addition, the method includes, by the MCPTT server, performing at least one of the following operations: sending a first notification to the at least one second MCPTT client that the at least one queued speech right request is canceled, and sending a first notification and a second notification to the at least one second MCPTT client that the at least one queued speech right request is not canceled.

[0011] In one embodiment, the method further includes the MCPTT server sending a response to the conversation right queue cancellation request message to the first MCPTT client based on at least one of the first notification and the second notification, wherein the response includes at least one of conversation right control queue cancellation information, information about the at least one second MCPTT client, or a status of the response.

[0012] In one embodiment, the status of the response includes at least one of a floor taken state, a pending floor cancellation state, a not granted and floor taken state, a not granted and floor idle state, or a granted state.

[0013] In one embodiment, at least one of the first notification and the second notification includes at least one bit indicator, wherein the at least one bit indicator represents a message type field setting value, a source field setting value, an operation of a timer, information of an MCPTT client, and a status of at least one second MCPTT client.

[0014] In one embodiment, determining by the MCPTT server that at least one queued speech request associated with at least one second MCPTT client is canceled based on a received speech queue cancellation request message includes: determining that at least one queued speech request meets a predefined threshold, determining that a first MCPTT client is an authorized client, wherein the authorized client is at least one of a dispatcher, a dispatch supervisor, and a mission-critical (MC) service administrator, and in response to determining that the at least one queued speech request meets the predetermined threshold and the first MCPTT client is an authorized client, determining that at least one queued speech request associated with the at least one second MCPTT client is canceled.

[0015] In one embodiment, when the first MCPTT client is not an authorized client, the method further includes performing, by the MCPTT server, at least one of the following operations: sending a response including a response status field and a value indicating that the first MCPTT client is not an authorized client, sending a response including a tracking information field if the voice queue cancellation request message includes a tracking information field, and setting a bit indicator in a response to at least one voice queue cancellation request message, wherein the bit indicator corresponds to a confirmation message.

[0016] In one embodiment, sending a response to the at least one dequeue request message by the MCPTT server to the first MCPTT client includes determining whether an active floor request queue is empty and performing at least one of the following operations: in response to determining that the active floor request queue is empty, sending a response including at least one of a response status 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 a response to the at least one dequeue request message, wherein the bit indicator corresponds to an acknowledgment message; in response to determining that the active floor request queue is not empty, sending a response including at least one of a response status field and a value indicating that removal of the queued floor request is successful; and if the received dequeue request message includes a tracking information field, sending a response including a tracking information field.

[0017] In one embodiment, sending, by the MCPTT server, a first notification that the at least one queued floor request has been canceled to the at least one second MCPTT client includes determining that an active floor request queue is not empty, and performing at least one of the following operations: in response to determining that the active floor request queue is not empty, removing from the active floor request queue the queued floor request associated with the at least one second MCPTT client identified in the user identification list field, and in response to determining that the active floor request queue is not empty, sending a floor queue cancellation notification message to the at least one second MCPTT client, wherein the queued floor request has been removed from the queue.

[0018] In one embodiment, sending, by the MCPTT server, the first notification and the second notification that at least one queued floor request has not been canceled to at least one second MCPTT client includes determining that an active floor request queue is not empty, and in response to determining that the active floor request queue is not empty, sending, to the at least one second MCPTT client in the active floor request queue, the second notification including a floor queue position information message, wherein the floor queue position information message includes at least one of a queue position, a floor priority in the queue, and a tracking information field.

[0019] In one embodiment, the voice queue cancellation request message includes at least one of an identification field of the first MCPTT client in a synchronization source (SSRC) field, a voice queue cancellation message type field, and a voice queue cancellation response status field, wherein the SSRC field is encoded in accordance with the provisions of Internet Engineering Task Force Request for Comments (IETF RFC) 3550.

[0020] In one embodiment, the voice right dequeue request message is used in an on-network mode, wherein the voice right dequeue request message is used on a unicast bearer in the on-network mode.

[0021] In one embodiment, the tracking information field is included when the MCPTT event involves a non-control MCPTT function.

[0022] In one embodiment, when the voice queue cancellation request message is initiated by the first MCPTT client, the identification field of the first MCPTT client is added, wherein if the voice queue cancellation request message is initiated by the MCPTT server, the identification field of the first MCPTT client may not be added.

[0023] Accordingly, embodiments herein disclose a method for processing MCS in a wireless communication network. The method includes sending, by a first MCPTT client, a voice queue cancellation request message to an MCPTT server to cancel at least one queued voice request associated with at least one second MCPTT client. Furthermore, the method includes receiving, by the MCPTT client, a response to the voice queue cancellation request message from the MCPTT server based on the voice queue cancellation request message.

[0024] In one embodiment, the response includes at least one bit indicator, wherein the at least one bit indicator represents a message type field setting value, a source field setting value, an operation of a timer, and a status of the first MCPTT client, wherein the status of the first MCPTT client includes at least one of a no-permission status.

[0025] In one embodiment, a response to a conversation right queue cancellation request message received by a first MCPTT client from an MCPTT server includes: the first MCPTT client starting a timer indicating a time period during which the conversation right queue cancellation request message can be canceled; the first MCPTT client determining that at least one queued conversation right request associated with a second MCPTT client has not been canceled when the timer expires; the first MCPTT client resending a conversation right queue cancellation request message to the MCPTT server to cancel at least one queued conversation right request associated with at least one second MCPTT client; and the first MCPTT client receiving a response to the conversation right queue cancellation request message from the MCPTT server.

[0026] Accordingly, an embodiment of the present invention discloses an MCPTT server for processing MCS in a wireless communication network. The MCPTT server includes an MCS controller coupled to a memory and a processor. The MCS controller is configured to receive a voice queue cancellation request message from an MCPTT client to cancel at least one queued voice request. The at least one queued voice request is associated with at least one second MCPTT client. In addition, the MCS controller is configured to determine whether at least one queued voice request associated with the at least one second MCPTT client is canceled based on the received voice queue cancellation request message. In addition, the MCS controller is configured to send a first notification to the at least one second MCPTT client that at least one queued voice request is canceled. In addition, the MCS controller is configured to send a first notification and a second notification to the at least one second MCPTT client that at least one queued voice request is not canceled.

[0027] Accordingly, embodiments herein disclose a first MCPTT client for processing an MCS in a wireless communication network. The MCPTT includes an MCS controller coupled to a memory and a processor. The MCS controller is configured to send a voice queue cancellation request message to an MCPTT server to cancel at least one queued voice request associated with at least one second MCPTT client. Furthermore, the MCS controller is configured to receive a response to the voice queue cancellation request message from the MCPTT server based on the voice queue cancellation request message.

[0028] Advantageous Effects of the Invention

[0029] The main purpose of the embodiments herein is to disclose a method and apparatus for processing MCS in a wireless communication network.

[0030] Another object of embodiments herein is to receive, by an MCPTT server from a first MCPTT client, a floor queue cancellation request message canceling one or more queued floor requests associated with one or more second MCPTT clients.

[0031] Another object of the embodiments herein is to determine whether one or more queued floor requests associated with one or more second MCPTT clients are canceled based on a queued floor cancel request message received by the MCPTT server.

[0032] Another object of the embodiments herein is to send a first notification to one or more second MCPTT clients that one or more queued speaking rights requests are canceled by the MCPTT server.

[0033] Another object of the embodiments herein is to send a first notification and a second notification to one or more second MCPTT clients that the one or more queued floor requests have not been canceled by the MCPTT server.

[0034] Another object of the embodiments of this document is to send, by the MCPTT server, a response to a conversation right queue cancellation request message to the first MCPTT client based on the first notification and the second notification.

[0035] Another object of the embodiments herein is to start a timer that indicates a period during which the talk right queue cancellation request message can be cancelled by the first MCPTT client.

[0036] Another object of embodiments herein is to determine that one or more queued floor requests associated with a second MCPTT client have not been canceled by the first MCPTT client upon expiration of a timer.

[0037] Another object of the embodiments herein is to resend, by a first MCPTT client to an MCPTT server, a voice queue cancellation request message to cancel one or more queued voice requests associated with one or more second MCPTT clients.

[0038] These and other aspects of the embodiments herein will be better understood and appreciated when considered in conjunction with the following description and accompanying drawings. However, it should be understood that the following description, while indicating at least one embodiment and many specific details thereof, is provided by way of illustration and not limitation. Many changes and modifications may be made within the scope of embodiments of the present invention without departing from the spirit of the present invention, and embodiments of the present invention include all such modifications. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 A wireless communication network for processing MCS according to embodiments disclosed herein is shown.

[0040] Figure 2 Various hardware components of an MCPPT server according to embodiments disclosed herein are shown.

[0041] Figure 3Various hardware components of an MCPPT client according to embodiments disclosed herein are shown.

[0042] Figure 4 is a flow chart illustrating a method implemented by an MCPTT server for processing MCS in a wireless communication network according to an embodiment disclosed herein.

[0043] Figure 5 is a flow chart illustrating a method implemented by an MCPTT client for processing MCS in a wireless communication network according to an embodiment disclosed herein.

[0044] Figure 6 is a sequential flow chart illustrating step-by-step operations for processing MCS in a wireless communication network according to embodiments disclosed herein.

[0045] Figure 7 The format of the voice queue cancellation message type field according to the embodiment disclosed herein is shown.

[0046] Figure 8A The format of a user identifier (ID) list field according to embodiments disclosed herein is shown.

[0047] Figure 8B An augmented Backus-Naur Form (ABNF) grammar for a string value of a user ID value according to embodiments disclosed herein is described.

[0048] Figure 9 The format of the response status field according to the embodiments disclosed herein is shown.

[0049] Figure 10 The content of a voice right queue cancellation message according to an embodiment disclosed herein is shown. DETAILED DESCRIPTION

[0050] Before proceeding with the following detailed description, it may be helpful to set forth definitions of certain words and phrases used throughout this patent document: the terms "include" and "comprising," and their derivatives, mean inclusion without limitation; the term "or" is inclusive, meaning and / or; the phrases "associated" and "associated therewith," and their derivatives, may mean including, being included, interconnected with, containing, being contained within, connected to or with..., coupled to or with..., communicable with..., cooperating with..., interleaved, juxtaposed, proximate, being incorporated into or with..., having, having characteristics, and the like; the term "controller" refers to any device, system, or portion thereof that controls at least one operation, and such device may be implemented in hardware, firmware, or software, or some combination of at least two. It should be noted that the functionality associated with any particular controller may be centralized or distributed, whether locally or remotely.

[0051] In addition, the various functions described below can be implemented or supported by one or more computer programs, each of which is formed of a computer-readable program code and contained in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, processes, functions, objects, classes, instances, related data, or a portion thereof that is suitable for implementation with a suitable computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" includes any type of medium that can be accessed by a computer, such as a read-only memory (ROM), random access memory (RAM), hard drive, compact disc (CD), digital video disc (DVD), or any other type of memory. "Non-transient" computer-readable media does not include wired, wireless, optical, or other communication links that transmit instantaneous electrical or other signals. Non-transient computer-readable media include media that can permanently store data and media that can store data and rewrite it later, such as rewritable optical discs or erasable storage devices.

[0052] Definitions for certain words and phrases are provided in this patent document, those of ordinary skill in the art should understand that in many, if not most instances, such definitions apply to prior, as well as future uses of such defined words and phrases.

[0053] Discussed below Figures 1 to 10 The various embodiments used to describe the principles of the present disclosure in this patent document are merely exemplary and should not be interpreted in any way as limiting the scope of the present disclosure. Those skilled in the art will understand that the principles of the present disclosure can be implemented in any suitably arranged system or device.

[0054] The embodiments of this invention and their various features and advantageous details are explained more fully with reference to the non-limiting embodiments shown in the accompanying drawings and described in detail in the following description. Descriptions of known components and processing techniques are omitted to avoid unnecessarily obscuring the embodiments of this invention. The examples used herein are merely for the purpose of facilitating understanding of the manner in which the embodiments of this invention may be practiced, and further enable those skilled in the art to practice the embodiments of this invention. Therefore, these examples should not be construed as limiting the scope of the embodiments of this invention.

[0055] The terms "speech right queue cancellation request message," "speech right queue cancellation message," "speech right request cancellation message," and "speech right release message" are used interchangeably in this patent disclosure. The terms "speech right control server," "speech right arbitrator," and "MCPTT server" are used interchangeably in this patent disclosure.

[0056] Embodiments herein implement a method for processing MCS in a wireless communication network. The method includes receiving, by an MCPTT server, a speech right queue cancellation request message from a first MCPTT client to cancel at least one queued speech right request. The at least one queued speech right request is associated with at least one second MCPTT client. In addition, the method includes determining, by the MCPTT server, whether the at least one queued speech right request associated with the at least one second MCPTT client is canceled based on the received queued speech right cancellation request message. In addition, the method includes performing, by the MCPTT server, at least one of the following operations: sending a first notification to the at least one second MCPTT client that the at least one queued speech right request is canceled, or sending a first notification and a second notification to the at least one second MCPTT client that the at least one queued speech right request is not canceled.

[0057] The method can be used to cancel queued speech requests of other MCPTT users from a speech control queue (i.e., a speech request queue) and notify the user that the speech request has been removed from the queue. The terms "speech control queue" and "speech request queue" are used interchangeably in the patent disclosure. If the MCPTT server reaches a threshold limit set by the 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 a message from a specific important user who is in the queue and needs immediate assistance in the wireless communication network, this allows the authorized user associated with the MCPTT client to intervene and clear the speech request. Therefore, the method can be used to improve the user experience.

[0058] In one example, based on the provided method, once a call is established in a wireless communication network, multiple users associated with one or more MCPTT clients can request the right to speak. If the right to speak has been granted to one user and other users also request the right to speak, the right to speak request is queued and added to the right to speak control queue. Once the user who has been granted the right to speak requests to release the right to speak or completes the authorization time, the right to speak request of the next user in the queue is granted permission to send data (e.g., text, audio, video, media, etc.). This continues until the right to speak queue is fully served. If the authorized user wants to clear the requests of other users in the queue, the authorized user's request can be sent to remove all stored right to speak requests from the queues of all other users. Users whose queued requests are being removed from the right to speak control queue can be notified that they have been removed from the queue.

[0059] Various embodiments of the provided method are employed in 3GPP TS 24.380.

[0060] Referring now to the drawings and more particularly to Figures 1 to 10At least one embodiment is shown, wherein like reference numerals refer to corresponding features throughout the several views.

[0061] Figure 1 A wireless communication network (300) for processing MCS according to an embodiment disclosed herein is shown. The wireless communication network (300) may be an MCPTT network. In one embodiment, the wireless communication network (300) includes an MCPTT server (100) and one or more MCPTT clients (200a-200n). The one or more MCPTT clients (200a-200n) may 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 notebook computer, a virtual reality device, an immersive system, an Internet of Things (IoT), a smart sensor, a drone, a vehicle, etc. The one or more MCPTT clients (200a-200n) communicate 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, etc. One or more MCPTT clients (200a-200n) communicate with a wireless communication network (300) through a network entity. The MCPTT network defines the concept of shareable MCPTT clients (200a-200n). In one embodiment, the shareable MCPTT clients (200a-200n) can be considered as a pool of MCPTT clients, where each MCPTT client can be exchanged with any other MCPTT respondent / user (public safety (PS) agent), and the MCPTT user / respondent / PS agent randomly selects one or more MCPTT clients from the pool.

[0062] Typically, once a call is established, multiple users associated with one or more MCPTT clients (200a-200n) can request a voice call. In one example, an MCPTT client (200n) sends a first queued voice call request to an MCPTT server (100). A third MCPTT client (200c) sends a second queued voice call request to an MCPTT server (100). A second MCPTT client (200n) sends a third queued voice call request to an MCPTT server (100). Now, the first queued voice call request, the second queued voice call request, and the third queued voice call request are in a voice call queue. Based on the method of the present disclosure, if an authorized user associated with an MCPTT client (200a) wants to clear queued requests of other users (e.g., MCPTT clients (200b-200n)), a voice call queue cancellation request message of the authorized user can be sent to the MCPTT server (100) to remove all stored voice call requests from the queues of all other users. Users whose queued requests are being removed from the floor control queue may be notified that they have been removed from the queue.

[0063] In one embodiment, the MCPTT client (200a) starts a timer (e.g. Figure 3 The MCPTT client (200a) determines whether one or more queued speech requests associated with the MCPTT client (200b-200n) are canceled before the timer expires. If the one or more queued speech requests associated with the MCPTT client (200b-200n) are not canceled before the timer expires, the MCPTT client (200a) resends the speech queue cancellation request message to the MCPTT server (100) to cancel the one or more queued speech requests associated with the one or more MCPTT clients (200b-200n).

[0064] If one or more queued voice requests associated with the MCPTT client (200b-200n) are canceled before the timer expires, the MCPTT server (100) sends a response of a voice queue cancel request message to the MCPTT client (200a).

[0065] In one embodiment, the MCPTT server (100) sends a first notification to the MCPTT client (200b-200n) indicating that at least one queued speech request is canceled. In another embodiment, the MCPTT server (100) sends the first notification and a second notification to the MCPTT client (200b-200n) indicating that at least one queued speech request is not canceled.

[0066] In one embodiment, an authorized user associated with an MPCTT client (200a) instructs a user requesting the right to speak (i.e., a target user) to initiate a talk request cancellation message or a talk release message. The authorized user instruction to the user requesting the right to speak can be an in-band new media burst release message (MBCP) unicast relayed to the target user by an MPCTT server (100) (i.e., a talk control server), or an out-of-band message (e.g., a Session Initiation Protocol (SIP) message outside of an MBCP session). In addition, the target user initiates the talk request cancellation message or the talk release message to remove the target user from the talk request queue.

[0067] For better understanding in the wireless communication network (300), the following describes the behavior and records the flow of the voice queue cancellation request message.

[0068] According to 3GPP TS 24.380, a list of voice control messages is listed in Table 1. In Table 1, the sub-clauses mentioned herein may be from the existing specification (TS 3GPP 24.380 specification) or from the current document (as long as applicable).

[0069] In Table 1, for some messages, the first bit (marked as x in the subtype) can be used to indicate whether the sender (e.g., MCPTT client (200a-200n)) wants acknowledgment. x is encoded as follows: "0" - no acknowledgment required, "1" - acknowledgment required.

[0070] This document describes whether a message needs to be confirmed. If confirmation is required, the message can be confirmed using the right-to-confirm message.

[0071]

Table 1

[0072]

[0073]

[0074] According to 3GPP TS 24.380, a subclause describes the voice control specific data field. The terms "voice queue cancellation," "voice request queue cancellation," "voice queue request cancellation," "voice queue request," "queue voice request" cancellation, and any other similar terms may be used interchangeably in this patent disclosure without departing from the scope of this disclosure. A voice control message may include a voice control specific data field included in the application-related data of the voice control message. The voice control specific data field follows the syntax specified in Table 2. Table 2 lists the available voice control specific data fields, including the assigned field ID.

[0075]

Table 2

[0076]

[0077]

[0078]

[0079] In Table 2, the "User List" field can alternatively be renamed "List of Users with Queued Speech Right Requests," which can be further used in a speech right queue cancellation message. The terms "user list," "queued user list," "user's cancellation queue request list," "list of users with queued speech right requests," and any other similar terms may be used interchangeably in this patent disclosure without departing from the scope of this disclosure.

[0080] The terms "response state," "reply state," "notification state," "result," and any other similar terms may be used interchangeably in the patent disclosure without departing from the scope of the present disclosure.

[0081] Speech Right Queue Cancel Message Type field: According to 3GPP TS 24.380, the Speech Right Queue Cancel Message Type field contains the type of message requested, namely, cancellation request, cancellation notification, and response to cancellation request. Figure 7 The format of the Speech Queue Cancel Message Type field is shown. The <Speech Queue Cancel Message Type Field ID> value is a binary value and is set (as shown in Table 2). The <Speech Queue Cancel Message Type Length> value is a binary value and has a value of "2", indicating the total length of the <Speech Queue Cancel Message Type> value item in octets. The <Speech Queue Cancel Message Type> value is a 16-bit binary value with the following values:

[0082] 1. "1" - cancel the request,

[0083] 2. "2" - response to cancel request,

[0084] 3. “3” - Notice of Cancellation, and

[0085] 4. All other values ​​are reserved for future use.

[0086] User List Field: According to 3GPP TS 24.380, the User List Field contains a list of MCPTT IDs of MCPTT users. Figure 8ADescribes the format of the User ID List field. The <User List Field ID> value is a binary value and is set (according to Table 2). The <User ID List Length> value is a binary value and includes a value indicating the length of the <User ID List> in eight bits. 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 a value indicating the length of the <User ID> value item in eight bits, excluding padding. The <User ID> value is encoded (as Figure 8B (As described in

[0014] , which describes the ABNF syntax for the string value of the <UserID> value). If the length of all <UserIDLength> values ​​and the sum of all <UserID> values ​​is not a multiple of (1+4) bytes, then the sum may be padded to (a multiple of) bytes. The value of the padding bytes is set to zero. The MCPTT client (200a-200n) ignores the padding bytes.

[0087] The response status field indicates the cancellation of the speaking right request of other MCPTT users whose speaking right requests are in the speaking right control queue. Figure 9 Describes the format of the Response Status field. The <Response Status Field ID> value is a binary value and can be set (according to Table 2). The <Response Status Length> value is a binary value and can have a value of "2" to indicate the total length of the <Response Status> value item in octets. The <Response Status> value is a 16-bit binary value containing the following values:

[0088] 1. "0" - success,

[0089] 2. "1" - Failed - Unauthorized,

[0090] 3. "2" - Failure - Queue is empty,

[0091] 4. "3" - Failed - The voice request for the specified user does not exist.

[0092] 5. "4" - Failure - Unknown reason, and

[0093] 6. All other values ​​are reserved for future use.

[0094] The talk queue cancel message is a request from a talk right participant who is an authorized user (if the participant type is dispatcher, dispatch supervisor and MC service administrator or based on configuration) to cancel the queue request of other MCPTT users. Similarly, the talk queue cancel request message is used to notify other MCPTT users that the queue request is being canceled and to notify the requesting MCPTT client (200a) (i.e., the initiator) to indicate the cancellation status of the queue request.

[0095] The voice queue cancellation message is used in networking mode. In networking mode, the voice queue cancellation message is used only on unicast bearers. Figure 10 Describes the content of the voice queue cancellation message.

[0096] Except for the first three 32-bit words, the order of the fields is not significant. Subtype: The subtype is encoded according to Table 1. Length: The length is encoded as specified in 3GPP TS 24.380.

[0097] Synchronization Source (SSRC): The SSRC field carries the SSRC of the floor participant / floor control server / floor arbitrator. If this message is used to cancel a queued floor request, the SSRC may be the SSRC of the floor participant requesting the cancellation. If this message is used to notify other floor participants of the cancellation of a queued floor request, or is a response to a message requesting the cancellation of a queued floor request initiated by a floor participant, the SSRC may be the SSRC of the floor control server / floor arbitrator. The SSRC field is encoded according to IETF RFC 3550.

[0098] Function Alias: This field may be included if the message is used to cancel a queued floor request from a floor participant, or is a response to a message used to cancel a queued floor request initiated by a floor participant. The Function Alias ​​field is encoded as described in 3GPP TS 24.380.

[0099] Tracking Information (info): When the MCPTT call involves a non-control MCPTT function, the Tracking Information field is included. The coding of the Tracking Information field is described in 3GPP TS 24.380.

[0100] List of users whose requests for permission to send media are queued: The User List field is used only to send a message to cancel the queued requests for permission to send media from other MCPTT users. The User List field is encoded as specified in the User List field and indicates a list of users whose requests for permission to send media are queued.

[0101] Requested Party Identification Field: The Requested Party Identification field is added only when the call queue cancellation request is initiated by the call participant user. If the call queue cancellation request message is initiated by the call control server (due to local policy), this field may not be added. This field is also included in the message used to respond to the message used to cancel the queued call request initiated by the call participant. The Requested Party Identification field is encoded according to the specifications in 3GPP TS 24.380.

[0102] The voice queue cancellation message type field: The voice queue cancellation message type field is encoded according to the provisions of 3GPP TS24.380.

[0103] Response Status Field: The Response Status Field is included only when sending a response to a message used to cancel a queued speaking right request initiated by a speaking right participant. The Response Status Field is encoded as specified in 3GPP TS 24.380.

[0104] As an alternative embodiment, a new voice queue cancellation response message may be defined to send the response status and other relevant information back to the requesting party.

[0105] Send a talk queue cancellation request message (S: Send talk queue cancellation request): When receiving an instruction from the MCPTT client (200a) to cancel the talk request of other MCPTT users whose talk requests are in the talk control queue, the talk participant (i.e., the first MCPTT client (200a)):

[0106] 1. You can send a request message to cancel the voice queue;

[0107] 2. Timer T134 (voice queue cancellation request) may be started; and

[0108] 3. Keep the status of "U: No permission".

[0109] Handling the receipt of a floor confirm message and what action to take if a floor confirm message is not received is an implementation option.

[0110] Timer T134 (voice queue cancellation request) expires:

[0111] When the timer T134 expires, the participant with the speaking right (i.e., the first MCPTT client (200a)):

[0112] 1. A timeout of a talk queue cancellation request may be provided to the first MCPTT client (i.e., 200a);

[0113] 2. It can remain in the "U: No Permission" state.

[0114] Handling the receipt of a timer expiration event and what action to take is an implementation option.

[0115] A response to the dialog right queue cancellation request message is received (R: response to the dialog right queue cancellation request).

[0116] When receiving a response to a conversation right queue cancellation request message, the conversation right participant:

[0117] 1. If the first bit in the subtype of the response to the right-to-talk queue cancellation request message is set to "1" (confirmation required) as described in the 3GPP standard specification, a right-to-talk confirmation message can be sent.

[0118] > a. May include a message type field set to "14" (voice queue cancellation request); and

[0119] > b. may include a source field set to "0" (the speaker is the source);

[0120] 2. The result of the request message can be provided to the MCPTT user;

[0121] 3. If timer T134 is running, timer T134 may be stopped (voice right queue cancellation request); and

[0122] 4. It can remain in the "U: No Permission" state.

[0123] Send a talk right queue cancellation request message (S: Send talk right queue cancellation request).

[0124] When receiving an instruction from the MCPTT client (200a) to cancel the speech request of other MCPTT users whose speech request is in the speech control queue, the speech participant (i.e., the MCPTT client (200a)):

[0125] 1. You can send a request message to cancel the voice queue;

[0126] 2. Timer T134 (voice queue cancellation request) may be started; and

[0127] 3. Maintain the "U: With License" status.

[0128] Handling the receipt of a floor confirm message and what action to take if a floor confirm message is not received is an implementation option.

[0129] Timer T134 (voice queue cancellation request) expires:

[0130] When timer T134 expires (speech right queue cancellation request), the speech right participant:

[0131] 1. It can provide the MCPTT client with a timeout for canceling the right-to-talk queue request;

[0132] 2. You can remain in the "U: With License" state.

[0133] Handling the receipt of a timer expiration event and what action to take is an implementation option.

[0134] A response to the dialog right queue cancellation request message is received (R: response to the dialog right queue cancellation request).

[0135] Upon receiving a response to a conversation right queue cancellation request message, the conversation right participant:

[0136] 1. If the first bit in the subtype of the response to the conversation queue cancellation request message is set to "1" (confirmation required), a conversation confirmation message may be sent. Confirmation message:

[0137] > a. May include a message type field set to "14" (voice queue cancellation request); and

[0138] > b. may include a source field set to "0" (the speaker is the source);

[0139] 2. The result of the request message can be provided to the MCPTT user;

[0140] 3. If timer T134 is running, timer T134 may be stopped (voice right queue cancellation request); and

[0141] 4. You can remain in the "U: With License" status.

[0142] Send a talk right queue cancellation request message (S: Send talk right queue cancellation request).

[0143] When receiving an instruction from the MCPTT client (200a) to cancel the speaking right request of other MCPTT users whose speaking right request is in the speaking right control queue, the speaking right participant:

[0144] 1. You can send a request message to cancel the voice queue;

[0145] 2. Timer T134 (voice queue cancellation request) may be started; and

[0146] 3. Maintain the "U: Queue" status.

[0147] Handling the receipt of a floor confirm message and what action to take if a floor confirm message is not received is an implementation option.

[0148] Timer T134 (voice queue cancellation request) expires:

[0149] When timer T134 expires, the participant with the speaking right:

[0150] 1. A timeout of a talk queue cancellation request can be provided to the MCPTT client (200a); and

[0151] 2. You can stay in the "U: Queue" state.

[0152] Handling the receipt of a timer expiration event and what action to take is an implementation option.

[0153] A response to the dialog right queue cancellation request message is received (R: response to the dialog right queue cancellation request).

[0154] Upon receiving a response to a conversation right queue cancellation request message, the conversation right participant:

[0155] 1. If the first bit in the subtype of the response to the conversation queue cancellation request message is set to "1" (confirmation required), a conversation confirmation message may be sent. Confirmation message:

[0156] > a. May include a message type field set to "14" (voice queue cancellation request); and

[0157] > b. may include a source field set to "0" (the speaker is the source);

[0158] 2. The result of the request message can be provided to the MCPTT user;

[0159] 3. If timer T134 is running, timer T134 may be stopped (voice right queue cancellation request); and

[0160] 4. You can stay in the "U: Queue" state.

[0161] Receive the voice queue cancellation notification message (R: Voice queue cancellation notification):

[0162] Upon receiving the talk queue cancellation notification message, the talk right participant:

[0163] 1. If the first bit in the subtype of the voice queue cancellation notification message is set to "1" (confirmation required), a voice confirmation message can be sent. Voice confirmation message:

[0164] > a. May include a message type field set to "14" (voice queue cancellation request); and

[0165] > b. may include a source field set to "0" (the speaker is the source);

[0166] 2. A notification of voice queue cancellation can be provided to the MCPTT user based on the response status field;

[0167] 3. The information in the requested party's identification field can be used to indicate to the user the user who has canceled the talk queue request;

[0168] 4. If timer T104 is running, timer T104 (voice queue position request) may be stopped; and

[0169] 5. You can enter the "U: No Permission" state.

[0170] Receive a talk right queue cancellation request message (R: talk right queue cancellation request).

[0171] When receiving a speech right queuing cancellation request message from an associated speech right participant, the speech right control arbitration process in the speech right control server (100):

[0172] 1. If the active voice request queue is empty:

[0173] >a. A response to the conversation queue cancellation request message may be sent to the associated conversation right participant. Response to the conversation queue cancellation request:

[0174] >>i. MAY be included in the Response Status field and have a value of "2" (Failed - Queue Empty);

[0175] >>ii If the right to speak request includes a tracking information field, you may include the received tracking information field;

[0176] > b can be the first bit of the subtype of the response to the conversation queue cancellation request message is set to "1" (confirmation required) (handling the reception of the conversation confirmation message and what action will be taken if the conversation confirmation message is not received is an implementation option); and

[0177] >c. You can remain in the "G: Speech Right Occupied" state.

[0178] 2. If the active speech request queue is not empty, the speech control server (100):

[0179] > a can be removed from the active right to speak request queue in the user ID list field identified in the queue right to speak request;

[0180] > b. A voice queue cancellation notification message may be sent to the associated voice participant whose voice request has been removed from the queue and for which the message was generated.

[0181] >c. A response to the conversation queue cancellation request message may be sent to the associated conversation right participant. Response to the conversation queue cancellation request:

[0182] >>i. May be included in the response status field and have a value of "0" (success);

[0183] >>ii If the right to speak request includes a tracking information field, you may include the received tracking information field;

[0184] >d. If the negotiation supports queuing of speech request, a speech queue position information message may be sent to the remaining users (if any) in the active speech request queue. Speech queue position information message:

[0185] >>i may include queue position and voice priority in the queue information field; and

[0186] >>ii If the right to speak request message includes a tracking information field, you may include the received tracking information field; and

[0187] >e. The state of "G: Speech Right Occupied" can be maintained.

[0188] Receive a talk right queue cancellation request message (R: talk right queue cancellation request).

[0189] When receiving a speech right queuing cancellation request message from an associated speech right participant, the speech right control arbitration process in the speech right control server (100):

[0190] 1. If the active voice request queue is empty:

[0191] >a. A response to the conversation queue cancellation request message may be sent to the associated conversation right participant. Response to the conversation queue cancellation request:

[0192] >>i. MAY be included in the Response Status field and have a value of "2" (Failed - Queue Empty);

[0193] >>ii If the right to speak request includes a tracking information field, you may include the received tracking information field;

[0194] > b can be the first bit of the subtype of the response to the conversation right queue cancellation request message is set to "1" (confirmation required); and

[0195] Handling the receipt of a floor confirm message and what action to take if a floor confirm message is not received is an implementation option.

[0196] >c. You can remain in the "G: Pending call cancellation" state.

[0197] 2. If the active speech request queue is not empty, the speech control server (100):

[0198] > a can be removed from the active right to speak request queue in the user ID list field identified in the queue right to speak request;

[0199] > b. A voice queue cancellation notification message may be sent to the associated voice participant whose voice request has been removed from the queue and for which the message was generated.

[0200] >c. A response to the conversation queue cancellation request message may be sent to the associated conversation right participant. Response to the conversation queue cancellation request:

[0201] >>i. May be included in the response status field and have a value of "0" (success);

[0202] >>ii If the right to speak request includes a tracking information field, you may include the received tracking information field;

[0203] >d. If the negotiation supports queuing of speech request, a speech queue position information message may be sent to the remaining users (if any) in the active speech request queue. Speech queue position information message:

[0204] >>i may include queue position and voice priority in the queue information field; and

[0205] >>ii If the right to speak request message includes a tracking information field, you may include the received tracking information field; and

[0206] >e. You can remain in the "G: Pending call cancellation" state.

[0207] Receive a talk right queue cancellation request message (R: talk right queue cancellation request).

[0208] When receiving a talk right queue cancellation request message from the associated talk right participant:

[0209] 1. If the MCPTT ID of the associated speaking right participant is an authorized user who cancels the speaking right request of other MCPTT users whose speaking right request is in the speaking right control queue (if the participant type is dispatcher, dispatch supervisor and MC service administrator), then the speaking right control interface facing the MCPTT client in the speaking right control server (100):

[0210] > a. The voice queue cancellation request message can be forwarded to the voice control server arbitration process; and

[0211] >b. The state can remain in "U: Unauthorized and the right to speak is occupied".

[0212] 2. If the MCPTT ID of the associated speaking right participant is not an authorized user (if the participant type is not a dispatcher, dispatch supervisor, or MC service administrator) and cancels the speaking right request of other MCPTT users whose speaking right request is in the speaking right control queue, the speaking right control interface facing the MCPTT client in the speaking right control server (100):

[0213] >a. A response to the conversation queue cancellation request message may be sent to the associated conversation right participant. Response to the conversation queue cancellation request:

[0214] >>i. MAY be included in the Response Status field and have a value of "1" (Failed - Unauthorized);

[0215] >>ii If the right to speak request includes a tracking information field, you may include the received tracking information field;

[0216] > b can be the first bit of the subtype of the response to the conversation right queue cancellation request message is set to "1" (confirmation required); and

[0217] Handling the receipt of a floor confirm message and what action to take if a floor confirm message is not received is an implementation option.

[0218] >c. The state can remain in "U: Unauthorized and the right to speak is occupied".

[0219] A response to the conversation right dequeue request message (response to conversation right dequeue request) is sent.

[0220] When a response to a conversation queue cancellation request message is received from the conversation control server arbitration process in the MCPTT server (100), the conversation control interface facing the MCPTT client in the conversation control server (100):

[0221] 1. The response to the conversation queue cancellation request message may be forwarded to the conversation right participant; and

[0222] 2. The state can remain in "U: Unauthorized and the right to speak is occupied".

[0223] Send a speech right queue cancellation notification message (S: speech right queue cancellation notification).

[0224] When a speech right queuing cancellation notification message is received from the speech right control arbitration process in the MCPTT server (100), the speech right control interface facing the MCPTT client in the MCPTT server (100):

[0225] 1. The notification message of canceling the right to speak can be forwarded to the relevant right-to-speak participants;

[0226] 2. The first bit in the subtype of the talk queue cancellation notification message may be set to "1" (confirmation required); and

[0227] Handling the receipt of a floor confirm message and what action to take if a floor confirm message is not received is an implementation option.

[0228] 3. The state can remain in "U: Unauthorized and Idle".

[0229] Receive a talk right queue cancellation request message (R: talk right queue cancellation request).

[0230] When receiving a talk right queue cancellation request message from the associated talk right participant:

[0231] 1. If the MCPTT ID of the associated speaking right participant is an authorized user (if the participant type is dispatcher, dispatch supervisor and MC service administrator), the speaking right control interface for canceling the speaking right request of other MCPTT users whose speaking right request is in the speaking right control queue is:

[0232] > a. The voice queue cancellation request message can be forwarded to the voice control server arbitration process; and

[0233] >b.Can remain in the "U: Licensed" state.

[0234] 2. If the MCPTT ID of the associated speaking right participant is not authorized (if the participant type is not dispatcher, dispatch supervisor and MC service administrator) to cancel the speaking right request of other MCPTT users whose speaking right request is in the speaking right control queue, the speaking right control interface facing the MCPTT client in the speaking right control server (100):

[0235] >a. A response to the conversation queue cancellation request message may be sent to the associated conversation right participant. Response to the conversation queue cancellation request:

[0236] >>i. MAY be included in the Response Status field and have a value of "1" (Failed - Unauthorized);

[0237] >>ii If the right to speak request includes a tracking information field, you may include the received tracking information field;

[0238] > b can be the first bit of the subtype of the response to the conversation right queue cancellation request message is set to "1" (confirmation required); and

[0239] Handling the receipt of a floor confirm message and what action to take if a floor confirm message is not received is an implementation option.

[0240] >c.Can remain in the "U: Permitted" state.

[0241] A response to the conversation right dequeue request message (response to conversation right dequeue request) is sent.

[0242] When a response to a conversation queue cancellation request message is received from the conversation control server arbitration process in the MCPTT server (100), the conversation control interface facing the MCPTT client in the conversation control server (100):

[0243] 1. The response to the conversation queue cancellation request message may be forwarded to the conversation right participant; and

[0244] 2. You can remain in the "U: Licensed" state.

[0245] Send a notification message for canceling the right to speak queue (S: Cancel the right to speak queue):

[0246] When a speech right queuing cancellation notification message is received from the speech right control arbitration process in the MCPTT server (100), the speech right control interface facing the MCPTT client in the MCPTT server (100):

[0247] 1. The notification message of canceling the right to speak can be forwarded to the relevant right-to-speak participants;

[0248] 2. The first bit in the subtype of the talk queue cancellation notification message may be set to "1" (confirmation required); and

[0249] Handling the receipt of a floor confirm message and what action to take if a floor confirm message is not received is an implementation option.

[0250] 3. It is possible to remain in the "U: Licensed" status.

[0251] The timers in the network speaking right participants are shown in Table 3 below.

[0252]

Table 3

[0253]

[0254]

[0255]

[0256]

[0257] Figure 2 Various hardware components of an MCPPT server (100) according to an embodiment disclosed herein are shown. In one embodiment, the MCPPT server (100) includes an MCS controller (110), a communicator (120), a memory (130), and a processor (140). The processor (140) operates in conjunction 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, hard-wired circuits, etc.) and can optionally be driven by firmware.

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

[0259] In one embodiment, based on the first notification and the second notification, the MCS controller (110) is configured to send a response of a conversation right queue cancellation request message to the MCPTT client (200a).

[0260] In addition, the processor (140) is configured to execute instructions stored in the memory (130) and perform various processes. The communicator (120) is configured to communicate internally between internal hardware components and to communicate 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 a non-volatile storage element. Examples of such non-volatile storage elements may include a magnetic hard disk, an optical disk, a floppy disk, a flash memory, or a form of electrically programmable memory (EPROM) or electrically erasable programmable memory (EEPROM). In addition, in some examples, the memory (130) may be considered a non-transitory storage medium. The term "non-transitory" may mean that the storage medium is not contained in a carrier or propagating signal. However, the term "non-transitory" should not be interpreted as meaning that the memory (130) is non-removable. In some examples, the non-transitory storage medium may store data that may change over time (e.g., in random access memory (RAM) or cache).

[0261] In addition, at least one of the multiple modules / controllers may be implemented by an artificial intelligence (AI) model. Functions associated with AI may be performed by a non-volatile memory, a volatile memory, and a processor (140). The processor (140) may include one or more processors. In this case, the one or more processors may be a general-purpose processor (such as a central processing unit (CPU), an application processor (AP), etc.), a graphics-specific processing unit (such as a graphics processing unit (GPU)), a visual processing unit (VPU), and / or an AI-specific processor (such as a neural processing unit (NPU)).

[0262] One or more processors control the processing of input data according to predefined operating rules or artificial intelligence (AI) models stored in non-volatile memory and volatile memory. The predefined operating rules or artificial intelligence models are provided through training or learning.

[0263] Herein, providing by learning means generating predefined operating rules or AI models of desired characteristics by applying a learning algorithm to a plurality of learning data. The learning can be performed in the device itself in which the AI ​​according to the embodiment is executed, and / or can be implemented by a separate server / system.

[0264] The AI ​​model may include multiple neural network layers. Each layer has multiple weight values, and layer operations are performed by calculating the previous layer and operating on multiple weights. Examples of neural networks include, but are not limited to, convolutional neural networks (CNNs), deep neural networks (DNNs), recurrent neural networks (RNNs), restricted Boltzmann machines (RBMs), deep belief networks (DBNs), bidirectional recurrent deep neural networks (BRDNNs), generative adversarial networks (GANs), and deep Q networks.

[0265] A learning algorithm is a method that uses multiple learning data to train a predetermined target device (e.g., a robot) to enable, 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.

[0266] Although Figure 2 Various hardware components of the MCPPT server (100) are shown, but it should be understood that other embodiments are not limited thereto. In other embodiments, the MCPPT server (100) may include fewer or greater numbers of components. Furthermore, the labels or names of the components are for illustrative purposes only and do not limit the scope of the present disclosure. One or more components may be combined to perform the same or substantially similar functions in the MCPPT server (100).

[0267] Figure 3 Various hardware components of an MCPPT client (200) according to an embodiment disclosed herein are shown. In one embodiment, the MCPPT client (200) includes an MCS controller (210), a communicator (220), a memory (230), a processor (240), and a timer (250). The processor (240) operates in conjunction with the MCS controller (210), the communicator (220), the memory (230), and the timer (250).

[0268] The MCS controller (210) is configured to send a voice queue cancellation request message to the MCPTT server (100) to cancel one or more queued voice requests associated with one or more MCPTT clients (200b-200n). In one embodiment, after sending the voice queue cancellation request message, the MCS controller (210) is configured to start a timer (250) that indicates a period during which the voice queue cancellation request message can be cancelled. The MCS controller (210) is configured to determine that the one or more queued voice requests associated with the MCPTT client (200b-200n) have not been cancelled when the timer (250) expires. Based on the determination, the MCS controller (210) is configured to resend the voice queue cancellation request message to the MCPTT server (100) to cancel the one or more queued voice requests associated with the one or more MCPTT clients (200b-200n). Based on the talk right queue cancellation request message, the MCS controller (210) is configured to receive a response to the talk right queue cancellation request message from the MCPTT server (100).

[0269] Furthermore, the MCS controller (210) is configured to notify the MCPTT server (100) of the transition from the first state to the second state 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, hard-wired circuits, etc.) and can optionally be driven by firmware.

[0270] In addition, the processor (240) is configured to execute instructions stored in the memory (230) and perform various processes. The communicator (220) is configured to communicate internally between internal hardware components and to communicate 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 a non-volatile storage element. Examples of such non-volatile storage elements may include a magnetic hard disk, an optical disk, a floppy disk, a flash memory, or a form of electrically programmable memory (EPROM) or electrically erasable programmable memory (EEPROM). In addition, in some examples, the memory (230) may be considered a non-transitory storage medium. The term "non-transitory" may mean that the storage medium is not contained in a carrier or propagating signal. However, the term "non-transitory" should not be interpreted as meaning that the memory (230) is non-removable. In some examples, the non-transitory storage medium may store data that may change over time (e.g., in random access memory (RAM) or cache).

[0271] At least one of the multiple modules may be implemented by an artificial intelligence (AI) model. Functions associated with AI may be performed by a non-volatile memory, a volatile memory, and a processor (240). The processor (240) may include one or more processors. In this case, the one or more processors may be a general-purpose processor (such as a central processing unit (CPU), an application processor (AP), etc.), a graphics-specific processing unit (such as a graphics processing unit (GPU)), a visual processing unit (VPU), and / or an AI-specific processor (such as a neural processing unit (NPU)).

[0272] One or more processors control the processing of input data according to predefined operating rules or artificial intelligence (AI) models stored in non-volatile memory and volatile memory. The predefined operating rules or artificial intelligence models are provided through training or learning.

[0273] Herein, providing by learning means generating predefined operating rules or AI models of desired characteristics by applying a learning algorithm to a plurality of learning data. The learning can be performed in the device itself in which the AI ​​according to the embodiment is executed, and / or can be implemented by a separate server / system.

[0274] The AI ​​model may include multiple neural network layers. Each layer has multiple weight values, and layer operations are performed by calculating the previous layer and operating on multiple weights. Examples of neural networks include, but are not limited to, convolutional neural networks (CNNs), deep neural networks (DNNs), recurrent neural networks (RNNs), restricted Boltzmann machines (RBMs), deep belief networks (DBNs), bidirectional recurrent deep neural networks (BRDNNs), generative adversarial networks (GANs), and deep Q networks.

[0275] A learning algorithm is a method that uses multiple learning data to train a predetermined target device (e.g., a robot) to enable, 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.

[0276] although Figure 3 Various hardware components of the MCPPT client (200) are shown, but it should be understood that other embodiments are not limited thereto. In other embodiments, the MCPPT client (200) may include fewer or greater numbers of components. Furthermore, the labels or names of the components are for illustrative purposes only and do not limit the scope of the present disclosure. One or more components may be combined to perform the same or substantially similar functions in the MCPPT client (200).

[0277] Figure 44 is a flow chart illustrating a method implemented by an MCPTT server (100) for processing MCS in a wireless communication network (300) according to an embodiment disclosed herein. Operations (402-408) are performed by an MCS controller (110).

[0278] At 402, the method includes receiving a voice queue cancellation request message from an MCPTT client to cancel one or more queued voice requests associated with one or more MCPTT clients (200b-200n). At 404, the method includes determining whether the one or more queued voice requests associated with the one or more MCPTT clients (200b-200n) have been cancelled based on the received voice queue cancellation request message. At 406, the method includes sending a first notification to the one or more MCPTT clients (200b-200n) that the one or more queued voice requests have been cancelled. At 408, the method includes sending a second notification to the one or more MCPTT clients (200b-200n) that the one or more queued voice requests have not been cancelled.

[0279] Figure 5 The present invention is a flowchart (500) illustrating a method implemented by an MCPTT client (200a) for processing MCS in a wireless communication network (300) according to an embodiment disclosed herein. Operations (502 and 504) are performed by an MCS controller (210).

[0280] At 502, the method includes sending a voice queue cancellation request message to the MCPTT server (100) to cancel one or more queued voice requests associated with one or more MCPTT clients (200b-200n). At 504, the method includes receiving a response to the voice queue cancellation request message from the MCPTT server (100) based on the voice queue cancellation request message.

[0281] The various actions, behaviors, blocks, steps, etc. in the flowcharts (400 and 500) can be performed in the order presented, in a different order, or simultaneously. In addition, in some embodiments, some actions, behaviors, blocks, steps, etc. can be omitted, added, modified, or skipped without departing from the scope of the present disclosure.

[0282] Figure 6is an example sequential flow chart illustrating step-by-step operations for processing MCS in a wireless communication network (300) according to an embodiment disclosed herein. Typically, once a call is established, multiple users associated with one or more MCPTT clients (200a-200n) can request a voice call. In one example, at 602a, the MCPTT client (200n) sends a first queued voice call request to the MCPTT server (100). At 602b, a third MCPTT client (200c) sends a second queued voice call request to the MCPTT server (100). At 602c, the second MCPTT client (200n) sends a third queued voice call request to the MCPTT server (100). Now, the first queued voice call request, the second queued voice call request, and the third queued voice call request are in the voice call queue. At 604, the MCPTT client (200a) sends a voice call queue cancellation request message to the MCPTT server (100).

[0283] At 606, the MCPTT server (100) determines that the first MCPTT client (200a) is an authorized client. At 608, the MCPTT client (200a) starts a timer (250) that indicates a period during which a voice queue cancellation request message can be cancelled. At 610, the MCPTT client (200a) determines whether one or more queued voice requests associated with the MCPTT clients (200b-200c) are cancelled before the expiration of the timer (250). If one or more queued voice requests associated with the MCPTT clients (200b-200c) are not cancelled before the expiration of the timer (250), then at 612, the MCPTT client (200a) resends a voice queue cancellation request message to the MCPTT server (100) to cancel the one or more queued voice requests associated with the one or more MCPTT clients (200b-200c).

[0284] If one or more queued floor requests associated with the MCPTT client (200b-200c) are canceled before the timer (250) expires, then at 614, the MCPTT server (100) sends a response to the queued floor cancel request message from the MCPTT server (100).

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

[0286] The embodiments disclosed herein may be implemented by at least one software program running on at least one hardware device and performing network management functions to control elements. These elements may be at least one of a hardware device or a combination of a hardware device and a software module.

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

[0288] Although the present disclosure has been described with various embodiments, various changes and modifications may occur to those skilled in the art. The present disclosure is intended to encompass such changes and modifications as fall within the scope of the appended claims.

Claims

1. A method for processing a mission critical service (MCS) in a wireless communication network, performed by a mission critical push-to-talk (MCPTT) server, the method comprising: receiving a voice queue cancellation request message from a first MCPTT client to cancel at least one queued voice request, wherein the at least one queued voice request is associated with at least one second MCPTT client; Identify whether the active voice request queue is empty; as well as sending a response to the speech right queuing cancellation request message to the first MCPTT client, wherein the response includes a response status field indicating a cancellation result of the at least one queuing speech right request, The value of the response status field is determined based on an identification of whether the active speaking right request queue is empty.

2. The method according to claim 1, wherein: In the case that the active floor request queue is empty, the value of the response status field indicates that the cancellation of the at least one queued floor request failed because the active floor request queue is empty, and In a case where the active speaking right request queue is not empty, the value of the response status field indicates that the cancellation of the at least one queued speaking right is successful.

3. The method according to claim 1, wherein In the case that the floor request associated with any of the at least one queued floor request includes tracking information, the response to the floor queue cancellation request message includes the tracking information.

4. The method according to claim 1, wherein The talk right queuing cancellation request message includes a user identifier (ID) list of the at least one second MCPTT client.

5. The method according to claim 4, further comprising removing the queued floor request of the user identified in the user ID list from the active floor request queue if the active floor request queue is not empty. 6 . The method according to claim 1 , further comprising sending a speech right queuing cancellation notification message to the at least one second MCPTT client to notify the at least one second MCPTT client that the at least one queued speech right request is cancelled.

7. A method for processing 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 a speech right queuing cancellation request message to the MCPTT server to cancel at least one queuing speech right request associated with at least one second MCPTT client; as well as receiving a response to the voice queue cancellation request message from the MCPTT server, wherein the response includes a response status field indicating a cancellation result of the at least one queued voice request, The value of the response status field is determined based on whether the active speaking right request queue of the MCPTT server is empty.

8. The method according to claim 7, wherein: In the case that the active floor request queue is empty, the value of the response status field indicates that the cancellation of the at least one queued floor request failed because the active floor request queue is empty, and In a case where the active speaking right request queue is not empty, the value of the response status field indicates that the cancellation of the at least one queued speaking right is successful.

9. The method according to claim 7, further comprising: Starting a timer associated with the speaking right queue cancellation request message; as well as When the timer expires, it is determined that the speaking right queuing cancellation request has timed out.

10. A mission-critical push-to-talk (MCPTT) server for processing a mission-critical service (MCS) in a wireless communication network, the MCPTT server comprising: transceiver; and a controller coupled with the transceiver and configured to: receiving, via the transceiver, a voice queue cancellation request message from a first MCPTT client to cancel at least one queued voice request, wherein the at least one queued voice request is associated with at least one second MCPTT client, Identify whether the active floor request queue is empty, and sending a response to the voice queue cancellation request message to the first MCPTT client via the transceiver, wherein the response includes a response status field indicating a cancellation result of the at least one queued voice request, The value of the response status field is determined based on an identification of whether the active speaking right request queue is empty.

11. The MCPTT server according to claim 10, wherein: In the case that the active floor request queue is empty, the value of the response status field indicates that the cancellation of the at least one queued floor request failed because the active floor request queue is empty, and In a case where the active speaking right request queue is not empty, the value of the response status field indicates that the cancellation of the at least one queued speaking right is successful.

12. The MCPTT server according to claim 10, wherein: In the case that the floor request associated with any of the at least one queued floor request includes tracking information, the response to the floor queue cancellation request message includes the tracking information.

13. The MCPTT server according to claim 10, wherein: The talk right queuing cancellation request message includes a user identifier (ID) list of the at least one second MCPTT client.

14. The MCPTT server according to claim 13, wherein: The controller is further configured to remove the queued floor request of the user identified in the user ID list from the active floor request queue if the active floor request queue is not empty.

15. The MCPTT server according to claim 10, wherein: The controller is further configured to send a speech right queuing cancellation notification message to the at least one second MCPTT client via the transceiver to notify the at least one second MCPTT client that the at least one queued speech right request is cancelled.

16. A first mission-critical push-to-talk (MCPTT) client for processing a mission-critical service (MCS) in a wireless communication network, the first MCPTT client comprising: transceiver; and a controller coupled with the transceiver and configured to: sending, via the transceiver, a voice queue cancellation request message to the MCPTT server to cancel at least one queued voice request associated with at least one second MCPTT client, and receiving a response to the voice queue cancellation request message from the MCPTT server via the transceiver, the response including a response status field indicating a cancellation result of the at least one queued voice request, The value of the response status field is determined based on whether the active speaking right request queue of the MCPTT server is empty.

17. The first MCPTT client according to claim 16, wherein: In the case that the active floor request queue is empty, the value of the response status field indicates that the cancellation of the at least one queued floor request failed because the active floor request queue is empty, and In a case where the active speaking right request queue is not empty, the value of the response status field indicates that the cancellation of the at least one queued speaking right is successful.

18. The first MCPTT client according to claim 16, wherein: The controller is further configured to: Starting a timer associated with the talk right queue cancellation request message, and When the timer expires, it is determined that the speaking right queuing cancellation request has timed out.

Images