增強(qiáng)型尋呼的方法及其機(jī)器類型通信裝置交叉引用本申請(qǐng)依據(jù)35U.S.C.§119要求如下優(yōu)先權(quán)：編號(hào)為61/506,463，申請(qǐng)日為2011年7月11日，名稱為“EnhancedPagingMechanismforMachineTypeCommunication”的美國(guó)臨時(shí)申請(qǐng)。上述申請(qǐng)標(biāo)的在此一起作為參考。技術(shù)領(lǐng)域本發(fā)明有關(guān)于機(jī)器類型通信(MachineTypeCommunication,MTC)，并且特別有關(guān)于在移動(dòng)網(wǎng)絡(luò)中用于機(jī)器類型通信的增強(qiáng)型尋呼機(jī)制。

背景技術(shù)：
機(jī)器類型通信涉及一個(gè)或多個(gè)不需要人類干預(yù)的實(shí)體的數(shù)據(jù)通信形式。優(yōu)化機(jī)器類型通信的服務(wù)不同于人與人之間(Human-to-Human,H2H)通信的服務(wù)。典型地，機(jī)器類型通信服務(wù)由于涉及不同的市場(chǎng)情況、純數(shù)據(jù)通信、更低的成本與代價(jià)以及潛在較大數(shù)量的每個(gè)終端具有極少訊務(wù)的通信終端，因此其不同于當(dāng)前移動(dòng)網(wǎng)絡(luò)通信服務(wù)。利用術(shù)語(yǔ)機(jī)器與機(jī)器(Machine-to-Machine,M2M)與MTC描述使用實(shí)例以及機(jī)器類型通信服務(wù)的不同特征。M2M與MTC裝置將是用于實(shí)現(xiàn)“物聯(lián)網(wǎng)”的下一代無(wú)線網(wǎng)絡(luò)的一部分。M2M與MTC潛在的應(yīng)用包含安保、追蹤、支付、健康、遠(yuǎn)程維護(hù)/控制、計(jì)量(metering)以及消費(fèi)裝置。機(jī)器類型通信服務(wù)的主要特征包含低移動(dòng)性、時(shí)間可控性、延遲容忍性、僅分組切換、低數(shù)據(jù)傳輸、僅移動(dòng)始端、低頻移動(dòng)終端、MTC監(jiān)視、優(yōu)先級(jí)警報(bào)、安全連接、位置特定觸發(fā)、提供上行鏈路數(shù)據(jù)終端的網(wǎng)絡(luò)、低頻傳輸以及基于分組的MTC特征。第三代合作計(jì)劃(3rdGenerationPartnershipProject,3GPP)提供MTC裝置與MTC服務(wù)器之間或者兩個(gè)MTC裝置之間的端對(duì)端(end-to-end)應(yīng)用。3GPP移動(dòng)網(wǎng)絡(luò)提供MTC的優(yōu)化傳輸與通信服務(wù)。然而，上述移動(dòng)網(wǎng)絡(luò)中的M2M裝置的數(shù)量預(yù)計(jì)遠(yuǎn)遠(yuǎn)大于用戶設(shè)備(UserEquipment,UE)的當(dāng)前數(shù)量，即高數(shù)據(jù)級(jí)的差距(orderlarger)。由于具有如此大的數(shù)量，網(wǎng)絡(luò)可能用完尋呼資源并且引起額外延遲。例如，由于maxPageRec為16并且無(wú)線電幀的最大尋呼子幀為4，所以移動(dòng)網(wǎng)絡(luò)在一秒鐘內(nèi)最多呼叫6400個(gè)MTC裝置。因此，潛在問(wèn)題是對(duì)于未來(lái)的MTC裝置，當(dāng)前的尋呼資源將變得不足。目前存在幾個(gè)關(guān)于在3GPP移動(dòng)網(wǎng)絡(luò)中尋呼過(guò)載的解決方案。一個(gè)解決方案是優(yōu)先尋呼S1應(yīng)用協(xié)議(S1ApplicationProtocol,S1AP)以在臨時(shí)過(guò)載時(shí)選擇性地舍棄尋呼。另一個(gè)解決方案是由系統(tǒng)信息區(qū)塊(SystemInformationBlock,SIB)修改以動(dòng)態(tài)改變尋呼配置。然而兩種解決方案對(duì)于MTC裝置來(lái)說(shuō)皆不理想。這是因?yàn)閷?duì)于特定的M2M應(yīng)用，由于節(jié)省電量的考慮，其可具有較低的工作周期(dutycycle)。例如，MTC裝置僅當(dāng)具有上行鏈路數(shù)據(jù)或者在空閑模式(idlemode)下具有遠(yuǎn)遠(yuǎn)長(zhǎng)于當(dāng)前允許的不連續(xù)接收(DiscontinuousReception,DRX)時(shí)才啟動(dòng)。除了空閑模式下的DRX，如果DRX值不足夠長(zhǎng)以支持其操作，則MTC裝置甚至可具有更長(zhǎng)的休眠周期(sleepcycle)。當(dāng)尋呼事件發(fā)生時(shí)，MTC裝置做下列動(dòng)作：在尋呼事件之前啟動(dòng)、檢查系統(tǒng)信息(SystemInformation,SI)值標(biāo)簽(tag)并且取得最新的SIB；在幾個(gè)DRX周期內(nèi)監(jiān)測(cè)實(shí)體下鏈控制信道(PhysicalDownlinkControlChannel,PDCCH)中的尋呼無(wú)線電網(wǎng)絡(luò)臨時(shí)標(biāo)識(shí)(Paging-RadioNetworkTemporaryIdentifier,P-RNTI)；如果具有匹配標(biāo)識(shí)碼(Identity，ID)則進(jìn)行響應(yīng)；以及當(dāng)時(shí)間結(jié)束時(shí)回到休眠狀態(tài)。如果尋呼過(guò)載發(fā)生，基站(eNB)將花費(fèi)幾秒鐘來(lái)重新配置尋呼信道。在重新配置后，將花費(fèi)更多的時(shí)間來(lái)處理?yè)砣那闆r。因此，MTC裝置在回到休眠狀態(tài)之前，eNB可能不會(huì)及時(shí)尋呼MTC裝置。然后延遲可為幾分鐘甚至幾小時(shí)。此外，如果eNB決定在過(guò)載解決后重新配置尋呼配置，則普通UE在無(wú)任何好處的情況下必須兩次取得SIB。因此，上述的尋呼過(guò)載問(wèn)題將降低在空閑模式下普通UE的效能。

技術(shù)實(shí)現(xiàn)要素：
有鑒于此，本發(fā)明提出增強(qiáng)型尋呼的方法及其機(jī)器類型通信裝置。一種增強(qiáng)型尋呼的方法，包含：在移動(dòng)通信網(wǎng)絡(luò)中機(jī)器與機(jī)器裝置接收從基站發(fā)送的尋呼消息，其中該尋呼消息指示一組或多組機(jī)器與機(jī)器裝置；基于尋呼匹配規(guī)則與尋呼響應(yīng)策略決定是否響應(yīng)該尋呼消息；在該移動(dòng)通信網(wǎng)絡(luò)中與該基站建立連接；以及從該基站接收分組廣播消息，其中該分組廣播消息包含分組無(wú)線電網(wǎng)絡(luò)臨時(shí)標(biāo)識(shí)碼。一種增強(qiáng)型尋呼的機(jī)器類型通信裝置，包含：射頻模塊，用于在移動(dòng)通信網(wǎng)絡(luò)中接收從基站發(fā)送的尋呼消息，其中該尋呼消息指示一組或多組機(jī)器與機(jī)器裝置；尋呼管理模塊，用于基于尋呼匹配規(guī)則與尋呼響應(yīng)策略決定是否響應(yīng)該尋呼消息；以及連接管理模塊，用于與該基站建立連接使得該機(jī)器類型通信裝置從該基站接收分組廣播消息，其中該分組廣播消息包含分組無(wú)線電網(wǎng)絡(luò)臨時(shí)標(biāo)識(shí)碼。一種增強(qiáng)型尋呼的方法，包含：在移動(dòng)通信網(wǎng)絡(luò)中由用戶設(shè)備監(jiān)測(cè)尋呼時(shí)段，其中每個(gè)尋呼周期為該用戶設(shè)備預(yù)定義該尋呼時(shí)段；接收從基站發(fā)送的尋呼消息，其中該尋呼消息包含繼續(xù)旗標(biāo)；如果該用戶設(shè)備屬于第一裝置類型則忽略該繼續(xù)旗標(biāo)；以及如果該用戶設(shè)備屬于第二裝置類型繼續(xù)監(jiān)測(cè)尋呼時(shí)段，直到如果該繼續(xù)旗標(biāo)設(shè)定為真則該用戶設(shè)備接收尋呼為止。本發(fā)明提出增強(qiáng)型尋呼的方法及其機(jī)器類型通信裝置可充分利用尋呼資源或者降低電量消耗。其他實(shí)施例以及優(yōu)勢(shì)將在下面作詳細(xì)描述。本發(fā)明內(nèi)容不限定本發(fā)明，本發(fā)明由權(quán)利要求限定。附圖說(shuō)明本發(fā)明的附圖用于說(shuō)明本發(fā)明的實(shí)施例，其中相同的標(biāo)號(hào)代表相同的組件。圖1是根據(jù)新穎方面描述的支持MTC增強(qiáng)型尋呼的3GPP網(wǎng)絡(luò)。圖2是根據(jù)新穎方面描述的MTC裝置的示意圖。圖3是根據(jù)新穎方面描述的移動(dòng)通信網(wǎng)絡(luò)中用于MTC裝置的增強(qiáng)型尋呼機(jī)制。圖4是描述在3GPP網(wǎng)絡(luò)中定義的尋呼幀以及尋呼時(shí)段。圖5是描述用于MTC裝置的自適應(yīng)尋呼設(shè)計(jì)的一個(gè)實(shí)施例。圖6是描述3GPP網(wǎng)絡(luò)中的分組尋呼。圖7是描述用于分組尋呼的RRC尋呼消息。圖8是描述利用G-IMSI作為分組尋呼ID的分組尋呼實(shí)施例。圖9是描述利用G-S-TMSI作為分組尋呼ID的分組尋呼實(shí)施例。圖10是描述利用分組尋呼機(jī)制的分組廣播的一實(shí)施例。圖11是描述關(guān)聯(lián)MO時(shí)段或者M(jìn)T時(shí)段的尋呼示例。圖12是描述動(dòng)態(tài)安排尋呼響應(yīng)策略的兩種選擇。具體實(shí)施方式關(guān)于本發(fā)明的多個(gè)實(shí)施例將作為詳細(xì)參考，附圖是為描述本發(fā)明的實(shí)施例所作。在說(shuō)明書(shū)及權(quán)利要求書(shū)當(dāng)中使用了某些詞匯來(lái)指稱特定的元件。所屬技術(shù)領(lǐng)域的技術(shù)人員應(yīng)可理解，硬件制造商可能會(huì)用不同的名詞來(lái)稱呼同一個(gè)元件。本說(shuō)明書(shū)及權(quán)利要求書(shū)并不以名稱的差異作為區(qū)分元件的方式，而是以元件在功能上的差異作為區(qū)分的準(zhǔn)則。在通篇說(shuō)明書(shū)及權(quán)利要求項(xiàng)中所提及的“包含”為一開(kāi)放式的用語(yǔ)，故應(yīng)解釋成“包含但不限定于”。此外，“耦接”一詞在此包含任何直接及間接的電氣連接手段。因此，若文中描述第一裝置耦接于第二裝置，則代表第一裝置可直接電氣連接于第二裝置，或透過(guò)其它裝置或連接手段間接地電氣連接至第二裝置。圖1是根據(jù)新穎方面描述的支持MTC增強(qiáng)型尋呼的3GPP網(wǎng)絡(luò)100。3GPP網(wǎng)絡(luò)100包含MTC服務(wù)器111，MTC服務(wù)器111通過(guò)與多個(gè)MTC裝置（例如圖1所示的MTC裝置114）通信向MTC用戶112提供各種MTC服務(wù)。在圖1的示例中，MTC服務(wù)器111、MTC用戶112以及分組數(shù)據(jù)網(wǎng)關(guān)(PacketDataNetworkGateway，PDNGW)屬于核心網(wǎng)絡(luò)110的一部分。MTC裝置114與服務(wù)的基站115屬于無(wú)線電存取網(wǎng)絡(luò)(RadioAccessNetwork,RAN)120的一部分。MTC服務(wù)器111通過(guò)PDNGW113、服務(wù)網(wǎng)關(guān)(ServingGateway，S-GW)116以及基站115與MTC裝置114通信。此外，移動(dòng)管理實(shí)體(MobilityManagementEntity，MME)117與基站115、S-GW116以及PDNGW113進(jìn)行通信用于3GPP網(wǎng)絡(luò)100中無(wú)線電存取裝置的移動(dòng)管理。值得注意的是，相比于人與人通信，術(shù)語(yǔ)MTC稱為M2M通信，于此同時(shí)相比于人與人裝置，MTC裝置稱為M2M裝置。在圖1的示例中，MTC服務(wù)器111在應(yīng)用協(xié)議層通過(guò)已建立的應(yīng)用程序編程接口(Application-ProgrammingInterface,API)140向MTC用戶112提供各種MTC服務(wù)/應(yīng)用。典型的MTC應(yīng)用包含安保（例如監(jiān)控系統(tǒng)）、追蹤定位（例如里程保險(xiǎn)服務(wù)）、支付（例如自動(dòng)售貨機(jī)以及游戲機(jī)）、健康（例如健康說(shuō)服系統(tǒng)）、遠(yuǎn)程維護(hù)/控制、量測(cè)（例如智能電網(wǎng)）以及消費(fèi)裝置（例如電子書(shū)）。為了提供端對(duì)端MTC服務(wù)，在3GPP網(wǎng)絡(luò)中MTC服務(wù)器111與多個(gè)MTC裝置進(jìn)行通信。每個(gè)MTC裝置（例如MTC裝置114）包含各種協(xié)議層模塊以支持端對(duì)端MTC應(yīng)用以及數(shù)據(jù)連接。在應(yīng)用層，應(yīng)用(Application,APP)模塊131在APP協(xié)議層上與MTC服務(wù)器111通信（例如虛線141所示），其中APP模塊131提供端對(duì)端控制/數(shù)據(jù)。在網(wǎng)絡(luò)層，非存取層(Non-AccessStratum,NAS)模塊132在NAS協(xié)議層與MME117通信（例如虛線142所示），其中NAS模塊132支持移動(dòng)管理以及其他信令功能。在RAN層，無(wú)線電資源控制(RadioResourceControl,RRC)模塊133在RRC協(xié)議層與基站115通信（例如虛線143所示），其中RRC模塊133負(fù)責(zé)系統(tǒng)信息廣播、RRC連接控制、尋呼、無(wú)線電配置控制、服務(wù)質(zhì)量(QualityofService,QoS)控制等。在移動(dòng)通信網(wǎng)絡(luò)中，可利用尋呼來(lái)搜索空閑UE以及建立信令連接。例如，到達(dá)S-GW的下行鏈路數(shù)據(jù)包觸發(fā)尋呼。當(dāng)S-GW接收目標(biāo)為空閑UE的下行鏈路數(shù)據(jù)包時(shí)，其不具有向eNB發(fā)送數(shù)據(jù)包的eNB地址。替換地，S-GW通知MME下行鏈路數(shù)據(jù)包已經(jīng)到達(dá)。MME獲知UE在哪個(gè)追蹤區(qū)域(TrackingArea,TA)漫游并且MME向TA清單中的所有eNB發(fā)送尋呼請(qǐng)求。一旦接收到尋呼消息，UE響應(yīng)MME并且激活承載(bearer)使得下行鏈路數(shù)據(jù)包發(fā)送至UE。存在3GPP網(wǎng)絡(luò)中定義的各種尋呼程序。對(duì)于長(zhǎng)期演進(jìn)技術(shù)(LongTermEvolution,LTE)核心網(wǎng)絡(luò)(CoreNetwork,CN)，網(wǎng)絡(luò)可利用尋呼程序以請(qǐng)求與UE的NAS信令連接的建立。尋呼程序的另一目的是由于網(wǎng)絡(luò)失敗如果需要提示UE重新獲取。另外，網(wǎng)絡(luò)可利用尋呼程序建立移動(dòng)終端向后支持電路交換(CircuitSwitched,CS)程序。對(duì)于LTERAN，可利用尋呼向在RRC_IDLE中的UE發(fā)送尋呼信息；將系統(tǒng)信息改變通知至在RRC_IDLE或RRC_CONNECTED中的UE；通知地震海嘯預(yù)警系統(tǒng)(EarthquakeandTsunamiWarningSystem,ETWS)主要通知及/或ETWS次級(jí)通知；及/或通知商業(yè)移動(dòng)預(yù)警系統(tǒng)(CMAS)。預(yù)計(jì)移動(dòng)網(wǎng)絡(luò)中的M2M裝置的數(shù)量遠(yuǎn)遠(yuǎn)大于目前UE的數(shù)量，即高數(shù)量級(jí)的差距。由于數(shù)量較大，網(wǎng)絡(luò)可用完尋呼資源并且產(chǎn)生額外延遲。例如，在無(wú)線電幀中maxPageRec為16并且最大尋呼子幀為4時(shí)，移動(dòng)網(wǎng)絡(luò)在一秒鐘最多可尋呼6400個(gè)MTC裝置。因此，一個(gè)潛在問(wèn)題是當(dāng)前的尋呼資源對(duì)于將來(lái)的MTC裝置是不足的。此外，對(duì)于某些M2M應(yīng)用，處于節(jié)省電量的考慮，其具有較低的工作周期。因此，如果由于較低優(yōu)先級(jí)選擇性的舍棄MTC尋呼，尋呼過(guò)載可引起對(duì)MTC裝置不可接受的長(zhǎng)延遲，或者如果系統(tǒng)信息（例如SIB）調(diào)整動(dòng)態(tài)改變了尋呼配置，因?yàn)槠胀║E必須獲得兩次SIB，則降低了空閑模式下普通UE的電量效能。在一新穎方面，可將增強(qiáng)型尋呼機(jī)制應(yīng)用于3GPP網(wǎng)絡(luò)的MTC裝置中。首先，提出自適應(yīng)尋呼用于MTC裝置自適應(yīng)分配額外的尋呼時(shí)段(PagingOccasion,PO)，不具有任何普通UE的額外過(guò)程或電量消耗。其次，提出分組尋呼以利用一個(gè)尋呼同時(shí)呼叫多個(gè)MTC裝置。另外提出了分組廣播與分組釋放。然后，提出具有響應(yīng)方案的尋呼以預(yù)定義或動(dòng)態(tài)配置MTC裝置的尋呼響應(yīng)方案。圖2是根據(jù)新穎方面描述的MTC裝置201的示意圖。MTC裝置201包含存儲(chǔ)器211、處理器212、耦接天線214的射頻模塊213、基帶模塊215、支持各種協(xié)議層的3GPP協(xié)議棧模塊226、TCP/IP協(xié)議棧模塊227、應(yīng)用模塊228以及包含尋呼管理模塊231與連接管理模塊232的管理模塊230，上述各種協(xié)議層包含NAS225、RRC224、分組數(shù)據(jù)匯聚協(xié)議/無(wú)線電連接控制(PacketDataConvergenceProtocol/RadioLinkControl,PDCP/RLC)223、介質(zhì)訪問(wèn)控制(MediaAccessControl,MAC)222以及實(shí)體(Physical,PHY)221。各種模塊是功能模塊并且由軟件、固件、硬件或其任意組合實(shí)施。當(dāng)處理器212執(zhí)行功能時(shí)（通過(guò)包含在存儲(chǔ)器中的程序說(shuō)明），上述功能模塊相互協(xié)作以允許MTC裝置201執(zhí)行自適應(yīng)尋呼、分組尋呼、分組廣播及/或具有對(duì)應(yīng)響應(yīng)策略的尋呼。例如，當(dāng)連接管理模塊232負(fù)責(zé)建立/釋放與網(wǎng)絡(luò)的連接時(shí)，尋呼管理模塊231負(fù)責(zé)監(jiān)測(cè)尋呼時(shí)段并且響應(yīng)尋呼。圖3是根據(jù)新穎方面描述的移動(dòng)通信網(wǎng)絡(luò)中用于MTC裝置的增強(qiáng)型尋呼機(jī)制。在圖3的示例中，多個(gè)MTC裝置（例如MTC裝置310）通過(guò)基站320以及MME330與MTC服務(wù)器340進(jìn)行通信。在步驟351，MTC服務(wù)器340將下行鏈路數(shù)據(jù)包發(fā)送至MTC裝置310。在步驟352，MME330向基站320發(fā)送尋呼請(qǐng)求。在步驟353，基站320向MTC310發(fā)送RRC尋呼消息。最終，在步驟354，MTC310接收上述尋呼消息并且向基站320發(fā)送回尋呼響應(yīng)。在第一新穎方面，MTC裝置310基于包含在尋呼消息中的“繼續(xù)旗標(biāo)”自適應(yīng)地監(jiān)測(cè)尋呼時(shí)段。在第二新穎方面，MTC裝置310利用分組尋呼ID監(jiān)測(cè)尋呼通道，其中可在AS層、NAS層、應(yīng)用層或者單獨(dú)或者任意結(jié)合控制。在第三新穎方面，MTC裝置310基于預(yù)定義或動(dòng)態(tài)安排尋呼策略響應(yīng)尋呼消息。圖4是描述在3GPP網(wǎng)絡(luò)中定義的尋呼幀(PagingFrame,PF)以及尋呼時(shí)段。尋呼幀為一個(gè)無(wú)線電幀，其可包含一個(gè)或多個(gè)尋呼時(shí)段。PF由下列公式給出：SFNmodT=(T/N)*(UE_IDmodN)其中-T=min(TC,TUE):特定UE與特定小區(qū)之間的最小DRX周期○在系統(tǒng)信息中廣播默認(rèn)DRX周期○上層配置UE特定DRX-N=min(T,nB):上述UE尋呼周期中的尋呼幀數(shù)量○nB={4T,2T,T,T/2,T/4,T/8,T/16,T/32}(SIB2,IEnB)-UE_ID=IMSImod1024(存儲(chǔ)在USIM中)尋呼時(shí)段為子幀，其中可存在PDCCH上發(fā)送的為尋呼消息提供方向的P-RNTI。如列表410所示，利用尋呼消息用于尋呼以及系統(tǒng)信息改變通知。用于尋呼的傳輸信道稱為尋呼信道(PagingChannel,PCH)，并且用于尋呼的邏輯信道稱為尋呼控制信道(PagingControlChannel,PCCH)。如列表420（用于分頻多任務(wù)）與列表430（用于分時(shí)多任務(wù)）所示，從子幀類型指向PO的指標(biāo)i_s從下列公式中取得：i_s=floor(UE_ID/N)modNs其中-Ns=max(1,nB/T)=max(1,{4,2,1,1/2,1/4,1/8,1/16,1/32})=1,2或4-i_s=floor(UE_ID/N)modNs=1,2或4當(dāng)網(wǎng)絡(luò)中預(yù)定義PF與PO時(shí)，然而尋呼MTC裝置的數(shù)量隨時(shí)間的不同而不為常數(shù)。在某些情況下，上述數(shù)量遠(yuǎn)遠(yuǎn)大于當(dāng)前的容量。通常，如果考慮MTC尋呼的第二優(yōu)先級(jí)，則由于不足的尋呼空間，存在網(wǎng)絡(luò)不能及時(shí)在裝置的PO中插入裝置ID的情況，這樣可引起顯著延遲。這樣不清楚網(wǎng)絡(luò)可提供何種程度的尋呼。如果網(wǎng)絡(luò)甚至不能提供尋呼負(fù)載，并且由于較長(zhǎng)延遲尋呼請(qǐng)求連續(xù)的丟失尋呼，由于“重新尋呼”將在核心網(wǎng)絡(luò)中引起更多的尋呼請(qǐng)求。某些不走運(yùn)的MTC裝置可遭受無(wú)限期的尋呼停止。圖5是描述用于MTC裝置的自適應(yīng)尋呼設(shè)計(jì)的一個(gè)實(shí)施例?？臻e模式下的普通UE在每個(gè)DRX周期內(nèi)只必須啟動(dòng)一個(gè)子幀(PO)。典型地，MTC裝置運(yùn)用UE特定DRX值的最長(zhǎng)DRX周期。除了空閑模式下的DRX，如果DRX值對(duì)于操作來(lái)說(shuō)不足夠長(zhǎng)，則MTC裝置可具有更長(zhǎng)的休眠周期。在休眠模式下，MTC裝置完全關(guān)閉其無(wú)線電，并且在休眠模式下MTC用戶或網(wǎng)絡(luò)不能到達(dá)/觸發(fā)/尋呼MTC裝置。因此，如圖5所示，用于MTC裝置的PO在尋呼周期N的子幀#1，以及在接下來(lái)的尋呼周期N+1的子幀#2發(fā)生。在每個(gè)尋呼周期中，MTC裝置監(jiān)測(cè)其PO并且進(jìn)入DRX直到下一個(gè)PO。例如，如果MTC裝置在子幀#1不能接收尋呼，則其進(jìn)入DRX直到子幀#2的下一個(gè)PO。在自適應(yīng)尋呼下，可自適應(yīng)安排額外的尋呼時(shí)段。在圖5的實(shí)施例中，可在尋呼消息中引入“繼續(xù)”旗標(biāo)。當(dāng)基站在對(duì)應(yīng)的PO中不能插入所有的尋呼時(shí)，可將“繼續(xù)”旗標(biāo)設(shè)定為真。普通UE將忽略上述旗標(biāo)并且按照傳統(tǒng)方式進(jìn)行。然而對(duì)于MTC裝置，當(dāng)設(shè)定了旗標(biāo)時(shí)，如果未接收到尋呼，MTC裝置將“繼續(xù)”監(jiān)測(cè)PO而不是進(jìn)入DRX直到下一個(gè)PO。例如，MTC裝置在接下來(lái)的N尋呼子幀中監(jiān)測(cè)PDCCH，其中N可為1、2、3等。旗標(biāo)可能包含N或者N是預(yù)定義的。另外可配置MTC裝置的哪個(gè)分組需要監(jiān)測(cè)額外的PO（例如子幀#3）。例如，通過(guò)RRC或NAS的專用信令可配置MTC裝置忽略旗標(biāo)?；疽嗫蓮V播通知MTC分組應(yīng)該繼續(xù)監(jiān)測(cè)尋呼子幀。一旦MTC裝置接收了尋呼，則不考慮上述旗標(biāo)停止尋呼監(jiān)測(cè)并且響應(yīng)上述尋呼。另外，如果“繼續(xù)”旗標(biāo)設(shè)定為假，UE在DRX下在每個(gè)尋呼周期檢測(cè)一次尋呼時(shí)段。分組尋呼是MTC裝置增強(qiáng)尋呼效能的另一機(jī)制。M2M分組可用于許多層。在AS層，可為M2M分組配置分組ID?？衫靡粋€(gè)尋呼以尋呼監(jiān)測(cè)尋呼分組中的所有MTC裝置?；究煽刂粕鲜鯩2M分組以節(jié)省AS資源。在NAS層，可在核心網(wǎng)絡(luò)層應(yīng)用M2M分組以節(jié)省信令開(kāi)銷，例如由MME控制。在應(yīng)用層，MTC用戶或MTC服務(wù)器可控制M2M分組以用于更簡(jiǎn)管理。不同層的M2M分組可為獨(dú)立的或者共存以提供靈活性。圖6是描述3GPP網(wǎng)絡(luò)中的分組尋呼。移動(dòng)通信網(wǎng)絡(luò)600包含MTC服務(wù)器610、PDNGW620、S-GW630、MME640、基站641與642以及MTC裝置650。在圖6的示例中，由于裝置管理，例如軟件升級(jí)或定期輪詢(periodicpolling)，MTC服務(wù)器需要分組中的每個(gè)MTC裝置皆作岀響應(yīng)。在沒(méi)有分組尋呼的支持下，尋呼信令需要一個(gè)一個(gè)地完成。在具有分組尋呼的支持下，MTC服務(wù)器610基于所有MTC裝置650的M2M應(yīng)用建立具有分組ID的M2M分組。MTC服務(wù)器610向MME640發(fā)送分組ID，接著MME640向已連接的基站641與642發(fā)送具有分組ID的尋呼請(qǐng)求，并且基站641與642將分組ID插入尋呼消息。通過(guò)分組尋呼的支持可優(yōu)化信令。圖7是描述RRC尋呼消息700的一個(gè)示例。尋呼消息包含尋呼紀(jì)錄列表。每個(gè)尋呼紀(jì)錄包含UE標(biāo)識(shí)碼，其在國(guó)際移動(dòng)用戶標(biāo)識(shí)碼(InternationalMobileSubscriberIdentity，IMSI)與伺服臨時(shí)移動(dòng)用戶標(biāo)識(shí)碼(ServingTemporaryMobileSubscriberIdentity，S-TMSI)作出選擇?？衫酶鞣N分組ID用于組尋呼。在第一實(shí)施例中，基于IMSI執(zhí)行分組尋呼。在第二實(shí)施例中，基于S-TMSI執(zhí)行分組尋呼。圖8是描述利用分組IMSI作為分組尋呼ID的分組尋呼實(shí)施例。除了IMSI，可利用分組IMSI(GroupIMSI,G-IMSI)配置每個(gè)MTC裝置。對(duì)于每個(gè)G-IMSI與IMSI，上層應(yīng)該指示是否應(yīng)跟隨對(duì)應(yīng)尋呼時(shí)段。在步驟851，MTC裝置組810向MTC服務(wù)器840預(yù)定(subscribe)MTC服務(wù)。在步驟852，MTC服務(wù)器840利用預(yù)定信息確認(rèn)MTC裝置，預(yù)定信息包含分組尋呼ID(G-IMSI)。在本示例中，MTC服務(wù)器預(yù)定義尋呼分組并且將其存儲(chǔ)在每個(gè)MTC裝置的SIM中（步驟853）。MME830維持G-IMSI的TA清單（步驟854）。在步驟855，MME830向涉及的基站820發(fā)送尋呼請(qǐng)求。在步驟856，基站820向MTC裝置組810發(fā)送尋呼消息?？衫眯碌臋C(jī)制監(jiān)測(cè)PO的G-IMSI，G-IMSI不如IMSI頻率高（步驟857）。例如，為G-IMSI定義不同的尋呼周期或nB。最終，在匹配包含在尋呼消息中的G-IMSI后，MTC裝置組810向基站820發(fā)送回尋呼響應(yīng)（步驟858）。典型地，建立RRC連接并且激活用于MTC裝置的承載。圖9是描述利用分組S-TMSI作為分組尋呼ID的分組尋呼實(shí)施例。除了S-TMSI，當(dāng)連接到網(wǎng)絡(luò)時(shí)可利用分組S-TMSI(GroupS-TMSI,G-S-TMSI)配置每個(gè)MTC裝置。在步驟951，MTC裝置組910與一個(gè)或多個(gè)基站920建立RRC連接。在步驟952，MME930向MTC裝置發(fā)送NAS信令消息。NAS信令消息包含為MTC裝置配置分組尋呼ID(G-S-TMSI)的配置信息。在本示例中，G-S-TMSI尋呼分組是靈活的并且可由NAS信令改變。例如，MME930可基于其自身決定或者來(lái)自本籍用戶服務(wù)器(HomeSubscriberServer,HSS)的信息以配置分組。在步驟953，MME930維持G-S-TMSI的TA清單。在步驟954，MME930向涉及基站920發(fā)送尋呼請(qǐng)求。在步驟955，基站920向MTC裝置組910發(fā)送尋呼消息。在步驟956，MTC裝置910監(jiān)測(cè)PO。G-S-TMSI分組不能改變尋呼監(jiān)測(cè)。最終，在匹配包含在尋呼消息中的G-S-TMSI后，MTC裝置910向基站920發(fā)送回尋呼響應(yīng)（步驟957）。典型地，建立RRC連接并且激活用于MTC裝置的承載?？衫闷渌麢C(jī)制進(jìn)一步加強(qiáng)分組尋呼支持。例如，可利用隨分組尋呼ID發(fā)送過(guò)來(lái)的其他規(guī)則提供顆細(xì)性(finergranularity)或者更大靈活性。在一實(shí)施例中，尋呼規(guī)則可包含用于裝置分組ID的“掩碼”或者“通配符”。例如，可利用問(wèn)號(hào)“?”作為或?yàn)?或?yàn)?的通配符。分組尋呼ID“101011??”表示要尋呼具有“10101100”、“10101110”、“10101101”、“10101111”裝置ID的所有裝置。在另一實(shí)施例中，可為分組尋呼ID提供操作數(shù)(operand)。為了執(zhí)行復(fù)雜分組尋呼任務(wù)，可利用邏輯操作數(shù)AND/OR/NOT、M2M分類及/或?qū)傩?、掩碼共同構(gòu)成分組尋呼規(guī)則。例如，一種尋呼規(guī)則可為尋呼具有優(yōu)先級(jí)為1并且分類為智能電表的所有MTC裝置，另一尋呼規(guī)則可為尋呼屬于尋呼組為111100??并且屬性為定期報(bào)告的所有MTC裝置。尋呼分組可在不同層進(jìn)行不同管理。在第一示例中，整個(gè)公共陸地移動(dòng)網(wǎng)絡(luò)(PublicLandMobileNetwork,PLMN)共享相同的尋呼分組。一個(gè)基站或者TA下的分組X與另一基站或者TA下的分組X屬于相同尋呼分組X。在第二示例中，整個(gè)TA共享相同的尋呼分組。在一個(gè)TA下的分組Y與在另一個(gè)TA下的分組Y是不同的。在相同TA中，在一個(gè)基站下的分組Y'與在另一個(gè)基站下的分組Y'屬于相同的尋呼分組Y'。在第三示例中，尋呼分組在特定基站下是單一的。在一個(gè)基站下的分組Z與在另一個(gè)基站下的分組Z是不同的。另外可優(yōu)化尋呼分組的大小。如果尋呼分組太大，可引起高隨機(jī)存取信道(RandomAccessChannel,RACH)沖突可能性，這導(dǎo)致更長(zhǎng)的延遲與更多電量消耗。另一方面，如果尋呼組太小，則不能充分利用RACH資源。當(dāng)從PLMN或MTC服務(wù)器請(qǐng)求分組尋呼時(shí)，發(fā)送組標(biāo)識(shí)碼（可選擇操作數(shù)與規(guī)則）而不是發(fā)送完整的UE標(biāo)識(shí)碼（IMSI或者S-TMSI）。一旦配置了分組標(biāo)識(shí)碼，MTC裝置監(jiān)測(cè)在對(duì)應(yīng)尋呼時(shí)段與資源中的分組的尋呼。如果存在匹配分組標(biāo)識(shí)碼或者符合規(guī)則組合，則響應(yīng)上述尋呼?？衫梅纸M尋呼用于分組廣播。在某些MTC應(yīng)用中，例如運(yùn)行管理維護(hù)(Operations,Administration,andMaintenance,OAM)或者軟件升級(jí)，消息內(nèi)容對(duì)于MTC裝置分組很可能是相同的。因此，分組廣播是有用的并且可節(jié)省無(wú)線電資源。圖10是描述在3GPP網(wǎng)絡(luò)中分組廣播的實(shí)施例。在步驟1051，MTC服務(wù)器1040向MME1030發(fā)送分組ID，其中根據(jù)可選擇的目的指示，例如分組軟件升級(jí)。在步驟1052，MME1030向一個(gè)或多個(gè)具有分組ID的涉及基站1020發(fā)送尋呼請(qǐng)求。在步驟1053，基站1020將分組ID插入尋呼消息并且將上述尋呼消息發(fā)送至MTC裝置組1010。MTC裝置監(jiān)測(cè)PO的分組ID（步驟1054）。一旦接收了尋呼消息，MTC裝置組1010與基站1020建立RRC連接（步驟1055）。在連接建立或RRC重新配置期間安排分組無(wú)線電網(wǎng)絡(luò)臨時(shí)標(biāo)識(shí)(Group-RadioNetworkTemporaryIdentifier,G-RNTI)。MTC裝置組1010亦連接MME1030并且向S-GW建立承載（步驟1056）。在步驟1057，MME/S-GW利用分組ID將軟件升級(jí)消息發(fā)送至基站1020。升級(jí)消息用于分組中的所有MTC裝置。在步驟1058，基站1020利用G-RNTI將升級(jí)消息廣播至分組中的所有MTC裝置。分組中的MTC裝置利用G-RNTI用于廣播數(shù)據(jù)的PDCCH監(jiān)測(cè)（例如軟件升級(jí)）。如果不存在混合式自動(dòng)重傳請(qǐng)求(HybridAutomaticRepeatreQuest,HARQ)，與廣播控制信道(BroadcastControlChannel,BCCH)相似（小區(qū)廣播信道，例如BCCH上的新SIB），利用PHY機(jī)制保證成功率，例如，重復(fù)或者傳輸時(shí)間間隔(TransmissionTimeInternal,TTI)捆綁。如果利用HARQ，則基站假定HARQ回饋是非應(yīng)答的(Non-Acknowledge,NACK)直到達(dá)到最大HARQ重傳。MTC裝置成功地接收將不發(fā)送任何消息的TB，MTC裝置不能譯碼將發(fā)送NACK的TB，以及如果至少存在一個(gè)已接收的NACK，基站將重新發(fā)送?？稍贛AC中執(zhí)行NACK而不是在PHY中。在步驟1059，MTC裝置組1010執(zhí)行軟件升級(jí)?？衫梅纸M釋放命令釋放已連接的MTC裝置組（步驟1060）。例如，利用信令消息作為RRCConnectionRelease的廣播版本以指示裝置的應(yīng)用類型。當(dāng)?shù)蛢?yōu)先級(jí)裝置發(fā)現(xiàn)上述消息時(shí)，執(zhí)行RRC連接釋放(RRCConnectionRelease)以釋放資源。可在細(xì)胞廣播信道上發(fā)送上述消息（BCCH上的新SIB）至僅涉及的MTC裝置收聽(tīng)。圖11是描述關(guān)聯(lián)MO時(shí)段或者M(jìn)T時(shí)段的M2M尋呼示例。對(duì)于M2M尋呼，當(dāng)尋呼消息包含裝置ID時(shí)，其可具有兩種可能的涵義。在第一種涵義中，一旦接收了上述尋呼（步驟1131），被尋呼的MTC裝置1110必須啟動(dòng)并且建立連接（步驟1132）（MT時(shí)段）。在第二種涵義中，網(wǎng)絡(luò)詢問(wèn)被尋呼的MTC裝置是否想啟動(dòng)以建立連接（MO時(shí)段）。一旦MTC裝置從基站1120接收了特定尋呼（步驟1133），則其確定是否符合條件并且需要利用MO數(shù)據(jù)進(jìn)行回復(fù)（步驟1134）。如果MTC裝置決定回復(fù)MO數(shù)據(jù)，則必須啟動(dòng)連接建立過(guò)程，例如，RACH前導(dǎo)傳輸（步驟1135）。如果數(shù)據(jù)訊務(wù)是可預(yù)測(cè)的，則來(lái)自CN或MTC服務(wù)器的輪詢MO為一靈活方案以實(shí)施端對(duì)端負(fù)載控制。MO的基于尋呼方案的主要優(yōu)勢(shì)在于其靈活性，例如與BCCH控制的預(yù)定義時(shí)間安排方案相比較。MO尋呼可在先前卸除訊務(wù)。對(duì)于延遲容忍應(yīng)用，例如讀表，亦可能完全停止MO請(qǐng)求并且唯一回復(fù)MO尋呼以從MTC裝置中得到數(shù)據(jù)。這樣由于協(xié)調(diào)MO時(shí)段創(chuàng)造的訊務(wù)突發(fā)(trafficburst)，例如同一時(shí)間不同類型的讀表，可減少RAN過(guò)載（例如RACH過(guò)載）的可能性。除了MO，需要所有MTC裝置支持MT時(shí)段，例如，為了OAM或軟件升級(jí)的目的。因此，尋呼消息應(yīng)該指示要尋呼的MTC裝置是否應(yīng)該立即響應(yīng)（MT時(shí)段）或者是否應(yīng)該只基于MO數(shù)據(jù)的可用性進(jìn)行響應(yīng)（MO時(shí)段）。不同尋呼響應(yīng)的指示可以各種方式實(shí)施。在第一示例中，尋呼消息中存在旗標(biāo)或者配置選項(xiàng)，例如，“MO尋呼”或者“MT尋呼”。在第二示例中，可利用不同的P-RNTI。在第三示例中，可利用特定尋呼代碼或者尋呼ID。在第四示例中，MTC裝置可適用于預(yù)配置尋呼情況（例如，在某些尋呼情況中發(fā)送普通尋呼(MT)以及在另外尋呼情況下發(fā)送特定尋呼(MO)）。除了指示不同尋呼響應(yīng)，可配置不同響應(yīng)策略以優(yōu)化尋呼效能，即可基于尋呼匹配規(guī)則與尋呼響應(yīng)策略決定是否響應(yīng)尋呼消息。在第一實(shí)施例中，為裝置預(yù)定義尋呼響應(yīng)策略(pagingresponsepolicy)。例如，在接收尋呼消息后，可配置裝置具有三種響應(yīng)策略。對(duì)于第一種策略，裝置必須立即連接網(wǎng)絡(luò)。對(duì)于第二種策略，裝置必須連接網(wǎng)絡(luò)，但可具有一定程度的延遲?？陕?lián)合該策略與網(wǎng)絡(luò)進(jìn)入擁塞改善技術(shù)(networkentrycongestionalleviationtechnique)。對(duì)于第三種策略，裝置可或者不可連接網(wǎng)絡(luò)，例如，只有當(dāng)存在緩沖數(shù)據(jù)(buffereddata)時(shí)，裝置連接網(wǎng)絡(luò)。裝置可基于是否存在報(bào)告的數(shù)據(jù)（及/或報(bào)告數(shù)據(jù)的優(yōu)先級(jí)）作出決定。裝置亦可基于網(wǎng)絡(luò)負(fù)載狀態(tài)作出決定。在第二實(shí)施例中，可動(dòng)態(tài)安排尋呼響應(yīng)策略?？稍趯ず粝⒅卸x尋呼響應(yīng)策略（例如，信息單元或旗標(biāo)位、概率信息）。對(duì)于概率信息，可利用分組標(biāo)識(shí)碼以及概率執(zhí)行尋呼（在每個(gè)UE的基礎(chǔ)上執(zhí)行隨機(jī)化），而不是單獨(dú)輪詢多個(gè)裝置。這對(duì)于特定應(yīng)用來(lái)說(shuō)是有用的，例如，收集分組狀態(tài)。例如，裝置擲出骰子并且與給定概率進(jìn)行比較以確定其是否連接到網(wǎng)絡(luò)。尋呼響應(yīng)策略亦可在裝置進(jìn)入空閑模式（例如撤銷消息或其他信令）之前或者同時(shí)進(jìn)行配置。圖12是描述動(dòng)態(tài)安排尋呼響應(yīng)策略的兩種選擇。在圖11的示例中，尋呼消息包含尋呼響應(yīng)策略。例如，可通過(guò)尋呼消息攜帶加載策略(loading-awarepolicy)及/或差異式接入分級(jí)策略(differentiatedaccessclasspolicy)。在第一選擇中，在一個(gè)尋呼消息中，應(yīng)用上述策略的尋呼裝置ID集合緊跟著每個(gè)策略標(biāo)識(shí)。例如，尋呼裝置ID1、ID2、ID3、ID4在策略標(biāo)識(shí)I下應(yīng)用響應(yīng)策略，與此同時(shí)，尋呼裝置ID5、ID6、ID7在策略標(biāo)識(shí)II下應(yīng)用另一響應(yīng)策略。在第二選擇中，在一個(gè)尋呼消息中，對(duì)應(yīng)的策略標(biāo)識(shí)緊跟著每個(gè)尋呼裝置ID。例如，具有ID1-ID4的每個(gè)尋呼裝置關(guān)聯(lián)于策略標(biāo)識(shí)I，與此同時(shí)，具有ID5-ID6的每個(gè)尋呼裝置關(guān)聯(lián)于策略標(biāo)識(shí)II。雖然為了說(shuō)明目的已經(jīng)描述了與本發(fā)明聯(lián)系的特定的實(shí)施例，然本發(fā)明并不局限于此。因此，對(duì)上述實(shí)施例的多個(gè)特征所作的各種修改、調(diào)整以及組合，皆視為未超出本發(fā)明的權(quán)利要求的范圍。