專利名稱：一種mtc設(shè)備下行數(shù)據(jù)傳輸控制方法和設(shè)備的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)領(lǐng)域，特別涉及一種MTC設(shè)備下行數(shù)據(jù)傳輸控制方法和設(shè)備。
背景技術(shù)：
作為未來泛在網(wǎng)絡(luò)的重要組成部分，機(jī)器間(M2M，Machine-to-Machine)通信是指應(yīng)用無線移動(dòng)通信技術(shù)，實(shí)現(xiàn)機(jī)器與機(jī)器、機(jī)器與人之間進(jìn)行數(shù)據(jù)通信和交互的一系列技術(shù)及技術(shù)組合的總稱。這樣的技術(shù)為各種終端設(shè)備提供了在系統(tǒng)之間、遠(yuǎn)程設(shè)備之間以及個(gè)人之間實(shí)時(shí)建立無線連接，傳輸數(shù)據(jù)信息的途徑。為了能夠很好地滿足M2M通信要求，2009年8月，第二階段的3GPP(3rdGeneration Partnership Project,第三代合作伙伴計(jì)劃)SA2工作組在75次會(huì)議上討論并通過了 NIMTC (Network Improvement for Machine-TypeCommunications, fflft W N ^ 進(jìn))的WID(Work Item Description，工作項(xiàng)目簡介)建議，計(jì)劃于2010年6月前針對第一階段提出的需求完成系統(tǒng)框架性的技術(shù)研究報(bào)告TR 23.888 "System Improvements for Machine—TypeCommunications，，。在第一階段的SAl 工作組報(bào)告 TS 22.368 "Network improvement for MTC” 中， 定義了一種Time Controlled(時(shí)間受控)的MTC(Machine-TypeCommunications，機(jī)械類通信)特性，是指:MTC設(shè)備(MTC Device, MD)僅在預(yù)先定義的某個(gè)時(shí)間段內(nèi)收發(fā)數(shù)據(jù)，而在其他時(shí)間段內(nèi)避免傳輸不必要的信令及數(shù)據(jù)信息，具體包含如下幾點(diǎn)需求1、網(wǎng)絡(luò)運(yùn)營商可以限制MD接入網(wǎng)絡(luò)。2、網(wǎng)絡(luò)運(yùn)營商可以在特定區(qū)域使用這些限制。3、MD能夠確定何時(shí)被限制接入網(wǎng)絡(luò)，例如，使用網(wǎng)絡(luò)提供的信息來決定是否發(fā)起或延遲數(shù)據(jù)傳輸。4、只有當(dāng)MTC Server向MD發(fā)送數(shù)據(jù)時(shí)，可以給MTC Server發(fā)送一個(gè)指示用于指明由于限制的原因MD當(dāng)前不可達(dá)。顯然，上述特性需求的核心之一在于要求網(wǎng)絡(luò)能夠根據(jù)接入網(wǎng)負(fù)載狀況對具有此類特性MD的上下行通信實(shí)施傳輸控制。對于處于空閑狀態(tài)的終端設(shè)備，UMTS(Universal MobileTelecommunications System，通用移動(dòng)通信系統(tǒng))系統(tǒng)及LTE (Long TermEvolution，長期演進(jìn))系統(tǒng)采用服務(wù)請求過程(Service Request)處理上下行方向達(dá)到的數(shù)據(jù)業(yè)務(wù)請求。UMTS系統(tǒng)中該過程在上下行方向的主要流程分別如圖1，圖2所示，在LTE系統(tǒng)中該過程如圖3，圖4所示。在上行方向，當(dāng)終端有數(shù)據(jù)業(yè)務(wù)產(chǎn)生時(shí)，終端直接發(fā)起Service ReqUeSt(服務(wù)請求)過程。在下行方向，當(dāng)網(wǎng)絡(luò)側(cè)有數(shù)據(jù)到達(dá)時(shí)，核心網(wǎng)管理控制實(shí)體(MME/SGSN)通過尋呼觸發(fā)終端發(fā)起服務(wù)請求過程。這里對具體細(xì)節(jié)不做展開，詳細(xì)步驟請參考較新版本的3GPP TS 23. 060 及 TS 23.401。
為了實(shí)現(xiàn)對具有時(shí)間容忍(Time Tolerant)特性MD的傳輸控制，現(xiàn)有的技術(shù)方案提出在Service Request過程中，通過Iu/Sl接口信令攜帶接入網(wǎng)負(fù)載信息或負(fù)載門限信息的方法來實(shí)現(xiàn)上行方向的傳輸控制。具體來說，在上行方向當(dāng)處于空閑態(tài)的MD有數(shù)據(jù)到達(dá)時(shí)，它將向網(wǎng)絡(luò)發(fā)起服務(wù)請求過程。根據(jù)主要處理實(shí)體的不同，有如下兩種操作方法一、在透傳 NAS (Non-Access Stratum)信令 Service Request 的過程中，接入網(wǎng)控制實(shí)體(如RNC/eNodeB/HeNodeB)通過Iu/Sl接口信令將接入網(wǎng)負(fù)載狀況通知給核心網(wǎng)管理控制實(shí)體(如SGSN/MME)。后者根據(jù)當(dāng)前網(wǎng)絡(luò)的負(fù)載狀況及從HLR/HSS獲取的(預(yù)) 定義的網(wǎng)絡(luò)負(fù)載門限判定是否接受MD的服務(wù)請求。若網(wǎng)絡(luò)拒絕MD的服務(wù)請求，核心網(wǎng)管理控制實(shí)體可為MD確定并維護(hù)一個(gè)參考時(shí)間以協(xié)助MD進(jìn)行時(shí)延等待，并通過服務(wù)拒絕信令將該時(shí)間告知MD。在接收到服務(wù)拒絕信令時(shí)，MD將以上述時(shí)間為參考，等待一段時(shí)間之后可重新發(fā)起服務(wù)請求。該過程的主要流程如圖5所示。方法二、在接收到MD發(fā)送的Service Request信令后，核心網(wǎng)管理控制實(shí)體在Iu/ Sl接口建立請求信令中將(預(yù))定義的網(wǎng)絡(luò)負(fù)載門限信息捎帶傳輸給接入網(wǎng)控制實(shí)體。后者根據(jù)接入網(wǎng)當(dāng)前的負(fù)載情況及接收到的網(wǎng)絡(luò)負(fù)載門限判定是否接受MD的服務(wù)請求。若網(wǎng)絡(luò)拒絕MD的服務(wù)請求，接入網(wǎng)控制實(shí)體可為MD確定一個(gè)參考時(shí)間來協(xié)助MD進(jìn)行時(shí)延等待。同時(shí)，接入網(wǎng)控制實(shí)體通過Iu/Sl接口失敗響應(yīng)信令將此參考時(shí)間通知給核心網(wǎng)管理控制實(shí)體，由后者對其進(jìn)行維護(hù)并通過服務(wù)拒絕信令告知MD。在接收到服務(wù)拒絕信令時(shí)， MD將以上述時(shí)間為參考，等待一段時(shí)間之后可重新發(fā)起服務(wù)請求。該過程的主要流程如圖 6所示?？傊?，在現(xiàn)有方法中對于時(shí)間容忍特性，如果接入網(wǎng)負(fù)載達(dá)到或超出(預(yù))定義的網(wǎng)絡(luò)負(fù)載門限，那么網(wǎng)絡(luò)將拒絕MD的服務(wù)請求，并可為其分配一個(gè)作為時(shí)延參考的等待時(shí)間。核心網(wǎng)管理控制實(shí)體(如SGSN/MME)通過ServiceReject信令將該時(shí)間告知MD，并在本地保存并維護(hù)該參數(shù)信息。這樣，MD和核心網(wǎng)管理控制實(shí)體之間達(dá)到同步，兩者對MD被延遲提供服務(wù)的操作有相同的認(rèn)知。根據(jù)此時(shí)延等待時(shí)間，MD在之后的延遲時(shí)間段內(nèi)將不會(huì)為上行數(shù)據(jù)業(yè)務(wù)發(fā)起服務(wù)請求，由此網(wǎng)絡(luò)便實(shí)現(xiàn)了上行方向的傳輸控制。ICMPdnternet Control Message Protocol, Internet 控制 艮文協(xié)議)是 TCP/IP 協(xié)議族的一個(gè)子協(xié)議，用于在IP主機(jī)、路由器之間傳遞控制消息?？刂葡⑹侵妇W(wǎng)絡(luò)通不通、主機(jī)是否可達(dá)、路由是否可用等網(wǎng)絡(luò)本身的消息。ICMP消息封裝在IP數(shù)據(jù)分組中傳輸， 協(xié)議號為1。ICMP消息主要是通過不同的類型(Type)和代碼(Code)讓主機(jī)識別不同的網(wǎng)絡(luò)狀況，有關(guān)ICMP消息定義的具體細(xì)節(jié)可參見RFC 792規(guī)范。與本發(fā)明相關(guān)的是類型為3的 ICMP消息，其主要作用是通知主機(jī)目的節(jié)點(diǎn)不可達(dá)，具體消息格式如下012 3
0 1 2 3 4 5 6 7890123456789012345678901
+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-
TypeCodeChecksum
-+-+-+-+-+-+-+-+-+-+-
unusedLengthNext-Hop MTU*
+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-
IInternet Header+leading octets of original datagramIIHI+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+其中，代碼域含義為0- Destination network unreachable1- Destination host unreachable2- Destination protocol unreachable3- Destination port unreachable4- Fragmentation required，and DF flag set5- Source route failed6- Destination network unknown7- Destination host unknown8- Source host isolated9- Network administratively prohibited10-Host administratively prohibitedIl-Network unreachable for TOS12-Host unreachable for TOS13-Communication administratively prohibited在Ipv6協(xié)議中，ICMP重新修訂為ICMPv6，具體細(xì)節(jié)可參見RFC4443/4884規(guī)范。 ICMPv6在IP數(shù)據(jù)分組中傳輸時(shí)使用的協(xié)議號為58。在ICMPv6中，用于通知主機(jī)目的節(jié)點(diǎn)不可達(dá)ICMP消息類型為1，具體消息格式如下012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I Type| Code|Checksum|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IUnused|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IAs much of invoking packet|+as possible without the ICMPv6 packet+Iexceeding the minimum IPv6 MTU[IPv6]|其中，代碼域含義為0-no route to destination1-communication with destination administratively prohibited2-beyond scope of source address3-address unreachable
4-port unreachab 1 e5-source address failed ingress/egress policy6-reject route to destination在實(shí)現(xiàn)本發(fā)明的過程中，發(fā)明人發(fā)現(xiàn)現(xiàn)有技術(shù)至少存在以下問題根據(jù)第一階段SAl工作組對MTC特性的需求，UMTS系統(tǒng)及LTE系統(tǒng)應(yīng)能根據(jù)接入網(wǎng)負(fù)載及(預(yù))定義的負(fù)載門限對具有Time Tolerant特性MD的上下行數(shù)據(jù)業(yè)務(wù)進(jìn)行傳輸控制。但是，現(xiàn)有方法主要考慮了處于空閑狀態(tài)的MD在有上行數(shù)據(jù)需要發(fā)送的情況下， 網(wǎng)絡(luò)如何根據(jù)網(wǎng)絡(luò)狀態(tài)對MD進(jìn)行傳輸控制的問題，而沒能針對下行方向的數(shù)據(jù)傳輸提出有效的傳輸控制方案。這將使3GPP網(wǎng)絡(luò)不能完全支持機(jī)器類通信Time Tolerant特性的需求。

發(fā)明內(nèi)容
本發(fā)明提供一種MTC設(shè)備下行數(shù)據(jù)傳輸控制方法和設(shè)備，在下行方向根據(jù)接入網(wǎng)負(fù)載的實(shí)時(shí)狀況對具有Time Tolerant特性的MTC設(shè)備進(jìn)行傳輸控制，從而優(yōu)化整個(gè)系統(tǒng)的服務(wù)能力及傳輸效率。為達(dá)到上述目的，本發(fā)明實(shí)施例一方面提供了一種機(jī)器類通信MTC設(shè)備下行數(shù)據(jù)傳輸控制方法，包括當(dāng)MTC服務(wù)器需要向MTC設(shè)備傳輸下行數(shù)據(jù)時(shí)，所述MTC服務(wù)器判斷是否啟動(dòng)了對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器；如果已經(jīng)啟動(dòng)對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器，所述MTC服務(wù)器緩存所述下行數(shù)據(jù)；當(dāng)所述對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器超時(shí)時(shí)，所述MTC服務(wù)器將緩存的所述下行數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送給對應(yīng)的MTC設(shè)備。另一方面，本發(fā)明實(shí)施例還提供了一種MTC服務(wù)器，包括定時(shí)器模塊，用于設(shè)定對應(yīng)當(dāng)前注冊的MTC設(shè)備的時(shí)延等待定時(shí)器；判斷模塊，用于當(dāng)需要向MTC設(shè)備傳輸下行數(shù)據(jù)時(shí)，判斷所述定時(shí)器模塊是否啟動(dòng)了對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器；緩存模塊，用于在所述判斷模塊判斷已經(jīng)啟動(dòng)對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器時(shí)，緩存所述下行數(shù)據(jù)；通信模塊，用于當(dāng)所述定時(shí)器模塊所設(shè)定的對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器超時(shí)時(shí)，將所述緩存模塊所緩存的所述下行數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送給對應(yīng)的MTC設(shè)備。與現(xiàn)有技術(shù)相比，本發(fā)明具有以下優(yōu)點(diǎn)通過應(yīng)用本發(fā)明實(shí)施例所提出的技術(shù)方案，解決了具有時(shí)間容忍特性MD下行方向數(shù)據(jù)業(yè)務(wù)的傳輸控制問題，在現(xiàn)有上行數(shù)據(jù)傳輸控制方案的基礎(chǔ)上，通過進(jìn)一步增強(qiáng)MTC krver與核心網(wǎng)各實(shí)體間，核心網(wǎng)內(nèi)部各實(shí)體間的交互過程，使系統(tǒng)能夠基于接入網(wǎng)負(fù)載情況及(預(yù))定義的簽約門限限制MTCServer向MD下行數(shù)據(jù)的發(fā)送，從而具有支持下行數(shù)據(jù)傳輸控制的能力。


圖1為現(xiàn)有技術(shù)中UMTS系統(tǒng)中的服務(wù)請求過程在上行方向的流程示意圖；圖2為現(xiàn)有技術(shù)中UMTS系統(tǒng)中的服務(wù)請求過程在下行方向的流程示意圖；圖3為現(xiàn)有技術(shù)中LTE系統(tǒng)中的服務(wù)請求過程在上行方向的流程示意圖；圖4為現(xiàn)有技術(shù)中LTE系統(tǒng)中的服務(wù)請求過程在下行方向的流程示意圖；圖5為現(xiàn)有技術(shù)中一種MTC設(shè)備上行數(shù)據(jù)傳輸控制方法的流程示意圖；圖6為現(xiàn)有技術(shù)中另一種MTC設(shè)備上行數(shù)據(jù)傳輸控制方法的流程示意圖；圖7為本發(fā)明實(shí)施例中的一種MTC設(shè)備下行數(shù)據(jù)傳輸控制方法的流程示意圖；圖8為本發(fā)明實(shí)施例中的一種具體應(yīng)用場景下MTC設(shè)備下行數(shù)據(jù)傳輸控制方法的流程示意圖；圖9為本發(fā)明實(shí)施例中的一種MTC設(shè)備下行數(shù)據(jù)傳輸控制方法的流程示意圖；圖10為本發(fā)明實(shí)施例中的一種MTC設(shè)備下行數(shù)據(jù)傳輸控制方法的流程示意圖；圖11為本發(fā)明實(shí)施例中的一種MTC設(shè)備下行數(shù)據(jù)傳輸控制方法的流程示意圖；圖12為本發(fā)明實(shí)施例中的一種MTC服務(wù)器的結(jié)構(gòu)示意圖；。
具體實(shí)施例方式本發(fā)明為具有時(shí)間容忍特性的MD提出一種下行數(shù)據(jù)業(yè)務(wù)傳輸控制的方法。該方法在現(xiàn)有上行數(shù)據(jù)傳輸控制方案的基礎(chǔ)上，通過進(jìn)一步增強(qiáng)MTCServer與核心網(wǎng)各實(shí)體間，核心網(wǎng)內(nèi)部各實(shí)體間的交互過程，使系統(tǒng)能夠基于接入網(wǎng)負(fù)載情況及(預(yù))定義的簽約門限限制MTC Server向MD下行數(shù)據(jù)的發(fā)送，從而具有支持下行數(shù)據(jù)傳輸控制的能力。如圖7所示，為本發(fā)明實(shí)施例提供的一種MTC設(shè)備下行數(shù)據(jù)傳輸控制方法的流程示意圖，該方法具體包括以下步驟步驟S701、當(dāng)MTC服務(wù)器需要向MTC設(shè)備傳輸下行數(shù)據(jù)時(shí)，MTC服務(wù)器判斷是否啟動(dòng)了對應(yīng)MTC設(shè)備的時(shí)延等待定時(shí)器。如果已經(jīng)啟動(dòng)對應(yīng)MTC設(shè)備的時(shí)延等待定時(shí)器，執(zhí)行步驟S702 ；如果沒有啟動(dòng)對應(yīng)MTC設(shè)備的時(shí)延等待定時(shí)器，執(zhí)行步驟S705。其中，對應(yīng)MTC設(shè)備的時(shí)延等待定時(shí)器，具體為MTC服務(wù)器根據(jù)從HLR或HSS獲取到的MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或MTC設(shè)備時(shí)延等待狀態(tài)信息進(jìn)行設(shè)定，其中，MTC服務(wù)器從HLR或HSS獲取MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或MTC設(shè)備時(shí)延等待狀態(tài)信息的方式， 具體包括MTC服務(wù)器在接收到MTC設(shè)備的登陸注冊請求后，MTC服務(wù)器向HLR或HSS訂閱 MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或MTC設(shè)備時(shí)延等待狀態(tài)信息。當(dāng)HLR或HSS判斷MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或時(shí)延等待狀態(tài)發(fā)生變化時(shí)，MTC服務(wù)器接收HLR或HSS發(fā)送的更新的MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或MTC設(shè)備時(shí)延等待狀態(tài)信息；或，當(dāng)MTC服務(wù)器接收到服務(wù)數(shù)據(jù)網(wǎng)關(guān)發(fā)送的向MTC設(shè)備傳輸下行數(shù)據(jù)失敗的通知消息時(shí)，MTC服務(wù)器向HLR或HSS發(fā)送MTC設(shè)備的等待時(shí)間信息或MTC設(shè)備時(shí)延等待狀態(tài)信息的查詢請求，并接收HLR或HSS返回的MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或MTC設(shè)備時(shí)延等待狀態(tài)信息。進(jìn)一步的，MTC服務(wù)器接收HLR或HSS發(fā)送的更新的MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或MTC設(shè)備時(shí)延等待狀態(tài)信息，具體包括
MTC服務(wù)器接收HLR或HSS發(fā)送的關(guān)于MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)的通知消息， MTC服務(wù)器根據(jù)MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)設(shè)定對應(yīng)MTC設(shè)備的時(shí)延等待定時(shí)器；或，MTC服務(wù)器接收HLR或HSS發(fā)送的關(guān)于MTC設(shè)備時(shí)延等待狀態(tài)信息的通知消息，如果MTC設(shè)備處于時(shí)延等待狀態(tài)，MTC服務(wù)器根據(jù)預(yù)設(shè)的時(shí)延等待時(shí)間參數(shù)設(shè)定對應(yīng)MTC設(shè)備的時(shí)延等待定時(shí)器。需要進(jìn)一步指出的是，上述的MTC設(shè)備的等待時(shí)間信息也可以通過以下方式產(chǎn)生當(dāng)MTC設(shè)備當(dāng)前不能達(dá)到發(fā)送上行數(shù)據(jù)的條件時(shí)，MTC設(shè)備所對應(yīng)的核心網(wǎng)控制實(shí)體確定上行數(shù)據(jù)傳輸失敗，并生成更新的MTC設(shè)備的等待時(shí)間信息；MTC設(shè)備所對應(yīng)的核心網(wǎng)控制實(shí)體向HLR或HSS發(fā)送更新的MTC設(shè)備的等待時(shí)間
fn息ο步驟S702、MTC服務(wù)器緩存下行數(shù)據(jù)。步驟S703、MTC服務(wù)器判斷對應(yīng)MTC設(shè)備的時(shí)延等待定時(shí)器是否超時(shí)。如果超時(shí)，執(zhí)行步驟S704 ；如果沒有超時(shí)，返回步驟S703。本步驟中的判斷過程可以是周期性的判斷，也可以是按照一定的觸發(fā)條件進(jìn)行判斷，具體判斷形勢的變化并不會(huì)影響本發(fā)明實(shí)施例的保護(hù)范圍。步驟S704、MTC服務(wù)器將緩存的下行數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送給對應(yīng)的MTC設(shè)備。步驟S705、MTC服務(wù)器將需要向MTC設(shè)備傳輸?shù)南滦袛?shù)據(jù)發(fā)送給相應(yīng)的網(wǎng)絡(luò)設(shè)備， 并由相應(yīng)的網(wǎng)絡(luò)設(shè)備將需要向MTC設(shè)備傳輸?shù)南滦袛?shù)據(jù)轉(zhuǎn)發(fā)給MTC設(shè)備。在本步驟執(zhí)行的過程中，還包括當(dāng)MTC設(shè)備當(dāng)前不能達(dá)到接收下行數(shù)據(jù)的條件時(shí)，MTC設(shè)備所對應(yīng)的核心網(wǎng)控制實(shí)體確定下行數(shù)據(jù)傳輸失敗，并生成更新的MTC設(shè)備的等待時(shí)間信息；MTC設(shè)備所對應(yīng)的核心網(wǎng)控制實(shí)體向HLR或HSS發(fā)送更新的MTC設(shè)備的等待時(shí)間 fn息；MTC設(shè)備所對應(yīng)的核心網(wǎng)控制實(shí)體通過服務(wù)數(shù)據(jù)網(wǎng)關(guān)向MTC服務(wù)器發(fā)送向MTC設(shè)備傳輸下行數(shù)據(jù)失敗的通知消息，MTC服務(wù)器緩存下行數(shù)據(jù)。在具體的應(yīng)用場景中，上述的向MTC設(shè)備傳輸下行數(shù)據(jù)失敗的通知消息，具體為表征目標(biāo)節(jié)點(diǎn)不可達(dá)的ICMP消息；或，表征目標(biāo)節(jié)點(diǎn)不可達(dá)的ICMPv6消息。與現(xiàn)有技術(shù)相比，本發(fā)明具有以下優(yōu)點(diǎn)通過應(yīng)用本發(fā)明實(shí)施例所提出的技術(shù)方案，解決了具有時(shí)間容忍特性MD下行方向數(shù)據(jù)業(yè)務(wù)的傳輸控制問題，在現(xiàn)有上行數(shù)據(jù)傳輸控制方案的基礎(chǔ)上，通過進(jìn)一步增強(qiáng)MTC krver與核心網(wǎng)各實(shí)體間，核心網(wǎng)內(nèi)部各實(shí)體間的交互過程，使系統(tǒng)能夠基于接入網(wǎng)負(fù)載情況及(預(yù))定義的簽約門限限制MTCServer向MD下行數(shù)據(jù)的發(fā)送，從而具有支持下行數(shù)據(jù)傳輸控制的能力。下面，結(jié)合具體的應(yīng)用場景，對本發(fā)明實(shí)施例所提出的技術(shù)方案進(jìn)行詳細(xì)說明。對處于空閑狀態(tài)的MD，當(dāng)有下行數(shù)據(jù)到達(dá)3GPP網(wǎng)絡(luò)服務(wù)網(wǎng)關(guān)節(jié)點(diǎn)(如S_GW)時(shí)， 核心網(wǎng)管理控制實(shí)體(如SGSN/MME)將發(fā)送尋呼信令觸發(fā)MD發(fā)起服務(wù)請求過程，旨在建立無線接入連接。在MD向網(wǎng)絡(luò)發(fā)送服務(wù)請求信令(如krvice Request)之后，網(wǎng)絡(luò)和終端設(shè)備按照現(xiàn)有的技術(shù)方案進(jìn)行處理，根據(jù)當(dāng)前的接入網(wǎng)負(fù)載狀況判斷終端設(shè)備是否可以接收下行數(shù)據(jù)。如果接入網(wǎng)負(fù)載符合要求，則建立相應(yīng)的通信信道接收相應(yīng)的下行數(shù)據(jù)。反之，在接入網(wǎng)負(fù)載達(dá)到或超出(預(yù))定義網(wǎng)絡(luò)負(fù)載門限的情況下，網(wǎng)絡(luò)將拒絕MD 的服務(wù)請求，并可為其分配一個(gè)時(shí)延等待時(shí)間。核心網(wǎng)管理控制實(shí)體(如SGSN/MME)在本地保存并負(fù)責(zé)維護(hù)該參數(shù)信息。為了使MTC Server能夠獲知3GPP網(wǎng)絡(luò)對MD的服務(wù)延遲信息，進(jìn)而有效控制下行數(shù)據(jù)的傳輸，本發(fā)明實(shí)施例中核心網(wǎng)管理控制實(shí)體在更新MD的時(shí)延等待時(shí)間參數(shù)之后需要將其通過S6a/S6d接口上的通知信令(如NotifyRequest)通知給HLR/HSS，并對此信息進(jìn)行維護(hù)。HLR/HSS在Subscriber MD上下文信息中增加時(shí)延等待時(shí)間參數(shù)信息(如Delayed Time)用于保存網(wǎng)絡(luò)系統(tǒng)為MD分配的時(shí)延等待時(shí)間參數(shù)。除了直接向HLR/HSS發(fā)送網(wǎng)絡(luò)為MD確定的時(shí)延等待時(shí)間之外，在網(wǎng)絡(luò)未提供時(shí)延等待參考時(shí)間的情況下，當(dāng)MD的傳輸狀態(tài)發(fā)生變化時(shí)，SGSN/MME可在通知信令中(如 Notify Request)增加指示信息(如 Delay StateIndicator)從而向 HLR/HSS 通知 MD 是否處于時(shí)延等待狀態(tài)。接收到該信息后，HLR/HSS可在Subscriber上下文信息中增加時(shí)延等待狀態(tài)指示信息(如Delay State Indicator)來記錄MD的數(shù)據(jù)傳輸是否被3GPP網(wǎng)絡(luò)限制。MTC Server 通過 Sh 接口信令(如 User Data Request, SubscribeNotifications Request等)從核心網(wǎng)設(shè)備HLR/HSS獲取3GPP網(wǎng)絡(luò)系統(tǒng)為MD設(shè)置的時(shí)延等待時(shí)間或者M(jìn)D 的時(shí)延等待狀態(tài)。根據(jù)所采用Si接口信令的不同，MTC Server可有基于訂閱和基于查詢兩種不同的獲取方法一、訂閱MTC Server 向 HLR/HSS 發(fā)送訂閱通知請求(如 Subscribe NotificationsRequest)信令，要求HLR/HSS在3GPP網(wǎng)絡(luò)系統(tǒng)為MD設(shè)置的時(shí)延等待時(shí)間參數(shù)或者M(jìn)D的時(shí)延等待狀態(tài)發(fā)生變化時(shí)對其進(jìn)行通知。方法二、查詢MTC Server向HLR/HSS發(fā)送用戶數(shù)據(jù)請求(如her-Data-Request)信令，要求 HLR/HSS為其提供當(dāng)前記錄的MD時(shí)延等待時(shí)間參數(shù)信息或者M(jìn)D時(shí)延等待狀態(tài)信息。MTC krver為具有時(shí)延容忍特性的MD設(shè)置一個(gè)時(shí)延等待定時(shí)器用于控制下行方向數(shù)據(jù)業(yè)務(wù)的傳輸。如果從HLR/HSS獲得了 MD的時(shí)延等待時(shí)間，那么MTC Server依照所獲取的時(shí)間參數(shù)值設(shè)置并啟動(dòng)該定時(shí)器。如果從HLR/HSS獲知MD處于時(shí)延等待狀態(tài)，那么 MTC krver可依系統(tǒng)給定的默認(rèn)時(shí)延等待時(shí)間(即前述的預(yù)設(shè)的時(shí)延等待時(shí)間參數(shù))設(shè)置并啟動(dòng)該定時(shí)器。具體來講，MTC Server的處理過程如下當(dāng)下行數(shù)據(jù)到達(dá)并需要向MD傳輸時(shí)，MTC krver查看是否已為該MD啟動(dòng)了時(shí)延等待定時(shí)器并決定后續(xù)操作。
如果未啟動(dòng)時(shí)延等待定時(shí)器，那么MTC Server將到達(dá)的IP數(shù)據(jù)分組直接發(fā)送至 3GGP核心網(wǎng)PDN網(wǎng)關(guān)節(jié)點(diǎn)(如P-GW)。如果已啟動(dòng)了時(shí)延等待定時(shí)器，那么MTC krver將到達(dá)的IP數(shù)據(jù)分組暫時(shí)緩存起來。待定時(shí)器超時(shí)后，MTC Server可根據(jù)下行數(shù)據(jù)傳輸?shù)男枰?GGP核心網(wǎng)PDN網(wǎng)關(guān)節(jié)點(diǎn)繼續(xù)發(fā)送。其中，對應(yīng)前述的方法一，如果MTC krver采取基于訂閱的方法獲取3GPP網(wǎng)絡(luò)系統(tǒng)為MD設(shè)置的時(shí)延等待時(shí)間參數(shù)或MD的時(shí)延等待狀態(tài)，那么當(dāng)MD在MTC Server上注冊完畢之后，MTC Server向HLR/HSS發(fā)送訂閱通知請求(如Subscribe Notifications Request)信令，要求HLR/HSS在系統(tǒng)所設(shè)置的等待時(shí)間參數(shù)或MD的時(shí)延等待狀態(tài)發(fā)生變化時(shí)對其進(jìn)行通知。當(dāng)系統(tǒng)所設(shè)置的時(shí)延等待時(shí)間參數(shù)或MD的時(shí)延等待狀態(tài)發(fā)生變化時(shí)，MTC Server 接收HLR/HSS發(fā)送的推送通知請求(如Push Notification Request)信令，并以推送通知應(yīng)答(如Push Notification Answer)信令對HLR/HSS進(jìn)行響應(yīng)。這里，如果推送通知請求信令中攜帶的參數(shù)為3GPP網(wǎng)絡(luò)系統(tǒng)為MD設(shè)置的時(shí)延等待時(shí)間，那么MTC Server依照此參數(shù)設(shè)置并啟動(dòng)一個(gè)時(shí)延等待定時(shí)器。如果推送通知請求信令中攜帶的參數(shù)為MD的時(shí)延等待狀態(tài)，那么MTC krver可依系統(tǒng)給定的默認(rèn)時(shí)延等待時(shí)間設(shè)置并啟動(dòng)一個(gè)時(shí)延等待定定時(shí)器。另一方面，對應(yīng)前述的方法二，如果MTC krver采取基于查詢的方法獲取3GPP網(wǎng)絡(luò)系統(tǒng)為MD設(shè)置的時(shí)延等待時(shí)間參數(shù)或MD的時(shí)延等待狀態(tài)，那么在接收到經(jīng)P-GW轉(zhuǎn)發(fā)由 S-Gff發(fā)送的ICMP控制分組時(shí)，MTC Server向HLR/HSS發(fā)送用戶數(shù)據(jù)請求(如her Data Request)信令，要求HLR/HSS提供當(dāng)前記錄的MD時(shí)延等待時(shí)間參數(shù)信息或者M(jìn)D的時(shí)延等待狀態(tài)信息。當(dāng)接收到HLR/HSS發(fā)送的用戶數(shù)據(jù)應(yīng)答信1令時(shí)，對于前者M(jìn)TC Server從中提取 3GPP網(wǎng)絡(luò)系統(tǒng)為MD設(shè)置的時(shí)延等待時(shí)間參數(shù)，并依此參數(shù)值設(shè)置并啟動(dòng)一個(gè)時(shí)延等待定時(shí)器。對于后者當(dāng)MTC設(shè)備處于時(shí)延等待狀態(tài)時(shí)，MTC krver可依系統(tǒng)給定的默認(rèn)時(shí)延等待時(shí)間(即前述的預(yù)設(shè)的時(shí)延等待時(shí)間參數(shù))設(shè)置并啟動(dòng)一個(gè)時(shí)延等待定時(shí)器。在上述的處理過程中，PDN網(wǎng)關(guān)節(jié)點(diǎn)(如P-GW)在接收到MTC Server發(fā)送的下行 IP數(shù)據(jù)分組時(shí)，P-Gff按照現(xiàn)有3GPP協(xié)議的要求對數(shù)據(jù)分組進(jìn)行協(xié)議轉(zhuǎn)換及適配。在完成 IP數(shù)據(jù)分組的GTP協(xié)議封裝之后，它將下行數(shù)據(jù)發(fā)送給服務(wù)數(shù)據(jù)網(wǎng)關(guān)(如S-GW)。如果接收到S-GW發(fā)送的ICMP控制消息，P-Gff完成協(xié)議轉(zhuǎn)換及適配，向MTC Server轉(zhuǎn)發(fā)ICMP數(shù)據(jù)分組。另一方面，服務(wù)數(shù)據(jù)網(wǎng)關(guān)(如S-GW)在接收到P-GW發(fā)送的下行數(shù)據(jù)分組時(shí)，如果 MD處于連接態(tài)，即S-GW與目的MD間已建立了無線接入連接，那么S-GW直接通過此連接向 MD傳輸下行數(shù)據(jù)。如果MD處于空閑態(tài)，即S-GW與目的MD間未建立無線接入連接，S-Gff則緩存到達(dá)的下行數(shù)據(jù)分組并依照協(xié)議TS 23. 060/TS 23.401中網(wǎng)絡(luò)觸發(fā)的服務(wù)請求流程進(jìn)行處理，即S-GW通過下行數(shù)據(jù)通知(如Downlink Data Notification)信令通知SGSN/ MME對處于空閑態(tài)的MD發(fā)起尋呼，以建立無線接入連接。而在服務(wù)數(shù)據(jù)網(wǎng)關(guān)(如S-GW)接收到SGSN/MME返回的下行數(shù)據(jù)通知應(yīng)答(如 Downlink Data Notification Acknowledge)信令時(shí)，如果原因參數(shù)指明目的MD由于被網(wǎng)絡(luò)系統(tǒng)限制服務(wù)而造成尋呼操作未能進(jìn)行；或者，在接收到SGSN/MME返回的下行數(shù)據(jù)通知失敗指示(如 Downlink Data NotificationFailure Indication)信令，其中的原因參數(shù)指明服務(wù)建立失敗是由于網(wǎng)絡(luò)拒絕向MD提供傳輸服務(wù)所致時(shí)，S-Gff經(jīng)P-GW向MTC Server 發(fā)送目的主機(jī)不可達(dá) ICMP/ICMPv6anternet Control Message Protocol/ICMP for IPv6) 控制消息通知MTC Server目的MD不可達(dá)并丟棄為該MD緩存的下行數(shù)據(jù)分組。實(shí)際應(yīng)用中，具體是發(fā)送ICMP消息還是發(fā)送ICMPv6消息需要根據(jù)核心網(wǎng)所支持的IP協(xié)議棧版本來定。若核心網(wǎng)支持IPv4協(xié)議棧，S-Gff則發(fā)送ICMP消息；若核心網(wǎng)支持 IPv6協(xié)議?；螂p棧，那么S-GW發(fā)送ICMPv6消息。在產(chǎn)生目的主機(jī)不可達(dá)ICMP/ICMPv6控制消息時(shí)，S-Gff有如下操作步驟1)若采用ICMP消息，“類型”置為3，，，代碼”置為1 ；若采用ICMPv6消息，“類型” 置為1，”代碼”置為3;2)從為MD緩存的封裝在GTP-U協(xié)議中的用戶IP數(shù)據(jù)分組中提取分組頭以及數(shù)據(jù)域前8個(gè)字節(jié)，將其填入ICMP控制消息“Internet包頭+源數(shù)據(jù)報(bào)”信息域中；若為ICMPv6， 則應(yīng)在不超過IPv6最小MTU(Maximum TransferUnit)的條件下，盡可能多的在ICMPv6消息中填入原用戶IP數(shù)據(jù)分組中的信息。3)完成校驗(yàn)和的計(jì)算，將結(jié)果填入“校驗(yàn)碼”信息域中。4)從為MD緩存的封裝在GTP-U協(xié)議中的用戶IP數(shù)據(jù)分組中提取源MTC krver及目的MD的IP地址。之后，將所獲得到的源、目的IP地址相互調(diào)換從而構(gòu)成用于封裝ICMP 控制消息的IP分組的源、目的IP地址，即，S-GW將所獲得的目的MD的IP地址作為封裝 ICMP/ICMPv6消息IP分組的源IP地址，將MTC Server的IP地址作為封裝ICMP/ICMPv6消息IP分組的目的IP地址。5)按照IP協(xié)議規(guī)范的要求，完成封裝ICMP/ICMPv6消息的IP分組首部其他信息域的填寫。ICMP/ICMPv6控制消息及用于封裝ICMP/ICMPv6分組的IP分組構(gòu)建完畢之后， S-GW根據(jù)S5/S8接口協(xié)議的不同，采取不同方式向MTC krver發(fā)送ICMP/ICMPv6分組。若 S5/S8接口采用的是GTP (GPRS Tunneling Protocol)協(xié)議，S-GW將封裝目的主機(jī)不可達(dá) ICMP/ICMPv6消息的IP分組作為服務(wù)數(shù)據(jù)單元封裝在GTP-U分組中沿原隧道經(jīng)P-GW發(fā)送給 MTC Server ；若 S5/S8 接口若采用 PMIP 的是 GRE (Generic Routing Encapsulation)協(xié)議或其它IP隧道協(xié)議，那么S-GW將封裝目的主機(jī)不可達(dá)ICMP/ICMPv6消息的IP分組作為服務(wù)數(shù)據(jù)單元封裝在所采用隧道協(xié)議的分組中沿原隧道經(jīng)P-GW發(fā)送給MTC Server0考慮到IP協(xié)議并不保證ICMP/ICMPv6消息的可靠交付，因此為了保證MTC Server 能夠以較大概率正確接收到ICMP/ICMPv6，S-GW—般要多次發(fā)送主機(jī)不可達(dá)ICMP/ICMPv6 消息，例如3 5次。進(jìn)一步的，核心網(wǎng)管理控制實(shí)體(如SGSN/MME)在接收到S-GW發(fā)送的下行數(shù)據(jù)通知(如Downlink Data Notification)信令時(shí)，SGSN/MME首先查看MD上下文中維護(hù)的時(shí)延等待時(shí)間參數(shù)或MD時(shí)延等待狀態(tài)指示，從而判斷MD是否已經(jīng)處于時(shí)延等待狀態(tài)。對于目的MD，如果SGSN/MME尚未維護(hù)MD時(shí)延等待時(shí)間參數(shù)或者M(jìn)D時(shí)延等待狀態(tài)指示，或者，時(shí)延等待時(shí)間參數(shù)或者時(shí)延等待指示等待過期或失效，SGSN/MME將以下行數(shù)據(jù)通知應(yīng)答(如Downlink Data Notif icationAcknowledge)信令對S-GW進(jìn)行響應(yīng)，表明請求被接受，并在MD注冊的路由區(qū)域/跟蹤區(qū)域中發(fā)起尋呼，觸發(fā)MD發(fā)起上行服務(wù)請求。如果SGSN/MME維護(hù)了一個(gè)有效的時(shí)延等待時(shí)間參數(shù)或者時(shí)延等待狀態(tài)指示，那么SGSN/MME將不會(huì)向MD發(fā)起尋呼，并將向S-GW返回下行數(shù)據(jù)通知應(yīng)答(如Downlink Data Notification Acknowledge)信令拒絕S_GW的通知請求，其中原因參數(shù)指明目的MD由于被網(wǎng)絡(luò)系統(tǒng)限制服務(wù)而造成尋呼操作未能進(jìn)行。這里MD時(shí)延等待狀態(tài)指示失效或者過期是指MD時(shí)延等待狀態(tài)指示的有效期達(dá)到或超出系統(tǒng)給定的默認(rèn)時(shí)延等待時(shí)間。在SGSN/MME接收到具有時(shí)間容忍特性MD發(fā)起的服務(wù)請求信令(如krvice Request)時(shí)，SGSN/MME依照現(xiàn)有的技術(shù)流程進(jìn)行操作。在接入網(wǎng)負(fù)載滿足(預(yù))定義網(wǎng)絡(luò)負(fù)載門限要求的情況下，SGSN/MME將接受MD的服務(wù)請求。在接入網(wǎng)負(fù)載達(dá)到或超過(預(yù)) 定義網(wǎng)絡(luò)負(fù)載門限的情況下，SGSN/MME將拒絕MD的服務(wù)請求。此時(shí)SGSN/MME向S-GW發(fā)送下行數(shù)據(jù)通知失敗指示(如 Downlink Data Notification Failure Indication)信令， 其中原因參數(shù)指明服務(wù)建立失敗是由于網(wǎng)絡(luò)拒絕向MD提供傳輸服務(wù)所致。在此過程之中， 如果3GPP網(wǎng)絡(luò)系統(tǒng)為MD分配了時(shí)延等待時(shí)間，那么SGSN/MME將其保存并負(fù)責(zé)維護(hù)。如果 3GPP網(wǎng)絡(luò)系統(tǒng)沒有為MD分配時(shí)延等待時(shí)間，那么SGSN/MME可在MD上下文中設(shè)置時(shí)延等待狀態(tài)指示，并將其有效期設(shè)置為系統(tǒng)給定的默認(rèn)時(shí)延等待時(shí)間。如果所維護(hù)的時(shí)延等待時(shí)間參數(shù)或時(shí)延等待狀態(tài)發(fā)生變化(例如，從無到有，從有到無，發(fā)生更新等)，SGSN/MME通過S6a/S6d接口向HLR/HSS發(fā)送通知信令(如Notify Request)通知HLR/HSS更新所記錄的時(shí)延等待時(shí)間參數(shù)(如Delayed Time)或者時(shí)延等待狀態(tài)指示信息(如Delay Statehdicator)。發(fā)送時(shí)，SGSN/MME在通知消息中增加時(shí)延等待時(shí)間參數(shù)(如Delayed Time)或時(shí)延等待狀態(tài)指示(如Delay State Indicator)用于攜帶MD最新的時(shí)延等待時(shí)間或MD最新的時(shí)延等待狀態(tài)信息。在本技術(shù)方案中，對其按前述的兩種方法，HLR/HSS的行為也對應(yīng)的存在兩種情況情況一、對于訂閱的方法，在接收到MTC Server發(fā)送的訂閱通知請求 (如 Subscribe-Notifications-Request)信令時(shí)，HLR/HSS 以訂閱通知應(yīng)答(如 Subscribe-Notifications-Answer)信令進(jìn)行響應(yīng)，并監(jiān)測3GPP網(wǎng)絡(luò)系統(tǒng)為MD設(shè)置的時(shí)延等待時(shí)間參數(shù)或MD時(shí)延等待狀態(tài)是否發(fā)生更新。情況二、對于查詢的方法，在接收到MTC krver發(fā)送的用戶數(shù)據(jù)請求(如 User-Data-Request)信令時(shí)，HLR/HSS以用戶數(shù)據(jù)應(yīng)答(如User-Data-Answer)信令進(jìn)行響應(yīng)，并通過此信令將3GPP網(wǎng)絡(luò)系統(tǒng)為MD設(shè)置的時(shí)延等待時(shí)間參數(shù)值或MD時(shí)延等待狀態(tài)告知 MTC Server0在接收到SGSN/MME發(fā)送的通知請求(如Notify Request)信令時(shí)，HLR/HSS依照該信令攜帶的時(shí)延等待時(shí)間參數(shù)信息(如Delayed Time)或時(shí)延等待狀態(tài)指示(如Delay State hdicator)更新所記錄的時(shí)延等待時(shí)間參數(shù)(如Delay Time)或時(shí)延等待狀態(tài)指示信息(如Delay State Indicator)，并以通知應(yīng)答(如Notify Answer)信令進(jìn)行響應(yīng)。更新完畢后，如果MTC krver通過訂閱通知請求信令要求HLR/HSS在時(shí)延等待時(shí)間參數(shù)或時(shí)延等待狀態(tài)發(fā)生變更后對其進(jìn)行通知，那么HLR/HSS通過證接口向MTC Server 發(fā)送推送通知請求(如Push-Notification-Request)信令以告知MTC Server 3GPP網(wǎng)絡(luò)系統(tǒng)為MD設(shè)置的最新的時(shí)延等待時(shí)間或MD最新的時(shí)延等待狀態(tài)。這里值得說明的是除了使S-GW產(chǎn)生主機(jī)不可達(dá)ICMP/ICMPv6控制消息向MTC krver通知目的MD不可達(dá)之外，也可使P-GW基于同樣的原理產(chǎn)生主機(jī)不可達(dá)ICMP/ ICMPv6控制消息通知MTC Server目的MD不可達(dá)。但后者要求系統(tǒng)在S-GW與P-GW之間采取新的通知機(jī)制以使P-GW獲得構(gòu)建ICMP/ICMPv6分組所需的必要信息。下面，結(jié)合具體的應(yīng)用場景進(jìn)行說明如圖8所示，為本發(fā)明實(shí)施例所提出的一種具體應(yīng)用場景下的MTC設(shè)備下行數(shù)據(jù)傳輸控制方法的流程示意圖，對于MTC訂閱時(shí)延等待時(shí)間參數(shù)信息，且MD未處于時(shí)延等待狀態(tài)的情況進(jìn)行說明。本實(shí)施例中，MTC krver基于訂閱方式從HSS獲取網(wǎng)絡(luò)系統(tǒng)MD設(shè)置的時(shí)延等待時(shí)間。步驟S801、核心網(wǎng)管理控制實(shí)體與HLR/HSS交互MD的簽約信息，其中包含網(wǎng)絡(luò)負(fù)載門限參數(shù)的信息。假設(shè)MD A具有Time Tolerant特性，簽約時(shí)為MD A設(shè)定的接入網(wǎng)負(fù)載門限為0. 7， 即當(dāng)接入網(wǎng)負(fù)載達(dá)到0.7或0.7以上時(shí)，網(wǎng)絡(luò)將不為MD A提供數(shù)據(jù)傳輸服務(wù)。這樣，HSS 在MD A的簽約信息中增加網(wǎng)絡(luò)負(fù)載門限參數(shù)(如Load Threshold)并將其值設(shè)置為0. 7。 此外，HSS還在MD A的簽約信息中增加時(shí)延等待時(shí)間參數(shù)(如Delay Time)用于記錄3GPP 網(wǎng)絡(luò)為MD A分配的時(shí)延等待時(shí)間。當(dāng)MD A發(fā)起Attach過程附著至網(wǎng)絡(luò)時(shí)，為MD A提供服務(wù)的MME從HSS讀取MD A 的簽約信息并在本地維護(hù)的MD A的上下文中增加負(fù)載門限參數(shù)信息(如Load Threshold) 保存簽約的負(fù)載門限值0.7。步驟S802、MD A向MTC Server進(jìn)行登錄注冊。為了使用MTC Server提供的服務(wù)，MD A在Attach過程中或者在Attach過程完畢后向MTC krver進(jìn)行登錄注冊。步驟S803、MTC Server向HLR/HSS訂閱MD A的時(shí)延等待時(shí)間參數(shù)信息。MTC Server 向 MD A 所屬 3GPP 核心網(wǎng) HSS 發(fā)送 Subscribe NotificationsRequest 信令，在其中指明要求HSS在3GPP網(wǎng)絡(luò)系統(tǒng)為MD A設(shè)置的時(shí)延等待時(shí)間參數(shù)發(fā)生變化時(shí)對其進(jìn)行通知。HSS以Subscribe Notifications Answer信令進(jìn)行響應(yīng)。附著，登錄注冊等初始化過程完畢之后，MD A沒有數(shù)據(jù)傳輸需求，返回空閑態(tài)。步驟S804、MTC Server中出現(xiàn)需要發(fā)送給MD A的下行數(shù)據(jù)。在某一時(shí)刻，如19:00，MTC krver有業(yè)務(wù)產(chǎn)生需要向MD A進(jìn)行下行數(shù)據(jù)傳輸。步驟S805、MTC krver判斷對MD A是否啟動(dòng)了時(shí)延等待定時(shí)器。如果啟動(dòng)了，則直接緩存該下行數(shù)據(jù)，等時(shí)延等待定時(shí)器超時(shí)時(shí)，再發(fā)送該下行數(shù)據(jù)，為了說明方便，此種情況在此不作說明，重點(diǎn)對沒有啟動(dòng)的情況進(jìn)行說明。假設(shè)時(shí)延等待定時(shí)器尚未啟動(dòng)，則執(zhí)行步驟S806。步驟S806、MTC Server將到達(dá)的IP數(shù)據(jù)分組直接發(fā)送至3GGP核心網(wǎng)P-GW。步驟S807、P-Gff對接收到的這些下行IP數(shù)據(jù)分組進(jìn)行協(xié)議轉(zhuǎn)換及適配，在完成 GTP協(xié)議封裝之后，轉(zhuǎn)發(fā)至S-GW。步驟S808、S_GW向核心網(wǎng)管理控制實(shí)體(后續(xù)直接以MME為例進(jìn)行說明)發(fā)送下1行數(shù)據(jù)通知。由于MD A處于空閑態(tài)，S-GW與MD之間不存在已建立的無線接入連接，因此S-GW 緩存到達(dá)的下行數(shù)據(jù)分組,并向MME發(fā)送Downlink DataNotification信令促使MME對MD A發(fā)起尋呼。步驟S809、MME判定MD A是否處于時(shí)延等待狀態(tài)。接收到S-GW發(fā)送的Downlink Data Notification信令時(shí)，MME首先查看MD A上下文中維護(hù)的時(shí)延等待時(shí)間參數(shù)(如Delayed Time)，判斷MD是否已處于時(shí)延等待狀態(tài)。如果是，則直接執(zhí)行步驟S813，此種情況不再另行說明；如果不是，則執(zhí)行步驟S810和步驟S811，其中，步驟S810和步驟S811之間沒有必然的先后關(guān)系，序號的存在只是為了描述方便。步驟S810、MME向S-GW反饋下行數(shù)據(jù)通知應(yīng)答，表示接受下行數(shù)據(jù)請求。假設(shè)MME尚未維護(hù)時(shí)延等待時(shí)間參數(shù)(如，Delayed Time值為空)，那么MME將以 Downlink Data Notification Acknowledge信令對S-GW進(jìn)行響應(yīng)，表明請求被接受。步驟S811、MME在MD A注冊的跟蹤區(qū)域中對MD A發(fā)起尋呼。步驟S812、MD A向MME請求建立無線接入連接。在接收到網(wǎng)絡(luò)側(cè)的尋呼信令之后，MD A向MME發(fā)送NAS信令ServiceRequest，請求建立無線接入連接。此后，網(wǎng)絡(luò)及終端MD A依照現(xiàn)有的技術(shù)方案對服務(wù)請求過程進(jìn)行處理。若當(dāng)前接入網(wǎng)負(fù)載為0.5，小于Load Threshold值0. 7，即表明接入網(wǎng)絡(luò)當(dāng)前負(fù)載在MD A的負(fù)載門限允許范圍之內(nèi)，能夠?yàn)镸D A提供服務(wù)，那么在服務(wù)請求過程處理完畢時(shí)，網(wǎng)絡(luò)最終將建立起無線接入連接允許下行數(shù)據(jù)傳輸。若當(dāng)前接入網(wǎng)負(fù)載為0.8，大于Load Threshold值0.7，即表明接入網(wǎng)當(dāng)前負(fù)載超出MD A簽約的負(fù)載門限，那么網(wǎng)絡(luò)最終將拒絕MD A的服務(wù)請求，并根據(jù)網(wǎng)絡(luò)負(fù)載狀況為MD A分配一個(gè)時(shí)延等待時(shí)間參數(shù)(如 19:30)要求MD A延遲30分鐘之后方可再次請求服務(wù)。本實(shí)施例對于后一種情況進(jìn)行具體說明如下。步驟S813、MME向S-GW發(fā)送下行數(shù)據(jù)失敗指示。MME 向 S-GW 返回 Downlink Data Notification Failure Indication 信令，其中原因參數(shù)指明服務(wù)建立失敗是由于網(wǎng)絡(luò)拒絕向MD提供傳輸服務(wù)所致。MME在MD A上下文Delayed Time參數(shù)中保存網(wǎng)絡(luò)系統(tǒng)為MD A分配的時(shí)延等待時(shí)間 19:30。接收到Downlink Data Notification Failure hdication 信令時(shí)，S-GW 丟棄為 MD A緩存的下行數(shù)據(jù)分組并通過P-GW向MTC Server發(fā)送ICMP控制消息通知MTC Server 終端MD A不可達(dá)。同時(shí)，在執(zhí)行本步驟的同時(shí)，進(jìn)一步執(zhí)行步驟S814。步驟S814、MME通知HLR/HSS新的時(shí)延等待時(shí)間參數(shù)。由于所維護(hù)的時(shí)延等待參數(shù)發(fā)生變化，MME通過S6a接口向HSS發(fā)送Notify Request信令通知HSS將所記錄的時(shí)延等待時(shí)間參數(shù)更新為19:30。HSS以Notify Answer 信令進(jìn)行響應(yīng)。更新完畢之后，HSS發(fā)送Push NotificationRequest信令將網(wǎng)絡(luò)為MD A設(shè)定的延遲等待時(shí)間19:30告知MTC Server。
在收到HSS 發(fā)送的 Push-Notification-Request 信令時(shí)，MTC Server 從中提取攜帶的時(shí)延等待時(shí)間參數(shù)并將本地的時(shí)延等待定時(shí)器設(shè)置為19:30并啟動(dòng)。同時(shí)，MTC Server 以 Push Notification Answer 信令對 HSS 進(jìn)行響應(yīng)。在定時(shí)器超時(shí)(19:30到達(dá))之前，若有數(shù)據(jù)分組到達(dá)，MTC krver緩存到達(dá)的下行IP數(shù)據(jù)分組并暫停通過3GPP網(wǎng)絡(luò)向MD A發(fā)送數(shù)據(jù)。待定時(shí)器超時(shí)之后，MTC krver可向3GPP核心網(wǎng)P-GW發(fā)送數(shù)據(jù)，進(jìn)而重新觸發(fā)服務(wù)請求。如圖9所示，為本發(fā)明實(shí)施例所提出的一種具體應(yīng)用場景下的MTC設(shè)備下行數(shù)據(jù)傳輸控制方法的流程示意圖，對于MTC訂閱時(shí)延等待時(shí)間參數(shù)信息，且MD已經(jīng)處于時(shí)延等待狀態(tài)的情況進(jìn)行說明。對于與圖8所示的實(shí)施例相同的應(yīng)用場景，步驟S901至步驟S903與步驟S801至步驟S803相一致。MD A 完成登錄注冊之后，MTC Server 通過 Subscribe-Notif ications-Request 信令向MD A所屬3GPP核心網(wǎng)HSS發(fā)出訂閱請求，要求HSS在3GPP網(wǎng)絡(luò)系統(tǒng)為MD A設(shè)置的時(shí)延等待時(shí)間參數(shù)發(fā)生變化時(shí)對其進(jìn)行通知。HSS以Subscribe-Notifications-Answer信令進(jìn)行響應(yīng)。附著，登錄注冊等初始化過程完畢之后，MD A沒有數(shù)據(jù)傳輸需求，返回空閑態(tài)。步驟S904、MD A中出現(xiàn)需要發(fā)送的上行數(shù)據(jù)。在某一時(shí)刻，如19:00，MD A有業(yè)務(wù)數(shù)據(jù)到達(dá)并向網(wǎng)絡(luò)發(fā)起服務(wù)請求。步驟S905、MD A向MME請求建立無線接入連接。此時(shí)，若接入網(wǎng)負(fù)載為0.8，大于Load Threshold值0. 7，網(wǎng)絡(luò)將拒絕MDA的服務(wù)請求，并為MD A分配一個(gè)時(shí)延等待時(shí)間參數(shù)(如19:30)要求MD A延遲30分鐘之后方可再次請求服務(wù)。MME在MD A上下文DelayedTime參數(shù)中將網(wǎng)絡(luò)系統(tǒng)為MD A分配的時(shí)延等待時(shí)間更新為19:30。步驟S906、MME通知HLR/HSS新的時(shí)延等待時(shí)間參數(shù)。由于所維護(hù)的時(shí)延等待參數(shù)發(fā)生變化，MME通過S6a接口向HSS發(fā)送Notify Request信令通知HSS將所記錄的時(shí)延等待時(shí)間參數(shù)更新為19:30。HSS以Notify Answer 信令進(jìn)行響應(yīng)。更新完畢之后，HSS發(fā)送Push-Notification-Request信令將網(wǎng)絡(luò)為MD A設(shè)定的延遲等待時(shí)間19:30告知MTC Server。在收到HSS 發(fā)送的 Push-Notification-Request 信令時(shí)，MTC Server 從中提取攜帶的時(shí)延等待時(shí)間參數(shù)并將本地的時(shí)延等待定時(shí)器設(shè)置為19:30并啟動(dòng)。同時(shí)，MTC Server 以 Push-Notification-Answer 信令對 HSS 進(jìn)行響應(yīng)。由于已啟動(dòng)了時(shí)延等待定時(shí)器，因此在定時(shí)器超時(shí)(19:30到達(dá))之前，若有數(shù)據(jù)分組到達(dá)，MTC krver緩存到達(dá)的下行IP數(shù)據(jù)分組并暫停通過3GPP網(wǎng)絡(luò)向MD A發(fā)送數(shù)據(jù)。待定時(shí)器超時(shí)之后，MTC krver可向3GPP核心網(wǎng)P-GW發(fā)送數(shù)據(jù)，進(jìn)而重新觸發(fā)服務(wù)請求。如圖10所示，為本發(fā)明實(shí)施例所提出的一種具體應(yīng)用場景下的MTC設(shè)備下行數(shù)據(jù)傳輸控制方法的流程示意圖，對于MTC查詢時(shí)延等待時(shí)間參數(shù)信息，且MD未處于時(shí)延等待狀態(tài)的情況進(jìn)行說明。
本實(shí)施例中，MTC Server基于查詢方式從HSS獲取網(wǎng)絡(luò)系統(tǒng)MD設(shè)置的時(shí)延等待時(shí)間。步驟S1001、核心網(wǎng)管理控制實(shí)體與HLR/HSS交互MD的簽約信息，其中包含網(wǎng)絡(luò)負(fù)載門限參數(shù)的信息。假設(shè)MD A具有Time Tolerant特性，簽約時(shí)為MD A設(shè)定的接入網(wǎng)負(fù)載門限為0. 7， 即當(dāng)接入網(wǎng)負(fù)載達(dá)到0.7或0.7以上時(shí)，網(wǎng)絡(luò)將不為MD A提供數(shù)據(jù)傳輸服務(wù)。這樣，HSS 在MD A的簽約信息中增加網(wǎng)絡(luò)負(fù)載門限參數(shù)(如Load Threshold)并將其值設(shè)置為0. 7。 此外，HSS還在MD A的簽約信息中增加時(shí)延等待時(shí)間參數(shù)(如Delay Time)用于記錄3GPP 網(wǎng)絡(luò)為MD A分配的時(shí)延等待時(shí)間。當(dāng)MD A發(fā)起Attach過程附著至網(wǎng)絡(luò)時(shí)，為MD A提供服務(wù)的MME從HSS讀取MD A 的簽約信息并在本地維護(hù)的MD A的上下文中增加負(fù)載門限參數(shù)信息(如Load Threshold) 保存簽約的負(fù)載門限值0.7。步驟S1002、MD A向MTC Server進(jìn)行登錄注冊。為了使用MTC Server提供的服務(wù)，MD A在Attach過程中或者在Attach過程完畢后向MTC krver進(jìn)行登錄注冊。附著，登錄注冊等初始化過程完畢之后，MD A沒有數(shù)據(jù)傳輸需求，返回空閑態(tài)。步驟S1003、MTC Server中出現(xiàn)需要發(fā)送給MD A的下行數(shù)據(jù)。在某一時(shí)刻，如19:00，MTC krver有業(yè)務(wù)產(chǎn)生需要向MD A進(jìn)行下行數(shù)據(jù)傳輸。步驟S1004、MTC krver判斷對MD A是否啟動(dòng)了時(shí)延等待定時(shí)器。如果啟動(dòng)了，則直接緩存該下行數(shù)據(jù)，等時(shí)延等待定時(shí)器超時(shí)時(shí)，再發(fā)送該下行數(shù)據(jù)，為了說明方便，此種情況在此不作說明，重點(diǎn)對沒有啟動(dòng)的情況進(jìn)行說明。假設(shè)時(shí)延等待定時(shí)器尚未啟動(dòng)，則執(zhí)行步驟S1005。步驟S1005、MTC Server將到達(dá)的IP數(shù)據(jù)分組直接發(fā)送至3GGP核心網(wǎng)P-GW。步驟S1006、P-GW對接收到的這些下行IP數(shù)據(jù)分組進(jìn)行協(xié)議轉(zhuǎn)換及適配，在完成 GTP協(xié)議封裝之后，轉(zhuǎn)發(fā)至S-GW。步驟S1007、S-Gff向核心網(wǎng)管理控制實(shí)體(后續(xù)直接以MME為例進(jìn)行說明)發(fā)送下行數(shù)據(jù)通知。由于MD A處于空閑態(tài)，S-Gff與MD之間不存在已建立的無線接入連接，因此S-GW 緩存到達(dá)的下行數(shù)據(jù)分組,并向MME發(fā)送Downlink DataNotification信令促使MME對MD A發(fā)起尋呼。步驟S1008、MME判定MD A是否處于時(shí)延等待狀態(tài)。接收到S-GW發(fā)送的Downlink Data Notification信令時(shí)，MME首先查看MD A上下文中維護(hù)的時(shí)延等待時(shí)間參數(shù)(如Delayed Time)，判斷MD是否已處于時(shí)延等待狀態(tài)。如果是，則直接執(zhí)行步驟S1012，此種情況不再另行說明；如果不是，則執(zhí)行步驟S1009和步驟S1010，其中，步驟S1009和步驟S1010之間沒
有必然的先后關(guān)系，序號的存在只是為了描述方便。步驟S1009、MME向S-GW反饋下行數(shù)據(jù)通知應(yīng)答，表示接受下行數(shù)據(jù)請求。假設(shè)MME尚未維護(hù)時(shí)延等待時(shí)間參數(shù)(如，Delayed Time值為空)，那么MME將以 Downlink Data Notification Acknowledge信令對S-GW進(jìn)行響應(yīng)，表明請求被接受。
步驟S1010、MME在MD A注冊的跟蹤區(qū)域中對MD A發(fā)起尋呼。步驟S1011、MD A向MME請求建立無線接入連接。在接收到網(wǎng)絡(luò)側(cè)的尋呼信令之后，MD A向MME發(fā)送NAS信令ServiceRequest，請求建立無線接入連接。此后，網(wǎng)絡(luò)及終端MD A依照現(xiàn)有的技術(shù)方案對服務(wù)請求過程進(jìn)行處理。若當(dāng)前接入網(wǎng)負(fù)載為0.5，小于Load Threshold值0. 7，即表明接入網(wǎng)絡(luò)當(dāng)前負(fù)載在MD A的負(fù)載門限允許范圍之內(nèi)，能夠?yàn)镸D A提供服務(wù)，那么在服務(wù)請求過程處理完畢時(shí)，網(wǎng)絡(luò)最終將建立起無線接入連接允許下行數(shù)據(jù)傳輸。若當(dāng)前接入網(wǎng)負(fù)載為0.8，大于Load Threshold值0.7，即表明接入網(wǎng)當(dāng)前負(fù)載超出MD A簽約的負(fù)載門限，那么網(wǎng)絡(luò)最終將拒絕MD A的服務(wù)請求，并根據(jù)網(wǎng)絡(luò)負(fù)載狀況為MD A分配一個(gè)時(shí)延等待時(shí)間參數(shù)(如 19:30)要求MD A延遲30分鐘之后方可再次請求服務(wù)。本實(shí)施例對于后一種情況進(jìn)行具體說明如下。步驟S1012、MME向S-GW發(fā)送下行數(shù)據(jù)失敗指示。MME 向 S-GW 返回 Downlink Data Notification Failure Indication 信令，其中原因參數(shù)指明服務(wù)建立失敗是由于網(wǎng)絡(luò)拒絕向MD提供傳輸服務(wù)所致。MME在MD A上下文Delayed Time參數(shù)中保存網(wǎng)絡(luò)系統(tǒng)為MD A分配的時(shí)延等待時(shí)間 19:30。接收到Downlink Data Notification Failure hdication 信令時(shí)，S-GW 丟棄為 MD A緩存的下行數(shù)據(jù)分組并通過P-GW向MTC Server發(fā)送ICMP控制消息通知MTC Server 終端MD A不可達(dá)。同時(shí)，在執(zhí)行本步驟的同時(shí)，進(jìn)一步執(zhí)行步驟S1013。步驟S1013、MME通知HLR/HSS新的時(shí)延等待時(shí)間參數(shù)。由于所維護(hù)的時(shí)延等待參數(shù)發(fā)生變化，MME通過S6a接口向HSS發(fā)送Notify Request信令通知HSS將所記錄的時(shí)延等待時(shí)間參數(shù)更新為19:30。HSS以Notify Answer 信令進(jìn)行響應(yīng)。步驟S1014、MTC Server向HLR/HSS查詢MD A的時(shí)延等待時(shí)間參數(shù)信息。接收到S-GW發(fā)送的告知終端MD A不可達(dá)的ICMP分組時(shí)，MTC Server向HSS發(fā)送 ^er-Data-Request信令，要求HSS提供當(dāng)前記錄的MD A的時(shí)延等待時(shí)間參數(shù)信息。HSS 通過^er-Data-Answer信令將網(wǎng)絡(luò)為MD A設(shè)定的延遲等待時(shí)間19:30告知MTC Server。收到HSS返回的her-Data-Answer信令之后，MTC Server從中提取攜帶的時(shí)延等待時(shí)間參數(shù)并將本地的時(shí)延等待定時(shí)器設(shè)置為19:30并啟動(dòng)。在定時(shí)器超時(shí)(19:30到達(dá))之前，若有數(shù)據(jù)分組到達(dá)，MTC krver緩存到達(dá)的下行IP數(shù)據(jù)分組并暫停通過3GPP網(wǎng)絡(luò)向MD A發(fā)送數(shù)據(jù)。待定時(shí)器超時(shí)之后，MTC krver可向3GPP核心網(wǎng)P-GW發(fā)送數(shù)據(jù)，進(jìn)而重新觸發(fā)服務(wù)請求。如圖11所示，為本發(fā)明實(shí)施例所提出的一種具體應(yīng)用場景下的MTC設(shè)備下行數(shù)據(jù)傳輸控制方法的流程示意圖，對于MTC訂閱時(shí)延等待時(shí)間參數(shù)信息，且MD未處于時(shí)延等待狀態(tài)的情況進(jìn)行說明。對于與圖10所示的實(shí)施例相同的應(yīng)用場景，步驟SllOl至步驟S1102與步驟 S1001至步驟S1002相一致。
附著，登錄注冊等初始化過程完畢之后，MD A沒有數(shù)據(jù)傳輸需求，返回空閑態(tài)。步驟S1103、MD A中出現(xiàn)需要發(fā)送的上行數(shù)據(jù)。在某一時(shí)刻，如19:00，MD A有業(yè)務(wù)數(shù)據(jù)到達(dá)并向網(wǎng)絡(luò)發(fā)起服務(wù)請求。步驟Sl 104、MD A向MME請求建立無線接入連接。此時(shí)，若接入網(wǎng)負(fù)載為0.8，大于Load Threshold值0. 7，網(wǎng)絡(luò)將拒絕MDA的服務(wù)請求，并為MD A分配一個(gè)時(shí)延等待時(shí)間參數(shù)(如19:30)要求MD A延遲30分鐘之后方可再次請求服務(wù)。MME在MD A上下文DelayedTime參數(shù)中將網(wǎng)絡(luò)系統(tǒng)為MD A分配的時(shí)延等待時(shí)間更新為19:30。步驟Sl 105、MME通知HLR/HSS新的時(shí)延等待時(shí)間參數(shù)。由于所維護(hù)的時(shí)延等待參數(shù)發(fā)生變化，MME通過S6a接口向HSS發(fā)送Notify Request信令通知HSS將所記錄的時(shí)延等待時(shí)間參數(shù)更新為19:30。HSS以Notify Answer 信令進(jìn)行響應(yīng)。步驟Sl 106、MTC Server中出現(xiàn)需要發(fā)送給MD A的下行數(shù)據(jù)。在某一時(shí)刻，如19:00，MTC krver有業(yè)務(wù)產(chǎn)生需要向MD A進(jìn)行下行數(shù)據(jù)傳輸。步驟S1107、MTC krver判斷對MD A是否啟動(dòng)了時(shí)延等待定時(shí)器。如果啟動(dòng)了，則直接緩存該下行數(shù)據(jù)，等時(shí)延等待定時(shí)器超時(shí)時(shí)，再發(fā)送該下行數(shù)據(jù)，為了說明方便，此種情況在此不作說明，重點(diǎn)對沒有啟動(dòng)的情況進(jìn)行說明。假設(shè)時(shí)延等待定時(shí)器尚未啟動(dòng)，則執(zhí)行步驟S1108。步驟S1108、MTC Server將到達(dá)的IP數(shù)據(jù)分組直接發(fā)送至3GGP核心網(wǎng)P-GW。步驟S1109、P-GW對接收到的這些下行IP數(shù)據(jù)分組進(jìn)行協(xié)議轉(zhuǎn)換及適配，在完成 GTP協(xié)議封裝之后，轉(zhuǎn)發(fā)至S-GW。步驟S1110、S-Gff向核心網(wǎng)管理控制實(shí)體(后續(xù)直接以MME為例進(jìn)行說明)發(fā)送下行數(shù)據(jù)通知。由于MD A處于空閑態(tài)，S-Gff與MD之間不存在已建立的無線接入連接，因此S-GW 緩存到達(dá)的下行數(shù)據(jù)分組,并向MME發(fā)送Downlink DataNotification信令促使MME對MD A發(fā)起尋呼。步驟S1111、MME判定MD A是否處于時(shí)延等待狀態(tài)。接收到S-GW發(fā)送的Downlink Data Notification信令時(shí)，MME首先查看MD A上下文中維護(hù)的時(shí)延等待時(shí)間參數(shù)(如Delayed Time)，判斷MD是否已處于時(shí)延等待狀態(tài)。如前，MD A上下文中的Delayed Time參數(shù)值表明當(dāng)前MD A正處于時(shí)延等待期， MD A當(dāng)前已經(jīng)處于時(shí)延等待狀態(tài)，所以進(jìn)一步處理過程如下步驟S1112、MME向S-GW發(fā)送下行數(shù)據(jù)失敗指示。MME 向 S-GW返回 Downlink Data Notification Acknowledge 信令拒絕 S-Gff 的通知請求，其中原因參數(shù)指明MD A由于被網(wǎng)絡(luò)系統(tǒng)限制服務(wù)而造成尋呼操作未能進(jìn)行。接收到Downlink Data Notification Acknowledge 信令時(shí)，S-GW 丟棄為 MD A 緩存的下行數(shù)據(jù)分組并通過P-GW向MTC Server發(fā)送ICMP控制消息通知MTC Server終端MD A不可達(dá)。步驟Sl 113、MTC Server向HLR/HSS查詢MD A的時(shí)延等待時(shí)間參數(shù)信息接收到S-GW發(fā)送的告知終端MD A不可達(dá)的ICMP分組時(shí)，MTC Server向HSS發(fā)送^er-Data-Request信令，要求HSS提供當(dāng)前記錄的MD A的時(shí)延等待時(shí)間參數(shù)信息。HSS 通過^er-Data-Answer信令將網(wǎng)絡(luò)為MD A設(shè)定的延遲等待時(shí)間19:30告知MTC Server。收到HSS返回的her-Data-Answer信令之后，MTC Server從中提取攜帶的時(shí)延等待時(shí)間參數(shù)并將本地的時(shí)延等待定時(shí)器設(shè)置為19:30并啟動(dòng)。在定時(shí)器超時(shí)(19:30到達(dá))之前，若有數(shù)據(jù)分組到達(dá)，MTC krver緩存到達(dá)的下行IP數(shù)據(jù)分組并暫停通過3GPP網(wǎng)絡(luò)向MD A發(fā)送數(shù)據(jù)。待定時(shí)器超時(shí)之后，MTC krver可向3GPP核心網(wǎng)P-GW發(fā)送數(shù)據(jù)，進(jìn)而重新觸發(fā)服務(wù)請求。與現(xiàn)有技術(shù)相比，本發(fā)明具有以下優(yōu)點(diǎn)通過應(yīng)用本發(fā)明實(shí)施例所提出的技術(shù)方案，解決了具有時(shí)間容忍特性MD下行方向數(shù)據(jù)業(yè)務(wù)的傳輸控制問題，在現(xiàn)有上行數(shù)據(jù)傳輸控制方案的基礎(chǔ)上，通過進(jìn)一步增強(qiáng)MTC krver與核心網(wǎng)各實(shí)體間，核心網(wǎng)內(nèi)部各實(shí)體間的交互過程，使系統(tǒng)能夠基于接入網(wǎng)負(fù)載情況及(預(yù))定義的簽約門限限制MTCServer向MD下行數(shù)據(jù)的發(fā)送，從而具有支持下行數(shù)據(jù)傳輸控制的能力。為了實(shí)現(xiàn)上述的本發(fā)明所提出的技術(shù)方案，本發(fā)明還提供了一種MTC服務(wù)器，其結(jié)構(gòu)示意圖如圖12所示，包括定時(shí)器模塊121，用于設(shè)定對應(yīng)當(dāng)前注冊的MTC設(shè)備的時(shí)延等待定時(shí)器；判斷模塊122，用于當(dāng)需要向MTC設(shè)備傳輸下行數(shù)據(jù)時(shí)，判斷定時(shí)器模塊121是否啟動(dòng)了對應(yīng)MTC設(shè)備的時(shí)延等待定時(shí)器；緩存模塊123，用于在判斷模塊122判斷已經(jīng)啟動(dòng)對應(yīng)MTC設(shè)備的時(shí)延等待定時(shí)器時(shí)，緩存下行數(shù)據(jù)；通信模塊124，用于當(dāng)定時(shí)器模塊121所設(shè)定的對應(yīng)MTC設(shè)備的時(shí)延等待定時(shí)器超時(shí)時(shí)，將緩存模塊123所緩存的下行數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送給對應(yīng)的MTC設(shè)備。其中，定時(shí)器模塊121，用于設(shè)定對應(yīng)當(dāng)前注冊的MTC設(shè)備的時(shí)延等待定時(shí)器，具體為定時(shí)器模塊121根據(jù)通信模塊124從HLR或HSS獲取到的MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或者M(jìn)TC設(shè)備時(shí)延等待狀態(tài)信息進(jìn)行設(shè)定，其中，通信模塊IM從HLR或HSS獲取 MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或MTC設(shè)備時(shí)延等待狀態(tài)信息的方式，具體包括通信模塊IM在接收到MTC設(shè)備的登陸注冊請求后，向HLR或HSS訂閱MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或MTC設(shè)備的時(shí)延等待狀態(tài)信息，當(dāng)HLR或HSS判斷MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或時(shí)延等待狀態(tài)發(fā)生變化時(shí)，通信模塊1 接收HLR或HSS發(fā)送的更新的MTC 設(shè)備的時(shí)延等待時(shí)間參數(shù)或時(shí)延等待狀態(tài)信息；或，當(dāng)通信模塊IM接收到服務(wù)數(shù)據(jù)網(wǎng)關(guān)發(fā)送的向MTC設(shè)備傳輸下行數(shù)據(jù)失敗的通知消息時(shí)，通信模塊124向HLR或HSS發(fā)送MTC設(shè)備的等待時(shí)間信息或時(shí)延等待狀態(tài)信息的查詢請求，并接收HLR或HSS返回的MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或時(shí)延等待狀態(tài)信息。在具體的應(yīng)用場景中，當(dāng)通信模塊IM接收HLR或HSS發(fā)送的關(guān)于MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)的通知消息時(shí)，定時(shí)器模塊121根據(jù)MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)設(shè)定對應(yīng)MTC設(shè)備的時(shí)延等待定時(shí)器；當(dāng)通信模塊IM接收HLR或HSS發(fā)送的關(guān)于MTC設(shè)備的時(shí)延等待狀態(tài)信息的通知消息時(shí)，若MTC設(shè)備處于時(shí)延等待狀態(tài)，定時(shí)器模塊121根據(jù)系統(tǒng)預(yù)設(shè)的時(shí)延等待時(shí)間參數(shù)設(shè)定對應(yīng)MTC設(shè)備的時(shí)延等待定時(shí)器。前述的向MTC設(shè)備傳輸下行數(shù)據(jù)失敗的通知消息，具體為表征目標(biāo)節(jié)點(diǎn)不可達(dá)的ICMP消息；或，表征目標(biāo)節(jié)點(diǎn)不可達(dá)的ICMPv6消息。在具體的應(yīng)用場景中，本發(fā)明實(shí)施例所提出的技術(shù)方案還包括如果判斷模塊122判斷沒有啟動(dòng)對應(yīng)MTC設(shè)備的時(shí)延等待定時(shí)器，通信模塊IM 將需要向MTC設(shè)備傳輸?shù)南滦袛?shù)據(jù)發(fā)送給相應(yīng)的網(wǎng)絡(luò)設(shè)備，并由相應(yīng)的網(wǎng)絡(luò)設(shè)備將需要向 MTC設(shè)備傳輸?shù)南滦袛?shù)據(jù)轉(zhuǎn)發(fā)給MTC設(shè)備。與現(xiàn)有技術(shù)相比，本發(fā)明具有以下優(yōu)點(diǎn)通過應(yīng)用本發(fā)明實(shí)施例所提出的技術(shù)方案，解決了具有時(shí)間容忍特性MD下行方向數(shù)據(jù)業(yè)務(wù)的傳輸控制問題，在現(xiàn)有上行數(shù)據(jù)傳輸控制方案的基礎(chǔ)上，通過進(jìn)一步增強(qiáng)MTC krver與核心網(wǎng)各實(shí)體間，核心網(wǎng)內(nèi)部各實(shí)體間的交互過程，使系統(tǒng)能夠基于接入網(wǎng)負(fù)載情況及(預(yù))定義的簽約門限限制MTCServer向MD下行數(shù)據(jù)的發(fā)送，從而具有支持下行數(shù)據(jù)傳輸控制的能力。通過以上的實(shí)施方式的描述，本領(lǐng)域的技術(shù)人員可以清楚地了解到本發(fā)明可以通過硬件實(shí)現(xiàn)，也可以借助軟件加必要的通用硬件平臺的方式來實(shí)現(xiàn)?；谶@樣的理解，本發(fā)明的技術(shù)方案可以以軟件產(chǎn)品的形式體現(xiàn)出來，該軟件產(chǎn)品可以存儲(chǔ)在一個(gè)非易失性存儲(chǔ)介質(zhì)(可以是⑶-ROM，U盤，移動(dòng)硬盤等)中，包括若干指令用以使得一臺計(jì)算機(jī)設(shè)備(可以是個(gè)人計(jì)算機(jī)，服務(wù)端，或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個(gè)實(shí)施場景所述的方法。本領(lǐng)域技術(shù)人員可以理解附圖只是一個(gè)優(yōu)選實(shí)施場景的示意圖，附圖中的模塊或流程并不一定是實(shí)施本發(fā)明所必須的。本領(lǐng)域技術(shù)人員可以理解實(shí)施場景中的裝置中的模塊可以按照實(shí)施場景描述進(jìn)行分布于實(shí)施場景的裝置中，也可以進(jìn)行相應(yīng)變化位于不同于本實(shí)施場景的一個(gè)或多個(gè)裝置中。上述實(shí)施場景的模塊可以合并為一個(gè)模塊，也可以進(jìn)一步拆分成多個(gè)子模塊。上述本發(fā)明序號僅僅為了描述，不代表實(shí)施場景的優(yōu)劣。以上公開的僅為本發(fā)明的幾個(gè)具體實(shí)施場景，但是，本發(fā)明并非局限于此，任何本領(lǐng)域的技術(shù)人員能思之的變化都應(yīng)落入本發(fā)明的保護(hù)范圍。
權(quán)利要求
1.一種機(jī)器類通信MTC設(shè)備下行數(shù)據(jù)傳輸控制方法，其特征在于，包括當(dāng)MTC服務(wù)器需要向MTC設(shè)備傳輸下行數(shù)據(jù)時(shí)，所述MTC服務(wù)器判斷是否啟動(dòng)了對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器；如果已經(jīng)啟動(dòng)對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器，所述MTC服務(wù)器緩存所述下行數(shù)據(jù)；當(dāng)所述對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器超時(shí)時(shí)，所述MTC服務(wù)器將緩存的所述下行數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送給對應(yīng)的MTC設(shè)備。
2.如權(quán)利要求1所述的方法，其特征在于，所述對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器， 具體為所述MTC服務(wù)器根據(jù)從HLR或HSS獲取到的所述MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或所述MTC設(shè)備時(shí)延等待狀態(tài)信息進(jìn)行設(shè)定，其中，所述MTC服務(wù)器從HLR或HSS獲取所述MTC 設(shè)備的時(shí)延等待時(shí)間參數(shù)或所述MTC設(shè)備時(shí)延等待狀態(tài)信息的方式，具體包括所述MTC服務(wù)器在接收到所述MTC設(shè)備的登陸注冊請求后，所述MTC服務(wù)器向HLR或 HSS訂閱所述MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或所述MTC設(shè)備的時(shí)延等待狀態(tài)信息，當(dāng)所述 HLR或HSS判斷所述MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或時(shí)延等待狀態(tài)發(fā)生變化時(shí)，所述MTC月艮務(wù)器接收所述HLR或HSS發(fā)送的更新的所述MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或所述MTC設(shè)備的時(shí)延等待狀態(tài)信息；或，當(dāng)所述MTC服務(wù)器接收到服務(wù)數(shù)據(jù)網(wǎng)關(guān)發(fā)送的向所述MTC設(shè)備傳輸下行數(shù)據(jù)失敗的通知消息時(shí)，所述MTC服務(wù)器向所述HLR或HSS發(fā)送所述MTC設(shè)備的等待時(shí)間信息或所述MTC 設(shè)備的時(shí)延等待狀態(tài)信息的查詢請求，并接收所述HLR或HSS返回的所述MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或所述MTC設(shè)備的時(shí)延等待狀態(tài)信息。
3.如權(quán)利要求2所述的方法，其特征在于，所述MTC服務(wù)器接收所述HLR或HSS發(fā)送的更新的所述MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或所述MTC設(shè)備的時(shí)延等待狀態(tài)信息，具體包括所述MTC服務(wù)器接收所述HLR或HSS發(fā)送的關(guān)于所述MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)的通知消息，所述MTC服務(wù)器根據(jù)所述MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)設(shè)定對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器；或，所述MTC服務(wù)器接收所述HLR或HSS發(fā)送的關(guān)于所述MTC設(shè)備的時(shí)延等待狀態(tài)信息的通知消息，如果所述MTC設(shè)備處于時(shí)延等待狀態(tài)，所述MTC服務(wù)器根據(jù)所述預(yù)設(shè)的時(shí)延等待時(shí)間參數(shù)設(shè)定對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器。
4.如權(quán)利要求1所述的方法，其特征在于，當(dāng)MTC服務(wù)器需要向MTC設(shè)備傳輸下行數(shù)據(jù)時(shí)，所述MTC服務(wù)器判斷是否啟動(dòng)了對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器之后，還包括如果沒有啟動(dòng)對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器，所述MTC服務(wù)器將所述需要向MTC 設(shè)備傳輸?shù)南滦袛?shù)據(jù)發(fā)送給相應(yīng)的網(wǎng)絡(luò)設(shè)備，并由所述相應(yīng)的網(wǎng)絡(luò)設(shè)備將所述需要向MTC 設(shè)備傳輸?shù)南滦袛?shù)據(jù)轉(zhuǎn)發(fā)給所述MTC設(shè)備。
5.如權(quán)利要求4所述的方法，其特征在于，所述相應(yīng)的網(wǎng)絡(luò)設(shè)備將所述需要向MTC設(shè)備傳輸?shù)南滦袛?shù)據(jù)轉(zhuǎn)發(fā)給所述MTC設(shè)備的過程中，還包括當(dāng)所述MTC設(shè)備當(dāng)前不能達(dá)到接收下行數(shù)據(jù)的條件時(shí)，所述MTC設(shè)備所對應(yīng)的核心網(wǎng)控制實(shí)體確定所述下行數(shù)據(jù)傳輸失敗，并生成更新的所述MTC設(shè)備的等待時(shí)間信息；所述MTC設(shè)備所對應(yīng)的核心網(wǎng)控制實(shí)體向所述HLR或HSS發(fā)送所述更新的所述MTC設(shè)備的等待時(shí)間信息；所述MTC設(shè)備所對應(yīng)的核心網(wǎng)控制實(shí)體通過服務(wù)數(shù)據(jù)網(wǎng)關(guān)向所述MTC服務(wù)器發(fā)送向所述MTC設(shè)備傳輸下行數(shù)據(jù)失敗的通知消息，所述MTC服務(wù)器緩存所述下行數(shù)據(jù)。
6.如權(quán)利要求2或5所述的方法，其特征在于，向所述MTC設(shè)備傳輸下行數(shù)據(jù)失敗的通知消息，具體為表征目標(biāo)節(jié)點(diǎn)不可達(dá)的ICMP消息；或， 表征目標(biāo)節(jié)點(diǎn)不可達(dá)的ICMPv6消息。
7.如權(quán)利要求1所述的方法，其特征在于，還包括當(dāng)所述MTC設(shè)備當(dāng)前不能達(dá)到發(fā)送上行數(shù)據(jù)的條件時(shí)，所述MTC設(shè)備所對應(yīng)的核心網(wǎng)控制實(shí)體確定所述上行數(shù)據(jù)傳輸失敗，并生成更新的所述MTC設(shè)備的等待時(shí)間信息；所述MTC設(shè)備所對應(yīng)的核心網(wǎng)控制實(shí)體向所述HLR或HSS發(fā)送所述更新的所述MTC設(shè)備的等待時(shí)間信息。
8.—種MTC服務(wù)器，其特征在于，包括定時(shí)器模塊，用于設(shè)定對應(yīng)當(dāng)前注冊的MTC設(shè)備的時(shí)延等待定時(shí)器； 判斷模塊，用于當(dāng)需要向MTC設(shè)備傳輸下行數(shù)據(jù)時(shí)，判斷所述定時(shí)器模塊是否啟動(dòng)了對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器；緩存模塊，用于在所述判斷模塊判斷已經(jīng)啟動(dòng)對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器時(shí)，緩存所述下行數(shù)據(jù)；通信模塊，用于當(dāng)所述定時(shí)器模塊所設(shè)定的對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器超時(shí)時(shí)，將所述緩存模塊所緩存的所述下行數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送給對應(yīng)的MTC設(shè)備。
9.如權(quán)利要求8所述的MTC服務(wù)器，其特征在于，所述定時(shí)器模塊，用于設(shè)定對應(yīng)當(dāng)前注冊的MTC設(shè)備的時(shí)延等待定時(shí)器，具體為所述定時(shí)器模塊根據(jù)所述通信模塊從HLR或HSS獲取到的所述MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或所述MTC設(shè)備時(shí)延等待狀態(tài)信息進(jìn)行設(shè)定，其中，所述通信模塊從HLR或HSS獲取所述MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或所述MTC設(shè)備時(shí)延等待狀態(tài)信息的方式，具體包括所述通信模塊在接收到所述MTC設(shè)備的登陸注冊請求后，向HLR或HSS訂閱所述MTC 設(shè)備的時(shí)延等待時(shí)間參數(shù)或所述MTC設(shè)備時(shí)延等待狀態(tài)信息，當(dāng)所述HLR或HSS判斷所述 MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或時(shí)延等待狀態(tài)發(fā)生變化時(shí)，所述通信模塊接收所述HLR或 HSS發(fā)送的更新的所述MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或所述MTC設(shè)備時(shí)延等待狀態(tài)信息； 或，當(dāng)所述通信模塊接收到服務(wù)數(shù)據(jù)網(wǎng)關(guān)發(fā)送的向所述MTC設(shè)備傳輸下行數(shù)據(jù)失敗的通知消息時(shí)，所述通信模塊向所述HLR或HSS發(fā)送所述MTC設(shè)備的等待時(shí)間信息或所述MTC 設(shè)備時(shí)延等待狀態(tài)信息的查詢請求，并接收所述HLR或HSS返回的所述MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)或所述MTC設(shè)備時(shí)延等待狀態(tài)信息。
10.如權(quán)利要求9所述的MTC服務(wù)器，其特征在于，當(dāng)所述通信模塊接收所述HLR或HSS發(fā)送的關(guān)于所述MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)的通知消息時(shí)，所述定時(shí)器模塊根據(jù)所述MTC設(shè)備的時(shí)延等待時(shí)間參數(shù)設(shè)定對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器；或，當(dāng)所述通信模塊接收所述HLR或HSS發(fā)送的關(guān)于所述MTC設(shè)備的時(shí)延等待狀態(tài)信息的通知消息時(shí)，如果所述MTC設(shè)備處于時(shí)延等待狀態(tài)，所述定時(shí)器模塊根據(jù)所述預(yù)設(shè)的時(shí)延等待時(shí)間參數(shù)設(shè)定對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器。
11.如權(quán)利要求9所述的MTC服務(wù)器，其特征在于，向所述MTC設(shè)備傳輸下行數(shù)據(jù)失敗的通知消息，具體為表征目標(biāo)節(jié)點(diǎn)不可達(dá)的ICMP消息；或， 表征目標(biāo)節(jié)點(diǎn)不可達(dá)的ICMPv6消息。
12.如權(quán)利要求8所述的MTC服務(wù)器，其特征在于，還包括如果所述判斷模塊判斷沒有啟動(dòng)對應(yīng)所述MTC設(shè)備的時(shí)延等待定時(shí)器，所述通信模塊將所述需要向MTC設(shè)備傳輸?shù)南滦袛?shù)據(jù)發(fā)送給相應(yīng)的網(wǎng)絡(luò)設(shè)備，并由所述相應(yīng)的網(wǎng)絡(luò)設(shè)備將所述需要向MTC設(shè)備傳輸?shù)南滦袛?shù)據(jù)轉(zhuǎn)發(fā)給所述MTC設(shè)備。
全文摘要
本發(fā)明公開了一種MTC設(shè)備下行數(shù)據(jù)傳輸控制方法和設(shè)備，通過應(yīng)用本發(fā)明實(shí)施例所提出的技術(shù)方案，解決了具有時(shí)間容忍特性MD下行方向數(shù)據(jù)業(yè)務(wù)的傳輸控制問題。在現(xiàn)有上行數(shù)據(jù)傳輸控制方案的基礎(chǔ)上，通過進(jìn)一步增強(qiáng)MTC Server與核心網(wǎng)各實(shí)體間，核心網(wǎng)內(nèi)部各實(shí)體間的交互過程，使系統(tǒng)能夠基于接入網(wǎng)負(fù)載情況及(預(yù))定義的簽約門限限制MTC Server向MD下行數(shù)據(jù)的發(fā)送，從而具有支持下行數(shù)據(jù)傳輸控制的能力。
文檔編號H04W28/08GK102244856SQ20101017622
公開日2011年11月16日 申請日期2010年5月13日 優(yōu)先權(quán)日2010年5月13日
發(fā)明者熊春山, 田野 申請人:電信科學(xué)技術(shù)研究院