- 经验
- 786
- 分贝
- 0
- 家园分
- 1111
- 在线时间:
- 71 小时
- 最后登录:
- 2016-7-8
- 帖子:
- 129
- 精华:
- 0
- 注册时间:
- 2014-11-11
- UID:
- 1069147
注册:2014-11-117
|
23#
大
中
小
发表于 2014-11-23 09:34:37
|只看该作者
我的4G之路-下行HARQ
之前,我们提及到HARQ就类似于一个快递公司,但是它比现实中的快递公司可要靠谱多了。
现实中,你的包裹交给快递后,若快递给弄丢了,最多赔点钱,再给点精神安慰。但在我们4G系统里,这个快递提供的是更人性的服务。
想像你所处的位置是RLC层,你有一个包,交给快递公司让他帮你从北京发送到上海的RLC层,即你的收件人。
北京快递公司在拿到你的包后,先不着急传。他会首先将包在传送之前进行多次拷贝,形成不同的版本(RV版本)。
我们可以简单理解对方收到每个版本都可以解析得到该包。假设北京快递分公司传送一个包到上海分公司,若对方一看,该包裹完好无损,则皆大欢喜,快递公司提交给你的收件人,同时给北京的快递分公司一个反馈,整个过程就完了。
但是若上海快递一看,该包有损害了,可能路途遥远,这个包已经惨不忍睹,有几个角给刮去了一大块,他也不会急着将该受损的包的丢弃。他会先告诉北京的快递公司进行一次重传,于是北京的快递公司将发送一个新的版本过来,上海的快递公司会将两次的传输结果进行合并,看能否拼接成完整的数据包,即HARQ中的Chase combing原理。
通常情况下,若信道确实比较差,多次合并,也无法让对方收到完整的包,快递公司也无能为力了。也只能是你的收件人打电话过来,让你亲自出马再重新去进行快递了。也就是说,若HARQ层无能为力,丢包只能由更高层即RLC层出马了。
我们假设一个周期为10天,分为周天即周0,周1、周2、…周9,下一个周期以此进行。
接下来,我们仅考虑从北京到上海这一个方向上。
假设一个很有趣的事情是:北京快递公司比较迷信,他找个大仙,掐指一算,周2、周3、周7、周8不宜发快递,只适合收(包括快递和反馈信息)。
他在周0发送了一个快递到上海,路上经历了一天,上海的快递公司办事效率也很成问题,解析包就解析了2天,一看已经周4了,也要等到周7北京可以收的时候,再给一个反馈过去。北京的快递公司在周7收到后,又用了一天弄明白对方的反馈要重传数据,于是花了两天组了一个重传包,打算在下一个周期的周1或者更晚再发送。
于是乎,假设北京快递公司就做着这一单生意,这11天里面,除了周0发送,周7得到反馈,再下一周期的周1再发重传包,至少我们可以看到,其实这11天里,大部分时间都啥都不做,不饿死才怪呢。
于是,他要找点活干,在周0发送了一个包后,他会在周1,周4,周5,周6,周9,以及下一周期的周0,全都忙活起来,每天打一个下行包发送。
以上例子中:
周0到周9即TDD系统中的典型DSUUDDSUUD的配置;
周2,周3,周7,周8为上行时隙,而其他为下行时隙;
周0发送一包,周7收到反馈,再到下一次包发送,即发送和反馈一个来回时间,即为RTT;
一共可以连续发送7包,即下行方向上7个HARQ进程。
可能有同学已经注意到了,快递公司是有苦衷的,他连续排这么多进程,其实原因在于他从第一包发出到第一个包,中间时间拖得太长了,整整11天呢,一方面是因为处理不力有时延,但一方面也和这个时隙有关。比方说,上海要发送反馈到北京的时候,已经周4了,他也必须等到周7,北京方面可以接收的时候才反馈。因此和上下行时隙配比有有很大关系的。
唉,谁让TDD系统就这么设计呢,将马路进行了限号,因为资源本身就窄,就一个单行道,不像FDD系统,财大气粗,俩马路,一个上行,一个下行,想什么时候发就什么时候发,必然其RTT时间就要短的多了(固定8ms)。
TDD系统因为比较穷,只能这么精打细算了。关于TDD和FDD系统的孰优孰劣问题,就不再此讨论了,至少出租车的司机就更愿意接入联通网络,而非移动网络,可以更快抢单! |
|