用于支持对等无线显示系统中的多个阱设备群的会话管理和控制规程的利记博彩app

用于支持对等无线显示系统中的多个阱设备群的会话管理和控制规程的利记博彩app
【专利摘要】描述了用于会话管理和控制规程以支持对等无线显示系统中的多个阱设备群的装置和方法。一个实现可包括被配置成向多个阱设备传送多媒体内容的装置。该装置可包括被配置成通过Wi?Fi对等连接来连接到每一阱设备的处理器。该处理器可被进一步配置成从每一阱设备接受能力信息。该处理器可被进一步配置成生成包括群会话ID和传输端口号的控制消息。该处理器可被进一步配置成确定用于阱设备的流送参数集。该处理器可被进一步配置成使用该传输端口号并根据该流送参数集来向每一Wi?Fi对等连接的阱设备传送该特定多媒体内容。
【专利说明】
用于支持对等无线显示系统中的多个阱设备群的会话管理和 控制规程
技术领域
[0001] 所描述的技术一般设及多媒体内容的无线流送。更具体而言，本公开设及用于支 持对等无线显示系统中的多个阱设备群的会话管理和控制规程。
[0002] 戦
[0003] 已经做出最新的进步W允许将视频和音频从一个启用无线通信的设备直接流送 到另一个启用无线通信的设备。一种运样的系统被称为"Miracast"eMiracast是由Wi-Fi联 盟颁布的无线（例如，I邸E 802.11无线协议族或"Wi-Fi")显示协议的商标。如此处所使用 的，术语Miracast指的是Wi-Fi联盟的显示共享协议的当前形式，其也被称为Wi-Fi显示 (WFDKMiracast规范被设计成用于将任何类型的视频比特流从源设备流送到阱设备。作为 一个示例，源可W是智能电话，而阱可W是电视机。尽管在典型的IEEE 802.11无线网络中， 客户机设备通过接入点(AP)设备来进行通信，但存在支持直接设备通信的协议(诸如Wi-Fi Direct) nMiracast系统使用运些协议来将显示数据从一个设备发送到另一设备，诸如从智 能电话发送到电视机或计算机，或反之。Miracast系统设及将源设备的帖缓冲器W及扬声 器音频的内容通过Wi-Fi连接共享到远程显示器/扬声器设备(阱）。
[0004] Miracast协议设及源捕捉来自帖缓冲器的RGB数据W及来自音频子系统的任何 PCM(脉冲编码调制）音频数据。帖缓冲器中的内容可W从在该源上运行的应用程序或媒体 播放器中导出。源然后压缩视频和音频内容并将运些数据传送到阱设备。当接收到比特流 时，阱对该比特流进行解码并将其呈现在该阱的本地显示器和/或扬声器上。
[0005] 当前Miracast规范主要处置用于从一个源设备到一个阱设备的多媒体流送的会 话建立和控制。为了支持将媒体内容从一个源设备共享到若干阱设备，Wi-Fi显示会话管理 需要增强W允许控制向阱设备群的媒体流送。
[0006] 概述
[0007]提供了配置成向多个阱设备传送多媒体内容的装置。该装置包括被配置成通过 Wi-Fi对等连接来连接到该多个阱设备中的每一者的处理器。该处理器被进一步配置成从 请求特定多媒体内容的每一 Wi-Fi对等连接的阱设备接收能力信息。该处理器被进一步配 置成生成包括群会话ID和传输端口号的控制消息，该传输端口号将用于向每一 Wi-Fi对等 连接的阱设备传递与该群相关联的特定多媒体内容。该处理器被进一步配置成向每一 WiFi 对等连接的阱设备传送该控制消息。该处理器被进一步配置成确定用于与该群会话 ID 相 关联的Wi-Fi对等连接的阱设备的流送参数集。该处理器被进一步配置成使用传输端口号 并根据该流送参数集来向每一 Wi-Fi对等连接的阱设备传送该特定多媒体内容。
[000引提供了向多个阱设备传送多媒体内容的方法。该方法包括通过Wi-Fi对等连接来 连接到该多个阱设备中的每一者。该方法还包括从请求特定多媒体内容的每一 Wi-Fi对等 连接的阱设备接收能力信息。该方法还包括生成包括群会话ID和传输端口号的控制消息， 该传输端口号将用于向每一 Wi-Fi对等连接的阱设备传达与该群相关联的特定多媒体内 容。该方法还包括向每一 Wi-Fi对等连接的阱设备传送该控制消息。该方法还包括确定用于 与该群会话ID相关联的Wi-Fi对等连接的阱设备的流送参数集。该方法还包括使用该传输 端口号并根据该流送参数集来向每一 Wi-Fi对等连接的阱设备传送该特定多媒体内容。
[0009] 提供了用于向多个阱设备传送多媒体内容的装备。该装备包括用于通过Wi-Fi对 等连接来连接到该多个阱设备中的每一者的装置。该装备还包括用于从请求特定多媒体内 容的每一 Wi-Fi对等连接的阱设备接收能力信息的装置。该装备还包括生成包括群会话ID 和传输端口号的控制消息的装置，该传输端口号将用于向每一 Wi-Fi对等连接的阱设备传 递与该群相关联的特定多媒体内容。该装备还包括用于向每一 Wi-Fi对等连接的阱设备传 送该控制消息的装置。该装备还包括用于确定用于与该群会话ID相关联的Wi-Fi对等连接 的阱设备的流送参数集的装置。该装备还包括用于使用该传输端口号并根据该流送参数集 来向每一 Wi-Fi对等连接的阱设备传送该特定多媒体内容的装置。
[0010] 提供了包括代码的非瞬态计算机可读介质，该代码在被执行时使一装置向多个阱 设备传送多媒体内容。该介质还包括在被执行时使一装置通过Wi-Fi对等连接来连接到多 个阱设备中的每一者的代码。该介质还包括在被执行时使一装置从请求特定多媒体内容的 每一 Wi-Fi对等连接的阱设备接收能力信息的代码。该介质还包括在被执行时使一装置生 成包括群会话ID和传输端口号的控制消息的代码，该传输端口号将用于向每一 Wi-Fi对等 连接的阱设备传达与该群相关联的特定多媒体内容。该介质还包括在被执行时使一装置向 每一 Wi-Fi对等连接的阱设备传送该控制消息的代码。该介质还包括在被执行时使一装置 确定用于与该群会话ID相关联的Wi-Fi对等连接的阱设备的流送参数集的代码。该介质还 包括在被执行时使一装置使用该传输端口号并根据该流送参数集来向每一 Wi-Fi对等连接 的阱设备传送该特定多媒体内容的代码。
[0011] 附图简述
[0012] 图IA是Miracast多媒体流送系统的一个实现中的源设备和阱设备的框图。
[0013] 图IB是图IA的Miracast多媒体流送系统的一个实现中的源设备的框图。
[0014] 图IC是图IA的Miracast多媒体流送系统的一个实现中的阱设备的框图。
[001引图2解说了在可W在图IA的Miracast多媒体流送系统内采用的无线设备中可利用 的各种组件。
[0016] 图3解说了从源设备到数个阱群的媒体流送的拓扑。
[0017] 图4解说了从源设备到多个阱群的媒体流送的编群示例。
[0018] 图5解说了阱设备加入源发起并控制的群会话的示例步骤序列。
[0019] 图6A解说了 Wi-Fi显示源设备与数个Wi-Fi显示阱设备之间的W源为中屯、的、基于 RTSP的能力协商和群会话建立方法的一个示例实现，并继续到图6B。
[0020] 图6B进一步解说了图6A的Wi-Fi显示源设备与数个Wi-Fi显示阱设备之间的W源 为中屯、的、基于RTSP的能力协商和群会话建立方法的示例实现。
[0021] 图7A解说了 Wi-Fi显示源设备与数个Wi-Fi显示阱设备之间的W源为中屯、的、基于 RTSP的群会话建立和能力协商方法的另一个示例实现，并继续到图7B。
[0022] 图7B进一步解说了图7A的Wi-Fi显示源设备与数个Wi-Fi显示阱设备之间的W源 为中屯、的、基于RTSP的群会话建立和能力协商方法的示例实现。
[0023] 图8A解说了 Wi-Fi显示源设备与数个Wi-Fi显示阱设备之间的W源为中屯、的、基于 RTSP的群会话建立和能力协商方法的另一个示例实现，并继续到图8B。
[0024] 图SB进一步解说了图8A的Wi-Fi显示源设备与数个Wi-Fi显示阱设备之间的W源 为中屯、的、基于RTSP的群会话建立和能力协商方法的示例实现。
[0025] 图9A解说了 Wi-Fi显示源设备与数个Wi-Fi显示阱设备之间的W源为中屯、的、基于 RTSP的群会话建立和能力协商方法的另一个示例实现，并继续到图9B。
[00%] 图9B进一步解说了图9A的Wi-Fi显示源设备与数个Wi-Fi显示阱设备之间的W源 为中屯、的、基于RTSP的群会话建立和能力协商方法的示例实现。
[0027]图IOA解说了 Wi-Fi显示源设备、Wi-Fi显示主控阱设备W及数个从属阱设备之间 的W阱为中屯、的、基于RTSP的群会话管理方法的示例实现，并继续至图10B。
[002引图IOB进一步解说了图IOA的Wi-Fi显示源设备、Wi-Fi显示主控阱设备W及多个从 属阱设备之间的W阱为中屯、的、基于RTSP的群会话管理方法的示例实现。
[0029] 图IlA解说了用于Wi-Fi显示群会话管理的示例子元素内容布局，并继续至图11B。
[0030] 图1IB进一步解说了图1IA的用于Wi-Fi显示群会话管理的示例子元素内容布局。
[0031] 图12解说了用于为群会话递送多媒体内容的数据面找的示例。
[0032] 各附图中解说的各种特征可能并非按比例绘制。相应地，出于清晰起见，各个特征 的尺寸可能被任意放大或缩小。另外，绘图中的一些可能并不描绘给定系统、方法或设备的 所有组件。最后，类似附图标记可被用于贯穿说明书和附图标示类似特征。
[0033] 详细描述
[0034] 下面结合附图阐述的详细描述旨在作为对本发明的特定实现的描述，而非旨在代 表可在其中实践本发明的仅有实现。贯穿本描述使用的术语"示例性"意指"用作示例、实例 或解说"，并且不应当一定要解释成优于或胜过其他示例性实现。本详细描述包括具体细 节，其目的在于提供对所公开的实现的透彻理解。在某些实例中，某些设备W框图形式示 出。
[0035] W下参照附图更全面地描述本新颖系统、装置和方法的各种方面。然而，所公开的 教导可用许多不同的形式实施并且不应解释为被限定于本公开通篇所给出的任何特定结 构或功能。确切而言，提供运些方面是为了使本公开将是透彻和完整的，并且其将向本领域 技术人员完全传达本公开的范围。基于本文中的教导，本领域技术人员应领会到，本公开的 范围旨在覆盖本文中公开的运些新颖的系统、装置和方法的任何方面，不论其是独立实现 的还是与本发明的任何其他方面组合实现的。例如，可W使用本文所阐述的任何数目的方 面来实现装置或实践方法。另外，本发明的范围旨在覆盖使用作为本文中所阐述的本发明 各种方面的补充或者与之不同的其他结构、功能性、或者结构及功能性来实践的装置或方 法。应当理解，本文所公开的任何方面可W由权利要求的一个或多个要素来实施。
[0036] 尽管本文描述了特定方面，但运些方面的众多变体和置换落在本公开的范围之 内。尽管提到了优选方面的一些益处和优点，但本公开的范围并非旨在被限定于特定益处、 用途或目标。确切而言，本公开的各方面旨在宽泛地适用于不同的无线技术、系统配置、网 络、和传输协议，其中一些藉由示例在附图和W下对优选方面的描述中解说。详细描述和附 图仅仅解说本公开而非限定本公开，本公开的范围由所附权利要求及其等效技术方案来定 义。
[0037] 如上所提及的，当前Miracast规范主要处置用于从一个源设备到一个阱设备的多 媒体流送的会话建立和控制。扩展一些实现W建立从源设备到多个阱设备中的每一者的个 体Wi-Fi显示(W抑)会话并向每一阱设备流送多媒体内容可W是有实现可能的。然而，会话 管理、会话控制W及媒体有效载荷处理要求维护分别的协议找和网络资源(例如，TCP/UDP 端口），并且运超出了当前Miracast规范的范围。另外，该办法的复杂性和带宽要求可能将 此类实现限于少量阱设备或低质量媒体格式。由于缺乏多会话处置(例如，如多播或广播那 样）的控制和灵活性，该办法还可能导致诸个体阱设备变得失步。此外，此类实现在各种产 品之间可能不是可互操作的。为了支持将媒体内容从一个源设备共享到若干阱设备，Wi-Fi 显示会话管理需要增强W允许控制到阱设备群的媒体流送。该增强可W按用于针对多设备 (1:N)拓扑的会话建立、会话控制W及数据面处置的新配置的形式出现。
[0038] 本公开设及允许此处被称为源的第一设备向此处被称为阱的一个或多个第二设 备递送多媒体内容W供在第二设备上显示的系统和方法。在一些实现中，每一个设备都能 够根据在此可被称为"Wi-Fi"的IE邸802.11无线通信协议族中的一个或多个协议来无线 地通信。尽管运些设备通常通过接入点（AP)而不是直接地通信，但已经开发出允许源设备 在不使用任何AP或其它中介的情况下直接向阱设备传送多媒体内容的协议。如上所述，一 个运样的协议被称为Miracast。W下阐述对该协议的增强和扩展。运些增强和扩展不仅适 用于Miracast,而且还适用于允许在本地环境中无线连接的设备上和之间传送、接收和呈 现显示数据的任何显示共享设备或协议、系统或方法，其中"本地"一般指无线LAN连接的范 围，诸如房间、建筑物内等等。
[0039] 在Miracast规范的当前状态中，不支持向阱群流送多媒体内容。能力协商和会话 建立被限于一个源设备和一个阱设备。此外，可能不支持对内容的任何多播/群播的流送控 审IJo为了解决至少运些问题，当前在Miracast中用于对等流送控制的RTSP(实时流送协议） 控制面可被扩展W管理阱设备群。此外，可基于阱设备群的能力来在逐群的基础上完成PES (分组化元流）、MPEG2-TS传输、W及RTP分组化。MPEG2-TS复用可包括多个节目的内容。此 夕h关于由RTSP控制找进行群寻址式帖递送的MAC层能力W及内容处理数据面的知识可使 得能对会话参数进行高效设置。
[0040] 现在参考图IA到1C，在Miracast系统中，可W在源设备30与阱设备32之间进行附 加控制通信和传递协议协商。如图IA所示，在源30处，将显示数据34路由至编码器36。在常 规Miracast系统中，编码器36和解码器38分别使用H. 264协议来对视频进行编码和解码。该 数据然后使用具有常规Miracast系统中的实时传输协议(RTSP)消息接发的MPEG2传输流来 被无线地传送到阱32。当在阱32处接收到该数据时，将该数据路由至对应的解码器38并将 其发送到阱32上的显示器40。还在源30和阱32之间传递控制信号。在常规Miracast系统中， 利用用于一个对等会话设立和会话维护的控制信号。
[0041] 现在参考图1B，解说了图1的源设备30的一个实现的框图。在图IB中，源设备包括 图形处理单元(GPU) 50、显示处理器/混合器52、帖缓冲器54和显示器56。该源可W正在运行 若干应用，诸如应用1 62和应用2 64等，其可提供显示数据W供呈现给用户。在源操作系统 的控制下，GPU 50和显示处理器/混合器52准备显示数据并填充帖缓冲器54, W供转发给显 示器56。该源还可包括媒体播放器66，其也通过视频解码器来将内容路由到显示处理器/混 合器52。
[0042] 镜像模式中的常规MIracast多媒体流送中在一个源设备到一个阱设备之间的数 据流由图IB解说。当正在执行Miracast镜像时，帖缓冲器54中相继的像素数据帖沿数据路 径80被路由到视频编码器72,经编码的数据由模块74组装成MPEG2传输流，由模块75将其与 RTP消息接发数据组合，并被路由到套接字77 W供传送到阱设备32。在常规Miracast中，编 码器72是H.264编码器，而套接字是UDP(用户数据报协议)套接字，且不支持其它选项。
[0043] 阱设备32在图IC中解说。在该阱中，套接字92接收传入数据流，用模块94提取RTP 报头信息，并且用模块96提取显示数据。显示数据可被路由至视频解码器98,然后至显示处 理器/混合器102,该显示处理器/混合器填充帖缓冲器104W供呈现在显示器106上。在常规 Miracast中，视频解码器98是H. 264解码器，运在与Miracast标准兼容的任何阱设备中是必 雨的。
[0044] 图2解说了可W在上述Miracast多媒体流送系统内采用的无线设备180中可利用 的各种组件。无线设备180是可被配置成实现本文描述的各种方法的设备的示例。
[0045] 无线设备180可包括控制无线设备180的操作的处理器184。处理器184也可被称为 中央处理单元(CPU)。可包括只读存储器(ROM)和随机存取存储器(RAM)两者的存储器186向 处理器184提供指令和数据。存储器186的一部分还可包括非易失性随机存取存储器 (NVRAM)。处理器184通常基于存储器186内存储的程序指令来执行逻辑和算术运算。存储器 186中的指令可W是可执行的W实现本文描述的方法。例如，取决于设备是源30、阱32、还是 两者，图1A、1B和IC中的框可W用处理器184和存储器186来实现。处理器184可包括用一个 或多个处理器实现的处理系统或者可W是其组件。运一个或多个处理器可W用通用微处理 器、微控制器、数字信号处理器(DSP)、现场可编程口阵列(FPGA)、可编程逻辑器件(PLD)JS 制器、状态机、选通逻辑、分立硬件组件、专用硬件有限状态机、或能够对信息执行演算或其 他操纵的任何其他合适实体的任何组合来实现。
[0046] 处理系统还可包括用于存储软件的机器可读介质。软件应当被宽泛地解释成意指 任何类型的指令，无论其被称作软件、固件、中间件、微代码、硬件描述语言、或是其他。指令 可包括代码(例如，呈源代码格式、二进制代码格式、可执行代码格式、或任何其他合适的代 码格式）。运些指令在由该一个或多个处理器执行时使处理系统执行本文描述的各种功能。
[0047] 无线设备180还可包括外壳188,该外壳188可包含发射机190和接收机192W允许 在无线设备180和远程位置之间进行数据的传送和接收。发射机190和接收机192可被组合 成收发机194。可提供天线196并使之电禪合至收发机194。无线设备180还可包括(未示出） 多个发射机、多个接收机、多个收发机、和/或多个天线。
[0048] 无线设备180还可包括可被用于力图检测和量化由收发机194接收到的信号电平 的信号检测器200。信号检测器200可检测诸如总能量、每副载波每码元能量、功率谱密度之 类的信号W及其他信号。无线设备180还可包括用于处理信号的数字信号处理器(DSP)202。 DSP 202可被配置成生成数据单元W供传输。无线设备180还可包括显示器204和用户接口 206。用户接口 206可包括触摸屏、小键盘、话筒和/或扬声器。用户接口206可包括向无线设 备180的用户传达信息和/或从该用户接收输入的任何元件或组件。
[0049] 无线设备180的各种组件可由一个或多个总线系统208禪合在一起。总线系统208 可包括例如数据总线，W及除了数据总线之外还有电源总线、控制信号总线和状态信号总 线。本领域技术人员将领会，无线设备180的各组件可禪合在一起或者使用某种其他机制来 接受或提供彼此的输入。
[0050] 尽管图2中解说了数个分开的组件，但运些组件中的一个或多个组件可被组合或 者共同地实现。例如，处理器184可被用于不仅实现W上关于处理器185描述的功能性，而且 还实现W上关于信号检测器200和/或DSP 202描述的功能性。另外，图7中解说的每个组件 可使用多个分开的元件来实现。另外，处理器184可被用于实现W下描述的组件、模块、电 路、或类似物中的任一者，或者每一者可使用多个分开的元件来实现。
[0051] 图3解说了从源设备300到K个阱群305-305K的媒体流送的拓扑。该WFD会话展示1: N拓扑。N个阱设备(310-310N)可被编群为K个阱群305-305K。每一群(G化），k=l，. .，K)可具 有Pk个阱设备W使
W便使用多个传输(例如，单播、单个多播、群播等)来从 源设备300发送媒体流。源设备300W及运N个阱设备310-310N可使用P2P连接(例如，对等、 Wi-Fi直连等）。运些规程也可W例如在使用TDLS(隧穿直接链路设立)连接时实现。此外，源 设备300还可被配置为软AP，且相关联的阱设备被配置为常规Wi-Fi STA。在一个实现中，运 K个阱群305-305K之一中的运N个阱设备310-310N可W是P2P群的一部分。
[0052] 该拓扑的示例用例包括智能电话或平板(作为源设备300)向多个膝上型设备或平 板(作为运N个阱设备310-310N)流送多媒体剪辑。该示例可包括教室共享，诸如向群的演 示。另一示例可包括平板(作为源设备300)将来自一个窗口的内容共享至N个阱设备310-310N的集合。可W存在多个阱设备群(305-305K)，且每一群可W从源设备300接收特异的内 容流。例如，多媒体内容可被流送至平板群(作为N个阱设备310-310N)，且音频可被流送至 共同的音频系统。另一示例可包括具有3G/4G数据连接的汽车耳机单元(作为源设备300)将 来自因特网的多媒体内容共享到乘客座位上的平板或无线耳机（作为N个阱设备310-310N)。发送到每一阱设备群305-305K的内容可W彼此不同，例如在一些设备上呈现电影剪 辑，而在其它设备上只呈现音乐。
[0053] 图4解说了从源设备400(例如，图3的源设备300)向多个阱群405A和405B(例如，图 3的运K个阱群305-305K中的任何阱设备）的媒体流送的编群示例。在一个示例中，阱群405A 包括两个阱设备410A和410B(例如，运N个阱设备310-310N中的任何阱设备），而阱群405B包 括S个阱设备410C、410D和410E(例如，运N个阱设备310-310N中的任何阱设备）。在一个示 例中，源设备400可W是蜂窝电话，而阱群405A可被用于向阱设备410A和410B传送具有72化 高清格式视频的多播视频，其可包括例如阱设备41OA中的超高清（4K 2160p)或全高清 (102化)DTV显示能力W及阱设备410B中的高清(720p)DTV显示能力。此外，阱群405B可被用 于向阱设备410C、410D和410E传送具有WVGA(800x480)格式的多播演示，阱设备410C、410D 和410E可包括例如具备不同的最大分辨率(例如，800x480p60、1024巧68p60等)能力的两个 平板显示器W及具有1280x960p60分辨率的膝上型设备显示器。
[0054] 图5解说了阱设备加入源发起并控制的群会话的示例步骤系列。运种类型的群会 话也可被称为源为中屯、的群"。
[0055] 在步骤1中，对等连接可W在源设备500(例如，图3的源设备300)与阱设备510A-510D(例如，N个阱设备310-310N中的任何阱设备)群之间建立。该对等连接也可被称为群会 话。为了发起连接，用户可W从源设备500启动Wi-Fi显示(W抑)应用W用于处置向阱设备群 的多媒体流送，运可导致源设备500向阱设备510A-510D宣告（例如，通告）其服务和群会话 能力。该宣告时段也可被称为P2P设备发现阶段。当MAC层支持或需要多播数据递送W用于 多播话务(例如，802.11定向多播服务(DMS)或带重试的群播(GCR))时，源设备500可能已经 通告其要成为群主的意图。在一个实施例中，源设备500和阱设备510A-510D可使用L3IGMP 协议(因特网群管理协议-RFC 3376)来建立群成员资格。
[0056] 为了支持Wi-Fi显示群操作，RTSP消息收发可由于其在消息交换方面的可靠性及 其对大量阱设备的处置而被用于群会话。取决于群中的阱设备的数目，源设备500可使用和 通告不同的RTSP信令和流送控制选项。例如，在存在大量阱设备(未描绘)的情形中，源设备 500可使用具有UDP的RTSP(RTSPU)方案（IETF RFC 2326)来用于其群会话(例如，共同会话） 发起请求消息(例如，诸如ANNOUNCE(通告)或SETUP(设立)之类的方法）。关于该方法W及其 它基于RTSP的方法的更多细节W下参照图6-9描述。
[0057] 不管所使用的RTSP方法如何，RTSP消息均可包括关于阱设备要加入群会话所要求 的能力的信息(例如，共同多媒体编解码器、共同多媒体格式、最小等待时间或缓冲器能力、 或者所支持的多播机制（例如，DMS或GCR))。在某些情形中，RTSP消息还可包括保活超时和 响应时间限制信息，源设备500可基于它旨在服务的阱设备的最大数目来设置运些信息。源 设备500也可基于合适的MC层传输方案(诸如单播、非GCR多播、DMS或GCR多播)来设置运一 信息。支持所要求的能力的每个阱设备(例如，510A-510DW及未描绘的任何附加阱设备何 响应所广播的RTSP消息。源设备500可W周期性地重传所广播的RTSP消息。运确保射程内的 所有阱设备都接收到RTSP消息和/或任何新发现的阱设备都有机会加入该群会话。
[0058] 在发现时段期间，各设备可W交换一个或多个MC帖(诸如探测请求、探测响应、或 信标帖(未示出））。包括所支持的群类型、任何预配置的编解码器和其它参数W及用于会话 管理控制的端口信息的群会话管理信息被包括在运些帖中W用于对等设备发现。基于所交 换的信息，阱设备510A-510G中的一者或多者可W拒绝与源设备500连接。在该示例中，阱设 备510D拒绝与源设备500连接。源设备500然后可创建UDP端口并将端口信息和其它会话控 制数据(例如，多播群)发送到其余阱。使用该信息和数据，各设备然后可形成对等连接或群 会话。
[0059] 在步骤2中，源设备500可使用具有关于数据面的信息的RTSP消息来宣告其群会话 配置，该信息可包括例如多媒体内容格式化、多播群信息W及UDP端口信息。通过宣告其关 于数据面的群会话配置，源设备500有效地邀请其它阱设备加入现有群会话。多媒体格式要 求的最小集合可被设为用于群会话的默认强制参数。在一个实施例中，用于群会话的共同 多媒体格式可W是固定的，例如CEA 1280x72化，24FPS分辨率。在一些实现中，相同的多媒 体内容可W用一个共同格式来流送到一个阱设备群，并且用另一共同格式来流送到另一阱 设备群。在该示例中，群会话505A包括阱设备510A-510C，而群会话505B包括阱设备510F-510G。阱设备510D未出现在任一群会话中，因为它在步骤1中拒绝了连接请求。源设备500可 W在有至少两个具有相同能力的阱设备要编群时建立群会话。
[0060] 为了提高效率并使处理最小化，源设备500可选择每一群中的预定数目的阱设备 成为"主动阱设备"。关于主动阱设备的信息可W在群会话管理数据中被更新。主动阱设备 可响应源设备500所发送的RTSP请求消息。被称为"被动阱设备"的其余阱设备不可响应该 RTSP请求消息并且可W从源设备500接收多媒体内容，并且W未经索求方式交换其能力信 息，例如与主动阱设备相比，被动阱设备只可从源设备500接收用于群会话中的流送的内容 格式W及端口信息。
[0061] 在步骤3中，源设备500可W开始在群会话505A中向阱设备510A-510C传送(例如， 流送)多媒体内容。在传输期间的任何时间，多媒体内容可基于媒体内容的原生格式来针对 可具有不同的编解码器或格式要求的不同多媒体内容进行切换。当阱设备无法支持内容的 原生格式时，可能需要转码至某一其它格式。在一个实现中，源设备500可将内容重新编码 成对于群会话505A中的所有阱设备510A-510C而言共同的格式。在群会话期间，源设备500 还可W使用如步骤2中那样的RTSP消息来周期性地宣告群会话配置。源设备500可处置绝大 多数流送控制，诸如"暂停"、"快进"、"倒回"、格式化改变等。
[0062] 在步骤4中，新阱设备510E可W接收在步骤2或3期间传送的群会话配置宣告消息， 并加入群会话505A。一旦新阱设备510E已经加入群会话505A，它也将接收到正从源设备500 传送到群会话505A的多媒体内容。新阱设备可W在任何时间请求加入群会话。类似地，当前 在群会话中的阱设备可W在任何时间请求离开群。
[0063] 图6(如由图6A和作为一个接续附图的图6B所解说的）解说了 Wi-Fi显示源设备与 数个Wi-Fi显示阱设备之间的W源设备为中屯、的、基于RTSP的能力协商和群会话建立方法 的一个示例实现。在所解说的示例中，所有阱设备都被假定为在同一群中。该方法在添加了 用于群会话建立和控制的消息和参数的情况下提高了 W上讨论的TCP端口上的单播RTSP消 息接发的效率。一般而言，在该方法中，源为了可靠的控制而建立个体RTSP连接，并且使得 在该群内的流送期间能够进行对媒体数据的多播，运适用于少量的阱设备。另外，如在步骤 670中描述的，源可生成群会话IDW用于在无需接收来自阱的SETUP请求的情况下自主地发 起群会话。
[0064] 在步骤661中，Wi-Fi显示源600发起与至少一个Wi-Fi显示阱610 (在该示例中与阱 610A)的发现阶段。在该发现阶段期间交换的发现信息可包括群会话管理和设备能力信息， 如W上参照图5描述的。发现阶段可W在所选信道(例如，信道1、6或11)上进行，运基于该信 道上的话务量。此外，发现信息可W经由探测请求帖和探测响应帖在源600与阱610之间被 交换。
[00化]在步骤662, 一个或多个阱610还可与源600交换服务发现信息。
[0066] 在步骤663,源600可W向用户650指示步骤661和662已经发生并通知用户650哪一 个或数个阱610已经在发现阶段期间被发现(在该示例中阱610A已被选择）。
[0067] 在步骤664,源600可完成与在发现阶段期间选择的该一个或数个阱610的连接设 立。在某些情形中，连接设立可W是Wi-Fi对等链路。
[0068] 在步骤665,源600可W在其自身与在发现阶段期间选择的该一个或数个阱610之 间交换能力信息。运一能力信息可包括多媒体编解码器、多媒体格式、最少等待时间或缓冲 器能力、或所支持的多播机制（例如DMS或GCR)等。源600可使用RTSP OPTIONS(选项）继W GET_PARAMETER(获取参数)命令通过包括群会话管理信息来交换并设置能力信息。
[0069] 在步骤666,源600可发起与附加阱610(在该示例中与阱610B和610C)的接续发现 阶段。在该发现阶段期间交换的发现信息可包括群会话管理和设备能力信息。该接续发现 阶段期间的信息交换可W-次与一个阱地发生，例如源600可W与阱610B交换发现信息并 且然后与阱610C交换发现信息。
[0070] 在步骤667, 一个或多个附加阱610(在此是610B和610C)也可交换来自源600的服 务发现信息。
[0071] 在步骤668,源600可W向用户650指示步骤666和667已经发生并通知用户650存在 且满足能力要求的数个阱610(在此是阱610A、610B和610C)已经在该发现阶段被选择。
[0072] 在步骤669,源600可W在其自身与在接续发现阶段期间选择的一个或数个附加阱 610(在此是610B和610C)之间交换能力信息。运一能力信息可包括多媒体编解码器、多媒体 格式、最少等待时间或缓冲器能力或所支持的多播机制（例如DMS或GCR)等。源600可使用 RTSP OPTIONS继W带群会话管理信息的GET_PARAMET邸命令来交换并设置能力信息。该阶 段期间的信息交换可W-次与一个阱地发生，例如源600可W与阱610B交换能力信息并且 然后与阱610C交换能力信息。
[0073] 在步骤670,源600可W准备好建立群会话。在其群会话建立中，源600可基于在上 述各步骤中所选择的一个或数个阱之间交换的能力信息来确定用于群会话的最优参数。源 600可W另外地为群会话生成会话ID。
[0074] 在步骤671，源600可进入宣告阶段，在该宣告阶段期间它可W向阱610之一(在该 情形中是阱610A)发送RTSP群会话信息的宣告。源600可使用RTSP ANNOUNCE命令来发送该 宣告。该宣告可包括关于呈现URL、编解码器参数、群IP地址、RTP端口号、W及与特定阱610 (在此是阱610A)的至阱会话ID的信息，等等。在宣告阶段期间，源600可W在W抑-TRIGGER-MET册D(W抑触发方法）=WA 口 (等待)命令下操作，在此期间它将等待播放多媒体内容。
[0075] 在步骤672,阱610(在此是阱610A)可W向源600发送RTSP OK消息，W指示它已经 接收到步骤671的宣告并且它准备好接收多媒体内容。
[0076] 在步骤673,源600可进入接续宣告阶段，在此期间它可W向附加阱610(在该情形 中是阱610B和610C)发送RTSP群会话信息的宣告。源600可再次使用RTSP ANNOUNCE命令来 发送该接续宣告。该接续宣告可包括关于呈现URL、编解码器参数、群IP地址、RTP端口号W 及将与特定附加阱610(在此是阱610B和610C)设立的会话ID的信息，等等。在该接续宣告阶 段期间，源600可W在W抑-TRIGGER-MET册D = PLAY(播放)命令下操作，在此期间源600可W 准备好向连接着的阱610(在此是阱610A、610B和610C)播放多媒体内容。
[0077] 在步骤674,附加阱610(在此是阱610B和610C)可W向源600发送RTSP OK消息，W 指示它们已经接收到步骤673的宣告并且它们准备好接收多媒体内容。
[007引在步骤675,一个或多个连接着的阱610可W经由RTSP呈现ML向源600发送播放请 求(例如，RTSP PLAY请求）。
[0079] 在步骤676,响应于步骤675的播放请求，源600可例如经由"播放响应or消息来通 知请求方阱610播放将开始。
[0080] 在步骤677,源600可W在群会话上向请求方阱610流送多媒体内容。在该时间期 间，源600可指示"正在播放"状态。
[0081] 在步骤678,请求方阱610可W从源600接收流送多媒体内容。
[0082] 在一个实现中，源600可选择跳过个体阱610能力交换（如W上在步骤665和669中 描述的），并且用预定的多媒体内容参数集(例如，内容格式)来开始群会话。预定的多媒体 内容参数集可改为在设备或服务发现阶段(如W上在步骤662和667中描述的）期间从阱610 获取。
[0083] 图7(如由图7A和作为一个接续附图的图7B所解说的）解说了 Wi-Fi显示源设备与 数个Wi-Fi显示阱设备之间的W源设备为中屯、的、基于RTSP的群会话建立和能力协商方法 的另一示例实现。在所解说的示例中，所有阱设备都被假定为在同一群中。该方法同样在添 加了用于群会话建立和控制的消息和参数的情况下提高了 W上讨论的TCP单播RTSP的效 率。一般而言，在该方法中，源为了可靠的控制而建立个体RTSP连接，并且使得在群内的流 送期间能够进行对媒体数据的多播，运适用于少量的阱设备。另外，如下所述，并且与图6中 的方法相比，源可执行与所选阱设备之一的设立交换。
[0084] 在步骤761中，Wi-Fi显示源700发起与至少一个Wi-Fi显示阱710(在该示例中与阱 710A)的发现阶段。在该发现阶段期间交换的发现信息可包括群会话管理和设备能力信息， 如W上参照图5描述的。发现阶段可W在所选信道(例如，信道1、6或11)上进行，运基于该信 道上的话务量。此外，发现信息可W经由探测请求帖和探测响应帖在源700与阱710之间被 交换。
[0085] 在步骤762,一个或多个阱710还可与源700交换服务发现信息。
[00化]在步骤763,源700可W向用户750指示步骤761和762已经发生并通知用户750哪一 个或数个阱710已经在发现阶段期间被发现(在该示例中阱710A已被选择）。
[0087] 在步骤764,源700可完成与在发现阶段期间选择的一个或数个阱710的连接设立。 在某些情形中，连接设立可W是Wi-Fi对等链路。
[0088] 在步骤765,源700可W在其自身与与在发现阶段期间选择的一个或数个阱710之 间交换能力信息。运一能力信息可包括多媒体编解码器、多媒体格式、最少等待时间或缓冲 器能力或所支持的多播机制（例如DMS或GCR)等。源700可使用RTSP OPTIONS和GET_ PARAMETER命令连同群会话管理信息来交换并设置能力信息。
[0089] 在步骤766,源700可发起与附加阱（在该示例中与阱710B和710C)的接续发现阶 段。在该发现阶段期间交换的发现信息可包括群会话管理和设备能力信息。该接续发现阶 段期间的信息交换可W-次与一个阱进行，例如源700可W与阱710B交换发现信息并且然 后与阱710C交换发现信息。
[0090] 在步骤767, 一个或多个附加阱710(在此是710B和710C)也可交换来自源700的服 务发现信息。
[0091] 在步骤768,源700可W向用户750指示步骤766和767已经发生并通知用户750存在 且满足能力要求的数个阱710(在此是阱710A、710B和710C)已经在该发现阶段被选择。
[0092] 在步骤769,源700可W在其自身与在接续发现阶段期间选择的一个或数个附加阱 710(在此是710B和710C)之间交换能力信息。运一能力信息可包括多媒体编解码器、多媒体 格式、最少等待时间或缓冲器能力或所支持的多播机制（例如DMS或GCR)等。源700可使用 RTSP OPTIONS和带有群会话管理信息的GET_PARAMET邸命令来交换并设置能力信息。该阶 段期间的信息交换可W-次与一个阱进行，例如源700可W与阱710B交换能力信息并且然 后与阱710C交换能力信息。
[0093] 在步骤770,源700可W准备好建立群会话。在其对群会话的建立中，源700可基于 在上述各步骤中所选择的一个或数个阱之间交换的能力信息来确定用于该群会话的最优 参数。如与图6中描述的方法相比，源700可能并不在此时为该群会话生成会话ID。
[0094] 在步骤771，源700可进入宣告阶段，在该宣告阶段期间它可W向阱710之一(在该 情形中是阱710A)发送RTSP群会话信息的宣告。源700可使用RTSP ANNOUNCE命令来发送该 宣告。该宣告可包括关于呈现URU编解码器参数、群IP地址、RTP端口号W及与特定阱710 (在此是阱710A)的至阱会话ID的信息，等等。在宣告阶段期间，源700可W在W抑-TRIGGER-METHOD = SETUP命令下操作，在此期间它将等待来自个体阱710 (在此是阱710A)的设立请 求。
[0095] 在步骤772,阱710(在此是阱710A)可W向源700发送RTSP OK消息，W指示它已经 接收到步骤771的宣告。
[0096] 在步骤773,单独阱710(在此是阱710A)可经由RTSP呈现U化来向源700发送RTSP设 立请求。
[0097] 在步骤774,源700可W向个体阱710(在此是阱710A)发送其对RTSP设立请求的确 认和批准。与图6相反，源700可W在此时发送群会话ID。
[0098] 在步骤775,源700可进入接续宣告阶段，在此期间它可W向附加阱710(在该情形 中是阱710B和710C)发送RTSP群会话信息的宣告。源700可再次使用RTSP ANNOUNCE命令来 发送该接续宣告。该接续宣告可包括关于呈现URL、编解码器参数、群IP地址、RTP端口号W 及与特定附加阱710(在此是阱710B和710C)的至阱会话ID的信息，等等。在该接续宣告阶段 期间，源700可W在W抑-TRIGGER-MET册D = SETUP命令下操作，在此期间源700可W等待来自 附加的连接着的阱710(在此是阱710B和710C)的设立请求。
[0099] 在步骤776,附加阱710(在此是阱710B和710C)可W向源700发送RTSP OK消息，W 指示它们已经接收到步骤775的宣告。
[0100] 在步骤777,附加阱710(在此是阱710B和710C)可经由RTSP呈现ML来向源700发送 RTSP设立请求。
[0101] 在步骤778,响应于设立请求，源700可W向附加阱710(在此是阱710B和710C)发送 其对RTSP设立请求的确认和批准。源700也可在此时发送群会话ID。
[0102] 在步骤779,一个或多个连接着的阱710可W经由RTSP呈现U化向源700发送播放请 求(例如，RTSP PLAY请求）。该播放请求可W根据群会话ID来发送。
[0103] 在步骤780，响应于步骤779的播放请求，源700可例如经由"播放响应or消息来通 知请求方阱710播放将开始。
[0104] 在步骤781，源700可W在群会话上向请求方阱710流送多媒体内容。在该时间期 间，源700可指示"正在播放"状态。
[0105] 在步骤782,请求方阱710可W从源700接收流送多媒体内容。
[0106] 在一个实现中，源700可选择跳过个体阱710能力交换(如W上在步骤765和769中 描述的），并且用预定的多媒体内容参数集(例如，内容格式)来开始群会话。预定的多媒体 内容参数集可改为在设备或服务发现阶段(如W上在步骤762和767中描述的）期间从阱710 获取。
[0107] 图8(如由图8A和作为一个接续附图的图8B解说的）解说了 Wi-Fi显示源设备与多 个Wi-Fi显示阱设备之间的W源设备为中屯、的、基于RTSP的群会话建立和能力协商方法的 另一示例实现。在所解说的示例中，所有阱设备都被假定为在同一群中。如与图6和7的基于 TCP的方法相比，该方法是用于更高效地建立Wi-Fi显示群会话的基于UDP的"RTSPU"方案， 该方案可使用多个重试功能性和机会来用于反馈(例如，W维持可靠性）。
[0108] 在步骤861中，Wi-Fi显示源800发起与至少一个Wi-Fi显示阱810 (在该示例中与阱 810A)的发现阶段。在该发现阶段期间交换的发现信息可包括群会话管理信息，如W上参照 图5描述的。在一个实现中，源800可使用发现信息来预定多媒体格式和参数集W使其可W 跳过W下的一些能力交换步骤(例如，步骤869、870和/或871)。发现阶段可W在所选信道 (例如，信道1、6或11)上发生，运基于该信道上的话务量。此外，发现信息可W经由探测请求 帖和探测响应帖在源800与阱810之间被交换。
[0109] 在步骤862,一个或多个阱810还可与源800交换服务发现信息。在一个实现中，源 800可使用服务发现信息来预定多媒体格式和参数集W使其可W跳过W下的一些能力交换 步骤(例如，步骤869、870和/或871)。
[0110] 在步骤863,源800可W向用户850指示步骤861和862已经发生并通知用户850哪一 个或数个阱810已经在发现阶段期间被选择(在该示例中阱810A已被选择）。
[0111] 在步骤864,源800可完成与在发现阶段期间选择的一个或数个阱810的连接设立。 在某些情形中，连接设立可W是Wi-Fi对等链路。
[0112] 在步骤865,源800可发起与附加阱（在该示例中与阱810B和810C)的接续发现阶 段。在该发现阶段期间交换的发现信息可包括群会话管理和设备能力信息。该接续发现阶 段期间的信息交换可W-次与一个阱进行，例如源800可W与阱810B交换发现信息并且然 后与阱810C交换发现信息。在一个实现中，源800可使用发现信息来预定多媒体格式和参数 集W使其可W跳过W下的一些能力交换步骤(例如，步骤869、870和/或871)。
[0113] 在步骤866, 一个或多个附加阱810(在此是810B和810C)也可交换来自源800的服 务发现信息。在一个实现中，源800可使用服务发现信息来预定多媒体格式和参数集W使其 可W跳过W下的一些能力交换步骤(例如，步骤869、870和/或871)。
[0114] 在步骤867,源800可完成与在接续发现阶段期间选择的附加阱810的连接设立。在 某些情形中，连接设立可W是Wi-Fi对等链路。
[0115] 在步骤868,源800可W向用户850指示步骤865-867已经发生并通知用户850存在 且满足能力要求的多个阱810(在此是阱810A、810B和810C)已经在该发现阶段被选择。在一 个实现中，如果源800已经预定了必需的多媒体格式和参数集W跳过能力交换，则源800或 用户850在此时可选择跳过步骤869、870和871。
[0116] 在步骤869，除非如上所示地被跳过，否则源800可W在其自身与在步骤861-867中 的发现阶段期间所选择的一个或数个阱810之间发送对能力信息的请求。该能力信息可包 括多媒体编解码器、多媒体格式、最少等待时间或缓冲器能力、或所支持的多播机制（例如 DMS或GCR)等。源800可将RTSP GET_PARAMET邸命令连同群会话管理信息一起用来交换并设 置能力信息。在一个实现中，源800可W为来自阱810的响应指定超时，如参照图5描述的。源 800可将响应超时基于所预期的网络往返时间（例如，对于Wi-Fi信道接入，往返时间可W是 50ms到500ms)。从源800发送的每一基于UDP的RTSP消息请求可包括至少基于该响应超时的 "响应时间限制"、"重试次数"W及"下一传送区阿'。每一基于UDP的RTSP消息请求还可包括 用W改进消息可靠性和清晰度的唯一性序列号(例如，CSeq报头）。
[0117] 在步骤870和871，除非如上所示地被跳过，否则源800可检索步骤869中从一个或 数个阱810请求的阱参数(例如，能力信息）。该阶段期间的信息交换可W-次与一个阱进 行，例如源800可W与阱810A交换能力信息（如在步骤870中）并且然后与阱810B或810C交换 能力信息(如在步骤871中）。
[0118] 在步骤872,源800可W准备好建立群会话。在其对群会话的建立中，源800可基于 在上述各步骤中所选择的一个或数个阱之间交换的能力信息来确定用于群会话的最优参 数。源800也可在此时生成群会话ID。
[0119] 在步骤873,源800可进入宣告阶段，在此期间它可W向连接着的阱810(例如，在此 是阱810A、810B和810C)发送RTSP群会话信息的宣告。源800可使用RTSP ANNOUNCE命令来发 送该宣告。该宣告可包括关于多播呈现URL、编解码器参数、群IP地址、RTP端口号、W及对于 群会话中的所有阱而言共同的会话ID的信息，等等。在宣告阶段期间，源800可W在WFD-TRIGG邸-METHOD=WAIT命令下操作，在运期间它将等待播放多媒体内容。该宣告还可遵循 响应超时和重试计数参数(如果在步骤869中确立了的话）。如果是，则源800可设置在继续 传送下一消息之前"只等待"来自一个或多个阱的响应预定的等待时间。此外，因为UDP上的 多播可减少协议处置负载，所W宣告中的RTSP多播呈现TOL可具有格式"rtspu://<host [":"port] [path]"。如在下文中进一步描述的，源800可继续传送宣告W招揽新阱加入该群 会话。该宣告可W按预定时间间隔被周期性地重复。被重复的宣告甚至可W在多媒体流送 已经开始(步骤880中）之后发生，如在步骤882中进一步描述的。
[0120] 在步骤874,阱810(在此是阱810A)可W向源800发送RTSP OK消息，W指示它已经 接收到步骤873的宣告。
[0121] 在步骤875,附加阱810(在此是阱810C)可W向源800发送RTSP OK消息，W指示它 们已经接收到步骤873的宣告。在一些实现中，该步骤可由于如上所述的超时和重试而被跳 过。
[0122] 如W上参照步骤873描述的，在步骤876,源800可继续传送宣告W招揽新阱加入该 群会话。该宣告可W按预定时间间隔被周期性地重复。被重复的宣告甚至可W在多媒体流 送已经开始(步骤880中）之后发生，如在步骤882中进一步描述的。在一些实现中，在该方法 中的该阶段发送的宣告可经由UDP上的单播来发送。在该宣告阶段期间，源800可W在W抑-TRIGGER-MET册D = PLAY命令下操作，在此期间源800可W准备好向连接着的阱810(在此是 阱810A、810B和810C)播放多媒体内容。
[0123] 在步骤877,任何附加阱810(在此是阱810B)可W向源800发送RTSP OK消息，W指 示它们已经接收到步骤876的宣告。
[0124] 在步骤878,一个或多个连接着的阱810可W经由RTSP呈现ML向源800发送播放请 求(例如，RTSP PLAY请求）。该播放请求可W根据群会话ID来发送。
[0125] 在步骤879，响应于步骤879的播放请求，源800可例如经由"播放响应or消息来通 知请求方阱810播放将开始。
[0126] 在步骤880,源800可W在群会话上向请求方阱810流送多媒体内容。在该时间期 间，源800可指示"正在播放"状态。
[0127] 在步骤881，请求方阱810可W从源800接收流送多媒体内容。
[0128] 如W上参照步骤873描述的，在步骤882,源800可继续传送宣告W招揽新阱加入该 群会话。该宣告可W按预定时间间隔被周期性地重复。在一些实现中，在该方法中的该阶段 发送的宣告可经由多播呈现TOL来发送。在宣告阶段期间，源800可W在WFD-TRIGGER-MET册D=WA 口命令下操作，此后接收方阱设备可W准备好在任何时间接收内容。
[0129] 图9(如由图9A和作为一个接续附图的图9B解说的）解说了 Wi-Fi显示源设备与多 个Wi-Fi显示阱设备之间的W源设备为中屯、的、基于RTSP的群会话建立和能力协商方法的 另一示例实现。在所解说的示例中，所有阱设备都被假定为在同一群中。如与图6和7的排他 地基于TCP的方法相比并且如与图8的排他地基于UDP的方法相比，该方法利用基于TCP的 RTSP消息接发和基于UDP的RTSPU消息接发方案两者的混合。如W下进一步描述的（参照步 骤973、975和979)，源维护到有限数目个"主动"阱设备的基于TCP的RTSP连接。源还确立用 于向有资格加入该群的任何其它"被动"阱设备通告群会话的基于UDP的RTSP消息接发方 案。
[0130] 在步骤961中，Wi-Fi显示源900发起与至少一个Wi-Fi显示阱910(在该示例中与阱 910A)的发现阶段。在该发现阶段期间交换的发现信息可包括群会话管理和设备能力信息， 如W上参照图5描述的。发现阶段可W在所选信道(例如，信道1、6或11)上发生，运基于该信 道上的话务量。此外，发现信息可W经由探测请求帖和探测响应帖在源900与阱910之间被 交换。
[0131 ]在步骤962，一个或多个阱910还可与源900交换服务发现信息。
[0132] 在步骤963,源900可W向用户950指示步骤961和962已经发生并通知用户950哪一 个或数个阱910已经在发现阶段期间被发现(在该示例中阱910A已被选择）。
[0133] 在步骤964,源900可完成与在发现阶段期间选择的一个或数个阱910的连接设立。 在某些情形中，连接设立可W是Wi-Fi对等链路。
[0134] 在步骤965,源900可W在其自身与与在发现阶段期间选择的一个或数个阱910之 间交换能力信息。运一能力信息可包括多媒体编解码器、多媒体格式、最少等待时间或缓冲 器能力或所支持的多播机制（例如DMS或GCR)等。源900可使用RTSP OPTIONS和GET_ PARAMETER命令连同群会话管理信息来交换并设置能力信息。
[0135] 在步骤966,源900可发起与附加阱（在该示例中与阱910B)的接续发现阶段。在该 发现阶段期间交换的发现信息可包括群会话管理和设备能力信息。
[0136] 在步骤967, 一个或多个连接着的阱910(在此是910A和910B)也可交换来自源900 的服务发现信息。
[0137] 在步骤968,源900可W向用户950指示步骤965-967已经发生并通知用户950存在 且满足能力要求的数个阱910(在此是阱910A和910B)已经在该发现阶段被选择。
[0138] 在步骤969,源900可W再次在其自身与在继续发现阶段期间选择的附加阱910(在 此是910B)之间交换能力信息。运一能力信息可包括多媒体编解码器、多媒体格式、最少等 待时间或缓冲器能力或所支持的多播机制（例如DMS或GCR)等。源900可使用RTSP OPTIONS 和GET_PARAMETER命令连同群会话管理信息来交换并设置能力信息。
[0139] 在步骤970和971，源900可发起与附加阱（在该示例中与阱910C和阱910D)的第二 接续发现阶段。在该发现阶段期间交换的发现信息可包括群会话管理和设备能力信息。该 接续发现阶段期间的信息交换可W-次与一个阱进行，例如源900可W与阱910C交换发现 信息(如在步骤970中）并且然后与阱910D交换发现信息(如在步骤971中）。
[0140] 在步骤972,源900可W准备好建立群会话。在其群会话建立中，源900可基于在上 述各步骤中所选择的一个或数个阱之间交换的能力信息来确定用于群会话的最优参数。源 900也可在此时生成群会话ID。此外，源900可经由基于UDP的多播端口来通告其群会话IDW 使得"被动"阱设备(在此是阱910C和910D)可加入该群。主动和被动阱的数目可被预定或基 于源900的计算。在一个实施例中，主动阱设备的数目将低于被阱设备的数目，因为主动阱 设备所要求的源900计算资源更多。如上所述，源900可维护到有限数目的主动阱设备(在此 是阱910A和910B)的基于TCP的RTSP连接，W使得源900可维持对有限数目的主动阱设备的 可靠 RTSP控制。
[0141 ]在步骤973和975，源900可进入单播宣告阶段，在该单播宣告阶段期间它可W向主 动阱910之一（在此是阱910A和910B)发送RTSP群会话信息的宣告。源900可使用RTSP A順OUNCE命令来向主动阱发送该宣告。该宣告可包括关于多播呈现URL、编解码器参数、群 IP地址、RTP端口号W及用于群会话中的个体的主动阱的会话ID的信息，等等。在一些实现 中，源900可W-次向一个主动阱发送宣告。例如，如在步骤973中，源900可W向主动阱910A 发送宣告，在该时间期间源900可W在W抑-TRIGGER-MET册D=WA 口命令下操作，在此期间它 将等待播放多媒体内容。此后，如在步骤975中，源900可W向主动阱910B发送宣告，在该时 间期间源900可W在WFD-TRIGGER-MET册D = PLAY命令下操作，在此期间源900可准备好向主 动阱910播放多媒体内容。宣告还可遵循如W上参照图8步骤869描述的响应超时和重试计 数参数。
[0142] 在步骤974和976,已经分别接收到步骤973或975的宣告的主动阱910(在此分别是 阱910A和910B)可W向源900发送RTSP OK消息W指示它们已经分别接收到步骤973和975的 宣告。
[0143] 在步骤977, 一个或多个主动阱910可W经由RTSP呈现TOL向源900发送播放请求 (例如，RTSP PLAY请求）。该播放请求可W根据群会话ID来发送。
[0144] 在步骤978,响应于步骤977的播放请求，源900可例如经由"播放响应or消息来通 知请求方主动阱910播放将开始。
[0145] 如W上参照步骤972、973和975描述的，在步骤979,源900可继续传送基于UDP的 RTSPU多播宣告W招揽新被动阱加入该群会话。在该宣告阶段期间，源900可W在WFD-TRIGGER-MET册D = READY(就绪)命令下操作，在此期间源900可W准备好向任何可能加入该 群的被动阱910(在此是阱910C和910C)播放多媒体内容。在一个实现中，源900可能不请求 或接收来自任何被动阱的ACK响应。例如，源900可能不跟踪被动阱设备。源900可改为只在 基于UDP的宣告内发送多媒体编解码器参数和其它重要群会话流送变化，无论被动阱是否 索求该信息。在一个实现中，发生在基于UDP的RTSPU多播宣告内的能力交换和会话通告可 由层2通过使用Wi-Fi显示动作帖或服务发现规程来执行。如果被动阱设备支持Wi-Fi显示 服务发现(WFDS)协议，则它们可使用应用服务平台（ASP)会话来在已经建立对等发现和连 接后从源900获取群会话能力。
[0146] 在步骤980,源900可开始通过群会话向任何连接着的主动和被动阱910(在此是阱 91OA、91OB、91OC和91OD)流送多媒体内容。在该时间期间，源900可指示"正在播放"状态。
[0147] 在步骤981，连接着的主动和被动阱910可W从源900接收流送多媒体内容。
[014引图10(例如，如由图IOA和作为一个接续附图的图IOB解说的）解说了 Wi-Fi显示源 设备、Wi-Fi显示主控阱设备W及数个从属阱设备之间的W阱为中屯、的、基于RTSP的群会话 管理方法的示例实现。与其中源发起了与个体阱或阱群的群会话的图6-9相反，在该方法 中，一个"主控"阱发起与源的群会话并且然后邀请其它"从属"阱到该群会话。
[0149] 在步骤1061 ,Wi-Fi显示主控阱1010发起与Wi-Fi显示源1000的发现阶段。在该发 现阶段期间交换的发现信息可包括群会话管理信息和设备能力信息，如W上参照图5描述 的。发现阶段可W在所选信道(例如，信道1、6或11)上发生，运基于该信道上的话务量。此 夕h发现信息可W经由探测请求和探测响应帖在源1000与主控阱1010之间被交换。
[0150] 在步骤1062,主控阱1010还可与源1000交换服务发现信息。
[0151] 在步骤1063,源1000可W向用户1050指示步骤1061和1062已经发生并通知用户 1050主控阱1010已经连接。
[0152] 在步骤1064,源1000和主控阱1010可W完成连接设立。在某些情形中，连接设立可 W是Wi-Fi对等链路。
[0153] 在步骤1065,源1000和主控阱1010可使用基于TCP的RTSP信息交换来交换能力信 息。运一能力信息可包括多媒体编解码器、多媒体格式、最少等待时间或缓冲器能力、或所 支持的多播机制（例如DMS或GCR)等。源1000可使用将RTSP OPTIONS和GET_PARAMET邸命令 连同群会话管理信息来交换并设置能力信息。在一个实现中，源1000可通知主控阱1010它 旨在服务作为阱为中屯、"的群的阱设备群。在该情形中，也在能力交换阶段期间，主控阱 1010可响应并承担主控阱(或"控制阱"）的角色。
[0154] 在步骤1066,源1000可W向主控阱1010发送单播RTSP宣告或参数请求。源1000可 使用RTSP ANNOUNCE命令来发送宣告，或者使用SET_PARAMETER命令来发送参数请求。该宣 告可包括关于多播呈现URL、编解码器参数、群IP地址、RTP端口号、W及用于主控阱的会话 ID的信息，等等。在该时间期间，源1000可W在W抑-TRIGG邸-MET册D = WA口命令下操作，在 此期间它将等待播放多媒体内容。在一些实现中，当要求在群会话中支持大量阱设备时，源 1000可使用帅P上的RTSPU方案（IETF RFC 2326)来管理群会话流送控制，例如使用 A順OUNCE方法。
[01巧]在步骤1067,源1000和主控阱1010可W在主控阱1010向源1000发送对群设立的请 求时暂时停止通信(例如，暂停），并且然后继续行至步骤1068。
[0156] 在步骤1068和1069,主控阱1010可发起与从属阱1020(在该示例中，与从属阱 1020A和从属阱1020B)的接续发现阶段。在该发现阶段期间交换的发现信息可包括群会话 管理信息和设备能力信息。主控阱1010可经由对等或服务发现来向从属阱1020发送群邀请 消息。群邀请消息可包括用于当前Wi-Fi显示群会话中的多媒体流送的多媒体格式。群邀请 消息还可包括阱设备可W从源1000接收的RTP/UDP分组的IP地址和端口号。该接续发现阶 段期间的信息交换可W-次与一个阱进行，例如，主控阱1010可W与从属阱1020A交换发现 信息（如在步骤1068中）并且然后与从属阱1020B交换发现信息（如步骤1069中）。在该时间 期间，主控阱1010还可建立到从属阱群的禪合和/或收集关于从属阱的信息。在一些实现 中，当需要在群会话中支持大量阱设备时，主控阱1010可使用UDP上的RTSPU方案(IETF RFC 2326)来管理群会话流送控制，例如使用ANNOUNCE方法。
[0157] 在步骤1070和1071，主控阱1010可W向从属阱1020(在此是从属阱1020A和1020B) 发送RTSP宣告。该宣告可包括请从属阱1020加入群会话或加入请求/响应过程的邀请。该宣 告可W-次被发送到一个从属阱，例如主控阱1010可W向从属阱1020A发送宣告(如在步骤 1070中）并且然后向从属阱1020B发送宣告(如在步骤1071中）。
[0158] 在步骤1072,源1000可W向用户1050指示步骤1064-1071已经发生并允许用户 1050为群会话做出设备选择。
[0159] 在步骤1073,主控阱1010可经由RTSP呈现URL来向源700发送RTSP设立请求。RTSP 设立请求可包括群会话成员资格信息，例如从属阱的数目和标识。
[0160] 在步骤1074,源1000可W向主控阱1010发送RTSP OK消息W指示它已经接收并批 准步骤1073的请求。
[0161] 在步骤1075,源1000可W准备好建立群会话。在其对群会话的建立中，源1000可确 定用于该群会话的最优参数。源1000也可在此时生成群会话ID。此外，源1000可经由基于 UDP的多播端口来通告其群会话IDW使得被动阱设备(在此是从属阱1020A和1020B)可加入 该群。该过程参照图9进一步描述。
[0162] 在步骤1076,源1000可进入单播宣告阶段，在该阶段期间它可W向主控阱1010发 送RTSP群会话信息的宣告。源1000可使用RTSP ANNOUNCE命令来向主控阱1010发送该宣告。 在该时间期间，源1000可W在W抑-TRIGGER-MET册D = PLAY命令下操作，在此期间源1000可 W准备好向主控阱1010播放多媒体内容。在一些实现中，当需要在群会话中支持大量阱设 备时，源1000可使用UDP上的RTSPU方案（IETF RFC 2326)来管理群会话流送控制，例如使用 A順OUNCE方法。
[0163] 在步骤1077,主控阱1010可W向源1000发送RTSP OK消息，W指示它已经接收到步 骤1076的宣告。
[0164] 在步骤1078,主控阱1010可W经由RTSP呈现TOL向源1000发送播放请求（例如， RTSP PLAY请求）。该播放请求可W根据群会话ID来发送。
[0165] 在步骤1079,响应于步骤1078的播放请求，源1000可例如经由"播放响应or消息 来通知主控阱1010播放将开始。
[0166] 在步骤1080,源1000可继续传送基于UDP的RTSPU多播宣告（如在步骤1075中描述 的）W招揽新被动阱（例如，从属阱1020A和1020B)加入该群会话。在该时间期间，源1000可 ^在胖。0-1316661?-161'册0 = ?1^\￥命令下操作，在此期间源1000可^准备好向可加入该群的 任何被动阱1010(在此是阱1020A和1020B)播放多媒体内容。该宣告可包括关于多播呈现 URU编解码器参数、群IP地址、RTP端口号、W及对于群会话中的所有阱而言共同的会话ID 的信息，等等。该宣告还可遵循如参照图8描述的响应超时和重试计数参数。在一些实现中， 当需要在群会话中支持大量阱设备时，源1000可使用UDP上的RTSPU方案（IETF RFC 2326) 来管理群会话流送控制，例如使用ANNOUNCE方法。
[0167] 在步骤1080的宣告后，任何其它阱设备可W在该时间后向主控阱1010发送要加入 该群的请求。如果请求方阱设备满足所要求的参数(如由群会话所确定的），则主控阱1010 可W向请求方阱设备发送肯定响应并向请求方阱设备发送加入该群的邀请。如果请求方阱 设备接受该邀请，则它可W向源1000发送阱信息。源1000然后可更新群会话参数信息并且 开始向基于UDP的多播端口流送多媒体内容。源1000还可W开始向任何其它MC层流送多媒 体内容W用于对用户群进行数据递送。在一些实现中，源10000可W在MAC层要求多播数据 递送来用于多播话务(例如，802. IlDMS或GCR规程)时宣告其要成为群主的意图。
[0168] 在步骤1081和1082,已经接收到步骤1080的宣告的从属阱1020(在此分别是阱 IOlOA和1010B)可W向源1000发送RTSP OK消息W指示它们已经接收到该宣告。RTSP OK消 息可W-次从一个从属阱接收，例如从属阱1020A可W向源1000发送RTSP OK消息（如在步 骤1081中）并且然后从属阱1020B可W向源1000发送RTSP OK消息(如在步骤1082中）。
[0169] 在步骤1083,源1000可开始通过群会话向主控阱IOlOW及任何连接着的从属阱 1010(在此是从属阱1020A和1020B)流送多媒体内容。在该时间期间，源1000可指示"正在播 放"状态。
[0170] 在步骤1084,连接着的阱可W从源1000接收流送多媒体内容。主控阱1010可管理 流送控制特征(例如，播放、暂停、或其它用户输入）。为了使得能由用户1050进行运一控制， 主控阱1010可在其TCP连接上具有用户输入返回信道化IBC)能力。
[0171] 图11(例如，如图IlA和作为一个接附图的图IlB解说的）解说了用于Wi-Fi显示群 会话管理信息的示例子元素内容布局。子元素可被包括在Wi-Fi显示信息元素内，W用于源 或阱通告关于设备发现(例如，发现数个阱设备）的群会话信息(诸如参照图4-10讨论的群 会话)的目的。子元素可包括设备应在设备发现期间交换的最少量的信息。
[0172] 参与该过程的设备可包括如参照图4-10描述的对等Wi-Fi显示群服务设备，例如 具备群会话能力的源、具备群会话能力的主控阱W及其它阱设备。运些设备中的一者或多 者可包括所解说的子元素，该子元素可指示群会话的能力、群会话类型、群会话管理端口信 息、W及MAC层对用于递送多播分组的群寻址帖的支持（如果有）等，如W下参照行1140、 1160和1180更完整地描述的。在源一次具有不止一个群会话的情形中，该源针对每一群可 包括一个多群会话管理信息子元素。
[0173] 在一个实现中，源或阱设备可支持来自Wi-Fi直连服务标准的服务发现规程，并且 子元素信息可被包括为用于服务发现的显示能力参数(例如，被包括在用于显示寻找服务 的se;rvice_info;rmation_request中）。图11中的表解说了该实现的示例。
[0174] 示例子元素可包括数个字段。字段列1100列出了示例字段。一些字段可具有所建 议的八位位组大小，该些大小在大小列中列出。在字段具有所建议的值的情形中，该值在值 列1104中列出。描述列1106提供了每一字段的简要概述，运将在下文中更详细地讨论。
[0175] 如在行1110中解说的，子元素可包括具有1八位位组大小和预定值的"子元素 ID" 字段。子元素 ID字段可标识Wi-Fi显示子元素的相应类型。
[0176] 如在行1120中解说的，子元素还可包括具有2八位位组大小和值6的"长度"字段。 该长度字段可指示该子元素中的任何后续字段的长度。
[0177] 如在行1130中解说的，子元素还可包括具有4个八位位组大小的"WH)群会话标识 符"字段。WFD群会话标识符字段可包括由源设备(例如，参照图4 10描述的源)在对群Wi-Fi 显示会话的RTSP会话建立期间指派的唯一性群会话标识符。在群会话尚未开始的情形中， WFD群会话标识符字段可具有全零值。
[017引如在行1140中解说的，子元素还可包括具有1个八位位组大小的"WH)群会话类型" 字段。WFD群会话类型字段可包括指定群会话类型的位图。在一些情形中，群会话可W是W 源为中屯、的类型，如参照图4-9描述的。在其它情形中，群会话可W是W主控阱为中屯、的类 型，如参照图10描述的。群会话也可W是其它类型。群会话类型可W在位图中的前四位中指 示。该位图还可指示管理群会话的RTSP协议端口的类型，例如TCP端口、UDP端口、或混合(所 有类型都如参照图4-10描述的）"RTSP协议端口类型可W在位图中的后四位中指示。
[0179] 如在行1150中解说的，该子元素还可包括具有2个八位位组大小的"群会话管理控 制端口信息"字段。群会话管理控制端口信息字段可包括Wi-Fi显示设备可藉W监听群会话 的RTSP消息的TCP或UDP端口。群会话管理控制端口消息的值可W是任何有效UDP或TCP端口 值。
[0180] 如在行1160中解说的，子元素还可包括具有7个八位位组大小的"所支持的群多播 方法"字段。所支持的群多播方法字段可包括指示MAC层对群寻址式帖递送的支持的位图。 可设置的支持系统的示例包括仅DMS、具有块ACK的GCR(群码记录）、具有非索求重试的GCR 等。该位图还可指示将不实现群寻址式递送支持。群定址式帖递送支持可W在该位图中的 前8位中指示。在位图设置具有块ACK的GCR或具有非索求重试的GCR的情形中，所支持的群 多播方法字段的接下来6个字节可包括GCR群地址。在位图设置除了具有块ACK的GCR或具有 非索求重试的GCR之外的其他支持系统的情形中，GCR群地址信息子字段可被留为保留。
[0181] 如在行1170中解说的，该子元素还可包括"强制群参数"字段。该强制群参数字段 可包括设及对共同多媒体格式的最少所要求支持、等待时间或缓冲器能力信息、和/或源向 一个或多个阱流送多媒体内容所必需的其它参数的信息。在一些情形中，强制群参数字段 的值可W是可任选的。在一个实现中，源可能要求对在强制群参数字段中指示的最少等待 时间、缓冲器能力、和/或用于在不转码的情况下进行流送的共同多媒体内容格式的支持。 在源不索求个体阱能力的情形中（例如，如在参照图8描述的方法的一个实现中）或者在阱 设备不支持内容的原生格式的情形中，则源或阱可将内容重新编码和/或转码成强制多媒 体格式和参数(例如，1280x72化，24fps分辨率）W用于在群会话期间流送。
[0182] 如在行1180中解说的，子元素还可包括具有7个八位位组大小的"WH)群成员信息 描述符"字段，该字段表示所有群成员的总和(例如，群成员个数）dWFD群成员信息描述符字 段可W在其首个八位位组中指示每一成员设备的类型和状态。成员设备的类型和状态的示 例可包括如参照图4-10描述的主控阱、常规阱、具备多播能力、仅单播等类型。WFD群成员信 息描述符字段还可包括每一设备的MAC地址或任何其它唯一性标识符。MAC地址或唯一性标 识符可位于WFD群成员信息描述符字段的末6个八位位组中。在WFD群成员信息描述符字段 持有单个条目（例如，7个字节)的情形中，MAC地址字段可包含全零，且第一八位位组可只指 示该群中的活跃设备或成员的数目。在一个实现中，源和/或主控阱可基于关于最后加入该 群的成员设备的信息来更新WFD群成员信息描述符字段。
[0183] 在一些实现中，子元素还可包括附加字段(未描绘）。附加字段的示例可包括设及 关于设备类别（例如，具备群会话能力的源、具备群服务能力的主控阱等)或每一设备的优 选模式(例如，对等GO、软AP、对于角色没有偏好等)的信息的字段。
[0184] 图12解说了用于为群会话递送多媒体内容的数据面找的示例。在一个实施例中， 数据面找的一个实例可能是对所要支持的每一群会话执行内容处理所必需的。使用W下方 法，向数据面找（即，通过使用RTSP流送控制协议)通知用于处置向阱设备群(例如，如参照 图4-10描述的阱设备)进行的帖递送的系统MAC层能力是有实现可能的。图12中的数据面找 解说包括若干会话群及其内容，诸如群A内容1200AW及群K内容1200K。每一群可包括全都 能够接收相同的所要求多媒体格式和/或满足最大等待时间要求的阱。数据面找还利用不 为一个群所特有的资源和控制信令，诸如共同RTSP控制1205W及TCP/UDP信息1210。该一个 或多个数据面找还可跨系统和所有群使用共同组件，诸如IP套接字1215W及Wi-Fi对等/ TLDS和Wi-Fi受保护设立处置单元1220。专用于每一阱群的数据面可包括个体组件或资源， 诸如视频编解码器1230、音频编解码器1235、分组化元系统(PES)信息1240、HDCP 2.0/2.1 信息1245、1?662-了5信息1250、1^?信息1255^及抓?信息1260。数据面找可将帖调度至其各 自的群地址如1225。
[0185] 对于阱群(例如，如W上在图12中显示的群）内的媒体内容递送，来自802. Ilaa的 定向多播服务(DMS)或带重试的群播(GCR)规程可被用于确保MAC层可靠性和稳健的多媒体 流送。DMS或GCR递送方法的确切重传规程可取决于群中的源和阱的能力、群中的设备数目、 信道状况、带宽要求等。给定运些参数的不同状况，可使用多媒体递送方法的若干选项。源 可基于W下示例来宣告群会话递送方法是仅DMS、仅非索求GCR、具有块ACK的GCR、DMS和GCR 两者、非GCR等。
[0186] 一种用于多媒体递送的示例方法可包括源通过一个MPEG2-TS和RTP/UDP流来进行 传送W用于与阱设备进行初始设立。随后，源可使用多播IP分组并使用DMS来转换成单播 MC帖。该方法提供了多个单播MC传输的可靠性。
[0187] 另一种用于多媒体递送的示例方法包括具有非索求重试的GCR。在该方法中，源可 W将数据帖传送至GCR地址，该GCR地址可在Wi-Fi显示信息元素（如参照图11描述的）和 RTSP消息中通告。源还可重传个体数据帖W确保它们被阱设备接收到。在源重传帖的情形 中，源可W向阱设备通告其重传策略。
[0188] 另一种用于多媒体递送的示例方法包括具有块ACK的GCR。在该方法中，数据帖可 经由多播发送到GCR地址。此外，源可W在MAC帖块的末尾发送块ACK请求帖。阱设备群然后 可W在超时时段内返回块ACK。
[0189] 在W上用于多媒体递送方法的示例方法中没有一种方法被支持(例如，由于源或 阱设备的有限能力）的情形中，群流送可使用非GCR多播方法。该非GCR多播方法可W不包括 ACK请求或重试。在该方法中，源和/或大量阱设备可能不支持任何群寻址式帖递送。源可W 作为对等GO或软AP来操作，并且可W在从UDP找接收到多播IP分组后使用常规多播来传送 数据帖。内容比特流可由数据面找的一个实例（例如，编解码器、PES、HDCP、MPEG2-TS/RTP/ UDP等）生成，并且MAC层可W在如在递送话务指示消息(DTIM)中指示的特定时刻传送运些 帖。该方法可结果导致多播帖的低数据率W及高分组丢失。结果，RTSP保活超时可被设置W 确保阱被连接着并且任何其它反馈机制(例如，RTSP)也可被使用。
[0190] 上面描述的方法的各种操作可由能够执行运些操作的任何合适的装置来执行，诸 如各种硬件和/或软件组件、电路、和/或模块。一般而言，在附图中所解说的任何操作可由 能够执行运些操作的相对应的功能性装置来执行。例如，用于响应于控制电压而选择性地 允许电流的装置可包括第一晶体管。另外，包括用于选择性地提供开路的装置的用于限制 控制电压量的装置可包括第二晶体管。
[0191] 信息和信号可使用各种各样的不同技艺和技术中的任一种来表示。例如，贯穿上 面描述始终可能被述及的数据、指令、命令、信息、信号、位(比特）、码元、和码片可由电压、 电流、电磁波、磁场或磁粒子、光场或光粒子、或其任何组合来表示。
[0192] 结合本文中所公开的实施例来描述的各种解说性逻辑框、模块、电路、和算法步骤 可实现为电子硬件、计算机软件、或运两者的组合。为清楚地解说硬件与软件的运一可互换 性，各种解说性组件、块、模块、电路、W及步骤在上面是W其功能性的形式作一般化描述 的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。 可针对每种特定应用W不同方式来实现所描述的功能性，但此类实现决策不可被解读为致 使脱离本发明的实施例的范围。
[0193] 结合本文所公开的实施例描述的各种解说性块、模块、和电路可用通用处理器、数 字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程口阵列(FPGA)或其他可编程逻辑器 件、分立口或晶体管逻辑、分立硬件组件、或其设计成执行本文所描述的功能的任何组合来 实现或执行。通用处理器可W是微处理器，但在替换方案中，该处理器可W是任何常规的处 理器、控制器、微控制器、或状态机。处理器还可W被实现为计算设备的组合，例如DSP与微 处理器的组合、多个微处理器、与DSP核屯、协同的一个或多个微处理器、或任何其它此类配 置。
[0194] 结合本文所公开的实施例描述的方法或算法和功能的各个步骤可直接用硬件、由 处理器执行的软件模块或两者的组合来实现。如果用软件实现，则运些功能可作为一条或 多条指令或代码存储在有形的非瞬态计算机可读介质上或藉其进行传送。软件模块可驻留 在随机存取存储器(RAM)、闪存、只读存储器(ROM)、电可编程ROM化PROM)、电可擦式可编程 ROM化EPROM)、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介 质中。存储介质被禪合到处理器W使得该处理器能从/向该存储介质读和写信息。在替换方 案中，存储介质可W被整合到处理器。如本文中所使用的盘(disk)和碟(disc)包括压缩碟 (CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘常常磁性地再现数据而碟用 激光光学地再现数据。上述的组合也可被包括在计算机可读介质的范围内。处理器和存储 介质可驻留在ASIC中。ASIC可驻留在用户终端中。替换地，处理器和存储介质可作为分立组 件驻留在用户终端中。
[0195] 出于概述本公开的目的，本发明的某些方面、优点和新颖特征已在本文中描述。应 当理解，未必根据本发明的任何特定实施例都可实现所有运些优点。因此，本发明可W按实 现或优化本文所教导的一个或一组优点而不一定实现如可能在本文中教导或提出的其他 优点的方式来实现或实施。
[0196] 对上述实施例的各种修改将是显而易见的，并且本文中定义的一般原理可被应用 于其他实施例而不会脱离本发明的精神或范围。因此，本发明不是旨在限于本文所示的各 实施例，而是应被授予与本文所公开的原理和新颖特征相一致的最宽范围。
【主权项】
1. 一种配置成向多个阱设备传送多媒体内容的装置，包括处理器，所述处理器被配置 成： 通过Wi-Fi对等连接来连接到所述多个讲设备中的每一者； 从请求特定多媒体内容的每一 Wi-Fi对等连接的阱设备接收能力信息； 生成包括群会话ID和传输端口号的控制消息，所述传输端口号将用于向每一Wi-Fi对 等连接的阱设备传达与所述群相关联的所述特定多媒体内容； 向每一 Wi-Fi对等连接的阱设备传送所述控制消息； 确定用于与所述群会话ID相关联的所述Wi-Fi对等连接的阱设备的流送参数集；以及 使用所述传输端口号并根据所述流送参数集来向每一 Wi-Fi对等连接的阱设备传送所 述特定多媒体内容。2. 如权利要求1所述的装置，其特征在于，所述流送参数集包括编解码器信息、显示器 分辨率、视频格式、以及音频格式中的至少一者。3. 如权利要求1所述的装置，其特征在于，所述控制消息还包括多播配置、单播配置、以 及包括用于内容流送的群MAC地址的可靠群播配置中的至少一者。4. 如权利要求1所述的装置，其特征在于，所述特定多媒体内容的传输通过使用稳健多 播帧递送技术来进行。5. 如权利要求4所述的装置，其特征在于，所述稳健多播帧递送技术基于802.1 laa标准 的确收和重试规程。6. 如权利要求1所述的装置，其特征在于，所述处理器被进一步配置成： 通过到所述多个阱设备中的数个阱设备的所述Wi-Fi对等连接来建立并维护所述群会 话；以及 确立控制消息接发方案，所述控制消息接发方案用于向未连接的阱设备广播所述群会 话ID、端口信息、以及流送参数集以允许这些未连接的阱设备与所述群会话ID进行关联。7. 如权利要求1所述的装置，其特征在于，所述处理器被进一步配置成按预定时间间隔 来周期性地广播所述群会话ID、端口信息、以及所述流送参数集。8. 如权利要求1所述的装置，其特征在于，所述处理器被进一步配置成在传送所述控制 消息或后续控制消息之前等待接收来自每一 Wi-Fi对等连接的阱设备的能力信息达预定时 间量。9. 如权利要求1所述的装置，其特征在于，所述处理器被进一步配置成： 绕过从每一Wi-Fi对等连接的阱设备接收能力信息；以及 以用于内容流送的预定群会话参数集来立即生成所述控制消息。10. 如权利要求1所述的装置，其特征在于，所述处理器被进一步配置成基于在所述装 置处发起的请求、在所述阱设备处发起的请求、以及所述阱设备的不足能力中的至少一者 来添加所述Wi-Fi对等连接的阱设备中的一者或多者或将其从相关联的群会话ID中移除。11. 如权利要求10所述的装置，其特征在于，所述阱设备的不足能力至少包括它无法支 持会话类型或无法支持将用于内容流送的流送参数中的至少一者。12. 如权利要求1所述的装置，其特征在于，所述处理器被进一步配置成建立与多个设 备群的Wi-Fi对等连接，其中所述特定多媒体内容、所述群会话ID、会话类型、端口信息、以 及所述流送参数集中的至少一者对于所述设备群中的每一设备群是不同的。13. 如权利要求1所述的装置，其特征在于，建立所述Wi-Fi对等连接包括Wi-Fi显示设 备发现信息的交换，其中所述Wi-Fi显示设备发现信息至少包括所述装置的群会话能力、群 会话管理控制端口数据集、群会话类型、以及将用于内容流送的流送参数集的指示。14. 如权利要求13所述的装置，其特征在于，所述Wi-Fi显示设备发现信息至少有一子 集是通过在预先建立的Wi-Fi对等连接上的所述Wi-Fi直连服务标准的应用服务平台来进 一步交换的。15. -种向多个阱设备传送多媒体内容的方法，包括： 通过Wi-Fi对等连接来连接到所述多个讲设备中的每一者； 从请求特定多媒体内容的每一 Wi-Fi对等连接的阱设备接收能力信息； 生成包括群会话ID和传输端口号的控制消息，所述传输端口号将被用于向每一Wi-Fi 对等连接的阱设备传达与所述群相关联的特定多媒体内容； 向每一 Wi-Fi对等连接的阱设备传送所述控制消息； 确定用于与所述群会话ID相关联的所述Wi-Fi对等连接的阱设备的流送参数集；以及 使用所述传输端口号并根据所述流送参数集来向每一 Wi-Fi对等连接的阱设备传送所 述特定多媒体内容。16. 如权利要求15所述的方法，其特征在于，进一步包括： 通过到所述多个阱设备中的数个阱设备的所述Wi-Fi对等连接来建立并维护所述群会 话；以及 确立控制消息接发方案，所述控制消息接发方案用于向未连接的阱设备广播所述群会 话ID、端口信息、以及流送参数集以允许这些未连接的阱设备与所述群会话ID进行关联。17. 如权利要求15所述的方法，其特征在于，进一步包括基于在所述装置处发起的请 求、在所述阱设备处发起的请求、以及所述阱设备的不足能力中的至少一者来添加所述WiFi 对等连接的阱设备中的一者或多者或将其从相关联的群会话 ID 中移除 ，其中所述阱设备 的不足能力至少包括它无法支持会话类型或无法支持将用于内容流送的流送参数中的至 少一者。18. 如权利要求15所述的方法，其特征在于，进一步包括建立与多个设备群的Wi-Fi对 等连接，其中所述特定多媒体内容、所述群会话ID、会话类型、端口信息、以及所述流送参数 集中的至少一者对于所述设备群中的每一设备群是不同的。19. 如权利要求15所述的方法，其特征在于，建立所述Wi-Fi对等连接包括Wi-Fi显示设 备发现信息的交换，其中所述Wi-Fi显示设备发现信息至少包括所述装置的群会话能力、群 会话管理控制端口数据集、群会话类型、以及将用于内容流送的流送参数集的指示。20. 如权利要求19所述的方法，其特征在于，所述Wi-Fi显示设备发现信息至少有一子 集是通过在预先建立的Wi-Fi对等连接上的所述Wi-Fi直连服务标准的应用服务平台来进 一步交换的。21. -种用于向多个阱设备传送多媒体内容的装备，包括： 用于通过Wi-Fi对等连接来连接到所述多个阱设备中的每一者的装置； 用于从请求特定多媒体内容的每一 Wi-Fi对等连接的阱设备接收能力信息的装置； 用于生成包括群会话ID和传输端口号的控制消息的装置，所述传输端口号将用于向每 一 Wi-Fi对等连接的阱设备传达与所述群相关联的特定多媒体内容； 用于向每一 Wi-Fi对等连接的阱设备传送所述控制消息的装置； 用于确定用于与所述群会话ID相关联的所述Wi-Fi对等连接的阱设备的流送参数集的 装置；以及 用于使用所述传输端口号并根据所述流送参数集来向每一Wi-Fi对等连接的阱设备传 送所述特定多媒体内容的装置。22. 如权利要求21所述的装备，其特征在于，进一步包括： 用于通过到所述多个阱设备中的数个阱设备的所述Wi-Fi对等连接来建立并维护所述 群会话的装置；以及 用于确立控制消息接发方案的装置，所述控制消息接发方案用于向未连接的阱设备广 播所述群会话ID、端口信息、以及流送参数集以允许这些未连接阱设备与所述群会话ID进 行关联。23. 如权利要求21所述的装备，其特征在于，进一步包括用于基于在所述装备处发起的 请求、在所述阱设备处发起的请求、以及所述阱设备的不足能力中的至少一者来添加所述 Wi-Fi对等连接的阱设备中的一者或多者或将其从相关联的群会话ID中移除的装置，其中 所述阱设备的不足能力至少包括它无法支持会话类型或无法支持将用于内容流送的流送 参数中的至少一者。24. 如权利要求21所述的装备，其特征在于，进一步包括用于建立与多个设备群的WiFi 对等连接的装置，其中所述特定多媒体内容、所述群会话 ID、会话类型、端口信息、以及所 述流送参数集中的至少一者对于所述设备群中的每一设备群是不同的。25. 如权利要求21所述的装备，其特征在于，建立所述Wi-Fi对等连接包括Wi-Fi显示设 备发现信息的交换，其中所述Wi-Fi显示设备发现信息至少包括所述装备的群会话能力、群 会话管理控制端口数据集、群会话类型、以及将用于内容流送的流送参数集的指示。26. 如权利要求25所述的装备，其特征在于，所述Wi-Fi显示设备发现信息至少有一子 集是通过在预先建立的Wi-Fi对等连接上的所述Wi-Fi直连服务的应用服务平台来进一步 交换的。27. -种包括代码的非瞬态计算机可读介质，所述代码在被执行时使一装置向多个阱 设备传送多媒体内容，以及： 通过Wi-Fi对等连接来连接到所述多个讲设备中的每一者； 从请求特定多媒体内容的每一 Wi-Fi对等连接的阱设备接收能力信息； 生成包括群会话ID和传输端口号的控制消息，所述传输端口号将用于向每一Wi-Fi对 等连接的阱设备传达与所述群相关联的特定多媒体内容； 向每一 Wi-Fi对等连接的阱设备传送所述控制消息； 确定用于与所述群会话ID相关联的所述Wi-Fi对等连接的阱设备的流送参数集；以及 使用所述传输端口号并根据所述流送参数集来向每一 Wi-Fi对等连接的阱设备传送所 述特定多媒体内容。28. 如权利要求27所述的介质，其特征在于，进一步包括在被执行时使一装置执行以下 操作的代码:基于在所述装置处发起的请求、在所述阱设备处发起的请求、以及所述阱设备 的不足能力中的至少一者来添加所述Wi-Fi对等连接的阱设备中的一者或多者或将其从相 关联的群会话ID中移除，其中所述阱设备的不足能力至少包括它无法支持会话类型或无法 支持将用于内容流送的流送参数中的至少一者。29. 如权利要求27所述的介质，其特征在于，建立所述Wi-Fi对等连接包括Wi-Fi显示设 备发现信息的交换，其中所述Wi-Fi显示设备发现信息至少包括所述装置的群会话能力、群 会话管理控制端口数据集、群会话类型、以及将用于内容流送的流送参数集的指示。30. 如权利要求29所述的介质，其特征在于，所述Wi-Fi显示设备发现信息至少有一子 集是通过在预先建立的Wi-Fi对等连接上的所述Wi-Fi直连服务的应用服务平台来进一步 交换的。
【文档编号】H04L29/06GK105830522SQ201480068061
【公开日】2016年8月3日
【申请日】2014年11月13日
【发明人】P·L·卡福里, F·肖卡特, V·N·萨布莱曼尼亚姆
【申请人】高通股份有限公司