[發(fā)明專利]應(yīng)用層尋呼消息的處理方法和裝置

有效

• 申請(qǐng)?zhí)枺?/td>: 201910019309.8
• 申請(qǐng)日: 2019-01-09
• 公開(kāi)（公告）號(hào): CN111432470B
• 公開(kāi)（公告）日: 2023-04-07
• 發(fā)明（設(shè)計(jì)）人: 劉揆;郭巖海;張玲;鄧時(shí)穎
• 申請(qǐng)（專利權(quán)）人: 成都鼎橋通信技術(shù)有限公司
• 主分類號(hào): H04W68/02
• 分類號(hào): H04W68/02;H04W76/27
• 代理公司: 北京德琦知識(shí)產(chǎn)權(quán)代理有限公司 11018
• 代理人: 孫清然;王琦

本申請(qǐng)公開(kāi)了一種應(yīng)用層尋呼消息的處理方法和裝置，其中方法包括：UE內(nèi)的Modem在接收到MCPTT?server在MBMS組播信道上發(fā)送的應(yīng)用層尋呼消息時(shí)，根據(jù)對(duì)該應(yīng)用層尋呼消息的解析結(jié)果，判斷是否需要對(duì)該應(yīng)用層尋呼消息進(jìn)行處理；當(dāng)判定需要進(jìn)行所述處理時(shí)，如果所述UE處于RRC空閑態(tài)，則所述Modem發(fā)起RRC連接過(guò)程；當(dāng)判定不需要進(jìn)行所述處理時(shí)，所述Modem將所述應(yīng)用層尋呼消息丟棄。采用本發(fā)明，可以降低終端功耗、減少處理時(shí)延。

技術(shù)領(lǐng)域

本發(fā)明涉及移動(dòng)通信技術(shù)，特別是涉及一種應(yīng)用層尋呼消息的處理方法和裝置。

背景技術(shù)

3GPP關(guān)鍵任務(wù)按鍵通話(MCPTT)標(biāo)準(zhǔn)協(xié)議23.379中定義了利用MBMS組播信道發(fā)送應(yīng)用層尋呼(Application?paging)的過(guò)程。該消息用于通知終端需要進(jìn)入連接態(tài)。接收的終端如果處于RRC空閑態(tài)，終端底層模塊(modem)會(huì)在EUTRAN層面發(fā)起RRC連接建立(RRCconnection?establishment)過(guò)程，從而使終端進(jìn)入RRC連接態(tài)。

MCPTT?server和MCPTT?client都屬于應(yīng)用層，對(duì)UE的RRC狀態(tài)不感知。EUTRAN層面(包括UE?modem和eNodeB)知道UE的RRC狀態(tài)。Application?paging消息中包含被尋呼的應(yīng)用層群組ID(針對(duì)MCPTT組呼業(yè)務(wù))或應(yīng)用層用戶ID(針對(duì)MCPTT單呼業(yè)務(wù))，MCPTT?client根據(jù)應(yīng)用層群組ID或用戶ID可以判斷本終端是否是尋呼對(duì)象。

現(xiàn)有協(xié)議的應(yīng)用層尋呼消息的具體處理流程包括如下步驟：

1、MCPTT?Server決定在單播信道上發(fā)起一個(gè)新的呼叫或者將一個(gè)正在進(jìn)行中的呼叫切換到單播。

2、MCPTT在MBMS組播信道上發(fā)送應(yīng)用層尋呼(Application?Paging)消息，通知MCPTTclient將在單播信道上進(jìn)行呼叫業(yè)務(wù)數(shù)據(jù)傳輸。

3、MCPTT?client觸發(fā)UE進(jìn)入RRC連接態(tài)，即通知modem發(fā)起RRC連接建立過(guò)程。

4、MCPTT?server如果已經(jīng)在MBMS組播信道上發(fā)送呼叫業(yè)務(wù)數(shù)據(jù)，則停止發(fā)送。

5、MCPTT?server向MCPTT?client在單播信道上發(fā)送呼叫業(yè)務(wù)數(shù)據(jù)。

3GPP規(guī)范23.280里定義了MBMS架構(gòu)與MC?service?client和MC?service?server的關(guān)系。MBMS組播信道可以用來(lái)傳輸MC?service?server到MC?service?client的下行信令及業(yè)務(wù)數(shù)據(jù)。MBMS組播信道消息通過(guò)Uu接口傳輸?shù)浇K端，由底層模塊(modem)接收。

對(duì)于MCPTT，該架構(gòu)中MC?service?client等同于MCPTT?client，MC?serviceserver等同于MCPTT?server。

發(fā)明人在實(shí)現(xiàn)本發(fā)明的過(guò)程中發(fā)現(xiàn)：上述應(yīng)用層尋呼消息的處理方案存在終端功耗較大處理時(shí)延長(zhǎng)的問(wèn)題。具體原因分析如下：

上述應(yīng)用層尋呼消息的處理方案中，UE收到MBMS承載發(fā)送的Application?Paging消息時(shí)，會(huì)默認(rèn)由MCPTT?client對(duì)消息進(jìn)行解析和處理，由MCPTT?client觸發(fā)UE底層模塊(modem)發(fā)起RRC連接建立(RRC?connection?establishment)過(guò)程。那么就會(huì)導(dǎo)致：

1.UE上層應(yīng)用頻繁被喚醒，功耗較大。

2.UE?modem負(fù)責(zé)接收MBMS組播信道上的數(shù)據(jù)，本身具有解析MBMS消息的能力。按現(xiàn)有方案，modem收到Application?Paging消息時(shí)，需要先傳給MCPTTclient進(jìn)行處理，然后再由MCPTTclient觸發(fā)UE?modem發(fā)起RRC連接過(guò)程，處理時(shí)延較長(zhǎng)。

發(fā)明內(nèi)容