CN110892686B - 向音频/视频接收器设备提供信息的方法和对应的装置 - Google Patents

向音频/视频接收器设备提供信息的方法和对应的装置 Download PDF

Info

Publication number
CN110892686B
CN110892686B CN201780091191.9A CN201780091191A CN110892686B CN 110892686 B CN110892686 B CN 110892686B CN 201780091191 A CN201780091191 A CN 201780091191A CN 110892686 B CN110892686 B CN 110892686B
Authority
CN
China
Prior art keywords
message
audio
video stream
receiver device
protocol version
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.)
Active
Application number
CN201780091191.9A
Other languages
English (en)
Other versions
CN110892686A (zh
Inventor
庄祖建
刘建成
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.)
InterDigital CE Patent Holdings SAS
Original Assignee
InterDigital CE Patent Holdings SAS
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 InterDigital CE Patent Holdings SAS filed Critical InterDigital CE Patent Holdings SAS
Publication of CN110892686A publication Critical patent/CN110892686A/zh
Application granted granted Critical
Publication of CN110892686B publication Critical patent/CN110892686B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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
    • 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/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • 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/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1877—Measures taken prior to transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/16—Multipoint routing
    • 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/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • 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/70—Media network packetisation
    • 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

Abstract

为了能够迅速启动音频/视频接收器设备并快速接收第一音频/视频流，在路由器设备和接收器设备之间的中间设备中提供一种方法。中间设备侦听音频/视频接收器设备与路由器设备之间的通信，以确定用于订阅音频/视频流的发送的路由器设备的协议版本，并确定接收器设备正在启动。如果协议版本是不支持源特定多播的版本并且接收器设备正在开启，则在接收器设备的启动期间向接收器设备发送指示协议版本的消息，以便接收器设备能够切换到IP多播路由器设备所支持的协议版本，而无需进一步的延迟。

Description

向音频/视频接收器设备提供信息的方法和对应的装置
技术领域
本公开一般涉及由路由器设备使用的协议版本与被配置为从路由器设备接收音频/视频流的音频/视频接收器设备之间的兼容性的领域。
背景技术
在此描述的任何背景信息旨在向读者介绍可能与以下描述的本实施例有关的技术的各个方面。相信该讨论有助于向读者提供背景信息以促进对本公开的各个方面的更好的理解。因此，应当理解的是，要在该角度上阅读这些陈述。
互联网组管理协议(IGMP)是通信协议，它是互联网协议(IP)多播(multicast)的一部分。IP多播是在一次发送中将IP数据报传送到一组感兴趣的接收器的方法。它是点对多点通信的一种形式，常常用于流式传输媒体应用，诸如在互联网和专用网络上在线流式传输视频和游戏。IGMP在IP多播接收器设备和本地IP多播路由器之间操作。为了接收IP多播流，IP多播接收器设备通过其本地IP多播路由器针对IP多播流请求IP多播组的成员资格，同时本地IP多播路由器监听这些请求并定期发出订阅查询。存在多个版本的IGMP。IGMP版本2(IGMPv2)通过添加IP多播接收器设备发信号通知期望离开多播组(IGMP“离开”)的能力，在IGMP版本1(IGMPv1)上进行改进。IGMP版本3(IGMPv3)主要通过支持源特定多播(source-specific multicast，SSM)，在IGMP版本2上进行改进。源特定多播是一种传递IP多播分组(packet)的方法，其中传递到IP多播接收器设备的仅有分组是源自IP多播接收器设备所请求的特定源地址的那些分组。通过如此限制源，SSM减少对网络的需求并提高安全性。
尽管当前销售的IP多播接收器设备符合IGMPv3，但仍有许多IP多播路由器以IGMPv2模式工作。以IGMPv3模式启动的IP多播接收器设备(例如，用于通过IP接收数字电视的IP机顶盒(IPSTB)，或IP数字电视(IPDTV))将无法从IGMPv2 IP多播路由器请求和接收IP多播流，直到它意识到IP多播路由器正在使用IGMPv2。这在IGMPv3 IP多播接收器设备启动时大大减慢第一IP多播流的接收。将IGMPv2 IP多播路由器升级到IGMPv3并非总是可能的。更换是昂贵的。
因此，需要一种解决方案来改善由于IP多播接收器设备的IGMP版本与IP多播路由器之间的不兼容而导致的IP多播接收器设备启动缓慢，而无需将IP多播路由器设备升级到最新IGMP版本或更换设备。
发明内容
根据本公开的一个方面，公开了一种向音频/视频流接收器设备提供信息的方法。该方法由将路由器设备和音频/视频流接收器设备互连的中间设备来实现。该方法包括：从路由器设备接收第一消息，并从第一消息获得协议版本，该协议版本供音频/视频流接收器设备使用以订阅由路由器设备进行的音频/视频流的发送。该方法还包括：从音频/视频接收器设备接收第二消息，该第二消息指示音频/视频接收器设备启动，以及如果协议版本为不支持源特定多播的协议版本，则向音频/视频流接收器设备发送指示路由器设备使用不支持源特定多播的协议版本的第三消息。
根据向音频/视频流接收器设备提供信息的方法的又一方面，协议是互联网组管理协议。协议版本是互联网组管理协议，音频/视频流是互联网协议多播音频/视频流，并且第一消息和第三消息是互联网组管理协议通用查询消息。
根据向音频/视频流接收器设备提供信息的方法的又一方面，第二消息是动态主机配置协议发现消息。
根据向音频/视频流接收器设备提供信息的方法的又一方面，该方法还包括：从第一消息的长度获得第一消息的互联网组管理协议版本。
根据向音频/视频流接收器设备提供信息的方法的又一方面，该方法还包括：从路由器设备的主机兼容性模式变量获得所接收到的互联网组管理协议通用查询消息的互联网组管理协议版本。
根据向音频/视频流接收器设备提供信息的方法的又一方面，该方法还包括：对向音频/视频流接收器设备发送第三消息施加附加条件，该附加条件为从第二消息中检查从其接收到第二消息的音频/视频流接收器设备是否与对其启用第三消息的发送的设备相对应。
根据向音频/视频流接收器设备提供信息的方法的又一方面，该方法还包括：对向音频/视频流接收器设备发送第三消息施加附加条件，该附加条件为从第二消息中检查音频/视频流接收器设备的媒体访问控制地址是否与对其启用第三消息的发送的设备相对应。
根据向音频/视频流接收器设备提供信息的方法的又一方面，该方法还包括：向音频/视频流接收器设备发送第三消息的附加条件，该附加条件为检查是否已经接收到派往(destine)音频/视频流接收器设备的动态主机配置协议确认消息。
本原理还涉及一种用于向音频/视频流接收器设备提供信息的设备。用于向音频/视频流接收器设备提供信息的设备包括处理器和存储器。处理器和存储器被配置为：从路由器设备接收第一消息，并从第一消息获得协议版本，该协议版本供音频/视频流接收器设备使用以订阅由路由器设备进行的音频/视频流的发送。处理器和存储器还被配置为：从音频/视频接收器设备接收第二消息，该第二消息指示音频/视频接收器设备启动，以及如果协议版本为不支持源特定多播的协议版本，则向音频/视频流接收器设备发送指示路由器设备使用不支持源特定多播的协议版本的第三消息。
根据用于向音频/视频流接收器设备提供信息的设备的又一方面，协议是互联网组管理协议，协议版本是互联网组管理协议，音频/视频流是互联网协议多播音频/视频流，并且第一消息和第三消息是互联网组管理协议通用查询消息。
根据用于向音频/视频流接收器设备提供信息的设备的又一方面，第二消息是动态主机配置协议发现消息。
根据用于向音频/视频流接收器设备提供信息的设备的又一方面，处理器和存储器还被配置为：从第一消息的长度获得第一消息的互联网组管理协议版本。
根据用于向音频/视频流接收器设备提供信息的设备的又一方面，处理器和存储器还被配置为：从路由器设备的主机兼容性模式变量获得互联网组管理协议通用查询消息的互联网组管理协议版本。
根据用于向音频/视频流接收器设备提供信息的设备的又一方面，处理器和存储器还被配置为：对向音频/视频流接收器设备发送第三消息施加附加条件，该附加条件为从第二消息中检查从其接收到第二消息的音频/视频流接收器设备是否与对其启用第三消息的发送的设备相对应。
根据用于向音频/视频流接收器设备提供信息的设备的又一方面，处理器和存储器还被配置为：对向音频/视频流接收器设备发送第三消息施加附加条件，该附加条件为从第二消息中检查音频/视频流接收器设备的媒体访问控制地址是否与对其启用第三消息的发送的设备相对应。
根据用于向音频/视频流接收器设备提供信息的设备的又一方面，处理器和存储器还被配置为：对向音频/视频流接收器设备发送第三消息施加附加条件，该附加条件为检查是否已经接收到派往音频/视频流接收器设备的动态主机配置协议确认消息。
附图说明
通过对特定的、非限定性实施例的描述，将显现本公开的更多优点。为了描述可以获得本公开的优点的方式，通过参考在附图中示出的本原理的特定实施例来呈现本原理的具体描述。附图描绘本公开的示例性实施例，并且因此不应被认为是对其范围的限制。所描述的实施例可以组合以形成特定的有利实施例。在以下附图中，将不再描述具有与在先前图中已经描述的项目相同的参考标号的项目，以避免不必要的混淆本公开。将参考以下附图描述实施例，附图中：
图1是用于请求设备是否对接收多播音频/视频流感兴趣的示例消息的消息报头。
图2是用于发送和接收音频/视频流的系统2。
图3是在图2的系统2的设备之间交换的数据通信消息的流程图。
图4是根据本公开的原理的系统4的实施例。
图5是在图4中描绘的系统4的设备之间交换的数据通信消息的流程图。
图6是根据本公开的原理的系统6的实施例。
图7是根据本原理向音频/视频流接收器设备提供信息。
图8是用于实现根据本公开的原理的方法的设备8的实施例。
应该理解的是，附图是出于说明本公开的概念的目的，并且不一定是用于说明本公开的唯一可能的配置。
具体实施方式
本描述示出了本公开的原理。因此，将理解，本领域技术人员将能够设计各种布置，这些布置尽管未在此被明确描述或示出，但是体现本公开的原理并被包括在其精神和范围内。
在此记载的所有示例和条件语言旨在用于教育目的，以帮助读者理解本公开的原理以及发明人为促进技术所贡献的概念，并且要被解释为不限于这样具体记载的示例和条件。
此外，在此记载本公开的原理、方面和实施例及其具体示例的所有陈述旨在涵盖其结构和功能上的等同物两者。另外，旨在这样的等同物包括当前已知的等同物以及将来开发的等同物，即，所开发的执行相同功能的任何元件，而与结构无关。
如背景技术部分中所述，以IGMPv3模式启动的IP多播接收器设备将无法请求从IGMPv2 IP多播路由器接收IP多播流，直到它意识到IP多播路由器正在使用IGMPv2并且它可以恢复到IGMPv2。这在IGMPv3 IP多播接收器设备启动时大大减慢第一IP多播流的接收。这是因为来自IGMPv3 IP多播接收器设备的任何IGMPv3 IGMP加入请求都将被IGMPv2 IP多播路由器丢弃。IGMPv3包括向后兼容特征，该特征指定如果IP多播接收器设备接收到IGMPv1或IGMPv2通用查询消息，则要求IP多播接收器设备恢复到较旧的IGMPv1或IGMPv2操作模式。IP多播路由器每125秒发送IGMP通用查询消息。因此，从启动IGMPv3 IP多播接收器设备到设置从IGMPv2 IP多播路由器接收第一IP多播流，可能耗费多达125秒以上。
图1是用于请求设备是否对接收多播音频/视频流感兴趣的示例消息的消息报头。具体地，在图1中描绘了IGMP成员资格查询消息的IGMP消息报头。为了与较旧版本路由器兼容，IGMPv3规范要求IGMPv3主机以v1和v2兼容模式操作。IGMPv3主机必须关于每个附接网络的兼容模式保持每个本地接口的状态。从主机兼容性模式(HCM)变量确定主机的兼容性模式，其可以处于以下三个状态之一：IGMPv1、IGMPv2或IGMPv3。该变量在每个接口被保持，并且尤其取决于在该接口上得知的通用查询的版本。有三个类型的成员资格查询消息。成员资格查询消息具有被设置为0x11的类型字段。先前讨论的通用查询消息是可能的成员资格查询消息之一。IGMP通用查询是其组地址字段和源数目(N)字段均为零的成员资格查询消息。可以如下确定通用查询消息的IGMP版本：
IGMPv1：长度为8个八位组(octet)，并且最大响应代码字段为零。
IGMPv2：长度为8个八位组，并且最大响应代码字段为非零。
IGMPv3：长度>＝12个八位组。
图2是用于发送和接收音频/视频流的系统2。具体地，系统2适合于IP多播流的发送和接收，包括诸如音频/视频流的视听数据的发送和接收。系统2包括数字电视DTV 14、机顶盒STB 13、家庭网络网关12、宽带远程访问服务器BRAS 11和提供商网络10。DTV14经由高清多媒体接口(HDMI)连接到STB 13。STB 13经由通常被称为局域网(LAN)的以太网链路连接到HNG 12。HNG 12经由数字用户链路(DSL)或电缆数据服务接口规范(DOCSIS)或无源光网络(PON)并经由未示出的后续网络设备连接到BRAS11。BRAS 11经由高带宽通信链路连接到提供商网络10。BRAS 11包括DHCP服务器和IGMPv2 IP多播路由器，而STB 13是IGMPv3 IP多播接收器。HNG12在桥接模式(开放系统互连模型(OSI)层2)下为DHCP和IGMP流量工作。也就是说，HNG 12没有积极参与STB 13和BRAS 11之间的DHCP和IGMP通信；STB 13可以通过发送IGMP加入消息来订阅对由BRAS 11发送的IP多播流的接收。如果BRAS 11接收到这样的消息，则它可以将所请求的IP多播流发送到STB 13。然后，STB 13对接收到的IP多播流中包括的信息进行解码，并发送解码后的流到DTV 14，DTV 14将多播流中包括的视听信息呈现为运动图像和声音。
图3是在如图2中描绘的系统2的设备之间交换的数据通信消息的流程图。从左到右示出了音频/视频流接收器设备STB 13、中间设备HNG 12和包括路由器112的BRAS 11。如前所述，HNG 12以桥接模式工作，并因此除了进行NAT之外不积极参与STB 13和BRAS 11之间的通信。STB 13使用第一协议版本来订阅由音频/视频流路由器设备进行的音频/视频流的发送(例如，IGMPv3模式)，而BRAS 11中的IP多播路由器使用第二协议版本(例如，nIGMPv2)。该流程图开始于BRAS 11中的IGMPv2 IP多播路由器112发送IGMPv2通用查询300。如前所述，每125s发送这样的消息。在其发生时，IGMPv2通用查询消息在STB 13关闭时被发送到STB 13。因此，STB 13未接收到该消息。当STB 13开启(启动)305时，STB 13以IGMPv3模式工作。在启动时，STB 13从BRAS 11中的DHCP服务器请求IP地址。这导致根据DHCP协议在STB 13和BRAS 11之间的一些交换(310-325)。STB最终被赋予IP地址。然后，STB 13希望订阅IP多播流，并因此向BRAS 11传送330IGMPv3加入消息。然而，由于BRAS 11中的IP多播路由器以IGMPv2模式工作，因此IGMPv3加入消息被丢弃。STB 13重复地(335，340)向BRAS 11传送IGMPv3加入消息，希望得到答复。这些消息被BRAS 11丢弃。在传送IGMPv2通用查询消息300之后一百二十五秒，BRAS 11重复345IGMPv2通用查询消息的发送。这次，STB 13接收到该消息，并且STB 13切换到IGMPv2操作模式。此后，它重复IGMP加入消息的发送，但是这次是以IGMPv2格式。这次，消息被BRAS 11中的IP多播路由器考虑，并且所请求的IP多播流被发送360到STB 13。STB 13接收并解码该流，STB 13在其HDMI接口上输出365视听数据，并由DTV 14呈现该视听数据。因此可以观察到浪费了125秒，花费在等待IGMP通用查询消息的下次发送上。在该等待时间(启动时间、启动延迟或开启延迟)期间，STB 13未接收到视听流，并且DTV 14未呈现视听数据。以上是最坏的情境。在实践中，因为在BRAS 11对通用查询消息的发送和STB 13的启动之间不存在同步，所以可能在STB 13启动之后接收到通用查询消息，在这种情况下，STB 13将能够较早地切换到IGMPv2，导致短于125秒的延迟。一般而言，因此可以说利用图2的现有技术系统2，在能够在DTV 14上显示画面之前可以预期最大125秒的随机等待时间。
图4是根据本公开的原理的系统4的实施例。HNG 12包括代理设备121，借助于图5来解释其工作。HNG 12可以包括用于存储代码和用于存储数据的本地存储器、用于执行代码以及用于将数据读取和写入到本地存储器的一个或多个处理器。HNG 12还可以包括有线或无线网络接口，例如，一个有线网络接口，用于经由外部网络连接到BRAS 11；两个网络接口，例如，有线以太网和无线WiFi，用于连接到包括STB 13的本地网络。图8中描绘了根据本原理的用于HNG的示例硬件。
图5是在如图4中描绘的系统4的设备之间交换的示例数据通信消息的流程图。从左到右示出了：STB 13、HNG 12中的代理121和BRAS11。如前所述，HNG 12以桥接模式工作，并且因此除了进行NAT之外不积极参与STB13和BRAS 11之间的通信。HNG 12是外部(广域网，WAN)网络和局域网(LAN)之间的中间设备。根据本公开的原理，中间设备(例如，借助于代理121的HNG 12)侦听(监听、监视、接收)WAN中的音频/视频流路由器设备(例如，BRAS11)与LAN中的音频/视频流接收器设备(例如，STB 13)之间的数据通信。例如，中间设备HNG12监听在WAN和LAN之间交换的DHCP和IGMP分组并获得协议版本，以供音频/视频流接收器设备使用以订阅由音频/视频流接收器设备进行的音频/视频流的发送。例如，LAN中的STB13以IGMPv3操作模式工作，而WAN BRAS 11中的IP多播路由器设备以IGMPv2操作模式工作。流程图开始于BRAS 11中的IGMPv2 IP多播路由器112发送IGMPv2通用查询300。如前所述，每125s发送这样的消息300。在其发生时，IGMPv2通用查询消息300在STB 13关闭时被发送到STB 13。因此，STB 13未接收到该消息。然而，根据本公开的原理，代理的IGMP侦听器功能接收到去往STB 13的IGMP通用查询，并从消息300中获得(读取)与BRAS 11中的IP多播路由器112的IGMP操作版本(协议版本)有关的信息。当STB 13开启(启动)305时，STB 13因此以IGMPv3模式工作。在启动时，STB 13从BRAS 11中的DHCP服务器111请求IP地址，例如，DHCP发现消息，该消息是指示音频/视频流接收器设备启动的消息的示例。这导致根据DHCP协议在STB 13和BRAS 11之间的一些交换(310-325)。STB 13最终被赋予IP地址。根据本公开的原理并且如前所述，中间设备HNG 12借助于代理121侦听STB 13和BRAS 11中的DHCP服务器111之间的DHCP交换；因此，HNG 12借助于代理121接收由STB 13发送到DHCP服务器111的DHCP消息，并因此意识到STB 13正处于开启过程中(正在启动、正处于启动过程中)的事实；因此，它检测510到STB 13正在开启或已开启。相应地，并且基于所获得的与BRAS 11中的IP多播路由器112的IGMP操作版本(协议版本)有关的信息，它将指示音频/视频流路由器设备(BRAS 11)使用不支持源特定多播的协议版本的消息发送(注入)到LAN中，例如IGMPv2通用查询消息515。STB 13接收该消息，并切换350到IGMPv2操作模式。然后，STB 13希望订阅IP多播流，并因此向BRAS 11中的IP多播路由器传送355IGMPv2加入消息。由于BRAS 11中的IP多播路由器也以IGMPv2模式工作，因此IGMPv2加入消息未被丢弃。该消息被BRAS 11中的IP多播路由器考虑，并且所请求的IP多播流被发送360到STB 13。STB 13接收并解码该流，STB 13在其HDMI接口上输出365视听数据，并由DTV 14呈现该视听数据。在上述实施例中，通过“侦听”(以非侵入方式监听、监视、接收)来自IP多播路由器的IGMP通用查询消息，来获得供音频/视频流接收器设备使用以订阅由音频/视频流路由器设备进行的音频/视频流的发送的协议版本，例如音频/视频流路由器设备的IGMP版本。例如，如果接收到的IGMP通用查询消息的长度为8个八位组，则IP多播路由器设备使用的IGMP版本为IGMPv1或IGMPv2；换句话说，音频/视频流路由器设备(IP多播路由器设备)不支持SSM。如果长度为十二个八位组或更多，则为IGMPv3通用查询消息；换句话说，IP多播路由器设备支持SSM。因此可以从所接收到的互联网组管理协议通用查询消息的长度中获得供音频/视频流接收器设备使用以订阅由音频/视频流路由器设备进行的音频/视频流的发送的协议版本，例如所述接收到的互联网组管理协议通用查询消息的互联网组管理协议版本。
根据不同的实施例，可以从读出先前提到的从IP多播路由器接收IGMP通用查询消息的IP多播接收器设备的接口的主机兼容性模式(HCM)变量(参数)中获得供音频/视频流接收器设备使用以订阅由音频/视频流路由器设备进行的音频/视频流的发送的协议版本，例如IP多播路由器设备的IGMP版本。在接收到IGMP通用查询消息时，刷新该变量(参数)。
因此可以观察到，通过本公开的原理，没有浪费时间，没有时间花费在等待IGMP通用查询消息的下次发送上。因此，利用图4中的系统4，STB 13的启动时间被大大减少到开启STB 13所需的正常启动时间，因为STB 13的对多播流的第一连接不会由于路由器和STB之间的不兼容问题而延迟。
图6是根据本公开的原理的系统6。HNG 62与HNG 12的不同之处在于HNG 62不以OSI层2桥接模式工作，并且包括DHCP服务器621和IGMPv2IP多播路由器622。本公开的原理同样适用于这种配置。因此，图6的HNG62中的代理121与图4的HNG 12中的代理121并无不同，除了DHCP和IGMP分组不在BRAS 11和STB 13之间交换而是在HNG 62和STB 13之间交换。与图4和图6中描绘的实施例还不同的实施例是可能的，并且不修改本原理。例如，BRAS可以包括IGMP路由器，而HNG包括DHCP服务器，或者与之相反。由于代理在具有中心位置的作为中间设备的HNG中，因此，无论DHCP服务器和IGMP路由器置于何处，在需要时，根据本公开的原理，代理能够侦听数据通信，例如，根据所选择的实施例的DHCP和可能的IGMP分组；能够从音频/视频流路由器设备接收消息(例如，IGMP通用查询消息)；能够从该消息中获得协议版本(例如，IGMPv2)，供音频/视频流接收器设备使用以订阅由音频/视频流路由器设备进行的音频/视频流的发送；并且在代理接收到指示音频/视频流接收器设备启动的消息(例如，DCHP发现消息)时，能够通过将指示音频/视频流路由器设备使用不支持源特定多播的协议版本的消息(例如IGMPv3通用查询消息)发送到音频/视频流接收器设备(IP多播接收器设备)来进行干预。
根据本公开的原理的实施例，当接收到指示音频/视频接收器设备启动的消息(LAN设备与DHCP服务器之间的DHCP通信)时，包括不止一个STB设备的LAN、代理/HNG使所讨论的指示音频/视频流路由器设备使用不支持源特定多播的协议版本的消息(例如，IGMPv2通用查询)向LAN设备的发送服从以下验证(检查)，即，验证(检查)从其接收到指示音频/视频接收器设备启动的消息的音频/视频流接收器设备是否与以下设备相对应：对该设备启用指示所述音频/视频流路由器设备使用不支持源特定多播的协议版本的消息的发送。这允许将中间设备(例如，代理/HNG)配置为对某些或所有LAN设备启用或禁用指示音频/视频流路由器设备使用不支持源特定多播的协议版本的消息(例如，IGMPv2通用查询消息)的发送(注入)。例如，可以基于在所接收的DHCP发现消息中的DHCP选项60字段来进行这种验证(检查)。DHCP发现消息中的选项60(供应商类别标识符(VCI))被广泛用于表示DHCP客户端的设备类型或用户类别。它是可变长度的字符串。用于启用/禁用指示音频/视频流路由器设备使用不支持源特定多播的协议版本的消息的发送的这种配置可以由网络管理员来进行，并且可以存储在中间设备的存储器中。然后，用于由中间设备向LAN设备发送指示所述音频/视频流路由器设备使用不支持源特定多播的协议版本的消息的条件是：供音频/视频流接收器设备使用以订阅由音频/视频流路由器设备进行的音频/视频流的发送的协议版本是不支持SSM的版本，并且LAN设备与以下设备相对应：该设备的DHCP发现选项60值存储在中间设备中、对其允许(启用)这种发送。在所有其他情况下，不进行发送。
根据不同的实施例，基于与设备的IP地址或设备的网络接口相反的、不改变的媒体访问控制(MAC)地址来进行中间设备的以下操作，即，使指示音频/视频流路由器设备使用不支持源特定多播的协议版本的消息向LAN设备的发送服从以下验证，即，验证从其接收到指示音频/视频接收器设备启动的消息的音频/视频流接收器设备是否与以下设备相对应：对该设备启用指示所述音频/视频流路由器设备使用不支持源特定多播的协议版本的消息的发送。然后，用于向LAN设备发送指示音频/视频流路由器设备使用不支持源特定多播的协议版本的消息的条件是：供音频/视频流接收器设备使用以订阅由音频/视频流路由器设备进行的音频/视频流的发送的协议版本是不支持源特定多播的协议版本，并且LAN设备的MAC地址的值与以下LAN设备的MAC地址相对应：该LAN设备的MAC地址存储在中间设备中，以作为对其允许(启用)这种发送的LAN设备的MAC地址。否则，不进行发送。
上面提到的服从于对特定LAN设备选择性地启用指示音频/视频流路由器设备使用不支持源特定多播的协议版本的消息的发送(注入)的实施例的至少一个优点在于，其限制LAN上的消息流量，并且避免为不相关的设备造成不想要的副作用。
根据可以与先前实施例组合的实施例，对特定LAN设备发送指示音频/视频流路由器设备使用不支持源特定多播的协议版本的消息还服从于以下检查，即，检查是否已经接收到派往LAN设备的确认消息(例如，在DHCP发现之后的DHCP ack)。该实施例的至少一个优点在于，其因此确保LAN设备在中间设备将指示音频/视频流路由器设备使用不支持源特定多播的协议版本的消息发送给它时准备好接收并考虑该消息，因为接收到DHCP ack表明LAN设备的IP地址被DHCP服务器确认。然后，用于由中间设备向LAN设备发送指示音频/视频流路由器设备使用不支持源特定多播的协议版本的消息的条件是：供音频/视频流接收器设备使用以订阅由音频/视频流路由器设备进行的音频/视频流的发送的协议版本是不支持源特定多播的协议版本，并且派往LAN设备的确认消息(例如，在DHCP发现之后的DHCPack)已被中间设备接收(侦听)。否则，不进行发送。
图7是根据本公开的原理的向音频/视频流接收器设备提供信息的方法的实施例的流程图。方法700例如由诸如HNG 12或HNG 61的中间设备来实现，该中间设备将诸如IGMP路由器112或622的音频/视频流路由器设备与诸如STB 13的音频/视频流接收器设备互连。该方法包括：从音频/视频流路由器设备接收第一消息(701-是)，并从第一消息获得702协议版本，该协议版本供音频/视频流接收器设备使用以订阅由音频/视频流路由器设备进行的音频/视频流的发送。该方法还包括：从音频/视频接收器设备接收第二消息，该第二消息指示音频/视频接收器设备启动(703-是)，以及如果协议版本为不支持源特定多播的协议版本(704-是)，则向音频/视频流接收器设备发送705指示音频/视频流路由器设备使用不支持源特定多播的协议版本的第三消息。
图8是用于实现根据本公开的原理的方法的具有处理器和存储器的中间设备8的实施例。设备8例如是图4的HNG 12或图6的HNG 62。它包括经由内部通信总线810互连的中央处理单元或处理器800、存储器801、第一网络接口802、第二网络接口803。第一网络接口802例如用于包括到图4的BRAS 11或图6的BRAS 61的WAN连接。第二网络接口803例如用于包括到STB 13的LAN连接。在设备8中执行如在图7的流程图700中描绘的功能。例如，通过第一网络接口802接收步骤701中的第一消息，并由处理器800执行步骤702。例如，通过第二网络接口803接收第二消息，并且处理器800执行步骤704。最后，通过第二网络接口803发送步骤705中的消息。
要理解，附图中的某些元件可能并不在所有实施例中都使用或者并非在所有实施例中都是必须的。可以并行执行某些操作。除了图示和/或描述的实施例以外的实施例是可能的。例如，实现本原理的设备可以包括硬件和软件的混合。本实施例的各方面可以在除IGMPv2/v3之外的其他IGMP版本中使用，诸如IGMPv1/v2。在不背离本原理的情况下，本实施例的各方面可以在除IGMP之外的其他通信协议中使用，诸如当前或将来的IP多播协议。在不背离本原理的情况下，本实施例的各方面可以在除DHCP之外的其他通信协议中使用，诸如能够确定LAN设备正在启动的其他当前或将来的协议。
要理解，本公开的原理的各方面可以体现为系统、方法或计算机可读介质。因此，本公开的原理的各方面可以采取以下形式：完全硬件实施例、完全软件实施例(包括固件、常驻软件、微代码等)、或者组合了硬件和软件方面的实施例，它们在此一般都可以定义为“电路”、“模块”或“系统”。此外，本公开的原理的各方面可以采取计算机可读存储介质的形式。可以利用一个或多个计算机可读存储介质的任何组合。
因此，例如，要理解，在此呈现的图表示体现本公开的原理的说明性系统组件和/或电路的概念视图。类似地，要理解，任何流程图、流程图表、状态转换图、伪代码等表示可以基本上在计算机可读存储介质中表示并因此由计算机或处理器执行的各种过程，无论这种计算机或处理器是否被明确示出。
计算机可读存储介质可以采取计算机可读程序产品的形式，该计算机可读程序产品包含在一个或多个计算机可读介质中，且具有可由计算机执行的在其上包含的计算机可读程序代码。在此使用的计算机可读存储介质被认为是非暂时性存储介质，给出在其中存储信息的固有能力以及提供从中检索信息的固有能力。计算机可读存储介质可以是例如但不限于电子的、磁性的、光学的、电磁的、红外的或半导体系统、装置或设备、或前述内容的任何适当组合。存储介质的某些方面或所有方面可以远程定位(例如，在“云”中)。要理解，如本领域普通技术人员容易理解的那样，以下内容尽管提供可以应用本原理的计算机可读存储介质的更具体的示例，但是仅仅是说明性而非详尽的列表：硬盘、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或闪速存储器)、便携式压缩盘只读存储器(CD-ROM)、光学存储设备、磁存储设备、或前述内容的任何适当组合。

Claims (16)

1.一种向音频/视频流接收器设备提供信息的方法(700)，其特征在于，所述方法由将路由器设备和所述音频/视频流接收器设备互连的中间设备来实现，所述方法包括：
从所述路由器设备接收(701)第一消息，并从所述第一消息获得(702)协议版本，所述协议版本供所述音频/视频流接收器设备使用以订阅由所述路由器设备进行的音频/视频流的发送；以及
从所述音频/视频接收器设备接收(703)第二消息，所述第二消息指示所述音频/视频接收器设备启动，以及如果所述协议版本为不支持源特定多播的协议版本，则向所述音频/视频流接收器设备发送(705)指示所述路由器设备使用不支持源特定多播的协议版本的第三消息。
2.根据权利要求1所述的方法，其中，所述协议是互联网组管理协议，所述协议版本是互联网组管理协议版本，所述音频/视频流是互联网协议多播音频/视频流，并且所述第一消息和所述第三消息是互联网组管理协议通用查询消息。
3.根据权利要求1或2所述的方法，其中，所述第二消息是动态主机配置协议发现消息。
4.根据权利要求2所述的方法，还包括：从所述第一消息的长度获得所述第一消息的所述互联网组管理协议版本。
5.根据权利要求2所述的方法，还包括：从所述路由器设备的主机兼容性模式变量获得所述接收到的互联网组管理协议通用查询消息的所述互联网组管理协议版本。
6.根据权利要求1或2所述的方法，还包括：对向所述音频/视频流接收器设备发送所述第三消息施加附加条件，所述附加条件为从所述第二消息中检查从其接收到所述第二消息的所述音频/视频流接收器设备是否与对其启用所述第三消息的所述发送的设备相对应。
7.根据权利要求1或2所述的方法，还包括：对向所述音频/视频流接收器设备发送所述第三消息施加附加条件，所述附加条件为从所述第二消息中检查所述音频/视频流接收器设备的媒体访问控制地址是否与对其启用所述第三消息的所述发送的设备相对应。
8.根据权利要求3所述的方法，还包括：向所述音频/视频流接收器设备发送所述第三消息的附加条件，所述附加条件为检查是否已经接收到派往所述音频/视频流接收器设备的动态主机配置协议确认消息。
9.一种用于向音频/视频流接收器设备提供信息的设备(8)，包括处理器(800)和存储器(801)，所述处理器(800)和存储器(801)被配置为：
从路由器设备接收第一消息，并从所述第一消息获得协议版本，所述协议版本供所述音频/视频流接收器设备使用以订阅由所述路由器设备进行的音频/视频流的发送；以及
从所述音频/视频接收器设备接收第二消息，所述第二消息指示所述音频/视频接收器设备启动，以及如果所述协议版本为不支持源特定多播的协议版本，则向所述音频/视频流接收器设备发送指示所述路由器设备使用不支持源特定多播的协议版本的第三消息。
10.根据权利要求9所述的设备，其中，所述协议是互联网组管理协议，所述协议版本是互联网组管理协议版本，所述音频/视频流是互联网协议多播音频/视频流，并且所述第一消息和所述第三消息是互联网组管理协议通用查询消息。
11.根据权利要求9或10所述的设备，其中，所述第二消息是动态主机配置协议发现消息。
12.根据权利要求10所述的设备，其中，所述处理器和所述存储器还被配置为从所述第一消息的长度获得所述第一消息的所述互联网组管理协议版本。
13.根据权利要求10所述的设备，其中，所述处理器和所述存储器还被配置为从所述路由器设备的主机兼容性模式变量获得所述互联网组管理协议通用查询消息的所述互联网组管理协议版本。
14.根据权利要求9或10所述的设备，其中，所述处理器和所述存储器还被配置为对向所述音频/视频流接收器设备发送所述第三消息施加附加条件，所述附加条件为从所述第二消息中检查从其接收到所述第二消息的所述音频/视频流接收器设备是否与对其启用所述第三消息的所述发送的设备相对应。
15.根据权利要求9或10所述的设备，其中，所述处理器和所述存储器还被配置为对向所述音频/视频流接收器设备发送所述第三消息施加附加条件，所述附加条件为从所述第二消息中检查所述音频/视频流接收器设备的媒体访问控制地址是否与对其启用所述第三消息的所述发送的设备相对应。
16.根据权利要求11所述的设备，其中，所述处理器和所述存储器还被配置为对向所述音频/视频流接收器设备发送所述第三消息施加附加条件，所述附加条件为检查是否已经接收到派往所述音频/视频流接收器设备的动态主机配置协议确认消息。
CN201780091191.9A 2017-05-24 2017-05-24 向音频/视频接收器设备提供信息的方法和对应的装置 Active CN110892686B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2017/085697 WO2018214051A1 (en) 2017-05-24 2017-05-24 Method of providing information to an audio/video receiver device and corresponding apparatus

Publications (2)

Publication Number Publication Date
CN110892686A CN110892686A (zh) 2020-03-17
CN110892686B true CN110892686B (zh) 2022-05-17

Family

ID=64396166

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201780091191.9A Active CN110892686B (zh) 2017-05-24 2017-05-24 向音频/视频接收器设备提供信息的方法和对应的装置

Country Status (4)

Country Link
US (1) US11218523B2 (zh)
EP (1) EP3632065B1 (zh)
CN (1) CN110892686B (zh)
WO (1) WO2018214051A1 (zh)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101098423A (zh) * 2006-06-30 2008-01-02 汤姆森许可贸易公司 接收音频/视频服务的方法及相应的终端和系统
CN102474426A (zh) * 2009-07-20 2012-05-23 瑞典爱立信有限公司 具多播能力的路由器上有效的主机管理协议
CN103905841A (zh) * 2014-03-18 2014-07-02 深圳市云宙多媒体技术有限公司 自适应网络带宽的多协议多播放器视频播放方法和系统

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7974192B2 (en) 1999-10-13 2011-07-05 Avaya Inc. Multicast switching in a distributed communication system
US20080000517A1 (en) 2003-06-10 2008-01-03 Gonsiorawski Ronald C Photovoltaic module with light reflecting backskin
FR2864869A1 (fr) * 2004-01-06 2005-07-08 Thomson Licensing Sa Methode de transmission de services numeriques sur un reseau et appareil mettant en oeuvre la methode
WO2006081454A2 (en) * 2005-01-26 2006-08-03 Internet Broadcasting Corporation Layered multicast and fair bandwidth allocation and packet prioritization
US7724739B2 (en) * 2005-03-18 2010-05-25 Cisco Technology, Inc. Source specific multicast layer 2 networking device and method
US20060282545A1 (en) 2005-06-11 2006-12-14 Arwe John E Method and apparatus for application or protocol version negotiation
US7685291B2 (en) 2005-11-08 2010-03-23 Mediatek Inc. Messaging service interoperability methods and related devices
KR100823544B1 (ko) 2006-10-27 2008-04-21 삼성전자주식회사 이동통신 시스템에서 프로토콜 버전 매칭 장치 및 방법
EP1983713A1 (en) 2007-04-16 2008-10-22 Nokia Siemens Networks Oy Method for operating a network element and according device as well as communication system comprising such device
US8379641B2 (en) * 2009-07-20 2013-02-19 Telefonaktiebolaget L M Ericsson (Publ) Light host management protocol on multicast capable router
US8891535B2 (en) * 2012-01-18 2014-11-18 International Business Machines Corporation Managing a global forwarding table in a distributed switch
US8953478B2 (en) * 2012-01-27 2015-02-10 Intel Corporation Evolved node B and method for coherent coordinated multipoint transmission with per CSI-RS feedback
CN104104606B (zh) * 2013-04-01 2018-06-12 南京中兴软件有限责任公司 一种调制解调器及其实现igmp报文版本自适应的方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101098423A (zh) * 2006-06-30 2008-01-02 汤姆森许可贸易公司 接收音频/视频服务的方法及相应的终端和系统
CN102474426A (zh) * 2009-07-20 2012-05-23 瑞典爱立信有限公司 具多播能力的路由器上有效的主机管理协议
CN103905841A (zh) * 2014-03-18 2014-07-02 深圳市云宙多媒体技术有限公司 自适应网络带宽的多协议多播放器视频播放方法和系统

Also Published As

Publication number Publication date
EP3632065A4 (en) 2020-12-30
EP3632065A1 (en) 2020-04-08
US11218523B2 (en) 2022-01-04
US20200213369A1 (en) 2020-07-02
EP3632065B1 (en) 2022-08-10
CN110892686A (zh) 2020-03-17
WO2018214051A1 (en) 2018-11-29

Similar Documents

Publication Publication Date Title
US7827275B2 (en) Method and system for remotely accessing devices in a network
CN111427527B (zh) 投屏方法、装置、设备及计算机可读存储介质
US20150181285A1 (en) Media Playback Method, Control Point, and Terminal
KR20090101384A (ko) 네트워크에서의 완전 메시 레이트 트랜잭션
EP2202974B1 (en) A method, equipment and system for starting a service of the network television
US20150067110A1 (en) Media Playing Method, Apparatus, and System
US10893086B2 (en) Node type based control of assistance for data streaming
CN109391551B (zh) 一种多端口组播方法、设备及计算机可读存储介质
KR20060039284A (ko) 멀티캐스트를 이용한 데이터 송수신 시스템 및 방법
WO2018113693A1 (zh) 局域网设备通信管理方法、系统及网关设备
WO2009021460A1 (fr) Procédé de rapport d'un résultat de mise en œuvre de politique, système de communication par réseau et équipement
WO2013107175A1 (zh) 家庭网络设备的控制方法及装置
WO2018121584A1 (zh) 一种数据流传输方法、装置、相关设备及存储介质
US20100054124A1 (en) Message transfer apparatus, output method, and computer program product
WO2020141544A1 (en) Multi-unicast discovery of devices on a network
CN107332894B (zh) 直播方法、装置及系统、服务器、存储介质
JP2012533959A (ja) マルチキャスト対応ルータにおいて効果的なホスト・マネジメント・プロトコル
CN104584514B (zh) 用于在通信网络中提供服务的设备和方法
TWI740210B (zh) 終端設備管理方法及伺服器
WO2012159287A1 (zh) 数据传输方法和设备
CN110892686B (zh) 向音频/视频接收器设备提供信息的方法和对应的装置
US8295200B2 (en) Discovering multicast routing capability of an access network
KR20050035038A (ko) 유피엔피(ＵＰｎＰ) 네트워크의 ＩＰ 주소 설정 방법
KR20210066641A (ko) Icn 시스템에서의 푸시 데이터 처리 방법 및 장치
KR20150022440A (ko) Mac 주소를 이용하는 이더넷 네트워크 장치 및 방법

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
GR01 Patent grant
GR01 Patent grant