Here’s the actual technical gobbledygook if it helps : borrowed from ’ the hearing aid blog’
About a decade ago, mobile phones started to incorporate IEEE 802.15.4 “Bluetooth” wireless Personal Area Network (PAN) connectivity both for synching to a user’s desktop PC, and for connecting to the ubiquitous headset (the ones that look like the wearer has a cockroach on their ear). You’ll notice that we spell out “IEEE 802.15.4″ instead of using the more generic “Bluetooth” for two distinct reasons:
• To emphasize that, in general, the IEEE 802.15 family is similar to TCP/IP in general, and moreso to IEEE 802.11 “WiFi” in that it is a two-way protocol, i.e. that the transmitting station sends a packet of data along with error correcting codes and a checksum, and then the receiving station decodes the packet, verifies and corrects what errors it can, and then transmit back an ACK(nowledgement) signal. If the sending station does not receive an ACK, then it will send the packet again. This presents issues with power consumption and up to 150 mSec latency, which will be discussed below;
• To separate out the commonly used 802.15.4 Personal Area Network (PAN) standard that we all know from the still-evolving 802.15.6 Body Area Network (BAN) standard that we believe Apple may be implementing in iOS 6.
Let’s look at how “Bluetooth” is currently implemented with hearing aids for connectivity, and the significant drawbacks.
First and foremost, we need to understand that any digital reception in a hearing aid is going to consume extra power — And lots of it, due to the decoding operation. Add to this the 802.15.4 overhead of transmitting ACK signalling, even occasionally in A2DP (Advanced Audio Distribution Protocol), and it makes for a real issue. Austin-based Audiotoniq has mostly sidestepped this with their hearing aids by using a Li-ION cell; but in fact their hearing aid wireless communications protocol is only really for phone use and not continuous streaming (though they have a clever workaround for it).
Most every other manufacturer uses a “Bluetooth streamer,” which acts as a “relay station” communicating via 802.15.4 to the phone or other Bluetooth -equipped device, and then using a second transmitter to broadcast a proprietary Hearing Instrument Body Area Network (HI-BAN) signal to the hearing aids. There are three basic ways this is accomplished, and it’s important to understand the distinction, as it is key in understanding what we speculate Apple will be doing:
• Widex and Phonak use a 28 meter (10.6 mHz) “near field” digital signal.² Phonak and Widex also use 10.6 mHz for ear-to-ear communication between the instruments for binaural coordination of directional microphone beam steering, compression to maintain binaural localization, and also program shift. Widex also uses it for binaural “Phone Plus” operation and Phonak for CROS and BiCROS communications; and both manufacturers also use it for wireless programming;
• Starkey uses a 33 cm (900 mHz) UHF digital signal for streaming and ear-to-ear communications; however they also have direct-to-instrument broadcasting through their SurfLink Media transmitter, i.e. unlike the Widex TV-Dex media transmitter, no additional relay is used. However, Starkey also just released their SurfLink Mobile device, which can be used as a Bluetooth relay, and also as a remote mic up to 20 feet away — But it’s on backorder until at least fall 2012 due to unanticipated demand;
• GN ReSound uses a variation of a 2.4 gHz 802.15.4 signal — An “unofficial” 802.15.6 HI-BAN — for direct, low (under 10 mSec) latency, direct-to-instrument broadcasting from various Unite accessories to their Alera series hearing aids, as well as for remote control and wireless programming (with inter-ear coordination available 4Q2012). It is this style of direct-to-hearing aid broadcasting that we believe Apple will be implementing in software in iOS 6, by essentially “hacking” the 802.15.4 Bluetooth stack and turning it into a de facto 802.15.6 HI-BAN stack for low latency broadcasting.³
