CN107211301A - 具有用于WiFi‑Miracast中的服务调停和寻址控制的对等辅助式资源管理的统一服务发现 - Google Patents

具有用于WiFi‑Miracast中的服务调停和寻址控制的对等辅助式资源管理的统一服务发现 Download PDF

Info

Publication number
CN107211301A
CN107211301A CN201580075187.4A CN201580075187A CN107211301A CN 107211301 A CN107211301 A CN 107211301A CN 201580075187 A CN201580075187 A CN 201580075187A CN 107211301 A CN107211301 A CN 107211301A
Authority
CN
China
Prior art keywords
computing device
trap
channel status
processor
error
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201580075187.4A
Other languages
English (en)
Inventor
K·M·拉比
V·N·萨布莱曼尼亚姆
P·L·卡福里
F·肖卡特
S·巴拉苏布拉曼亚姆
S·普拉文库玛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of CN107211301A publication Critical patent/CN107211301A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H04L43/0829—Packet loss
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

用于无线网络中的可缩放数据服务分发的方法、设备、系统和非瞬态处理器可读存储介质。无线网络(诸如，WiFi网络)中的源计算设备的处理器可将被调度成接收服务的帧或分组的所有阱计算设备分群到单个多播群中，并且向这些阱计算设备传送多播帧或分组。该网络中的个体阱计算设备可被配置成将指示它们与源计算设备的相应无线连接的质量的差错日志发送给源计算设备。可在阱计算设备的一个或多个硬件模块中执行估计信道状态、确定所估计的信道状态是否满足差错阈值以及生成差错日志的操作。

Description

具有用于WiFi-Miracast中的服务调停和寻址控制的对等辅 助式资源管理的统一服务发现
相关申请
本申请要求于2015年2月5日提交的题为“Centralized Application LevelMulticasting With Peer-Assisted Application Level Feedback For ScalableMultimedia Data Distribution In WiFi Miracast(具有用于WiFi Miracast中的可缩放多媒体数据分发的对等辅助式应用级反馈的集中式应用级多播)”的美国临时专利申请No.62/112,574的优先权权益，其全部内容通过援引纳入于此。
背景
常规无线媒体递送平台(例如，WiFi修订版1、苹果Wi-Di等)被大量地构想为使用运动图像专家组(MPEG)传输流来无线地模仿高清晰度多媒体接口(HDMI)媒体流。例如，用户可按压智能电话上的按钮以将流送MPEG格式图像无线地投影到附近连接的监视器和/或扬声器上。
单播、广播、多播和等播(peercast)过滤技术可在无线媒体递送平台(诸如WiFi)中使用。然而，将多媒体数据从多媒体服务器递送给多个客户端以寻求可接受的服务质量(QoS)和体验质量(QoE)完全取决于服务基础设施的可缩放性，并且如此无线媒体递送平台中的可缩放多媒体数据分发要求使用多播。由于WiFi的分发协调功能(DCF)和单播性能不确定性，对于要求低等待时间/近实时响应的应用(例如，多通道音频，诸如高清晰度7.1环绕声、多通道视频等)而言，无线媒体递送平台(诸如WiFi)中向大量接收机的单播递送通常是不可能的。例如，在经由WiFi向多个不同扬声器发送未压缩的基带音频时，对于向每个扬声器作出单播传输的带宽要求可能超过WiFi系统中可用的总可用带宽。因此，在多播传输速率足够时，多播是对于要求对向大量接收设备的低等待时间/近实时响应的传输应用(例如，多通道音频(诸如高清晰度7.1环绕声)、多通道视频等)的可行替换方案。
内容递送网络(CDN)、网络层多播和P2P内容分发是常规用于多媒体数据的群分发的多媒体策略。然而，支持此类无线媒体递送平台中的多播取决于支持多播路由协议的计算设备的高级别操作系统或者要求有效的接入控制和网络管理，这是许多计算设备不具有的能力。另外，由于无线网络的固有不可靠性，无线媒体递送平台(诸如WiFi)中具有群通信分组的实时多媒体数据分发要求差错弹性以寻求用于无线媒体递送平台的当前多播策略不能提供的可接受质量。
肯定确收是使WiFi优化信道接入和连接容量的具有冲突避免的载波侦听多址(CSMA/CA)的关键。尽管无线媒体递送平台应当支持多播，但由于媒体接入控制(MAC)不公平、损耗和有效的低信道带宽(BW)的问题，当前标准的WiFi多播未能使得当前无线媒体递送平台(诸如WiFi)能够支持要求要求低等待时间/近实时响应的应用(例如，多通道音频(诸如高清晰度7.1环绕声)、多通道视频等)。用于可靠多播的当前802.11无线标准协议(即，WiFi)被设计成独立于应用层和应用层的数据传输协议来起作用，并且未能使得当前无线媒体递送平台(例如，WiFi)能够支持要求要求低等待时间/近实时响应的应用(例如，多通道音频(诸如高清晰度7.1环绕声)、多通道视频等)。取决于信道失真的源，当前用于可靠多播的802.11WiFi协议使用强力盲目地重复帧或分组，这很少增强WiFi传输可靠性。另外，用于可靠多播的当前802.11WiFi协议往往利用低调制和编码方案(MCS)单播来传送内容数据、而非提供实际的多播服务，这同样是有缺陷的，因为低MCS单播可清除旨在通过使用多播达成的所有信道效率。
概述
各种实施例提供了用于WiFi中的可缩放数据服务分发的方法、设备、系统和非瞬态处理可读存储介质。在一实施例中，WiFi网络中的源计算设备的处理器可将被调度成接收服务的帧或分组的所有阱计算设备分群到单个多播群中，并且向这些阱计算设备传送多播帧或分组。在一实施例中，WiFi网络中的个体阱计算设备可被配置成监视网络资源和确定它们与源计算设备的相应无线连接的质量。在一实施例中，WiFi网络中的个体阱计算设备可被配置成向源计算设备发送指示从源计算设备接收到的WiFi通信的服务质量的差错日志或类似消息。在一实施例中，源计算设备可至少部分地基于从多播群成员阱计算设备接收到和/或未接收到的差错日志来将多播群成员阱计算设备添加到单播群。
一种用于无线网络中监视通信链路的实施例方法可包括阱计算设备：在无线网络上从源计算设备接收携带多媒体内容的多播数据流；实时监视接收到的多播数据流内的数据元素，该数据元素包括对应于多媒体内容的时间或序列信息；基于接收到的多播数据流内所监视的数据元素的时间或序列信息来估计信道状态；生成包括所估计的信道状态的差错日志；以及在无线网络的上行链路信道上向源计算设备传送差错日志。
在一些实施例中，该方法可进一步包括阱计算设备确定是否从源计算设备接收到差错日志请求；以及响应于确定接收到请求而生成包括所估计的信道状态的差错日志。在一些实施例中，多媒体内容可以是环绕声音频数据，源计算设备可以是媒体播放器并且阱计算设备可以是扬声器。在一些实施例中，无线网络可以是Wi-Fi网络。
在一些实施例中，该方法可进一步包括阱计算设备确定所估计的信道状态是否满足差错阈值；以及响应于确定所估计的信道状态满足差错阈值而生成包括所估计的信道状态的差错日志。在一些实施例中，该方法可进一步包括阱计算设备响应于确定所估计的信道状态满足差错阈值而中断接收到的多播数据流的多媒体内容的重放。在一些实施例中，所估计的信道状态可以是分组丢失率并且差错阈值可以是最大分组丢失率。
在一些实施例中，估计信道状态、确定所估计的信道状态是否满足差错阈值以及生成差错日志的操作可以在一个或多个硬件模块中执行。
进一步实施例包括一种包括处理器的阱计算设备，该处理器配置有处理器可执行指令以用于执行上述实施例方法的操作。进一步实施例包括其上存储有处理器可执行指令的非瞬态处理器可读存储介质，这些指令被配置成使处理器执行上述实施例方法的操作。进一步实施例包括一种阱计算设备，该阱计算设备包括用于执行上述实施例方法的操作的功能的装置。
附图简要说明
纳入本文且构成本说明书一部分的附图解说了权利要求书的示例性实施例，并与以上给出的概括描述和下面给出的详细描述一起用来解释权利要求书的特征。
图1是适用于各个实施例的无线媒体递送平台或系统的系统框图。
图2是解说根据一实施例的在源计算设备与阱计算设备之间交换以建立集中式应用层多播(ALM)群的消息的呼叫流图。
图3是解说根据一实施例的WiFi协议栈中的ALM套接字接口的数据结构示图。
图4是解说根据一实施例的使用ALM的WiFi协议栈的数据结构示图。
图5是解说用于应用级信道质量估计的实施例方法的过程流程图。
图6是解说用于基于群的信道差错纠正的自适应单播重复/重传的实施例方法的过程流程图。
图7是解说在源计算设备与阱计算设备之间交换以用于基于群的信道质量质询的消息的呼叫流图。
图8A是解说用于生成和发送差错日志的实施例方法的过程流程图。
图8B是解说实现图8A的实施例方法的实施例阱计算设备的框图。
图9A和9B是解说用于WiFi中的可缩放数据服务分发的实施例方法的过程流程图。
图10是适于在各种实施例中使用的移动计算设备的组件框图。
图11是适于在各实施例中使用的扬声器单元的组件框图。
详细描述
将参照附图详细描述各种实施例。在可能之处，相同附图标记将贯穿附图用于指代相同或类似部分。对特定示例和实现作出的引述用于解说性目的，而无意限定权利要求的范围。
措辞“示例性”在本文中用于表示“用作示例、实例或解说”。本文中描述为“示例性”的任何实现不必然被解释为优于或胜过其他实现。
本文中使用术语“计算设备”来指代蜂窝电话、智能电话、上网平板、平板计算机、启用因特网的蜂窝电话、启用WiFi的电子设备、个人数据助理(PDA)、膝上型计算机、个人计算机、扬声器、家庭影院接收器、机顶盒、电视机、媒体播放器、打印机、装备视频显示器的头靠、相机、打印机、可穿戴设备、以及配备至少一处理器的类似电子设备中的任一者或全部。在各个实施例中，此类计算设备可以进一步配置有收发机(例如，LTE、3G、4G、蓝牙、WiFi等无线网络收发机)以建立诸如经由广域网(WAN)或局域网(LAN)的无线连接。
在各个实施例中，无线网络(诸如，WiFi网络)中的计算设备取决于它们在传送还是接收内容数据而被分类为源和/或阱。源可以是向一个或多个其他计算设备(即，阱设备)发送内容帧或分组的计算设备，例如作为向无线网络中的其他计算设备提供帧或分组的服务器操作。阱可以是从一个或多个其他计算设备接收内容帧或分组的计算设备。计算设备可以在无线网络(诸如WiFi网络)中排他地作为源操作，排他地作为阱操作，和/或作为阱和源操作。作为示例，家庭环绕声影院系统可在WiFi网络中实现，该WiFi网络包括充当源的家庭影院接收器，其将多通道音频(诸如，高清晰度7.1环绕声)无线地提供给充当阱的一系列扬声器。作为另一示例，WiFi网络可包括充当源的智能电话，其将流送MPEG格式图像无线地投影到充当一个或多个源的一个或多个附近连接的监视器上。
不同无线连接、无线网络和无线媒体递送平台的各个示例在本文讨论，尤其是WiFi连接、网络和媒体递送平台。对WiFi的讨论仅被提供为示例以更好地解说各个实施例的诸方面并且不旨在将权利要求限定到WiFi除非特别声明。其他无线连接、无线网络和无线媒体递送平台(例如，苹果的Wi-Di等)可使用各个实施例或与其联用，并且可在本文讨论的各个示例中替换其他无线连接、无线网络和无线媒体递送平台。
在一实施例中，WiFi中具有多个结构化对等(P2P)连接的源计算设备(例如，移动电话或平板设备)可自组织依赖于应用和应用控制的一跳容错的集中式应用层多播(ALM)群以用于多媒体数据向一群阱计算设备的可缩放分发。例如，WiFi阱计算设备的集中式ALM群可协作式地形成虚拟覆盖网络以用于直接地从源计算设备接收覆盖上递送的多播有效载荷。基于应用分发模型，多个WiFi阱计算设备可被分群以用于同时接收来自WiFi中的套接字的应用数据。在一实施例中，集中式ALM可用源计算设备中的多播套接字接口来实现，其直接恳请阱计算设备的对等客户端中的套接字对象并与其通信以前摄地组织多播群。核心套接字对象服务可包括打开连接、接受连接、发送数据和接收数据。可使用服务发现框架在集中式ALM上支持服务管理。
在一实施例中，WiFi网络中的源计算设备的处理器可将被调度成接收服务的帧或分组的所有阱计算设备分群到单个多播群中，并且向这些阱计算设备传送多播帧或分组。在一实施例中，多播帧或分组可包括指导任何接收方阱计算设备生成差错日志(或者信道统计的任何其他类型指示)并将其发送回源计算设备的指示。源计算设备可收集传入差错日志并且基于差错日志的接收和/或没有接收来确定特定阱计算设备是否接收到了多播帧或分组。在一实施例中，被源计算设备的处理器确定为尚未接收到多播帧或分组的任何阱计算设备可被移至单播群，并且该多播帧或分组可经由单播传输直接重传给单播群中的每一个相应阱计算设备。尽管理想地所有阱计算设备可经由原始多播传输接收到多播帧或分组，由此消除了对单播重传的任何需要，但单个多播群中的至少一部分阱计算设备很有可能经由原始多播传输接收到多播帧或分组，这与经由分开的单播传输向所有成员阱计算设备发送帧或分组相比降低了单播传输的需求。自适应单播重传可被用来到达未接收到原始多播传输的阱计算设备子集中的每一个设备。以此方式，较少带宽可专用于单播传输，因为帧或分组的单播传输可避开单个多播群中接收到原始传输的那些阱计算设备。
在一些实施例中，帧或分组的重传可包括不设置与在源计算设备的存储器中缓冲的先前传送的帧或分组相关联的标记，以使得未标记的帧或分组可再次被源计算设备的处理器标识为未传送。这可使得源计算设备的处理器重传来自缓冲器的未标记的帧或分组。
在进一步实施例中，源计算设备的处理器可确定下一帧或分组的传输时间是否到达。例如，每一个帧或分组可以与一传输时间相关联，并且基于源计算设备处的时钟时间，源计算设备的处理器可确定下一帧或分组的传输时间是否已到达。响应于确定下一帧或分组的传输时间未到达，源计算设备的处理器可经由单播传输直接向单播群中的每一个相应阱计算设备重传先前帧或分组。响应于确定下一帧或分组的传输时间到达，源计算设备的处理器可发送下一帧或分组而不重传先前帧或分组。以此方式，在帧或分组的传输窗口已关闭(如通过下一帧或分组的传输时间到达所指示的)时，源计算设备的处理器可避免在重传上花费资源并且直接行进到经由多播传输向多播群中的相应阱计算设备以及经由单播传输向单播群中的每一个相应阱计算设备发送下一帧或分组。
在一实施例中，对差错日志(或信道统计的任何其他类型指示)的请求可以从源计算设备通过与多播帧或分组分开的消息(诸如通过控制面消息)发送。例如，WiFi可使用实时流送协议(RTSP)信令以用于发送消息以请求与多播传输相关联的差错日志。在一实施例中，源计算设备可通过使用任何控制消息(诸如RTSP SET_PARAMETER(RTSP设置_参数)请求)向阱计算设备发送对生成和发送差错日志(或者信道统计的任何其他类型指示)的请求。在一实施例中，对差错日志的请求还可以通过服务发现框架从源计算设备发送给阱计算设备。
在各个实施例中，对差错日志(或信道统计的任何其他类型指示)的请求可以是由阱计算设备对差错日志的一次传输的请求或者该请求可以是由阱计算设备对连续差错日志的周期性传输的请求。例如，从源计算设备发送的对差错日志的请求可指示阱计算设备应当生成和发送单个差错日志。作为另一示例，从源计算设备发送的对差错日志的请求可指示阱计算设备应当以指定时段(例如，至少每50ms)生成和发送误差日志。
在一实施例中，WiFi网络中的个体阱计算设备可被配置成监视和确定它们与源计算设备的相应无线连接的质量。在一实施例中，阱计算设备的处理器可在多媒体内容帧或分组(诸如MPEG帧或分组)被接收到时监视该帧或分组中所包括的一个或多个数据元素。这些数据元素可包括对应于多媒体内容的时间和/或序列信息。基于帧或分组中的数据元素，阱计算设备的处理器可作出信道状态估计(诸如，帧或分组丢失率)以确定源计算设备与阱计算设备之间的无线连接的质量。时间和序列信息的示例可包括包含多媒体内容的MPEG传输流的节目时钟参考(PCR)和连续性计数器(CC)。另一示例可包括包含MPEG传输流的实时传输协议(RTP)的序列号(SEQ_NUM)。
在一实施例中，阱计算设备的处理器可将两个或更多个连续接收到的帧或分组中指示的MPEG节目时钟参考(PCR)进行比较以计算PCR遗漏或遗失率。在一实施例中，高于存储在阱计算设备的存储器中的阈值的PCR遗漏或遗失率可指示已发生PCR差错。在一实施例中，PCR遗漏或遗失率和/或PCR差错发生的指示可由阱计算设备的处理器用来作出信道质量(或信道状态)估计，诸如分组丢失率。
在一实施例中，阱计算设备的处理器可将两个或更多个连续接收到的帧或分组中指示的MPEG连续性计数器(CC)进行比较以计算连续性计数器遗漏或遗失率(即，序列中的一个或多个帧未被接收到的比率)。在一实施例中，高于存储在阱计算设备的存储器中的阈值的连续性计数器遗漏或遗失率可指示已发生连续性计数器差错。在一实施例中，连续性计数器遗漏或遗失率和/或连续性计数器差错发生的指示可由阱计算设备的处理器用来作出信道状态估计，诸如分组丢失率。
在一实施例中，阱计算设备的处理器可将两个或更多个连续接收到的帧或分组中指示的RTP序列号(SEQ_NUM)进行比较以计算RTP SEQ_NUM遗漏或遗失率。在一实施例中，高于存储在阱计算设备的存储器中的阈值的RTP SEQ_NUM遗漏或遗失率可指示已发生RTPSEQ差错。在一实施例中，RTP SEQ_NUM遗漏或遗失率和/或RTP SEQ差错发生的指示可由阱计算设备的处理器用来作出信道状态估计，诸如分组丢失率。
在进一步实施例中，PCR遗漏或遗失率和/或PCR差错发生的指示、连续性计数器遗漏或遗失率和/或连续性计数器差错发生的指示、以及RTP SEQ_NUM遗漏或遗失率和/或RTPSEQ差错发生的指示中的两者或更多者的各种组合可由阱计算设备的处理器一起使用以作出信道状态估计，诸如分组丢失率。
在一实施例中，阱计算设备可将信道状态估计(诸如分组丢失率)与存储器中所存储的阈值进行比较并且响应于信道状态估计超过阈值可生成差错日志(例如，CQE日志)或者信道统计的任何其他类型指示。在一实施例中，差错日志可指示信道状态估计，诸如分组丢失率。在进一步实施例中，差错日志可包括与阱计算设备相关的其他度量，诸如应用性能估计(例如，QoS估计、QoE估计等)。在一实施例中，阱计算设备可响应于来自源设备的对差错日志的请求(诸如从源计算设备向阱计算设备发送的帧或分组中指示的差错日志请求)而生成差错日志(例如，CQE日志)。在各个实施例中，响应于信道状态估计超过阈值(诸如，分组丢失率超过存储器中所存储的分组丢失阈值)，和/或响应于来自源设备的对差错日志的请求，阱计算设备可向源计算设备发送所生成的差错日志(例如，CQE日志)。在一实施例中，差错日志可以在单独的无线上行链路信道上在单播传输中从阱设备发送给源计算设备。
在一实施例中，源计算设备可至少部分地基于从多播群成员阱计算设备接收到的差错日志内所包含的信息以及来自多播群的成员的差错日志的不存在(即，缺少差错日志)来向单播群添加多播群成员阱计算设备。例如，响应于确定源计算设备尚未从作为多播群成员的特定阱计算设备接收到差错日志，源计算设备可在该计算设备未接收到多播传输的假定下将该计算设备添加到单播群或列表。作为另一示例，响应于接收到指示多播群成员阱计算设备的信道性能低于可接受水平的差错日志，源计算设备可将该多播群成员阱计算设备添加到单播群或列表以确保内容数据的可靠递送。
在各个实施例中，在经由多播传输向多播群成员阱计算设备传送帧或分组之后，源计算设备可经由单播向也在单播群中或在单播列表上的阱计算设备重传相同帧或分组。以此方式，源计算设备可尝试两次向单播群成员设备的传输，第一次经由帧或分组的多播传输，并且第二次经由向每一个单播群成员的单播传输。在一实施例中，源计算设备可检查当前信道上的可用带宽，并且给单播群成员的单播重传可以响应于可用带宽足够高以支持所需单播传输而发生。响应于带宽没有足够高，源计算设备可释放信道。
在一实施例中，阱计算设备可响应于它们被源计算设备接收到的相应差错日志指示该阱计算设备的信道性能已达到可接受水平而从单播群或列表中被移除。以此方式，阱计算设备可在它们接收到来自多播传输的服务可靠性时从单播群被移除，由此减少对单播带宽的需求，因为进一步帧或分组将不会经由单播重传给此类阱计算设备。
在一实施例中，源计算设备可基于一个或多个接收到的差错日志来确定信道状态是否可接受。响应于信道状态不可接受，源计算设备可释放信道和/或使服务降级。以此方式，在信道不能支持多播时，资源可以不被浪费在经由单播的尝试重传上。例如，响应于确定信道状态不可接受，源计算设备可使服务从7.1环绕声服务降级到5.1环绕声服务。
图1解说了包括连接到Wi-Fi LAN 190和/或能够利用Wi-Fi通信的各个计算设备102-118的无线媒体递送平台或系统100(诸如WiFi平台或系统)的示例。在该系统100中，计算设备可经由无线连接120和/或122彼此交换数据(诸如，帧或分组、消息、日志等)。例如，智能电话102可经由无线连接120(例如，LAN 190上的WiFi连接等)接收来自摄像机118(例如，因特网或web相机等)、可穿戴设备116(例如，智能手表等)、个人或台式计算机114和/或数码相机112的MPEG流。在此类示例中，摄像机118、可穿戴设备116、个人或台式计算机114和/或数码相机112可作为源计算设备操作，其将帧或分组提供给作为阱计算设备操作的智能电话102。作为阱计算设备操作的智能电话102可将消息(诸如，确收消息)和/或日志(诸如，差错日志(或信道统计的任何其他类型指示))提供给作为源计算设备操作的摄像机118、可穿戴设备116、个人或台式计算机114和/或数码相机112。
进一步，智能电话102可经由无线连接122(例如，LAN 190上的Wi-Fi连接等)向扬声器设备104、打印机设备106、监视器设备108和/或头戴式显示器(HMD)设备110传送MPEG流。具有此类一对多能力的情况下，WiFi和类似的无线媒体递送平台可提供设备间连通性，其使得整个服务能够通过多个设备成为可能。例如，为了渲染电影，智能电话102可向头戴式显示器设备110提供视频MPEG流并且向扬声器设备104提供音频MPEG流。在此类示例中，智能电话102可作为源计算设备操作，其将帧或分组提供给作为阱计算设备操作的扬声器设备104、打印机设备106、监视器设备108和/或HMD设备110。作为阱计算设备操作的扬声器设备104、打印机设备106、监视器设备108和/或HMD设备110可将消息(诸如，确收消息)和/或日志(诸如，差错日志(或信道统计的任何其他类型指示))提供给作为源计算设备操作的智能电话102。
图2是解说根据一实施例的在源计算设备与阱计算设备之间交换以建立集中式ALM群的消息的呼叫流图。图2解说了在源计算设备的处理器上运行的源栈任务层202和源WiFi层204(例如，恳求方层和/或MAC层等)与在阱计算设备的处理器上运行的阱WiFi层208(例如，恳求方层和/或MAC层等)和阱栈任务层208之间经由用户信道205(诸如，无线WiFi信道)发送的消息。在一实施例中，集中式ALM可用主机Mobil-PH/Pad对等服务器中的多播套接字接口来实现以用于直接恳请对应对等客户端中的许多套接字对象并与其通信以前摄地组织多播群。相应地，核心套接字对象服务可包括打开连接、接受连接、发送数据和接收数据。可使用服务发现框架在集中式ALM上支持服务管理。
如图2中所解说的，当阱计算设备接收到打开连接和接受连接消息时，在阱WiFi层206与源WiFi MAC层204之间(例如，在各WiFi MAC层之间)通过用户信道205交换WiFi确收。另外，源计算设备的源栈任务层202可经由给远程多播端口的写和/或读消息向多播群的阱计算设备发送多播信道状态估计查询(例如，对差错日志的请求)。阱计算设备的阱栈任务层208可使用经由用户信道205发送给源地址和端口的读响应/写消息(例如，所请求的差错日志)来响应。
图3是解说根据一实施例的WiFi协议栈300中的ALM套接字接口的数据结构示图。如由流向和流自应用层的服务管理模块302的各个箭头所指示的，应用会话和接入控制管理消息可以根据需要为单播或广播。在一实施例中，无线信道传输可作为多播从服务管理模块302通过多通道音频分组化器模块304和多播路由模块306分发。另外，用于多播传输的连接映射可通过打开连接模块308设置用于源计算设备的本地端口来控制，以使得阱计算设备可通过寻址源计算设备的本地端口来响应多播传输。
图4是解说根据一实施例的使用ALM的WiFi协议栈400的数据结构示图。在一实施例中，多个阱计算设备可被分群到多播群中以用于在WiFi中接收来自单个源套接字的应用数据。如由图4中的球虚线多播线所解说的，来自分组接收机模块和传入分组路由器模块的传入多播帧或分组可被路由给在阱计算设备的处理器上运行的覆盖分组构建器的ALM模块402。另外，来自传出分组检查和路由器模块的传出帧或分组可被路由给在阱计算设备的处理器上运行的覆盖分组构建器的ALM模块402。以此方式，多播群的阱计算设备可使用多播套接字来接收分组和到达源计算设备处的应用服务器(例如，经由FEC标记)。
图5是解说用于应用级信道状态估计的实施例方法500的过程流程图。在一实施例中，方法500的操作可由阱计算设备的处理器执行。在框502，阱计算设备的处理器可计算应用性能度量。在框504，阱计算设备的处理器可计算PCR遗漏/遗失率。在框506，阱计算设备的处理器可计算连续性计数器遗漏/遗失率。在框508，阱计算设备的处理器可计算RTP序列号遗漏/遗失率。在框510，阱计算设备的处理器可基于框502、504、506和508中计算的结果中的一者或多者来确定信道状态估计。例如，信道状态估计可以是分组丢失率。
在判定框512，阱计算设备的处理器可确定分组丢失率是否大于阈值。响应于确定分组丢失率高于阈值(即，判定框512＝“是”)，阱计算设备的处理器可在框514在单独的无线上行链路信道上在单播传输中向源计算设备发送差错日志。响应于确定分组丢失率不高于阈值(即，判定框512＝“否”)，阱计算设备的处理器可重复框502、504、506和508中的计算性能度量的操作以便对无线连接中的改变进行检测和调整。
图6是解说用于基于群的信道差错纠正的自适应单播重复/重传的实施例方法的过程流程图。在一实施例中，方法600的操作可由源计算设备的处理器执行。在判定框602，源计算设备的处理器可确定多播帧是否准备好。响应于确定多播帧准备好(即，判定框602＝“是”)，源计算设备的处理器可在判定框604确定信道是否空闲。响应于确定信道空闲(即，判定框604＝“是”)，源计算设备的处理器可在框606等待所要求的帧间间隔(IFS)历时(诸如，分布式协调功能(DCF)帧间空间(DIFS)历时)并且在框610确定信道是否空闲。尽管源计算设备被描述为等待所要求的可以为DIFS的IFS历时，但DIFS仅仅是一个示例IFS时间，并且所要求的IFS历时可由一个或多个其他时段来表示，诸如仲裁帧间间隔(AIFS)接入类别(AC)AIFS[AC]历时。
响应于确定信道不空闲(即，判定框604＝“否”或判定框610＝“否”)，源计算设备的处理器可在判定框612确定退避时段是否已超时。响应于确定退避时段已超时(即，判定框612＝“是”)，源计算设备的处理器可在框614等待DIFS历时并且在判定框616确定信道是否空闲。响应于确定信道不空闲(即，判定框616＝“否”)，源计算设备的处理器可在框618重新计算退避时段。
在框618重新计算退避时段之际或者响应于确定退避时段尚未超时(即，判定框612＝“否”)，源计算设备的处理器可在框608收集传入差错日志(例如，CQE日志)并再次在判定框612确定退避时段是否已超时。
响应于确定信道空闲(即，判定框610或616＝“是”)，源计算设备的处理器可在框620传送多播帧。在框621，源计算设备的处理器可计算每个群成员的CQE并且测量多播应用QoS/QoE。在判定框622，源计算设备的处理器可至少部分地基于每个群成员的CQE和多播应用QoS/QoE来确定信道是否可用。响应于确定信道不可用(即，判定框622＝“否”)，源计算设备的处理器可在框624释放信道。
响应于确定信道可用(即，判定框622＝“是”)，源计算设备的处理器可在判定框626确定是否到达所有群成员。例如，源计算设备的处理器可确定是否从每一个群成员接收到CQE日志和/或是否从每一个群成员接收到某种类型的确收消息以确定是否到达每一个群成员。响应于确定未到达至少一个群成员(即，判定框626＝“否”)，源计算设备的处理器可在框630使用单播向沉默节点(例如，未到达的阱计算设备)发送多播应用帧。
响应于确定到达所有群成员(即，判定框626＝“是”)，源计算设备的处理器可在判定框628确定信道性能或多播应用QoS是否不良。响应于确定信道性能或多播应用QoS不良(即，判定框628＝“是”)，源计算设备的处理器可在框624释放信道。响应于确定信道性能或多播应用QoS并非不良(即，判定框628＝“否”)，源计算设备的处理器可在框632使用单播向具有比率异常问题的节点重复/重传多播应用帧。该处理器可通过在框602确定下一多播帧是否准备好以循环方式执行方法602的操作。
图7是解说在源计算设备与阱计算设备之间交换以用于基于群的信道质量质询的消息的呼叫流图。图7类似于以上描述的图2，其中它示出了以上讨论的在层202、204、206和208之间跨用户信道205的进一步交换。图7解说了可如何使用多播向所有群成员查询它们相应的CQE和/或应用QoS/QoE。在一实施例中，未响应于健康质询的节点(例如，阱计算设备)或者报告不良链路性能的那些节点可被列出以用于单播重传。
图8A是解说用于生成和发送差错日志的实施例方法800的过程流程图。在一实施例中，方法800的操作可由阱计算设备的处理器执行。在框802，阱计算设备的处理器可接收帧或分组。例如，帧或分组可以是经由多播传输从源计算设备和/或经由单播传输从源计算设备接收到的帧或分组。
在框804，阱计算设备的处理器可至少部分地基于接收到的帧或分组中的一个或多个数据元素与先前接收到的帧或分组中的一个或多个数据元素的比较来估计信道状态。在一实施例中，阱计算设备的处理器可在帧或分组被接收时监视内容帧或分组，诸如MPEG帧或分组。基于帧或分组中的数据元素(诸如，RTP SEQ_NUM、MPEG-TS和PCR)，阱计算设备的处理器可通过将当前接收到的帧或分组与先前接收到的帧或分组进行比较来估计信道状态。在一实施例中，阱计算设备的处理器可将两个或更多个连续接收到的帧或分组中指示的节目时钟参考(PCR)进行比较以计算PCR遗漏或遗失率。在一实施例中，高于存储在阱计算设备的存储器中的阈值的PCR遗漏或遗失率可指示已发生PCR差错。在一实施例中，PCR遗漏或遗失率和/或PCR差错发生的指示可由阱计算设备的处理器用来估计信道状态，诸如信道的分组丢失率。在一实施例中，阱计算设备的处理器可将两个或更多个连续接收到的帧或分组中指示的MPEG时间戳(TS)和连续性计数器(CC)进行比较以计算连续性计数器遗漏或遗失率。在一实施例中，高于存储在阱计算设备的存储器中的阈值的连续性计数器遗漏或遗失率可指示已发生连续性计数器差错。在一实施例中，连续性计数器遗漏或遗失率和/或连续性计数器差错发生的指示可由阱计算设备的处理器用来估计信道状态，诸如信道的分组丢失率。在一实施例中，阱计算设备的处理器可将两个或更多个连续接收到的帧或分组中指示的实时传输协议(RTP)序列号(SEQ_NUM)进行比较以计算RTP SEQ_NUM遗漏或遗失率。在一实施例中，高于存储在阱计算设备的存储器中的阈值的RTP SEQ_NUM遗漏或遗失率可指示已发生RTP SEQ差错。在一些实施例中，RTP SEQ_NUM遗漏或遗失率和/或RTP SEQ差错发生的指示可由阱计算设备的处理器用来估计信道状态，诸如信道的分组丢失率。在进一步实施例中，PCR遗漏或遗失率和/或PCR差错发生的指示、连续性计数器遗漏或遗失率和/或连续性计数器差错发生的指示、以及RTP SEQ_NUM遗漏或遗失率和/或RTP SEQ差错发生的指示中的两者或更多者的各种组合可由阱计算设备的处理器一起使用以估计信道状态，诸如信道的分组丢失率。
在判定框806，阱计算设备的处理器可确定所估计的信道状态是否高于阈值。例如，阱计算设备的处理器可将所估计的信道状态与存储器中存储的阈值进行比较。作为具体示例，阱计算设备的处理器可将所估计的分组丢失率与存储器中存储的最大分组丢失率进行比较。响应于确定所估计的信道状态处于或低于阈值(即，判定框806＝“否”)，阱计算设备的处理器可在判定框808确定源计算设备是否请求差错日志。例如，阱计算设备的处理器可确定接收到的来自源计算设备的帧或分组中是否包括差错日志请求指示。
响应于确定未请求差错日志(即，判定框808＝“否”)，阱计算设备的处理器可在框802接收下一帧或分组。
响应于确定源计算设备请求差错日志(即，判定框808＝“是”)或者所估计的信道状态高于阈值(即，判定框806＝“是”)，阱计算设备的处理器可在框810生成和发送包括所估计的信道状态的差错日志。例如，该差错日志可以是经由单播发送给源计算设备的CQE日志。处理器可通过在框802接收下一帧或分组来重复方法800。
图8B是解说实现图8A的实施例方法800的实施例阱计算设备850a的框图。实施例阱计算设备850a、850b、850c和850d(统称为850)中的每一者可以是在无线网络870(例如，WiFi)上与源计算设备880(例如，WiFi服务器设备880)通信的WiFi客户端设备。
在一实施例中，源计算设备880可在无线多播信道上向WiFi客户端设备850多播多媒体或其他实时内容，并且阱计算设备可将差错日志或者无线多播信道质量或状态的其他指示传达回源计算设备880。差错日志可周期性地(例如，至少每50ms)、响应于满足差错阈值或者在被源计算设备880要求之际而被传达。作为示例，WiFi服务器设备可以实现媒体播放器，并且WiFi客户端设备可以实现多通道环绕声系统的各种音频扬声器组件。
实施例阱计算设备850a可包括控制器模块852、流监视器854、流分析器856和资源管理器858。控制器模块852、流监视器854和流分析器856的功能性可在硬件中作为电路系统或电路模块实现以用于改进的实时处理。
阱计算设备850a还可包括一个或多个应用模块860以及一个或多个通信模块862。应用模块860可实现要求对数据的低等待时间访问的多媒体或其他实时应用。例如，应用模块860可实现输出音频、视频或者音频和视频两者的多媒体应用。一个或多个通信模块862可实现用于在无线网络870上通信的一组通信协议。例如，通信模块862可实现一组传输、网络和物理层通信协议以在WiFi网络上进行通信。一个或多个应用模块860以及一个或多个通信模块862可在硬件中作为电路系统或电路模块或者作为在处理器上运行的软件模块实现。
在操作中，作为多播群的成员的阱计算设备850在无线网络870上从源计算设备880接收多播数据流882。多播数据流882可携带多媒体或其他实时内容以供阱计算设备850重放或其他输出呈现。例如，一组WiFi音频扬声器(阱计算设备850的示例)可从WiFi环绕声媒体播放器接收多通道音频数据的多播数据流。媒体播放器可以是固定的计算设备(例如，机顶盒)或移动计算设备(例如，便携式音乐播放器)。
阱计算设备850a可通过用于根据各种物理、网络和传输层协议处理的一个或多个通信模块862来传达接收到的多播数据流882。例如，通信模块862可包括WiFi物理层模块、网际协议(IP)网络模块、以及用户数据报协议(UDP)传输模块。多播数据流882可进一步在总线或其他硬件接口上传达给应用模块860，其中对多媒体或实时内容执行应用层专用处理。例如，WiFi音频扬声器的应用模块860可控制多通道音频数据的解码和重放以用于特定音频通道(例如，前左、中央、前右、环绕左、环绕后、环绕右、低音炮)。
在通信模块862与应用模块860之间传达的多播数据流882可被分段成分组、帧或其他单元。例如，多播数据流882可被分段成根据某些应用层协议(例如，实时传输协议(RTP))格式化的分组。每一个RTP分组可包括RTP报头和有效载荷。RTP分组的报头可包括表示特定应用层(或因应用而异的)时间和/或序列信息(包括针对每个RTP分组递增的序列号(RTP_SEQ_NUM))的数据元素。RTP分组的有效载荷可携带多媒体或其他实时内容或者可包括一个或多个子分组。例如，在一些实施例中，RTP分组的有效载荷可包括携带音频和/或视频数据的基本流的MPEG-2传输流(TS)分组。MPEG-2 TS分组的报头还可包括表示应用层(或因应用而异的)时间和/或序列信息的数据元素。
在多媒体或其他实时内容的情形中，应用模块850例如以最小分组丢失良好地接收多播数据流可能是优选的。如果一个或多个阱计算设备850正在遗失或遗漏分组(即，并非所有分组被接收和解码)，则对应重放或输出可被负面地影响。为了确定客户端设备850有多好地接收多播数据，每一个阱计算设备850可被配置成监视和分析多播数据流882中接收到的分组的特定应用层数据元素(例如，时间和/或序列信息)并且将此类分析的结果以差错日志或无线信道质量的其他指示的形式传达回源计算设备880以用于在需要时的补救动作。
在一些实施例中，控制器模块852可配置有来自源计算设备880的信息以用于检测和监视接收到的多播数据流882的分组。例如，控制器模块852可配置有目的地套接字标识符，其可包括多播地址和端口号。控制器模块852可进一步配置有用于标识可在多播数据流882内复用的各基本流(例如，音频、视频等)之一的分组标识符。源计算设备880可在单独的多播或单播消息中将此类配置信息传达给每一个阱计算设备850，该多播或单播消息被源管理器858接收和使用以将控制模块852配置成用于检测接收到的多播流的分组。
在多播数据流882的分组从通信模块862被传达给应用模块860时，控制器模块852可使用配置的套接字标识符和/或分组标识符来检测与正被监视的多播数据流882相对应的分组。每一次检测到多播数据流882的分组时，控制器模块852可向流监视器854发送中断或其他警报以指示检测到的分组的存在。
流监视器854可被配置成监视检测到的分组中所包含的一个或多个数据元素。在一实施例中，该一个或多个数据元素可包括与分组中携带的多媒体内容相对应的时间或序列信息。例如，在分组为RTP分组的实现中，流监视器854可被配置成读取或提取RTP分组的报头中的序列号(RTP_SEQ_NUM)的值。作为另一示例，RTP的有效载荷可进一步包括MPEG-2传输流(TS)分组，并且由此流监视器854可被配置成读取或提取MPEG-2 TS分组中的节目时钟参考(PCR)和/或连续性计数器(CC)的值。
流监视器854可被进一步配置成将检测到的分组中所监视的数据元素与先前接收到的分组中的数据元素进行比较。响应于确定检测到的分组中所监视的数据元素的值不同于预期值，流监视器可确定已发生接收差错。例如，RTP分组的报头中的序列号(RTP_SEQ_NUM)针对每一个RTP数据分组递增1。因此，响应于确定连续RTP分组的序列号之差大于1，流监视器854可确定存在RTP_SEQ_NUM差错。RTP_SEQ_NUM差错通常指示一个或多个丢失(即，未接收到)的RTP分组。类似地，MPEG-2 TS分组的节目时钟参考(PCR)和连续性计数器(CC)的值也预期以特定速率和间隔递增。因此，响应于确定两个连续接收到的PCR值之间的实际间隔不同于预期间隔(例如，每100毫秒一次)，可检测到节目时钟参考(PCR)差错。类似地，可响应于确定连续监视的连续性计数器(CC)之差大于1而检测到连续性计数器(CC)差错。
流监视器854可被配置成响应于确定存在接收差错(例如，RTP_SEQ_NUM PCR和/或CC差错)而将接收差错和附加相关元数据传达给流分析器856。流分析器856可被配置成维护各种接收差错的记录以及随时间跟踪此类差错的比率(例如，RTP_SEQ_NUM、PCR和/或CC遗失/遗漏差错率)。流分析器856可被进一步配置成基于一个或多个接收差错率来计算无线信道的状态或质量的估计。在一实施例中，所估计的信道状态可以是分组丢失率。例如，分组丢失率的估计可以基于RTP_SEQ_NUM、PCR和/或CC遗漏/遗失差错率中的一者或多者。
流分析器854还可被配置成将所估计的信道状态(诸如分组丢失率)与差错阈值(诸如最大分组丢失率)进行比对。响应于确定无线信道的所估计信道状态满足或超过差错阈值，流分析器854可将所估计的信道状态以警报或中断的形式传达给资源管理器858。响应于该警报，资源管理器858可生成包括所估计的信道状态的差错日志并将其传送回源计算设备880。在一些实施例中，源管理器858可在生成日志之后立即将差错日志发送给源计算设备880。在阱计算设备850被配置成以预定时间(例如，每50ms)或在源计算设备880要求之际传送差错日志的其他实施例中，资源管理器858可生成包括所估计信道状态在时间上聚集的多个打时间戳的条目的差错日志。阱计算设备850的资源管理器858可在单独的WiFi信道连接上将差错日志在单播消息中传送回源计算设备880。
在一些实施例中，资源管理器858还可被配置成将具有或不具有所估计信道状态的警报传达给应用模块860。在所估计的信道状态指示客户端设备没有良好地接收多播数据流时，警报可按命令的形式传达以中断多媒体或实时内容的重放或其他输出呈现。该警报还可以按通知消息的形式传达(包括所估计的信道状态)以使得应用模块860能够基于客户端设备未良好地接收到多播数据流来决定是否要中断内容的重放或其他输出呈现。
在一些实施例中，源计算设备880和阱计算设备850可以实现具有增强型对等辅助式资源管理的统一服务发现框架，其可包括服务调停和寻址控制。服务调停可包括协商和/或降级对等客户端设备850的服务等级(例如，从7.1降级到5.1多通道环绕声)。服务调停还可包括在阱计算设备850的无线信道质量可接受时协商和升级服务等级。地址控制可包括将数据多播给经历可接受无线信道质量的对等阱计算设备850和将相同数据单播给经历不可接受无线信道质量的一个或多个客户端设备850。源计算设备880可基于差错日志来确定一个或多个客户端设备850是否正经历不可接受信道质量，该差错日志可在服务发现框架的新的或现有信道上被传达。源计算设备880与阱计算设备850之间的配置信道和/或差错日志的通信可以通过服务发现框架的现有信道上的消息传输来实现。
图9A和9B是解说用于WiFi中的可缩放数据服务(例如，多媒体数据服务)分发的实施例方法900的过程流程图。在一实施例中，方法800的操作可由源计算设备的处理器执行。在框902(图9A)，处理器或源计算设备可将要接收数据服务(诸如多播数据服务(例如，高清晰度音频、视频等))的所有阱计算设备分群到多播群中。在框904，处理器或源计算设备可经由多播传输(例如，经由WiFi多播传输)发送数据服务的帧或分组。在一实施例中，所发送的帧或分组可包括指示任何接收方阱计算设备生成包括状态和/或性能指示的差错日志并将该差错日志发送回源计算设备的指示。
在框906，处理器或源计算设备可检查接收到的差错日志。例如，处理器或源计算设备可确定是否有任何接收到的差错日志被存储在被指定用于从阱计算设备接收到的差错日志的存储的存储器位置中。
在判定框908，处理器或源计算设备可确定是否已接收到关于所有多播群成员的差错日志。从多播群成员接收差错日志的失败可指示多播帧或分组未到达该群成员，因为该群成员未使用差错日志进行响应。响应于确定未接收到关于所有多播群成员的差错日志(即，判定框908＝“是”)，处理器或源计算设备可在框910将与缺少差错日志相关联的多播群成员添加到单播群。以此方式，其差错日志未被接收到的阱计算设备可成为多播群和单播群两者的成员。
响应于确定接收到关于所有多播群成员的差错日志(即，判定框908＝“是”)或者响应于在框910将多播群成员添加到单播群，处理器或源计算设备可在判定框912确定接收到的差错日志是否指示信道状态可接受。例如，处理器或源计算设备可确定接收到的差错日志的全部或部分(例如，大部分、平均等)是否指示分组丢失率低于最大分组丢失率。
响应于接收到的差错日志指示信道状态可接受(即，判定框912＝“是”)，处理器或源计算设备可在判定框914确定是否有任何接收到的差错日志指示关于所有多播群成员的信道性能可接受。响应于确定并不是关于所有多播群成员的信道性能可接受(即，判定框914＝“否”)，处理器或源计算设备可在框916将具有不可接受信道性能的任何多播群成员添加到单播群。以此方式，其差错日志指示该特定阱计算设备的信道性能不可接受的阱计算设备可成为多播群和单播群两者的成员。
响应于确定关于所有多播群成员的信道性能可接受(即，判定框914＝“是”)或者响应于在框916将具有不可接受信道性能的多播群成员添加到单播群，处理器或源计算设备可在判定框918确定接收到的差错日志是否指示关于任何单播群成员的信道性能可接受(图9B)。如以上所讨论的，帧或分组可包括在收到之际生成和发送差错日志的指示，并且在经由单播传输(例如，WiFi单播传输)接收到重传的帧或分组之际，阱计算设备可例如经由WiFi单播向源计算设备发送差错日志。由单播群成员指示的信道性能可使单播群成员有资格从单播群中被移除并且回复到帧或分组仅经由多播从源计算设备接收。以此方式，如果阱计算设备的信道性能改进(例如，因干扰源的消除等)，则单播资源可不再专用于给该阱计算设备的传输。
响应于确定接收到的差错日志指示关于任何单播群成员的信道性能可接受(即，判定框918＝“是”)，源计算设备的处理器可在框920将具有可接受信道性能的单播群成员从单播群中移除。以此方式，被移除的群成员将不再接收多播帧或分组的单播重传。
响应于确定接收到的差错日志不指示关于任何单播群成员的信道性能可接受(即，判定框918＝“否”)或者响应于在框920将单播群成员从单播群中移除，源计算设备的处理器可在判定框922确定是否有信道带宽可用于给单播群中的群成员的单播传输。以此方式，源计算设备可检查是否有必需的带宽可用于完成给单播群的所有当前成员的单播传输。
响应于确定带宽可用于单播传输(即，判定框922＝“是”)，源计算设备的处理器可在判定框923确定是否到达下一帧或分组的传输时间。例如，每一个帧或分组可以与一传输时间相关联，并且基于源计算设备处的时钟时间，源计算设备的处理器可确定下一帧或分组的传输时间是否到达。
响应于确定不是下一帧或分组的传输时间(即，判定框923＝“否”)，源计算设备的处理器可在框924经由单播传输(例如，WiFi单播传输)向单播群中的群成员重传帧或分组。例如，帧或分组的重传可包括不设置与被缓冲在源计算设备的存储器中的先前传送的帧或分组相关联的标记以使得未标记的帧或分组可再次被源计算设备的处理器标识为未传送，由此使得源计算设备的处理器重传来自缓冲器的未标记的帧或分组。通过框924中帧或分组的重传，超出框904(图9A)中的原始多播传输的提供帧或分组的附加尝试可由源计算设备承担以尝试确保单播群成员接收到帧或分组。
响应于框924(图9B)中经由单播重传帧或分组或者响应于确定是下一帧或分组的传输时间(即，判定框923＝“是”)，源计算设备的处理器可在框905(图9A)经由多播向多播群和经由单播向单播群发送下一帧或分组。
响应于确定接收到的差错日志指示信道状态不可接受(即，判定框912＝“否”)或者响应于确定带宽不可用于单播传输(即，判定框922＝“否”)，源计算设备的处理器可在框926(图9B)释放信道和/或使服务降级。例如，源计算设备的处理器可切换到服务的较低质量表示，因为信道可能不支持经由多播的可接受传输或者因为信道可能不支持纠正未被阱计算设备经由多播接收到的帧或分组所需的单播传输。
各个实施例可被实现在各种无线计算设备上，其中一示例在图10中以移动设备1000的形式作了解说。在各个实施例中，移动设备1000可包括耦合到触摸屏控制器1004和内部存储器1002的处理器1001。处理器1001可以是指定用于一般或特定处理任务的一个或多个多核集成电路(IC)。内部存储器1002可以是易失性或非易失性存储器，并且还可以是安全和/或加密的存储器、或者不安全和/或未加密存储器，或其任何组合。触摸屏控制器1004和处理器1001还可被耦合到触摸屏面板1012，诸如电阻式传感触摸屏、电容式传感触摸屏、红外传感触摸屏等。
移动设备1000可具有彼此耦合和/或耦合至处理器1001的一个或多个无线电信号收发机1008(例如，RF无线电)以及天线1010以用于发送和接收。收发机1008和天线1010可与以上提及的电路系统一起使用以实现各种无线传输协议栈和接口。在一些实施例中，移动设备1000可包括蜂窝网络无线调制解调器芯片1016，该芯片使得能够经由蜂窝网络进行通信并且耦合至处理器。
移动设备1000可以包括耦合至处理器1001的外围设备连接接口1018。外围设备连接接口1018可被配置成单独接纳一种类型的连接，或者被配置成多路接纳共用的或专有的各种类型的物理和通信连接，诸如通用串行总线(USB)、火线(FireWire)、雷电(Thunderbolt)或PCIe。外围设备连接接口1018还可被耦合至类似地配置的外围设备连接端口(未示出)。
移动设备1000还可包括用于提供音频输出的扬声器1014。移动设备1000还可包括用于容纳本文所讨论的组件中的全部或一些组件的外壳1020，外壳1020由塑料、金属或多种材料的组合来构成。移动设备1000可以包括耦合至处理器1001的电源1022，诸如一次性或可充电电池。可充电电池还可以耦合至外围设备连接端口以从移动设备1000外部的源接收充电电流。
以上所描述的各实施例还可实现在各种计算设备(诸如图11中所解说的扬声器单元1100)内。扬声器单元1100可包括耦合至存储器1104的处理器1102。扬声器单元1100可包括可连接至处理器且被配置成输出声音的扬声器1106。扬声器单元1100还可包括彼此耦合和/或耦合至处理器1110的一个或多个无线电信号收发机1110(例如，RF无线电等)以及天线以用于发送和接收。收发机1110和天线可与以上提及的电路系统一起使用以实现各种无线传输协议栈和接口。扬声器单元1110还可包括全部耦合至处理器1102的触摸板1108和显示器1112。
本文所描述的各种处理器可以是能通过软件指令(应用)配置成执行包括本文所描述的各种实施例的功能在内的各种功能的任何可编程微处理器、微型计算机或者一个或多个多处理器芯片。在各种设备中，可提供多个处理器，诸如一个处理器专用于无线通信功能并且一个处理器专用于运行其他应用。通常，软件应用可被存储在内部存储器中，然后它们被访问并被加载到这些处理器中。处理器可包括足以存储应用软件指令的内部存储器。在许多设备中，内部存储器可以是易失性或非易失性存储器(诸如闪存)，或这两者的混合。出于本说明书的目的，对存储器的一般性引述是指可由这些处理器访问的存储器，包括内部存储器或插入到各种设备中的可移除存储器、以及在处理器内部的存储器。
上述方法描述和过程流程图仅作为解说性示例而提供，且并非旨在要求或暗示各个实施例的操作必须按所给出的次序来执行。如本领域技术人员将领会的，前述各实施例中的操作次序可按任何次序来执行。诸如“其后”、“然后”、“接着”等的措辞并非旨在限定操作的次序；这些措辞仅是简单地用以指引读者遍历方法的描述。进一步，对单数形式的权利要求元素的任何引述(例如使用冠词“一”、“某”或“该”的引述)不应解释为将该元素限定为单数。
结合本文中所公开的实施例来描述的各种解说性逻辑框、模块、电路、和算法操作可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、块、模块、电路、和操作在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员可针对每种特定应用以不同方式来实现所描述的功能性，但此类实现决策不应被解读为致使脱离权利要求的范围。
用以实现结合本文中公开的实施例描述的各种解说性逻辑、逻辑框、模块、以及电路的硬件可用设计成执行本文中描述的功能的通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其他可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协同的一个或多个微处理器、或任何其它此类配置。替换地，一些操作或方法可由专用于给定功能的电路系统来执行。
在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现，则这些功能可作为一条或多条指令或代码存储在非瞬态处理器可读、计算机可读或服务器可读介质或非瞬态处理器可读存储介质上，或藉由其进行传送。本文所公开的方法或算法的步骤可在处理器可执行软件模块或处理器可执行指令中实施，该处理器可执行软件模块或处理器可执行指令可驻留在非瞬态计算机可读存储介质、非瞬态服务器可读存储介质、和/或非瞬态处理器可读存储介质上。在各种实施例中，此类指令可以是所存储的处理器可执行指令或所存储的处理器可执行软件指令。有形非瞬态计算机存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，此类非瞬态计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储、磁盘存储或其他磁存储设备、或能被用来存储指令或数据结构形式的期望程序代码且能被计算机访问的任何其他介质。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字通用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据而碟(disc)用激光以光学方式再现数据。以上的组合也应被包括在非瞬态计算机可读介质的范围内。另外，方法或算法的操作可作为一条代码和/或指令或者代码和/或指令的任何组合或集合而驻留在可被纳入计算机程序产品中的有形、非瞬态处理器可读存储介质和/或计算机可读介质上。
提供所公开的实施例的先前描述是为了使本领域任何技术人员皆能制作或使用本权利要求。对这些实施例的各种修改对于本领域技术人员而言将是显而易见的，并且本文中定义的通用原理可被应用于其他实施例而不会脱离权利要求的范围。由此，本发明并非旨在限定于本文中示出的实施例，而是应被授予与所附权利要求和本文中公开的原理和新颖性特征一致的最广义的范围。

Claims (28)

1.一种在无线网络中监视通信链路的方法，包括阱计算设备：
在所述无线网络上从源计算设备接收携带多媒体内容的多播数据流；
实时监视接收到的多播数据流内的数据元素，所述数据元素包括对应于所述多媒体内容的时间或序列信息；
基于接收到的多播数据流内所监视的数据元素的所述时间或序列信息来估计信道状态；
生成包括所估计的信道状态的差错日志；以及
在所述无线网络的上行链路信道上向所述源计算设备传送所述差错日志。
2.如权利要求1所述的方法，其特征在于，进一步包括所述阱计算设备：
确定是否从所述源计算设备接收到差错日志请求；以及
响应于确定接收到所述请求而生成包括所估计的信道状态的所述差错日志。
3.如权利要求1所述的方法，其特征在于，所述多媒体内容是环绕声音频数据，所述源计算设备是媒体播放器并且所述阱计算设备是扬声器。
4.如权利要求1所述的方法，其特征在于，所述无线网络是Wi-Fi网络。
5.如权利要求1所述的方法，其特征在于，进一步包括所述阱计算设备：
确定所估计的信道状态是否满足差错阈值；以及
响应于确定所估计的信道状态满足所述差错阈值而生成包括所估计的信道状态的所述差错日志。
6.如权利要求5所述的方法，其特征在于，进一步包括所述阱计算设备响应于确定所估计的信道状态满足所述差错阈值而中断接收到的多播数据流的所述多媒体内容的重放。
7.如权利要求5所述的方法，其特征在于，所估计的信道状态是分组丢失率并且所述差错阈值是最大分组丢失率。
8.如权利要求5所述的方法，其特征在于，估计信道状态、确定所估计的信道状态是否满足差错阈值以及生成差错日志的操作在一个或多个硬件模块中执行。
9.一种阱计算设备，包括：
存储器；
包括接收机的无线电；以及
耦合至所述存储器和所述无线电的处理器，其中所述处理器配置有处理器可执行指令以执行操作，所述操作包括：
在无线网络上从源计算设备接收携带多媒体内容的多播数据流；
实时监视接收到的多播数据流内的数据元素，所述数据元素包括对应于所述多媒体内容的时间或序列信息；
基于接收到的多播数据流内所监视的数据元素的所述时间或序列信息来估计信道状态；
生成包括所估计的信道状态的差错日志；以及
在所述无线网络的上行链路信道上向所述源计算设备传送所述差错日志。
10.如权利要求9所述的阱计算设备，其特征在于，所述处理器配置有用于执行进一步包括以下操作的操作的处理器可执行指令：
确定是否从所述源计算设备接收到差错日志请求；以及
响应于确定接收到所述请求而生成包括所估计的信道状态的所述差错日志。
11.如权利要求9所述的阱计算设备，其特征在于，其特征在于，所述多媒体内容是环绕声音频数据，所述源计算设备是媒体播放器并且所述阱计算设备是扬声器。
12.如权利要求9所述的阱计算设备，其特征在于，所述无线网络是Wi-Fi网络。
13.如权利要求9所述的阱计算设备，其特征在于，所述处理器配置有用于执行进一步包括以下操作的操作的处理器可执行指令：
确定所估计的信道状态是否满足差错阈值；以及
响应于确定所估计的信道状态满足所述差错阈值而生成包括所估计的信道状态的所述差错日志。
14.如权利要求13所述的阱计算设备，其特征在于，所述处理器配置有用于执行进一步包括以下操作的操作的处理器可执行指令：响应于确定所估计的信道状态满足所述差错阈值而中断接收到的多播数据流的所述多媒体内容的重放。
15.如权利要求13所述的阱计算设备，其特征在于，所估计的信道状态是分组丢失率并且所述差错阈值是最大分组丢失率。
16.一种其上存储有处理器可执行指令的非瞬态处理器可读存储介质，所述指令被配置成使得阱计算设备的处理器执行操作，所述操作包括：
在无线网络上从源计算设备接收携带多媒体内容的多播数据流；
实时监视接收到的多播数据流内的数据元素，所述数据元素包括对应于所述多媒体内容的时间或序列信息；
基于接收到的多播数据流内所监视的数据元素的所述时间或序列信息来估计信道状态；
生成包括所估计的信道状态的差错日志；以及
在所述无线网络的上行链路信道上向所述源计算设备传送所述差错日志。
17.如权利要求16所述的非瞬态处理器可读存储介质，其特征在于，所存储的处理器可执行指令被配置成使所述处理器执行进一步包括以下操作的操作：
确定是否从所述源计算设备接收到差错日志请求；以及
响应于确定接收到所述请求而生成包括所估计的信道状态的所述差错日志。
18.如权利要求16所述的非瞬态处理器可读存储介质，其特征在于，所述多媒体内容是环绕声音频数据，所述源计算设备是媒体播放器并且所述阱计算设备是扬声器。
19.如权利要求16所述的非瞬态处理器可读存储介质，其特征在于，所述无线网络是Wi-Fi网络。
20.如权利要求16所述的非瞬态处理器可读存储介质，其特征在于，所存储的处理器可执行指令被配置成使所述处理器执行进一步包括以下操作的操作：
确定所估计的信道状态是否满足差错阈值；以及
响应于确定所估计的信道状态满足所述差错阈值而生成包括所估计的信道状态的所述差错日志。
21.如权利要求20所述的非瞬态处理器可读存储介质，其特征在于，所存储的处理器可执行指令被配置成使所述处理器执行进一步包括以下操作的操作：响应于确定所估计的信道状态满足所述差错阈值而中断接收到的多播数据流的所述多媒体内容的重放。
22.如权利要求20所述的非瞬态处理器可读存储介质，其特征在于，所估计的信道状态是分组丢失率并且所述差错阈值是最大分组丢失率。
23.如权利要求20所述的非瞬态处理器可读存储介质，其特征在于，估计信道状态、确定所估计的信道状态是否满足差错阈值以及生成差错日志的操作在一个或多个硬件模块中执行。
24.一种阱计算设备，包括：
用于在无线网络上从源计算设备接收携带多媒体内容的多播数据流的装置；
用于实时监视接收到的多播数据流内的数据元素的装置，所述数据元素包括对应于所述多媒体内容的时间或序列信息；
用于基于接收到的多播数据流内所监视的数据元素的所述时间或序列信息来估计信道状态的装置；
用于生成包括所估计的信道状态的差错日志的装置；以及
用于在所述无线网络的上行链路信道上向所述源计算设备传送所述差错日志的装置。
25.如权利要求24所述的阱计算设备，其特征在于，进一步包括：
用于确定是否从所述源计算设备接收到差错日志请求的装置；以及
用于响应于确定接收到所述请求而生成包括所估计的信道状态的所述差错日志的装置。
26.如权利要求24所述的阱计算设备，其特征在于，进一步包括：
用于确定所估计的信道状态是否满足差错阈值的装置；以及
用于响应于确定所估计的信道状态满足所述差错阈值而生成包括所估计的信道状态的所述差错日志的装置。
27.如权利要求26所述的阱计算设备，其特征在于，进一步包括：
用于响应于确定所估计的信道状态满足所述差错阈值而中断接收到的多播数据流的所述多媒体内容的重放的装置。
28.如权利要求26所述的阱计算设备，其特征在于，所估计的信道状态是分组丢失率并且所述差错阈值是最大分组丢失率。
CN201580075187.4A 2015-02-05 2015-12-02 具有用于WiFi‑Miracast中的服务调停和寻址控制的对等辅助式资源管理的统一服务发现 Pending CN107211301A (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201562112574P 2015-02-05 2015-02-05
US62/112,574 2015-02-05
US14/799,851 2015-07-15
US14/799,851 US20160234032A1 (en) 2015-02-05 2015-07-15 Unified Service Discovery with Peer-Assisted Resource Management for Service Mediation and Addressing Control in WiFi-Miracast
PCT/US2015/063317 WO2016126309A1 (en) 2015-02-05 2015-12-02 Unified service discovery with peer-assisted resource management for service mediation and addressing control in wifi-miracast

Publications (1)

Publication Number Publication Date
CN107211301A true CN107211301A (zh) 2017-09-26

Family

ID=55024255

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201580075187.4A Pending CN107211301A (zh) 2015-02-05 2015-12-02 具有用于WiFi‑Miracast中的服务调停和寻址控制的对等辅助式资源管理的统一服务发现

Country Status (5)

Country Link
US (1) US20160234032A1 (zh)
EP (1) EP3254490B1 (zh)
CN (1) CN107211301A (zh)
TW (1) TW201635742A (zh)
WO (1) WO2016126309A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10892966B2 (en) * 2018-06-01 2021-01-12 Apple Inc. Monitoring interconnect failures over time
JP7156088B2 (ja) * 2019-02-28 2022-10-19 株式会社リコー 通信機器、ログ転送方法及び通信システム
US11223959B2 (en) 2020-05-12 2022-01-11 T-Mobile Usa, Inc. Unlicensed assisted access aggregated band for improving direct communication channel bandwidth reliability in a V2X communication
US11259190B2 (en) 2020-05-12 2022-02-22 T-Mobile Usa, Inc. Direct communication channel bandwidth reliability in a V2X communication
US11228883B2 (en) * 2020-06-02 2022-01-18 T-Mobile Usa, Inc. Vehicle-to-everything (V2X) communication assisted medical devices

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101185267A (zh) * 2005-04-04 2008-05-21 诺基亚公司 终止多媒体广播/多媒体服务（mbms）服务承载的移动台接收的方法、装置和计算机程序
WO2013056031A1 (en) * 2011-10-14 2013-04-18 Qualcomm Incorporated Feedback channel for wireless display devices
CN103947142A (zh) * 2011-09-30 2014-07-23 英特尔公司 使用单播子帧的多播服务

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1783952B1 (en) * 2005-11-04 2012-01-11 Research In Motion Limited Correction of errors in radio communication, responsive to error frequency
JP2010510695A (ja) * 2006-10-17 2010-04-02 アベガ システムズ ピーティーワイ リミテッド 無線ネットワークにおけるメディア配信
EP2409481B1 (en) * 2009-03-19 2016-05-11 Telecom Italia S.p.A. Tool for testing distribution cabinets of a telephone network
US9582239B2 (en) * 2011-01-21 2017-02-28 Qualcomm Incorporated User input back channel for wireless displays
US8514824B2 (en) * 2011-04-20 2013-08-20 Mobitv, Inc. Methods and apparatus for broadcast and multicast/unicast transition
US8887222B2 (en) * 2011-09-14 2014-11-11 Qualcomm Incorporated Multicasting in a wireless display system
US9730108B2 (en) * 2012-12-14 2017-08-08 Plantronics, Inc. Network architecture using Wi-Fi devices
KR102089459B1 (ko) * 2013-08-16 2020-03-16 삼성전자 주식회사 무선 통신에 기반한 데이터 송수신 방법 및 장치
US9357357B2 (en) * 2013-10-22 2016-05-31 Qualcomm Incorporated Group owner selection for a peer-to-peer group

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101185267A (zh) * 2005-04-04 2008-05-21 诺基亚公司 终止多媒体广播/多媒体服务（mbms）服务承载的移动台接收的方法、装置和计算机程序
CN103947142A (zh) * 2011-09-30 2014-07-23 英特尔公司 使用单播子帧的多播服务
WO2013056031A1 (en) * 2011-10-14 2013-04-18 Qualcomm Incorporated Feedback channel for wireless display devices

Also Published As

Publication number Publication date
TW201635742A (zh) 2016-10-01
EP3254490B1 (en) 2019-01-30
EP3254490A1 (en) 2017-12-13
WO2016126309A1 (en) 2016-08-11
US20160234032A1 (en) 2016-08-11

Similar Documents

Publication Publication Date Title
CN107211257A (zh) 具有用于WiFi Miracast中的可缩放多媒体数据分发的对等辅助式应用级反馈的集中式应用级多播
US11611498B2 (en) Round-trip time evaluation system, method, and apparatus
EP3055968B1 (en) Audio distribution
CN107211301A (zh) 具有用于WiFi‑Miracast中的服务调停和寻址控制的对等辅助式资源管理的统一服务发现
KR101749261B1 (ko) 스트림들의 끊김없는 경로 스위칭을 갖는 하이브리드 네트워킹 시스템
CN103959724B (zh) 混合联网路径选择和负载平衡
US9059922B2 (en) Network traffic distribution
WO2021057671A1 (zh) 一种网络的oam方法及装置
US11102273B2 (en) Uplink performance management
TW201306527A (zh) 利用相異網路傳送一封包之方法
CN103416022B (zh) 分布式路由器/交换机架构中的服务中吞吐量测试方法和系统
WO2022067791A1 (zh) 一种数据处理、传输方法及相关设备
CN110199505B (zh) 确定通信链路的带宽
US9866456B2 (en) System and method for network health and management
CN111224889A (zh) 一种数据传输的方法和装置
CN105262682A (zh) 一种用于电力数据通信的软件定义网络及其流量疏导方法
US11916770B2 (en) Pinpointing sources of jitter in network flows
Elbadry Publish/Subscribe Based Wireless Communication for Edge Environments
WO2023214903A1 (en) Improved robustness for control plane in sixth generation fronthaul
Gupta Measurement-Driven Algorithm and System Design for Wireless and Datacenter Networks
JP2012175297A (ja) ＱｏＳ制御システム、ＱｏＳ制御管理装置、及びＱｏＳ制御方法
da Silva Multiple Multicast Trees for media distribution
Simmonds J eá, 00Y

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20170926

WD01 Invention patent application deemed withdrawn after publication