CN116033591A - 一种组播处理方法、装置及系统 - Google Patents

一种组播处理方法、装置及系统 Download PDF

Info

Publication number
CN116033591A
CN116033591A CN202310323602.XA CN202310323602A CN116033591A CN 116033591 A CN116033591 A CN 116033591A CN 202310323602 A CN202310323602 A CN 202310323602A CN 116033591 A CN116033591 A CN 116033591A
Authority
CN
China
Prior art keywords
multicast
frame
access point
node
block
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
Application number
CN202310323602.XA
Other languages
English (en)
Other versions
CN116033591B (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.)
Shanghai Langli Semiconductor Co ltd
Original Assignee
Shanghai Langli Semiconductor Co ltd
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 Shanghai Langli Semiconductor Co ltd filed Critical Shanghai Langli Semiconductor Co ltd
Priority to CN202310323602.XA priority Critical patent/CN116033591B/zh
Publication of CN116033591A publication Critical patent/CN116033591A/zh
Application granted granted Critical
Publication of CN116033591B publication Critical patent/CN116033591B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

本申请提供一种组播处理方法、装置及系统,应用于无线局域网技术领域,其中接入点向组播节点发送组播帧,并当发送完组播帧后发起一次基于竞争的块确认过程,其中由接入点向组播节点发送块确认请求,块确认请求中包含有退避竞争参数;组播节点根据自身接收组播帧的接收情况调整退避竞争参数进行信道的退避竞争,以及竞争到信道的组播节点向接入点反馈块确认数据,其中块确认数据包括需要重传的组播帧的序列号;接入点在接收块确认数据后,根据块确认数据重传对应的组播帧,以及当确定组播帧均正常完成组播传输后,向所述组播节点发送结束帧以结束当前轮的组播。通过改进与组播密切相关的传输机制,改善了组播的传输效率、稳定性及灵活性。

Description

一种组播处理方法、装置及系统
技术领域
本申请涉及无线局域网技术领域,具体涉及一种组播处理方法、装置及系统。
背景技术
如图1所示,现有无线局域网拓扑结构中,通常可以包含至少1个接入点(AccessPoint,AP)和n个节点(Station,STA,也称站点),组播通信通常描述为AP发送数据的对象是一组节点,比如将STA 1和STA 2构成一个组播组,则AP发送数据的目标地址就对应该组播组。另外,广播可以认为是组播的一种特殊情况,即所有的节点都加入同一个组播组。
在无线局域网中接入点与节点之间的数据通信,通常是基于传统的传输协议规范实现组播通信,比如802.11、802.11v、802.11aa等协议规范。由于这些协议规范是面对各种组播需求而制定的通用性规范,因而传输效率、稳定性以及灵活性等方面与实际应用的需求有较大差距,需要一种能够提升无线环境下组播性能的新技术方案。
发明内容
有鉴于此,本说明书实施例提供一种组播处理方法、装置及系统,通过在现有协议规范中有针对性地增加一些与组播密切相关的传输机制,有效地改善了无线局域网中组播的传输效率、稳定性及灵活性,使得改进后的协议规范可以适应各种无线组播场景应用。
本说明书实施例提供以下技术方案:
本说明书实施例提供一种组播处理方法,应用于接入点,所述组播处理方法包括:
向组播节点发送组播帧,其中组播帧的地址为组播节点对应的地址;
当所述组播帧传输完成后,向所述组播节点发送块确认请求,其中所述块确认请求中包含有退避竞争参数,以使所述组播节点根据所述组播帧的接收情况调整所述退避竞争参数,并在竞争到信道后向所述接入点反馈块确认数据,所述块确认数据包括需要重传的组播帧的序列号;
接收所述块确认数据,并根据所述块确认数据重传对应的组播帧;
当确定组播帧均正常地完成组播传输后,向所述组播节点发送结束帧以结束当前轮的组播。
优选地,基于802.11的块确认请求帧结构形成所述块确认请求对应的帧结构;其中,所述块确认请求对应的帧结构中:帧控制字段设置为第一帧类型,其中第一帧类型用于表征接入点下发的竞争参数能够进行动态调节;持续时间字段设置为可变类型;接收地址字段设置组播/广播地址;在块响应控制字段中添加以下新子字段:策略字段、竞争窗口;以及在块响应信息字段中添加以下新子字段:连续组播帧数目信息。
优选地,基于802.11的块确认响应帧结构形成所述块确认数据对应的帧结构;其中,所述块确认数据的帧结构中:帧控制字段设置为第二帧类型,其中第二帧类型用于表征节点反馈的竞争参数能够进行动态调节;持续时间字段设置为可变类型;接收地址字段设置为接入点的单播地址;在块响应控制字段中添加以下新子字段:策略字段;以及在块响应信息字段中添加以下新子字段:块响应位图。
优选地,所述结束帧对应的帧结构包括以下字段:帧控制字段设置为帧接收类型;持续时间字段设置为零时长;接收地址字段设置为组播/广播地址;发送地址字段设置为接入点的单播地址;帧检测序列字段。
优选地,在所述块确认请求的帧结构,持续时间字段所设置的时长不小于以下时长之和:退避竞争过程的时长、块响应帧的时长、重传组播帧的时长。
优选地,所述组播处理方法还包括:当确认连续成功传输预设第一数量的组播帧时,则提升组播帧的传输速率,和/或当确认连续丢失第二数量的组播帧时,则降低组播帧的传输速率。
优选地,重传组播帧的传输速率设置为竞争到信道的组播节点能够成功接收数据的最高速率。
优选地,在本说明书任意一项实施例中,所述退避竞争参数包括以下任意一项竞争参数:竞争窗口时长,频域竞争参数,时频资源片上的竞争参数,按位冲裁序列的参数。
本说明书实施例还提供一种组播处理方法,应用于组播节点,所述组播处理方法包括:
接收接入点发送的组播帧,以及接收所述接入点在所述组播帧传输完成后发送的块确认请求,其中所述块确认请求中包含有退避竞争参数;
根据自身在接收所述组播帧的成败情况,调整所述退避竞争参数,以根据调整后的所述退避竞争参数确定是否竞争到信道,并在竞争到信道后向所述接入点反馈块确认数据,所述块确认数据包括需要重传的组播帧的序列号。
优选地,所述组播处理方法还包括:判断自身是否属于接收者,并当不属于时则在收到任意帧之后,根据所述接入点发送的持续时长参数设置信道忙;和/或,当接收到所述接入点发送的多个持续时长参数时,将最新收到的持续时长参数覆盖先前的持续时长参数。
优选地,当所述退避竞争参数包括竞争窗口大小参数时,调整所述退避竞争参数包括:按比例调节自身的竞争窗口大小,其中竞争窗口大小与接收成败情况及接入点发送组播帧的数目之间满足以下关系:
CW=Max_CW_Size×(本地错误接收的数据包数量)/(接入点所发送的连续组播帧数目),其中Max_CW_Size为所述块确认请求中块响应控制字段的竞争窗口新子字段设置的参数。
本说明书实施例还提供一种组播处理装置,应用于接入点,所述组播处理装置包括:
组播帧发送模块,用于向组播节点发送组播帧,其中组播帧的地址为组播节点对应的地址;
块确认请求模块,用于在所述组播帧发送模块传输完成所述组播帧后,向所述组播节点发送块确认请求,其中所述块确认请求中包含有退避竞争参数,以使所述组播节点根据所述组播帧的接收情况调整所述退避竞争参数,并在竞争到信道后向所述接入点反馈块确认数据,所述块确认数据包括需要重传的组播帧的序列号;
重传模块,用于接收所述块确认数据,并根据所述块确认数据重传对应的组播帧;
结束模块,用于当确定组播帧均正常地完成组播传输后,向所述组播节点发送结束帧以结束当前轮的组播。
本说明书实施例还提供一种组播处理装置,应用于组播节点,所述组播处理装置包括:
数据接收模块,用于接收接入点发送的组播帧,以及接收所述接入点在所述组播帧传输完成后发送的块确认请求,其中所述块确认请求中包含有退避竞争参数;
竞争模块,用于根据自身在接收所述组播帧的成败情况,调整所述退避竞争参数,以根据调整后的所述退避竞争参数确定是否竞争到信道,并在竞争到信道后向所述接入点反馈块确认数据,所述块确认数据包括需要重传的组播帧的序列号。
本说明书实施例还提供一种组播处理系统,包括接入点和若干组播节点,其中:所述接入点用于向所述组播节点发送组播帧,其中组播帧的地址为组播节点对应的地址;以及,当所述组播帧传输完成后,向所述组播节点发送块确认请求,其中所述块确认请求中包含有退避竞争参数;
所述组播节点用于根据所述组播帧的接收情况调整所述退避竞争参数,并在竞争到信道后向所述接入点反馈块确认数据,所述块确认数据包括需要重传的组播帧的序列号;
所述接入点还用于接收所述块确认数据,并根据所述块确认数据重传对应的组播帧,以及当确定组播帧均正常地完成组播传输后,向所述组播节点发送结束帧以结束当前轮的组播。
与现有技术相比,本说明书实施例采用的上述至少一个技术方案能够达到的有益效果至少包括:
在技术方案中,由接入点向组播节点连续地发送组播帧,并在发送完组播帧后,发送包含有退避竞争参数的块确认请求,使得接收组播帧的各个节点能够根据自身接收情况调整退避竞争参数后进行退避竞争信道,以及使得竞争到信道的组播节点向接入点反馈重传组播帧的块确认数据,便于接入点重传该块确认数据所指定的重传组播帧后结束本轮组播。因此,通过优化组播传输过程,形成能够提供竞争解决方案的新组播传输模式,从而能够兼顾传输效率、稳定性和灵活性等方面,使得整个传输过程得到优化改进,明显提升组播传输的整体性能和普适性。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其它的附图。
图1是接入点与组播节点之间结构的示意图;
图2是802.11协议规范中接入点进行基本组播的示意图;
图3是802.11v协议中DMS组播传输的示意图;
图4是802.11aa协议中GCR组播传输的示意图;
图5是802.11aa协议中具有块确认的GCR组播传输的示意图;
图6是以请求次数为中心的竞争参数动态调节的示意图;
图7是基于信道状态信息的竞争参数动态调节的示意图;
图8是本申请中具有竞争机制且竞争参数动态调节的无线组播处理方法的流程图;
图9是本申请中无线组播处理方法中进行退避竞争的示意图;
图10是本申请中接入点向组播节点发送的一种块确认请求帧结构的示意图;
图11是本申请中接入点向组播节点发送的另一种块确认请求帧结构的示意图;
图12是本申请中组播节点向接入点反馈的块确认数据帧结构的示意图;
图13是本申请中接入点向各个组播节点发送的结束帧结构的示意图;
图14是本申请中应用于接入点的组播处理装置的结构示意图;
图15是本申请中应用于组播节点的组播处理装置的结构示意图。
具体实施方式
下面结合附图对本申请实施例进行详细描述。
以下通过特定的具体实例说明本申请的实施方式,本领域技术人员可由本说明书所揭露的内容轻易地了解本申请的其他优点与功效。显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。本申请还可以通过另外不同的具体实施方式加以实施或应用,本说明书中的各项细节也可以基于不同观点与应用,在没有背离本申请的精神下进行各种修饰或改变。需说明的是,在不冲突的情况下,以下实施例及实施例中的特征可以相互组合。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
要说明的是,下文描述在所附权利要求书的范围内的实施例的各种方面。应显而易见,本文中所描述的方面可体现于广泛多种形式中,且本文中所描述的任何特定结构及/或功能仅为说明性的。基于本申请,所属领域的技术人员应了解,本文中所描述的一个方面可与任何其它方面独立地实施,且可以各种方式组合这些方面中的两者或两者以上。举例来说,可使用本文中所阐述的任何数目和方面来实施设备及/或实践方法。另外,可使用除了本文中所阐述的方面中的一或多者之外的其它结构及/或功能性实施此设备及/或实践此方法。
还需要说明的是,以下实施例中所提供的图示仅以示意方式说明本申请的基本构想,图式中仅显示与本申请中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制,其实际实施时各组件的型态、数量及比例可为一种随意的改变,且其组件布局型态也可能更为复杂。
另外,在以下描述中,提供具体细节是为了便于透彻理解实例。然而,所属领域的技术人员将理解,可在没有这些特定细节的情况下实践。
目前,针对无线局域网的组播通信,在传播模式方面,针对特定场景已制定有多个传统传输协议规范。
如图2所示,802.11协议规范中提供了一种基本的组播(Multicast)传输模式,在该基本模式中,在信道忙(Busy)过后,并等待DIFS时隙(Distributed Inter-frameSpacing,分布协调功能帧间间隔,是用于异步帧竞争访问的时延,如图中示意的D)和Backoff(退避,如图中示意的BO)后,接入点AP会直接发送一个组播帧(Multicast Frame,如图中示意的组播帧1)给组内节点,该组播帧的目标地址为组播地址,该组播帧采用网络所支持的最低速率(通常为802.11b的1Mbps)进行发送,采用该速率的原因有两个:一方面所有节点都支持该速率,另一方面该速率的冗余内容最多,能抵抗最多的干扰。因此,在该基本模式下,每一个组播帧传输均需要遵从标准的802.11协议,即AP或节点需要等待信道DIFS时间后,进行Backoff并胜利后才可以发送,亦即组播帧只会传输1次,若传输失败,仍不会重传该组播数据包。因此,不仅传输速率低,而且传输失败时不会重传,整体效率很低。
如图3所示,802.11v协议定义的DMS(Directed Multicast Service,定向组播传输)组播传输模式下,AP会将一个组播帧(如DMS Frame1,即图中示意的定向传播组播帧1)复制(copy)成多个单播包(如图中示意的复制1、复制2等)进行传输,每一个单播包的目的地址均为组内节点的地址。单播包的数目等于该组中所包含的节点数。以及,每一个DMS单播包传输都需要遵从标准的802.11协议,即AP或节点需要等待信道DIFS时间后,进行Backoff并胜利才可以发送,DMS单播包可以采用更高的传输速率,该速率通常设置为目标节点的最优速率(实施中可以通过Rate adaption算法实现速率调节)。具体地,在DMS模式下,如果DMS单播包发送成功,则接收方需要在SIFS(Short Interframe Space,短帧间间隔)时间后反馈ACK(应答信号),比如STA1在AP发送DMS Frame1成功时回应ACK1,STA2在AP发送DMS Frame2成功时回应ACK2;但是,如果DMS单播包发送失败,则接收方不会在SIFS时间后反馈ACK,发送方应会进行重传,重传的具体机制和一般的单播包重传相同。因此,将一次组播转换成多次单播,传输效率显著降低。
如图4所示,802.11aa协议定义的GCR(Groupcast with Retries,带重试群组广播)组播传输的GCR主动重试(GCR Unsolicited Retry)模式,该模式类似于前述802.11的基本模式,该组播帧的目标地址为组播地址,并且AP采用网络所支持的最低速率发送组播帧,当相比802.11的基本模式,该组播帧可以连续传输多次(如图中示意的组播帧1多次传输),每一次传输均为该组播帧提供一个冗余副本(Redundancy)。若一个组播帧发生错误后,节点可以直接利用冗余的组播帧进行解调,减少了延迟,提升了效率。此处,每一个组播帧(包含冗余的组播帧)传输都需要遵从标准的802.11协议,即AP或节点需要等待信道DIFS时间后,进行Backoff并胜利后才可以进行发送。因此,由于需要提供冗余副本,传输速率低,无法根据节点的真实需求进行重传,灵活性差,以及如果当前信道质量好,则Redundancy冗余传输则是浪费,进一步降低了效率,又或者是如果当前信道质量差,有可能Redundancy冗余仍然不够,仍然无法避免传输错误。
如图5所示,802.11aa协议定义的GCR组播传输的GCR块确认(GCR Block ACK)模式,该模式是基于Block ACK(块确认)机制的一种组播传输模式。在该模式下,AP会连续发送多个组播帧给组内节点,这些包的目标地址均为组播地址,发送速率一般采用网络所支持的最低速率,并且连续发送组播帧数量为一个预设的固定值(如图中示意的2个)。当一组连续组播发送完毕后,AP会发送GCR BAR(Block ACK Request,块响应请求)请求BA(即Block ACK,块响应),并根据BA的结果进行重传。以图5的示出为例,AP竞争到信道以后,首先会连续发送多个Multicast Frames(组播帧),当发送完毕后,AP会挑选一个节点(比如STA1)发送GCR BAR 1(即Block ACK请求)。当节点(比如STA1)接收到GCR BAR1后,则会反馈BA1,其中在BA1中会指示该节点是否成功接收,若成功则反馈Pass(通过),若失败则反馈Fail(失败,也可以标记为error,错误)。当这一次GCR Multicast传输(如图中示意的组播帧1和组播帧2)完毕后,进行下一次组播帧的连续传输(如图中示意的组播帧3和组播帧4),并发送GCR BAR 2给节点2(记为STA 2)。此处STA 2会反馈自己接收数据包的情况(包括之前组播帧1和组播帧2的接收情况),这里STA 2指示自己组播帧1和组播帧3错误(error),此后AP针对这两个帧进行重传(Retransmissions)。因此,在选择节点询问BA信息并考虑重传时,并没有考虑到节点的信道情况,其是按照默认节点顺序进行询问的,不仅传输速率低,还会出现这种逐个问询的资源浪费,即该节点没有数据包错误,但是AP仍然需要对其进行询问,降低了信道利用率,增加了延迟。
综上,虽然现有协议规范中定义有多种组播传输模式,但在这些组播模式中,一方面仍然需要遵循802.11规定的传输速率和组播帧传输顺序,另一方面各个组播传播模式均是针对特定传输需要而制定的,所以在实际无线组播传输应用中,在传输效率、稳定性、灵活性等方面的性能和普适性较低。
另外,针对无线局域网的传输中发生竞争的情形,现有方案可以为以下两种竞争解决方案。
如图6所示,“以请求次数为中心的竞争参数动态调节”方案中,例如在一种基于智能驾驶的数据请求场景,如在一个路口,每一个节点都可以观察到部分的路口信息(记为Cube)。在该场景下,任何一个节点(车辆)都有可能向其他节点发送请求(如Cube Request)用于请求未知的哪些Cube信息,还有也会出现多个不同节点对一个相同的Cube进行多次请求,此时就存在竞争。因此,“以请求次数为中心的竞争参数动态调节”基本思想是:如果一个Cube被多次请求之后,比如图6中的路口信息2(记为Cube Request2)被连续请求了2次(即Base on 2-times requests),而路口信息1(记为Cube Request1)仅仅被请求了1次(即Base on 1-time request),则路口信息响应2(记为Cube Response2)的优先级可以被提高,这时可以采用更短的Backoff竞争时间,即针对Cube Response2采用更短的竞争时间Short BO(记为短BO),而针对Cube Response1采用更长的竞争时间Long BO(记为长BO)。因此,虽然基于请求次数可以解决多个请求并存的竞争传输,但它无法应用到组播场景。
如图7所示,“基于CSI(channel state information,信道状态信息)用户选择算法的竞争参数动态调节”方案中,定义了一种MU-MIMO(Multi-User Multiple-InputMultiple-Output,多用户多输入多输出,即多用户MIMO)接入场景。在该场景下,允许多个节点同时进行物理层传输。然而,不同的节点组合执行并行传输的质量不同,这时需要在竞争过程中选择出最优的节点组合。如图7中示意,该竞争机制采用一个8-BA(即代表8个时隙的按位仲裁竞争)的按位仲裁机制,并且在该机制中,也存在竞争优先级。整个接入过程由AP发起(即发送探测帧,记为Probe frame),在首轮时,由于还未存在节点间的干扰,所有节点公平地执行竞争,并决胜出1个胜利者,接着由胜利者反馈自身的信道状态信息(CSI),其他节点可以通过该胜利者反馈的信道状态信息,获知其对自身的干扰情况。例如,首轮的胜利者为站点1(记为STA 1),这时STA1反馈自身的CSI1,其他节点(如STA2、STA3)根据STA1反馈的信道状态信息1(记为CSI1)获知自身反馈情况,比如STA 2受到的干扰就大于STA 3受到的干扰。在首轮后,节点会根据干扰情况设置第二轮竞争的优先级,这时STA 3的优先级就大于STA 2的优先级,STA 3获得了竞争胜利,并反馈自身CSI给AP。当多个节点的CSI都接收完毕后,AP就可以执行一次并行的MU-MIMO传输了。虽然基于CSI可以解决MU-MIMO场景中的竞争传输,但它同样无法应用到组播场景。
综上,现有解决竞争传输的方案,因与组播之间无关联性,无法用于组播场景。
有鉴于此,发明人通过对无线局域网及其传输协议、过程,结合实际应用场景,在改进探索中发现:现有协议规范已经对无线局域网的传输作了格式化规范,虽然这些格式化规范是针对特定应用场景而定义的,但是可以在这些格式规范提供的帧结构基础上,通过优化组播传输过程,形成能够提供竞争解决方案的新组播传输模式,从而能够兼顾传输效率、稳定性和灵活性等方面,使得整个传输过程得到优化改进,明显提升组播传输的整体性能和普适性。
本说明书实施例提供基于802.11aa的GCR Block ACK进行改进设计得到的一种新组播传输模式:NGCR Block ACK竞争机制。
如图8所示,一种新型无线组播处理方案中,接入点AP先向若干节点STA(如STA1至STAn)传输组播帧,并在组播帧传输完成后,比如等待SIFS时隙,再向各个节点发起一次基于竞争的块确认过程,比如广播块确认请求(Block ACK Request,BAR,也记为NGCR BAR,本说明书中不作区分),其中BAR中包含有Backoff(退避)竞争参数(如Backoff窗口大小,简记为BO),各个节点根据信道竞争策略,比如基于失败接收组播帧数量越多则越容易竞争到信道的策略,这时节点可以依据自身本地对组播数据包(即组播帧)的接收情况调整Backoff竞争参数,如所有组播帧均成功接收,则不减小Backoff窗口大小,或者根据优先级相应地减小Backoff窗口大小,又比如存在组播帧接收失败,则根据失败的组播帧多少相应地减小Backoff窗口大小,从而在各个节点动态调整完Backoff竞争参数后,组播帧接收失败最多的节点优先竞争得到信道(如图中示意的STA2)。节点STA2在竞争得到信道后,向接入点AP反馈块确认数据(Block ACK,BA,也记为NGCR BA,本说明书中不作区分),这时接入点AP在接收到节点反馈的块确认数据BA后,根据块确认数据BA进行组播帧的重传。当组播帧均正常地完成组播传输后,接入点AP再向各个节点发送结束组播传输的信息,以结束本轮的组播传输。
需要说明的是,当前轮的组播传输是否能够结束,可根据实际场景需要确定,比如重传的组播帧正常完成组播传输后结束组播传输,又比如所有组播帧均正常完成组播传输后结束组播传输等,这里不作限定,
具体地,如图9所示,在该模式下AP可以连续发送多个组播帧(如图中示意的组播帧1(记为Multicast Frame 1)至组播帧4(记为Multicast Frame 4))给组内节点,其中这些组播帧的目标地址均为组播地址。当一组组播帧连续传输发送完毕后,AP会发送一个组播的块确认请求(Block ACK Request,记为NGCR BAR)。在该块确认请求中,AP通知组内节点可以通过Backoff(退避)竞争方式来反馈块确认(Block ACK,记为NGCR BA),其中退避竞争方式可以是数据包错误越多的节点越容易竞争到信道。当组内节点通过竞争获取信道后,反馈NGCR BA帧给AP,此后AP根据该BA帧的信息进行重传。例如,STA2的错误数据包为组播帧1和组播帧3,错误的数据包最多,因而STA2竞争到信道,并向AP反馈NGCR BA2,这时AP获知需要重传的组播帧为组播帧1和组播帧3,进而重传这些组播帧。当重传完毕后,AP会发送结束帧(NGCR End)来结束该轮重传,并进入下一轮传输过程。
通过接入点向组播节点连续地发送组播帧,并发送包含有退避竞争参数的块确认请求,以及接收组播帧的各个节点能够根据自身接收情况调整退避竞争参数,以便通过调整后的退避竞争参数竞争到信道后向接入点反馈重传组播帧的块确认数据,便于接入点重传该块确认数据所指定的重传组播帧后结束本轮组播。因此,通过优化组播传输过程,形成能够提供竞争解决方案的新组播传输模式,从而能够兼顾传输效率、稳定性和灵活性等方面,使得整个传输过程得到优化改进,明显提升组播传输的整体性能和普适性。
在一些实施方式中,接入点可以基于传统帧结构向各组播节点广播块确认请求,以使得组播节点能够根据块确认请求以及自身接收情况动态调整竞争参数。
因此,接入点可以在传统帧结构基础上,通过设置新的块确认请求帧结构,进而基于新帧结构向各组播节点广播块确认请求。
在一种示例中,如图10所示的一种NGCR BAR帧结构(记为Type-1),首先是将传统帧结构的以下字段作新设置:帧控制字段(Frame Control)设置帧类型为NGCR BAR;持续时间/ID字段(Duration/ID)设置为可变类型(Variable,即作为变量)的竞争时长;接收地址字段(RA)设置为组播/广播地址(记为Multicast Addr);其余字段与传统帧结构相同,如发送地址(TA,设置单播地址,即Unicast Addr)、帧校验序列(Frame Check Sequence,FCS)等字段,不作限定;
其次,在传统帧结构上进行了新修改:
添加块响应控制字段(NGCR BAR Control),其中响应策略(NGCR Policy)表示ACK策略,最大竞争窗口尺寸(NGCR Max CW Size)代表竞争参数最大竞争窗口(CW),请求响应数量(NGCR Request ACK Numbers)代表当前请求的ACK范围;另外,压缩位图(CompressedBitmap),多个传输流标识号标记(Multi-TID Flag),传输流标识号信息(TID_Info)与传统帧结构相同,这里不作限定;
添加块响应信息字段(NGCR BAR Information),其中响应起始序列号(BAStarting Sequence Number)根据NGCR机制进行修改;另外,每个传输流标识号信息(PerTID Info)与传统帧结构相同,这里不作限定。
需要说明的是,这里是基于GCR BAR进行改进而得到NGCR BAR,因而添加可以理解为是在对GCR BAR的帧结构上进行改进时,相对于GCR BAR的字段进行部分内容的添加。
在一种示例中,如图11所示的另一种NGCR BAR帧结构(记为Type-2),Type-2帧结构整体和前述Type-1帧结构基本相同,不同的是在Type-2帧结构中采用块响应终止序列号(BA Ending Sequence Number)代替Type-1帧结构中NGCR BAR帧结构的响应请求数量(NGCR Request ACK Numbers)字段,其中响应请求数量、块响应终止序列号和块响应起始序列号之间满足:BA Ending Sequence Number = BA Starting Sequence Number + NGCRRequest ACK Numbers。
因此,基于传统帧结构上定义新的帧结构(如新设置部分字段内容、增加部分新字段等),将接入点对各个节点在NGCR Block ACK竞争机制中对块确认请求的竞争机制进行新定义,使得各节点在接收到接入点广播的块确认请求后,可以根据接入点的要求以及自身接收情况,通过动态地调整竞争参数进行块响应,从而各节点在接入点的组播中能够动态地进行信道竞争,实现NGCR Block ACK竞争机制下的新组播方式,能够更好地兼顾传输效率、稳定性和灵活性。
在一些实施方式中,各节点在进行块响应(即反馈BA)时,可以在块响应帧结构中动态地调整竞争参数,从而通过块响应中竞争参数的动态调整来竞争到信道。
如图12所示,节点进行块响应的帧结构(记为NGCR BA帧结构)如下:
对于传统帧结构进行了参数调节,即把传统帧结构的以下字段作新设置:帧控制字段(Frame Control)设置帧类型NGCR BA,Duration/ID设置为可变类型(Variable)的竞争时长,接收地址字段(RA)设置为接入点AP的单播地址(Unicast Addr);另外,发送地址字段(TA)设置为单播地址(Unicast Addr),以及设置帧校验序列(FCS),这里TA、FCS等字段与传统帧结构的相同,不作限定;
在传统帧结构上进行了修改:添加控制字段(NGCR BA Control),其中NGCRPolicy表示ACK策略,另外压缩位图(Compressed Bitmap),多传输流标识号标记(Multi-TID Flag),传输流标识号信息(TID_Info)与传统帧结构相同;添加信息字段(NGCR BAInformation),其中块响应位图(BA Bitmap)根据NGCR机制进行修改,另外每个传输流标识号信息(Per TID Info)字段与传统帧结构相同,不作限定。
因此,节点可以根据自身接收情况实时动态地调整竞争参数进行块响应,从而根据竞争机制可以在调整参数中进行信道竞争。
在一些实施方式中,在接入点传输完重传组播帧后,可以通过帧结构向各节点发出当前轮组播结束的信息,便于在接入点与各节点之间进行下一轮组播传输。
如图13所示,接入点AP发出的结束帧结构(记为NGCR End帧结构)仍基于传统帧结构进行参数调节得到,其中帧控制字段(Frame Control)设置帧类型NGCR End,Duration/ID设置为0,RA字段设置为组播/广播地址。
在一些实施方式中,在信道竞争的反馈过程中,退避竞争参数可以是竞争窗口大小(如前述示例中的竞争时长),且可以是节点能够根据本地接收成功的结果动态调节的竞争窗口大小,以便接收失败越多的节点(即需要重传组播帧越多的节点)优先竞争到信道。
竞争窗口大小的调整示意如下:如果节点所有的数据包都成功接收,则在默认的竞争窗口内选择随机数进行反馈;如果节点错误的数据包越多,因而可以调节自己的竞争窗口大小,比如说一共发送4个包,节点的错误数据包为2个,那么节点的竞争窗口大小就缩减为1/2。因此,通过竞争窗口大小调整后,错误组播帧越多的节点越容易竞争到信道。
因此,可以在前述各帧结构(如NGCR BAR帧结构、NGCR BA帧结构、NGCR End帧结构等),通过对帧结构中的持续时间字段(Duration/ID)进行重新定义,将竞争时长参数作为可变类型,进而将其作为退避竞争参数,即把Duration/ID定义为可变类型,并根据不同场景设置,比如定义的时长是根据应用场景进行预先设置的参数,也可以是能够在竞争过程进行动态调整的参数。因此,可以通过Duration/ID字段设置,即确保了在所设置的竞争时间内,只有该组的组内节点可以竞争信道,其余非属于该组播组的节点不能够竞争信道,又能够灵活设置竞争时长,在能够兼顾传输效率、稳定性和灵活性等方面后,进一步提升组播传输的整体性能和普适性。
实施中,通过设置帧结构中的竞争时长参数,可以提供一种新的TXOP保护机制,即NGCR Block ACK竞争接入时间TXOP保护机制。
正如前述示例中,可以通过设置各帧结构中的Duration/ID字段,确保了只有组内的节点可以参与竞争,其余非组内的节点不能够参与竞争。因此,在接入点广播NGCR BAR帧要求各节点进行块响应时,若节点为帧对应的接收者(比如组内节点),则不会根据Duration参数设置信道忙,若节点不是对应的接收者,则在收到任意帧之后,根据Duration参数设置信道忙。另外,当节点涉及到多个Duration参数时,会将最新收到的Duration参数覆盖之前的参数。
竞争时长参数的设置示意如下:
NGCR BAR帧的Duration:该Duration为一个预设值,设置时长包含其后的竞争BO过程,NGCR BA帧时长,多个组播帧(Multicast Frame)重传时长;
NGCR BA帧的Duration:该Duration为一个预设值,设置时长包含其后多个Multicast Frame重传时长;
Multicast Frame帧的Duration:该Duration为一个预设值,设置时长包含其后多个Multicast Frame重传时长。
NGCR End帧的Duration:该Duration设置为0,并重置所有节点的Duration为0。
在一些实施方式中,在竞争反馈过程中,节点的竞争窗口(Contention Windows,CW)参数是节点自身能够根据本地接收情况进行动态调整,本说明书实施例提供一种NGCRBlock ACK竞争参数CW选择方案。
正如前述示例中,接入点AP会在NGCR Multicast BAR帧中包含一个基础的NGCRMax CW Size参数,这个参数是由接入点AP决定的一个基础Contention Windows参数,节点可以基于NGCR Max CW Size作为基础竞争窗口,并根据本地错误接收的数据包进行动态调节。
具体调节过程示意如下:
首先,节点STA获得接入点AP所发送的连续组播帧数目,比如根据NGCR BAR type-1帧中的NGCR Request ACK Numbers直接确定,或者根据NGCR BAR type-2帧中的BAEnding Sequence Number与BA Starting Sequence Number之差确定;
然后,节点将本地的竞争窗口CW(Contention Windows)设置为:CW= NGCR Max CWSize ×(本地错误接收的数据包数量)/(接入点AP所发送的连续组播帧数目);例如,如果节点错误的数据包越多,那么就按比例调节自己的竞争窗口大小(比如说一共发送4个包,节点错2个,那么节点的竞争窗口大小就缩减为1/2)。
此后节点就在该范围内均匀选择一个随机数作为自己的竞争参数,并逐个时隙进行竞争。
因此,通过接入点预先给定NGCR Max CW Size参数的基础值,以及各节点根据自身接收情况动态调整该基础值进行信道竞争,实现NGCR Block ACK竞争参数CW的动态选择及调节。
在一些实施方式中,传统组播传输中并未设计相关ACK,无法做到速率自适应(Rate adaption),而本说明书提供的组播传输模式中给出了NGCR BA的内容,因而可以利用NGCR BA的内容,以及对应节点设置速率自适应算法后,能够在此基础上适配传统组播中的速率自适应。
实施中,组播帧的传输速率由响应块确认请求(NGCR BAR)的节点决定,即竞争到信道的节点反馈块确认数据,因此速率一般设置为保证该节点能够成功接收到的最高速率。该模式下,接入点AP发送连续组播帧的数量也为一个预设的固定值(例如前述示例中为4帧),当一组连续传输发送完毕后,接入点AP会发送一个组播的块确认请求(NGCR BAR)。在NGCR BAR中,接入点AP通知组内节点可以通过竞争的方式来反馈BA,并在该帧中带入一些竞争参数(比如包含一个默认的竞争窗口大小(即Contention Window Size)),因而基于传统ACK的速率自适应机制,如果连续确认多个数据包成功传输,那么提升速率,如果连续丢失多个数据包,那么降低速率。
在一些实施方式中,基于前述示例给出的NGCR Block ACK竞争机制,可以进行竞争过程拓展,即基于前述示例NGCR Block ACK竞争机制,竞争过程可以更替为其他竞争过程,进一步提升组播传输的通用性。
实施中,竞争过程可以更替为其他竞争过程,进而利用前述示例的动态调整参数的构思对其他竞争过程的竞争参数实现动态调整。需要说明的是,具体其他竞争过程可参见相关现有技术的频域竞争过程,时频资源片竞争过程,按位冲裁竞争过程,这里不对具体的其他竞争过程作展开说明;以及,竞争过程中的竞争参数的调整可以参考本说明书前述实施例中对竞争窗口大小的调整示意,不再展开。
例如,NGCR BA的竞争过程可以采用频域竞争过程,并根据节点本地的ACK情况确认频域竞争参数。
例如,NGCR BA的竞争过程可以采用时频资源片的竞争过程,并根据节点本地的ACK情况确认时频资源片上的竞争参数。
例如,NGCR BA的竞争过程可以采用按位仲裁竞争过程,并根据节点本地的ACK情况确认竞争时按位冲裁序列的参数。
综上,通过形成新组播传输模式,并在传输模式中由节点根据自身接收情况动态调整竞争参数进行信道竞争,不仅在稳定性、灵活性等方面优于传统组播传输,而且也性能上也优于传统组播传输。
例如,在传输效率方面,本发明通过动态竞争的方式,让组播传输中,接收错误最多的节点可以优先竞争到信道,并针对该节点调节重传和速率适配机制。
例如,在稳定性方面,本发明引入了NGCR Block ACK,因此组播传输过程中的错误数据可以进行重传恢复,从而提升稳定性。
例如,在灵活性方面,本发明中通过节点根据自身接收情况来动态调整退避竞争参数进行信道竞争,比如引入NGCR CW Size,接入点AP所发送的连续组播帧的数目,以及发送采用的速率都可以动态调节,从而增加了协议的灵活性。
另外,相比传统的基本组播传输机制,本发明可以优化速率适配。相比传统的DMS传输,本发明可以优化效率,减少传输次数,提升效率。相比GCR Unsolicited Retry和GCRBlock ACK,本发明可以避免盲目性,让错误最多的节点,也就是最需要重传的节点发起BA确认,避免盲目的冗余或者逐个节点盲目的轮询过程。
基于相同发明构思,本说明书还提供与前述应用于接入点的组播处理方法对应的一种组播处理装置。
其中,如图14所示,应用于接入点的所述组播处理装置包括:
组播帧发送模块1401,用于向组播节点发送组播帧,其中组播帧的地址为组播节点对应的地址;
块确认请求模块1403,用于在所述组播帧发送模块1401传输完成所述组播帧后,向所述组播节点发送块确认请求,其中所述块确认请求中包含有退避竞争参数,以使所述组播节点根据所述组播帧的接收情况调整所述退避竞争参数,并在竞争到信道后向所述接入点反馈块确认数据,所述块确认数据包括需要重传的组播帧的序列号;
重传模块1405,用于接收所述块确认数据,并根据所述块确认数据重传对应的组播帧;
结束模块1407,用于当确定组播帧均正常完成组播传输后,向所述组播节点发送结束帧以结束当前轮的组播。
基于相同发明构思,本说明书还提供与前述应用于组播节点的组播处理方法对应的一种组播处理装置。
如图15所示,应用于组播节点的所述组播处理装置,包括:
数据接收模块1501,用于接收接入点发送的组播帧,以及接收所述接入点在所述组播帧传输完成后发送的块确认请求,其中所述块确认请求中包含有退避竞争参数;
竞争模块1503,用于根据自身在接收所述组播帧的成败情况,调整所述退避竞争参数,以根据调整后的所述退避竞争参数确定是否竞争到信道,并在竞争到信道后向所述接入点反馈块确认数据,所述块确认数据包括需要重传的组播帧的序列号。
基于相同发明构思,本说明书还提供与前述方法对应的一种组播处理系统,其中所述组播处理系统包括接入点和若干组播节点,所述接入点用于向所述组播节点发送组播帧,其中组播帧的地址为组播节点对应的地址;以及,当所述组播帧传输完成后,向所述组播节点发送块确认请求,其中所述块确认请求中包含有退避竞争参数;
所述组播节点用于根据所述组播帧的接收情况调整所述退避竞争参数,并在竞争到信道后向所述接入点反馈块确认数据,所述块确认数据包括需要重传的组播帧的序列号;
所述接入点还用于接收所述块确认数据,并根据所述块确认数据重传对应的组播帧,以及当组播帧均正常地完成组播传输后,向所述组播节点发送结束帧以结束当前轮的组播。
本说明书中,各个实施例之间相同相似的部分互相参见即可,每个实施例侧重说明的都是与其他实施例的不同之处。尤其,对于后面说明的产品实施例而言,由于其与方法是对应的,描述比较简单,相关之处参见系统实施例的部分说明即可。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以权利要求的保护范围为准。

Claims (14)

1.一种组播处理方法,其特征在于,应用于接入点,所述组播处理方法包括:
向组播节点发送组播帧,其中组播帧的地址为组播节点对应的地址;
当所述组播帧传输完成后,向所述组播节点发送块确认请求,其中所述块确认请求中包含有退避竞争参数,以使所述组播节点根据所述组播帧的接收情况调整所述退避竞争参数,并在竞争到信道后向所述接入点反馈块确认数据,所述块确认数据包括需要重传的组播帧的序列号;
接收所述块确认数据,并根据所述块确认数据重传对应的组播帧;
当确定组播帧正常完成组播传输后,向所述组播节点发送结束帧以结束当前轮的组播。
2.根据权利要求1所述的组播处理方法,其特征在于,基于802.11的块确认请求帧结构形成所述块确认请求对应的帧结构;其中,所述块确认请求对应的帧结构中:帧控制字段设置为第一帧类型,其中第一帧类型用于表征接入点下发的竞争参数能够进行动态调节;持续时间字段设置为可变类型;接收地址字段设置组播/广播地址;在块响应控制字段中添加以下新子字段:策略字段、竞争窗口;以及在块响应信息字段中添加以下新子字段:连续组播帧数目信息。
3.根据权利要求2所述的组播处理方法,其特征在于,基于802.11的块确认响应帧结构形成所述块确认数据对应的帧结构;其中,所述块确认数据的帧结构中:帧控制字段设置为第二帧类型,其中第二帧类型用于表征节点反馈的竞争参数能够进行动态调节;持续时间字段设置为可变类型;接收地址字段设置为接入点的单播地址;在块响应控制字段中添加以下新子字段:策略字段;以及在块响应信息字段中添加以下新子字段:块响应位图。
4.根据权利要求2所述的组播处理方法,其特征在于,所述结束帧对应的帧结构包括以下字段:帧控制字段设置为帧接收类型;持续时间字段设置为零时长;接收地址字段设置为组播/广播地址;发送地址字段设置为接入点的单播地址;帧检测序列字段。
5.根据权利要求2所述的组播处理方法,其特征在于,在所述块确认请求的帧结构,持续时间字段所设置的时长不小于以下时长之和:退避竞争过程的时长、块响应帧的时长、重传组播帧的时长。
6.根据权利要求1所述的组播处理方法,其特征在于,所述组播处理方法还包括:当确认连续成功传输预设第一数量的组播帧时,则提升组播帧的传输速率,和/或当确认连续丢失第二数量的组播帧时,则降低组播帧的传输速率。
7.根据权利要求6所述的组播处理方法,其特征在于,重传组播帧的传输速率设置为竞争到信道的组播节点能够成功接收数据的最高速率。
8.根据权利要求1-7中任意一项所述的组播处理方法,其特征在于,所述退避竞争参数包括以下任意一项竞争参数:竞争窗口时长,频域竞争参数,时频资源片上的竞争参数,按位冲裁序列的参数。
9.一种组播处理方法,其特征在于,应用于组播节点,所述组播处理方法包括:
接收接入点发送的组播帧,以及接收所述接入点在所述组播帧传输完成后发送的块确认请求,其中所述块确认请求中包含有退避竞争参数;
根据自身在接收所述组播帧的成败情况,调整所述退避竞争参数,以根据调整后的所述退避竞争参数确定是否竞争到信道,并在竞争到信道后向所述接入点反馈块确认数据,所述块确认数据包括需要重传的组播帧的序列号。
10.根据权利要求9所述的组播处理方法,其特征在于,所述组播处理方法还包括:判断自身是否属于接收者,并当不属于时则在收到任意帧之后,根据所述接入点发送的持续时长参数设置信道忙;和/或,当接收到所述接入点发送的多个持续时长参数时,将最新收到的持续时长参数覆盖先前的持续时长参数。
11.根据权利要求9所述的组播处理方法,其特征在于,当所述退避竞争参数包括竞争窗口大小参数时,调整所述退避竞争参数包括:按比例调节自身的竞争窗口大小,其中竞争窗口大小与接收成败情况及接入点发送组播帧的数目之间满足以下关系:
CW=Max_CW_Size×(本地错误接收的数据包数量)/(接入点所发送的连续组播帧数目),其中Max_CW_Size为所述块确认请求中块响应控制字段的竞争窗口新子字段设置的参数。
12.一种组播处理装置,其特征在于,应用于接入点,所述组播处理装置包括:
组播帧发送模块,用于向组播节点发送组播帧,其中组播帧的地址为组播节点对应的地址;
块确认请求模块,用于在所述组播帧发送模块传输完成所述组播帧后,向所述组播节点发送块确认请求,其中所述块确认请求中包含有退避竞争参数,以使所述组播节点根据所述组播帧的接收情况调整所述退避竞争参数,并在竞争到信道后向所述接入点反馈块确认数据,所述块确认数据包括需要重传的组播帧的序列号;
重传模块,用于接收所述块确认数据,并根据所述块确认数据重传对应的组播帧;
结束模块,用于当确定组播帧正常完成组播传输后,向所述组播节点发送结束帧以结束当前轮的组播。
13.一种组播处理装置,其特征在于,应用于组播节点,所述组播处理装置包括:
数据接收模块,用于接收接入点发送的组播帧,以及接收所述接入点在所述组播帧传输完成后发送的块确认请求,其中所述块确认请求中包含有退避竞争参数;
竞争模块,用于根据自身在接收所述组播帧的成败情况,调整所述退避竞争参数,以根据调整后的所述退避竞争参数确定是否竞争到信道,并在竞争到信道后向所述接入点反馈块确认数据,所述块确认数据包括需要重传的组播帧的序列号。
14.一种组播处理系统,包括接入点和若干组播节点,其特征在于,所述接入点用于向所述组播节点发送组播帧,其中组播帧的地址为组播节点对应的地址;以及,当所述组播帧传输完成后,向所述组播节点发送块确认请求,其中所述块确认请求中包含有退避竞争参数;
所述组播节点用于根据所述组播帧的接收情况调整所述退避竞争参数,并在竞争到信道后向所述接入点反馈块确认数据,所述块确认数据包括需要重传的组播帧的序列号;
所述接入点还用于接收所述块确认数据,并根据所述块确认数据重传对应的组播帧,以及当确定组播帧正常完成组播传输后,向所述组播节点发送结束帧以结束当前轮的组播。
CN202310323602.XA 2023-03-30 2023-03-30 一种组播处理方法、装置及系统 Active CN116033591B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310323602.XA CN116033591B (zh) 2023-03-30 2023-03-30 一种组播处理方法、装置及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310323602.XA CN116033591B (zh) 2023-03-30 2023-03-30 一种组播处理方法、装置及系统

Publications (2)

Publication Number Publication Date
CN116033591A true CN116033591A (zh) 2023-04-28
CN116033591B CN116033591B (zh) 2023-08-08

Family

ID=86077971

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310323602.XA Active CN116033591B (zh) 2023-03-30 2023-03-30 一种组播处理方法、装置及系统

Country Status (1)

Country Link
CN (1) CN116033591B (zh)

Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002064589A (ja) * 2000-08-14 2002-02-28 Nippon Telegr & Teleph Corp <Ntt> 応答集中回避方法
US20090279470A1 (en) * 2008-05-09 2009-11-12 Yongho Seok Device and method for multicast in wireless local access network
US20110096710A1 (en) * 2008-06-26 2011-04-28 Hang Liu Apparatus for requesting acknowledgement and transmitting acknowledgement of multicast data in wireless local area networks
CN103298027A (zh) * 2012-02-24 2013-09-11 华为技术有限公司 一种控制网络拥塞的方法、装置和网络系统
US20150071051A1 (en) * 2013-09-10 2015-03-12 Samsung Electronics Co., Ltd. Acknowledgement, error recovery and backoff operation of uplink multi-user multiple-input-multiple-output communication in wireless networks
US20150381676A1 (en) * 2012-12-27 2015-12-31 Lg Electronics Inc. Method and apparatus for multicasting/broadcasting in relay network of wireless lan system
US20160081098A1 (en) * 2013-05-21 2016-03-17 Huawei Technologies Co., Ltd. Channel competition method and device
US20160183062A1 (en) * 2014-12-19 2016-06-23 Stmicroelectronics, Inc. Multi-acked multicast protocol
CN105765893A (zh) * 2013-11-27 2016-07-13 高通股份有限公司 用于无线网络中的多播通信的系统和方法
WO2016172942A1 (zh) * 2015-04-30 2016-11-03 华为技术有限公司 确定初始竞争窗口参数的方法、站点和接入点
CN107645759A (zh) * 2016-07-20 2018-01-30 中兴通讯股份有限公司 一种组播数据传输的应答方法及装置
CN109787903A (zh) * 2019-02-28 2019-05-21 武汉晟联智融微电子科技有限公司 集中式网络中无碰撞的组播数据反馈方法
CN111052845A (zh) * 2018-02-28 2020-04-21 Lg电子株式会社 在无线通信系统中调节竞争窗口大小的方法和使用该方法的设备
WO2022148234A1 (zh) * 2021-01-08 2022-07-14 华为技术有限公司 组播反馈方法、装置及系统

Patent Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002064589A (ja) * 2000-08-14 2002-02-28 Nippon Telegr & Teleph Corp <Ntt> 応答集中回避方法
US20090279470A1 (en) * 2008-05-09 2009-11-12 Yongho Seok Device and method for multicast in wireless local access network
US20110096710A1 (en) * 2008-06-26 2011-04-28 Hang Liu Apparatus for requesting acknowledgement and transmitting acknowledgement of multicast data in wireless local area networks
CN103298027A (zh) * 2012-02-24 2013-09-11 华为技术有限公司 一种控制网络拥塞的方法、装置和网络系统
US20150381676A1 (en) * 2012-12-27 2015-12-31 Lg Electronics Inc. Method and apparatus for multicasting/broadcasting in relay network of wireless lan system
US20160081098A1 (en) * 2013-05-21 2016-03-17 Huawei Technologies Co., Ltd. Channel competition method and device
US20150071051A1 (en) * 2013-09-10 2015-03-12 Samsung Electronics Co., Ltd. Acknowledgement, error recovery and backoff operation of uplink multi-user multiple-input-multiple-output communication in wireless networks
CN105765893A (zh) * 2013-11-27 2016-07-13 高通股份有限公司 用于无线网络中的多播通信的系统和方法
US20160183062A1 (en) * 2014-12-19 2016-06-23 Stmicroelectronics, Inc. Multi-acked multicast protocol
WO2016172942A1 (zh) * 2015-04-30 2016-11-03 华为技术有限公司 确定初始竞争窗口参数的方法、站点和接入点
CN107645759A (zh) * 2016-07-20 2018-01-30 中兴通讯股份有限公司 一种组播数据传输的应答方法及装置
CN111052845A (zh) * 2018-02-28 2020-04-21 Lg电子株式会社 在无线通信系统中调节竞争窗口大小的方法和使用该方法的设备
CN109787903A (zh) * 2019-02-28 2019-05-21 武汉晟联智融微电子科技有限公司 集中式网络中无碰撞的组播数据反馈方法
WO2022148234A1 (zh) * 2021-01-08 2022-07-14 华为技术有限公司 组播反馈方法、装置及系统

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
林灿;陈柯宇;程恩;林文;: "一种学习的水声传感器网络ALOHA协议", 哈尔滨工程大学学报, no. 05, pages 1 - 7 *
韩莉;钱焕延;: "网络编码用于无线网络流媒体多播的优势分析", 计算机科学, no. 1, pages 1 - 4 *

Also Published As

Publication number Publication date
CN116033591B (zh) 2023-08-08

Similar Documents

Publication Publication Date Title
US8472365B2 (en) Method and system for acknowledgement and retransmission of multicast data in wireless local area networks
US8514763B2 (en) Apparatus for requesting acknowledgement and transmitting acknowledgement of multicast data in wireless local area networks
US11337222B2 (en) Coordinated stations in a single BSS with shared TXOP in the frequency domain
US11405944B2 (en) Coordinated stations in OBSS with shared TXOP in the frequency domain
US11516846B2 (en) RTA packet duplication in time and frequency
WO2021202372A1 (en) Coordinated wifi stations with shared txop in time domain
US11856606B2 (en) Coordinated stations in OBSS with shared TXOP in time domain
JP2023534818A (ja) 非ap staによって開始されるトリガー要求フレーム及びtxop共有
JP2023518273A (ja) ダウンリンクofdmビームフォーミング同時送信
US20220174732A1 (en) Coordinated wifi stations with shared txop among dl and ul over time domain
CN116033591B (zh) 一种组播处理方法、装置及系统
US20230199845A1 (en) Long packet and quick acking on secondary link
CN109995477B (zh) 无线自组织网络中的智能协作重传方法及其设备和系统
EP4233457A1 (en) Coordinated wifi stations with shared txop among dl and ul over time domain
US20230403741A1 (en) Transmitting and receiving via remote radio head
WO2022118136A1 (en) Coordinated stations in obss with shared txop in time domain

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