Method and apparatus for providing configurable functionality in an electronic device

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Patent Application Serial No. 60/257,200, filed Dec. 19, 2000, which is incorporated herein by reference in its entirety.

BACKGROUND

[0002] I. Field of the Invention

[0003] The present invention pertains generally to the field of microprocessor-based electronics, and more specifically to providing a method and apparatus for providing configurable functionality in such an electronic device.

[0004] II. Description of the Related Art

[0005] Wireless communications have become commonplace in much of the world today. In many digital wireless communication systems, audio information, typically voice, is transmitted between wireless communication devices and other end units via infrastructure equipment. Examples of various communication systems include code division multiple access (CDMA) systems, global system for mobile communications (GSM) systems, wideband code division multiple access (WCDMA) systems, as well as others.

[0006] Wireless communication devices used in such communication systems comprise many electronic circuits, organized into “functional blocks”, for performing various functions necessary to the type of communications desired. Wireless communication devices are generally designed with a single type of functional block for each function to be performed. For example, in a wireless digital telephone, audio information is generally filtered and amplified, then converted into a digital signal using one of a possible number of functional blocks. The digital signal may then be provided to a vocoder, which is a well known device in the art for compressing digitized speech for efficient wireless transmission. The vocoder generates discreet packets of information, known as vocoder frames, and are then generally provided to a modulator. The vocoder circuitry, or functional block, is one of a number of different possible vocoder types that is designed into the wireless communication device by engineers who designed the wireless device.

[0007] Modulated data is then provided to an RF transmitter where the modulated data is upconverted and amplified prior to transmission. Various types of vocoders are widely known, for example, fixed or variable vocoders are readily available.

[0008] Of course, other wireless communication devices are designed specially for other tasks.

[0009] For example, another wireless communication device is a cellular telephone that communicates in an encrypted, or “secure”, mode. In such a device, another functional block for providing encrypted communications is pre-selected by engineers and designed into the wireless communication device.

[0010] One problem with any of the above-described communication devices is that once the functional blocks for providing the desired functionality are chosen and incorporated into the wireless communication device, the overall functionality for the desired application is set and cannot be changed. For example, in an application where it is desired to send and receive secure voice communications using a variable-rate vocoder having a top encoding rate of 14 kbps, it is not possible to communicate using a vocoder having a top encoding rate of, say, 9 kbps, even if other communication devices are able to communicate using the 9 kbps encoding rate.

SUMMARY

[0011] The present invention is directed to a method and apparatus for providing configurable functionality in a wireless communication device. In one embodiment, a wireless communication device comprises a memory for storing a plurality of software modules, each of said plurality of software modules for providing a specific functionality for the wireless communication device. The wireless communication device also comprises a host processor for receiving a command to set up a communication, the command comprising information relating to the type of communication desired, and for selecting at least one of the plurality of software modules based on the type of communication desired, and further for loading at least one of the selected software modules into a digital signal processor. The digital signal processor stores the selected software modules and executes them as needed to provide the desired communication type.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The features, advantages, and objects of the present invention will become more apparent from the detailed description as set forth below, when taken in conjunction with the drawings in which like referenced characters identify correspondingly throughout, and wherein:

[0013]FIG. 1 illustrates a functional block diagram of a communication device employing the teachings of a method and apparatus for providing configurable functionality in a communication device;

[0014]FIG. 2 illustrates a flow diagram illustrating one embodiment of the method for providing configurable functionality to a communication device; and

[0015]FIG. 3 is a diagram illustrating the various messages which are transmitted between a first communication device and a second communication device during negotiation during a call setup.

DETAILED DESCRIPTION

[0016]FIG. 1 illustrates a functional block diagram of a communication device (CD) <b>100</b>. As described herein, communication device <b>100</b> comprises a wireless telephone, although it should be understood that CD <b>100</b> could alternatively comprise one of any number of possible electronic devices, such as a wireline telephone, or a wireless or wireline data modem, among others. It should also be understood that CD <b>100</b> could comprise any electronic device, not just communication device, in which a digital signal processor (DSP) is used. Many function blocks of CD <b>100</b> have been omitted for clarity.

[0017] In one embodiment, CD <b>100</b> comprises a memory <b>102</b>, a host processor <b>104</b>, and a digital signal processor (DSP) <b>106</b>. Memory <b>102</b> comprises an electronic digital memory for storing executable computer instructions, or software modules, for configuring CD <b>100</b> for multiple communication types. Memory <b>102</b> comprises a random access memory (RAM), a read-only memory (ROM), flash memory, electrically-erasable programmable read-only memory (EEPROM), ultra-violet programmable read-only memory (UVPROM), or any other electronic memory known in the art. Memory <b>102</b> could alternatively comprise an electromechanical storage device such as a hard drive, a tape drive, a CD rom, or others.

[0018] Memory <b>102</b> stores various software modules for performing functions relating to the operation of CD <b>100</b>. As shown in FIG. 1, memory <b>102</b> comprises a first DSP interface module <b>108</b>, a second DSP interface module <b>110</b>, an audio front-end module <b>112</b>, a first vocoder module <b>114</b>, a second vocoder module <b>116</b>, a first encryption cipher <b>118</b>, a second encryption cipher <b>120</b>, a third encryption cipher <b>122</b>, a first multi-media module <b>124</b>, and a second multi-media module <b>126</b>. Each of these modules comprise executable computer instructions which can be run by DSP <b>106</b>. It should be understood that a greater or a fewer number of software modules can be stored in memory <b>102</b> in other embodiments.

[0019] DSP <b>106</b> is a well-known digital signal processor for performing specialized tasks. The essential difference between a DSP and a microprocessor is that a DSP processor has features designed to support high-performance, repetitive, numerically intensive tasks. In contrast, general-purpose processors or micro controllers (GPPs/MCUs for short) are either not specialized for a specific kind of applications (in the case of general-purpose processors), or they are designed for control-oriented applications (in the case of micro controllers). Features that accelerate performance in DSP applications include:

[0020] Single-cycle multiply-accumulate capability; high-performance DSPs often have two multipliers that enable two multiply-accumulate operations per instruction cycle; some DSP have four or more multipliers

[0021] Specialized addressing modes, for example, pre- and post-modification of address pointers, circular addressing, and bit-reversed addressing

[0022] Most DSPs provide various configurations of on-chip memory and peripherals tailored for DSP applications. DSPs generally feature multiple-access memory architectures that enable DSPs to complete several accesses to memory in a single instruction cycle

[0023] Specialized execution control. Usually, DSP processors provide a loop instruction that allows tight loops to be repeated without spending any instruction cycles for updating and testing the loop counter or for jumping back to the top of the loop

[0024] DSP processors are known for their irregular instruction sets, which generally allow several operations to be encoded in a single instruction. For example, a processor that uses 32-bit instructions may encode two additions, two multiplications, and four 16-bit data moves into a single instruction. In general, DSP processor instruction sets allow a data move to be performed in parallel with an arithmetic operation. GPPs/MCUs, in contrast, usually specify a single operation per instruction.

[0025] DSPs are commercially available from Texas Instruments, for example the TMS320C2000, TMS320C5000, and TMS320C6000 series of chips; Motorola (the DSP56300, DSP56800, and MSC8100 (StarCore) series); Agere Systems (formerly Lucent Technologies) (the DSP16000 series); and Analog Devices (the ADSP-2100 and ADSP-21000 (“SHARC”) series).

[0026] Host processor <b>104</b> comprises generally any one of a number of microprocessors known in the art, such as any of the 80×86 processors manufactured by Intel Corporation. Alternatively, host processor <b>104</b> comprises an ARM <b>7</b> or an ARM <b>9</b>, manufactured by Advanced RISC Machines, LTD. Host processor <b>104</b> controls the overall functionality of CD <b>100</b>, including the control of DSP <b>106</b> and memory <b>102</b>. For example, in an embodiment where CD <b>100</b> comprises a wireless telephone, a user of CD <b>100</b> may initiate a wireless communication, for example, a “secure” voice communication with a second CD. The desire to initiate a secure voice communication may be explicitly entered by the user, for instance by depressing a predefined key on a keypad, or it may be a default configuration of CD <b>100</b>. In another embodiment, the user may select a number of options relating to the type of communication desired. For example, the user may choose to initiate a voice communication, an asynchronous voice-over-data communication, a synchronous voice-over-data communication, a synchronous or asynchronous data communication, or other types of communications well known to those in the art. The user may also have other choices available to him or her as well, to customize the type of communication desired. For example, the user may choose which kind of vocoder to use during the communication, or which type of encryption/decryption cipher to use during a secure communication. The user may choose to initiate a multi-media communication in which one of several possible choices of media playback, encryption/decryption are possible.

[0027] In another embodiment, the user may not have explicit control over which features are used during a communication. In this embodiment, the decision on which software module in memory <b>102</b> to use is decided by host processor <b>104</b>, either unilaterally, or during a negotiation period upon call setup with another CD. For example, in a unilateral arrangement, the user may have only a limited amount of control over the configuration of a desired communication. For example, the user may only be able to enter a desired communication mode, that is, either voice or data mode. When this command is received by host processor <b>104</b>, host processor <b>104</b> determines which software modules should be used for the desired communication type. This may be based on a number of factors, including whether CD <b>100</b> is within range of a wireless service provider capable of providing the desired communication type.

[0028] Host processor <b>104</b> may, alternatively, decide which software modules to use during a call setup with another CD. During many wireless communications, information is exchanged between CDs prior to actual voice or data being transmitted during this time. Therefore, in the present example, if a user of CD <b>100</b> initiates a secure voice communication with a second CD, CD <b>100</b> will contact the second CD and negotiate an exchange of cryptographic keys or agree upon which cipher algorithm to use during the communication. It may be the case that memory <b>102</b> inside CD <b>100</b> comprises three cipher algorithms, A, B, and C and that the second CD comprises cipher algorithms C and D. Therefore, the only cipher algorithm that is common to both CDs is cipher algorithm C, and CD <b>100</b> would then select cipher algorithm C and load it into DSP <b>106</b> for use during the subsequent secure voice communication. Of course, other software modules could be negotiated as well, such as which vocoder to use during the communication. Again, once an agreed-upon vocoder is chosen, CD <b>100</b> selects and loads the chosen vocoder into DSP <b>106</b> for use during the communication.

[0029] DSP <b>106</b> comprises one or more electronic memories for receiving the selected software modules from host processor <b>104</b>. Once stored in memory, the selected software modules are used to process information for transmission. For instance, voice information from a user is converted into vocoder frames using the selected vocoder software module. If encrypted communications are desired, the vocoder frames might be encoded by an encryption software module. The encrypted data would then be passed to a modulator and RF circuitry for wireless transmission to the second CD.

[0030]FIG. 1 shows a number of software modules stored in memory <b>102</b>. It should be understood that the software modules shown in FIG. 1 are for illustrative purposes only and, as such, a greater or fewer number and types of software modules could be present in other embodiments. Each of the software modules are designed and configured with generic Application Program Interfaces (API's) such that any module may be combined with another module and executed properly once selected and loaded into DSP <b>106</b>.

[0031] DSP interface module <b>108</b> and DSP interface module <b>110</b> comprise executable computer instructions detailing how data is passed between, for example, host processor and DSP processor <b>106</b>. For example, DSP interface module <b>108</b> may define a time interval for fetching vocoder frames from DSP <b>106</b> while DSP interface module <b>110</b> may define a series of interrupts which determine how data flows between DSP <b>106</b> and host processor <b>104</b>.

[0032] Audio front-end module <b>112</b> might define the characteristics of certain filter and amplifier characteristics for “front-end” circuitry generally used to pre-process audio signals. It may also include various characteristics for controlling an analog-to-digital conversion process, such as the number of bits of resolution or speed at which a sample-and-hold process is carried out. Since only one such audio front-end module is shown in FIG. 1, it will be used every time there is a need by host processor <b>104</b> to use an audio front-end software module. Of course, a second audio front-end software module could be entered into CD <b>100</b> and stored in memory <b>102</b>, using any number of conventional techniques well known in the art. In that case, host processor <b>104</b> would have to decide which of the two audio front-end software modules to use if the desired communication type necessitated the use of such a module. This would be done either unilaterally, or by some other method, as described earlier with respect to encryption software modules.

[0033] Vocoder module <b>114</b> and vocoder module <b>116</b> comprise executable computer instructions detailing how digitized audio information is encoded to minimize over-the-air transmissions.

[0034] Vocoders are well-known in the art for “compressing” human speech for more efficient wireless transmission. Vocoders may encode information at a fixed rate, or variable-rate vocoders may be used. Operational variations may exist between different fixed-rate vocoders and also between variable-rate vocoders. For example, vocoder module <b>114</b> may allow DSP <b>106</b> to encode information at 13 kbps at the highest data rate, while vocoder module <b>116</b> might allow DSP <b>106</b> to encode information at only 9.4 kbps at the highest data rate. Of course, other differences between vocoder modules could exist. Host processor <b>104</b> selects which of the available vocoders are used during a desired voice communication generally either unilaterally, or by negotiating with a second CD.

[0035] Encryption modules <b>118</b>, <b>120</b>, and <b>122</b> comprise executable computer instructions detailing how information is encrypted during secure communications. For example, encryption module <b>118</b> might comprise instructions to implement single DES (Data Encryption Standard), encryption module <b>120</b> might comprise instructions to implement triple DES, and encryption module <b>122</b> might be comprise instructions to implement RSA (Rivest, Shamir, and Adleman). Again, host processor selects one of the available encryption modules either by instructions from the user, unilaterally (for instance, always use DES, otherwise do not initiate secure communications), or by negotiation. Of course, each encryption module may also comprise instructions on how to decrypt information received by CD <b>100</b>, or such instructions may be stored in memory <b>102</b> as individual modules.

[0036] Multi-media module <b>124</b> and <b>126</b> comprise executable computer instructions detailing how information is encoded and/or decoded with respect to audio and video compression schemes. Video information may be encoded using any number of compression schemes, such as MPEG, AVI, MPEG-2, and many others. Audio information may be encoded using any number of audio compression schemes, such as MP3, WAV, and others. If host processor <b>104</b> determines that a communication (or simply the storage or retrieval of audio and/or video information) is desired by the user of CD <b>100</b>, host processor <b>104</b> selects one of the available multi-media modules and loads it into DSP <b>106</b>. When media is received by host processor <b>104</b>, it is provided to DSP <b>106</b> where the chosen multi-media module operates on it to either encode or decode the media, depending on the desired application

[0037]FIG. 2 illustrates a flow diagram illustrating one embodiment of the method for providing configurable functionality to a communication device. In step <b>200</b>, a user of CD <b>100</b> enters a command indicating a desire to initiate a communication. This is typically done by the user depressing one or more pre-designated keys on a keypad on CD <b>100</b>.

[0038] In step <b>202</b>, the command is received by host processor <b>104</b>. The command comprises at least an indication of the type of communications desired, for example, voice communications, secure voice communications, asynchronous data communications, synchronous data communications, secure asynchronous data communications, secure synchronous data communications, voice-over-data communications, secure voice-over data communications, and others.

[0039] In step <b>204</b>, host processor <b>204</b> determines whether or not at least one type of all software modules needed to perform the desired communication exist in memory <b>102</b>. If one of the needed modules are missing, processing continues to step <b>206</b> where the process is terminated. An indication of such termination is generally conveyed to the user, generally in the form of an audible, visual, or tactile alert. In another embodiment, host processor <b>104</b> initiates an action to obtain the necessary software module(s), generally be initiating an over-the-air request for the needed module(s). The wireless request and subsequent receipt of data in a wireless communication system is well known in the art and will not be discussed herein.

[0040] If at least one type of each software module needed to perform the desired communication is present in memory <b>102</b>, processing continues to step <b>208</b> where host processor <b>104</b> selects the software modules for the desired communication. As explained previously, if more than one software module exists for a particular function, host processor <b>104</b> selects one type of software module to use either unilaterally or by negotiating with a second CD, as explained above and as explained with respect to FIG. 3, below. In another embodiment, the user may also provide instructions to host processor <b>104</b> as to a preferred software module to be used.

[0041] Once host processor <b>104</b> has selected each software module for use in the desired communication, they are loaded into a memory contained within DSP <b>106</b>, as shown in step <b>210</b>.

[0042] In step <b>212</b>, the software modules are executed by DSP <b>106</b> under the command of host processor <b>104</b>, thereby providing the desired communication to the user.

[0043]FIG. 3 is a diagram illustrating the various messages which are transmitted between a first CD (CD<b>1</b> in FIG. 3) and a second CD (CD<b>2</b> in FIG. 3) as software modules are negotiated during a call setup. CD<b>1</b> comprises the following software modules in its memory <b>102</b>: vocoder module <b>1</b>, vocoder module <b>2</b>, encryption module <b>2</b>, encryption module <b>3</b>, multi-media module <b>1</b>, and multi-media module <b>3</b>. CD<b>2</b> comprises the following software modules in its memory <b>102</b>: vocoder module <b>2</b>, encryption module <b>3</b>, and multi-media module <b>2</b>. It is assumed that only modules having the same functionality can be used with each other, for example, vocoder module <b>1</b> can only be used to communicate with another CD having a similar vocoder module <b>1</b> functionality.

[0044] The first step in initiating a communication from CD<b>1</b> to CD<b>2</b> (after a desired communication type has been selected by a user of CD<b>1</b>) is for CD<b>1</b> to send a “hello” message to CD<b>2</b>. The hello message is generally a message used to initiate a communication with another CD. The hello message may be transmitted directly to CD<b>2</b> or it may be processed by in intermediary hardware, such as a cellular base station, Public Switched Telephone Network (PSTN), etc. In any case, the hello message simply alerts CD<b>2</b> to the fact that CD<b>1</b> wishes to initiate a communication.

[0045] In response to the hello message <b>300</b>, CD<b>2</b> transmits an acknowledgment (ACK) message <b>302</b>, indicating to CD<b>1</b> that CD<b>2</b> has received the hello message and is ready to continue setting up the communication.

[0046] When the ACK <b>302</b> is received by CD<b>1</b>, a message <b>304</b> is transmitted to CD<b>2</b> indicating the type of communications desired by CD<b>1</b>. The message <b>304</b> may explicitly indicate which communication type is desired (i.e., voice, secure voice, multi-media, data, etc), or the message <b>304</b> may simply comprise a list of one or more software module names which are desired for the communication to take place.

[0047] CD<b>2</b> receives message <b>304</b> and in response transmits an acknowledgement (ACK) and capabilities message <b>306</b>, in one embodiment. The ACK and capabilities message indicates to CD<b>1</b> that CD<b>2</b> received the message <b>304</b> and also provides a list of software modules available for use by CD<b>2</b>. The list of available modules may include all software modules stored in CD<b>2</b>'s memory <b>102</b>, or it may comprise a list of only those software modules pertinent to the type of communications requested by CD<b>1</b>. In another embodiment, CD<b>2</b> does not use a series of software modules to configure itself for various communication types. In other words, CD<b>1</b> may comprise a voice-only cellular telephone having a single vocoder to support such voice communications. In this case, CD<b>2</b> would indicate the type of vocoder used in the ACK and capabilities message <b>306</b>. CD<b>1</b> would then be able to determine if communications are possible with CD<b>2</b> based on the identification of the type of vocoder used in CD<b>1</b>.

[0048] CD<b>1</b> receives the ACK and capabilities message <b>306</b> and determines which software modules to select for providing the requested communication type. In this example, if encrypted voice communications were requested, the host processor <b>104</b> within CD<b>1</b> determines that CD<b>2</b> is capable of running vocoder module <b>2</b> and encryption module <b>3</b> (or, for example, that CD<b>2</b> comprises a single vocoder of a particular type which matches the functionality of one of the vocoder modules stored in memory <b>102</b>). Since these two modules are the only ones that CD<b>2</b> is capable of performing, the host processor <b>104</b> inside CD<b>1</b> selects vocoder module <b>2</b> and encryption module <b>3</b> and loads those modules into DSP <b>106</b> to support the secure voice communication. Had CD<b>2</b> not contained a matching vocoder module or encryption module to the modules stored within CD<b>1</b>, then host processor <b>104</b> inside CD<b>1</b> could not complete the communication, and the user of CD<b>1</b> would have been alerted accordingly.

[0049] After CD<b>1</b> has selected the software module(s) to support the communication, an application definition message <b>308</b> is transmitted to CD<b>2</b>, indicating which software modules to use during the subsequent communication. CD<b>2</b> then uses the identified software modules during the subsequent communication. If CD<b>2</b> does not comprise the capability for adaptive configuration like CD<b>1</b>, but is able to nonetheless operate in accordance with the software module(s) as specified in the application definition message <b>308</b>, then CD<b>2</b> is able to continue with the communication setup.

[0050] When CD<b>2</b> is ready to begin communications, it sends an acknowledgement message <b>310</b> to CD<b>1</b> indicating that the application definition message <b>308</b> was received and that CD<b>2</b> is ready for communicating using the software module(s) or equivalent functionality as indicated by CD<b>1</b>.

[0051] In response to the acknowledgement message <b>310</b>, CD<b>1</b> may, in one embodiment, transmit a start or sync message <b>312</b> to CD<b>2</b> as an indication that the communication is starting.

[0052] Such a start or sync message <b>312</b> may be used to synchronize one or more counters, variables, or other parameters between CD<b>1</b> and CD<b>2</b>.

[0053] The previous description of the preferred embodiments is provided to enable any person skilled in the art to make and use the present invention. The various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without the use of the inventive faculty.

[0054] Thus, the present invention is not intended to be limited to the embodiments discussed herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.