这是我听过eMTC/NB/LTE最牛的一课

先来一段freestyle！

挂起-恢复流程

NB-IoT的非锚定载波的分配

UE Context Release谁发起

E-RAB Release谁发起

EPS bearer context去激活

EPS bearer，E-RAB、用户上下文和PDN连接啥关系

eMTC/NB/LTE的功控机制

eMTC终端的增强覆盖

有没有能编成曲的？我们等着你来合作哦

不闲扯了，我们来硬货。

嘿，哟，check it，切克闹，煎饼果子来一套。

来不来？

来了。

挂起-恢复流程
挂起恢复流程是eMTC/NB-IoT等蜂窝物联网技术才引进的，LTE并不具备这样的流程。这种机制的引入主要针对物联网海量连接，不活跃小数据包的特点，适时的挂起流程可以减少网络的资源开销，并且保证了物联终端的耗电。而恢复流程对于NAS的信令流程进行了优化，这样在简化信令流程的同时也可以减少海量物联对于核心网的信令冲击。

网络侧通过RRCConnectionRelease封装Suspend消息通知UE挂起，当RRC连接被挂起后，UE存储UE AS上下文和resumeIdentity，同时变为RRC_IDLE状态。挂起针对已建立的用户面承载，所以在至少一个DRB成功建立之后，挂起流程才能够执行。

如果有上行数据或者寻呼通知到来，UE会通过高层触发RRC连接恢复流程。当网络侧接收UE恢复请求后，UE从RRC_IDLE状态转变为RRC_CONNECTED状态。RRC层依据UE之前存储的AS上下文和接收来自网络侧的RRC配置信息重新对UE进行配置。RRC连接恢复流程重新激活安全机制和重建SRB和DRB。Resume请求携带resumeIdentity，该请求不被加密，但是进行MAC（message authentication code）保护。

接入网的挂起触发了核心网对于NAS层信令的挂起，挂起流程伴随着UP优化模式（user plane CIoT optimization），什么叫"伴随"呢？因为UP模式是一种不需要经过NAS信令触发获得连接，获取相应承载资源（DRB、EPS bear），因此UP优化模式流程往往都是UE被挂起后再resume执行的，可以说resume流程就是UP优化模式，resume之后不需要发送Service Request。而NAS层信令的恢复流程是由UE触发的。在UP模式下，RRC通知NAS层连接被挂起，此时UE携带悬挂指示进入EMM-IDLE模式，但并不释放NAS信令连接。根据进一步的底层指示，UE更新EMM-IDLE模式下的悬挂指示状态。当UE的NAS（UP/CP）触发RRC层恢复时，需提供RRC建立的原因值。

常用的几个原因值说明如下：
Emergency:紧急呼叫涉及的信令与业务请求，一般都是主叫发起。

mo-Signalling:一般是由于类似Attach Request/Tracking Area Update这样的NAS层信令触发,在VoLTE通话中的TAU也算作这一类型的触发原因；

mo-Data:一般由主叫Service Request/Extended Service Request触发该原因值，可以是主叫数据业务，也可以是主叫VoLTE话音/视频业务或者主叫SMSoIP业务，或者是主叫CSFB业务（CDMA2000 1xRTT例外），其中ESR里面所带服务类型标签"mobile originating CS fallback"

mt-Access:一般是被叫UE收到寻呼后触发Service Request/Extended Service Request/Control Plane Service Request，其中SR携带"PS"指示,ESR携带"packet services via S1"或者"mobile terminating CS fallback"，CPSR携带 "mobile terminating request"，这些主要针对类似数据业务寻呼响应，CSFB寻呼响应，NB/eMTC控制面传输数据业务寻呼响应

delayTolerantAcess:针对主叫数据业务，UE配置为NAS信令低优先级，那么RRC建立的原因设置为Delay tolerant。不过对于VoLTE话音( MMTEL video)，多媒体音频( MMTEL video)，SMSoIP之类的IMS业务依然设置为mo-Data类型。

mo-ExceptionData:针对NB的主叫信令发起，如果小区访问禁止，而UE允许使用接入异常事件标签，那么对于Attach/TAU/Service request可以继续发送，而RRC接入标签则可设置为mo-ExceptionData原因值。

mo-VoiceCall：如果UE支持mo-VoiceCall的设置，而且该小区通过SIB2中的 voiceServiceCauseIndication指示支持mo-VoiceCall,并且UE发起的业务是VoLTE，那么可以将RRC建立原因值设置为mo-VoiceCall。

highPriorityAccess：基于mo-Signalling请求，对于某一系列特定终端（AC11-15）可以设置该原因值，携带该值得接入对于NAS层EMM管理优先级较高，如同Emergency一样，不会由于流控被拒绝。

这些RRC侧请求携带的原因标签与NAS层的请求的优先级息息相关，NAS层可以直接通过reject消息进行流控，也可以通过S1发送OVERLOAD START通知eNodeB进行相应的流控机制触发。NAS层可以通过特定业务的NAS请求比率触发流控。而NAS和eNodeB两级流控机制可以根据实际业务请求情况进行调整，意味着可以趋缓或者激进。

当UE重选到新的小区发现TAC改变，准备发起TAU流程时，如果该小区不支持UP数据传输优化模式，那么UE就清理掉suspend indication，以"非挂起"的身份重新发起流程。

另外，当UE获悉RRC连接恢复以后，UE就进入了EMM-CONNECTED,而除了SERVICE REQUEST/CONTROL PLANE SERVICE REQUEST（不带数据包）/EXTENDED SERVICE REQUEST等NAS信令，其他的NAS初始消息都可以被发送。

我们将挂起-恢复的流程图梳理归纳下