前一段本来下定决定写个白话**系列的，可是一个是到年底了事情多，一个是对自己有点放纵了，就放下了，而过了年又准备了个考试，书又翻了翻，看了看DOB和lte的资料，突然又想接着以前的写写了，理论的东西是不会落伍的，尤其是LTE，说的那么邪乎，其实你DO搞明白的话，LTE很多东西都很好理解。不说了，今天换个方式，介绍一下啊EVDO的各层，给大家理个框架，通过这个框架去看协议会省力不少，毕竟协议也是一层一层的写。水平有限，我自己看的也是云里雾里，有错误欢迎指正。
1、应用层：
DO的应用层不同于计算机的应用层，主要是承载上层协议的，如ip和ppp之类，严格的说在互联网物理层的下面。如果说这个EVDO的协议是个军队的话，这个层的主要作用就是这个军队的通信连。包含信令和流控2个方面，信令最主要的两个协议就是signal network protocol和signal link protocol（slp），AN和AT同层的用message来交流，注意是交流。而上下层则不同了，上层对下层用command（命令），而下层对上层则是indication（请示），通过这种方式保证了AT和AN之间各个层的沟通。
还有流控方面，下面重点讲讲Radiolinkprotocol协议，可以说很多人认识应用层都是通过RLP层，全称是无线链路层，这个层有个最大的特点就是顺序传递，就是如果发送方是12345这样的发送，那么接收端也必须是12345这样接收，不能乱。为了保证顺序传递，才写了rlp协议，rlp是nakbase，如果没收到就回个nak，这样的好处就是不用每收到一个包就回ack，效率高。例如如果我收到了1和3，就说明2丢了，则回一个nak，要求重传2，则必须要发起rlp重传，然后就通过上面的协议通知物理层重传2。还有一种情况，如果发送端发出最后一个包，而接收端丢了怎么办？例如12345，发5的时候丢了，接收端收到4，由于没有6所以不知道5丢了，也就不会回nak，这时候rlp协议里规定了1个计时器
，flush timer，如果发送端发了5，就开计时器，当flushtimer超时后还没有下个包要发，发送端就认为这是最后一个包，发一个flushpacket给接收端，告诉对方这是最后一个包，不用等了。
那还有一种情况，如果发了1和3,2丢了，接收端如果一直等2等不来，是不是以后的就不用发了，肯定不是，等待也是有期限的，叫abort timer，如果超时就不等了，继续往下发，那么丢失的2怎么办，给上层tcp层去纠错。实际上在后续的rlp协议了，针对某些业务也是允许丢弃一些包的，为了保证时延。其实RLP到了B版本才比较复杂了一些，有机会在讨论。
2、流层（stream）：
这个没什么可讲的，当初设计的时候想的很好，但是随着evdo的最小粒度变成了flow，stream层的作用就很尴尬。规定了4种流，0是信令，1是an stream ，2是pdsn stream，4是测试流。具体的作用能像是承接应用层流和flow流之间的一个通道。事实上我觉得完全可以用flow流来代替，在后续版本里增加了虚拟流，增加到255个流，但是考虑到flow流可以无数个，所以虚拟流还只是停留在理论阶段，没有实际应用。
3、session层，这个层主要是保存一些配置，如果继续那军队做比喻的话，这个层算是参谋，会准备N套方案，AT和AN一建立连接第一件事就是配session，告诉对方我有什么，例如，AT告诉AN我是0版本的手机，你不要给我发A的业务。或者AN告诉AT,我不支持voip业务，你不要申请这个业务了之类。当然还会给AT一个标识，叫做UATI，也是唯一合法的标识。这个层的3个协议也主要是session管理，session配置和地址管理，通过名字也知道主要干什么。
AT开机以后第一件事就是配session，申请UATI，先建立一个connection，然后是配session，主要原则就是AT先配，AN后配，最后以AN的为主，换个说法，AT先上报我的能力，AN再逐一回复，这个协商的过程是分层的，例如协商应用层，包含RLP字段，AT说我是B版本手机，我支持增强型rlp协议，AN回复说我没有，所以你还是用普通RLP协议吧。诸如此类。配完了一个session后，会继续配下一个，为什么要配多个，其实也是业务需要，AN和AT会根据不同的能力配多个session，如0版本的，A版本的，如果你从一个A版本的基站切换到0版本的基站的话，session里面的personality就会变。配完所有session后会close connection，然后激活一个session，使用一个UATI，UATI就相当于你在这个网络里的ip。
高通老师讲过一个例子，说connect层如果是高速公路的话，session就是公路上的标识牌，告诉你跑多快等等。当然session也是有时限的，目前默认是54小时，很多地市改成24小时了，也就是说你每24小时就要重新配一次session，24小时之内你无论开关机都无需再配session，当然也需要手机的支持，如果手机关机后存储器清空的话，开机会重新申请，那么上一次申请的session依然保存在AN里，只不过没用了。
RevA版本的session层，增加了手机多模能力的发现，支持接收分集，支持多套收发系统。只不过目前厂家从成本控制上还没有用，否则的话我们在DO上网的时候来电话就不会断网了，可以一套天线1x，一套天线DO。
4，连接层
这个层也没什么可讲的，和1x类似，无非就是一些状态管理啊，信令标识啊，通话管理和导频集管理。主要的协议也都是这方面的。但是DO的连接层有个3层睡眠还是很有意思的，也算是一个改进，公式写不出来，大家去资料区找找看，原理是手机睡眠1如果没有收到寻呼就会进入睡眠2，这个睡眠周期会变长，如果还没有寻呼它会进入睡眠3，睡眠时间更长，避免了频繁醒来监听控制信道，由于控制信道和业务信道物理上一同一个信道，所以减少监听的话会节约时隙给业务。
5，安全层
和1x一样，完成鉴权和加密的生成，和1x有个区别，1x的akey是写在卡里的，而DO的key是生成的，但是大家记住一点，DO的鉴权还是和终端的imsi和AN码有关。
6、mac层
主要是制定物理信道访问规则，包括DRC，功控，包的封装，发送时序等。DO的mac层应该是DO的核心思想了，时分，DSC、DRC等都是在这一层，这一层的协议也都是精华，非常值得一看，
7、物理层
频点，调制解调，编码，harq，前面的白话也都写了，大家可以回顾一下，值得一说的就是RevA的物理层emfpa支持多用户包，就是如果一个用户的信息太少，占不了一个包，那么剩下的包的空间可以分给别的用户，不想以前浪费掉，但是现网中没有用，主要的问题在于多用户包条件太苛刻，首先要这几个用户的包qos大致一样，不能把视频包和下载包放在一起吧，优先级不同，其次用户的无线环境也要差不多，因为这个包的ARQ必须所有用户都发ACK确认收到了才行，如果一个用户不ACK，整个包都要重发，也就是以前一个人同意就行，现在要好几个人同意才行，这样算下来，多用户包有时候并不见得效率高，所以现网就放弃了，但是有这么个技术。还有很多，就不在这里写了。
不好意思，又虎头蛇尾了，不过DO的精华都在mac层和物理层了，如果铺开写太多，今天回顾了一下发现好多东西都记不清了只是有个印象，看来老不翻书也不行了，如果想仔细看看协议方面的内容，去资料区搜索C.S0024。