掛起-恢復流程
掛起恢復流程是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之類的呢？

eMTC/NB/LTE撥號