用于无线音频设备的通信系统专利检索-耳背式助听器助听器假肢专利检索查询-专利查询网

用于无线音频设备的通信系统

阅读：759发布：2020-07-03

专利汇可以提供用于无线音频设备的通信系统专利检索，专利查询，专利分析的服务。并且本发明提供了一种用于在一个以上的无线音频设备和其他电子装置间进行无线通信的系统，以提供一组丰富的流音频、控制、程序设计和增强的听音功能。，下面是用于无线音频设备的通信系统专利的具体信息内容。

权利要求

1.一种用于以无线通信方式，在远距离信源和一定数目的助听器佩戴者之间传送信息的系统，包括：
多个助听器，每一个助听器具有用于接收分组通信的无线电接收机，所述分组通信包括分组报头以及包括数据在内的有效载荷，所述分组报头包括将特定比特识别为控制比特的信息，并经由所述控制比特来提供用于控制所述多个助听器中至少一个助听器的控制，以及所述有效载荷包括音频；以及
装置，包括无线接口，所述无线接口包括：适于从所述远距离信源接收所述信息的第一端口；以及适于以无线通信方式，将所述信息以分组格式传送至所述多个助听器的第二端口，所述无线接口包括提供多种可编程传输模式的数字电子装置，
其中，所述系统包括各自具有唯一地址的多个节点；所述节点与所述多个助听器中的每一个助听器以及与所述装置相对应，所述系统使用所述传输模式在所述多个节点中的至少两个节点之间提供可编程通信，所述系统在单一分组中提供控制信息和音频。
2.根据权利要求1所述的系统，其中无线接口适于发送流音频。
3.根据权利要求2所述的系统，其中流音频是立体声音频。
4.根据权利要求1所述的系统，其中可对助听器进行编程，以播放音频信息的立体声形式的右声道或左声道的声音。
5.根据权利要求1所述的系统，其中数字电子装置还支持向多个助听器中特定助听器传输的单播模式。
6.根据权利要求1所述的系统，其中数字电子装置还支持向多个助听器中特定的多个助听器传输的多播模式。
7.根据权利要求1所述的系统，其中数字电子装置还支持向多个助听器传输的广播模式。
8.根据权利要求1所述的系统，其中第一端口通过有线连接，接收音频。
9.根据权利要求1所述的系统，其中第一端口通过无线连接，接收音频。
10.根据权利要求9所述的系统，其中第一端口适用于兼容蓝牙协议的通信。
11.根据权利要求9所述的系统，其中第一端口适用于兼容IEEE802.11协议的通信。
12.根据权利要求9所述的系统，其中第一端口适用于兼容IEEE802.15协议的通信。
13.根据权利要求9所述的系统，其中第一端口适用于兼容IEEE802.16协议的通信。
14.根据权利要求9所述的系统，其中第一端口适用于兼容IEEE802.20协议的通信。
15.根据权利要求9所述的系统，其中第一端口适用于码分多址(CDMA)通信。
16.根据权利要求9所述的系统，其中第一端口适用于全球移动通信系统(GSM)。
17.根据权利要求9所述的系统，其中第一端口适用于超宽带(UWB)通信。
18.根据权利要求1所述的系统，其中第一端口支持光通信。
19.根据权利要求1所述的系统，其中第一端口支持超声波通信。
20.根据权利要求1所述的系统，其中第二端口适用于兼容蓝牙协议的通信。
21.根据权利要求1所述的系统，其中第二端口适用于兼容IEEE802.11协议的通信。
22.根据权利要求1所述的系统，其中第二端口适用于兼容IEEE802.15协议的通信。
23.根据权利要求1所述的系统，其中第二端口适用于兼容IEEE802.16协议的通信。
24.根据权利要求1所述的系统，其中第二端口适用于兼容IEEE802.20协议的通信。
25.根据权利要求1所述的系统，其中第二端口适用于码分多址(CDMA)通信。
26.根据权利要求1所述的系统，其中第二端口适用于全球移动通信系统(GSM)。
27.根据权利要求1所述的系统，其中第二端口适用于超宽带(UWB)通信。
28.根据权利要求1所述的系统，其中第二端口适用于光通信。
29.根据权利要求1所述的系统，其中第二端口适于载波侦听多路访问“CSMA”通信。
30.根据权利要求1所述的系统，其中助听器包括耳背式助听器。
31.根据权利要求1所述的系统，其中助听器包括耳内式助听器。
32.根据权利要求1所述的系统，其中助听器包括深耳道式助听器。
33.根据权利要求1所述的系统，其中第二端口包括第一发射机和第二发射机，用于发射立体声形式的音频。
34.一种用于以无线通信方式，将来自远距离信源的音频信息传送至多个无线助听设备的系统，其中每个无线助听设备都具有用于接收的接收机，该系统包括：
接口，包括：适于从远距离信源接收音频信息的第一端口；适于以无线通信方式，将音频信息以分组形式传送至多个无线助听设备的第二端口，该接口包括提供多种传输模式的数字电子装置，其中，所述接口被配置为提供针对至少一个佩戴者的右助听设备和左助听设备来编码的分组通信，该右助听设备和左助听设备各自具有不同的地址且各自能够接收不同的音频信息。
35.根据权利要求34所述的系统，其中该接口包括载波侦听多路访问“CSMA”传输系统。
36.根据权利要求34所述的系统，其中该接口包括数字信号处理器。
37.根据权利要求34所述的系统，其中无线助听设备包括助听器。
38.根据权利要求37所述的系统，其中助听器适于与接口进行载波侦听多路访问“CSMA”通信。
39.一种传送来自远距离信源的音频信息的系统，包括：
多个无线助听设备，每一个均具有用于接收分组的接收机；和
接口，包括：适于从远距离信源接收音频信息的第一端口；适于以无线通信方式，将音频信息以分组形式传送至多个无线助听设备的第二端口，该接口包括提供多种传输模式的数字电子装置，其中传输模式包括立体声传输模式，用于向多个无线助听设备传输立体声形式的音频信息，其中，所述接口被配置为提供针对至少一个佩戴者的右助听设备和左助听设备来编码的分组通信，该右助听设备和左助听设备各自具有不同的地址且各自能够接收不同的音频信息。
40.一种传送来自远距离信源的音频信息的系统，包括：
多个无线助听设备，每一个均具有用于接收的接收机；和
接口，包括：适于从远距离信源接收音频信息的第一端口；适于以无线通信方式，将音频信息传送至多个无线助听设备的第二端口，该接口包括提供多种传输模式的数字电子装置，其中传输模式包括立体声传输模式，用于向多个无线助听设备传输立体声形式的音频信息，其中，所述接口被配置为提供针对至少一个佩戴者的右助听设备和左助听设备来编码的通信，该右助听设备和左助听设备各自具有不同的地址且各自能够接收不同的音频信息。

说明书全文

用于无线音频设备的通信系统

[0001] 相关申请

[0002] 本申请依35U.S.C.119(e)的规定，要求2005年6月5日提交的美国临时申请序列号60/687,707的优先权，并将该申请以引用方式合并于此。

技术领域

[0003] 本主题总体涉及无线通信，更具体地说，涉及用于无线音频设备的无线通信系统。

背景技术

[0004] 随着时间的推移，用于收听声音的音频设备变得越来越丰富多样。音频设备制造商寻找新的技术和应用，以实现新方案和新设计。为了使音频设备更加轻便易携，制造商对制造无线设备产生了日益浓厚的兴趣。新内容形式和通信形式的出现，为制造商提供了机遇，并使他们能够跨越工程上的障碍。

[0005] 现有技术所需要的是一种用于和无线音频设备进行通信的系统。这种系统应灵活地提供增强特征。应可对多种内容和通信选项进行配置。发明内容

[0006] 本主题解决上述问题和此处未明确讨论的其它问题。通过阅读和学习本说明，读者将能够了解这些问题。

[0007] 本主题提供了一种用于在一个或多个的无线音频设备和其它电子装置之间进行无线通信的系统，其中其它电子装置用于提供一组丰富的流音频、控制、编程和增强的听觉功能。在一应用中，本系统为助听设备(如助听器)提供了高度可编程通信和智能通信。在各种实施例中，支持单声道通信模式和立体声通信模式。在某些实施例中，还支持单播、多播和广播通信模式。提供了许多方法，且此处所阐述的实例本意上并不是限制性的或排他性的。

[0008] 本主题是本申请的某些技术方案的概述，并非意在对本主题进行排他性或详尽无遗地论述。在详细说明和所附权利要求中，可以找到关于本主题的其他细节。本发明的范围由所附权利要求和它们的法定等价物所限定。附图说明

[0009] 图1A、1B和1C说明了依照本主题的某些实施例的、通信设备和一个或多个的无线音频设备间的接口；

[0010] 图2-5提供了依照本主题某些实施例的一些实例；

[0011] 图6示出了依照本主题一实施例的麦克风应用。

[0012] 图7示出了依照本主题一实施例的无线音频控制器。

[0013] 图8和9示出了接口应用的某些实例，以说明依照本主题某些实施例，可能存在本系统的多种通信模式和应用。

[0014] 图10示出了依照本主题一实施例的字节图。

[0015] 图11示出了依照本主题一实施例的系统的各层。

[0016] 图12是依照本主题一实施例的系统的逻辑图。

[0017] 图13-16示出了依照本主题一实施例的系统的各种发送和接收过程。

[0018] 图17示出了依照本主题一实施例的系统的各种请求时序。

[0019] 图18示出了依照本主题一实施例的各种协议的关系。

具体实施方式

[0020] 以下本发明的详细说明涉及附图中的主题，其中附图通过图解说明，示出了可以实施本主题的具体方案和实施例。对这些实施例予以足够详尽的说明，以使所属领域技术人员能够实施本主题。在本公开中，对“一”、“一个”、或“各种”实施例的引用未必指同一实施例，且这些引用考虑到了一个或多个的实施例的情况。以下详细说明是说明性的，因此并不是详尽无遗的，本主题的范围由所附权利要求和它们的法定等价物所限定。

[0021] 图1A示出了用于无线音频设备的通信系统100的一实施例。在一实施例中，系统包括：接口110，提供从通信设备120到第一端口112的通信，以及从第二端口114到无线音频设备130的通信。在各种实施例中，系统100还提供到无线音频设备140的通信。某些这类实施例包括单独的无线接口，用于执行到无线音频设备130和140的通信。其他此类实施例具有结合了至少两个无线接口116和117的第二端口114，如图1B所示。为便于阐述，本公开将示出第二端口114，然而，应理解接口110的不同实施例具有可以包含一个、二个或更多个无线接口的第二端口114。在分组系统中，虚拟接口的有效数量由编码方案规定。在这类设计中，物理第二接口可以使用同一发射机。不同实施例可以使用多个发射机。应了解，接口110的各种实施例包括适于不同通信应用的可编程端口。

[0022] 图1C示出了多条可能的通信路径，每条路径可以是双向或单向的，具体取决于端口110的程序编制。在各种实施例中，端口110和第二接口114可以支持不同的通信模式，包括：到特定设备的通信(以下称为“单播”)、到特定数量设备的通信(以下称为“多播”)和/或到所有此类设备的通信(以下称为“广播”)。

[0023] 一旦获知用户是否具有一对无线音频设备，就可以建立特定的单播、多播和广播模式。例如，在至少一用户具有两个无线音频设备的情况下，用户单播指：或通过该用户的单个音频设备，或者通过该用户的两个无线音频设备，向一个用户发送信息的行为。也可以基于已知的、用户具有哪些设备，执行用户多播和用户广播。

[0024] 各种实施例以适于不同通信应用和通信环境的可编程通信模式为特色。在各种实施例中，接口110是可编程的，以在由接口110所支持的各通信路径上，利用单向和双向通信模式，提供不同的配置。因此，这些通信模式是可调节和高度可编程的。

[0025] 无线

[0026] 在各种实施例中，系统100的第一端口112适于采用无线通信方式。在此类实施例中，可以支持从通信设备120到接口110的一种或多种的无线通信方式。在各种实施例中，无线通信可以包括标准通信或非标准通信。标准无线通信的一些实例包括：链路协议，TM包括但不局限于：Bluetooth ，IEEE 802.11(无线LANs)、802.15(WPANs)、802.16(WiMAX)、
802.20移动无线宽带接入；蜂窝协议，包括但不局限于：CDMA和GSM；Zigbee和超宽带(UWB)技术。这类协议支持射频通信，某些还支持红外通信。还可以采用其他无线通信形式，如超声波通信、光通信及其他。应了解，可采用的标准包括以往的和现有的标准。还应预料到，可以在不背离本主题范围的前提下，采用这些标准的未来版本和全新的未来标准。

[0027] 在各种实施例中，系统100的第二端口114适于采用无线通信方式。可以支持一种或多种的无线通信方式。在一实施例中，支持CSMA通信。在各种实施例中，无线通信可以包括标准或非标准通信。标准无线通信的一些实例包括：链路协议，包括但不局限于：TM
Bluetooth ，IEEE 802.11(无线LANs)、802.15(WPANs)、802.16(WiMAX)、802.20移动无线宽带接入；蜂窝协议，包括但不局限于：CDMA和GSM；Zigbee和超宽带(UWB)技术。这类协议支持射频通信，某些还支持红外通信。还可以采用其他无线通信形式，如超声波通信、光通信及其他。应了解，可采用的标准包括以往的和现有的标准。还应预料到，可以在不背离本主题范围的前提下，采用这些标准的未来版本和全新的未来标准。

[0028] 采用标准通信方式使接口110容易适于与现有的设备和网络一起使用，然而，应了解，在某些实施例中，可以在不背离本主题的前提下，采用非标准通信。

[0029] 有线

[0030] 在各种实施例中，系统100的第一端口112适于连接至通信设备120。此类连接包括但不局限于：多于一个的、采用链路协议的、单声道和立体声连接或数字连接，其中链路协议包括但不局限于：IEEE802.3(以太网)、802.4、802.5、USB、ATM、光纤通道、火线或1394、InfiniBand、或本地流接口。此类连接包括所有以往的或现有的链路协议。还应预料到，可以在不背离本主题范围的前提下，采用这些标准的未来版本和全新的未来标准。

[0031] 采用标准通信方式使接口110容易适于与现有的设备和网络一起使用，然而，应了解，在某些实施例中，可以在不背离本主题的前提下，采用非标准通信。

[0032] 混合

[0033] 在各种实施例中，系统110的第一端口112适于具有一个或多个的无线接口和一个或多个的有线接口。各种实施例提供了可编程的和可选的选项。

[0034] 处理和格式化

[0035] 在各种实施例中，第一端口112适于从通信设备120接收信息，如需要，对收到的信息进行处理或格式化，并向一个或多个的无线音频设备130发送信息。第一端口112从通信设备120接收信息，并将其发送至一个或多个的无线音频设备130和140。无线音频设备130和140利用该信息，向收听者提供音频。在一应用中，从通信设备120接收流音频分组，并将其发送至无线音频设备130和140。在某些实施例中，该流音频是立体声的，听音设备是左右一对独立的无线接收机。接口110可以发送立体声信息，后者由合适的无线音频设备接收，以保持信息的立体声性质。在某些实施例中，无线音频设备130和140间具有通信路径，用于以无线通信方式，向彼此发送各种信息或控制信号。在各种实施例中，接口110所采用的协议将支持无线音频设备130和140间的通信。

[0036] 对用无线音频设备所收发的信息进行格式化，使信息适于放置在节能且与此类设备兼容的协议中。例如，在无线音频设备包括助听器的情况下，此类设备自然限于适合于耳背式或耳内式形状的形状因素。这类尺寸限制是十分重要的，因为它们限制了电池的大小，并因而限制了任何此类设备的可用功率，它们还将天线和通信电子设备的大小限制在麦克风、信号处理和接收机电子装置所不用的空间范围以内。

[0037] 在某些实施例中，接口110和无线音频设备间迅速传送信息的能力允许进行共享处理和存储。因此，这种新型的拓扑可以简化无线音频设备的某些处理和存储要求，并能够通过将系统作为一个整体，增强此类设备的信号处理能力。

[0038] 通信设备选项

[0039] 应了解，在各实施例中，通信设备120可以是多个不同的数据源，还可以经过多条连接。例如，在一实施例中，它包括连接至网络(如因特网)上一内容来源的计算机。在一TM应用中，它包括存储设备，如iPod 或其他流音频设备。在应用中，它包括连至无线音频信源的连接。在一实施例中，它包括连至蓝牙电话的连接。在一实施例中，它包括连至具有蓝牙收发机的计算机的连接。在一实施例中，它包括连至蓝牙MP3播放器的无线连接。在一实施例中，它包括连至装备着蓝牙接口的音频/视频设备。在一应用中，它包括连至具有蓝牙接口的立体声设备的无线连接。在各种实施例中，支持多种无线协议，包括但不局限于，wi-fi、wi-max、ZigBee和UWB。一应用包括有线立体声或单声道连接。应了解，可以支持多种设备和通信方式的结合。在不背离本主题的前提下，可能存在许多应用，且此处提供的应用本意上是说明性，而不是排他性或详尽无遗的。

[0040] 应了解，接口110和通信设备120间传输的数据可以包括，但不局限于以下任意的、所提供的用于说明某些选项、且本意上不是排他或详尽无遗的数据，包括：流音频数据、软件或程序数据、可变或参数数据；生物统计数据、控制信号、安全或加密数据、诊断数据和/或状态数据。

[0041] 接口选项

[0042] 接口110可以具有多个第一端口112，图2至9将说明其中一些端口。图2示出了接口210的实施例，接口210利用通信端口220，从信源(如通信设备120)接收数字信号。信号经数字信号处理器230处理，经收发机240，利用天线250，发送至一个或多个的无线音频设备。在一实施例中，数字信号是无线信号。在一实施例中，数字信号是有线信号。可以用接口210的通信端口220双向收发，单向发送或单向接收数字信号。

[0043] 在接收模式下，天线250接收来自一个或多个的无线音频设备的无线信号，并用收发机240对其进行解调。用数字信号处理器230处理信号，并将任意结果信号发送至通信端口220，以向通信设备120发送。

[0044] 附图示出了在一实施例中为发送和接收所共享的天线250。在不背离本主题范围的前提下，各种实施例可以合并独立的接收和发射部分以及天线。此外，在各种实施例中，天线可位于接口210的底部。在其他实施例中，天线可以位于接口210的外部。可以采用各种类型的天线，包括全向或定向天线。

[0045] 图3说明了一方框图的实例，此方框图示出了图2概括示出的接口实例的更详细的细节。例如，用蓝牙处理器取代通信端口220。DSP 330向收发机340提供经处理的数字信号。图3的剩余部分同阻抗匹配和信号接收与发送的增益控制有关。在不背离本主题范围的前提下，还可能存在其他拓扑和电路设计。

[0046] 在该实例中，蓝牙设备(在该实例中是无线电话)与用于传送音频和数据的接口310进行通信。这说明只有一种可能的无线第一端口设计和可能的通信设备。本说明提供了其它的可替换实施例和未来的可替换实施例。

[0047] 图4说明了模拟无线输入信号的实例，如输入无线接口410的FM信号。在本实例中，FM收发机420用于接收和解调FM信号。DSP 430处理收到的和经解调的信息，收发机440利用天线450，向一个或多个的无线音频设备发送经处理的信息。在各种实施例中，系统还可以利用包含来自一个或多个的无线音频设备的信号的信息，广播FM信号。在不背离本主题范围的前提下，还可能存在其他拓扑和电路设计。

[0048] 图5说明了一有线模拟输入系统，其中来自一个或多个麦克风的信号被输入接口510。模拟一数字转换器520产生信号的数字形式，DSP530对后者加以处理。收发机540适于利用天线550与一个或多个的无线音频设备进行通信。收发机540能按照需要进行单向或双向通信。在不背离本主题范围的前提下，还可能存在其他拓扑和电路设计。

[0049] 图6说明了一如图5所示的系统，其中，麦克风612内建于小型便携设备610，后者具有同无线音频设备614和615进行无线通信的能力。在一实施例中，链路是低功耗的单向语音链路。在各种实施例中，发射频率是不同的。在一使用于美国的实施例中，发射频率大约为915MHz，然而，可以在不背离本主题的前提下使用此处所讨论的其它频率。由于可以将设备612附在扬声器上，以提供更清晰和更清脆的声音，因此设备612为聋人提供了收听扬声器的更好的机会。该设备的输出可以是单播、多播或广播，以向一个或多个的聋人提供更好地收听扬声器的能力。

[0050] 设备610作为无线麦克风，同无线音频设备(如助听器)614和615进行通信，并和具有兼容无线电收发装置的任何其他设备进行通信。在各种实施例中，设备610可以方便地缠在或附在衣服上。可以是隐蔽的。设备610包括麦克风，它可以是全向的或定向的。麦克风可以是可编程的，以在不同条件下更好地接收音频。设备610还包括无线电收发装置，至少支持单向通信，但在各种实施例中，也可以支持双向通信。设备610包括：电源(如电池)、通断开关或软开关和用于进行通信和控制的软件。

[0051] 图7示出了接口110的一实例，它被称为无线音频控制器(WAC)710，能够连接多种通信设备，包括但不局限于：麦克风、蜂窝或蓝牙设备和网络设备。如图7所示，实施例以音量控制器720和麦克风730为可选特征。WAC可用于协助拥有无线音频设备的个人同多个无线和有线设备进行通信，如图8和9所示。即使图8和9示出了具有无线接口的助听器HA1和HA2，应理解，WAC还可以和具有兼容无线接口的其他无线音频设备和具有兼容无线接口的其他无线设备(如，具有兼容无线接口的路由器或存储器)进行通信。

[0052] 图8和图9旨在说明在各种助听器应用中，无线音频控制器710所支持的多种不同的无线和有线通信设备和通信协议。附图示出了频率为915MHz的通信，然而，此频率只依照一实施例，还可以在不背离本主题范围的前提下，采用此处阐述的其它频率。还应了解，可以在不背离本技术方案范围的前提下，采用任一无线协议。

[0053] 助听器应用和协议

[0054] 在某些应用中，无线音频设备130和140是一个或多个的助听器，包括但不局限于：耳背式助听器、耳内式助听器和深耳道式助听器。

[0055] 在使用助听器的一实施例中，设计了一种专门的无线协议，以便于将接口110收到信息(可能用有线或无线的第一端口112的实施例接收)以无线通信方式、按分组格式发送至助听器。此无线协议设计用来以所选中的、与其他通信类型兼容的频率，为低功耗系统提供高速通信链路。

[0056] 在各种实施例中，路径1、路径2和路径3是双向通信路径。在不背离本主题范围的前提下，存在其他实施例。例如，通信路径的方向性可以根据应用和通信方向的需要而变化。

[0057] 在各种实施例中，为无线通信协议提供额外支持，使一无线音频设备和另一无线音频设备之间可以通信(如路径4)。

[0058] 在各种实施例中，无线协议还支持到一个或多个额外的无线音频设备的通信，例如，在图1C中，助听器使用者通过路径N和N+1同接口110进行通信。在一实施例中，采用CSMA传输方法予以实现。这种系统可以是可编程的，以支持单播、多播、广播，并与特定的无线音频设备和/或特定的、一对此类设备的使用者进行通信。

[0059] 助听设备的特殊功能

[0060] 考虑到所阐述系统的灵活性，应明白，助听器的应用可以支持多种智能数字信号处理功能，包括但不局限于双耳表示。双耳表示的一些实例包括，但不局限于，Bren等人的美国专利申请号2003/0215106、Bren等人的美国专利申请号2004/0052391，特此将两者全部合并于此以做参考。

[0061] 还有可用于感应电圈工作的、先进的声音处理操作，包括但不局限于，Bren等人的美国专利号6,760,457，Bren等人的美国专利号6,633,645，Bren等人的美国专利申请号2004/0052391和Bren等人的美国专利申请号2003/0059073中所提供的内容，所有上述内容都将全部合并于此以做参考。

[0062] 此类系统可以支持语音通信、语音识别和其他智能声音处理。语音检测的一实例包括，但不局限于Victorian等人的欧洲专利申请1519625所提供的技术方案，特此将后者全部合并于此以做参考。

[0063] 助听器应用的无线协议的一个实例

[0064] 本主题包括各种无线通信协议。在各种实施例中，无线协议为在无线音频设备(如，助听器和助听器辅助设备)间交换信息提供规范。在各种实施例中，通信发生在射频通信信道上。以下无线通信协议的实例为助听器和一个或多个的助听器辅助设备间的、射频通信信道上的信息交换提供了规范，同时该协议适于规定共享传输信道访问。

[0065] 将要说明的是这种无线通信协议的方法。可以在不背离本主题范围的前提下，对比特顺序、比特数、用途、内容、过程的顺序、检错过程、和所阐述的过程加以改动。相信所属领域技术人员一旦阅读并理解了本文档，就能理解未背离此处所提供的技术方案的变体。因此，以下的无线通信协议只意图说明一实施例，而不是详尽无遗的或排除本方案所提供方法以外的其他方法的。

[0066] 示例无线通信协议以分组或帧格式形式传送信息。在帧的起点，用起始标记对帧进行定界。帧起始标记前是用于建立符号同步的前导。表1示出了一般的帧格式。

[0067]

[0068] 表格1

[0069] 示例无线通信协议包括协议分层。在各种实施例中，利用协议分层有助于模块化协议实现。在各种实施例中，协议层将通信协议分成更小的、更简单的成分，同时隐藏实际实现的细节(也称为抽象)。通过采用分层协议实现的一个目的是减小各层的相互依赖。一个额外的好处是减小了抽象的副作用。因此，在改变协议实现时，协议分层使得对于其他协议层的调整降低至最小限度。

[0070] 表2示出了用于说明本示例无线通信协议协议数据格式的记号。

[0071]

[0072] 表格2

[0073] 用附图(图)部分阐释本无线通信实例。这些附图按字段的发送顺序，示出了字段的格式，先发送最左边的比特。

[0074] 图10示出了如16和32位比特值的多字节值，这些值按重要性逐渐下降的顺序，按从值的最高有效字节(MSB)1002到值的最低有效字节(LSB)1004的顺序排列。协议的个人用户可以解析多字节数据。MSB数据被置于数据流的开头，LSB数据被置于数据流的结尾1006。

[0075] 本无线通信协议实例包括按重要性逐渐下降的顺序排列的比特数据。字节按表3说明的顺序排列，首先发送最高有效位(MSB)比特7，最后发送最低有效位(LSB)比特0。

[0076]

[0077] 表格3

[0078] 在各种实施例中，一旦字段或含有最左边比特的比特被认为是最重要的，要求比较字段或比特的过程就执行比较功能。

[0079] 网络结构

[0080] 本无线通信协议的实例包括具有节点的网络结构。该网络包括任意数量的节点。网络上的每个节点都标以唯一的地址，以实现两节点间的专用通信。使用协议的供应商决定该如果规划其唯一地址。地址可以是序列号的派生物，序列号在接通组件电源的初始化期间创建，也可以在生产过程中被配置于组件中。在所提供的实例中，由于在任意给定时刻，每个信道中只有一节点可以发送，因此无线链路上的传输是半双工的。在彼此的范围内，多节点同时发送可能会导致数据出错。

[0081] 本无线通信协议的实例包括节点寻址。地址用于在全世界范围内唯一标识特定节点。网络中的每个节点都应具有唯一的标识符，以使通信不存在任何混淆通信分组预期目的地的可能。地址包括两部分。供应商id，定义分组预期发送至的供应商、供应商组织或所有供应商。设备id在供应商id范围内唯一标识某一设备。如下是节点寻址的一实例：<地址(25比特)>＝<供应商ID(3比特)>+<设备ID(22比特)>。因此，本系统支持对每个具有协议兼容接收机的设备进行独立寻址。这提供了对传输模式的控制，使传输可以是单播、多播或广播传输。

[0082] 本无线通信协议的实例包括供应商ID。供应商ID是3位比特值，指示特定的供应商，供应商联盟或所有供应商。表4示出了所定义的值。

[0083]

[0084] 表格4

[0085] 可以将保留供应商ID定义为代表多个供应商，从而实现向特定供应商组织广播的能力。

[0086] 本无线通信协议的实例包括设备ID。设备ID是供应商所定义的22位比特值。获得和特定供应商ID相关的设备ID的方法由各供应商的指定。各供应商负责为该供应商所支持的任意或全部无线设备(即，助听器、遥控器、程序设计装置)分配和维护适当的地址范围。此外，各供应商还负责为供应商内部的广播/多播分配和维护适当的地址范围。

[0087]

[0088] 表格5

[0089] 对与广播/多播供应商ID有关的设备ID具有如下限制：设备ID0x3FFFFF被保留为供应商间的广播地址；设备ID范围0x000000至0x3FFFFE被保留为动态的供应商间多播地址。

[0090] 本无线通信协议的实例包括各种寻址类型。支持三种寻址类型：单播、多播和广播。单播寻址只允许两个节点进行通信。多播寻址允许一节点向选中的一组节点发送，如程控设备向左右助听器同时发送信息。在某些实施例中，多播寻址不使用分组确认。广播寻址允许一节点向所有节点发送，例如程控设备发现其范围内的所有节点。在某些实施例中，广播寻址不使用分组确认。

[0091] 单播寻址使用一发射机和一接收机。实例包括，程序设计装置与单独的助听器或两个彼此通信的助听器进行通信。

[0092] 多播寻址使用单个发射机和多个接收机。由于控制数据流的应用指定地址值及其使用，因此多播地址针对于特定应用的。实例可以是程序设计装置同时与两个助听器进行通信。

[0093] 广播寻址使用单个发射机和多个接收机，后者采用预先定义的广播地址。这组接收机可以包括：针对一供应商、多个供应商或所有供应商的接收机。实例可以是，在礼堂环境中，向发射机范围内所有助听器传送音频。

[0094] 协议栈

[0095] 图11示出了本示例协议，它包括一组分层协议1102，其中各层执行一组逻辑上相关的通信任务，同时隐藏或抽象了协议层实现的细节。分层的基本原则是使各层独立。为实现这个目的，定义各层向临近高层提供的服务，但不定义如何实现这些服务。这使得可以改变某层而不影响其他层，并使整个通信系统的模块化实现成为可能。

[0096] 各协议层提供服务和发送和/或接收数据的方法。待利用协议发送数据被称为服务数据单元(SDU)，或有效载荷。链路协议将SDU和协议控制信息加以封装，以形成协议数据单元(PDU)，后者也被称为帧或数据分组。本文档的主要焦点在于如图11所示的物理和数据链路层1104。

[0097] 物理层协议1106工作在层1，功能上等效于OSI模型1102的物理层1108。该协议层定义了控制和监视收发机工作的方法。该协议层提供RF信道上的数据串行化，并参与单个比特的传送。为了确保接收机正常工作，产生接收机PLL时钟，可对分组数据进行编码，以确保必要的上升和下降沿密度。

[0098] 系统的RF载频可以改变。系统能工作在任意数量的可用频率上，然而，法律规制限制了在任意国家中的可用频带。由于这些频带随时间变化，且由于本技术方案可工作于任意的多个频带，因此本说明并不局限于此处阐述的频带。例如，在提交本申请时，认为在美国可用频率包括，但不局限于，约795MHz至965MHz。在另一实例中，频率范围约为902MHz至908MHz。在另一实例中，采用约915MHz的中心频率。所用频率取决于设备用户所在国家的地方性法规。一般而言，在许多国家可以使用约700MHz以上的频率。还可以在不背离本主题范围的前提下使用其他频率。

[0099] 更多的国家具有条例，这些条例太多以致无法全部包含于此。例如，在加拿大，认为一可用的频率范围约为902MHz至928MHz。另一实例为，在欧洲可以使用约863MHz至865MHz的频率范围。另一实例为，在日本可以使用约806MHz至810MHz的频率范围。另一实例为，在澳大利亚可以使用约918MHz至926MHz的频率范围。另一实例为，在中国可以使用约702MHz至798MHz的频率范围。另一实例为，在台湾可以使用的范围包括约960MHz以上的频率。另一实例为，在韩国可以使用约928MHz至930MHz或约950MHz至952MHz的频率范围。另一实例为，在哥伦比亚可以使用约902MHz至924MHz的频率范围。另一实例为，在巴西可以使用约902MHz至907.5MHz或915MHz至928MHz的频率范围。另一实例为，在墨西哥可以使用约902MHz至928MHz的频率范围。另一实例为，在香港可以使用约
819.1MHz至823.1MHz或约919.5MHz至920MHz的频率范围。另一实例为，在新加坡可以使用约866.6MHz至869MHz或约924MHz至925MHz的范围。另一实例为，在南非可以使用约
863MHz至865MHz的频率范围。另一实例为，在泰国可以使用约903MHz至960MHz的频率范围。另一实例为，在菲律宾可以使用约902MHz至928MHz或约900MHz至915MHz的频率范围。另一实例为，在保加利亚可以使用约863MHz至865MHz的频率范围。再次强调，应注意此处所提供的频率范围并不是系统的技术操作提出的要求，而是为了遵守地方法律。因此，可以在不背离本主题范围的前提下改变频率。

[0100] 一组6个频率间隔为606kHz的物理信道以选中的频率为中心。一组之中的物理信道应被看作逻辑信道1-6，逻辑信道1与频率最低的物理信道相关联，信道6与频率最高的物理信道相关联。

[0101] 所用的调制类型是高斯连续相位2FSK，ITU命名为150KF1DCN，由Bt＝.5的2-GFSK产生。用+/-46.545KHz频偏对VCO进行频率调制。

[0102] 基本RF信道数据比特速率定义为186182比特每秒。

[0103] 该协议采用白化算法作为无线信道上数据比特的编码方法。白化器基于以下多项11 2
式：G(D)＝D +D+1。该算法使用一组包含示例值1202的值，并根据多项式1204对它们进行合并。结果被施加1208于输入数据，生成数据输出1206。该算法的初始种子值是0x7FE。
该算法要求在发送每个分组之前，更新初始种子值。图12示出了多项式的一LFSR结构。

[0104] 本示例协议包括前导。前导是可变长的、交替10次的序列，发送于帧起始标记字之前。它使接收站能够设置其接收机增益，恢复发射载波频率，并为输入分组数据调整其符号时钟。前导具有以下的非编码格式：

[0105] <非编码前导>＝11001100b+11001100b+11001100b+11001100b+11001100b+11001100b+11001100b+11001100b+11001100b+11001100b

[0106] 本实例协议包括帧起始标记。该40比特的标记指示新帧的起点，并使接收设备同输入数据建立单元/字节的相位同步。起始标记字是0xB14D8F299A。

[0107] 本实例协议包括数据链路层。数据链路层工作于层2，包括负责媒体接入控制(MAC)和逻辑链路控制(LLC)的两个子层。

[0108] 本示例协议包括协议数据单元。表6示出数据链路层的PDU格式。

[0109]

[0110] 表格6

[0111] 表7示出了各协议数据单元字段的大小和简要说明。

[0112]

[0113] 表格7

[0114] 本示例实施例包括帧大小。帧大小是一个10比特的值，指示从帧头帧校验序列之后到有效载荷(SDU)末尾的字节数。其有效范围取决于报文的帧类型。

[0115] 本示例实施例包括帧描述符。8比特的帧描述符定义了帧格式，并被划分成表8中所说明的位域。

[0116]

[0117] 表格8

[0118] 本示例实施例包括协议标识符。协议标识符，比特0-2，指示特定分组被送达的协议层。表9和以下文本说明了规定的协议。

[0119]

[0120] 表格9

[0121] 000b-确认表示这是一个链路层确认分组，该分组的发送是由于在收到的帧描述符中设置了某些比特的结果。

[0122] 001b-媒体接入协议是用来指定逻辑链路控制操作(如信道预留)的信息。

[0123] 010b-助听器控制协议是用来指定助听器控制操作(如调整应用)的信息。

[0124] 011b-双向语音协议是包含双向音频数据、并用来指定音频应用的信息。

[0125] 100b-单向流音频协议是包含音频数据、并用来指定音频应用的信息。

[0126] 101b-保留。

[0127] 110b-保留。

[0128] 111b-此二进制码用来表示，为了将分组送达至协议层，将额外的扩展协议字节包含为帧格式的一部分。

[0129] 本示例协议包括有效载荷FCS模式。在FCS下，比特3-4用来定义用于在帧内进行差错控制的载荷帧校验序列的字节数。用从帧头FCS之后的第一个字节到载荷(SDU)末尾的全部数据计算有效载荷FCS。表10说明了规定的FCS模式。

[0130]

[0131] 表格10

[0132] 有效载荷FCS模式01b和10b采用如此处所列的检错方法检查错误。此处列出了各种检错方法。

[0133] 本示例协议包括Ack标记。Ack标记，比特5，用于指示链路层协议是否应对该帧予以确认。如果Ack标记位是0，将不对该帧予以确认。如果Ack标记位是1，且如果FCS校验成功，该帧不是确认，该帧不包含广播或多播地址，就对该帧予以确认。

[0134] 本示例协议包括嵌入数据。嵌入数据，比特6，用于指示嵌入信道字段中的数据是否有效。如果嵌入数据位是1，嵌入信道字段中的数据就是有效的。如果嵌入数据位是0，嵌入信道字段中的数据就是无效的。在此处提供的示例协议中，该字段仅对于双向语音(BDV)或单向流音频(OSA)协议类型分组有效。

[0135] 本示例协议包括版本。版本，比特7，指示收到的帧格式的版本。对于该比特，值0表示帧格式的第一版。对于该比特，保留值1用于表示今后对帧格式所作的任何修改。

[0136] 本示例协议包括目的地址。目的节点地址可以是单播、多播或广播地址中的任何一种类型。此外，本示例协议包括源地址。源节点地址不应是多播或广播地址。另外，本示例协议包括嵌入信道。嵌入信道在节点间提供低速通信信道。该字段只对双向语音(BDV)或单向流音频(OSA)协议类型分组有效。

[0137] 本示例协议包括序列号。此字段用于要求链路层确认的媒体接入(MA)、助听器控制(HAC)或扩展(EX)协议类型单播分组。发送链路层确认(Ack)分组，以响应收到的报文，应将链路层确认(Ack)分组的序列号(SEQN)字段设置成与收到报文中的SEQN字段相同。对任意协议类型的广播或多播分组，应将SEQN字段设置成0。

[0138] 独立节点应为与其交换需要链路层确认的，MA、HAC或EX协议类型的单播分组的各节点，维持单独的内部发送和接收序列号。对于发送节点，在发送需要链路层确认的第一个MA、HAC或EX协议类型的单播分组时，建立发送和接收序列号。对于接收节点，一旦有效接收到需要链路层确认的第一个MA、HAC或EX协议类型的单播分组，就建立发送和接收序列号。源节点和目的节点上各字段的初始值都是0。

[0139] 本示例协议使用发送序列号。就图13的发送算法而言，在源节点上，每个新发送的、需要链路层确认的，MA、HAC或EX协议类型的单播分组使发送1302序列号(TX_SEQN)递增1304、1306、1308。当序列号到达最大值时，就转回到最小值。接着，在源节点上，将TX_SEQN放入所发送(1310)分组的序列号字段(SEQN)。随后，接收1312分组。在重传分组的情况下，在源节点上TX_SEQN不变，且重传该分组时使用和源分组相同的TX_SEQN。

[0140] 本示例协议使用接收序列号。就图14的接收算法而言，在目的节点处收到1402接收序列号(RX_SEQN)。在目的节点处，一旦有效接收到需要链路层确认的，MA、HAC或EX协议类型的单播分组，就用RX_SEQN进行分组过滤1404、1406、1408、1410、1412、1416。应将所接收的分组中的序列号值(SEQN)与目的接收序列号(RX_SEQN)进行比较。如果它们不同，则表明收到了新的数据有效载荷，并将RX_SEQN设置为SEQN的值；否则，就说明收到的是相同的数据有效载荷，并予以丢弃1416。任一情况都结束于发送1414、1418。

[0141] 本示例协议包括启用有效载荷FEC。启用有效载荷FEC位指示是否对报文的有效载荷进行了Reed Solomon编码。如果启用有效载荷FEC位为0，就说明尚未对报文的有效载荷进行Reed Solomon编码。如果启用有效载荷FEC位为1，就说明已对报文的有效载荷进行了Reed Solomon编码。

[0142] 本示例协议包括帧头帧校验序列。帧头帧校验序列为每个收到的帧提供了一种误码检测方式。此字段的大小是两字节。FCS包含在发送前所计算的循环冗余校验(CRC)值。16比特的FCS基于CRC-CCITT定义。从帧起始标记之后到序列号字段末尾的所有数据都参与CRC的计算。

[0143] 在各种实施例中，在源节点处编码之前和目的节点处译码之后，完成CRC计算。此外，可以对节点加以配置，使得当帧头帧校验序列在帧头中检测到错误比特时，节点或忽略分组、或对分组进行处理。如果收到分组，且通过帧校验序列检测到帧头中有错误比特，节点又被配置为忽略这些分组，那么帧将不被送达至下层协议，也不会产生可能需要的链路层确认分组。

[0144] 本示例协议包括扩展协议。只有当帧描述符字节中的帧类型比特被设置为111b时，才存在扩展协议字节。扩展协议字节应是一个有效网络服务的标识符，后者用于将收到的分组送达至适当的协议层。此处包含各种应用和网络服务标识符。

[0145] 本示例协议包括有效载荷。有效载荷字段包含针对于特定应用的信息。本示例协议还包括有效载荷帧校验序列。有效载荷帧校验序列为每个收到的帧提供一种误码检测方式。FCS包含在发送前计算的循环冗余校验(CRC)值。32比特的FCS基于CRC-32定义。从帧头帧校验序列之后到有效载荷字段末尾的所有数据都参与CRC计算。如果检测到错误，那么帧将不被送达至下层协议，也不会产生链路层确认分组。在各种实施例中，在源节点处编码之前和目的节点处译码之后，完成CRC计算。

[0146] 本示例协议包括媒体接入控制(MAC)子层。媒体接入控制(MAC)子层负责通过共享信道，向节点发送分组或从节点接收数据分组。MAC子层使用节点传输协议和节点唤醒协议，以确保通过信道发送自不同站点的分组不发生冲突，并被正确接收。此外，MAC子层还负责接收来自信道的分组。在一应用中，要求节点节能，因此节点不总是可用来接收分组。因而，MAC子层使用节点监控和节点休眠协议协调分组的接收。

[0147] 本示例协议包括节点传输。由于本无线通信协议采用单工操作，因此节点不能在检测信道的同时进行发送，这意味着节点不能执行碰撞检测。因此，如果两节点同时发送，这两个发送就会产生干扰(至少干扰两发送节点范围以内的节点)。为了将冲突减至最低程度，并最大化数据吞吐量，共享媒体需要采用载波侦听多路访问(CSMA)协议。CSMA表示“先听后说”的策略，其中，想要发送的节点在发送前，先对媒体进行探测，判断是否另一节点正在发送。采用本主题的协议的一个应用包括多种CSMA协议的定义。不同的CSMA协议使不同设备能够在存在干扰的情况下进行通信。

[0148] 本主题的一应用包括两种不同类型的设备：助听器；和助听器辅助设备。在各种实施例中，助听器或自动发送分组，或在尝试发送分组时，执行CSMA协议。所发送分组的协议标识符是判断分组是自动发送，还是执行了CSMA协议的关键。对于双向语音和单向流音频协议标识符，助听器将自动发送分组。对于所有其他协议标识符，助听器将在发送分组时执行CSMA协议。CSMA协议设计用于在有干扰存在的情况下，为由助听器发送的分组提供成功传送的最佳时机。然而，在采用CSMA协议的各种实施例中，多个助听器可能同时尝试发送，并导致冲突。这种情况的解决方法是，让助听器使用随机自动重传请求(ARQ)算法，此算法为随后的重传尝试提供了冲突避免技术。

[0149] 助听器辅助设备或自动发送分组，或在尝试发送分组时执行CSMA/CA协议。所发送分组的协议标识符用于判断分组是自动发送的，还是执行了CSMA/CA协议。对于双向语音和单向流音频协议标识符，助听器自动发送分组。对于所有其他协议标识符，助听器在发送分组时执行CSMA协议。CSMA/CA协议设计用于协助助听器执行CSMA协议。然而，使用CSMA/CA协议，仍存在分组发生冲突的可能。这种情况的解决方法是，让助听器辅助设备对随后的重传尝试采用静态自动重传请求(ARQ)算法。

[0150] 本示例协议包括载波侦听多路访问(CSMA)协议。图15说明了按照此算法的、帧发送尝试。在各种实施例中，算法起始于传输请求1502。该方法还包括信道空闲查询1504。如果信道空闲，算法就发送分组1506，并结束1514。

[0151] 如果信道不为空闲，方法就继续嗅探，直至信道空闲或发生超时1508。接着，方法检测到信道空闲或超时1510。如果信道空闲，就发送分组1506。如果信道不为空闲，就发生了嗅探超时，过程放弃发送分组1512。接着，过程结束1514。表11列出了嗅探超时的实例。

[0152] 该方法是本主题的一实施例。本主题还包括省略某些步骤的执行顺序。本主题还包括与本实例相比顺序变化了的执行顺序。

[0153] 应注意，实现该算法的各节点提供了启用和仅用此算法的功能。默认/初始状态是启用算法。

[0154]

[0155] 表格11

[0156] 可用于传输的分组的异步性质、节点的物理位置和/或信号强度可能导致两个节点同时发送，并在接收机处使分组遭到破坏。这种情况可通过节点所采用的任意的自动重传请求算法加以解决。

[0157] 本示例协议包括如图16所示的载波侦听多路访问/冲突避免(CSMA/CA)。表12说明了该算法的示例参数。用于助听器辅助设备的、基本CSMA算法上的CA扩展，引入了退避程序。检测到媒体繁忙的站点将推迟发送，直至媒体空闲为止。由于可能有多个站点在等待接入，因此极有可能在媒体刚变为空闲后产生冲突。为了减少在此期间的冲突，节点应产生一随机退避时间。

[0158] 在各种实施例中，方法起始于传输请求1602。方法执行信道空闲查询1604。如果回答是肯定的，方法就执行分组传输1612，接着终止1616。如果回答是否定的，就查询是否已超过CSMA计数器的最大值1606。倘若如此，过程就放弃分组传输。如果不是，过程就执行嗅探，直到信道空闲为止。该过程以两种方式之一终止：1)嗅探超时，放弃分组传输1614，接着过程终止1616；2)空闲信道，访问某事件的随机定时器1608，然后返回至信道空闲查询1604。

[0159] 实施此算法的各节点应提供启用和禁用该算法的功能。默认/初始状态是启用算法。

[0160]

[0161] 表格12

[0162] 本示例协议包括各种算法。图17示出了使用三个节点的算法。该图解说明了，依照本主题的算法，节点A1702、节点B1704和节点C1706随时间1708做出的时序调整。节点的物理位置和/或信号强度可能导致发射节点并非对于所有节点均可见。这可能导致两个节点同时发送，并在接收机处使分组遭到破坏。这种情况可通过节点所采用的任意的自动重传请求算法加以解决。

[0163] 本示例协议包括节点唤醒功能。具有输出分组的节点使用节点唤醒功能，以确保将一个或多个的目的节点唤醒，使其准备好接收分组。可能需要发送节点在发送分组之前先发送唤醒序列。唤醒序列包括连续发送TR毫秒的前导。表13对该变量进行了说明。只有当发送节点尚未与在通过编程指定的距离范围内的目的节点存在任何通信时，才需要唤醒序列。本主题包括规定了时间间隔的节点休眠功能。如果节点已存在通信，发送节点就在发送分组前发送普通的前导。

[0164]

[0165] 表格13

[0166] 本示例协议包括节点监控功能。此功能使用表14所说明的变量。为了使节点接收分组，将需要周期性地唤醒和监控信道。需要每TR毫秒周期性地唤醒接收节点。然后，在信道上执行Tdwell毫秒的初始监控，查看信道活动，以判断是否有节点正在尝试发送。如果在初始监控期间未检测到信道活动，节点就将返回休眠状态，直到下一个TR-Tdwell毫秒的周期唤醒时间。如果在初始监视期间，检测到信道活动，节点就应继续监控信道TR毫秒。如果节点在扩展监控期间收到分组，就应执行文中所描述的过程。本示例协议包括节点休眠。如果节点未在扩展监控期间收到分组，就在扩展监控时间间隔的终点，执行了Tdwell毫秒的查看信道活动的初始监控后，启动此过程。

[0167]

[0168] 表格14

[0169] 本示例协议包括节点休眠功能。表15说明了此功能的参数。在成功收到分组，并在必要情况下发送了确认之后，节点应保持清醒，以利于接收后继分组。要求节点保持清醒，并在8*TR毫秒时间内查看是否存在额外的分组。如果在此时间间隔期间，收到后继分组，就需要重置保持清醒的时间。

[0170]

[0171] 表格15

[0172] 本示例协议包括逻辑链路控制子层。数据链路层的逻辑链路控制子层负责管理网络中一条链路上的设备间的通信。该子层允许多个更高层的协议共享一条物理数据链路。该子层只支持更高层的协议所使用的无连接服务。

[0173] 本示例协议包括静态自动重传请求(ARQ)。表16列出了有关参数。数据链路层依靠检错和重传确保成功发送每个分组。对于需要链路层确认的分组，应在“Ack等待定时器”计时期间接收链路层确认分组。否则，就重发原分组。分组重发的最大次数受“最大重传次数”限制。

[0174] 分组需要链路层确认，这可能导致报文的重传；由于确认失败而发生重传。要求在目的节点处对重传加以过滤，以免目的节点对同一报文进行多次处理。如此处所讨论的，分组中的序列号(SEQN)字段使目的节点可以丢弃任何未被正确接收的重传。

[0175]

[0176] 表格16

[0177] 本示例协议包括随机自动重传请求(ARQ)。表17列出了有关参数。数据链路层依靠检错和重传确保成功发送每个分组。对于需要链路层确认的分组，应在“Ack等待定时器”计时期间接收链路层确认分组。否则，就重发原分组。分组重发的最大次数受“最大重传次数”限制。

[0178] 分组需要链路层确认，这可能导致报文的重传；由于确认失败而发生重传。要求在目的节点对重传加以过滤，以免目的节点对同一报文进行多次处理。如此处所讨论的，分组中的序列号(SEQN)字段使目的节点可以丢弃任何未被正确接收的重传。

[0179]

[0180] 表格17

[0181] 本示例协议包括逻辑信道。一组6个物理信道以选中的信道组为中心。信道组中的各物理信道可以被看作逻辑信道，逻辑信道1与频率最低的物理信道相关联，而信道6与频率最高的物理信道相关联。保留每组中的逻辑信道3，用作控制信道和用于传输少量数据。需要专用控制信道，以缩短在全部逻辑信道上监控、调谐和发现潜在通信设备所需的时间。由于逻辑信道3位于信道组的中心，因此使用它，利用其中心位置，更快地调谐至任意其他信道。

[0182] 信道3用于交换程序设计数据、耳到耳信息，也可交换报文，后者指示节点调谐至不同的逻辑信道，以交换双向的语音数据或单向的流音频数据。由于与助听器相比，助听器辅助设备具有更高的接收机灵敏度，因此各种应用不执行真正的信道协商过程。在一应用中，助听器辅助设备确定最佳信道。然后向助听器发送该信道，助听器只对选中信道简单地加以确认。

[0183] 本示例协议包括监控信道可用性的方法和装置。表18列出了有关参数。通过在固定的时间间隔内监控信道，判断信道的可用性。如果在监控时间间隔期间的任一时刻检测到活动，就认为信道处于使用状态。如果在监控时间间隔期间未检测到活动，就认为信道空闲。监视时间间隔的持续时间应足够长，以确保能用任何更高层的协议检测到信道处于使用状态，并检测到任意已知干扰。在一应用中，已将此时间间隔规定为Tmon毫秒。

[0184]

[0185] 表格18

[0186] 在一应用中，助听器辅助设备是执行判断信道可用性过程的唯一节点。这是由于与助听器接收机相比，助听器辅助设备接收机对信道活动更加敏感。

[0187] 本示例协议包括媒体接入协议。媒体接入协议用于协商信道组内可用于交换额外数据的可用逻辑信道。表19列出了媒体接入协议所支持的请求/响应。

[0188]

[0189] 表格19

[0190] 本示例协议包括单向流起始会话请求/响应。表20是单向流起始会话请求PDU的格式。

[0191]

[0192] 表格20

[0193] 大小＝0x0C，有效载荷中的字节数

[0194] 帧描述符-

[0195] 比特7-版本＝0b

[0196] 比特6-嵌入数据＝0b

[0197] 比特5-Ack标记＝0b，无确认

[0198] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0199] 比特2-0-帧类型＝001b，媒体接入协议

[0200] 地址-

[0201] 目的供应商＝001b，组织1

[0202] 目的设备ID＝0x112233，供应商特有的值

[0203] 源供应商＝001b，组织1

[0204] 源设备ID＝0x123456，供应商特有的值

[0205] 序列号-00b

[0206] 启用载荷FEC-1b

[0207] 帧头帧校验序列-0xXXXX(16比特CRC)

[0208] 有效载荷-见表21

[0209] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0210] 表21提供了“有效载荷”字段的详细格式：

[0211]

[0212] 表格21

[0213] 请求操作码-0x03，单向流起始会话请求

[0214] 信道-0x04，信道标识符

[0215] 编码译码器ID-0x02，定义用于对音频流进行编码的编译码器。编码译码器标识符的完整列表请参考表58。

[0216] 编码译码器Fs-0x05，定义用于对音频流进行编码的采样率。采样率的完整列表请参考表60。

[0217] 比特率-0x08，定义每采样的比特数。比特率的完整列表请参考表59。

[0218] 采样数/分组-0x0205，定义每传输分组中所发送的采样数。

[0219] 多播地址-0x01300001供应商ID＝001b设备ID＝0x300001(供应商特有的值)

[0220] 选项-00000000b，单向流选项的说明请参见表22。

[0221] 选项字段是标识与音频数据流相关的配置选项的位域。图22示出了这些选项。

[0222]

[0223]

[0224] 表格22

[0225] 表23是接受或拒绝响应PDU的格式。

[0226] 表格23

[0227] 大小＝0x01，有效载荷中的字节数

[0228] 帧描述符-

[0229] 比特7-版本＝0b

[0230] 比特6-嵌入数据＝0b

[0231] 比特5-Ack标记＝0b，无确认

[0232] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0233] 比特2-0-帧类型＝001b，媒体接入协议

[0234] 地址-

[0235] 目的供应商＝001b，组织1

[0236] 目的设备ID＝0x123456，供应商特有的值

[0237] 源供应商＝001b，组织1

[0238] 源设备ID＝0x112233，供应商特有的值

[0239] 序列号-00b

[0240] 启用载荷FEC-1b

[0241] 帧头帧校验序列-0xXXXX(16比特CRC)

[0242] 响应操作码-0x01，接受响应或0x02拒绝响应

[0243] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0244] 本示例协议包括单向停止会话请求/响应。表24是单向流停止会话请求PDU的格式。

[0245]

[0246] 表格24

[0247] 大小＝0x01，有效载荷中的字节数

[0248] 帧描述符-

[0249] 比特7-版本＝0b

[0250] 比特6-嵌入数据＝0b

[0251] 比特5-Ack标记＝0b，无确认

[0252] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0253] 比特2-0-帧类型＝001b，媒体接入协议

[0254] 地址-

[0255] 目的供应商＝001b，组织1

[0256] 目的设备ID＝0x123456，供应商特有的值

[0257] 源供应商＝001b，组织1

[0258] 源设备ID＝0x112233，供应商特有的值

[0259] 序列号-00b

[0260] 启用有效载荷FEC-1b

[0261] 帧头帧校验序列-0xXXXX(16比特CRC)

[0262] 响应操作码-0x04，单向流停止会话请求

[0263] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0264] 表25是接受或拒绝响应PDU的格式。

[0265]

[0266] 表格25

[0267] 大小＝0x01，有效载荷中的字节数

[0268] 帧描述符-

[0269] 比特7-版本＝0b

[0270] 比特6-嵌入数据＝0b

[0271] 比特5-Ack标记＝0b，无确认

[0272] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0273] 比特2-0-帧类型＝001b，媒体接入协议

[0274] 地址-

[0275] 目的供应商＝001b，组织1

[0276] 目的设备ID＝0x123456，供应商特有的值

[0277] 源供应商＝001b，组织1

[0278] 源设备ID＝0x112233，供应商特有的值

[0279] 序列号-00b

[0280] 启用有效载荷FEC-1b

[0281] 帧头帧校验序列-0xXXXX(16比特CRC)

[0282] 响应操作码-0x01，接受响应或0x02拒绝响应

[0283] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0284] 本示例协议包括双向流起始会话请求/响应。表26是双向流起始会话请求PDU的格式。

[0285]

[0286] 表格26

[0287] 大小＝0x0C，有效载荷中的字节数

[0288] 帧描述符-

[0289] 比特7-版本＝0b

[0290] 比特6-嵌入数据＝0b

[0291] 比特5-Ack标记＝0b，无确认

[0292] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0293] 比特2-0-帧类型＝001b，媒体接入协议

[0294] 地址-

[0295] 目的供应商＝001b，组织1

[0296] 目的设备ID＝0x112233，供应商特有的值

[0297] 源供应商＝001b，组织1

[0298] 源设备ID＝0x123456，供应商特有的值

[0299] 序列号-00b

[0300] 启用有效载荷FEC-1b

[0301] 帧头帧校验序列-0xXXXX(16比特CRC)

[0302] 有效载荷-见表27

[0303] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0304] 表27提供了“有效载荷”字段的详细格式：

[0305]

[0306] 表格27

[0307] 请求操作码-0x05，双向流起始请求

[0308] 信道-0x05，信道标识符

[0309] 编码译码器ID-0x01，定义用于对音频流进行编码的

[0310] 编译码器。编码译码器标识符的完整列表请参考表58。

[0311] 编码译码器Fs-0x11，定义用于对音频流进行编码的

[0312] 采样率。采样率的完整列表请参考表60。

[0313] 比特率-0x01，定义每采样的比特数。比特率的完整

[0314] 列表请参考表59。

[0315] 采样数/分组-0x0080，定义每传输分组中所发送的采样数。

[0316] 多播地址-0x01300001供应商ID＝001b设备ID＝0x300001(供应商特有的值)

[0317] 选项-00000100b，双向流选项的说明请参见表28。

[0318] 选项字段是标识与音频数据流有关的配置选项的位域。图28示出了这些选项。

[0319]

[0320] 表格28

[0321] 表29是接受或拒绝响应PDU的格式。

[0322]

[0323] 表格29

[0324] 大小＝0x01，有效载荷中的字节数

[0325] 帧描述符-

[0326] 比特7-版本＝0b

[0327] 比特6-嵌入数据＝0b

[0328] 比特5-Ack标记＝0b，无确认

[0329] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0330] 比特2-0-帧类型＝001b，媒体接入协议

[0331] 地址-

[0332] 目的供应商＝001b，组织1

[0333] 目的设备ID＝0x123456，供应商特有的值

[0334] 源供应商＝001b，组织1

[0335] 源设备ID＝0x112233，供应商特有的值

[0336] 序列号-00b

[0337] 启用有效载荷FEC-1b

[0338] 帧头帧校验序列-0xXXXX(16比特CRC)

[0339] 响应操作码-0x01，接受响应或0x02拒绝响应

[0340] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0341] 本示例协议包括双向流停止会话请求/响应。表30是双向流停止会话请求PDU的格式。

[0342]

[0343] 表格30

[0344] 大小＝0x01，有效载荷中的字节数

[0345] 帧描述符-

[0346] 比特7-版本＝0b

[0347] 比特6-嵌入数据＝0b

[0348] 比特5-Ack标记＝0b，无确认

[0349] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0350] 比特2-0-帧类型＝001b，媒体接入协议

[0351] 地址-

[0352] 目的供应商＝001b，组织1

[0353] 目的设备ID＝0x112233，供应商特有的值

[0354] 源供应商＝001b，组织1

[0355] 源设备ID＝0x123456，供应商特有的值

[0356] 序列号-00b

[0357] 启用有效载荷FEC-1b

[0358] 帧头帧校验序列-0xXXXX(16比特CRC)

[0359] 响应操作码-0x04，双向流停止会话请求

[0360] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0361] 表31是接受或拒绝响应PDU的格式。

[0362]

[0363] 表格31

[0364] 大小＝0x01，有效载荷中的字节数

[0365] 帧描述符-

[0366] 比特7-版本＝0b

[0367] 比特6-嵌入数据＝0b

[0368] 比特5-Ack标记＝0b，无确认

[0369] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0370] 比特2-0-帧类型＝001b，媒体接入协议

[0371] 地址-

[0372] 目的供应商＝001b，组织1

[0373] 目的设备ID＝0x123456，供应商特有的值

[0374] 源供应商＝001b，组织1

[0375] 源设备ID＝0x112233，供应商特有的值

[0376] 序列号-00b

[0377] 启用有效载荷FEC-1b

[0378] 帧头帧校验序列-0xXXXX(16比特CRC)

[0379] 响应操作码-0x01，接受响应或0x02拒绝响应

[0380] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0381] 本示例协议包括信道改变请求。表22是信道改变请求PDU的格式。

[0382]

[0383] 表格32

[0384] 大小＝0x02，有效载荷中的字节数

[0385] 帧描述符-

[0386] 比特7-版本＝0b

[0387] 比特6-嵌入数据＝0b

[0388] 比特5-Ack标记＝0b，无确认

[0389] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0390] 比特2-0-帧类型＝001b，媒体接入协议

[0391] 地址-

[0392] 目的供应商＝001b，组织1

[0393] 目的设备ID＝0x112233，供应商特有的值

[0394] 源供应商＝001b，组织1

[0395] 源设备ID＝0x123456，供应商特有的值

[0396] 序列号-00b

[0397] 启用有效载荷FEC-1b

[0398] 帧头帧校验序列-0xXXXX(16比特CRC)

[0399] 响应操作码-0x07-信道改变请求

[0400] 有效载荷-04-信道标识符

[0401] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0402] 表33是接受或拒绝响应PDU的格式。

[0403]

[0404] 表格33

[0405] 大小＝0x01，有效载荷中的字节数

[0406] 帧描述符-

[0407] 比特7-版本＝0b

[0408] 比特6-嵌入数据＝0b

[0409] 比特5-Ack标记＝0b，无确认

[0410] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0411] 比特2-0-帧类型＝001b，媒体接入协议

[0412] 地址-

[0413] 目的供应商＝001b，组织1

[0414] 目的设备ID＝0x123456，供应商特有的值

[0415] 源供应商＝001b，组织1

[0416] 源设备ID＝0x112233，供应商特有的值

[0417] 序列号-00b

[0418] 启用有效载荷FEC-1b

[0419] 帧头帧校验序列-0xXXXX(16比特CRC)

[0420] 响应操作码-0x01，接受响应或0x02拒绝响应

[0421] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0422] 本示例协议包括广播/多播报文响应。为了避免帧冲突，当节点收到以广播地址作为目的地址的有效输入PDU时，就应发送响应，而各独立节点需延迟发送它们的响应。此延迟值被用作避免冲突的机制，以防止收到广播报文的所有节点同时发送它们的响应，所导致帧冲突。延迟值从以下集合{4，8，12，16，29，24，28，32毫秒}中随机选取。

[0423] 本示例协议包括纠错/检错。纠错/检错功能为接收节点提供了检测和纠正在传输分组期间发生的某些错误。

[0424] 本示例协议包括前向纠错。用分组纠错码——Reed Solomon码纠正通信信道所引入的错误。用分组大小为44比特Reed Solomon码RS(15，11)纠正分组中的错误。因此，每44信息比特的分组经编码生成60比特的码字。由于编码器使用长44比特的信息段，因此必须在有效载荷的末尾，或在CRC(如果报文有CRC)后附加值为0的尾比特。用于编码的比特总数应是44的倍数。因此，附加的尾比特数是满足此条件的可能的最小值(即在区间0...43内)。这些尾比特不被计算在帧头的大小字段中。

[0425] 数据链路PDU总是对从大小字段到帧头帧校验序列字段的数据进行前向纠错。然而，数据链路PDU可以也可以不对剩余的数据链路PDU数据进行前向纠错，具体取决于数据链路PDU的协议标识符字段。不对数据链路PDU的“有效载荷”进行前向纠错的唯一的协议标识符是双向语音协议标识符。

[0426] 本示例协议包括检错功能。本示例协议包括CRC-CCITT功能。16比特的CRC-CCITT16 12 5
使用多项式-X +X +X+1。在计算前，先将CRC值初始化为0xFFFF。发射机或接收机将不对最终的CRC计算值进行修改，如采用全一的补码。帧接收机采用和发射机相同的方式计算收到的FCS，并将算得的FCS与收到的FCS进行比较。如果两者相等，就说明成功接收了帧数据。接收机将直接把算得的和收到的CRC值进行比较。

[0427] 本示例协议包括CRC-32功能。32比特的CRC-32使用多项式-X32+X26+X23+X22+X16+12 11 10 8 7 5 4 2
X +X +X +X+X+X+X+X+X+1。在计算前，将CRC值初始化为0xFFFFFFFF。发射机或接收机将不对最终的CRC计算值进行修改，如采用全一的补码。帧接收机采用和发射机相同的方式计算收到的FCS，并将算得的FCS与收到的FCS进行比较。如果两者相等，就说明成功接收了帧数据。接收机将直接把算得的和收到的CRC值进行比较。

[0428] 本示例协议包括更高层的协议。目前定义了四个更高层的协议：助听器控制、双向语音、单向流音频和扩展协议。助听器控制协议用于和助听器进行通信，指示有关控制和配置的操作，如调整功能。双向语音协议用于向助听器发送和从助听器接收数字音频数据。单向流音频用于向助听器发送单向数字音频数据。扩展协议用于提供对其他网络服务协议的访问。

[0429] 本示例协议包括助听器控制协议。助听器控制协议用于向助听器传送调整应用、生产应用和其他相似类型应用的程序设计信息。用于向助听器传送助听数据的PDU帧格式如下表34所示：

[0430]

[0431] 表格34

[0432] 大小＝0xC，有效载荷中的字节数

[0433] 帧描述符-

[0434] 比特7-版本＝0b

[0435] 比特6-嵌入数据＝0b

[0436] 比特5-Ack标记＝1b，需要确认

[0437] 比特4-3-有效载荷FCS模式＝10，32比特长CRC

[0438] 比特2-0-帧类型＝010b，助听器数据

[0439] 地址-

[0440] 目的供应商＝001b，组织1

[0441] 目的设备ID＝0x112233，供应商特有的值

[0442] 源供应商＝001b，组织1

[0443] 源设备ID＝0x123456，供应商特有的值

[0444] 序列号-01b

[0445] 启用有效载荷FEC-1b

[0446] 帧头帧校验序列-0xXXXX(16比特CRC)

[0447] 助听器数据-0xAABBCCDD1122334455667788(供应商相关数据)

[0448] 有效载荷帧校验序列-0xXXXXXXXX(32比特CRC)

[0449] 由目的节点返回的层2确认分组如下表35所示：

[0450]

[0451] 表格35

[0452] 大小＝0x00，有效载荷中的字节数

[0453] 帧描述符-

[0454] 比特7-版本＝0b

[0455] 比特6-嵌入数据＝0b

[0456] 比特5-Ack标记＝0，无确认

[0457] 比特4-3-有效载荷FCS模式＝00b，无有效载荷CRC

[0458] 比特2-0-帧类型＝000b，确认

[0459] 地址-

[0460] 目的供应商＝001b，组织1

[0461] 目的设备ID＝0x123456，供应商特有的值

[0462] 源供应商＝001b，组织1

[0463] 源设备ID＝0x112233，供应商特有的值

[0464] 序列号-01b

[0465] 启用有效载荷FEC-0b

[0466] 帧头帧校验序列-0xXXXX(16比特CRC)

[0467] 本示例协议包括双向语音协议。双向语音协议用于发送和接收数字音频信息。用于向助听器传送双向音频信息的PDU格式如下表36所示：

[0468]

[0469] 表格36

[0470] 大小＝0x80，有效载荷中的字节数

[0471] 帧描述符-

[0472] 比特7-版本＝0b

[0473] 比特6-嵌入数据＝0b

[0474] 比特5-Ack标记＝0b，无确认

[0475] 比特4-3-有效载荷FCS模式＝00b，无有效载荷CRC

[0476] 比特2-0-帧类型＝011b，双向音频数据

[0477] 地址-

[0478] 目的供应商＝001b，组织1

[0479] 目的设备ID＝0x112233，供应商特有的值

[0480] 源供应商＝001b，组织1

[0481] 源设备ID＝0x123456，供应商特有的值

[0482] 序列号-00b

[0483] 启用有效载荷FEC-0b

[0484] 帧头帧校验序列-0xXXXX(16比特CRC)

[0485] 音频码字-供应商特有的值(长度为128字节)

[0486] 本示例协议包括单向流音频协议。流音频协议用于发送数字音频信息。用于向助听器传送流音频信息的PDU格式如下表37所示：

[0487]

[0488] 表格37

[0489] 大小＝0x205，有效载荷中的字节数

[0490] 帧描述符-

[0491] 比特7-版本＝0b

[0492] 比特6-嵌入数据＝0b

[0493] 比特5-Ack标记＝0b，无确认

[0494] 比特4-3-有效载荷FCS模式＝00，无有效载荷CRC

[0495] 比特2-0-帧类型＝100b，流音频数据

[0496] 地址-

[0497] 目的供应商＝001b，组织1

[0498] 目的设备ID＝0x112233，供应商特有值

[0499] 源供应商＝001b，组织1

[0500] 源设备ID＝0x123456，供应商特有的值

[0501] 序列号-00b

[0502] 支持载荷FEC-1b

[0503] 帧头帧校验序列-0xXXXX(16比特CRC)

[0504] 音频码字-供应商特有的值(长度为517字节)

[0505] 本示例协议包括扩展协议。扩展协议是一种允许其他网络服务利用无线通信协议数据链路和物理层的机制。此处说明了扩展协议的实例。

[0506] 扩展协议

[0507] 图18示出了本主题范围内的各种网络服务的整体结构。此图示出了一应用1802，后者连接媒体接入协议1804、助听器数据协议1806、双向语音协议1808、单向音频协议1810、fm控制1814、遥控1816、设备信息1818和基带控制1820。此外，扩展协议(网络服务)与1814-1820连接，还与链路协议1824相连接。在各种实施例中，链路协议使用ack。
链路协议的协议ID是0x0。表38提供了目前已规定的网络服务标识符列表。网络服务标识符0和255是保留值。

[0508]

[0509] 表格38

[0510] 本示例协议包括基带控制网络服务。基带控制网络服务允许为无线节点指派地址或取消指派地址。表39列出了基带控制网络服务的服务请求和响应。

[0511]

[0512] 表格39

[0513] 各种基带控制节点请求和响应将使用单播地址。如果在收到基带控制请求的同时，在源或目的地址中收到了广播或多播长地址，就忽略/丢弃基带控制请求。由于各种基带请求需要特定的基带响应，因此在某些实施例中，发送请求和响应而不要求链路层确认。

[0514] 本示例协议包括指派地址/取消指派地址的请求/响应。表40是指派长地址/取消指派长地址请求PDU的格式。

[0515]

[0516] 表格40

[0517] 大小＝0x06，有效载荷中的字节数

[0518] 帧描述符-

[0519] 比特7-版本＝0b

[0520] 比特6-嵌入数据＝0b

[0521] 比特5-Ack标记＝0b，无确认

[0522] 比特4-3-有效载荷FCS模式＝00，16比特长CRC

[0523] 比特2-0-帧类型＝111b，扩展协议

[0524] 地址-

[0525] 目的供应商＝001b，组织1

[0526] 目的设备ID＝0x112233，供应商特有的值

[0527] 源供应商＝001b，组织1

[0528] 源设备ID＝0x123456，供应商特有的值

[0529] 序列号-00b

[0530] 启用有效载荷FEC-1b

[0531] 帧头帧校验序列-0xXXXX(16比特CRC)

[0532] 有效载荷-见表41

[0533] 有效载荷帧校验和序列-0xXXXX(16比特CRC)

[0534] 表41提供了“有效载荷”字段的详细格式：

[0535]

[0536] 表格41

[0537] 网络服务ID-0x03，基带控制网络服务

[0538] 请求操作码-0x03或0x04，指派/取消指派地址请求

[0539] 供应商ID-001b，供应商ID地址

[0540] 设备ID-0x000001，设备ID地址

[0541] 表42是接受或拒绝响应PDU的格式。

[0542]

[0543] 表格42

[0544] 大小＝0x02，有效载荷中的字节数

[0545] 帧描述符-

[0546] 比特7-版本＝0b

[0547] 比特6-嵌入数据＝0b

[0548] 比特5-Ack标记＝0b，无确认

[0549] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0550] 比特2-0-帧类型＝111b，扩展协议

[0551] 地址-

[0552] 目的供应商＝001b，组织1

[0553] 目的设备ID＝0x123456，供应商特有的值

[0554] 源供应商＝001b，组织1

[0555] 源设备ID＝0x112233，供应商特有的值

[0556] 序列号-00b

[0557] 启用有效载荷FEC-1b

[0558] 帧头帧校验序列-0xXXXX(16比特CRC)

[0559] 网络服务ID-0x0，基带控制网络服务

[0560] 响应操作码-0x01，接受响应或0x02拒绝响应

[0561] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0562] 本示例协议包括设备信息网络服务。设备信息网络业务发现无线节点并获取无线节点信息。表43列出了设备信息网络服务所支持的服务请求和响应。

[0563] Ping请求和响应(操作码0x01-0x06)用于获取范围内节点的基本长地址。其左右版本分别用于请求所指派的左右节点的地址。因此，如果一节点被定义成左节点，它就应使用“来自左HA的Ping应答”(0x05)来响应Ping(0x01)和“Ping左HA”(0x02)的请求，且它不对“Ping右HA”(0x03)请求做出响应。尚未指派左右的节点应做出“Ping应答(0x04)响应。

[0564] 其余的请求和响应用于从无线节点获取其他信息。

[0565]

[0566] 表格43

[0567] 设备信息Ping请求可以用广播地址作为目的地址。然而，设备信息Ping响应和所有其他设备信息请求和响应应使用单播地址作为源和目的地址；否则，就应忽略或丢弃它们。

[0568] 由于所有设备信息请求需要特定设备的信息响应，因此可以发送所有请求和响应而不要求发送链路层确认。最后，由于无线协议和相关的设备信息控制请求/响应的缘故，在无线节点间，每次只执行一个设备信息控制操作。

[0569] 本示例协议包括Ping请求/响应。表44说明了Ping请求PDU的一种格式。

[0570]

[0571] 表格44

[0572] 大小＝0x02，有效载荷中的字节数

[0573] 帧描述符-

[0574] 比特7-版本＝0b

[0575] 比特6-嵌入数据＝0b

[0576] 比特5-Ack标记＝0b，无确认

[0577] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0578] 比特2-0-帧类型＝111b，扩展协议

[0579] 地址-

[0580] 目的供应商＝001b，组织1

[0581] 目的设备ID＝0xFFFFF，广播地址

[0582] 源供应商＝001b，组织1

[0583] 源设备ID＝0x123456，供应商特有的值

[0584] 序列号-00b

[0585] 启用有效载荷FEC-1b

[0586] 帧头帧校验序列-0xXXXX(16比特CRC)

[0587] 网络服务ID-0x02，设备信息网络服务

[0588] 响应操作码-0x01Ping，0x02Ping左HA，或0x03Ping右HA

[0589] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0590] 表45是Ping响应PDU的一种格式。

[0591]

[0592] 表格45

[0593] 大小＝0x04，有效载荷中的字节数

[0594] 帧描述符-

[0595] 比特7-版本＝0b

[0596] 比特6-嵌入数据＝0b

[0597] 比特5-Ack标记＝0b，无确认

[0598] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0599] 比特2-0-帧类型＝001b，扩展协议

[0600] 地址-

[0601] 目的供应商＝001b，组织1

[0602] 目的设备ID＝0x123456，供应商特有的值

[0603] 源供应商＝001b，组织1

[0604] 源设备ID＝0x112233，供应商特有的值

[0605] 序列号-00b

[0606] 启用有效载荷FEC-1b

[0607] 帧头帧校验序列-0xXXXX(16比特CRC)

[0608] 网络服务ID-0x02，设备信息网络服务

[0609] 响应操作码-0x04Ping应答，0x05来自左HA的Ping应答，或0x06来自右HA的Ping应答

[0610] 供应商数据长度-0x02供应商数据长度

[0611] 供应商数据-0xaabb供应商数据(该字段的格式和使用对各供应商是独一无二的。)

[0612] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0613] 本示例协议包括地址信息请求/响应。地址信息请求PDU大小固定。表46是一地址信息请求PDU。

[0614]

[0615] 表格46

[0616] 大小＝0x02，有效载荷中的字节数

[0617] 帧描述符-

[0618] 比特7-版本＝0b

[0619] 比特6-嵌入数据＝0b

[0620] 比特5-Ack标记＝0b，无确认

[0621] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0622] 比特2-0-帧类型＝001b，扩展协议

[0623] 地址-

[0624] 目的供应商＝001b，组织1

[0625] 目的设备ID＝0x112233，供应商特有的值

[0626] 源供应商＝001b，组织1

[0627] 源设备ID＝0x123456，供应商特有的值

[0628] 序列号-00b

[0629] 启用有效载荷FEC-1b

[0630] 帧头帧校验序列-0xXXXX(16比特CRC)

[0631] 网络服务ID-0x02，设备信息网络业务

[0632] 响应操作码-0x07地址信息请求

[0633] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0634] 地址信息请求PDU具有可变大小，具体大小取决于节点的conFIG.d的地址数。响应的最小尺寸是0x05字节。这包括地址数字段和所有节点应具有的一个地址conFID.D。表47示出了地址信息数据的格式。

[0635]

[0636] 表格47

[0637] 表48是具有一指派地址的地址信息响应。

[0638]

[0639] 表格48

[0640] 大小＝0x07，有效载荷中的字节数

[0641] 帧描述符-

[0642] 比特7-版本＝0b

[0643] 比特6-嵌入数据＝0b

[0644] 比特5-Ack标记＝0b，无确认

[0645] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0646] 比特2-0-帧类型＝111b，扩展协议

[0647] 地址-

[0648] 目的供应商＝001b，组织1

[0649] 目的设备ID＝0x123456，供应商特有的值

[0650] 源供应商＝001b，组织1

[0651] 源设备ID＝0x112233，供应商特有的值

[0652] 序列号-00b

[0653] 启用有效载荷FEC-1b

[0654] 帧头帧校验序列-0xXXXX(16比特CRC)

[0655] 网络服务ID-0x02，设备信息网络服务

[0656] 响应操作码-0x08地址信息应答

[0657] 地址信息数据-0x010F7FFFFF-该节点的地址信息

[0658] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0659] 本示例协议包括扩展设备信息请求/响应。扩展设备信息提供了一种获取关于节点的识别信息的方法。请求PDU尺寸固定。表49是一地址信息请求PDU。

[0660]

[0661] 表格49

[0662] 大小＝0x02，有效载荷中的字节数

[0663] 帧描述符-

[0664] 比特7-版本＝0b

[0665] 比特6-嵌入数据＝0b

[0666] 比特5-Ack标记＝0b，无确认

[0667] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0668] 比特2-0-帧类型＝111b，扩展协议

[0669] 地址-

[0670] 目的供应商＝001b，组织1

[0671] 目的设备ID＝0x112233，供应商特有的值

[0672] 源供应商＝001b，组织1

[0673] 源设备ID＝0x123456，供应商特有的值

[0674] 序列号-00b

[0675] 启用有效载荷FEC-1b

[0676] 帧头帧校验序列-0xXXXX(16比特CRC)

[0677] 网络服务ID-0x02，设备信息网络服务

[0678] 响应操作码-0x09扩展设备信息请求

[0679] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0680] 表50是扩展设备信息响应。

[0681]

[0682] 表格50

[0683] 大小＝0x17，有效载荷中的字节数

[0684] 帧描述符-

[0685] 比特7-版本＝0b

[0686] 比特6-嵌入数据＝0b

[0687] 比特5-Ack标记＝0b，无确认

[0688] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0689] 比特2-0-帧类型＝111b，扩展协议

[0690] 地址-

[0691] 目的供应商＝001b，组织1

[0692] 目的设备ID＝0x123456，供应商特有的值

[0693] 源供应商＝001b，组织1

[0694] 源设备ID＝0x112233，供应商特有的值

[0695] 序列号-00b

[0696] 启用有效载荷FEC-1b

[0697] 帧头帧校验序列-0xXXXX(16比特CRC)

[0698] 网络服务ID-0x02，设备信息网络服务

[0699] 响应操作码-0x0A扩展设备信息应答

[0700] 扩展数据信息数据-该节点独有的扩展设备信息扩展设备信息数据具有表51所示的格式。

[0701]

[0702] 表格51

[0703] 表52示出了该节点的设备类型的有效值。

[0704]

[0705] 表格52

[0706] 设备模型字段是采用供应商定义的编码方案的设备的详细标识符；设备序列号是供应商定义的设备序列号(或其部分的)的编码；设备位置显示该设备是否已被指派左/右。表53示出了设备位置的有效值。

[0707]

[0708] 表格53设备位置字段

[0709] 链路MTU字段标识节点可接收的最大PDU。链路选项字段是标识节点支持的其他选项的位域。如果支持该选项，该比特就为1；如果不支持该选项，该比特就为0。表54示出了这些选项。

[0710]

[0711] 表格54链路选项字段

[0712] 链路音频字段包含设备所支持的音频流数量。值0意味着不支持音频流。

[0713] 本示例协议包括音频信息请求/响应。音频信息请求PDU大小固定。表55是音频信息请求PDU。

[0714]

[0715] 表格55

[0716] 大小＝0x02，有效载荷中的字节数

[0717] 帧描述符-

[0718] 比特7-版本＝0b

[0719] 比特6-嵌入数据＝0b

[0720] 比特5-Ack标记＝0b，无确认

[0721] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0722] 比特2-0-帧类型＝111b，扩展协议

[0723] 地址-

[0724] 目的供应商＝001b，组织1

[0725] 目的设备ID＝0x112233，供应商特有的值

[0726] 源供应商＝001b，组织1

[0727] 源设备ID＝0x123456，供应商特有的值

[0728] 序列号-00b

[0729] 启用有效载荷FEC-1b

[0730] 帧头帧校验序列-0xXXXX(16比特CRC)

[0731] 网络服务ID-0x02，设备信息网络服务

[0732] 响应操作码-0x0B，音频信息请求

[0733] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0734] 音频信息响应PDU具有可变尺寸，具体大小取决于节点所支持的音频流数量。响应的最小尺寸是0x01字节。这包括无支持音频流的音频流数量字段。表56说明了音频信息数据域的值。

[0735]

[0736] 表格56

[0737] 表57是支持两个音频流的音频信息响应。

[0738]

[0739] 表格57

[0740] 大小＝0x07，有效载荷中的字节数

[0741] 帧描述符-

[0742] 比特7-版本＝0b

[0743] 比特6-嵌入数据＝0b

[0744] 比特5-Ack标记＝0b，无确认

[0745] 比特4-3-有效载荷FCS模式＝01，16比特长CRC

[0746] 比特2-0-帧类型＝111b，扩展协议

[0747] 地址-

[0748] 目的供应商＝001b，组织1

[0749] 目的设备ID＝0x123456，供应商特有的值

[0750] 源供应商＝001b，组织1

[0751] 源设备ID＝0x112233，供应商特有的值

[0752] 序列号-00b

[0753] 启用有效载荷FEC-1b

[0754] 帧头帧校验序列-0xXXXX(16比特CRC)

[0755] 网络服务ID-0x02，设备信息网络服务

[0756] 响应操作码-0x0C，音频信息应答

[0757] 音频信息数据-0x02010111020305-该节点的音频信息；支持两个音频流--CVSD编码译码器，1比特/采样@64KHz和μ律编译码器，3比特/采样@16KHz[0758] 有效载荷帧校验序列-0xXXXX(16比特CRC)

[0759] 本示例协议包括遥控网络服务。遥控网络服务支持在助听器和遥控设备间传送信息。遥控网络服务是供应商特有的，因而不定义任何具体的请求或响应。所有遥控网络服务数据都可以利用供应商所规定的寻址方式发送。

[0760] 本示例协议包括FM控制网络服务。FM控制网络服务支持在辅助设备和FM收发机(如附在助听器上的FM底座)间传送信息。FM控制网络服务是供应商特有的，因此不定义任何具体的请求或回答。所有FM控制网络服务数据都可以利用供应商所规定的寻址方式发送。

[0761] 标识符

[0762] 本示例协议包括编码译码器ID。表58列出了支持的各种编码译码器：

[0763]

[0764] 表格58

[0765] 注意可以按照需要分配其他编码类型。

[0766] 本示例协议包括比特率ID。表59列出了所支持的各种比特率ID。

[0767]

[0768] 表格59

[0769] 注意可以按照需要分配其他比特率。

[0770] 本示例协议包括采样频率ID。表60列出了所支持的各种采样频率。

[0771]

[0772] 表格60

[0773] 注意可以按照需要分配其他采样频率。

[0774] 高层协议

[0775] 具备无线通信能力的助听器(HI)要求HI 固件开发者考虑有线通信无需考虑的因素。本文档将简要说明无线通信信道的一些设计因素。

[0776] 有线HI通过线路以“点对点”方式通信；充当附在线路另一端的“主”设备的从属设备。点对点关系是有线连接所导致的结果，而主/从关系是用于传送数据的协议(SDA或SSI)的结果。主设备发起所有的通信，而从属设备同步地予以响应。通常，这就是“程序设计装置”所采用的机制。

[0777] 具有无线链路的HI不局限于点对点或主/从关系。当发送无线报文时，任何具有兼容无线收发机的设备都可接收此报文。因此，任何设备都可发起与其范围内其他设备的通信。这种“对等”关系为HI提供了与另一HI或辅助设备进行通信的可能。在一实施例中，在无线链路上支持的高层协议包括，但不局限于：助听器控制、单向流音频、双向流音频和扩展协议。

[0778] 助听器控制协议是在HI和调整应用或辅助没备或另一HI间传送数据的主要机制。

[0779] 单向流音频协议用于向HI发送数字音频。当在HI中使用此协议时，HI不能发送任何数据。

[0780] 双向流音频协议用于向HI发送数字音频。当在HI中使用此协议时，HI只能向音频网关发送数据。可以被发送的数据是数字音频或少量的嵌入控制数据。

[0781] 扩展协议用于提供额外的网络服务。这些服务包括设备发现、动态地址分配和设备信息获取。

[0782] 在一实施例中，当正在使用一流音频协议时(即，“会话”激活)，使用任何其他协议(助听器控制、扩展或其他流音频协议)的尝试都将终止此流音频会话。

[0783] 当使用助听器控制协议时，发送的报文可以带有或不带有较低层的确认(ack)。较低层的ack表示收到了报文，并将报文送至目标应用进行处理。它并不表示报文真正由接收应用处理。

[0784] 如果使用较低层的ack，则为了把报文送至目的应用，将会进行多次尝试。如果较低层不能传送报文，发送应用将被告知发送失败。如果较低层能传送报文，发送应用将被告知发送成功。较低层的ack机制确保不发生重复。

[0785] 如果不发送较低层的ack，就将尝试传送报文。如果发送了报文，发送应用将被告知发送成功。此通知并不意味着目的应用收到了报文。如果发射机不能发送报文，发送应用就被告知发送失败。

[0786] 当选择是否使用链路层ack时，应用开发者有许多需要考虑的选项。这些选项包括：

[0787] ◆报文是否需要来自接收应用的应答？

[0788] 如果希望接收应用应答，接收应用应答就可以被用作应用层ack，并取代链路层ack。这要求应用执行自己的超时和重试处理。除了确保确实发送了报文，协议将不对这些提供支持。应用应答能向网络发送更多的数据业务，然而，使用链路层ack可消除对执行超时和重试处理的应用的要求。

[0789] ◆报文未到达目的地要不要紧？

[0790] 如果报文是否到达无关紧要，则从节能的角度来看，不使用链路层ack将更加高效。前提是，通信信道“足够”理想，大多数情况下，可以成功传送消息。另一个前提是，传送失败不会对HI功能造成重大影响(即，佩戴者不会注意到存在的差异)或者报文是定期更新的，当下次发送时，能到达目的地。

[0791] 如果报文必须到达目的地，且不希望使用应用应答，则链路层ack可能是最合适的。

[0792] 在一实施例中，助听器控制协议能承载1024字节的应用数据。当选择放入分组中的数据量时，可以进行多种折衷。例如，对于较大的分组，更可能无法纠正遭到破坏的比特。这绝大部分取决于链路质量(尤其是BER)；链路质量受无线接收机设计、通信设备间距离和外部“干扰”的影响。较大分组的优势在于，由于协议开销较少，所以网络链路的总吞吐量较大。

[0793] 较小分组的一个劣势在于，如果应用报文大于分组，则应用必须自己提供对应用报文进行分段和重组的机制。例如，假设正在从调整应用向SSI 缓冲器发送256个字节。如果每个分组容纳100字节的有效载荷，则必须发送三个分组。此外，必须在报文中包括一些信息，以便接收机能够判断是否收到了某一分组。

[0794] 对于音频流协议，所有应用信息都必须在嵌入数据区的范围内。嵌入数据区共25比特；3比特用于定义嵌入信息类型。其余22比特取决于此嵌入消息类型。保留一模式用于WAC-HI通信。其他模式目前尚未定义，且全部可用。由于音频流协议在两设备间建立了专用会话，因此嵌入信息的源和目的是固定的。

[0795] 服务质量(QOS)指类似于发送报文的延迟和可靠性之类的指标。无线协议的某些实施例不保证成功传送报文。由于ack算法最终将放弃尝试，所以采用链路层ack不能提供这种保证。此外，实际的BER将具有如前面部分所说明的影响。流音频协议遵循与助听器协议不同的规则；因此，在此处对嵌入数据时延的讨论中，不考虑他们。

[0796] 在一实施例中，助听器控制协议采用CSMA算法判断无线信道是否可用。发送HA可以等待信道变为可用，等待时间长达320毫秒；该时延是为了适应“干扰”。除了CSMA，还要考虑两种情况：使用链路层ack和不使用链路层ack。

[0797] 如果不使用链路层ack，则发送或失败前的最大时延是320毫秒的CSMA时延。

[0798] 如果使用链路层ack，则发射机在目的设备确认该分组前，最多重试三次。每次发送后，发射机将暂停100ms。在最坏情况下，成功或失败前的时延是1680ms。

[0799] ((第#次发送)*(CSMA超时))+((第#次暂停)*(暂停持续时间))＝(4*320ms)+(4*100ms)＝1280ms+400ms＝1680ms

[0800] 对于耳到耳报文，还需在最坏情况时延上增加额外的250ms。这是节点唤醒序列所带来的时延，如果希望目的设备休眠，则可能需要使用节点唤醒序列。

[0801] 无线助听器控制协议实例

[0802] 所提出的系统的一种可能的应用是对使用无线协议的助听器进行控制。以下只是执行此类控制的一个建议。应理解，可以在不背离本主题范围的前提下，利用无线协议，在功能、过程、编码和控制方面作出修改。

[0803] 所提出的无线协议的使用可以在两个助听器以及接口110(如WAC设备)和助听器间传送远程命令和控制信息。可以传送如音量设置、静音状态、电池剩余寿命、声学环境、麦克风状态等信息，以对助听器进行控制、同步，或提供用户反馈。所有这些使助听器成为更有效的，接收无线输入、声音输入或两者的结合的听音设备。

[0804] 遥控信息用于在无线音频会话期间控制各种音频信源。因此，为了使收听者感到舒适，并照顾到收听者的偏好，将嵌入信息和流音频数据一起发送是有利的。

[0805] 依照一实施例，为了命令和控制助听器，定义了六种数据类型，保留一种数据类型用于今后的扩展。两种数据类型是特别针对嵌入信道的，但也可将它们用于普通的数据有效载荷信息。无线协议使用具有60比特帧头的分组，其中帧头使用CRC-16循环冗余码，并采用RS(15，11)前向纠错码进行编码。帧头之后是可变长度的有效载荷比特，可以也可以不使用RS(15，11)对有效载荷进行编码。载荷还可以包括适合发送数据类型的CRC校验。

[0806] 用于遥控助听器的信息可以被包含于此处所提供的无线协议实例的分组头中。有时，可以用有用的遥测信息替换数字音频分组中的源地址字段，有用的遥测信息可被传送至助听器或从助听器传送而来，以进行音频控制。这样做的原因之一是由于，在流或双向音频会话期间，有效载荷比特被用于传递数字音频信息，因而缺少可用于如遥测等信息的带宽资源。此外，可以也可以不用CRC码或Reed-Solomon前向纠错码对有效载荷加以保护。因此，决定在帧头中源地址(设备ID)通常所在的位置容纳音频控制信息，其中源地址在流会话期间与接收站没有特别的关系。此音频控制信息被称为嵌入数据。源地址包括3比特供应商ID和预先指派的22比特的设备ID，当存在嵌入数据时，设备ID将被嵌入数据所替代。嵌入数据提供25比特的控制和状态信息，可以在流音频会话期间，但不局限于流音频会话期间可靠地传送这些信息。

[0807] 可利用无线协议发送这些消息，并将后者包含于无线帧头PDU中，帧头PDU的帧描述符(FD)字段中设置的比特6指示嵌入数据类型。消息则位于帧头PDU的嵌入信道(EC)字段中。

[0808] 该消息类型也可位于普通分组的有效载荷中，并由帧头PDU的帧描述符(FD)字段的协议标识符比特中的扩展数据类型标识。扩展数据类型是帧头PDU校验和之后的第一个有效载荷字节。服务id0x03，表示这是遥控消息。此服务id之后就是此处所定义的实际的遥控消息。

[0809] 该消息在某种程度上将是通用的和可扩展的。保留消息的头三个比特用于表示消息类型，消息类型范围从0到7，保留7用于表示扩展消息类型。其余的比特将被视为遥控信息类型中的有效载荷比特。在本文档的撰写期间，已确定了两种消息类型。对它们的大小加以限制，使它们可用于嵌入信道，但它们的使用并不局限于嵌入信道，也可以在通过普通的有效载荷消息信道，正常交换遥测信息时使用它们。

[0810]

[0811] 表格61.通用遥控消息

[0812] 下表示出了两个实例。表62示出了作为帧头PDU中嵌入数据的遥控消息。表63示出了作为扩展数据类型(FD)的网络服务ID类型0x03(遥控)的部分有效载荷的命令消息。

[0813]

[0814] 表格62.作为流音频帧头PDU中嵌入数据的遥控消息

[0815]

[0816] 表格63.扩展帧描述符类型分组中的遥控消息

[0817] 消息类型0是嵌入命令消息，在一实施例中，嵌入命令消息不长于25比特，其比特映射方式如下表64所示。

[0818]

[0819] 表格64嵌入命令消息类型0

[0820] 此消息的有效载荷比特如下所示。

[0821] 音量调节在此消息中音量是一个相对设置。

[0822] 比特3指示音量递增量。

[0823] 比特4指示变化方向1＝增加音量0＝减小音量

[0824] 音量级

[0825] 比特5-9

[0826] 0表示音量未发生改变

[0827] 1＝最小值

[0828] 31＝最大值

[0829] 存储器增量

[0830] 比特10表示存储器选集的变化，在该比特上，1指示助听器将存储器选集加1，直至存储器选集的模值转回到1(0+1)为止。0无效。

[0831] 存储器状态有多达7种不同的存储器设置

[0832] 比特11-13

[0833] 0＝存储器状态未发生改变

[0834] 1＝存储器1

[0835] ·

[0836] ·

[0837] ·

[0838] 7＝存储器7

[0839] 静音状态

[0840] 比特6指示静音状态的变化。如中频音频控制文档中所说明的，存在三种静音状态。因此，这些静音状态从0-2关于模3递增。状态如下。

[0841] 0＝只启用助听器麦克风(无线静音)。

[0842] 1＝只启用无线输入(助听器麦克风静音)。

[0843] 2＝混合无线和助听器麦克风(不静音)。

[0844] 提示音

[0845] 比特7和8用于提示音

[0846] 有四种不同的音频指示器是可用的，可以通过比特7和8来启用它们。

[0847] 这些音调产生于本地助听器。

[0848] 00＝禁用音调

[0849] 01＝来话铃声

[0850] 10＝WAC电池电量不足指示

[0851] 11＝范围内的WAC

[0852] 状态请求

[0853] 当设置该比特时，就请求状态消息。当处于高保真流音频模式时，助听器不能对此请求做出响应。

[0854] 注意：对音量和存储器所做的绝对设置将优先于包含于同一消息中的相对递增或递减。

[0855] RF信道

[0856] 选择一RF信道，当设置为0时，预置RF信道不应发生任何改变。如果当前的调谐信道不是该字段中所发送的非零信道，接收站就将改变信道。

[0857] 比特19-21

[0858] 信道1-6

[0859] 表65示出了消息类型1的比特：

[0860]

[0861] 表格65.状态应答消息类型1

[0862] 该消息的有效载荷比特如下。

[0863] 音量状态

[0864] 比特3-7指示助听器的当前音量设置

[0865] 1＝最低音量设置

[0866] 31＝最高音量设置

[0867] 注意0是无效的

[0868] 存储器状态

[0869] 比特8-10指示存储器设置

[0870] 1＝存储器1

[0871] ·

[0872] ·

[0873] ·

[0874] 7＝存储器7

[0875] 注意0是无效的

[0876] 静音状态

[0877] 比特11-12表示当前的静音情况

[0878] 0＝启用麦克风和无线输入

[0879] 1＝启用麦克风/禁用无线输入

[0880] 2＝禁用麦克风/启用无线输入

[0881] 3＝禁用麦克风和无线输入

[0882] 电池状态

[0883] 比特13-16指示电池状态

[0884] 0＝电池电量空

[0885] ·

[0886] ·

[0887] ·

[0888] 15＝电池充满

[0889] 麦克风选择

[0890] 比特17-18指示当前的麦克风设置

[0891] 0＝全向麦克风

[0892] 1＝心型麦克风

[0893] 2＝超心型麦克风

[0894] 3＝保留1

[0895] 环境状态

[0896] 比特20-22指示当前的环境情况

[0897] 0＝无输入

[0898] 1＝只有语音输入

[0899] 2＝有噪声无语音

[0900] 3＝有噪声有语音

[0901] 4＝周期性噪声

[0902] 5＝音乐

[0903] 6＝保留1

[0904] 7＝保留2

[0905] 保留

[0906] 比特23-24

[0907] 收发机硬件

[0908] 许多发射机和接收机的组合可用于进行接口110和无线音频设备间的无线通信。此处提供了一这样的体系结构，然而，应了解可以在不背离本主题的前提下，对其加以改变。

[0909] 在一实施例中，收发机是混合信号ASIC，与助听器一起使用，以在左右助听器间以无线方式传送设置信息，并在无线设备和助听器间传送双向语音、单声道、双声道的单向音频和双向程序设计数据。在一实施例中，它使用约700MHz以上的免许可频段中的300KHz信道。此ASIC包括：频率合成器；发射和接收RF电路；用于执行比特和帧同步、发射接收控制和其他数字功能的MAC；以及连接至伴随助听器的串行接口。

[0910] 在一实施例中，收发机将在300KHz宽的信道上，采用时分复用方式，发送和接收经GFSK调制的数字数据。可以在不背离本主题范围的前提下，采用其它传输实施例。利用寄存器对信道频率和其他特征进行配置，其中必须通过SSI端口对寄存器进行编程。寄存器程序设计允许选择性地关闭IC以节约能量。清除信道分配(CCA)包括由程序控制的、并由逐次逼近模拟数字转换器进行了数字化的接收机信道的RSSI强度。收到的和发送的数据将由MAC加以处理。

[0911] 在一实施例中，收发机必须能调谐至预先确定的一组6个彼此间隔606KHz的信道。发射机由高斯滤波器、电压控制振荡器(VCO)和功率放大器(PA)组成。待发送的数据输出至单比特D-A转换器，后者的输出被施加于带宽≈300KHz的高斯滤波器。将此信号与PLL的环路滤波器电压相加，然后再将结果施加于VCO的输入。在发射时，暂时打开在正常运行时驱动VCO的PLL环路滤波器，以便PLL环不会试图追踪包含已调制数据的高斯滤波器输出所施加的电压。从而，用+/-46.545KHz的频偏对VCO进行频率调制。调制类型是BT＝.5的高斯连续相位2FSK。通过设置施加于VCO的已调制信号的增益，控制调制指数。VCO具有大约10MHz/v的Kv电压，因此大概需要4.6mvp-p的信号，以实现指定的频偏。必须在各工作频率上调整此增益参数(调制指数)，以实现指定的频偏。

[0912] 将已调制信号施加于具有可编程功率输出设置的功率放大器，可以通过控制偏置电流的寄存器控制功率输出设置，偏置电流的控制范围从100到1500uA，步长为100uA。频率范围可从约700MHz以上调谐至约965MHz。这覆盖了世界上大多数国家的ISM频段的中频。

[0913] 所属领域技术人员容易意识到，可以在不背离本主题的前提下采用其他收发机的实施例。

[0914] 虽然此处已阐释并说明了特定的实施例，但是所属领域技术人员应意识到，还可能存在不背离本主题范围的其他实施例。

标题	发布/更新时间	阅读量
基于云技术的智能助听器	2020-05-27	7
一种用于耳背式助听器的指敲机体检测方法	2020-05-14	937
一种性能稳定的耳背式助听器	2020-05-12	133
一种带蓝牙与照明功能的耳背式助听器	2020-05-14	796
耳内受话耳背式助听器的非分离式可变形耳钩	2020-05-13	837
高性能声电转换模组、大功率助听器模块及耳背式助听器	2020-05-24	30
大功率耳背式助听器	2020-05-20	506
一种耳背式助听器	2020-05-15	549
自除潮耳背式助听器	2020-05-16	156
改进的耳背式助听器电路	2020-05-22	126

用于无线音频设备的通信系统

用于无线音频设备的通信系统

技术领域

背景技术

具体实施方式

该功能需要专业版企业版VIP权限，您可以：