MXPA06005406A - Integrated cellular/pcs-pots communication system - Google Patents

Integrated cellular/pcs-pots communication system

Info

Publication number
MXPA06005406A
MXPA06005406A MXPA/A/2006/005406A MXPA06005406A MXPA06005406A MX PA06005406 A MXPA06005406 A MX PA06005406A MX PA06005406 A MXPA06005406 A MX PA06005406A MX PA06005406 A MXPA06005406 A MX PA06005406A
Authority
MX
Mexico
Prior art keywords
cell phone
pots
telephone
bluetooth
audio input
Prior art date
Application number
MXPA/A/2006/005406A
Other languages
Spanish (es)
Inventor
Mohan Chandra
Majumdar Jayanta
Original Assignee
Majumdar Jayanta
Mohan Chandra
Thomson Licensing Sa
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
Application filed by Majumdar Jayanta, Mohan Chandra, Thomson Licensing Sa filed Critical Majumdar Jayanta
Publication of MXPA06005406A publication Critical patent/MXPA06005406A/en

Links

Abstract

There is provided a system for integrating at least one residential Plain Old Telephone System (POTS) phone to a cellular phone network. A Subscriber Line Interface Circuit (SLIC 120) interfaces audio from the cellular phone network to the at least one residential POTS phone. A line switcher (122), connected to the SLIC, connects the at least one residential POTS phone to any one of a POTS line or a cellular line. An audio gateway (116), connected to the SLIC, wirelessly receives the audio from a cellular phone connected to the cellular phone network for subsequent transmission to the at least one residential phone and wirelessly transmits the audio from the POTS line to the cellular phone.

Description

CELLULAR COMMUNICATION SYSTEM / INTEGRATED PCS-POTS FIELD OF THE INVENTION The present invention generally relates to wired and wireless communications and, more particularly, to an integrated communication system of the Cellular / Personal Communication System - Old Flat Telephone Service (PCS-POTS).
BACKGROUND OF THE INVENTION Currently, there is no consistent way to join the Cellular / Personal Communications System (PCS) system with the landline of the Old Flat Telephone Service (PCS-POTS) in a residential setting. Due to this insufficiency the residential user has to overcome at least three inconveniences: (1) a cellular call / PCS can not be received at home or in other landline phones, which means that you have to resort to the cell phone to answer the Call or move around the house with a cell phone / PCS on your body (which means you can not charge your cell phone); (2) Most cellular carriers offer unlimited weekend minutes and a large number of minutes of "anytime" calls that are not available for use by anyone in the house, unless the particular cell phone is used in any case to make the call; (3) Houses that have both POTS as well as cell phones / PCS have to pay two bills, (a) one for the cellular carrier and (b) another for the use of POTS. Accordingly, it would be desirable and highly advantageous to have an integrated cellular / PCS-POTS communication system that overcomes at least the deficiencies identified above.
COMPENDIUM OF THE INVENTION The aforementioned problems as well as other related problems of the prior art are solved by the present invention, which is desired for a communication system of integrated cellular / personal communication system - old flat telephone service (PCS-POTS). Accordingly to one aspect of the present invention, there is provided a system for integrating at least one Old Flat Telephone System (POTS) telephone for a cellular telephone network. A Subscriber Line Interface Circuit (SLIC) interferes with cell phone network audio for at least one residential POTS telephone. A line switch, connected to the SLIC, is connected to at least one residential POTS telephone for any one POTS line in a cell line. An audio input, connected to the SLIC, wirelessly receives audio from a cell phone connected to the cell phone network for subsequent transmission to at least one residential telephone and wirelessly transmits the audio from the POTS line to the cell phone. These and other aspects, features and advantages of the present invention will become apparent from the following detailed description of preferred embodiments, which are read in connection with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a diagram illustrating an integrated communication system 100 employing a BLUETOOTH (BT) allowed Audio Input, in accordance with an illustrative embodiment of the present invention. Figure 2 is a diagram illustrating a more generic implementation of another integrated communication system 200, in accordance with an illustrative embodiment of the present invention; Figure 3 is a diagram using an individual connection 305, a piconet 310, and a scatternet 315 to which the present invention can be applied, according to an illustrative embodiment of the present invention; Figure 4 is a diagram illustrating a frame structure of BLUETOOTH 400 to which the present invention can be applied, according to an illustrative embodiment of the present invention; Figure 5 is a diagram illustrating multiple slot packets 500, according to an illustrative embodiment of the present invention; Figure 6 is a diagram illustrating physical link types 600, according to the illustrative embodiment of the present invention; Figure 7 is a diagram of various packet types, according to an illustrative embodiment of the present invention; Figure 8 is a diagram illustrating voice packets, according to an illustrative embodiment of the present invention; Figure 9 is a diagram illustrating a data rate calculation 900 for packets of DM1 and DH1, according to an illustrative embodiment of the present invention; Figure 10 is a diagram illustrating a data rate calculation 1000 for packets of DM3 and DH3, according to an illustrative embodiment of the present invention; Figure 11 is a diagram illustrating a data rate calculation 1100 for packets of DM5 and DH5, according to an illustrative embodiment of the present invention; Figure 12 is a diagram illustrating data packet types 1200, according to an illustrative embodiment of the present invention; Figure 13 is a diagram illustrating the package structure of BLUETHOOT 1300 for which the present invention can be applied, according to an illustrative embodiment of the present invention; Figure 14 is a diagram further illustrating the access code field 1316, the header field 1318, and the payload field 1320 of Figure 13, in accordance with an illustrative embodiment of the present invention; Figure 15 is a diagram illustrating types of access code 1500, according to an illustrative embodiment of the present invention; Figure 16 is a diagram that further illustrates various fields of the BLUETOOTH packet structure 1300 of Figure 13, in accordance with an illustrative embodiment of the present invention; Figure 17 is a diagram that further illustrates the packet header field 1318 of the packet structure of BLUETOOTH 1300 of Figure 13, in accordance with an illustrative embodiment of the present invention; Figure 18 is a diagram illustrating characteristics of packet type 1800, according to an illustrative embodiment of the present invention; Figure 19 is a diagram illustrating the BLUETOOTH protocol group 1900 according to an illustrative embodiment of the present invention; Figure 20 is a diagram illustrating the package structure of BLUETOOTH 2000 for which the present invention can be applied, according to an illustrative embodiment of the present invention; Figure 21 is a diagram illustrating the discovery process that relates to the discovery of the BLUETOOTH device through another device, in accordance with an illustrative embodiment of the present invention; Figure 22 is a diagram illustrating the audio position in the BLUETOOTH group 1950 of Figure 19, according to an illustrative embodiment of the present invention; Figure 23 is a diagram illustrating the payload body of the Protocol Data Unit (PDU) of the Link Management Protocol (LMP), according to an illustrative embodiment of the present invention; Figure 24 is a diagram illustrating the structure of a Protocol Data Unit (PDU) of the Service Discovery Protocol (SDP) 2400, in accordance with an illustrative embodiment of the present invention; Figure 25 is a diagram illustrating several steps for configuring a Service Discovery Protocol (SDP) session, in accordance with an illustrative embodiment of the present invention; Figure 26 in a diagram illustrating BLUETOOTH 2600 profiles to which the present invention can be applied, according to an illustrative embodiment of the present invention; Figure 27 is a diagram illustrating the sending of Quality of Service (QoS) messages 2700, according to an illustrative embodiment of the present invention; Figure 28 is a diagram illustrating an integrated communication system based on BUETOOTH according to an illustrative embodiment of the present invention; Figure 29 is a diagram illustrating internal connections corresponding to an analog audio interface in a NOKIA 51xx / 61xx 2900 cell phone, according to the prior art; Figure 30 is a diagram illustrating modified NOKIA 3000 hearing aids for an answer / end call configuration, according to an illustrative embodiment of the present invention; Figure 31 is a diagram that in summary form illustrates methods used to connect between the three modem operating modes of construction 3100 in a telephone (T68i) of the Cellular / Personal Communication (PCS) of SONY ERICSSON, according to an illustrative embodiment of the present invention; Figure 32 is a diagram illustrating the profile structure of BLUETOOTH 3200 and corresponding to profile dependencies; Figure 33 is a diagram illustrating a group of hands-free protocols to which the present invention can be applied, according to an illustrative embodiment of the present invention; Figure 34 is a diagram illustrating features 3400 supported on Audio Input 116 and features 3450 supported on Hands-Free (HF) units, in accordance with an illustrative embodiment of the present invention.; Figure 35 is a diagram illustrating the service level connection initiation 3500, according to an illustrative embodiment of the present invention; Figure 36 is a diagram illustrating a service level connection release, according to an illustrative embodiment of the present invention; Figure 37 is a diagram illustrating a transfer of registration status, according to an illustrative embodiment of the present invention; Figure 38 is a diagram that. illustrates an audio connection configuration, according to an illustrative embodiment of the present invention; Figure 39 is a diagram illustrating a method for answering an incoming call, according to an illustrative embodiment of the present invention; Figure 40 is a diagram illustrating a method for terminating a calling process of the Audio Input 116 according to an illustrative embodiment of the present invention; Figure 41 is a diagram illustrating a method for placing a call with a telephone number provided by an Audio Input 116 according to an illustrative embodiment of the present invention; Figure 42 is a diagram illustrating a method for performing Call Line Identification (CLI) notification, in accordance with an illustrative embodiment of the present invention; Figure 43 is a diagram illustrating an illustrative network integration solution addressed to a Cellular / Personal Communications System (PCS) telephone and an Old Flat Telephone Service (POTS) telephone in accordance with an illustrative embodiment of the present invention; Figure 44 is a diagram illustrating another illustrative network integration solution addressed to a Cellular / Personal Communications System (PCS) telephone and an Old-Phone Telephone Service (POTS) telephone, in accordance with another illustrative embodiment of the present invention; Figure 45 is a diagram illustrating even another illustrative network integration solution addressed to a Cellular / Personal Communications System (PCS) telephone and an Old-Phone Telephone Service (POTS) telephone according to even another illustrative embodiment of the present invention; Figure 46 is a diagram illustrating even another illustrative network integration solution addressed to a Cellular / Personal Communications System (PCS) telephone and an Old Plain Telephone Service (POTS) telephone in accordance with an illustrative embodiment of the present invention.
DETAILED DESCRIPTION OF THE INVENTION The present invention is directed to an integrated cellular / personal communication system - communication system of Old Flat Telephone Service (PCS-POTS).
It should be understood that the present invention can be implemented in various forms of hardware, software, firmware, special-purpose processors, or a combination thereof. Preferably, the present invention is implemented as a combination of hardware and software. In addition, the software is preferably implemented as an application program tangibly represented in a program storage device. The application program may be loaded for, executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (CPU), a random access memory (RAM), input / output interface (s) (I / O). The computer platform also includes an operating system and micro instruction code. The various processes and functions described herein may be part of the micro instruction code or part of the application program (or combination thereof) that is executed through the operating system. In addition, various other peripheral devices may be connected to the computer platform such as an additional data storage device and a printing device. It should further be understood that, because some components of the constituent system and method steps are illustrated in the accompanying figures are preferably implemented in software, the actual connections between the system components (or the process steps) may differ depending on the way in which the present invention is programmed. Given the techniques shown herein as one skilled in the art will be able to contemplate these implementations and the like or configurations of the present invention. Advantageously, the present invention provides the ability to integrate existing residential cord or wireless products into the cellular infrastructure (Telephone Access Point), regardless of cellular standards (including, but not limited to, Global System for Mobile Communications (GSM)). , general package radio service (GPRS), enhanced data for evolution GSM (EDGE), universal mobile telecommunications system (UMTS), international mobile telephony 2000 (IMT2000), multiple access code division (CDMA), telephone service advanced narrow-band mobile (NAMPS), broadband code division multiple access (WCDMA), time division code division multiple access (TDCDMA), advanced mobile phone system (AMPS)). In addition, the present invention advantageously provides connectivity for a residential network of POTS line telephones with cell phones / PCS through the use of wired / wireless connections, either through a Data terminal in the micro cell phone / PCS or through fixed wireless data connectivity solutions including, but not limited to, 802.11 / 802.15 / Infrared Data Association (lRDA) / BLUETOOTH / Ultra Wide Broadband (UWB) on cell phones / PCS. The present invention can provide such connectivity using solutions via cables and / or wireless. The present may provide such connectivity using solutions using cables that employ any of the known standards including, but not limited to, the Universal Serial Conductor, (USB) /802.11 in the cable / Recommended Standard - 232 (RS-232) / RS-485 / telephone line network alliance (PNA) / proprietary protocols, etc., with the capability of analog voice delivery types, g, 711 (a / mu Pulse Rate Modulation (PCM) / adaptive delta / modulation of differential pulse code (ADPCM) or voice in Internet protocol (VolP) The present invention can provide such connectivity using wireless connections including, but not limited to, BLUETOOTH / 802.11 / UWB / 802.15 / near field communication / IrDA (optical). Communication and control can be implemented through a Wireless Delta Communication system set in the cell phone / PCS or through the connection of external wireless sounds to the cellular phone / PCS data port that are patronizing to any owner or establishment which uses, for example, the aforementioned standards, with the capacity of analog voice delivery types g.711 (law a / mu PCM) / ADPCM or VolP. Both cable and wireless solutions can be employed using, for example, AT 'command mode (Data Circuit - Termination Equipment - Data Circuit - Termination Equipment (DCE-DCE)) or (terminal equipment mode). data - data circuit - terminating equipment) to access the cellular / PCS data port. In addition, the present invention advantageously provides a Subscriber Line interface circuit to interfere with cell phone / PCS data and audio to residential telephones, either linked directly to the TAP (Telephone Access Point) or at various locations in the place through means by wires / wireless, devices, and so on. The type of signals and the POTS line can vary between traditional analog audio to g.711 (law a / mu PCM) / ADPCM or type of VolP. Also, the present invention advantageously provides the capability of home cord / cordless telephones to make / receive calls, receive caller ID information from a cellular call / PCS, have a third party conversation, call support, and indication of Call duration and many other features offered by the micro cell phone / PCS through the TAP. Additionally, the present invention advantageously provides the ability to distribute data from the cellular / PCS network, in the form of Instant Message (IM), MM, and email to any of the residential telephones / terminals. In addition, the present invention advantageously allows downloading. new controllers (for new cellular / PCS models) and system software updates at the Telephone Access Point (TAP), either directly from the Internet through a dial-up modem or through a USB / RS-232 port in The Telephone Access Point connected to a Personal Computer (PC) or a data storage device. In addition, the present invention advantageously facilitates the synchronization and exchange of address books, ringing sounds and other items between the cellular phone / PCS and Personal Digital Assistants (PDAs) through the Telephone Access Point, without the need for a PC Figure 1 is a diagram illustrating an integrated communication system 100 employing a BLUETOOTH (BT) enabled Audio Input, according to an illustrative embodiment of the present invention. The BLUETOOTH is used as the replacement technology through cables to connect the cell phone / PCS. The integrated communication system 100 includes BLUETOOTH wireless microphones 102, a BLUETOOTH allowed cell phone of Base Station 104, a wireless data and audio connection telephone 106, a Synchronous Dynamic Random Access Memory (SDRAM) / flash memory 108, a USB interface 110, an RS_232 + analog audio interface 112, a BLUETOOTH of Wireless Base Station 114, an Audio Input BLUETOOTH 116, a screen and keyboard 118, a Subscriber Line Interface Circuit (SLIC) 120, a POTS Line Switch and Dual Tone Frequency Decoder (DTMF), (collectively or individually represented by reference number 122), and a housing controller (also referred to herein as "Host Control Processor" (HCP)) 124. Figure 2 is a diagram illustrating a more generic implementation of another integrated communication system 200, according to an illustrative embodiment of the present invention. The integrated communication system 200 includes wireless microphones 202, a Wireless Fidelity (WiFi) / BLUETOOTH / infrared (IR) enabled cell phone 204, an audio via cables and data with cell phone / PCS 206, an SDRAM / instant memory 108, a USB / Ethernet 110 interface, an RS_232 + analog audio interface 212, a (BLUETOOTH) Wireless Base Station 214 , an Audio Input (BLUETOOTH / WiFi / lR) 216, a screen and keyboard 218, a Subscriber Line Interface Circuit (SLIC) 220, a POTS line switch and DTMF 222 encoder, and a driver 224. The BLUETOOTH has become the de facto global standard for short-range wireless data communications that allow devices to communicate with others using secure radio waves, and is the basis for the Institute of Electrical and Electronics standard ( IEEE) 802.15.1. The BLUETOOTH was originally conceived as a basic cable replacement technology, although it is inevitable that new applications and usage patterns will get involved with the technology as they become more penetrating. The BLUETOOTH operates in the industry, scientific, and medical (ISM) 2.4 GHz band that is not licensed and available for use anywhere. Since the frequency band is already full, the BLUETOOTH has been designed to be robust enough to operate in noisy environments. The BLUETOOTH is designed to be used in mobile devices, where the size, cost, and life of batteries are key factors. It normally operates with a range of 10 meters, although higher energy versions are available generating a range of up to 100 meters. Since it is a radio link, the BLUETOOTH is not limited to line of sight and can pass through walls. It uses frequency hopping to change its frequency 1600 times per second in a pseudo-random pattern, making it more difficult to spy, and employs 128-bit enclosure in the link layer for added security. One of the most important features of the BLUETOOTH specification is that it must allow devices from several different manufacturers to work with one another. For that reason BLUETOOTH does not define a radio system, but also a group of software that allows applications to find other BLUETOOTH devices in the area, discover what services they can offer, and use the services. The BLUETOOTH allows up to 8 devices to be connected together in a group called a piconet. Different piconets can be linked in scatternets, but the data rate between scatternets will be less than the speed within an individual piconet. The BLUETOOTH devices operate at 2.4 GHz, in the globally available, license-free band of ISM. That is the bandwidth reserved for general use by the world of industrial, scientific and medical applications. Since this radio band is free to be used by any radio transmitter while satisfying the regulations, the intensity and origin of interference can not be predicted. Therefore, interference immunity is a very important issue for BLUETOOTH. Generally, interference immunity can be obtained by its pressure or interface evasion. Suppression can be obtained by coding or expanding the direct sequence, but the dynamic range of the interference signals in appropriate networks can be enormous, so that the coding practically sustained and the processing gains are usually inadequate. Frequency evasion is more practical. Since the 2.4 GHz ISM band provides approximately 83 MHz of bandwidth and all radio systems are limited bands, there is a high probability that a part of the spectrum can be found with strong interference.
Considering all this, we have chosen a frequency expectation technique - Code Division Multiple Access (FH-CDMA) to implement the multiple access scheme for BLUETOOTH. The FH-CDMA technique combines a number of properties, that make it the best option for a suitable radio system. The FH-CDMA technique meets the expansion requirements established in the ISM band, that is, an average of the signal can be extended over a large frequency range, but instantaneously only a small part of the bandwidth is occupied, avoiding the most potential interference. Additionally, the BUETOOTH does not require rigorous time synchronization schemes (such as Time Division Multiple Access (TDMA)), or Coordinated Transmission power control schemes as in the Direct Sequence Code Division Multiple Access, for normal operation. In the ISM band of 2.45 GHz, a group of jump conveyors 79 has been defined, in the 1 MHz spacing. A nominal jump residence time of 625 us is used in the system and each residence time happens in a different frequency. If multiple slots are used to transmit data, then the frequency remains unchanged during the multiple slot data transmission period. Complete double communication is achieved by applying Time Double Division (TDD) techniques, and since transmission and reception take place in different time slots, they can also take place in different hoppers.
A large number of optimal pseudo-random jump sequences have been identified and the BLUETOOTH unit which is commonly connected to several BLUETOOTH peripheral devices determines the choice of a specific pseudo-random jump sequence used in a piconet. The unit to which the peripheral BLUETOOTH units commonly connect is usually called the master and also defines the time parameters during the communication session. Other devices involved in the session, the slaves have to adjust their expansion sequences and synchronize to the master. The BLUETOOTH uses a Gaussian-shaped Frequency Shift Keying modulation (GFSK) with a nominal modulation index of k = 0.3. The binary modulation was chosen for its robust form and, with the accepted bandwidth restriction, it can provide incomplete data rates up to 1 Mbps. Non-coherent demodulation can be performed with a limiting Frequency Modulation (FM) discriminator. This simple modulation scheme allows the implementation of low cost radio units, which is one of the main purposes of the BLUETOOTH system. A BLUETOOTH Frequency Hopping (FH) channel is associated with the piconet. As mentioned above, the master unit defines the piconet channel by providing the jump sequence and the jump phase. All the other units participating in the piconet are slaves. However, since the BLUETOOTH is based on peer-to-peer communications, the slave / master role is only attributed to one unit for the duration of the communication session in a piconet. When the communication session is complete, the master and slave roles are also canceled. In addition to defining the piconet, the master also controls piconet traffic and takes care of access control. The time slots are alternatively used for master and slave transmission. In order to prevent collisions in the channel due to multiple slave transmissions, the master applies a voting technique, for each slave to master transmission slot and decides which slave is allowed to transmit in that slot. If the teacher has no information to send, he even has to vote for the slave explicitly with a short voting package. This master control effectively prevents collisions between participants in the piconet, but independent placed piconets can interfere with one when they occasionally use the same jump conveyor. This can happen because the units do not check a clean transporter (not heard before speaking). If the collision does not occur, the data is retransmitted to the next transmission opportunity. Due to the short residence time, the collision evasion schemes are less suitable for the FH system. The topology used in BLUETOOTH technology is called net scattered. This is basically made up of an architecture of cells called a piconet. A piconet is a group of BLUETOOTH devices that share a common channel. Four modes of operation are identified to make: Master, Slave, Pause, or Stationed or Support. The master operation mode can control up to 7 simultaneous links and 200 active slaves. The slave mode of the operation can participate in one or more piconets. The Operation Pause mode is the default state on BLUETOOTH devices. The Pause and Parked modes are low energy states. Basically a piconet is a star-shaped connection where the center of one is the master and the other devices are slaves. Figure 3 is a diagram illustrating an individual connection 305, a piconet 310, and a scatternet 315 to which the present invention can be applied, according to an illustrative embodiment of the present invention. In this way, in a piconet, a master device can serve up to 7 slave devices. If more than 7 devices have been connected then the slave devices have to be tuned to the low power parking mode. After tuning them to the parked mode, other devices (that are going to be connected) have to be invited to become active. The master also controls the fiow of data transmission. A Scatternet is a group of piconets that are interconnected with one another. These are connected to each other through bridge nodes. The function of the bridge node is to remain in each piconet for some time and, in that way, it can rotate through the attached piconets. In this way, it is able to receive and transmit data for each piconet to other piconets. The Physical channel is created through 79 jump channels defined by the pseudo-random sequence. The physical channel is divided into time slots where each slot corresponds to an RF jump frequency. The nominal jump frequency is 1600 jumps / s. Figure 4 is a diagram illustrating a BLUETOOTH frame structure 400 to which the present invention can be applied, according to an illustrative embodiment of the present invention. In that way, each time slot is 625 microseconds in length. In the TDD scheme shown in Figure 3, the Slave and Master can be transmitted simultaneously while the transmissions happen at different frequencies. The frequency of RF Jump must remain fixed for the duration of the packet. Two types of physical links can be established between masters and slaves, a Synchronous Connection Oriented (SCO) link and a Less Synchronous Connection (ACL) link. The SCO link is the point-to-point link between the master and slave in the piconet. This helps to receive a time slot in both directions at regular intervals. That way, this link is able to transmit voice, which is a limited time information. The master device can support up to 3 SCO links to the same or different slaves. SCO packets are sent through the master device at regular intervals. The directed slave device responds with an SCO packet. The SCO link is established through the master when sending a SCO configuration message that includes the required time parameters. An ACL link provides connected packet connection between the master and all active slaves participating in the piconet. This takes care of the protection of data payload through the Cyclic Redundancy Review (CRC). That also makes good use of piconet channels. The slave is not allowed to transmit ACL packets only if they have been routed in the master to pre-slave slot, otherwise the slave is not allowed to transmit. Figure 5 is a diagram illustrating multiple slot packets 500, according to an illustrative embodiment of the present invention. Figure 6 is a diagram illustrating physical link types 600, according to an illustrative embodiment of the present invention. A description will now be provided of various SCO and ACL connection scenarios according to an illustrative embodiment of the present invention. If a BLUETOOTH device has an ACL, but no SCO, the device can request any type of HVx package, but once the SCO is requested, all future SCO connections, if possible based on resources, should be same kind.
Figure 7 is a diagram of several packets 700, according to an illustrative embodiment of the present invention. The various types of packets 700 include control packets 710 and data / voice packets 720. According to a first illustrative connection scenario, the BLUETOOTH device wishes to establish an SCO using HV1. If so, then no more SCO links can be established because all the slots are used for this and only the SCO / HV1 link link. According to a second illustrative connection scenario the BLUETOOTH device wishes to establish an SCO using HV2. If so, then only one more SCO link can be established and it can only be another SCO using HV2 due to slot distributions. According to a third connection scenario, the BLUETOOTH device wants to establish an SCO that uses HV3. If so, then if one or two more SCO links are going to be established, then they should be SCO links that use HV3. If an SCO connection is already made then: (a) if the SCO link used HV1, then unless the first SCO link is modified use either HV2 or HV3, the additional SCO link is refused due to the obligations of resource; (b) if the original SCO link used HV2, then this additional SCO link must use HV2 OR if the original link is modified to use HV3, then the original SOC link must be configured using also HV3; and (c) if the original SCO link used HV3, then this SCO link must use HV3; (d) if the two original SCO links use HV2, then the SCO request must be refused, unless the two previous SCO links are modified to first use HV3 first, then the third SCO link must be established using HV3; and (e) if the two SCO links use HV3, then the additional SCO request must use HV3. Figure 8 is a diagram illustrating voice packets 800, according to an illustrative embodiment of the present invention. Such voice packets 800 may include, for example, voice packets HV1, HV2, and HV3. In addition such voice packets 800 may include an access code field 1316, a header field 1318, and a payload field 1320. • HV1 packets transmit every 1.25 usegs, with a payload of 80 (10x8) bits . The performance speed in this mode is calculated as follows: Bits / slot x slots / seconds = 80x (1600/2) 64 Kbps. HV2 packets transmit every 2.5 uses, with a payload of 160 (20X8) bits. The performance speed in this mode is calculated as follows: Bits / slot x slots / seconds = 160 x (1600/4) = 64 Kbps. HV3 packets transmit every 3.75 usegs, with a payload of 240 (30x8) bits . The speed of performance in this mode is calculated as follows: Bits / slot x slots / seconds = 240x (1600/6) = 64 Kbps. A description will now be provided for the case when a slave has two different masters. In this case the SCO links of the slave for each of the masters must be an SCO that uses HV3. If not, there is no way for the slave to jump back and forth between two piconets. It should be noted that in one of the previous cases describing a modification of the link can occur without interrupting the SCO link data. Diagram 9 is a diagram using data rate calculations 900 for packets of DM1 and DH1, according to an illustrative embodiment of the present invention. The DM1 packets transmit every 1.25 usegs, with a payload of (17x8) 136 bits. The speed of performance in this mode is calculated as follows: Bits / slot x slots / seconds = 136 x (1600/2) = 108.8 Kbps. DH1 packets transmit every 1.25 usecs, with a payload of (27x8) 216 bits. The performance speed in this mode is calculated as follows: Bits / slot x slots / seconds = 216 x (1600/2) = 172.8 Kbps. Figure 10 is a diagram illustrating the 1000 data rate calculation for DM3 packages and DH3, according to an illustrative embodiment of the present invention. The DH3 packets transmit every 1,875 usegs, with a payload of (183X8) 1464 bits. The speed of performance in this mode is calculated as follows: Bits / slot x slots / seconds = 1464 x (1600/4 = 585.6 Kbps.
The DM3 packets transmit every 1,875 usegs, with a payload of (121 x 8) 968 bits. The performance speed in this mode is calculated as follows: Bits / slot x slots / seconds = 968 x (1600/4) = 387.2 Kbps. Figure 11 is a diagram illustrating a data rate calculation 1100 for DM5 packets and DH5, according to an illustrative embodiment of the present invention. The DH5 packets transmit every 3.125 usegs, with a payload of (339x8) 2712 bits. The speed of performance in this mode is calculated as follows: Bits / slot x slots / seconds = 2712 x (1600/6) = 723.2 Kbps. DM5 packets transmit every 3.125 usegs, with a payload of (224x8) 1792 bits . The performance speed in this mode is calculated as follows: Bits / slot x slots / seconds = 1792 x (1600/6) = 477.8 Kbps. Figure 12 is a diagram illustrating data packet types 1200, according to a illustrative embodiment of the present invention. The DV package is a special package transferred over the SCO link. It contains an 80-bit voice field and a data field of up to 150 bits. Up to 10 bytes of data can be sent in a DV packet. The data and a 16-bit Cyclic Redundancy Code (CRC) together are encoded using the Error Correction Forward (FEC) 2/3. The DV packet format provides some limited applications in time in effective means to transfer data through the circuit connected data path. There are 4 types of control packages used: ID, NULL, POLL and FHS. They are common for both SCO and ACL links. They are used for synchronization, voting and other channel control functions. Figure 13 is a diagram illustrating the package structure of BLUETOOTH 1300 for which the present invention can be applied, according to an illustrative embodiment of the present invention. BLUETOOTH packet structure 1300 includes a field of AM_ADDR (3 bits) 1302, a field of type (4 bits) 1304, a field of flow (1 bit) 1306, a field of ARQB (1 bit) 1308, a field of SEQN (1 bit) 1310, a Header Error Correction field (HEC) (8 bits) 1312, a + FEC field (36 bits) 1314, an access code field (72 bits) 1316, a field of header (58 bits) 1318, a payload field (0-2745 bits) 1320, a preamble field 1322, a synchronization word field (64 bits) 1324, a test field (4 bits) 1326. Of that way, each package has 72 bits access code, 54-bit header and a payload of variable size. Compared with 802.11b, a packet of BLUETOOTH is much smaller, providing an advantage of a lower probability of error. Figure 14 is a diagram that further illustrates the access code field 1316, the header field 1318 and the payload field 1320 of Figure 13, in accordance with an illustrative embodiment of the present invention. The access code is the same for all packets transmitted in a piconet. It includes a 4-bit preamble, a 64-bit synchronization word and possibly a 4-bit test. The receiver of a BLUETOOTH unit used an auxiliary correlator to correlate against the synchronization word to determine the time. Depending on the state of the piconet, the synchronization word is generated in different ways. The preamble and the test are used for DC compensation. Figure 15 is a diagram that further illustrates the access code field 1316, according to an illustrative embodiment of the present invention. The access code field 1316 may include several types of access codes. Access code types 1500 include, but are not limited to, Channel Access Code (CAC), Device Access Code (DAC), and Inquiry Access Code (IAC). A unit can find if the package is targeted or simply observe the 1318 header, go back to sleep for the rest of the slot if it is not for it. That design will reduce energy consumption even in active mode. Figure 16 is a diagram that further illustrates various fields of the BLUETOOTH packet structure 1300 of Figure 13, in accordance with an illustrative embodiment of the present invention. The package header has six fields. The field of AM_ADDR 1302 is the address of the active member that the teacher used to distinguish them. The TYPE 1304 field includes information such as, for example, how long the packet will last, the error correction scheme it uses and the type of packet, for example you can use it to vote with the slave or only the synchronization. The FLOW 1306 bit is used to flow control in the ACL link. The ARQN 1308 field is used for ARQ. The SEQN 1310 bit is used to differentiate retransmitted packets from new ones. The field of HEC 1312 is in an 8-bit header error check. For other protection, the full header that includes the HEC 1312 field is coded for 1/3 54-bit speed FEC to achieve more robust quality. The payload 1320 is variable in size, depending on the type of packets. The SCO link only has a fixed-length voice field (with the exception of the DV packet, which has both voice and data fields). Figure 17 is a diagram that further illustrates packet header field 1318 of the packet structure of BLUETOOTH 1300 of Figure 13, in accordance with an illustrative embodiment of the present invention. In the ACL link, the data field itself includes a payload header, a payload body and possibly a payload CRC code. The payload header includes the following 3 fields: 2 - BIT L_CH, used to identify logical channels. 1 - bit FLOW to control the flow. - bit LENGTH (8 bits for multiple slot packets) to indicate the variable payload size. Figure 18 is a diagram illustrating packet type characteristics 1800 in accordance with an illustrative embodiment of the present invention. However, ACL packets that are not addressed to a specific slave are considered transmission packets and are read through any slave device. A Brief Discussion will now be provided regarding the channel capacity and link efficiency, according to an illustrative embodiment of the present invention. The BLUETOOTH is implemented in a bandwidth of 83.5 MHz. In the Frequency Hopping Extension Spectrum, a Multiple Division Code Access form is used to multiply. There is a lower guard band of 2.0 MHz and a guard band higher than 3.5 MHz. Among these guard bands there are 79 RF channels spaced at 1.0 MHz. The nominal bandwidth is therefore BW = 1.0 MHz. The distance operative for a BLUETOOTH link with an antenna power of O dBm, is 10m. The product of band-distance amplitude is: BWD = 10.0 MHz m. The operating distance for a BLUETOOTH link with 20 dBm antenna power is 100m. The product of band-distance amplitude is: BVWD = 100.0 MHz m. The signal is modulated using a Gaussian Frequency Shift Key with two symbols, therefore M = 2. Through the Nyquist theorem, the theoretical channel capacity, C, is defined as follows: C = 2W log2 (M) where C is the channel capacity and W is the bandwidth. When substituting the real values, we obtain the following: C = 2 * 1.0 MHz log2 (2) = 2.0 Mbps The transmission speed mentioned for BLUETOOTH is 1.0 Mbps. The minimum energy requirement in the receiver is -70dBm. Now the Shannon-Hartley theorems refer to the channel capacity for the SNR. C = W log2 (1 + S / N) substitutes 1.0 Mbps for C and 1.0 MHz for W. This implies that a noise energy Np of -70 dBm (10 - 10 watts) is the maximum noise level tolerated. BLUETOOTH implements a media access scheme Time Division Doubles in order to provide a full double connection. For example, the following are considered: (a) Three SCO links at 64 kbps = 192 kbs, Double connections Full 192 kbs * = 384 kbps use HVE packages. Any FEC in the payload. Header of 54 bits of total frame size + 240 bits of payload = 294 bits. The superiors 54bits / 294 bits = 18.37% and the net yield is 81.63% or 313.5 kbps. (b) Two SCO links at 64 kbps = 128 kbs Full Double connections at 128 kbs * 2 = 256 kbps using HV2 and 2/3 FEC packets on payload packets. Header of 134 bits / 294 bits = 45.58%. Overall frame size plus payload of 54.42% or 139.3 kbps. (c) An SCO link at 64 kbps Full Double connection at 64 kbs * 2 = 128 kbps using HV1 packets with 1/3 FEC in the payload packets. The 54-bit header of total frame size + 240 bits payload = 294 bits. The higher 214 bits / 294 bits = 72.79%. The actual performance is 27.21% or 34.8 kbps. (d) An SCO link at 64 kbps Full Double connections at 64 kbps * 2 = 128 kbps uses HV3 packets. There is no FEC in payload packages. Header of 54 bits of total frame size +240 bits payload = 294 bits. The higher 54 bits / 294 bits = 18.37%. Actual performance is 81.63% or 104.5 kbps. In addition, the symmetric ACL link 433.9 bkps * 2 = 867.8 kbps. For maximum actual performance, use DH5 packet without FEC in payload packets: 54-bit header of total frame size plus 16-bit payload header + CRC + 2728 data bits = 2814 bits. The upper one is 86 bits / 2814 bits = 3%. The actual performance is 97% or 841.3 kbps. The total performance is calculated as kbps + 841.3 kbs = 945.8 kbps (forward link + return link).
The BLUETOOTH protocol group is defined as a series of layers, through which there are some characteristics that cross several layers. A BLUETOOTH device can be made of two parts: a housing that implements the upper layers of the protocol group, and a module that implements the lower layers. This preparation of the layers can be useful for several reasons. For example, accommodations such as PCs have room to reserve capacity to control higher layers, allowing the BLUETOOTH device to have less memory and a lower power processor, which leads to a cost reduction. Also the accommodation device can sleep and can be awakened through a BLUETOOTH connection that enters. Of course, an ipterfase is necessary between the upper and lower layers, and for that purpose the BLUETOOTH defines the Host Controller Interface (HCl). However, for some small and simple systems, it is possible to have all the layers of the protocol group running in the processor. An example of such a system that use headphones in hands-free mode. Figure 19 is a diagram illustrating the BLUETOOTH protocol group 1900, according to an illustrative embodiment of the present invention. The BLUETOOTH 1900 protocol group includes an application layer 1902, a TCS 1904 layer, an OBEX 1906 layer, a WAP 1908 layer, a SDP 1910 layer, a Radio Frequency Communication (FRCOMM) 1912 layer, a logical link control and application layer 1914, a host controller interface 1916, a link manager 1918, a baseband / link controller 1920 and a radio layer 1922. Upper layers 1950 in a 1951 housing include upper layers 1952, an audio layer 1954, a layer of L2CAP 1956, a control layer 1958, a 1960 HCl controller, and a 1962 physical driver driver. The lower layers 1970 in a BLUETOOTH 1971 module include a common physical conductor driver 1972, a common HCl 1974 driver, a layer of link manager 1976, a link controller layer 1978, and a radio layer 1980. The 1999 HCl packets are exchanged between the upper layers 1950 and the lower layers 1970. With respect to the baseband layer 1920, there are two basic types of physical links that can be established between a master and a scale: Synchronous Oriented Connection (SCO); Y Less Asynchronous Connection (ACL). An SCO link provides a symmetric link between the master and the slave, with a regular periodic exchange of data in the form of reserved slots. In this way, the SCO link provides a connected circuit connection where the data is regularly exchanged, and as such it is intended to be used with information limited by time as audio. A master can support up to three SCO links for the same or different slaves. A slave can support up to three SCO links from the same master. An ACI link is a multiple point-to-point link between the master and all the slaves in the piconet. You can use all the remaining slots in the channel not used for SCO links. The ACL link provides a packet-connected connection where data is sporadically exchanged, while making it available for higher layers. The traffic in the ACL link is completely programmed by the teacher. Each BLUETOOTH device a 48-bit IEEE address (Excess Media Control (MAC) used for the derivation of the access code.) The access code has pseudo random properties and includes the identity of the piconet master All the exchanged packets in the channel are identified by this master entity This prevents packets from being sent in a piconet to be falsely accepted through devices in another piconet that happens to use the same hop frequency in a certain time slot.All packets have the same format, starting with a code of access followed by a packet header and a header with the user load useful Figure 20 is a diagram using the packet format of BLUETOOTH 2000 for which the present invention can be applied, according to an illustrative embodiment of the present invention The packet format 2000 may include an access code field 1316, a header field 1318, and a payload field 1320 The payload included in the payload field 1320 may include voice 2010 or data 2020. The access code included in the access field 1316 is used to direct the packet to a specific device. The header field 1318 includes all the control information associated with the packet and the link. The payload field 1320 includes the actual message information. BLUETOOTH packages can be 1.3, or 5 slots long, but multiple slit packs are always sent on an individual hopper transporter. The link control layer 1920 is responsible for managing the discovery capability of the device to establish connections and maintain them. In the BLUETOOTH three elements have been defined to support the establishment of connection: revision, page and inquiry. The inquiry is a process in which a device tries to discover all the devices enabled by BLUETOOTH in this local area. A unit that wants to make a connection transmits an inquiry message that induces the receivers to return their addresses. The units that receive the inquiry message return the Frequency Leap Synchronization (FHS) packet that includes, among other things, their identity and synchronization information. The identity of the receiver is required to determine the page message and wake-up sequence. For the return of the FHS packages, a random recovery mechanism is used to prevent collisions.
Figure 21 is a diagram illustrating the discovery process that relates to the discovery of a BLUETOOTH device through another device, in accordance with an illustrative embodiment of the present invention. In the illustrative embodiment of Figure 21 the two devices include a laptop 2110 and a mobile phone 2120. Inquiries are sent from the portable computer 2110 to the mobile telephone 2120 and then an FHS packet from the mobile telephone 2120 is sent to the computer Portable 2110. An idle mode unit wants to sleep most of the time to save power, but, from time to time, it has to listen if other units want to contact it (page review). In a truly adequate system, there is no common control channel that a unit can close in order to listen to page messages. Thus, each time the unit wakes up, it checks a different jump conveyor for an extended time. An agreement has been made between the energy consumption of the inactive mode and the response time: increases the sleep time reduces the energy consumption but prolongs the time before an access can be made. The unit you want to contact has to resolve the frequency-time uncertainty: that unit does not know when an inactive unit wakes up and at what frequency. For this reason, the collating unit transmits the access code repeatedly at different frequencies: every 1.25 ms the paging unit transmits two access codes and listens twice for a response. In a period of 10 ms, 16 different hoppers are visited. If the inactive unit wakes up on any of these 16 frequencies, the inactive will receive the access code and will start with a connection setup procedure. First, the inactive will notify the collating unit upon returning a message, and then the inactive one will transmit an FHS packet containing all the collator information. This information is then used by both units to establish the piconet. Once a baseband link is established, the master and slave can exchange roles if they wish, so that the slave becomes the master and the master becomes the slave. It should be noted that the link control rests completely with the local device. If the local device does not make itself discoverable through the page review then the local device can not find it. If the local device is not made itself connectable through the page review, then the local device can not be linked to it, and once a local device connection is free to disconnect without warning at any time. Audio data is transported through SCO channels (Oriented Synchronized Connection). These SCO channels use pre-stored slots to maintain the temporal consistency of the audio transported in them. This allows us to build devices such as wireless headsets, microphones and portable phones using BLUETOOTH for many consumer products such as cell phones, call center switch boards, or even personal music players. There are two routes for the audio to pass through a BLUETOOTH system: through the HCl as the data in HCl package, and through direct PCM connection to the baseband CODECs. Figure 22 is a diagram illustrating the audio position in the BLUETOOTH group 1950 of Figure 19, according to an illustrative embodiment of the present invention. The HCl route has some deficiencies when transporting audio data, that is, packets that cross the HCL are subject to flow control and therefore to variable latency due to the microcontroller that executes the tasks of HCl and LM (Link Manager) . The direct PCM route is not well specified in the BLUETOOTH specifications, but it is very common in commercial implementations. With respect to link manager 1918, the host directs a BLUETOOTH device through the Hosting Controller Interface (HCl) commands, but it is the link manager 1918 that translates those commands into operations at the baseband level . Its main functions are to control the piconet administration (establishment and destruction of links and change of paper), link configuration, and security and QoS functions. The 1918 link manager communicates with its peers on other devices using the Link Management Protocol (LMP) 1976. Each LMP message begins with a flag bit that is zero if a master initiated the transaction and one if the slave initiated the transaction. The bit is followed by a 7-bit Operation Code, and through the message parameters. Figure 23 is a diagram illustrating the payload body of the Link Management Protocol (LMP) Protocol Data Unit (PDU) 2300, in accordance with an illustrative embodiment of the present invention. The payload body of LMP PDU 2300 includes a TID field 2310, an OpCode field 2320, and parameter fields 1 through N 2330. Where a link is first established, it uses predetermined individual slot packets. Multiple slot packages make band use more effective, but there are some occasions when they can not be used, for example in noisy links or if the SCO links leave enough space between their slots for multiple slot packets. The 1976 LMP also provides a mechanism to negotiate lock-in modes and coordinate lock-in keys used by the devices at both ends of the link. In addition, the 1976 LMP supports messages for the configuration of the quality of service in a connection. The packet types can automatically change according to the quality of the channel, so that the data can be transferred at a higher speed when the channel quality is good, at a lower speed when there is more error protection if the quality of the channel deteriorates. The Logical Link Control and Adaptation Protocol (L2CAP) 1914 takes data from upper layers 1952 of the BLUETOOTH group and from applications and sends them to the lower layers of the group. L2CAP 1914 passes packets to either the 1974 HCl, or in a less host system directly to the Link Manager 1976. One of the major functions of the L2CAP 1914 is to multiply between different higher layer protocols to allow several higher layer links to share a connection of individual ACL. The L2CAP uses channel numbers to label packets so that, when they are received, they can be routed to a correct place. Another of the major functions of the L2CAP 1914 is the segmentation and reassembly that allows the transfer of larger packages than those that support the lower layers. All applications must use L2CAP 1914 to send data. L2CAP 1914 was also used through the upper layers of BUETOOTH such as RFCOMM 1912 and SDP 1910 and, thus, L2CAP 1914 can be considered a mandatory part of any BLUETOOTH system. The RFCOMM 1912 is a reliable simple transport protocol that provides emulation of the serial cable line configurations and status of an RS-232 serial port. The RFCOMM 1912 provides connections to multiple devices by relying on L2CAP 1914 to control the multiplication of the individual connection. The RFCOMM s 1912 supports two types of devices as follows: Type 1 - internal emulated serial port. These devices are usually the end of a communication path, for example a PC or printer. Type 2 - Intermediate device with physical serial port. These are devices that are set in the middle of a communication path, for example. a modem Up to 30 data channels can be established, so that FRCOMM 1912 can theoretically support 30 different services at once. RFCOMM 1912 is based on the GSM TS 07.10 standard, which is an asymmetric protocol used by GSM cell phones to multiply several data streams in a physical serial cable. The Service Discovery Protocol (SDP) 1910 is one of the most important members of the BLUETOOTH 1900 protocol group. The SDP 1910 provides a means for an SDP client to access information about the services offered by SDP servers. An SDP server is any BLUETOOTH device that offers services to other BLUETOOTH devices. The information about the services is maintained in the SDP database, there is no centralized database, so that each SDP server maintains its own database. The SDP database is simply a group of records that describe all the services that a BLUETOOTH device can offer to another BLUETOOTH device, and the service discovery protocol provides a means for another device to observe these records. To be easier to find the service you want, the services are arranged in a hierarchical structure as a tree in which you can navigate. Clients begin to examine the root of the tree, then follow the hierarchy outside of the leaf nodes where the individual services are described. To browse client classes, or obtain information about a specific service, SDP clients and servers exchange messages that are transported in SDP Protocol Data Units (PDUs). The first PDU byte is an ID 2410, which identifies the message in the PDU. The services have Universally Unique Identifiers (UUIDs) that describe them. The services defined by BLUETOOTH profiles have UUIDs assigned by the standard, but service providers can define their own services and assign their own UUIDs to those services. Figure 24 is a diagram illustrating the structure of a Protocol Discovery Unit (PDU) 2400 of the service discovery protocol (SDP), according to an illustrative embodiment of the present invention. The PDP 2400 SDP includes a TID 2410 PDU field, a transaction ID field 2420, a parameter length field 2430, and a parameter field 2440. The SDP relies on L2CAP links being established between the SDP client 2501 and the SDP 2502 server, before retrieving information of SDP. Figure 25 is a diagram illustrating several steps for configuring a Service Discovery Protocol (SDP) session, according to an illustrative embodiment of the present invention. The session is conducted through a local device (SDP client) 2501 and a remote device (SDP server) 2502. The steps shown in Figure 25 extensively include link controller connection configuration 2510, an administrator connection configuration link 2520, connection configuration of L2CAP 2530, session SDP 2540 and disconnection 2550. More specifically, the connection configuration 2510 includes a look-up step 2511 and a collating step 2512. The connection manager connection step 2520 includes a LMP hosting connection request 2521, an accepted LMP 2522 response, a LMP name request 2523, a LMP name response 2524, an authentication 2525, a complete LMP 2526 configuration message and another complete configuration message LMP 2527. The connection step of L2CAP 2530 includes a connection request of L2CAP 2531 and a connection response of L2CAP 2532. The session of SDP 2540 includes inquiries SDP 2541 and responses of SDP 2542. Disconnection 2550 includes a termination message 2551. With respect to Protocol Supported, as mentioned above, one of the most important characteristics of the specification of BLUETOOTH is that it must allow devices from several different manufacturers to work with one another. For that reason, the BLUETOOTH is designed in such a way to allow many different protocols to run at the tip of these. Some of these protocols are Wireless Access Protocol (WAP); Object Exchange Protocol (OBEX); and Telephony Protocol. WAP provides a protocol group similar to the Internet Protocol (IP) group, but WAP is configured for the needs of mobile devices. WAP supports the limited presentation size and resolution typically found on mobile devices by providing special formats for Web pages that match their capabilities. WAP also provides the low bandwidth of mobile devices by defining a method for WAP content to be compressed before the WAP content is transmitted over a wireless link. The WAP can use BLUETOOTH as a support layer in the same way that it can use GSM, CDMA and other wireless services. The WAP group is linked to the BLUETOOTH group that uses the User Datagram Protocol (UDP), Internet Protocol (IP) and Point-to-Point Protocol (PPP).
OBEX is a protocol designed to allow a variety of devices to exchange data simply and spontaneously. BLUETOOTH has adopted this protocol of the Infrared Data Association (IrDA) specifications. OBEX has a client / server architecture and allows a client to send data to a server or obtain data from the server. For example, a PDA can obtain a file from a laptop, or a phone that synchronizes a address book can be sent to a PDA. The similarities between the two lower layers of the communication protocols mean that the OBDA protocol of IrDA is ideally suited for transferring objects between BLUETOOTH devices. The BLUETOOTH Telephony Control Protocol (TCS) Specification defines how telephone calls should be sent over a BLUETOOTH link. The TCS provides guidelines for the signaling necessary to configure both point-to-point and point-to-point calls. When using TCS, calls from an external network can be routed to other BLUETOOTH devices. For example, a cell phone might receive a call to use TCS to redirect the call to a laptop, allowing the laptop to be used as a hands-free phone. The TCS is routed through a telephony application that provides the user interface, and provides the source of voice or data transferred through the connection configured by TCS. A description of BLUETOOTH profiles associated with certain applications will now be provided. That is, in addition to the protocols guaranteeing that two units speak the same language, the BLUETOOTH specification defines the profiles. The profiles specify which protocol elements are mandatory in certain applications. This concept prevents devices with low memory and processing power that implement the entire BLUETOOTH group when they only require a small fraction of the BLUETOOTH group. Simple devices such as hearing aids or mice in this way can be implemented with a strongly reduced protocol group. The BLUETOOTH profiles are organized in groups, with each profile being built on low inherent characteristics of the later. For developers, this means that key features of a BLUETOOTH solution can be reused in other solutions, which lower development costs and accelerate the development cycle. Figure 26 is a diagram illustrating BLUETOOTH 2600 profiles for which the present invention can be applied, in accordance with an illustrative embodiment of the present invention. The profiles implemented by BLUETOOTH are: Generic Access 2605; Port in Series 2610; Marking Network 2615; FAX 2620; Hearing Aids 2625; Local Area Network (LAN) Access Point 2630; Exchange of Generic Object 2635; File transfer 2640; Object Shipment 2645; Synchronization 2650; Wireless telephone 2655; and intercom 2660. The Generic Access 2605 defines the basic rules for using the protocol group. The Serial Port 2610 defines how to use the serial port emulation capabilities of RFCOMM in BLUETOOTH products. Dialing network 2615 defines a BLUETOOTH link for a modem. The FAX 2620 defines how to transfer a fax in BLUETOOTH. With respect to the 2625 hearing aids, a double link for a hearing aid; controlled by an audio input such as a cell phone. The LAN Access Point 2630 defines a link for LAN through BLUETOOTH. The Generic Object Exchange 2635 defines a group of rules to use OBEX, which supports file transfer, object submission and synchronization profiles. File Transfer 2640 refers to transferring files between BLUETOOTH devices. Sending object 2645 refers to sending objects from a BLUETOOTH enabled by the server to a client. Synchronization 2650 refers to synchronizing objects between BLUETOOTH devices. The 2655 wireless telephone refers to directing telephone calls to BLUETOOTH devices. The intercom 2660 refers to short-range voice connections between BLUETOOTH devices. The BLUETOOTH 2600 profiles also include a 2665 Service Discovery Application Profile. The basic security elements necessary to be considered to prevent unauthorized use and spyware in a BLUETOOTH system although they are primarily intended for short-range connectivity between personal devices. The security features are included in the link level and are based on a secret link key that is shared through a pair of devices. To generate this key, a pair procedure is used when the two devices communicate for the first time. In a connection establishment, an authentication process is carried out to verify the entities of the units involved. The authentication process uses a conventional challenge response routine. The verifier compares the indicated response (SRES) produced by the claimant with its own SRES and decides whether the challenge can continue with the connection establishment. To prevent the spy in the link, which is an inherent damage to radio communications, the payload of the packet is enclosed. The confinement is based on current figure; the payload bits are module 2 added to a binary key stream. The central element in the security process is the 128-bit link key. This link key is a secret key that resides on the BLUETOOTH hardware and is not accessible by the user. The link key is generated during an initiation phase. Once the initiation has been carried out, the 128-bit link keys reside in the devices and thereafter they can be used for automatic authentication without user interaction. In addition, the methods are available to use the same locking keys for all slaves in an individual piconet. BLUETOOTH provides a limited number of security elements at the lowest level. More advanced security procedures can be implemented in higher layers. While many BLUETOOTH devices operate through batteries, special attention has been paid to reducing energy consumption in the design. Also, many tests have been conducted to test BLUETOOTH devices that are too low in energy to have a negative impact on health. Three low energy modes, which extend the life of the battery by reducing the activity in a connection, have been defined. These modes are called Parking, Maintenance and Aspiration. The Parking mode provides the greatest opportunities to save energy. The device only wakes up in periodic guide slots when the device listens to Master's un-stationary transmissions. If you are not parked, the device returns to sleep by turning off your receiver. The devices that are parked provide their active member addresses, so that one Master can have more devices in parking mode at the same time. In Aspiration mode, the slave does not check every slot from master to slave, but it has a larger interval between revisions. Devices in suction mode maintain their active member addresses. Typically, aspiration devices will be active more frequently than parked devices. Both parking and aspiration modes involve placing devices in a state where they periodically awaken while the Maintenance mode only places a connection in a low energy state for an individual period. Thus, the first Teacher needs to perform an investigation to allow the service to connect again. In the connection state, current consumption is minimized and waste interference prevented only when transmitted when data is available. In longer periods of silence, the Master needs to send a packet in the channel once in a moment so that all the slaves can re-synchronize their clocks and compensate the game. During continuous TX / RX operations, a unit starts to verify the access code at the beginning of the RX slot. If the access code is not found, or even the access code is found but the slave addresses do not match the receiver, the unit sleeps to the next slot. The header indicates what type of package it is and how long the package will last; therefore, non-targeted recipients can determine how much they can sleep. The nominal transmit power used by most BLUETOOTH applications for short range connectivity is 0 dBm. This restricts current consumption and keeps interference to other systems to a minimum. However, the BLUETOOTH radio specifications allow TX power up to 20 dBm. The signal strength indication energy received with closed rotation of O dBm is mandatory. This energy control can be compensated for propagation losses and slow fading. In low power modes many layers of the BLUETOOTH protocol group are involved: as after periods of inactivity the device may lose synchronization and need to hear transmissions in a wider window than usual, the baseband layer alters the properties of the correlation. The link manager provides a variety of messages to configure and negotiate low power modes between ends of a connection. HCl 1960 provides a set of commands that can be used through a housing to configure and control the power saving capabilities of a module. L2CAP 1914 must be aware of the low energy modes due to their quality of service commitments. Different devices from. BLUETOOTH may have different requirements for data rate, delay variation, and reliability. The specification provides Quality of Service (QOS) configurations for the link properties according to the requirements of higher layer applications or protocols. These properties include the QOS type, signal rate, signal rate receiver size, peak bandwidth, latency, and delay variation.
Figure 27 is a diagram illustrating the sending of Quality of Service (QoS) message 2700, according to an illustrative embodiment of the present invention. That means, Figure 27 illustrates how to use a message through a BLUETOOTH protocol group to control QOS. The messages that configure and set the QOS flow vertically up and down the layers of the group, while the Link manager and the Logical Link control and the adaptation layer (L2CAP) 1914 configure QOS in pair negotiations. The link manager 1976 actually implements QOS policies to configure and control the baseband links and has several means to try to satisfy QOS requesting the L2CAP 1914. Sending QoS message 2700 includes messages that relate to QoS requirements 2705, QoS configuration succeeds or fails 2710, violations of 2715, QoS configuration 2720, link control 2725, and link information 2730. The message is exchanged between, for example, the upper layer and application 1952 protocols, L2CAP 1914, HCl 1974 and Link Manager 1976. When a link is first established, the QoS is requested from the upper layer 1952 for L2CAP 1914. Then the 2799 negotiation packets for QOS configuration are sent between local L14CAP 1914 and remote. The link manager 1976 provides QOS capabilities in accordance with the L2CAP 1914 requests. In systems with a 1974 HCl, this interaction between L2CAP 1914 and the link manager 1976 is performed through a series of HCl commands and events. The LMP 2798 commands can be used to configure the voting interval, the maximum interval between packets sent from master to slave, and the transmission packet repetition times. The termination of the QOS configuration is generated when the LMP has been configured. If the LMP configuration has failed, then the message will be sent back to the uppermost layer to decide whether to try again or if it stops. If the LMP configuration has been successful, then the channel will open to transfer data to the desired QOS. Even a channel has been configured, it is important that the applications are aware if their QOS is not as requested, while they may wish to close the link rather than running it at an inappropriate quality, or close other links to improve this link. In such a case, the lower layers are sent QOS violation events to tell the upper layers and allow them to decide what to do about that. Referring again to Figure 1, a description will now be provided of some of the elements of the integrated communication system based on BLUETOOTH 100 shown here. The BLUETOOTH 102 Wireless Headphones are bi-directional communication devices based on BLUETOOTH technology. These terminals have the ability to link to the wireless-based station and exchange voice and data packet. The hearing aids 102 are configured in the slave mode and the wireless base station 114 is configured in the master mode. Based on the functional requirement of the wireless headphones 102, the appropriate usage profile is loaded. For example, if a voice link is contemplated, then the wireless units 102 can be assigned as a hands-free profile or a more appropriate wireless telephone profile. The BLUETOOTH integrated circuit in the wireless base 114 can communicate with the first Host Control Processor 124 to coordinate a variety of functions as dictated by the application. The Audio Input 116 functions as the call agent for data exchange between the cell phone / PCS and the integrated communication system 100 and uses a BLUETOOTH device configured in a slave mode with hands-free profile. The input functionality does the following things but is not limited to the items listed below. For a cellular call in progress, audio input 116 makes an ongoing call on cell phone 104, including: sending a command on a BLUETOOTH Audio Input 116 for cell phone 104 to "dial" the number and initiate the call (the call is routed through the Cellular Network rather than through the landline network); the BLUETOOTH voice channel configuration between the cellular telephone 104 and the wireless micro telephone 102.
For a cell phone call in progress, the audio input 116 hangs the micro cell phone / PCS including: send notification of call hanger to the cell phone. For a cellular call in progress, audio input 116 employs SMS / MMS / dialing modem, including: the ability to upload / download digital images; the ability to access the Internet; the ability to send instant messages / multimedia messages; adjust the audio level (volume); the ability to use Voice Recognition to dial and control functions on the cell phone / PCS; and the ability to put the call in Maintenance. For an incoming cellular / PCS call, the audio input 116 detects the incoming call and displays the CLIP information. If the user accepts / rejects the call, the cell phone is informed. To hang the micro cell phone / PCS, the audio input 116 sends notification to hang up the cell phone call; has the ability to put a call "in maintenance"; interconnect in a cell phone / PCS conference mode operation with POTS line; make cellular call / PCS re-routing through the POTS line; has the ability to upload / download digital images; has the ability to collect information and control different products and applications through the cellular network; has the ability to send instant messages / multimedia messages; adjust the audio level (volume); has the ability to put the call in maintenance; has the ability to direct a voice message left by the Cell Phone Caller to a designated person or group through a computer-based dialing or through an independent (independent modem) by sending an email to a file of Wave or MP3. With respect to the screen and keyboard 118, the function of the screen 118 is to present various program menus as well as CLIP or other information relevant to the user. Screen 118 prompts the user to pick up the correct cell phone / PCS software module for interconnectivity. It also boosts the user during software download overruns. The keyboard 118 allows the marking of the Access Point, Menu Selection, Software Download Impulses, Configurations Default, System Configuration Settings, Instant Message Send and Multimedia Send. Figure 28 is a diagram that further illustrates the Subscriber Line Interface Circuit (SLIC) 120 of Figure 1, in accordance with an illustrative embodiment of the present invention. The SLIC 120 includes a control interface 2805, a PCM interface 2810, a PLL 2815, a compression module 2820, an expansion module 2825, a DTMF decoder 2830, a gain / attenuation module 2835, a tone generator 2840 , another gain / attenuation module 2845, a Analog to Digital Converter 2850, a Digital to Analog Converter 2855, a DC-DC Converter Driver 2860, a line power control module 2865, a line status module 2870 , a first 2875 investor, a second 2880 investor, and a 2885 hybrid programming module. SLIC 120 modules and / or interfaces with, among other devices, low cost external discrete devices 2899. The SLIC 120 provides a line interface Analogue telephone complete and ideal for applications of short turn (less than 609.6 meters). The SLIC 120 integrates subscriber line interface (SLIC) circuit, encoding and decoding, and DC-to-DC converter 2860. The SLIC 120 also integrates a 5 REN tone generator into the DTMF 2830 decoder, and double tone generator, which also reduces the number of external components. The 5 REN tone generator and the dual tone generator are included in the tone generator 2840. The DC-to-DC converter driver in the 2860 micro-insert allows the SLIC 120 to dynamically generate line voltages from a power supply. 9V to 30V DC, eliminating the need for large negative voltage supply and energy saving. The SLIC 120 is programmable to meet global telephone standards, which allow individual designs to be implemented throughout the world for a variety of applications including cable telephony, wireless local turn, PBX, voice over IP, and ISDN terminal adapters. The SLIC 120 takes digital signals from PCM and produces an analog voltage in the POTS line and also takes an analog signal from the PCM line and converts it into a digital PCM stream for direct transmission. In addition to these functions, the SLIC 120 can be programmed to send caller ID signals through the tip and tone results of the SLIC 120. In summary, the SLIC 120 begs for almost all the functions in a central office that traditionally makes for the POTS line. With respect to the POTS line switch and the DTMF 122 decoder, the POTS switch is necessary to connect the residential telephone to either the POTS line or the cellular line. This connection is important since the SLIC 120 can not be connected to the tip and tone line while a POTS line call is being made. Isolation is necessary to prevent the passage of DTMF signals on the Punta and Tono lines to the central telephone office, while a residential telephone connected to the SLIC is signaled to initiate a cellular / PCS call, the POTS line switch and the DTMF decoder 122 is normally established for connectivity to the cellular network. However, this facility is selectable by the user and defaults to a POTS line connection during a power shortage. The various connectivity options, for regular POTS phone integration is with the system, it will be detailed from here somewhere else. A separate DTMF decoder 122 is included in this block 122 for taking DTMF commands for the Guest Controller 124, of a connected POTS telephone for call control to work, while an active voice connection is on with a cellular phone / PCS.
With respect to the instant memory module / SDRAM 108, there are 4 critical functions for this module 108 as follows: 1) Software for BLUETOOTH 116 audio input; 2) Software for BLUETOOTH 114 wireless base station; 3) Software to control the SLIC 120; 4) Software for several Cell Phone Profiles. The primary form of control and connectivity with the cell phone is established through the Attention (AT) commands that are specific to the particular cell phone / PCS that is linking to the Access Point (AP). The RS-232 / Analog Audio Interface 112 allows the connection between the cell phone / PCS and the Access Point through the media via cables. The result of cell phone headsets / microphones (analog signals) is converted to a 13-bit linear PCM stream in direct transmission to a wireless system or to SLIC 120 as may be appropriate. The data port is directly wired to the RS-232 connector at the Access Point, using the cell phone vendor data cable or any other compatible commercial cable. In some cases, these cables would be terminated from USB, in which case the USB connector 110 would be used to send the AT commands. In addition to this function, the RS232 port 112 and / or the USB port 110 allow an external computer to be connected to computer-enabled telephony when using the computer telephony series.
With respect to the analog audio interface 112, FIG. 29 is a diagram illustrating internal connections corresponding to an analog audio interface in a NOKIA 51xx / 61xx 2900 cell phone, according to the prior art. The cellular phone 2900 includes a microphone 2902, a hearing aid 2904, a plurality of capacitors 2980, a plurality of resistors 2982, a common lead 2984, and a plurality of Integrated Circuits (ICs) 2986. Analog mic and audio signals can be route to SLIC 120, to interact with the POTS phone. Figure 30 is a diagram illustrating a NOKIA hearing aid 3000 for a response / termination call feature, according to an illustrative embodiment of the present invention. The hearing aid 3000 includes a microphone 2902, a hearing aid 2904, a plurality of capacitors 2906, a common lead 2910, and a switch 2999. In Figure 30, the hearing aid signal is connected through the switch 2999, which momentarily returns to the signal ground. When the 2999 switch is started, it is possible to take the cell phone from the hook on to the off hook and vice versa. However, the configuration of Figure 30 is not able to extract the Calling Line Identity Presentation (CLIP) information from the cell phone unless communication is established with the cell phone's internal modem (not shown, but included in the cell phone 104 shown in Figures 1 and 2). For example, Nokia phones use two types of communication methods for data transmission and communications with the PCs: FBUS and M2BUS. Sending ring tones and graphics to a phone depends on whether you use FBUS or M2BUS. An M2BUS has the following characteristics: it uses 5 pins; double media communication; used in Nokia 21xx phones (data communication only); used for the service and adjustment purposes; and up to 2Mbps internal data, speed data on the cable connection. An FBUS has the following features: full high-speed dual communications between the phone and PC; the Nokia Data Suite TM application vl.x and v2.x uses only the FBUS transmission method; used in Nokia 3/5/7/8/9 series phones; used for data communications on 9/6/14, 4kbps for GSM and PC network; and used for service and adjustment operations. When the FBUS or any other type of communication link is stable with the cellular modem, either through a cable connection or through BLUETOOTH, IrDA or Wi-Fi external bells, it is possible to establish connectivity to the Access Point and have the voice and data sent in the modem connection, when making use of the Offline command modes of the cellular modem. Alternatively, the modem can be used to perform data communication between the Access Point and the cell phone, while the audio is derived from analog audio and mic terminals for further processing. With respect to the Cellular / PCS Modem and AT Commands: AT commands are used to: configure the phone to connect through an infrared port or the common system driver; configure the phone to connect through a BLUETOOTH / Wi-Fi / IrDA port or the common system driver; configure the modem to connect through an infrared port or the common system driver; request information about the current configuration or operating status of the telephone or the modem; and test availability on the telephone or modem and, when applicable, request the range of valid parameters when applicable, for an AT command. The construction modem in the cell phone 104 can be set in any of the following 3 modes of operation: Off-line command mode; online data mode; and online command mode. In offline command mode, the construction modem is placed in offline command mode when it is first turned on and is ready for AT command input. The online data mode allows the "normal" operation of the construction modem that exchanges data or facsimiles with a remote modem. In online command mode, it is possible to connect the online command mode when you want to send AT commands to the construction modem while still being connected to the remote modem. Figure 31 is a diagram that summarizes the methods used to connect between the three modes of modem construction operation 3100 in a telephone (T68i) of the Cellular / Personal Communication System (PCS) of SONY ERICSSON, in accordance with a illustrative embodiment of the present invention. The three construction modem operating modes 3100 include an offline command mode 3105, an online data mode 3110, and an online command mode 3115. The three modem operating modes 3100 can be entered into the start 3199. In offline command mode 3105, the construction modem accepts data as commands and not as normal communication traffic. With respect to the connection to online data mode 3110, for data to be exchanged with the modem at the other end of the link, enter the ATD command. By the telephone number to make the call. Alternatively, writing ATA to resolve an incoming call will also place the construction modem in online data mode 3110. With respect to the backward connection to off-line command mode 3105, any of the following will return the modem from construction to mode of offline command 3105 of online data mode 3110: Loss of connection (error NOT TRANSPORTED); loss of the infrared link between the construction modem and your computer; press the "NO" button on your mobile phone; and get low DTR (not available when the cable is used). A description is now provided regarding using AT commands during a data connection, in accordance with an illustrative embodiment of the present invention. If we want to use AT commands while connected to a remote modem in online data mode 3110 and maintain connection to the remote modem, first enter the command mode in line 3105. There are two ways to interconnect from online data mode 3110 to online command mode 3115. The first way to connect from online data mode 3110 and online command mode 3115 is the type of escape sequence "+ + +" followed by an appropriate AT command. The command must be selected from the AT, ATE, ATH, ATI, ATL, ATM, ATQ, ATV and ATX options. Using this method, an AT function can be performed while moving in online command mode 3115. For example, the connection using the ATH + + + command CR > Interconnects the construction modem to online command mode 3115. The AT command is executed, causing the connection to be terminated (hung-executed). Writing the escape sequence "+ + +" without any next command will cause the system to wait a second, connect to the online command mode 3115, and respond ACCEPT; The second way to connect from online data mode 3110 to online command mode 3115 is by obtaining DTR after preconfiguring AT & D = 1. To return to online data mode 3110 while in command mode in line 3115, write: ATO < CR > To return the construction modem to off-line command mode 3105 to form in on-line command mode 3115, use any of the methods described above with respect to interconnect backward from off-line command mode 3105; and write + + + ATH < CR > to interconnect to online command mode 3115 to hang once. With respect to the operation of the AT commands, the following 4 types of commands can be issued: a command to adjust the operating parameters of the construction modem; and execute command that directs the action without the need of any of the parameters; a read command to see the current command settings; and a test compound to see the available command parameters. Not all AT commands support all four functions. The standard format for entering a group command is: AT < command > = < parameters > < CR > Where AT notifies the construction modem that a command has been entered. < command > The name of the command being entered. < parameters > The values that are going to be used through the command. < CR > All command lines are terminated by pressing the < CR > (Return or Enter). Note: All command lines are contemplated when you press the < CR > on the computer keyboard. To set the construction modem to operate with self control in an asynchronous connection, the command line would be: AT + CBST = 0,0,1 However, the commands also have default settings. These are values that are presumed to have been entered when no real value is placed on the command line. For example, the above command can be entered, such as: AT + CBST = ,, 1 The default values used by the commands are indicated by bold text in the following descriptions. When the parameter is a character row (for example "<name>"), then the value must be entered between the quotas. For example "Peter". Optional parameters are shown in brackets. For example (< value >). A description will now be provided with respect to entering an execution command. The execution commands are very similar to the group commands. They usually do not require any of the parameters that are used to obtain information about the mobile phone or construction modem or to run an event. For example, to find the information about the mobile phone battery, enter the command + CBC: AT + CBC The construction modem answers: + CBC: 0,60 Indicating, that the battery of the mobile phone is connected (0) and that The remaining charge is 60%. To answer an incoming call, execute the A: ATA command A description will now be provided with respect to the command needed to view the command configurations. To review the current settings of a command, use the "?" Option. For example, review the current settings of the + CBTS command, enter: AT + CBST? If CBST has been established according to the previous example, the configurations are presented as: + CBST: 0,0,1 A description will now be given regarding the use of the test commands for request command help. At least the availability of a command and the range of parameters, use the option of, =? ™ with the command. For example, review the parameters available for the command line in the previous example; either: AT + CBST =? The line: + CBST: (0,4,6,7,68,70,71), (0), (1) It is presented indicating the range of valid entries that can be established for the parameters < data speed > < support service > and < connection element > . Each cell / PCS has a set of AT commands that supports the phone's modem. Emphasize that different cell phones / PCS support different AT command lists. It is possible to write appropriate AT translators at the Access Point in order to establish either key or optical / wireless connectivity between the cell phone / PCS and Access Point. The Host Control Processor (HCP) 124 is the "Brain" of the access point. The HCP124 initiates the concession of communication with the rest of the connected peripherals. The Host Control Processor 124 allows the following functions. The Host Control Processor 124 obtains the correct cell phone signal profile and initiates the AT commands to communicate with the Cell Phone 104. The AT commands are first sent to the Audio Input 116, which in turn speak to the cellular data port through one of the four methods: (a) Via Cables (either cell phone vendor provided or others); (b) Fixed BLUETOOTH module; (c) External BLUETOOTH hood; (d) Infrared (IrDA).
Host Central Processor 124 coordinates the multiple cell phone / PCS 104 link for the Access Point. The Host Control Processor 124 preloads the configurations required in the SLIC 120 for proper operation in the Transmission and Reception modes. The Host Control Processor 124 receives the information from CLIP of the cellular incoming call / PCS and presents them on the local LCD screen and also formats this number so that the SLIC 120 performs the functions of caller ID and caller ID and a telephone instrument of POTS type. The Host Control Processor 124 describes local keyboard entries. The Host Control Processor 124 coordinates the audio input / command routing 116 to the wireless base unit BLUETOOTH module 114. The Host Control Processor 124 processes the DTMF signal of both the SLIC 120 and the encoder. of external DTMF 122 for translation to an appropriate AT command. The Host Control Processor 124 allows USB and RS-232 connectivity with a computer, memory device or isolated client, for new program downloads as well as enabling other services. The Host Control Processor 124 does the memory management. The Host Control Processor 124 performs the translation of AT command and any DTMF / any other digital command for call handling control with cellular / PCS and POTS line. The Host Control Processor 124 performs keyboard revision and presentation routines for menu services. The Host Control Processor 124 performs configuration control for the integrated communication system. The Host Control Processor 124 associates the CLIP number of the cell / PCS online caller with a name so that both the field can be presented in the Caller ID presentation (CID) in the regular POTS telephone (calls from cell phone only have a number but no name). The Host Control Processor 124 generates polyphonic or distinct ringing patterns in order to differentiate between: (a) a cellular call / PCS and a call POTS; and (b) between the different cell phones / PCS connected to the Access Point. The USB 110 module is used primarily to download software updates from a computer. As a newer cell phone evolves, there may be a need to update the cell phone AT command library. The downloads can be through a connection to a USB smart storage device or a computer. This connection can also be used to update cell phone ring tones, address books, CID listings and establish Internet connectivity through the cellular network. This port 110 is also important if we want to deploy Wav / MP3 based on ease of sending voice message electronic message in this system. A description of a conaction methodology between a cell phone / PCS 104 and Audio Input 116 will now be provided, according to an illustrative embodiment of the present invention. The connection between the cell phone / PCS 104 and the Audio Input 116 is established through the BLUETOOTH unit link establishment in the cell phone 104 and the Audio Input 116. Both the cell phone 104 and the Audio Input 116 are configured in the hands-free profile so that the AT commands can be passed back and forth between the Audio Input 116 and the cell phone 104, in any direction, while they have the audio stream between the two devices that goes on an SCO channel. This ensures the interruption of free audio connectivity (separate data channel). A brief description of the BLUETOOTH hands-free operation mode is described below. Figure 32 is a diagram illustrating the profile structure of BLUETOOTH 3200 and the corresponding profile dependencies. A profile is dependent on another profile if you reuse parts of that profile, by reverently revealing it. The profile includes: A generic access profile 3205, a service discovery application profile 3210, profiles based on binary TCS 3215, a 3220 wireless telephony profile, a 3225 intercom profile, a 3230 serial port profile, a 3235 dial network profile, a 3240 fax profile, a 3245 hearing aid profile, a 3250 LAN access profile, a 3255 hands-free profile, a generic object exchange profile 3260, a file transfer profile 3265, an object send profile 3270, and a sync profile 3275. As indicated in Figure 32, the hands-free profile 3255 is dependent on both the 3230 serial port profile and Generic Access Profile 3205. As another example, the 3270 object submission profile is dependent on the generic object exchange profile 3260, the 3230 serial port profile, and the generic access profile 3205, in addition, the intercom profile 3255 is dependent on both the binary TCS-based profiles 3215, and the generic access profile 3205. Figure 33 is a diagram illustrating a hands-free protocol group to which one can apply the present invention, in accordance with the illustrative embodiment of the present invention. On one side of Audio Input, a group of audio input protocol 3301 includes an application layer (audio port emulation) 3304, a hands-free control layer 3308, a layer of RFCOMM 3312, a layer of SDP 3316, a layer of LMP 3320, a layer L2CAP 3324, and a layer of base band 3328. On a hands-free side, a corresponding hands-free protocol group 3350 includes: an application layer (audio conductor) 3354 , a hands-free control layer 3308, a RFCOMM layer 3312, a SDP layer 3316, a LMP layer 3320, a L2CAP layer 3324, and a base band layer 3328. The base band layer 3328, the LMP 3320 layer, and the L2CAP 3324 layer are the Open Systems Interconnection (OSI) layer 1 and 2 BLUETOOTH protocols. The RFCOMM 3312 layer is the BLUETOOTH serial port emulation entity. The SDP layer 3316 is the Service Discovery Protocol of BLUETOOTH. The compatibility to the "BLUETOOTH System specification", core, version 1.1, February 22, 2001, incorporated herein by reference in its entirety, is deferred. Hands-free control is the entity responsible for the specific hands-free unit control signaling; this signaling is based on AT command. Although not shown in the previous model, it is pressed by the Hands-Free Control profile that has access to some lower capture procedures (for example, SCO link establishment). The audio port emulation layer 3304 shown in Figure 3 is the entity that emulates the audio port in the Audio Input 116, and the audio driver 3354 is the driver software in the hands-free unit. For the shaded protocols / entities in Figure 33, the Serial Port Profile is used as the base standard. For these protocols, all the mandatory requirements mentioned in the Serial Port Profile apply, except in those cases where this specification explicitly mentions deviations. The following roles are defined for this profile. The Audio Input (AG) 116 is the device that is the input of the audio, both input and output. According to the present invention, the Audio Input 116 activates the Access Point (AP) to integrate the cell phone / PCS 104 for the POTS line, which carries both voice and data between the Access Point, BLUETOOTH telephones. and the cell phone / PCS 104 (the cell phone 104 has the same BLUETOOTH profile as the AG116). The hands-free unit (HF) is the device that acts as a remote audio input and output mechanism for the Audio Input. The HF also provides some remote control means. In this particular embodiment of the invention, the Hands Free unit is the external BLUETOOTH Bell which allows a BLUETOOTH cellular / PCS phone to communicate with the Audio Input 116. Figure 34 is a diagram illustrating features 3400 supported in the Audio Input 116 and features 3450 supported in the hands-free unit (HF), according to an illustrative embodiment of the present invention. The characteristics supported in the Audio Input 116 are shown in the left table 3470 in Figure 34. The features supported in the Hands Free unit (HF) are shown in the right table 3480. In Figure 34, "M" indicates Compulsory compliance and "O" indicates optional compliance to the BLUETOOTH hands-free profile standards. A description will now be provided regarding user requirements and scenarios, in accordance with the illustrative embodiment of the present invention. The following rules apply to this profile: (a) The profile mentions the mandatory and optional features when the "Hands-Free Profile" is active on the Audio Input 116 and the cell phone 104. (b) The profile commands the use of CVSD or PCM for audio transmission (in the BLUETOOTH link). The resulting audio is monophonic, with a quality that, under normal circumstances, would not have a perceived audio degradation. (c) Between the cellular telephone 104 and the Audio Input 116, only one audio connection is supported at a time. This means that there are no two cell phones connected to the Audio Input 116, both of which can not simultaneously send audio to the Audio Input 116. d) Both Audio Input 116 and cell phone 104 can initiate audio connection establishment and release. Valid language data must exist in the SCO link in both directions after the audio connection is established. (e) At any time there is an "audio connection", there must also be a related "Service Level Connection". (f) The presence of "Service Level Connection" must not imply that there is an "audio connection". Releasing a "service level connection" must also release any "Audio Connection" related to it. A description relating to hands-free control interoperability requirements will now be provided, in accordance with an illustrative embodiment of the present invention. The procedures described here are mainly based on the use of a minimum set of AT commands as the control protocol. These AT commands and their result codes are described later. In addition, how the Service Level Connections are controlled in general will also be described later, including how layers are used under the equity of hands-free unit control to establish and release a Service Level Connection. A description will now be provided regarding the service level connection establishment, in accordance with the illustrative embodiment of the present invention. With a user action in an internal event, either the cell phone or the Audio Input 116 may initiate a Service Level Connection establishment procedure. A Service Level Connection establishment requires the existence of an RFCOMM connection, that is, an RFCOMM data link channel between the cellular telephone 104 and the Audio Input 116. Both the cellular telephone 104 and the Audio Input 116 can initiate the RFCOMM connection establishment. If there is no RFCOMM session between the Audio Input 116 and the cell phone 104, the initiating device must first start RFCOMM. The RFCOMM connection establishment must be performed as defined by the BLUETOOTH standards for the Generic Access Profile 3205 and the Serial Port Profile 3230. A description will now be given regarding the service level connection initiation, according to an illustrative embodiment of the present invention. Figure 35 is a diagram illustrating the service level connection initiation 3500, according to an illustrative embodiment of the present invention. When an RFCOMM connection (3501) has been established, the service level connection initiation procedure 3500 must be executed. First, in the initiation procedure, Audio Input 116 must send the feature command > Supported from AT + BRSF = < AG for the cell phone 104 (3504), both to notify the cell phone 104 of the features supported in the Audio Input 116, as well as to retrieve the features supported in the cell phone 104 that use the + BRSF result code ( 3508). An Accept message is sent from the cellular telephone 104 to the Audio Input 116 (3512). After having received the features supported on the cellular telephone 104, the Audio Input 116 must determine which indicators are supported by the cellular phone, as well as the order of the supported indicators. This is due, in accordance with the Technical Specification of GSM 07.07, version 5.0.0 July 1996, the cell phone can support additional indicators not provided by the Hands-Free Profile, and because the order of the indicators is specific to implementation. The Technical Specification of GSM 07.07 is incorporated herein by reference in its entirety. Audio Input 116 uses the test command of AT + CIND =? To retrieve information about the supported indicators and their order (3516). The cell phone 104 then sends a + CIND command: ... to Audio Input 116 (3520), as well as an Accept message (3524). Once the audio input 116 has the necessary supported indicator and the order information, the Audio Input 116 must retrieve the appropriate status of the indicators on the cell phone 104 using the AT + CIND read command (3528). The retrieval of the information through the Audio Input 116 of the cellular telephone 104 also involves the cell phone 104 that sends a + CIND command: ... to the Audio Input 116 (3532), as well as the OK message ( 3536). After having recovered the status of the indicators on the cell phone, the AG must then allow the "indicator status update" function on the cell phone when issuing the AT + CMER (3540) command, to which the cell phone will respond with a message of Accept 3544. As a result, the cell phone can send the unsolicited + CIEV result code with the corresponding indicator value at any time that a change occurs in the service, call, or configuration status of call. When an update is required both for the call and for the call configuration indicators, the cell phone will send the unsolicited + CIEV result code for the call indicators before sending the unsolicited + CIEV result code for the Call configuration indicator. Audio Input 116 should use the information provided by the + CIEV code to update its own internal and / or external indications. Once the "update indicator status" function has been enabled, the cell phone will keep the function enabled until the AT + CMER command is issued to disable it, or Service Level Connection between Audio Input 116 and the cell phone 104 goes down for any reason. After Audio Input 116 has enabled the "update indicator status" function in the cell phone, and if the "call waiting and 3 ongoing calls" bit was set in the bitmap features supported both by the cell phone 104 and the Audio Input 116, the audio input 116 must issue the test command of AT + CHLD =? To retrieve information about how the phone maintains and the multi-part services are supported on the cell phone (3548). The cell phone then sends the command + CHLD: ... 3552 to the Audio Input as well as an Accept message 3556. The Audio Input 116 should not issue the test command of AT + CHLD =? In case any cell phone 104 or Audio Input 116 does not support the "Three Way Call" feature. Audio Input 116 will consider the Service Level Connection to be fully initiated, and thus established (3580), in any of the following cases. The Audio Input 116 will consider the Service Level Connection to be fully initiated, thereby established after the Audio Input 116 which has successfully retrieved information on how to maintain the call and the multiple part services are supported on the cell phone 104 using the AT + CHLD command, if and only if the "call waiting and 3-way call" bit were set in the bitmap of supported features for both cell phone 104 and Audio Input 116. The input Audio 116 will consider the Service Level Connection to be fully initiated and thus established after the audio input 116 successfully enabled the "indicator status update" which is used by the AT + CMER command if and only if the bit of "call waiting and 3-way call" was not established in the bitmap of the supported features for any of the cell phone 104 or Audio Input 116. Cell phone 104 will consider that the Service Level Connection is fully initiated, and with this is established, in any of the following cases. Audio Input 116 will consider the Service Level Connection to be fully initiated and thereby established after the cell phone 104 successfully responded with information about call maintenance and multiple party services are supported on the cell phone using + CHLD as well as Accept answered, if the "call waiting and three-way call" bit was set in the bitmap of supported features for both the cell phone 104 and the Audio Input 116. Audio Input 116 will consider the Service Level Connection to be completely started, and thereby established after the cell phone 104 was successfully answered with OK for the AT + CMER command (to allow the "status indicator update" function), if the "call waiting and three-way call" bit was not set in the bit map of features supported by the phone cellular phone 104 or Audio Input 116. A description will now be given regarding the loss of link recovery of an Audio Input 116 according to an illustrative embodiment of the present invention. The Audio Input 116 can be reconnected with the cell phone 104 at any time where the BLUETOOTH link is lost. When a Service Level Connection is disconnected due to explicit termination at one end (using the service connection release as described below), then both devices (Audio Input 116 and cell phone 104) must await an action of explicit user before an attempt is made to re-establish the Service Level Connection. If the Audio Input 116 determines that the Service Level Connection was disconnected due to a link monitoring term, then the Audio Input 116 may execute the "Service Level Connection Establishment" procedure as described above for establish a new Service Level Connection for the cellular telephone 104. Following a link loss due to the link supervision term, the Audio Input 116 should not assume that the service level connection status of the previous connection is valid (such as the Call State, Service State). A description will now be given regarding service level connection release, according to an illustrative embodiment of the present invention. Figure 36 is a diagram illustrating a service level connection release, according to an illustrative embodiment of the present invention. The disconnection of a 3580 Service Level Connection must immediately mean the removal of the RFCOMM data link channel between the cellular telephone 104 and the Audio Input 116 (3608). Also, an existing audio connection must be removed as a result of the removal of the Service Level Connection. Removal of L2CAP 3324 and link layers is optional. An Established Service Level Connection must be placed using a "service level connection removal" procedure. The "Service Level Connection Removal" procedure must be initiated through an explicit user request by cell phone 104 or by Audio Input 116 (3612). The "Level Connection Connection Removal" procedure Service "must be started if BLUETOOTH functionality page 68 is disabled on cell phone 104 or Audio Input 116. The procedure of" Service Level Connection Removal "can be initiated if an" Audio Connection "transfers to the cell phone ", if performed during an ongoing call on the cellular phone 104. In the event that the Service Level Connection is removed, the cellular telephone 104 will attempt to re-establish the Service Level Connection, once it has been The call is dropped As a precondition for this procedure, an ongoing Service Level Connection between Audio Input 116 and cell phone 104 must exist.A description will now be provided regarding the transfer of registration status, in accordance with an illustrative embodiment of the present invention.
Figure 37 is a diagram illustrating a transfer a registration status transfer, according to an illustrative embodiment of the present invention. The AT + CMER command, as described above, enables the "Regulation Status Update" function in the cell phone 104 (3704). When this function is enabled, the cell phone 104 will send the unsolicited + CIEV result code with the corresponding service indicator and the value for the Audio Input 116 at any time the cell phone registration status changes (3702). . Audio Input 116 should be able to interpret the information provided by the + CIEV result code to determine the status of service availability. As a precondition for this procedure, a Current Service Level Connection 3580 between the Audio Input 116 and the cell phone 104 must exist. If this connection does not exist, the cellular telephone 104 will autonomously establish the Service Level Connection using the procedure as described above. A description will now be provided regarding the call transfer and call configuration status, according to an illustrative embodiment of the present invention. The AT + CMER command, as discussed above, allows the function of "updating call status indicators" on the telephone. When the instruction is enabled, the cell phone will issue an unsolicited + CIEV result code with the corresponding call indicator and the value at any time that changes the current cell phone call status. Similarly, Audio Input 116 will issue an unsolicited + CIEV result code with the corresponding call setup indicator and the value at any time that changes the configuration status of the current cell phone call. The Audio Input 116 will be able to interpret the information provided by the + CIEV result code to determine the call status. In addition, the cell phone unit may also be able to interpret the optional call configuration status information provided by the + CIEV result code. A description will now be given regarding an audio connection configuration according to an illustrative embodiment of the present invention. Figure 38 is a diagram illustrating an audio connection configuration according to an illustrative embodiment of the present invention. With a user action or internal event (3802), either the cell phone 104 or the Audio Input 116 can initiate the establishment of an Audio Connection at any time that is necessary. In addition, internal actions may be necessary by the cellular telephone 104 or the Audio Input 116 to internally route the audio parts. An Audio Connection setup procedure always means establishing an SCO link (3810) and it is always associated with a Service Level Connection (3580). At first, configuring an Audio Connection by using the procedure described here is not necessarily related to any calling process. Once there is an Audio Connection (3880) between the cellular phone 104 and the Audio Input 116, the cell phone will use the Audio Input 116 as its only audio port. The cellular telephone 104 will maintain two audio paths, call related, or not, routed (3820) to the Audio Input 116 for all operations (eg, voice, alert, pressure tones) that involve the presence of audio. As a precondition of this procedure, a Service Level Connection 3580 between the Audio Input 116 and the cell phone 104 must exist. If this 3580 connection does not exist, the initiator of the procedure must automatically establish the Service Level Connection using the appropriate procedure as previously discovered. Both the initiator and the acceptor will notify the presence of the Audio Connection. The incoming Audio Connection can be rejected when released (as described below). A description regarding audio connection release will now be provided, according to an illustrative embodiment of the present invention. With a user action or an internal event, either the cell phone 104 or the Audio Input 116 can release an existing 3880 Audio Connection, at any time that is necessary. An Audio Connection removal always means the disconnection of its corresponding SCO link 3810. When the audio connection is released, the audio paths will be routed back to the cell phone / PCS 104. In principle, the removal of a connection from Audio when using the procedure described in this section is not necessarily related to any calling process. As a precondition for this procedure, there must be an Audio Connection 3880 between the Audio Input 116 and the cellular telephone 104. A description will now be provided regarding an incoming call, in accordance with an illustrative embodiment of the present invention. Figure 39 is a diagram illustrating a method for answering an incoming call, according to an illustrative embodiment of the present invention. With an established service tag (3904), an SCO link can be established between Audio Input 116 and cell phone 104 (3908). Then an audio connection (3910) is established. With an incoming call, the cellular phone 104 will send a sequence of unsolicited Ring Alerts to Audio Input (Access Point) 116. The Ring alert should be repeated while the call acceptance is pending or until the incoming call is received. interrupt for any reason. The Audio Input 116 may produce a local alert, (for example, a ring tone) when RINGER reacts. The Audio Input 116 can abort the incoming bell call at any time you wish. A description will now be provided with respect to terminating a call process of the Audio Input 116, in accordance with an illustrative embodiment of the present invention. Figure 40 is a diagram illustrating a method for terminating an Audio Input 116 calling process, in accordance with an illustrative embodiment of the present invention. Either the cell phone 104 or the Audio Input 116, by means of a user action or any other event (4002), can terminate a call procedure in progress. The following preconditions apply to this procedure. An ongoing service level connection between Audio Input 116 and phone named 104 must exist (3580). If this connection does not exist, Audio Input 116 must automatically establish the Service Level Connection using the copied procedure as described above. Another such precondition is that a process related to call (4010) is in progress in the AG. Although it is not required for the call termination process, an Audio Connection is typically present between the cell phone and AG. The user can abort the ongoing call process using any means provided by the Audio Input 116. The Audio Input 116 should send an AT + CHUP command to the cell phone 104 (4020), and the cell phone 104 will then start the procedure to terminate or interrupt the current calling procedure (4030). The cell phone 104 will then send an OK message (4040) by the + CIEV result code, with the value indicating (call = 0) (4050). When performing a similar procedure, the AT + CHUP command described above can be used to interrupt a normal call setup process. Although not required for the call termination process, an Audio Connection is typically present between the HF and AG. A description will now be given regarding placing a call with a telephone number provided by an Audio Input 116, in accordance with an illustrative embodiment of the present invention. Figure 41 is a diagram illustrating a method for placing a call with a telephone number provided by an Audio Input 116, according to an illustrative embodiment of the present invention. The Audio Input 116 can initiate voice calls in progress by providing the destination telephone number to the cell 104. To initiate the call setup, the Audio Input 116 will initiate the establishment of Connecting a Service Level, if necessary and send an appropriate ATDdd ... dd command to the cell phone 104 (4102). Cell phone 104 will send Accept to Audio Input 116 (4104), and will be the call set-up procedure using the telephone number received from Audio Input 116 and will output the + C1EV result code with the value (configuration of call = 2) to notify the Audio Input wall 116 that the call setup has been successfully started (4106). As a pre-condition for this procedure, a Connection of Service level (3580) between Audio Input 116 and cell phone 104 exists. If this connection does not exist. If this connection does not exist, then the audio input 116 will autonomously establish the Service Level Connection using the appropriate procedure as described above. If an Audio Connection has not been established the cellular telephone 104 will begin to configure (4108) the audio connection to establish the appropriate Audio Connection (4110) and routes the audio paths of the current call to the Audio Input 116 following immediately the beginning of the call setup procedure in progress. Once the alert of the remote party begins, the cell phone 104 will issue the + CIEV result code, with the value indicating (call configuration = 3) (4112). The + C1EV result code is used to report states such as "call = 1") (4114). If the normal call set-up procedure is interrupted for this reason, the cell phone 104 will issue the + CIEV result code with the value indicating (call configuration = 0) (4116), to notify the Audio Input 116 of this condition. If the cell phone 104 supports the "3-way call" feature and if a call is already in progress from the cell phone 104, perform this see procedure resulting in a new call being placed to a third party with the current call in progress or is in maintenance. A description will now be provided regarding the Call Line Identification (CLI) notification, in accordance with an illustrative embodiment of the present invention. Figure 42 is a diagram illustrating a method for performing the Call Line Identification (CLI) notification, in accordance with an illustrative embodiment of the present invention. An internal event or user request can be directed to enable CLI notification (4201). The Audio Input 116 can issue the AT + CLIP command to enable the "call line identification notification" function on a cell phone (4204). If the information of the call subscriber number is available from the network, the cell phone will issue the + CLIP unsolicited result code only after the RINGER indication when the Audio Input 116 is alerted on an incoming call. Once the Audio Input 116 issues the command of AT + CLIP the cell phone 104 will respond with a message of ACCEPT (4208). The cellular telephone 104 will then maintain the "call-line identification notification" enabled until the AT + CLIP command is issued by the Audio Input 116 to disable it, or the current Service Level Connection between the Audio Input 116 the cell phone 104 goes down for any reason. As a precondition for this method, a Service Level Connection between the Audio Input 116 and the cell phone will exist (3580). If this connection does not exist, Audio Input 116 will autonomously establish the Service Level Connection using the appropriate procedure as described above. A description will now be provided which refers to the integration of an Audio Input 116 into the residential telephone network, according to an illustrative embodiment of the present invention. There are several ways through which the audio and cell phone / PCS 104 data can be distributed on the home telephone network. Figure 43 is a diagram illustrating an illustrative network integration solution directed to a cell phone / PCS and a Telephone Old Flat Phone Service (POTS), according to an illustrative embodiment of the present invention. An Audio Input 116, a wireless base solution 114, and a POTS telephone 4304 is connected to a Telco Entry Point (RJ11) 4302. Another POTS 4310 telephone and a cell phone / PCS via cables 106 are connected to the Audio Input 116. A cellular telephone 104 is capable of communicating wirelessly with Audio Input 116 and vice versa. Each of the plurality of wireless microphones 102 is capable of communicating wirelessly with the wireless base station 114 and vice versa. It should be appreciated that the POTS 4304 telephone, the other POTS 4310 telephone, and the plurality of wireless microphones 102 (in conjunction with the base station 114) are also collectively referred to herein as the POTS 4399 telephone. PCS 104 is via cables or linked to the Access Point (Audio Input 116) through a BLUETOOTH connection. The Access Point has a SLIC 120 that can be connected between the regular POTS line and the cellular signal path to the POTS 4399 telephone to the Access Point. As noted above, the POTS 4399 telephone can be wired (for example, 4304, 4310) or wireless (102 with 114). The connected POTS phone 4399 is always connected to the cellular circuit but has the ability to direct calls through the POTS line as well. For the initiation of call through the cellular network, the POTS 4399 telephone sends a coded DTMF sequence that is understood by the Access Point that a call is being initiated. The DTMF 2830 encoder in the SLIC 120 decodes the dialed digits of the POTS 4399 telephone and mutes and formats the dial number row with the appropriate AT commands. It is presumed that the necessary link and the audio channel establishment procedures described above have already occurred. The link is then configured between the POTS phone 4399 and the cell phone 104. In the case of the incoming call, the details of the connection between the cell phone and the Access Point are described above. A "RING" signal is received from the cellular telephone 104, which was decoded at the Access Point which in turn issues the "RING" command to the SLIC 120. Any CLIP information (caller ID) that is received from the telephone cellular 104 is approximately modulated between the ring signals (as per the existing POTS line standards), so that any generic 4399 POTS telephone (cordless or wireless) with caller ID decoding capability can decode the signal and present it The POTS 4399 telephone then takes the call when an appropriate AT command is issued from the Access Point to the cell phone 104 and the audio connection is established. Again, at the termination of the call, the Access Point senses the line voltage or waits for a DTMF command issued from the 4399 telephone to make a call state determination and appropriately warns the cell phone 104. In summary, in where you use the offline command modes in the cellular modem you will make this connection. It is possible through the use of appropriate AT commands to exploit the full capacity of the cellular modem. This scenario is going to be targeted at the extension of the architecture scope to POTS phone locations. Figure 44 is a diagram illustrating another illustrative network integration solution directed to a cellular telephone / PCS and a POTS Old Telephone Telephone Service telephone, in accordance with another illustrative embodiment of the present invention. The diagram in Figure 44 illustrates a system architecture with cellular / PCS connection enabled by BLUETOOTH / BLUETOOTH cables and remote extenders based on BLUETOOTH. The system architecture shown in Figure 44 extends the scope of the Access Point to provide remote extenders that allow signaling and communication between a remote POTS phone to any POTS line or cellular network without violating any of the telephone companies and Federal Communications Commission (FCC) rules. There are methods of providing this signaling extension between the Access Point and the remote POTS telephones. Two methods illustrated in Figures 44 and 45 show the remote extensions provided by: (a) a wireless connection based on BLUETOOTH; and (b) it uses a 400 KHz sub-transporter that carries both bilateral audio as well as command and DTMF signals. Referring to Figure 44, an Audio Input 116, a first SLIC and POTS 4402 line breaker, a second SLIC and POTS 4404 line breaker, a first wireless station 114A, and a first POTS 4406 telephone are connected to a Telco Entry Point (RJ11) 4302. A second POTS 4410 telephone, a cell phone / PCS via cables 106, and a base station without BLUETOOTH 4411 guard are connected to the Audio Input 116. A cell phone 104 is able to communicate wirelessly with Audio Input 116 and vice versa.
A second wireless base station 114B and a first wireless extension of BLUETOOTH 4415 are connected to the first line breaker of SLIC and POTS 4402. A third POTS telephone 4418 and a second wireless extension of BLUETOOTH 4420 are connected to the second line breaker of SLIC and POTS 4404. Each of the plurality of wireless microphones 102A are capable of communicating wirelessly with the first wireless base station 114A and vice versa. Each of the plurality of other wireless microphones 102B are capable of communicating wirelessly with the second wireless base station 114B and vice versa. The 4411 BLUETOOTH wireless base station is able to communicate wirelessly with each of the BLUETOOTH 4420 and 4415 wireless extensions and vice versa. Figure 45 is a diagram illustrating even another illustrative network integration solution addressed to a cell phone / PCS and a Telephone Old Flat Phone Service (POTS), in accordance with another illustrative embodiment of the present invention. The diagram in Figure 45 illustrates a system architecture with cellular / PCS connection enabled by BLUETOOTH / BLUETOOTH cables and remote extenders based on High Frequency (HF). Referring to Figure 45, a first SLIC and .POTS 4520 line breaker, a second line breaker 4530 a first sub-conveyor module of 400 KHz 4540, and a third line breaker of SLIC and POTS 4552 included in the Point of 4550 access are connected to a Telco Entry Point (RJ11) 4302. The access point 4550 further includes an analog audio module 4554 and an Audio Input (BLUETOOTH) 4556. A cellular telephone 104 is capable of communicating wirelessly with the Audio Input 4550 and vice versa. The Access Point 4510 is coupled to a second sub-transporter module of 400 KHz 4556 which, in turn, is coupled to a BLUETOOTH 4558 wireless base station. The third SLIC and POTS 4552 line switch included in a first Point of Access 4550 is also coupled to a first wireless base station 114A. Each of the plurality of wireless microphones 102 A is capable of communicating wirelessly with the first wireless base station 114A and vice versa. The analog audio module 4554 included in the Point of Access 4550 is coupled to a cell phone / PCS via cables 106. The first SLIC and POTS 4520 line breaker is coupled to a first remote unit 4522 which, in turn, is coupled to a first wireless extension of BLUETOOTH 4524.
The first SLIC and POTS 4520 line switch is coupled to a first POTS telephone 4526. The second SLIC and POTS 4530 line switch is coupled to a second remote unit 4532, which, in turn, is coupled to a second one. BLUETOOTH wireless extension 4534. The second SLIC and POTS 4530 line switch is also coupled to a second wireless base station 114B. Each of the plurality of wireless microphones 102B is able to communicate wirelessly with the second wireless base stations 114B and vice versa. The first 400KHz 4540 sub-transport module is coupled to the third remote unit 4542 which, in turn, is coupled to a fourth SLIC and POTS 4544 line breaker. The fourth SLIC and POTS 4544 line breaker is also coupled to a third wireless base station 114C. Each of the plurality of wireless micro telephone 102C is capable of wirelessly communicating with the third wireless base station 114C and vice versa. The BLUETOOTH 4558 wireless base station is able to communicate wirelessly with each of the BLUETOOTH 4524 and 4534 wireless extensions, and vice versa. Figure 46 is a diagram illustrating even another illustrative network integration solution directed to a cell phone / PCS and to an Old Flat Telephone Service (POTS) telephone, according to even another illustrative embodiment of the present invention. In Figure 46, instead of having a BLUETOOTH connection between the cellular telephone 104 and the Access Point 4650, a cellular telephone 104 is included in the Access Point 4650. This cellular telephone 104 may also be specific for a cellular standard. / PCS or it could be a multi-brand multiple system implementation that allows a uniform integration opportunity. The system architecture of Figure 46 presumes the following: (a) It is possible to change a SIM card from the mobile unit to the Access Point and allow the mobile to be turned off. (b) it is possible to dynamically transfer the SIM details of the mobile to the Access Point either in the air or through connection by cables in the Access Point. (c) It is possible for the mobile S1M to be cloned on the cell phone at the Access Point. (d) It is possible to reroute all calls inside and outside the mobile to the cell phone set at the Access Point. The fixed cell phone may or may not have the same number as the mobile phone. (e) The Cellular Service provider has a scheme that allows the sharing of the mobile phone number and the residential fixed number.(f) Any other scheme that a cellular service provider may obtain with which the mobile or cell phone will be allowed to receive a cell phone so that it is transparent to the Access Point in terms of command capacity, controls and routes the audio through of the Access Point. If any of the above points is true, then it is possible to control the modem off-line in the cellular phone 104 and control the calling parameters, bilaterally, and also route the audio for the 4650 Access Point. Application for intercommunication of access point E cell phone will be issued through Host Control Processor 124, allowing Access Point 4650 to use all the features supported by the cell phone 104. Routing of audio signals and protocols of communication and methodology are identical to the previous cases.
Referring to Figure 46, a first SLIC and POTS 4620 line breaker, a second SLIC and POTS 4630 line breaker, a first 400KHz 4640 sub-conveyor module, and a third SLIC line breaker and POTS 4652 included in a 4650 Access Point are connected to a Telco Entry Point (RJ11) 4302. The 4650 access point also includes a 4654 cell phone / docking station. A 4654 cell phone / docking station is capable of communicate wirelessly with a cell tower (not shown). Access Point 4610 is coupled to a second sub-transporter module at 400KHz 4656 ie, in turn, coupled to a base station if BLUETOOTH 4658 cord. E third line switch of SLIP and POTS 4652 included in a Point Access 4650 is also coupled to a first wireless base station 114A. Each of the plurality of wireless headphones 102A is capable of communicating wirelessly with the first base station without cordo + pm114A, and vice versa.
The first SLIC and POTS 4620 line switch is coupled to a first remote unit 4622, which, in turn, is coupled to a first wireless extension 4624 of BLUETOOTH. The first SLIC and POTS 4620 line breaker is also coupled to a second wireless base 114B. Each of a plurality of wireless headphones 102B is able to communicate wirelessly with the second wireless base station 114B, and vice versa. The second switch of SLIC and POTS 4530 is coupled to a second remote unit 4632, which, in turn, is coupled to a second wireless extension of BLUETOOH 4634. The second line switch of SL1C and POTS 4630 is also coupled to a first POTS 4636 telephone. The first 400 KHz sub-carrier module 4640 is coupled to a third remote unit 4642 which, in turn, is coupled to a fourth SLIC and POTS 4644 line breaker. The fourth SLIC line breaker and POTS 4644 is further coupled to a third wireless base station 114C. Each of the plurality of wireless handset 102C is capable of communicating wirelessly with the third wireless base station 114C and vice versa. The BLUETOOTH 4658 wireless base station is able to communicate wirelessly with each of the BLUETOOTH 4624 and 4634 wireless extensions and vice versa. It should be appreciated that in the figures, for example, Figures 44-46, a first element coupled to a second element may be separated from or part of the second element. Of course, other variations are possible and are readily contemplated by one skilled in the art, while maintaining the spirit of the present invention. Although the illustrative embodiments have been described herein with reference to the accompanying drawings, it should be understood that the present invention is not limited to those precise embodiments, and that various other changes and modifications may be made here through one of ordinary skill in the art without depart from the scope or spirit of the invention. Such changes and modifications are intended to be included within the scope of the invention as defined by the appended claims.

Claims (17)

1. - A system for integrating at least one telephone of Old Residential Flat Phone System (POTS) to a cellular telephone network, comprising: a Subscriber Line Interface Circuit (SLIC) (120) for interconnecting audio from the network of cell phone to at least one residential POTS phone; a line switch (122), connected to said SLIC, for connecting at least one residential POTS telephone to any POTS line or a cellular line; and an audio input (116), connected to said SLIC, for wirelessly receiving audio from a cellular telephone connected to the cellular telephone network for subsequent transmission to at least one residential telephone and for wirelessly transmitting the audio of the POTS line to the cell phone.
2. The system according to claim 1, wherein said SLIC comprises a Double-Tone Multiple Frequency Decoder (122) for decoding a row of initially dialed number entered into the residential POTS telephone, and for formatting the row of dialed number to be used by the cell phone network.
3. The system according to claim 2, wherein the cellular phone includes a modem, and said SLCI (120) formats the number row marked in Attention commands (AT) to be used by the modem included in the cell phone. .
4. The system according to claim 3, wherein the cellular phone includes a modem, and said audio input includes an AT command translator.
5. The system according to claim 1, wherein the cellular telephone includes a modem, and said audio input is an Attention command translator for receiving AT commands from said SLIC and translating the AT commands into a compatible format. with the modem included in the cell phone.
6. The system according to claim 1, wherein said SLIC (120) comprises a caller ID module for receiving caller ID information from the cellular telephone network and for taking caller ID information to be used. by residential POTS phone.
7. The system according to claim 1, wherein said SLIC (120) receives Pulse Code Modulation (PCM) signals from the cell phone network for conversion to analog signals for subsequent receipt by the residential POTS telephone. , and receive the analog signals from the POTS line for conversion to the PCM signals for subsequent receipt by the cell phone.
8. The system according to claim 1, wherein at least one residential POTS telephone includes a remote residential POTS telephone, and said system further comprises at least one remote extender (4420) to allow communications between the POTS telephone. remote residential and any of the line of POTS and the cell line.
9. The system according to claim 1, wherein said audio input comprises a fixed cell phone and docking station (4654), to allow communications between the cell phone and the fixed cell phone.
10. The system according to claim 1, wherein said SLIC (120) is connected to a Telephone Access Point. (TAP).
11. The system according to claim 1, wherein said audio input (116) is capable of communicating with the cell phone through either a cable through cables, a fixed BLUETOOTH module, an external BLUETOOTH bell. , and an Infrared (IR) module.
12. The system according to claim 1, wherein the cellular telephone includes a modem, said audio input emits Attention commands (AT) addressed to the modem included in the cell phone to enable the cell phone to receive a call from phone dialed to a residential POTS phone number.
13. The system according to claim 1, further comprising a USB interface (110) to connect the cell phone to said SLIC.
14. The system according to claim 1, which also comprises an RS-232 / Analog Audio Interface (112) to connect the cell phone to said SLIC.
15. The system according to claim 1, wherein at least one residential POTS telephone comprises at least one wireless telephone.
16. The system according to claim 15, wherein at least the residential POTS telephone further comprises at least one cordless telephone.
17. The system according to claim 1, wherein the audio input (116) is capable of perceiving line voltages and Dual Tone Multiple Frequency commands to determine the call status, and provide an indication of the status of the call to the cell phone using Attention (AT) commands.
MXPA/A/2006/005406A 2003-11-13 2006-05-12 Integrated cellular/pcs-pots communication system MXPA06005406A (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US60/519,595 2003-11-13

Publications (1)

Publication Number Publication Date
MXPA06005406A true MXPA06005406A (en) 2006-10-17

Family

ID=

Similar Documents

Publication Publication Date Title
KR101112456B1 (en) Integrated cellular/PCS-POTS communication system
Shepherd Bluetooth wireless technology in the home
KR101240551B1 (en) Bluetooth-based chatting system and method
EP2196040B1 (en) Negotiation of a short range wireless communication parameters using configuration data received through rfid
US6571103B1 (en) Establishing a communication link
EP1469659B1 (en) A short-range radio terminal adapted for data streaming and real time services
US7327981B2 (en) Systems and methods for using landline telephone systems to exchange information with various electronic devices
EP1324550B1 (en) Portable terminal with combined direct short haul radio and cellular radio communication
US20030235186A1 (en) Internet cordless phone
US20070211624A1 (en) Communication device, radio communication arrangement and method for transmitting information
US8095078B2 (en) Communication terminal device
CN103733661A (en) Methods and apparatuses for providing profile information in a bluetooth communication system
US20030162544A1 (en) Call handling device
Negus et al. HomeRF™ and SWAP: wireless networking for the connected home
US20020172191A1 (en) Call handling device
JP2001144827A (en) Communication controller and communication control method
MXPA06005406A (en) Integrated cellular/pcs-pots communication system
KR100605904B1 (en) Method for embodying telecommunication network in home by use of the bluetooth
KR200228406Y1 (en) earphone set for handphone
KR100382188B1 (en) earphone set for handphone
Djonin et al. The Bluetooth System
JP2004193697A (en) Wireless communication system, mobile terminal, and host terminal
JP2006019881A (en) Wireless network communication method and wireless network communication system
Robert Bluetooth: A Short Tutorial
JP2005086610A (en) Communication system