centos8 拨号联网

Posted 2023-04-18

参考技术A 参考： https://www.jb51.net/article/173041.htm

可能提示没有PPP服务，想办法联网（比如使用路由器直连），

可能出现** Error: GPG check FAILED 由于源key错误导致的dnf安装错误
**， 添加 --nogpgcheck 就可以。

安装完重启一下电脑！！！

附：

eMTC/NB/LTE拨号

挂起-恢复流程
挂起恢复流程是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初始消息都可以被发送。

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

 

RRC连接挂起流程

 

RRC连接恢复流程某种特定的原因所触发，例如可以当UE不活跃定时器超时后进行触发。

NB-IoT的非锚定载波的分配
借鉴了GSM主辅载波的概念，NB-IoT分为锚定载波（anchor carrier）和非锚定载波(non-anchor carrier)，锚定载波承载NPSS/NSSS/NPBCH/SIB-NB等一系列的的同步，系统消息。这意味着UE在IDLE态只能驻留在主载波上进行下行同步和系统消息侦听。而非主载波则通过专属信令流程指明。UE在锚定载波进行初始随机接入，而通过专属信令指明的非锚定载波进行数据传输，那么哪些流程会指派非锚定载波呢？先上一张图。

 

如图所示，RRC在连接建立，重配，恢复，重建立等信令中都可以通知UE可以从非锚定载波接入进行数据传输。UE对于以上信令的反馈都在非锚定载波进行发送。这表示非锚定载波的接入可能分别发生在初始连接建立、小区间切换流程、RRC连接恢复流程以及RRC连接重建立流程中。

 

UE Context Release谁发起
eMTC/NB/LTE中，用户上下文释放既可以由eNodeB发起也可以由MME发起。这一释放流程不仅释放S1-AP信令连接（S1-MME），同时也释放S1-U承载。而对于eMTC/NB中的CP优化模式，这一流程之间释放了S11-U承载。由于某些特殊的原因，例如S1信令传输丢失或者eNodeB/MME某个网元的问题，用户上下文可以在某个网元进行本地释放，这样就不需要使用或者依靠如下图网元之间的信令流程了。

 

eNodeB发起释放的原因主要有：O&M网管干预，没有指定的错误，用户不活跃（定时器超时），重复的RRC信令完整性保护校验失败，UE发起的信令释放，触发CSFB，异系统重定向；

MME发起释放的原因主要有：鉴权失败，去附着，非法CSG小区。

E-RAB Release谁发起
E-RAB释放既可以由MME发起，也可以由eNodeB发起。MME发起的释放指令中包含 E-RAB To Be Released List ，这是要被释放的E-RAB。eNodeB接收到指令后，不仅需要把列表中的E-RAB释放掉，同时通过空口（Uu）把对应的DRB以及分配资源释放掉，并将S1的分配资源释放掉，同时对于释放掉的E-RAB情况通过Response指令反馈给MME。

 

 

eNodeB也可以发起E-RAB释放流程。同样在eNodeB发起的释放指示中也需要携带E-RAB Released List 从而明确需要被释放的是哪些E-RAB。注意，如果eNodeB想要清除掉所有保留的E-RAB，例如当用户不活跃定时器超时后，那么取而代之的就是发起用户上下午释放请求流程了。另外，如果eNodeB在（通过重配信令）在空口释放相应DRB时，UE无反馈或者负反馈（重配失败），或者eNodeB无法成功释放MME指令要求释放的E-RAB，那么eNodeB也会发起S1 UE Context Release Request流程。

 

 

 

 

EPS bearer context去激活
MME发起EPS承载上下文去激活请求，一般主要是如下ESM原因导致（TS 24.031）

  #8：运营商决定禁止接入

#26：资源不足

#36：正常去激活

#38：网络失败

#39：重新激活请求

#112：APN限制值与激活EPS承载上下文不兼容

#113：对于一个PDN连接不需要有多个访问接入

 

除此之外，EPS承载去激活还可以由UE发起的承载资源修改流程或者UE要求的PDN连接释放流程触发，如果是这两种原因，EPS承载去激活请求必须携带分别来自BEARER RESOURCE MODIFICATION REQUEST或者 PDN DISCONNECT REQUEST的流程交易标识PTI（procedure transaction identity）

EPS bearer，E-RAB、用户上下文和PDN连接啥关系
不闲扯，先来一张图

 

一个PDN连接可以包含多个EPS bear,其中包含至少一个默认承载（default EPS bear）和若干专属承载（dedicated EPS bear）。一个EPS bear是基于QoS建立的逻辑概念，是对一系列数据集的QoS进行归类标识的基本单位。因此，EPS Bearer本身没有上下行Bear之分。不过，一个EPS bear可以分别对应上行TFT（ traffic flow template）和下行TFT。一个TFT又可以包含若干packet filter(s)，而这些packer filter通过自身优先级标签（precedence index）的机制分别将上下行的数据包封装映射进不同的EPS bear。

 

Radio Bearer是空口侧的承载，S1 Bearer是S1对应的传输承载。E-RAB是Radio Bearer与S1 Bearer的级联。Radio Bearer与E-RAB与EPS Bear是一一对应的。

CP优化模式一般发生在上行初始接入，对于NB-IoT终端，RRC重配和RRC重建立流程都省略了。况且DRB也不建立，导致EPS bearer也没有，因此也就无从提起QoS映射。CP优化模式伴随的主要业务形态都是封装在NAS信令里的上下行小数据包，通过RRC接入信令Piggybacking进行传输，如果非要说谁的优先级比较高，那么相对于DRB承载的EPS bearer，肯定是SRB承载的NAS信令的优先级比较高了。

用户上下文是指的一个用户所有的业务，是EPS承载业务的总和，因此用户上下文释放也意味着所有E-RAB被释放了，但是LTE为了保证永远在线，默认EPS承载是不释放的，否则就属于EMM-Deregistered状态了。

一个用户有可能有多个PDN连接么？答案是肯定的，例如VoLTE语音业务和数据业务的并发。这里PDP上下文激活会通过两个APN寻址，一个是PGW出口到IMS域，一个是PGW出口到Internet(IP network)，这时就建立了两个PDN连接。
 

 

eMTC/NB/LTE的功控机制
eMTC/NB/LTE三个系统对于上行信道都是有功控机制的，对于随机接入信道采取一种步长逐步抬升的功控机制。NB简化掉了PUCCH信道和SRS信号，三个系统对于PUSCH信道的功率控制计算公式分别汇总如下：

eMTC（CE ModeA）/LTE的功控计算公式

 

二者区别不大，主要在功控步长补偿值的解码信道格式有所不同。可以看出影响功率的因素主要取决于上行调度资源，初始参数设置，距离路损，以及功控算法这四个因素。

eMTC（CE ModeB）发射功率

 

更高等级的增强型覆盖采取一直满功率发射的策略。

NB-IoT功控计算公式

 

（分配RU重复次数>2）

 

(other)

NB-IoT主要是间歇性的小包业务，因此没有像LTE采取那么复杂的功控调度算法，从计算公式直观来看功控的机制大大简化了，影响发射功率的因素仅仅取决于分配载波资源数量，初始参数设置以及路径损耗这三个因素。从另外一个角度来看，这里并没有考虑到网内干扰抬升的问题，物联网间歇式小包业务的特性导致上行干扰不会是主要矛盾，即使稍微受了一些干扰，通过资源分配调度算法把上行分配的子载波资源以及MCS同时降下来，既能保证相对稳定的数据传输，同时也把功耗降下来了。这样“不行也别硬抗”的技术思路会导致滚雪球一样的连锁效应，整网的上行底噪也得以抑制，不失为一种聪明且有趣的技术策略。

eMTC终端的增强覆盖
协议规定eMTC终端包含两种类型。一种叫BL UEs（Bandwidth reduced low complexity UEs）,另外一种叫做UE in CE(Coverage Enhanced)。随着这两种UE命名上有所不同，但是对于以深度覆盖为关注焦点之一的eMTC物联网终端都关注于增强型的覆盖。而增强型覆盖则是以增强型的覆盖技术功能进行小区接入。增强型的覆盖功能包含Mode A和Mode B两种模式，对于BL UEs，支持Mode A是必选项。不同等级对应随机接入的时频资源，以及重复次数和最大传送尝试次数是不同的。当然除了增强覆盖类型，也包括一般覆盖类型，这就与一般的覆盖技术功能是一样的。

BL UEs与UE in CE的寻呼机制是一样的，寻呼的其实时刻，重复周期与覆盖等级无关。不过，UE在能力上报中可以上报ue-RadioPagingInfo，包括UE的类型以及相应可支持的增强覆盖等级。

 

 

除了在UE能力上报中携带这一UE寻呼能力消息，在MME下发eNodeB的S1-AP信令中的Paging request也可以携带这一消息以及相应的Cell ID，目的是告知eNodeB可以采取一些定制化的寻呼策略。这两类终端还有一些共同特点，例如连接态不检测系统消息改变，空闲态不通知网络enhanced converage改变。

BL UEs还有一个特点就是传输带宽只占用6个PRB,即系统最大带宽占用1.4MHz。可以认为BL UEs是UE in CE这一类型终端分别在带宽和覆盖等级上的子集， 在一般覆盖区域两种终端可以沿用BL UEs的系统消息，而在不同的增强型覆盖等级，两种类型终端可以使用特定的系统消息。

除此之外，对于增强型覆盖类型还有个有趣的规定，就是不论在本小区处于增强型覆盖区域多么好，如果异频邻区在此处区域处于正常覆盖区域，那么UE都应重选过去，这其实类似LTE异频小区重选机制中往覆盖好的区域进行重选。当然这个目标小区如果是故障或者高干扰小区，可以通过cell bar或者调整重选参数的方式进行规避了，这属于建设后期的网络精准优化了。

看到这里就算完了，那多扫兴啊。我们也为千辛万苦，跋山涉水爬到这里的各位宝宝们留两个小问题思考

1、当UE不活跃定时器超时后，什么条件下触发挂起流程？而什么条件下又直接触发释放流程呢？

2、MME为什么不采取像eNodeB为RRC信令分配SRB机制，也为NAS信令分配个什么EPS bearer之类的呢？