WO2005096553A1

WO2005096553A1 - Selective header error correction for ad hoc networks

Info

Publication number: WO2005096553A1
Application number: PCT/US2004/037337
Authority: WO
Inventors: L. Scott Bloebaum
Original assignee: Sony Ericsson Mobile Communications Ab
Priority date: 2004-03-17
Filing date: 2004-11-09
Publication date: 2005-10-13
Also published as: CN1926813A; JP2007529950A; US7443785B2; CN100568838C; DE602004020811D1; JP4700683B2; US20050207350A1; EP1733508A1; EP1733508B1

Abstract

Error control is provided in an ad hoc network having an asynchronous communication mode and a synchronous communication mode. A packet including a header and a payload is received. The header includes a header error check (HEC) computed based on the header. An error indicator is calculated based on the received header. The received payload is forwarded if the calculated error indicator indicates an error free header. The header, only in the synchronous communication mode, is modified based on an error correction table when the calculated error indicator corresponds to a value in the error correction table and the received payload is forwarded. A received packet error is detected in the synchronous communication mode when the calculated error indicator indicates an error in the header and the calculated error indicator does not correspond to a value in the error correction table. A received packet error is detected in the asynchronous communication mode when the calculated error indicates an error in the header.

Description

SELECTIVE HEADER ERROR CORRECTION FOR AD HOC NETWORKS

FIELD OF THE INVENTION This invention relates to wireless communications, and more particularly to enor conection for wireless communications.

BACKGROUND OF THE INVENTION Various ad hoc communication networks support packet communications in an asynchronous communication mode and/or a synchronous communication mode. The different communication modes may be used, for example, to support different services. For example, a synchronous communication link may be more appropriate for a demanding service, such as voice. One example of such an ad hoc network is a Bluetooth compliant network. The Bluetooth 1.1 standard ("BT-1.1 ") specifies packets that include an access code, header and payload as illustrated in Figure 1A. As will be more fully described below, the header is protected by a cyclical redundancy check (CRC) that is generally effective at detecting enors but not designed to conect enors. As one of the header fields may indicate a destination device for a packet, an indeterminate header enor could lead to unintended reception by an inconect device in the same Bluetooth piconet. As a result, the BT-1.1 standard specifies that a receiver discard any packets with enors detected by a bad CRC check on the packet header. This packet-handling approach is provided based on the requirements of a data-communications environment where the Bluetooth link is shared by multiple devices that may transmit bursts of data asynchronously. For such asynchronous communication mode operations, the destination of a packet is generally not known in advance to the receiver, which, therefore, operates to accept only its own packets. Bluetooth also provides for support of various applications using a synchronous communication mode. For example, the BT-1.1 standard provides for supporting a real time application such as voice. In such a case, Bluetooth provides a synchronous link in which the transmissions are scheduled in advance to occur at regular intervals so that a receiver may know when to expect packets for the synchronous link. Dropped packets due to bad header CRC results may adversely affect voice quality in such a real-time application as with, for example, a Bluetooth headset. The BT-1.1 standard will now be more fully described with reference to the baseband (BB) packet illustrated in Figure 1 A. As illustrated in Figure 1 A, the access code is 72 bits in length. The access code may be used by the receiver for timing recovery, frequency offset determination and compensation and/or channel access control functions. During normal link operations after a Bluetooth piconet has been established, a Channel Access Code (CAC) may be used to identify the particular piconet. Two other access codes, the Device Access Code (DAC) and the Inquiry Access Code (IAC) may be used during the piconet establishment procedures of paging and inquiry, respectively. The header illustrated in Figure 1 A is 54 bits in length. The header may contain information for packet acknowledgement, packet sequence number for reordering, flow control, identity of the slave device within the Bluetooth piconet that is the intended destination or the source of the packet and/or the header enor check (HEC), which is a type of cyclical redundancy check (CRC). As specified by the BT- 1.1 standard, an 8-bit HEC is computed for a 10-bit header data field to form an 18-bit header. The 18-bit header may be protected by a rate-1/3 repeat code to form a 54-bit field as illustrated in Figure 1 A. The repeat code is specified for use in improving the signal to noise ratio at the receiver rather than for use in connection with an enor conection code decoding processing at the receiver. Also shown in Figure 1A is the payload. The payload may be 0 bits for a null packet or range from 240 bits to 2,745 bits in length for data packets. The 240 bit length payload may be supported within a single time slot of the Bluetooth specified frame structure. Greater payload lengths may be supported by allocating multiple time slots within a frame for a single packet. The payload can contain data for either a synchronous connection-oriented (SCO) link or an asynchronous connection-less (ACL) link. Each payload type (ACL or SCO) may be provided a variety of different options for enor conection, including no coding, rate 2/3 block and/or rate 1/3 sequential repeat code. The format of coding for the payload may be established at the time of negotiation of a link between a master and a slave device on a Bluetooth piconet. Further details of the BT-1.1 standard format of the header are illustrated in Figure IB. As shown in Figure IB, the header includes a member address (AMER_ADDR) distinguishing between active members participating on a piconet, a packet type (TYPE), a flow control bit (FLOW) for flow control of packets over the asynchronous link, a one bit acknowledgement indication (ARQN) to acknowledge successful transfer of payload data, a sequence bit (SEQN) providing a sequential numbering scheme for ordering data in a packet stream and a header-enor-check (HEC) to check the header integrity. SUMMARY OF THE INVENTION Some embodiments of the present invention provide enor control in an ad hoc network having an asynchronous communication mode and a synchronous communication mode. A packet including a header and a payload is received. The header includes a header enor check (HEC) computed based on the header. An enor indicator is calculated based on the received header. The received payload is forwarded if the calculated enor indicator indicates an enor free header. The header, only in the synchronous communication mode, is modified based on an enor conection table when the calculated enor indicator conesponds to a value in the enor conection table and the received payload is forwarded. A received packet enor is detected in the synchronous communication mode when the calculated error indicator indicates an enor in the header and the calculated enor indicator does not conespond to a value in the error conection table. A received packet enor is detected in the asynchronous communication mode when the calculated enor indicates an enor in the header. In other embodiments of the present invention, the enor indicator is a remainder value. The header may include n data bits and the enor conection table may be an n-entry table, each of the entries conesponding to an enor in an associated one of the data bits. The ad hoc network may be a Bluetooth compliant network and detecting a received packet enor may include discarding the received payload. The header may have an eighteen bit length and the HEC may be eight bits of the header. The received header may be a repeat coded header and receiving the packet may include demodulating the repeat coded header to provide the header including the HEC. In further embodiments of the present invention, detecting a received packet enor further includes discarding the received payload. The header further includes a destination device address and modifying the header includes determining a destination device address based on the modified header and forwarding the received payload when the determined destination device address conesponds to an expected destination device address. A received packet enor is detected and the received payload is discarded when the determined destination device address does not conespond to the expected destination device address. In other embodiments of the present invention, the synchronous connection- oriented (SCO) link is negotiated to establish the synchronous communication mode. A frame time is associated with the SCO link. A packet received at about the frame time is characterized as a synchronous communication mode received packet. Modifying the header, only in the synchronous communication mode, includes modifying the header only for the synchronous communication mode received packets. Packets not received at about the frame time may be characterized as asynchronous communication mode received packets and forwarding the received payload may include forwarding the received payload for asynchronous communication mode received packets having a destination device address conesponding to an expected destination device address and discarding the received payload for asynchronous communication mode received packets having a destination device address not conesponding to the expected destination device address. In further embodiments of the present invention, modifying the header includes, for synchronous mode received packets, forwarding the received payload when the determined destination device address conesponds to the expected destination device address and detecting a received packet enor and discarding the received payload when the determined destination device address does not conespond to the expected destination device address. The enor indicator may be a remainder value and calculating the remainder value may include calculating the remainder value based on a generator polynomial and an initial value known to a device receiving a packet and a device transmitting the packet. Negotiating a synchronous connection-oriented (SCO) link may include establishing the initial value for the SCO link. In other embodiments of the present invention, a bit enor rate for the SCO link is estimated. Modifying the header is disabled when the estimated bit error rate fails to satisfy an enor conection criterion. In further embodiments of the present invention, enor control in an ad hoc network includes receiving a packet including a header and a payload, the header including a header enor check (HEC) computed based on the header. An enor indicator is calculated based on the received header. The received payload is forwarded if the calculated enor indicator indicates an enor free header. The header is modified based on an enor conection table when the calculated enor indicator conesponds to a value in the enor conection table and the received payload is forwarded based on the modified header. A received packet enor is detected when the calculated enor indicator indicates an enor in the header and the calculated enor indicator does not conespond to a value in the error conection table. In other embodiments of the present invention, a communication device for an ad hoc network having an asynchronous communication mode and a synchronous communication mode includes a receiver configured to receive a packet including a header and a payload, the header including a header enor check (HEC) computed based on the header. The device further includes an enor detect circuit configured to calculate an error indicator based on the received header and an enor conection circuit configured to modify the header based on an enor conection table when the calculated enor indicator conesponds to a value in the enor conection table. The enor conection circuit is configured to modify the header only in the synchronous communication mode. The device also includes a payload processing circuit configured to forward the received payload when the calculated enor indicator indicates an enor free header and/or when the enor conection circuit modifies the header and to detect a received packet enor when the calculated error indicator indicates an enor in the header and the calculated enor indicator does not conespond to a value in the enor conection table in the synchronous communication mode and to detect a received packet enor in the asynchronous communication mode when the calculated enor indicator indicates an enor in the header. In further embodiments of the present invention, the payload processing circuit is further configured to discard the received payload if a received packet enor is detected. The payload processing circuit may be further configured to discard the received payload if a received packet enor is detected. The header may further include a destination device address and the enor conection circuit may be configured to determine a destination device address based on the modified header. The payload processing circuit may be configured to forward the received payload when the determined destination device address conesponds to an expected destination device address and to detect a received packet enor and discard the received payload when the determined destination device address does not conespond to the expected destination device address. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1A illustrates a baseband packet for a BT1.1 standard Bluetooth network. Figure IB illustrates a header for a BT1.1 standard Bluetooth network baseband packet. Figure 2 is a schematic block diagram illustrating a communication device, such as a mobile terminal, according to some embodiments of the present invention. Figure 3 is a flowchart illustrating operations for enor control in an ad hoc network according to various embodiments of the present invention. Figure 4 is a flowchart illustrating operations for enor control in an ad hoc network according to further embodiments of the present invention. Figure 5 is a flowchart illustrating operations for enor control in an ad hoc network according to various embodiments of the present invention. Figure 6 is a schematic block diagram illustrating a communication device according to some embodiments of the present invention.

DETAILED DESCRIPTION The present invention now will be described more fully hereinafter with reference to the accompanying drawings, in which embodiments of the invention are shown. However, this invention should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout. It also will be understood that, as used herein, the term "comprising" or "comprises" is open-ended, and includes one or more stated elements, steps and/or functions without precluding one or more unstated elements, steps and/or functions. It will also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. The present invention is described below with reference to block diagrams and/or operational illustrations of methods and wireless terminals according to embodiments of the invention. It is understood that each block of the block diagrams and/or operational illustrations, and combinations of blocks in the block diagrams and/or operational illustrations, can be implemented by radio frequency, analog and/or digital hardware, and/or computer program instmctions. These computer program instmctions may be provided to a processor of a general purpose computer, special purpose computer, ASIC, and/or other programmable data processing apparatus, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, create means for implementing the functions/acts specified in the block diagrams and/or operational block or blocks. In some alternate implementations, the functions/acts noted in the blocks may occur out of the order noted in the operational illustrations. For example, two blocks shown in succession may in fact be executed substantially concunently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. The invention is generally described herein in the context of wireless terminals that can communicate over an ad hoc, typically short-range (i.e., low power), communication channel, such as a Bluetooth communication channel, with network accessible devices or other wireless devices. As used herein, a "wireless terminal" or "mobile terminal" includes, but is not limited to, a terminal that is configured to communicate via a wireless interface such as, for example, a cellular interface, a wireless local area network interface (WLAN), Bluetooth interface, another RF communication interface, and/or an optical interface. Example wireless terminals include, but are not limited to, a cellular wireless terminal; a personal communication terminal that may combine a cellular wireless terminal with data processing, facsimile and data communications capabilities; a personal data assistance (PDA) that can include a wireless transceiver, pager, Internet/intranet access, local area network interface, wide area network interface, Web browser, organizer, and/or calendar; and a mobile or fixed computer or other device that includes a wireless transceiver. The wireless terminal may be configured to communicate via a cellular communication link that may include a protocol such as, for example, ANSI- 136, Global Standard for Mobile (GSM) communication, General Packet Radio Service (GPRS), enhanced data rates for GSM evolution (EDGE), code division multiple access (CDMA), wideband-CDMA, CDMA2000, and UMTS. As understood by those who are skilled in the art, the Bluetooth protocol provides a universal radio interface in the 2.45 GHz unlicensed frequency band between electronic devices that connect and communicate wirelessly via short-range ad hoc networks. Communication protocols as used herein may specify the information communicated, the timing, the frequency, the modulation, and/or the operations for setting-up and/or maintaining a communication connection. As will be appreciated by one of skill in the art, the present invention may be embodied as a method or device, such as a mobile terminal or other ad hoc protocol supporting devices like headphones or the like. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects, all generally refereed to herein as a "circuit." Computer program code for canying out operations of the present invention may be written in an object oriented programming language such as Java®, Smalltalk or C++, a conventional procedural programming languages, such as the "C" programming language, or lower-level code, such as assembly language and/or microcode. The program code may execute entirely on a single processor and/or across multiple processors, as a stand-alone software package or as part of another software package. The present invention is described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instmctions. These computer program instmctions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instmctions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart illustration and/or block diagram block or blocks. The computer program instmctions may also be loaded onto a computer or other programmable data processor to cause a series of operational steps to be performed on the computer or other programmable processor to produce a computer implemented process such that the instmctions that execute on the computer or other programmable processor provide steps for implementing the functions or acts specified in the flowchart illustration and/or block diagram block or blocks. Embodiments of the present invention will now be further described with reference to the schematic block diagram illustration of a mobile terminal 200 in Figure 2. Figure 2 illustrates a mobile wireless terminal 200 receiving an ad hoc wireless communication network signal 175. The mobile terminal 200 may include a keyboard/keypad 105, a display 110, a speaker 115, a microphone 120, a network transceiver 125, and a memory 130 that communicate with a processor 140. The network transceiver 125 typically comprises a transmitter circuit 150 and a receiver circuit 145, which respectively transmit outgoing radio frequency signals to an ad hoc network transceiver 26 of the network and receive incoming radio frequency signals from the transceiver 26 via an antenna 165. While a single antenna 165 is shown in Figure 2, it is to be understood that multiple antennas and/or different types of antennas may be utilized based on the types of signals being received. The radio frequency signals transmitted between the mobile terminal 200 and the transceiver 26 may comprise both traffic and control signals (e.g. , paging signals/messages for incoming voice/data), which are used to establish and maintain communication with another device, and may provide uplink and/or downlink communications. However, the present invention is not limited to such two-way communication systems. With respect to their role in various conventional operations of the mobile terminal 200, including cellular network communications, the foregoing components of the mobile terminal 200 may be included in many conventional mobile terminals and their functionality is generally known to those skilled in the art. It should be further understood, that, as used herein, the term "mobile terminal" or "wireless terminal" may include a cellular radiotelephone with or without a multi-line display; a Personal Communications System (PCS) terminal that may combine a cellular radiotelephone with data processing, facsimile and data communications capabilities; a Personal Data Assistant (PDA) that can include a radiotelephone, pager,

Internet/intranet access, Web browser, organizer, calendar and/or a global positioning system (GPS) receiver, an accessory device supporting wireless communications and a conventional laptop and/or palmtop receiver or other device that includes a radio transceiver. Mobile terminals may also be refened to as "pervasive computing" devices. Also shown in the mobile terminal 200 of Figure 2 is an enor detect circuit 155 that is configured to calculate an enor indicator based on the received header. For example, the enor indicator may be a remainder value. The mobile terminal 200 of Figure 2 further includes an enor conection circuit 160 configured to modify a header based on an enor conection table when the calculated enor indicator conesponds to a value in an enor conection table 132. For example, the error conection table 132 may be stored in the memory 130. The enor conection circuit 160 in the embodiments of Figure 2 is configured to modify the header only when the terminal 200 is in the synchronous communication mode (i.e., receives a packet designated for a synchronous connection-oriented (SCO) link). Also shown in Figure 2 is a payload processing circuit 165. The payload processing circuit 165 is configured to forward a received payload when the calculated enor indicator from the enor detect circuit 155 indicates an enor free header and/or when the enor conection circuit 160 modifies the header. The payload processing circuit 165 may be further configured to detect a received packet enor when the calculated enor indicator indicates an enor in the header and the calculated enor indicator does not conespond to a value in the enor conection table for a packet received in the synchronous communication mode. The payload processing circuit 165 may be configured to detect a received packet enor in the asynchronous communication mode when the calculated enor indicator indicates an enor in the header. The payload processing circuit 165 in some embodiments of the present invention is further configured to discard a received payload if a received packet enor is detected. In addition, the payload processing circuit 165 may be further configured to discard a received packet based on a received packet enor when a determined destination device address for a packet processed by the enor detect circuit 155 and the enor conection circuit 160 does not conespond to the expected destination device address (i.e., the address of the receiving device). In such embodiments, the enor conection circuit 160 may be configured to determine the destination device address based on the modified header selected by the enor conection circuit 160. While the enor detect circuit 155, enor conection circuit 160 and payload processing circuit 165 are illustrated in the embodiments of Figure 2 as implemented on the processor 140, it will be understood that the functionality of the different circuits may be distributed across multiple processors. Furthermore, the allocation of functionality between the respective enor detect 155, enor conection 160 and payload processing 165 circuits may be distributed differently between the respective circuits and the present invention is not limited to embodiments having a particular distribution of functionality as described above with reference to Figure 2. It will also be understood that, while embodiments of the present invention have been described with reference to a mobile terminal 200 above, the communication device for an ad hoc network may be a variety of other devices having either one or two way communication support, such as headsets and/or other accessory devices or the like. Operations for enor control in an ad hoc network having an asynchronous communication mode and a synchronous communication mode will now be described for various embodiments of the present invention with reference to the flow chart illustration of Figure 3. As shown in Figure 3, operations begin at Block 300 by receiving a packet including a header and a payload. The header includes a header enor check (HEC) computed based on the header and included in the header at the transmitting device. An enor indicator is calculated based on the received header (Block 305). As will be described more fully with reference to the exemplary embodiments of Figure 6, the enor indicator may be a remainder value. Based on the calculated enor indicator, it is determined if the received header is an enor free header (Block 310). If the header is not enor free, it is determined if the calculated enor indicator conesponds to a value in the enor conection table (Block 315). If the calculated enor indicator does not conespond to a value in the enor conection table, a received packet enor is detected (Block 325). If the calculated enor indicator does conespond to a value in the enor conection table, the header is modified (Block 320). The received payload is forwarded if the calculated enor indicator indicates an enor free header at Block 310 or after modifying the header at Block 320 (Block 330). Operations described with reference to Blocks 315 and 320 may be canied out only in the synchronous communication mode of the receiving device. Accordingly, it will be understood that, in an asynchronous communication mode, if an enor is detected in the header at Block 325, then a received packet enor is detected. Where a received enor is detected at Block 325, the receiving device may discard the payload rather than forwarding the payload. Operations for enor control in an ad hoc network having an asynchronous communication mode and a synchronous communication mode for further embodiments of the present invention will now be described with reference to the flow chart illustration of Figure 4. Operations begin at Block 400 by receiving a packet including a header and a payload, where the header includes a header enor check (HEC) computed based on the header. An enor indicator is calculated based on the received header (Block 405). If the calculated enor indicator indicates an enor free header (Block 410), the received payload is forwarded (Block 440). If the calculated enor indicator does not indicate an enor free header (Block 410) and the packet was received in an asynchronous communication mode (Block 415) a received packet enor is detected (Block 425). In a synchronous communication mode (Block 415), it is determined if the calculated enor indicator from Block 405 conesponds to a value in an enor conection (EC) table (Block 420). If not, a received packet enor is detected (Block 425). If the calculated enor indicator conesponds to a value in the enor conection table (Block 420), the destination device address is determined based on a candidate modified header, and if the determined destination device address does not conespond to an expected destination device address (Block 430), a received packet enor is detected (Block 425). For example, an SCO link may be negotiated and set up for a particular master and slave pair of devices. Therefore, as synchronous communication mode may be determined based on the presumption that a packet received at a particular time is associated with such a specific SCO link, if the modified address generated by the enor conection logic described above indicates a destination device having a different address, there likely was an enor in either the assumption that the received packet was associated with a particular SCO link or that the modified header does not accurately conect an enor in the received packet. For example, in embodiments of the present invention providing for single bit enor conection, a particular multi-bit enor condition may conespond to an enor table value associated with a distinct single bit enor resulting in a possible modified header that does not conect an enor but, instead is itself enoneous. If the destination device address based on the modified header corresponds to an expected destination device address (Block 430), the header is modified based on the enor conection table (Block 435). The received payload associated with the successfully modified header is forwarded to the destination device address (Block 440). Operations for enor control in an ad hoc network related to determining whether enor conection should be enabled or disabled will now be further described with reference to the flowchart illustration of Figure 5. As shown in Figure 5, operations begin at Block 500 by negotiating a synchronous connection-oriented (SCO) link between a master and slave device to establish a synchronous communication mode. The negotiation of the SCO link at Block 500 may establish various aspects of the SCO link, including aspects such as a frame and time slot associated with the SCO link. Accordingly, a particular frame time may be associated with the SCO link (Block 505). If a packet is received at the associated frame time of the SCO link (Block 510), the packet is characterized as a synchronous communication mode received packet (Block 515). Otherwise, the packet is characterized as an asynchronous communication mode received packet (Block 535). In some embodiments of the present invention, as illustrated by Blocks 520 and 525 of Figure 5, the use of error conection even in synchronous communication mode may be limited. For example, in some embodiments of the present invention, the enor conection table may be configured specifically to conect only single bit enors and may be subject to an unacceptable risk of false header correction above a certain bit enor rate for a channel. An exemplary analysis including an estimate of a false conection rate risk at various bit enor rates will be described below. In light of the potential for false enor conection, some embodiments of the present invention provide for estimating an enor rate for the link (Block 520). In such embodiments of the present indention, if the estimated bit enor rate for the SCO link fails to satisfy an enor conection criterion (Block 525), enor conection is disabled (Block 540). If the criterion is satisfied (Block 525), enor conection is enabled (Block 530). Thus, if there are enor rates at which the risk of false conection is unacceptable, header modification based on an enor conection table may be disabled in both synchronous communication mode and asynchronous communication mode. In various embodiments of the present invention described herein, header enor conection is disabled in asynchronous communication mode without regard to a channel bit enor rate as the receiver may use information in the header to determine the packet destination and other coixtrol information associated with the asynchronous communication link. Accordingly, a bit enor in one of the header fields illustrated in Figure IB could cause the receive and transmit link control states to diverge, which may result in a significant deterioration of communication performance. Therefore, enor conection as described herein may be limited to SCO links where the receive destination address for a packet may be known in advance based on knowledge of when an SCO packet burst should occur as established at the time of negotiation of the SCO link. The present invention will now be further described with reference to the schematic block diagram of various embodiments of the present invention illustrated in Figure 6. The embodiments in Figure 6 may provide improved performance of an SCO link by reducing HEC enor rates for such a link. The embodiments of Figure 6 are particularly directed to an ad hoc network based on the BT-1.1 standard of Bluetooth. As shown in Figure 6, Blocks 605 through 620 illustrate the computation of a header h by the Bluetooth transmitter which is transmitted with the payload p over the channel 625. An M-bit cyclical redundancy check (CRC) 615 is computed on the M-bit header data 610 by the CRC calculation circuit 605 using a generator polynomial G and an initial value P that is known by both the transmitter and the receiver. The (N+M)-bit header h is rate- 1/3 repeat-coded per the Bluetooth BT-1.1 standard and then transmitted together with the payload over the channel 625 to the receiver. At the receiver, including Blocks 630 through 660 of Figure 6, the received header x (after combining with repeated bits) is given by:

where e is an (N+M)-bit enor vector for which e, = 1 represents an enor in the i^th received bit of h. The rate- 1/3 combiner 630, as described previously, may be used in demodulating a received signal to advantageously improve the signal to noise ratio using the rate- 1/3 repeat coded received signal to generate the received header x. The receiver CRC calculation circuit 635 calculates the CRC remainder r on the received vector , using techniques known to those of skill in the art, based on the polynomial G and the initial value P. The remainder value may then indicate that the header x was received enor free (i.e., e = 0) and, if so, the control logic 650 may forward the received payload as schematically indicated by the switch 655 in Figure 6. As shown in Figure 6, an enor free indication conesponds to a remainder value r of 0. If the remainder value r is not equal to 0 (i.e., e is not equal to 0) the remainder value r is compared to entries in an enor conection table E 640. For the embodiments of Figure 6, the enor conection table E has N entries with the i'^h entry E,- conesponding to the CRC remainder resulting from a single bit enor in the i^th position of the header h, such that:

Ert(e , i-0...N-\.

For some embodiments of the present invention, the table E can be precomputed based on the fixed value of G and then stored for usage during link activity. In case r=E_t, the f¹ bit in x may be conected by the enor conection EC circuit 645. If r does not match any value in the table E 640, then no conection may occur and the no match indication may be provided to the control logic block 650 to prevent forwarding of the payload as illustrated by the switch 655 in Figure 6. Thus, the match indication may be combined in the control logic block 650 with expected link type information (SCO or ACL) and an Enable EC control indicator (such as based on a determination or estimate of channel 625 enor rate) to allow the enor conection to be enabled and/or disabled under software control. An exemplary control logic for allowing enor conection according to some embodiments of the present invention is as follows: IF r = 0, Pass on payload q_ to higher layers; ELSEIF (Enable EC = = 1 AND Expected Link Type = = SCO), Compare r to all values in EC table E; IF Match to entry i, Conect i'^h bit in data section of header; Pass on payload q_ to higher layer; ELSE Indicate packet erasure to higher layer. ELSE, Indicate packet erasure to higher layer.

An exemplary analysis including an estimate of a false conection rate risk at various bit enor rates will now be described. If the single-bit probability of an enor is p and individual bit enors are assumed independent, then the probability P of i enors in an N-bit word is given by P^_P' -PT' W), where (N, i) represents the number of different choices of i elements firom N total. As the Bluetooth header generally employs a rate- 1/3 repeat coding, the _rate p is used here to refer to the probability of a single bit enor. For N=l 0 in the case of the Bluetooth header, Table 1 estimates the erasure rate versus y? with or without header enor conection according to some embodiments of the present invention. Table 1.

Table 1 illustrates an improvement in frame erasures due to HEC, which may lead to performance improvement in, for example, voice over an SCO link. This result is modeled for an AWGΝ channel where bit enors are independent, but results may differ for a fading channel where enors are more likely to occur in blocks (i.e., higher probability of multi-bit enors in the header). Note that there may not be a unique relationship between e and r , which may lead to aliasing of multi-bit enors into the enor conection table E. In- the case of Bluetooth, where N=10 and M=8, the CRC operation maps the 18-bit enors e into the 8-bit remainders r. Thus, there is some probability of falsely detecting a single-bit enor when, in fact, there exists a multi-bit enor in the received header x that has the same remainder r. It can be shown that all single bit enors have a unique r. The probability of a random enor pattern aliasing on one of the N remainder vectors in E can be calculated as: P_a = N/2^M~ 4% Thus, approximately 96% of the multi-bit enors should be detected by the CRC check while the remaining 4% may be falsely detected and "conected" by the EC table as single bit enors. The table below shows the effect of this for various values of p. Again, these results are modeled only for a channel with independent bit enors.

The flowcharts, flow diagrams and block diagrams of Figures 2 through 6 illustrate the architecture, functionality, and operation of possible implementations of devices, methods and computer program products for enor control according to embodiments of the present invention. In this regard, each block in the flow charts or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical act(s). It should also be noted that, in some alternative implementations, the acts noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concunently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. In the drawings and specification, there have been disclosed typical illustrative embodiments of the invention and, although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation, the scope of the invention being set forth in the following claims.

Claims

WHAT IS CLAIMED IS:

1. A method for enor control in an ad hoc network having an asynchronous communication mode and a synchronous communication mode, the method comprising: receiving a packet including a header and a payload, the header including a header enor check (HEC) computed based on the header; calculating an enor indicator based on the received header; forwarding the received payload if the calculated enor indicator indicates an enor free header; modifying the header, only in the synchronous communication mode, based on an enor correction table when the calculated enor indicator conesponds to a value in the enor conection table and forwarding the received payload; detecting a received packet enor in the synchronous comm nication mode when the calculated enor indicator indicates an enor in the header and the calculated enor indicator does not conespond to a value in the enor correction table; and detecting a received packet enor in the asynchronous comnrunication mode when the calculated enor indicates an enor in the header.

2. The method of Claim 1 wherein the enor indicator comprises a remainder value.

3. The method of Claim 1 wherein the header includes n data bits and wherein the enor conection table comprises an n-entry table, each of the entries conesponding to an enor in an associated one of the data bits.

4. The method of Claim 3 wherein the ad hoc network comprises a Bluetooth compliant network and wherein detecting a received packet enor further comprises discarding the received payload.

5. The method of Claim 4 wherein the header has an eighteen bit length and wherein the HEC comprises eight bits of the header.

6. The method of Claim 4 wherein the received header comprises a repeat coded header and wherein receiving the packet includes demodulating the -repeat coded header to provide the header including the HEC.

7. The method of Claim 1 wherein detecting a received packet enor further comprises discarding the received payload and wherein the header further includes a destination device address and wherein modifying the header comprises determining a destination device address based on the modified header and forwarding the received payload when the determined destination device address conesponds to an expected destination device address and detecting a received packet enor and discarding the received payload when the determined destination -device address does not conespond to the expected destination device address.

8. The method of Claim 1 further comprising: negotiating a synchronous connection-oriented (SCO) link to establish the synchronous communication mode; associating a frame time with the SCO link; and characterizing a packet received at about the frame time as a synchronous communication mode received packet; and wherein modifying the header, only in the synchronous communication mode, comprises modifying the header only for synchronous communication mod---; received packets.

9. The method of Claim 8 wherein the header further includes a. destination device address, the method further comprising: characterizing packets not received at about the frame time as async-tironous communication mode received packets; and wherein forwarding the received payload comprises forwarding the ireceived payload for asynchronous communication mode received packets having a destination device address conesponding to an expected destination device address and discarding the received payload for asynchronous communication mode received packets having a destination device address not conesponding to the expected destination device address.

10. The method of Claim 9 wherein modifying the header comprises, for synchronous mode received packets, forwarding the received payload when the determined destination device address conesponds to the expected destination device address and detecting a received packet enor and discarding the received payload when the determined destination device address does not conespond to the expected destination device address.

11. The method of Claim 10 wherein the enor indicator comprises a remainder value and wherein calculating the remainder value comprises calculating the remainder value based on a generator polynomial and an initial value known to a device receiving a packet and a device transmitting the packet.

12. The method of Claim 11 wherein negotiating a synchronous connection-oriented (SCO) link includes establishing the initial value for the SCO link.

13. The method of Claim 12 further comprising: estimating a bit error rate for the SCO link; and disabling modifying the header when the estimated bit enor rate fails to satisfy an enor conection criterion.

14. A method for enor control in an ad hoc network, comprising: receiving a packet including a header and a payload, the header including a header enor check (HEC) computed based on the header; calculating an enor indicator based on the received header; forwarding the received payload if the calculated enor indicator indicates an enor free header; modifying the header based on an enor conection table when the calculated enor indicator conesponds to a value in the error conection table and forwarding the received payload; and detecting a received packet enor when the calculated enor indicator indicates an enor in the header and the calculated enor indicator does not correspond to a value in the enor conection table.

15. A communication device for an ad hoc network having an asynchronous communication mode and a synchronous communication mode, the device comprising: a receiver configured to receive a packet including a header and a payload, the header including a header enor check (HEC) computed based on the header; an enor detect circuit configured to calculate an enor indicator based on the received header; an enor conection circuit configured to modify the header based on an enor conection table when the calculated enor indicator conesponds to a value in the enor conection table, the enor conection circuit being configured to modify tibe header only in the synchronous communication mode; and a payload processing circuit configured to forward the received payload when the calculated enor indicator indicates an enor free header and/or when t-fcie enor conection circuit modifies the header and to detect a received packet eno>r when the calculated enor indicator indicates an enor in the header and the calculated enor indicator does not conespond to a value in the enor conection table in the synchronous communication mode and to detect a received packet error ixi the asynchronous communication mode when the calculated enor indicator indicates an enor in the header.

16. The device of Claim 15 wherein the enor indicator comprises a remainder value.

17. The device of Claim 15 wherein the header includes n data bits and wherein the enor conection table comprises an n-entry table, each of the entries conesponding to an enor in an associated one of the data bits.

18. The device of Claim 17 wherein the ad hoc network comprises a Bluetooth compliant network and wherein the payload processing circuit is further configured to discard the received payload if a received packet enor is detected.

19. The device of Claim 15 wherein the payload processing circuit is further configured to discard the received payload if a received packet error is detected and wherein the header further includes a destination device address and wherein the enor conection circuit is further configured to determine a destination device address based on the modified header and wherein the payload processing circuit is further configured to forward the received payload when the determined destination device address conesponds to an expected destination device address and to detect a received packet enor and discard the received payload when the determined destination device address does not conespond to the expected destination device address.

20. The device of Claim 15 further comprising: means for negotiating a synchronous connection-oriented (SCO) link to establish the synchronous communication mode; means for associating a frame time with the SCO link; and means for characterizing a packet received at about the frame time as a synchronous communication mode received packet; and wherein the enor conection circuit is configured to modify the header only for synchronous communication mode received packets.

21. The device of Claim 20 wherein the header further includes a destination device address, the device further comprising: means for characterizing packets not received at about the frame time as asynchronous communication mode received packets; and wherein the payload processing circuit is configured to forward the received payload for asynchronous communication mode received packets having a destination device address conesponding to an expected destination device address and discard the received payload for asynchronous communication mode received packets having a destination device address not conesponding to the expected destination device address.

22. The device of Claim 21 wherein the payload processing circuit is configured, for synchronous mode received packets, to forward the received payload when the determined destination device address conesponds to the expected destination device address and to detect a received packet enor and discard the received payload when the determined destination device address does not conespond to the expected destination device address.

23. The device of Claim 22 further comprising: means for estimating a bit enor rate for the SCO link; and wherein the enor conection circuit is configured to disable modifying the header when the estimated bit enor rate fails to satisfy an enor conection criterion.

24. The device of Claim 15 wherein the device comprises a mobile terminal.

25. A device for enor control in an ad hoc network, comprising: means for receiving a packet including a header and a payload, the header including a header enor check (HEC) computed based on the header; means for calculating an enor indicator based on the received headier; means for forwarding the received payload if the calculated enor indicator indicates an enor free header; means for modifying the header based on an error conection table when the calculated enor indicator conesponds to a value in the enor conection table and forwarding the received payload; and means for detecting a received packet enor when the calculated error indicator indicates an enor in the header and the calculated enor indicator does not -conespond to a value in the enor correction table.