CN115486090A - System and method for handling media transport in a Mission Critical (MC) system - Google Patents

Abstract

The present disclosure relates to a communication method and system for converging a fifth generation (5G) communication system for supporting higher data rates outside of fourth generation (4G) systems with technology for internet of things (IoT). The present disclosure is applicable to smart services based on 5G communication technologies and IoT related technologies, such as smart homes, smart buildings, smart cities, smart cars, connected cars, healthcare, digital education, smart retail, security, and security services. In the present disclosure, a system and method for handling media transmission in a Mission Critical (MC) system or MC video system is provided. According to the system and the method of the invention, the waste of network resources can be avoided, and the other participants in the group can be given the opportunity of transmitting important data when the maximum transmission times in the group call is limited by the network capacity. Therefore, the efficiency of the MC video system can be improved.

Description

Systems and methods for handling media transmission in a mission critical (MC) system

technical field

The present disclosure relates to telecommunications networks, and more particularly to mission critical (MC) systems provided over telecommunications networks. More specifically, the present invention relates to systems and methods for handling media transmission in mission critical (MC) systems or MC video systems.

Background technique

In order to meet the demand for wireless data services that have increased 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 called "post-4G networks" or "post-LTE systems". 5G communication systems are considered to be implemented in higher frequency (mmWave) frequency bands, such as the 60GHz band, in order to achieve higher data rates. In order to reduce the propagation loss of radio waves and increase the transmission distance, in 5G communication systems, beamforming, massive multiple-input multiple-output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, large scale antenna technology. In addition, in the 5G communication system, advanced small cells, cloud radio access network (RAN), ultra-dense network, device-to-device (D2D) communication, wireless backhaul, mobile network, cooperative communication, coordinated multi-point (CoMP) ), the development of system network improvements such as interference cancellation at the receiving end. In 5G systems, hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) as advanced coded modulation (ACM), and filter bank multicarrier (FBMC), non-orthogonal multi- Nominated access access (NOMA) and sparse code multiple access (SCMA) have been developed.

According to the development of communication systems, there is a need for a method of handling media transmission in mission critical (MC) systems or MC video systems.

Contents of the invention

technical problem

In MC system or MC video system, the transmission control server state machine for 'General reception control operation' as described in 3GPP TS 24.581 subclause 6.3.6, as described in 3GPP TS 24.581 subclause 6.3.4 The Transport Control Server state machine for 'General Transport Control Operations', and the Transport Control Server State Machine for 'Basic Transport Control Operations oriented to Transport Participants' as described in 3GPP TS 24.581 subclause 6.3.5 are not defined Any procedure to terminate a transmitter's stream when all MC Video Receivers terminate receiving the stream, or when all MC Video Receivers fail to receive notifications after being given sufficient time to accept or reject notifications. Therefore, there is no defined procedure for terminating a transport stream when no users are interested in receiving that particular stream. Furthermore, conventional systems also do not provide any reason for transmission termination. Therefore, if other users want to send important communications, this opportunity is not provided.

Accordingly, it would be desirable to address the above or other disadvantages, or at least provide a useful alternative.

problem solution

In a mission-critical video (MCVideo) system, when a user is granted permission to send media, all MCVideo users belonging to the group will get a media transfer notification message from the server. Based on user interest or priority, the user can accept/decline/ignore the notification. If, within a given time, none of the users in the group accept the notification, or initially some users are accepted, but later all accepted users terminate reception by sending an end-of-reception request to the server, the transmitter's stream should terminated, and the sending user should be informed of the reason for the termination. 3GPP TS 24.581 currently does not define any procedure or method for terminating a flow and notifying the transmitter when there are no active receivers for the flow.

In this disclosure, a process for solving the above-mentioned problems is disclosed. In this disclosure, new timers and new counters in MCVideo server are disclosed. When no MCVideo user is receiving the stream, even if the stream is currently being sent from other MCVideo users, a new timer will be started. And when at least one user is granted permission to receive the stream, the new timer will be stopped. A new counter is used to track the count of active receiving users for this stream. When there are no active receivers for the stream, the MCVideo server can use a Transmission End Request or Transmission Cancellation message to terminate the stream and notify the transmitter of the reason for the termination.

According to one embodiment of the present disclosure, a method of processing media transmission in Mission Critical (MC) is disclosed herein. Accordingly, the method comprises receiving, by the MC server, a request from a first sender to send a media stream to at least one receiver. Thereafter, a notification is sent by the MC server to at least one receiver to receive the media stream sent by the first sender. Thereafter, the MC server starts a timer with a predetermined duration after sending the notification. Then, the MC server determines that the notification of receiving the media stream is rejected or not accepted by at least one receiver within the predetermined duration of the timer, and then, based on one of the rejection or non-acceptance of the reception of the media stream, the MC server sends to the first The host sends a transmission end request to terminate the media stream sending request.

According to another embodiment of the present disclosure, a method of processing media transmission in mission critical (MC) at an MC device is disclosed herein. Accordingly, the method includes receiving, by the MC device, from the MC server, an end-of-transmission request for terminating the transmission of the media stream. Thereafter, a user associated with the MC device is notified by the MC device of a reason for terminating the transmission of the media stream, wherein the reason for terminating the transmission is due to lack of at least one receiver device for receiving the media stream. The method also includes sending, by the MC device, a transmission end response to the MC server, and terminating the transmission of the media stream to the MC server.

According to another embodiment of the present disclosure, a method of handling media transmission in a mission critical (MC) at a transmission participant device is disclosed herein. Accordingly, the method includes receiving, by the transfer participant device, a transfer end request from the transfer control server. A user associated with the transfer participant device is then notified by the transfer participant device that the media stream termination reason indicating the client's authorization to send the media was revoked due to a lack of at least one participant device to receive the media stream. Afterwards, the transmission participant device sends a transmission end response to the transmission control server, and terminates sending the media stream to the transmission control server.

According to another embodiment of the present disclosure, a method of handling media transmissions in mission critical (MC) at a transmission control server is disclosed herein. Therefore, the method includes sending, by the transmission control server to the transmitting MC device, a transmission end request message for terminating the transmission of the media stream when the timer (T11) defined as the stream reception idle T11 timer expires. Thereafter, a transfer end response is received by the transfer control server from the transfer participant device. The transmission control server then sends a transmission end notification message to at least one media receiving client, wherein the transmission end notification message indicates the end of the transmission from the transmission participant device.

According to another embodiment of the present disclosure, a method of handling media transmissions in mission critical (MC) at a transmission control server is disclosed herein. Accordingly, the method includes authorizing, by the transmission control server, the first transmission participant device to transmit media streams to a plurality of MC devices, and then sending a "media transmission notification" message to at least one MC device to receive the media stream transmitted by the first transmission participant device. media stream. Thereafter, a "receive media request" message is received by the transport control server from at least one MC device to receive the media stream from the first transport participant device. Thereafter, the transmission control server sends a "Receive Media Response (Authorization)" message to at least one MC device to indicate authorization to receive media streams from the first transmission participant device. Then, the transmission control server receives a "media reception end request" message to terminate reception from at least one MC device, and then the transmission control server sends a "media reception end response" to indicate a termination response of media stream reception. Then, the transmission control server determines that at least one MC device does not receive the media stream based on the expiration of the predetermined duration of the timer T11 (stream receiving idle), and then based on the counter defined as the count of active receivers of the media stream (C11) value, enters the "Receive Idle" state.

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. It should be understood, however, that the following description, while indicating preferred embodiments, as well as numerous specific details, are given by way of illustration and not limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the spirit of the invention, and the embodiments herein include all such modifications.

Beneficial Effects of the Invention

In the present disclosure, a system and method for handling media transmission in a mission critical (MC) system or MC video system is provided. According to the system and method of the present invention, the waste of network resources can be avoided, and when the maximum number of transmission times in a group call is limited by network capacity, other participants in the group can be given a chance to transmit important data. Therefore, the efficiency of the MC video system can be improved.

Description of drawings

The present disclosure is illustrated in the drawings, wherein like reference numerals designate corresponding parts in the various drawings. Embodiments herein will be better understood from the following description with reference to the accompanying drawings, in which:

Figure 1A shows an exemplary scenario (a) according to the prior art;

Figure 1B shows an exemplary scenario (b) according to the prior art;

Figure 2 illustrates an example architecture for a mission-critical (MC) system for processing media transmissions according to an embodiment of the present disclosure;

FIG. 3 shows a block diagram of an MC device for processing media transmission according to an embodiment of the present disclosure;

Figure 4 shows a block diagram of a transport control server for processing media transport according to an embodiment of the present disclosure;

FIG. 5 shows a flowchart for processing media transmission in an MC system according to an embodiment of the present disclosure;

FIG. 6 shows a flowchart for processing media transmission in the MC device 101 according to an embodiment of the present disclosure;

FIG. 7 shows a flowchart for processing media transmission in a transmission participant device according to an embodiment of the present disclosure;

FIG. 8 shows a flowchart for processing media transmission in the transmission control server 102 according to an embodiment of the present disclosure;

FIG. 9 shows a flowchart for processing media transmission in the transmission control server 102 according to an embodiment of the present disclosure;

Figure 10 shows a state diagram of "transfer participant basic transfer control operations" according to an embodiment of the present disclosure;

FIG. 11 shows a state diagram of "Transport Control Server Generic Transport Control Operations" according to an embodiment of the present disclosure;

FIG. 12 shows a state machine diagram for "Basic Transport Control Operations of a Transport Participant-Oriented Transport Control Server" according to an embodiment of the present disclosure;

FIG. 13 shows a state machine diagram for general receive control operations of a transport control server according to an embodiment of the present disclosure;

Figure 14 shows yet another exemplary implementation according to an embodiment of the present disclosure;

Figure 15 shows a block diagram of an MC device according to an embodiment of the present disclosure; and

FIG. 16 shows a block diagram of an MC server according to an embodiment of the present disclosure.

Furthermore, those skilled in the art will appreciate that elements in the figures are shown for simplicity and have not necessarily been drawn to scale. For example, the flowcharts show the method in terms of the most salient steps involved to help improve understanding of aspects of the disclosure. Furthermore, in terms of the construction of the device, one or more parts of the device may be represented by conventional symbols in the drawings, and the drawings may only show those specific details relevant to understanding the embodiments of the present disclosure, so as not to overwhelm the accompanying drawings. The figures are obscured and these details will be apparent to one of ordinary skill in the art having the benefit of the description herein.

detailed description

To promote an understanding of the principles of the disclosure, reference will now be made to the embodiments illustrated in the drawings, and specific language will be used to describe the same. It should be understood, however, that no limitation of the scope of the disclosure is thereby intended and that such changes and further modifications in the illustrated system, and such further applications of the principles of the disclosure shown therein are considered to be part of the present disclosure. Those skilled in the art involved would normally think of it.

It is to be understood by those skilled in the art that the foregoing general description and the following detailed description are explanations of the present disclosure, rather than limitations of the present disclosure.

Reference throughout this specification to "an aspect," "another aspect," or similar language means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, appearances of the phrases "in one embodiment," "in another embodiment," and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

The terms "comprises", "comprises" or any other variation thereof are intended to cover a non-exclusive inclusion such that a process or method comprising a series of steps includes not only those steps but may also include items not expressly listed or inherent to such process or method. other steps. Similarly, the word "comprise" of one or more devices or subsystems or elements or structures or components does not exclude other devices or other subsystems or other elements or other structures or other components or Presence of additional equipment or additional subsystems or additional elements or additional structures or additional components.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. The systems, methods and examples provided herein are illustrative only and not limiting.

In a mission critical video (MCVideo) system, when a user is granted permission to send media, all MCVideo users belonging to the group will get a media transfer notification message from the server. Based on user interest or priority, the user can accept/decline/ignore the notification. If, within a given time, none of the users in the group accept the notification, or initially some users are accepted, but later all accepted users terminate reception by sending an end-of-reception request to the server, the transmitter's stream should terminated, and the sending user should be informed of the reason for the termination. This is mainly to avoid wasting resources and to give other users the opportunity to send important data. 3GPP TS 24.581 currently does not define any procedure or method for terminating a flow and notifying the transmitter when there are no active receivers for the flow. Exemplary situations are shown in the drawings. Figures 1A and 1B illustrate problems that may occur due to this condition.

Fig. 1A shows an exemplary scenario (a) according to the prior art. According to FIG. 1A, user A is requested to send media. MCVideo server sends authorization to user A and transfer notification to user C and user D. At this point, no other members of the group are sending media. Assume that user C and user D do not accept transmission notifications. But user A is sending media, but none of the users are receiving media. Now, User B is requested to send media, but while User A's transmission is still valid, User B's request is rejected or queued.

Fig. 1B shows an exemplary scenario (b) according to the prior art. According to FIG. 1B , user A is requested to send media. MCVideo server sends authorization to user A and transfer notification to user C and user D. At this stage, no other members of the group are sending at that time. Assume User C accepts the notification, but User D rejects/ignores the transmission notification. After some time, user C ends receiving even though user A is still sending. So user A sends media, but there is no user who receives media. Now, User B is requested to send media, but while User A's transmission is still valid, User B's request is rejected or queued.

According to the situation disclosed above, even though no receiver (C or D) is accepting the notification request, the sender A keeps sending it. This results in unnecessary waste of resources. It also prohibits/does not allow another user B to initiate his media transmission. Furthermore, mission critical systems have limitations on the maximum simultaneous transmissions in a particular group call. Some actors have important disaster video streams to transmit, potentially blocking/delaying the real-time transmission of information to the decision-making control room, thereby disrupting lifesaving efforts. This situation may not be good in a mission-critical environment.

According to the present embodiment, a unique procedure for solving the above-mentioned problems is disclosed. In particular, a new timer T11 and a new counter C11 are defined at the MCVideo server if none of the mission-critical users in the group are receiving a particular stream due to other priorities.

The new timer T11 can be started when no MCVideo user is receiving the stream, even if it is currently being sent from other MCVideo users, and when the timer expires, the server will initiate a "transmission TM end request", rejecting the sending device/client to terminate The stream is sent, and other users in the queue are authorized to send media. The new timer T11 can be stopped when at least one user is authorized to receive the stream. Additionally, a new counter C11 is used to track the active receiving user count for this stream. When there are no active receivers for the stream, the MCVideo server can use a Transmission End Request or Transmission Cancellation message to terminate the media stream and notify the transmitter of the reason for the termination.

FIG. 2 illustrates an example architecture of a mission critical (MC) system for processing media transmissions according to an embodiment of the disclosure. According to FIG. 2, the MC system 200 may include one or more MC devices 1, 2, . . . , MC equipment N. As one example, an MC device may be referred to as 101 throughout this disclosure. Furthermore, the MC device 101 may alternatively be referred to as a receiver, a transmitter, without departing from the scope of this disclosure. The MC device 101 communicates with the transport control server 102 . The transport control server 102 may alternatively be referred to as a server, MC server, MCVideo server, without departing from the scope of this disclosure. The transmission control server 102 is exchangeably coupled with the transmission participant device 100 . The transfer participant device 100 may also communicate with the MC client 103 . As an example, the transfer participant device 100 and the MC client 103 may alternatively be referred to as receivers, MC devices, without departing from the scope of this disclosure.

According to FIG. 2 , an MC group call session can be established between the MC device 100 , the MC device 101 and the transport control server 102 . A plurality of transfer participant devices 100 may send transfer requests to the transfer control server 102 to send media. As an example, media could be referred to as a media stream, without departing from the scope of this disclosure. The transmission control server 102 may grant permission to the transmission participant device 100 and send a "media transmission notification" to other MC devices 101 to receive the media transmission. Based on the MC device's 101 response, media may only be sent to authorized MC devices 101 . A new timer T11 and counter C11 can be implemented at the transport control server 102 for handling the various cases explained, but not limited to, in FIGS. 1A and 1B .

Fig. 3 shows a block diagram of an MC device for processing media transmission according to an embodiment of the present disclosure. As an example, the MC device 101 may include a computing device such as, but not limited to, a smartphone, a tablet, smart glass, a smart webcam, a desktop computer, a laptop, a relay device, a D2D device, a V2X device, or any other computing device. Transfer participant device 100 may also be referred to as MC device 101 and is associated with the same group. Referring to FIG. 3 , the MC device 101 of an embodiment of the present disclosure may include a memory 110 , a processor 120 , a communicator 130 and an I/O interface 140 . Memory 110 may include application program repository 110a. Application repository 110a may include applications 110aa through 110an. Processor 120 may include an MC communication session organizer 120a and an MC media engine 120b.

FIG. 4 shows a block diagram of a transmission control server for handling media transmissions according to an embodiment of the disclosure. As an example, the transport control server 102 may include various network devices including routers, bridges, servers, computing devices, storage devices, and the like. Participating in and controlling the MCVideo functionality may be referred to as a transport control server 102 . Referring to FIG. 4, the transmission control server 102 of the embodiment of the present disclosure may include a memory 102a, a processor 102b, a communicator 102c, and an I/O interface 102d. Processor 102b may include MC media engine 102ba and MC communication session organizer 102bb.

Fig. 5 shows a flowchart for processing media transmission in an MC system according to an embodiment of the present disclosure. Referring to FIG. 5 , the method 500 may be implemented in the MC server 102 of the MC system, as shown in FIG. 2 . Here, explanations will be made with reference to FIGS. 2 to 4 in combination. In one implementation, MC server 102 may perform method 500 .

According to FIG. 5 , at step 501 , the method 500 initially comprises receiving, by the MC server 102 , a request from a first sender to send a media stream to at least one receiver. As an example, the first sender may be one of the transfer participant devices 100 and the receiver may be one of the MC devices 101 . As another example, the first sender and the at least one receiver belong to the same group of MC devices 101, and wherein the media stream may include but not limited to at least one of video and audio data.

Thereafter, in step 503, the MC server 102 may be configured to send a notification to at least one receiver to receive the media stream sent by the first sender. As examples, notifications may include, but are not limited to, audio, video, text, multimedia, user interface element type messages.

Thereafter, at step 505, the MC server 102 may be configured to execute a start timer for a predetermined duration after sending the notification. As an example, the timer may be a timer T11 defined as stream reception idle. Furthermore, the duration can be set according to the criticality of the MC system.

Thereafter, at step 507, the MC server 102 may be configured to perform a determination of whether the notification of receiving the media stream is rejected or not accepted by at least one receiver within the predetermined duration of the timer. As one example, the media stream may be rejected due to priority tasks, or the receiver may not be aware of the notification and not accept it.

At step 509, the MC server 102 may be configured to perform sending an end-of-transmission request to the first sender to terminate the media streaming request based on one of rejection or non-acceptance of receipt of the media stream.

Furthermore, at step 505, that is, after sending the notification to at least one receiver, the MC server 102 may be configured to perform a check of acceptance of the sent media by said at least one receiver. Now, based on a rejection or non-acceptance of reception of the media stream by at least one receiver, the MC server 102 may be configured to perform termination of the transmission of the media stream from the first sender device.

In a further implementation of method 500, MC server 102 may be configured to receive an end-of-transmission response from the first sender in response to sending the end-of-transmission request. The transfer end request may include a reason for ending the transfer. Furthermore, the reason for ending the transmission is due to lack of at least one receiver for receiving the media stream.

In another embodiment of the method 500, the MC server 102 may be configured to perform authorization of the second sender to transmit the new media stream to the at least one recipient after sending the end-of-transmission request to the first sender.

In a further implementation of the method 500, the MC server 102 may be configured to perform accepting notifications of received media streams. Accepting the notification of receiving the media stream includes receiving, by the MC server 102, a request to receive the media stream from at least one receiver. As an example, when the notification is accepted by at least one receiver, the receiver sends a request to the MC server to receive the media stream in response.

Now, after the above-mentioned steps, the MC server 102 may be configured to perform sending a response to at least one receiver to notify the reception authorization. Thereafter, the MC server may be configured to perform an increment of a counter value for each active receiver from at least one receiver upon receipt of the authorization. As an example, a new counter C11 has been defined and counts active receivers for this stream.

The method 500 executes after the acceptance of the notification of receiving the media stream is performed, receiving a request by the MC server 102 to terminate the reception of the media stream from at least one receiver. Thereafter, MC server 102 may be configured to send a response to indicate termination of media stream reception. Furthermore, the MC server 102 may be configured to decrement the counter value by 1 for each termination of a media stream received from at least one receiver. Thereafter, if the timer expires, the MC server 102 determines that at least one receiver is not receiving the media stream. Thus, the MC server 102 enters the "reception idle" state based on the counter value. Now, after the timer expires, the MC server 102 may be configured to send a transmission end request to the first sender to terminate the transmission.

In another implementation, in the method 500, the MC server 102 may be configured to: when the counter value reaches the minimum predetermined value after the counter value is decremented or when the MC server 102 sends a "media transmission notification" message to the MC device 102, Scheduled duration to execute restart timer.

In a further implementation, method 500, the MC server 102 may be configured to perform termination if at least one receiver accepts a notification to receive the media, or if the media transmission is terminated by the transmission control server (102) by sending a transmission end notification message. timer.

FIG. 6 shows a flowchart for processing media transmission in the MC device 101 according to an embodiment of the present disclosure. Referring to FIG. 6 , the method 600 may be implemented in the MC device 101 of the MC system 200 , as shown in FIG. 2 . Here, explanations will be made with reference to FIGS. 2 to 5 in combination. In one implementation, the MC device 101 may perform the method 600 .

According to FIG. 6 , at step 601 , the method 600 includes receiving, by the MC device 101 , a transmission end request from the MC server 102 for terminating media stream transmission, and then proceeding to step 509 as shown in FIG. 5 .

Thereafter, at step 603, the method 600 includes notifying, by the MC device 101, a user associated with the MC device 101 of the reason for terminating the media streaming. As an example, the reason for ending the transmission is due to lack of at least one receiver device for receiving the media stream. Thus, the user who may possess the MC device 101 is notified of the end of the transmission and the reason.

After step 603 , at step 605 , the MC device 101 may be configured to send a transmission end response to the MC server 102 , and thereafter at step 607 , the MC device 101 may be configured to terminate the transmission of the media stream to the MC server 102 .

Fig. 7 shows a flowchart for processing media transmission in a transmission participant device according to an embodiment of the present disclosure. Referring to FIG. 7 , the method 700 may be implemented in the transmission participant device 100 of the MC system 200 , as shown in FIG. 2 . Here it will be described in conjunction with FIG. 2 to FIG. 6 . In an implementation in transfer participant device 100, method 700 may be performed.

According to FIG. 7 , at step 701 , the method 700 includes receiving a transmission end request from the transmission control server ( 102 ) by the transmission participant device ( 100 ), and proceeding to step 509 as shown in FIG. 5 .

Thereafter, at step 703, the method 700 includes configuring the transfer participant device 100 to notify a user associated with the transfer participant device 100 of the media stream termination reason. The media stream termination cause indicates that the client's authorization to send media is being revoked due to a lack of at least one participant device 100 to receive the media stream.

Subsequently, at step 705 , the transfer participant device 100 may be configured to send a transfer end response to the transfer control server 102 .

Thereafter, at step 707, the transmission participant device 100 may be configured to terminate sending the media stream to the transmission control server (102).

According to FIG. 7, the transfer participant device 100 may be configured to enter a "call release" state for a broadcast group call or a "not allowed to send" state for a normal or non-broadcast group call. For example, if the call initiated as a broadcast group call is sent after the end response message is sent, that is, after step 705, the transmission participant device 100 will enter the call release state. For any other type of call after step 705, the transfer participant device 100 may enter the "not allowed" state. As an example, a transfer participant device (100) may be an MC device (101) and be associated with the same group.

FIG. 8 shows a flowchart for processing media transmissions in the transmission control server 102 according to an embodiment of the present disclosure. Referring to FIG. 8 , the method 800 may be implemented in the transmission control server 102 of the MC system 200 , as shown in FIG. 2 . Here, explanations will be made with reference to FIGS. 2 to 7 in combination. In an implementation in transport control server 102, method 800 may be performed. The method disclosed in FIG. 8 is according to another embodiment of the transport control server 102 disclosed in FIG. 5 .

According to FIG. 8 , in step 801 , the method 800 includes sending a transmission end request message by the transmission control server 102 to the transmission MC device 101 , for terminating the transmission of the media stream when the timer T11 expires. The timer T11 is called a stream reception idle T11 timer. As an example, the end-of-transfer request includes at least one of the "no receiving participant" reasons in the "reject reason" field of the end-of-transfer request, which indicates the reason for terminating the media stream

At step 803, the transmission control server 102 is configured to receive a transmission end response from the transmitting transmission participant device (100). Thereafter, in step 805, the transmission control server 102 is configured to send a transmission end notification message to at least one media receiving client. As an example, the transmission end notification message indicates the end of the transmission from the transmission participant device (100).

In one implementation, the method 800 further configures the transmission control server 102 to determine whether there are any media transmission requests in the queue. If there are any media transmission requests in the queue, the transmission control server 102 is configured to remove the media transmission requests from the queue. Thereafter, the transmission control server 102 may be configured to authorize the sending of the media stream to the second transmission participant device (100). In step 801, after sending a transmission end request message to a transmission participant device (100), the transmission control server (102) enters a "pending transmission cancellation" state.

In another implementation to step 803, that is, after receiving a transmission end response message from the transmission participant device (100), if the counter value (Cx) reaches the minimum limit during the simultaneous transmission of media streams, in The Transport Control Server (102) of the Universal Transport Control Operational State Machine enters the "Transfer Idle" state, or enters "Transfer Seized" if the counter value (Cx) has not reached the minimum limit. The counter Cx is the same as the counter C11 explained above. In particular, the transmission control server (102) in the general transmission control operation state enters the "transmission idle" state if no other transmission participant device 100 is transmitting media at this time, or if at least one transmission participant device 100 is transmitting media at this time , it enters the "Transfer Occupied" state.

In another implementation to step 803, that is, after receiving a transmission end response message from the transmission participant device (100), the transmission control server (102) operating in the basic transmission control operation state machine stops the timer T3. Timer T3 is defined as a transmission cancel timer. Additionally, the Transport Control Server (102) may be configured to enter the 'U: Not Allowed and Transport Idle' state.

As an example, a basic traffic control operation is one state machine per user, or a group general traffic control operation is one state machine per group. For example, if there exists in a group call of three users [MC device], there may be one instance of general transport control operation state machine and three instances of basic transport control operation [one instance/user/group] in the server.

FIG. 9 shows a flowchart for processing media transmissions in the transmission control server 102 according to an embodiment of the present disclosure. Referring to FIG. 9 , the method 900 may be implemented in the transmission control server 102 of the MC system 200 as shown in FIG. 2 . Here, explanations will be made with reference to FIGS. 2 to 8 in combination. In an implementation in transport control server 102, method 900 may be performed. The method disclosed in FIG. 9 is according to another embodiment of the transmission control server 102 disclosed in FIGS. 5 and 8 .

According to FIG. 9 , at step 901 , the method 900 includes the transmission control server 102 authorizing the first transmission participant device 100 to send media streams to a plurality of MC devices 101 . Thereafter, in step 903 , the transmission control server 102 may be configured to send a “media transmission notification” message to at least one MC device 101 to receive the media stream transmitted by the first transmission participant device 100 . At step 905 , the transmission control server 102 may be configured to receive a “receive media request” message from the at least one MC device 101 to receive a media stream from the first transmission participant device 100 . After step 905 , at step 907 , the transmission control server 102 sends a “Receive Media Response (Authorization)” message to at least one MC device 101 to indicate authorization to receive media streams from the first transmission participant device 100 . Thereafter at step 909 , the transmission control server 102 is configured to receive a “media reception end request” message to terminate reception from at least one MC device 101 . In step 911, the transmission control server 102 is configured to send a "media reception end response" to indicate a termination response of media stream reception. Afterwards, in step 913, the transport control server 102 determines that at least one MC device 101 is not receiving the media stream. This determination is based on the expiration of a predetermined duration of timer T11 (stream reception idle). Now at step 915, the transport control server 102 enters a "receive idle" state based on the counter (C11) value. The counter value provides a count of active receivers that are receiving the media stream.

For example, the counter C11 value is initialized to zero. Furthermore, the counter C11 is associated with at least one transmitter synchronization source (SSRC) or user ID of the MC device 101 . Furthermore, a timer T11 is defined as a stream reception idle timer, which is started with a predetermined duration after the transmission control server 102 sends a "media transmission notification" message to at least one MC device 101 or if the counter (C11) value reaches a minimum limit .

As another example, for each "Receive Media Response (Authorization)" sent to MC Device 101, the counter C11 value is incremented by 1, and for each "Media Receive End Request" or "Media Receive End Request" received from MC Device 101 Response" message, the value of counter C11 is reduced by 1.

As another example, if at least one MC device 101 receives a media stream from a transfer participant device (100) by sending an authorization grant via a receive media request (authorization) message, or by a transfer control server (102) by sending an authorization request to at least one MC device 101 sends a "transmission end notification" message to end the media transmission, then the transmission control server 102 may disable the timer (T11). Therefore, after the timer T11 (stream reception idle expires) expires, the MC server sends an indication to terminate the transmission. The various state machine diagrams for the various entities mentioned above will be explained in detail in the subsequent paragraphs.

FIG. 10 shows a state diagram of "transfer participant basic transfer control operations" according to an embodiment of the disclosure. Therefore, a new procedure has been added to receive a transfer end request from the server 102 and send a transfer end response from the transfer participant device 100 . The state diagram explained in FIG. 10 corresponds to the method 700 explained in FIG. 7 . An explanation of similar steps is avoided for the sake of brevity of the present disclosure. The details of the state machine are explained below:

In one embodiment, when the state 1001 'permission to send has been obtained' is reached, and when a 'transmission end request message' 1003, 1005 is received from the transmission control server 102, the transmission participant device 100 performs the following steps:

1. The user shall be notified that the permission to send RTP media is being revoked;

2. Can provide users with information on the reasons for terminating the authorization to send media;

3. The media in the MCVideo client 103 should be requested to discard any remaining cached RTP media packets and stop forwarding the encoded video to the MCVideo server 102; and

4. A transfer end response message should be sent to the transfer control server 102 .

5. If the session is not a broadcast group call, or if the A bit in the Transmission Indicator field is set to '1' (normal call), then the 'U: No permission to send' state shall be entered; and

6. If the session was started as a broadcast group call:

a. The MCVideo client 103 should be indicated that the media transfer is complete; and

b. Should enter the "release call" state.

FIG. 11 shows a state diagram of "Transport Control Server Generic Transport Control Operations" according to an embodiment of the present disclosure. Therefore, a new process was added to handle the end-of-transfer request message and forward it to the "Transmission Control Server Basic Transmission Control State Machine". The state diagram explained in FIG. 11 corresponds to the methods 500 , 800 , 900 explained in FIGS. 5 , 8 , 9 . An explanation of similar steps is avoided for the sake of brevity of the present disclosure. The details of the state machine are explained below:

In one embodiment, in state 1101 'G: Transfer Seized', and upon receiving a Transfer End Request message, the transfer control arbitration logic in the transfer control server 102 performs the following operations:

1. If running, stop timer T4 (transfer authorization);

2. Shall include a Rejection Reason field with <Rejection Reason> value set to #8 (no receiving participant);

i. may include an additional text string explaining the reason for denying the transfer request in the value of the Deny Reason field's <Rejection Words>; and

3. The 'G: Pending Transfer Cancellation' state shall be entered.

According to one embodiment, the transmission control arbitration logic in the transmission control server 102 uses the 'G: pending transmission withdrawal' state 1109 after sending a transmission withdrawal or transmission end request message to an allowed transmission participant device 100 . In this state, the MCVideo server 102 forwards the RTP media packets to other transport participant devices 100 in the MCVideo call.

As an example, the functionality of the Transfer End Request message and Transfer Cancel message sent from the server 102 is the same on both the client and server side, currently the processing of the Transfer End Request message is added in the 'G: Pending Transfer Cancel' state . New states can also be created later if required for this purpose.

According to one embodiment, upon entering the 'G: Pending Transfer Withdrawal' state 1109, the transfer control arbitration logic in the transfer control server:

1. A transfer cancel or transfer end request message shall be sent to the permitted transfer participants. Transmission withdraw or transmission end request message:

a. The reason for sending the "Transfer Withdrawal Message" or "Transfer End Request" shall be included in the <Rejection Reason> value in the Rejection Reason field; and

b. If the group call is a broadcast group call, a system call, an emergency call, an impending permanent call, or an ad hoc group session, include a transmission indicator field with appropriate indication; and

2. The general status shall be set to 'G: Pending transfer withdrawn'.

In one embodiment, in state 'G: Pending Transfer Cancellation' 1109, upon receipt of a Transfer End Response message, the transfer control arbitration logic in the transfer control server:

1. shall request the media distributor in the MCVideo server to stop forwarding RTP media packets for the requested transmission participant; and

2. If Cx (simultaneous video transmission) does not reach its lower limit, then decrement Cx (simultaneous video transmission) by 1;

3. If Cx (simultaneous video transmission) has reached the lower limit, enter the 'G: transmission idle' state.

4. If Cx (simultaneous video transmission) has not reached the lower limit, and if the queue of active transmission requests is not empty, the transmission control server:

a. A queued transfer request shall be selected from the top of the active transfer request queue;

b. The queued transfer request shall be removed from the active transfer request queue; and

c. The 'G: Transfer Seized' state should be entered.

FIG. 12 shows a state machine diagram for "Transport Participant-Oriented Transport Control Server Basic Transport Control Operations" according to an embodiment of the present disclosure. Therefore, new procedures have been added to send a transfer end request from the server 102 to the transfer participant device 100 and to process the transfer end response from the transfer participant. The state diagram explained in FIG. 12 corresponds to the methods 500 , 800 , 900 explained in FIGS. 5 , 8 , 9 . An explanation of similar steps is avoided for the sake of brevity of the present disclosure. The details of the state machine are explained below:

In one embodiment, in state 1201 'U:Allow', when receiving a transmission end request message from the transmission control server, the transmission control interface towards the MCVideo client in the transmission control server:

1. The "Transfer End Request" message shall be forwarded to the relevant transfer participants; and

2. The status 'U Pending Transmission Cancelled' shall be entered.

As an example, in one embodiment, in state 1203 'U: Pending Transfer Withdrawal', during the grace period after sending a Transfer Withdrawal or Transfer End Request message, the send control interface to the MCVideo client in the transfer control server uses the status.

In this state, timer T3 (transfer cancel) runs.

As another example, the functionality of a Transfer End Request message and a Transfer Cancellation message sent from the server is the same on both the client and server side, currently adding the processing of the Transfer End Request message in the 'U: Pending Transfer Cancellation' state, And the timer T3 (transmission cancel) is also used for the transmission end request message. A new state and timer can then also be created for this purpose, if desired.

In one embodiment, in state 'U: Pending Transmission Cancellation' 1203, upon expiry of timer T3 (Transmission Cancellation), the transmission control interface towards the MCVideo client in the transmission control server:

1. A "Transfer Cancellation" or "Transfer End Request" message shall be resent to the associated transfer participant. Transmission withdraw message or transmission end request:

a. SHOULD include the same Rejection Reason field and the same Transmission Indicator field as in the previously sent Transfer Cancel message or Transfer End Request;

2. Timer T3 (Transfer Cancellation) shall be started; and

3. Should remain in the 'U: Pending Transfer Cancellation' state.

In a further implementation, the number of times the transmission control server resends a transmission withdraw message or transmission end request and the action taken when the transmission control server gives up is an implementation option. However, it is recommended to disconnect the MCVideo client from the MCVideo call when the Transport Control Server gives up.

In one embodiment, in state 'U: Pending Transfer Cancellation' 1203, upon receipt of a Transfer End Response message from an associated Transfer Participant, the Transfer Control Interface faces the MCVideo Client in the Transfer Control Server:

1. If the first bit in the Subtype of the Transmission End Response message is set to '1' (acknowledgment required), then a Transmission Control Ack message shall be sent. Transmission Control Ack message:

a. SHOULD include a Message Type field set to '1' (Transmission End Response); and

b. SHOULD include a source field set to '2' (Control MCVideo function is source);

2. If timer T3(transfer cancel) is running, timer T3(transfer cancel) shall be stopped; and

3. SHOULD forward the Transfer End Response message to the Transfer Control Server arbitration logic; and

4. The status 'U: not allowed and 'transmission idle' should be entered.

FIG. 13 shows a state machine diagram for general receive control operations of a transport control server according to an embodiment of the present disclosure. Therefore, new timers and new counters are introduced. When no MCVideo user is receiving the stream, even if the stream is currently being sent from other MCVideo users, a new timer will be started. And the new timer can be stopped when at least one user is granted permission to receive the stream. A new counter is used to track the count of active receiving users for this stream. When there are no active receivers for a stream, the general reception control operation state machine will notify the transmission control arbitration logic to terminate the ongoing transmission. The state diagram explained in FIG. 13 corresponds to the methods 500 , 800 , 900 explained in FIGS. 5 , 8 , 9 . An explanation of similar steps is avoided for the sake of brevity of the present disclosure. The details of the state machine are explained as follows:

In one embodiment, in state 1301 'Gr: Receive Idle', upon receiving a media transmission request notification, the reception control arbitration logic in the transmission control server 102:

1. A media transfer notification message shall be sent to all other transfer participants. Media transfer notification message:

a. If the group call is a broadcast group call, a system call, an emergency call, or an upcoming call, it should include the receiving mode, and the receiving mode field is set to '0' to indicate the automatic receiving mode;

b. If the group call is not a broadcast group call, a system call, an emergency call, or an impending call, then a Receive Mode field indicating that Manual Receive Mode is set to '1' shall be included.

2. Timer T11 (Stream Receive Idle) should be started and associated with the transmitter SSRC or UserId.

3. The counter C11 (count of active receivers for the stream) should be initialized to '0' and associated with the transmitter SSRC or UserId.

4. Should remain in 'Gr: Receive Idle' state.

In one embodiment, in state 1301 'Gr: Receive Idle', upon receiving a receive media request message, the receive control arbitration logic in the transmission control server 102:

1. If "Receive Media Request" is rejected:

a. A "Media Response Received (Rejected)" message should be sent. "Received Media Response" message:

i. Set the first bit in the subtype of the received Media Response message to '1' (confirmation required), send a Transmission Control Ack message; and

ii. SHOULD include a Result field set to '0' (Receive Media Rejected); and

b. shall remain in the 'Gr: Receive Idle' state; or

2. If "receive media requests" is authorized:

a. Timer T5 should be stopped (reception inactive);

b. If it is already running, stop timer T11 (stream receive idle);

c. Increment the counter C11 (count of active receivers of the stream) associated with the transmitter SSRC by 1;

d. The SSRC of the transfer participant requesting to receive the media shall be stored until the reception associated with that send request is complete;

e. A Receive Media Response message should be sent. Receive media response message:

i. Set the first bit in the subtype of the received Media Response message to '1' (confirmation required), send a Transmission Control Ack message; and

ii. SHOULD include the Result field set to '1' (Authorized Receiving Media);

f. If C7 (Accept Receive) has not reached its upper limit, it should be increased by 1; and

g. The status 'Gr: Accepted Received' should be entered.

In one embodiment, in state 1301 'Gr: Receive Idle', upon receiving an end-of-transmission notification, the reception control arbitration logic in the transmission control server 102:

1. A "transfer end notification" message should be sent to all other transfer participants.

2. If running, timer T11 associated with transmitter SSRC should be stopped (stream reception idle);

3. Should remain in 'Gr: Receive Idle' state.

In one embodiment, in state 1301 'Gr: Receive Idle', upon expiration of timer T11 (Stream Receive Idle), the receive control arbitration logic in the transport control server 102:

1. Should communicate with the transport control arbitration logic in the transport control server to terminate the flow associated with the expired timer T11.

2. Should remain in 'Gr: Receive Idle' state.

As an example, it is determined based on the MCVideo server 102 local policy to terminate the stream by sending a transport cancel message or a transport end request message.

In one embodiment, in state 1303 'Gr: Receive Accepted', upon receiving the receive media request message, the receive control arbitration logic in the transmission control server 102:

1. If you refuse to receive a media request:

a. A Receive Media Response (Reject) message should be sent. Receive media response message:

i. Set the first bit in the subtype of the received Media Response message to '1' (confirmation required), send a Transmission Control Ack message; and

ii. SHOULD include a Result field set to '0' (Receive Media Rejected); and

b. shall remain in 'Gr: Accepted' status; or

2. If the receive media request is authorized:

a. Timer T5 should be stopped (inactive);

b. If running, the timer T11 associated with the transmitter SSRC (stream reception idle) shall be stopped;

c. Increment the counter C11 (count of active receivers of the stream) associated with the transmitter SSRC by 1;

d. shall store the SSRC of the transfer participant requesting to receive the media until the reception associated with that transfer request is complete;

e. A Receive Media Response (Authorization) message should be sent. Receive media response message:

i. Set the first bit in the subtype of the received Media Response message to '1' (confirmation required), send a Transmission Control Ack message; and

ii. SHOULD include the Result field set to '1' (Authorized Receiving Media);

f. Timer T6 should be started (receive authorization);

g. If C7 (Accept Receive) has not reached its upper limit, it should be increased by 1; and

h. Should remain in the 'Gr: Accept Received' state.

In one embodiment, in the state 1303Gr: accept receiving', when receiving the receiving media end request message, the receiving control arbitration logic in the transmission control server:

1. A Receive Media End Response message should be sent. Receive media end response message:

i. Receive Media End Response message with first bit in Subtype set to '1' (acknowledgment required), Transmission Control Ack message shall be sent.

ii. SHOULD include a Message Type field set to 'y' (Authorized to Receive Media End);

2. Timer T6 (receive authorization) should be stopped;

3. If the counter C11 (count of active receivers for the stream) has not reached its lower limit, decrement the counter C11 by 1;

4. If C11 has reached its lower limit, timer T11 (stream reception idle) should be started.

5. If the lower limit is not reached, decrement C7 (acceptance) by 1;

6. If C7 has not reached its lower limit, it should remain in the 'Gr: Accept Received' state.

7. If C7 has reached its lower limit, it shall enter the 'Gr: Receive Idle' state.

As an example, when all participants have stopped receiving, the decision to start the same timer T11 or a new timer can be made based on the MCVideo server local policy.

In one embodiment, in the state 1303 'Gr: accept receiving', when receiving the receiving media end response message, the receiving control arbitration logic in the transmission control server 102:

1. If the first bit in the subtype of the Receive Media End Response message is set to '1' (acknowledgment required), then a Transmission Control Acknowledgment message shall be sent.

2. Timer T6 (receive authorization) should be stopped;

3. If the counter C11 (count of active receivers for the stream) has not reached its lower limit, decrement the counter C11 by 1;

4. If C11 has reached its lower limit, timer T11 (stream reception idle) should be started.

5. If the lower limit is not reached, decrement C7 (acceptance) by 1;

6. If C7 has not reached its lower limit, it should remain in the 'Gr: Accept Received' state.

7. If C7 has reached its lower limit, it should enter the 'Gr: Receive Idle' state.

In one embodiment, in state 1303 'Gr: accepting reception', upon receiving a media transmission request notification message from the reception control arbitration logic in the transmission control server 102:

1. A media transfer notification message shall be sent to all other transfer participants. Media transfer notification message:

a. If the group call is a broadcast group call, a system call, an emergency call, or an upcoming call, the receive mode shall be included, with the receive mode field set to "0" indicating automatic receive mode; and

b. If the group call is not a broadcast group call, a system call, an emergency call, or an upcoming call, the receive mode shall be included, with the receive mode field set to '1' indicating manual receive mode; and

2. Timer T11 (Stream Reception Idle) should be started and associated with the transmitter SSRC or UserId present in the Media Transfer Notification message.

3. The counter C11 (count of active receivers of the stream) should be initialized to 0 and associated with the transmitter SSRC or UserId present in the media transfer notification message.

4. Should remain in the 'Gr: Accept Received' state.

In one embodiment, in state 1303 'Gr: accepting reception', upon receiving a transmission end notification message, the reception control arbitration logic in the transmission control server 102:

1. A media transfer end notification message shall be sent to all other transfer participants.

2. If running, timer T11 associated with transmitter SSRC should be stopped (stream reception idle);

3. C7 (acceptance) should be lowered by the value of C11 (count of active receivers for the stream) relative to the transmitter SSRC; in one implementation, the difference between the values of C7 and C11 can be considered to be used to determine the transmission control server The counter value of the state of 102. Specifically, after the counter value reaches the minimum limit, the transmission control server 102 enters the "receiving idle" state, otherwise the transmission control server 102 enters the "accepting reception" state.

4. If C7 has not reached its lower limit, it should remain in the Gr: Accept Received' state.

5. If C7 has reached its lower limit, it shall enter the 'Gr: Accept Idle' state.

In one embodiment, in state 1303 'Gr: accepting reception' when timer T11 expires (stream reception is idle), the reception control arbitration logic in the transmission control server:

1. Should communicate with the transport control arbitration logic in the transport control server to terminate the flow associated with the expired timer T11.

2. Should remain in the 'Gr: Accept Receive' state.

As an example, the decision to terminate the stream by sending a Transmission Cancel message or a Transmission End Request message is based on the MCVideo server local policy.

In one embodiment, when the transport stream is terminated due to the expiration of the T11 timer, the transmission end request sent from the transport control server 102 with rejection reason #8 is explained in detail below.

Reason #8 - No Receiver

A <Deny Reason> value set to '8' indicates that the MCVideo Client's permission to send media is being revoked due to no participants receiving the stream.

In one embodiment, a Reject Reason Value field is added to the end of transfer request message to indicate the reason for ending the transfer. The basic format of the transmission end request message can be seen in Table 1:

[Table 1]

Denial Reason:

The Rejection Reason field of the Transfer End Request message includes a <Rejection Reason> reason value in the Rejection Reason field, explaining why the transfer control server wants the transfer participant to stop transferring the media, and may be followed by additional information. Therefore, the length of the packet can vary depending on the value of the reason for rejection.

In one embodiment, a timer T11 (stream receive idle) is used in the transport control server 102 . Even if the stream is currently being sent from other MCVideo users, the timer will be started when no MCVideo user is receiving the stream. The timer can be stopped when at least one user is authorized to receive the stream basic details of the timer T11 shown in Table 2.

[Table 2]

In one embodiment, a counter C11 (count of active receivers for a stream) used in the transport control server 102 stores a count of active receiving users for the stream. The basic details of counter C11 are shown in Table 3.

[table 3]

Accordingly, gathering this disclosure from the foregoing provides the following procedure:

1. Handling end-of-transport[TM] request and response messages and state transitions based on that message handling on both the client and server side.

2. A new counter [C11 (Count of active receivers for flow)] is introduced to store the count of active receivers per flow. Implemented counter initialization/increment/decrement based on different message processing and state transition based on counter value.

3. A new timer [T11 (Stream Receive Idle)] and timer stop/start/expiration handling in the server state machine is being implemented.

4. A method to terminate a stream, with the help of the newly introduced "Rejection Reason Value" field and a reason to notify the reason for termination when no users are receiving the stream. Handle any race conditions in the server in the Transport[TM] End Request message.

Therefore, the present disclosure avoids the waste of network resources and gives other participants in the group the opportunity to transmit important data when the maximum number of transmissions in a group call is limited by network capacity. This solution improves the efficiency of mission critical video (MCVideo) systems in high network congestion situations where mission critical video systems typically operate.

Fig. 14 shows another exemplary implementation according to an embodiment of the present disclosure. FIG. 14 shows another exemplary hardware configuration of a system 1400 in the form of a computer system 1400 . Computer system 1400 may include a set of instructions executable to cause computer system 1400 to perform any one or more of the disclosed methods. Computer system 1400 may operate as a standalone device or may be connected to other computer systems or peripheral devices, eg, using a network.

In a networked deployment, computer system 1400 may operate in a server capacity, or as a client user computer in a server-client user network environment, or as a peer computer in a peer-to-peer (or distributed) network environment system operation. Computer system 1400 can also be implemented as or incorporated in various devices, such as personal computers (PCs), tablet PCs, personal digital assistants (PDAs), mobile devices, palmtops, laptops, desktops, A communication device, wireless telephone, landline telephone, network device, network router, switch or bridge, or any other machine capable of executing a set of instructions (sequential or otherwise) specifying actions to be taken. through the machine. In addition, while a single computer system 1400 is illustrated, the term "system" shall also be taken to include any collection of systems or subsystems that individually or jointly execute one or more sets of instructions to perform one or more computer functions.

Computer system 1400 may include a processor 1402, such as a central processing unit (CPU), a graphics processing unit (GPU), or both. Processor 1402 may be a component in various systems. For example, processor 1402 may be part of a standard personal computer or workstation. Processor 1402 can be one or more general purpose processors, digital signal processors, application specific integrated circuits, field programmable gate arrays, servers, networks, digital circuits, analog circuits, combinations thereof, or other now known or later developed equipment for analyzing and processing data. Processor 1402 may implement a software program, such as manually (ie, programmed) generated code.

Computer system 1400 can include memory 1404 , such as memory 1404 that can communicate via bus 1408 . Memory 1404 may include, but is not limited to, computer-readable storage media, such as random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, Various types of volatile and non-volatile storage media such as tape or disk, optical media, etc. In one example, memory 1404 includes cache memory or random access memory for processor 1402 . In alternative examples, the memory 1404 is separate from the processor 1402, such as the processor's cache memory, system memory, or other memory. Memory 1404 may be an external storage device or a database for storing data. The memory 1404 is operable to store instructions executable by the processor 1402 . Functions, acts or tasks shown or described in the figures can be performed by programmed processor 1402 to execute instructions stored in memory 1404 . Functions, acts or tasks are independent of a particular type of instruction set, storage medium, processor or processing strategy and may be performed by software, hardware, integrated circuits, firmware, microcode, etc. operating alone or in combination. Likewise, processing strategies may include multiprocessing, multitasking, parallel processing, and the like.

As shown, computer system 1400 may or may not include a display unit 1410 such as a liquid crystal display (LCD), organic light emitting diode (OLED), flat panel display, solid state display, cathode ray tube (CRT), projector, printer, or Other now known or later developed display devices for outputting certain information. Display 1410 may serve as an interface for a user to view functions of processor 1402 , or specifically, software stored in memory 1404 or drive unit 1416 .

Additionally, computer system 1400 may include an input device 1412 configured to allow a user to interact with any of the components of system 1400 . Computer system 1400 may also include a disk or optical drive unit 1416 . The disk drive unit 1416 may include a computer readable medium 1422 in which one or more sets of instructions 1424, such as software, may be embedded. Additionally, instructions 1424 may include one or more of the methods or logic described. In particular examples, instructions 1424 may reside, completely or at least partially, within memory 1404 or within processor 1402 during execution by computer system 1400 .

The invention relates to a computer-readable medium containing instructions 1424 or receiving and executing instructions 1424 in response to a propagated signal such that devices connected to a network 1426 can transmit voice, video, audio, images or any other data via the network 1426 . Additionally, instructions 1424 may be sent or received over a network 1426 via communications port or interface 1420 or using bus 1408 . Communication port or interface 1420 may be part of processor 1402, or may be a separate component. Communication port 1420 can be created in software, or can be a physical connection in hardware. Communication port 1420 may be configured to interface with network 1426, external media, display 1410, or any other component in system 1400, or a combination thereof. The connection to network 1426 may be a physical connection, such as a wired Ethernet connection, or may be established wirelessly as discussed later. Likewise, additional connections to other components of system 1400 may be physical or may be established wirelessly. Alternatively, network 1426 may be directly connected to bus 1408 .

The network 1426 may include a wired network, a wireless network, an Ethernet AVB network, or a combination thereof. The wireless network can be a cellular telephone network, 802.11, 802.16, 802.20, 802.1Q or WiMax network. Additionally, network 1426 can be a public network, such as the Internet, a private network (e.g., an intranet), or a combination thereof, and can utilize various networking protocols now available or later developed, including but not limited to TCP/IP-based networking protocols . The system is not limited to operation with any particular standard and protocol. For example, standards for Internet and other packet-switched network transports (eg, TCP/IP, UDP/IP, HTML, and HTTP) may be used.

Figure 15 illustrates a block diagram of a MC device according to an embodiment of the invention.

Referring to FIG. 15 , an MC device 1500 of an embodiment of the present disclosure includes a transceiver 1510 , a controller 1520 and a memory 1530 .

The transceiver 1510 is capable of transmitting/receiving signals to/from other MC devices, servers or entities according to an embodiment of the present disclosure.

The controller 1520 can control the operation of the MC device 1500 . The controller 1520 can control the MC device 1500 to perform operations related to the MC device 1500 as described in the embodiments of the present disclosure.

The memory 1530 can store at least one of information related to the MC device 1500 and information transmitted/received via the transceiver 1510 .

FIG. 16 shows a block diagram of an MC server according to an embodiment of the present disclosure.

Referring to FIG. 16 , an MC server 1600 of an embodiment of the present disclosure includes a transceiver 1610 , a controller 1620 and a memory 1630 . The MC server 1600 may be a transmission control server as described in an embodiment of the present disclosure.

The transceiver 1610 is capable of transmitting/receiving signals to/from other MC devices, servers, or entities according to an embodiment of the present disclosure.

The controller 1620 can control the operation of the MC server 1600 . The controller 1620 can control the MC server 1600 to perform operations related to the MC server 1600 as described in the embodiments of the present disclosure.

The memory 1630 can store at least one of information related to the MC server 1600 and information transmitted/received via the transceiver 1610 .

According to an embodiment of the present disclosure, a method of processing media transmission in a mission critical (MC) system is provided. The MC server receives a request from the first sender to send a media stream to at least one receiver; the MC server sends a notification to at least one receiver to receive the media stream sent by the first sender; Timer of the duration; the notification of receiving the media stream is determined by the MC server to be rejected or not accepted by at least one receiver within the predetermined duration of the timer; Accept one of the media stream receptions to terminate the media stream send request.

In an embodiment of the present disclosure, wherein after sending the notification to the at least one receiver, the method further includes: checking, by the MC server, acceptance of the sent media by the at least one receiver; and Terminating, by the MC server, transmission of the media stream from the first sender device based on one of rejection or non-acceptance of receipt of the media stream by the at least one receiver.

In an embodiment of the present disclosure, the method further includes receiving, by the MC server, an end-of-transmission response from the first sender in response to sending an end-of-transmission request, wherein the end-of-transmission request includes a reason for ending the transmission, and wherein the reason for ending the transmission is due to Missing at least one sink for receiving media streams.

In an embodiment of the present disclosure, the method further includes authorizing, by the MC server, the second sender to transmit a new media stream to the at least one recipient after sending the transmission end request to the first sender.

In an embodiment of the present disclosure, the method further includes accepting a notification of receiving a media stream, including: the MC server receives a request for receiving a media stream from at least one receiver; the MC server sends a response to the at least one receiver to notify receiving an authorization grant; and incrementing a counter value by one for each active receiver from the at least one receiver upon receipt of the authorization.

In an embodiment of the present disclosure, the method further includes receiving, by the MC server, a request to terminate media stream reception from at least one receiver; the MC server sends a response indicating that media stream reception is terminated; Each termination of the media stream, the counter value is decremented by 1; the MC server determines that at least one receiver has not received the media stream based on the expiration of the timer; the MC server enters the "receive idle" state based on the counter value.

In an embodiment of the present disclosure, the method further includes: when the counter value reaches a minimum predetermined value after each counter value is decremented, or when the MC server sends a "media transmission notification" message to the MC device, restarting the Start the timer.

In an embodiment of the present disclosure, the method further includes terminating the timer by the MC server based on at least one of the following: a) if at least one receiver accepts the notification to receive the media; or b) if the media transmission is sent by the transmission control server 102 via end of transmission with a notification message.

In an embodiment of the present disclosure, wherein after the timer expires, the MC server sends a transmission end request to the first sender to terminate the transmission.

In an embodiment of the present disclosure, wherein the first sender and the at least one receiver belong to the same group of MC devices, and wherein the media stream includes at least one of video and audio data.

According to another embodiment of the present disclosure, a method of processing media transmission in a mission critical (MC) system is provided. The MC device receives a transmission end request for terminating the media stream transmission from the MC server; the MC device notifies the user associated with the MC device of the reason for terminating the media stream transmission, wherein the reason for terminating the transmission is due to the lack of at least one user for receiving the media stream. The receiver device of the stream; the MC device sends a transmission end response to the MC server; the MC device terminates sending the media stream to the MC server.

According to another embodiment of the present disclosure, a method of processing media transmission in a mission critical (MC) system among multiple MC devices is provided. The method includes: receiving a transmission end request from the transmission control server 102 by the transmission participant device 100; notifying the user associated with the transmission participant device 100 of a media stream termination reason indicating authorization of the client to send the media by the transmission participant device 100 revoked due to lack of at least one participant device to receive the media stream; a transmission end response sent by the transfer participant device 100 to the transfer control server 102 ; and sending of the media stream to the transfer control server 102 terminated by the transfer participant device 100 .

In the disclosed embodiment, the method further includes entering, by the transmitting participant device 100, a "call release" state for a broadcast group call or a "not allowed to send" state for a normal or non-broadcast group call, wherein the transmitting participant Device 100 is MC device 101 and is associated with the same group.

According to another embodiment of the present disclosure, a method of handling media transmission in a mission critical (MC) system in a transmission control server 102 is provided. The method comprises: when the timer (T11) defined as the flow receiving idle timer expires, the transmission control server 102 sends a transmission end request message for terminating the media flow to the transmission MC device; The participant device 100 receives the transmission end response; and the transmission control server 102 sends a transmission end notification message to at least one media receiving client, wherein the transmission end notification message indicates the transmission end from the transmission participant device 100 .

In an embodiment of the present disclosure, the method further includes: determining by the transmission control server 102 whether there is any media transmission request in the queue; the transmission control server 102 removing the media transmission request from the queue; The second transmission participant device 100 sends the permission of the media stream, wherein after sending the transmission end request message to the transmission participant device 100, the transmission control server 102 enters the "pending transmission withdrawal" state.

In an embodiment of the present disclosure, where after receiving a transmission end response message from the transmission participant device 100, if the counter value (Cx) reaches the minimum limit during the simultaneous transmission of the media stream, the general transmission control operation state machine The transmission control server 102 enters the "transmission idle" state, or if the counter value (Cx) has not reached the minimum limit, enters the "transmission busy".

In an embodiment of the present disclosure, where after receiving a transmission end response message from a transmission participant device 100, the transmission control server 102 operating in the basic transmission control operation state machine stops a timer defined as a transmission cancellation timer ( T3), and enter the 'U: not allowed and transmission idle' state.

In an embodiment of the present disclosure, wherein the end-of-transmission request includes at least one of the reasons of "no receiving participant" in the "reject reason" field of the end-of-transmission request to indicate the reason for terminating the media stream.

According to another embodiment of the present disclosure, a method of handling media transmission in a mission critical (MC) system in a transmission control server 102 is provided. The method includes: the transmission control server 102 authorizes the first transmission participant device 100 to transmit media streams to multiple MC devices 101; A media stream transmitted by the transmission participant device 100; the transmission control server 102 receives a "receive media request" message from at least one MC device 101 to receive the media stream from the first transmission participant device 100; the transmission control server 102 sends at least one An MC device 101 sends a "Receive Media Response (Authorization)" message to indicate the authorization to receive the media stream from the first transmission participant device 100; the transmission control server 102 receives the "Media Receive End Request" message to terminate the request from at least one MC. Reception by device 101; a "media reception end response" sent by transport control server 102 to indicate a termination response for media stream reception; determination by transport control server 102 based on expiration of a predetermined duration of timer T11 that at least one MC device 101 has not receiving the media stream; and entering a "receive idle" state by the transport control server 102 based on a counter (C11) value defined as a count of active receivers for the media stream.

In an embodiment of the present disclosure, wherein the value of the counter C11 is initialized to 0, wherein the counter C11 is associated with the transmitter synchronization source (SSRC) or user ID and the timer (T11) of the at least one MC device, the timing A timer (T11) is defined as a stream reception idle timer started with a duration after the transmission control server 102 sends a "media transmission notification" message to the at least one MC device 101.

In the embodiment of the present disclosure, wherein for each of the "Receive Media Response (Authorization)" sent to the MC device 101, the value of the counter C11 is incremented by 1, and for the "Media Reception End Request" received from the MC device 101 or For each of the "media reception end response" messages, the value of the counter C11 is decremented by 1.

In an embodiment of the present disclosure, wherein the timer (T11) starts with a duration based on at least one of the following: (a) the counter (C11) value reaches a minimum limit; after the news.

In an embodiment of the present disclosure, wherein the timer (T11) is disabled by the transport control server 102 based on at least one of the following: (a) at least one MC device 101 is authorized to send an authorization grant via receiving a media request (authorization) message from The transmission participant device 100 receives the media stream; or (b) the media transmission is ended by the transmission control server 102 by sending a "transmission end notification" message to at least one MC device 101 .

In the embodiment of the present disclosure, the MC server sends an instruction to terminate the transmission after the timer T11 expires.

According to another embodiment of the present disclosure, an MC server for handling media transmission in a mission critical (MC) system is provided. The MC server includes one or more processors configured to: receive a request from a first sender to send a media stream to at least one receiver; send a notification to the at least one receiver to receive a media stream sent by the first sender; after sending the notification, starting a timer with a predetermined duration; determining that the at least one receiver refuses or does not accept receiving the notification within the predetermined duration of the timer a notification of the media stream; and a request to terminate transmission of the media stream based on one of denial or non-acceptance of receipt of the media stream sending an end-of-transmission request to the first sender.

According to another embodiment of the present disclosure, an MC device for handling media transmission in a mission critical (MC) system is provided. The MC device includes one or more processors configured to: receive an end-of-transmission request from the MC server to terminate the media streaming; notify a user associated with the MC device of a reason for terminating the media streaming, wherein the reason for terminating the transmission The reason is due to lack of at least one receiver device for receiving the media stream; sending a transmission end response to said MC server; and terminating the media stream to the MC server.

According to another embodiment of the present disclosure, a transfer participant device for handling media transfer in a mission critical (MC) system among a plurality of MC devices 101 is provided. The transfer participant device includes one or more processors configured to: receive a transfer end request from the transfer control server 102; notify a user associated with the transfer participant device of the termination of the media stream indicating the client's authorization to send media The cause is revoked due to lack of at least one participant device to receive the media stream; a transmission end response is sent to the transmission control server 102; and transmission of the media stream to the transmission control server 102 is terminated.

According to another embodiment of the present disclosure, a transmission control server for handling media transmission termination in a mission critical (MC) system is provided. The transmission control server includes one or more processors configured to: when a timer (T11) defined as a flow reception idle timer expires, send a transmission end request message to the sending MC device to terminate the flow of the media flow. transmitting; receiving a transmission end response from the transmission participant device 100; and sending a transmission end notification message to at least one media receiving client, wherein the transmission end notification message indicates the end of the transmission from the transmission participant device 100.

According to another embodiment of the present invention, a transport control server for handling media transport in a mission critical (MC) system is provided. The transmission control server includes one or more processors configured to: authorize the first transmission participant device 100 to send media streams to a plurality of MC devices 101; send a "media transmission notification" message to at least one MC device 101 to receiving a media stream transmitted by the first transmission participant device 100; receiving a "receive media request" message from the at least one MC device 101 to receive the media stream from the first transmission participant device 100; sending the at least one The MC device 101 sends a "Receive Media Response (Authorization)" message to indicate authorization to receive the media stream from the first transmission participant device 100; The reception of MC equipment 101; Send " media receives end response " to indicate the termination response that media stream receives; Based on the expiry of the predetermined duration of timer T11, determine that described at least one MC equipment 101 has not received media stream; And based on The counter (C11) value defined as the count of active receivers of the media stream enters the "Receive Idle" state.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The systems, methods and examples provided herein are illustrative only and not limiting.

Although specific language has been used to describe the inventive subject matter, no limitation is intended thereto. Various working modifications may be made to this method as will be apparent to those skilled in the art in order to carry out the inventive concepts taught herein. The drawings and foregoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be divided into multiple functional elements. Elements from one embodiment may be added to another embodiment.

Claims (15)

1. A method performed by a mission-critical MC server in a mission-critical MC system, the method comprising:

receiving a request message from a first MC device to send a stream to at least one second MC device;

transmitting a notification message to the at least one second MC device for receiving the flow transmitted by the first MC device, wherein a timer associated with reception of the flow is started and a counter value for a count of active receivers of the flow is initialized;

identifying that transmission of the flow is to be terminated based on expiration of the timer; and

sending a request message to the first MC device to end transmission of the stream.

2. The method of claim 1, further comprising:

receiving a request message for reception of the stream from the at least one second MC device; and

in case the reception of the flow is authorized, the timer is stopped and the counter is incremented by 1.

3. The method of claim 1, further comprising:

receiving a request message or a response message for ending reception of the stream from the at least one second MC device;

decreasing the counter value by 1 if the counter value does not reach a lower limit value; and

starting the timer if the counter value has reached the lower limit value.

4. The method of claim 1, further comprising:

sending a notification message to the at least one second MC device to end the flow and stopping the timer.

5. The method of claim 1, further comprising:

receiving a response message for ending transmission of the stream from the first MC device,

wherein:

the timer is associated with a synchronization source SSRC or a user ID of the first MC device,

the counter is associated with the SSRC or the user ID of the first MC device,

the request message to end transmission of the flow includes a deny reason value indicating that the reason why the first MC device was sending permission for the flow is being revoked is that no participant received the flow,

the stream comprises at least one of a media stream or a video stream, an

The MC server comprises a transmission control server in the MC server.

6. A method performed by a first mission-critical MC device in a mission-critical MC system, the method comprising:

transmitting a flow to at least one second MC device if the first MC device is authorized to transmit the flow;

receiving a request message from the MC server for ending transmission of the flow based on expiration of a timer associated with receipt of the flow being idle, and

sending a response message to the MC server for ending transmission of the stream.

7. The method of claim 6, wherein:

stopping the timer in case the counter value of the count of active receivers for the flow increases,

starting the timer in case the counter value has reached a lower limit value,

the timer is associated with a synchronization source SSRC or a user ID of the first MC device,

the counter is associated with the SSRC or the user ID of the first MC device,

the request message to end transmission of the flow includes a deny reason value indicating that the reason why the first MC device was sending permission for the flow is being revoked is that no participant received the flow,

the stream comprises at least one of a media stream or a video stream, an

The MC server comprises a transmission control server in the MC server.

8. A mission critical MC server in a mission critical MC system, the MC server comprising:

a transceiver; and

a controller configured to:

receiving a request message from a first MC device to send a stream to at least one second MC device via the transceiver,

transmitting, via the transceiver, a notification message to the at least one second MC device to receive the flow transmitted by the first MC device, wherein a timer associated with reception of the flow is started and a counter value for a count of active receivers of the flow is initialized;

identifying that transmission of the flow is to be terminated based on expiration of the timer; and

sending, via the transceiver, a request message to the first MC device to end transmission of the stream.

9. The MC server of claim 8, wherein the controller is further configured to:

receive a request message for reception of the flow from the at least one second MC device via the transceiver,

in case the reception of the flow is authorized, the timer is stopped and the counter is incremented by 1.

10. The MC server of claim 8, wherein the controller is further configured to:

receiving a request message or a response message for ending reception of the stream from the at least one second MC device via the transceiver;

decreasing the counter value by 1 if the counter value does not reach a lower limit value; and

starting the timer if the counter value has reached the lower limit value.

11. The MC server of claim 8, wherein the controller is further configured to:

sending a notification message to the at least one second MC device via the transceiver to end transmission of the flow and stopping the timer.

12. The MC server of claim 8, wherein the controller is further configured to:

receiving, via the transceiver, a response message from the first MC device to end transmission of the stream.

13. The MC server of claim 8, wherein:

the timer is associated with a synchronization source SSRC or a user ID of the first MC device,

the counter is associated with the SSRC or the user ID of the first MC device,

the request message to end transmission of the flow includes a deny reason value indicating that the reason why the first MC device was sending permission for the flow is being revoked is that no participant received the flow,

the stream comprises at least one of a media stream or a video stream, an

The MC server comprises a transmission control server in the MC server.

14. A first mission-critical MC device in a mission-critical MC system, the first MC device comprising:

a transceiver; and

a controller configured to:

transmitting a flow to at least one second MC device via the transceiver in the event that the first MC device is authorized to allow the flow to be transmitted;

receiving, via the transceiver, a request message from the MC server for ending transmission of the flow based on expiration of a timer associated with receipt of the flow being idle, and

sending a response message to the MC server via the transceiver to end transmission of the stream.

15. The first MC device of claim 14, wherein:

stopping the timer in case the counter value of the count of active receivers for the flow increases,

starting the timer in case the counter value has reached a lower limit value,

the timer is associated with a synchronization source SSRC or a user ID of the first MC device,

the counter is associated with the SSRC or the user ID of the first MC device,

the request message to end transmission of the flow includes a deny reason value indicating that the reason why the first MC device was sending permission for the flow is being revoked is that no participant received the flow,

the stream comprises at least one of a media stream or a video stream, an

The MC server includes a transmission control server in the MC server.

Images