【原创连载】 我的4G之路（9月5日连载：240#更新）

Helloamy2014

唉,格式怎么又乱了...

Helloamy2014

通信技术你问我答 (积分兑奖)

我的4G之路-情深意重，一个都不能少之AM数据接收

上回说到若是在定时器超时之后，依然有部分人没有到达，则忽略之，已经到达的人就上车走了。但这次，情况有点变化。

还是以你们项目组一拨人去长城Team Building为例，假设你们从长城出口出发，步行去公交站。这次你们项目组同事很讲义气，比上次更加情深意重，不仅想要一个个连在一起走，而且不原意丢下任何一个人。

若一旦发现有人没有按时到达，需要发消息告知你们的发端，即长城出口。

长城出口管理员也是很讲义气的，一定要确保每个人都顺利到达公交站，于是派人一个个去催这些掉队在路上的人是否需要帮助，除非得到目的地的肯定确认。

假设你冲到上车的地方，发现人都没来，你是第一个到达的。于是你告诉公交站。

和UM模式一样，先启动定时器等待。于是公交站依然派来两位大妈，大妈甲和大妈乙，分别站在你们这拨人的对首和队尾（即你站的位置），就等等同事们。。于是再派出大妈丙去招呼后来断断续续到达的同事。

若经过了一定时间，即还是有人没到，公交站就告知发端有人没到。当然发端也可以主动来来问问，都有哪些人还没有到啊？

在公交站看来，经过了第一个等待过程后，肯定谁没来一目了然了。当然也期望继续进行新一轮等待排序，这样可以告知发端更多用户的到达状态。

我们知道大妈甲和大妈乙就是用于排序等待的，但是由于只要大妈甲等的包不到达，她就不能挪位置，于是重新派出了一位新的大妈小甲来和大妈乙一起履行重排序的过程。

于是我们可以看到，在等待第一个人到的同时，重排序等待是在持续进行的。这样就可以及时通知发端，哪些人没有到。

看完了这个，你应该明白，其实这里说大体上的就是AM的接收过程：
其实这里的大妈甲即始终坚守队首位置，即VR(R)；

大妈小甲和大妈乙负责后续的重排序排序，即VR（MS）、VR(X)；
大妈丙总是跟着最新的往前挪，即VR(H)。

基本上只需要看看VR(MS)的状态就知道哪些用户没到。

具体看下面例子

VR(R) and VR(MR)构成了接收窗口的上下边界；VR(R)之前意味着完整接收，则VR(R)更新到下一个非完整接收处， VR(X）即定时器启动时，等待的包的上界，和UM类似。从图中可见，若等待0、1，而包3到达，则UR(R)和UR(X)分别指向0、3。

若包0在定时器超时后，依然没有到达，VR(R)不挪动，即整个窗口是不可以往前挪动的。于是启动VR（MS）到下一个缺口和VR(X)分别指向3、6再进行新一轮等待。后续若包3也到达，则VR（MS）指向6，意味这6之前的包状态都定了。

从以上看，VR（MS）在首先在两种情况下被更新：

首先是：定时器超时后，指向下一缺口，此时作用完全是用于重排序定时器的下界，即大妈小甲首先是履行了大妈甲的功能。

其次:VR（MS）本身所指的包也到达之后，她将自动指向下一缺口。

有同学可能要问，VR（MR）可以等到定时器超时后，指向下一缺口啊？此时更新何故？

我理解，这样的目的是可以尽量用VR(MS)来记录更多状态信息。因为发端poll过来的时候，完全是查询VR(MS)而得知。VR（MS）用来记录经过重排序定时器排序后状态已经尘埃落定的包。VR(MS)意味着之前的包都经过了重排序定时器的洗礼。

当然若在定时器超时前收到VR(R)，则更新窗口下边界。如下所示：

我们来总结一下各变量：
VR(R)之前意味着之前的包被完整接收，即大妈甲的位置；

VR(MS)意味着之前的包都经过了重排序定时器的洗礼，即大妈小甲的位置；

VR(X)重排序定时器的最高边界，即当前最近收到的包；

VR(H)总是伴随着新包挪动。

所以从直观上看，大妈甲是最清闲的，守着一个基本不用动。其次是大妈乙，总是在定时器开启时的上边界；而大妈小甲要忙很多，定时器超时时要挪动，缺口的包到达要挪动，因为她总是反映了包的最新到达状态。

最后，再问一个问题，若VR(R)等待的包一直没到呢？发端会知道这件事情的，当它判决出该情况发生后，认为链路存在问题，作出的决定就是将这条路重新再建立一遍，即RLC达到最大重传次数的重建过程。

Helloamy2014

我的4G之路-Some fun facts about ARQ

除了昨天提及的收端主要操作，还有3个ARQ基本过程，大致摘要如下：

1）发端重传

重传即按照授权的大小组包，当重传的授权比较小时，可以对重传块进行重新分段。

2）Poll

Poll就是发信到对方问问，对方的接收情况。总共有4种poll触发条件。

在poll时，会记录到最新发送的包序号SN，若对方状态报告回来的时候，答非所问，即记录的SN依然没有得到确认，则意味这要继续在定时器超时之后再poll。意思就是铁了心的一定要等到发端要poll的SN的状态报告回来。

3）状态报告

收端状态报告的反馈将在收到poll或者重排序定时器超时检测到丢包后发送。状态报告的上报是ACK和NACK list联合上报方式，什么意思呢？

比方说，8个包，第8包正常是收到了，1-7包有些丢失，有些部分丢失，于是先记录一个ACK，即8，意味这8正常收到，再记录多个丢失包的NACK，再记录多个部分丢失包丢失的哪一块，即SOstart和SOend。若授权没有那么多，放不下，则只能对接收状态反馈给精简精简。比如填写到第五个包之前的状态。

但是，如果光了解以上的大致流程显然是不够的。其实还需要了解一下里面的细节。我大致列了一下供有好奇心的同学做进一步参考。

1）poll的触发方式？

Poll的目的是想要发端及时知道收端的状态。在收端检测到丢包时，会回复状态报告。

发端也可以主动去询问，即poll的方式。对于连续发送数据包，而收端一直没有检测到丢包时，更是需要发端去主动询问，否则导致发送窗口停滞。

直观想到的是，3G当中的周期性的触发poll。但是这是是不合适的。LTE是共享信道系统，很可能一个用户长时间都不调度。

其次基于发端发送了多少个SDU的方式。鉴于SDU个数和RLC的SN分配关系不大。因此该方式不适合。不如采用发送了每发送多少PDU和字节的方式来计数。

最后是最后一包时发送。

2）poll禁止 or 不禁止？

不需要。因为收端的状态报告禁止已经可以保证状态报告不会被频繁回复。更何况，poll的发送不会带来额外信令开销。

3）状态报告 禁止 or 不禁止？

需要避免状态报告发送太频繁。因为状态报告是采用ack和NACK list联合上报。为避免前一次重传未发送完成，下一次NACK又回复到发端，造成多于重传，因此需要避免状态报告发送太频繁。

4)状态报告重传？

状态报告丢失怎么办？是否需要重传？不需要。状态报告本身是经过了HARQ的多次传输，其次发端的poll的正确使用可以使得状态报告得以一定频度发送。

5）SDU丢弃？

SDU丢弃中，在收到PDCP丢弃指示后，已经被RLC分配了SN的SDU不丢弃？

不丢弃。假设在AM模式下，发端丢弃一些SDU，则收端检测到缺口，将不停向发端发送状态报告，要求重传。除非发端将显示通过信令通知收端不必再等那些数据包。

这样处理就太复杂了。

在下一个章节里，将说一下RLC的包结构，并补充一些设计的细节问题。

Helloamy2014

我的4G之路-你被RLC包搞晕了咩？



以下是一个UMD PDU的各式，谁能告诉我FI是个什么鬼？

-------------------------------------------华丽分割线，几个补充问题----------------------------------------

1）why we need 字节对齐？

在LTE系统中所有L2的数据包都是字节对齐的。主要是因为目前UE为32bit或者64bit的机器，任何非对齐的情况下，要先进行对齐，再处理。若数据本身就是字节对齐的，则可以节约软件处理时延和CPU处理时延。

2）Why UM SN： 5Bit &10bit

5bit开销小，用于支持voip业务。若速率比较高的业务，若5bit SN无法满足传输要求，可以使用10bit

3）AMD SN： why 10bit？

SN的长度要保证经过HARQ以及ARQ之后，高层收到的SN不混淆。因此需要分析HARQ、ARQ以及传输过程中时延总的时间内可能支持发送多少RLC PDU。之前有篇文章计算了一下在单天线下需要8bit，考虑到MIMO的情况，用10bit足够。具体内容下回再补充一下。

hhuzhangying

Helloamy2014 发表于 2015-8-23 09:43
我的4G之路-Some fun facts about ARQ

楼主，第三点状态报告中，如果第八个包正常收到，应该是ACK_SN=9吧？因为协议里讲The ACK_SN field indicates the SN of the next not received RLC Data PDU which is not reported as missing in the
STATUS PDU.

hhuzhangying

Helloamy2014 发表于 2015-8-23 09:43
我的4G之路-Some fun facts about ARQ

还想请教一个问题：协议里关于触发STATUS reporting，有一个触发条件是t_reordering超时，但是后面有一个注释是The expiry of t-Reordering triggers both VR(MS) to be updated and a STATUS report to be triggered, but the STATUS report shall be triggered after VR(MS) is updated，我想问的是：这是因为在行程STATUS PDU时，PDU SN的范围是VR(R) <= SN < VR(MS) 吗？

hhuzhangying

Helloamy2014 发表于 2015-8-23 09:52
我的4G之路-你被RLC包搞晕了咩？

看了您的讲解，终于明白FI的真正作用了，非常感谢，一定会继续关注的:)

一向如此

Helloamy2014 发表于 2014-11-27 21:42
我的4G之路-如果你想寻呼都教授(一)

文中提到"假设在一个寻呼消息里，可以放16个用户",这个是否有相关规定一个寻呼消息里最大可支持的用户个数?谢谢^_^

Helloamy2014

hhuzhangying 发表于 2015-8-24 14:55
楼主，第三点状态报告中，如果第八个包正常收到，应该是ACK_SN=9吧？因为协议里讲The ACK_SN field indic ...

是的.这个地方我之前写错了,更新一下.

Helloamy2014

hhuzhangying 发表于 2015-8-24 15:08
还想请教一个问题：协议里关于触发STATUS reporting，有一个触发条件是t_reordering超时，但是后面有一个 ...

是的,就是说MS之前的都是状态已经尘埃落定的.

Helloamy2014

一向如此 发表于 2015-8-28 15:41
文中提到"假设在一个寻呼消息里，可以放16个用户",这个是否有相关规定一个寻呼消息里最大可支持的用户个数 ...

应该有把.
哪个协议,我还得查查,其他同学可以帮忙回答以下吗?

Helloamy2014

hhuzhangying 发表于 2015-8-24 15:09
看了您的讲解，终于明白FI的真正作用了，非常感谢，一定会继续关注的

谢谢!
其他的地方你觉得都说明白了吗?

Helloamy2014

我的4G之路-我来说协议之322AM部分

本文将逐行解释协议中AM部分。鉴于在上一篇文章中，已经把各种场景都详细解释过了，因此在本文中，就不再通俗解释。

依然基于之前的R9版本。本文只是摘取了AM的接收部分的一些精华片断，这样大家就再也不用担心看不懂咯。

再次友情提醒一下大家，因为word文档贴过来的时候格式全乱了。于是，我用了图片贴过来。你们可以单独点开图片，并且放大了看。这样看着不那么费眼睛。因为有同学说，在地铁上用手机看协议，眼睛都要瞎掉啦。

hdyhz

图文并茂，谈笑间已道出4G原理之真谛，期待。。。

雨中行走

写的很好，加油

Helloamy2014

不好意思,这边比公共帐号要慢很多. 因为有时候时间比较晚,就来不及在这里更新了.

Helloamy2014

有兴趣的同学可以通过公共号察看

Helloamy2014

我的4G之路-小作怡情？论PDCP 序列号的维护

No Zuo no die.

攻城狮们经常会吐槽说，妹纸们的心思很难猜...猜来猜去都猜不明白...

大作虽然伤身，但小作绝对是怡情。

额额，我想说的是，要是一点都不作，那才是真正的危险来临呢。具体案例请见前一阵知乎上的一篇神文章“最佳前女友”。

而且，我觉得妹纸们的心思一点都不难猜啊，她一定会给你足够的暗示的！你要做的就是多一点耐心。

说到这里，我就想到PDCP。我觉得你一定会喜欢PDCP这种会玩点小作的风格，刚开始看到时候，可能一堆疑惑，但是沉心下来，你就会了解她的用意，而且一猜一个准，就像大内密探里头阿发的老婆，每次生气都躲起来但是一定会让你找她，完了还会给你煮碗面吃。

首先来看看PDCP的作体现在哪里？那就是开篇就来一段伪代码，各种判断HFN，还没看明白就晕过去了...。但其实就是在空口传输仅传SN,而HFN是不传输的，需要对方来猜测。

干嘛让对方猜来猜去，搞得这么zuo？但是你要知道她这么zuo是很有理由的。

首先要说说，为什么发送方和接收方都需要知道PDCP包的序列号即COUNT值，即HFN+SN。首先除了用于按序递交的排序，还为了AS层的安全。

AS层的安全是啥？还得从头说起：主要功能为用户面和数据面数据的加密和控制面数据的完整性保护。二者都是基于五元组原理。

以完整性保护为例：

完整性保护：5元组，其原理就是根据5个参数（Count值、消息内容、方向、承载ID、密钥）生成校验码即MAC-I，若对方收到之后基于同样的五元组生成XMAC-I；若二者相同，则意味着该消息没有经过篡改，是完整的。

由此可见，维持PDCP序号的重要性。也就是说，对方需要知道COUNT值进行校验。

注意：HFN的长度比SN长多了。于是COUNT值中的HFN由收发端本地维护并保证两侧同步，只有SN被包含在PDCP数据PDU中在空口上传输。这样既能减少协议头开销，又能增强安全性，因为中途拦截者中无法获取HFN值。所以这么看来，在你收到PDCP数据包的时候，你只知道SN，而其中HFN的获取则需要去揣测一下对方的心思。

如何猜HFN？

我们都知道HFN和SN开始都是初始化为0，而后，SN从0可以发送一个包加1，直到增大到4095之后，又回复到0开始继续增加，而此时HFN加1。所以我们可以简单理解为HFN显示的是当前发包的轮数，而SN显示的是序列号。

而何以在接收方从SN来推测HFN呢？

场景1：

假设发方就一个一个包发送数据，到接收端的时候，有部分包可能丢失，但是数据包在接收侧收到的时候还是大致有序的。

若我们发现期望接收一个数据包SN=4095，突然又接收到一个SN=1的数据包，即出现SN突然变小，那么我们就推测已经到新的一轮。此时HFN为原来的HFN+1。

场景2：
略为复杂点的场景：假如发送方在正常情况下是顺着发送数据包，而在某些场景下，数据包到达接收方的时候可能存在重复包，或者乱序包，此时情况就有点复杂。

在下图中，接收方有个重排序窗口(蓝色部分)，负责重复包的删除和排序，此时经过处理过后排序好的顺序的PDCP逐步往高层提交，即下图中Last逐渐往右移动，重排序窗口也逐步往右边移动。Next总是指向下一个当前接收到的最大的count值的下一个包。

看到这里，你应该明白，其实：

HFN总是指Next_PDCP_RX_SN所指示的HFN。Received SN的HFN的获得其实就是根据其和Next_PDCP_RX_SN的相对位置得到。

而场景1，即对应了UM模式的切换场景，因为数据包无重传，因此即便经过了重建，在接收测看到基本还是有序的。因此处理起来会简单。

而场景2则对应了AM模式的切换场景下，收端就有可能收到收端就收到了重复和乱序的数据包，因此才需要判决重排序窗口的位置以及收到的包在期望的包的左边还是右边的问题，才导致如此复杂的HFN判决。

但是不管怎么说，按照以上流程来说，总是可以猜测到正确的HFN的，是不？

Helloamy2014

我的4G之路-PDCP和RLC之间剪不断理还乱？

PDCP和RLC之间剪不断理还乱？

切换真的是一个很好的场景，能够说明白很多问题。在本章节将以切换现身说法，揭开RLC和PDCP层层交互的面纱。

首先抛出俩问题：

322协议中说：

When receiving a positive acknowledgement for an AMD PDU with SN = VT(A), the transmitting side of an AM RLC entity shall:

- set VT(A) equal to the SN of the AMD PDU with the smallest SN, whose SN falls within the range VT(A) <= SN <= VT(S) and for which a positive acknowledgment has not been received yet.

- if positive acknowledgements have been received for all AMD PDUs associated with a transmitted RLC SDU:

- send an indication to the upper layers of successful delivery of the RLC SDU.

这句话说的是，RLC层从对方得到状态报告后，若判决该RLC SDU对应的所有PDU都正常收到后，将告知PDCP SDU正常收到。RLC告诉PDCP这个有啥用？

而PDCP中有这么一段描述：

In addition, for radio bearers that are mapped on RLC AM, if the PDCP entity has previously performed the re-establishment procedure, the UE shall also consider the following as data available for transmission in the PDCP layer:

For SDUs for which a corresponding PDU has only been submitted to lower layers prior to the PDCP re-establishment, starting from the first SDU for which the delivery of the corresponding PDUs has not been confirmed by the lower layer, except the SDUs which are indicated as successfully delivered by the PDCP status report, if received:

- the SDU, if it has not yet been processed by PDCP, or

- the PDU once it has been processed by PDCP.

这句说的是，PDCP重建后，比如说切换之后，要从没有从RLC层得到的确认的第一个包传起？

这是什么意思呢？

依然以切换为例，看明白切换的场景，你应该就彻底明白了。

虽然之前从300的角度来写过切换用户面处理，但这次将从RLC和PDCP的角度来写切换。

在网络找到两张切换的示意图，原图网址：http://blog.sina.com.cn/s/blog_673b30dd0100j4p4.html。在此借用一下，对原作者表示感谢。

该图说的是在上行方向上，原基站收到1,2,4,5， 原基站将按序的包1,2提交到SGW，同时将失序的包4 以及SN status前传到目标eNB。

对于UE而言，收到了SN号为1，2和4 的PDCP PDU的确认，但3是第一个没有得到确认的包，于是将PDCP SN号为3，4，5，6的包依次向目标eNodeB发送。

目标eNodeB依据SN号来对PDCP的PDU进行排序和重复检测。于是目标enb收到包的顺序是：4, 3，4，5，6。在此例中，包4属于重复的数据包，将被丢弃。目标eNodeB将排序好的无重复的PDCP包3，4，5，6 包发送给SGW。

看到这里，你应该明白在切换的时候，乱序包以及重复包是如何造成的了。

假如没有RRC层配置PDCP的状态报告，那发送端PDCP层就得从第一个未确认的数据包开始重新发送，而这个第一个未确认数据包很有可能对方收到了，可能在切换前未来的及回复而已就已经发生了重建，于是就可能出现乱序和重复包。

假如RLC层在传输数据包3的时候，对方是真没有收到呢？

此时因为切换时重建的发生，RLC的发端将数据都丢弃，那依靠对方RLC层肯定是无法得到该包的重传包了。

我们都知道，RLC层的重传可以纠正MAC层的HARQ引起的丢包和失序，RLC层可以根据其头部的序列号来重新加以排序。而在切换的时候，RLC层的不给力只能依赖于高层，即PDCP层的重传才能保证连续性。RLC造的孽就只能PDCP来还。

既然PDCP如此如此给力， PDCP对删包是非常谨慎的，数据包必然有备份版本在，除非丢弃定时器超时，或者收到PDCP的状态报告表示对方已经收到。

PDCP即便是收到RLC的指示，也不会删除包，因为他觉得还是自己的状态报告最可靠，收到PDCP自己的状态报告才能显示删包。因为若是提早删除了，而对方RLC虽然正常接收而PDCP无法正常解压缩怎么办？此时就白删除了。

因此323中有一段描述：

5.4 PDCP discard

When the discardTimer expires for a PDCP SDU, or the successful delivery of a PDCP SDU is confirmed by PDCP status report, the UE shall discard the PDCP SDU along with the corresponding PDCP PDU. If the corresponding PDCP PDU has already been submitted to lower layers the discard is indicated to lower layers.

可见，PDCP给RLC提供了强大的后盾，切换前后序列号的连续保证了切换过程中数据的有序传输和重复检测，以及切换过程中数据的无损传输。

配置PDCP层状态报告是切换过程的一种优化。这样可以少传输一些重复包的发送。

若配置了PDCP状态报告，且4被前传到目标enb，则当用户接入到目标小区后，下行方向上第一个包就是目标eNB向UE发送的状态报告，即要求UE重传3，UE无需重传包4，只需重传包3和5以及新包6等即可。目标eNB将3，4，5, 6顺序递交到SGW。

但是这种优化行为，是否有不良后果？正如状态报告是这么填写的（要看仔细哦）：

- setting as ‘0’ in the corresponding position in the bitmap field for all PDCP SDUs that have not been received as indicated by lower layers, and optionally PDCP SDUs for which decompression have failed;

目前看来问题不大，因为状态报告中即将要选择性重传的包的反馈或许不包括解压缩失败的包，因此可能会导致选择性重传造成的有损。但毕竟这种情况处于rare error case。

最后，我们来郑重总结一下二者的关系：

本质上说，PDCP不是在RLC之上再叠加一个ARQ功能。

我觉得这段话深刻表达了PDCP和RLC之间的关系：

There is common understanding in RAN2 not to make the PDCP layer into a full ARQ layer, but just as an optimisation layer for avoiding duplication and maintain in-sequence delivery. I.e. the PDCP Status reporting and SN maintenance in the target cell is only considered an optimisation for avoiding unnecessary duplication.

所以，PDCP和RLC之间剪不断理还乱的关系你应该是理明白了吧？呵呵

P.S.对于UM和SRB不用无损，也没有重传，维护旧Count值没有任何意义，换了新基站，从0开始最方便。

副参谋byzs

感谢楼主分享，学习了很多知识