一種異常情況下的尋呼控制方法及裝置制造方法
【專利摘要】本發(fā)明公開了一種異常情況下的尋呼控制方法及裝置，用于解決MME發(fā)送大量尋呼消息造成負荷過重而引發(fā)設(shè)備故障，以及不區(qū)分UE等級導致對優(yōu)先級高的UE無法優(yōu)先處理的問題，該方法為：在設(shè)定的檢測周期內(nèi)，每次對UE發(fā)送尋呼消息之前，獲取在檢測周期內(nèi)累計的尋呼消息條數(shù)，并判斷尋呼消息條數(shù)是否大于第一設(shè)定閾值；在判定尋呼消息條數(shù)大于第一設(shè)定閾值時，進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值，若是，則發(fā)送尋呼消息，否則，在確定尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送尋呼消息；在判定尋呼消息條數(shù)小于或等于第一設(shè)定閾值時，發(fā)送尋呼消息。采用上述方法，可以有效對尋呼過程進行控制。
【專利說明】一種異常情況下的尋呼控制方法及裝置
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及通信領(lǐng)域，尤其涉及一種異常情況下的尋呼控制方法及裝置。
【背景技術(shù)】
[0002]UE注冊到LTE網(wǎng)絡(luò)中，當沒有業(yè)務(wù)發(fā)生時，一般會處于空閑(ECM-1DLE)狀態(tài)，該狀態(tài)是用于指示UE和移動管理實體(Mobile Management Entity,MME)之間的信令連接釋放，即SI鏈路釋放。參閱圖1所示的網(wǎng)絡(luò)側(cè)發(fā)起的尋呼過程，具體包括步驟I至步驟6b，其中，當網(wǎng)絡(luò)側(cè)有下行數(shù)據(jù)或者有下行信令時(即步驟I和步驟2)，需要對處于ECM-1DLE態(tài)的UE發(fā)起尋呼(即步驟3和步驟4)，UE收到MME對其的尋呼消息后，發(fā)起服務(wù)請求過程(即步驟5)來恢復(fù)SI鏈路連接，在恢復(fù)SI鏈路連接后，下行數(shù)據(jù)或者下行信令才會下發(fā)到終端。
[0003]根據(jù)3GPP協(xié)議，以下幾種情況MME都需要對UE進行尋呼:
[0004]參閱圖2所示的專用承載激活過程，具體包括步驟I至步驟12，3GPP協(xié)議記載:服務(wù)網(wǎng)關(guān)發(fā)送給MME創(chuàng)建承載請求，若UE處于ECM-1DLE態(tài)，從步驟3處，MME將會觸發(fā)網(wǎng)絡(luò)觸發(fā)服務(wù)請求。(The Serving Gff sends the Create Bearer Request message to theMME.1f the UE is in ECM-1DLE state the MME will trigger the Network TriggeredService Request from step3.)
[0005]參閱圖3所示的MME發(fā)起的去附著過程，具體包括步驟I至步驟14，以及參閱圖4所示的HSS發(fā)起的去附著過程，具體包括步驟Ia至步驟10a，3GPP協(xié)議記載:若UE處于ECM-1DLE態(tài)，MME會尋呼UEJIf the UE is in ECM-1DLE state the MME pages the UE.)
[0006]參閱圖5所示的UE在激活狀態(tài)下的F1DN GW發(fā)起的承載去激活過程,具體包括步驟I至步驟11，3GPP協(xié)議記載:MME通過發(fā)送給UE去附著請求消息，隱式地將UE去附著。若UE 處于 ECM-1DLE 態(tài),MME 會尋呼 UE。(the MME explicitly detaches the UE by sendinga Detach Request message to the UE.1f the UE is in ECM-1DLE state the MME pagesthe UE.)
[0007]在某些突發(fā)或者異常的情況下，如分組數(shù)據(jù)網(wǎng)(Packet Data Network, PDN)向大量UE發(fā)送業(yè)務(wù)推送消息或者分組數(shù)據(jù)網(wǎng)網(wǎng)關(guān)(PDN Gateway, PGW)因為故障而需要釋放掉所有的用戶等等異常情況。在上述異常情況下，若大量的UE處于ECM-1DLE態(tài)，根據(jù)3GPP協(xié)議，MME需要對所有UE發(fā)起尋呼，MME瞬間會有大量的尋呼消息下發(fā)，大量的尋呼消息可能會造成MME的負荷飽和從而引發(fā)MME設(shè)備故障(如宕機)，嚴重時會造成整個網(wǎng)絡(luò)的癱瘓。并且尋呼消息的下發(fā)并不區(qū)分UE等級，導致對于優(yōu)先級高的UE無法保證可以優(yōu)先處理。
【發(fā)明內(nèi)容】
[0008]本發(fā)明實施例提供一種異常情況下的尋呼控制方法及裝置，用以解決現(xiàn)有技術(shù)中存在的異常情況下，MME對UE發(fā)起尋呼，瞬間產(chǎn)生大量尋呼消息下發(fā)至UE時，造成MME負荷過重，從而引發(fā)設(shè)備故障的問題，以及在MME的負荷加重時，對尋呼消息的下發(fā)并不區(qū)分UE等級，導致對優(yōu)先級高的UE無法優(yōu)先處理的問題。[0009]本發(fā)明實施例提供一種異常情況下的尋呼控制方法及裝置。
[0010]第一方面，一種異常情況下的尋呼控制方法，該方法包括:
[0011]在設(shè)定的檢測周期內(nèi)，每次對UE發(fā)送尋呼消息之前，獲取在檢測周期內(nèi)累計的尋呼消息條數(shù)，并判斷尋呼消息條數(shù)是否大于第一設(shè)定閾值；
[0012]在判定尋呼消息條數(shù)大于第一設(shè)定閾值時，進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值，若是，則發(fā)送尋呼消息，否則，在確定尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送尋呼消息；
[0013]在判定尋呼消息條數(shù)小于或等于第一設(shè)定閾值時，發(fā)送尋呼消息。
[0014]結(jié)合第一方面，在第一種可能的實現(xiàn)方式中，獲取在當前檢測周期內(nèi)累計的尋呼消息條數(shù)之后，在判斷尋呼消息條數(shù)是否大于第一設(shè)定閾值之前，進一步包括:
[0015]判定尋呼消息條數(shù)小于當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，確定執(zhí)行后續(xù)判斷操作。
[0016]結(jié)合第一方面的第一種可能的實現(xiàn)方式，在第二種可能的實現(xiàn)方式中，進一步包括:
[0017]在判定尋呼消息條數(shù)大于或等于當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，丟棄尋呼消息，其中，丟棄的尋呼消息不進行累計。
[0018]通過這種可能的實現(xiàn)方式，在尋呼消息條數(shù)大于或等于當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，不再發(fā)送待發(fā)送的尋呼消息，可以使得MME設(shè)備不至于達到負荷最大的狀態(tài)而導致設(shè)備癱瘓。
[0019]結(jié)合第一方面，在第三種可能的實現(xiàn)方式中，在判定尋呼消息條數(shù)大于第一設(shè)定閾值后，在進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值之前，進一步包括:
[0020]判定當前尋呼由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，確定執(zhí)行后續(xù)判斷操作。
[0021]通過這種可能的實現(xiàn)方式，處于空閑態(tài)的用戶在多種情況下會發(fā)生尋呼過程，對于創(chuàng)建承載過程以及發(fā)送下行數(shù)據(jù)時觸發(fā)而發(fā)送的尋呼消息過程，用戶感知明顯，因此，需要優(yōu)先處理。
[0022]結(jié)合第一方面的第三種可能的實現(xiàn)方式，在第四種可能的實現(xiàn)方式中，進一步包括:
[0023]判定當前尋呼不是由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，在進一步確定尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送尋呼消息。
[0024]結(jié)合第一方面或第一方面的上述任意一種可能的實現(xiàn)方式，在第五種可能的實現(xiàn)方式中，在確定當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級未達到第二設(shè)定閾值之后，進一步包括:
[0025]在確定尋呼消息的尋呼類型不為指定尋呼類型時，丟棄尋呼消息，丟棄的尋呼消息不進行累計。
[0026]通過這種可能的實現(xiàn)方式，通過指定尋呼類型，排除MME給全網(wǎng)發(fā)送尋呼消息對應(yīng)的尋呼類型，以減少MME發(fā)送尋呼消息的條數(shù)。
[0027]結(jié)合第一方面或第一方面的第一至第四種中任意一種實現(xiàn)方式，在第六種可能的實現(xiàn)方式中，在確定尋呼消息的尋呼類型為指定尋呼類型之后，在發(fā)送尋呼消息之前，進一步包括:
[0028]判斷尋呼消息不為重發(fā)尋呼消息時，初步確定能夠發(fā)送尋呼消息。
[0029]結(jié)合第一方面的第六種可能的實現(xiàn)方式，在第七種可能的實現(xiàn)方式中，進一步包括:
[0030]確定尋呼消息為重發(fā)尋呼消息時，丟棄尋呼消息，其中，丟棄的尋呼消息不進行累計。
[0031]通過這種可能的實現(xiàn)方式，可以盡可能的少發(fā)尋呼消息，有效的對尋呼消息進行控制，不對重發(fā)的尋呼消息，再次重復(fù)發(fā)送。
[0032]第二方面，一種異常情況下的尋呼控制裝置，該裝置包括:
[0033]第一處理單元，用于在設(shè)定的檢測周期內(nèi)，每次對UE發(fā)送尋呼消息之前，獲取在檢測周期內(nèi)累計的尋呼消息條數(shù)，并判斷尋呼消息條數(shù)是否大于第一設(shè)定閾值；
[0034]第二處理單元，用于在判定尋呼消息條數(shù)大于第一設(shè)定閾值時，進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值，若是，則發(fā)送尋呼消息，否則，在確定尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送尋呼消息；
[0035]第三處理單元，用于在判定尋呼消息條數(shù)小于或等于第一設(shè)定閾值時，發(fā)送尋呼消息。
[0036]結(jié)合第二方面，在第一種可能的實現(xiàn)方式中，第一處理單元，還用于:
[0037]在獲取在當前檢測周期內(nèi)累計的尋呼消息條數(shù)之后，在判斷尋呼消息條數(shù)是否大于第一設(shè)定閾值之前，判定尋呼消息條數(shù)小于當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，確定執(zhí)行后續(xù)判斷操作。
[0038]結(jié)合第二方面的第一種可能的實現(xiàn)方式，在第二種可能的實現(xiàn)方式中，第一處理單元，還用于:
[0039]在判定尋呼消息條數(shù)大于或等于當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，丟棄尋呼消息，其中，丟棄的尋呼消息不進行累計。
[0040]通過這種可能的實現(xiàn)方式，在尋呼消息條數(shù)大于或等于當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，不再發(fā)送待發(fā)送的尋呼消息，可以使得MME設(shè)備不至于達到負荷最大的狀態(tài)而導致設(shè)備癱瘓。
[0041]結(jié)合第二方面，在第三種可能的實現(xiàn)方式中，第二處理單元，還用于:
[0042]在判定尋呼消息條數(shù)大于第一設(shè)定閾值后，在進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值之前，判定當前尋呼由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，確定執(zhí)行后續(xù)判斷操作。
[0043]通過這種可能的實現(xiàn)方式，處于空閑態(tài)的用戶在多種情況下會發(fā)生尋呼過程，對于創(chuàng)建承載過程以及發(fā)送下行數(shù)據(jù)時觸發(fā)而發(fā)送的尋呼消息過程，用戶感知明顯，因此，需要優(yōu)先處理。
[0044]結(jié)合第二方面的第三種可能的實現(xiàn)方式，在第四種可能的實現(xiàn)方式中，第二處理單元，還用于:
[0045]判定當前尋呼不是由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，在進一步確定尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送尋呼消息。[0046]結(jié)合第二方面或第二方面的上述任意一種可能的實現(xiàn)方式，在第五種可能的實現(xiàn)方式中，第二處理單元，還用于:
[0047]在確定當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級未達到第二設(shè)定閾值之后，在確定尋呼消息的尋呼類型不為指定尋呼類型時，丟棄尋呼消息，丟棄的尋呼消息不進行累計。
[0048]通過這種可能的實現(xiàn)方式，通過指定尋呼類型，排除MME給全網(wǎng)發(fā)送尋呼消息對應(yīng)的尋呼類型，以減少MME發(fā)送尋呼消息的條數(shù)。
[0049]結(jié)合第二方面或第二方面的第一至第四種中任意一種實現(xiàn)方式，在第六種可能的實現(xiàn)方式中，第二處理單元，還用于:
[0050]在確定尋呼消息的尋呼類型為指定尋呼類型之后，在發(fā)送尋呼消息之前，判斷尋呼消息不為重發(fā)尋呼消息時，初步確定能夠發(fā)送尋呼消息。
[0051]結(jié)合第二方面的第六種可能的實現(xiàn)方式，在第七種可能的實現(xiàn)方式中，第二處理單元，還用于:
[0052]確定尋呼消息為重發(fā)尋呼消息時，丟棄尋呼消息，其中，丟棄的尋呼消息不進行累計。
[0053]通過這種可能的實現(xiàn)方式，可以盡可能的少發(fā)尋呼消息，有效的對尋呼消息進行控制，不對重發(fā)的尋呼消息，再次重復(fù)發(fā)送。
[0054]第三方面，一種異常情況下的尋呼控制裝置，該裝置包括:
[0055]處理器，用于在設(shè)定的檢測周期內(nèi)，每次對UE發(fā)送尋呼消息之前，獲取在檢測周期內(nèi)累計的尋呼消息條數(shù)，并判斷尋呼消息條數(shù)是否大于第一設(shè)定閾值；在判定尋呼消息條數(shù)大于第一設(shè)定閾值時，進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值，若是，則發(fā)送尋呼消息，否則，在確定尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送尋呼消息；或者，在判定尋呼消息條數(shù)小于或等于第一設(shè)定閾值時，發(fā)送尋呼消息。
[0056]結(jié)合第三方面，在第一種可能的實現(xiàn)方式中，處理器，還用于:
[0057]在獲取在當前檢測周期內(nèi)累計的尋呼消息條數(shù)之后，在判斷尋呼消息條數(shù)是否大于第一設(shè)定閾值之前，判定尋呼消息條數(shù)小于當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，確定執(zhí)行后續(xù)判斷操作。
[0058]結(jié)合第三方面的第一種可能的實現(xiàn)方式，在第二種可能的實現(xiàn)方式中，處理器，還用于:
[0059]在判定尋呼消息條數(shù)大于或等于當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，丟棄尋呼消息，其中，丟棄的尋呼消息不進行累計。
[0060]通過這種可能的實現(xiàn)方式，在尋呼消息條數(shù)大于或等于當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，不再發(fā)送待發(fā)送的尋呼消息，可以使得MME設(shè)備不至于達到負荷最大的狀態(tài)而導致設(shè)備癱瘓。
[0061]結(jié)合第三方面，在第三種可能的實現(xiàn)方式中，處理器，還用于:
[0062]在判定尋呼消息條數(shù)大于第一設(shè)定閾值后，在進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值之前，判定當前尋呼由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，確定執(zhí)行后續(xù)判斷操作。[0063]通過這種可能的實現(xiàn)方式，處于空閑態(tài)的用戶在多種情況下會發(fā)生尋呼過程，對于創(chuàng)建承載過程以及發(fā)送下行數(shù)據(jù)時觸發(fā)而發(fā)送的尋呼消息過程，用戶感知明顯，因此，需要優(yōu)先處理。
[0064]結(jié)合第三方面的第三種可能的實現(xiàn)方式，在第四種可能的實現(xiàn)方式中，處理器，還用于:
[0065]判定當前尋呼不是由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，在進一步確定尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送尋呼消息。
[0066]結(jié)合第三方面或第三方面的上述任意一種可能的實現(xiàn)方式，在第五種可能的實現(xiàn)方式中，處理器，還用于:
[0067]在確定當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級未達到第二設(shè)定閾值之后，在確定尋呼消息的尋呼類型不為指定尋呼類型時，丟棄尋呼消息，丟棄的尋呼消息不進行累計。
[0068]通過這種可能的實現(xiàn)方式，通過指定尋呼類型，排除MME給全網(wǎng)發(fā)送尋呼消息對應(yīng)的尋呼類型，以減少MME發(fā)送尋呼消息的條數(shù)。
[0069]結(jié)合第三方面或第三方面的第一至第四種中任意一種實現(xiàn)方式，在第六種可能的實現(xiàn)方式中，處理器，還用于:
[0070]在確定尋呼消息的尋呼類型為指定尋呼類型之后，在發(fā)送尋呼消息之前，判斷尋呼消息不為重發(fā)尋呼消息時，初步確定能夠發(fā)送尋呼消息。
[0071]結(jié)合第三方面的第六種可能的實現(xiàn)方式，在第七種可能的實現(xiàn)方式中，處理器，還用于:
[0072]確定尋呼消息為重發(fā)尋呼消息時，丟棄尋呼消息，其中，丟棄的尋呼消息不進行累計。
[0073]通過這種可能的實現(xiàn)方式，可以盡可能的少發(fā)尋呼消息，有效的對尋呼消息進行控制，不對重發(fā)的尋呼消息，再次重復(fù)發(fā)送。
【專利附圖】
【附圖說明】
[0074]圖1為現(xiàn)有技術(shù)中網(wǎng)絡(luò)側(cè)發(fā)起的尋呼協(xié)議圖；
[0075]圖2為現(xiàn)有技術(shù)中專用承載激活過程協(xié)議圖；
[0076]圖3為現(xiàn)有技術(shù)中MME發(fā)起的去附著過程協(xié)議圖；
[0077]圖4為現(xiàn)有技術(shù)中HSS發(fā)起的去附著過程協(xié)議圖；
[0078]圖5為現(xiàn)有技術(shù)中UE在激活狀態(tài)下的TON Gff發(fā)起的承載去激活過程協(xié)議圖；
[0079]圖6為本發(fā)明實施例中異常情況下的尋呼控制流程圖；
[0080]圖7為本發(fā)明實施例中異常情況下的尋呼控制詳細流程圖；
[0081]圖8為本發(fā)明實施例中異常情況下的尋呼控制裝置圖；
[0082]圖9為本發(fā)明實施例中異常情況下的用于尋呼控制的處理器結(jié)構(gòu)圖。
【具體實施方式】
[0083]為了解決現(xiàn)有技術(shù)中存在的異常情況下，MME對UE發(fā)起尋呼，瞬間產(chǎn)生大量尋呼消息下發(fā)至UE時，造成MME負荷過重，從而引發(fā)設(shè)備故障的問題，以及在MME的負荷加重時，對尋呼消息的下發(fā)并不區(qū)分UE等級，導致對優(yōu)先級高的UE無法優(yōu)先處理的問題，本發(fā)明實施例提供一種異常情況下的尋呼控制方法及裝置。
[0084]下面結(jié)合附圖，用具體實施例對本發(fā)明提供的方法及裝置和相應(yīng)系統(tǒng)進行詳細描述。
[0085]參閱圖6所示，本發(fā)明實施例提供的異常情況下的尋呼控制方法，具體為根據(jù)當前尋呼的尋呼類型以及當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級進行尋呼控制，處于ECM-1DLE態(tài)的用戶，在多種情況下會發(fā)生尋呼過程，比如承載建立、承載刪除或有下行鏈路數(shù)據(jù)時。對于承載刪除過程，用戶感知并不明顯，但是對于承載建立或有下行鏈路數(shù)據(jù)時，用戶感知明顯，對于承載建立過程以及有下行鏈路數(shù)據(jù)發(fā)送時，本發(fā)明實施里的尋呼控制方法可以在尋呼消息條數(shù)達到一定程度時，保證優(yōu)先級高的用戶優(yōu)先建立承載，對于非承載建立或有下行鏈路數(shù)據(jù)發(fā)送時，如承載刪除等過程引起的尋呼，則根據(jù)尋呼類型進行尋呼控制，具體流程如下:
[0086]步驟600:在設(shè)定的檢測周期內(nèi)，MME每次對UE發(fā)送尋呼消息之前，獲取在檢測周期內(nèi)累計的尋呼消息條數(shù)，并判斷尋呼消息條數(shù)是否大于第一設(shè)定閾值，若是，則執(zhí)行步驟610 ;否則，執(zhí)行步驟620。
[0087]具體的，在MME獲取在當前檢測周期內(nèi)累計的尋呼消息條數(shù)之后，在判斷尋呼消息條數(shù)是否大于第一設(shè)定閾值之前，判定尋呼消息條數(shù)小于當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，確定執(zhí)行后續(xù)判斷操作。在判定尋呼消息條數(shù)大于或等于當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，丟棄尋呼消息，其中，丟棄的尋呼消息不進行累計。
[0088]上述流程具體為:獲取在檢測周期內(nèi)累計的尋呼消息條數(shù)可以通過在MME設(shè)備設(shè)置循環(huán)定時器以及尋呼條數(shù)計數(shù)器，循環(huán)定時器可配置檢測周期，在每個周期的開始時刻對尋呼條數(shù)計數(shù)器進行初始化，即尋呼條數(shù)計數(shù)器清零的操作。在獲取當前檢測周期內(nèi)累計的尋呼條數(shù)之后，判斷尋呼消息條數(shù)是否大于或等于當前周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)，若是，則丟棄當前尋呼的尋呼消息；否則，執(zhí)行步驟610，判斷尋呼消息條數(shù)是否大于第一設(shè)定閾值以及判斷后的后續(xù)操作。上述最大尋呼條數(shù)以及第一設(shè)定閾值可以通過操作維護中心(Operation and Maintenance Centre, OMC)配置，第一設(shè)定閾值的設(shè)置是根據(jù)MME發(fā)送的尋呼消息條數(shù)在一個檢測周期內(nèi)達到一定數(shù)值時，需要開始對后續(xù)尋呼進行尋呼控制。
[0089]步驟610 =MME判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值，若是，則執(zhí)行步驟620 ;否則，執(zhí)行步驟630。
[0090]步驟620 =MME發(fā)送尋呼消息。
[0091]步驟630:MME在確定尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送尋呼消息。
[0092]具體的，在判定尋呼消息條數(shù)大于第一設(shè)定閾值后，在進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值之前，判定當前尋呼由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，確定執(zhí)行后續(xù)判斷操作(即步驟610)。判定當前尋呼不是由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，在進一步確定尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送尋呼消息。
[0093]上述流程具體為:MME在判定尋呼消息條數(shù)大于第一設(shè)定閾值后，判斷當前尋呼是否由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)，若是，則執(zhí)行判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值；否則，執(zhí)行判斷當前待發(fā)送的尋呼消息的尋呼類型是否為指定尋呼類型。
[0094]其中,UE的優(yōu)先級主要通過業(yè)務(wù)質(zhì)量(Quality of Service, QoS)參數(shù)中的分配和保留優(yōu)先級(Allocation Retention Priority,ARP)中包含的優(yōu)先級別(Priority-Level)來指示的，優(yōu)先級別(Priority-Level)的取值范圍為I至15,取值為I用于指示最高優(yōu)先級，取值為15用于指示最低優(yōu)先級。本發(fā)明實施例中的，所謂的優(yōu)先級達到第二設(shè)定閾值即判斷當前待發(fā)送的尋呼消息所針對的UE默認承載的ARP中指示的優(yōu)先級別(Priority-Level)的取值是否小于某個設(shè)定值,若小于某個設(shè)定值時,則當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級高于設(shè)定的優(yōu)先級，例如，第二閾值設(shè)定為5，則優(yōu)先級別(Priority-Level)的取值為I至5時，即為優(yōu)先級達到第二閾值。
[0095]MME判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值，若是，則發(fā)送尋呼消息；否則，在確定尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送尋呼消
肩、O
[0096]在確定當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級未達到第二設(shè)定閾值之后，進一步確定尋呼消息的尋呼類型不為指定尋呼類型時，丟棄尋呼消息，丟棄的尋呼消息不進行累計。
[0097]在確定尋呼消息的尋呼類型為指定尋呼類型之后，在發(fā)送尋呼消息之前，進一步判斷尋呼消息不為重發(fā)尋呼消息時，初步確定能夠發(fā)送尋呼消息。若確定尋呼消息為重發(fā)尋呼消息時，丟棄尋呼消息，其中，丟棄的尋呼消息不進行累計。
[0098]上述流程具體為:MME判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值，若是，則發(fā)送尋呼消息，否則，執(zhí)行判斷尋呼消息的尋呼類型是否為指定尋呼類型，若確定尋呼消息的尋呼類型為指定尋呼類型，則進一步判斷尋呼消息是否為重發(fā)尋呼消息，若是，則丟棄尋呼消息，否則，發(fā)送尋呼消息。若確定尋呼消息的尋呼類型部位指定尋呼類型，則直接丟棄該尋呼消息。
[0099]其中，上述指定尋呼類型通常指定為全球唯一(用戶)臨時標識(GloballyUnique Temporary Identity, GUTI)尋呼，GUTI 為 MME 為 UE 分配的臨時標識，GUTI 尋呼這種類型的尋呼為小范圍的尋呼，若確定尋呼類型不為GUTI尋呼為國際移動用戶標識(International Mobile Subscriber Identity, IMSI)尋呼時，則丟棄尋呼消息。
[0100]步驟640:MME在判定尋呼消息條數(shù)小于或等于第一設(shè)定閾值時，發(fā)送尋呼消息。
[0101]在判定尋呼消息條數(shù)小于或等于第一設(shè)定閾值時，MME設(shè)備在當前檢測周期內(nèi)發(fā)送的尋呼消息條數(shù)在可處理的尋呼條數(shù)范圍內(nèi)，因此直接發(fā)送尋呼消息。
[0102]參閱圖7所示，通過舉例詳細對上述尋呼控制的流程進行說明。
[0103]步驟7000 =MME啟動循環(huán)定時器和尋呼消息條數(shù)計數(shù)器，在循環(huán)定時器完成一個檢測周期的計時后，初始化尋呼條數(shù)計數(shù)器，并且直接執(zhí)行步驟7020。
[0104]步驟7010:尋呼消息條數(shù)加1，尋呼消息條數(shù)加I后，執(zhí)行步驟7020。
[0105]可以通過循環(huán)定時器配置檢測周期，本舉例中將檢測周期設(shè)為一秒鐘，則循環(huán)定時器和尋呼消息條數(shù)計數(shù)器用來檢測每秒鐘MME發(fā)送的尋呼消息條數(shù)，尋呼消息條數(shù)的累計規(guī)則為只累計成功發(fā)送的尋呼消息條數(shù)，對丟棄的尋呼消息不進行累計。檢測周期可以通過OMC配置。[0106]步驟7020:MME有尋呼消息待發(fā)送。
[0107]步驟7030:MME判斷尋呼消息條數(shù)大于或等于當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)；若是，則執(zhí)行步驟7040 ;否則，執(zhí)行步驟7050。
[0108]其中最大尋呼條數(shù)可以通過OMC配置，本舉例中，假設(shè)最大尋呼條數(shù)為5000條。則在每秒鐘內(nèi)尋呼消息條數(shù)累計至5000條之后發(fā)送的尋呼消息進行丟棄處理，不再發(fā)送。若每秒鐘內(nèi)尋呼消息條數(shù)沒有達到5000條時，繼續(xù)執(zhí)行后續(xù)操作。
[0109]步驟7040 =MME丟棄上述尋呼消息，丟棄尋呼消息后，返回步驟7020。
[0110]步驟7050:MME判斷尋呼消息條數(shù)是否大于第一設(shè)定閾值；若是，則執(zhí)行步驟7060 ;否則，執(zhí)行步驟7070。
[0111]該第一設(shè)定閾值可以通過OMC配置，可以配置為最大尋呼條數(shù)的一定百分比，例如，每秒鐘發(fā)送的尋呼消息條數(shù)在達到最大尋呼條數(shù)的百分之八十(即每秒發(fā)送4000條)開始對尋呼過程進行控制，則本舉例中的第一設(shè)定閾值為4000條，則當前一秒內(nèi)，若發(fā)送的尋呼消息條數(shù)超過4000時，開始對尋呼過程進行控制，即執(zhí)行后續(xù)判斷操作，若發(fā)送的尋呼消息條數(shù)未超過4000，則直接發(fā)送上述尋呼消息。
[0112]步驟7060:MME判斷當前尋呼是否由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)；若是，則執(zhí)行步驟7080 ;否則，執(zhí)行步驟7100。
[0113]步驟7070:MME發(fā)送當前待發(fā)送尋呼消息，發(fā)送尋呼消息后，返回步驟7010。
[0114]步驟7080 =MME判斷當前待發(fā)送的尋呼消息所針對的UE默認承載的ARP中的優(yōu)先級是否小于設(shè)定值；若是，則執(zhí)行步驟7090 ;否則執(zhí)行步驟7100。
[0115]UE默認承載的ARP中的優(yōu)先級別的取值范圍為I到15，其中，取值I用于指示最高優(yōu)先級，取值15用于指示最低優(yōu)先級，例如，將設(shè)定值設(shè)置為5，則在判定當前待發(fā)送的尋呼消息所針對的UE默認承載的ARP中的優(yōu)先級別的取值為1-4時，執(zhí)行步驟7090 ;若在判定當前待發(fā)送的尋呼消息所針對的UE默認承載的ARP中的優(yōu)先級別的取值為5-15時，則執(zhí)行步驟7100。
[0116]步驟7090:MME發(fā)送上述尋呼消息，發(fā)送尋呼消息后，返回步驟7010。
[0117]步驟7100:MME判斷尋呼消息的尋呼類型是否為GUTI尋呼；若是，則執(zhí)行步驟7110 ;否則，執(zhí)行步驟7120。
[0118]步驟7110 =MME判斷尋呼消息是否為重發(fā)尋呼消息；若是，則執(zhí)行步驟7130 ;否則執(zhí)行步驟7140。
[0119]步驟7120:若為MSI尋呼，則MME丟棄上述尋呼消息，丟棄尋呼消息后，返回步驟7020。
[0120]步驟7130 =MME丟棄上述尋呼消息，丟棄尋呼消息后，返回步驟7020。
[0121]步驟7140:MME發(fā)送上述尋呼消息，發(fā)送尋呼消息后，返回步驟7010。
[0122]基于同一發(fā)明構(gòu)思，根據(jù)本發(fā)明上述實施例提供的異常情況下的尋呼控制方法，相應(yīng)地，本發(fā)明另一實施例還提供了一種異常情況下的尋呼控制裝置，該裝置的結(jié)構(gòu)示意圖如圖8所示，具體包括:第一處理單元800、第二處理單元810以及第三處理單元820:
[0123]第一處理單元800，用于在設(shè)定的檢測周期內(nèi)，每次對UE發(fā)送尋呼消息之前，獲取在檢測周期內(nèi)累計的尋呼消息條數(shù)，并判斷尋呼消息條數(shù)是否大于第一設(shè)定閾值；
[0124]第二處理單元810，用于在判定尋呼消息條數(shù)大于第一設(shè)定閾值時，進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值，若是，則發(fā)送尋呼消息，否則，在確定尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送尋呼消息；
[0125]第三處理單元820，用于在判定尋呼消息條數(shù)小于或等于第一設(shè)定閾值時，發(fā)送尋呼消息。
[0126]第一處理單元800，還用于:
[0127]在獲取在當前檢測周期內(nèi)累計的尋呼消息條數(shù)之后，在判斷尋呼消息條數(shù)是否大于第一設(shè)定閾值之前，判定尋呼消息條數(shù)小于當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，確定執(zhí)行后續(xù)判斷操作。
[0128]第一處理單元800，還用于:
[0129]在判定尋呼消息條數(shù)大于或等于當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，丟棄尋呼消息，其中，丟棄的尋呼消息不進行累計。
[0130]第二處理單元810，還用于:
[0131]在判定尋呼消息條數(shù)大于第一設(shè)定閾值后，在進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值之前，判定當前尋呼由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，確定執(zhí)行后續(xù)判斷操作。
[0132]第二處理單元810，還用于:
[0133]判定當前尋呼不是由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，在進一步確定尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送尋呼消息。
[0134]第二處理單元810，還用于:
[0135]在確定當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級未達到第二設(shè)定閾值之后，在確定尋呼消息的尋呼類型不為指定尋呼類型時，丟棄尋呼消息，丟棄的尋呼消息不進行累計。
[0136]第二處理單元810，還用于:
[0137]在確定尋呼消息的尋呼類型為指定尋呼類型之后，在發(fā)送尋呼消息之前，判斷尋呼消息不為重發(fā)尋呼消息時，初步確定能夠發(fā)送尋呼消息。
[0138]第二處理單元810，還用于:
[0139]確定尋呼消息為重發(fā)尋呼消息時，丟棄尋呼消息，其中，丟棄的尋呼消息不進行累計。
[0140]基于同一發(fā)明構(gòu)思，根據(jù)本發(fā)明上述實施例提供的異常情況下的尋呼控制方法，相應(yīng)地，本發(fā)明另一實施例還提供了一種異常情況下的尋呼控制實體裝置，該裝置的結(jié)構(gòu)示意圖如圖9所示,具體包括:處理器900:
[0141]處理器900，用于在設(shè)定的檢測周期內(nèi)，每次對UE發(fā)送尋呼消息之前，獲取在檢測周期內(nèi)累計的尋呼消息條數(shù)，并判斷尋呼消息條數(shù)是否大于第一設(shè)定閾值；在判定尋呼消息條數(shù)大于第一設(shè)定閾值時，進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值，若是，則發(fā)送尋呼消息，否則，在確定尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送尋呼消息；或者，在判定尋呼消息條數(shù)小于或等于第一設(shè)定閾值時，發(fā)送尋呼消息。
[0142]處理器900,還用于:
[0143]在獲取在當前檢測周期內(nèi)累計的尋呼消息條數(shù)之后，在判斷尋呼消息條數(shù)是否大于第一設(shè)定閾值之前，判定尋呼消息條數(shù)小于當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，確定執(zhí)行后續(xù)判斷操作。
[0144]處理器900，還用于:
[0145]在判定尋呼消息條數(shù)大于或等于當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，丟棄尋呼消息，其中，丟棄的尋呼消息不進行累計。
[0146]處理器900,還用于:
[0147]在判定尋呼消息條數(shù)大于第一設(shè)定閾值后，在進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值之前，判定當前尋呼由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，確定執(zhí)行后續(xù)判斷操作。
[0148]處理器900,還用于:
[0149]判定當前尋呼不是由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，在進一步確定尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送尋呼消息。
[0150]處理器900，還用于:
[0151]在確定當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級未達到第二設(shè)定閾值之后，在確定尋呼消息的尋呼類型不為指定尋呼類型時，丟棄尋呼消息，丟棄的尋呼消息不進行累計。
[0152]處理器900，還用于:
[0153]在確定尋呼消息的尋呼類型為指定尋呼類型之后，在發(fā)送尋呼消息之前，判斷尋呼消息不為重發(fā)尋呼消息時，初步確定能夠發(fā)送尋呼消息。
[0154]處理器900，還用于:
[0155]確定尋呼消息為重發(fā)尋呼消息時，丟棄尋呼消息，其中，丟棄的尋呼消息不進行累計。
[0156]綜上所述，本發(fā)明實施例提供的方案在大量UE處于ECM-1DLE態(tài)時，MME對UE發(fā)起尋呼，瞬間產(chǎn)生大量尋呼消息下發(fā)至UE時，根據(jù)UE優(yōu)先級以及當前尋呼的尋呼類型對尋呼過程進行控制，不會造成MME負荷過重，避免了設(shè)備故障的問題，以及在MME的負荷加重時，對尋呼消息的下發(fā)并區(qū)分UE等級，可以在上述異常情況下優(yōu)先處理優(yōu)先級高的UE的請求。
[0157]顯然，本領(lǐng)域的技術(shù)人員可以對本發(fā)明進行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權(quán)利要求及其等同技術(shù)的范圍之內(nèi)，則本發(fā)明也意圖包含這些改動和變型在內(nèi)。
【權(quán)利要求】
1.一種異常情況下的尋呼控制方法，其特征在于，該方法包括: 在設(shè)定的檢測周期內(nèi)，每次對UE發(fā)送尋呼消息之前，獲取在所述檢測周期內(nèi)累計的尋呼消息條數(shù)，并判斷所述尋呼消息條數(shù)是否大于第一設(shè)定閾值； 在判定所述尋呼消息條數(shù)大于第一設(shè)定閾值時，進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值，若是，則發(fā)送所述尋呼消息，否則，在確定所述尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送所述尋呼消息； 在判定所述尋呼消息條數(shù)小于或等于第一設(shè)定閾值時，發(fā)送所述尋呼消息。
2.如權(quán)利要求1所述的方法，其特征在于，獲取在當前檢測周期內(nèi)累計的尋呼消息條數(shù)之后，在判斷所述尋呼消息條數(shù)是否大于第一設(shè)定閾值之前，進一步包括: 判定所述尋呼消息條數(shù)小于所述當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，確定執(zhí)行后續(xù)判斷操作。
3.如權(quán)利要求2所述的方法，其特征在于，進一步包括: 在判定所述尋呼消息條數(shù)大于或等于所述當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，丟棄所述尋呼消息，其中，丟棄的尋呼消息不進行累計。
4.如權(quán)利要求1所述的方法，其特征在于，在判定所述尋呼消息條數(shù)大于第一設(shè)定閾值后，在進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值之前，進一步包括: 判定當前尋呼由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，確定執(zhí)行后續(xù)判斷操作。
5.如權(quán)利要求4所述的方法，其特征在于，進一步包括: 判定當前尋呼不是由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，在進一步確定所述尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送所述尋呼消息。
6.如權(quán)利要求1一 5任一項所述的方法，其特征在于，在確定當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級未達到第二設(shè)定閾值之后，進一步包括: 在確定所述尋呼消息的尋呼類型不為指定尋呼類型時，丟棄所述尋呼消息，丟棄的尋呼消息不進行累計。
7.如權(quán)利要求1一 5任一項所述的方法，其特征在于，在確定所述尋呼消息的尋呼類型為指定尋呼類型之后，在發(fā)送所述尋呼消息之前，進一步包括: 判斷所述尋呼消息不為重發(fā)尋呼消息時，初步確定能夠發(fā)送所述尋呼消息。
8.如權(quán)利要求7所述的方法，其特征在于，進一步包括: 確定所述尋呼消息為重發(fā)尋呼消息時，丟棄所述尋呼消息，其中，丟棄的尋呼消息不進行累計。
9.一種異常情況下的尋呼控制裝置，其特征在于，該裝置包括: 第一處理單元，用于在設(shè)定的檢測周期內(nèi)，每次對UE發(fā)送尋呼消息之前，獲取在所述檢測周期內(nèi)累計的尋呼消息條數(shù)，并判斷所述尋呼消息條數(shù)是否大于第一設(shè)定閾值； 第二處理單元，用于在判定所述尋呼消息條數(shù)大于第一設(shè)定閾值時，進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值，若是，則發(fā)送所述尋呼消息，否則，在確定所述尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送所述尋呼消息； 第三處理單元，用于在判定所述尋呼消息條數(shù)小于或等于第一設(shè)定閾值時，發(fā)送所述尋呼消息。
10.如權(quán)利要求9所述的裝置，其特征在于，所述第一處理單元，還用于: 在獲取在當前檢測周期內(nèi)累計的尋呼消息條數(shù)之后，在判斷所述尋呼消息條數(shù)是否大于第一設(shè)定閾值之前，判定所述尋呼消息條數(shù)小于所述當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，確定執(zhí)行后續(xù)判斷操作。
11.如權(quán)利要求10所述的裝置，其特征在于，所述第一處理單元，還用于: 在判定所述尋呼消息條數(shù)大于或等于所述當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，丟棄所述尋呼消息，其中，丟棄的尋呼消息不進行累計。
12.如權(quán)利要求9所述的裝置，其特征在于，所述第二處理單元，還用于: 在判定所述尋呼消息條數(shù)大于第一設(shè)定閾值后，在進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值之前，判定當前尋呼由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，確定執(zhí)行后續(xù)判斷操作。
13.如權(quán)利要求12所述的裝置，其特征在于，所述第二處理單元，還用于: 判定當前尋呼不是由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，在進一步確定所述尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送所述尋呼消息。
14.如權(quán)利要求9一 13任一項所述的裝置，其特征在于，所述第二處理單元，還用于: 在確定當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級未達到第二設(shè)定閾值之后，在確定所述尋呼消息的尋呼類型不為指定尋呼類型時，丟棄所述尋呼消息，丟棄的尋呼消息不進行累計。
15.如權(quán)利要求9一 13任一項所述的裝置，其特征在于，所述第二處理單元，還用于: 在確定所述尋呼消息的尋呼類型為指定尋呼類型之后，在發(fā)送所述尋呼消息之前，判斷所述尋呼消息不為重發(fā)尋呼消息時，初步確定能夠發(fā)送所述尋呼消息。
16.如權(quán)利要求15所述的裝置，其特征在于，所述第二處理單元，還用于: 確定所述尋呼消息為重發(fā)尋呼消息時，丟棄所述尋呼消息，其中，丟棄的尋呼消息不進行累計。
17.一種異常情況下的尋呼控制裝置，其特征在于，該裝置包括: 處理器，用于在設(shè)定的檢測周期內(nèi)，每次對UE發(fā)送尋呼消息之前，獲取在所述檢測周期內(nèi)累計的尋呼消息條數(shù)，并判斷所述尋呼消息條數(shù)是否大于第一設(shè)定閾值；在判定所述尋呼消息條數(shù)大于第 一設(shè)定閾值時，進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值，若是，則發(fā)送所述尋呼消息，否則，在確定所述尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送所述尋呼消息；或者，在判定所述尋呼消息條數(shù)小于或等于第一設(shè)定閾值時，發(fā)送所述尋呼消息。
18.如權(quán)利要求17所述的裝置，其特征在于，所述處理器，還用于: 在獲取在當前檢測周期內(nèi)累計的尋呼消息條數(shù)之后，在判斷所述尋呼消息條數(shù)是否大于第一設(shè)定閾值之前，判定所述尋呼消息條數(shù)小于所述當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，確定執(zhí)行后續(xù)判斷操作。
19.如權(quán)利要求18所述的裝置，其特征在于，所述處理器，還用于: 在判定所述尋呼消息條數(shù)大于或等于所述當前檢測周期內(nèi)能夠發(fā)送的最大尋呼條數(shù)時，丟棄所述尋呼消息，其中，丟棄的尋呼消息不進行累計。
20.如權(quán)利要求17所述的裝置，其特征在于，所述處理器，還用于: 在判定所述尋呼消息條數(shù)大于第一設(shè)定閾值后，在進一步判斷當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級是否達到第二設(shè)定閾值之前，判定當前尋呼由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，確定執(zhí)行后續(xù)判斷操作。
21.如權(quán)利要求20所述的裝置，其特征在于，所述處理器，還用于: 判定當前尋呼不是由創(chuàng)建承載過程觸發(fā)或者由發(fā)送下行數(shù)據(jù)觸發(fā)時，在進一步確定所述尋呼消息的尋呼類型為指定尋呼類型時，再發(fā)送所述尋呼消息。
22.如權(quán)利要求17- 21任一項所述的裝置，其特征在于，所述處理器，還用于: 在確定當前待發(fā)送的尋呼消息所針對的UE的優(yōu)先級未達到第二設(shè)定閾值之后，在確定所述尋呼消息的尋呼類型不為指定尋呼類型時，丟棄所述尋呼消息，丟棄的尋呼消息不進行累計。
23.如權(quán)利要求17- 21任一項所述的裝置，其特征在于，所述處理器，還用于: 在確定所述尋呼消息的尋呼類型為指定尋呼類型之后，在發(fā)送所述尋呼消息之前，判斷所述尋呼消息不為重發(fā)尋呼消息時，初步確定能夠發(fā)送所述尋呼消息。
24.如權(quán)利要求23所述的裝置，其特征在于，所述處理器，還用于: 確定所述尋呼消息為重發(fā)尋呼消息時，丟棄所述尋呼消息，其中，丟棄的尋呼消息不進行累計。
【文檔編號】H04W68/02GK103648165SQ201310747088
【公開日】2014年3月19日 申請日期:2013年12月30日 優(yōu)先權(quán)日:2013年12月30日
【發(fā)明者】蘇麗芳, 習建德 申請人:大唐移動通信設(shè)備有限公司