通信人家园

标题: LTE中MAC层进行HARQ在RLC层保留了ARQ是否必要 [查看完整版帖子] [打印本页]

时间: 2011-6-21 22:58

作者: winddt 标题: LTE中MAC层进行HARQ在RLC层保留了ARQ是否必要

MAC层的HARQ重传机制已经可以纠正由于信道环境造成的差错，在RLC层继续保留ARQ机制是否必要呢，如果RLC层去掉ARQ会有什么影响呢

时间: 2011-6-22 09:18

作者: jeffyko

对于某些FTP类业务，PER（Packet Error Rate）要求为10^-6，仅通过HARQ有可能不满足（比如HARQ-ACK反馈可能出错），需要通过RLC重传来保证业务QoS。
HARQ+RLC ARQ可以满足业务PDB（Packet Delay Budget）和PER的要求。

时间: 2011-6-22 13:29

作者: illidan

原帖由 jeffyko 于 2011-6-22 09:18 发表
对于某些FTP类业务，PER（Packet Error Rate）要求为10^-6，仅通过HARQ有可能不满足（比如HARQ-ACK反馈可能出错），需要通过RLC重传来保证业务QoS。
HARQ+RLC ARQ可以满足业务PDB（Packet Delay Budget）和PER的要求 ...

能否解释一下，对于PER，为啥HARQ做不到的，RLC就能做到。如果说HARQ ACK可能出错，RLC也可能出错呀。

时间: 2011-6-22 15:16

作者: jeffyko

HARQ大多数情况都能搞定，但对于TCP类业务可能不能满足其QoS要求，比如出现NACK->ACK虚警（虚警概率一般要求在10^-3~10^-4），或者即使以10% IBLER重传4次，但RBLER仍然有10^-4；此时就需要RLC ARQ机制。
另外，PER是核心网对业务QoS的要求，所以不仅包含空口误码，还有RAN/CN侧误码。
因此RLC ARQ是配合HARQ来满足业务QoS，并非谁要替代谁。

时间: 2011-6-22 15:19

作者: illidan

原帖由 jeffyko 于 2011-6-22 15:16 发表
HARQ大多数情况都能搞定，但对于TCP类业务可能不能满足其QoS要求，比如出现NACK->ACK虚警（虚警概率一般要求在10^-3~10^-4），或者即使以10% IBLER重传4次，但RBLER仍然有10^-4；此时就需要RLC ARQ机制。
另外，PER ...

比如说HARQ搞到了1e-4，RLC又是能如何实现1e-6的？这个是我不理解的地方。

另外，RLC只能管RaN侧，CN侧误不误码，它手再长也管不到啊。

时间: 2011-6-22 15:29

作者: jeffyko

呵呵，这个也好理解呀。
HARQ重传针对的是MAC PDU（即TB），而RLC重传针对的是RLC PDU。在发端将重传RLC PDU或RLC PDU分段等组装成MAC PDU，交给空口传输。

时间: 2011-6-22 16:49

作者: illidan

方案1：RLC+ max 3 times of HARQ Tx
方案2：max (3+n) times of HARQ Tx

那按你的理解，这两种可以等效不？如果可以，我不就可以扔掉RLC了么？如果不可以，理由又是什么捏？

时间: 2011-6-22 17:31

作者: jeffyko

RLC ARQ的delay较大（需要polling和status report，详细可查阅36.322 RLC协议文本），即使从误码上来看等效，但delay是完全不同的。
我觉得在系统设计上，会有很多折衷考虑。比如HARQ最大重传次数，如果你看看36.331中的HARQ重传次数：

maxHARQ-Tx ENUMERATED {
n1, n2, n3, n4, n5, n6, n7, n8,
n10, n12, n16, n20, n24, n28,
spare2, spare1} OPTIONAL, -- Need ON

最大可以到28次，但为什么一般来说maxHARQ-Tx会设置成4？因为HARQ虽然能提升边缘用户性能，但也影响到了小区平均性能，同时影响业务时延。这里如果有兴趣，可以找相关的提案来细致研究一下。
顺带提一下，LTE上行不是有个TTI Bundling吗，当然目前主要是用于VoIP业务，思路就和你说的类似。我一个Bundle同时传4个RV，不能正确接收时，再整个Bundle重传。

时间: 2011-6-22 21:17

作者: jxy

谢谢小酌怡情的讲解

时间: 2011-6-22 23:15

作者: illidan

原帖由 jeffyko 于 2011-6-22 17:31 发表
RLC ARQ的delay较大（需要polling和status report，详细可查阅36.322 RLC协议文本），即使从误码上来看等效，但delay是完全不同的。
我觉得在系统设计上，会有很多折衷考虑。比如HARQ最大重传次数，如果你看看36.33 ...

delay较大不是一个缺点吗？为什么要故意留下一个有缺点的设计呢？

时间: 2011-6-23 19:12

作者: pzx123pzx

都是高手！膜拜了！

时间: 2011-6-25 10:24

作者: eagletcjy

ARQ 有一个功能是按序提交。 HARQ则没有。因为下到MAC的SDUs在空口上传送后可能乱序。

时间: 2011-6-28 21:49

作者: winddt

按序递交是RLC的功能，但跟ARQ的关系不大。乱序递交也不是不行，只是总需要有一层来重新组包而已。
我在想，RLC层现在主要的功能就是分段/串接，ARQ和按序递交，如果把这些功能放在MAC层，这样是不是又可以省一个子层了，协议体系结构又简化了，网络的时延可以进一步缩小，系统实现时，也省去了MAC层与RLC层之间的频繁交互。

时间: 2011-6-29 10:08

作者: loseblue

原帖由 illidan 于 2011-6-22 23:15 发表

delay较大不是一个缺点吗？为什么要故意留下一个有缺点的设计呢？

这东西就是性价比的一个体现，便宜没好货，好货不便宜，

用在这里就是为了稳定性就得牺牲处理速率，要是追求速率就没法保证稳定性。

时间: 2011-6-29 18:46

作者: illidan

之前提了很多问句，现在来给些陈述句。

RLC和它的表弟HARQ都有的功能，就是ARQ。HARQ把ARQ三个字穿在身上，而表哥RLC的主要功能之一也是ARQ。

RLC有，而HARQ木有的能力，包括：

1. 按序递交（AM和UM都有）。由于HARQ是多个并发的Stop-And-WAit处理过程，所以可能会乱序。排序功能由rLC来做（在UTRA时代，MAC层，也就是MAC-hs和MAC-es也会做reordering，E-UTRA的re-ordering则完全交给RLC来做）。

2. 流量控制（仅RLC AM支持）。HARQ是个傻快的东东，没有聪明谨慎的RLC会做端到端的flow control。相当于rLC站在一个更高的层次来改善整个E-UTRAN的性能。ARQ机制是flow control的基础。

3. 时间分集（仅AM）。HARQ的和重传可能很快，在ms级，如果处于快衰的深度衰落期，几次重传可能都还是出不了深衰。而时间粒度较粗的RLC，可能在下一次重传时，信道刚好离开了深度衰落区，重传成功率大为提高。相当于在H-ARQ的基础上又加了一道保险。

[ 本帖最后由 illidan 于 2011-6-29 18:57 编辑 ]

时间: 2011-7-28 11:25

作者: smartcat_cmcc

RLC的ARQ粒度和MAC的HARQ的粒度是不一样的，因为MAC是基于RLC SDU的，而RLC是基于RLC PDU的。

时间: 2011-7-28 11:34

作者: smartcat_cmcc

HARQ与ARQ都可以通过重传来纠正传输过程中的错误，因此看起来在RLC上的ARQ是多余的，但是在某些情况下HARQ并不能够纠正所有的错误。尽管MAC层的HARQ可以纠正几乎所有的错误，但是在一些情况下依然存在错误的情况：
   1、NACK传输过程出错被理解成ACK
         2、 HARQ重传次数超过门限值
   3、这样的错误概率有可能去到1%，这对于TCP业务来说是不可以接受的，这在高速移动数据业务会导致大量性能大大降低

时间: 2011-7-30 23:44

作者: tonyang

MAC层的HARQ只能做到一定级别的BLER(对应到一定级别的PER)如1e-4, 这和MAC层的系统设计有关, 如HARQ最大重传次数, NACK->ACK虚警率, CRC虚警率等, 对于通常的业务可能1e-4的BLER已经足够, 但针对一些特殊的服务, 如TCP累业务,可能就不满足要求了. 这样就需要再加一层保护, 如RLC层加入编码(通常是CRC校验编码)+HARQ机制, 这样就可以讲PER进一步降低. 当然你可以说通过增加MAC层的最大重传次数等改善BLER性能, 或者增加对NACK->ACK虚警率的要求, CRC虚警率等, 但这样做的一个坏处是会导致MAC层的效率降低, 如增加HARQ重传次数, 因为对于末次deep fading某一次传输对应的Block块始终无法解对, 会导致MAC HARQ一直重传, 而如果换一个Block 块可能就可以解对了, 对这次没有解对的Block, 可以等过一段时间deep fading结束后(一定概率)再重传,或者用其他的Block size/coding rate传输, 可能就解对了; 再比如降低NACK-->ACK虚警率, 通常会增加ACK->NACK的miss detection rate, 这样会导致更多的无效HARQ重传, 降低传输效率. 所以了, MAC层的保护能以是按照一定的标准设计的, 这个标准通过针对常见的业务性能需求的分析和实现方便难易程度的综合考虑定下来的(这个通常就是由制定标准的那帮大牛考虑的, 呵呵)

时间: 2011-7-30 23:47

作者: tonyang 标题: 回复 15# 的帖子

15楼正解

时间: 2011-10-9 11:07

作者: tracyone 标题: 回复 2# 的帖子

请问发送端的物理层需不需要保存编码后的拷贝？

时间: 2012-1-9 22:05

作者: happyjiaju

都是牛人，学习了！

时间: 2012-1-18 11:43

作者: illidan

原帖由 smartcat_cmcc 于 2011-7-28 11:25 发表
因为MAC是基于RLC SDU的，而RLC是基于RLC PDU的。

这种似是而非的陈述怎么被人引用了这么多次。第一它没有体现任何本质特性；第二，它本身也是不正确的，至少是颠倒了。RLC根据MAC调度器的空口授权情况，将属于某个逻辑信道(DTCH)的用户面高层（如IP协议栈）数据分割、重组为RLC SDU，加上RLC header，组成RLC PDU，交给MAC层。MAC层将多个逻辑信道打包成MAC PDU（也叫TrBlk)，在空口上发送。如果遇到RLC PDU需要重传，且空口授权发生变化，RLC还会对未被确认的RLC PDU进行重新分段、打包。

时间: 2014-6-3 16:53

作者: heclong

本帖最后由 heclong 于 2014-6-3 17:11 编辑

原理大概了解了，如果系统中发现上行 MAC HARQ 成功率很高，而上行的 RLC ARQ成功率只有一半是什么原因呢？？

时间: 2014-6-3 17:17

作者: heclong

LTE系统中，RCL可以处理由于噪声、信道变化等导致的传输差错，但是多数情况下这些工作都由MAC层的HARQ协议来完成。使用RLC和基于MAC的重传机制的差异主要在于反馈信令。
HARQ用于克服由于噪声和信道变化所导致的差错传输。尽管基于MAC的HARQ是重传的主要方式，但是当期失败后还需要RLC进行重传，这种情况主要发生在反馈信令出现差错时。例如，NAK被错误地翻译成了ACK，从而引起了数据的丢失。该情况发生的概率约为1%，这对TCP业务而言差错率还是过高。规范中对于超过100Mbit/s的业务，其分组丢失率要低于10-5。TCP会把分组丢失看作是拥塞。分组差错会引起TCP的拥塞避免机制，从而像***降低发送数据速率，RLC_AM是实现TCP无差错数据传输的重要方式。
因此，可以看出LTE为什么要采用两种重传机制。HARQ的目标是快速重传，在每个TTI中它会尽快地反馈必要的1bitACK/NAK状态信息。尽管原则上ACK/NAK反馈的差错概率很小，但是低差错概率意味着较高的ACK/NAK发射功率。保持适当的发射功率就会导致出现1%的差错率，这就决定了HARQ的剩余差错率。由于RLC状态报告没有HARQ ACK/NAK发送的那样频繁，所以其获得10-5差错率的成本较低。因此，将HARQ和RLC结合可以获得较小的换回时间和合理的反馈开销，从而实现两者的互补。
由于RLC和HARQ都位于相同的节点，所以两者之间的交互是很方便的。如果HARQ检测出不可恢复的差错，那么就可以立即出发RLC状态报告的发送，而无需等到规定的时间发送，这就会导致在丢失PDU时RLC能够更快地重传。这样，在某种程度上，HARQ和RLC的组合可以看做是具有两种状态反馈机制的重传机制。

时间: 2016-6-7 19:21

作者: HesperusC

heclong 发表于 2014-6-3 17:17
LTE系统中，RCL可以处理由于噪声、信道变化等导致的传输差错，但是多数情况下这些工作都由MAC层的HARQ协议来 ...

你好，我想问一下，当出现虚警状况时，ARQ重传会立即启动重传吗，还是说等到一个合适时间再重传

通信人家园 (https://www.txrjy.com/)