專利名稱：：一種機(jī)器類通信中的擁塞處理方法及設(shè)備的制作方法
技術(shù)領(lǐng)域：
：本發(fā)明涉及機(jī)器類通信技術(shù)，特別涉及一種機(jī)器類通信中的擁塞處理方法及設(shè)備。
背景技術(shù)：
：在現(xiàn)有的MTC(MachineTypeCommunications，機(jī)器類通信)技術(shù)中，由于MTCDevice(機(jī)器類通信設(shè)備)的數(shù)量眾多，需要考慮到由此產(chǎn)生的大量的信令和數(shù)據(jù)傳輸可能帶來的網(wǎng)絡(luò)擁塞，因此在3GPP(3rdGenerationpartnershipproject，3代合作項目)中，提出了研究MTC通信的CongestionControl(擁塞控制)特性。在SA2#80此會議上，NTTDoCoMo提出了一種基于APN(AccessPointName，接入點名稱)的congestioncontrol的方法，用來避免和解決與特定的APN相關(guān)的擁塞。網(wǎng)絡(luò)根據(jù)判斷某個APN是否擁塞，來啟動kick-offtimer(退避定時器)，包括MobilityManagementback-offtimer(移動性管理退避定時器)Managementback-offtimer(會話管理退避定時器)，指示MTCDevice在kick-ofTtimer超時之前，不能發(fā)起任何EMM(EPSMobilityManagement,EPS移動性管理；EPS:EvolvedPacketSystem，演進(jìn)分組系統(tǒng))或ESM(EPSSessionManagement，EPS系統(tǒng)的會話管理)的請求，其實現(xiàn)的步驟為1.MME(MobilityManagementEntity，移動性管理實體)根據(jù)一定的標(biāo)準(zhǔn)來檢測基于APN的congestion，標(biāo)準(zhǔn)包括a.PerAPN(每個APN)的激活的EPSBearer(EPS承載，EPS=EvolvedPacketSystem，演進(jìn)分組系統(tǒng))的最大數(shù)目；b.PerAPN的EPSBearer的激活速率；c.MME到一個或多個PGW(PDNGateway,PDN網(wǎng)關(guān)；PDN=PacketDataNetwork,分組數(shù)據(jù)網(wǎng)絡(luò))不可達(dá)，或者收到來自這些PDNGW的congestionindication；當(dāng)針對某一個APN的congestion發(fā)生時，MME存儲一個MobilityManagementback-offtimer(針對EPSMobilityManagement(EPS移動性管理)過程，例如Attach(附著)，TAU(TrakingAreaUpdate,跟蹤區(qū)更新)過程)和一個kssionManagementback-offtimer(針對EPSSessionManagement(EPS會話管理)過程，例如PDNConnectivityRequest(PDN連接請求)過程)，如果UE(UserEquipment，用戶設(shè)備)在這些timer超時之前，發(fā)起到此APN的接入或連接請求，網(wǎng)絡(luò)應(yīng)該拒絕。詳細(xì)分為a.當(dāng)Attach或TAU過程中請求的APN是處于擁塞狀態(tài)，則MME應(yīng)該拒絕該過程，并啟動MobilityManagementback-offtimer,同時指示UE在該timer超時之前，不能發(fā)起任何MobilityManagement過程。b.UE發(fā)起的PDNConnectivityRequest過程，攜帶APN，如果沒有攜帶APN，則使用簽約數(shù)據(jù)里defaultAPN(默認(rèn)APN)，如果判斷使用的APN處于擁塞狀態(tài)，MME應(yīng)該拒絕PDNConnectivityRequest消息,并指不UE啟動SessionManagementback-offtimer,在此timer超時之前，UE不能發(fā)起對應(yīng)此APN的PDNConnectivityRequest過程。現(xiàn)有技術(shù)中，網(wǎng)絡(luò)在拒絕Attach過程后，需要保留UE的簽約信息一段時間?，F(xiàn)有技術(shù)存在的不足在于當(dāng)一個UE簽約了多個APN時，基于APN的congestioncontrol的方案，在其中一個APN發(fā)生擁塞時，將會妨礙UE獲得正常的服務(wù)或造成信令過程的浪費。
發(fā)明內(nèi)容本發(fā)明所解決的技術(shù)問題在于提供了一種機(jī)器類通信中的擁塞處理方法及設(shè)備，用以解決現(xiàn)有技術(shù)中當(dāng)UE簽約了多個APN時，在基于APN的congestioncontrol的方案進(jìn)行處理過程中導(dǎo)致的妨礙UE獲得正常服務(wù)的問題。本發(fā)明實施例中提供了一種MTC中的擁塞處理方法，包括如下步驟移動性管理實體MME在接收用戶設(shè)備UE發(fā)起的附著請求AttachRequest消息后，確定UE的簽約接入點名稱APN；MME確定簽約APN中處于擁塞的APN;MME在返回UE的消息中指示簽約APN中處于擁塞的APN，以及指示對處于擁塞的APN設(shè)置會話管理退避定時器kssionManagementback-offtimer。本發(fā)明實施例中提供了一種MTC中的擁塞處理方法，包括如下步驟UE向MME發(fā)送AttachRequest消息；UE接收MME返回的消息，所述消息中指示了UE的簽約APN中處于擁塞的APN，以及指示對處于擁塞的APN設(shè)置SessionManagementback-offtimer；UEXi^hTfiSWAPNi^gSessionManagementback-offtimer。本發(fā)明實施例中提供了一種移動性管理實體設(shè)備，包括APN確定模塊，用于在接收UE發(fā)起的AttachRequest消息后，確定UE的簽約APN；擁塞確定模塊，用于確定簽約APN中處于擁塞的APN；指示模塊，用于在返回UE的消息中指示簽約APN中處于擁塞的APN，以及指示對處于擁塞的APN設(shè)置SessionManagementback-offtimer。本發(fā)明實施例中提供了一種用戶設(shè)備，包括發(fā)送模塊，用于向MME發(fā)送AttachRequest消息；接收模塊，用于接收MME返回UE的消息，所述消息中指示了UE的簽約APN中處于擁塞的APN，以及指示對處于擁塞的APN設(shè)置kssionManagementback-offtimer；擁塞處理模塊，用于對處于擁塞的APN設(shè)置kssionManagementback-offtimer。本發(fā)明有益效果如下在本發(fā)明實施例提供的技術(shù)方案中，MME在接收UE發(fā)起的AttachRequest消息后，確定UE的簽約APN中處于擁塞的APN；并向UE指示簽約APN中處于擁塞的APN，以及指示對處于擁塞的APN設(shè)置kssionManagementback-offtimer。由于UE在發(fā)起AttachRequest消息后，便可以獲知簽約APN中處于擁塞的APN，也因而能夠采取相應(yīng)的后續(xù)流程，而不會因一個APN處于擁塞而導(dǎo)致不能發(fā)起Attach請求，也不會在雖然成功附著后因為別的簽約APN擁塞而被網(wǎng)絡(luò)拒絕。也因此克服了當(dāng)UE簽約了多個APN時妨礙UE獲得正常服務(wù)的問題。在UE正常Attach之后，如果UE能夠獲得簽約APN中所有處于擁塞的APN的信息，進(jìn)一步的，便可以避免UE向這些APN發(fā)起EPSSessionManagement過程，從而避免不必要的信令浪費?？梢?，本發(fā)明實施例提供的技術(shù)方案能夠針對現(xiàn)有技術(shù)的不合理之處提出改進(jìn)，能夠盡量減少網(wǎng)絡(luò)中的信令資源消耗，又能保證正常業(yè)務(wù)的運行，提高用戶體驗。圖1為本發(fā)明實施例中MME側(cè)的MTC中的擁塞處理方法實施流程示意圖；圖2為本發(fā)明實施例中UE側(cè)的MTC中的擁塞處理方法實施流程示意圖；圖3為本發(fā)明實施例中UE使用defaultAPN來建立PDN連接的MTC中的擁塞處理方法實施流程示意圖；圖4為本發(fā)明實施例中UE希望提供APN的MTC中的擁塞處理方法實施流程示意圖；圖5為本發(fā)明實施例中移動性管理實體設(shè)備結(jié)構(gòu)示意圖；圖6為本發(fā)明實施例中用戶設(shè)備結(jié)構(gòu)示意圖。具體實施例方式發(fā)明人在發(fā)明過程中注意到在MTC技術(shù)中，由于MTCDevice的數(shù)量眾多，如果大量的MTCDevice同時與網(wǎng)絡(luò)進(jìn)行信令交互或數(shù)據(jù)傳輸，可能會產(chǎn)生網(wǎng)絡(luò)擁塞。網(wǎng)絡(luò)的擁塞可以分為用戶面擁塞和信令面擁塞，一旦網(wǎng)絡(luò)擁塞發(fā)生，網(wǎng)絡(luò)應(yīng)該拒絕相應(yīng)的信令連接請求或數(shù)據(jù)傳輸請求?，F(xiàn)有協(xié)議中，存在一種基于APN的擁塞控制的方法，提出在Attach過程中，如果請求的APN(defaultAPN)發(fā)生了擁塞，則拒絕Attach過程，同時啟動一個back-offtimer,在此定時器超時之前，MTCDevice不能發(fā)起任何MobilityManagement請求，即不能再發(fā)起Attach過程。在LTE(LongTermEvolution，長期演進(jìn))系統(tǒng)中，Attach過程必須要建立一個PDN連接，這就要求UE發(fā)起Attach過程的同時，發(fā)起PDNConnectivityRequest過程，在現(xiàn)有的Attach過程里，UE在AttachRequest消息的ESMmessagecontainerIE(ESM消息容器信息單元；IEinformationElement，信息單元)中捎帶PDNConnectivityRequest消息，此時PDNConnectivityRequest消息不能攜帶APN，這樣網(wǎng)絡(luò)可以使用UE簽約的defaultAPN(默認(rèn)APN)來發(fā)起PDNConnectivityRequest過程。如果UE希望提供APN,則需要在PDNConnectivityRequest消息中設(shè)置ESMinformationtransferflag(ESM信息傳送標(biāo)志)，這樣MME會在kcurityContext(安全上下文)建立之后發(fā)起ESMinformationrequest(ESM信息請求)過程，然后UE會在ESMINFORMATIONRESPONSE(ESM信息響應(yīng))消息中提供APN。如果網(wǎng)絡(luò)允許使用該APN，則使用該APN來發(fā)起PDNConnectivityRequest過程。然而，當(dāng)一個UE可能簽約了多個APN，UE發(fā)起Attach過程時，可能使用的APN正處于擁塞狀態(tài)，但是對于其他APN，可能其處于正常狀態(tài)時，以及建立的PDN連接所使用的APN沒有發(fā)生擁塞，但是UE簽約的其他APN正在發(fā)生擁塞時，基于APN的congestioncontrol的方法就不能很好的工作，例如至少存在以下2個不合適的場景1、在現(xiàn)有的Attach過程中，UE可以使用defaultAPN來建立PDN連接，也可以使用其他APN來建立PDN連接，如果按照NTTDocomo的方法來設(shè)置MobilityManagementbackofftimer,阻止UE后續(xù)發(fā)起的MobilityManagement過程，那么只要UE發(fā)起的Attach過程中請求的APN處于擁塞狀態(tài)，那么UE將在整個backofftimer時間內(nèi)，都不能接入網(wǎng)絡(luò)，即使UE簽約的其他APN沒有發(fā)生擁塞，UE也不能獲得相應(yīng)的服務(wù)。因此該方法妨礙了UE獲取正常的服務(wù)。2、如果UE發(fā)起Attach過程中，建立的PDN連接所使用的APN沒有發(fā)生擁塞，但是UE簽約的其他APN正在發(fā)生擁塞，在現(xiàn)有方法中，UE在Attach過程結(jié)束后并不能知道其他APN是否處于擁塞狀態(tài)，因此UE可能很快發(fā)起了對應(yīng)正處于擁塞狀態(tài)的APN的additionalPDNconnection(附加PDN連接)的建立過程，而該過程會被網(wǎng)絡(luò)拒絕，浪費信令資源?？梢?，一個UE可能簽約了多個APN，UE發(fā)起Attach過程時，可能使用的APN正處于擁塞狀態(tài)，但是對于其他APN，可能其處于正常狀態(tài)，而UE可能在Attach過程被拒絕之后，希望嘗試對應(yīng)其他非擁塞APN的Attach過程以獲得對應(yīng)這些APN的服務(wù)，而這現(xiàn)有技術(shù)中不能實現(xiàn)，因為UE發(fā)起的Attach過程被拒絕后，任何MobilityManagement過程都被拒絕。以及建立的PDN連接所使用的APN沒有發(fā)生擁塞，UE可能很快發(fā)起了對應(yīng)正處于擁塞狀態(tài)的APN的additionalPDNconnection的建立過程的情況導(dǎo)致被網(wǎng)絡(luò)拒絕。本發(fā)明實施例中將解決UE如何在Attach過程被拒絕之后重新發(fā)起對應(yīng)非擁塞APN的Attach過程，使得UE可以及時獲得對應(yīng)其他非擁塞APN的服務(wù)。下面結(jié)合附圖對本發(fā)明的具體實施方式進(jìn)行說明。在說明過程中，首先分別從MME側(cè)與UE側(cè)的實施進(jìn)行說明，最后再對二者的配合實施進(jìn)行說明，但這并不意味著二者必須配合實施，實際上，當(dāng)MME與UE分開實施時，也解決了分別在MME側(cè)、UE側(cè)所存在的問題，只是二者結(jié)合使用時，會獲得更好的技術(shù)效果。圖1為MME側(cè)的MTC中的擁塞處理方法實施流程示意圖，如圖所示，可以包括如下步驟步驟101、MME在接收UE發(fā)起的AttachRequest消息后，確定UE的簽約APN；步驟102、MME確定簽約APN中處于擁塞的APN；步驟103、MME在返回UE的消息中指示簽約APN中處于擁塞的APN，以及指示對處于擁塞的APN設(shè)置SessionManagementback-offtimer。相應(yīng)的，本發(fā)明實施例中還提供了UE側(cè)的MTC中的擁塞處理方案。圖2為UE側(cè)的MTC中的擁塞處理方法實施流程示意圖，如圖所示，可以包括如下步驟步驟201、UE向MME發(fā)送AttachRequest消息；步驟202、UE接收MME返回UE的消息，所述消息中指示了UE的簽約APN中處于擁塞的APN，以及指示對處于擁塞的APN設(shè)置SessionManagementback-offtimer；步驟203、UE對處于擁塞的APN設(shè)置SessionManagementback-offtimer?？梢姡诒痉桨钢?，UE在發(fā)起AttachRequest消息后，便可以獲知簽約APN中處于擁塞的APN，也因而能夠采取相應(yīng)的后續(xù)流程，而不會因一個APN處于擁塞而導(dǎo)致不能發(fā)起Attach請求，也不會在雖然成功附著后因為別的簽約APN擁塞而被網(wǎng)絡(luò)拒絕。下面對當(dāng)一個UE可能簽約了多個APN，UE發(fā)起Attach過程時，可能使用的APN正處于擁塞狀態(tài)，但是對于其他APN，可能其處于正常狀態(tài)時，以及建立的PDN連接所使用的APN沒有發(fā)生擁塞，但是UE簽約的其他APN正在發(fā)生擁塞時，基于APN的congestioncontrol的方法就不能很好的工作的場景的實施來闡述本發(fā)明方案的實施。但是采用下述的兩種實施方式來說明僅僅是因為在這兩種情況下基于APN的congestioncontrol的方法不能很好的工作這一問題表現(xiàn)得較為突出；但是，從理論上來說，在其他情況下也是可以使用本發(fā)明實施例中提供的技術(shù)方案的，只要能夠在UE發(fā)起Attach后，告知UE簽約APN的狀態(tài)，以便于UE進(jìn)行后續(xù)流程即可，下述的兩種方式僅用于教導(dǎo)本領(lǐng)域技術(shù)人員具體如何實施本發(fā)明，但不意味僅能在這兩種場景中使用，實施過程中可以結(jié)合實踐需要來確定相應(yīng)的流程改進(jìn)。方式一該方式是以UE使用defaultAPN來建立PDN連接為例進(jìn)行說明的。下面先從MME側(cè)的實施進(jìn)行說明。實施中，MME可以在返回UE的附著拒絕AttachReject消息中指示簽約APN中處于擁塞的APN，以及指示對處于擁塞的APN設(shè)置會話管理退避定時器SessionManagementback-offtimer。實施中，在UE發(fā)起Attach過程中，UE沒有在AttachRequest消息的ESMmessagecontainer的PDNConnectivityRequest消息中攜帶APN或ESMinformationtransferflag時，MME可以在返回UE的AttachReject消息中進(jìn)行指示，并拒絕UE的Attach過程。下面再從UE側(cè)相應(yīng)的實施進(jìn)行說明。實施中，UE在AttachRequest消息的ESMmessagecontainer的PDNConnectivityRequest^ΕΦ^^δΙτAPNESMinformationtransferflag。實施中，MME返回UE的消息是AttachReject消息。實施中，還可以進(jìn)一步包括UE確定處于擁塞與不擁塞的APN;UE選擇不擁塞的APN發(fā)起Attach請求，或者在擁基的APN的SessionManagementback-offtimer超時后發(fā)起Attach請求。實施中，UE發(fā)起Attach請求完成后，還可以進(jìn)一步包括UE不選擇未超時的SessionManagementbackofftimer對應(yīng)的APN發(fā)起PDNConnectivityRequest。在該方式中，1、UE發(fā)起Attach過程，并且不向網(wǎng)絡(luò)提供APN，也不在AttachRequest夕肖;|、白勺ESMmessagecontainer^PDNConnectivityRequest夕肖;|、巾ESMinformationtransferflag,defaultAPNPDNConnectivityRequest程，由于defaultAPN正處于擁塞狀態(tài)，網(wǎng)絡(luò)拒絕Attach過程，但在拒絕消息中攜帶UE簽約的各個處于擁塞狀態(tài)的APN的SessionManagementbackofftimer，也不啟動MobilityManagementbackofftimer。2、UE收到簽約的各個處于擁塞狀態(tài)的APN的SessionManagementbackofftimer，啟動相應(yīng)的timer，然后查看簽約的APN中是否有不處于擁塞狀態(tài)的，如果有，則使用此APN再次發(fā)起Attach過程；如果沒有，則UE需要等到有APN的SessionManagementbackofftimer超時再發(fā)起Attach過程。3、UE使用不處于擁塞狀態(tài)的APN發(fā)起Attach過程。4、Attach完成之后，UE不能發(fā)起對應(yīng)SessionManagementbackofftimer未超白勺APN白勺PDNConnectivityRequest。下面以實例進(jìn)行說明。實施例1圖3為UE使用defaultAPN來建立PDN連接的MTC中的擁塞處理方法實施流程示意圖，圖中newMME為UE發(fā)起附著請求的新MME，oldMME為之前為的UE提供服務(wù)的MME；如圖所示，在該過程中可以包括如下流程步驟301、UE向eNB發(fā)送Attach請求消息；步驟302、eNB向newMME發(fā)送Attach請求消息；步驟303、newMME向oldMME發(fā)送識別請求消息；步驟304、oldMME向newMME發(fā)送識別響應(yīng)消息；步驟305、newMME向UE發(fā)送識別請求消息；步驟306、UE向newMME發(fā)送識別響應(yīng)消息；步驟307、鑒權(quán)、安全性認(rèn)證等；步驟308-309、UE、newMME>EIR(EquipmentIdentificationRegister，設(shè)備識別登錄器)之間進(jìn)行識別過程，其中MEIdentityCheck為移動設(shè)備標(biāo)識檢查；步驟310、newMME向UE發(fā)送加密選項請求消息；步驟311、UE向newMME發(fā)送加密選項響應(yīng)消息；步驟312、newMME向SGW發(fā)送刪除會話請求消息；步驟313、SGff向newMME發(fā)送刪除會話響應(yīng)消息；步驟314、newMME向HSS(HomeSubscriberServer，歸屬用戶服務(wù)器)發(fā)送位置更新請求消息；步驟315、HSS向oldMME發(fā)送位置消除消息；步驟316、oldMME向HSS返回位置消除確認(rèn)消息；步驟317、ο1dMME向PGW發(fā)送刪除會話請求消息；步驟318、PGff向oldMME發(fā)送刪除會話響應(yīng)消息；步驟319、HSS向newMME發(fā)送位置更新確認(rèn)消息；步驟320、newMME向UE發(fā)送Attach拒絕消息；步驟321、UE判斷是否有不處于擁塞的APN；步驟322、UE向newMME發(fā)送Attach請求消息。在上述過程中，MME和UE的行為可以按如下方式實施1>UE^^aAttachj±禾呈，^tESMmessagecontainerψ白勺PDNconnectivityRequest中不帶APN,也不帶ESMinformationtransferflag。2、MME取得UE的簽約信息，得到UE簽約的defaultAPN,但是發(fā)現(xiàn)defaultAPN正處于擁塞狀態(tài)，則拒絕Attach過程。3、MME在AttachReject消息中返回UE簽約的處于擁塞狀態(tài)的APN和對應(yīng)的Sessionbackofftimer，實施中，其消息格式可以在如下的消息格式中增加加粗示意的部分為ThismessageissentbythenetworktotheUEtoindicatethatthecorrespondingattachrequesthasbeenrejected.Seetable8.2.3.1.Messagetype=ATTACHREJECTSignificance:dualDirection:networktoUETable8.2.3.1=ATTACHREJECTmessagecontent權(quán)利要求1.一種機(jī)器類通信MTC中的擁塞處理方法，其特征在于，包括如下步驟移動性管理實體MME在接收用戶設(shè)備UE發(fā)起的附著請求AttachRequest消息后，確定UE的簽約接入點名稱APN；MME確定簽約APN中處于擁塞的APN；MME在返回UE的消息中指示簽約APN中處于擁塞的APN，以及指示對處于擁塞的APN設(shè)置會話管理退避定時器SessionManagementback-offtimer。2.如權(quán)利要求1所述的方法，其特征在于，MME在返回UE的附著拒絕AttachReject消息中指示簽約APN中處于擁塞的APN，以及指示對處于擁塞的APN設(shè)置kssionManagementback-offtimer。3.如權(quán)利要求2所述的方法，其特征在于，在UE發(fā)起Attach過程中，UE沒有在AttachRequest消息的演進(jìn)分組系統(tǒng)的會話管理消息容器信息單元ESMmessagecontainer的分組數(shù)據(jù)網(wǎng)絡(luò)連接請求PDNConnectivityRequest消息中攜帶APN或演進(jìn)分組系統(tǒng)的會話管理信息傳送標(biāo)志ESMinformationtransferflag時，MME在返回UE的AttachReject消息中進(jìn)行指示，并拒絕UE的Attach過程。4.如權(quán)利要求1所述的方法，其特征在于，UE發(fā)起的AttachRequest消息的ESMmessagecontainer的PDNConnectivityRequest消息中攜帶有ESMinformationtransferflag；MME在返回UE的演進(jìn)分組系統(tǒng)的會話管理信息請求ESMinformationRequest消息中指示簽約APN中處于擁塞的APN，以及指示對處于擁塞的APN設(shè)置kssionManagementback-offtimer。5.如權(quán)利要求4所述的方法，其特征在于，進(jìn)一步包括在UE返回MME的演進(jìn)分組系統(tǒng)的會話管理信息響應(yīng)ESMinformationResponse消息中攜帶有APN時，MME用UE返回的ESMinformationResponse消息中攜帶的APN為UE完成PDNConnectivityRequest過禾呈；在UE返回MME的ESMinformationResponse消息中沒有攜帶有APN時，MME拒絕UE的Attach過程。6.如權(quán)利要求3或5所述的方法，其特征在于，MME拒絕UE的Attach過程時，進(jìn)一步包括MME^]]MobilityManagementbackofftimer。7.一種MTC中的擁塞處理方法，其特征在于，包括如下步驟UE向MME發(fā)送AttachRequest消息；UE接收MME返回的消息，所述消息中指示了UE的簽約APN中處于擁塞的APN，以及指^X^^hTilSWAPNi^gSessionManagementback-offtimer；UEXi^hTfiSWAPNi^gSessionManagementback-offtimer。8.如權(quán)利要求7所述的方法，其特征在于，UE在AttachRequest消息的ESMmessagecontainer的PDNConnectivityRequest消息中沒有攜帶APN或ESMinformationtransferflag。9.如權(quán)利要求8所述的方法，其特征在于，MME返回UE的消息是AttachReject消息。10.如權(quán)利要求7至9任一所述的方法，其特征在于，進(jìn)一步包括UE確定處于擁塞與不擁塞的APN；UE選擇不擁塞的APN發(fā)起Attach請求，或者在擁塞的APN的kssionManagementback-offtimer超時后發(fā)起Attach請求。11.如權(quán)利要求10所述的方法，其特征在于，UE發(fā)起Attach請求完成后，進(jìn)一步包括UE不選擇未超時的kssionManagementbackofftimer對應(yīng)的APN發(fā)起PDNConnectivityRequest。12.如權(quán)利要求7所述的方法，其特征在于，UE在AttachRequest消息的ESMmessagecontainer的PDNConnectivityRequest消息中攜帶有ESMintormationtransferflag。13.如權(quán)利要求12所述的方法，其特征在于，MME返回UE的消息是ESMinformationRequest消息。14.如權(quán)利要求7或12或13所述的方法，其特征在于，進(jìn)一步包括UE確定處于擁塞與不擁塞的APN；UE選擇一個不擁塞的APN，并在ESMinformationResponse消息中攜帶該APN后向MME上報；若沒有不擁塞的APN，則不在ESMinformationResponse消息中攜帶APN。15.如權(quán)利要求14所述的方法，其特征在于，若ESMinformationResponse消息中沒有攜帶APN，進(jìn)一步包括￠￠1APN白勺SessionManagementback-offtimerIgBijp^iSAttachi青$。16.如權(quán)利要求15所述的方法，其特征在于，UE發(fā)起Attach請求完成后，進(jìn)一步包括UE不選擇未超時的kssionManagementbackofftimer對應(yīng)的APN發(fā)起PDNConnectivityRequest。17.—種移動性管理實體設(shè)備，其特征在于，包括APN確定模塊，用于在接收UE發(fā)起的AttachRequest消息后，確定UE的簽約APN；擁塞確定模塊，用于確定簽約APN中處于擁塞的APN；指示模塊，用于在返回UE的消息中指示簽約APN中處于擁塞的APN，以及指示對處于擁塞的APN設(shè)置SessionManagementback-offtimer。18.如權(quán)利要求17所述的設(shè)備，其特征在于，指示模塊進(jìn)一步用于在返回UE的AttachReject消息中指示簽約APN中處于擁塞的APN，以及指示對處于擁塞的APN設(shè)置kssionManagementback-offtimer。19.如權(quán)利要求18所述的設(shè)備，其特征在于，指示模塊進(jìn)一步用于在UE發(fā)起Attach禾呈巾，UEi^WiAttachRequest夕肖;|、白勺ESMmessagecontainer白勺PDNConnectivityRequest消息中攜帶APN或ESMinformationtransferflag時，在返回UE的AttachReject消息中進(jìn)行指示。20.如權(quán)利要求19所述的設(shè)備，其特征在于，進(jìn)一步包括附著處理模塊，用于在返回AttachReject消息時，拒絕UE的Attach過程。21.如權(quán)利要求17所述的設(shè)備，其特征在于，指示模塊進(jìn)一步用于在UE發(fā)起的AttachRequest夕肖;|、白勺ESMmessagecontainer^PDNConnectivityRequest^^43!!^ESMinformationtransferflag時，在返回UE的ESMinformationRequest消息中指示簽約APN中處于擁塞的APN，以及指示對處于擁塞的APN設(shè)置kssionManagementback-offtimer。22.如權(quán)利要求21所述的設(shè)備，其特征在于，進(jìn)一步包括附著處理模塊，用于在UE返回MME的ESMinformationResponse消息中攜帶有APN時，用UE返回的ESMinformation!Response消息中攜帶的APN為UE完成PDNConnectivityRequest過程；在UE返回MME的ESMinformationResponse消息中沒有攜帶有APN時，拒絕UE的Attach過程。23.如權(quán)利要求19或22所述的設(shè)備，其特征在于，附著處理模塊進(jìn)一步用于在拒絕UE的Attach過程時，不啟動MobilityManagementbackofftimer。24.一種用戶設(shè)備，其特征在于，包括發(fā)送模塊，用于向MME發(fā)送AttachRequest消息；接收模塊，用于接收MME返回UE的消息，所述消息中指示了UE的簽約APN中處于擁塞的APN，以及指示對處于擁塞的APN設(shè)置kssionManagementback-offtimer；擁塞處理模塊，用于對處于擁塞的APN設(shè)置kssionManagementback-offtimer。25.如權(quán)利要求M所述的用戶設(shè)備，其特征在于，發(fā)送模塊進(jìn)一步用于不在AttachRequest夕肖;|、白勺ESMmessagecontainer^PDNConnectivityRequest夕肖;|、巾APNgESMinformationtransferflag。26.如權(quán)利要求25所述的用戶設(shè)備，其特征在于，接收模塊進(jìn)一步用于接收MME返回UE的AttachReject消息。27.如權(quán)利要求M至沈任一所述的用戶設(shè)備，其特征在于，擁塞處理模塊進(jìn)一步用于確定處于擁塞與不擁塞的APN；選擇不擁塞的AP汝發(fā)起Attach請求，或者在擁塞的APN的SessionManagementback-offtimer超時后發(fā)起Attach請求。28.如權(quán)利要求27所述的用戶設(shè)備，其特征在于，擁塞處理模塊進(jìn)一步用于在發(fā)起Attach請求完成后，不選擇未超時WkssionManagementbackofftimer對應(yīng)的APN發(fā)起PDNConnectivityRequest。29.如權(quán)利要求M所述的用戶設(shè)備，其特征在于，發(fā)送模塊進(jìn)一步用于在AttachRequest夕肖;|、白勺ESMmessagecontainer^PDNConnectivityRequest^^43!]ESMinformationtransferflag。30.如權(quán)利要求四所述的用戶設(shè)備，其特征在于，接收模塊進(jìn)一步用于接收MME返回UE的ESMinformationRequest消息。31.如權(quán)利要求24或四或30所述的用戶設(shè)備，其特征在于，擁塞處理模塊進(jìn)一步用于確定處于擁塞與不擁塞的APN；選擇一個不擁塞的APN，并在ESMinformationResponse消息中攜帶該APN后向MME上報；若沒有不擁塞的APN，則不在ESMinformationResponse消息中攜帶APN。32.如權(quán)利要求31所述的用戶設(shè)備，其特征在于，擁塞處理模塊進(jìn)一步用于若不在ESMinformationResponseffil、+^^APN，￠#1白勺APN白勺SessionManagementback-offtimer超時后發(fā)起Attach請求。33.如權(quán)利要求32所述的用戶設(shè)備，其特征在于，擁塞處理模塊進(jìn)一步用于在發(fā)起Attach請求完成后，不選擇未超時的kssionManagementbackofftimer對應(yīng)的APN發(fā)起PDNConnectivityRequest。全文摘要本發(fā)明公開了一種機(jī)器類通信中的擁塞處理方法及設(shè)備，包括移動性管理實體在接收用戶設(shè)備發(fā)起的附著請求消息后，確定用戶設(shè)備的簽約接入點名稱；移動性管理實體確定簽約接入點名稱中處于擁塞的接入點名稱；移動性管理實體在返回用戶設(shè)備的消息中指示簽約接入點名稱中處于擁塞的接入點名稱，以及指示對處于擁塞的接入點名稱設(shè)置會話管理退避定時器。本發(fā)明能夠針對現(xiàn)有技術(shù)的不合理之處提出改進(jìn)，能夠盡量減少網(wǎng)絡(luò)中的信令資源消耗，又能保證正常業(yè)務(wù)的運行。文檔編號H04W28/02GK102448111SQ201010504059公開日2012年5月9日申請日期2010年9月30日優(yōu)先權(quán)日2010年9月30日發(fā)明者王胡成申請人:電信科學(xué)技術(shù)研究院