《窄帶物聯(lián)網(wǎng)（NB-IoT）原理與技術(shù)》課件第5章

第5章NB-IoT關(guān)鍵信令流程5.1無線空口RRC信令鏈路相關(guān)流程5.2附著流程5.3去附著流程5.4TA更新流程5.5業(yè)務(wù)請(qǐng)求流程5.6CP傳輸方案信令流程5.7UP傳輸方案信令流程

5.1無線空口RRC信令鏈路相關(guān)流程

5.1.1RRC連接建立流程連接建立流程是無線RRC連接建立的基礎(chǔ)，相比于LTE，NB-IoT的RRC消息進(jìn)行了簡化，NB-IoT引入了新的信令承載SRB1bis，SRB1bis的LCID為3，和SRB1配置相同，區(qū)別在于SRB1bis沒有PDCP實(shí)體，不啟用PDCP層的加密和完保措施。RRC連接建立流程創(chuàng)建SRB1的同時(shí)隱式創(chuàng)建SRB1bis。對(duì)于采用CP優(yōu)化方案來說，RRC連接建立只使用SRB1bis。

當(dāng)空閑態(tài)的UE要發(fā)數(shù)據(jù)傳輸或響應(yīng)尋呼時(shí)，可以發(fā)起RRC連接建立請(qǐng)求，NB-IoT支持四種RRC連接建立原因(RRCsetupcause)：mt-Access、mo-Signalling、mo-Data、mo-Exception-Data。這四種連接建立原因值適用場景如表5-1所示。

RRC連接建立請(qǐng)求流程：

(1)終端通過上行邏輯信道UL-CCCH在SRB0上發(fā)送RRC連接建立請(qǐng)求(RRCConnectionRequest-r13)，其中攜帶終端的初始標(biāo)識(shí)(S-TMSI)、隨機(jī)數(shù)(RandomValue)、連接建立原因或終端的多通道(Tone)支持能力。

(2)eNodeB通過下行邏輯信道DL-CCCH在SRB0上響應(yīng)RRC連接建立(RRCConnectionSetup-r13)，這條消息對(duì)應(yīng)MAC層中隨機(jī)接入步驟中的Msg4，其中攜帶有SRB1的完整配置信息，包括物理層/MAC/RLC等各個(gè)實(shí)體的配置參數(shù)。

(3)終端按照RRC連接建立消息配置完后，通過上行邏輯信道UL-CCCH發(fā)送RRC連接建立完成(RRCConnectionSetupComplete-r13)消息，這條RRC連接建立完成消息，根據(jù)需要可能會(huì)攜帶NAS信息。例如對(duì)于控制面優(yōu)化傳輸方案(CP優(yōu)化方案)，此信息可以攜帶NAS信息轉(zhuǎn)發(fā)給MME用于建立S1連接。

RRC連接建立請(qǐng)求流程如圖5-1所示。圖5-1RRC連接建立成功流程圖

如果在RRC連接第(2)步中，eNodeB拒絕為終端建立RRC連接，則通過下行邏輯信道DL-CCCH在SRB0上回復(fù)RRC連接拒絕消息(RRCConnectionReject-r13)，流程如圖5-2所示。圖5-2RRC連接建立失敗流程

5.1.2RRC連接重配流程

在NB-IoT中，RRC連接重配流程只適用于UP優(yōu)化方案，采用CP優(yōu)化方案不支持RRC連接重配流程，RRC重配流程如圖5-3所示。圖5-3RRC連接重配流程

5.1.3RRC掛起流程

RRC掛起流程是UE在無數(shù)據(jù)傳輸時(shí)釋放RRC連接，但eNodeB和MME保存UE的接入層AS的上下文信息，以便UE進(jìn)入掛起(Suspend)狀態(tài)。這個(gè)過程也稱為AS上下文緩存。RRC掛起流程如圖5-4所示。圖5-4RRC掛起流程圖

5.1.4RRC恢復(fù)流程

恢復(fù)流程(ResumeConnectionprocedure)用于恢復(fù)RRC鏈路。RRC恢復(fù)流程只適用于UP優(yōu)化方案，采用CP優(yōu)化方案時(shí)不支持RRC恢復(fù)流程。

RRC恢復(fù)流程可分為同一個(gè)MME內(nèi)恢復(fù)和不同MME恢復(fù)兩種情況，同一MME內(nèi)恢復(fù)流程如圖5-5所示。圖5-5RRC恢復(fù)流程

5.1.5RRC連接重建立流程

在NB-IoT中，RRC連接重建立流程只適用于UP優(yōu)化方案，采用CP優(yōu)化方案不支持RRC連接重建立流程，RRC連接重建立成功與失敗的流程如圖5-6所示。圖5-6RRC連接重建立成功/失敗流程圖

對(duì)于支持用戶面優(yōu)化傳輸方案的場景，當(dāng)終端發(fā)現(xiàn)無線鏈路失敗、完整性校驗(yàn)失敗以及RRC重配失敗時(shí)，會(huì)觸發(fā)RRC連接重建立的流程。

(1)終端RRC連接重建立請(qǐng)求(RRCConnectionReestablishmentRequest-r13)攜帶UE的原先鑒權(quán)內(nèi)容以及重建路由；

(2)基站收到重建立請(qǐng)求后，如果基站接受終端的重建請(qǐng)求，則回復(fù)RRC連接重建立(RRCConnectionReestablishment-r13)；

(3)終端收到RRC連接重建立消息后重建RRC鏈路，RRC鏈路建立完成后回復(fù)RRC連接重建立完成消息(RRCConnectionReestablishmentComplete-r13)。

RRC重建立流程相當(dāng)于RRC鏈路的最后挽救機(jī)制，如果重建立失敗，終端就會(huì)返回空閑態(tài)，對(duì)于時(shí)延不敏感的小包業(yè)務(wù)來說，如果重建失敗，還可重新發(fā)起RRC連接建立流程。

5.2附著流程

附著流程是用戶注冊(cè)到NB-IoT網(wǎng)絡(luò)上的流程，是用戶開機(jī)后的第一個(gè)過程，是后續(xù)所有流程的基礎(chǔ)。附著主要完成終端接入網(wǎng)絡(luò)的鑒權(quán)和加密、資源清理和注冊(cè)更新等過程。附著完成后，網(wǎng)絡(luò)記錄UE的位置信息，核心網(wǎng)相關(guān)節(jié)點(diǎn)為UE建立上下文。

由于NB-IoT引入控制面優(yōu)化傳輸方案以及用戶面優(yōu)化傳輸方案，因此相比LTE的附著流程，NB-IoT附著流程有以下特點(diǎn)：

(1)?NB-IoTUE可以支持不建立PDN連接的附著，即在附著流程中不建立PDN連接，體現(xiàn)在如圖5-7所示的完整附著流程圖中的步驟12～16可不執(zhí)行。

(2)如果NB-IoTUE和網(wǎng)絡(luò)都支持使用控制面優(yōu)化傳輸方案來傳輸用戶數(shù)據(jù)，那么UE在附著過程中即使攜帶PDN連接建立請(qǐng)求信息，網(wǎng)絡(luò)側(cè)也可以不建立用戶的無線數(shù)據(jù)承載(DRB)。這樣，UE與MME使用NAS消息來傳輸用戶數(shù)據(jù)，體現(xiàn)在圖5-7中的步驟17～24可不執(zhí)行。

一個(gè)完整的UE初始附著流程，如圖5-7所示。圖5-7完整附著流程圖

附著流程的步驟如下：

步驟1UE發(fā)起附著請(qǐng)求：UE根據(jù)NB-IoT小區(qū)的廣播消息內(nèi)容，執(zhí)行特定的附著流程，在廣播消息中指示待接入的網(wǎng)絡(luò)是否支持不建立PDN連接的附著。

(1)若網(wǎng)絡(luò)指示不支持不建立PDN連接的附著，但UE只支持不建立PDN連接的附著，則該UE不能在這個(gè)網(wǎng)絡(luò)下的小區(qū)內(nèi)發(fā)起附著流程，并觸發(fā)PLMN選擇功能，UE會(huì)選擇其他支持不建立PDN連接的網(wǎng)絡(luò)進(jìn)行附著。

(2)若網(wǎng)絡(luò)僅支持不建立PDN連接的附著，而UE只支持PDN連接的附著，則結(jié)果同上，UE也不能在該網(wǎng)絡(luò)附著。

(3)除了網(wǎng)絡(luò)指示不支持不建立PDN連接的附著和網(wǎng)絡(luò)僅支持不建立PDN連接附著而UE只支持PDN連接的附著這兩種情況，UE均可正常附著于網(wǎng)絡(luò)。

(4)如果NB-IoTUE不需要PDN連接建立，則在附著請(qǐng)求(Attachrequest)消息中不攜帶ESM消息。

(5)如果NB-IoTUE在附著過程中請(qǐng)求建立PDN連接，但是網(wǎng)絡(luò)采用控制面優(yōu)化傳輸方案(CP模式)，則網(wǎng)絡(luò)無需通過RRC重配信令為UE建立無線數(shù)據(jù)承載(DRB)，此時(shí)步驟17～22僅使用S1-APNAS傳遞以及RRC直傳(DirectTransfer)消息來傳輸附著接受和附著完成消息。

(6)如果UE支持非IP數(shù)據(jù)傳輸(Non-IP)并建立Non-IP類型的PDN連接，則ESM消息中PDN類型可設(shè)置為“Non-IP”。

(7)如果支持控制面優(yōu)化和控制面優(yōu)化頭壓縮的UE在附著流程中請(qǐng)求Ipv4、Ipv6或Ipv4v6類型的PDN連接，即附著請(qǐng)求消息中的ESM消息容器內(nèi)不僅要求攜帶的PDN類型為Ipv4、Ipv6或Ipv4v6類型，還要要求包括HCO消息以及頭壓縮上下文建立參數(shù)，HCO是包含建立ROHC信道所必需的信息。

(8)對(duì)于僅支持NB-IoT的單模終端，在請(qǐng)求短信業(yè)務(wù)時(shí)，可在附著請(qǐng)求中攜帶“非聯(lián)合注冊(cè)的短信業(yè)務(wù)”信息來標(biāo)識(shí)，以便請(qǐng)求短信業(yè)務(wù)。

(9)?NB-IoTUE不能進(jìn)行緊急業(yè)務(wù)的附著流程。

步驟2eNodeB發(fā)起附著請(qǐng)求：eNodeB通過RRC參數(shù)中老的GUMMEI和指示的選擇網(wǎng)絡(luò)查找到MME。

步驟3UE身份標(biāo)識(shí)請(qǐng)求/響應(yīng)：如果UE通過GUTI識(shí)別并且分離后MME已經(jīng)改變，新MME通過UE帶上來的GUTI找到老MME地址，再發(fā)送一個(gè)標(biāo)識(shí)請(qǐng)求消息給老MME以請(qǐng)求IMSI。

步驟4身份標(biāo)識(shí)請(qǐng)求/響應(yīng)：如果UE在老MME和新MME都未曾注冊(cè)過，則新MME發(fā)送身份標(biāo)識(shí)請(qǐng)求消息給UE以請(qǐng)求IMSI。UE給MME回應(yīng)身份標(biāo)識(shí)響應(yīng)消息。

步驟5a鑒權(quán)/安全過程：當(dāng)網(wǎng)絡(luò)側(cè)沒有UE上下文，或AttachRequest消息沒有完整性保護(hù)，或完整性檢查失敗的情況，因?yàn)樾帕畹耐暾员Ｗo(hù)和NAS加密是必需的，所以后續(xù)所有NAS消息都將使用NAS加密和完整性保護(hù)進(jìn)行保護(hù)。

步驟5b終端設(shè)備身份(ME)標(biāo)識(shí)請(qǐng)求/響應(yīng)：ME標(biāo)識(shí)應(yīng)加密傳輸。為減少信令延遲，ME標(biāo)識(shí)可以在步驟5a中的NAS安全建立過程獲取。

步驟6加密選項(xiàng)請(qǐng)求/響應(yīng)：如果UE在AttachRequest消息中設(shè)置了加密選項(xiàng)傳輸標(biāo)識(shí)，加密選項(xiàng)(如PCO)應(yīng)先通過該步驟從UE獲取。

步驟7釋放會(huì)話請(qǐng)求/響應(yīng)：如果在新MME上有用戶激活的承載，則新MME通過發(fā)送刪除會(huì)話請(qǐng)求消息給GW刪除承載。

步驟8位置更新請(qǐng)求：如果從UE上次分離后MME改變了，或MME沒有UE的有效的簽約上下文，或如果ME標(biāo)識(shí)改變，或如果UE提供的IMSI或者UE提供的老GUTI在MME沒有關(guān)聯(lián)到有效的上下文，則MME發(fā)送更新位置請(qǐng)求消息給HSS。

步驟9取消位置請(qǐng)求/確認(rèn)：HSS發(fā)送取消位置消息給老MME。老MME回應(yīng)取消位置應(yīng)答消息，刪除UE安全參數(shù)和承載上下文。

步驟10釋放會(huì)話請(qǐng)求/響應(yīng)：如果在老MME上有用戶激活的承載，則老MME通過發(fā)送刪除會(huì)話請(qǐng)求消息給GW刪除承載。GW給MME回刪除會(huì)話響應(yīng)。如果部署了PCRF，則PGW執(zhí)行IP-CAN會(huì)話結(jié)束過程來指示釋放資源。

步驟11位置更新確認(rèn)：HSS發(fā)送更新位置應(yīng)答消息給新MME，消息包含IMSI、簽約數(shù)據(jù)等。

步驟12創(chuàng)建會(huì)話請(qǐng)求：MME選擇PGW和SGW，MME向SGW發(fā)送創(chuàng)建會(huì)話請(qǐng)求消息。

步驟13創(chuàng)建會(huì)話請(qǐng)求/響應(yīng)：SGW創(chuàng)建EPS承載的新入口，發(fā)送創(chuàng)建會(huì)話請(qǐng)求消息給之前選擇的PGW。

步驟14PCEF發(fā)起的IP-CAN會(huì)話建立/釋放：如果部署了動(dòng)態(tài)PCC規(guī)則，則PGW將執(zhí)行IP-CAN會(huì)話建立過程，從而獲得UE默認(rèn)PCC規(guī)則。

步驟15創(chuàng)建會(huì)話響應(yīng)：如果部署了動(dòng)態(tài)PCC規(guī)則，則PGW執(zhí)行PCEF發(fā)起的IP-CAN會(huì)話修改過程。PGW創(chuàng)建EPS承載的一個(gè)新入口，生成一個(gè)計(jì)費(fèi)標(biāo)識(shí)。

步驟16創(chuàng)建會(huì)話響應(yīng)：SGW回復(fù)創(chuàng)建會(huì)話響應(yīng)消息給新MME。

步驟17初始上下文建立請(qǐng)求或下行NAS傳輸：MME向eNodeB發(fā)送附著接受(AttachAccept)消息。

(1)如果UE在附著過程中請(qǐng)求建立了PDN連接，且MME決定為此PDN連接建立無線數(shù)據(jù)承載，那么MME將附著接受消息包含在S1-AP初始上下文建立請(qǐng)求消息中。

(2)如果UE在附著流程中請(qǐng)求Non-IP類型的PDN連接，并且MME決定為此PDN連接建立無線數(shù)據(jù)承載，則MME除將附著接受消息包含在S1-AP初始上下文建立請(qǐng)求消息中，還要在消息中攜帶PDN類型(此時(shí)PDN類型為“Non-IP”)，指示eNodeB不執(zhí)行頭壓縮。

(3)如果UE在附著過程中請(qǐng)求建立了PDN連接，并且MME確定使用控制面優(yōu)化傳輸方案，那么MME將附著接受消息通過S1-AP下行NAS傳輸消息發(fā)送至eNodeB。

(4)如果UE在附著過程中不請(qǐng)求建立PDN連接(即UE發(fā)送的附著請(qǐng)求消息沒有攜帶ESM消息)，則MME將附著接受消息通過S1-AP下行NAS傳輸消息發(fā)送至eNodeB。

(5)如果附著過程中建立的PDN連接采用控制面優(yōu)化，且UE在附著請(qǐng)求消息中的ESM消息中攜帶HCO，若MME支持頭壓縮參數(shù)，則MME在附著接受消息中的ESM消息中包含HCO。如果UE在HCO中包含了頭壓縮上下文建立參數(shù)，則MME可向UE確認(rèn)這些參數(shù)。如果在附著過程中沒有建立ROHC上下文，則UE和MME應(yīng)在附著完成之后根據(jù)HCO建立ROHC上下文。

步驟18RRC連接重配或RRC直傳：與LTE類似，如果eNodeB收到S1-AP初始上下文建立請(qǐng)求消息，則eNodeB向UE發(fā)送RRC連接重配置消息，其包含EPS無線承載ID和附著接受消息。

(1)如果eNodeB接收到S1-AP下行NAS傳遞消息，則eNodeB向UE發(fā)送RRC直傳消息。

(2)如果采用控制面優(yōu)化或者附著請(qǐng)求消息中沒攜帶ESM消息，則步驟19和步驟20不執(zhí)行。

步驟19?RRC重配完成：eNodeB發(fā)送包含EPS無線承載標(biāo)識(shí)的RRC連接重配消息及AttachAccept消息給UE。

步驟20初始上下文響應(yīng)：UE發(fā)送RRC連接重配完成消息給eNodeB。

步驟21直傳：UE發(fā)送直傳消息給eNodeB，該消息包含AttachComplete消息。eNodeB通過上行NAS傳輸消息透傳AttachComplete消息給新MME。

步驟22附著完成：eNodeB發(fā)送初始上下文響應(yīng)消息給新MME。

(1)如果步驟1中的附著請(qǐng)求消息中攜帶ESM消息，則UE在收到附著接受消息及UE獲得IP地址信息后，UE可以向eNodeB發(fā)送上行數(shù)據(jù)包。

(2)如果采用控制面優(yōu)化傳輸方案且UE在附著請(qǐng)求過程中請(qǐng)求建立PDN連接，則上行數(shù)據(jù)的發(fā)送見5.6節(jié)CP傳輸方案信令流程。

步驟23修改承載請(qǐng)求：新MME接收到步驟21的初始上下文響應(yīng)消息和步驟22的AttachComplete消息，新MME發(fā)送修改承載請(qǐng)求消息給SGW。

(1)如果UE使用控制面優(yōu)化且PDN連接是連接到SGW、PGW的，則步驟23a、23b、24不執(zhí)行。

(2)當(dāng)PDN連接是連接到SCEF的，則步驟23～26不執(zhí)行。

步驟23a修改承載請(qǐng)求：如果步驟23包含承載修改指示，則SGW發(fā)送修改承載請(qǐng)求消息給PGW，使其將報(bào)文從非3GPP接入切到3GPP接入，立即將報(bào)文發(fā)給SGW。

步驟23bPGW發(fā)起修改承載響應(yīng)：PGW向SGW發(fā)送修改承載響應(yīng)消息。

步驟24SGW發(fā)起修改承載響應(yīng)：SGW向新MME發(fā)送修改承載響應(yīng)消息。SGW可發(fā)送緩存的下行報(bào)文。

步驟25通知請(qǐng)求：新MME接收到SGW發(fā)送的修改承載響應(yīng)消息。如果請(qǐng)求類型沒有指示承載修改，且MME選擇的PGW不同于HSS簽約PDN上下文的PGW標(biāo)識(shí)，則MME應(yīng)發(fā)送通知請(qǐng)求消息給HSS。

步驟26通知響應(yīng)：HSS保存APN和PGW標(biāo)識(shí)，發(fā)送通知響應(yīng)消息給MME。

5.3去?附?著?流?程

當(dāng)UE不需要或者不能夠繼續(xù)附著在網(wǎng)絡(luò)時(shí)，將發(fā)起去附著流程。去附著流程分為顯示去附著和隱式去附著兩種。(1)顯示去附著：由網(wǎng)絡(luò)或UE通過明確的信令方式去附著。(2)隱式去附著：網(wǎng)絡(luò)注銷UE，不通過信令方式告知UE。

根據(jù)發(fā)起方不同，去附著過程可分為UE側(cè)發(fā)起或網(wǎng)絡(luò)側(cè)MME發(fā)起的去附著過程。

(1)如果UE不存在激活的PDN連接，那么去附著流程中不存在MME-SGW-PGW網(wǎng)元間的信令。

(2)如果UE存在激活的PDN連接，則去附著流程與LTE流程類似。

5.3.1UE發(fā)起的去附著流程

UE發(fā)起的去附著流程如圖5-8所示，主要是步驟2與LTE的去附著流程存在差異，區(qū)別是UE有無激活的PDN連接。圖5-8UE發(fā)起的去附著流程

步驟1去附著請(qǐng)求：UE發(fā)送DetachRequest消息給MME。

步驟2釋放會(huì)話請(qǐng)求：MME按每PDN連接發(fā)送釋放會(huì)話請(qǐng)求消息給SGW。

(1)如果UE沒有激活的PDN連接，則步驟2～8不需要執(zhí)行。

(2)如果UE存在到SCEF的PDN連接，則MME向SCEF指示UE的PDN連接不可用，而不需執(zhí)行步驟2～8。

(3)如果UE存在到PGW的PDN連接，則MME向SGW發(fā)送釋放會(huì)話請(qǐng)求消息。

步驟3釋放會(huì)話響應(yīng)：SGW響應(yīng)“釋放相關(guān)承載”信息，把“刪除會(huì)話請(qǐng)求消息(TEID)”發(fā)送給PGW。

步驟4分離通知：MME通知SGSN釋放舊會(huì)話(LTE才會(huì)有本步驟，NB-IoT中不存在步驟4和步驟5)。

步驟5SGW釋放會(huì)話請(qǐng)求：SGSN通知SGW釋放舊的會(huì)話。

步驟6PGW釋放會(huì)話請(qǐng)求：PGW給SGW返回刪除會(huì)話響應(yīng)消息(TEID)。

步驟7、8釋放會(huì)話響應(yīng)：如果部署了PCRF，則PGW執(zhí)行PCEF發(fā)起的IP-CAN會(huì)話結(jié)束流程去指示PCRF釋放EPS承載。

步驟9釋放會(huì)話響應(yīng)：SGW向MME發(fā)送刪除會(huì)話響應(yīng)消息(TEID)。

步驟10去附著響應(yīng)：如果關(guān)機(jī)指示分離不是由關(guān)機(jī)引起的，則MME發(fā)送去附著接受(DetachAccept)給UE。

步驟11去附著接受：MME發(fā)送S1釋放信令給eNodeB，用于釋放UE的S1-MME信令連接。

步驟12信令連接釋放：eNodeB釋放無線信令連接。

5.3.2MME發(fā)起的去附著流程

與UE發(fā)起的去附著流程類似，同樣在步驟2中會(huì)依據(jù)UE是否存在激活的PDN連接，而會(huì)有相應(yīng)的流程。本小節(jié)只列出有區(qū)別的步驟，如圖5-9所示，其余相同步驟詳見5.3.1UE發(fā)起的去附著流程。圖5-9MME發(fā)起的去附著流程

步驟1去附著請(qǐng)求：MME發(fā)送NAS去附著請(qǐng)求消息(DetachRequest)給UE。

步驟2釋放會(huì)話請(qǐng)求：MME按PDN連接發(fā)送釋放會(huì)話請(qǐng)求消息給SGW。

(1)如果UE沒有激活的PDN連接，則步驟2～8不需要執(zhí)行。

(2)如果UE存在到SCEF的PDN連接，則MME向SCEF指示UE的PDN連接不可用，而不需執(zhí)行步驟2～8。

(3)如果UE存在到PGW的PDN連接，則MME向SGW發(fā)送釋放會(huì)話請(qǐng)求消息。

5.4TA?更?新?流?程

TA是位置跟蹤區(qū)域，與LTE相比，NB-IoTUE觸發(fā)跟蹤區(qū)更新流程條件還包括UE支持的網(wǎng)絡(luò)行為信息發(fā)生變化。由于NB-IoT終端一般不移動(dòng)(注：通常僅在基站新入網(wǎng)時(shí)采用移動(dòng)終端進(jìn)行業(yè)務(wù)驗(yàn)證)，R13協(xié)議版本不支持2G/3G網(wǎng)絡(luò)中接入，因此僅支持SGW不變的TA更新流程(TrackingAreaUpdate，TAU)，如圖5-10所示。圖5-10SGW不變的TAU更新流程

步驟1觸發(fā)TAU流程：UE根據(jù)條件判決，觸發(fā)TAU流程。

步驟2UE向eNodeB發(fā)起TAU請(qǐng)求：消息內(nèi)包含支持及偏好的網(wǎng)絡(luò)行為。

(1)如果UE沒有激活任何PDN連接，則TAU中不攜帶激活標(biāo)記或EPS承載狀態(tài)字段。

(2)如果UE激活Non-IP類型的PDN連接，則UE需在TAU請(qǐng)求消息中攜帶EPS承載狀態(tài)。

(3)TAU請(qǐng)求消息中還攜帶信令激活標(biāo)識(shí)字段來指示網(wǎng)絡(luò)是否應(yīng)該保留UE與MME之間的NAS信令連接。

步驟3eNodeB向新MME發(fā)起TAU請(qǐng)求：eNodeB根據(jù)舊GUMMEI得到MME地址，并將TAU消息轉(zhuǎn)發(fā)給新MME，轉(zhuǎn)發(fā)消息中還需攜帶小區(qū)的無線接入類型(RAT)，以區(qū)分是NB-IoT還是LTE系統(tǒng)。

步驟4新MME向舊MME查詢UE的上下文：新MME根據(jù)GUTI獲取原MME地址，并向其發(fā)送上下文請(qǐng)求消息來獲取用戶的移動(dòng)性管理和承載上下文信息。如果新MME支持NB-IoT優(yōu)化傳輸功能，則本消息中還攜帶NB-IoT優(yōu)化支持信息，用于指示新MME所支持的NB-IoT優(yōu)化方案，例如支持控制面優(yōu)化的頭壓縮功能等。

步驟5舊MME向新MME響應(yīng)上下文查詢：如果UE沒有激活任何PDN連接，則上下文響應(yīng)消息中不攜帶EPS承載相關(guān)信息。

針對(duì)NB-IoT優(yōu)化支持信息及MME的支持能力，有如下情況：

(1)如果舊MME支持NB-IoT優(yōu)化功能，但新MME不支持，則此時(shí)舊MME不會(huì)將Non-IP的PDN連接信息傳送給新MME。

(2)如果某個(gè)PDN連接的所有EPS承載上下文沒有被完全轉(zhuǎn)移到新MME，則舊MME會(huì)將該P(yáng)DN連接的所有承載視為失敗，并觸發(fā)MME請(qǐng)求的PDN連接釋放流程。同時(shí)原MME在收到上下文確認(rèn)消息后丟棄其所緩存的數(shù)據(jù)。

(3)在R13版本協(xié)議中，不支持UE從NB-IoT移動(dòng)到LTE或者從LTE移動(dòng)到NB-IoT，當(dāng)UE發(fā)生這兩種移動(dòng)過程時(shí)，MME將要求UE進(jìn)行重新附著。

步驟6鑒權(quán)/安全過程。

步驟7上下文確認(rèn)：新MME與舊MME進(jìn)行上下文確認(rèn)，如果UE沒有激活任何PDN連接，則步驟8～11不需執(zhí)行。

步驟8修改承載請(qǐng)求：新MME向SGW發(fā)起修改承載消息，消息中攜帶MME的控制面IP地址和TEID。

步驟9修改會(huì)話請(qǐng)求/響應(yīng)：SGW創(chuàng)建EPS承載的新入口，發(fā)送創(chuàng)建會(huì)話請(qǐng)求消息給之前選擇的PGW。

步驟9aPCEF發(fā)起的IP-CAN會(huì)話建立/釋放：如果部署了動(dòng)態(tài)PCC規(guī)則，則PGW執(zhí)行IP-CAN會(huì)話建立過程，從而獲得UE默認(rèn)PCC規(guī)則。

步驟10修改會(huì)話響應(yīng)：如果部署了動(dòng)態(tài)PCC規(guī)則，則PGW執(zhí)行PCEF發(fā)起的IP-CAN會(huì)話修改過程，創(chuàng)建一個(gè)EPS承載的新入口，生成一個(gè)計(jì)費(fèi)標(biāo)識(shí)，并給SGW返回創(chuàng)建會(huì)話響應(yīng)消息。

步驟11SGW發(fā)起的修改會(huì)話響應(yīng)：SGW更新承載上下文并向新MME返回修改承載響應(yīng)消息。

步驟12位置更新請(qǐng)求：新MME發(fā)送更新位置請(qǐng)求消息給HSS。

步驟13～14取消位置請(qǐng)求/確認(rèn)：HSS發(fā)送取消位置消息給老MME。老MME回應(yīng)取消位置應(yīng)答消息，刪除舊MME相關(guān)的承載上下文。

步驟15位置更新確認(rèn)：HSS發(fā)送位置更新確認(rèn)消息給新MME。

步驟16TAU接受：MME向UE回應(yīng)TAU接受消息，并告訴UE新的GUTI信息。

步驟17TAU完成：UE通過跟蹤區(qū)完成(TrackingAreaUpdateComplete)消息發(fā)送給新MME，以確認(rèn)新的GUTI。

5.5業(yè)務(wù)請(qǐng)求流程

5.5.1UE發(fā)起的業(yè)務(wù)請(qǐng)求流程與LTE類似，當(dāng)UE發(fā)起業(yè)務(wù)連接時(shí)，會(huì)發(fā)起業(yè)務(wù)請(qǐng)求(ServiceRequest)流程，即使UE和網(wǎng)絡(luò)僅支持控制面優(yōu)化傳輸方案或用戶面優(yōu)化傳輸方案，處于空閑態(tài)(ECM-IDLE)的UE也可通過業(yè)務(wù)請(qǐng)求流程建立無線資源承載。UE發(fā)起業(yè)務(wù)請(qǐng)求的流程如圖5-11所示。

步驟1RRC連接建立攜帶：UE附著網(wǎng)絡(luò)后轉(zhuǎn)為空閑態(tài)，當(dāng)有業(yè)務(wù)要發(fā)送時(shí)，UE要將發(fā)給MME的NAS信令(ServiceRequest)封裝在RRC包中，通過RRC信息發(fā)送到eNodeB。

步驟2S1-AP初始UE消息：eNodeB通過S1-AP初始UE消息將UE的NASPDU轉(zhuǎn)發(fā)給MME。

步驟3完整性校驗(yàn)及解密數(shù)據(jù)：MME檢查NASPDU的完整性，然后解密數(shù)據(jù)，觸發(fā)鑒權(quán)及安全加密過程。MME根據(jù)配置需要執(zhí)行安全相關(guān)的流程，步驟4～9可與安全相關(guān)流程并行執(zhí)行，但步驟10和步驟11只可等到安全相關(guān)流程完成后再執(zhí)行。

步驟4～7建立S11-U承載，如果S11-U未建立，則MME向SGW發(fā)送修改承載消息，消息中攜帶MME下行用戶面IP地址和TEID，建立S11-U承載。

步驟8上行數(shù)據(jù)：S11-U承載建立成功后，MME將上行數(shù)據(jù)經(jīng)SGW發(fā)送給PGW。

步驟9下行數(shù)據(jù)：如果在步驟1中未攜帶期望下行數(shù)據(jù)接收，當(dāng)上行數(shù)據(jù)傳送完畢后，MME執(zhí)行步驟14的S1連接釋放過程。如果步驟1攜帶期望下行數(shù)據(jù)接收，則開始接收下行數(shù)據(jù)。

步驟10數(shù)據(jù)加密及完整性保護(hù)：MME將步驟9中接收到的下行數(shù)據(jù)進(jìn)行加密和完整性保護(hù)。

步驟11下行S1-AP消息：MME將下行數(shù)據(jù)封裝在NASPDU中，在S1-AP下行消息中將NASPDU發(fā)送給eNodeB。

步驟12RRC下行直傳：eNodeB向UE發(fā)送RRC下行數(shù)據(jù)消息，將封裝下行數(shù)據(jù)的NASPDU下發(fā)給UE，若同時(shí)收到MME的S1-APUE上下文釋放指令消息，則eNodeB會(huì)先發(fā)送NASPDU，再執(zhí)行步驟14釋放連接。

步驟13檢測是否有數(shù)據(jù)傳輸：eNodeB檢測下行數(shù)據(jù)傳輸，如果持續(xù)一段時(shí)間沒有NASPDU傳輸，則進(jìn)入步驟14進(jìn)行S1鏈路釋放。

步驟14S1-AP連接釋放過程：eNodeB或MME觸發(fā)S1釋放流程。

5.5.2網(wǎng)絡(luò)觸發(fā)的業(yè)務(wù)請(qǐng)求流程

網(wǎng)絡(luò)觸發(fā)的業(yè)務(wù)請(qǐng)求流程主要是網(wǎng)絡(luò)收到下行數(shù)據(jù)后，向UE發(fā)起尋呼，UE收到尋呼信息后，發(fā)起正常的服務(wù)請(qǐng)求流程，其流程如圖5-12所示。圖5-12網(wǎng)絡(luò)觸發(fā)的業(yè)務(wù)請(qǐng)求流程

步驟1下行數(shù)據(jù)：下行數(shù)據(jù)到達(dá)SGW。當(dāng)SGW收到UE的下行數(shù)據(jù)包或下行控制信令時(shí)，SGW先緩存UE的用戶數(shù)據(jù)。

步驟2下行數(shù)據(jù)通知/確認(rèn)：SGW向MME發(fā)起下行數(shù)據(jù)通知，MME收到下行數(shù)據(jù)通知后，向SGW確認(rèn)并回復(fù)下行數(shù)據(jù)通知確認(rèn)信息。

步驟3MME開始尋呼UE：如果UE已在MME注冊(cè)并且處于尋呼可達(dá)狀態(tài)，則MME向UE已注冊(cè)的跟蹤區(qū)內(nèi)的每個(gè)eNodeB發(fā)送尋呼消息，消息中攜帶尋呼的NASID和跟蹤區(qū)標(biāo)識(shí)信息。

步驟4eNodeB收到來自MME的尋呼消息：在空口發(fā)送尋呼消息。

步驟5服務(wù)請(qǐng)求流程：UE收到尋呼后，響應(yīng)尋呼消息，發(fā)起服務(wù)請(qǐng)求流程，后續(xù)流程與UE發(fā)起的業(yè)務(wù)請(qǐng)求流程相同。

5.6CP傳輸方案信令流程

CP傳輸方案(DataoverNAS)是用控制面消息傳遞用戶數(shù)據(jù)的方法。其目的是減少UE接入過程中的空口消息交互次數(shù)，節(jié)省UE傳輸數(shù)據(jù)的功耗。CP傳輸方案端到端信令流程，以UE向網(wǎng)絡(luò)發(fā)起數(shù)據(jù)傳輸流程為例，如圖5-13所示。圖5-13UE向網(wǎng)絡(luò)發(fā)起數(shù)據(jù)傳輸時(shí)的信令流程

步驟0UE處于空閑態(tài)：UE已經(jīng)完成附著，且當(dāng)前狀態(tài)為空閑狀態(tài)(ECM-IDLE)。

步驟1RRC連接建立：UE建立RRC連接，發(fā)送受完整性保護(hù)的NAS數(shù)據(jù)包(NASPDU)。NASPDU攜帶EPS承載ID(EPSBearerID)和加密上行數(shù)據(jù)。對(duì)于配置，為支持報(bào)頭壓縮的IPPDN類型的PDN連接，UE應(yīng)該在將數(shù)據(jù)封裝到NAS消息之前應(yīng)用報(bào)頭壓縮。UE還可以在NASPDU中的輔助信息中表明，是否預(yù)期不再進(jìn)行上行或下行數(shù)據(jù)傳輸，或者預(yù)期在此上行數(shù)據(jù)傳輸之后僅進(jìn)行一次下行數(shù)據(jù)傳輸(如對(duì)上行數(shù)據(jù)的確認(rèn)或響應(yīng))。

步驟1b恢復(fù)UE上下文：在NB-IoT系統(tǒng)中，eNodeB基于配置信息，可以從MME檢索EPS協(xié)商后的QoS配置文件。RRCConnectionRequest報(bào)文中S-TMSI中的MME代碼用于識(shí)別MME。在網(wǎng)絡(luò)共享的情況下，MME代碼在運(yùn)營商的MME池內(nèi)是唯一的。eNodeB可以在觸發(fā)步驟2之前在RRC連接中依據(jù)UE優(yōu)先級(jí)建立相應(yīng)資源承載。

步驟2S1-AP初始UE消息：在步驟1中發(fā)送的NASPDU由eNodeB使用S1-AP初始UE消息(S1-APInitialUEmessage)轉(zhuǎn)發(fā)到MME。為了協(xié)助定位服務(wù)，eNodeB向MME指示UE的覆蓋級(jí)別。

步驟3完整性校驗(yàn)及解密數(shù)據(jù)：MME檢查NAS消息的完整性，如果MME中用于衡量UE活躍時(shí)長的計(jì)時(shí)器超時(shí)，則MME會(huì)拒絕UE收聽尋呼時(shí)發(fā)起的被叫數(shù)據(jù)連接請(qǐng)求，并通過NASPDU返回拒絕原因。MME還可以為UE提供一個(gè)移動(dòng)管理備份計(jì)時(shí)器，設(shè)置為UE活躍時(shí)長計(jì)時(shí)器的剩余值，然后執(zhí)行步驟15。

步驟4修改承載請(qǐng)求：MME發(fā)送ModifyBearerRequest消息到SGW，消息中攜帶MME的下行傳輸?shù)刂贰?/p>

步驟5PGW修改承載請(qǐng)求：當(dāng)UE位置信息中攜帶的位置信息發(fā)生改變時(shí)，SGW會(huì)通過ModifyBearerRequest消息通知PGW，讓PGW改變?cè)纫呀?jīng)建立的承載。

步驟6修改承載響應(yīng)：PGW完成承載修改后，給SGW回復(fù)承載修改完成(ModifyBearerResponse)。

步驟7SGW修改承載響應(yīng)：SGW把承載修改完成信息告知MME，消息中攜帶上行傳輸?shù)腟GW地址和TEID。

步驟8上行數(shù)據(jù)：MME收到SGW的承載修改響應(yīng)消息(ModifyBearerResponse)后，UE可通過NAS進(jìn)行上行數(shù)據(jù)傳輸。

步驟9下行數(shù)據(jù)：在RRC連接激活期間，UE還可以在NAS消息中發(fā)送上行數(shù)據(jù)，上行數(shù)據(jù)中攜帶ReleaseAssistanceInformation。如果在步驟1的ReleaseAssistanceInformation中沒有下行數(shù)據(jù)指示，MME將上行數(shù)據(jù)發(fā)送給PGW后，立即釋放連接，執(zhí)行步驟15。否則，進(jìn)行下行數(shù)據(jù)傳輸。如果沒有接收到數(shù)據(jù)，則跳過步驟11～14進(jìn)行S1鏈路釋放。

步驟10數(shù)據(jù)加密及完整性保護(hù)：MME接收到下行數(shù)據(jù)后，會(huì)進(jìn)行加密和完整性保護(hù)。

步驟11下行S1-AP消息：如果接收到下行數(shù)據(jù)，則MME會(huì)在NAS消息中下發(fā)給eNodeB。如果上行數(shù)據(jù)中的ReleaseAssistanceInformation指示有下行數(shù)據(jù)，則MME不會(huì)釋放S1鏈路，直到上行數(shù)據(jù)傳送結(jié)束后，MME釋放S1鏈路。

步驟12RRC下行直傳：eNodeB將NAS數(shù)據(jù)下發(fā)給UE，若此時(shí)收到MME的S1釋放指示，則會(huì)在NAS數(shù)據(jù)下發(fā)后釋放RRC連接。

步驟13檢測是否有數(shù)據(jù)傳輸：如果網(wǎng)絡(luò)設(shè)置eNodeB向MME發(fā)送NAS交付指示(NASDeliveryindication)，則eNodeB需要把發(fā)送NAS數(shù)據(jù)成功與否的狀態(tài)響應(yīng)反饋給MME。

步驟14未檢測到進(jìn)