Patent Application
20060172752
The present invention relates generally to communication systems and, in particular, to providing talk permit notification (TPN) for push to talk (PTT) calls.
In push to talk (PTT) calling systems, a caller initiates a PTT call by triggering a PTT activation. For example, the caller may depress a PTT key on a mobile handset to trigger the PTT activation. In the moments that follow, it is common to provide a talk permit notification (TPN) to signal the caller that he or she may begin speaking. The shorter the interval between PTT activation and TPN, the more responsive the system feels to callers and generally the better their overall user experience is.
In order to reduce this interval, some existing systems provide the TPN before the PTT call has been fully established. If the TPN is provided to the caller, but the PTT call then cannot be fully established, the caller may begin speaking and later realize that the called party has not heard what was said. Needless to say, this falsing of the TPN can be quite frustrating to users. Thus, it is desirable to reduce both the average TPN delay and the average rate of falsing. However, typically TPN delay must be increased to reduce the rate of falsing.
Accordingly, it would be desirable to have a method and apparatus for providing TPN with less average delay, given a desired rate of falsing, than prior art systems can achieve.
Specific embodiments of the present invention are disclosed below with reference to
Various embodiments are described to provide push to talk (PTT) talk permit notification (TPN) with less average delay, given a desired rate of falsing, than prior art systems can achieve. A first communication system device (e.g., 101, 121, or 161) determines (504) whether one or more conditions are present for a PTT call that decrease the likelihood of successfully establishing the call. If (506) one or more conditions are present or a querying delay is expected to be less than an acceptable delay amount, the first device queries (508) a second communication system device (e.g., 121, 161, 122, or 102) for an indication to proceed with a TPN for the call before providing the TPN. Otherwise, the first device provides (512) the TPN without waiting for an indication to proceed with the TPN from the second device. Thus, the described embodiments determine on a per-call basis whether or not to incur additional delay in order to avoid possibly falsing the TPN for this call.
The disclosed embodiments can be more fully understood with reference to
More specifically, communication system 100 comprises user equipment (UE) 101 and 102, radio access networks (RANs) 121 and 122, packet data networks 141 and 142, IP (internet protocol) network 151, and PTT server 161. Those skilled in the art will recognize that
PTT server 161 is depicted in
Thus, given an algorithm, a logic flow, a messaging flow, and/or a protocol specification, those skilled in the art are aware of the many design and development techniques available to implement a server processing unit that performs the given logic. Therefore, PTT server 161 represents a known PTT server that has been adapted, in accordance with the description herein, to implement multiple embodiments of the present invention. Furthermore, those skilled in the art will recognize that aspects of the present invention may be implemented in and across various physical components and none are necessarily limited to single platform implementations. For example, the PTT server aspect of the present invention may be implemented in a RAN, in a PDN, on a dedicated network server platform, or distributed such components.
RANs 121 and 122 use air interfaces comprising channel groups 111-114 for communication with UEs 101 and 102. 3GPP2 channel groups 111 and 112 each comprise a variety of well-known non-traffic channel types, such as broadcast channels, paging channels, access channels and common control channels, in accordance with the particular 3GPP2 signaling technology used. 3GPP2 channel groups 113 and 114 each comprise dedicated traffic channels, which are dynamically assigned and de-assigned to support user services, again in accordance with the particular 3GPP2 signaling technology used.
UEs may be thought of as mobile stations (MSs); however, UEs are not necessarily mobile nor able to move. Thus, UE platforms are known to refer to a wide variety of consumer electronic platforms such as, but not limited to, mobile stations (MSs), access terminals (ATs), terminal equipment, gaming devices, personal computers, personal digital assistants (PDAs), cable set-top boxes and satellite set-top boxes. In particular, UE 101 comprises processing unit 105, transceiver 107, a keypad (not shown), a speaker (not shown), a microphone (not shown), and a display (not shown). Processing units, transceivers, keypads, speakers, microphones, and displays as used in UEs are all well-known in the art.
For example, UE processing units are known to comprise basic components such as, but not limited to, microprocessors, digital signal processors (DSPs), microcontrollers, memory devices, application-specific integrated circuits (ASICs), and/or logic circuitry. Such MS components are typically adapted to implement algorithms and/or protocols that have been expressed using high-level design languages or descriptions, expressed using computer instructions, expressed using messaging flow diagrams, and/or expressed using logic flow diagrams. Thus, given an algorithm, a logic flow, a messaging/signaling flow, a call flow, and/or a protocol specification, those skilled in the art are aware of the many design and development techniques available to implement user equipment that performs the given logic. Therefore, UE 101 represents a known UE that has been adapted, in accordance with the description herein, to implement embodiments of the present invention.
Operation of various embodiments in accordance with the present invention occur substantially as follows. In general, the various embodiments involve determining whether to query another communication system device for an indication to proceed with a talk permit notification (TPN) for the PTT call before providing the TPN. The device making this determination may be either a UE device or a fixed network device. For example, after detecting a PTT activation by its user and before providing the user a TPN, UE processing unit 105 determines whether one or more conditions are present for the PTT call that would indicate a decreased likelihood of successfully establishing the PTT call.
Two conditions that decrease the likelihood of success are when the PTT call is either a private call (i.e., a one-to-one PTT call) or a group call (i.e., a one-to-many PTT call) for which all the group members must be available to establish the call. As compared to a regular group call, where only one of the PTT targets is required to establish the call, both of these conditions have a lower chance of success, since all of the targets must be available. Two additional conditions that decrease the likelihood of success are when the PTT target(s) has not recently performed any presence signaling or recently responded to a PTT talk burst.
Thus, if UE processing unit 105 determines that one of these conditions is present, it queries, via transceiver 107 and channel group 111, another communication system device for an indication to proceed with a TPN for the PTT call. Alternatively, if UE processing unit 105 expects that a querying delay is going to be acceptable (2 seconds, for example), it may also query for an indication to proceed with the TPN. For example, for certain system architectures UE 101 may be able to anticipate that the fixed network will receive a page response from target UE 102 prior to completing the establishment of a traffic channel from channel group 113. In such a situation, the querying delay may be little more than a query-and-response round trip time. Also, some systems may be designed with features that enable responses to such queries within an acceptable period of time. In any case, what constitutes an acceptable delay amount can be set and/or modified by a system operator.
On average, querying should reduce the rate of TPN falsing. Thus, querying is expected to be beneficial whenever the required delay is acceptable. Moreover, for situations where there is reason to anticipate a greater chance of not establishing the call, the benefits of querying should be the greatest.
If UE processing unit 105 expects that a querying delay is going to be acceptable or it determines a condition indicating a decreased likelihood of establishing the PTT call is present, then UE 101 queries another communication system device before providing a TPN for the PTT call. Otherwise, UE processing unit 105 provides the TPN without waiting for an indication from the other communication system device to proceed with the TPN. For a UE, providing the TPN involves notifying the user by some means. For example, UE 101 may play a tone on its speaker, vibrate or signal the user via its display. Also, querying another device is sometimes referred to as “check with server” operation, “check with target” operation or “check with other” operation, while not querying may referred to as “check with self” operation.
Although UE 101 may decide not to wait for an indication to proceed with the TPN, “check with self” operation, UE processing unit 105 may wait for a particular call-setup event, in some embodiments, before providing the TPN. For example, UE processing unit 105 may wait to receive signaling, via transceiver 107 and channel group 111, in response to UE origination messaging or UE reverse short data burst signaling for the PTT call. Such response signaling may take the form of a base station acknowledgment (BS ACK). Other examples of call-setup events for which UE processing unit 105 may wait include receiving channel assignment messaging for the PTT call (for example, a channel assignment or enhanced channel assignment message (ECAM)) or receiving signaling on a traffic channel assigned for the PTT call (for example, null data or a BS ACK).
Some of the functionality described above is illustrated in
As an example, the PoC Server may perform the following functions when it fulfills the Controlling PoC Function: providing centralized PoC Session handling, providing centralized media distribution, providing centralized talk burst arbitration functionality including talker identification, providing Session Initiation Protocol (SIP) session handling, such as SIP session origination, termination, etc., providing policy enforcement for participation in group sessions, providing the participants information, collecting and providing centralized media quality information, providing centralized charging reports, supporting user plane adaptation procedures, providing transcoding between different codecs, and supporting talk burst control protocol negotiation. As an example, the PoC Server may perform the following functions when it fulfills the Participating PoC Function: providing PoC session handling, supporting user plane adaptation procedures, providing the talk burst control message relay function between PoC Client and PoC Server performing the Controlling PoC Function, providing SIP session handling, such as SIP Session origination, termination, etc., on behalf of the represented PoC Client, providing policy enforcement for incoming PoC session (e.g. access control, incoming PoC session barring, availability status, etc), providing Participant charging reports, supporting talk burst control protocol negotiation, storing the current answer mode and incoming PoC session barring preferences of the PoC Client. When the participating PoC Function is on the media path, the PoC Server may also perform the following functions: providing the media relay function between PoC Client and PoC Server, performing the Controlling PoC Function, providing a talk burst control message relay function between PoC Client and PoC Server performing the Controlling PoC Function, collecting and providing media quality information, providing filtering of the media streams in the case of simultaneous sessions, and providing transcoding between different codecs.
As a final example, the SIP/IP Core includes a number of SIP proxies and SIP registrars, which may perform the following functions in support of the PoC service: routing the SIP signaling between the PoC Client and the PoC Server, providing discovery and address resolution services, supporting SIP compression, performing authentication and authorization of the PoC user at the PoC Client based on the PoC user's service profile, maintaining the registration state, providing support for identity privacy on the control plane, providing charging information, providing capabilities to lawful interception, and supporting lawful interception functionality.
Since
In contrast,
Therefore, when UE processing unit 105 queries another communication system device for an indication to proceed with a TPN, UE processing unit 105 may receive, via UE transceiver 107, an explicit indication to proceed or messaging that when sent indicates a condition exists which UE processing unit 105 may consider sufficient as an indicator to proceed with a TPN. Depending on the embodiment, such conditions may include some or all of the following: a condition where the RF environment of a PTT target of the PTT call has not recently been poor, a condition where presence signaling has recently occurred with a PTT target of the PTT call, a condition where a RAN of a PTT target has resources to support the PTT call, a condition where a PTT target of the PTT call has registered and is not busy, a condition where a page response has been received from a PTT target of the PTT call, a condition where a reverse short data burst has been received from a PTT target of the PTT call, a condition where acknowledgment signaling has been received from a PTT target of the PTT call, and a condition where signaling has been received from a PTT target on a traffic channel assigned for the PTT call. For example, UE processing unit 105 may receive a SIP 100 TRYING message or a SIP 200 OK message and know that these messages are sent only when one or more of these conditions are present.
In some embodiments, UE processing unit 105 will not provide a TPN without querying and waiting for an indication to proceed until UE processing unit 105 receives an indication from the fixed network equipment that UE 101 may provide TPNs without waiting. In other words, UE 101 may need authorization before operating in a “check with self” mode. This authorization may be given during registration procedures or be given dynamically post-registration. However, the authorization may be dependent upon the presence of one or more conditions. These autonomous TPN conditions may include the following: a condition in which a number of PTT targets of the PTT call is greater than a threshold, a condition in which an amount of time since communication was received from a PTT target of the PTT call is less than a threshold, a condition in which a PTT target of the PTT call is a member of a designated set of PTT targets, a condition in which a PTT target of the PTT call has certain PTT attributes, and a condition in which a PTT target of the PTT call has certain presence attributes.
As noted above, various embodiments are described herein that involve determining whether to query another communication system device for an indication to proceed with a TPN before providing the TPN. The device making this determination may be either a UE device or a fixed network device. Depending on the embodiment, the fixed network device could be a RAN (such as RAN 121 or RAN 122) or a PoC server (such as PTT server 161 and/or other devices that comprise aspects of the PoC server). For clarity of description, a single system component, PTT server 161, will be used as an example.
Unlike UE 101, PTT server 161 does not detect a user PTT activation but rather it receives an indication from UE 101, via RAN 121 and PDN 141, that a PTT activation has a occurred and that UE 101 is waiting for an indication to provide a TPN for the PTT call. For example, as depicted in
Two conditions that decrease the likelihood of success are when the PTT call is either a private call (i.e., a one-to-one PTT call) or a group call (i.e., a one-to-many PTT call) for which all the group members must be available to establish the call. Additional conditions that decrease the likelihood of success include a condition where a PTT target of the PTT call recently dropped due to RF loss, a condition where an RF environment of a PTT target has recently been poor, a condition where a serving cell of a PTT target effectively has no resources, a condition where no signaling (presence, call activity, etc.) has recently occurred with a PTT target, a condition where a PTT target has unchecked voice mail or e-mail, a condition where a PTT target has not responded to a recent short message service message, a condition where a PTT target has not responded to a recent PTT talk burst, and a condition where a PTT target has a low battery. Depending on the embodiment, PTT server processing unit 165 may only consider the presence of some of these conditions or only have sufficient information to consider some of them.
Thus, if PTT server processing unit 165 determines that one of these conditions is present, it queries, via network interface 167, another communication system device for an indication to proceed with a TPN for the PTT call. Alternatively, if PTT server processing unit 165 expects that a querying delay is going to be acceptable (2 seconds, for example), it may also query for an indication to proceed with the TPN. For example, some systems may be designed with features that enable responses to such queries within an acceptable period of time. In any case, what constitutes an acceptable delay amount can be set and/or modified by a system operator.
If PTT server processing unit 165 expects that a querying delay is going to be acceptable or it determines a condition indicating a decreased likelihood of establishing the PTT call is present, then PTT server 161 queries another communication system device before providing a TPN for the PTT call. Otherwise, PTT server processing unit 165 provides the TPN without waiting for an indication from the other communication system device to proceed with the TPN. For a PTT server (or other fixed network device), providing the TPN involves indicating to the waiting UE that a TPN may be provided to the user. For example, as depicted in
In the case where PTT server 161 queries another communication system device before providing a TPN for the PTT call, at least a couple of options exist. The communication system device queried may be a PTT target, such as UE 102, or a RAN serving the PTT target, such as RAN 122. For example, call flow 200 depicts querying PTT target client B using INVITE 210. Client B responds with SIP 200 OK 211 which eventually indicates to the PoC server that it may proceed to provide a TPN. SIP 200 OK 203 is then used to indicate to client A that it should proceed with TPN 202. In another example, PTT server 161 queries target UE 102 by soliciting a page response or reverse short data burst from UE 102 via channel group 112. Upon receiving an indication that UE 102 responded, PTT server could indicate to UE 101 to provide the TPN for the PTT call.
However, PTT server 161 may prefer to query RAN 122 instead of UE 102 to get a faster response. RAN 122 may have information that PTT server 161 does not, and this information may indicate that a condition exists for a PTT target(s) which may be considered sufficient to proceed with a TPN. Depending on the embodiment, such conditions may include some or all of the following: a condition where the RF environment of a PTT target of the PTT call has not recently been poor, a condition where presence signaling has recently occurred with a PTT target of the PTT call, a condition where the RAN of a PTT target of the PTT call has resources to support the PTT call, a condition where a PTT target of the PTT call has registered and is not busy, a condition where a page response has been received from a PTT target of the PTT call, a condition where a reverse short data burst has been received from a PTT target of the PTT call, a condition where acknowledgment signaling has been received from a PTT target of the PTT call, and a condition where signaling has been received from a PTT target on a traffic channel assigned for the PTT call. In some embodiments, RAN 122 may simply determine whether it is aware of some reason that a PTT target will not be available. If it is not aware of any such reason, RAN 122 responds to PTT server 161 with an indication to proceed with the TPN. The indication to proceed with the TPN, whatever the basis for determining, may take the form of a SIP 100 TRYING message.
Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments of the present invention. However, the benefits, advantages, solutions to problems, and any element(s) that may cause or result in such benefits, advantages, or solutions, or cause such benefits, advantages, or solutions to become more pronounced are not to be construed as a critical, required, or essential feature or element of any or all the claims. As used herein and in the appended claims, the term “comprises,” “comprising,” or any other variation thereof is intended to refer to a non-exclusive inclusion, such that a process, method, article of manufacture, or apparatus that comprises a list of elements does not include only those elements in the list, but may include other elements not expressly listed or inherent to such process, method, article of manufacture, or apparatus.
The terms a or an, as used herein, are defined as one or more than one. The term plurality, as used herein, is defined as two or more than two. The term another, as used herein, is defined as at least a second or more. The terms including and/or having, as used herein, are defined as comprising (i.e., open language). The term coupled, as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically. The terms program, computer program, and computer instructions, as used herein, are defined as a sequence of instructions designed for execution on a computer system. This sequence of instructions may include, but is not limited to, a subroutine, a function, a procedure, an object method, an object implementation, an executable application, an applet, a servlet, a shared library/dynamic load library, a source code, an object code and/or an assembly code.
