CN113037515A - 基于hinoc系统的mac层组播数据帧的帧格式解析方法及装置 - Google Patents
基于hinoc系统的mac层组播数据帧的帧格式解析方法及装置 Download PDFInfo
- Publication number
- CN113037515A CN113037515A CN202110271550.7A CN202110271550A CN113037515A CN 113037515 A CN113037515 A CN 113037515A CN 202110271550 A CN202110271550 A CN 202110271550A CN 113037515 A CN113037515 A CN 113037515A
- Authority
- CN
- China
- Prior art keywords
- data frame
- mac layer
- multicast
- multicast data
- type
- 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.)
- Granted
Links
Images
Classifications
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/64—Addressing
- H04N21/6405—Multicasting
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种基于HINOC系统的MAC层组播数据帧的帧格式解析方法及装置,所述方法包括:根据各个HM终端设备的类型配置对应的用于对MAC层组播数据帧的帧格式进行解析的解析方式;根据当前HM终端设备的类型,采用与当前HM终端设备的类型匹配的解析方式对MAC层组播数据帧的帧格式进行解析,得到对应的解析结果,因此,本申请实施例提供的解析方法,预先根据各个HM终端设备的类型配置对应的用于对MAC层组播数据帧的帧格式进行解析的解析方式,解析方式包括与HINOC3.0HM终端设备匹配的第一解析方式和与HINOC2.0HM终端设备匹配的第二解析方式,能够做到:针对不同类型的HM终端设备进行同步且并行兼容解析MAC层组播数据帧的帧格式,最终有效地提升了帧格式的解析效率。
Description
技术领域
本发明涉及通信技术领域,特别涉及基于HINOC系统的MAC层组播数据帧的帧格式解析方法及装置。
背景技术
组播又称多目标广播、多播,是网络中使用的一种传输方式。它允许把所发消息传送给所有可能目的地中的一个经过选择的子集,即向明确指出的多种地址输送信息。是一种在一个发送者和多个接收者之间进行通信的方法。组播的一个重要应用是传输视频节目,即视频节目服务器将采用组播技术向点播了相同节目的用户组传输视频节目数据报,相比单播的传输方式,在组播传输过程中,相同节目的数据包仅需传输一份,节省了网络的传输带宽。
在以太网中,组播帧是通过目的MAC地址进行区分的,即组播帧的目的MAC地址高24比特总是0x01005E,第25比特总是为0。在IP层,组播报文的目的IP为224.0.0.0–239.255.255.255。同时,TCP/IP协议组定义了IGMP协议。IGMP协议负责组播成员管理的协议,用来在主机和与其直接相邻的组播路由器之间建立、维护组播组成员关系。
高性能同轴电缆通信系统(HINOC)是一种基于同轴电缆的宽带通信系统。其中,HINOC2.0技术在国内外得到了广泛应用,可以在128MHz的通信带宽内提供千兆接入能力。HINOC2.0为二层传输网络,包括MAC层和物理层两部分。MAC负责对接收到以太网帧按照HINOC2.0协议重新组帧,物理层负责对HINOC2.0 MAC层数据帧进行调制发送。HINOC2.0协议作为以太网帧的二层透传协议,对组播业务的转发过程并未做定义。在实际的芯片和设备实现过程中,HINOC2.0局端设备(HB)和终端设备(HM)根据IGMP协议建立组播转发表,组播转发表定义了需要转发的组播MAC地址。HB将需要转发的组播帧按照HINOC2.0的数据帧进行重新组帧并通过广播时隙进行发送;HM接收HINOC2.0广播时隙,解调出组播帧,并根据HM本地的组播转发表,确定是否向下转发以及转发到哪些以太网端口。
现有的基于HINOC系统中的MAC层组播数据帧的帧格式解析方法,需要采用不同的方法分别进行解析,无法做到针对不同类型的HM终端设备,例如,HINOC3.0 HM终端设备、HINOC2.0 HM终端设备进行同步且并行兼容解析,因此,造成对MAC层组播数据帧的帧格式的解析效率较低。
发明内容
本申请实施例提供了一种基于HINOC系统的MAC层组播数据帧的帧格式解析方法及装置。为了对披露的实施例的一些方面有一个基本的理解,下面给出了简单的概括。该概括部分不是泛泛评述,也不是要确定关键/重要组成元素或描绘这些实施例的保护范围。其唯一目的是用简单的形式呈现一些概念,以此作为后面的详细说明的序言。
第一方面,本申请实施例提供了一种基于HINOC系统的MAC层组播数据帧的帧格式解析方法,所述方法包括:
获取与HB局端进行通信的各个HM终端设备的类型信息和所述MAC层组播数据帧;
对所述类型信息进行解析,得到与所述HB局端进行通信的各个HM终端设备的类型;
根据各个HM终端设备的类型配置对应的用于对所述MAC层组播数据帧的帧格式进行解析的解析方式,所述解析方式包括与HINOC3.0 HM终端设备匹配的第一解析方式和与HINOC2.0 HM终端设备匹配的第二解析方式;
根据当前HM终端设备的类型,采用与当前HM终端设备的类型匹配的解析方式对所述MAC层组播数据帧的帧格式进行解析,得到对应的解析结果。
在一种实施方式中,所述根据当前HM终端设备的类型,采用与当前HM终端设备的类型匹配的解析方式对所述MAC层组播数据帧帧格式进行解析包括:
若当前HM终端设备的类型为HINOC3.0HM终端设备,则采用所述第一解析方式对所述MAC层组播数据帧的帧格式进行解析,得到第一解析结果;或者,
若当前HM终端设备的类型为HINOC2.0 HM终端设备,则采用所述第二解析方式对所述MAC层组播数据帧的帧格式进行解析,得到第二解析结果。
在一种实施方式中,所述第一解析方式包括对扩展信息子帧的中的序号字段进行解析的方式和对扩展信息子帧中的组播成员掩码字段进行解析的方式,所述若当前HM终端设备的类型为HINOC3.0 HM终端设备,则采用所述第一解析方式对所述MAC层组播数据帧的帧格式进行解析包括:
若当前HM终端设备的类型为HINOC3.0 HM终端设备,则对所述扩展信息子帧的所述序号字段进行解析,以及对所述扩展信息子帧的所述组播成员掩码字段进行解析。
在一种实施方式中,所述方法还包括:
对接收到的组播以太网帧按照HINOC2.0 MAC层数据帧格式进行组帧,并且将数据帧首部中的扩展帧头标志置1以及将扩展帧头中的扩展信息子帧标志置1,以使得每个MAC层组播数据帧均携带对应的一个扩展信息子帧。
在一种实施方式中,所述序号字段采用第一TLV编码字段格式进行编码,所述第一TLV编码字段格式包括与所述序号字段对应的第一类型域、第一长度域和第一值域,所述第一类型域根据所需协议进行配置,所述第一长度域的取值为2字节或4字节,所述第一值域为2字节或4字节的计数值,且每当组帧生成一个属于该组播流的HINOC组播数据帧时,该序号加1。
在一种实施方式中,所述组播成员掩码字段采用第二TLV编码字段格式进行编码,所述第二TLV编码字段格式包括与所述组播成员掩码字段对应的第二类型域、第二长度域和第二值域,所述第二类型域根据所需协议进行配置,所述第二长度域取值为8,所述第二值域为预设长度比特的掩码。
在一种实施方式中,所述方法还包括:
获取所述第二值域和第一预设条件,所述第一预设条件包括:若所述掩码中的任意一个位置的比特数标识为1,则该位置对应的HM终端设备需要接收所述MAC层组播数据帧,若所述掩码中的任意一个位置的比特数标识为0,则该位置对应的HM终端设备不需要接收所述MAC层组播数据帧;
根据所述第一预设条件和所述第二值域,判断出与所述HB局端进行通信的各个HM终端设备中需要接收所述MAC层组播数据帧的第一HM终端设备集合,以及不需要接收所述MAC层组播数据帧的第二HM终端设备集合。
在一种实施方式中,所述方法还包括:
获取由预设格式的协议生成的组播转发表、与所述HB局端进行通信的各个HM终端设备的信道绑定表和第二预设条件,所述第二预设条件包括:所述组播成员掩码字段指示的HM终端设备是所述组播转发表中该组播流的接收成员,所述组播成员掩码字段指示的各个HM终端设备均绑定了当前组播数据帧的传输信道,同一个组播数据帧在多个传输信道多次发送时,将HM终端设备配置成任意一个HM终端设备最多被一个传输信道上的组播成员掩码字段指示为有效;
根据所述组播转发表、所述信道绑定表和所述第二预设条件,生成所述组播成员掩码字段。
在一种实施方式中,所述预设格式的协议包括IGMP协议或MLD协议,所述IGMP协议包括IPv4网络中的IGMPv1、IGMPv2或IGMPv3协议版本,所述MLD协议包括IPv6网络中的MLDv1和MLDv2版本。
第二方面,本申请实施例提供了一种基于HINOC系统的MAC层组播数据帧的帧格式解析装置,所述装置包括:
获取模块,用于获取与HB局端进行通信的各个HM终端设备的类型信息和所述MAC层组播数据帧;
第一解析模块,用于对所述获取模块获取的所述类型信息进行解析,得到与所述HB局端进行通信的各个HM终端设备的类型;
配置模块,用于根据所述第一解析模块解析出的各个HM终端设备的类型配置对应的用于对所述获取模块获取的所述MAC层组播数据帧的帧格式进行解析的解析方式,所述解析方式包括与HINOC3.0 HM终端设备匹配的第一解析方式和与HINOC2.0 HM终端设备匹配的第二解析方式;
第二解析模块,用于根据所述第一解析模块解析出的当前HM终端设备的类型,采用与所述配置模块配置出的当前HM终端设备的类型匹配的解析方式对所述获取模块获取的所述MAC层组播数据帧的帧格式进行解析,得到对应的解析结果。
本申请实施例提供的技术方案可以包括以下有益效果:
在本申请实施例中,获取与HB局端进行通信的各个HM终端设备的类型信息和MAC层组播数据帧;对类型信息进行解析,得到与HB局端进行通信的各个HM终端设备的类型;根据各个HM终端设备的类型配置对应的用于对MAC层组播数据帧的帧格式进行解析的解析方式,解析方式包括与HINOC3.0 HM终端设备匹配的第一解析方式和与HINOC2.0HM终端设备匹配的第二解析方式;根据当前HM终端设备的类型,采用与当前HM终端设备的类型匹配的解析方式对MAC层组播数据帧的帧格式进行解析,得到对应的解析结果,因此,本申请实施例提供的解析方法,预先根据各个HM终端设备的类型配置对应的用于对MAC层组播数据帧的帧格式进行解析的解析方式,解析方式包括与HINOC3.0 HM终端设备匹配的第一解析方式和与HINOC2.0 HM终端设备匹配的第二解析方式,由于该解析方法不仅适用于通过单信道与HB局端进行通信的HINOC2.0 HM终端设备,还适用于通过多信道与HB局端进行通信的HINOC3.0 HM终端设备,因此,能够做到:针对不同类型的HM终端设备,例如,HINOC3.0 HM终端设备、HINOC2.0 HM终端设备进行同步且并行兼容解析MAC层组播数据帧的帧格式,这样,最终有效地提升了对MAC层组播数据帧的帧格式的解析效率。应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本发明。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本发明的实施例,并与说明书一起用于解释本发明的原理。
图1是本申请实施例提供的一种基于HINOC系统的MAC层组播数据帧的帧格式解析方法的流程示意图;
图2本申请实施例提供的HINOC组播业务场景的一示意图;
图3是本申请实施例提供的一种应用场景下的HINOC MAC层组播数据帧的帧格式的示意图;
图4是HINOC3.0信道绑定系统的信号收发流程示意图;
图5是本申请实施例提供的HINOC组播业务场景的另一示意图;
图6是本申请实施例提供的一种基于HINOC系统的MAC层组播数据帧的帧格式解析装置的结构示意图。
具体实施方式
以下描述和附图充分地示出本发明的具体实施方案,以使本领域的技术人员能够实践它们。
应当明确,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例,都属于本发明保护的范围。
基于现有的解析方法,对MAC层组播数据帧的帧格式的解析效率较低的问题,为此,本申请提供了一种基于HINOC系统的MAC层组播数据帧的帧格式解析方法及装置,以解决上述相关技术问题中存在的问题。本申请提供的技术方案中,获取与HB局端进行通信的各个HM终端设备的类型信息和MAC层组播数据帧;对类型信息进行解析,得到与HB局端进行通信的各个HM终端设备的类型;根据各个HM终端设备的类型配置对应的用于对MAC层组播数据帧的帧格式进行解析的解析方式,解析方式包括与HINOC3.0 HM终端设备匹配的第一解析方式和与HINOC2.0 HM终端设备匹配的第二解析方式;根据当前HM终端设备的类型,采用与当前HM终端设备的类型匹配的解析方式对MAC层组播数据帧的帧格式进行解析,得到对应的解析结果,因此,本申请实施例提供的解析方法,预先根据各个HM终端设备的类型配置对应的用于对MAC层组播数据帧的帧格式进行解析的解析方式,解析方式包括与HINOC3.0 HM终端设备匹配的第一解析方式和与HINOC2.0 HM终端设备匹配的第二解析方式,由于该解析方法不仅适用于通过单信道与HB局端进行通信的HINOC2.0 HM终端设备,还适用于通过多信道与HB局端进行通信的HINOC3.0 HM终端设备,因此,能够做到:针对不同类型的HM终端设备,例如,HINOC3.0 HM终端设备、HINOC2.0 HM终端设备进行同步且并行兼容解析MAC层组播数据帧的帧格式,这样,最终有效地提升了对MAC层组播数据帧的帧格式的解析效率,下面采用示例性的实施例进行详细说明。
下面将结合图1至图5,对本申请实施例提供的一种基于HINOC系统的MAC层组播数据帧的帧格式解析方法进行详细介绍。
如图1所示,是本申请实施例提供的一种基于HINOC系统的MAC层组播数据帧的帧格式解析方法的流程示意图;如图1所示,本申请实施例的解析方法可以包括以下步骤:
S102,获取与HB局端进行通信的各个HM终端设备的类型信息和MAC层组播数据帧。
如图2所示,是本申请实施例提供的HINOC组播业务场景的一示意图。
如图2所示,给出了一个组播业务场景。在该场景中,HINOC3.0 HB局端设备进行了多个传输信道的绑定,不仅能够通过单信道进行组播业务,例如,仅仅通过信道编号为#2的单信道进行组播业务,其中,HM5终端设备为HINOC2.0 HM终端设备;还可以通过多信道进行组播业务,传输信道编号分别为#1、#2、#3和#4。共有5个HM接入了该网络,分别为HM1、HM2、HM3、HM4和HM5,每个HM下面各有1个PC,每个PC点播了位于HB上游Server中的不同IPv4组播业务。
正如上述图2所示,本申请实施例提供的解析方法不仅适用于通过单信道与HB局端进行通信的HINOC2.0 HM终端设备,还适用于通过多信道与HB局端进行通信的HINOC3.0HM终端设备,因此,能够做到:针对不同类型的HM终端设备,例如,HINOC3.0 HM终端设备、HINOC2.0 HM终端设备进行同步且并行兼容解析MAC层组播数据帧的帧格式,这样,最终有效地提升了对MAC层组播数据帧的帧格式的解析效率。
S104,对类型信息进行解析,得到与HB局端进行通信的各个HM终端设备的类型;
在本申请实施例中,与HB局端进行通信的各个HM终端设备的类型不仅包括HINOC3.0HM终端设备,还包括HINOC2.0 HM终端设备。
S106,根据各个HM终端设备的类型配置对应的用于对MAC层组播数据帧的帧格式进行解析的解析方式,解析方式包括与HINOC3.0 HM终端设备匹配的第一解析方式和与HINOC2.0 HM终端设备匹配的第二解析方式。
在本申请实施例中,与HINOC3.0 HM终端设备匹配的第一解析方式包括对扩展信息子帧的中的序号字段进行解析的方式和对扩展信息子帧中的组播成员掩码字段进行解析的方式。这样,若当前HM终端设备的类型为HINOC3.0 HM终端设备,则采用第一解析方式对MAC层组播数据帧的帧格式进行解析的过程不仅包括对扩展信息滋镇的序号字段进行解析的解析过程,还包括对扩展信息子帧的组播成员掩码字段进行解析的解析过程。
与HINOC3.0 HM终端设备匹配的第一解析方式对应的帧格式具有如图2所示的帧格式,而与HINOC2.0 HM终端设备匹配的第二解析方式对应的帧格式为HINOC2.0 MAC层数据帧格式,该格式为常规格式,在此不再赘述。
如图3所示,是本申请实施例提供的一种应用场景下的HINOC MAC层组播数据帧的帧格式的示意图。如图2所示的帧格式是对应于第一解析方法的帧格式。
如图3所示,本申请实施例提供的对应于第一解析方法的HINOC MAC层组播数据帧格式包括以下特征:
1)自上层的组播业务按照HINOC2.0 MAC层数据帧的格式进行组帧。
基于HINOC2.0 MAC层数据帧的组播组帧方式能够体现协议演进的一致性,并且有利于与原HINOC2.0 HM兼容,即:HINOC2.0 HM设备不支持HINOC3.0中的多信道绑定,HINOC2.0 HM在接收HINOC3.0 HB发送的MAC层组播数据帧时将EISF扩展信息子帧忽略,即可完成正常的组播数据接收。
2)将数据帧首部中的扩展帧头标志(EH_FLAG)置1和扩展帧头中的扩展信息子帧标志(EISF_FLAG)置1;这样,使得每个MAC层组播数据帧均将携带一个扩展信息子帧(EISF),进而可以在EISF中携带更多的控制信息。
3)在EISF扩展信息子帧中增加序号字段。
序号字段采用TLV编码字段格式(类型域-长度域-值域),其中,TLV编码字段的类型域可根据协议需要进行设定;TLV编码字段的长度域取值为2字节或4字节;TLV编码字段的值域为2字节或4字节的计数值,每当组帧生成一个属于该组播流的HINOC组播数据帧该序号加1。
通过增加序号字段,能够做到:对属于同一条组播流的组播数据帧进行编号,编号大小代表了组播数据帧在组播流中的先后顺序。这样就可以在多个并行的物理层传输信道中分别转发该组播流的一部分,提高了该组播流的传输带宽,同时无需担心组播流乱序到达HM接收机,因为HM接收机可以根据组播数据帧EISF中的序号字段对乱序的组播数据帧进行重排序。
4)在EISF扩展信息子帧中组播成员掩码字段。
组播成员掩码字段采用TLV编码字段格式(类型域-长度域-值域),其中,TLV编码字段的类型域可根据协议需要进行设定;TLV编码字段的长度域取值为8;TLV编码字段的值域为长度64比特的掩码,分别代表64个HM是否需要接收该组播数据帧,比特1代表需要接收,比特0代表不需要接收。
组播成员掩码字段由IGMP或MLD协议生成的组播转发表以及各个HM的信道绑定表联合决定,应满足以下约束条件:组播成员掩码字段指示的HM是组播转发表中该组播流的接收成员;组播成员掩码字段指示的HM均绑定了当前组播数据帧的传输信道;同一个组播数据帧在多个传输信道多次发送时,应保证HM最多被一个传输信道上的组播成员掩码字段指示为有效。
通过组播成员掩码字段能够做到:每一个组播数据帧中均指明了允许接收该帧的HM,同时按照上述原则进行设计组播成员掩码,可以避免HM收到重复的组播数据帧。
综上所述,本申请实施例提供的HINOC MAC层组播数据帧格式体现了HINOC协议演进的一致性,并且有利于与原HINOC2.0 HM兼容,同时解决了多信道绑定系统中的组播数据的有序唯一接收。
在一种具体应用场景下,本申请实施例提供了一种基于HINOC系统的MAC层组播数据帧组帧格式,该格式具有以下特征,具体如下所述:
对接收到的组播以太网帧按照HINOC2.0 MAC层数据帧格式进行组帧;将数据帧首部中的扩展帧头标志(EH_FLAG)置1和扩展帧头中的扩展信息子帧标志(EISF_FLAG)置1;在扩展信息子帧(EISF)中增加序号字段和组播成员掩码字段。
进一步的,序号字段采用TLV编码字段格式(类型域-长度域-值域),其中,TLV编码字段的类型域可根据协议需要进行设定;TLV编码字段的长度域取值为2字节或4字节;TLV编码字段的值域为2字节或4字节的计数值,每当组帧生成一个属于该组播流的HINOC组播数据帧该序号加1。
进一步的,组播成员掩码字段采用TLV编码字段格式(类型域-长度域-值域),其中,TLV编码字段的类型域可根据协议需要进行设定;TLV编码字段的长度域取值为8;TLV编码字段的值域为长度64比特的掩码,分别代表64个HM是否需要接收该组播数据帧,比特1代表需要接收,比特0代表不需要接收。
进一步的,组播成员掩码字段由IGMP或MLD协议生成的组播转发表以及各个HM的信道绑定表联合决定,应满足以下约束条件:组播成员掩码字段指示的HM是组播转发表中该组播流的接收成员;组播成员掩码字段指示的HM均绑定了当前组播数据帧的传输信道;同一个组播数据帧在多个传输信道多次发送时,应保证HM最多被一个传输信道上的组播成员掩码字段指示为有效。
正如前述可知,本申请实施例提供的解析方法,提供了一种基于HINOC MAC层组播帧数据帧的帧格式,该帧格式对应于前述第一解析方法。该格式基于HINOC2.0 MAC层数据帧格式,仅仅通过扩展HINOC2.0 MAC层数据帧中的EISF,即可解决HINOC3.0信道绑定系统中的组播转发问题。
此外,在本申请实施例中,在对应于第一解析方法的组播数据帧中,由于在组播数据帧的扩展信息子帧中增加了序号字段,能够做到有序接收,有序接收是指属于同一组播IP(目的MAC地址)流内的以太帧的先后顺序不允许发生变化,这样,能够有效地解决多信道绑定系统中组播业务转发中存在的乱序问题,以及在组播数据帧的扩展信息子帧中增加了组播成员掩码字段,这样,能够有效地解决多信道绑定系统中组播业务转发中存在的重复帧的问题,避免重复组播数据帧是指HM终端不允许接收到属于同一组播IP流的多个相同的以太帧。
如图4所示,是HINOC3.0信道绑定系统的信号收发流程示意图。如图4所示,HB局端和HM终端设备由MAC介质访问控制层和PHY物理层层模块构成,其中PHY层支持多信道绑定,单个信道带宽为128MHz,为MAC层提供多个并行的MAC帧传输通道,每个PHY层信道由发送单元和接收单元组成,发送单元将MAC帧转换为射频信号,接收单元将射频信号转换为MAC帧。
由于HINOC3.0采用了信道绑定技术,为了保证多信道绑定HM可以有序接收到不重复的组播数据帧,本申请实施例提出了一种HINOC MAC层组播数据帧格式,如图3所示。HINOC MAC层组播数据帧以HINOC2.0 MAC层数据帧为基础,HINOC2.0 MAC层数据帧格式包括首部、子帧头集合、EISF、其他子帧、填充和CRC等部分。其中,EISF帧在HINOC2.0协议中的一个特殊子帧,可用于携带特殊的控制信息,这些控制信息采用TLV编码字段的形式,例如在HINOC2.0协议定义了EISF传送详细队列报告信息。
S108,根据当前HM终端设备的类型,采用与当前HM终端设备的类型匹配的解析方式对MAC层组播数据帧的帧格式进行解析,得到对应的解析结果。
在一种可能的实现方式中,根据当前HM终端设备的类型,采用与当前HM终端设备的类型匹配的解析方式对MAC层组播数据帧帧格式进行解析包括以下步骤:
若当前HM终端设备的类型为HINOC3.0HM终端设备,则采用第一解析方式对MAC层组播数据帧的帧格式进行解析,得到第一解析结果。
在本申请实施例中,第一解析方式包括对扩展信息子帧的中的序号字段进行解析的方式和对扩展信息子帧中的组播成员掩码字段进行解析的方式,若当前HM终端设备的类型为HINOC3.0 HM终端设备,则采用第一解析方式对MAC层组播数据帧的帧格式进行解析包括以下步骤:
若当前HM终端设备的类型为HINOC3.0 HM终端设备,则对扩展信息子帧的序号字段进行解析,以及对扩展信息子帧的组播成员掩码字段进行解析。
在本申请实施例中,结合上述图2所示,本申请实施例提供的解析方法还包括以下步骤:
对接收到的组播以太网帧按照HINOC2.0 MAC层数据帧格式进行组帧,并且将数据帧首部中的扩展帧头标志置1以及将扩展帧头中的扩展信息子帧标志置1,以使得每个MAC层组播数据帧均携带对应的一个扩展信息子帧。
在本申请实施例中,结合上述图2所示,序号字段采用第一TLV编码字段格式进行编码,第一TLV编码字段格式包括与序号字段对应的第一类型域、第一长度域和第一值域,第一类型域根据所需协议进行配置,第一长度域的取值为2字节或4字节,第一值域为2字节或4字节的计数值,且每当组帧生成一个属于该组播流的HINOC组播数据帧时,该序号加1。
在本申请实施例中,结合上述图2所示,组播成员掩码字段采用第二TLV编码字段格式进行编码,第二TLV编码字段格式包括与组播成员掩码字段对应的第二类型域、第二长度域和第二值域,第二类型域根据所需协议进行配置,第二长度域取值为8,第二值域为预设长度比特的掩码。
在本申请实施例中,基于HINOC系统的MAC层组播数据帧的帧格式解析方法还包括以下步骤:
获取第二值域和第一预设条件,第一预设条件包括:若掩码中的任意一个位置的比特数标识为1,则该位置对应的HM终端设备需要接收MAC层组播数据帧,若掩码中的任意一个位置的比特数标识为0,则该位置对应的HM终端设备不需要接收MAC层组播数据帧;
根据第一预设条件和第二值域,判断出与HB局端进行通信的各个HM终端设备中需要接收MAC层组播数据帧的第一HM终端设备集合,以及不需要接收MAC层组播数据帧的第二HM终端设备集合;这样,就可以精准地标识出与HB局端通信的各个HM终端设备中,哪些设备需要接收MAC层组播数据帧,并由所有需要接收MAC组播数据帧的HM终端设备组成第一HM终端设备集合;以及哪些设备并不需要接收MAC层组播数据帧,并由所有不需要接收MAC组播数据帧的HM终端设备组成第二HM终端设备集合。
在有效地区分出上述哪些HM终端设备需要接收MAC层组播数据帧时,只有确认其接收到MAC层组播数据帧时,才对其数据帧的帧格式进行解析,这样,能够有效地避免无效解析过程,大大地提升了对MAC层组播数据帧的帧格式解析效率。
结合前述图3所示,在本申请实施例中,基于HINOC系统的MAC层组播数据帧的帧格式解析方法还包括以下步骤:
获取由预设格式的协议生成的组播转发表、与HB局端进行通信的各个HM终端设备的信道绑定表和第二预设条件,第二预设条件包括:组播成员掩码字段指示的HM终端设备是组播转发表中该组播流的接收成员,组播成员掩码字段指示的各个HM终端设备均绑定了当前组播数据帧的传输信道,同一个组播数据帧在多个传输信道多次发送时,将HM终端设备配置成任意一个HM终端设备最多被一个传输信道上的组播成员掩码字段指示为有效;
根据组播转发表、信道绑定表和第二预设条件,生成组播成员掩码字段;通过第二预设条件,由于引入了组播成员掩码字段,这样,能够有效地解决多信道绑定系统中组播业务转发中的重复帧问题。
在本申请实施例中,预设格式的协议包括IGMP协议或MLD协议,IGMP协议包括IPv4网络中的IGMPv1、IGMPv2或IGMPv3协议版本,MLD协议包括IPv6网络中的MLDv1和MLDv2版本。
在一种可能的实现方式中,根据当前HM终端设备的类型,采用与当前HM终端设备的类型匹配的解析方式对MAC层组播数据帧帧格式进行解析还包括以下步骤:
若当前HM终端设备的类型为HINOC2.0 HM终端设备,则采用第二解析方式对MAC层组播数据帧的帧格式进行解析,得到第二解析结果。
在本申请实施例中,第二解析方法用来解析HINOC2.0 MAC层数据帧格式,基于该解析方法是常规方法,在此不再赘述。
如图5所示,是本申请实施例提供的HINOC组播业务场景的另一示意图。如图5给出了一个组播业务场景。在该场景中,HINOC3.0 HB局端进行了4个传输信道的绑定,传输信道编号分别为#1、#2、#3和#4。共有4个HM终端设备接入了该网络,分别为HM1、HM2、HM3和HM4,每个HM终端设备下面各有1个PC,每个PC点播了位于HB上游Server中的不同IPv4组播业务。在如图5所示的组播业务场景中,基于HINOC系统进行组播业务转发的步骤具体如下所述:
步骤1)HB使用IGMP或MLD协议控制每个组播转发表的组播接收成员加入或删除;IGMP或MLD协议包括IPv4网络中的IGMPv1、IGMPv2或IGMPv3协议版本,以及IPv6网络中的MLDv1和MLDv2版本。在本示例中,组播业务为IPv4业务,顾采用IGMP协议。根据图4中所示的PC点播情况,HB通过IGMP建立的组播转发表为如下表1:
组播IP | 组播接收成员 |
224.0.1.100 | HM1、HM2、HM3 |
224.0.1.101 | HM1、HM4 |
224.0.1.102 | HM2 |
224.0.1.103 | HM3、HM4 |
表1
步骤2)根据组播转发表中每个组播IP流的接收成员集合,查找信道绑定表,计算每个组播IP流的转发信道集合和每个转发信道上的组播成员掩码;不同HM绑定的信道集合可能不同,图4中的4个HM的信道绑定表如下表2所示:
HM | 绑定的信道集合 |
HM1 | #1、#2、#3、#4 |
HM2 | #1、#2 |
HM3 | #3、#4 |
HM4 | #2、#4 |
表2
224.0.1.100的接收成员为HM1、HM2和HM3,考虑到HM1、HM2和HM3的信道绑定集合且为了保证三个HM均能接收到224.0.1.100业务,则224.0.1.100业务至少需要发送两次,这里我们假定分别在信道#1和#3上分别传输224.0.1.100业务。
224.0.1.101的接收成员为HM1和HM2,则可以选择在HM1和HM2的公共信道{#1,#2}上进行传输,这里可以选择单独使用信道#1或单独使用信道#2进行传输该组播IP流,或同时使用信道{#1,#2}进行分流传输,所谓的联合传输是指将该组播IP流拆分为两个子流,信道#1和#2各传输一条支流。在本示例中,我们选用信道#2进行传输224.0.1.100业务。
224.0.1.102的接收成员为HM2,与224.0.1.101的情况类似,可以从信道#1和#2中选择一个信道进行独立传输或两个信道进行分流传输。在本示例中,我们选用信道#1和#2进行分流传输。
224.0.1.103的接收成员为HM3和HM4,两个HM仅有一个公共信道,即信道#4,则选择在公共信道上传输一次该组播IP流即可。
通过以上的分析,可以得到每个组播IP流的转发信道集合,更新组播转发表,如下表3所示:
表3
得到每个组播IP流的转发信道集合后,需要进一步计算每个转发信道上组播成员掩码,用来指示在每个信道上哪些HM可以解调该组播数据帧。
224.0.1.100组播流在信道#1和#3上转发两次,其中HM2只能在信道#1上接收组播数据帧,HM3在信道#3上接收组播数据帧,而HM1可以在信道#1或#3接收数据,为了避免每个HM接收到多个相同的组播数据帧,HM1只能选择其中一个信道进行接收数据。这里我们选择HM1从信道#1上接收数据。
224.0.101组播流在信道#2转发,HM1和HM4均需要接收。
224.0.102组播流在信道#1和#2上分流传输,HM2需要同时接收两个信道上的子流,并按照组播数据帧中的序号字段进行重排序。
224.0.103组播流在信道#4转发,HM3和HM4均需要接收。
通过以上的分析,可以得到每个组播IP流在每个转发信道上的组播成员掩码,更新组播转发表,如下表4所示:
表4
其中,每个信道的组播成员掩码长度为64比特,本示例中,组播成员掩码的最左侧代表HM1的指示位,最右侧代表HM64的指示位,比特“1”代表需要接收,“0”代表不需要接收。
在本申请实施例中,组播转发表的每个条目由组播IP、接收成员集合、转发信道集合以及组播成员掩码组成,其特征在于,组播IP为该组播转发表的索引值。实现过程中,组播转发表可以由一张表构成,也可以由多张子表构成:由一张表构成是指组播转发表的每个条目由组播IP、接收成员集合、转发信道集合以及组播成员掩码组成;由多张子表构成是指接收成员集合、转发信道集合以及组播成员掩码可以分别存在多个子表中,各个子表均以组播IP为索引。
步骤3)接收到组播数据帧时,查找组播转发表,若该组播数据帧的转发信道集合为非空,则对该组播数据帧按照上述提供的HINOC组播数据帧格式进行组帧形成HINOC组播数据帧,其中,组播成员掩码字段的值域填为全零值;
步骤4)将HINOC组播数据帧依次发送到转发信道集合中的每一个传输信道中,且在发送之前将HINOC组播数据帧中的组播成员掩码字段的值域修改为转发信道对应的组播成员掩码。
在本示例中,224.0.1.100组播流分别转发到信道#1和#3,且转发到信道#1时,该组播流组帧形成的组播数据帧中的组播成员掩码字段填充为“11000000…0”,转发到信道#3时,组播成员掩码字段填充为“00100000…0”。
224.0.1.101组播流需要转发到信道#2,且在转发时组播数据帧中的组播成员掩码填充为“10010000…0”。
224.0.1.102组播流需要分流转发到信道#1和信道#2,且在转发时,每个信道上的组播数据帧的组播成员掩码均为“01000000…0”。
224.0.1.103组播流需要转发到信道#4,且在转发时组播数据帧中的组播成员掩码填充为“00110000…0”。
在本申请实施例中,获取与HB局端进行通信的各个HM终端设备的类型信息和MAC层组播数据帧;对类型信息进行解析,得到与HB局端进行通信的各个HM终端设备的类型;根据各个HM终端设备的类型配置对应的用于对MAC层组播数据帧的帧格式进行解析的解析方式,解析方式包括与HINOC3.0 HM终端设备匹配的第一解析方式和与HINOC2.0 HM终端设备匹配的第二解析方式;根据当前HM终端设备的类型,采用与当前HM终端设备的类型匹配的解析方式对MAC层组播数据帧的帧格式进行解析,得到对应的解析结果,因此,本申请实施例提供的解析方法,预先根据各个HM终端设备的类型配置对应的用于对MAC层组播数据帧的帧格式进行解析的解析方式,解析方式包括与HINOC3.0 HM终端设备匹配的第一解析方式和与HINOC2.0 HM终端设备匹配的第二解析方式,由于该解析方法不仅适用于通过单信道与HB局端进行通信的HINOC2.0 HM终端设备,还适用于通过多信道与HB局端进行通信的HINOC3.0 HM终端设备,因此,能够做到:针对不同类型的HM终端设备,例如,HINOC3.0 HM终端设备、HINOC2.0 HM终端设备进行同步且并行兼容解析MAC层组播数据帧的帧格式,这样,最终有效地提升了对MAC层组播数据帧的帧格式的解析效率。
下述为本发明基于HINOC系统的MAC层组播数据帧的帧格式解析装置实施例,可以用于执行本发明基于HINOC系统的MAC层组播数据帧的帧格式解析方法实施例。对于本发明基于HINOC系统的MAC层组播数据帧的帧格式解析装置实施例中未披露的细节,请参照本发明基于HINOC系统的MAC层组播数据帧的帧格式解析方法实施例。
请参见图6,其示出了本发明一个示例性实施例提供的基于HINOC系统的MAC层组播数据帧的帧格式解析装置的结构示意图。该基于HINOC系统的MAC层组播数据帧的帧格式解析装置可以通过软件、硬件或者两者的结合实现成为终端的全部或一部分。该基于HINOC系统的MAC层组播数据帧的帧格式解析装置包括获取模块10、第一解析模块20、配置模块30和第二解析模块40。
具体而言,获取模块10,用于获取与HB局端进行通信的各个HM终端设备的类型信息和MAC层组播数据帧;
第一解析模块20,用于对获取模块10获取的类型信息进行解析,得到与HB局端进行通信的各个HM终端设备的类型;
配置模块30,用于根据第一解析模块20解析出的各个HM终端设备的类型配置对应的用于对获取模块10获取的MAC层组播数据帧的帧格式进行解析的解析方式,解析方式包括与HINOC3.0 HM终端设备匹配的第一解析方式和与HINOC2.0 HM终端设备匹配的第二解析方式;
第二解析模块40,用于根据第一解析模块20解析出的当前HM终端设备的类型,采用与配置模块30配置出的当前HM终端设备的类型匹配的解析方式对获取模块10获取的MAC层组播数据帧的帧格式进行解析,得到对应的解析结果。
可选的,第二解析模块40用于:
若当前HM终端设备的类型为HINOC3.0HM终端设备,则采用第一解析方式对MAC层组播数据帧的帧格式进行解析,得到第一解析结果;或者,
若当前HM终端设备的类型为HINOC2.0 HM终端设备,则采用第二解析方式对MAC层组播数据帧的帧格式进行解析,得到第二解析结果。
可选的,第一解析方式包括对扩展信息子帧的中的序号字段进行解析的方式和对扩展信息子帧中的组播成员掩码字段进行解析的方式,第二解析模块40具体用于:
若当前HM终端设备的类型为HINOC3.0 HM终端设备,则对扩展信息子帧的序号字段进行解析,以及对扩展信息子帧的组播成员掩码字段进行解析。
可选的,所述装置还包括:
组帧模块(在图6中未示出),用于对接收到的组播以太网帧按照HINOC2.0MAC层数据帧格式进行组帧;
配置模块30还用于:将数据帧首部中的扩展帧头标志置1以及将扩展帧头中的扩展信息子帧标志置1,以使得每个MAC层组播数据帧均携带对应的一个扩展信息子帧。
可选的,序号字段采用第一TLV编码字段格式进行编码,第一TLV编码字段格式包括与序号字段对应的第一类型域、第一长度域和第一值域,第一类型域根据所需协议进行配置,第一长度域的取值为2字节或4字节,第一值域为2字节或4字节的计数值,且每当组帧生成一个属于该组播流的HINOC组播数据帧时,该序号加1。
可选的,组播成员掩码字段采用第二TLV编码字段格式进行编码,第二TLV编码字段格式包括与组播成员掩码字段对应的第二类型域、第二长度域和第二值域,第二类型域根据所需协议进行配置,第二长度域取值为8,第二值域为预设长度比特的掩码。
可选的,获取模块10还用于:获取第二值域和第一预设条件,获取模块10获取的第一预设条件包括:若掩码中的任意一个位置的比特数标识为1,则该位置对应的HM终端设备需要接收MAC层组播数据帧,若掩码中的任意一个位置的比特数标识为0,则该位置对应的HM终端设备不需要接收MAC层组播数据帧;
所述装置还包括:
判断模块(在图6中未示出),用于根据获取模块10获取的第一预设条件和第二值域,判断出与HB局端进行通信的各个HM终端设备中需要接收MAC层组播数据帧的第一HM终端设备集合,以及不需要接收MAC层组播数据帧的第二HM终端设备集合。
可选的,获取模块10还用于:
获取由预设格式的协议生成的组播转发表、与HB局端进行通信的各个HM终端设备的信道绑定表和第二预设条件,获取模块10获取的第二预设条件包括:组播成员掩码字段指示的HM终端设备是组播转发表中该组播流的接收成员,组播成员掩码字段指示的各个HM终端设备均绑定了当前组播数据帧的传输信道,同一个组播数据帧在多个传输信道多次发送时,将HM终端设备配置成任意一个HM终端设备最多被一个传输信道上的组播成员掩码字段指示为有效;
所述装置还包括:生成模块(在图6中未示出),用于根据获取模块10获取的组播转发表、信道绑定表和第二预设条件,生成组播成员掩码字段。
可选的,预设格式的协议包括IGMP协议或MLD协议,IGMP协议包括IPv4网络中的IGMPv1、IGMPv2或IGMPv3协议版本,MLD协议包括IPv6网络中的MLDv1和MLDv2版本。
需要说明的是,上述实施例提供的基于HINOC系统的MAC层组播数据帧的帧格式解析装置在执行基于HINOC系统的MAC层组播数据帧的帧格式解析方法时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将设备的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的基于HINOC系统的MAC层组播数据帧的帧格式解析装置与基于HINOC系统的MAC层组播数据帧的帧格式解析方法实施例属于同一构思,其体现实现过程详见基于HINOC系统的MAC层组播数据帧的帧格式解析方法实施例,这里不再赘述。
在本申请实施例中,获取模块用于获取与HB局端进行通信的各个HM终端设备的类型信息和MAC层组播数据帧;第一解析模块用于对获取模块获取的类型信息进行解析,得到与HB局端进行通信的各个HM终端设备的类型;配置模块用于根据第一解析模块解析出的各个HM终端设备的类型配置对应的用于对获取模块获取的MAC层组播数据帧的帧格式进行解析的解析方式,解析方式包括与HINOC3.0 HM终端设备匹配的第一解析方式和与HINOC2.0HM终端设备匹配的第二解析方式;以及第二解析模块用于根据第一解析模块解析出的当前HM终端设备的类型,采用与配置模块配置出的当前HM终端设备的类型匹配的解析方式对获取模块获取的MAC层组播数据帧的帧格式进行解析,得到对应的解析结果,因此,本申请实施例提供的解析装置,预先根据各个HM终端设备的类型配置对应的用于对MAC层组播数据帧的帧格式进行解析的解析方式,解析方式包括与HINOC3.0 HM终端设备匹配的第一解析方式和与HINOC2.0 HM终端设备匹配的第二解析方式,由于该解析方法不仅适用于通过单信道与HB局端进行通信的HINOC2.0 HM终端设备,还适用于通过多信道与HB局端进行通信的HINOC3.0 HM终端设备,因此,能够做到:针对不同类型的HM终端设备,例如,HINOC3.0 HM终端设备、HINOC2.0 HM终端设备进行同步且并行兼容解析MAC层组播数据帧的帧格式,这样,最终有效地提升了对MAC层组播数据帧的帧格式的解析效率。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,该计算机程序可存储于一计算机可读取存储介质中,该程序在执行时,可包括如上述各方法的实施例的流程。其中,前述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory,ROM)等非易失性存储介质,或随机存储记忆体(Random Access Memory,RAM)等。
以上所述实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本发明的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对本发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干变形和改进,这些都属于本发明的保护范围。因此,本发明专利的保护范围应以所附权利要求为准。
Claims (10)
1.一种基于HINOC系统的MAC层组播数据帧的帧格式解析方法,其特征在于,所述方法包括:
获取与HB局端进行通信的各个HM终端设备的类型信息和所述MAC层组播数据帧;
对所述类型信息进行解析,得到与所述HB局端进行通信的各个HM终端设备的类型;
根据各个HM终端设备的类型配置对应的用于对所述MAC层组播数据帧的帧格式进行解析的解析方式,所述解析方式包括与HINOC3.0HM终端设备匹配的第一解析方式和与HINOC2.0HM终端设备匹配的第二解析方式;
根据当前HM终端设备的类型,采用与当前HM终端设备的类型匹配的解析方式对所述MAC层组播数据帧的帧格式进行解析,得到对应的解析结果。
2.根据权利要求1所述的方法,其特征在于,所述根据当前HM终端设备的类型,采用与当前HM终端设备的类型匹配的解析方式对所述MAC层组播数据帧帧格式进行解析包括:
若当前HM终端设备的类型为HINOC3.0HM终端设备,则采用所述第一解析方式对所述MAC层组播数据帧的帧格式进行解析,得到第一解析结果;或者,
若当前HM终端设备的类型为HINOC2.0HM终端设备,则采用所述第二解析方式对所述MAC层组播数据帧的帧格式进行解析,得到第二解析结果。
3.根据权利要求2所述的方法,其特征在于,所述第一解析方式包括对扩展信息子帧的中的序号字段进行解析的方式和对扩展信息子帧中的组播成员掩码字段进行解析的方式,所述若当前HM终端设备的类型为HINOC3.0HM终端设备,则采用所述第一解析方式对所述MAC层组播数据帧的帧格式进行解析包括:
若当前HM终端设备的类型为HINOC3.0HM终端设备,则对所述扩展信息子帧的所述序号字段进行解析,以及对所述扩展信息子帧的所述组播成员掩码字段进行解析。
4.根据权利要求3所述的方法,其特征在于,所述方法还包括:
对接收到的组播以太网帧按照HINOC2.0MAC层数据帧格式进行组帧,并且将数据帧首部中的扩展帧头标志置1以及将扩展帧头中的扩展信息子帧标志置1,以使得每个MAC层组播数据帧均携带对应的一个扩展信息子帧。
5.根据权利要求3所述的方法,其特征在于,
所述序号字段采用第一TLV编码字段格式进行编码,所述第一TLV编码字段格式包括与所述序号字段对应的第一类型域、第一长度域和第一值域,所述第一类型域根据所需协议进行配置,所述第一长度域的取值为2字节或4字节,所述第一值域为2字节或4字节的计数值,且每当组帧生成一个属于该组播流的HINOC组播数据帧时,该序号加1。
6.根据权利要求3所述的方法,其特征在于,
所述组播成员掩码字段采用第二TLV编码字段格式进行编码,所述第二TLV编码字段格式包括与所述组播成员掩码字段对应的第二类型域、第二长度域和第二值域,所述第二类型域根据所需协议进行配置,所述第二长度域取值为8,所述第二值域为预设长度比特的掩码。
7.根据权利要求6所述的方法,其特征在于,所述方法还包括:
获取所述第二值域和第一预设条件,所述第一预设条件包括:若所述掩码中的任意一个位置的比特数标识为1,则该位置对应的HM终端设备需要接收所述MAC层组播数据帧,若所述掩码中的任意一个位置的比特数标识为0,则该位置对应的HM终端设备不需要接收所述MAC层组播数据帧;
根据所述第一预设条件和所述第二值域,判断出与所述HB局端进行通信的各个HM终端设备中需要接收所述MAC层组播数据帧的第一HM终端设备集合,以及不需要接收所述MAC层组播数据帧的第二HM终端设备集合。
8.根据权利要求3所述的方法,其特征在于,所述方法还包括:
获取由预设格式的协议生成的组播转发表、与所述HB局端进行通信的各个HM终端设备的信道绑定表和第二预设条件,所述第二预设条件包括:所述组播成员掩码字段指示的HM终端设备是所述组播转发表中该组播流的接收成员,所述组播成员掩码字段指示的各个HM终端设备均绑定了当前组播数据帧的传输信道,同一个组播数据帧在多个传输信道多次发送时,将HM终端设备配置成任意一个HM终端设备最多被一个传输信道上的组播成员掩码字段指示为有效;
根据所述组播转发表、所述信道绑定表和所述第二预设条件,生成所述组播成员掩码字段。
9.根据权利要求8所述的方法,其特征在于,
所述预设格式的协议包括IGMP协议或MLD协议,所述IGMP协议包括IPv4网络中的IGMPv1、IGMPv2或IGMPv3协议版本,所述MLD协议包括IPv6网络中的MLDv1和MLDv2版本。
10.一种基于HINOC系统的MAC层组播数据帧的帧格式解析装置,其特征在于,所述装置包括:
获取模块,用于获取与HB局端进行通信的各个HM终端设备的类型信息和所述MAC层组播数据帧;
第一解析模块,用于对所述获取模块获取的所述类型信息进行解析,得到与所述HB局端进行通信的各个HM终端设备的类型;
配置模块,用于根据所述第一解析模块解析出的各个HM终端设备的类型配置对应的用于对所述获取模块获取的所述MAC层组播数据帧的帧格式进行解析的解析方式,所述解析方式包括与HINOC3.0HM终端设备匹配的第一解析方式和与HINOC2.0HM终端设备匹配的第二解析方式;
第二解析模块,用于根据所述第一解析模块解析出的当前HM终端设备的类型,采用与所述配置模块配置出的当前HM终端设备的类型匹配的解析方式对所述获取模块获取的所述MAC层组播数据帧的帧格式进行解析,得到对应的解析结果。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110271550.7A CN113037515B (zh) | 2021-03-12 | 2021-03-12 | 基于hinoc系统的mac层组播数据帧的帧格式解析方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110271550.7A CN113037515B (zh) | 2021-03-12 | 2021-03-12 | 基于hinoc系统的mac层组播数据帧的帧格式解析方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113037515A true CN113037515A (zh) | 2021-06-25 |
CN113037515B CN113037515B (zh) | 2022-11-04 |
Family
ID=76468574
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110271550.7A Active CN113037515B (zh) | 2021-03-12 | 2021-03-12 | 基于hinoc系统的mac层组播数据帧的帧格式解析方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113037515B (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114362885A (zh) * | 2022-01-10 | 2022-04-15 | 中电望辰科技有限公司 | 物联网数据传输方法、装置、设备和介质 |
CN114401072A (zh) * | 2021-12-12 | 2022-04-26 | 西安电子科技大学 | 一种基于hinoc协议的拆帧重排序队列的动态缓存控制方法及系统 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2016175778A1 (en) * | 2015-04-29 | 2016-11-03 | Entropic Communications, Inc. | Efficient bandwidth usage in two-way broadband access networks |
CN108334546A (zh) * | 2017-12-27 | 2018-07-27 | 上海未来宽带技术股份有限公司 | 通信设备融合管理方法、存储介质及通信设备 |
CN210958386U (zh) * | 2020-02-20 | 2020-07-07 | 深圳市赛锐琪科技有限公司 | 一种基于hinoc2.0的网络抖动侦测装置 |
CN111585850A (zh) * | 2020-04-09 | 2020-08-25 | 北京瀚诺半导体科技有限公司 | 一种hinoc信道绑定方法、芯片及设备 |
CN112272128A (zh) * | 2020-09-26 | 2021-01-26 | 西安电子科技大学 | Hinoc组帧方法、系统、介质、计算机设备及应用 |
-
2021
- 2021-03-12 CN CN202110271550.7A patent/CN113037515B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2016175778A1 (en) * | 2015-04-29 | 2016-11-03 | Entropic Communications, Inc. | Efficient bandwidth usage in two-way broadband access networks |
CN108334546A (zh) * | 2017-12-27 | 2018-07-27 | 上海未来宽带技术股份有限公司 | 通信设备融合管理方法、存储介质及通信设备 |
CN210958386U (zh) * | 2020-02-20 | 2020-07-07 | 深圳市赛锐琪科技有限公司 | 一种基于hinoc2.0的网络抖动侦测装置 |
CN111585850A (zh) * | 2020-04-09 | 2020-08-25 | 北京瀚诺半导体科技有限公司 | 一种hinoc信道绑定方法、芯片及设备 |
CN112272128A (zh) * | 2020-09-26 | 2021-01-26 | 西安电子科技大学 | Hinoc组帧方法、系统、介质、计算机设备及应用 |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114401072A (zh) * | 2021-12-12 | 2022-04-26 | 西安电子科技大学 | 一种基于hinoc协议的拆帧重排序队列的动态缓存控制方法及系统 |
CN114401072B (zh) * | 2021-12-12 | 2024-02-06 | 西安电子科技大学 | 一种基于hinoc协议的拆帧重排序队列的动态缓存控制方法及系统 |
CN114362885A (zh) * | 2022-01-10 | 2022-04-15 | 中电望辰科技有限公司 | 物联网数据传输方法、装置、设备和介质 |
CN114362885B (zh) * | 2022-01-10 | 2024-04-26 | 中电望辰科技有限公司 | 物联网数据传输方法、通信系统、设备和介质 |
Also Published As
Publication number | Publication date |
---|---|
CN113037515B (zh) | 2022-11-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8699490B2 (en) | Data transmission method, network node, and data transmission system | |
US9426093B2 (en) | Multicast interworking systems and methods | |
US8320293B2 (en) | Method and apparatus for controlling uplink multicast service | |
US10506007B2 (en) | Apparatus and method for transmitting multimedia data in a broadcast system | |
US20080095082A1 (en) | Tdd frame format | |
CN113037515B (zh) | 基于hinoc系统的mac层组播数据帧的帧格式解析方法及装置 | |
KR101086778B1 (ko) | 다채널 방송망에 적합한 송신용 및 수신용 방송 매체 접속 제어 장치 | |
KR20130120416A (ko) | 디지털 방송 시스템에서 시그널링 정보 송수신 장치 및 방법 | |
US20110194560A1 (en) | Multicast address to packet identifier mapping for broadcast systems | |
CN105580342B (zh) | 发送广播信号的方法、接收广播信号的方法、发送广播信号的设备以及接收广播信号的设备 | |
US20070280257A1 (en) | Service discovery section | |
CN1988507A (zh) | 转发组播数据的方法、系统及路由器 | |
CN1528070B (zh) | 在中央服务器构成的网络中管理远程客户端的方法和系统 | |
WO2009102246A1 (en) | Segmentation of multicast distributed services | |
CN113037514B (zh) | 一种基于hinoc系统的组播业务转发方法及装置 | |
US8553555B2 (en) | Methods and apparatus for an efficient multicast file distribution system | |
US7286497B2 (en) | Look up table for QRT | |
GB2447673A (en) | Identification of multiplexed multimedia broadcast multicast service from a central node to a UMTS evolved Node B (eNB) | |
US20160050546A1 (en) | Method and apparatus for wireless router multicast | |
EP2139159A1 (en) | Method and device for managing multicast content distribution | |
US20090113013A1 (en) | Method, system, server and user equipment for obtaining default notification message | |
KR100965053B1 (ko) | 제한적 멀티캐스트 기반의 인터넷 방송 데이터 전송 방법 | |
KR100456677B1 (ko) | 멀티캐스팅 통신에서 랑데부 포인트 선정 방법 | |
RU2020133481A (ru) | Способ распределения ресурсов и устройство для поддержки связи транспортного средства в системе мобильной связи следующего поколения |
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 |