Method and device for controlling floor in push to service

This application claims the priority of US Provisional Application No. 60 / 852,412 filed on October 18, 2006, and Korean Application No. 10-2007-0062429 filed in the Republic of Korea on June 25, 2007. All of these are incorporated herein by reference.

The present invention relates to PT (Push-To) (for example, PTT (Push-To-Talk), PTV (Push-To-View), PTD (Push-To-Data)) services, and in particular, the right to speak in the PT service. (Floor, talk burst authority, media burst authority, or permission to send media burst, etc.) Control methods and devices.

A PT service is a kind of half-duplex, such as PTT for transmitting voice (audio) data to provide a call service, PTV for transmitting image (video) data, PTD for transmitting various data, and so on. It is a half duplex communication service. Of the clients that participated in the session set up via the server in the PT service, one client that has the right to speak (talk burst authority, media burst authority, floor) or the right to send media bursts is the media data including audio or video. (For example, talk burst or media burst) is transmitted, and the remaining clients participating in the session receive the transmitted media data.

Compared to general mobile communication terminals, the PT client in the PT service communicates with multiple different PT clients without performing procedures such as dialing, waiting for a telephone connection, and providing a telephone ringing tone. It can provide fast communication. The PT service can also send the user's voice and data to one recipient (one-to-one) or to multiple recipients (one-to-many), such as in a group chat session.

Traditional PT services are between the process of a particular client selecting at least one other client and inviting them to a PT session, and between the inviting client (outgoing client) and the invited client (incoming client). It includes a process of setting a session and a process of transmitting and receiving voice (audio) and / or other data between clients in which the session is set.

In the PT service, the user has the media data transmission authority (or talk burst authority, media burst authority) before the user transmits media data such as audio, video, or other data by the user's PT terminal. , Floor), hereinafter referred to as "media burst authority") must be requested from the PT server (for example, PoC (Push to Talk over Cellular) server). The user can transmit media data when the right to speak is granted by the PT server. Controlling the speaking right of the user terminal in this way is called speaking right control (Talk Burst Control or Media Burst Control). Further, in such a voice control, it is possible to restrict a specific user who has acquired the voice from transmitting media data through a communication channel, and such a function is referred to as "Talk Burst Revoke". ".

FIG. 1 is a state transition diagram (state machine diagram) of the PT server (on the PT server side) for the media burst operation to the conventional PT client. FIG. 1 is a diagram showing each state of the PT server with respect to the media burst (or talk burst) operation to the PT client (that is, the terminal). The states shown in the ellipse in FIG. 1 are classified into a stable state and a transition state according to the nature of each state. Events are shown in boxes in Figure 1.

The related states shown in FIG. 1 are as follows.

(a) The "Start-stop" state is a state in which there is no SIP (Session Initiation Protocol) session between the PT server and the related PT client. Hereinafter, the "Start-stop" state is referred to as the "0th (zero) state".

(b) The "U: not permitted and MB-Idle" state is a stable state in which the PT server can receive a voice request from the PT client. That is, the PT client can send a voice request (this is called MB_Request) to send the media burst to the PT server. Hereinafter, the "U: not permitted and MB-Idle" state is referred to as the "first state".

(c) The "U: permitted" state is a stable state in which the PT server grants the related PT client the media burst transmission authority, and the related PT client can transmit the media burst to the PT server. Is. Hereinafter, the "U: permitted" state is referred to as a "second state". In this state, the PT server activates (starts) the T1 timer (that is, the End of RTP Media timer) and the T2 timer (that is, the Stop talking timer). These timers will be described later.

(d) The "U: not permitted but sends media" state is a transition state in which the PT server receives media data (or RTP media packet) from a PT client that does not have the right to speak. Hereinafter, the "U: not permitted but sends media" state is referred to as the "third state". In this state, the PT server activates (starts) the T8 timer (that is, the Media Burst Revoke timer).

(e) The "U: pending MB_Revoke" state is a transition state, during the grace period after the PT server sends an MBCP (Media Burst Control Protocol) Media Burst Revoke message. Use this state. Hereinafter, the "U: pending MB_Revoke" state is referred to as the "fourth state". In this state, the PT server activates (starts) the T3 timer (that is, Start talking grace timer), and the period during which the T3 timer operates corresponds to the grace period.

(f) The "U: waiting MB_Revoke" state is a stable state in which the PT server does not grant the media burst transmission authority requested by the related PT client for a predetermined period during which the T9 timer operates. The PT server penalizes the associated PT client if the associated PT client continues to transmit media data beyond the media burst transmit authorization period (ie, the period of operation until the T2 timer expires). In this state, the PT server activates (starts) the T9 timer (that is, the retry-after timer). Hereinafter, such a "U: waiting MB_Revoke" state is referred to as a "fifth state".

(g) The "U: not permitted MB_Taken" state is a stable state, and other PT clients (that is, unrelated PT clients) other than the related PT client that has acquired the media burst transmission authority have the media burst transmission authority. When making a request, the PT server notifies the other PT client that the media burst transmission authority has already been acquired. Hereinafter, such a "U: not permitted MB_Taken" state is referred to as a "sixth state".

The T1 timers, T2, T3, T8, and T9 introduced in the description of Figure 1 are used to limit or control the transmission of Media Burst (MB) between the PT server and associated PT clients. The operation of such a timer will be described below. Generally, the media data transmitted from the PT client to the PT server is transmitted in the RTP (Real Time Protocol) packet format.

<u style="single">T1 timer (End of RTP Media timer)</u> The T1 timer is a timer that counts whether or not the PT server receives the next RTP packet within the valid period after receiving the previous RTP packet. Normally, the T1 timer is set to 4 seconds by default. After the terminal sends media data, that is, an RTP media packet, to the PT server, when the PT server receives the first RTP packet, the T1 timer is activated and restarts each time the next RTP packet is received. When the PT server receives the last RTP packet, the T1 timer stops or expires.

<u style="single">T2 timer (Stop talking timer)</u> The T2 timer is a timer that counts the allowable (valid) period during which a terminal having media burst transmission authority (speaking right) can transmit media data. The PT server activates the T2 timer when the terminal sends the first RTP packet. Normally, the T2 timer is set to 30 seconds by default.

<u style="single">T3 timer (Stop talking grace timer)</u> The T3 timer is a timer that counts the grace period during which the PT server can receive more media data even after the T2 timer has expired. Here, the grace period refers to a kind of marginal excess time that enables the PT server to receive media data even after the T2 timer has expired. That is, even if the terminal having the authority to transmit media data transmits the media data after the period allowed for the terminal to transmit the media data has elapsed, the PT server still transmits the media data during the setting period of the T3 timer. That is, the media data received from the terminal is allowed until the T3 timer expires.

<u style="single">T9 timer (Retry-after timer)</u> The T9 timer is a timer that counts the penalty time imposed on the terminal so that the terminal cannot request media burst authority from the PT server when the terminal transmits media data beyond the permitted period. Is. If the terminal transmits media data beyond the value (period) set in the T2 timer (ie, after a period allowed for transmission of media data), the PT server will send an MBCP cancellation message to the terminal. After sending (MBCP Revoke message) or TBCP cancel message (TBCP Revoke message), activate the T3 timer. If the PT server does not receive the MBCP release message or TBCP release message from the terminal during the time set in the T3 timer, it activates the T9 timer and corresponds to the time value set in the T9 timer. For a predetermined period (that is, the operating period of the T9 timer), the terminal cannot request the right to speak and transmit media data.

<u style="single">T8 timer (Talk Burst Revoke timer)</u> The T8 timer is a timer that is activated when the PT server sends an MB_Revoke message. If the terminal does not send the MB_Release message within the value (that is, the period) set in the T8 timer, the PT server activates the T8 timer again and waits for the reception of the MB_Release message sent by the terminal.

FIG. 2 is a signal flow diagram showing acquisition of media burst transmission authority and transmission of media data between a conventional PT server and a terminal.

Hereinafter, description will be made with reference to FIGS. 1 and 2. Here, it is assumed that the SIP session is started in the 0th state of the PT server in FIG. 1, and the PT server sends an MB_Idle message to each terminal (PT client device) to transition (change) to the 1st state. That is, the PT server is in a state in which each terminal can request the PT server to transmit a media burst authority (that is, a media burst authority).

Each of terminals A, B, and C has a voice (floor, media burst authority, talk burst). Send a message requesting authority) or media burst send permission (ie, MB_Request) to the PT server (S1). If the PT server decides to grant terminal A the right to send media bursts, the PT server sends an MB_Granted message to terminal A in response to terminal A's MB_Request message. On the other hand, the PT server sends a message (that is, MB_Taken) indicating that the media burst transmission authority has been granted to the terminal A to the terminals B and C (S2). According to the steps S1 and S2, the operating state of the PT server with respect to the terminal A transitions from the first state to the second state (that is, U: permitted) as shown in FIG. Therefore, the terminal A can transmit the media data (or RTP media packet) to the PT server during the period set in the T2 timer (that is, during the operation period of the T2 timer). Further, since the terminals B and C are in the state of receiving the MB_Taken message by the steps S1 and S2, the operating state of the PT server with respect to the terminals B and C is the sixth state (that is, ". U: not permitted and MB_Taken ").

Since the state of the PT server with respect to the terminal A in FIG. 1 corresponds to the second state (that is, the U: permitted state), the terminal A can transmit the media data (RTP media packet) to the PT server (that is, the U: permitted state). S3). Here, the PT server can operate the T1 timer and the T2 timer at the same time when it receives the first RTP media packet transmitted from the terminal A.

When terminal A sends a message for releasing the media burst transmission authority (that is, MB_Release message) within the period when media data transmission is allowed to terminal A (that is, the value (period) set in the T2 timer). As shown in FIG. 1, the state of the PT server with respect to the terminal A transitions from the second state to the first state. The PT server also stops the running T2 timer (ie, the T2 timer stops before it expires). However, when the period during which media data transmission is permitted to the terminal A (that is, the value (period) set in the T2 timer) expires, the PT server sends a message for revoking the media burst transmission authority (that is, the MB_Revoke message). ) Is sent to terminal A.

Generally, messages and media data (or RTP media packets) from terminals are transmitted by different network routing routes under a physical communication environment. However, in such a physical communication environment, transmission delay (transition delay) may occur during reception of messages and media data on different network routing routes. Further, due to such a situation, the current state of the PT server for the terminal may unintentionally become the third state (for example, "U: not permitted but sends media") in the state machine diagram of FIG. is there.

For example, when the PT server is in the second state and receives an MB_Release message from the terminal, the PT server transitions from the second state to the first state. After that, when the PT server receives the media data (RTP packet) transmitted by the terminal earlier than the MB_Release message but arrives at the PT server later due to the delay of the routing route, the PT server is shown in FIG. As shown, the transition from the first state to the third state. However, in the third state, the terminal cannot request the media burst transmission authority from the PT server, and the PT server must return to the first state to allow the terminal to request the media burst transmission authority. The third state is currently not the desired state. Furthermore, the PT server cannot return to the first state at that time. This is because in order to do so, the PT server must receive other MB_Release messages that are unlikely to occur at that time. As a result, there is a problem that the terminal based on the state machine diagram of FIG. 1 continues to remain in an undesired state (that is, the third state) in which the PT server cannot be requested to transmit media burst transmission authority.

For example, if the terminal sequentially transmits an RTP media packet and an MB_Release message, the MB_Release message may arrive at the PT server before the RTP media packet, and vice versa. In this case, after receiving the MB_Release message on the predetermined network routing route, the PT server receives a part of the RTP media packet on another network routing route (for example, the last or the last of the RTP media packets transmitted by the terminal). Other RTP media packets) can be received. Here, since the PT server has already received the MB_Release message, the state of the PT server with respect to the terminal in the state diagram of FIG. 1 changes from the second state (that is, "U: permitted") to the first state (that is, "U"). : not permitted and MB_idle "). After that, even when the PT server receives the last RTP media packet, it cannot recognize that the last received RTP media packet was transmitted before the already received MB_Release message. As a result, the PT server determines that the terminal without the media burst transmission authority has transmitted the media data (that is, the last received RTP media packet). Therefore, the PT server discards the last RTP media packet received and sends an MB_Revoke message (indicating that the media burst transmission authority granted to the terminal has been revoked) to the terminal (ie, this means that it has been revoked). Corresponds to "Situation 1" in Figure 1). That is, the state of the PT server with respect to the terminal in the conventional state diagram of FIG. 1 changes from the first state (that is, "U: not permitted and MB_Idle") to the third state (that is, "U: not permitted but sends"). It changes to media "). In the third state of Figure 1, the PT server sends an MB_Revoke message to the terminal and activates the T8 timer (ie, this corresponds to "Situation 2" in Figure 1). However, such situation 2 is repeated until the PT server receives the MB_Release message from the terminal, and the state of the PT server with respect to the terminal maintains the third state in the state machine diagram of FIG. If Situation 2 is repeated, the terminal may suffer the disadvantage of not being able to request the PT server to speak even though it has already sent the MB_Release message. This is a problem that can occur because the network routing route of the message sent by the terminal is different.

In addition, since the network routing route of the message transmitted by the terminal is different, as a result, the terminal may unintentionally reach the fifth state (that is, U: waiting MB_Revoke) in the state diagram of FIG. That is, after the terminal (or PT client) acquires the media burst transmission authority, the media data (that is, a series) during the period when the media data transmission is permitted (that is, the period corresponding to the set value of the T2 timer). RTP media packet) can be sent to the PT server. In some cases, a series of RTP media packets sent by a terminal contains a sequence number. Information about the sequence number of the last RTP media packet may also be included in the MB_Release message.

Even if the terminal sequentially sends a series of RTP media packets (ie, media data) and MB_Release messages to the PT server within the set period of the T2 timer (eg, "30 seconds"), the messages (ie, RTP media packets and Since the network routing route of the MB_Release message) is different, the reception of the PT server may be non-sequential compared to the message transmitted sequentially. For example, when an RTP media packet and an MB_Release message are transmitted in sequence, the MB_Release message may arrive at the PT server before the RTP media packet. That is, the PT server may receive a part of the RTP media packet (for example, the last RTP media packet among the RTP media packets transmitted by the terminal) after receiving the MB_Release message transmitted by the terminal. Here, the PT server confirms (that is, searches and analyzes) the information regarding the sequence number of the last RTP media packet included in the MB_Release message, and then waits until the last RTP media packet is received. That is, the state of the PT server with respect to the terminal continuously maintains the second state (that is, the "U: permitted" state) shown in FIG. However, if the T2 timer expires while the PT server is waiting to receive the last RTP media packet, the PT server sends an MB_Revoke message to the terminal (ie, this corresponds to situation 3 in Figure 1). Here, the state of the PT server with respect to the terminal is from the second state to the fourth state (that is, "U:". Transition to the "pending MB_Revoke" state). After that, when the last RTP media packet is received, the PT server arrives at the last received RTP media packet within the allowable period for transmitting the media data (that is, the set period of the T2 timer). It considers the packet to be invalid (not allowed) and penalizes the terminal. Therefore, the state of the PT server with respect to the terminal changes from the fourth state to the fifth state (that is, the "U: waiting MB_Revoke" state), that is, the state in which the terminal receives a penalty. That is, in the fifth state, the terminal cannot request the PT server to have a media burst authority during the period when the penalty is imposed (that is, the period corresponding to the set value of the T9 timer).

Therefore, if the terminal sequentially transmits an RTP media packet (media data) and an MB_Release message within the period allowed for transmitting media data (that is, the period set in the T2 timer) (for example, 30 seconds). Due to the transmission delay (transition delay) of the network routing route, the media data in a state where the PT server receives the MB_Release message first and does not receive some RTP media packets (for example, the last RTP media packet). After the permissible period for sending the data, the terminal will be in an undesired state where it cannot request media burst authority from the PT server for the period set in the T9 timer (for example, 30 seconds). There is.

<p> An object of the present invention is to provide a PT server state control method and device that solves the limitations and drawbacks of the prior art.</p><p> Another object of the present invention is to provide a PT client device (terminal) and a PT server capable of providing an effective media burst control technique.</p><p> Further, in the present invention, when the PT server receives a predetermined media data after receiving a message for canceling the media burst transmission authority (floor, media burst authority) from the terminal (PT client device). Is also for allowing the terminal to request media burst transmission authority.</p><p> Further, in the present invention, even when the period for which the media burst transmission authority is permitted elapses after the PT server receives the message for canceling the media burst transmission authority from the terminal (PT client device), the terminal has a predetermined period. , The purpose is to enable the request of media burst transmission authority without being restricted (suppressed, controlled).</p>

<p> The state control method of the PT server according to one aspect of the present invention includes a stage in which the PT server in the second state transitions to the first state when receiving the media burst release message, and the PT server in the first state media from the PT client. This includes a step in which the PT server maintains the first state when a packet is received and when the previous PT server in the second state receives the media burst release message.</p><p> The state control method of the PT server according to another aspect of the present invention includes a step in which the PT server in the second state transitions to the first state when receiving the media burst release message, and a first state in which the PT server has transitioned. If a media packet is received while in, the step of determining whether or not the media burst release message was received in the previous second state and the step of the PT server in the previous second state When it is determined that the media burst release message has been received, the step of maintaining the transitioned first state at the time of receiving the media packet is included. In the method, the PT server in the second state receives at least one media packet from the PT client while the T2 timer is operating, and the PT server in the second state receives the PT while the T2 timer is operating. It also includes the stage of receiving a media burst release message from the client.</p><p> The state control method of the PT server according to still another aspect of the present invention includes a step of determining whether or not the PT server in the second state has received the media burst release message when the T2 timer expires, and the PT server. A step of transitioning from the second state to the first state when it is determined that the media burst release message has been received in the determination stage, or a transition from the second state to the fourth state based on the result of the determination. And include.</p><p> The state control method of the PT server according to still another aspect of the present invention is the step of receiving the media burst release message while the PT server is operating and the media burst when the PT server expires. This includes a stage of determining whether or not a release message has been received, and a stage of transitioning to a media burst idle state when the PT server determines that the media burst release message has been received in the determination stage.</p><p> The PT client device according to still another aspect of the present invention transmits at least one media packet and a media burst release message to the PT server, and receives a media burst idle message from the PT server in response to the media burst release message. The media burst idle message includes a control unit that transmits a media burst request to the PT server after receiving the media burst idle message, and the media burst idle message is a case where the media burst release message is received before the T2 timer expires. Is received from the PT server.</p><p> The PT client device according to still another aspect of the present invention transmits at least one media packet and a media burst release message to the PT server, and receives a media burst idle message from the PT server in response to the media burst release message. The media burst request includes a control unit that transmits a media burst request to the PT server after receiving the media burst idle message, and the media burst request is at least 1 in the first state after the PT server receives the media burst release message. It is transmitted when one media packet is received, and the media burst release message is received by the PT server in the previous state.</p><p> Such and other objectives of the present application will become apparent in the detailed description below. However, since it will be apparent to those skilled in the art that various changes and modifications can be made from the detailed description within the ideas and scope of the present invention, the detailed description and specific examples show preferred embodiments of the present invention. However, it should be understood that it is given for illustration purposes only.</p><p> The present invention will be more fully understood from the accompanying drawings provided for detailed description and mere illustration below, but is not limited thereto.</p>

<figref num="1">FIG. 1 is a state machine diagram showing transmission / reception of media bursts between a conventional PT client and a PT server.</figref><figref num="2">FIG. 2 is a signal flow diagram showing acquisition of media burst transmission authority and transmission of media data between a conventional PT server and a terminal (PT client).</figref><figref num="3">FIG. 3 is a signal flow diagram showing media burst control according to the first embodiment of the present invention.</figref><figref num="4">FIG. 4 is a signal flow diagram showing media burst control according to the second embodiment of the present invention.</figref><figref num="5">FIG. 5 is a PT structure showing the UE (or terminal) of the present invention.</figref>

The description of preferred embodiments of the present invention can be applied to PT communication systems and related devices that provide PT services. However, the present invention is not limited to this, and can be applied to all wireless communication systems and related devices to which the technical characteristics of the present invention can be applied.

According to one aspect of the present invention, a terminal that has acquired a media burst authority (floor, media burst authority) has media data (for example, an RTP media packet having no sequence number) and the media burst transmission authority. When a message for cancellation (that is, MB_Release) is sent to the PT server within the media burst transmission permission period, the PT server receives the MB_Release message due to a transmission delay (transition delay) on a different network routing route. After that, even if a part of the media data (for example, the last RTP media packet or at least one RTP media packet that is not the last RTP packet) is received, the terminal is restricted to the PT server in any way. Without this, the request for the media burst transmission authority is allowed.

According to another aspect of the present invention, when a terminal that has acquired the media burst transmission authority sequentially transmits media data (for example, an RTP media packet having a sequence number) and an MB_Release message within the media burst transmission authority period. Due to a transmission delay (transition delay) on a different network routing route, after the PT server receives the MB_Release message first, a part of the media data (for example, the last one) before the media burst transmission permission period elapses. Even if the RTP media packet or at least one RTP media packet that is not the last RTP packet is received, the terminal is allowed to request the media burst transmission authority without any limitation.

Hereinafter, the configuration and operation of the preferred embodiment of the present invention will be described with reference to the accompanying drawings. In the present invention, the first and second embodiments are proposed as mere examples.

The first embodiment is applied regardless of whether the RTP media packet (media data) has or does not have a sequence number. In the second embodiment, the RTP media packet (media data) has a sequence number, and the "sequence number of the last packet" information included in the media burst release message (for example, MB_Release message) received by the PT server is used. Examination reveals that at least one additional RTP media packet can be received and is preferably applied when it is possible to wait for the additional RTP media packet to be received. Here, the sequence number of each RTP media packet (media data) serves as an identifier of each packet and also serves as a kind of indicator for notifying the sequence (order) of each packet. Each MB_Release message contains information that can identify the last RTP media packet, such as "the sequence number of the last packet". However, each RTP media packet may or may not include the sequence number of the RTP media packet.

FIG. 3 is a signal flow diagram showing media burst control according to the first embodiment of the present invention.

Hereinafter, description will be made with reference to FIGS. 1 and 3. Here, it is assumed that the SIP session is started in the 0th state of the PT server in FIG. 1, and the PT server sends an MB_Idle message to each terminal and is in the 1st state. That is, each terminal is in a state where it can request the PT server to have the right to speak (media burst authority, floor, or media burst transmission authority (permission to send media burst)). However, here, as an example, it is assumed that the terminal A has acquired the media burst transmission authority from the PT server.

Each of terminals A, B, and C (PT client device) sends a message requesting media burst transmission authority (for example, MB_Request) to the PT server (S10). If the PT server decides to grant terminal A media burst transmission permission, the PT server sends a consent message (for example, MB_Granted) to terminal A in response to the request for media burst transmission permission by terminal A, while the terminal A message indicating that the media burst transmission authority has been granted to the terminal A is transmitted to B and C (S20). In steps S10 to S20, the state of the PT server with respect to the terminal A transitions (changes, moves) from the first state in FIG. 1 to the second state machine (that is, the U: permitted state). Therefore, the terminal A can transmit the media data (or RTP media packet) to the PT server during the allowable (valid) period set in the T2 timer. Further, since the terminals B and C are in the state of receiving the MB_Taken message in the steps S10 to S20, the operating state of the PT server with respect to the terminals B and C is the sixth state in FIG. 1 (U: not). "permitted and MB_Taken" status). Since the terminal A is in the second state (that is, the "U: permitted" state), the media data (or RTP media packet) can be transmitted to the PT server (S30). Here, the PT server activates the T1 timer and the T2 timer when it receives the first RTP media packet. That is, the terminal A can send a series of RTP media packets to the PT server within the time (period) (for example, 30 seconds) set in the T2 timer (S31 to S33). Here, the PT server restarts (restarts) the T1 timer each time each RTP media packet arrives. The T1 timer counts the period from the arrival of one RTP media packet to the arrival of the next RTP media packet.

If the T1 timer expires or receives an MB_Release message from terminal A, the PT server considers terminal A to have completed the transmission of media data, from the second state of FIG. 1 to the first state of FIG. That is, the terminal A transitions to a state in which it can request the right to speak (the right to transmit media bursts).

Hereinafter, step S30 will be described in more detail. As shown in FIG. 3, terminal A transmits a series of RTP media packets to the PT server within the permissible period for transmitting media data (that is, the value (period) set in the T2 timer) (that is, the period). S31 ~ S33), and then sent an MB_Release message to the PT server (S34). Here, the messages transmitted by the terminal A (that is, the RTP media packet and the MB_Release message) are transmitted to the PT server by different network routing routes. This causes a transmission delay (transition delay) due to the use of different network routing routes. Therefore, the PT server may receive the last RTP media packet or at least one RTP media packet (not the last RTP media packet) after receiving the MB_Release message sent by terminal A (S34).

Since the PT server received the MB_Release message while the T2 timer was running in step S34, the TBCP (or MBCP) state of the PT server for terminal A is the second state (ie, "U: permitted"), which is the current state. Transition from state) to first state machine (ie, "U: not permitted and MB_Idle" state). The PT server can receive a media burst transmission authority request message (for example, MB_Request) from the terminal A, which means that the terminal A can send the media burst request to the PT server again in this state if necessary.

Then, according to the present invention, as in step S33, when the PT server in the first state receives the last RTP media packet or other RTP media packet, the PT server sends an MB_Release message (ie, the PT server). Determines if the second state {that is, the message already received in the "U: permitted" state} has already been received. If it determines that the MB_Release message has already been received, the PT server does not transition to the third state ("U: not permitted but sends media") and the last RTP media packet or other RTP media packet received. After discarding (rather than sending to other PT clients), it retains its primary state so that Terminal A can request media burst send permission again if desired. On the other hand, if it is determined that the MB_Release message has not been received, the PT server transitions from the first state to the third state.

In the embodiment of FIG. 3, the PT server in the first state, unlike the prior art of FIG. 1, has already received an MB_Release message (ie, the PT server has already received in the second state {ie, the U: permitted state}. It is determined that the message) has already been received (for example, in step S34), the received RTP media packet is discarded, the first state is maintained, and the state does not transition to the third state (S35). That is, when the PT server in the first state receives the RTP media packet in step S33, the state of the PT server with respect to the terminal A changes from the first state to the third state (that is, U: not permitted but sends in FIG. Does not transition to "media" state). As a result, even if the PT server receives the RTP media packet in step S33 after receiving the MB_Release message in step S34, the PT server does not have the media burst transmission authority for the terminal A that sent the media data. Do not judge.

In the above case, after receiving the MB_Release message in step S34, the PT server discards the last RTP media packet (or another RTP media packet) received in step S33, and the terminal A bursts the media. Allows you to continue to request send permissions. That is, the TBCP (or MBCP) state of the PT server with respect to the terminal A continuously maintains the first state. Therefore, if terminal A sends an MB_Release message after sending media data (ie, a series of RTP media packets) within the time (period) set in the T2 timer, that is, the media burst transmission permission period, network routing It is possible to prevent disadvantageous processing due to the transmission delay (transition delay) of the route. As a result, the state machine of the PT server for the terminal does not transition from the first state to the third state. Therefore, in the present invention, the terminal A can advantageously and effectively request the PT server for the media burst transmission authority again, and no penalty is imposed.

FIG. 4 is a signal flow diagram showing media burst control according to the second embodiment of the present invention. Here, it is assumed that the SIP session is started in the 0th state of the PT server in FIG. 1, and the PT server sends an MB_Idle message to each terminal and is in the 1st state. That is, each terminal is in a state where it can request the media burst transmission authority from the PT server. However, as an example, the description will be made on the assumption that the terminal A has acquired the media burst transmission authority from the PT server. Steps S10 and S20 in the second embodiment of FIG. 4 have the same operation and function as steps S10 and S20 in the first embodiment of FIG. Unlike the first embodiment of FIG. 3, in the second embodiment of FIG. 4, each RTP media packet (or media data) has a sequence number, and the MB_Release message is the sequence number of the last RTP media packet. Contains information about.

Further, in the second embodiment of the present invention as shown in FIG. 4, for example, the last RTP media packet transmitted before the MB_Release message, or at least one RTP media packet that is not the last RTP media packet is used. Even if the MB_Release message is first received from the terminal A to the PT server before it is received, the state of the PT server does not change (change) from the second state to the first state, and the second state of the PT server changes. It is continuously maintained for terminal A. This means that the PT server waits for the last RTP media packet (or other media packet) to be received from terminal A until the T2 timer expires. In FIG. 4, each RTP media packet has a sequence number, so the PT server waits for the last packet to arrive by checking the "last packet sequence number" information contained in the received MB_Release message. be able to.

Also, in the second embodiment of FIG. 4, a series of RTP media packets (preferably having a sequence number) and an MB_Release message were sent from terminal A to the PT server before the T2 timer expired, but in the network routing path. Due to the transmission delay (transition delay), the MB_Release message may be received first by the PT server. As a result, the T2 timer will expire when the PT server has not received some of the RTP media packets (eg, the last or at least one media packet). Hereinafter, the operation related to the reception of the MB_Release message and the specific RTP media packet of the PT server will be described in more detail with reference to step S40 according to the present invention.

Referring to step S40, Terminal A, which has acquired the media burst transmission authority, receives a series of RTP media packets within the allowable period for transmitting media data (that is, the value (period) set in the T2 timer). To the PT server (S41 ~ S43). Here, it is preferable that each of the RTP media packets has a sequence number. Terminal A sends an MB_Release message to the PT server during the media data transmission period (that is, the value (period) set in the T2 timer) (S44). However, even if the RTP media packet and the MB_Release message are sequentially transmitted from the terminal A to the PT server, the network routing route to which each RTP media packet and the MB_Release message is transmitted may be different. Therefore, since the routing routes through which the packets and messages are transmitted are different, transmission delay (transition delay) may occur.

In the embodiment of FIG. 4, the PT server receives the RTP media packet (sequence number 1), the RTP media packet (sequence number 2), and the like before the T2 timer expires (S41 to S42). The transmission delay (transition delay) may then cause the MB_Release message to be received before the last or other RTP media packet (ie, the RTP media packet with sequence number n) (S43 and S44). At this time, the PT server analyzes the information regarding the sequence number (for example, n) of the last RTP media packet included in the received MB_Release message, and whether or not the received RTP media packet is the last RTP packet. Can be judged. For example, the "last packet sequence number" information / parameter provided in the received MB_Release message can be examined. The PT server can store information about the sequence number of the last RTP media packet in a specific memory (for example, a memory built in (installed) in the PT server or an external memory).

Since the "sequence number of the last packet" information contained in the received MB_Release indicates that the PT server still needs to receive the last packet, when the PT server receives the MB_Release message, the ( Wait for the last RTP media packet (with sequence number) to be received. Further, according to the present invention, the state of the PT server with respect to the terminal A does not transition from the second state to the first state, and maintains the current second state (S45). As a result, the PT server can receive the media data transmitted by the terminal A before the expiration of the T2 timer (for example, the last RTP media packet having the sequence number n).

However, if the last RTP media packet cannot be received when the T2 timer expires (for example, if the last RTP media packet is received after the T2 timer expires in step S43), the PT server will have the PT server MB_Release. Determine if the message has already been received (S46). That is, if the T2 timer expires while the PT server is in the second state (U: permitted), the PT server does not transition to the fourth state and maintains the second state as is (S45). Then, the PT server determines whether or not the MB_Release message has already been received (S46). If it determines that the MB_Release message has already been received, the PT server will go from the second state to the first state ("U: not permitted and". Transition to "MB_Idle"), send an MB_Idle message to terminal A, and discard all RTP media packets received later. In the embodiment of FIG. 4, since the PT server has already received the MB_Release message in step S44, the PT server determines that the MB_Release message has already been received in step S45. Therefore, after transitioning from the second state to the first state, the PT server maintains the first state and sends an MB_Idle message to the terminal A (S47 and S48).

On the other hand, if it is determined in step S45 that the MB_Release message has not been received, the PT server sends the MB_Revoke message to terminal A (S49) and changes from the second state to the fourth state ("U: pending MB_Revoke"). Transition (S50).

As described above, based on the determination in step S45, the PT server can confirm whether or not the MB_Release message has already been received in step S44 before the T2 timer expires. Therefore, there is an advantage that the PT server transitions from the second state to the first state, and the terminal A can request the media burst transmission authority. That is, according to the present invention, the PT server does not send the MB_Revoke message to the terminal A as soon as the T2 timer expires. Further, in this case, the state of the PT server with respect to the terminal A does not transition (change) from the second state to the fourth state (that is, the "U: pending MB_Revoke" state). However, if the PT server determines in step S45 that it has not yet received the MB_Release message when the T2 timer expires, the PT server sends an MB_Revoke message to terminal A (S49). Here, the state of the PT server for the terminal A transitions from the second state to the fourth state (U: pending MB_Revoke state) (S50).

On the other hand, the PT server can activate the T3 timer when the T2 timer expires. If the PT server receives the last RTP media packet (sequence number n) before the T3 timer expires, the PT server sends the last RTP media packet (sequence number n) to terminal B and / /. Or send to terminal C (ie, this applies to situation 4 in Figure 1). However, if the T3 timer expires or the PT server in the 4th state receives the last RTP media packet (with sequence number n), the PT server will have terminal A media burst authority. ) (Media burst transmission authority), it is considered that the media data (that is, the last RTP media packet whose sequence number is n) has been transmitted. Therefore, the state of the PT server for terminal A is from the 4th state ("U: pending MB_Revoke" state) to the 5th state ("U: waiting"). Transition (change) to "MB_Revoke" state). In such a fifth state, the PT server imposes a penalty on terminal A for not being able to request media burst transmission authority for a predetermined period (that is, the period set in the T9 timer).

Therefore, in the second embodiment of the present invention, if the PT server receives the MB_Release message first before receiving the last RTP media packet from the terminal A within the allowable period of the T2 timer, the MB_Release message is displayed. After confirming (analyzing) the information about the sequence number of the last RTP media packet included, it does not transition from the second state to the first state and waits for the reception of the last RTP media packet. However, even if the last RTP media packet is not received when the T2 timer expires, the PT server does not automatically send the MB_Revoke message to terminal A, but whether or not the MB_Release message has already been received. After judging whether or not, it is possible to move from the second state to the fourth state based on the judgment. In the conventional technology, when the T2 timer expires, the PT server automatically transitions from the second state to the fourth state, so that the T3 timer and the T9 timer are activated, and the terminal A has the authority to transmit media burst while the T9 timer is operating. Cannot be requested. This is a problem because the PT server imposes too strict penalties on terminals. The present invention overcomes such a limitation because the PT server selectively transitions from the second state to the fourth state based on the determination result in step S46. As a result, according to the present invention, the user (terminal A) does not receive an unnecessary penalty, and the PT server can allow the terminal A to request the media burst transmission authority. Therefore, the terminal A is preferably provided with the PT service without being limited by the network transmission delay (transition delay).

As mentioned above, the specification of the present invention has been described merely with reference to exemplary embodiments. It will be apparent to those skilled in the art that various modifications and modifications are possible in the present invention. For example, the method of the invention discussed herein can be realized by software, hardware, or a combination thereof, i.e. stored in a storage medium (eg, terminal internal memory, flash memory, hard disk, etc.) and a processor. It can be realized by code or command in a software program programmed by (for example, the internal microprocessor of the terminal). Further, in the embodiment of the present invention, the talk burst indicates audio data, and the media burst indicates data such as characters, moving images, or photographs. Both talk bursts and media bursts can be applied to embodiments of the present invention regardless of the data format. Accordingly, the present invention may include modifications and modifications provided within the appended claims and their equivalents.

Each terminal according to the present invention (for example, terminals A, B, C, etc.) is a PT client device (all devices including a PT client) capable of providing a PT service. Each terminal may include a control unit, a memory, and other components for realizing the method of the present invention discussed herein. For example, each terminal may be one of all types of mobile communication terminals, notebook computers, desktop computers, portable game consoles, MPSs, or other home appliances that can use PT services. Further, in the description of the present invention, each terminal preferably indicates a physical entity including a PT client, and the PT client means a logical or physical entity included in the terminal. Is preferable. Therefore, for convenience of description of the present invention, the terminal may indicate a PT client device and vice versa.

FIG. 5 shows a PT system structure including a terminal (or UE) configuration according to the present invention. Hereinafter, description will be made with reference to FIG.

In the embodiment of FIG. 5, the PT client is located at the mobile terminal and is used for PT service connection. The PT client can be configured to start (eg, codec negotiate), join (eg, talk or listen) and cancel a PT session. The PT client can be configured to perform registration using the SIP / IP core and authenticate the PT user to the SIP / IP core. The PT client can be configured to generate and transmit talk bursts (media bursts) by audio recording or audio encoding. The PT client can be configured to receive a talk burst and decode the received talk burst to generate audio. The PT client can be configured to support talk burst control procedures and talk burst protocol negotiation. The PT client is the PT configuration data (PT configuration) provided by the DM client. data) can be configured to incorporate. The PT client can answer mode indication (manual response, automatic response), incoming PT session barring, incoming instant personal alert barring, and simultaneous PT. It can be configured to support the ability to configure session support (simultaneous PT sessions support). The PT client can be configured to support a user plane adaptation procedure when initiated by a PT server. The PT client can be configured to support receiving instant personal alerts. The PT client supports sending instant personal alerts and group notifications (group). can be configured to provide advertisement). The PT client can be configured to support multiple talk burst control protocols as well as talk burst request queuing that can be based on priority and time stamp. The PT client can be configured to send quality feedback reports after the end of the talk burst. The PT client can be configured to support a session that has already been configured. The PT client can be configured to support simultaneous sessions and session on-hold procedures in order to request privacy for a user identity.

In the embodiment of FIG. 5, the XDMC (XML Document Management Client) is an XML document stored in a network (for example, a PT-specific document in PT XDMS), for example, a shared XDMS (shared XDMS). It may be an XCAP client that manages (such as a URI list used as a contact list). Management characteristics include actions such as create, modify, search, and delete.

In the embodiment of FIG. 5, the presence source is an entity that provides (issues) presence information to the presence service. A watcher is an entity that requests presence information about presentity or watcher information about a watcher and constitutes the presence service.

As described above, in the present invention, the terminal is not restricted by the PT server due to the network transmission delay (transition delay), and requests the media burst transmission authority (speak authority (talk burst authority, media burst authority, floor)). Therefore, the terminal and the PT server can use the PT service smoothly and preferably.

The present invention has only been described with reference to exemplary embodiments. It will be apparent to those skilled in the art that various modifications and modifications can be made in the present invention within the ideas and scope of the present invention. Accordingly, the invention may include modifications and variations of the invention provided within the appended claims and their equivalents.