对于LTE协议栈的一些理解

写在前面

这篇文档主要想和大家讨论下我对协议栈的理解，我觉得学习协议栈最重要的是了解我们需要什么功能，为什么我们需要这些功能。这是学习协议栈的关键。其次才是我们如何实现这些功能，也就是协议上规定的实现方式。对于协议上的实现方式首先也是需要对协议栈有整体的认识，了解基本功能的实现方式以及各层各模块的分工配合，然后才是细节的处理。在这篇文档我希望能够列出协议栈需要的功能，并对应到协议栈的实现方式，从而能够从整体上对协议栈进行一个大概的介绍。后续还将对一些细节进行详细的介绍。但是毕竟经验不多，很多也是理解的不够正确，全面或者深刻，有不对的还请大家指出，希望大家能够一起讨论提高。

NAS

非接入层NAS的功能主要有4个：标识，鉴权加密，位置，业务处理。标识其实是属性，每个手机会有一个IMEI号，标识这个设备。每个SIM卡会有一个ISDN的号，比如13812345678的号码，还有一个IMSI，IMSI会包含运营商的标识。这些号码都是唯一的，如果在空口传递可能有被检测到的风险，所以对于一个已经和网络连接的手机，网络还会分配一个临时的编号GUTI，用来代替刚才提到的号码。鉴权就好像是登录MSN时输入密码一样，必须是经过运营商认证的用户在可以运营商的网络里得到正常服务。同样因为在空口传递，所以的业务必须加密，加密就会用到加密算法和加密密钥，加密算法通过信令指定，加密密钥由NAS计算。关于位置更新，UE必须经常向网络汇报自己的位置，或者在位置改变时通知网络，这样网络如果需要找到UE，比如别人打你的电话时，就可以准确找你UE。业务就是当用户要发起一个业务时，和网络协商业务信道的各个参数，比如Qos等等，并且触发建立业务信道的处理，最终为业务提供承载。

LAS

接入层的功能主要分为两部分：一部分是对业务数据的处理(主要是L2—PDCP,RLC,MAC)，一部分是对协议栈状态的维护（包括NAS和RRC）。对业务数据的处理是一个相对固定的过程，主要要求处理的性能较高。而对协议栈状态的维护因为需要处理各种各样的情况，因此处理较为复杂。

业务处理模块
首先来介绍对业务数据的处理。下面以IP业务为例。
首先我们要考虑的对用户数据的加密，用户的数据通过电磁波传送，每个人都可以接收到这些信号，所以加密就成了必须的功能。加密所用到的加密参数和加密算法都是在鉴权的时候产生的。上面提到NAS负责计算加密密钥，实际的加密操作则在这里进行。另外我们考虑到IP包的包头太长32个字节，而很可能业务数据才几个字节，无线通信的带宽本来就小，这样的业务包格式太过浪费，因此想到要把IP的包头压缩一下。在LTE中把这两部分功能放在一起给PDCP层来处理。
经过PDCP层处理的数据包可以直接发给PHY层发送了吗？暂时还不行，因为每次PHY能够发送的数据大小是固定的，和业务需要的发送的大小不匹配。比如PHY这次可以发送30字节，但是业务需要发送的包有40个字节，那么我们就需要把这个40字节的数据包分成两次发送。因此，为了把业务数据组成合适的大小给PHY发送，必须要把业务的数据包进行分段或者级联。除了考虑数据包的大小，还需要考虑数据包的确认模式和非确认传输模式。比如我们靠网络视频，这时候如果中间有几帧没有正确接收，基本不会影响观看。但是是传文件，中间少了几个字节那也必须重传。对于这两种不同的业务模式，协议栈也必须有不同的处理。对于必须正确接收的业务，引入ARQ自动重传请求（Automatic Repeat-reQuest，ARQ）的机制，协议栈在发送每一个数据包的时候必须得到对端的反馈，如果反馈接收错误就再次发送直到正确为止。而对于非确认的业务，发端只要不停的发送就可以了。这里提到的两部分功能就放在的RLC层。

经过RLC层处理的数据包可以放到PHY上发送了吗？还是不行。业务可能同时有多个，PDCP和RLC都有多个实体处理每一个业务。但是如何把同时并发的多个业务放在一起发送呢。我们还需要一个复用的模块，把PHY能够发送的大小分配给每一个业务，然后把各种业务的数据包整合在一起放到PHY上发送。MAC的功能不仅仅是分配资源，整合各个业务，同时还需要和网络交互，通知网络UE当前需要发送的业务大小，然后网络会根据MAC上报的信息再次调度上行的资源。刚才说到了RLC层的确认机制，但是这个机制还是不能够保证没有错误产生，所以我们还需要再加入一层确认机制来减小出错的概率，来尽量满足TCP协议对差错率的要求。因此LTE里引入的是HARQ机制。除了以上三部分还有如DRX(控制PHY休眠以省电)，RA(控制PHY做接入)，TA(保持和网络的同步)等功能也都是在MAC完成。

业务处理流程
每个业务承载在一个RB上，或者说对应一系列处理流程（从PDCP到MAC）。这个RB的配置里里包括了从PDCP，RLC，MAC各个层的所有属性，也就是描述了这个业务的数据包在协议栈如何一步步处理，最后在PHY资源上发送。
业务或者说RB在PDCP和RLC层各对应一个实体，在MAC层对应一个逻辑信道。MAC的功能包括把各个逻辑信道的业务汇聚到一起，汇聚到一起的信道就叫做传输信道。
当业务到来是，我们说要建立连接，建立连接的目的，对于下层来说主要为了和网络上行同步(下行同步搜小区就完成了)，并得到UE dedicated资源的配置，对于上层来说主要为了得到每一层的处理参数。这样UE就可以正确的处理数据，然后发送给网络了。
下行：PHY层收到下行业务发给MAC，MAC从DL-SCH解析出各个逻辑信道的内容，交给各个逻辑信道去处理。逻辑信道再传给RLC和PDCP处理，处理完最后交给RRC和CAS或者IP层处理。注意PCCH和BCCH纯粹是为了和业务处理的形式上的统一，这两个都没有使用MAC的包结构，和MAC几乎没有任何关系，物理层报给MAC以后，MAC直接送给RRC。和CCCH不一样，CCCH虽然没有PDCP和RLC处理，但是还是放在MAC的数据包里发送的。

上行：MAC得到PHY的发送许可grant以后，计算出汇聚以后UL-SCH可以发送的大小，然后分配到各个逻辑信道，各个逻辑信道调用PDCP和RLC处理，最后MAC再把各个逻辑信道处理好的数据汇聚到传输信道UL-SCH发送。

协议栈状态管理
为什么和TCP/IP不一样，不是各层维护自己的状态，而需要维护整个协议栈的状态呢？这个可能还是得从无线和有线的不同说起。你抱着笔记本可以到处跑，插上网线，网卡一检测到有了物理连接就可以获得IP然后上网了。可是在无线的条件下，如何完成这个物理连接的工作呢？具体实现必然由PHY层完成，但是必须有一个模块去控制PHY，这就是RRC。RRC控制PHY找到小区，和小区建立物理连接（当然是无线的），然后测量周围的小区，信号不好是换到更好的小区。其次，3GPP里业务是享有专有的链路，这个从上到下的链路需要一个模块来统一配置维护，也必须也有一个模块来维护。
状态维护主要是没有业务的IDLE状态，进行业务的CONN状态。

IDLE状态
首先是一个小区搜索驻留IDLE的过程, CAS选一个PLMN，RRC根据已有信息开始搜小区。如果没有以前的信息，就开始全频搜，发现可用的频率以后，去同步小区，同步上以后，得到小区的phy的cellid，然后开始读MIB，根据MIB再读SIB1，根据SIB1再读其他的SIB，读完系统消息判断驻留的条件，如果满足就驻留小区，就会通知CAS消息的信息配置服务小区的测量，配置paging的参数，进入IDLE状态。整个小区搜索状态完成。

UE在IDLE主要是监测当前小区的服务质量，选择驻留信号最好的suitable小区。同时也要监听paging消息，看网络是否触发UE的操作，比如在系统消息改变时通知UE重读系统消息，或者本UE被呼叫时触发连接建立。
UE在IDLE时处理任务很少，在不处理的时候可以让PHY层睡眠，以达到省电的目的，这就是DRX，网络只在某些固定的时刻给UE发送paging，这样UE就可以在其他时间选择睡眠。
当然还要完成一些特殊情况的处理，比如搜不到小区，或者突然失去覆盖等等情况的处理。
CONNETION的状态
这个过程的目的就是为了获得UE独有的PHY资源以及SRB和DRB的配置，这样UE就可以进行触发这个连接的业务了。

连接下同样需要检测信号质量，转换到质量更好的小区，但是不同于IDLE下的重选，在连接下切换由网络控制。当UE发现某些小区满足某些条件，比如有个邻小区比服务小区好很多，就会通知网络，网络就会通知UE切换到更好的邻小区。
在连接状态下，PHY层也会有一些信道质量的测量，完全由MAC控制发送，不再在RRC处理。
当然还要完成一些特殊情况的处理，比如连接建立失败，或者连接丢失等等情况的处理。


PHY
PHY的理解有限，只能介绍一些基本功能。
PHY资源
PHY资源可以分成频域，时域和码域。所以的信息bit都会经过一系列处理映射到实际的物理资源。物理资源的分为3个级别，一个是系统级别，也就是LTE系统设计的所有资源，这个就是协议里规定的所有资源。第二个是小区级别，就是某个小区的内使用的资源，一般在系统消息里广播。第三个UE级别，是针对每个UE使用的资源，一般在进入连接状态时，网络分配的dedicated的资源，这样不同的UE使用不同的资源，网络可以区分出不同的UE。
PHY信道
介绍完上层的协议，再介绍下层物理信道：
- Physical Uplink Shared Channel, PUSCH
- Physical Uplink Control Channel, PUCCH
- Physical Random Access Channel, PRACH
- Physical Downlink Shared Channel, PDSCH
- Physical Downlink Control Channel, PDCCH
- Physical Control Format Indicator Channel, PCFICH
- Physical Hybrid ARQ Indicator Channel, PHICH
- Physical Broadcast Channel, PBCH
- Physical Multicast Channel, PMCH
PUSCH 是UE用来发送各种上行业务的信道。
PUCCH是UE用来发送控制信息的信道，包括ACK/NACK，信道质量等等。
PRACH是UE用来发起接入的信道。
PDSCH是网络用来发送各种下行数据的信道，包括了系统消息(除了MIB以外的所有系统消息消息), Paging, 业务数据等等内容。
PDCCH 是最重要的调度信道，指示UE PDSCH的下行业务和调度PUSCH的上行业务，以及各种控制信息。
PCFICH用来指示PDCCH的资源的个数的信道。
PHICH 是网络用来对上行业务做反馈的信道。
PBCH是用来发送MIB的信道，位置固定，UE在获得下行同步以后就可以得到MIB的内容。
PMCH是现在还没有用的信道。
物理信道的基本过程
首先是下行同步，然后解出MIB，MIB里有PHICH的配置，根据PHICH就可以得到PCFICH的配置，然后根据PCFICH就可以得到PDCCH，通过PDCCH就可以得到PDSCH中的SIB，就可以驻留小区。
然后通过PRACH做RA，获得上行同步。之后就可以进行上下行业务。
如果收到PDCCH的上行调度，就可以根据调度中的调制方式，TBsize等在PUSCH上发送数据。网络收到上行业务以后，会在PHICH发送ACK/NACK。UE根据PHICH的反馈以及下次PDCCH上的上行调度决定是新发数据还是重传数据。
如果收到PDCCH下行调度，就可以在PDSCH接收下行业务。然后在PUCCH或者PUSCH上给网络反馈接收的情况。具体使用哪种资源可以由PDCCH调度的参数决定。网络也会根据收到的反馈决定新发还是重传。
在LTE下行资源的调度是动态的，网络可以根据当前信道质量进行调度，网络需要UE及时的反馈信道的情况，UE会在PUCCH信道反馈信道的相关情况。


详细处理
以前陆陆续续也写过一些具体的介绍，不过都还没有很好的整理，稍后将陆续贴出来和大家分享。
NAS 基本功能介绍
NAS PLMN优先级
RRC 系统消息调度
RRC IDLE小区重选
RRC DRX
RRC intra handover
RLC的AM和UM模式
MAC传输信道的汇聚
HARQ的处理
PRACH
PHICH
PUCCH