在无线显示系统中进行多播的制作方法

在无线显示系统中进行多播的制作方法
【专利摘要】本公开内容涉及用于在无线显示（WD）系统中，在源设备与多个宿设备之间建立多播通信会话的技术。两个或更多个宿设备可能对从源设备接收相同的媒体数据感兴趣。根据该技术，在WD系统中，该源设备与宿设备建立多播会话，并且使用接收多播端口向感兴趣的宿设备发送针对多播会话的多播媒体上数据的单个拷贝。该源设备选择接收多播端口号作为针对每个多播会话的目的地标识符。对接收给定的多播会话的媒体数据感兴趣的宿设备在针对该多播会话的接收多播端口上进行绑定。本公开内容描述了用于确保在每个宿设备处的接收多播端口上正确地进行绑定的若干示例性多播订制过程。
【专利说明】在无线显示系统中进行多播
[0001]本申请要求享受2011年9月14日提交的美国临时申请N0.61/534，742和2011年10月14日提交的美国临时申请N0.61/547，240的权益，故以引用的方式将上述每个临时申请的全部内容整体并入本文。
【技术领域】
[0002]本公开内容涉及在无线源设备和无线宿设备之间发送数据。
【背景技术】
[0003]无线显示系统(WD)系统包括源设备以及一个或多个宿设备。源设备和宿设备中的每个宿设备可以是移动设备或具有无线通信能力的有线设备。作为移动设备，例如，源设备和重点设备中的一个或多个可以包括移动电话、具有无线通信卡的便携计算机、个人数字助理(PDA)、便携媒体播放器、或具有无线通信能力的其它闪存设备，包括所谓的“智能”电话和“智能”平板或平板电脑，或其它类型的无线通信设备。作为有线设备，例如，源设备和宿设备中的一个或多个可以包括包含无线通信能力的电视、桌面型计算机、监控器、投影仪
坐寸ο
[0004]源设备向参与特定通信会话的宿设备中的一个或多个宿设备发送诸如音频和/或视频数据之类的媒体数据。可以在源设备的本地显示器和在所述宿设备的显示器的每一个上播放该媒体数据。更具体地，每个参与的宿设备将所接收的媒体数据呈现在其显示和音频设备上。在一些情况下，宿设备的用户可以向宿设备应用用户输入，诸如触摸输入和远程控制输入。在WD系统中，用户输入是从宿设备发送到源设备的。源设备对从宿设备接收的用户输入进行处理，并将用户输入的影响应用在向宿设备发送的后续媒体数据上。

【发明内容】

[0005]概括而言，本公开内容涉及用于在无线显示(WD)系统中，在源设备和多个宿设备之间建立多播通信会话的技术。在一些环境下，两个或更多个宿设备可能对从源设备接收相同的媒体数据(例如，音频和/或视频(A/V)数据)感兴趣。传统地，源设备与宿设备中的每个宿设备建立单播会话，并在针对特定宿设备的接收端口上向感兴趣的宿设备中的每个宿设备发送相同媒体数据的单独拷贝。根据本公开内容的技术，在WD系统中，源设备与宿设备建立多播会话，并使用多播地址和接收多播端口向感兴趣的宿设备发送针对该多播会话的多播媒体数据的单个拷贝。
[0006]更具体地，为了在WD系统中提供多播，源设备选择多播因特网协议(IP)地址和接收多播端口号作为针对每个多播会话的目的地标识符。对接收给定的多播会话的媒体数据感兴趣的宿设备在与该多播会话相关联的多播IP地址和接收多播端口上进行绑定。源设备向WD系统中的所有宿设备广播多播组的媒体数据。在与该多播会话相关联的多播IP地址和接收多播端口上绑定的感兴趣的宿设备将接收并处理该媒体数据。本公开内容描述了若干示例性的多播订制过程，以确保在多播地址和每个宿设备处的接收多播端口上正确地进行绑定。
[0007]在一个示例中，一种方法包括:在W)系统中，在源设备与两个或更多个宿设备之间建立一个或多个多播通信会话，其中包括通告针对所述多播会话的多播媒体数据的可用性以及从所述宿设备接收要加入所述多播会话的请求；利用所述源设备，针对所述多播会话中的每个多播会话选择接收多播端口号；以及使用所选择的接收多播端口号，向所述宿设备发送针对所述多播会话中的每个多播会话的多播媒体数据的单个拷贝。
[0008]在另一不例中，一种方法包括:在WD系统中，利用宿设备与源设备建立一个或多个多播通信会话，其中包括:从所述源设备接收针对所述多播会话的多播媒体数据的通告，以及向所述源设备发送要加入所述多播会话中的一个或多个多播会话的请求；利用所述宿设备，在针对所述多播会话中所述宿设备感兴趣加入的一个多播会话而选择的接收多播端口号上进行绑定；以及利用所述宿设备，在所述宿设备绑定到的所选择的接收多播端口号上接收针对所述多播会话中的所述一个多播会话的所述多播媒体数据的拷贝。
[0009]在另外的示例中，一种源设备包括:存储器，用于存储媒体数据；以及处理器，其被配置成:在WD系统中，在源设备与两个或更多个宿设备之间建立一个或多个多播通信会话，包括通告针对所述多播会话的多播媒体数据的可用性和从所述宿设备接收要加入所述多播会话的请求；针对所述多播会话中的每个多播会话选择接收多播端口号；以及使用所选择的接收多播端口号，向所述宿设备发送针对所述多播会话中的每个多播会话的所述多播媒体数据的单个拷贝。
[0010]在另一示例中，一种宿设备包括:存储器，其存储媒体数据；以及处理器，其配置为:在WD系统中，与源设备建立一个或多个多播通信会话，其中包括:从所述源设备接收针对所述多播会话的多播媒体数据的通告，以及向所述源设备发送要加入所述多播会话中的一个或多个多播会话的请求；在针对所述多播会话中所述宿设备感兴趣加入的一个多播会话而选择的接收多播端口号上进行绑定；以及在所述宿设备绑定到的所选择的接收多播端口号上接收针对所述多播会话中的所述一个多播会话的所述多播媒体数据的拷贝。
[0011 ] 在另外的示例中，一种源设备包括:用于在WD系统中，在源设备与两个或更多个宿设备之间建立一个或多个多播通信会话的模块，其中所述建立包括通告针对所述多播会话的多播媒体数据的可用性以及从所述宿设备接收要加入所述多播会话的请求；用于针对所述多播会话中的每个多播会话选择接收多播端口号的模块；以及用于使用所选择的接收多播端口号，向所述宿设备发送针对所述多播会话中的每个多播会话的多播媒体数据的单个拷贝的模块。
[0012]在另一不例中，一种宿设备包括:用于在WD系统中，与源设备建立一个或多个多播通信会话的模块，其中所述建立包括:从所述源设备接收针对所述多播会话的多播媒体数据的通告，以及向所述源设备发送要加入所述多播会话中的一个或多个多播会话的请求；用于在针对所述多播会话中所述宿设备感兴趣加入的一个多播会话而选择的接收多播端口号上进行绑定的模块；以及用于在所述宿设备绑定到的所选择的接收多播端口号上接收针对所述多播会话中的所述一个多播会话的所述多播媒体数据的拷贝的模块。
[0013]在另外的示例中，一种计算机可读介质包括:当在源设备中执行时，使可编程处理器执行以下操作的指令:在WD系统中，在所述源设备与两个或更多个宿设备之间建立一个或多个多播通信会话，其中包括通告针对所述多播会话的多播媒体数据的可用性以及从所述宿设备接收要加入所述多播会话的请求；利用所述源设备，针对所述多播会话中的每个多播会话选择接收多播端口号；以及使用所选择的接收多播端口号，向所述宿设备发送针对所述多播会话中的每个多播会话的多播媒体数据的单个拷贝。
[0014]在另外的示例中，一种计算机可读介质包括:当在源设备中执行时，使可编程处理器执行以下操作的指令:在WD系统中，利用所述宿设备与源设备建立一个或多个多播通信会话，其中包括:从所述源设备接收针对所述多播会话的多播媒体数据的通告，以及向所述源设备发送要加入所述多播会话中的一个或多个多播会话的请求；利用所述宿设备，在针对所述多播会话中所述宿设备感兴趣加入的一个多播会话而选择的接收多播端口号上进行绑定；以及利用所述宿设备，在所述宿设备绑定到的所选择的接收多播端口号上接收针对所述多播会话中的所述一个多播会话的所述多播媒体数据的拷贝。
[0015]在附图和下面的描述中给出了本公开内容的一个或多个示例的细节。根据描述和附图以及根据权利要求书，其它的特征、目的以及优点将显而易见。
【专利附图】

【附图说明】
[0016]图1A是示出包括源设备和多个宿设备的无线显示(WD)系统的示例的框图，该源设备和多个宿设备能够支持多播通信会话。
[0017]图1B是更详细地示出来自IA中的源设备和一个宿设备的示例的框图。
[0018]图2是示出可以实现本公开内容的技术的源设备的示例的框图。
[0019]图3是示出可以实现本公开内容的技术的宿设备的示例的框图。
[0020]图4是不出可以实现本公开内容的技术的发射机系统和接收机系统的框图。
[0021]图5是示出用于使用静态多播订制过程,在源设备和两个宿设备之间建立多播通信会话的示例性消息传送序列的示意图。
[0022]图6是示出用于使用利用盲端口修改的动态多播订制过程,在源设备和两个宿设备之间建立多播通信会话的示例性消息传送序列的示意图。
[0023]图7是示出用于使用利用通知的端口修改的动态多播订制过程，在源设备和两个宿设备之间建立多播通信会话的示例性消息传送序列的示意图。
[0024]图8是示出用于将源设备和一个宿设备之间的单播通信会话转换成该源设备和两个宿设备之间的多播通信会话的示例性消息传送序列的示意图。
[0025]图9是示出在WD系统中由源设备和宿设备进行的静态多播订制过程的示例性操作的流程图。
[0026]图10是示出在WD系统中由源设备和宿设备进行的动态多播订制过程的示例性操作的流程图。
【具体实施方式】
[0027]图1A是包括源设备120和多个宿设备160、170和180的无线显示(WD)系统100的示例的框图，源设备120和多个宿设备160、170和180能够支持多播通信会话。在WD系统100中，源设备100向参与通信会话的宿设备160、170和180中的每一个发送诸如音频和/或视频数据(A/V数据)之类的媒体数据。该媒体数据可以在源设备120的本地显示器和参与的宿设备160、170和180中的每一个宿设备的本地显示器上进行播放。[0028]在一些情况下，宿设备160、170和180可能对从源设备120接收相同的媒体数据感兴趣。传统地，源设备120与宿设备160、170和180中的每一个建立单播会话。在单播会话的情况下，宿设备160、170和180中的每一个识别在该宿设备处的可用的接收端口，其中，源设备120可以向该可用的接收端口发送针对该单播会话的媒体数据。然后，源设备120向所识别的、感兴趣的宿设备160、170和180的接收端口发送相同媒体数据的单独的拷贝。
[0029]然而，当宿设备160、170和180对接收相同的媒体数据感兴趣时，更有效率的是发送可以由所有感兴趣的宿设备160、170和180接收的媒体数据的单个拷贝。本公开内容的技术使得能够在WD系统100中进行多播。根据该技术，源设备120与宿设备160、170和180中的两个或更多个宿设备建立多播通信会话，并向在所有感兴趣的宿设备160、170和/或180处可用的单个接收多播端口发送针对该多播会话的媒体数据的单个拷贝。
[0030]在图1A中示出的示例性WD系统100中，源设备120和宿设备160、170和180可以形成W1-Fi点对点(P2P)组，其中，源设备120作为组拥有者。以此方式，源设备120和宿设备160、170和180全部使用相同的服务集标识符(SSID)来识别该W1-Fi组。为了进行多播，源设备120使用公知的、预定义的广播介质访问控制(MAC)地址作为接收地址来发出多播媒体数据。WD系统100中的所有宿设备160、170和180能够在MAC层接收该多播媒体数据，因为它们属于与源设备120相同的W1-Fi组。
[0031]为了向WD系统100中所有感兴趣的宿设备仅发送针对给定多播会话的多播媒体数据的单个拷贝，源设备120选择多播因特网协议(IP)地址和接收多播端口号作为针对该多播会话的目的地标识符。然后，对参与该给定多播会话感兴趣的宿设备160、170和/或180在与该多播会话相关联的多播IP地址和接收多播端口上进行绑定。源设备120使用广播MAC地址向WD系统100中的所有宿设备160、170和180广播针对该多播会话的媒体数据。在与该多播会话相关联的多播IP地址和接收多播端口上绑定的感兴趣的宿设备160、170和/或180将接收该媒体数据，并将所接收的媒体数据传递至高层以进行处理。本公开内容描述了若干示例性多播订制过程，以确保在宿设备160、170和180中的每一个处，在多播地址和接收多播端口上正确地绑定。
[0032]源设备120和宿设备160、170和180中的每一个可以是移动设备或具有无线通信能力的有线设备。作为移动设备，例如，源设备120和宿设备160、170和180中的一个或多个可以包括移动电话、具有无线通信卡的便携式计算机、个人数字助理(PDA)、便携式媒体播放器、或具有无线通信能力的其它闪存设备，包括所谓的“智能”电话以及“智能”平板或平板电脑、或其它类型的无线通信设备。作为有线设备，例如，源设备120和宿设备160、170和180中的一个或多个可以包括包含无线通信能力的电视、台式计算机、监控器、投影仪等。在一些情况下，源设备120和宿设备160、170和180中的每一个可以包括设备的系统，这些设备包括例如显示器、扬声器、用户接口(UI)设备以及处理器，这些设备是都是独立的但可互操作的设备。
[0033]在本公开内容中，术语源设备通常用于指正在发送A/V数据的设备，术语宿设备通常用于指正在从源设备接收A/V数据的设备。在许多情况下，源设备120和宿设备160、170和180可以是类似的或相同的设备，其中，一个设备操作为源而其它设备操作为宿。此夕卜，在不同的通信会话中，这些角色可以反转。因而，一个通信会话中的宿设备可以在随后的通信会话中变成源设备，反之亦然。
[0034]图1B是更详细地示出来自图1A中的源设备120和其中一个宿设备160的示例的框图。如图1B中示出的，源设备120经由通信信道150与宿设备160进行通信。
[0035]源设备120可以包括:存储音频和/或视频(A/V)数据的存储器121、显示器122、扬声器123、音频和/或视频(A/V)编码器124 (也被称为编码器124)、音频和/或视频(A/V)控制模块125、以及发射机/接收机(TX/RX)单元126。宿设备160可以包括显示器162、扬声器163、音频和/或视频(A/V)解码器164 (也被称为解码器164)、发射机/接收机单元166、用户输入(UI)设备167、以及用户输入处理模块(UIPM) 168。所示出的组件仅构成针对WD系统中一个源设备和宿设备的一个示例性配置。其它的配置可以包括比所示出的组件更少的组件或可以包括与所示出的组件相比另外的组件。
[0036]在图1的示例中，源设备120可以在显示器122上显示A/V数据121的视频部分，并且可以在扬声器123上输出A/V数据121的音频部分。A/V数据121可以本地地存储在源设备120上，从诸如文件服务器、硬盘、外部存储器、蓝光光盘、DVD之类的外部存储介质或其它物理存储介质来访问，或者可以经由诸如因特网之类的网络连接流式传送到源设备120。在一些实例中，A/V数据121可以通过源设备120的照相机和麦克风实时捕获。A/V数据121可以包括诸如电影、电视节目或音乐之类的多媒体内容，但还可以包括由源设备120生成的实时内容。这种实时内容可以例如由在源设备120上运行的应用或所捕获的视频数据(例如作为视频电话会议的一部分)产生。在一些实例中，这种实时内容可以包括可供用户选择的用户输入选择的视频帧。在一些实例中，A/V数据121可以包括为不同类型的内容的组合的视频帧，诸如电影或电视节目的视频帧，其中，在该视频帧上覆盖有用户输入选项。
[0037]除了通过显示器122和扬声器123在本地呈现A/V数据121，源设备120的A/V编码器124可以对A/V数据121进行编码，并且发射机/接收机单元126可以在通信信道150上向宿设备160发送经编码的数据。宿设备160的发射机/接收机166接收该经编码的数据，并且A/V解码器164对该经编码的数据进行解码，并通过显示器162和扬声器163输出经解码的数据。以此方式，由显示器122和扬声器123呈现的音频和视频数据可以由显示器162和扬声器163同时呈现。可以将该音频数据和视频数据安排在帧中，并且在呈现时可以将音频帧与视频帧时间同步。
[0038]A/V编码器124和A/V解码器164可以实现任意数量的音频和视频压缩标准，诸如ITU-T H.264标准，或者称为MPEG-4、部分10、高级视频编码(AVC)、或新兴的高效率视频编码(HEVC)标准。也可以使用许多其它类型的专有或标准化的压缩技术。一般说来，A/V解码器164被配置成执行A/V编码器124的反向编码操作。虽然在图1中未示出，然而，在一些方面，A/V编码器124和A/V解码器164可以分别与音频编码器和解码器整合，并且可以包括适当的MUX-DEMUX单元、或其它的硬件和软件，以处理共同的数据流或单独的数据流中音频和视频的编码。
[0039]除了实现如上文所描述的视频压缩标准以外，A/V编码器124还可以执行其它编码功能。例如，在A/V数据121被发送至宿设备160之前，A/V编码器124可以将各种类型的元数据添加到A/V数据121。在一些实例中，A/V数据121可以以编码的形式被存储在源设备120上或在源设备120处被接收，从而无需由A/V编码器124进行进一步压缩。[0040]虽然图1示出了单独携带音频有效载荷数据和视频有效载荷数据的通信信道150，但应该理解的是，在一些实例中，音频有效载荷数据和视频有效载荷数据可以是共同数据流的一部分。如果适用的话，MUX-DEMUX单元可以遵循ITU H.223多路复用器协议，或诸如用户数据报协议(UDP)之类的其它协议。A/V编码器124和A/V解码器164均可以被实现为一个或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、分立逻辑、软件、硬件、固件或其任意组合。A/V编码器124和A/V解码器164中的每一个可以被包括在一个或多个编码器或解码器中，其中的任意一个可以被整合为组合的编码器/解码器(CODEC)的一部分。从而，源设备120和宿设备160中的每一个可以包括被配置成执行本公开内容的一个或多个技术的专用机器。
[0041]显示器122和显示器162可以包括诸如阴极射线管(CRT)、液晶显示器(IXD)、等离子显示器、发光二极管(LED)显示器、有机发光二极管(OLED)显示器、或其它类型的显示器设备之类的各种视频输出设备中的任意一个。在这些或其它的示例中，显示器122和162均可以是发射型显示器或透射型显示器。显示器122和显示器162也可以是触摸显示器，使得它们同时是输入设备和显示设备。这种触摸显示器可以是电容性、电阻性或允许用户向相应的设备提供用户输入的其它类型的触摸板。
[0042]扬声器123和扬声器163可以包括诸如耳机、单扬声器系统、多扬声器系统、或环绕立体声系统之类的各种音频输出设备中的任意一个。此外，虽然显不器122和扬声器123被不为源设备120的一部分,并且显不器162和扬声器163被不为宿设备160的一部分,但源设备120和宿设备160实际上可以是设备的系统。作为一个示例，显示器162可以是电视，扬声器163可以是环绕立体声系统，并且解码器164可以是有线或无线地连接到显示器162和扬声器163的外接盒的一部分。在其它实例中，宿设备160可以是单个设备，诸如平板式计算机或智能电话。在其它的情况下，源设备120和宿设备160是类似的设备，例如，两者都是智能电话、平板式计算机等。在这种情况下，一个设备可以操作为源，而另一个设备可以操作为宿。这些角色在后续的通信会话中甚至可以反转。在其它的情况中，源设备可以包括移动设备，诸如智能电话、膝上型或平板式电脑，并且宿设备可以包括更固定的设备(例如，具有AC电源线)，在该情况下，源设备可以传送音频和视频数据，以通过宿设备向一大群人展示。
[0043]发射机/接收机单元126和发射机/接收机单元166均可以包括各种混合器、滤波器、放大器和设计用于信号调制的其它组件，以及一个或多个天线和设计用于发送和接收数据的其它组件。通信信道150通常表示用于从源设备120向宿设备160发送视频数据的任意适当的通信介质、或不同通信介质的集合。通信信道150通常是相对短距离的通信信道，类似于W1-F1、蓝牙等。然而，通信信道150无需在此方面受限制，并且可以包括任意无线或有线通信介质(诸如射频(RF)频谱或一个或多个物理传输线)，或无线和有线介质的任意组合。在其它示例中，通信信道150甚至可以形成基于分组网络的一部分，诸如有线或无线局域网、广域网或诸如因特网之类的全球网。此外，通信信道150可以由源设备120和宿设备160使用，以创建点对点链路。
[0044]源设备120和宿设备160可以根据例如使用实时流协议(RTSP)控制消息的能力协商来建立通信会话。然后，源设备120和宿设备160可以使用诸如来自IEEE802.11标准族的标准之类的通信协议在通信信道150上通信。源设备120和宿设备160可以例如根据W1-Fi直连(WFD)标准进行通信，使得源设备120和宿设备160在不使用诸如无线接入点或所谓的热点之类的中介的情况下，彼此直接地进行通信。源设备120和宿设备160还可以建立隧道直接链路建立(TDLS)，以避免或减少网络拥塞。WFD和TDLS旨在建立相对短距离的通信会话。在该上下文中，相对短距离指的是例如小于大约70米，然而在嘈杂的或有阻碍的环境中，设备之间的距离甚至可能更短，诸如小于大约35米或小于大约20米。
[0045]本公开内容的技术有时会针对WFD进行描述，但是可以预期的是，这些技术的方面还可以与其它通信协议兼容。通过举例而非限制的方式，源设备120和宿设备之间的无线通信可以利用正交频分复用(OFDM)技术。也可以使用各种各样其它的无线通信技术，包括但不限于时分多址(TDMA)、频分多址(FDMA)、码分多址(CDMA)、或OFDM、FDMA, TDMA和/或⑶MA的任意组合。
[0046]除了对来自源设备120的数据进行解码和呈现之外，宿设备160还可以接收来自用户输入设备167的用户输入。用户输入设备167可以例如是键盘、鼠标、轨迹球或跟踪板、触摸屏、语音命令识别模块、或任意其它这种用户输入设备。UIPM168对由用户输入设备167接收的用户输入命令格式化成源设备120能够解释的数据分组结构。由发射机/接收机166通过通信信道150将这种数据分组发送到源设备120。发射机/接收机单元126接收该数据分组，并且A/V控制模块125解析该数据分组，以解释由用户输入设备167所接收的用户输入命令。基于在数据分组中接收的命令，A/V控制模块125可以改变被编码和发送的内容。以此方式，宿设备160的用户可以在不直接与源设备120进行交互的情况下，远程地控制由源设备120进行发送的音频有效载荷数据和视频有效载荷数据。
[0047]此外，宿设备160的用户能够启动和控制源设备120上的应用。例如，宿设备160的用户能够启动在源设备120上存储的照片编辑应用，并使用该应用来编辑本地存储在源设备120上的照片。宿设备160可以向用户提供看上去或感觉上好像是在宿设备160上本地地编辑照片的用户体验，而实际上是在源设备120上编辑照片。使用这种配置，设备用户能够利用一个设备的能力来与若干设备一起使用。例如，源设备120可以是具有大量内存和高端处理能力的智能电话。然而，当观看电影时，用户可能想要在具有更大显示屏的设备上观看该电影，在该情况下，宿设备160可以是平板计算机或甚至更大的显示设备或电视机。当想要发送或回复电子邮件时，该用户可能希望使用具有物理键盘的设备，在该情况下，宿设备160可以是膝上型计算机。在这两个示例中，即使该用户正与宿设备进行交互，但大多数处理可能仍然由源设备120执行。源设备和宿设备可以通过协商和或识别在任意给定的会话中的能力，来促进双向交互。
[0048]在一些配置中，A/V控制模块125可以是由源设备120的操作系统执行的操作系统过程。但是，在其它配置中，A/V控制模块125可以是在源设备120上运行的应用的软件过程。在这种配置中，可以由软件过程来解释用户输入命令，使得宿设备160的用户与在源设备120上正在运行的应用直接进行交互，而不是与在源设备120上运行的操作系统。通过与应用而不是操作系统直接交互，宿设备160的用户可以访问对于源设备120的操作系统而言不是本地的命令库。此外，直接与应用交互可以使得能够由在不同平台上运行的设备更容易地发送和处理命令。
[0049]可以通过通信信道150向源设备120发送回在宿设备160处应用的用户输入。在一个示例中，可以实现反向信道架构(还称为用户接口返回信道(UIBC))，以使得宿设备160能够向源设备120发送在宿设备160处应用的用户输入。反向信道架构可以包括用于传输用户输入的高层消息，以及用于在宿设备160和源设备120处协商用户接口能力的低层帧。WBC可以驻留在位于宿设备160和源设备120之间的因特网协议(IP)传输层上。以此方式，UIBC可以在开放系统互联(OSI)通信模型中的传输层之上。为了促进可靠传输以及按顺序传送包含用户输入数据的数据分组，UIBC可以配置成在诸如传输控制协议/因特网协议(TCP/IP)或用户数据报协议(UDP)之类的其它基于分组的通信协议的上部运行。在OSI层架构中，UDP和TCP可以并行操作。TCP/IP可以使得宿设备160和源设备120能够在分组丢失的情况下实现重传技术。
[0050]WBC可以被设计成传输各种类型的用户输入数据，包括跨平台用户输入数据。例如，源设备120可以运行iOS?操作系统，而宿设备160运行诸如Android?或Windows?之类的另一操作系统。不考虑平台，UIPM168可以以A/V控制模块125可理解的形式对所接收的用户输入进行封装。WBC可以支持多种不同类型的用户输入格式，以允许许多不同类型的源设备和宿设备利用该协议，而不考虑宿设备和源设备是否在不同的平台上操作。可以定义通用的输入格式，并且可以支持特定于平台的输入格式，从而以在其中WBC能够在源设备120和宿设备160之间传送用户输入的方式来提供灵活性。
[0051]本公开内容的技术使得在WD系统中源设备120能够与宿设备160和一个或多个另外的宿设备建立多播通信会话。常规地，当两个或更多个宿设备可能对接收相同的媒体数据感兴趣时，源设备与宿设备中的每个宿设备建立多播会话，并在针对特定宿设备的接收端口上，向感兴趣的宿设备中的每个宿设备发送相同媒体数据的单独的拷贝。然而，根据本公开内容的技术，在WD系统中，源设备120可以与宿设备160和一个或多个另外的宿设备建立多播会话，并使用多播地址和接收多播端口向感兴趣的宿设备发送多播媒体数据的单个拷贝。
[0052]更具体地，为了在WD系统中提供多播，源设备120针对在源设备120处可用的每个多播会话，选择多播IP地址和接收多播端口号作为目的地标识符。如果对接收给定的多播会话的媒体数据感兴趣，则宿设备160在与该多播会话相关联的多播IP地址和接收多播端口上进行绑定。源设备120向WD系统中的所有宿设备广播该多播会话的媒体数据。宿设备160以及在与该多播会话相关联的多播IP地址和接收多播端口上绑定的任意其它感兴趣的宿设备将接收和处理该媒体数据。在下文更详细地描述了确保在每个宿设备处在多播地址和接收多播端口上正确地进行绑定的若干示例性多播订制过程。
[0053]图2是示出可以实现本公开内容的技术的源设备220的一个示例的框图。源设备220可以是与图1A&1B类似的设备，并且其可以以与源设备120相同的方式操作。源设备220包括本地显示器222、扬声器223、处理器231、显示处理器235、音频处理器236、存储器232、传输单元233以及无线调制解调器。如图2中示出的，源设备220可以包括对A/V数据进行编码和/或解码以进行传输、存储和显示的一个或多个处理器(即，处理器231、显示处理器235以及音频处理器236)。例如，媒体或A/V数据可以被存储在存储器232中。存储器232可以存储整个A/V文件，或可以包括仅存储例如流式传送自另一设备或源的A/V文件的一部分的更小的缓冲器。
[0054]传输单元233可以处理经编码的A/V数据以进行网络传输。例如，经编码的A/V数据可以由处理器231处理，并由传输单元233封装到网络接入层(NAL)单元，以通过网络传送。NAL单元可以由无线调制解调器234通过网络连接向无线宿设备发送。例如，无线调制解调器234可以是配置成实现IEEE802.11标准家族中的一个的W1-Fi调制解调器。源设备220还可以本地地处理和显示A/V数据。具体地，显示处理器235可以处理视频处理，以在本地显示器222上显示，以及音频处理器236可以处理音频数据，以在扬声器223上输出。
[0055]如上文参考图1中的源设备120所描述的，源设备220可以从宿设备接收用户输入命令。例如，源设备220的无线调制解调器234可以从宿设备接收封装的用户输入数据分组，例如，NAL单元，并向传输单元233发送封装的数据单元，以进行解封装。传输单元233可以从NAL单元提取用户输入数据分组，处理器231可以解析数据分组以提取用户输入命令。基于用户输入命令，处理器231正由源设备220处理的A/V数据及的类型。在其它示例中，源设备220可以包括从传输单元233接收用户输入数据分组、对数据分析进行解析以提取用户输入命令的用户输入单元或驱动器(图2中未示出)，以及用于基于用户输入命令来修改正由源设备220处理的A/V数据的类型的直接处理器231。以此方式，上文参考图1中的A/V控制模块125描述的功能可以全部地或部分地由处理器231来实现。
[0056]图2中的处理器231通常代表各种处理器中的任意一种，包括但不限于，一个或多个数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程逻辑阵列(FPGA)、其它等同的集成或离散逻辑电路、或其某一组合。图2中的存储器232可以包括各种易失性或非易失性存储器中的任意一种，包括但不限于，诸如同步动态随机访问存储器(SDRAM)之类的随机存取存储器(RAM)、只读存储器(ROM)、非易失性随机访问存储器(NVRAM)、电可擦除可编程只读存储器(EEPR0M)、闪存等，存储器232可以包括用于存储音频/视频数据以及其它种类的数据的计算机可读存储介质。存储器232可以另外地存储由处理器231作为执行本公开内容中描述的各种技术的一部分来执行的指令和程序代码。
[0057]根据本公开内容的技术，源设备220可以在WD系统中与多个宿设备之间建立多播通信会话。然后，源设备220可以向对使用与多播通信会话相关联的多播地址和接收多播端口来接收相同媒体数据感兴趣的宿设备发送多播媒体数据的单个拷贝。源设备220针对源设备220可用的每个多播会话，选择多播IP地址和接收多播端口号作为目的地标识符。对接收给定多播会话的媒体数据感兴趣的宿设备在与多播会话相关联的多播IP地址和接收多播端口上进行绑定。然后，源设备220向WD系统中的所有宿设备广播该多播会话的媒体数据，并且在与该多播会话相关联的该多播IP地址和该接收多播端口上绑定的宿设备将接收和处理该媒体数据。
[0058]本公开内容描述了确保在每个宿设备处在多播地址和接收多播端口上正确地进行绑定的若干示例性多播订制过程。在图2的示例中，源设备220的处理器231可以被配置成执行多播订制过程中的任意一个。在其它示例中，源设备220的单独的处理器或功能模块(图2中未示出)可以被配置成执行本公开内容中所描述的多播订制过程。
[0059]在第一示例性多播订制过程中，源设备220可以使用公知的多播订制协议(例如，因特网群组管理协议(IGMP))，来建立多播会话。在WD系统中，源设备220与宿设备执行RTSP (实时流协议)协商，以确定用于传送该多播订制协议的端口号。例如，源设备220可以使用RTSPGET_PARAMETER交换，来获得每个宿设备处针对该多播订制协议通信信道的端口号信息。[0060]然后，源设备220使用多播订制协议来通告多播会话，并且宿设备中的一个或多个可以使用多播订制协议来请求加入多播会话。在该情况下，WFD规范具有针对特定的多播应用的固定的多播端口号。WFD规范对多播订制协议提供了固定的多播端口号，以通知参与该多播会话的宿设备该固定的多播端口号。
[0061]在被称为“静态的”多播订制过程的第二示例性多播订制过程中，源设备220使用WD通信会话建立的RTSP能力协商阶段来建立多播通信会话。在该情况下，源设备220在公知的、预定义的多播IP地址和端口上发送多播媒体数据。因此，所有的宿设备可以盲目地在多播IP地址和接收多播端口上绑定，以接收任何可能的多播数据。
[0062]本技术提供了一种订制过程来避免宿设备盲目地仅在接收多播端口上绑定以丢弃不想要的多播媒体数据。本技术允许源设备220首先通告针对媒体会话的媒体数据的可用性，并且允许宿设备当感兴趣时具体地请求该多播媒体数据。源设备220使用RTSP (例如，使用RTSP SET_PARAMETER请求)来向宿设备通告媒体数据的可用性。每个宿设备可以例如使用RTSP建立请求来请求多播媒体数据或单播媒体数据。在多播媒体数据的情况下，WFD规范提供了预定义的多播端口号。在单播媒体数据的情况下，每个进行请求的宿设备提供单播端口号。参考图5更详细地描述了静态的多播订制过程。
[0063]在被称为“动态的”多播订制过程的第三示例性多播订制过程中，源设备220使用WD通信会话建立的RTSP能力协议阶段来建立多播通信会话以及针对该多播会话选择多播端口号。与上文所描述的第一和第二示例性多播订制过程不同，该动态多播订制过程使得源设备220能够基于感兴趣的宿设备的可用的端口号，来针对多播会话选择多播端口号。
[0064]源设备220首先例如使用RTSP GET_PARAMETER请求来询问每个宿设备其对多播媒体数据的大体兴趣以及其可用的端口。每个宿设备响应指示其是否对接收多播媒体数据感兴趣，并且如果感兴趣，则提供可用的多播端口号。然后，源设备220针对每个特定的多播会话，选择在所有感兴趣的宿设备处都可用的多播端口号。源设备220例如使用RTSPSET_PARAMETER交换来向宿设备通告:针对每个多播会话多播媒体数据的可用性以及针对多播会话所选择的多播端口号。每个宿设备可以例如使用RTSP SETUP (建立)交换来请求特定多播会话的多播媒体数据或单播媒体数据。在多播媒体数据的情况下，每个进行请求的宿设备已经从初始通告知道了针对该多播会话所选择的多播端口号。在单播媒体数据的情况下，每个进行请求的宿设备向源设备220提供单播端口号。
[0065]如果在多播会话期间新的宿设备加入，则如果该新的宿设备不具有所选择的可用的端口，则所选择的多播端口可能需要修改。在一个示例中，可以使用盲端口修改来修改该端口号，在盲端口修改中，将在源设备220处针对所有多播会话可用的端口号修改为在所有宿设备处可用的，而不管新的宿设备感兴趣加入哪一个多播会话。一旦修改了该多播端口号，源设备220就将该新的端口号通知所有宿设备。此外，源设备220可以在预定义的时间段内向旧的端口号和新的端口号发送多播媒体数据。参考图6更详细地描述了利用盲端口修改的动态多播订制过程。
[0066]在另一个不例中，可以使用通知的端口修改来修改端口号，在通知的端口修改中，源设备220确定新的宿设备感兴趣加入哪一个多播会话，然后仅针对该多播会话修改端口号。在通知的端口修改的情况下，源设备220例如使用RTSP GET_PARAMETER请求来询问每个宿设备其对特定多播会话的兴趣，而不是上文所描述的执行通用询问。通知的端口修改过程可以提供对端口号的更有效的使用，这是因为针对每个多播会话的端口号仅需在输入该特定多播会话的那些宿设备处可用，而不是对通常对接收多播数据感兴趣的所有宿设备处而言。参考图7更详细地描述了利用通知的端口修改的动态多播订制过程。
[0067]在第二宿设备加入仅包括在进行单播会话的单个宿设备的WD系统的情况下，源设备220可以转换到与两个宿设备的多播会话。根据本技术，源设备220与第二个宿设备执行上文描述的多播订制过程中的一个。如果第二宿设备请求加入多播会话，则源设备220在继续向第一宿设备发送单播媒体数据的同时，向第二宿设备发送多播媒体数据。然后，源设备220与第一宿设备执行多播订制过程。一旦第一宿设备加入多播会话，源设备220中断单播会话。参考图8更详细地描述了用于将单播通信会话转换到多播会话的过程。
[0068]图3是示出可以实现本公开内容的技术的宿设备的示例的框图。宿设备360可以与图1A&1B中的宿设备160相类似。宿设备360包括处理器331、存储器332、传输单元333、无线调制解调器334、显示处理器335、本地显示器362、音频处理器336、扬声器363以及用户输入接口 376。宿设备360在无线调制解调器334处接收从源设备发送的封装的数据单元。无线调制解调器334例如可以是被配置成实现来自IEEE802.11标准家族中的一个或多个标准的W1-Fi调制解调器。传输单元333可以将封装的数据单元解封装。例如，传输单元333可以从封装的数据单元提取经编码的视频数据，并向处理器331发送经编码的A/V数据，以被解码及呈现以输出。显示处理器335可以处理解码的视频数据，以在本地显示器362上显示，以及音频处理器336可以处理解码的音频数据，以在扬声器363上输出。
[0069]除了呈现音频和视频数据之外，无线宿设备360还可以通过用户输入接口 376接收用户输入数据。用户输入接口 376可以代表多个用户输入设备中的任意一个，上述多个用户输入设备包括但不限于触摸显示接口、键盘、鼠标、语音命令模块、姿势捕获设备(例如，具有基于照相机的输入捕获能力)或多个用户输入设备中的任意其它的。通过用户输入金额可376接收的用户输入可以由处理器331处理。上述处理可以包括生成包括所接收的用户输入命令的数据分组。一旦生成，传输单元333就可以处理数据分组，以由网络通过WBC传输至源设备。
[0070]图3中的处理器331可以包括范围广泛的处理器中的一个或多个，例如一个或多个数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、其它等同的集成或离散逻辑电路或其某一组合。图3中的存储器332可以包括各种暂时性或非暂时性的存储器中的任意一个，包括但不限于诸如同步动态随机存取存储器(SDRAM)之类的随机存取存储器(RAM)、只读存储器(ROM)、非暂时性随机访问存储器(NVRAM)、电可擦除可编程只读存储器(EEPR0M)、闪存等，存储器232可以包括用于存储音频/视频数据以及其它种类数据的计算机可读存储介质。存储器332可以另外存储由处理器331作为执行本公开内容中描述的各种技术的一部分来执行的指令和程序代码。
[0071]根据本公开内容的技术，宿设备360可以加入与WD系统中的源设备和一个或多个其它宿设备直接的多播通信会话。然后，源设备可以向宿设备360和对使用针对该多播会话的多播地址和接收多播端口来接收相同的媒体数据感兴趣的任意其它的宿设备发送多播媒体数据的单个拷贝。源设备针对在源设备处可用的每个多播会话，选择多播IP地址和接收多播端口号作为目的地标识符。宿设备360知道针对每个多播会话的多播IP地址和接收多播端口号，这是因为上述地址和端口号是由WFD规范预定义的或由源设备通告的。如果对接收给多播会话的媒体数据感兴趣，则宿设备360在与该多播会话相关联的多播IP地址和接收多播端口上进行绑定。然后，源设备向宿设备360和WD系统中其它参与的宿设备广播多播会话的媒体数据，并且在与该多播会话相关联的多播IP地址和接收多播窗口上绑定的宿设备360接收并处理该媒体数据。
[0072]本公开内容描述了确保在每个宿设备处在多播地址和接收多播端口上正确地进行绑定的若干示例性多播订制过程。在图3的示例中，宿设备360的处理器331可以被配置成执行多播订制过程中的任意一个。在其它示例中，宿设备360的单独的处理器或功能模块(图3中未示出)可以被配置成执行本公开内容中描述的多播订制过程。
[0073]在第一示例性多播订制过程中，宿设备360可以使用公知的多播订制协议(例如，IGMP)，来加入多播会话。宿设备360参与与源设备之间的RTSP协商，以通知源设备在宿设备360处用来传输多播订制协议的端口号。例如，宿设备360可以针对该多播订制协议通信信道使用RTSPGET_PARAMETER交换来向源设备发送端口号信息。
[0074]然后，源设备使用多播订制协议通告针对多播会话的多播媒体数据，宿设备360使用多播订制协议来请求加入所通告的多播会话。在该情况下，WFD规范具有针对特定的多播应用的固定的多播端口号。WFD规范对多播订制协议提供固定的多播端口号，以向参与该多播会话的宿设备通知固定的多播端口号。
[0075]在被称为“静态的”多播订制过程的第二示例性多播订制过程中，宿设备360使用WD通信会话建立的RTSP能力协议阶段来加入多播会话。在该情况下，源设备在公知的、预定义的多播IP地址和端口上发送多播媒体数据。因此，宿设备360与任意其它宿设备一起可以盲目地在该多播IP地址和端口上绑定，以接收任何可能的多播数据。
[0076]本技术提供了一种订制过程来避免宿设备360盲目地仅在接收多播端口上绑定，以丢弃不想要的多播媒体数据。本技术允许源设备首先通告针对该多播会话的多播媒体数据的可用性，并且允许宿设备360在感兴趣时具体地请求该多播媒体数据。源设备使用RTSP (例如，使用RTSP SET_PARAMETER)，来向宿设备360通告媒体数据的可用性。作为响应，宿设备360可以例如使用RTSP SETUP请求来请求多播媒体数据或单播媒体数据。在多播媒体数据的情况下，WFD规范提供了预定义的多播端口号。在单播媒体数据的情况下，每个进行请求的宿设备向源设备提供单播端口号。参考图5更详细地描述了静态的多播订制过程。
[0077]在被称为“动态的”多播订制过程的第三示例性多播订制过程中，宿设备360使用WD通信会话建立中的RTSP能力协商阶段来加入多播会话，以及接收关于针对该多播会话的多播端口号的通知。不象上文所描述的第一和第二示例性多播订制过程，该动态的多播订制过程使得源设备能够基于宿设备360以及其它感兴趣的宿设备可用的端口号来针对多播会话选择多播端口号。
[0078]源设备220首先例如使用RTSP GET_PARAMETER请求来询问每个宿设备其对多播媒体数据的大体兴趣以及其可用的端口。宿设备360响应指示其是否对接收多播媒体数据感兴趣，并且如果感兴趣，则提供其可用的多播端口号。然后，源设备针对在源设备可用的每个特定的多播会话，选择在所有感兴趣的宿设备处都可用的多播端口号。源设备例如使用RTSP SET_PARAMETER交换来向宿设备360通告:针对每个多播会话多播的媒体数据的可用性以及针对多播会话所选择的多播端口号。然后，宿设备360可以例如使用RTSP SETUP交换来请求特定多播会话的多播媒体数据或单播媒体数据。在多播媒体数据的情况下，每个进行请求的宿设备已经从初始通告知道了针对该多播会话所选择的多播端口号。在单播媒体数据的情况下，每个进行请求的宿设备向源设备220提供单播端口号。参考图6&7更详细地描述了动态的多播订制过程。
[0079]图4是示出示例性发射机系统410和接收机系统450的框图，其可以由图1中的发射机/接收机126和发射机/接收机166使用，以在通信信道150上通信。在发射机系统410处，从数据源412向发射(TX)数据处理器414提供多个数据流的业务数据。每个数据流可以在相应的发射天线上发送。TX数据处理器414对每个数据流的业务数据基于对该数据流所选择的特定编码方案，进行格式化、编码和交织。可以使用正交频分复用(OFDM)技术将每个数据流的编码数据与导频数据复用。也可以使用各种其它的无线通信技术，包括但不限于时分多址(TDMA)、频分多址(FDMA)、码分多址(CDMA)以及OFDM、FDMA、TDMA和/或CDMA的任意组合。
[0080]与图4 一致，导频数据通常是已知的数据模式，其以已知的方式被处理，并可以在接收机系统450处使用以估计信道响应。然后，基于针对该数据流所选择的特定的调制方案(例如，二相相移键控(BPSK)、正交相移键控(QPSK)、M-PSK或M-QAM (正交幅度调制)，其中M是2的幂)对该数据流的经复用的导频和编码数据进行调制，以提供调制符号。利用由处理器430执行的指令，可以确定每个数据流的数据速率、编码和调制，其中处理器430可以与存储器432耦合。
[0081]然后，将数据流的调制符号提供到TX MMO处理器420，TX MMO处理器420可以进一步处理调制符号(例如，用于0FDM)。然后，TX MIMO处理器420可以向NT个发射机(TMTR)422A- 422T( “发射机422”)提供NT个调制符号流。在某些方面，TX MMO处理器420对数据流的符号以及从其处发送符号的天线应用波束成形权重。发射机422中的每一个可以接收及处理相应的符号流，以提供一个或多个模拟信号，并进一步调节(例如，放大、滤波以及上变频)模拟信号，以提供适合在MMO信道上传输的经调制的信号。然后，从Nt个天线424A - 424t (“天线424”)分别发送Nt个经调制的信号。
[0082]在接收机系统450处，由Nk个天线452A - 452R(“天线452”)接收所发送的经调制的信号，并且从天线452中的每一个向相应的接收机(RCVR) 454A-454R (“接收机454”)中的一个提供所接收的信号。接收机454中的每一个对所接收的相应的信号进行调节(例如，滤波、放大以及下变频)，数字化经调节的信号以提供采样，并进一步处理上述采样，以提供相应的“接收”符号流。然后，接收(RX)数据处理器基于特定的接收机处理技术，接收并处理乂个接收符号流，以提供Nt个“检测”符号流。然后，RX数据处理器460对每一检测符号流进行解调、解交织以及解码，以恢复数据流的业务数据。由数据处理器460执行的处理与由TX MIMO处理器420和TX数据处理器414在发射机系统410处执行的相反。
[0083]可以与存储器472耦合的处理器470定期地确定要使用哪一个预编码矩阵。反向链路消息可以包括关于通信链路和/或所接收的数据流的各种类型的信息。然后，反向链路消息由TX数据处理器438处理，由调制器480进行调制，由发射机454进行调节，并发送回发射机系统410，其中，TX数据处理器438还从数据源436接收多个数据流的业务数据。
[0084]在发射机系统410处，来自接收机系统450的经调制的信号由天线424接收、由接收机422调节、由解调器440解调、以及由RX数据处理器442处理，以提取由接收机系统450发送的反向链路消息。然后，处理器430确定要使用哪一个预编码矩阵来确定波束成形权重，并处理所提取的消息。
[0085]图5是示出用于使用静态多播订制过程，在源设备510和两个宿设备512、514之间建立多播通信会话的示例性消息传送序列的示意图。源设备510通常可以以与上文针对图1A&1B中的源设备120以及图2中的源设备220所描述的相同的方式操作。宿设备512和514通常可以以与上文针对图1A&1B中的宿设备160和图3中的宿设备360相同的方式操作。
[0086]在所示出的图5的示例中，源设备510已经建立了与宿设备512的多播会话，并且正在该会话上向宿设备512发送多播媒体数据。为了与宿设备514通信，源设备510和宿设备514执行P2P设备发现和配对522。在一些情况下，源设备510、宿设备512和宿设备514可以形成W1-Fi P2P组，其中源设备510作为组的拥有者。
[0087]在源设备510和宿设备514建立连接之后，源设备510和宿设备514可以为其通信会话确定一组参数和能力，作为使用RTSPGET_PARAMETER交换524的能力协商交换的一部分。基于交换524，源设备510可以确定要用于通信会话的最佳的一组参数，并向宿设备514发送RTSP SET_PARAMETER请求消息526。请求消息526可以包含要在源设备510和宿设备514之间的通信会话期间使用的参数组。
[0088]根据静态多播订制过程，源设备510向宿设备514通告针对多播会话的多播媒体数据和针对单播会话的单播媒体数据的可用性。例如，如在图5中所示出的，源设备510使用在 RTSP SET_PARAMETER请求消息 526 中的 multicast_presentation_url 参数，向宿设备514通告多播媒体数据的可用性。源设备510还使用在相同的请求消息526中的unicast_presentation_url参数，来通告单播媒体数据的可用性。multicast_presentation_url参数用于将多播内容以及其传输模式与unicast_presentation_url区分开。在接收到请求消息526之后，宿设备514利用RTSP SET_PARAMETER响应消息528进行响应，其中，RTSPSET_PARAMETER响应消息528包括指示如在请求消息526中所指定的来设置参数是否成功的RTSP状态码。
[0089]然后，宿设备514可以使用RTSP SETUP请求消息530来请求接收多播媒体数据或单播媒体数据。在图5的示例中，宿设备514通过向源设备510发送包括multiCast_presentation_url参数的请求消息530来请求加入多播会话。
[0090]在接收到请求消息530之后，源设备510利用包括RTSP状态码的RTSP SETUP响应消息532来进行响应，其中RTSP状态码指示将宿设备514添加到多播会话是否成功。在静态多播订制过程中，WFD规范向宿设备514提供预定义的多播端口号。在接收到响应消息532之后，宿设备514在预定义的多播端口上进行绑定，以接收所通告的多播媒体数据。然后，源设备510使用该预定义的多播端口号，通过会话向宿设备512和514发送针对多播会话的多播媒体数据的单个拷贝。在该情况下，不需要来自宿设备514的播放命令来发起来自源设备510的多播媒体数据。
[0091]在所示出的图5的示例中，源设备510还可以与宿设备516建立单播通信会话。为了与宿设备516通信，源设备510和宿设备516执行P2P设备发现和配对536。在源设备510和宿设备516建立连接之后，源设备510和宿设备516可以针对其通信会话来确定一组参数和能力，作为使用RTSPGET_PARAMETER交换538的能力协商交换的一部分。基于交换538，源设备510可以确定要用于该通信会话的最佳的一组参数，并向宿设备516发送RTSP SET_PARAMETER请求消息540。请求消息540可以包含要在源设备510和宿设备516之间的通信会话期间使用的参数组。
[0092]根据静态的多播订制过程，源设备510向宿设备516通告针对多播会话的多播媒体数据和针对单播会话的单播媒体数据的可用性。例如，如在图5中示出的，源设备510使用multicast_presentation_url参数来通告多播媒体数据的可用性，以及使用RTSP SET_PARAMETER请求消息540中的unicast_presentation_url参数来通告单播媒体数据的可用性。在接收到请求消息540之后，宿设备516利用包括RTSP状态码的RTSP SET_PARAMETER响应消息542进行响应，该RTSP状态码指示如在请求消息540所指定的对参数进行设置是否成功。
[0093]然后，宿设备516可以使用RTSP SETUP请求消息544来接收多播媒体数据或单播媒体数据。在图5的示例中，宿设备516通过向源设备510发送包含unicast_presentation_url参数的请求消息544来加入单播会话。在该情况下，宿设备516还使用请求消息544中的receiving_port_unicast参数来向源设备510提供在其上接收单播媒体数据的可用的接收单播端口号。
[0094]在接收到请求消息544之后，源设备510利用包含RTSP状态码的RTSP SETUP响应消息546来进行响应，其中，RTSP状态码指示建立与宿设备516的单播会话是否成功。为了接收单播媒体数据，宿设备516向源设备510发送RTSP播放命令。然后，源设备510使用先前所指示的针对该单播会话的接收单播端口号向宿设备516发送单播媒体数据。
[0095]图6是示出用于使用利用盲端口修改的动态多播订制过程在源设备与两个宿设备612、614之间建立多播通信会话的示例性消息传送序列的示意图。源设备610通常可以以与上文针对图1A&1B中的源设备120和图2中的源设备220所描述的相同的方式操作。宿设备612和614通常可以以与上文针对图1A&1B中的宿设备160和图3中的源设备360所描述的相同的方式操作。
[0096]在所示出的图6中的示例，为了与宿设备612建立通信会话，源设备610首先执行P2P设备发现和配对620以及宿设备612。在源设备610和宿设备612建立连接之后，源设备610可以确定宿设备612所支持的一组参数和能力以在其通信会话期间使用，作为使用RTSP GET_PARAMETER请求消息622的能力协商交换的一部分。根据动态多播订制过程，源设备610使用请求消息622询问宿设备612其对多播数据的大体兴趣及其可用的端口。例如，如在图6中所示出的,源设备610使用multicast_interested参数从宿设备612请求对接收多播媒体数据的兴趣的指示，以及使用请求消息622中的multicast_ports参数从宿设备612请求可用的端口。
[0097]宿设备612利用指示其大体上是否对接收多播数据感兴趣的RTSP GET_PARAMETER响应消息624来对请求消息622进行响应，并且如果其感兴趣，则提供可用的端口号。例如，如在图6中所示出的，宿设备612在响应消息624中使用被设置成等于“是”的multicast_interested参数来指示对接收多播媒体数据感兴趣，以及使用设置成等于端口“6000”的multicast_ports参数以及端口范围“6100-6200”来指示可用的多播端口。
[0098]基于消息622、624的RTSP GET_PARAMETER交换，源设备610可以确定要用于通信会话的最佳的一组参数，并执行与宿设备612的RTSPSET_PARAMETER交换626。交换626可以包含要在源设备610和宿设备612之间的通信会话期间使用的参数组。根据动态多播订制过程，由于宿设备612对接收多播媒体数据感兴趣，因此源设备610针对在源设备610可用的每个多播会话，选择在宿设备612处可用的接收多播端口号。在源设备610与超过一个宿设备通信的情况下，源设备610可以基于在对接收多播媒体数据感兴趣的所有宿设备处均可用的端口来针对该多播会话选择接收多播端口号。
[0099]然后，源设备610使用RTSP SET_PARAMETER交换626，向宿设备612通告针对每个多播会话的多播媒体数据的可用性以及针对该多播会话所选择的多播端口号。如图6中所示出的，源设备610在交换626中使用multicast_presentationl参数来通告针对第一多播会话的多播媒体数据的可用性，以及使用multicast_presentation2参数来通告针对第二多播会话的多播媒体数据的可用性。在所示出的示例中，multicast_presentationl参数通告在具有多播IP地址“ipl”和接收多播端口号“6120”的“urll”上多播媒体数据的可用性。此外,multicast_presentation2参数通告在具有多播IP地址“ip2”和接收多播端口号“6150”的“url2”上多播媒体数据的可用性。
[0100]然后，宿设备612可以使用RTSP SETUP交换628来请求接收针对第一多播会话的多播媒体数据。在图6的示例中，宿设备612通过与源设备610执行包含设置成等于urll的multicast_presentation_url参数的请求的交换628来加入第一多播会话。宿设备612在由源设备610所通告的针对第一多播会话所选择的多播IP地址(例如，ipl)和多播端口号(例如，6120)上进行绑定，以接收多播媒体数据。然后，源设备610使用所选择的多播IP地址和接收多播端口号，在该会话上，向宿设备612发送针对第一多播会话的多播媒体数据的单个拷贝。在该情况下，无需来自宿设备612的播放命令来发起来自源设备610的多播媒体数据的传输。
[0101]宿设备612还可以使用RTSP SETUP交换630来请求接收针对第二多播会话的多播媒体数据。在图6的示例中，宿设备612通过与源设备610执行包括设置成等于url2的multicast_presentation_url参数的交换630来加入第二多播会话。宿设备612在由源设备610所通告的针对第二多播会话所选择的多播IP地址(例如，ip2)和多播端口号(例如，6150)上进行绑定，以接收多播媒体数据。然后，源设备610使用所选择的多播IP地址和接收多播端口号，通过会话向宿设备612发送针对第二多播会话的多播媒体数据的单个拷贝。在该情况下，无需来自宿设备612的播放命令来发起来自源设备610的多播媒体数据的传输。
[0102]在所示出的图6的示例中，在与宿设备612建立多播通信会话之后，新的宿设备614可以加入WD系统。为了建立与宿设备614的通信会话，源设备610首先执行P2P设备发现和配对632以及宿设备614。例如，源设备610、宿设备612以及宿设备614可以形成W1-Fi P2P组，其中源身边610作为组拥有者。
[0103]在源设备610和宿设备614建立连接之后，源设备610可以确定宿设备614所支持的一组参数和能力以在他们的通信会话期间使用，作为使用RTSP GET_PARAMETER请求消息634的能力协商交换的一部分。根据该动态多播订制过程，源设备610使用请求消息634询问宿设备614其对多播数据的大体兴趣及其可用的端口。宿设备614利用指示其大体上是否对接收多播数据感兴趣的RTSP GET_PARAMETER响应消息636来对请求消息634进行响应，如果感兴趣，则提供可用的端口号。在图6的示例中，宿设备614在响应消息636中使用设置成等于“是”的multicast_interested参数来指示对接收多播媒体数据感兴趣，以及使用设置成端口 “6000”的multicast_ports参数以及端口范围“6150-6200”来指示
可用的多播端口。
[0104]根据动态多播订制过程，由于新的宿设备614也对接收多播媒体数据感兴趣，所以源设备610针对在源设备610处可用的每个多播会话选择在宿设备612和614处均可用的接收多播端口号。在一些情况下，源设备610基于新近加入的宿设备614的可用端口，可能需要修改针对该多播会话先前所选择的多播端口号。例如，在图6中，新的宿设备614不具有所选择的针对第一多播会话可用的接收多播端口号“6120”。因此，源设备610基于在对接收多播媒体数据感兴趣的宿设备612和614处均可用的端口，修改针对第一多播会话所选择的端口号。
[0105]在所示出的图6的示例中，源设备610使用盲端口修改来修改针对第一多播会话的接收多播端口号。在该情况下，源设备610修改了针对该第一多播会话所选择的端口号，以在对接收多播媒体数据感兴趣的所以宿设备处均可用，而不管新的宿设备614是否对加入第一多播会话感兴趣。
[0106]一旦修改了接收多播端口号，然后源设备610使用RTSPSET_PARAMETER交换638来向宿设备612通告针对该可用多播会话的多播媒体数据和所选择的多播端口号。如在图6中所示出的，源设备610在交换638中向宿设备612通告针对第一多播会话的修改后的接收多播端口号“6160”。在接收该通告之后，宿设备612需要修改其绑定在其上的端口号，以继续接收针对第一多播会话的多播媒体数据。在该示例中，宿设备612作为替代在源设备610所通告的针对第一多播会话的、修改后的多播端口号(例如，6160)上进行绑定，以接收多播媒体数据。在一些情况下，源设备610可以在预定义的时间段内，向旧的端口号(例如，6120)以及新的端口号(例如，6160)都发送针对第一多播会话的多播媒体数据。
[0107]源设备610还使用RTSP SET_PARAMETER交换640来向宿设备614通告针对多播会话的多播媒体数据和所选择的多播端口号。然后，宿设备614可以使用RTSP SETUP交换642来请求接收针对第二多播会话的多播媒体数据。在图6的示例中，宿设备614通过与源设备610执行包括设置成url2的multicast_presentation_url参数的交换642来加入第二多播会话。宿设备614在源设备610所通告的针对第二多播会话所选择的多播IP地址(例如，ip2)以及多播端口号(例如，6150)上进行绑定，以接收多播媒体数据。
[0108]然后，源设备610使用所选择的多播IP地址和接收多播端口号，通过会话向宿设备612和宿设备614两者发送针对第二多播会话的多播媒体数据的单个拷贝。在该情况下，无需来自宿设备612或宿设备614的播放命令来发起来自源设备610的多播媒体数据的传输。
[0109]图7是用于使用利用通知的端口修改的动态多播订制过程，在源设备710与两个宿设备712、714之间建立多播通信会话的示例性消息传送序列的示意图。源设备710通常可以以与上文针对1A&1B中的源设备120和图2中的源设备220所描述的相同的方式操作。宿设备712和714通常可以以与上文针对1A&1B中的宿设备160和图3中的宿设备360所描述的相同的方式操作。
[0110]在所示出的图7的示例中，为了建立与宿设备712的通信会话，源设备710首先执行P2P设备发现和配对720以及宿设备712。在源设备710和宿设备712建立连接之后，源设备710可以确定要用于识别在第一 RTSPSET_PARAMETER交换722中与宿设备712的可用的多播会话的参数。
[0111]根据动态的多播订制过程，源设备710使用交换722来向宿设备712通告针对第一多播会话和第二多播会话的多播媒体数据的可用性。例如，如在图7中所示出的，源设备710使用在交换722中被设置成等于“urll”的multicast_presentation_urll参数和被设置成等于“url2”的multicast_presentation_url2参数来向宿设备712通告多播媒体数据的可用性。
[0112]然后，源设备710可以确定宿设备712所支持的、用于在其会话期间使用的一组参数和能力，作为使用RTSP GET_PARAMETER请求消息724的能力协商交换的一部分。根据动态多播订制过程，源设备710使用请求消息724来询问宿设备712其对先前所通告的多播会话的多播数据的兴趣以及其可用的端口。例如，如图7中所示出的，源设备710使用请求消息724中的interested_multicast_url参数从宿设备712请求对接收针对特定多播会话的多播媒体数据的兴趣的指示，以及使用multicast_ports参数从宿设备712请求可用的端口。
[0113]宿设备712利用RTSP GET_PARAMETER响应消息726来响应请求消息724，其中，RTSP GET_PARAMETER响应消息726指示宿设备712对接收来自特定多播会话的多播数据感兴趣，并且如果感兴趣，则提供可用的端口号。例如，如在图7中所示出的，宿设备712在响应消息726中使用被设置成“urll”和“url2”的interested_multicast_url参数来指示对接收针对第一和第二多播会话的多播媒体数据感兴趣，以及使用被设置成等于端口 “6000”的multicast_ports参数和端口范围“6100-6200”来指示可用的多播端口。
[0114]基于消息724、726的RTSP GET_PARAMETER交换，源设备710可以确定要用于通信会话的最佳的一组参数，并与宿设备712执行第二 RTSPSET_PARAMETER交换728。交换728可以包含设置成要在源设备710和宿设备712之间的通信会话中使用的参数。根据动态多播订制过程，由于宿设备712对接收针对第一和第二多播会话的多播媒体数据感兴趣，所以源设备710选择在宿设备712处针对第一和第二多播会话都可用的接收多播端口号。在源设备710正在与超过一个的宿设备通信的情况下，源设备710可以基于在对接收针对特定多播会话的多播媒体数据感兴趣的所有宿设备处可用的端口，来针对多播会话中的每个多播会话选择接收多播端口号。
[0115]然后，源设备710使用RTSP SET_PARAMETER交换728来向宿设备728通告:针对宿设备712感兴趣的第一和第二多播会话的多播媒体数据的可用性以及针对上述多播会话选择的多播端口号。如图7中所示出的，源设备710在交换728中使用multicast_presentationl参数来通告针对第一多播会话的多播媒体数据的可用性以及使用multicast_presentation2参数来通告针对第二多播会话的多播媒体数据的可用性。在所示出的示例中，multicast_presentationl参数利用多播IP地址“ ipl ”和接收多播端口号“6120”来通告在“urll”上多播媒体数据的可用性。此外，multicast_presentation2参数利用多播IP地址“ip2”和接收多播端口号“6150”来通告在“url2”上多播媒体数据的可用性。
[0116]然后，宿设备712可以使用RTSP SETUP交换730来请求接收针对第一多播会话的多播媒体数据。在图7的示例中，宿设备712通过与源设备710执行包括设置成urll的multicast_presentation_url参数的交换730来请求加入第一多播会话。宿设备712在由源设备710所通告的针对第一多播会话所选择的多播IP地址(例如，ipl)和多播端口号(例如，6120)上进行绑定，以接收多播媒体数据。然后，源设备710使用所选择的多播IP地址和接收多播端口号，通过会话向宿设备712发送针对第一多播会话的多播媒体数据的单个拷贝。在该情况下，无需来自宿设备712的播放命令来发起来自源设备710的多播媒体数据的传输。
[0117]宿设备712还可以使用RTSP SETUP交换732来请求接收针对第二多播会话的多播媒体数据。在图7的示例中，宿设备712通过与源设备710执行包括包括被设置成url2的multicast_presentation_url参数的交换732来请求加入第二多播会话。宿设备712在由源设备710所通告的针对第二多播会话所选择的多播IP地址(例如，ip2)和多播端口号(例如，6150)上进行绑定，以接收多播媒体数据。然后，源设备710使用所选择的多播IP地址和接收多播端口号，通过会话向宿设备712发送针对第二多播会话的多播媒体数据的单个拷贝。在该情况下，无需来自宿设备712的播放命令来发起来自源设备710的多播媒体数据的传输。
[0118]在所示出的图7的示例中，在与宿设备712建立多播通信会话之后，新的宿设备714可以加入WD系统。为了建立与宿设备714的通信会话，源设备710首先执行P2P设备发现和配对734以及宿设备714。例如，源设备710、宿设备712和宿设备714可以形成W1-FiP2P组，其中，源设备710作为组拥有者。
[0119]在源设备710与宿设备714建立连接之后，源设备710可以确定要用于识别在与宿设备714的第一 RTSP SET_PARAMETER交换736中可用的多播会话的参数。根据动态多播订制过程，源设备710使用交换736来通告针对第一多播会话和第二多播的多播媒体数据的可用性。然后，源设备710可以确定由宿设备714所支持的、用于在它们的通信会话期间使用的一组参数和能力，作为使用RTSP GET_PARAMETER请求消息738的能力协商交换的一部分。根据动态多播订制过程，源设备710使用请求消息738来询问宿设备714其对先前所通告的多播会话的媒体数据的兴趣以及其可用的端口。
[0120]宿设备714利用RTSP GET_PARAMETER响应消息740来响应请求消息738其中，RTSP GET_PARAMETER响应消息740指示宿设备714对接收来自特定多播会话的多播数据感兴趣，并且如果感兴趣，则提供可用的端口号。例如，如在图7中所示出的，宿设备714在响应消息740中使用被设置成“url2”的interested_multicast_url参数来指示对接收针对第二多播会话的多播媒体数据感兴趣，以及使用被设置成等于端口 “6000”的multiCast_ports参数和端口范围“6100-6200”来指示可用的多播端口。
[0121]根据动态多播订制过程，由于新的宿设备714也对接收针对第二多播会话的多播媒体数据感兴趣，所以源设备710针对第二多播会话选择在宿设备712和714处均可用的接收多播端口号。在一些情况下，基于在新近加入的宿设备714处可用的端口，源设备710可能需要修改针对该多播会话先前所选择的多播端口号。例如，在图7中，新的宿设备714不具有针对第一多播会话可用的所选择的接收多播端口号“6120”。然而，新的宿设备714还未指示对加入第一多播会话感兴趣。因此，源设备710无需修改针对第一多播会话所选择的端口号。
[0122]然后，源设备710使用RTSP SET_PARAMETER交换742向宿设备714通告:针对宿设备714感兴趣的第二多播会话的多播媒体数据的可用性以及针对第二多播会话所选择的多播端口号。然后，宿设备714可以使用RTSP SETUP交换744来请求接收针对第二多播会话的多播媒体数据。在图7的示例中，宿设备714通过与源设备710执行包括被设置成url2的multicast_presentation_url参数的交换744来加入第二多播会话。宿设备714在由源设备710所通告的针对第二多播会话所选择的多播IP地址(例如，ip2)和多播端口号(例如，6150)上进行绑定，以接收多播媒体数据。然后，源设备710使用所选择的多播IP地址和接收多播端口号，通过会话向宿设备712和宿设备714两者发送针对第二多播会话的多播媒体数据的单个拷贝。在该情况下，无需从宿设备712和宿设备714接收播放命令来发起针对源设备710的多播媒体数据的传输。
[0123]图8是示出用于将源设备810和一个宿设备812之间的单播通信会话转换成源设备810和两个宿设备812、814之间的多播通信会话的示例性消息传送序列的示意图。源设备810通常可以以与上文针对图1A&1B中的源设备120以及图2中的源设备220所描述的相同的方式操作。宿设备812和814通常可以以与上文针对图1A&1B中的宿设备160以及图3中的宿设备360所描述的相同的方式操作。
[0124]在所示出的图8的示例中，源设备810已经建立了与宿设备812的单播会话。在与宿设备812建立单播会话之后，新的宿设备814可以加入WD系统。为了与新的宿设备814通信，源设备810和宿设备814执行P2P设备发现和配对820。在源设备810和宿设备814建立连接之后，源设备810和宿设备814可以确定针对多播通信会话的一组参数和能力，作为针对多播交换822的RTSP能力协商的一部分。
[0125]源设备810可以与新的宿设备814执行上文所描述的多播订制过程中的一个。根据多播订制过程，源设备810向宿设备814通告针对多播会话的多播媒体数据的可用性。然后，宿设备814可以使用RTSP SETUP请求消息824来请求接收所通告的多播媒体数据。在图8的示例中，宿设备814通过向源设备810发送包括multicast_presentation_url参数的请求消息824来请求加入多播会话。
[0126]在接收请求消息824之后，源设备810利用包括RTSP状态码的RTSPSETUP响应消息826来进行响应，其中，RTSP状态码指示将宿设备814添加到多播会话是否成功。在静态多播订制过程的情况下，WFD规范向宿设备814提供针对多播会话的预定义的多播端口号。在动态多播订制过程的情况下，源设备810基于在宿设备814处可用的端口号，针对该多播会话选择多播端口号。在任一情况下，然后，源设备810使用上述多播端口号，通过会话向宿设备814发送针对该多播会话的多播媒体数据的单个拷贝。
[0127]如图8中所示出的，源设备810在继续向宿设备812发送单播媒体数据的同时，向宿设备814发送多播媒体数据。根据本技术，然后，源设备810与宿设备812执行多播订制过程。例如，在图8中，源设备810和宿设备812可以确定针对多播通信会话的一组参数和能力，作为针对多播交换828的RTSP能力协商的一部分。
[0128]源设备810可以与宿设备812执行多播订制过程，以确定宿设备812是否对接收多播媒体数据感兴趣。然后，宿设备可以使用RTSP SETUP请求消息830来请求接收所通告的多播媒体数据。在图8的示例中，宿设备812通过向源设备810发送包括multiCast_presentation_url参数的请求消息830来请求加入多播会话。然后，源设备810使用多播端口号，通告该会话向宿设备812和宿设备814两者发送针对该多播会话的多播媒体数据的单个拷贝。一旦宿设备812加入多播会话，则源设备810中断单播会话。
[0129]图9是示出在WD系统中由源设备和宿设备进行的静态多播订制过程的示例性操作的流程图。在本申请中针对图2终端源设备220和图3中的宿设备360描述了操作。在其它示例中，在本公开内容中描述的任意源设备和宿设备可以执行示例性的操作。
[0130]根据静态多播订制过程，源设备220使用WD通信会话建立的RTSP能力协商阶段来与宿设备360以及WD系统中的一个或多个另外的宿设备建立多播通信会话。更具体地，源设备220向宿设备360通告针对多播会话的多播媒体数据的可用性(910)。源设备220使用RTSP (例如使用RTSPSET_PARAMETER请求)来向宿设备通告媒体数据的可用性。如果对接收所通告的多播媒体数据感兴趣，则然后，宿设备360可以向源设备220发送请求以加入多播会话(912)。宿设备360可以例如使用RTSP SETUP请求来请求多播媒体数据。源设备220从宿设备360以及WD系统中的任意其它感兴趣的宿设备接收要加入多播会话的请求(914)。
[0131]WFD规范提供了公知的、预定义的多播IP端口和接收多播端口号。因此，源设备220和宿设备360都知道要用于在WD系统中接收多播媒体数据的预定义的多播端口号。宿设备360以及对接收所通告的多播媒体数据感兴趣的任意其它宿设备在针对该多播会话的预定义的多播端口号上(916)进行绑定。此外，源设备220针对该多播会话选择预定义的多播端口号(918)。然后，源设备220使用该预定义的多播端口号，向宿设备360和任意其它感兴趣的宿设备发送针对该多播会话的多播媒体数据的单个拷贝(920)。宿设备360在其被绑定在其上的预定义的多播端口上接收针对多播会话的多播媒体数据的单个拷贝(922)。
[0132]图10是示出在WD系统中，由源设备和宿设备进行的动态多播订制过程的示例性操作的流程图。在本申请中针对图2中的源设备220和图3中的宿设备360描述的操作。在其它示例中，在本公开内容中描述的任意源设备和宿设备可以执行示例性的操作。
[0133]根据动态多播订制过程，源设备220使用WD通信会话建立的RTSP能力协商阶段来与宿设备360以及WD系统中的一个或多个另外的宿设备建立多播通信会话，并针对该多播会话选择多播端口号。与上文描述的静态多播订制过程不同，动态多播订制过程使得源设备220能够基于感兴趣的宿设备可用的端口号来针对多播会话选择多播端口号。
[0134]源设备220请求宿设备360是否对多播媒体数据感兴趣以及在宿设备360处可用的端口号(1010)。源设备220使用RTSP (例如使用RTSPGET_PARAMETER请求)来询问宿设备360以及WD系统中的任意其它宿宿设备。在利用盲端口修改的动态的多播订制过程的情况下，源设备220询问宿设备其对多播媒体数据的大体兴趣和端口号。在利用通知的端口修改的动态多播订制过程的情况下，源设备220针对特定的多播会话询问宿设备其对多播媒体数据的兴趣。如果对接收多播媒体数据感兴趣，则然后宿设备360可以向源设备220发送指示其对接收多播媒体数据感兴趣并提供其可用的多播端口号的响应(1012)。
[0135]源设备220接收宿设备360以及WD系统中的任意其它感兴趣的宿设备对接收多播媒体数据感兴趣以及在每个宿设备处可用的端口号的指示(1014)。然后，源设备220基于在感兴趣的宿设备处可用的端口号，针对多播会话选择多播端口号(1016)。在利用盲端口修改的动态多播订制过程的情况下，源设备220基于在大体上对接收多播媒体数据感兴趣的所有宿设备处可用的端口号，针对每个多播会话选择多播端口号。在利用通知的端口修改的动态多播订制过程的情况下，源设备220基于在对特定的多播会话感兴趣的宿设备处可用的端口号，针对每个多播会话选择多播端口号。
[0136]然后，源设备220向宿设备通告:针对每个多播会话的多播媒体数据的可用性以及针对多播会话所选择的多播端口号(1018)。源设备220使用RTSP (例如使用RTSP SET_PARAMETER请求)，向宿设备通告多播媒体数据和多播端口号。如果对接收所通告的多播媒体数据感兴趣，则宿设备360以及对接收所通告的多播媒体数据感兴趣的任意其它宿设备在针对该多播会话所选择的多播端口号上进行绑定(1020)。此外，宿设备360向源设备220发送要加入多播会话的请求(1022)。宿设备360可以请求多播媒体数据，例如使用RTSPSETUP请求来请求。
[0137]源设备220从宿设备360以及WD系统中的任意其它感兴趣的宿设备接收要加入多播会话的请求(1024)。然后，源设备220使用预定义的多播端口号向宿设备360以及任意其它感兴趣的宿设备发送针对该多播会话的多播媒体数据(1026)。宿设备360在所选择的、其被绑定在其上的端口上接收针对该多播会话的多播媒体数据的拷贝(1028)。
[0138]在一个或多个示例中，所述功能可以用硬件、软件、固件或其任意组合的方式来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质可以包括计算机数据存储介质或通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任意介质。在一些示例中，计算机可读介质可以包括非暂时性计算机可读介质。数据存储介质可以是能够由一个或多个计算机或一个或多个处理器存取，以取出用于实现本公开内容中描述的技术的指令、代表和/或数据结构的任意可用介质。
[0139]通过示例的方式而不是限制的方式，这种计算机可读介质可以包括非暂时性介质，例如RAM、ROM、EEPROM、CD-ROM或其它光盘存储器、磁盘存储器或其它磁存储设备、闪存、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机进行存取的任意其它介质。此外，任意连接都可以被适当地称为计算机可读介质。例如，如果软件是使用同轴线缆、光纤线缆、双绞线、数字用户线(DSL)或者诸如红外线、无线和微波之类的无线技术从网站、服务器或其它远程源传输的，那么同轴线缆、光纤线缆、双绞线、DSL或者诸如红外线、无线和微波之类的无线技术包括在所述介质的定义中。如本申请所使用的，磁盘和光盘包括压缩盘(⑶)、激光盘、光盘、数字多功能光盘(DVD)、软盘和蓝光盘，其中磁盘通常磁性地复制数据，而光盘则用激光来光学地复制数据。上面的组合也应当包括在计算机可读介质的保护范围之内。
[0140]可以由一个或多个处理器来执行代码，例如，一个或多个数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它等同的集成或离散逻辑电路。相应地，本申请中所使用的术语“处理器”可以指上述结构中的任意一个或适合实现本申请中描述的技术的任意其它结构。此外，在一些方面，本申请中描述的功能可以在配置成用于编码和解码的专用硬件和/或软件模块中提供，或者被并入组合的编解码器中。此外，可以用一个或多个电路或逻辑器件来充分实现本技术。
[0141]本公开内容的技术可以在包括无线手持设备、集成电路(IC)或一组IC (例如，芯片组)的各种设备或装置中实现。在本公开内容中描述了各种组件、模块或单元，以强调配置成执行所公开的技术的设备的功能方面，但是并不一定需要利用不同的硬件单元来实现。而是，如上文所描述的，可以将各个单元组合在编解码器硬件单元中或由包括一个或多个处理器的、相互操作的硬件单元的组合结合适当的软件和/或固件来提供。
[0142]已经描述了本发明的各个实施例。这些以及其它的实施例子随后的权利要求书的保护范围内。
【权利要求】
1.一种方法，包括: 在无线显示(WD)系统中，在源设备与两个或更多个宿设备之间建立一个或多个多播通信会话，其中包括通告针对所述多播会话的多播媒体数据的可用性以及从所述宿设备接收要加入所述多播会话的请求； 利用所述源设备，针对所述多播会话中的每个多播会话选择接收多播端口号；以及 使用所选择的接收多播端口号，向所述宿设备发送针对所述多播会话中的每个多播会话的多播媒体数据的单个拷贝。
2.根据权利要求1所述的方法，其中，选择接收多播端口号包括:针对所述多播会话中的一个或多个多播会话来选择预定义的多播端口号。
3.根据权利要求1所述的方法，其中，选择接收多播端口号包括:基于在所述宿设备处可用的端口号，针对所述多播会话中的每个多播会话来选择多播端口号，还包括:向所述宿设备通告针对所述多播会话中的每个多播会话所选择的多播端口号。
4.根据权利要求1所述的方法，还包括: 响应于在所述WD系统中的能力协商阶段期间来自所述源设备的请求，在所述源设备处从所述宿设备中的每个宿设备接收指示特定的宿设备对接收所述多播媒体数据感兴趣并且指示在该宿设备处可用的端口号的信号，其中，选择接收多播端口号包括:基于在所有所述宿设备处可用的端口号，针对所述多播会话中的每个多播会话来选择多播端口号。
5.根据权利要求4所述的方法，还包括: 从新的宿设备接收指示所述新的宿设备对接收所述多播媒体数据感兴趣并且指示在所述新的宿设备处可用的端口号的信号；以及 当针对所述多播会话中的至少一个多播会话所选择的多播端口号在所述新的宿设备处不可用时，基于在包括所述新 的宿设备在内的所有所述宿设备处可用的端口号，修改针对所述多播会话中的所述一个多播会话所选择的多播端口号，而不管所述新的宿设备是否对加入所述多播会话中的所述一个多播会话感兴趣。
6.根据权利要求1所述的方法，还包括: 响应于在所述WD系统中的能力协商阶段期间来自所述源设备的请求，在所述源设备处从所述宿设备中的每个宿设备处接收指示特定的宿设备对接收针对一个或多个特定的多播会话的所述多播媒体数据感兴趣并且指示在所述宿设备处可用的端口号的信号，其中，选择接收多播端口号包括:基于在对所述特定的多播会话感兴趣的所述宿设备处可用的端口号，针对所述多播会话中的每个多播会话选择多播端口号。
7.根据权利要求6所述的方法，还包括: 从新的宿设备接收指示所述新的宿设备对接收针对所述一个或多个特定的多播会话的所述多播媒体数据感兴趣并且指示在所述新的宿设备处可用的端口号的信号；以及 当针对所述多播会话中的至少一个多播会话所选择的多播端口号在所述新的宿设备处不可用，并且所述新的宿设备对所述多播会话中的所述一个多播会话感兴趣时，基于包括所述新的宿设备在内的、对所述特定的多播会话感兴趣的所述宿设备处可用的端口号，修改针对所述多播会话中的所述一个多播会话所选择的多播端口号。
8.根据权利要求1所述的方法，其中，建立所述多播会话包括: 针对多播订制协议，在所述源设备与所述宿设备中的每个宿设备之间建立通信信道；以及 在所述通信信道上使用所述多播订制协议来建立所述多播会话。
9.根据权利要求1所述的方法，还包括: 在所述WD系统中，在所述源设备和第一宿设备之间建立单播通信会话； 在所述源设备和新的宿设备之间建立多播通信会话；以及 将在所述源设备和所述第一宿设备之间的所述单播会话切换到所述多播会话。
10.一种方法，包括: 在无线显示(WD)系统中，利用宿设备与源设备建立一个或多个多播通信会话，其中包括:从所述源设备接收针对所述多播会话的多播媒体数据的通告，以及向所述源设备发送要加入所述多播会话中的一个或多个多播会话的请求； 利用所述宿设备，在针对所述多播会话中所述宿设备感兴趣加入的一个多播会话而选择的接收多播端口号上进行绑定；以及 利用所述宿设备，在所述宿设备绑定到的所选择的接收多播端口号上接收针对所述多播会话中的所述一个多播会话的所述多播媒体数据的拷贝。
11.根据权利要 求10所述的方法，其中，在所选择的接收多播端口号上进行绑定包括: 在针对所述多播会话中所述宿设备感兴趣加入的一个或多个多播会话的预定义的多播端口号上进行绑定。
12.根据权利要求10所述的方法，还包括: 从所述源设备接收针对所述多播会话中的所述一个多播会话所选择的多播端口号的通告，其中，所述源设备基于在所述宿设备处可用的端口号，来针对所述多播会话中的每个多播会话选择所述多播端口号，并且其中，在所选择的接收多播端口号上进行绑定包括:在所通告的针对所述多播会话中所述宿设备感兴趣加入的所述一个多播会话而选择的多播端口号上进行绑定。
13.根据权利要求10所述的方法，还包括: 响应于在所述WD系统中的能力协商阶段期间来自所述源设备的请求，向所述源设备发送指示所述宿设备对接收针对所述多播会话中的任意多播会话的多播媒体数据感兴趣，并且指示在所述宿设备处可用的端口号的信号。
14.根据权利要求13所述的方法，还包括: 当针对所述多播会话中的所述一个多播会话所选择的多播端口号在新的宿设备处不可用时，接收对基于在包括所述新的宿设备在内的所有所述宿设备处可用的端口号而修改的、针对所述多播会话中的所述一个多播会话所选择的多播端口号的通告，而不管所述新的宿设备是否对加入所述多播会话中的所述一个多播会话感兴趣。
15.根据权利要求10所述的方法，还包括: 响应于在所述WD系统中的能力协商阶段期间来自所述源设备的请求，向所述源设备发送指示所述宿设备对接收针对一个或多个特定的多播会话的多播媒体数据感兴趣，并且指示在所述宿设备处可用的端口号的信号。
16.根据权利要求15所述的方法，还包括: 当针对所述多播会话中的所述一个多播会话所选择的多播端口号在新的宿设备处不可用，并且所述新的宿设备对加入所述多播会话中的所述一个多播会话感兴趣时，接收对基于在包括所述宿设备和所述新的宿设备在内的对所述多播会话中的所述一个多播会话感兴趣的所述宿设备处可用的端口号而修改的、针对所述多播会话中的所述一个多播会话所选择的多播端口号的通告。
17.根据权利要求10所述的方法，其中，建立所述多播会话包括: 针对多播订制协议，在所述源设备与所述宿设备中的每个宿设备之间建立通信信道；以及 在所述通信信道上使用所述多播订制协议来建立所述多播会话。
18.根据权利要求10所述的方法，还包括: 在所述WD系统中，在所述源设备和所述宿设备之间建立单播通信会话；以及 在所述WD系统中，在所述源设备和新的宿设备之间建立所述多播通信会话之后，将所述源设备和所述宿设备之间的所述单播会话切换到多播通信会话。
19.一种源设备，包括: 存储器，其存储媒体数据；以及 处理器，其配置成:在无线显示(WD)系统中，在源设备与两个或更多个宿设备之间建立一个或多个多播通信 会话，其中包括通告针对所述多播会话的多播媒体数据的可用性以及从所述宿设备接收要加入所述多播会话的请求；针对所述多播会话中的每个多播会话选择接收多播端口号；以及使用所选择的接收多播端口号，向所述宿设备发送针对所述多播会话中的每个多播会话的多播媒体数据的单个拷贝。
20.根据权利要求19所述的源设备，其中，所述处理器针对所述多播会话中的一个或多个多播会话来选择预定义的多播端口号。
21.根据权利要求19所述的源设备，其中，所述处理器基于在所述宿设备处可用的端口号，针对所述多播会话中的每个多播会话来选择多播端口号，并且向所述宿设备通告针对所述多播会话中的每个多播会话所选择的多播端口号。
22.根据权利要求19所述的源设备，其中，响应于在所述WD系统中的能力协商阶段期间来自所述源设备的请求，所述处理器: 在所述源设备处从所述宿设备中的每个宿设备接收指示特定的宿设备对接收所述多播媒体数据感兴趣并且指示在该宿设备处可用的端口号的信号；以及 基于在所有所述宿设备处可用的端口号，针对所述多播会话中的每个多播会话来选择多播端口号。
23.根据权利要求22所述的源设备，其中，所述处理器: 从新的宿设备接收指示所述新的宿设备对接收所述多播媒体数据感兴趣并且指示在所述新的宿设备处可用的端口号的信号；以及 当针对所述多播会话中的至少一个多播会话所选择的多播端口号在所述新的宿设备处不可用时，基于在包括所述新的宿设备在内的所有所述宿设备处可用的端口号，修改针对所述多播会话中的所述一个多播会话所选择的多播端口号，而不管所述新的宿设备是否对加入所述多播会话中的所述一个多播会话感兴趣。
24.根据权利要求19所述的源设备，其中，响应于在所述WD系统中的能力协商阶段期间来自所述源设备的请求，所述处理器: 在所述源设备处从所述宿设备中的每个宿设备处接收指示特定的宿设备对接收针对一个或多个特定的多播会话的所述多播媒体数据感兴趣并且指示在所述宿设备处可用的端口号的信号；以及 基于在对所述特定的多播会话感兴趣的所述宿设备处可用的端口号，针对所述多播会话中的每个多播会话选择多播端口号。
25.根据权利要求24所述的源设备，其中，所述处理器: 从新的宿设备接收指示所述新的宿设备对接收针对所述一个或多个特定的多播会话的所述多播媒体数据感兴趣并且指示在所述新的宿设备处可用的端口号的信号；以及 当针对所述多播会话中的至少一个多播会话所选择的多播端口号在所述新的宿设备处不可用，并且所述新的宿设备对所述多播会话中的所述一个多播会话感兴趣时，基于包括所述新的宿设备在内的、对所述特定的多播会话感兴趣的所述宿设备处可用的端口号，修改针对所述多播会话中的所述一个多播会话所选择的多播端口号。
26.根据权利要求19所述的源设备，其中，在所述WD系统中的能力协商阶段期间，所述处理器: 针对多播订制协议，在所述源设备与所述宿设备中的每个宿设备之间建立通信信道；以及 在所述通信信道上使用所述多播订制协议来建立所述多播会话。
27.根据权利要求19所述的源设备，其中，所述处理器: 在所述WD系统中，在所述源设备和第一宿设备之间建立单播通信会话； 在所述源设备和新的宿设备之间建立多播通信会话；以及 将在所述源设备和所述第一宿设备之间的所述单播会话切换到所述多播会话。
28.—种宿设备,包括: 存储器，其存储媒体数据；以及 处理器，其配置为:在无线显示(WD)系统中，与源设备建立一个或多个多播通信会话，其中包括:从所述源设备接收针对所述多播会话的多播媒体数据的通告，以及向所述源设备发送要加入所述多播会话中的一个或多个多播会话的请求；在针对所述多播会话中所述宿设备感兴趣加入的一个多播会话而选择的接收多播端口号上进行绑定；以及在所述宿设备绑定到的所选择的接收多播端口号上接收针对所述多播会话中的所述一个多播会话的所述多播媒体数据的拷贝。
29.根据权利要求28所述的宿设备，其中，所述处理器在针对所述多播会话中所述宿设备感兴趣加入的一个或多个多播会话的预定义的多播端口号上进行绑定。
30.根据权利要求28所述的宿设备，其中，所述处理器: 从所述源设备接收针对所述多播会话中的所述一个多播会话所选择的多播端口号的通告，其中，所述源设备基于在所述宿设备处可用的端口号，来针对所述多播会话中的每个多播会话选择所述多播端口号；以及 在所通告的针对所述多播会话中所述宿设备感兴趣加入的所述一个多播会话而选择的多播端口号上进行绑定。
31.根据权利要求28所述的宿设备，其中，响应于在所述WD系统中的能力协商阶段期间来自所述源设备的请求，所述处理器向所述源设备发送指示所述宿设备对接收针对所述多播会话中的任意多播会话的多播媒体数据感兴趣，并且指示在所述宿设备处可用的端口号的信号。
32.根据权利要求31所述的宿设备，其中，当针对所述多播会话中的所述一个多播会话所选择的多播端口号在新的宿设备处不可用时，所述处理器接收对基于在包括所述新的宿设备在内的所有所述宿设备处可用的端口号而修改的、针对所述多播会话中的所述一个多播会话所选择的多播端口号的通告，而不管所述新的宿设备是否对加入所述多播会话中的所述一个多播会话感兴趣。
33.根据权利要求28所述的宿设备，其中，响应于在所述WD系统中的能力协商阶段期间来自所述源设备的请求，所述处理器向所述源设备发送指示所述宿设备对接收针对一个或多个特定的多播会话的多播媒体数据感兴趣，并且指示在所述宿设备处可用的端口号的信号。
34.根据权利要求33所述的宿设备，其中，当针对所述多播会话中的所述一个多播会话所选择的多播端口号在新的宿设备处不可用，并且所述新的宿设备对加入所述多播会话中的所述一个多播会话感兴趣时，所述处理器接收对基于在包括所述宿设备和所述新的宿设备在内的对所述多播会话中的所述一个多播会话感兴趣的所述宿设备处可用的端口号而修改的、针对所述多播会话中的所述一个多播会话所选择的多播端口号的通告。
35.根据权利要求28所述的宿设备，其中，所述处理器: 针对多播订制协议，在所述源设备与所述宿设备中的每个宿设备之间建立通信信道；以及 在所述通信信道上使用所述多播订制协议来建立所述多播会话。
36.根据权利要求28所述的宿设备，其中，所述处理器: 在所述WD系统中，在所述源设备和所述宿设备之间建立单播通信会话；以及 在所述WD系统中，在所述源设备和新的宿设备之间建立所述多播通信会话之后，将所述源设备和所述宿设备之间的所述单播会话切换到多播通信会话。
37.一种源设备,包括: 用于在无线显示(WD)系统中，在源设备与两个或更多个宿设备之间建立一个或多个多播通信会话的模块，其中所述建立包括通告针对所述多播会话的多播媒体数据的可用性以及从所述宿设备接收要加入所述多播会话的请求； 用于针对所述多播会话中的每个多播会话选择接收多播端口号的模块；以及 用于使用所选择的接收多播端口号，向所述宿设备发送针对所述多播会话中的每个多播会话的多播媒体数据的单个拷贝的模块。
38.根据权利要求37所述的源设备，还包括: 用于针对所述多播会话中的一个或多个多播会话来选择预定义的多播端口号的模块。
39.根据权利要求37所述的源设备，还包括: 用于基于在所述宿设备处可用的端口号，针对所述多播会话中的每个多播会话来选择多播端口号的模块；以及 用于向所述宿设备通告针对所述多播会话中的每个多播会话所选择的多播端口号的模块。
40.根据权利要求37所述的源设备，还包括: 用于响应于在所述WD系统中的能力协商阶段期间来自所述源设备的请求，在所述源设备处从所述宿设备中的每个宿设备接收指示特定的宿设备对接收所述多播媒体数据感兴趣并且指示在该宿设备处可用的端口号的信号的模块；以及 用于基于在所有所述宿设备处可用的端口号，针对所述多播会话中的每个多播会话来选择多播端口号的模块。
41.根据权利要求37所述的源设备，还包括: 用于响应于在所述WD系统中的能力协商阶段期间来自所述源设备的请求，在所述源设备处从所述宿设备中的每个宿设备处接收指示特定的宿设备对接收针对一个或多个特定的多播会话的所述多播媒体数据感兴趣并且指示在所述宿设备处可用的端口号的信号的模块；以及 用于基于在对所述特定的多播会话感兴趣的所述宿设备处可用的端口号，针对所述多播会话中的每个多播会话选择多播端口号的模块。
42.根据权利要求37所述的源设备，还包括: 用于在所述WD系统中，在所述源设备和第一宿设备之间建立单播通信会话的模块； 用于在所述源设备和新的宿设备之间建立多播通信会话的模块；以及 用于将在所述源设备和所述第一宿设备之间的所述单播会话切换到所述多播会话的模块。
43.—种宿设备,包括: 用于在无线显示(WD)系统中，与源设备建立一个或多个多播通信会话的模块，其中所述建立包括:从所述源设备接收针对所述多播会话的多播媒体数据的通告，以及向所述源设备发送要加入所述多播会话 中的一个或多个多播会话的请求； 用于在针对所述多播会话中所述宿设备感兴趣加入的一个多播会话而选择的接收多播端口号上进行绑定的模块；以及 用于在所述宿设备绑定到的所选择的接收多播端口号上接收针对所述多播会话中的所述一个多播会话的所述多播媒体数据的拷贝的模块。
44.根据权利要求43所述的宿设备，还包括: 用于在针对所述多播会话中所述宿设备感兴趣加入的一个或多个多播会话的预定义的多播端口号上进行绑定的模块。
45.根据权利要求43所述的宿设备，还包括: 用于从所述源设备接收针对所述多播会话中的所述一个多播会话所选择的多播端口号的通告的模块，其中，所述源设备基于在所述宿设备处可用的端口号，来针对所述多播会话中的每个多播会话选择所述多播端口号；以及 用于在所通告的针对所述多播会话中所述宿设备感兴趣加入的所述一个多播会话而选择的多播端口号上进行绑定的模块。
46.根据权利要求43所述的宿设备，还包括: 用于响应于在所述WD系统中的能力协商阶段期间来自所述源设备的请求，向所述源设备发送指示所述宿设备对接收针对所述多播会话中的任意多播会话的多播媒体数据感兴趣，并且指示在所述宿设备处可用的端口号的信号的模块。
47.根据权利要求43所述的宿设备，还包括: 用于响应于在所述WD系统中的能力协商阶段期间来自所述源设备的请求，向所述源设备发送指示所述宿设备对接收针对一个或多个特定的多播会话的多播媒体数据感兴趣，并且指示在所述宿设备处可用的端口号的信号的模块。
48.根据权利要求43所述的宿设备，还包括: 用于在所述WD系统中，在所述源设备和所述宿设备之间建立单播通信会话的模块；以及 用于在所述WD系统中，在所述源设备和新的宿设备之间建立所述多播通信会话之后，将所述源设备和所述宿设备之间的所述单播会话切换到多播通信会话的模块。
49.一种计算机可读介质，包括当在源设备中执行时，使可编程处理器执行以下操作的指令: 在无线显示(WD)系统中，在所述源设备与两个或更多个宿设备之间建立一个或多个多播通信会话，其中包括通告针对所述多播会话的多播媒体数据的可用性以及从所述宿设备接收要加入所述多播会话的请求； 利用所述源设备，针对所述多播会话中的每个多播会话选择接收多播端口号；以及使用所选择的接收多播端口号，向所述宿设备发送针对所述多播会话中的每个多播会话的多播媒体数据的单个拷贝。
50.一种计算机可读介质，包括当在宿设备中执行时，使可编程处理器执行以下操作的指令: 在无线显示(WD)系统中，利用所述宿设备与源设备建立一个或多个多播通信会话，其中包括:从所述源设备接收针对所述多播会话的多播媒体数据的通告，以及向所述源设备发送要加入所述多播会话中的一个或多个多播会话的请求； 利用所述宿设备，在针对所述多播会话中所述宿设备感兴趣加入的一个多播会话而选择的接收多播端口号上进行绑定；以及 利用所述宿设备， 在所述宿设备绑定到的所选择的接收多播端口号上接收针对所述多播会话中的所述一个多播会话的所述多播媒体数据的拷贝。
【文档编号】H04L12/18GK103814593SQ201280044925
【公开日】2014年5月21日 申请日期:2012年9月13日 优先权日:2011年9月14日
【发明者】X·黄, V·R·拉韦恩德朗, D·S·金, F·肖卡特, X·王 申请人:高通股份有限公司