CN115398947A - 用于在无线通信系统中进行云认证配对的方法、设备和计算机程序及其记录介质 - Google Patents

Abstract

本公开内容涉及用于在无线通信系统中进行云认证配对的方法、设备和计算机程序及其记录介质。根据本公开内容的一个实施方式，用于在无线通信系统中执行基于帐户的配对的方法可以包括以下步骤：搜索者设备从服务器获取提供者设备的凭证信息；搜索者设备从提供者设备获取广告分组，该广告分组包括基于凭证信息的散列值；以及搜索者设备根据所获取的凭证信息和基于所获取的凭证信息的散列值来与提供者设备建立连接。

Description

用于在无线通信系统中进行云认证配对的方法、设备和计算 机程序及其记录介质

技术领域

本公开内容涉及在无线通信系统中进行云认证配对的方法、装置、计算机程序及其记录介质。

背景技术

蓝牙是一种短程无线通信标准，并且包括BR(基本速率)/EDR(增强数据速率)技术和LE(低功耗)技术。BR/EDR也被称为蓝牙经典，并且包括由蓝牙1.0应用的BR技术和由蓝牙2.0应用的EDR技术。在蓝牙4.0之后应用的蓝牙LE(BLE)是一种支持以低功耗发送和接收相对大量的数据的技术。

蓝牙标准包括各种配置文件。例如，免提配置文件(HFP)定义了一个设备用作音频网关(AG)例如智能电话和另一个设备用作免提设备例如耳机的必要条件。另外，A2DP(高级音频分发配置文件)定义了一个设备用作音频源例如音乐回放器和另一个设备用作音频信宿例如扬声器的必要条件。

随着近来无线设备的普及，对在多对多或M对N连接类型的各种拓扑中发送和接收音频数据的需求正在增加。例如，需要5.1通道环境的流式传输服务正在出现，并且正在讨论使用多个蓝牙便携式扬声器来支持5.1通道环境，从而摆脱常规5.1通道专用有线扬声器的限制。然而，由于常规蓝牙音频技术主要是考虑到两个设备之间一对一连接的使用情况而开发的，因此它不适合支持多个设备之间的音频数据发送/接收，并且延迟是一个大问题。另外，随着蓝牙音频设备数量的增加，存在搜索外围设备的功耗增加的问题。

在常规蓝牙系统中，不存在用于提供与新设备配对的自动认证的方法。

同时，在常规蓝牙系统中，没有提供用于提供在多个设备中的每一个中的记录媒体(音频和/或视频)的集成同步的方法。

发明内容

【技术问题】

本公开内容的技术问题是提供一种用于无线通信系统中的新配对目标设备的自动认证方法。

本公开内容的另一个技术问题是提供一种在无线通信系统中的多个设备中的每一个中的媒体记录中的集成同步方法。

本公开内容中要实现的技术问题不限于上面提到的技术问题，并且本公开内容所属领域的普通技术人员将从以下描述中清楚地理解没有提到的其他技术问题。

【技术方案】

根据本公开内容的方面的在无线通信系统中执行基于帐户的配对的方法可以包括：由搜索者设备从服务器获得关于提供者设备的凭证信息；由搜索者设备从提供者设备获得包括基于凭证信息的散列值的广告分组；以及由搜索者设备根据所获得的凭证信息和基于所获得的凭证信息的散列值来与提供者设备建立连接。

根据本公开内容的附加方面的用于在无线通信系统中执行基于帐户的配对的搜索者设备侧上的装置可以包括：收发器，其用于执行与另一装置的信号发送和接收；以及处理器，其用于控制收发器和装置，并且处理器可以被配置成：由搜索者设备从服务器获得关于提供者设备的凭证信息；由搜索者设备从提供者设备获得包括基于凭证信息的散列值的广告分组；以及由搜索者设备根据所获得的凭证信息和基于所获得的凭证信息的散列值来与提供者设备建立连接。

上面关于本公开内容简要概述的特征仅是下面的本公开内容的详细描述的示例性方面，并且不限制本公开内容的范围。

【技术效果】

根据本公开内容，本公开内容的目的是提供一种用于无线通信系统中的新配对目标设备的自动认证方法。

根据本公开内容，可以提供一种在无线通信系统中的多个设备中的每一个中的媒体记录中的集成同步方法。

本公开内容的技术效果不限于上述效果，并且本领域技术人员可以从下面的描述中理解本文中没有提到的其他效果。

附图说明

图1是示例性地示出了常规音频连接类型和本公开内容适用的音频连接类型的图。

图2是示例性地示出了常规音频相关协议和本公开内容适用的音频相关协议栈的图。

图3是示出了本公开内容适用的5.1通道环绕系统硬件的示例的图。

图4是示出了本公开内容适用的音频数据编码/解码处理的图。

图5是示出了本公开内容适用的两个设备的通道分配的示例的图。

图6是用于描述本公开内容适用的两个流的同步延迟的图。

图7是用于描述本公开内容适用的多个设备的广播操作的图。

图8和图9是用于描述本公开内容适用的ICL类型和INCL类型的操作的图。

图10是示出了本公开内容适用的广播音频流状态机的图。

图11是示出了本公开内容适用的音频设置过程的图。

图12是示出了本公开内容适用的链路层状态机的图。

图13是示出了本公开内容适用的音频拓扑的示例的图。

图14至图16是示出了本公开内容适用的客户端与服务器之间的消息交换过程的图。

图17是示出了本公开内容适用的呼叫服务的状态机的图。

图18是示出了本公开内容适用的每个层的分组格式的图。

图19是示出了本公开内容适用的数据单元格式的示例的图。

图20是示出了本公开内容适用的广告单元格式的示例的图。

图21是用于描述可以应用本公开内容的自动认证方法的示例的图。

图22是示出了可以应用本公开内容的广告分组的示例性格式的图。

图23是用于描述可以应用本公开内容的自动认证方法的附加示例的图。

图24是示出了可以应用本公开内容的基于帐户的自动连接的应用示例的图。

图25是用于描述可以应用本公开内容的基于帐户的配对方法的图。

图26是用于描述可以应用本公开内容的媒体同步时钟的图。

图27是用于描述可以应用本公开内容的基于媒体同步时钟的媒体数据同步方法的图。

图28是示出了可以应用本公开内容的第一设备和第二设备的配置的图。

具体实施方式

在下文中，参照附图，将详细描述本公开内容的实施方式，使得本公开内容所属的领域的普通技术人员可以容易地实现它们。然而，本公开内容可以以几种不同的形式被体现，并且不限于本文中描述的实施方式。

在描述本公开内容的实施方式时，如果确定公知配置或功能的详细描述可能模糊本公开内容的主旨，则将省略对其的详细描述。并且在附图中，省略了与本公开内容的描述无关的部分，并且相似的附图标记被附于相似的部分。

在本公开内容中，当组件“连接”、“耦接”或“访问”另一个组件时，它不仅可以包括直接连接关系，而且还包括其中另一个组件存在于中间的间接连接关系。此外，在本公开内容中，术语“包括”或“具有”指出叙述的特征、步骤、操作、元件和/或组件的存在，但是它不排除存在或添加一个或更多个其他特征、步骤、操作、元件、组件和/或其组。

在本公开内容中，诸如“第一”和“第二”的术语仅用于区分一个组件和其他组件的目的，并且不用于限制组件。并且，除非另有说明，否则术语不会限制组件之间的顺序或重要性。因此，在本公开内容的范围内，在一个实施方式中的第一组件在另一实施方式中可以被称为第二组件，并且类似地，在一个实施方式中的第二组件在另一实施方式中可以被称为第一组件。

在本公开内容中，彼此区分开的组件用于清楚地描述每个特性，并不一定意味着组件是分开的。也就是说，可以集成多个组件以形成一个硬件单元或软件单元，或者可以分配一个组件以形成多个硬件单元或软件单元。因此，即使没有具体提及，这样的集成的或分散的实施方式也被包括在本公开内容的范围内。

本公开内容的各种实施方式不旨在列出组件的所有可能组合，而是旨在示出本公开内容的代表性方面，并且各种实施方式中描述的组件中的一些或所有可以独立地或者两个或更多个组合地被应用。也就是说，本公开内容的各种实施方式中描述的组件不一定是指必要的组件，并且一些组件可能是可选组件。因此，由一个实施方式中描述的组件的子集组成的实施方式也被包括在本公开内容的范围内。另外，除了在各种实施方式中描述的组件之外，包括其他组件的实施方式也被包括在本公开内容的范围内。

为了描述清楚起见，本公开内容的示例方法被表示为一系列操作，但这并不旨在限制执行步骤的顺序，并且如果有必要的话，可以同时或以不同的顺序执行每个步骤。另外，为了实现根据本公开内容的方法，除了所示出的步骤之外，还可以包括其他步骤，除了一些步骤之外，还可以包括步骤，或者除了一些步骤之外，还可以包括其他步骤。

本公开内容中使用的术语用于描述特定实施方式，并且不旨在限制权利要求。除非上下文另有清楚地说明，否则如在实施方式的描述中以及在所附权利要求中使用的，单数形式也旨在包括复数形式。此外，在本公开内容中使用的术语“和/或”可以指代相关列举中的一个，或者意在指代和包括其两个或更多个的所有可能(或随机)组合。

本公开内容中使用的术语的定义如下。

音频信宿是从音频源接收音频数据的实体。

音频源是将音频数据发送至音频信宿的实体。

音频通道是编码或未编码的音频数据的单一流。

音频流是单向逻辑通信通道，其携载从音频源流至音频信宿的音频数据。音频数据可以在音频流会话(ASS)上流动。音频流可以携载一个或更多个音频通道的音频数据。

音频组可以包括一个或更多个同步的音频流。

内容类型指示音频组的内容的分类。分类可以包括音频是否由用户发起。内容类型指示音频组的内容的分类。分类可以包括音频是否由用户发起。内容类型的示例可以包括未分类音频(UncategorizedAudio)、铃声(Ringtone)、系统声音(SystemSound)、卫星导航(Satnav)、呼叫音频(CallAudio)、媒体(Media)等。

元数据是描述和提供音频数据的上下文的可变长度数据。可以针对较高层定义元数据。

音频流会话(ASS)是指音频流的单向或双向传输/交换过程。ASS的端点对应于音频流会话的音频输入和/或音频输出，并且可以对应于一个设备或一组设备。ASS的末端驻留在服务器上，并且可以由服务器或客户端来配置。服务器可以存储、改变和管理ASS状态。

QoS(服务质量)是指音频流的服务质量并且可以对应于对特定服务的要求。

音频位置是指打算用于呈现音频的设备的空间布置内的音频通道的逻辑空间呈现位置。例如，耳机的左位置和右位置可以对应于音频位置。音频位置可以被分配给音频通道。

CBIS(基于连接的等时流)是在核心层中定义的术语，并且是与ASS服务中的音频流相对应的概念。单向CBIS可以具有一个音频流，并且双向CBIS可以具有两个音频流。

CBISS(基于连接的等时流集)是在核心层中定义的术语，并且是与ASS服务中的音频组相对应的概念。

音频场景应用(ASA)是指执行特定内容类型的音频组。

ASC(音频流能力)是配置音频会话能力所需的参数集。

音频广告是为了发现ASA参与的可用性。音频通用广告是不指定目标的音频广告，并且音频定向广告是针对特定目标的音频广告。

等时数据是指受时间限制的数据。例如，等时数据可以是时间相关的音频比如需要相对于视频的图像被同步的电视音频或者需要在构成多通道的多个设备中被同步和被再现的音频。

等时通道是指用于将等时数据从发送设备发送至一个或更多个接收设备的逻辑发送端。

等时流是指携载一个或更多个等时通道的逻辑链路。

图1是示例性地示出了常规音频连接类型和本公开内容适用的音频连接类型的图。

图1(a)示出了BR/EDR音频连接类型的示例。在BR/EDR的情况下，支持一对一连接类型。一个设备(例如，智能电话)可以用作中央设备，并且可以与若干个设备中的每一个一对一连接。也就是说，可能存在多个一对一连接。因此，可以支持诸如通过耳机的电话呼叫或通过扬声器的音乐再现的服务。这种连接类型中的服务的中心是音频源，并且音频信宿(audio sink)例如耳机、扬声器和AVN(音频视频导航)可以作为音频源的外围设备进行操作。

图1(b)示出了BLE音频连接类型的示例。在BLE的情况下，可以支持多对多连接。在这种情况下，可以存在多个中心设备例如TV、智能电话和网关等，并且可以配置复杂的M对N连接。因此，可以支持通过耳机的电话呼叫和音乐再现的服务，并且可以支持广播音频服务，例如闹钟、门铃和广告语音。这种连接类型中的服务的中心是音频信宿，并且可以通过移动多个音频源来使用音频服务。

图2是示例性地示出了常规音频相关协议栈和本公开内容适用的音频相关协议栈的图。

图2(a)示出了音频相关协议栈的示例。L2CAP(逻辑链路控制和适配协议)层在上层与下层之间起到仲裁和调解的作用。在上层中，可以包括诸如RFCOMM(射频通信)、AVDTP(音频/视频分发传输协议)、AVCTP(音频/视频控制传输协议)等的协议和诸如HFP(免提配置文件)、A2DP(高级音频分发配置文件)、AVRCP(音频/视频远程控制配置文件)等的配置文件。下层可以包括MAC/PHY层。MAC(媒体访问控制)层可以包括链路管理器和链路控制器，并且PHY(物理)层可以包括BR/EDR无线电。另外，面向同步连接(SCO)/扩展SCO(eSCO)可以提供用于语音的同步数据通信路径。因此，在BR/EDR中，可以为每个配置文件设计协议栈。L2CAP层、BR/EDR协议、通用访问配置文件(GAP)和BR/EDR配置文件层可以被统称为主机层，并且链路管理器、链路控制器和BR/EDR无线电层可以被称为控制器层。主机与控制器之间的接口可以被称为HCI(主机控制器接口)。

图2(b)示出了BLE音频相关协议栈的示例。与为每个配置文件配置协议的BR/EDR不同，在BLE中，可以设计用于各种配置文件的通用协议栈。该通用协议栈可以被称为中间件。例如，可以配置以中间件形式的用于诸如助听器、高质量音频/音乐、语音识别和呼叫/媒体的各种配置文件的通用协议。例如，中间件可以包括诸如设备发现、流控制(或流管理)、编解码器和遗留管理的协议。另外，核心层可以包括链路层(Link Layer，LL)、LE无线电(即，PHY层)，并且LL可以包括与由蓝牙5定义的多播支持等时通道相关的功能。

另外，配置文件和中间件可以被称为主机层，核心层可以被称为控制器层，并且可以在主机与控制器之间定义HCI。

除了图2(b)中示出的主机配置文件和协议之外，主机可以包括LE配置文件、通用访问配置文件(GAP)、通用属性配置文件(GATT)、属性(ATT)协议、安全管理器(SM)等。

从主机发送至控制器的信息可以被称为HCI命令分组。从控制器发送至主机的信息可以被称为HCI事件分组。另外，可以在主机与控制器之间交换HCI异步数据分组或HCI同步数据分组。

此外，除了图2(b)中所示的中间件配置文件和服务之外，中间件还可以包括如下各种配置文件和/或服务：

音频会话能力服务(ASCS)：音频会话能力服务(ASCS)是支持与音频会话相关的广告或发现能力的服务；

音频流会话服务(Audio Stream Session Service，ASSS)：音频流会话服务(ASSS)是支持与音频会话相关的发现、设置、建立、控制和管理的服务；

音频输入管理服务(AIMS)：用于管理音频输入音量等的服务；

音频路由服务(ARS)：用于选择音频输入和输出的位置的服务；

音频中间件配置文件(AMP)：用于分发音频的设备的行为的基本配置文件；

呼叫管理配置文件(CMP)：两个设备之间为呼叫而进行交互的角色和过程的配置文件；

音频通用中间件配置文件(AGMP)：使实现内容和/或流控制的基本配置文件；

组标识服务(GIS)：用于发现属于组的设备的服务。组标识服务(GIS)或组标识配置文件(GIP)可以允许设备作为组的一部分而被发现。组被定义为一起操作以支持特定场景的一组设备，并且这些设备可以被称为组成员。例如，一起响应于控制命令的一组设备例如一对助听器、一对耳塞式耳机(earbud)或接收多通道(例如，5.1CH)音频的扬声器集合可能是这样的示例：

音频回放器管理配置文件(APMP)：支持音频回放器的控制或交互的配置文件；

音频回放器管理服务(APMS)：支持音频回放器的控制或交互的服务；

麦克风管理配置文件：用于麦克风状态管理的配置文件；

麦克风管理服务：支持用于麦克风状态管理的接口和状态的服务；

快速服务发现服务(QSDS)：支持快速发现诸如音频回放器管理和呼叫管理的服务的服务；

呼叫承载服务：支持设备上承载的呼叫接口和呼叫状态的管理的服务；

音量管理配置文件：支持设备的音频音量管理的配置文件；

音量管理服务：支持设备的音频音量接口和状态的服务；

音量偏移管理服务：用于音频输出的音量管理的服务。

图3示出了本公开内容适用的5.1通道环绕系统硬件的示例。

在图3中，LE音频源设备可以执行发起者的功能，并且LE音频信宿设备可以执行接受者的功能。发起者是指发起音频会话的设备，而接受者是指接受发起的音频会话的设备。在此，源并不总是发起者或者信宿(sink)并不总是接受者，源可以是接受者或者信宿可以是发起者。

例如，音频源可以是TV设备，并且音频信宿可以是扬声器设备。音频源可以将音频数据发送至音频信宿。另外，音频源可以从音频信宿接收反馈数据。多个音频信宿可以分别接收与5.1通道——FL(左前)、FR(右前)、RL(左后)、RR(右后)、C(中央)和W(低音扬声器)——中的一个相对应的音频数据，并且通过扬声器输出该音频数据。

音频编码器或解码器可以支持各种音频格式。例如，音频格式可以包括蓝牙低功耗音频编解码器(BLEAC)、杜比5.1CH、数字环绕声(DTS)等，并且每种格式的特性如下。BLEAC是单通道编解码器，并且BLEAC的96kbps的传输速率可以提供与SBC(子带编解码器)的256kbps和MP3的200kbps相同的质量。杜比5.1CH可以支持48kHz采样速率，支持1到5.1(或1到6)通道，并且支持高达448kbps的传输速率。DTS可以支持48kHz或96kHz采样速率，支持2至6.1通道，并且支持768kbps半速率和1,536kbps全速率的传输速率。

图4是示出了本公开内容适用的音频数据编码/解码处理的图。

参照图4(a)，DTS格式流或杜比5.1CH格式流可以被输入至发送端(Tx)的DTS解码器或杜比5.1CH解码器，并且PCM(脉冲编码调制)格式的音频信号可以被输出。PCM信号可以被输入至BLEAC编码器并作为BLEAC格式的音频信号被输出。在此，可以添加可选的供应商特定信息。BLEAC信号可以通过BLE接口被发送至接收端(Rx)的BLE接口。接收端可以通过BLEAC解码器处理BLEAC信号并将该BLEAC信号转换成可以通过扬声器输出的信号。

在此，可以将多个流从发送端发送至多个接收端。例如，多个流中的每一个可以包括与5.1CH之中的一个通道相对应的音频信号。可以从多个接收端在不同时间接收多个流，但是所述多个流具有需要同时回放或呈现的等时性质，并且这些流可以被称为CBIS(基于连接的等时流)。也就是说，可以将与5.1CH相对应的六个CBIS从发送端发送至接收端，并且这六个CBIS的集合可以被称为一个CBISS(基于连接的等时流集)。

图4(b)和图4(c)概念性地示出了通过多个流的音频流式传输。一个或更多个音频流可以对应于CBIS，并且音频组可以对应于CBISS。例如，一个音频流可以对应于一个CBIS，而两个或更多个音频流可以对应于一个CBIS。多个CBIS可以被包括在一个音频组或CBISS中。

图5是示出了本公开内容适用的两个设备的通道分配的示例的图。

接收端可以根据由发送端提供的定时信息而发起流接收。例如，定时信息可以表示从包括定时信息的数据单元被发送的时间点的预定偏移之后的时间点。接收端可以接收与流中包括的一个或更多个通道相对应的音频数据。例如，可以将包括在一个流中的多个通道分别分配给多个接收端。可以以时分多路复用(TDM)方法来发送包括在一个流中的多个通道(或多个音频数据)。例如，可以在第一定时处发送第一通道的音频数据，并且可以在第二定时处发送第二通道的音频数据。

广播接收端可以通过使用由发送端周期性广告的数据单元中包括的信息来检测当前可获得的广播音频流、流偏移值、流间隔值等。

在作为基于无连接的等时链路的等时非连接链路(INCL)的情况下，可以在源设备与信宿设备之间没有连接的情况下发送/接收(例如，以广播方式)等时通道。从诸如由发送端广告的AUX_SYNC_IND协议数据单元(PDU)中包括的BSG(广播同步组)的信息，接收端可以检查INCL流偏移或BSG偏移并确定锚点定时。INCL流传输可以从锚点开始。两个连续的锚点之间的定时差可以被定义为间隔(例如，图5的INCL CH1间隔或ISO间隔)。一个或更多个子事件可以被包括在流传输事件中。

在图5的示例中，一个音频流可以包括两个通道的音频数据。第一通道(CH1)可以被分配给第一设备(设备#1)，并且第二通道(CH2)可以被分配给第二设备(设备#2)。在锚点之后的一个或更多个定时处，可以将包括在INCL流中的CH1发送至设备#1，此后，可以在一个或更多个定时处将CH2发送至设备#2。另外，INCL流事件可以包括CH1的事件和CH2的事件。CH1的事件可以包括两个子事件。CH2的事件可以包括两个子事件。子事件之间的定时差可以被定义为子事件间隔。

等时音频数据可能具有有限的寿命。也就是说，在预定时间到期之后，音频数据可能无效。例如，可以在ICL通道中定义预定超时值，并且在预定超时值到期之后，可以丢弃发送至多个设备的等时音频数据。例如，超时可以被表达为多个子事件。

图6是用于描述本公开内容适用的两个流的同步延迟的图。

假设多个流被包括在一个音频组中，并且多个流具有需要同时被再现的等时性。可以从一个设备发送多个流或者可以从不同的设备发送多个流。此外，多个流可以由一个设备接收或者可以由不同的设备接收。

由于蓝牙通信方法不支持同时传输多个流，因此可以根据预定顺序在不同时间资源(或定时)上以TDM方法发送多个流。在这种情况下，在多个流的传输定时中可能出现差异，因此，在多个流的接收定时中也可能出现差异。另外，由于需要同时再现多个流，因此首先接收到的流不能首先被再现，而是可以在等待直到接收到最后的流之后才被再现。也就是说，可以直到完成所有流的接收的定时才发生同步延迟。

在图6的示例中，第一流(CBIS#1)和第二流(CBIS#2)可能需要同时被再现，并且可以被包括在一个CBISS中。CBISS锚点可以与CBIS#1的锚点相同，并且在可以发送CBIS#1音频数据之后，继在CBIS#1间隔之后的时间点(例如，T1)之后的CBIS#1音频数据可以被发送。接下来，在从CBIS#2的锚点发送CBIS#2音频数据之后，继在CBIS#2间隔(例如，T2)之后的时间点之后的CBIS#2音频数据可以被发送。在接收到一个CBISS中包括的所有流之后，可以同时再现它们。也就是说，可以在完成相对晚发送的CBIS#2的接收时处理和再现CBIS#1和CBIS#2的音频数据。

在此，CBISS的同步延迟可以被定义为直到从CBISS相对晚地接收的CBIS#2的接收完成时间(T2)的时间间隔。例如，CBIS#1的接收完成时间T1和CBIS#2的接收完成时间T2之中的较晚时间点可以被确定为CBISS的同步延迟。也就是说，多个流的同步延迟之中的较晚接收完成时间可以被确定为CBISS的同步延迟。具体地，当CBIS#1和CBIS#2被绑定到相同的单个CBISS中时，可以在等待直到发送接收的流CBIS#2信息之后再现先前接收的流CBIS#1。

发送端(Tx)可以向接收端(Rx)通知预先考虑到CBIS的数目、CBIS事件、子事件和间隔而计算的预期延迟值。例如，发送端可以在配置通道时向接收端通知预期延迟值。

在基于连接的等时连接链路(ICL)的情况下，由于发送端和接收端连接，因此接收端可以向发送端通知实际延迟值。

在INCL的情况下，由于发送端和接收端不连接，因此接收端无法向发送端通知实际延迟值。即使可以从接收端向发送端通知延迟值，发送端也不能控制特定设备的回放时间以便使多个设备同步。

例如，甚至在INCL的情况下，当在一个CBISS中包括多个CBIS(例如，与5.1CH的六个通道相对应的六个CBIS)时，发送端也可以接收来自接收器的反馈以调整同步。通过反馈，接收端可以向发送端通知其延迟信息。

图7是用于描述本公开内容适用的多个设备的广播操作的图。

音频源设备可以计算用于等时流的同时再现的同步延迟值，并将该同步延迟值发送至多个音频信宿设备。信宿设备中的每一个可以基于从源设备提供的延迟值来确定回放定时。也就是说，由于源设备无法准确地知道信宿设备接收和处理音频数据所花费的时间量，因此信宿设备可以提供延迟值作为用于确定回放定时的基本信息。信宿设备可以根据其设备特性来确定再现定时并再现音频数据。

例如，在等时广播操作中，源设备(例如，TV)可以计算传输延迟、呈现延迟等，并将传输延迟、呈现延迟等发送至信宿设备(例如，扬声器)。信宿设备可以通过反映接收的延迟值来调整音频数据的回放或呈现定时。由于对每个信宿设备制造商而言，设备特性是不同的，因此可以由信宿设备确定实际回放定时。

如果信宿设备可以将信息发送至源设备，则信宿、信宿设备可以计算延迟值并将延迟值发送至源设备。因此，源设备可以基于从信宿设备提供的延迟值来确定传输定时。

例如，可以形成反馈通道，信宿设备(例如，扬声器)可以通过该反馈通道将信息传送至源设备(例如，TV)。在这种情况下，可以执行基于等时连接的单播操作。信宿设备可以计算呈现延迟值并通过反馈通道将呈现延迟值发送至源设备。因此，源设备可以通过反映从信宿设备提供的延迟值来调整音频数据的传输时间。

参照图7，在发送端是TV并且两个接收端是第一扬声器(扬声器#1)和第二扬声器(扬声器#2)的情况下，示例性地示出了等时流操作。可以为第一扬声器分配第一流/通道(例如，5.1CH中的RR通道)，并且可以为第二扬声器分配第二流/通道(例如，5.1CH中的RL通道)。

第一扬声器和第二扬声器可以分别发送音频通用广告或音频定向广告。TV和第一扬声器或第二扬声器中的至少一个可以彼此连接或可以不彼此连接。

当TV和扬声器中的至少一个连接时，扬声器可以计算呈现延迟值并将该呈现延迟值报告给TV。当TV和扬声器没有连接时，TV可以计算传输延迟、呈现延迟值等并将其发送至扬声器。

考虑到音频内容特性、音频/视频同步、编解码器特性等，TV可以执行同步操作并将延迟强制地应用于特定音频流。例如，由于音频编解码器编码/解码延迟与BLEAC的40ms、SBC的200ms、APT-X的100ms等不同，因此可以根据编解码器特性来确定延迟值。另外，由于A/V内容的特性根据游戏、电影、动画等而不同，因此可能考虑到这一点来确定延迟值。此外，可以考虑到媒体时钟与BLE接口的时钟之间的差异来确定延迟值。可以通过A/V时标信息来确认媒体时钟。

另外，如图7的左侧所示，可以考虑到在各种广播标准中定义的音频/视频信号处理时间来确定延迟值。例如，在高级电视系统委员会(ATSC)中，音频-视频-音频之间的时间间隔为15ms和45ms；在ITU-R BT.1359-1中，音频-视频-音频之间的时间间隔为125ms和45ms；以及在SMPTE(电影电视工程师协会)中，音频-视频-音频之间的时间间隔被定义为22ms和22ms，而且可以考虑到这些时间间隔来确定延迟值。

TV可以配置每个流的呈现延迟值并向扬声器通知该呈现延迟值，或者TV可以基于从扬声器提供的延迟值来确定流的传输定时。

TV可以基于所确定的延迟值将流发送至扬声器。也就是说，作为发送端的源设备或TV可以与作为接收端的信宿设备和扬声器交换延迟值，并且可以通过反映延迟值来执行同步操作。

图8和图9是用于描述本公开内容适用的ICL类型和INCL类型的操作的图。

在BLE中，可以将用于音频传输的通道分类为ICL类型和INCL类型。ICL通道和INCL通道两者都可以使用流ID和通道ID将音频数据发送至多个设备和/或多个配置文件。根据ICL类型和INCL类型，可以确定要对用于音频数据传输的BLE通道执行什么操作。

ICL通道对应于基于连接的用例，该基于连接的用例通过一个源设备与一个信宿设备之间的点对点物理链路来支持单向或双向通信。另外，INCL通道对应于广播用例，该广播用例通过一个源设备与一个或更多个信宿设备之间的点对多点物理链路来支持仅单向通信。

设备的协议栈可以按照从上层到下层的顺序包括配置文件层、通道管理器层、主机层和控制器层。可以以通道为单位在配置文件层与通道管理器层之间递送数据，并且可以以流为单位在通道管理器层与主机层之间递送数据。

参照图8，在ICL类型的情况下，主设备(M)与第一从设备S1之间的连接以及主设备M与第二从设备S2之间的连接。在这种情况下，可以通过通道标识符来划分包括在一个流中的两个通道，并将这两个通道发送至两个从设备。也就是说，可以将通道ID 1分配给S1，并且可以将通道ID 2分配给S2。通道ID 1和通道ID 2两者都可以通过相同的流ID 1被发送。另外，由于基于连接可以进行双向通信，因此从设备可以将反馈信息提供至主设备M。例如，当S1是安装在右耳上的无线耳机并且S2是安装在左耳上的无线耳机时，可以通过S1和S2以立体声收听由主设备M发送的音乐。

参照图9，在INCL类型的情况下，在主设备M与从设备(S1，S2)之间没有连接，并且从设备可以基于由主设备广告的同步信息与INCL流偏移、事件、子事件的定时同步，并且可以接收广播音频数据。另外，主设备M可以包括两个配置文件(配置文件#1和配置文件#2)。第一从设备S1可以包括配置文件#1，第二从设备S2可以包括配置文件#1和配置文件#2。在配置文件#1中，可以通过一个流——流ID 1——从主设备M广播通道ID 1和通道ID 2，并且类似于图8，从设备S1和S2分别接收配置文件#1中的通道ID 1和通道ID。另外，在配置文件#2中，可以通过流ID 2从主设备M广播通道ID 1，并且第二从设备S2可以接收配置文件#2中的通道ID 1。

图10是示出了本公开内容适用的广播音频流状态机的图。

广播音频流的控制可以被描述为广播发送端处的广播音频流状态机和状态转换。

广播音频流状态机可以允许广播发送器在没有连接的情况下以单向方式与一个或更多个广播接收器(或广播发现客户端)进行通信或者不与广播接收器(或广播发现客户端)进行通信。广播发送器可以以广播音频源会话(BASS)的形式使用广播音频广告进行通信。广播音频流可以由广播发送器发送。

音频待机状态是指没有发送广播音频流的状态。

音频配置状态是指广播接收器(或广播发现发起者)通过周期性广告事件来开始用于检测音频流的广告信息的状态。周期性广告事件可以包括递送广告元数据、流配置、同步信息等。在该状态下，没有音频数据分组从广播发送器被发送。

音频流式传输状态是指在广播发送器中启用广播音频流并且可以发送音频数据分组的状态。广播发送器可以在发送广播音频流时通过周期性广告连续地执行元数据广告。如果在音频待机状态下配置流，则它可以转换到音频配置状态，并且如果在音频配置状态下释放流，则它可以转换到音频待机状态。如果在音频配置状态下启用流，则它可以转换到音频流式传输状态，并且如果在音频流式传输状态下禁用流，则它可以转换到音频配置状态。如果在音频配置状态下发生流重新配置，则它可以转换到音频配置状态。当在音频流式传输状态下发生内容重新分配时，它可以转换到音频流式传输状态。

图11是示出了本公开内容适用的音频设置过程的图。

当不存在发现结果(即，零发现)时，可以转换音频待机状态，并且如果存在发现结果，则用于音频流能力(ASC)的发现可以被执行并转换到音频待机状态。

当发生ASS(音频流会话)配置时，它可以转换到音频配置状态。如果在音频配置状态下释放ASS，则它可以转换到音频待机状态。当在音频配置状态下发生重新配置时，它可以通过ASS配置转换到音频配置状态。

当ASS被激活时，它可以转换到音频流式传输状态。如果在音频流式传输状态下发生ASS停用，则它可以转换到音频配置状态。如果在音频流式传输状态下发生内容重新分配，则它可以转换到音频流式传输状态。

图12是示出了本公开内容适用的链路层状态机的图。

链路层LL的操作可以被表示为(根据等时通道)待机状态、广告状态、扫描状态、发起状态、连接状态、同步化(同步性)状态和流式传输(等时广播)状态。

待机状态对应于转换到另一状态之前的待机状态。

在广告状态下，LL可以作为发送广告分组的广告者而操作。当在广告状态下建立连接时，设备可以作为从设备而操作。

在发起状态下，LL可以充当发起者，该发起者监听来自其他广告者的分组，并且响应于分组而发起连接。当在发起状态下建立连接时，设备可以作为主设备而操作。

在扫描状态下，LL可以充当扫描者，该扫描者监听来自其他广告者的分组并请求附加信息。

同步化状态可以是指可以接收或与另一设备同步接收音频流的状态。

流式传输状态可以是指音频流被发送至另一同步化设备的状态。

图13是示出了本公开内容适用的音频拓扑的图。

在单播的情况下，可以支持单向音频流或双向音频流。可以执行基于耳机与智能电话之间的连接的单播音频数据发送/接收，以及可以执行基于耳机与智能电话之间的连接和耳机与平板计算机之间的连接的单播音频数据发送/接收。在这种情况下，单播音频服务的服务器可以是头戴式耳机，并且客户端可以是智能电话或平板计算机。此外，头戴式耳机可以对应于音频信宿，并且智能电话或平板计算机可以对应于音频源。

在广播的情况下，通知系统、门铃、TV等可以以广播方式发送音频数据，并且一个或更多个设备可以接收广播音频数据。在这种情况下，广播音频服务的服务器可以是通知系统、门铃、TV等，并且客户端可以是头戴式耳机。此外，头戴式耳机可以对应于音频信宿，并且通知系统、门铃和TV可以对应于音频源。

图14至图16是示出了本公开内容适用的服务器与客户端之间的消息交换过程的图。

在图14至图16的示例中，客户端可以是音频源，服务器可以是音频信宿。或者客户端可以是音频信宿，服务器可以是音频源。

图14示例性地示出了音频会话能力(ASC)发现过程和ASC更新过程。

在图14(a)的音频会话能力发现过程中，客户端可以通过将ASC发现请求消息发送至服务器来请求能力发现，并且响应于这，服务器可以通过将ASC发现响应消息发送至客户端来发送能力的详细信息。

在图14(b)的音频会话能力更新过程中，服务器可以将ASC更新指示消息发送至客户端以通知已经发生了能力更新，并且客户端可以通过发送ASC更新确认消息来通知服务器执行能力更新。随后，可以执行音频会话能力发现过程或ASC发现过程。

在图14的示例中使用的消息的格式可以如下面表1中所示地被定义。

【表1】

ASC更新指示消息和ASC更新确认消息可以分别包括指示需要ASC发现的信息和用于此的确认信息。

图15示例性地示出了单播音频流配置过程和单播音频流建立过程。

在图15(a)的单播音频流配置过程中，客户端在音频待机状态下可以将编解码器配置请求消息发送至服务器，以向服务器通知编解码器请求配置等。作为响应，服务器可以将编解码器配置响应消息发送至客户端，以向服务器通知由服务器支持的QoS和呈现延迟值。另外，客户端可以将QoS协商请求消息发送至服务器以指定特定的音频流会话(ASS)、音频组和音频流，以向客户端通知由客户端支持的QoS和呈现延迟值。作为响应，服务器可以将QoS协商响应消息发送至客户端。因此，可以通过客户端与服务器之间的协商来确定带宽(BW)、比特率等，并且客户端和服务器可以转换到配置状态。

在图15(b)的单播音频流建立过程中，客户端可以在音频配置状态下将ASS启用请求消息发送至服务器，以通知关于ASS请求激活的信息。作为响应，服务器可以将ASS启用响应消息发送至客户端以通知关于要激活哪个ASS。针对基于连接的等时链路参数的配置可以在客户端处被执行，并且可以通过客户端和服务器配置基于连接的等时流连接和相关参数来建立CBIS。如果客户端是音频信宿并且服务器是音频源，则服务器可以准备播放音频数据并将ASS Rx就绪指示消息发送至客户端，并且客户端可以在接收到ASS接收就绪指示通知消息之后准备提供音频数据。因此，客户端和服务器可以转换到音频流式传输状态。

在图15的示例中使用的消息的格式可以如下面表2中所示地被定义。

【表2】

图16示例性地示出了用于通过客户端禁用音频流的过程和用于通过服务器禁用音频流的过程。

在图16(a)中的客户端禁用音频流的过程中，如果客户端是音频源并且服务器是音频信宿，则当客户端决定在音频流式传输状态下停止音频时，可以将ASS禁用请求消息发送至服务器。因此，服务器可以停止流式传输音频数据并将ASS禁用响应消息发送至客户端。在接收到这时，客户端可以停止音频数据编码和音频应用操作。

可替选地，如果客户端是音频信宿并且服务器是音频源，则客户端可以停止音频数据流式传输，并将ASS禁用请求消息发送至客户端。因此，服务器可以停止音频数据编码和音频应用操作，并将ASS禁用响应消息发送至客户端。

此后，客户端和服务器可以执行基于连接的等时流释放和相关参数设置释放。在此，为客户端与服务器之间的重新连接作准备，可以将设备信息连同等时流连接相关参数存储在客户端和/或服务器中。因此，客户端可以释放基于连接的等时链路相关参数设置。因此，客户端和服务器可以转换到音频配置状态。

在图16(b)的示例中，在通过服务器禁用音频流的过程中，如果服务器是音频源并且客户端是音频信宿，则当服务器决定在音频流式传输状态下停止音频时，可以将ASS禁用指示消息发送至客户端。因此，客户端可以停止流式传输音频数据，并且可以或可以不将ASS禁用确认消息发送至服务器。服务器可以在接收或没有接收ASS停用响应的情况下停止编码音频数据和音频应用操作。

可替选地，如果服务器是音频信宿并且客户端是音频源，则服务器可以停止音频数据流式传输并将ASS禁用指示消息发送至客户端。因此，客户端可以停止音频数据编码和音频应用操作，并且可以或可以不将ASS禁用确认消息发送至服务器。

此后，客户端和服务器可以执行基于连接的等时流释放和相关参数配置释放。在此，为客户端与服务器之间的重新连接作准备，可以将设备信息连同等时流连接相关参数存储在客户端和/或服务器中。因此，客户端可以释放基于连接的等时链路相关参数配置。因此，客户端和服务器可以转换到音频配置状态。

在图16的示例中使用的消息的格式可以如下面表3中所示地被定义。

【表3】

下面的表4示例性地示出了内容重新分配请求/响应、ASS释放请求/响应、通用广告和定向广告消息格式。

【表4】

图17是示出了用于本公开内容适用的呼叫服务的状态机的图。

当在音频待机状态下接收到呼叫时，它可以转换到呼叫接受状态。当在呼叫接受状态下接受呼叫时，它可以转换到呼叫激活状态。当在呼叫接受状态下拒绝呼叫时，它可以转换到音频待机状态。在呼叫接受状态下不能接收呼叫的保持的情况下，它可以转换到呼叫保持状态，并且当在呼叫保持状态下释放保持时，它可以转换到呼叫激活状态。当呼叫保持状态或呼叫激活状态被终止时，它可以转换到音频待机状态。

此外，当呼叫在音频待机状态下呼出时，它可以转换到呼叫发起状态。当它在呼叫发起状态下应答来自远程位置或其他方的呼叫时，它可以转换到呼叫激活状态。当它在呼叫发起状态下结束时，它可以转换到音频待机状态。

在这样的呼叫服务状态机中，可能发生需要在音频待机状态下被递送至耳机的音频数据。例如，当通过声音通知拨打电话号码时的响应时，可以将音频数据发送至耳机。

可替选地，明确地指示与呼叫服务相关的各种无线接入技术(例如，2G、3G、4G、5G、Wi-Fi、GSM、CDMA、WCDMA等)的信息。例如，可以定义大小为1个八位字节的承载技术字段。这可能与上述呼叫承载服务相关。

在多路呼叫的情况下，可以存在多条线路，并且可以针对每条线路来维护如图17中所示的状态机。例如，在第一线路处于呼叫激活状态时，当第二线路从音频待机状态转换到呼叫接受状态时，第一线路或第二线路可以根据用户的控制转换到呼叫保持状态。

在下文中，将描述蓝牙系统的逻辑链路和逻辑传输。

可以使用各种各样的逻辑链路来支持不同的应用数据传送要求。每个逻辑链路与逻辑传输相关联，该逻辑传输可能具有各种特性。这些特性可以包括流量控制、确认/重复机制、序列编号和调度操作等。逻辑传输可以根据其类型承载各种类型的逻辑链路。可以将多个逻辑链路多路复用成相同的单个逻辑传输。逻辑传输可以由特定通道上的物理链路承载。

逻辑传输标识和实时(链路控制)信令可以被包括在分组报头中，并且可以在有效载荷的报头中包括特定的逻辑链路标识。

下面的表5示例性地示出了逻辑传输类型、支持的逻辑链路类型、支持的物理链路和物理通道类型以及逻辑传输的描述。

【表5】

图18是示出了本公开内容适用的每个层的分组格式的图。

图18(a)示出了链路层(LL)分组格式的示例。LL分组格式可以包括前导码、访问地址(或访问代码)、PDU和循环冗余码(CRC)字段。前导码可以具有1个八位字节的大小，可以用于在接收侧的频率同步、符号定时估计、自动增益控制(AGC)训练等，并且可以用预定的位序列来配置。访问地址可以具有4个八位字节的大小，并且可以被用作物理通道的相关代码。可以在蓝牙4.0版本中用2个至39个八位字节的大小来定义PDU，并且可以在版本4.2中将PDU定义为2个至257个八位字节的大小。CRC可以包括被计算为PDU的24位长校验和的值。

图18(b)示出了图18(a)的PDU的示例性格式。可以以两种类型定义PDU，一种类型是数据通道PDU(Data channel PDU)，另一种类型是广告通道PDU(Advertising channelPDU)。将参照图19详细描述数据通道PDU，并且将参照图20详细描述广告通道PDU。

图18(c)示出了L2CAP PDU格式的示例，其可以对应于图18(b)的有效载荷字段的示例性格式。L2CAP PDU可以包括长度、通道ID和信息有效载荷字段。长度字段可以指示信息有效载荷的大小，并且信息有效载荷字段可以包括较高层的数据。通道标识符字段可以指示信息有效载荷字段包括哪个上层数据。例如，如果通道标识符字段的值是0x0004，则它可以指示ATT(属性协议)，如果通道标识符字段的值是0x0004，则它可以指示SMP(安全管理器协议)，或者可以定义和使用指示不同类型的上层或中间件值的另一个通道标识符。

当图18(c)的L2CAP分组是在信令通道上发送的L2CAP PDU(即，控制帧)时，图18(c)的信息有效载荷字段可以如图18(d)中所示地被配置。信息有效载荷字段可以包括代码(Code)字段、标识符(Identifier)字段、长度(Length)字段和数据(Data)字段。例如，代码字段可以指示L2CAP信令消息的类型。标识符字段可以包括与请求和响应匹配的值。长度字段可以指示数据字段的大小。数据字段可以包含属性。属性是任意数据的单元，并且可以包括例如在设备的各种状态下的各个时间点处的数据，比如位置、大小、重量、温度和速度。

属性可以具有包括属性类型、属性句柄、属性值和属性权限的格式。

属性类型可以包括指示由通用唯一标识符(UUID)标识的属性数据的类型的值。

属性句柄可以包含由服务器分配以标识属性数据的值。

属性值可以包括属性数据的值。

属性权限可以由GATT(通用属性配置文件)来配置，并且可以包括指示被允许访问(例如，它是否可以读取/写入、是否需要加密、是否需要认证、是否需要授权等)相应的属性数据的类型的值。

从属性协议(ATT)/通用属性配置文件(GATT)的角度来看，设备可以用作服务器和/或客户端。服务器可以用于提供属性和相关值，并且客户端可以发挥在服务器上发现、读取或写入属性的作用。

在ATT/GATT中，它可以支持服务器与客户端之间的属性数据的发送和接收。为此，由ATT协议支持的PDU可以包括六种方法类型，即请求、响应、命令、通知、指示和确认。

请求从客户端被发送至服务器，并且需要来自服务器的响应。响应从服务器被发送至客户端，并且当存在来自客户端的请求时被发送。命令从客户端被发送至服务器，并且不需要响应。通知从服务器被发送至客户端，并且不需要确认。指示从服务器被发送至客户端，并且需要客户端的确认。确认从客户端被发送至服务器，并且当存在来自服务器的指令时被发送。

此外，GATT可以支持各种配置文件。基于GATT的配置文件的结构可以被描述为服务(service)和特性(characteristics)。设备可以支持一个或更多个配置文件。一个配置文件可以包括零个或者一个或更多个服务。多个配置文件可以使用相同的服务。一个服务可以包括一个或更多个特性。特性是指作为读取、写入、指示或通知的主题的数据值。也就是说，服务可以被理解为用于描述特定功能或特征的数据结构，并且作为特性的组合的服务可以指示由设备执行的操作。所有服务都由服务器实现并且可以由一个或更多个客户端访问。

图19是示出了本公开内容适用的数据单元格式的示例的图。

图19(a)示出了数据物理通道PDU(协议数据单元)的示例性格式。数据通道PDU可以用于在数据物理通道(例如，通道编号0至36)上发送分组。数据物理通道PDU包括16位或24位长度报头和可变大小(例如，0个到251个八位字节大小)有效载荷，并且还可以包括消息完整性检查(MIC)字段。例如，可以在有效载荷字段大小不是0的加密的链路层连接的情况下包括MIC字段。

如图19(b)中所示，报头字段可以包括LLID(逻辑链路标识符)、NESN(下一个预期序列号)、SN(序列号)、MD(更多数据)、CP(CTEInfo存在)、RFU(被保留供将来使用)。RFU对应于被保留供在必要时将来使用的部分，并且其值通常可以用0来填充。此外，根据CP字段的值，报头字段还可以包括恒定音调扩展信息(CTEInfo)子字段。另外，长度字段可以指示有效载荷的大小，并且当MIC被包括时，它可以指示MIC和有效载荷的长度。

图19(c)示出了LL控制PDU的示例性格式。LL控制PDU可以对应于用于控制链路层连接的数据物理通道PDU。LL控制PDU可以根据操作码(Opcode)具有固定值。Opcode字段可以指示LL控制PDU的类型。控制数据(CtrData)字段可以具有由Opcode指定的各种格式和长度。

例如，LL控制PDU的Opcode可以具有指示LL_CBIS_REQ、LL_CBIS_RSP、LL_CBIS_IND、LL_CBIS_TERMINATE_IND、LL_CBIS_SDU_CONFIG_REQ和LL_CBIS_SDU_CONFIG_RSP中的一个的值(例如，0x1F、0x20、0x21、0x22、……)。

当opcode指示LL_CBIS_REQ时，CtrData字段可以包括CBIS请求所需的信息连同CBISS标识信息和CBIS标识信息。类似地，在Opcode指示LL_CBIS_RSP、LL_CBIS_IND、LL_CBIS_TERMINATE_IND、LL_CBIS_SDU_CONFIG_REQ、LL_CBIS_SDU_CONFIG_RSP中的一个的每种情况下，CtrData可以包括CBIS响应、CBIS指示、CBIS终止指示、CBIS服务数据单元(SDU)设置请求和CBIS SDU设置响应所需的信息。

图19(d)示出了音频数据PDU格式的示例。

音频数据PDU可以是CBIS PDU或广播等时PDU。当在CBIS流中被使用时，音频数据PDU可以被定义为CBIS PDU。当在广播等时PDU中被使用时，音频数据PDU可以被定义为广播等时PDU。

音频数据PDU可以包括16位长度报头字段和可变长度有效载荷字段。此外，音频数据PDU还可以包括MIC字段。

在CBIS PDU的情况下，报头字段的格式可以包括2位LLID、1位NESN、1位SN、1位关闭等时事件(CIE)、1位RFU、1位空PDU指示符(NPI)、1位RFU、9位长度子字段。

在广播等时PDU的情况下，报头字段的格式可以包括2位LLID、3位控制子事件序列号(CSSN)、1位控制子事件传输号(CSTF)、2位RFU和8位长度子字段。

音频数据PDU的有效载荷字段可以包括音频数据。

图20是示出了本公开内容适用的广告单元格式的示例的图。

图20(a)示出了广告物理通道PDU(协议数据单元)的示例性格式。广告通道PDU可以用于在广告物理通道(例如，通道号37、38、39)上发送分组。广告通道PDU可以由2个八位字节的报头和6个到37个八位字节的有效载荷组成。

图20(b)示出了广告通道PDU的报头的示例性格式。报头可以包括PDU类型、被保留供将来使用(RFU)、发送地址(TxAdd)、接收地址(RxAdd)、长度(Length)和RFU字段。报头的长度字段可以指示有效载荷的大小。

图20(c)示出了广告通道PDU的有效载荷的示例性格式。有效载荷可以包括长度为6个八位字节的广告者地址(AdvA)字段以及长度为0个到31个八位字节的AdvData字段。AdvA字段可以包括广告者的公共地址或随机地址。AdvData字段可以包括零个或更多个广告数据(AD)结构，必要时还可以包括填充。

图20(d)示出了一个AD结构的格式。AD结构可以包括三个字段。长度字段可以指示AD数据字段的长度。也就是说，通过从由长度字段指示的值中减去1获得的值可以对应于AD数据字段的长度。AD类型字段可以指示AD数据字段中包括的数据的类型。AD数据字段可以包括从广告者的主机提供的广告数据。

在下文中，将描述根据本公开内容的云认证配对。

本公开内容涉及与新配对目标设备的安全自动认证。

根据本公开内容，通过经过帐户服务器(或凭证代理)预先将关于第一设备的信息传送至第二设备来自动执行在第一设备(或提供者)与第二设备(或搜索者)之间的认证的实施方式。

例如，关于第一设备的信息可以通过和与第二设备(或第一搜索者)相同的帐户(或用户)相关联的第三设备(或第二搜索者)预先被提供至帐户服务器。

例如，第一设备可以是可以与各种设备配对(或连接)的配对目标设备(例如，耳机、耳塞式耳机等)，并且第二设备和/或第三设备(或者第一搜索者和/或第二搜索者)可以对应于能够通过与第一设备配对来向第一设备提供数据的用户设备。

另外，鉴于根据本公开内容的协议，第一设备可以对应于提供者。第二设备和/或第三设备可以对应于搜索者。

因此，用户可以与多个设备(例如，第二设备和第三设备)中的配对目标设备(例如，第一设备)无缝连接或配对。

图21是用于描述可以应用本公开内容的自动认证方法的示例的图。

图21的示例可以包括使用云或服务器基于用户帐户为设备提供自动认证的方法。

帐户服务器(或凭证代理)可以维护和管理用户信息(例如，关于用户帐户的凭证信息等)、提供者设备信息、帐户管理器信息等。

帐户管理器(或搜索者)可以通过与用户的交互来获得用户信息并管理用户信息。例如，帐户管理器可以被包括在音频源或用户设备(例如，智能电话、膝上型计算机等)中。在本公开内容中，假设多个帐户管理器与同一个用户帐户相关联。此外，帐户管理器可以对应于从提供者搜索用户信息的搜索者。

提供者可以获得用户信息，并基于用户信息建立与帐户管理器的自动连接(或配对)。例如，提供者可以被包括在音频信宿或外围设备(例如，耳机)中。

帐户服务器(或凭证代理)可以经由各种带外(OOB)通信方法(例如，因特网上的HTTP)与帐户管理器(或搜索者)和/或提供者交换信息。从使用包括帐户管理器的设备的用户的角度来看，帐户服务器可以被认为是包括在云中。

同时，帐户管理器(或搜索者)和提供者可以通过带内通信方法(例如，基于蓝牙的通信方法)交换信息。例如，帐户管理器和提供者可以通过基于GATT的特性的读/写/指示/通知过程来交换信息。

例如，在图21中，帐户服务器可以通过与帐户管理器#1的消息交换将特定用户的凭证信息传送至帐户管理器#1。

当帐户管理器#1建立与提供者#1的基于蓝牙的连接和绑定(或配对)时，它可以检查提供者#1是否是针对用户的可信设备以及是否向提供者#1提供凭证信息。

如果用户允许(例如，用户针对关于是否允许通过帐户管理器#1的用户接口(UI)交换凭证信息的警报选择允许/是)，则可以执行凭证信息交换过程。

如果安全级别低，则在帐户管理器#1与提供者#1之间创建安全链路，以执行凭证信息交换过程。如果安全级别高，则可以执行凭证信息交换过程，而无需创建安全链路的过程。

通过该凭证信息交换，提供者#1可以获取全部或部分的凭证信息(例如，基于凭证信息生成的散列值)。

提供者#1可以广告所获得的凭证信息。

图22是示出了可以应用本公开内容的广告分组的示例性格式的图。

本公开内容包括定义用于广告凭证信息的新型广告分组的示例。例如，使用广告分组格式，广告数据类型可以被指定为指示与用户帐户相关的数据的新值，并且基于凭证信息的信息可以被包括在广告数据中。

图22(a)和图22(b)对应于图18(a)和图18(b)，因此将省略其描述。然而，由于图22用于广告分组，因此图22(b)的有效载荷可以由长度为6个到37个八位字节的广告通道PDU组成。

在广告分组的情况下，图22(b)的有效载荷可以包括长度为6个八位字节的AdvA字段和长度为0个至31个八位字节的AdvData字段，如图22(c)中所示。AdvA字段可以包括广告者的公共地址或随机地址。如果需要，AdvData字段可以包括零个或更多个广告数据(AD)结构和填充。

图22(d)示出了一个AD结构的格式。AD结构可以包括三个字段。长度字段可以指示AD数据字段的长度。也就是说，通过从由长度字段指示的值中减去1而获得的值可以对应于AD数据字段的长度。AD类型字段可以指示包括在AD数据字段中的数据的类型。AD数据字段可以包括从广告者的主机提供的广告数据。

为了指示本公开内容中使用的与用户帐户相关的新广告分组，AD类型可以包括指示与用户帐户相关的信息的值，并且AD数据可以包括基于用户信息生成的信息。例如，AD类型可以具有指示“基于帐户的配对”的值。另外，AD数据可以包括基于用户的凭证信息生成的散列值。

因此，为了传送在广告数据中包括凭证信息的广告分组，可以通过在广告分组(具体而言，广告通道PDU的有效载荷)中包括基于凭证信息的信息并改变它以包括指示它的AD类型来设计它。

因此，通过广告基于用户的凭证信息的信息，根据本公开内容的基于用户帐户的连接方法甚至可以应用于支持现有广告分组格式的设备。

用户凭证信息还可以包括各种信息。例如，用户凭证信息还可以包括设备型号标识符、公钥、散列值、帐户名称、许可级别、刷新周期、凭证有效性、凭证类型和帐户类型中的一个或更多个。

返回参照图21，提供者#1可以以图22中所示的格式广告包括用户凭证信息的广告分组。

在接收到包括用户的凭证信息的广告分组时，帐户管理器#2可以通知用户其可以连接到提供者#1设备。

在此，帐户管理器#1和帐户管理器#2可以对应于与同一用户帐户相关联的设备。因此，帐户管理器#2可以将具有其相关联的用户帐户的凭证信息的提供者#1确定为相应用户的设备。

另外，帐户管理器#2可以省略诸如用于初始配对的认证的过程并且支持与提供者#1配对，即使其先前从未与提供者#1连接或配对。

也就是说，即使提供者#1是用于帐户管理器#2的新的配对目标设备，帐户管理器#2也可以通知用户与提供者#1配对是可能的，就好像其先前已经与提供者#1配对过一样。

例如，帐户管理器#2可以将提供者#1显示为用户的设备(包括诸如用户ID、电子邮件地址等的用户标识信息)并经由UI通过连接确认请求来通知用户。

如果用户允许帐户管理器#2与提供者#1之间的连接，则可以执行基于帐户的自动连接过程。

图23是用于描述可以应用本公开内容的自动认证方法的附加示例的图。

在图23的示例中，将省略与图21的示例交叠的部分的描述。

将描述在图23中用于将凭证信息从帐户管理器#1递送至帐户管理器#2的过程。用户的凭证信息可以在帐户管理器(或搜索者)之间(例如，在智能电话与膝上型计算机之间)直接被递送。例如，由帐户管理器#1持有的用户的凭证信息可以被直接递送到一个或更多个其他帐户管理器(例如，帐户管理器#2和/或帐户管理器#3)。

作为另一个示例，帐户管理器#1可以通过向服务器发送注册设备消息将用户帐户与一个或更多个其他帐户管理器(例如，帐户管理器#2和/或帐户管理器#3)相关联(或注册)。通过这，即使用户不直接操作帐户管理器#2设备，帐户管理器#3设备也可以通过帐户管理器#1而注册到他们的帐户，帐户管理器#1是特定设备(例如，用户的优选设备)。因此，帐户服务器可以通过与帐户管理器#3的消息交换将用户的凭证信息传送至帐户管理器#3。

因此，已经从服务器或从另一帐户管理器接收到用户的凭证信息的帐户管理器(或搜索者)可以执行与广告用户的凭证信息(或基于其的信息)的提供者设备基于用户帐户而自动连接。

同时，服务器可以定期或在发生预定事件(例如，凭证有效期到期等)时执行刷新用户凭证信息的过程。当用户凭证信息被更新时，持有更新的凭证信息的服务器或帐户管理器可以将更新的凭证信息传送至另一个帐户管理器。

另一方面，如果帐户管理器#1与提供者#1建立安全链路，则从帐户管理器#1接收用户凭证信息并与提供者#1建立连接的帐户管理器#2可以被限制成使得该帐户管理器#2不能与提供者#1建立比帐户管理器#1和提供者#1的安全级别更高级别的连接。在直接从服务器获得凭证信息的帐户管理器#3的情况下，该安全级别限制可能不适用。

作为附加示例，提供者#1和提供者#2可以是被配置为一套的两个设备(例如，一对耳塞式耳机)。在这种情况下，两个设备之中的一个代表性设备可以广告用于基于帐户的自动连接的基本信息。例如，提供者#1可以预先获得提供者#2的信息，并且可以通过生成包括提供者#2的信息的广告分组来执行广告。在这种情况下，可以从提供者#1或提供者#2中的至少一个获得用户的凭证信息(或基于其生成的信息)，并且提供者之一可以以其他提供者名义(或代表其他提供者)或者通过从其他提供者接收必要的信息来执行包括凭证信息(或基于其生成的信息)的广告。

图24是示出了可以应用本公开内容的基于帐户的自动连接的应用示例的图。

在步骤1中，帐户管理器#1可以通过诸如服务订阅和登录到帐户服务器的过程来交换用户凭证信息。例如，用户凭证信息可以包括用于特定商店(例如，商店A)的用户凭证信息(例如，商店A的凭证信息)。在此，假设部署在商店A中的提供者预先具有用于商店A的凭证信息。例如，商店A的代表性设备可以从帐户服务器接收关于商店A的凭证信息，并且可以将其提供至部署在商店A中的一个或更多个提供者。

在步骤2中，用户可以带着安装有帐户管理器#1的设备(例如，智能电话)移动到特定地点。特定地点提供由用户订阅的服务，但是可以是用户首次访问的商店(例如，商店A)。也就是说，假设部署在特定商店(商店A)中的提供者(例如，无线充电器)是新的配对目标设备，该新的配对目标设备与安装帐户管理器#1的设备没有连接历史。

在步骤3中，提供者可以广告其预先具有的用于商店A的凭证信息。因此，在步骤4中，帐户管理器#1可以与提供者建立基于帐户的自动连接。由于提供者的凭证信息广告和基于此的基于帐户的自动连接的详细操作与上述示例相同，因此将省略冗余描述。

在步骤5中，通过帐户管理器#1与提供者自动建立基于帐户的连接的设备可以通过提供者接收服务(例如，无线充电)。

因此，帐户管理器#1可以通过立即完成配对来接收服务，就像之前具有与相应提供者配对的历史一样，而无需通过与新的配对目标提供者的单独认证过程。

图25是用于描述可以应用本公开内容的基于帐户的配对方法的图。

在步骤S2510中，搜索者设备(或帐户管理器设备)可以从服务器(或帐户服务器或凭证代理)获得关于提供者设备的凭证信息。

在步骤S2520中，搜索者设备可以从提供者设备获得广告分组。广告分组可以包括基于由提供者设备持有的凭证信息的散列值。

在步骤S2530中，搜索者设备可以根据基于在步骤S2510中从服务器获得的凭证信息和在步骤S2520中从提供者设备获得的凭证信息的散列值来确定是否与提供者设备连接。

例如，当作为从提供者获得的散列值的基础的凭证信息与从服务器获得的凭证信息相同时，搜索者设备可以与相应提供者建立连接。

如果从提供者设备接收到的广告分组不包括基于凭证信息的散列值(例如，如果服务器不持有用于提供者设备的凭证信息，因此搜索者设备也不持有用于提供者设备的凭证信息，并且提供者和搜索者第一次配对)，则搜索者设备和提供者设备可以建立一般配对(或具有较低安全级别的连接)而不是基于帐户的配对。因此，搜索者设备可以检查相应的提供者设备是否是可信设备。

如果提供者设备是可信设备，则搜索者设备可以向提供者设备提供凭证信息。

此后，提供者设备可以广告包括基于更新的凭证信息的散列值的广告分组。

在下文中，将描述根据本公开内容的媒体同步的示例。

在生成媒体(音频和/或视频)数据时，可以使用一个或更多个音频记录设备(例如，麦克风)以及一个或更多个视频记录设备(例如，摄像机)。在这种情况下，需要音频数据与视频数据之间的时间同步、多个音频数据之间的时间同步或多个视频数据之间的时间同步，以用于媒体数据的编辑等。

当这些音频/视频记录设备被无线连接时，存在的问题是时间同步不容易。例如，由于应用了基于设备制造商的技术的各种音频/视频时间同步方法，因此难以使用不同制造商的设备来配置各种拓扑。

在该实施方式中，可以包括使用预定媒体同步时钟提供媒体数据的时间同步的方法。媒体同步时钟可以是在不同设备中彼此同步的时钟。

该实施方式包括基于媒体同步时钟向媒体数据提供时间参考点。例如，通过将由第一设备生成的第一音频数据与基于媒体同步时钟的时间戳相关联并且将由第二设备生成的第二音频数据与基于媒体同步时钟的时间戳相关联，可以基于在第一设备和第二设备中彼此同步的时间戳来使第一音频数据和第二音频数据对准。

例如，媒体同步时钟可以是蓝牙时钟(BT时钟)。例如，通过调整由蓝牙方法连接的设备中的每一个的内部时钟，它可以提供在设备之间相互同步的临时BT时钟。

因此，根据本公开内容，可以使用基于标准化BT时钟的同步来提供时间同步。例如，通过传送包括在音频信息中的基于BT时钟的时间戳，可以基于时间戳来使音频流对准。

本公开内容的实施方式可以应用于如下情况，在这种情况下，在通过连接无线麦克风和智能电话来在智能电话中接收和存储无线麦克风的音频输入的同时，通过摄像机记录视频。在这种情况下，音频控制或麦克风相关的控制是可能的。

例如，当摄像机被暂停时，周围同步的麦克风和设备被暂停，并且当摄像机被再次操作时，附近同步的麦克风和设备恢复操作，从而提供使用的便利性。

图26是用于描述可以应用本公开内容的媒体同步时钟的图。

蓝牙设备可以具有其自己的本地时钟。本地时钟可以从自由运行的参考时钟得到。为了使蓝牙设备的本地时钟与非蓝牙设备同步，可以对参考时钟应用偏移。为了使蓝牙设备的本地时钟与其他蓝牙设备同步，可以向每个本地时钟添加适当的偏移，因此可以提供在蓝牙设备之间相互同步的临时时钟，如上所述，在本公开内容中，设备之间同步的时钟可以被称为媒体同步时钟。例如，媒体同步时钟可以对应于BT时钟。

媒体同步时钟可以与一天中的时间(ToD)无关，并且可以被初始化为任意值。媒体同步时钟可以在长度上具有大约一天的周期。参照图24，例如，当媒体同步时钟被实现为28位计数器时，0到2²⁸-1的值可以回绕。最低有效位(LSB)可以以312.5us(微秒)(或半个时隙)为单位滴答一次，并且时钟速率可以是3.2kHz。另外，参考时钟在待机、保持等状态下可以具有高达250ppm(百万分之一)误差的精度，而在其他状态下可以具有20ppm误差的精度。这种精度可以用于在网络内执行时钟调整。

如上所述，当配置设备之间同步的媒体同步时钟时，基于媒体同步时钟的参考点(例如，时间戳)可以被包括在媒体数据中。这样的参考点可以用于在处理媒体数据的过程中匹配(或对准)来自不同源的媒体数据的同步。

例如，来自不同源的媒体数据的同步可以在数据生成、后处理(例如，编辑、混合等)、传输、回放等期间被执行。

图27是用于描述可以应用本公开内容的基于媒体同步时钟的媒体数据同步方法的图。

例如，包括音频输入#1和音频输入#2的设备可以各自是无线麦克风设备。

视频记录器和音频接受器可以对应于在一个设备中包括的功能单元。例如，视频记录器和音频接受器可以被包括在智能电话或摄像机中。此外，音频接受器可以包括音频输入#3。

包括音频输入#1的设备#1、包括音频输入#2的设备#2和包括视频记录器和音频接受器的设备#3可以构成网络拓扑。例如，设备#1和设备#3可以配对。此外，设备#2和设备#3可以配对。另外，M个音频输入和N个音频接受器可以建立多对多(或M:N)配对。

在设备彼此配对之后，每个设备的媒体同步时钟可以被同步。例如，可以检查每个设备的内部时钟之间的偏移，并且可以基于此来配置在多个设备中同步的媒体同步时钟。例如，设备#1的时钟相对于设备#3可以具有625us的偏移，而设备#2的时钟相对于设备#3可以具有1.25ms的偏移。通过反映这些偏移中的每一个，可以在设备#1到设备#3之间设置同步的媒体同步时钟。同时，假设包括在一个设备#3中的视频记录器和音频接受器(或音频输入#3)彼此同步。

当在多个设备中配置同步的媒体同步时钟时，每个设备可以将基于媒体同步时钟的时间戳与其生成的媒体数据相关联。

例如，音频输入#1可以包括基于在设备#1的位置处记录的音频生成的音频流#1中的时间戳。音频输入#2可以包括基于在设备#2的位置处记录的音频生成的音频流#2中的时间戳。视频记录器可以包括基于正在设备#3的位置处记录的视频生成的视频流中的时间戳。音频输入#3可以包括基于在设备#3的位置处记录的音频生成的音频流#3中的时间戳。

设备#1可以将包括时间戳的音频流#1传送至设备#3的音频接受器。设备#2可以将包括时间戳的音频流#2传送至设备#3的音频接受器。因此，音频接受器可以通过使用基于媒体同步时钟提供的时间戳值，针对从不同设备递送的音频流#1和音频流#2执行音频流同步或对准。

如果设备#3生成包括时间戳的音频流#3，则音频接受器可以使用基于媒体同步时钟提供的时间戳值，针对音频流#1、音频流#2和音频流#3执行音频流同步或对准。

另外，设备#3可以使用基于媒体同步时钟分配的时间戳值，针对由其自身生成的视频流以及由其自身生成的或从外部设备递送的音频流来执行音频流同步或对准。

因此，可以根据基于同步时钟分配的时间戳值来同步由不同设备生成的媒体流。也就是说，多通道音频可以被同步和存储，音频和视频混合可以被执行，并且以这种方式生成的音频/视频(A/V)内容数据可以被传送至服务器并被存储在服务器中。

另外，如在本公开内容中，当多个设备之间的媒体同步时钟被配置时，媒体控制操作可以基于此同步地被执行。

例如，当在设备#3中执行开始或恢复视频或音频记录的操作时，可以将指示这的控制消息传送至设备#1或设备#2中的一个或更多个。指示记录开始或恢复操作的消息可以包括基于媒体同步时钟的时间戳值。因此，接收消息的设备#1或设备#2中的至少一个可以在由时间戳值指示的时间点处开始或恢复音频记录。

此外，当在设备#3中执行暂停视频或音频记录的操作时，指示这的控制消息可以被传送至设备#1或设备#2中的一个或更多个。指示记录暂停操作的消息可以包括基于媒体同步时钟的时间戳值。因此，接收消息的设备#1或设备#2中的至少一个可以在由时间戳值指示的时间点处暂停音频记录。

在此，可以假设，与在设备中执行音频记录控制的延迟相比，在设备之间交换媒体控制消息的延迟非常短。

因此，即使用户没有对设备#1或设备#2执行单独的音频记录操作，也可以通过用户对设备#3的操作来对设备#1或设备#2自动执行媒体控制。

作为附加示例，设备#1的位置信息可以被包括在音频流#1中。此外，设备#2的位置信息可以被包括在音频流#2中。设备#1或设备#2的位置信息可以是指示绝对位置的信息或指示相对于设备#3的相对位置的信息。

该位置信息可以用于混合由音频接受器自身生成的或从外部传送的多个媒体流。因此，可以生成包括基于位置或基于音频对象的音频内容的媒体数据。

例如，设备#1可以是相对于设备#3位于右侧的麦克风，并且设备#2可以是相对于设备#3位于左侧的麦克风。因此，当设备#3混合多个音频流时，音频流#1可以被映射到位于图像的左侧位置处的音频对象，并且音频流#2可以被映射到位于图像的右侧位置处的音频对象。因此，它可以在再现混合的A/V数据时向观众提供空间感。

另外，即使设备#1和设备#2的位置被实时改变，由于基于媒体同步时钟的时间戳被包括在媒体流中，因此可以标识音频流#1和音频流#2各自都包含在特定时间的特定位置处的音频数据。

例如，时间戳值或位置信息中的一个或更多个可以被包括在媒体数据的有效载荷中或者被包括在媒体数据的报头部分中。

图28是示出了可以应用本公开内容的第一设备和第二设备的配置的图。

第一设备2800可以包括处理器2810、天线单元2820、收发器2830和存储器2840。

处理器2810可以执行基带相关的信号处理，并且可以包括主机处理单元2811和控制器处理单元2815。主机处理单元2811和控制器处理单元2815可以通过HCI交换信息。主机处理单元2811可以处理诸如L2CAP配置文件层、ATT配置文件层、GATT配置文件层、GAP配置文件层和LE配置文件层的操作。控制器处理单元2815可以处理诸如LL层和PHY层的操作。除了执行基带相关的信号处理之外，处理器2810还可以控制第一设备2800的整体操作。

天线单元2820可以包括一个或更多个物理天线。收发器2830可以包括RF(射频)发送器和RF接收器。存储器2840可以存储由处理器2810和软件处理的信息、操作系统以及与第一设备2800的操作相关的应用，并且可以包括诸如缓冲器等的部件。

第一设备2800的处理器2810可以被配置成：实现本公开内容中描述的实施方式中的第一设备(或者音频源设备或客户端设备)的操作。

例如，第一设备2800(例如，搜索者设备)的处理器2810的主机处理单元2811可以从服务器(例如，帐户服务器或凭证代理)获得有关第二设备2850(例如，提供者设备)的凭证信息。

此外，主机处理单元2811可以通过控制器处理单元2815获得包括在第二设备2850的广告分组中的基于凭证信息的散列值。

此外，主机处理单元2811可以基于从服务器获得的凭证信息和从提供者获得的散列值来确定是否与提供者建立连接。

第二设备2850可以包括处理器2860、天线单元2870、收发器2880和存储器2890。

处理器2860可以执行基带相关的信号处理，并且可以包括主机处理单元2861和控制器处理单元2865。主机处理单元2861和控制器处理单元2865可以通过HCI交换信息。主机处理单元2861可以处理诸如L2CAP配置文件层、ATT配置文件层、GATT配置文件层、GAP配置文件层和LE配置文件层的操作。控制器处理单元2865可以处理LL层、PHY层等的操作。除了执行基带相关的信号处理之外，处理器2860还可以控制第二设备2860的整体操作。

天线单元2870可以包括一个或更多个物理天线。收发器2880可以包括RF发送器和RF接收器。存储器2890可以存储由处理器2860和软件处理的信息、操作系统以及与第二设备2850的操作相关的应用，并且可以包括诸如缓冲器等的部件。

第二终端设备2850的处理器2860可以被配置成：实现本公开内容中描述的实施方式中的第二设备(或者音频信宿或者服务器设备)的操作。

例如，当从第一设备2800(或搜索者设备)获得(更新的)凭证信息时，第二设备2850(或提供者设备)的处理器2860的主机处理单元2861可以基于相应的凭证信息生成散列值。此外，主机处理单元2861可以将生成的散列值传送至控制器处理单元2865，以通过广告分组被广告。此外，主机处理单元2861可以根据来自第一设备2800的连接请求与第一设备2800建立连接。

当控制器处理单元2865不保留凭证信息时，控制器处理单元2865可以广告不包括散列值的通用广告分组。

在第一设备2800和第二设备2850的操作中，在本公开内容的示例中，第一设备(或搜索者设备)和第二设备(或提供者设备)的描述可以同样适用，并且将省略交叠的描述。

本公开内容的各种实施方式可以由硬件、固件、软件或其组合来实现。为了通过硬件实现，本公开内容的各种实施方式可以被实现为一个或更多个专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、通用器件。它可以由处理器(通用处理器)、控制器、微控制器、微处理器等来实现。

本公开内容的范围包括软件或机器可执行指令(例如，操作系统、应用、固件、程序等)以及非暂态计算机可读介质，所述软件或机器可执行指令使根据各种实施方式的方法的操作在设备或计算机上被执行，这样的软件或指令被存储在所述非暂态计算机可读介质中并且在设备或计算机上被执行。可以被用于编程处理系统以执行本公开内容中描述的特征的指令可以被存储在存储介质或计算机可读存储介质上/中，并且可以使用包括这样的存储介质的计算机程序产品来实现本公开内容中描述的特征。存储介质可以包括但不限于诸如DRAM、SRAM、DDR RAM的高速随机存取存储器或其他随机存取固态存储器设备、一个或更多个磁盘存储设备、光盘存储设备、闪存设备；或者存储介质可以包括非易失性存储器，例如其他非易失性固态存储设备。存储器可选地包括从处理器远程定位的一个或更多个存储设备。存储器或可替选地存储器内的非易失性存储器设备包括非暂态计算机可读存储介质。本公开内容中描述的特征可以被存储在机器可读介质中的任何一个上以控制处理系统的硬件，并且它可以被并入至如下软件和/或固件中，所述软件和/或固件允许处理系统与其他机构进行交互，所述其他机构利用根据本公开内容的实施方式的结果。这样的软件或固件可以包括但不限于应用代码、设备驱动程序、操作系统和执行环境/容器。

【工业实用性】

本公开内容的实施方式可以应用于各种无线通信系统以提高无线通信系统的性能。

Claims (9)

1.一种用于在无线通信系统中执行基于帐户的配对的方法，所述方法包括：

由搜索者设备从服务器获得关于提供者设备的凭证信息；

由所述搜索者设备从所述提供者设备获得包括基于凭证信息的散列值的广告分组；以及

由所述搜索者设备根据所获得的凭证信息和基于所获得的凭证信息的散列值来与所述提供者设备建立连接。

2.根据权利要求1所述的方法，其中，

基于由所述搜索者设备从所述服务器获得的关于所述提供者设备的凭证信息以及与所述散列值相对应的凭证信息是相同的，所述搜索者设备与所述提供者设备建立连接。

3.根据权利要求1所述的方法，其中，

如果从所述提供者设备接收到的广告分组不包括基于所述凭证信息的散列值，

则当所述搜索者设备与所述提供者设备建立连接时，所述搜索者设备确认所述提供者是否是可信设备。

4.根据权利要求3所述的方法，其中，

如果所述提供者设备是可信设备，则所述搜索者设备将凭证信息提供至所述提供者设备。

5.根据权利要求4所述的方法，其中，

从所述提供者设备提供的广告分组包括基于从所述搜索者设备提供的更新的凭证信息的散列值。

6.根据权利要求1所述的方法，其中，

所述凭证信息包括以下中的至少一个：

与和所述搜索者设备或所述提供者设备中的至少一个相关联的用户帐户相关的信息；

与所述服务器、所述搜索者设备或所述提供者设备中的至少一个相关的信息；或者

和所述搜索者设备与所述提供者设备之间的加密相关的信息。

7.根据权利要求1所述的方法，其中，

所述搜索者设备、所述提供者设备或所述服务器中的至少一个支持带外(OOB)数据交换。

8.根据权利要求1所述的方法，其中，

所述凭证信息在预定时间内是有效的。

9.一种在无线通信系统中执行基于帐户的配对的搜索者设备侧的装置，所述装置包括：

收发器，所述收发器用于执行与另一装置的信号发送和接收；以及

处理器，所述处理器用于控制所述收发器和所述装置，

其中，所述处理器被配置成：

由搜索者设备从服务器获得关于提供者设备的凭证信息；

由所述搜索者设备从所述提供者设备获得包括基于凭证信息的散列值的广告分组；以及

由所述搜索者设备根据所获得的凭证信息和基于所获得的凭证信息的散列值来与所述提供者设备建立连接。

Images