CA2567041A1 - Architecture, client specification and application programming interface (api) for supporting advanced voice services (avs) including push to talk on wireless handsets and networks - Google Patents

Architecture, client specification and application programming interface (api) for supporting advanced voice services (avs) including push to talk on wireless handsets and networks Download PDF

Info

Publication number
CA2567041A1
CA2567041A1 CA002567041A CA2567041A CA2567041A1 CA 2567041 A1 CA2567041 A1 CA 2567041A1 CA 002567041 A CA002567041 A CA 002567041A CA 2567041 A CA2567041 A CA 2567041A CA 2567041 A1 CA2567041 A1 CA 2567041A1
Authority
CA
Canada
Prior art keywords
group
call
voice services
presence
wireless network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
CA002567041A
Other languages
French (fr)
Inventor
Ravi Ayyasamy
Krishnakant M. Patel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kodiak Networks Inc
Original Assignee
Kodiak Networks, Inc.
Ravi Ayyasamy
Krishnakant M. Patel
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US56995304P priority Critical
Priority to US60/569,953 priority
Priority to US57930904P priority
Priority to US60/579,309 priority
Application filed by Kodiak Networks, Inc., Ravi Ayyasamy, Krishnakant M. Patel filed Critical Kodiak Networks, Inc.
Priority to PCT/US2005/016534 priority patent/WO2005112494A1/en
Publication of CA2567041A1 publication Critical patent/CA2567041A1/en
Application status is Abandoned legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/40Services or applications
    • H04L65/4061"Push-to-X" services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/10Signalling, control or architecture
    • H04L65/1013Network architectures, gateways, control or user entities
    • H04L65/1016IMS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/10Push-to-Talk [PTT] or Push-On-Call services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/40Connection management for selective distribution or broadcast
    • H04W76/45Connection management for selective distribution or broadcast for Push-to-Talk [PTT] or Push-to-Talk over cellular [PoC] services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/02Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04Large scale networks; Deep hierarchical networks
    • H04W84/08Trunked mobile radio systems

Abstract

An architecture, client specification and application programming interface (API) for supporting advanced voice services (AVS) for use in handsets in order to support advanced voice services (AVS) for wireless communications systems. The handset or mobile unit executes a client application therein for performing the call setup and in-band signaling with the wireless network for the group voice services, and executes a presence/group management application therein for performing presence and group management functions related to the group voice services in the mobile unit.

Description

ARCHITECTURE, CLIENT SPECIFICATION AND APPLICATION
PROGRAMMING INTERFACE (API) FOR SUPPORTING ADVANCED VOICE
SERVICES (AVS) INCLUDING PUSH TO TALK ON WIRELESS HANDSETS
AND NETWORKS
CROSS REFERENCE TO RELATED APPLICATIONS
This application claims the benefit under 35 U.S.C. Section 119(e) of the following co-pending and commonly-assigned U.S. provisional patent applications:
Serial Number 60/569,953, filed on May 11, 2004, by Ravi Ayyasamy and Krishnakant Patel, entitled PRESS TO TALK CLIENT APPLICATION
PROGRAMMING INTERFACE (PCAPI), attorneys' docket number 154.9-US-P1;
and Serial Number 60/579,309, filed June 14, 2004, by Ravi Ayyasamy, Krishnakant Patel, and Gorachand Kundu, entitled CLIENT SPECIFICATION AND
ARCHITECTURE FOR SUPPORTING PRESS TO TALK AND OTHER
PREMIUM VOICE SERVICES IN WIRELESS NETWORKS, attorneys' docket number 154.15-US-P1;
both of which applications are incorporated by reference herein.
This application is a continuation-in-part and claims the benefit under 35 U.S.C. Sections 119, 120 and/or 365 of the following co-pending and commonly-assigned patent applications:
Serial Number 10/515,556, filed on November 23, 2004, by Gorachand Kundu, Ravi Ayyasamy, and Krishnakant Patel, entitled DISPATCH SERVICE
ARCHITECTURE FRAMEWORK, attorneys' docket number 154.4-US-WO, which application claims the benefit under 35 U.S.C. Section 365 of the following co-pending and commonly-assigned PCT international patent application:
Serial Number PCT/US03/16386, filed on May 23, 2003, by Gorachand Kundu, Ravi Ayyasarny, and Krishnakant Patel, entitled DISPATCH SERVICE ARCHITECTURE FRAMEWORK, attorneys' docket number 154.4-WO-U1, which application claims the benefit under 3S U.S.C.
Section 1 I9(e) of the following co-pending and commonly-assigned U.S.
provisional patent applications:
Serial Number 60/382,981, filed on May 24, 2002, by Gorachand Kundu, Ravi Ayyasamy, and Krishnakant Patel, entitled RADIO GATEWAY ARCHITECTURE FRAMEWORK, attorneys' docket number 154.3-US-P1;
Serial Number 60/383,179, filed May 24, 2002, by Gorachand Kundu, Ravi Ayyasamy, and Krishnakant Patel, entitled DISPATCH
SERVICE ARCHITECTURE FRAMEWORK, attorneys' docket number 154.4-US-P1; and Serial Number 601407,168, filed August 30, 2002, by Gorachand Kundu, Ravi Ayyasamy, and Krishnakant Patel, entitled DISPATCH SERVICE ARCHITECTURE FRAMEWORK, 1S attorneys' docket number 1S4.S-US-P1; and Serial Number PCT/US04/23038, filed on July 16, 2004, by F. Craig Farrill, Bruce D. Lawler, and Krishnakant M. Patel, entitled PREMIUM VOICE SERVICES
FOR WIRELESS COMMUNICATIONS SYSTEMS, attorneys' docket number 154.7-WO-U1, which application claims the benefit under 3S U.S.C. Section 119(e) of the following co-pending and commonly-assigned U.S. provisional patent applications:
Serial Number 60/488,638, filed on July 18, 2003, by F. Craig Farrill, Bruce D. Lawler and Krishnakant Patel, entitled REAL-TIME EXCHANGE, attorneys' docket number 154.7-US-P1;
2S Serial Number 60/492,650, filed August S, 2003, by Bruce D. Lawler, Krishnakant Patel, and F. Craig Farrill, entitled CDMA PRESS-TO-TALK
(P2T) PROOF=OF-CONCEPT DEMONSTRATION, attonieys' docket number 154.8-US-P1; and Serial Number 60/576,094, filed June 2, 2004, by Craig Farnll, Bruce Lawler, and Krishnakant Patel, entitled TECHNIQUE FOR ZERO DELAY
CALL SET-UP IN P2T SYSTEMS, attorneys' docket number 154.14-US-P1;
all of which applications are incorporated by reference herein.
BACKGROUND OF THE INVENTION
1. Field of the Invention.
This invention relates in general to wireless communications systems, and more specifically, to an architecture, client specification and application programming interface (API) for supporting advanced voice services (AVS) including push-to-talk or press-to-talk on wireless handsets and networks.
2. Description of Related Art.
Group-based voice services, such as two-way half duplex voice calls within a group or between individuals, also known as "Push-to-Talk," "Press-to-Talk,"
PTT or P2T, have enormous revenue earnings potential for wireless networks, such as cellular networks and personal communications systems (PCS) networks. Corporate subscribers primarily use such services for coordinating field people or fleet users from a central location.
Currently, there are three major approaches employed in providing group-based voice services such as P2T in wireless networks. One approach requires the installation of a dedicated private network, parallel to the wireless network, to support the group-based voice services. NEXTEL uses such a system, based on a solution developed by MOTOROLA known as IDEN. However, a dedicated private network is costly to install and maintain and is employed by a few public wireless Garners.
Also, the IDEN system is non-standard, and hence cannot be used in standard wireless communications networks, such as those based on CDMA and GSM.
Another approach is based on Voice over IP (VolP) technologies. While this approach promises compliance with newer and emerging standards, such as GPRS

(General Packet Radio Service), UMTS (Universal Mobile Telecommunications System), etc., it does not provide a solution for carriers employing wireless networks based on existing standards, such as GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access), etc. However, even for the newer standards, solutions based on VoIP have serious drawbacks, including slower call setup, significant overhead, increased susceptibility to packet losses, low bit rate voice coders (vocoders), and significant modifications to the mobile handset.
There is a need, instead, for solutions that require only minimal upgrades to the handset.
Still another approach is that defined in the co-pending and commonly-assigned patent applications cross-referenced above and incorporated by reference herein. In this approach, group-based voice services are provided by a real-time exchange or dispatch gateway that interfaces to the wireless network to provide the group-based voice services therein, wherein both the real-time exchange and mobile handsets that use the group-based voice services communicate with each other using call setup and in-band signaling within the wireless network.
Notwithstanding these innovations, there is a need in the art for an architecture, client specification and application programming interface (API) for use in handsets in order to support advanced voice services (AVS) for wireless communications systems. The present invention aims to satisfy this need.
SUMMARY OF THE INVENTION
To overcome the limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, the present invention discloses an architecture, client specification and application programming interface (API) for use in handsets in order to support advanced voice services (AVS) for wireless communications systems.
The handset or mobile unit executes a client application therein for performing the call setup and in-band signaling with the wireless network for the group voice services, and executes a presence/group management application therein for performing presence and group management functions related to the group voice services in the mobile unit.
BRIEF DESCRIPTION OF THE DRAWINGS
Referring now to the drawings in which like reference numbers represent corresponding parts throughout:
FIG. 1 is a block diagram that illustrates an exemplary embodiment of a wireless communications network according to a preferred embodiment of the present invention;
FIG. 2 illustrates a proposed arclutecture for a real-time exchange according to the preferred embodiment of the present invention;
FIG. 3 is a state diagram that illustrates the operation of a push-to-talk call according to a preferred embodiment of the present invention;
FIG. 4 illustrates the high-level functional components and their interfaces inside a mobile handset according to a preferred embodiment of the present invention;
FIG. 5 illustrates the high-level functional components of the push-to-talk client application and presence/group management application according to a preferred embodiment of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
In the following description of the preferred embodiment, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration the specific embodiment in which the invention may be practiced. It is to be understood that other embodiments may be utilized as structural changes may be made without departing from the scope of the present invention.

Overview The present invention provides an architecture, client specification and application programming interface (API) for supporting advanced voice services (AVS) on handsets used in wireless communications networks.
Network Architecture FIG. 1 is a block diagram that illustrates an exemplary embodiment of a wireless communications network according to a preferred embodiment of the present invention.
Within the network 100, an RTX (Real-Time Exchange) 102, previously known as a Dispatch Gateway (DG), communicates with a MSC (Mobile Switching Center) 104 and PSTN (Public Switched Telephone Network) 106 using SS7 -ISUP/WIN/CAMEL (Signaling System 7 - Integrated Services Digital Network User Paa-t/Wireless Intelligent Network/Customized Applications for Mobile Enhanced Logic) messages at a signaling plane 108. A bearer path 110 implements a TDM
(Time Division Multiplexing) interface carrying PCM (Pulse Code Modulation) or TFO (Tandem Free Operation) voice frames. Support for TFO in this path 110 is negotiated between a BSC (Base Station Controller) 112 and the RTX 102 for each originating and terminating leg of a group call. The use of TFO ensures high voice quality (as voice vocoder conversion is avoided) between mobile-to-mobile calls.
When a subscriber originates a group call, the MSC 104 routes the call to the RTX 102. The MSC 104 also requests the BSC 112 via 116 to establish a radio traffic path 118 with a mobile unit or handset 120 via the BTS (Base Transceiver Station) 122 (as it does for a normal cellular call). At this time, the BSC 112 tries to negotiate TFO (if it is supported) on a TDM link with the far end (in this case, the RTX
102).
At the same time (after the MSC 104 terminates the group call request to the RTX 102), the RTX 102 identifies the terminating group users and their MS-ISDN
(Mobile Station - Integrated Services Digital Network) numbers. It sends an ISUP call origination request for each terminating handset 120. It may send requests directly to the MSC 104, PSTN 106 or IP network 124 via a PDSN (Public Data Switched Network) 126, Router 128, and/or Internet/Intranet 130, depending on the routing table configuration for terminating MS-ISDN numbers. Once the bearer path 110 is established, the RTX 102 begins a negotiation with the far end (in this case, the terminating BSC 112) for each terminating leg to a handset 120.
Once bearer paths 110 are established for originating and terminating legs for a group call, the RTX 102 switches (or duplicates) voice frames from the originating handset 120 to all terminating mobile handsets 120.
The RTX 102 may use an IP network 124 or the Internet/Intranet 130 for two different purposes. The IP network 124 or the Internet/Intranet 130 can be used in a toll bypass mode where two RTXs 102 can exchange voice traffic bypassing the PSTN 106. However, each RTX 102 is responsible for terminating traffic to its closest MSC 104. In this case, the IP network 124 or the Internet/Intranet 130 is used as a backbone transport of voice traffic between two RTXs 102.
The IP network 124 or the Internet/W tranet 130 can also be used for a registration and presence application. Since the MSC 104 will not direct a registration request from a handset 120 to the RTX 102 (because it would require changes in the MSC 104), the latter does not have any information of the registered mobile handsets 120. To circumvent this issue, a registration and presence application runs over an IP
stack in the handset 120. After the handset 120 registers for a data interface (i.e., obtaining an IP address) with the PDSN 126 (or Serving GSM Service Nodes (SGSN) in the case of GSM networks), the registration and presence application in the handset 120 registers with the RTX 102 using its IP address. The RTX 102 also uses this IP
interface to update the presence information of other group members to a handset 120.
An alternative embodiment would use the SMS (Short Message Service) transport to carry presence messages over a data channel. The RTX 102 interacts with the mobile handset 120 using predefined presence application related messages that axe transported as SMS messages. The same messages can be transported via the PDSN 126 interface, if group users have data service.

Real Time Exchange FIG. 2 illustrates a proposed architecture for the RTX 102 according to the preferred embodiment of the present invention.
The architecture includes a Call Processing system 200, Presence Server 202, Real-Time Event Processing system 204, one or more Media Managers 206, and an SMPP (Short Message Peer-to-Peer) Transport 208, as well as modules for various SS7 protocols, such as MTP-1 (Message Transfer Part Level 1) 210, MTP-2 (Message Transfer Part Level 2) 212, MTP-3 (Message Transfer Part Level 3) 214, ISUP
(Integrated Services Digital Network User Paxt) 216, SCCP (Signaling Connection Control Part) 218, and TCAP (Transactions Capabilities Application Part) 220 protocols.
The Call Processing system 200, Presence Server 202, Media Managers 204, SMPP Transport 206, and other modules communicate across an IP network 222.
The Real-Time Event Processing system 204 communicates directly with the Call Processing system 200, Presence Server 202, and the modules for various SS7 protocols. The modules for various SS7 protocols communicate with other entities via a SS7 Signaling Link 224. The SMPP Transport 206 communicates with a SMSC
(Short Message Service Center) gateway using the SMPP protocol 226. The Media Managers 204 communicate among themselves using the H.110 protocol 228 (or some other protocol, such TCP/IP).
The operation of these various components axe described in the co-pending and commonly-assigned patent applications cross-referenced above and incorporated by reference herein.
P2T State Diagram FIG. 3 is a state diagram that illustrates the operation of a P2T call according to a preferred embodiment of the present invention.

State 300 represents a mobile handset 120 in a NULL state, i.e., the start of the logic. A user pressing a P2T button or making a request to terminate a group call triggers a transition out of this state.
State 302 represents a mobile handset 120 in an active group call state. In this state, the user receives a chirp tone to start talking. The user responds by pressing the P2T button on the mobile handset 120 and talking. A talking user must hold the button. The mobile handset 120 ensures that only when the user presses the P2T
button is the reverse traffic channel is used to send voice frames, and the RTX 1'02 switches voice frames only in one direction, i.e., from talker to listener, which ensures the half duplex operation required for a P2T call.
State 304 represents the group "floor" being available to all members of the group. When the talking user releases the P2T button, the floor is available to all group members. All members of the group receive a "free floor" tone on their mobile handset 120. A user who requests the floor by pressing the P2T button first (in the "free-floor" state) is assigned the floor, wherein the network 100 sends a chirp tone to the successful user.
State 306 represents a mobile handset 120 being in an active group call state.
In this state, the user is listening to the group call. If a non-talking user presses the P2T button in a call active state, the user does not receive any response from the network 100 and remains in the same functional state.
State 308 represents a user receiving an "unsuccessful bidding" tone on his mobile handset 120, after the user pressed the P2T button, but was not granted the floor of the group call. The user subsequently starts listening to the voice message of the talking user.
Non-talking users (including the tallcing user who must release the P2T button to end the call thus becoming non-talking and making the floor available for others) can request the network 100 to end their respective call legs explicitly.
State 310 represents a terminating leg being released from the group call after the user ends the call.

State 312 also represents a terminating leg being released from the group call after the user ends the call.
State 314 represents all terminating legs being released from the group call when no member of the group bids for the floor within a specified time period.
Mobile Handset Components FIG. 4 illustrates the high-level functional components and their interfaces inside the mobile handset 120 according to a preferred embodiment of the present invention. The high-level functional components and their interfaces include a physical layer 400, layer 2 402, signaling layer 3 406, cellular voice application 408, P2T client application 410, SMS (or USSD (Unstructured Supplementary Services Data) or GPRS (General Packet Radio Service)) application 412 and presence/group management application 414.
Note that P2T client application 410 and presence/group management application 414 are incorporated without requiring any changes in signaling layer 3 406 and below. All the existing messages that the cellular voice application 408 and SMS application 412 use remain as is and no additional messages are required to be implemented.
The P2T client application 410 performs all the call signaling states described in FIG. 3, which are the same that are traversed through by the cellular voice application 408. However, in some cases, the actions or behaviors in a particular state may vary.
As an example, for terminating a P2T call, the P2T client application 410 in an "alerting" state does not play an alerting tone to the user and wait for user action.
Instead, it plays a small duration "alert" tone, sends a "connect" message immediately to the network 100 and joins the vocoder output to a speaker on the handset 120.
(Alternatively, the handset 120 could answer the call, and the RTX 102 plays the tone.) Similarly, the presence/group management application 414 messages are tunneled via SMS (or USSD or GPRS) messages and delivered to the SMS
application 412 by Layer 3 signaling 406, and vice versa. These messages are identified and handed over to the presence/group management application 414 for decoding. In one embodiment, the Wireless Village protocol messages are used between the handset 120 and the RTX 102 for presence and group management operations, although other messages could be used as well.
P2T Client Application and Presence/Group Management Application FIG. 5 illustrates the high-level functional components of the P2T client application 410 and the presence/group management application 414 according to a preferred embodiment of the present invention.
In tlus embodiment, the P2T client application 410 includes a message transport layer 500, encoder 502, decoder 504 and database 506. In addition, the P2T
client application 410 provides an application programming interface (API) for use by other components of the handset 120.
~ther components in the handset 120 that use the API of the P2T client application 410 include the presence/group management application 414, a user interface 50~, call manager 510 and non-volatile (NV) memory 512.
. The P2T client application 410 itself interfaces to the operating system 514 of the handset 120 in order to perform its functions.
The transport layer 500 delivers encoded messages from the handset 120 to a destination presence server 202 in the RTX 102. The media used to transport these messages could be SMS, USSD or GPRS. The transport layer 500 can be configured for any of these media based on the configuration parameters.
The transport layer 500 implements a queue to transport the messages from the handset 120. The transport layer 500 also notifies the upper layer modules, such as the presence/group management application 414, about the failure or success of the message transport. In case of any failures in sending the messages, the transport layer 500 handles the re-transmission of the messages. The retransmission parameters are configurable and can be modified at run time without affecting the other module functionalities.
As noted above, the presence server 202 and handset 120 communicate using Wireless Village messages. The encoder 502 encodes the Wireless Village messages, and handles message fragmentation, if necessary.
The decoder 504 decodes incoming Wireless Village messages from the RTX
102 and populates specific data structures in the handset 120. The decoder 504 checks the validity of the incoming messages by verifying mandatory parameters for each of the incoming messages. A message will not be processed further if the decoder 504 fails to decode the message.
The presencelgroup management application 414 does the most of the processing of the Wireless Village messages. The decoded message from decoder is sent to the presence/group management application 414 to take the appropriate action. In this regard, the presence/group management application 414 may interact with the encoder 502, database 506, transport layer 500 or user interface 508.
The presence/group management application 414 enables P2T subscribers to track the presence of fellow members of the group in the network 100 on their mobile handsets 120. It also provides a mechanism and API to carry-out group management operations on the handset 120, such as add member, delete member, etc. The communication interface between presence/group management application 414 and the presence server 202 in the RTX 102 may rely on either SMS (or USSD or GPRS) messages for transport.
Since most of the presence information is stored in the database 506, the database 506 is tightly integrated with the presence/group management application 414. The database 506 stores groups, contacts, presence and availability related information in the NV memory 512. The database 506 information essentially contains group and member information along with presence information associated with each group and member. .Apart from group and member information, the database 506 also stores subscriber information, such as privileges, presence information, etc. The other components of the handset 120 may interact with the database 506 to retrieve/update the group, members and presence information for various operations. The database 506 also has pointers to the native address book on the handset 120, which is stored in the NV memory 512, to provide seamless "alias"
naming for contacts between cellular calls and P2T calls.
The user interface 508 provides a mechaiusm for the user to view and manage groups, group members, contacts, presence and availability. The user interface also makes it possible to make P2T calls from the group/contact list screens.
The call manager 510 handles all the telephony related functionalities, such as P2T Group/Private/Dynamic Group calls. The call manager 510 implementation is device-specific and vendor-specific, and it interacts with the user interface 508 and database 506. The required information for call-related functionalities is obtained from the wrappers provided by the database 506.
The NV memory 512 is also used to store the configuration parameters, which can be updated by the RTX as required.
User Interactions with the Mobile Handset This section describes various scenarios that a group user may explicitly invoke through the mobile handset 120.
Table 1: User Interactions with the Mobile Handset No. User action Action by the P2T clientRemarks application 410 and presencelgroup management application 414 in the handset 1. The user powers The presence/group Each handset 120 on the is handset 120. management applicationconfigured with 414 the is notified when the address of the handset home 120 is turned on. The RTX 102 when it is resence/ ou mana ementrovisioned for grou application 414 sends service.
a "presence registration"
message to the home RTX
102. The presence/group management application interacts with the SMS
application 412 to transport this message to the SMSC
gateway and the SMSC
gateway routes the message to the home RTX 102 via the IP
network 124 (as e-mail).

2. The user powers The presence/group off the handset 120. management application is notified when the handset 120 is turned off.
The presence/group management application 414 sends a predefined "presence registration" message to the home RTX 102. The presence/group management application 414 interacts with the SMS application 412 to transport this message to the SMSC gateway and the SMSC gateway routes this message to the home RTX

102 via the IP network (as e-mail).

3. The user presses The P2T client applicationThe MSC 104, based the P2T button on 410 is invoked. It on the DP trigger, the sends a call handset 120 to origination message sends a query to contact with the the the default group.called party's addressRTX 102 with the parameter filled with called party's a DP address.

trigger code, a code The RTX 102 responds to identify a private/groupwith its routing call number and the default group and sets up the id. A

bearer path is set terminating legs up and the for the vocoder inputloutput group. The call is setup connected to the microphoneis performed in parallel and speaker of the in order to improve handset call 120, res ectivel . setu time.

4. The user selects The P2T client application a 410 is invoked. It particular group sends a call from a origination message list of groups with the displayed called party's address on the handset parameter filled with 120 and a DP
presses the P2T trigger code, a code button. to identify the private/group call, and the selected MS-ISDN/group id. A bearer path is set up and the vocoder input/output is connected to the microphone and speaker of the handset 120, res ectively.

5. The user wants The P2T client applicationThe RTX 102 should to make a private call 410 is invoked. (A be able to isolate and private call the presses the P2T is considered a group MS-ISDN number button. call and (A private call where only two partiesgroup id based involves are on the only two parties.involved). It sends code.
The a call called party in origination message a private with the call may be a called party's address member of his/her subscribedparameter filled with a DP

group or he/she Trigger code, a code can to enter called party'sidentify a private/group call MS-ISDN number and the selected MS-ISDN

explicitly). number. A bearer path is set up and the vocoder input/output is to the microphone and speaker of the handset 120, res ectively.

6. The user selects The P2T client application a particular group 410 is invoked. It from sends a call the list of groupsorigination message with the displayed on the called party's address handset, marks parameter filled with a set of a DP

members and then Trigger code, a selected group presses the P2T id and the positions button. of the maxked members within the group. A bearer path is set up and the vocoder input/output is connected to the microphone and speaker of the handset 120, res ectively.

7. While in a group The P2T client application call 410 sends a "#" as active state, an in-band the user DTMF signal to the releases the P2T BSC 112.
button The BSC 112 injects to free the floor.this DTMF signal into the PCM
stream.

8. While in a group The P2T client application call active state, 410 sends a "*" as the user an out of presses the P2T band DTMF signal to button the to get the floor.BSC 112. The BSC 112 injects this DTMF signal into the PCM stream.

9. While in a group The P2T client application call active state, 410 sends a call release the user presses the "End"message to the MSC
104.

button explicitlyThe MSC 104 requests to the release the grouphandset 120 to clear call. its call states and sends a release message to the RTX
102. The RTX 102 releases that user's 1e from the grou call.

Note that the P2T client application 410 and presence/group management application 414 also may manage a P2C (Press-To-Conference) session in a manner similar to a P2T session. More information on P2C sessions can be found in the co-pending and common-assigned patent application Serial Number PCT/LTS04/23038, filed on July 16, 2004, by F. Craig Farrill, Bruce D. Lawler, and Krishnakant M.
Patel, entitled PREMIUM VOICE SERVICES FOR WIRELESS
COMMUNICATIONS SYSTEMS, attorneys' docket number 154.7-WO-U1, which application is incorporated by reference herein.
Network Interactions with the Mobile Handset This section outlines scenarios that occur when the P2T client application 410 and presence/group management application 414 in the mobile handset 120 interact with the network 100. Note that user is not aware of these scenarios as the P2T client application 410 and presence/group management application 414 in the mobile handset 120 handle these network-generated events in the background.
Table 2: Network Interactions with the Mobile Handset No. Causing Event/ScenarioAction by P2T clientRemarks in Mobile application 410 and presence/group management application 414 in the Mobile Handset 120 1. A cellular call The P2T client applicationThe indicator terminates for to the handset 120 410 is invoked. It group call in which does not the the calling party play an alerting calling party's starts tone to the address with a "*" (in an user as specified should be unique alerting in the state). The call "Alert With Info" enough so that it is termination identifiermessage. Instead, never used in can it plays a be either a prefix a small duration cellular call.
or a (e.g., 200 suffix. ms) special group call terminating alerting tone, immediately sends a connect message to the network 100, and connects the vocoder output to the speaker of the handset 120.

2. While in a group The P2T client application call active state, a 410 releases allocated release event is received resources in the from handset the network 100. 120 and sends a "release complete" message to the network 100. There are two possible scenarios:
(1) the originator disconnects and the call goes on, or (2) the originator disconnects and the entire call is ended.

3. A Presence Update The presence/group Notification messagemanagement application is delivered through 414 is invoked to the decode SMS interface. the message. It adds/deletes/modifies the member's information with the presence information in the specific group indicated in the message. There is a special WV delimiter that differentiates this from re lar SMS/data.

4. An Auto ConfigurationThe presence/group Update message is management application delivered through 414 is invoked to the decode SMS application the message.
412.

This message is Configuration parameters received only once when a for the P2T client user is provisioned for application 410 group and voice service. presence/group management application 414 are set.

Service Interactions with the P2T client application A handset 120 can support either cellular or group voice service at any instant of time. This section highlights various scenarios when the two services may conflict with each other. In some of these cases, the user's intervention is needed to select one of the services, whereas other cases are decided by the P2T client application itself as part of the call processing logic. This section also discusses the impact of other cellular services, such as call hold, call forwarding, call forwarding busy, call waiting, call forwarding no answer, etc., on group voice services.
The following table has been prepared with the assumption that, while using group voice services, a user cannot put other parties on hold, even though they can switch to another call without disconnecting the group call leg. However, a user can leave a group call session at any time by selecting an "end" soft key. The objective is to allow group members to continue with the call, while one or more legs can either be released from the RTX 102 or disjoined at the MSC 104 (at the time of service switching) during a session. The network 100 releases a group call only when the floor remains free for some predefined time. If a talking user leaves the session, the network 100 will make the floor available to all others.
It is also assumed that a member of a group has call waiting, calling number presentation at call waiting, call forwarding busy (to voicemail) and calling line identity presentation features enabled on the handset 120.
Table 3: Service Interactions for the P2T client application No. Present State Triggering Action by the Remarks (in Event P2T
Mobile) client application 410 and presence/group management application 414 in the Mobile Handset 1. A group voice Another group (1) In this case,For (1), call or the the is in an activecellular call P2T client applicationuser remains state is as and the user being terminated410 sends a DTMFa non-talking is talking with by the MSC signal to free leg to the the 104 the RTX

P2T button pressed.and a call-waitingfloor. Next, 102, even the P2T

tone is played.client applicationthough the The user is sends a "Flash circuit is with prompted to Info" message broken at to the accept the accept the secondMSC 104.
second The call. The call, while the RTX 102 may first following call is broken release all at the legs scenarios can MSC 104. After of the 'call at occur: (1) attending to any time.
the user the releases the second call, P2T the user button and may toggle to the first accepts the call. (2) In this case, second call; the P2T client (2) the user releasesapplication 410 sends the P2T button,a DTMF signal to ends the activefree the floor.
Next, it call and acceptsreleases the active the second call and the call; second (3) the user call is established.
does (3) not accept The MSC 104 the waiting secondhandles the second call and continuescall using a "call with the firstforwarding no call.

answer" feature provisioned for the user.

2. A group voice Another group (1) In this case, call or the is in an activecellular call P2T client application state is and the user being terminated410 sends a "Flash is not talking (i.e., by the MSC with Info" message does 104 to not press the and the call- accept the second button). waiting tone call, while the is first played. The call is broken user at the-is prompted MSC 104. After to accept the attending to the second call. The second call, the user following may toggle to the first scenarios can call. (2) In this case, occur: (1) the P2T client the user accepts the application 410 second call, releases the active (2) the user ends call and the second the active call call is established.
and (3) accepts the In this case, the MSC

second call, 104 handles the or (3) the user does second call using not the accept the "call forwarding waiting no call and continuesanswer" feature with the firstprovisioned for call. the user.

3. A cellular voiceAnother group Similar to the call is in an activecall is terminatedprevious case.
state by the MSC

and the "call-waiting" tone is played. The user's action is similar to the revious case.

4. A group call The user wants(1) In this case,The first is in to the case an active stateoriginate anotherP2T client applicationmay lead and to a the user is cellular call.410 sends a DTMF 3-party call, talking The with the P2T following signal to free which should button the pressed. scenarios may floor. Next, the be avoided occur: (1) client a licationfrom a ou The 410 user releasessends a "Flash call the with P2T button Info" message perspective.
and to originates originate the the second second call, cellular call, or (2) while the user releasesthe first call is broken the P2T button,at the MSC 104.

ends the firstAfter attending to the active call, second call, the and user originates may toggle to the the first second call call. (2) In this (the case, user can originatethe P2T client a group call application 410 as sends well). a DTMF signal to free the floor.
Next, the P2T client application 410 releases the active call and then originates a cellular or group call (by pressing the P2T

button).

5. A group call The user wants(1) In this case, is in to the an active stateoriginate P2T client application with another a non-talking cellular call.410 sends a "Flash user The (the P2T buttonfollowing with Info" message is to free). scenarios originate the may second occur: (1) cellular call, the user while originates the first call a is broken second cellularat the MSC 104.

call, or (2) After attending the to the user ends second call, the the first user active call may toggle to and the first originates call. (2) In this a case, second call the P2T client (the user can alsoapplication 410 originate releases the active a group call). call and then originates a cellular or group call (by pressing the P2T

button .

6. A cellular voiceThe user wants(1) In this case, call to the is in an activeon mate a P2T client a lication state. P2T

call. The 410 sends a "Flash following with Info" message to scenarios originate the may second occur: (1) P2T call, while the user the originates first call is a broken at second P2T the MSC 104. After call by pressing attending to the the P2T button, second call, the or (2) user the user endsmay toggle to the the first first active call. (2) In this call case, and originatesthe P2T client a second P2T application 410 call.

releases the active call and then originates a group call (by pressing the P2T button).

Conclusion The foregoing description of the preferred embodiment of the invention has been presented for the purposes of illustration and description. It is not intended to be . exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not with this detailed description, but rather by the claims appended hereto.

Claims (14)

1. ~An apparatus for providing group voice services in a wireless network, comprising:
a mobile unit for communicating with a wireless network in order to provide group voice services with other mobile units;
the wireless network including a real-time exchange to provide the group voice services therein;
both the real-time exchange and the mobile unit providing the group voice services using call setup and in-band signaling within the wireless network;
the real-time exchange switching the voice frames for the group voice services from an originating mobile unit to all terminating mobile units across bearer paths in the wireless network;
the mobile unit executing a client application therein for performing the call setup and in-band signaling with the wireless network for the group voice services;
and the mobile unit executing a presence/group management application therein for performing presence and group management functions related to the group voice services in the mobile unit.
2. ~The apparatus of claim 1, wherein the group voice services comprises a Push To Talk (P2T) service.
3. ~The apparatus of claim 1, wherein the client application provides instant two-way half duplex voice messaging within a group of users of the wireless network.
4. ~The apparatus of claim 1, wherein the presence/group management application enables subscribers to track the presence of fellow members of a group in the network on their mobile units.
5. ~The apparatus of claim 1, wherein the presence/group management application provides a mechanism and application programming interface (API) to carry-out group management operations on the mobile unit.
6. ~The apparatus of claim 1, wherein the client application includes a group and member database for storing group-related and member-related information.
7. ~The apparatus of claim 1, wherein the mobile unit exchanges a set of defined in-band DTMF tones with the real-time exchange within the wireless network as call control events to regulate a group call.
8. ~A method of providing group voice services in a wireless network, comprising:
communicating between a mobile unit and a wireless network in order to provide group voice services with other mobile units, wherein the wireless network includes a real-time exchange to provide the group voice services therein and both the real-time exchange and the mobile unit provide the group voice services using call setup and in-band signaling within the wireless network;~
switching the voice frames for the group voice services in the real-time exchange from an originating mobile unit to all terminating mobile units across bearer paths in the wireless network;
executing a client application in the mobile unit for performing the call setup and in-band signaling with the wireless network for the group voice services;
and executing a presence/group management application in the mobile unit for performing presence and group management functions related to the group voice services in the mobile unit.
9. ~The method of claim 8, wherein the group voice services comprises a Push To Talk (P2T) service.
10. ~The method of claim 8, wherein the client application provides instant two-way half duplex voice messaging within a group of users of the wireless network.
11. ~The method of claim 8, wherein the presence/group management application enables subscribers to track the presence of fellow members of a group in the network on their mobile units.
12. ~The method of claim 8, wherein the presence/group management application provides a mechanism and application programming interface (API) to carry-out group management operations on the mobile unit.
13. ~The method of claim 8, wherein the client application includes a group and member database for storing group-related and member-related information.
14. ~The method of claim 8, wherein the mobile unit exchanges a set of defined in-band DTMF tones with the real-time exchange within the wireless network as call control events to regulate a group call.
CA002567041A 2004-05-11 2005-05-11 Architecture, client specification and application programming interface (api) for supporting advanced voice services (avs) including push to talk on wireless handsets and networks Abandoned CA2567041A1 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
US56995304P true 2004-05-11 2004-05-11
US60/569,953 2004-05-11
US57930904P true 2004-06-14 2004-06-14
US60/579,309 2004-06-14
PCT/US2005/016534 WO2005112494A1 (en) 2004-05-11 2005-05-11 Architecture, client specification and application programming interface (api) for supporting advanced voice services (avs) including push to talk on wireless handsets and networks

Publications (1)

Publication Number Publication Date
CA2567041A1 true CA2567041A1 (en) 2005-11-24

Family

ID=37574962

Family Applications (1)

Application Number Title Priority Date Filing Date
CA002567041A Abandoned CA2567041A1 (en) 2004-05-11 2005-05-11 Architecture, client specification and application programming interface (api) for supporting advanced voice services (avs) including push to talk on wireless handsets and networks

Country Status (4)

Country Link
EP (1) EP1749411A1 (en)
CA (1) CA2567041A1 (en)
IL (1) IL179124A (en)
WO (1) WO2005112494A1 (en)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7764950B2 (en) 2002-05-24 2010-07-27 Kodiak Networks, Inc. Advanced voice services architecture framework
US7403775B2 (en) 2002-05-24 2008-07-22 Kodiak Networks, Inc. Roaming gateway for support of advanced voice services while roaming in wireless communications systems
US7529557B2 (en) 2002-05-24 2009-05-05 Kodiak Networks, Inc. Press-to-connect for wireless communications systems
US10057105B2 (en) 2004-11-23 2018-08-21 Kodiak Networks, Inc. Architecture framework to realize push-to-X services using cloudbased storage services
US9485787B2 (en) 2005-05-24 2016-11-01 Kodiak Networks, Inc. Method to achieve a fully acknowledged mode communication (FAMC) in push-to-talk-over-cellular (PoC)
US7738896B2 (en) 2002-05-24 2010-06-15 Kodiak Networks, Inc. Subscriber identity module (SIM) enabling advanced voice services (AVS) including push-to-talk, push-to-conference and push-to-message on wireless handsets and networks
US9137646B2 (en) 2004-11-23 2015-09-15 Kodiak Networks, Inc. Method and framework to detect service users in an insufficient wireless radio coverage network and to improve a service delivery experience by guaranteed presence
CA2486072A1 (en) 2002-05-24 2003-12-04 Kodiak Networks, Inc. Dispatch service architecture framework
US7738892B2 (en) 2002-05-24 2010-06-15 Kodiak Networks, Inc. Architecture, client specification and application programming interface (API) for supporting advanced voice services (AVS) including push to talk on wireless handsets and networks
US10111055B2 (en) 2004-11-23 2018-10-23 Kodiak Networks, Inc. Optimized methods for large group calling using unicast and multicast transport bearer for PoC
US10178513B2 (en) 2004-11-23 2019-01-08 Kodiak Networks, Inc. Relay-mode and direct-mode operations for push-to-talk-over-cellular (PoC) using WiFi-technologies
US10367863B2 (en) 2004-11-23 2019-07-30 Kodiak Networks Inc. Method for providing dynamic quality of service for push-to-talk service
US10116691B2 (en) 2004-11-23 2018-10-30 Kodiak Networks, Inc. VoIP denial-of-service protection mechanisms from attack
US7813722B2 (en) 2005-02-18 2010-10-12 Kodiak Networks, Inc. Enhanced features in an advanced voice services (AVS) framework for wireless communications systems
US7689238B2 (en) 2005-08-03 2010-03-30 Kodiak Networks, Inc. Architecture and implementation of closed user groups and limiting mobility in wireless networks
US8036692B2 (en) 2005-08-08 2011-10-11 Kodiaks Networks, Inc. Brew platform enabling advanced voice services (AVS) including push-to-talk, push-to-conference and push-to-message on wireless handsets and networks
US7853279B2 (en) 2006-04-26 2010-12-14 Kodiak Networks, Inc. Advanced features on a real-time exchange system
US8761822B2 (en) 2007-09-24 2014-06-24 Qualcomm Incorporated Continuous interface maintenance for group communications to a wireless communications device group
US8676189B2 (en) 2008-01-24 2014-03-18 Kodiak Networks, Inc. Converged mobile-web communications solution
US8958348B2 (en) 2008-10-20 2015-02-17 Kodiak Networks, Inc. Hybrid push-to-talk for mobile phone networks
WO2011146205A1 (en) * 2010-05-21 2011-11-24 Kodiak Networks, Inc. Predictive wakeup for push-to-talk-over-cellular (poc) call setup optimizations
US9913300B2 (en) 2011-12-14 2018-03-06 Kodiak Networks, Inc. Push-to-talk-over-cellular (PoC)
CA2804368C (en) 2012-02-01 2018-03-13 Kodiak Networks, Inc. Wifi interworking solutions for push-to-talk-over-cellular (poc)
MX350027B (en) 2013-07-23 2017-08-23 Kodiak Networks Inc EFFECTIVE PRESENCE FOR PUSH-TO-TALK-OVER-CELLULAR (PoC) NETWORKS.
US10362074B2 (en) 2015-02-03 2019-07-23 Kodiak Networks, Inc Session management and notification mechanisms for push-to-talk (PTT)
CA3000202A1 (en) 2015-10-06 2017-04-13 Kodiak Networks, Inc. System and method for media encoding scheme (mes) selection
WO2017062627A1 (en) 2015-10-06 2017-04-13 Kodiak Networks, Inc. System and method for improved push-to-talk communication performance
DE112017002108T5 (en) 2016-04-22 2019-01-03 Kodiak Networks Inc. System and method for push-to-talk (ptt) on-button pressure call
US10257669B2 (en) 2016-12-01 2019-04-09 Kodiak Networks, Inc. PTX data analytic engine notifying group list of detected risk event
US10341823B2 (en) 2016-12-30 2019-07-02 Kodiak Networks Inc. System and method for direct mode push to talk communication protocols

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6026087A (en) 1997-03-14 2000-02-15 Efusion, Inc. Method and apparatus for establishing a voice call to a PSTN extension for a networked client computer
CA2486072A1 (en) 2002-05-24 2003-12-04 Kodiak Networks, Inc. Dispatch service architecture framework

Also Published As

Publication number Publication date
IL179124D0 (en) 2007-03-08
EP1749411A1 (en) 2007-02-07
IL179124A (en) 2011-06-30
WO2005112494A1 (en) 2005-11-24

Similar Documents

Publication Publication Date Title
US8576878B2 (en) Method for controlling parties in real-time data communication
CN1534972B (en) Fast netowrk STD/SDP procedure used for conference junction according to user's inquiry for optimizing netowrk resource
US7099291B2 (en) Dispatch call origination and set up in a CDMA mobile communication system
US7596102B2 (en) Image exchange for image-based push-to-talk user interface
KR100888098B1 (en) Method and system for use in reducing cost associated with lost connections in wireless communication
CN1853395B (en) Setting up communication sessions
ES2435518T3 (en) Word shift control for group call telecommunications services
DE60209230T2 (en) Process and system for a group calling service
KR100924513B1 (en) A method of communication
US7043232B2 (en) Method and system for sending personalized outgoing voicemail/multimedia mail messages based on the caller ID
US20080037746A1 (en) Method and system for automatic call redialing
US7058042B2 (en) One-to-one communication
US6392999B1 (en) Conferencing and announcement generation for wireless VoIP and VoATM calls
CN100348060C (en) A method and system for setting application settings for a push-to-talk service
US20050232241A1 (en) Method and apparatus for push-to-talk communications
US20150281170A1 (en) WiFi INTERWORKING SOLUTIONS FOR PUSH-TO-TALK-OVER-CELLULAR (PoC)
EP1738485B1 (en) Providing push-to-talk communications in a telecommunications network
JP2005535231A (en) Providing advanced communication mechanisms
US20040224678A1 (en) Reduced latency in half-duplex wireless communications
US7200139B1 (en) Method for providing VoIP services for wireless terminals
US20060111135A1 (en) Method to facilitate distribution of group identifications for push-to-talk groups
KR100605247B1 (en) System and method of expediting call establishment in mobile communication
EP2323457B1 (en) Enabling combinational services in a communications network
US6996414B2 (en) System and method of group calling in mobile communications
US6792281B2 (en) Method and system for patching dispatch calling parties together

Legal Events

Date Code Title Description
EEER Examination request
FZDE Dead

Effective date: 20140513