低能耗音频流式传输的制作方法

本申请特此要求享有2016年4月8日提交的名称为“lowenergyaudiostreaming”的美国临时专利申请62/320,026(代理人案卷号415.0024p)的权益和优先权，该美国临时专利申请的全部内容通过引用纳入本文(包括其任何附录)。

本公开内容的多个方面涉及通信，并且特别涉及用于有效通信的终端用户装置(device)和应用程序(application)。

背景技术：

多种装置准许音频数据(例如，语音和其他声音)的收集和传输。在一些音频通信系统中，终端用户通信装置(例如，可穿戴装置、免手持装置和/或其他高度便携式装置)允许用户触摸该装置并且因此使用在中间通信装置(例如，智能电话、计算机、游戏装置、平板计算机或其他计算装置)上运行的通信应用程序来通信，该中间通信装置被连接(link，链接)到该终端用户装置并且与该终端用户装置相关联并且被配置为充当用于在相关联的终端用户装置和其他终端用户装置之间通过通信网络等通信的通道。

这样的便携式终端用户装置可以具有有限的能量源。结果，利用终端用户装置和中间通信装置之间的能量有效的通信并且因此延长终端用户装置中的能量源的有用使用寿命将是有利的。

概览

本文所公开的低能耗(lowenergy，低能，低功耗)音频流式传输(audiostreaming)的实施方式包括使用低能耗通信(例如，低能耗蓝牙(“ble”))使得能够实现便携式终端用户装置和相关联的通信装置之间的音频数据的低能耗通信的系统、方法和软件。创建音频数据(例如，使用被称为“源”装置的终端用户装置中的拾音器和处理系统等将收集的声信号转换成数据)，并且通过循环更新和传输含有表示该音频数据的数据值的ble特性来在终端用户装置之间(例如，在终端用户“源”装置和终端用户“宿”装置之间)以及在它们的相关联的中间通信装置之间传输该音频数据。由终端用户源装置发送的ble特性作为音频数据分组(packet，包)片段发送，所述音频数据分组片段由该终端用户源装置的中间通信装置组装成音频数据分组(例如，16khz音频分组)。可以执行对传输的音频数据的进一步打包(和/或其他处理)(例如，使用封装(envelope，信封)和/或块(chunk))，包括但不限于加密。将最终打包的音频数据从一个中间通信装置传输到一个或多个附加的中间通信装置，例如使用通信网络。

通过通信网络传输的音频数据由连接到终端用户宿装置和/或与终端用户宿装置相关联的至少一个中间通信装置接收。该终端用户宿装置的相关联的中间通信装置接收由该终端用户源装置的中间通信装置发送的打包的音频数据。该数据被解包并且通过循环更新和传输的具有转换成声信号(例如，使用扬声器)的数据值的ble特性以音频数据分组片段的形式传输到终端用户宿装置。

提供本概览是为了以简化的形式介绍一些概念，所述概念将在下文在具体实施方式中被进一步描述。可以理解，本概览不意在识别或强调所要求保护的主题的关键特征或必要特征，也不意在用来限制所要求保护的主题的范围。

附图说明

参考以下附图可以更好地理解本公开内容的许多方面。虽然结合这些附图描述了若干个实施方式，但是本公开内容不限于本文所公开的实施方式。相反，目的是覆盖所有替代方案、改型和等同物。

图1例示了被配置为便于使用低能耗通信的安全通信的一个或多个示例性系统。

图2例示了被配置为执行低能耗音频数据传输的一个或多个通信节点。

图3例示了关于使用ble低能耗通信的音频数据传输的实施方式的表。

图4例示了运作通信系统的一种或多种方法。

图5例示了序列图，该序列图描绘了利用使用ble低能耗通信的音频数据传输的多个通信节点之间的示例通信。

图6例示了利用低能耗音频流式传输经由终端用户装置提供群组通信的计算架构。

具体实施方式

以下描述和相关联的图教导本发明的最佳模式。出于教导发明原理的目的，可以简化或省略最佳模式的一些常规方面。以下权利要求指定了本发明的范围。注意，最佳模式的一些方面可能未落入如由权利要求所指定的本发明的范围内。因此，本领域技术人员将理解根据落入本发明的范围内的最佳模式的变体。本领域技术人员将理解，下文描述的特征可以以多种方式组合以形成本发明的多个变体。结果，本发明不限于下文描述的具体实施例，而是仅由权利要求及其等同物限制。

本文所公开和所要求保护的低能耗音频流式传输的实施方式提供了与作为终端用户装置之间的实时音频数据传输的至少一部分的低能耗蓝牙等的利用有关的设备(apparatus)、计算机可读介质以及方法。现在参考附图描述本公开内容的多个方面，其中相同的附图标记始终用于指代相同的元件。在以下描述中，出于解释的目的，阐述了许多具体细节以提供对一个或多个方面的透彻理解。然而，应理解，可以不用这些具体细节或用其他方法、部件、材料等来实践本公开内容的某些方面。在其他情况下，以框图形式示出了众所周知的结构和装置以便于描述一个或多个方面。

低能耗音频流式传输的实施方式利用通信节点之间的低能耗通信，所述通信节点每个包括一个终端用户装置(即，端点通信装置)和与端点装置相关联的一个中间通信装置(例如，智能电话、游戏装置、平板计算机、膝上型计算机和/或其他类型的计算机)。该中间通信装置(icd)可以运行协调配对的终端用户装置(eud)和中间通信装置(它们一起可以被认为是一个通信节点的全部或一部分)之间的通信的通信应用程序。在一些实施方式中，使用一组低能耗蓝牙(ble)特性在终端用户装置和中间通信装置之间传输音频数据，所述低能耗蓝牙(ble)特性被循环更新，并且被传输到终端用户装置或从终端用户装置传输，这分别取决于终端用户装置是在接收音频数据还是在发送音频数据。可以使用数据分组、数据封装、数据块或其他合适的格式经由通信网络等在icd之间传输音频数据，并且可以将音频数据加密。

使用ble特性传输的音频数据被打包成音频数据分组片段以用于ble传输。由中间通信装置从其相关联的终端用户装置(终端用户“源”装置)接收的音频数据分组片段被组装成音频数据分组(例如，使用opus音频编解码器)。对音频数据的进一步打包(和/或其他处理)可以在中间通信装置之间的网络输送之前发生(例如，在一些实施方式中，广播icd可以经由网络将打包的审计数据传输到多个接收icd)。由中间通信装置接收的音频数据可以被解包，并且同样地使用音频数据分组片段(例如，使用ble)传输到其相关联的终端用户装置(终端用户“宿”装置)。通过控制由终端用户装置生成或由终端用户装置接收的音频数据分组片段的更新(即，写入)的定时和/或缓冲，可以在这样的终端用户装置之间流式传输音频数据。

图1例示了示例性低能耗音频流式传输系统100，该系统被配置为尤其便于通信网络上的端点装置之间的安全音频通信。系统100包括通信节点130(该通信节点包括终端用户装置110和通信装置120)、通信节点170(该通信节点包括终端用户装置160和通信装置150)、通信节点190(该通信节点包括终端用户装置191和通信装置193)、标准音频装置通信节点180，以及节点130、170、180、190所连接144到的通信网络140。

通信节点130中的中间通信装置120通过低能耗通信链路142与其相关联的终端用户装置110通信，并且使用通信网络140通过网络通信链路144进一步通信到节点130外部。通信节点170中的通信装置150也使用低能耗通信链路142与其相关联的终端用户装置160通信，并且使用通信网络140通过网络通信链路144进一步通信到节点170外部。类似地，通信节点190中的通信装置193使用低能耗通信链路142与其相关联的终端用户装置192通信，并且使用通信网络140通过网络通信链路144通信到节点190外部。

如本文更详细描述的，可以使用低能耗通信链路142来执行音频数据的低能耗分组片段传送，以在作为端点装置的终端用户装置110、160之间提供音频数据流式传输以及用于其他目的(例如，在一些实施方式中终端用户装置可以选择使用此低能耗通信模式或使用某种其他模式)。通信节点180中的标准音频装置同样可以使用一个或多个通信网络链路144经由通信网络140与中间通信装置120、150通信。也就是说，在一些实施方式中，音频数据可以在一个节点中使用低能耗音频流式传输来生成，并且可以被传输到不利用低能耗音频流式传输的另一个节点，反之亦然(音频数据可以在一些实施方式中由实施低能耗音频流式传输的节点接收，并且如此被传输到该接收节点的端点装置)。

将中间通信装置120连接到通信网络140的通信链路144可以使用以下中的一个或多个：时分复用(tdm)、异步传输模式(atm)、ip、以太网、同步光纤网络(sonet)、混合光纤-同轴电缆(hfc)、电路交换、通信信令、无线通信或某种其他通信格式，包括其改进。将中间通信装置150、193连接到网络140的链路144类似地运作。通信链路144每个使用金属、玻璃、光学、空气、空间或某种其他材料作为输送介质，并且每个可以是直接链路，或可以包括中间网络、系统(包括一个或多个管理服务系统)或装置，并且可以包括通过多个物理链路输送的逻辑网络链路。

每个中间通信装置120、150、193可以包括能够运行通信应用程序并且能够使用因特网或某个其他分布广的通信网络与通信网络140通信的智能电话、游戏装置、平板计算机、计算机或某种其他通信装置(其中的任何一个可以是与图6一致的计算架构)。当传输和接收音频数据时，通信装置120、150、193可以使用适当的音频数据传送方案(例如，opus音频编解码器和opus的增强实施方式)。

通信网络140可以包括能够向多个通信节点以及其相应的端点装置(诸如终端用户装置110、160、191和节点180中的标准音频装置)提供通信服务的利用一个或多个计算装置的服务器系统。终端用户装置110、160、191每个可以包括扬声器、拾音器、处理系统、通信接口和用户接口，以分别与通信装置120、150、193交换通信，并且因此与通信网络140和多种类型的其他端点装置交换通信。

根据ble音频流式传输的一个或多个实施方式，网络140的端点装置包括终端用户装置110、160、191。在一些实施方式中，这些终端用户装置可以是可穿戴的并且作为即按即说(ptt)装置运作。更具体地，图1中例示的一些实施方式提供终端用户装置110、160、191之间的分别经由通信节点130、170、190中它们的配对的相应的中间通信装置120、150、193通过网络140的通信。在由图1例示的其他非限制性实施例中，终端用户装置110可以经由通信装置120和网络140与标准音频装置(例如，节点180中的装置)交换音频数据(发送和/或接收)，而不管该标准音频装置是否利用如本文所描述的、终端用户装置和中间通信装置之间的低能耗分组片段传送。

在运作中，中间通信装置120、150、193可以使用含有音频数据的离散分组通过网络链路144经由网络140传输音频数据。例如，在使用opus音频编解码器的非限制性实施例中，可以传输1-40个字节的音频数据分组，其中每个音频数据分组表示20毫秒的音频。一个流由使用网络140传输的一系列音频数据分组(例如，被表示为a、b、c、d、e、......)组成。分别可以在每个通信装置120、150、193上的前台或后台中运作的移动通信应用程序125、155、195负责打包和解包使用网络140传输的音频数据。

当终端用户装置110、160、191发送音频数据时，发送装置被称为“源”终端用户装置，并且当终端用户装置110、160、191接收音频数据时，它被称为“宿”终端用户装置。每个终端用户装置与其相应的中间通信装置之间的低能耗通信链路142可以使用低能耗蓝牙来实施，低能耗蓝牙不必需具有特定的音频数据传输模式并且不一定被设计为处理opus和其他标准音频数据传送方案。而是，在本文所公开的低能耗音频流式传输的实施方式中，ble链路适于利用ble特性、属性、服务等来实施如本文所描述的音频数据传送。

在低能耗蓝牙中，通用属性配置文件(gatt)被建立在属性协议(att)之上，两者都被用于发现服务。gatt为通过att输送和存储的数据建立通用操作和框架，并且定义了两个角色：服务器和客户端(att定义了逻辑链路控制和适配协议上ble服务器和客户端之间的通信)。ble客户端向ble服务器发送两种类型的非请求型消息(unsolicitedmessage，非引发性消息)——客户端“命令”(对于其，不要求服务器回复)和客户端“请求”(其要求ble服务器通过发送服务器“响应”来回复)。ble服务器向ble客户端发送两种类型的非请求型消息——“服务器通知”(对于其，不要求客户端回复)和服务器“指示”(其要求ble客户端通过发送客户端“确认”来回复)。在一些实施方式中利用此通信方案的ble链路142由中间通信装置120中的应用程序125建立和维护，并且类似地分别由中间通信装置150、193中的应用程序155、195建立和维护。

在利用ble的音频流式传输的一些实施方式中——所述实施方式的一个或多个非限制性实施例被示出在图2中，终端用户装置210(其可以是图1的装置110、160、191中的一个)充当gatt服务器，并且中间通信装置220(运行通信应用程序225，该通信应用程序可以是图1的应用程序125、155、195中的一个)充当gatt客户端，两者都被包括在通信节点230(其可以是图1的节点130、170、190中的一个)中。在图2中，终端用户装置(gatt服务器)210通过ble242连接到中间通信装置(gatt客户端)220。因此，终端用户装置(gatt服务器)210存储通过att输送的数据，并且接受来自中间通信装置(gatt客户端)220的att请求、命令和确认。当终端用户装置(gatt服务器)210上发生指定事件(例如，用户发起的发送和接收音频数据)时，终端用户装置(gatt服务器)210可以异步地向中间通信装置(gatt客户端)220发送指示和通知，并且作为对来自装置220的请求的回复，该终端用户装置向装置220发送响应。因此，gatt请求和响应243被配对，gatt通知和确认244也是如此。

gatt还指定gatt服务器(图2中的装置210)上容纳的数据的格式。属性由att输送并且被格式化为特性(例如，单个数据值和描述特性值的描述符，其几个非限制性实施例被示出在图3中的表a和表d中)和服务(例如，特性的集合，诸如图3中的表a和表d的“orion”音频数据传送服务)。在低能耗音频流式传输的一些实施方式中，诸如终端用户装置110、160、191的端点装置可以充当gatt服务器以分别实施音频数据到(和通过)连接的中间通信装置(gatt客户端)120、150、193的传输，并且也可以充当gatt服务器以实施如本文所教导的从(和通过)连接的中间通信装置(gatt客户端)接收音频数据。

图1中系统100的非限制性示例性实施方式例示了音频数据从终端用户装置110到终端用户装置160的传输。因此，在这样的实施例中，终端用户装置110是终端用户“源”装置，并且在这样的实施方式中，终端用户装置160是终端用户“宿”装置。然而，如本文所描述的终端用户装置(无论是源装置还是宿装置)与中间通信装置之间的低能耗分组片段传送的优点之一是，利用低能耗分组片段传送的其他实施方式是可能的，所述其他实施方式不要求全部参与的端点装置都利用低能耗连接和音频数据传送，如本领域技术人员将理解的(例如，从利用低能耗分组片段传送的终端用户装置到不利用低能耗分组片段传送的标准音频装置的传输，反之亦然)。

诸如可使用链路144在通信网络140上传输的opus音频编解码器分组的个体音频分组可能不能够使用低能耗链路142(例如低能耗蓝牙)来发送。在终端用户源装置和中间通信装置之间利用ble等的情况下，该源装置将音频数据分组中会含有的数据分配给音频数据分组片段，其中在音频数据传送的整个运作过程中，每一个音频数据分组由n个音频数据片段组成。因此，如果每一个音频数据分组由2个片段组成，则所述片段作为有次序的片段对相关联。类似地，由3个有次序的片段组成的音频数据分组则作为片段三元组等相关联。每个音频数据分组中有n个有顺序的数据片段。

在采用ble作为每个低能耗通信链路142的系统100的非限制性实施例中，每个音频数据分组包括2个音频数据分组片段。当用户使用终端用户装置110开始传输音频时，使用ble(例如，音频传输状态)在终端用户装置110中更新“即按即说”(ptt)或类似的gatt属性，如在图3的表a中看到的。ptt属性的更新可以从终端用户装置(gatt服务器)110发送到中间通信装置(gatt客户端)120作为gatt通知或指示以提醒装置120和应用程序125音频数据传输正在开始，在此之后利用附加的gatt特性(例如，指定为源0、源1、源2、源3或s0、s1、s2、s3的4个特性(字节数组))的数据传输过程开始。如果示例性源x特性是专有的，则用户定义的uuid可以被用于ble，如在图3的表a中看到的。

在此实施例中，装置120上的通信应用程序125订阅表a中示出的至少所有5个gatt特性(即，ptt和4个源x特性)。如果每个源x特性容纳最多达20个字节，则可以使大小为1-40个字节的分组成片段，如在图3的表b中在一个非限制性实施例中示出的。虽然在此实施例中在终端用户源装置110中生成音频数据，但是gatt源x属性被循环更新(写入)以将音频数据从终端用户源装置110持续地移动到其相关联的中间通信装置120。再次，从终端用户源装置110到中间通信装置120的传输可以作为ble指示或ble通知发送(中间通信装置120传输对其的ble确认)。当通信装置120上的通信应用程序125从源终端用户装置110接收对源x特性的更新时，应用程序125收集配对的片段(在此实施例中，源0和源1被配对，如同源2和源3被配对)以组装音频数据分组以用于在通信链路144上传输。例如，在接收源0字节数组和源1字节数组后，这两个字节数组被组装成音频数据分组a。类似地，在组装音频数据分组a之后，源2字节数组和源3字节数组被重新组装成音频数据分组b，其中在一些实施方式中每个音频数据分组可以是opus音频编解码器分组。接下来的两个音频数据分组片段是更新的源0字节数组和源1字节数组，这两个字节数组再次被组装，这次被组装成音频数据分组c。在组装音频数据分组时执行的通知和动作可以接着，如图3的表c中示出的。

如在图3的表c的非限制性实施例中看到的，如果通信应用程序125接收对源0的更新，接着接收对源2的更新，并且然后接收对源3的更新，则应用程序125识别它丢失了或未能接收一个片段(对源1的更新)，因此应用程序125可以丢弃源0字节，但是保留源2和源3中的字节。如果在一行中丢失多个片段，则应用程序125可以例如看到源0接着看到源3或甚至再次看到源0。应用程序125可以对丢失的片段的数目进行最佳估计，并且使正确数目的遗漏片段指示符排队(例如，2个或3个)。在丢失4个片段的不太可能的情况下，应用程序125可能会看到源0接着是源1，因此未意识到任何错误。例如，在使用opus音频编解码器的情况下，这样的事件可能导致由畸形的音频数据分组造成的音频故障，该畸形的音频数据分组例如由与音频数据分组c的第二片段组装成一个分组的音频数据分组a的第一片段组成。这可能导致乱码噪声，但是不会造成任何长期问题；系统100最终将在几个分组之后恢复。一旦音频数据分组被组装，它们就可以被放入封装内。然后，使这些分组填充的封装沿着输送流向下发送。

终端用户宿装置行为与终端用户源装置的行为对称。在图1中例示的一个非限制性实施例中，经由链路144发送的、输送封装的形式的音频数据分组由通信节点170中的中间通信装置150接收并且在该中间通信装置处被拆开，其中通信应用程序155正在运行(再次，在前台或后台中)。应用程序155更新gatt中的ptt属性(例如，在中间通信装置中和/或在终端用户装置中)，并且开始使用对附加的gatt特性(例如，指定为宿0、宿1、宿2、宿3或s0、s1、s2、s3的4个字节-数组特性(再次，用户定义的uuid可以用在这些的ble定义中)，如在图3的表d中看到的)的更新来流式传输分组片段(例如，通过将opus音频编解码器音频数据分组分成片段而获得的)。在此实施例中，应用程序155订阅所有5个gatt特性。因此，终端用户装置160从通信装置150接收音频数据分组片段，并且再现(render)音频数据(例如，组装配对的音频数据分组片段：宿0和宿1、宿2和宿3)，所述音频数据可以作为声信号在终端用户装置160上被广播。可以使用ble请求、ble命令和/或ble确认将音频数据分组片段从中间通信装置(gatt客户端)150发送到终端用户宿装置(gatt服务器)160。

如果在使用ble输送将使用通信协议(例如，超文本传输协议安全输送)传输的音频数据分组(例如，opus分组)传输到终端用户装置160之前，应用程序155管理该音频数据分组的递送，则通信装置150和/或应用程序155必须确保ble输送不被音频数据分组淹没。因此，在一些实施方式中，可以使用缓冲器和/或定时器来适应任何潜在的定时差异。

当使用gatt通过ble发送音频数据分组时，使用4个特性即宿0、宿1、宿2、宿3(例如，它们每个可以容纳最多达20个字节)。如结合

图3的表b所述的，例如，具有总共30个字节的音频数据的音频数据分组a可以由20个字节的第一片段和10个字节的第二片段组成。音频数据分组b、c和d同样可以分成类似的片段组成部分，如在表b中看到的。当接收音频数据分组时，读取器可以使用s0、s1、s2、s3、s0、s1、s2、s3、s0、s1、s2、s3...序列以检测分组丢失。这要求为一个或多个片段(例如，图3的表b中的分组c中的0字节的源1片段)写入0字节值，以避免错误地检测丢失的分组。

每个gatt写入可以由应用程序155定时，以使得gatt写入在先前gatt写入之后至少规定时间间隔(例如，10ms的“写入间隔”)发生。如果操作系统唤醒一个线程非常晚(例如，100ms之后)，则接下来的4个gatt属性可以一个快速序列被写入(即，它们之间没有额外的延迟)，但是同一属性永远不会在同一10ms写入间隔内被写入两次。

在一些实施方式中当终端用户装置110正在传输音频数据时，装置120的通信应用程序125可以使用适当的过程(例如，http1.1分块，其在传输开始之前发送器不一定知道传输的内容的长度时便于数据传送)发送数据到其输送流。在使用http分块的情况下，http块可以大约每100毫秒结束(goout)(即，每秒10个分组，每个http块具有～200字节的opus+封装)。字节可以被缓冲在应用程序代码中，并且然后在100ms消逝之后被写入http类。替代地，如果相关的http库存在并且可以相应地运作，则可以使用缓冲流和.flush()过程。

在一些实施方式中，多个opus分组可以进入单个http分块的数据块，其中存在正确的封装字节以使得能够通过接收通信应用程序155进行正确的分组解包。分组构建时间管理在两个方向上提供优势，避免了太频繁地数据打包并且避免了太频繁地执行数据打包。例如，通过每秒仅10次而不是以更高的速率(例如，每秒50次)调用http，通过在更多有用的数据字节上分摊散列开销来减少https开销。此外，这避免了太频繁地创建新的tcp分组(并且因此也避免了太频繁地创建wifi/3g/lte分组)，并且避免了由于处理许多较小的分组而导致服务器上的过多cpu负荷。相反，通过每秒至少10次而不是以更慢的速率(例如每秒一次，或每4kb数据一次)启用http，避免了引入过多的音频流延迟，同时允许系统更响应于改变的网络条件(例如，通过快速注意网络延迟何时发生)。

将接收的音频数据分组递送到终端用户装置的应用程序155可以执行若干个步骤以改善音频数据递送质量。例如，当从网络输送接收音频数据分组时，接收应用程序可以尽快将第一分组递送到ble，将它写入宿0/宿1(例如，其间具有10ms的写入间隔)。此外，如果在间隔到了之前接收到更多分组，可以使这些附加的分组排队。同样，如果在间隔允许处理时队列中没有分组，则接收应用程序可以等待附加的分组到达。如果在规定的等待周期之后没有什么到达，则适当的状态gatt特性可以被更新并且应用程序停止处理。如果存在大量等待并且附加的音频数据分组的确到达，则可以在再次调用间隔定时器之前立即写入一串音频数据分组(例如，每个宿x属性一个)。通过评估随着时间的过去的突发行为(例如，研究操作系统错误日志等)，可能能够减轻这样的行为。

图4例示了第一终端用户装置和第二终端用户装置之间的低能耗音频流式传输的一种或多种方法。如结合图1-图3所描述的，通信装置可以包括智能电话、计算机、平板计算机、游戏装置或被配置为通过通信网络通信并且被配置为管理或控制通信装置和端点装置(诸如终端用户装置)之间的低能耗音频流式传输的任何其他计算装置。不是使用通信装置来与组织或用户所期望的特定群组通信，在低能耗音频流式传输的一些实施方式中，每个终端用户装置可以与连接的(相关联的)中间通信装置上的应用程序结合使用以提供所期望的通信。

为了实现这些终端用户装置之间的低能耗音频流式传输，使用低能耗传输(例如，低能耗蓝牙)并且因此使用任何合适的技术通过通信网络在每个终端用户装置与其相关联的中间通信装置之间传输音频数据。为了开始过程400，在终端用户源装置和与终端用户源装置相关联的中间通信装置之间建立低能耗通信信道(例如，低能耗蓝牙)(410)。当ptt属性被更新为“开着(on)”以开始音频流式传输时(415)，终端用户源装置开始生成音频数据(420)，例如通过收集和/或接收由终端用户源装置中的拾音器捕获的语音和其他声信号并且将声信号转换成音频数据流。该音频数据流然后被分割成多个音频数据分组片段并且被打包为多个音频数据分组片段，所述多个音频数据分组片段被循环更新并且使用低能耗通信链路(诸如ble)传输(430)到与终端用户源装置相关联的中间通信装置(425)。然后，相关联的中间通信装置通过将接收的音频数据分组片段组装成音频数据分组来生成音频数据分组(430)，其中每个音频数据分组由n个分组片段组成。如在图4中注意到的，音频数据分组片段可以是ble字节-数组特性，所述ble字节-数组特性被循环更新并且使用ble通知、指示和/或响应从终端用户源装置(例如，作为gatt服务器)传输到其相关联的中间通信装置。此循环属性更新和从终端用户源装置到中间通信装置的传输继续，直到ptt属性被切换为“关着(off)”。然后可以将组装的音频数据分组进一步组装成封装和/或块(435)。这样的进一步的数据打包还可以包括将组装的数据加密。在步骤435之后，终端用户源装置对音频数据的处理通过返回以检查ptt属性是否仍为“开着的”而继续，同时打包的音频数据被发送下去以用于在网络输送上传输。可以在通信节点(诸如图1的节点130)内执行步骤410到435。

然后，将组装的分组、封装和/或块从与终端用户源装置相关联的中间通信装置传输(440)到与终端用户宿装置相关联的另一中间通信装置(例如，使用通信网络，诸如图1的网络140)。此第二中间通信装置将接收的数据解包，以生成音频数据分组片段(445)。这些生成的片段可以与由终端用户源装置生成的音频数据分组片段相同，或可以是不同的片段格式。如果适当的ble属性(例如，ptt)准许将音频数据传送到相关联的终端用户装置(450)，则将音频数据从第二中间通信装置转发到其相关联的终端用户宿装置。再次，在一些实施方式中，音频数据分组片段可以是音频数据分组片段可以是ble字节-数组特性，所述ble字节-数组特性被循环更新并且使用ble请求、命令和/或确认从其关联的中间通信装置传输(455)到终端用户宿装置(例如，作为gatt客户端)。然后，音频数据分组片段由终端用户宿装置转换回声信号(460)。如所述，可以根据opus音频编解码器或任何其他合适的协议、技术等来执行音频数据分组、封装和/或块的传输。解包和音频数据分组片段的ble传输继续，直到传输暂停(例如，通过切换适当的ptt属性(460)和/或以某种其他方式)。

图5例示了一个序列图，该序列图描绘了经由通信网络(诸如，图1的网络140)连接的多个通信节点之间的示例性通信。具体地，图5的示例性过程描绘了使用终端用户装置到中间通信装置的低能耗蓝牙连接以用于流式传输音频数据。

开始，在终端用户源装置510和其相关联的中间通信装置520之间建立低能耗通信信道(例如，ble信道)。装置520可以正在运行使用低能耗信道来实施、管理和/或以某种其他方式控制装置510和装置520之间的低能耗通信的应用程序等。在步骤1处，终端用户#1打开音频流式传输功能(例如，使用即按即说(ptt)选择)，该音频流式传输功能可以被传输到通信系统中的多个装置(例如，两个终端用户装置510、560以及两个中间通信装置520、570)。在步骤2处由用户#1生成声信号，并且这些声信号可以由终端用户装置510中的拾音器收集并且被转换成音频数据，然后在步骤3中将该音频数据打包成音频数据分组片段。在步骤4处将所述音频数据分组片段从终端用户源装置510传输到中间通信装置520，在此所述片段被用来生成音频数据分组并且在一些实施方式中可能生成音频数据封装和/或块。也可以在打包过程中的适当阶段将音频数据加密。

在步骤6处，经由网络540将打包的音频数据传输到一个单独的通信节点中的第二中间通信装置570。应该记住，在一些实施方式中可以经由网络540将打包的音频数据传输到使用低能耗音频流式传输的多个通信节点和用户。音频数据分组片段在步骤7处在中间通信装置570内生成，并且然后在步骤8处被传输到终端用户宿装置560。装置560在步骤9处生成声信号，所述声信号然后可以被广播给用户#2。通过将字节数组ble特性按顺序更新和写入，可以循环地继续将音频数据打包成音频数据分组片段和其他数据结构(例如，音频数据分组、封装、块)和从音频数据分组片段和其他数据结构(例如，音频数据分组、封装、块)解包出音频数据。ble请求、响应、命令、指示、通知和/或确认可以被用来在各配对装置(即，终端用户装置和其相关联的中间通信装置)之间传输以ble特性保持的数据。

图6例示了用于实施图1-图5中的通信系统、装置、设备和过程的计算架构600。计算架构600可以表示这样的计算架构：该计算架构可以被用作任何计算设备、系统或装置，或其集合，以适合地实施图1-图5中的系统、装置、设备和过程中的一个或多个(包括但不限于，终端用户装置、中间通信装置、通信网络部件和系统等)。计算架构600包括网络通信接口601、低能耗通信接口602、用户接口603和处理系统604。处理系统604被通信地连接到通信接口601、602和用户接口603。处理系统604包括处理电路系统605和存储装置606，该存储装置存储操作软件607(包括通信应用程序615，该通信应用程序可以与应用程序125、155、195、225相同或类似和/或可以被配置为执行与如图4中示出的过程相同或类似的过程)。

网络通信接口601包括通过网络和相关通信链路(例如，包括在通信节点外部延伸的那些)通信的部件，诸如网卡、端口、rf收发器、处理电路系统和软件，或一些其他通信装置。网络通信接口601可以被配置为通过金属链路、无线链路或光学链路通信。网络通信接口601还可以被配置为使用tdm、ip、以太网、光网络、无线协议、通信信令或某种其他通信格式——包括其组合。低能耗通信接口602包括使用低能耗信道(诸如低能耗蓝牙)通信的部件。用户接口603包括准许用户与计算架构600交互的部件。用户接口603可以包括键盘、显示屏、鼠标、触摸板或某种其他用户输入/输出设备。在一些实施例中可以省略用户接口603。

处理电路系统605包括从存储装置606检索并且执行操作软件607的微处理器和其他电路系统。存储装置606包括非暂时性存储介质，诸如磁盘驱动器、闪存驱动器、数据存储电路系统或某种其他存储设备(例如，非暂时性计算机可读存储介质，所述非暂时性计算机可读存储介质具有存储在其上的被配置为如本文所描述的那样运作的通信应用程序)。操作软件607包括计算机程序、固件或某种其他形式的机器可读处理指令。操作软件607可以包括任何数目的软件模块，以提供本文所描述的通信操作。操作软件607还可以包括操作系统、实用程序(utility)、驱动程序、网络接口、应用程序或某种其他类型的软件。当由电路系统605执行时，操作软件607指挥处理系统604如本文所描述的那样运作计算架构600，以提供低能耗音频流式传输和其他通信。

包括的描述和图描绘了教导本领域技术人员如何作出和使用最佳选项的具体实施方式。出于教导发明原理的目的，已经简化或省略了一些常规方面。本领域技术人员将理解根据这些实施方式的落入本发明的范围内的变化。本领域技术人员还将理解，上文描述的特征可以以多种方式组合以形成多个实施方式。结果，本发明不限于上文描述的具体实施方式，而是仅由权利要求以及其等同物限制。