本發(fā)明涉及通信領(lǐng)域，具體涉及一種支持機(jī)器類通信設(shè)備數(shù)據(jù)傳輸?shù)姆椒ê脱b置。

背景技術(shù)：

隨著無線通信技術(shù)的迅猛發(fā)展和人們通信需求的日益增加，5g時代即將來臨。5g的一個重要應(yīng)用就是機(jī)器類通信(mtc，machinetypecommunication)，mtc擁有大規(guī)模的潛在應(yīng)用前景，使其贏得大量移動網(wǎng)絡(luò)運營商、設(shè)備制造商、研究機(jī)構(gòu)的廣泛關(guān)注。mtc主要應(yīng)用領(lǐng)域包括智能電網(wǎng)、智能交通、智能家居、遠(yuǎn)程測量、無線傳感器網(wǎng)絡(luò)等，是新興物聯(lián)網(wǎng)的重要組成部分。

mtc設(shè)備支持的業(yè)務(wù)是多樣的。大多數(shù)mtc設(shè)備的要求通常是低成本和低功耗，如用于環(huán)境監(jiān)測或者農(nóng)業(yè)的大量傳感器等。mtc設(shè)備支持的業(yè)務(wù)一般是低速率的，但是也可能有需要傳輸大數(shù)據(jù)的情況。mtc設(shè)備支持的業(yè)務(wù)一般對時延要求不高，但是也可能有緊急事件需要快速傳輸?shù)那闆r。

例如對于火警報警設(shè)備，其業(yè)務(wù)有如下幾種要求：

周期上報?；钚畔ⅲ霰；钚畔⒂糜诜?wù)器確定設(shè)備是否以及何時發(fā)生故障，時延要求不高，數(shù)據(jù)量小到幾十byte或者更低；

火警上報信息，時延要求比較高，數(shù)據(jù)量可能小到幾十byte(字節(jié))，也可能需要上報視頻信息，數(shù)據(jù)量比較大到數(shù)m(兆)；

服務(wù)器命令，時延要求比較高，數(shù)據(jù)量小到幾十byte或者更低；

軟件版本更新，時延要求比較低，數(shù)據(jù)量比較大，可能有數(shù)m。

由此可見，mtc設(shè)備支持的業(yè)務(wù)是多樣的，包括周期業(yè)務(wù)上報、異常 事件上報、網(wǎng)絡(luò)命令下發(fā)、軟件版本更新等多種業(yè)務(wù)。不同業(yè)務(wù)對網(wǎng)絡(luò)要求的qos(qualityofservice，服務(wù)質(zhì)量)也各不相同的。

同時，一些mtc設(shè)備可能會傳輸高速率的數(shù)據(jù)，例如便攜式應(yīng)用中，智能眼鏡可能需要傳輸實時視頻數(shù)據(jù)。智能手表可能需要打電話，這種業(yè)務(wù)需要很高的qos保證。

mtc設(shè)備數(shù)量可能是海量的，大量的設(shè)備接入可能給網(wǎng)絡(luò)帶來大量信令開銷。為了有效降低mtc設(shè)備的成本，也為了節(jié)省網(wǎng)絡(luò)側(cè)的系統(tǒng)開銷，3gpp標(biāo)準(zhǔn)目前引入了兩種小數(shù)據(jù)傳輸方式來進(jìn)行優(yōu)化：

1，控制面優(yōu)化方式：將數(shù)據(jù)包打包成naspdu(networkattachedstoragepacketdataunit，網(wǎng)絡(luò)附屬存儲分組數(shù)據(jù)單元)附著在控制面信令中傳輸。

2，用戶面優(yōu)化方式：終端和網(wǎng)絡(luò)側(cè)使用drb(dataresourcebearer，終端與基站之間的數(shù)據(jù)承載)傳輸數(shù)據(jù)，數(shù)據(jù)傳輸完畢后，雙方保存承載信息上下文，as(applicationserver，應(yīng)用服務(wù)器)安全上下文等，后續(xù)再次發(fā)送數(shù)據(jù)時，雙方通過掛起-激活流程來恢復(fù)drb承載的使用。

但是控制面優(yōu)化方式存在如下劣勢：

1、安全性能稍差：控制面優(yōu)化方案中沒有建立drb，網(wǎng)絡(luò)側(cè)和終端都沒有as安全上下文，無法對數(shù)據(jù)進(jìn)行as層加密。

2、不適合傳輸比較大的數(shù)據(jù)量：考慮到信令附加的naspdu很有限，傳輸?shù)臄?shù)據(jù)包長度有限，對于比較大的數(shù)據(jù)包，需要分成過多的小包，考慮到mtc設(shè)備一般覆蓋不太好，容易帶來丟包問題，導(dǎo)致接收方難以接收完整的數(shù)據(jù)包。而且控制面方式是使用信令傳輸數(shù)據(jù)的，過多的小包將帶來過多的信令傳輸，占用過多資源。

3、低優(yōu)先級數(shù)據(jù)業(yè)務(wù)占用過高的調(diào)度資源：一般的，mtc終端發(fā)送的周期性上報數(shù)據(jù)，其優(yōu)先級比較低，但是因為該數(shù)據(jù)是附著在空口層3信令中發(fā)送，從而獲得了和常規(guī)rrc(radioresourcecontrol，無線資源控制)信令一樣的調(diào)度優(yōu)先處理，從而會擠占那些真正的rrc接入信令(無mtc數(shù)據(jù)傳輸)的調(diào)度優(yōu)先級，可能導(dǎo)致更高的空口接入失敗。

此外，當(dāng)網(wǎng)絡(luò)內(nèi)同時支持?jǐn)?shù)據(jù)使用控制面優(yōu)化方式傳輸和使用drb傳輸時，因為srb(signalresourcebearer，終端與基站之間的信號承載)的調(diào)度優(yōu)先級總是比drb高，所以，這些低優(yōu)先級數(shù)據(jù)總是可以獲得比drb更高的調(diào)度優(yōu)先處理，可能導(dǎo)致使用drb傳輸?shù)母邇?yōu)先級業(yè)務(wù)調(diào)度得不到保障。

用戶面優(yōu)化方案存在如下劣勢：

1、信令優(yōu)化效果沒有控制面優(yōu)化效果好：控制面優(yōu)化方式節(jié)省信令更多；而用戶面優(yōu)化方案需要先恢復(fù)承載上下文信息，然后傳輸數(shù)據(jù)，相對來說，信令優(yōu)化效果小些。

2、承載上下文維護(hù)開銷比較大，存在對不齊的風(fēng)險：終端和網(wǎng)絡(luò)側(cè)始終要維護(hù)著終端mtc業(yè)務(wù)承載上下文，存在一定的系統(tǒng)開銷，包括內(nèi)存開銷、cpu(centralprocessingunit，中央處理器)開銷。此外，長時間使用中可能出現(xiàn)上下文的不對齊。因為mtc設(shè)備一般使用時間很長，數(shù)年甚至十來年的使用壽命，而網(wǎng)絡(luò)側(cè)一直處于變化中，很可能帶來和終端上下文不一致的風(fēng)險。設(shè)備接入小區(qū)的變更帶來額外上下文遷移的開銷。因為業(yè)務(wù)承載上下文的分配和站點相關(guān)，當(dāng)設(shè)備接入的站點或者小區(qū)改變時，網(wǎng)絡(luò)側(cè)需要在站點間傳遞或者修改上下文。

第三代伙伴組織計劃(thirdgenerationpartnershipprojects，簡稱為3gpp)網(wǎng)絡(luò)目前為mtc終端提供了和網(wǎng)絡(luò)側(cè)通過attach(附著)流程協(xié)商數(shù)據(jù)傳輸模式的方法，不能滿足設(shè)備內(nèi)各種mtc業(yè)務(wù)傳輸場景的不同的qos需求；可能給網(wǎng)絡(luò)帶來負(fù)面影響，例如網(wǎng)絡(luò)側(cè)開銷過大等。

技術(shù)實現(xiàn)要素：

本發(fā)明提供一種支持機(jī)器類通信設(shè)備數(shù)據(jù)傳輸?shù)姆椒ê脱b置，滿足mtc不同業(yè)務(wù)qos和網(wǎng)絡(luò)性能的靈活的數(shù)據(jù)傳輸。

為了實現(xiàn)上述發(fā)明目的，本發(fā)明采取的技術(shù)方案如下：

一種支持機(jī)器類通信設(shè)備數(shù)據(jù)傳輸?shù)姆椒?，?yīng)用于第一通信節(jié)點，包括：

確定數(shù)據(jù)傳輸模式進(jìn)行切換；

通過上行消息通知網(wǎng)絡(luò)側(cè)設(shè)備進(jìn)行數(shù)據(jù)傳輸模式切換。

可選地，確定數(shù)據(jù)傳輸模式進(jìn)行切換包括：

根據(jù)機(jī)器類通信mtc當(dāng)前傳輸業(yè)務(wù)的狀態(tài)信息和所述第一通信節(jié)點處理業(yè)務(wù)能力確定數(shù)據(jù)傳輸模式進(jìn)行切換。

可選地，所述方法之后還包括：

接收所述網(wǎng)絡(luò)側(cè)設(shè)備發(fā)送的切換響應(yīng)信息；

清除保存的當(dāng)前業(yè)務(wù)的數(shù)據(jù)傳輸模式的上下文信息；

根據(jù)切換后的數(shù)據(jù)傳輸模式更新數(shù)據(jù)傳輸模式的上下文信息。

可選地，所述當(dāng)前傳輸業(yè)務(wù)的狀態(tài)信息包括以下至少之一：

業(yè)務(wù)數(shù)據(jù)量、業(yè)務(wù)服務(wù)質(zhì)量qos要求、終端能力、終端負(fù)荷、終端電量。

可選地，所述上行消息包括以下至少之一：

上行網(wǎng)絡(luò)附屬存儲nas消息或上行空口rrc消息；

所述上行網(wǎng)絡(luò)附屬存儲nas消息或上行空口rrc消息包括切換指示。

可選地，所述切換指示包括：切換數(shù)據(jù)傳輸模式指示信元或者數(shù)據(jù)傳輸目的模式信元。

本發(fā)明還提供一種支持機(jī)器類通信設(shè)備數(shù)據(jù)傳輸?shù)姆椒?，?yīng)用于網(wǎng)絡(luò)側(cè)設(shè)備，包括：

接收第一通信節(jié)點發(fā)送的上行消息；

根據(jù)所述上行消息的切換指示進(jìn)行數(shù)據(jù)傳輸模式切換。

可選地，根據(jù)所述上行消息的切換指示進(jìn)行數(shù)據(jù)傳輸模式切換包括：

清除保存的當(dāng)前業(yè)務(wù)的數(shù)據(jù)傳輸模式的上下文信息；

根據(jù)所述上行消息的切換指示更新數(shù)據(jù)傳輸模式的上下文信息。

可選地，所述方法之后還包括：向所述第一通信節(jié)點發(fā)送切換響應(yīng)信息。

可選地，所述網(wǎng)絡(luò)側(cè)設(shè)備包括基站和移動管理實體mme。

本發(fā)明還提供一種支持機(jī)器類通信設(shè)備數(shù)據(jù)傳輸?shù)难b置，設(shè)置于第一通信節(jié)點，包括：

第一切換模塊，用于確定數(shù)據(jù)傳輸模式進(jìn)行切換；

第一通信模塊，用于通過上行消息通知網(wǎng)絡(luò)側(cè)設(shè)備進(jìn)行數(shù)據(jù)傳輸模式切換。

可選地，所述第一切換模塊確定數(shù)據(jù)傳輸模式進(jìn)行切換包括：

根據(jù)機(jī)器類通信mtc當(dāng)前傳輸業(yè)務(wù)的狀態(tài)信息和所述第一通信節(jié)點處理業(yè)務(wù)能力確定數(shù)據(jù)傳輸模式進(jìn)行切換。

可選地，所述第一通信模塊，還用于接收所述網(wǎng)絡(luò)側(cè)設(shè)備發(fā)送的切換響應(yīng)信息；

所述第一切換模塊，還用于清除保存的當(dāng)前業(yè)務(wù)的數(shù)據(jù)傳輸模式的上下文信息；還用于根據(jù)切換后的數(shù)據(jù)傳輸模式更新數(shù)據(jù)傳輸模式的上下文信息。

本發(fā)明還提供一種支持機(jī)器類通信設(shè)備數(shù)據(jù)傳輸?shù)难b置，設(shè)置于網(wǎng)絡(luò)側(cè)設(shè)備，包括：

第二通信模塊，用于接收第一通信節(jié)點發(fā)送的上行消息；

第二切換模塊，用于根據(jù)所述上行消息的切換指示進(jìn)行數(shù)據(jù)傳輸模式切換。

可選地，所述第二切換模塊，還用于清除保存的當(dāng)前業(yè)務(wù)的數(shù)據(jù)傳輸模式的上下文信息；根據(jù)所述上行消息的切換指示更新數(shù)據(jù)傳輸模式的上下文信息。

可選地，所述第二通信模塊，還用于向所述第一通信節(jié)點發(fā)送切換響應(yīng)信息。

本發(fā)明和現(xiàn)有技術(shù)相比，具有如下有益效果：

本發(fā)明提供的方案提供了滿足mtc不同業(yè)務(wù)qos和網(wǎng)絡(luò)性能的靈活的數(shù)據(jù)傳輸方式切換方法，實現(xiàn)控制面數(shù)據(jù)傳輸模式和用戶面數(shù)據(jù)傳輸模式靈活切換，可以為不同mtc業(yè)務(wù)選擇不同的數(shù)據(jù)發(fā)送模式，能夠滿足設(shè)備內(nèi) 各種mtc業(yè)務(wù)傳輸場景的不同的qos需求，提升mtc業(yè)務(wù)的qos保證，包括業(yè)務(wù)對時延的要求，業(yè)務(wù)對安全性的要求，業(yè)務(wù)速率大小的需求等。

附圖說明

圖1是本發(fā)明實施例的一種支持機(jī)器類通信設(shè)備數(shù)據(jù)傳輸?shù)姆椒ǖ牧鞒虉D；

圖2是本發(fā)明實施例的另一種支持機(jī)器類通信設(shè)備數(shù)據(jù)傳輸?shù)姆椒ǖ牧鞒虉D；

圖3是本發(fā)明實施例的一種支持機(jī)器類通信設(shè)備數(shù)據(jù)傳輸?shù)难b置的結(jié)構(gòu)示意圖；

圖4是本發(fā)明實施例的另一種支持機(jī)器類通信設(shè)備數(shù)據(jù)傳輸?shù)难b置的結(jié)構(gòu)示意圖；

圖5是終端通過上行nas消息指示網(wǎng)絡(luò)側(cè)數(shù)據(jù)傳輸模式切換的示意圖；

圖6是終端側(cè)通過上行空口消息指示網(wǎng)絡(luò)側(cè)數(shù)據(jù)傳輸模式切換的示意圖。

具體實施方式

為使本發(fā)明的發(fā)明目的、技術(shù)方案和有益效果更加清楚明了，下面結(jié)合附圖對本發(fā)明的實施例進(jìn)行說明，需要說明的是，在不沖突的情況下，本申請中的實施例和實施例中的特征可以相互任意組合。

如圖1所示，本發(fā)明實施例提供一種支持機(jī)器類通信設(shè)備數(shù)據(jù)傳輸?shù)姆椒?，?yīng)用于第一通信節(jié)點，包括：

確定數(shù)據(jù)傳輸模式進(jìn)行切換；

通過上行消息通知網(wǎng)絡(luò)側(cè)設(shè)備進(jìn)行數(shù)據(jù)傳輸模式切換。

確定數(shù)據(jù)傳輸模式進(jìn)行切換包括：

根據(jù)機(jī)器類通信mtc當(dāng)前傳輸業(yè)務(wù)的狀態(tài)信息和所述第一通信節(jié)點處理業(yè)務(wù)能力確定數(shù)據(jù)傳輸模式進(jìn)行切換。

其中，所述方法之后還包括：

接收所述網(wǎng)絡(luò)側(cè)設(shè)備發(fā)送的切換響應(yīng)信息；

清除保存的當(dāng)前業(yè)務(wù)的數(shù)據(jù)傳輸模式的上下文信息；

根據(jù)切換后的數(shù)據(jù)傳輸模式更新數(shù)據(jù)傳輸模式的上下文信息。

其中，本發(fā)明實施例的所述當(dāng)前傳輸業(yè)務(wù)的狀態(tài)信息包括以下至少之一：

業(yè)務(wù)數(shù)據(jù)量、業(yè)務(wù)服務(wù)質(zhì)量qos要求、終端能力、終端負(fù)荷、終端電量等。在其他實施例中不限于上述狀態(tài)信息，可以為其他狀態(tài)信息。

其中，所述上行消息包括以下至少之一：

上行網(wǎng)絡(luò)附屬存儲nas消息或上行空口rrc消息；

所述上行網(wǎng)絡(luò)附屬存儲nas消息或上行空口rrc消息包括切換指示。

其中，切換指示可以為上行nas消息或上行空口rrc消息新增的字段，也可以利用上行nas消息或上行空口rrc消息的現(xiàn)有字段。

mtcue根據(jù)mtc業(yè)務(wù)的數(shù)據(jù)量大小、業(yè)務(wù)qos特性、終端能力等情況，向網(wǎng)絡(luò)側(cè)設(shè)備指示在不同的數(shù)據(jù)傳輸方式之間轉(zhuǎn)換。具體如下：

終端通過業(yè)務(wù)量大小、業(yè)務(wù)qos特性等決策當(dāng)前的數(shù)據(jù)傳輸方式是否需要切換，如果需要切換，則通過上行消息通知網(wǎng)絡(luò)側(cè)設(shè)備進(jìn)行數(shù)據(jù)傳輸模式切換。

上行nas消息包括但不限于以下消息：

initialcontextsetupresponse、initialcontextsetupfailure、uecontextreleaserequest、uecontextmodificationresponse、uecontextmodificationfailure、initialuemessage、uplinknastransport、nasnondeliveryindication、消息其他新增上行nas消息等。

上行rrc消息包括但不限于以下消息：

rrcconnectionreconfigurationcomplete、

rrcconnectionreestablishmentcomplete、

rrcconnectionreestablishmentrequest、rrcconnectionrequest、

rrcconnectionsetupcomplete、ulinformationtransfer、

ueinformationresponse、或者新增上行空口消息等。

所述切換指示包括：切換數(shù)據(jù)傳輸模式指示信元或者數(shù)據(jù)傳輸目的模式信元。

其中，用于指示切換數(shù)據(jù)傳輸模式的方法如下但不限于以下方式，使用上行nas消息新增切換指示或者使用上行空口消息新增切換指示；新增的切換指示可以是新增ue切換數(shù)據(jù)傳輸模式指示信元，或者新增期望切換到的數(shù)據(jù)傳輸模式信元，或者是切換的原因指示等。

如圖2所示，本發(fā)明實施例提供一種支持機(jī)器類通信設(shè)備數(shù)據(jù)傳輸?shù)姆椒?，?yīng)用于網(wǎng)絡(luò)側(cè)設(shè)備，包括：

接收第一通信節(jié)點發(fā)送的上行消息；

根據(jù)所述上行消息的切換指示進(jìn)行數(shù)據(jù)傳輸模式切換。

根據(jù)所述上行消息的切換指示進(jìn)行數(shù)據(jù)傳輸模式切換包括：

清除保存的當(dāng)前業(yè)務(wù)的數(shù)據(jù)傳輸模式的上下文信息；

根據(jù)所述上行消息的切換指示更新數(shù)據(jù)傳輸模式的上下文信息。

所述方法之后還包括：向所述第一通信節(jié)點發(fā)送切換響應(yīng)信息。

所述網(wǎng)絡(luò)側(cè)設(shè)備包括基站和移動管理實體mme。

如圖3所示，本發(fā)明實施例提供一種支持機(jī)器類通信設(shè)備數(shù)據(jù)傳輸?shù)难b置，設(shè)置于第一通信節(jié)點，包括：

第一切換模塊，用于確定數(shù)據(jù)傳輸模式進(jìn)行切換；

第一通信模塊，用于通過上行消息通知網(wǎng)絡(luò)側(cè)設(shè)備進(jìn)行數(shù)據(jù)傳輸模式切換。

所述第一切換模塊確定數(shù)據(jù)傳輸模式進(jìn)行切換包括：

根據(jù)機(jī)器類通信mtc當(dāng)前傳輸業(yè)務(wù)的狀態(tài)信息和所述第一通信節(jié)點處理業(yè)務(wù)能力確定數(shù)據(jù)傳輸模式進(jìn)行切換。

可選地，所述第一通信模塊，還用于接收所述網(wǎng)絡(luò)側(cè)設(shè)備發(fā)送的切換響 應(yīng)信息；

所述第一切換模塊，還用于清除保存的當(dāng)前業(yè)務(wù)的數(shù)據(jù)傳輸模式的上下文信息；還用于根據(jù)切換后的數(shù)據(jù)傳輸模式更新數(shù)據(jù)傳輸模式的上下文信息。

如圖4所示，本發(fā)明實施例提供一種支持機(jī)器類通信設(shè)備數(shù)據(jù)傳輸?shù)难b置，設(shè)置于網(wǎng)絡(luò)側(cè)設(shè)備，包括：

第二通信模塊，用于接收第一通信節(jié)點發(fā)送的上行消息；

第二切換模塊，用于根據(jù)所述上行消息的切換指示進(jìn)行數(shù)據(jù)傳輸模式切換。

可選地，所述第二切換模塊，還用于清除保存的當(dāng)前業(yè)務(wù)的數(shù)據(jù)傳輸模式的上下文信息；根據(jù)所述上行消息的切換指示更新數(shù)據(jù)傳輸模式的上下文信息。

可選地，所述第二通信模塊，還用于向所述第一通信節(jié)點發(fā)送切換響應(yīng)信息。

實施例一

如圖5所示，終端設(shè)備使用上行nas消息指示網(wǎng)絡(luò)側(cè)從用戶面方式切換到控制面方式步驟如下：

步驟11：火警設(shè)備當(dāng)前和網(wǎng)絡(luò)協(xié)商使用用戶面優(yōu)化方式傳輸數(shù)據(jù)。

步驟12：終端有周期性?；钚畔⑿枰蟼鳎紤]到?；钚畔?shù)據(jù)量很小而且時延要求低、發(fā)送間隔周期比較長，終端希望切換到控制面方式發(fā)送以節(jié)約信令。

步驟13：終端發(fā)起rrcconnectionresume消息給enodeb，恢復(fù)連接。

enodeb收到后，通知mme(mobilitymanagemententity，移動管理實體)恢復(fù)該用戶s1連接。

enodeb發(fā)送rrcconnectionresumecomplete給ue。

步驟14：終端發(fā)送nas消息dettachrequest消息給mme，其中，新增 切換指示。

步驟15：mme收到dettachrequest消息帶入的切換指示后，清除掉自身保存的用戶面?zhèn)鬏敺绞降纳舷挛男畔?，并且通過下行s1消息通知enodeb也清除該信息。

mme發(fā)送dettachresponse給ue。

步驟16：ue收到dettachresponse后，清除終端保存的用戶面?zhèn)鬏敺绞降纳舷挛男畔ⅰ?/p>

步驟17：終端重新發(fā)起attachrequest消息，其中帶入控制面prefer指示。

步驟18：網(wǎng)絡(luò)側(cè)收到后，切換到控制面優(yōu)化方式，并且通過attachresponse指示給ue。

其中，火警mtc設(shè)備支持如下四種業(yè)務(wù)：

1、周期上報保活信息，時延無要求，數(shù)據(jù)量0-20byte,，上報周期為10分鐘。

2、火警上報信息，時延<10s，上報告警信息，數(shù)據(jù)量0-20byte；

3、火警控制室下發(fā)命令給設(shè)備：時延要求<10s，數(shù)據(jù)量0-20byte；

4、軟件版本更新，時延無要求，數(shù)據(jù)量2000byte。

實施例二

如圖6所示，終端設(shè)備使用上行空口消息指示網(wǎng)絡(luò)側(cè)從用戶面方式切換到控制面方式步驟如下：

步驟21：火警設(shè)備當(dāng)前和網(wǎng)絡(luò)協(xié)商使用用戶面優(yōu)化方式傳輸數(shù)據(jù)。

步驟22：終端有周期性保活信息需要上傳，考慮到?；钚畔?shù)據(jù)量很小而且時延要求低、發(fā)送間隔周期比較長，終端希望切換到控制面方式發(fā)送以節(jié)約信令。

步驟23：終端發(fā)起rrcconnectionresume消息給enodeb，恢復(fù)連接。

enodeb收到后，通知mme恢復(fù)該用戶s1連接。

enodeb發(fā)送rrcconnectionresumecomplete給ue。

步驟24：終端發(fā)送ulinformationtransfer消息給enodeb，其中新增切換指示。

步驟25：enodeb收到ulinformationtransfer消息帶入的切換指示后，清除掉自身保存的用戶面?zhèn)鬏敺绞降纳舷挛男畔?，并且通過上行s1消息通知mme也清除該信息。

enodeb發(fā)送dlinformationtransfer消息給ue。

步驟26：ue收到dlinformationtransfer后，清除終端保存的用戶面?zhèn)鬏敺绞降纳舷挛男畔ⅰ?/p>

步驟27：終端重新發(fā)起attachrequest消息，其中帶入控制面prefer指示。

步驟28：網(wǎng)絡(luò)側(cè)收到后，切換到控制面優(yōu)化方式，并且通過attachresponse指示給ue。

雖然本發(fā)明所揭示的實施方式如上，但其內(nèi)容只是為了便于理解本發(fā)明的技術(shù)方案而采用的實施方式，并非用于限定本發(fā)明。任何本發(fā)明所屬技術(shù)領(lǐng)域內(nèi)的技術(shù)人員，在不脫離本發(fā)明所揭示的核心技術(shù)方案的前提下，可以在實施的形式和細(xì)節(jié)上做任何修改與變化，但本發(fā)明所限定的保護(hù)范圍，仍須以所附的權(quán)利要求書限定的范圍為準(zhǔn)。