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