小忽雷

UE Contention Resolution Identity: This field contains the uplink CCCH SDU

这个msg 4里携带的contention resolution ID就是msg 3里的CCCH SDU（RRCConnectionRequest, etc），原封不动的反射回去。

contention ID = 48 bits

RRCConnectionRequest = S-TMSI or Random(40bits) + cause(8bits)

为UE设置接入等级的目的是在某些情况下限制某些UE在cell的接入，例如在网络建设初期是允许运营商员工的UE接入而禁止普通大众UE的接入；在紧急情况下某些机构（如消防，医院等）的UE能够优先接入，等等。

关于不同等级的UE在该cell是否允许接入的信息 在SIB中广播，例如如果等级10不允许接入，那么小于10的等级都不允许接入。

Access Classes一共有16级，在22.011中定义。其中0-9级被随机分配给普通用户，储存在USIM卡里。11-15为特殊级别。级别10用于紧急呼叫允许控制，如果级别10在小区广播中为不允许，那么0-9用户的紧急呼叫在该小区为不允许，而11-15级的紧急呼叫允许。如果10和11同时不允许，那么11就不允许紧急呼叫。

Class 11 – reserved for PLMN use.
Class 12 – for security services.
Class 13 – for public utilities (e.g. water/gas suppliers).
Class 14 – for emergency services.
Class 15 – for PLMN staff.

1    CCE
在PDCCH上，承载DCI（Downlink Control Information）的基本单元是CCE（Control Channel Element）。每个CCE包含9个REGs（Resource Element Group），每个REG包含4个REs，也就是一个CCE是包含36个RE的一个连续资源块。那么在系统带宽和用于PDCCH的symbol数量确定后基本可以计算出总的CCE数量（从总的RE数量中去掉PCFICH，PHICH以及参考信号所占的RE，再除以36）。
CCE是如何编号的呢，是每个symbol的CCE都从0开始编号？或者symbol 1中CCE的编号从symbol 0的最后一个CCE开始递增？从36.213中计算UE-Specific Search Space起始位置的HARSH函数来看似乎是每个symbol的CCE是独立编号的，都从0开始（need confirmation）。

2    盲检
UE一般不知道当前DCI传送的是什么format的信息，也不知道自己需要的信息在哪个位置。但是UE知道自己当前在期待什么信息，例如在Idle态UE期待的信息是paging, SI；发起Random Access后期待的是RACH Response；在有上行数据等待发送的时候期待UL Grant等。对于不同的期望信息UE用相应的X-RNTI去和CCE信息做CRC校验，如果CRC校验成功，那么UE就知道这个信息是自己需要的，也知道相应的DCI format，调制方式，从而进一步解出DCI内容。这就是所谓的“盲检”过程。
那么UE是不是从第一个CCE开始，一个接一个的盲检过去呢？这也未免太没效率了。所以协议首先划分了CCE公共搜索空间（Common Search Space）和UE特定搜索空间（UE-Specific Search Space），对于不同的信息在不同的空间里搜索。
另外对于某些format的信息，一个CCE是不够承载的，可能需要多个CCE，因此协议规定了所谓的CCE Aggregation Level取值为1，2，4，8。例如对于位于公共空间里的信息Aggregation Level只有4，8两种取值，那么UE搜索的时候就先按4 CCE为粒度搜索一遍，再按8 CCE为粒度搜索一遍就可以了。
3    Seach Space
DCI信息包括
UL Grant（format 0）
DL Assignment（format 1）
Paging（format 1c）
RACH Response（format 1c）
System Information（format 1c）
MIMO Downlink Assignment（format 2）
Power Control Command（format 3）
…
可以看出，有些信息如paging, SI, RACH response是所有UE都要去监听的，有一些则是跟特定UE相关的如上下行调度指令。所以协议将CCE划分为CCE公共搜索空间（Common Search Space）和UE特定搜索空间（UE-Specific Search Space），从而提高UE的盲检效率。其中公共搜索空间是最前面的16个CCE。UE特定搜索空间的起始位置根据36.213 9.1.1中的公式计算，空间大小则和Aggregation Level有关，最小为6 CCEs最大为16 CCEs。
从36.213表9.1.1-1可以查到不同搜索空间的可能Aggregation Level取值，UE一般不知道应该使用那种Aggregation Level，所以UE能做的是把所有可能性都尝试一遍。例如对于Common Search Space，UE需要分别按Aggregation Level = 4和Aggregation Level = 8来搜索。当按AL=4搜索时，16个CCE需要搜索4次，也就是有4个Control Channel Candidates；当按AL=8搜索时，16个CCE需要搜索2次，也就是有2个CCH Candidates；那么对于公共空间一共有4+2=6个CCH Candidates。
 

对于UE Specific来说，对应于AL=1，2，4，8分别有6，6，2，2个CCH Candidates，一共有16个。

Redundancy Version

现在我们知道了HARQ发送buffer里的数据是什么样子，那么HARQ process是如何从这个buffer里取数据？首传和重传所取的数据有何不同呢？这些问题的答案都在Redundancy Version这把钥匙上。
我曾经花了较长时间来理解RV到底如何运作，直到看到36.212 - 5.1.4.1.2的这个公式才恍然大悟
 
公式里的rvidx就是RV（取值0，1，2，3），RTCsubblock就是交织矩阵的行数，也就是前面的前面的Nrow。这个计算出来的k0就是不同RV在circular buffer中的起始位置。
我们依次把rv=0,1,2,3代入公式计算一下可以看到rv=0时（首传）数据起始位置在buffer头往后挪2个交织矩阵行数。Rv=1,2,3时数据起始位置差不多依次往后挪1/4个buffer size。如下图所示。
 
图4 Redundancy Version
在下行HARQ中，每次发送数据的多少根据UE的接收soft buffer确定，这个soft buffer size可能小于发送circular buffer的大小，所以每次发送的可能只是circular buffer的部分数据；
在上行HARQ中，每次都发送circular buffer中的所有数据；

Type II和Type III Incremental Redundancy

大家都知道LTE的HARQ采用type II或type III的IR方式（type III也叫Partial IR），两者的区别是type II IR只有首传数据具有自解码功能，重传数据只是冗余比特，不具有自解码功能，需要和首传数据合并解码；而type III IR则无论首传还是重传都具有自解码功能。Type II的优点是重传包size较小（可以打孔？）因而减少对资源占用，缺点是如果首传包受损严重，则无论如何重传也无法解码成功。Type III的优点是每个包可以独立解码，但效率较低。
从图4可以清楚地看到RV=0时所选择的数据大部分是信息比特，而RV=1,2,3时则大部分是冗余比特，那么这应该是type II的方式；
对于type III的实现方式应该与图4有所区别。我的理解是：要么数据在circular buffer中的布局和图4有所区别，从而使得按RV选择数据时，每次都得到一定的信息比特和冗余比特；要么数据在circular buffer中的布局仍然一样，但按RV选取数据时不是顺序选取，而是通过一定的规则使得每个RV最终选取的数据都包含一定的信息比特和冗余比特。
以上只是一些猜测，在协议或其他资料里没有看到准确的说明。

HARQ的基本概念、几种类型（Chase Combining，Incremental Redundancy，Partial IR）以及HARQ进程的时序，反馈机制等内容相信大家都很熟悉，但如果仅停留在36.321的层面恐怕还谈不上深入理解HARQ吧。HARQ的发送端buffer内的数据是如何组织的？Redundancy Version如何理解？数据在接收端又是如何合并的？为什么接收端的数据叫Soft Bits，合并叫Soft Combining？这些问题还是要搞个清爽才好。

从Transport Block到Circular Buffer

所谓的Circular Buffer就是一个首尾相连环成一圈的一个数据结构，如同一个贪食蛇（如图1所示）。当数据进入这个缓冲区的时候，如果数据尺寸大于缓冲区尺寸，则新数据会覆盖最先进入缓冲区的那些数据；当从这个缓冲区读取数据的时候，如果读取的尺寸大于缓冲区尺寸，则缓冲区头部的那些数据会被重复读取。发送端HARQ进程使用的buffer就是这样的Circular Buffer。

图1 Circular Buffer

如果从由逻辑信道经过复用映射后得到的传输信道（Transport Channel）上待发送的数据块（Transport Block）开始，我们来看看数据是如何经过各种变化最终进入HARQ进程的发送buffer吧。 TB先要加一个24bits的CRC，然后TB被分为为合适大小的Code Block，Code Block的尺寸要看接收端soft buffer的大小吧。分段后的Code Block同样加上24bits CRC进入信道编码。

LTE中大部分信道使用的都是编码速率为1/3的turbo编码，turbo编码的原理暂时不需要理会，我们只用知道经过turbo编码后会得到3个数据流，每个数据流的长度跟code block长度差不多。其中第一个数据流是信息比特流（Information bits，也叫系统比特Systematic Bits）；第二个和第三个数据流都是校验比特流（parity bits，也叫冗余比特redundancy bits）。如下图所示。一般信息比特会在HARQ首传中传送，然后在重传中发送冗余比特，仅有冗余比特是不能自解码的，所以接收端必须把重传的冗余比特与首传的信息比特合并解码，这也就是type II的Incremental Redundancy方式。

图2 Turbo Coder

上面三路数据流再各自用一个Nrow×32的矩阵交织一下，简单地说就是按矩阵的行填入数据，按一定pattern打乱后再按矩阵的列顺序依次把数据读出来。那么现在各路数据长度从交织前的K变成了Nrow×32，如果K比Nrow×32小怎么办，没关系，在矩阵的最前面填入相应个数的NULL bit。交织矩阵的列数固定为32，行数是可变的。不同的矩阵大小得到的输出数据流长度不同，这也是个速率匹配的过程。
按我的理解在交织前应该还有一个数据打孔（puncturing）过程，当信道质量好能够适应高编码速率传输的话，我们可以把一些冗余比特puncture掉，从而提高编码速率。或者相反如果信道质量特别差需要降低编码速率的话，可以重复一些冗余比特（repetition）。但这个打孔过程在36.212里并未提及，可能是系统实现相关吧。
交织完的三路比特流按[X0,X1,…,Xk-1,P10,P11,…,P1k-1,P20,P21,…,P2k-1]的顺序放入HARQ发送端的circular buffer，得到如图3的一个待发送缓冲区。
 
图3 HARQ Circular Buffer

对于同时存在E-UTRAN及GERAN/UTRAN多种接入网络的核心网，UE可能同时注册当前位置为E-UTRAN的Tracking Area List之下或者GERAN/UTRAN之下，当UE在两种接入网的小区内移动时，为了防止UE频繁地发送位置登记消息（TAU，RAU，LAU）特设计了ISR功能，以减少UE和网络间的信令交互以及减少UE耗电。

（待续）

UE的EPS attach过程在23.401里有详细描述

UE向eNB发送Attach Request从而发起attach过程，Attach Request是一个NAS消息，通过RRC_Connection_Setup里的nas-DedicatedInformation承载，对eNB来说是透明的。

（待续）

不同用户间 PUCCH format 1/1a/1b复用: 通过正交码（3）和CAZAC序列的Cyclic Shift（12）来区分不同的用户，Cyclic Shift间隔为2，1个RB上可支持18个用户。

不同用户间 PUCCH format2/2a/2b复用: 通过CAZAC序列的Cyclic Shift（12）来区分不同的用户，1个RB上可支持12个用户。

不同用户间PUCCH format 1/1a/1b和PUCCH format 2/2a/2b的复用: 把Cyclic Shift分成两个区域，例如：

从Cyclic Shift＝0到Cyclic Shift＝3 用于PUCCH format 1/1a/1b；
从Cyclic Shift＝5 到Cyclic Shift＝10用于PUCCH format 2/2a/2b；
Cyclic Shift＝4 和Cyclic Shift＝11用于两个区域之间的保护间隔。

SFN位长为10bit，也就是取值从0-1023循环。

在PBCH的MIB广播中只广播前8位，剩下的两位根据该帧在PBCH 40ms周期窗口的位置确定，第一个10ms帧为00，第二帧为01，第三帧为10，第四帧为11。

PBCH的40ms窗口手机可以通过盲检确定。

36.331

systemFrameNumber

Defines the 8 most significant bits of the SFN. The 2 least significant bits of the SFN are acquired implicitly in the P-BCH decoding, i.e. timing of 40ms P-BCH TTI indicates 2 least significant bits (within 40ms P-BCH TTI, the first radio frame: 00, the second radio frame: 01, the third radio frame: 10, the last radio frame: 11)

codeword 是经过信道编码和速率适配以后的数据码流。在MIMO系统中，可以同时发送多个码流，所以可以有1，2甚至更多的codewords。在LTE系统中，一个TTI最多只能同时接收2个TB流，所以一般最多2个codewords；

layer和信道矩阵的“秩”（rank）是一一对应的，信道矩阵的秩是由收发天线数量的最小值决定的。例如4发2收天线，那么layer/rank = 2；4发4收天线，layer/rank=4；codeword的数量和layer的数量可能不相等，所以需要一个layer mapper把codeword流转换到layer上（串并转换）；

经过layer mapper的数据再经过precoding矩阵对应到不同的antenna port发送；