WO2007080517A2

WO2007080517A2 - Headset with voip capability for a cellular phone without voip capability

Info

Publication number: WO2007080517A2
Application number: PCT/IB2007/000106
Authority: WO
Inventors: Gregory Nathan; Poovandhran Chetty
Original assignee: Gregory Nathan; Poovandhran Chetty
Priority date: 2006-01-16
Filing date: 2007-01-16
Publication date: 2007-07-19
Also published as: WO2007080517A3

Abstract

A communication device to enable voice communication over a mobile phone within the mobile communication network that is not VOIP enabled for full duplex or half duplex voice using Voice over Internet Protocol (VOIP). The communication device includes a voice receiving module to receive voice to be transmitted over the mobile communication network. A data converter converts the received voice into a VOIP data set which VOIP data set is able to be received by a mobile communications device and then transmitted by the mobile communications device over the mobile communications network. A transmitter is used to transmit the VOIP data set to a mobile communications device using a protocol other than the SIP protocol used for VOIP, typically the Bluetooth data protocol. A communication device including an operating system compatibility chip to determine compatibility between the requirements of the data converter and the requirements of a data converter to which voice is being transmitted. based on the types of operating systems of the mobile communication devices.

Description

A COMMUNICATIONS DEVICE

BACKGROUND OF THE INVENTION

THIS invention relates to a communications device.

Mobile communication devices such as mobile telephones communicate with one another using a number of different protocols. One such protocol is the Voice over Internet Protocol (VOIP) which is the routing of voice conversations over the Internet or through any other IP-based network.

Using VOIP has a number of advantages with the main advantage for a user being that of cost savings. This is due to utilizing a single network to carry voice and data.

Therefore, a user of a mobile communications device might prefer using VOIP as they will in most cases pay a reduced rate.

However, a number of mobile telephones are not VOIP enabled. Also, mobile telephones in the market, typically with RAM of less than 128Kb, that are VOIP enabled do not allow for both asynchronous VOIP (e.g. push to talk) and synchronous full duplex conversation on the phone between users. There also exists a problem with JAVA phones at present in that the application programmer is unable to intercept the phone codec functionality using newer and older versions of the JAVA application type software (MIDP1 and MIDP2) which are non VOIP enabled phones.

There does exist VOIP (e.g. using push to talk) enabled JAVA phones. This invention addresses mobile phones that are intrinsically not enabled for real time VOIP conversation (full duplex and half duplex). Examples of non-VOIP enabled phones include: Motorola E770v, 3G Motorola V3x Razr, Nokia 6230 (2G), LG 3G Chocolate, Sony Ericsson v600i. Furthermore the lack of software programming interfaces on JAVA phones for wireless Access Point Network (APN) and special commands for modem type activity (e.g. data connection > establishment and monitoring) reduces or eliminates the possibility of standardising the software link connectivity methods within the mobile phone for bearers (3G, GPRS, EDGE) required to establish such communication. The execution of two way (full duplex) synchronous real time VOIP communication is therefore not currently possible across generic commercially available JAVA phones.

The present invention seeks to address these and other drawbacks.

SUMMARY

A communication device is provided to enable voice communication over a mobile communication network using Voice over Internet Protocol (VOIP), the communication device includes:

a voice receiving module to receive voice to be transmitted over the mobile communication network;

a data converter to convert the received voice into a VOIP data set which VOIP data set is able to be received by a mobile communications device and then transmitted by the mobile communications device over the mobile communications network; and

a transmitter to transmit the VOIP data set to a mobile communications device using a protocol other than the VOIP protocol.

The VOIP data set is able to be received by a mobile communications device that is not VOIP enabled. The device enables half duplex and full duplex voice communication.

The VOIP data may be able to be received by a mobile communications device that is VOIP enabled and is unable to provide either synchronous or asynchronous VOIP communication services.

In one example the transmitter is a Bluetooth transmitter to transmit, the VOIP data set to the VOIP mobile communications device using the Bluetooth protocol.

The data converter may be a codec.

The device may further include a modem such as a GPRS, 3G or other mobile bearer technology modem.

The device may also include a voice activation module.

In addition, the device may include a data buffer.

In one example the device includes an operating system compatibility chip to determine compatibility between the requirements of the data converter and the requirements of a data converter to which voice is being transmitted based on the types of operating systems of the mobile communication devices.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows an example embodiment of a communications device;

Figure 2 shows an example block circuit diagram of the communications device of Figure 1 ; and

Figure 3 shows an example environment within which the device operates. DESCRIPTION OF PREFERRED EMBODIMENTS

Figure 1 shows an example embodiment of a communication device 10 to enable voice communication over a mobile communication network using Voice over Internet Protocol (VOIP).

In one example embodiment the communication device 10 takes the form of a headset. The headset includes a voice receiving module including a microphone 12.

The communication device 10 includes a speaker 14. The headset can be placed on a user's head either by means of a headband or by means of an earpiece, for example.

Referring now to Figure 2, a block circuit diagram of the communications device 10 is shown.

The speaker 14 and microphone 12 are connected to an amplifier 16 to amplify the signals to and from these components.

The voice receiving module receives voice to be transmitted over the mobile communication network.

In the illustrated embodiment the device 10 includes a codec (coder- decoder) 18. The codec 18 converts the audio signal from the microphone 12 into a compressed digital form or VOIP data set for transmission.

The codec will typically be a low bit rate codec (e.g. AMR 4.8kbit/s to 8kbit/s). The codec is also specially designed to also allow its function to be downloadable from a website. A digital processing chip 24 will process the non-compliant phone and a programming application in the RAM 20 will determine which software codec should be downloaded to the headset. The headset application will then instruct the client application on the phone to create a Wireless Application Protocol (WAP) download activation, which then automatically alerts the user to download the compatible codec. This is a once off setup operation.

Furthermore, when users of incompatible phone manufacture types are communicating with each other, for example, between Symbian and JAVA phones, the Symbian phone inbuilt codec (of AMR type) will communicate to the other JAVA phone headset with the hardware AMR codec. The matching codec on the phone will be a software codec that performs the necessary digital processing of the digital bits received from the headset codec. If the codec functionality is unknown then it will be simulated with a combination of hardware via the Java compatibility DSP chip 24 and software processing 20.

The choice of codec and location of the digital signal processing of the analog information received via the microphone 12 will be based on the extent of cross compatibility required between phones of different operating systems (e.g. Symbian, Java, Windows Mobile, Linux etc). All headsets will at least have an inbuilt AMR codec 18 to address the generic compatibility requirements across the Symbian/Windows Mobile and the JAVA platforms. The headset codec is to create independence of the need to access the JAVA inbuilt phone codec or a codec on a standard Bluetooth headset which is not interceptive by commercial application software. The interfaces in the new headset are also designed such that key functionality which is inaccessible by the current art using especially JAVA phones, that is, the codec, phone modem, APN at the server are now made accessible via the JAVA compatibility DSP 24 and the GPRS/3G modem 32.

An onboard RAM 20 provides random access memory for processing that cannot be done on board a mobile communications device such as a mobile phone that the headset will communicate with. It may also store key user default information settings of the headset such as the preset volume information or standby time settings to automatically switch the headset off after non active usage time limits expire. The RAM 20 will contain the executable instruction set to enable the headset to operate as a modem (modulator demodulator).

3G phones require special instruction set processing which will be built into a hardware component GPRS/3G modem 30. The GPRS/3G modem 30 attends to asynchronous processing of setup of the connectivity to the APN that may not be able to be setup within the RAM or the DSP. Special quality of services instructions (e.g. checking tower signal strength, phone signal strength) will require a separate interface for the extended 3G modem functionality to be housed in this component and accessible to users having 3G phones of different vendors.

The headset needs to operate as a modem as a key need for the headset is the use of its Bluetooth interface at the level of interaction with the phone. It is the Bluetooth interface functionality which provides specific modem access to the server access point network. The setup, control and signaling instruction set within the JAVA API on the phone alone is inadequate to setup and maintain a VOIP conversation. The purpose of the Bluetooth headset is primarily linked directly to need to use this specific form of transmission medium, namely the Bluetooth transmission standard and its programming interfaces thereby enabling modem connectivity with the secondary purpose (and equally important) to allow for the transit of data to the phone.

The RAM 20 also allows for easy upgradeability in the event of the user changing his/her phone model. This prevents the need to purchase a new headset.

A Read Only Memory (ROM) 22 will serve as the separate central processing unit execution instruction set for the headset and the software programming instruction set on the headset will control how data flows between the mobile phone and headset (and vice versa). Because ROM cannot be written to, its main use for the headset would be in the distribution of firmware.

A JAVA compatibility digital signal processor (DSP) 24 is a hardware component to allow a non-VOIP enabled JAVA phone to be VOIP enabled and to cater for additional hardware devices necessary to bridge the missing hardware interfaces (e.g. codec addition, hardware digital signal processor) required across different major mobile phone handset manufacturers to carry voice over IP.

A voice activation detection module 26 is a speech detection module that reduces the need for extended memory caching requirements and addressing ^■ the requirements for push to talk over lower bandwidth bearers such as GPRS . By its nature push to talk relies on lower packet throughput to attain the need for an acceptable quality of service for the user. The ordinary software IP interfaces which uses the RTP (real time protocol) would in itself require the adaptive mechanism of the voice activation detection module to determine the precise capture points, buffer and transmission sequence of the voice packets needed for push to talk at both user end conversations.

The voice activation detection module 26 operates by monitoring the received signal for voice activity. This prevents the DSP 24 encoder output from being transported across the network when there is silence to save bandwidth. This voice activation module 26 also measures the idle noise characteristics of the headset interface. It reports this information to the software interface on the RAM chip 20 in order to properly compensate for noise generation when no voice is present.

The voice activation detection module 26 is based on energy detection and provides time stamping of the state changes between the presence of voice activity (start event) and the removal of voice activity (stop events). The voice activation detection module 26 allows the headset to configure the maximum threshold level to start recording, minimum threshold level to stop recording, switch activation debounce time, switch deactivation debounce time and pre- speech buffer size.

A Bluetooth transceiver 28 is a radio frequency chip based on the version 2 Bluetooth technology or other Bluetooth technologies (e.g. USB Bluetooth). The Radio Frequency (RF) input passes through the amplifier 16 and then flows though a special mixed-signal preprocessor followed by a digital processor (not shown). The resulting radio design is fully integrated with the digital baseband processing unit. The baseband processing unit converts the high frequency of Bluetooth to a low frequency range within the audio frequency band. The detail is not shown as this is a standard hardware component within any Bluetooth headset.

Almost all passive elements such as varactors, external SAW filters, VCOs (Voltage controlled oscillators), and resonators are either eliminated or integrated into the Bluetooth Transceiver.

A PTT buffer 30 is included within the headset for the purposes of JAVA phone communication. It controls the data flow to the external mobile communications device and acts as a data recorder of the speech signal produced by the user's speech. The PTT (push to talk) buffer will be used to record speech needed for asynchronous real time push to talk which ability is not embedded within a standard Bluetooth headset.

An echo canceller 34 is included as one of the problems that results from high end-to-end delay in a voice network is echo. Echo becomes a problem when the round-trip delay is more than 50 milliseconds. Since echo is perceived as a significant quality problem, VOIP systems must address the need for echo control and implement some means of echo cancellation.

An MP3 service component 36 allows the device to extend it's audio capability to allow the phone or other wireless devices to stream high quality audio to the headset.

An RTP/RTCP module 38 provides end-to-end network transport functions suitable for applications transmitting real-time audio in the form of data, video or simulation data.

A Data Clock module 40 control gates of clocks not needed by certain components to achieve the necessary power management. The clock control also facilitates a clock recovery scheme and an alternate clock source plan in the event of clock failure. If the clocks of the transmitter device 10 of the sender and receiver device 10 of the receiver are too far out of synchronization, the transmitter may fill the receive buffer faster than the receiver can process the incoming packets. The data clock control compensates for this buffer overrun. Clock Drift can also cause packet delay and loss.

The headset works as follows, a user requests to talk to another user via a client application on a mobile telephone which will be used in conjunction with the headset of the present invention. The user initialization process is interactive and menu driven by the application residing on a mobile telephone. The user selects a member of the user group that he or she wants to engage in a media communication. If the end user is not online, he may be alerted synchronously via a pop up alert displayed within the mobile phone application (in certain implementations of JAVA or Symbian) or alternatively alerted asynchronously, for example, via SMS sent from within the application or alternatively a specific signal ring tone call that signals that the caller needs the destination party to go online.

Alternatively, if the originator is online, then a Session Initiation Protocol (SIP) call will be made with the mobile phone acting as a conduit for the Voice over data. The remote SIP server establishes the connection to the targeted party and the call originating user is able to commence such media communication with that target party.

This occurs with the JAVA phone application software requesting the modem 32 on the headset to open a modem channel on the phone via its Bluetooth interface.

The user then talks which is received by the microphone 12.

In a low bandwidth scenario in order to speak the user may push and hold a button on their headset, which forms a start marker to such conversation. Alternatively software within the specially designed headset 10 or software residing on the mobile telephone is able to automatically detect the start and end of a continuous sentence based on pause intervals detected within the speech pattern. A PTT buffer which will be explained in more detail below controls the data flow to the mobile telephone and acts as a data recorder of the speech signal produced by the user's speech.

In any event, speech is converted into data on the headset 10 and relayed via the Bluetooth interface of the standard mobile phone. The transformed data information is relayed via the radio frequency interface of the phone to the nearest mobile phone network tower, which receives such signal and channels such information to the public internet or private access point network linked to the internet. Ultimately the data will be received by a destination server which will control the media session, including duration of the session, charging, validation, user authentication and synchronisation of the transformed data.

The targeted user receives the transformed data information via the radio frequency interface of the target mobile phone. The mobile phone application channels the data via the Bluetooth radio frequency interface of the phone to a separate Bluetooth device headset of the target user. Data is converted back into voice and the target user is able to hear the originating user's speech in a coherent representation.

Figure 3 illustrates an example environment within which the device may be used showing the device 10 in contact with a mobile communications device 42. The mobile communications device 42 communicates via a mobile communications network 44 with another mobile communications device 46. The second mobile communications device 46 may or may not be in contact with a headset 10 depending on the capability of the second mobile communications device 46. It will be appreciated that the mobile communications devices 42 and 46 may be Java and/or Symbian type phones. The terminating user can also similarly communicate with the other users using the above operational mechanism on their headset linked to their mobile telephone.

Where client server bandwidth exceeds the minimum bandwidth for media communications by the specified bandwidth constraint (for example, voice channel bandwidth exceeds 14 kilobits per second to cater for the minimum data packet compression payload overhead produced by the headset) simultaneous two way conversions without the need for using the above push to talk mechanism is processed via the headsets of both users. The above data processing flow through devices remains similar to the above mentioned. The GSM mobile network operates at circa 14kbps (overhead is included due to need for signaling data being included in the bit stream). Improved compression toward 4 kilobits per second is achievable by shifting the high CPU and DSP hardware or software processing requirements toward the headset with this interface functionality also being resident in the inventive headset communication device. A flexible compression scheme is designed to allow compression to slip between different compression throughput mechanisms in networks where bandwidth required for voice communication moves between extremes.

In any event, once the microphone 12 senses the user's speech, the sensed analog signal is transmitted by the codec that converts the speech into digital format.

The JAVA compatibility chip 24 determines the local and far end (other user) codec processing requirements and prepares voice samples for transmission over the Bluetooth interface of the headset. The headset components linked to the JAVA compatibility chip 24 perform echo cancellation, voice-activity detection, jitter removal, clock synchronization, and voice packetisation that will vary dependant on the phone type (manufacturer of phone and the phone operating system). The packets are then received on the phone and pushed toward the server communicating using SIP. The server then pushes the data stream toward the receiving user's mobile phone. The receiving user's phone streams the data stream toward the Bluetooth interface which is then received on the headset transceiver chip which is then transmitted to the Bluetooth codec.

The RAM 20 controls the processing actions and interface dependencies within the headset. This^' relieves the memory processing overhead of the phone.

The PTT buffers control the packetisation throughput (in the case of a Push to talk service type) and the JAVA compatibility DSP 24 shapes the data stream into an acceptable quality of service level by adjusting for differences in phone types, operating system types, losses in impairment parameters and memory capacity of the phone.

The PTT (half duplex) service and real time full duplex VOIP service cannot together be accomplished on older JAVA MIDP1 type phones without the additional RAM processing needed for packetisation control performed by the JAVA compatibility DSP 24. The older type phones support only 64 kilobytes of RAM and a minimum of 45 kilobytes is required for a graphical thin client with an acceptable user experience with multiple service types. This remaining 19 kilobytes is inadequate for software processing on the phone itself. Aside from memory, the processing speed of a normal handset is variable and the VOIP functionality cannot be dependable if the core processing is relegated to the phone since the processing requirements within software requires a multitasking algorithm. The lowest tick (rate at which the software loops through a common break point in a multitask loop) for VOIP software on the phone will not be sufficient to carry extended functionality for bidirectional real time VOIP and PTT, high graphical phone client processing and server processing. The processing ability of the chip will be constant, therefore known and dependable across phone types of different manufacturers. The mobile phone application referred to above is primarily a router of data which data arrives on the mobile phone device. The data is routed to the GSM network via a data bearer technology (e.g. 3G or GPRS). The internet interface protocol is SIP (Session initiation protocol) which is an application, layer protocol between the client (phone and Bluetooth headset) and the server. SlP will be used for creating, modifying, and terminating sessions with one or more user participants. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorise users for services, implement provider call-routing policies, - and provide features to users. The application also presents a graphical user interface allowing the user to experience seemless connectivity in an easily understandable representation. A standardised J2ME platform (for mobile phone devices) and Symbian platform (for PDA devices) enables the software controlled routing of transformed data on the mobile device.

Thus it will be appreciated that the device is enabled for VOIP using SlP interfaces/RTP (Real time protocol)/RTCP and adaptable for use of the Push to talk service which is dependant on different voice control mechanisms such as the voice activation detection and PTT buffer recording. A standard Bluetooth headset is not real time IP enabled allowing for simultaneous two way conversation using voice over data. However a standard Bluetooth headset will be able to communicate with a phone enabled with VOIP software/hardware.

The purpose of a standard Bluetooth headset is then primarily for wireless communication to the phone and performs as a normal Bluetooth headset since the VOIP functionality of a VOIP enabled phone is then independent of the headset. The latter scenario does not however address the need to apply two key service types on the same phone and across generic phones of different vendors.

In the case of the invention, the separate VOIP client application developed for the phone is extensible to allow for compatibility with the special headset (where it is required as in the case of JAVA) and to allow for software VOIP processing within 2G phones where the RAM specification is a minimum of 64 kilobytes or the 3G high end processing phones supporting high RAM and operating system specifications (greater than or equal to 128 kilobytes) with Symbian or windows operating systems.

Transmission integrity is assured by the hardware and software of the inventive headset and not of the mobile phone. Transmission integrity on normal Bluetooth headsets is controlled via the hardware and software within the mobile phone that is inaccessible or uncontrollable by the application programmer.

In addition, connectivity to a wireless APN (wireless access service provider) or ISP (internet service provider) is created by a modem chip on the headset. A modem chip is not available on normal headsets. Generally where modems are available on normal JAVA phones, they are not Voice enabled, that is, there is no inbuilt mechanism to control the setup of a voice call and management of the call.

There is no mechanism in current headsets or phones to include software or hardware whose function is to compensate for key voice impairment parameters such as delay, jitter and packet loss whilst the headset described above compensates for these.

The special headset also provides extensions of command sets not provided on 2G phones for the purposes of quality control for VOIP.

A vendor plug-in is not available on a headset to address the universal connectivity of the headset to phones of different vendors. The headset modem 32 described above will issue vendor-specific AT commands to determine if the modem receiving interface is supported and what . command sets are applicable. A standard Bluetooth headset does not contain VOIP functionality suited for carrying full duplex and/or half duplex voice content to other users in real time.

In addition, a standard Bluetooth headset assumes that the receiver of data or access point within range wants to receive media data in the same format. There is no thinking software or hardware on the Bluetooth device to determine which data channel link types (such as full duplex or half duplex) and data rate adjustments at each end should be used. However, the receipt of data in the same format may not always be appropriate. Consider the case where participants in one area are connected through a low-speed link to the majority of the conference participants who enjoy high-speed network access. Instead of forcing everyone to use a lower- bandwidth with reduced-quality audio encoding, an RTP-level relay called a mixer is placed near the low-bandwidth area. This mixer resynchronizes incoming audio packets to reconstruct the constant 20 ms spacing generated by the sender, mixes these reconstructed audio streams into a single stream, translates the audio encoding to a lower-bandwidth one and forwards the lower-bandwidth packet stream across the low-speed link to the receiver who is able to receive data at a lower throughput.

A standard Bluetooth headset does not require a separate application via the commercial API on the mobile phone to function, whereas the headset design needs an application interface on the phone to assist with the capture and transmission of data to the mobile network.

The JAVA compatibility DSP chip 24 present on the headset design creates synchronous and asynchronous VOIP communication on JAVA enabled phones and enables cross compatible VOIP functionality between different vendor operating systems (e.g. between JAVA and Symbian). Part of the cross compatibility functionality is to address the codec differences between different vendor operating systems by allowing for the required interface elements of the vendor to be designed within a hardware chip.

Claims

CLAIMS:

1. A communication device to enable voice communication over a mobile communication network using Voice over Internet Protocol (VOIP), the communication device including:

a data converter to convert the received voice into a VOIP data set which VOIP data set is able to be received by a mobile communications device and then transmitted by the mobile communications device over the mobile communications network; . and

2. A communication device according to claim 1 wherein the VOIP data set is able to be received by a mobile communications device that is not VOIP enabled.

3. A communication device according to claim 1 or claim 2 wherein the device enables half duplex and full duplex voice communication.

4. A communication device according to claim 1 wherein the VOIP data is able to be received by a mobile communications device that is VOIP enabled and is unable to provide either synchronous or asynchronous VOIP communication services.

5. A communication device according to claim 1 wherein the transmitter is a Bluetooth transmitter to transmit the VOIP data set to the VOIP mobile communications device using the Bluetooth protocol.

6. A communication device according to any preceding claim wherein the data converter is a codec.

7. A communication device according to any preceding claim further including a modem.

8. A communication device according to claim 7 wherein the modem is a GPRS, 3G or other mobile bearer technology modem.

9. A communication device according to any preceding claim further -, including a voice activation module.

10. A communication device according to any preceding claim further including a data buffer.

11. A communication device according to any preceding claim further including an operating system compatibility chip to determine compatibility between the requirements of the data converter and the requirements of a data converter to which voice is being transmitted based on the types of operating systems of the mobile communication devices.