專利名稱：用戶信息的查詢方法及多媒體消息中心的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，具體而言，涉及一種用戶信息的查詢方法及多媒體消息中 心。
背景技術(shù)：
多媒體消息業(yè)務(wù)(Multimedia Messaging Service，簡(jiǎn)稱為MMS)是一種能夠在終 端(例如，手機(jī))和終端之間以及終端和Email服務(wù)器等其他應(yīng)用之間傳送多媒體內(nèi)容的 消息服務(wù)。與目前應(yīng)用的非常成功的文本形式的短消息業(yè)務(wù)相比，多媒體消息將為用戶提 供包括圖象、聲音等多種媒體格式的消息內(nèi)容，使運(yùn)營(yíng)商可以為用戶提供非常豐富的，個(gè)性 化的服務(wù)。例如，可以在旅程中將看到的美景配上背景音樂隨時(shí)隨地發(fā)送給遠(yuǎn)方的親朋好 友，發(fā)送精心制作的電子賀卡。當(dāng)多媒體消息發(fā)送給手機(jī)用戶時(shí)，手機(jī)的用戶信息保存在HLR服務(wù)器中，多媒體 消息中心需要通過匪5消息接口查詢HLR服務(wù)器，得到手機(jī)的用戶信息，根據(jù)上述用戶信息 確定彩信下發(fā)方式，如果用戶手機(jī)狀態(tài)正常，則多媒體消息中心給手機(jī)用戶下發(fā)正常的多 媒體消息通告消息。然而，當(dāng)多媒體消息中心通過MM5消息接口查詢HLR服務(wù)器失敗時(shí)，多媒體消息中 心無法下發(fā)需要提交的多媒體消息，從而導(dǎo)致下發(fā)多媒體消息的成功率降低，大大降低了 用戶體驗(yàn)。

發(fā)明內(nèi)容
本發(fā)明的主要目的在于提供一種用戶信息的查詢方法及多媒體消息中心，以解決 上述的問題至少之一。根據(jù)本發(fā)明的一個(gè)方面，提供了一種用戶信息的查詢方法。根據(jù)本發(fā)明的用戶信息的查詢方法，應(yīng)用于MMSC，包括當(dāng)用戶信息查詢失敗時(shí)， 業(yè)務(wù)處理模塊確定發(fā)起查詢重試流程，向重試模塊發(fā)送用戶信息的查詢重試消息；重試模 塊將接收到的查詢重試消息中滿足預(yù)定觸發(fā)條件的查詢重試消息發(fā)送至業(yè)務(wù)處理模塊；業(yè) 務(wù)處理模塊重新發(fā)起查詢滿足預(yù)定觸發(fā)條件的查詢重試消息對(duì)應(yīng)的用戶信息的流程。根據(jù)本發(fā)明的另一方面，提供了一種多媒體消息中心。根據(jù)本發(fā)明的多媒體消息中心包括業(yè)務(wù)處理模塊，用于在用戶信息查詢失敗時(shí)， 確定發(fā)起查詢重試流程，向重試模塊發(fā)送用戶信息的查詢重試消息，在接收到查詢重試消 息中滿足預(yù)定觸發(fā)條件的查詢重試消息時(shí)，重新發(fā)起查詢?cè)摬樵冎卦囅?duì)應(yīng)的用戶信息 的流程。重試模塊，用于確定滿足預(yù)定觸發(fā)條件的查詢重試消息，將該查詢重試消息發(fā)送至 業(yè)務(wù)處理模塊。通過本發(fā)明，匪SC查詢用戶信息失敗后，在確定重試查詢的情況下，重新發(fā)起查 詢重試消息中滿足預(yù)定觸發(fā)條件的重試消息對(duì)應(yīng)的用戶信息的流程。解決了相關(guān)技術(shù)中 MMSC下發(fā)多媒體消息的成功率較低的問題，進(jìn)而可以有效提高M(jìn)MSC下發(fā)多媒體消息的成功率，從而提高了用戶體驗(yàn)。


此處所說明的附圖用來提供對(duì)本發(fā)明的進(jìn)一步理解，構(gòu)成本申請(qǐng)的一部分，本發(fā) 明的示意性實(shí)施例及其說明用于解釋本發(fā)明，并不構(gòu)成對(duì)本發(fā)明的不當(dāng)限定。在附圖中圖1是根據(jù)本發(fā)明實(shí)施例的用戶信息的查詢方法的流程圖；圖2是根據(jù)本發(fā)明優(yōu)選實(shí)施例的用戶信息的查詢方法的流程圖；圖3是根據(jù)本發(fā)明實(shí)施例的多媒體消息中心的結(jié)構(gòu)框圖；圖4為根據(jù)本發(fā)明優(yōu)選實(shí)施例的多媒體消息中心的結(jié)構(gòu)框圖。
具體實(shí)施例方式下文中將參考附圖并結(jié)合實(shí)施例來詳細(xì)說明本發(fā)明。需要說明的是，在不沖突的 情況下，本申請(qǐng)中的實(shí)施例及實(shí)施例中的特征可以相互組合。圖1是根據(jù)本發(fā)明實(shí)施例的用戶信息的查詢方法的流程圖。其中，該方法應(yīng)用于 MMSC，如圖1所示，該用戶信息的查詢方法主要包括以下處理步驟S102 當(dāng)用戶信息查詢失敗時(shí)，業(yè)務(wù)處理模塊確定發(fā)起查詢重試流程，向重 試模塊發(fā)送用戶信息的查詢重試消息；步驟S104 重試模塊將接收到的查詢重試消息中滿足預(yù)定觸發(fā)條件的查詢重試 消息發(fā)送至業(yè)務(wù)處理模塊；步驟S106 業(yè)務(wù)處理模塊重新發(fā)起查詢滿足預(yù)定觸發(fā)條件的查詢重試消息對(duì)應(yīng) 的用戶信息的流程。相關(guān)技術(shù)中，當(dāng)多媒體消息中心通過匪5消息接口查詢HLR服務(wù)器失敗時(shí)，多媒體 消息中心無法下發(fā)需要提交的多媒體消息。采用上述方法，可以有效提高M(jìn)MSC下發(fā)多媒體 消息的成功率，從而提高了用戶體驗(yàn)。其中，上述多媒體消息中心可以包括多個(gè)功能模塊業(yè)務(wù)處理模塊、代理模塊、重 試模塊、和業(yè)務(wù)配置模塊等。在優(yōu)選實(shí)施過程中，多媒體消息提交到多媒體彩信中心以后，由多媒體彩信中心 的業(yè)務(wù)處理模塊對(duì)消息進(jìn)行分析，如果終呼用戶是移動(dòng)終端(例如，手機(jī))，則發(fā)起一個(gè)對(duì) 終呼用戶的MM5查詢請(qǐng)求消息(即用戶信息查詢消息)，將該查詢請(qǐng)求消息發(fā)送給代理模 塊。代理模塊收到查詢請(qǐng)求以后，首先根據(jù)多媒體消息業(yè)務(wù)配置模塊上配置的HLR的 信息，得到HLR的網(wǎng)絡(luò)信息，并向HLR建鏈鏈路，如果鏈路成功，則代理模塊將請(qǐng)求消息編 碼，向HLR發(fā)起匪5查詢請(qǐng)求，并且等待HLR響應(yīng)。如果代理模塊接收到HLR服務(wù)器的查詢響應(yīng)，代理模塊將響應(yīng)消息解碼，將查詢 結(jié)果返回給業(yè)務(wù)處理模塊。在業(yè)務(wù)處理模塊接收到匪5查詢響應(yīng)以后，如果成功查詢，則繼續(xù)多媒體消息提 交流程。但是，在以下之一情況下，可能會(huì)導(dǎo)致用戶信息查詢失敗。第一種情況匪SC的代理模塊與保存用戶信息的HLR建鏈?zhǔn)。?br> 第二種情況HLR返回響應(yīng)超時(shí)；第三種情況HLR查詢用戶信息錯(cuò)誤。優(yōu)選地，在步驟S102中，業(yè)務(wù)處理模塊確定發(fā)起查詢重試流程可以包括以下處 理(1)業(yè)務(wù)處理模塊接收來自于代理模塊的狀態(tài)碼，其中，狀態(tài)碼用于反映與查詢失 敗對(duì)應(yīng)的上述情況；(2)業(yè)務(wù)處理模塊根據(jù)狀態(tài)碼確定是否需要發(fā)起查詢重試流程。在優(yōu)選實(shí)施過程中，如果用戶信息查詢失敗，則代理模塊會(huì)返回給業(yè)務(wù)處理模塊 查詢的狀態(tài)碼，每種狀態(tài)碼表示一種錯(cuò)誤情況，例如，與HLR服務(wù)器建鏈?zhǔn)″e(cuò)誤，HLR返回 響應(yīng)超時(shí)錯(cuò)誤，HLR查詢終端手機(jī)號(hào)碼錯(cuò)誤等多重錯(cuò)誤類型，每種錯(cuò)誤都有指定的錯(cuò)誤碼， 但是這些錯(cuò)誤狀態(tài)并不是每種都需要重試的，這里就需要配置需要重試的狀態(tài)碼。當(dāng)某種 狀態(tài)碼被配置，當(dāng)業(yè)務(wù)處理模塊接收到該狀態(tài)碼時(shí)就會(huì)發(fā)起MM5重試請(qǐng)求。在上述第一種情況下，即代理模塊與HLR建立鏈路失敗，則代理模塊向業(yè)務(wù)處理 模塊返回錯(cuò)誤。如果業(yè)務(wù)處理模塊收到代理模塊的建鏈?zhǔn)№憫?yīng)，則業(yè)務(wù)處理模塊根據(jù) MMSC的業(yè)務(wù)配置模塊中配置決定這種情況是否進(jìn)行重試，如果需要重試，則向重試模塊發(fā) 送查詢重試請(qǐng)求，重試模塊根據(jù)業(yè)務(wù)配置模塊的配置信息建立重試控制信息。如果代理模塊成功發(fā)送MM5查詢消息，但是如果在系統(tǒng)設(shè)置時(shí)間內(nèi)沒有收到HLR 返回的響應(yīng)，則代理模塊返回給業(yè)務(wù)處理模塊失敗響應(yīng)，業(yè)務(wù)處理模塊接收到響應(yīng)后，根據(jù) 配置信息確定是否進(jìn)行重試，如果需要重試則進(jìn)入重試流程。如果代理模塊接收到HLR的 查詢響應(yīng)，代理模塊將響應(yīng)消息解碼，將查詢結(jié)果返回給業(yè)務(wù)處理模塊。業(yè)務(wù)處理模塊接收到匪5查詢響應(yīng)以后，如果成功查詢，則繼續(xù)多媒體消息提交 流程；如果查詢用戶信息錯(cuò)誤，則根據(jù)狀態(tài)碼判斷是否需要進(jìn)行重試，如果需要重試則進(jìn)入 重試流程。優(yōu)選地，上述步驟S104中的預(yù)定觸發(fā)條件包括以下之一(1)接收到來自于HLR的表示終端處于激活狀態(tài)的通知消息，其中，該消息和滿足 預(yù)定觸發(fā)條件的查詢重試消息攜帶的終端標(biāo)識(shí)一致；(2)接收到來自于匪SC的業(yè)務(wù)配置模塊的重試定時(shí)消息，其中，該消息和滿足預(yù) 定觸發(fā)條件的查詢重試消息攜帶的終端標(biāo)識(shí)一致。在優(yōu)選實(shí)施過程中，當(dāng)重試模塊建立了 MM5重試機(jī)制后，可以通過兩種觸發(fā)方式 發(fā)起重試請(qǐng)求，第一種觸發(fā)方式是HLR主動(dòng)發(fā)起的匪5Alert消息(即上述通知消息)，該 消息表示用戶處于激活狀態(tài)，當(dāng)重試模塊收到該消息以后，則立即發(fā)起重啟請(qǐng)求；第二種方 式是根據(jù)在業(yè)務(wù)配置模塊中配置的重試策略進(jìn)行重試。例如，每隔五分鐘重試一次，在預(yù) 定時(shí)間到達(dá)時(shí)，向MMSC的業(yè)務(wù)配置模塊發(fā)送重試定時(shí)消息，觸發(fā)重試流程。業(yè)務(wù)處理模塊接收到上述通知消息或重試定時(shí)消息以后，重新進(jìn)行匪5查詢，并 且將查詢結(jié)果通知給多媒體消息重試模塊，多媒體消息業(yè)務(wù)處理模塊收到重試消息以后， 重新發(fā)起MM5查詢請(qǐng)求，并且按照上述步驟決定后續(xù)流程。優(yōu)選地，在重試模塊將滿足預(yù)定觸發(fā)條件的查詢重試消息發(fā)送至業(yè)務(wù)處理模塊 時(shí)，還可以包括以下處理重試模塊在查詢重試消息中刪除滿足預(yù)定觸發(fā)條件的查詢重試 消息。
通過上述處理，重試模塊只會(huì)被通知消息和重試消息隊(duì)列的重試定時(shí)消息中的一 個(gè)消息觸發(fā)。例如，重試模塊首先接收到重試定時(shí)消息，則重試模塊將該條重試消息發(fā)送給 業(yè)務(wù)處理模塊，并且將該條消息從重試隊(duì)列中刪除，這樣就可以保證接收到通知消息后不 會(huì)被重復(fù)觸發(fā)。優(yōu)選地，上述方法還可以包括以下處理重試模塊判斷當(dāng)前重試次數(shù)是否達(dá)到 MMSC的業(yè)務(wù)配置模塊中配置的最大次數(shù)；如果是，結(jié)束用戶信息查詢流程。在優(yōu)選實(shí)施過程中，如果當(dāng)前重試次數(shù)達(dá)到了業(yè)務(wù)配置模塊中配置的最大次數(shù)， 此時(shí)還沒有成功查詢用戶信息，則MMSC下發(fā)多媒體消息失敗。通過該處理，可以有效避免 MMSC不間斷查詢用戶信息，從而節(jié)省了系統(tǒng)資源。以下結(jié)合圖2描述上述優(yōu)選實(shí)施方式。圖2是根據(jù)本發(fā)明優(yōu)選實(shí)施例的用戶信息的查詢方法的流程示意圖。以下結(jié)合圖 2描述上述用戶信息的查詢方法，該方法主要包括以下步驟步驟1 在業(yè)務(wù)配置模塊中配置MM5查詢失敗重試信息，其中，該信息主要包含(1)重試狀態(tài)碼如果匪5查詢失敗，則代理模塊(MM5Agent)會(huì)返回給業(yè)務(wù)處理 模塊(MMS Relay)查詢的狀態(tài)碼，每種狀態(tài)碼表示一種錯(cuò)誤狀態(tài)，例如，代理模塊與HLR建 鏈?zhǔn)″e(cuò)誤，HLR返回響應(yīng)超時(shí)錯(cuò)誤，HLR查詢終端手機(jī)號(hào)碼錯(cuò)誤等多重錯(cuò)誤類型，每種錯(cuò) 誤都有指定的狀態(tài)碼，但是這些錯(cuò)誤狀態(tài)并不是每種都需要重試的，這里就需要配置需要 重試的狀態(tài)碼。當(dāng)某種狀態(tài)碼被配置，當(dāng)MMS Relay接收到該狀態(tài)碼時(shí)就會(huì)發(fā)起MM5重試 請(qǐng)求。(2)MM5重試機(jī)制(策略)此處包含重試次數(shù)和每次重試之間的時(shí)間間隔。重試 次數(shù)表示失敗重試的總體次數(shù)，如果重試次數(shù)大于該設(shè)置值，則表示最終重試失敗；重試時(shí) 間表示每次重試之間的時(shí)間間隔，重試時(shí)間和次數(shù)可以任意組合，比如重試三次，每次重視 間隔五分鐘，這只重試兩次，第一次重試為五分鐘，第二次重試為十分鐘。(3)外部觸發(fā)匪5重試事件配置2中，配置的是重試模塊主動(dòng)發(fā)起重試的策略， 但是還有一些重試是由外部服務(wù)器觸發(fā)的，例如，上述HLR服務(wù)器主動(dòng)發(fā)起的MM5A1 ert消 息，如果多媒體消息業(yè)務(wù)配置模塊中配置該類配置，則當(dāng)MMS Relay收到該類消息，則發(fā)起 消息主動(dòng)觸發(fā)MM5重試流程。步驟2 其他彩信平臺(tái)向MMS Relay發(fā)送多媒體消息提交請(qǐng)求，MMS Relay對(duì)其他 彩信平臺(tái)回復(fù)彩信提交響應(yīng)。MMS Relay接收到多媒體消息以后，通過業(yè)務(wù)分析，發(fā)現(xiàn)終呼 用戶為手機(jī)終端，需要查詢HLR，則發(fā)起匪5查詢請(qǐng)求，將消息發(fā)送給匪5Agent模塊。步驟3 :MM5Agent接收到查詢消息以后，首先讀取業(yè)務(wù)配置模塊中配置的HLR的網(wǎng) 絡(luò)信息，向HLR服務(wù)器建立通訊鏈路，如果建立鏈路失敗，則返回指定的狀態(tài)碼，MMS Relay 模塊查詢業(yè)務(wù)配置模塊的配置信息中該狀態(tài)碼是否需要重試，如果需要，則發(fā)送重試消息 給重試模塊，執(zhí)行步驟S208，如果不需要，則下發(fā)多媒體消息失敗。如果建立鏈路成功，執(zhí)行 步驟S210。步驟4:重試模塊接收到重試消息以后，首先讀取業(yè)務(wù)配置模塊中配置的重試機(jī) 制，如果該狀態(tài)碼配置了重試機(jī)制，則根據(jù)重試機(jī)制中配置的第一次重試時(shí)間，將重試消息 插入定時(shí)重試隊(duì)列中，重試消息觸發(fā)的時(shí)間就是配置中的第一次重試時(shí)間。并且保存查詢 消息中的需要查詢的終端號(hào)碼，然后重試模塊進(jìn)入等待模式，等待MM5定時(shí)重試隊(duì)列的觸發(fā)。步驟5 當(dāng)步驟S206中匪5Agent和HLR建鏈成功，則將查詢消息編碼，發(fā)送給HLR 服務(wù)器。步驟6 匪5Agent在規(guī)定時(shí)間內(nèi)未收到HLR服務(wù)器的查詢響應(yīng)，則返回給匪S Relay失敗消息和指定狀態(tài)碼，MMS Relay接收到響應(yīng)消息后，查詢配置信息中該狀態(tài)碼是 否需要重試，如果需要，則發(fā)送重試消息給MM5重試模塊，如果不需要，則多媒體消息失敗。 然后重復(fù)步驟S208操作。步驟7 匪5Agent模塊接收到HLR服務(wù)器返回響應(yīng)以后，將消息返回給匪S Relay 模塊。如果MM5查詢成功則繼續(xù)多媒體消息提交流程，如果查詢失敗，MMS Relay模塊查詢 配置信息中該狀態(tài)碼是否需要重試，如果需要，則發(fā)送重試消息給MM5重試模塊，如果不需 要，則多媒體消息下發(fā)失敗。然后重復(fù)步驟S208操作。步驟8 當(dāng)匪5查詢進(jìn)入重試流程以后，匪5重試模塊進(jìn)入等待模式，如果業(yè)務(wù)配 置模塊中配置了匪5Alert消息觸發(fā)重試機(jī)制，則匪5重試模塊等待兩種觸發(fā)消息，一種是 匪5Alert消息，一種是匪5重試定時(shí)消息，當(dāng)匪5重試模塊接收到任何一種重試消息以后， 則丟棄另外一種觸發(fā)消息。步驟9 如果匪5重試模塊首先接收到HLR的匪5Alert消息以后，匪5重試被 匪5Alert消息觸發(fā)，MM5重試模塊在重試消息隊(duì)列中查詢到所有與MM5Alert消息中攜帶終 端號(hào)碼相同的重試消息，并且將該消息向MMS Relay發(fā)送，并且刪除重試隊(duì)列中該條重試消 息。即在這種情況下MM5重試只被匪5Alert消息觸發(fā)，不會(huì)在被重試消息隊(duì)列的定時(shí)消息 觸發(fā)。如果MM5重試模塊首先收到MM5重試定時(shí)消息，則MM5重試模塊將該條重試消息發(fā) 送給匪S Relay，并且將該條消息從重試隊(duì)列中刪除，這樣就可以保證收到MM5Alert消息 后不會(huì)被重復(fù)觸發(fā)。步驟10 匪S Relay模塊接收到重試消息以后，重新發(fā)起匪5查詢消息，返回執(zhí)行 步驟S206。步驟11 如果MM5重試次數(shù)最終達(dá)到多媒體消息業(yè)務(wù)配置中最大配置時(shí)，MM5查詢 還未成功，則多媒體消息提交失敗，結(jié)束流程。圖3是根據(jù)本發(fā)明實(shí)施例的多媒體消息中心的結(jié)構(gòu)框圖。如圖3所示，該多媒體 消息包括業(yè)務(wù)處理模塊30和重試模塊32。業(yè)務(wù)處理模塊30，用于在用戶信息查詢失敗時(shí)，確定發(fā)起查詢重試流程，向重試模 塊發(fā)送用戶信息的查詢重試消息，在接收到查詢重試消息中滿足預(yù)定觸發(fā)條件的查詢重試 消息時(shí)，重新發(fā)起查詢?cè)摬樵冎卦囅?duì)應(yīng)的用戶信息的流程。重試模塊32，用于確定上述滿足預(yù)定觸發(fā)條件的查詢重試消息，將該查詢重試消 息發(fā)送至業(yè)務(wù)處理模塊。上述MMSC中，業(yè)務(wù)處理模塊30對(duì)重試模塊32確定的滿足預(yù)定觸發(fā)條件的查詢重 試消息重新發(fā)起用戶信息查詢流程?？梢杂行岣進(jìn)MSC下發(fā)多媒體消息的成功率，從而提 高了用戶體驗(yàn)。優(yōu)選地，如圖4所示，上述MMSC還可以包括代理模塊34，用于向業(yè)務(wù)處理模塊返 回狀態(tài)碼，其中，該狀態(tài)碼用于反映與查詢失敗對(duì)應(yīng)的情況，情況包括以下之一代理模塊 與保存用戶信息的HLR建鏈?zhǔn)?、HLR返回響應(yīng)超時(shí)、HLR查詢用戶信息錯(cuò)誤；則業(yè)務(wù)處理模塊30，還用于接收來自于代理模塊的狀態(tài)碼，根據(jù)狀態(tài)碼確定是否需要發(fā)起查詢重試流 程。優(yōu)選地，如圖4所示，上述匪SC還可以包括業(yè)務(wù)配置模塊36，用于向重試模塊32 發(fā)送重試定時(shí)消息；則重試模塊32，還用于在來自于HLR的表示終端處于激活狀態(tài)的通知 消息或重試定時(shí)消息與滿足預(yù)定觸發(fā)條件的查詢重試消息攜帶的終端標(biāo)識(shí)一致時(shí)，確定發(fā) 送滿足預(yù)定觸發(fā)條件的查詢重試消息。優(yōu)選地，如圖4所示，重試模塊32，還用于在判斷當(dāng)前重試次數(shù)達(dá)到業(yè)務(wù)配置模塊 中配置的最大次數(shù)時(shí)，結(jié)束用戶信息查詢流程。優(yōu)選地，如圖4所示，重試模塊32，還用于在向業(yè)務(wù)處理模塊發(fā)送滿足預(yù)定觸發(fā)條 件的查詢重試消息時(shí)，從查詢重試消息中刪除滿足預(yù)定觸發(fā)條件的查詢重試消息。下面描述上述各模塊相互結(jié)合的優(yōu)選實(shí)施方式。多媒體消息提交到多媒體彩信中心以后，由業(yè)務(wù)處理模塊30對(duì)消息進(jìn)行分析，如 果終呼用戶是手機(jī)終端，則發(fā)起一個(gè)對(duì)終呼用戶的匪5查詢請(qǐng)求消息，將該消息發(fā)送給代 理模塊。代理模塊34接收到查詢請(qǐng)求以后，首先根據(jù)業(yè)務(wù)配置模塊36上配置的HLR的信 息，得到HLR的網(wǎng)絡(luò)信息，并向HLR建立鏈路請(qǐng)求，如果建立鏈路成功，則代理模塊34將請(qǐng) 求消息編碼，向HLR發(fā)起MM5查詢請(qǐng)求，并且等待HLR響應(yīng)；如果HLR鏈路建立失敗，則向業(yè) 務(wù)處理模塊30返回錯(cuò)誤。如果業(yè)務(wù)處理模塊30接收到代理模塊的建鏈?zhǔn)№憫?yīng)，則業(yè)務(wù)處理模塊根據(jù)業(yè) 務(wù)配置模塊36中的配置決定這種情況是否進(jìn)行重試，如果需要重試，則向重試模塊32發(fā)送 MM5重試請(qǐng)求，重試模塊32根據(jù)配置建立重試控制信息。如果代理模塊34成功發(fā)送匪5查詢消息，但是如果在系統(tǒng)設(shè)置時(shí)間內(nèi)沒有收到 HLR響應(yīng)，則代理模塊34返回給業(yè)務(wù)處理模塊30失敗響應(yīng)，業(yè)務(wù)處理模塊30接收到響應(yīng) 后，根據(jù)配置決定是否進(jìn)行重試，如果需要重試則進(jìn)入重試流程。如果代理模塊接收到HLR 服務(wù)器的查詢響應(yīng)，代理模塊將響應(yīng)消息解碼，將查詢結(jié)果返回給業(yè)務(wù)處理模塊。業(yè)務(wù)處理模塊30接收到MM5查詢響應(yīng)以后，如果成功查詢，則繼續(xù)多媒體消息提 交流程；如果查詢失敗，則根據(jù)狀態(tài)碼判斷是否需要進(jìn)行重試，如果需要重試則進(jìn)入重試流 程。當(dāng)重試模塊32建立了 MM5重試機(jī)制后，可以根據(jù)兩種重試方式發(fā)起重試請(qǐng)求，第 一種方式是HLR主動(dòng)發(fā)起的MM5Alert消息，該種消息表示用戶處于激活狀態(tài)，當(dāng)重試模塊 接收到該消息以后，則立即發(fā)起重啟請(qǐng)求；第二種方式是根據(jù)在業(yè)務(wù)配置模塊中配置的重 試策略進(jìn)行重試。業(yè)務(wù)處理模塊30接收到MM5查詢重試請(qǐng)求以后，重新進(jìn)行MM5查詢，并且將查詢 結(jié)果通知給重試模塊，業(yè)務(wù)處理模塊30接收到重試消息以后，重新發(fā)起MM5查詢請(qǐng)求，并且 按照上述步驟決定后續(xù)流程。如果在業(yè)務(wù)配置模塊36配置的匪5重試策略規(guī)定內(nèi)，還是沒有匪5重試查詢成 功，則多媒體消息提交失敗。綜上所述，多媒體消息中心進(jìn)行用戶信息查詢失敗以后，根據(jù)返回失敗狀態(tài)，決定 是否進(jìn)行MM5重試查詢，如果需要重試查詢，則根據(jù)多媒體消息中心的控制信息進(jìn)行MM5查詢重試，直到成功或者最終查詢失敗。借助本發(fā)明提供的上述實(shí)施例，可以有效提高M(jìn)MSC 下發(fā)多媒體消息的成功率，從而大大提高了用戶體驗(yàn)。顯然，本領(lǐng)域的技術(shù)人員應(yīng)該明白，上述的本發(fā)明的各模塊或各步驟可以用通用 的計(jì)算裝置來實(shí)現(xiàn)，它們可以集中在單個(gè)的計(jì)算裝置上，或者分布在多個(gè)計(jì)算裝置所組成 的網(wǎng)絡(luò)上，可選地，它們可以用計(jì)算裝置可執(zhí)行的程序代碼來實(shí)現(xiàn)，從而，可以將它們存儲(chǔ) 在存儲(chǔ)裝置中由計(jì)算裝置來執(zhí)行，并且在某些情況下，可以以不同于此處的順序執(zhí)行所示 出或描述的步驟，或者將它們分別制作成各個(gè)集成電路模塊，或者將它們中的多個(gè)模塊或 步驟制作成單個(gè)集成電路模塊來實(shí)現(xiàn)。這樣，本發(fā)明不限制于任何特定的硬件和軟件結(jié)合。以上所述僅為本發(fā)明的優(yōu)選實(shí)施例而已，并不用于限制本發(fā)明，對(duì)于本領(lǐng)域的技 術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何 修改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
一種用戶信息的查詢方法，應(yīng)用于多媒體消息中心MMSC，其特征在于，所述MMSC包括業(yè)務(wù)處理模塊和重試模塊，所述方法包括當(dāng)用戶信息查詢失敗時(shí)，所述業(yè)務(wù)處理模塊確定發(fā)起查詢重試流程，向所述重試模塊發(fā)送用戶信息的查詢重試消息；所述重試模塊將接收到的所述查詢重試消息中滿足預(yù)定觸發(fā)條件的查詢重試消息發(fā)送至所述業(yè)務(wù)處理模塊；所述業(yè)務(wù)處理模塊重新發(fā)起查詢所述滿足預(yù)定觸發(fā)條件的查詢重試消息對(duì)應(yīng)的用戶信息的流程。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，在以下之一情況下，所述用戶信息查詢失敗所述MMSC的代理模塊與保存所述用戶信息的HLR建鏈?zhǔn)。?所述HLR返回響應(yīng)超時(shí)； 所述HLR查詢所述用戶信息錯(cuò)誤。
3.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述業(yè)務(wù)處理模塊確定發(fā)起查詢重試流 程包括所述業(yè)務(wù)處理模塊接收來自于所述代理模塊的狀態(tài)碼，其中，所述狀態(tài)碼用于反映與 查詢失敗對(duì)應(yīng)的所述情況；所述業(yè)務(wù)處理模塊根據(jù)所述狀態(tài)碼確定是否需要發(fā)起查詢重試流程。
4.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述預(yù)定觸發(fā)條件包括以下之一接收到來自于所述HLR的表示終端處于激活狀態(tài)的通知消息，其中，該消息和所述滿 足預(yù)定觸發(fā)條件的查詢重試消息攜帶的終端標(biāo)識(shí)一致；接收到來自于所述MMSC的業(yè)務(wù)配置模塊的重試定時(shí)消息，其中，該消息和所述滿足預(yù) 定觸發(fā)條件的查詢重試消息攜帶的終端標(biāo)識(shí)一致。
5.根據(jù)權(quán)利要求1所述的方法，其特征在于，在所述重試模塊將所述滿足預(yù)定觸發(fā)條 件的查詢重試消息發(fā)送至所述業(yè)務(wù)處理模塊時(shí)，所述方法還包括所述重試模塊在所述查 詢重試消息中刪除所述滿足預(yù)定觸發(fā)條件的查詢重試消息。
6.根據(jù)權(quán)利要求1至5中任一項(xiàng)所述的方法，其特征在于，所述方法還包括所述重試模塊判斷當(dāng)前重試次數(shù)是否達(dá)到所述MMSC的業(yè)務(wù)配置模塊中配置的最大次數(shù)；如果是，結(jié)束用戶信息查詢流程。
7.一種多媒體消息中心匪SC，其特征在于，包括業(yè)務(wù)處理模塊，用于在用戶信息查詢失敗時(shí)，確定發(fā)起查詢重試流程，向重試模塊發(fā)送 用戶信息的查詢重試消息，在接收到所述查詢重試消息中滿足預(yù)定觸發(fā)條件的查詢重試消 息時(shí)，重新發(fā)起查詢?cè)摬樵冎卦囅?duì)應(yīng)的用戶信息的流程。所述重試模塊，用于確定所述滿足預(yù)定觸發(fā)條件的查詢重試消息，將該查詢重試消息 發(fā)送至所述業(yè)務(wù)處理模塊。
8.根據(jù)權(quán)利要求7所述的MMSC，其特征在于，所述MMSC還包括代理模塊，用于向所述業(yè)務(wù)處理模塊返回狀態(tài)碼，其中，所述狀態(tài)碼 用于反映與查詢失敗對(duì)應(yīng)的情況，所述情況包括以下之一所述代理模塊與保存所述用戶信息的HLR建鏈?zhǔn)?、所述HLR返回響應(yīng)超時(shí)、所述HLR查詢所述用戶信息錯(cuò)誤；所述業(yè)務(wù)處理模塊，還用于接收來自于所述代理模塊的所述狀態(tài)碼，根據(jù)所述狀態(tài)碼 確定是否需要發(fā)起查詢重試流程。
9.根據(jù)權(quán)利要求7所述的MMSC，其特征在于，所述MMSC還包括業(yè)務(wù)配置模塊，用于向所述重試模塊發(fā)送重試定時(shí)消息；所述重試模塊，還用于在來自于所述HLR的表示終端處于激活狀態(tài)的通知消息或所述 重試定時(shí)消息與所述滿足預(yù)定觸發(fā)條件的查詢重試消息攜帶的終端標(biāo)識(shí)一致時(shí)，確定發(fā)送 所述滿足預(yù)定觸發(fā)條件的查詢重試消息。
10.根據(jù)權(quán)利要求9所述的多媒體消息中心匪SC，其特征在于，所述重試模塊，還用 于在判斷當(dāng)前重試次數(shù)達(dá)到所述業(yè)務(wù)配置模塊中配置的最大次數(shù)時(shí)，結(jié)束用戶信息查詢流 程。
11.根據(jù)權(quán)利要求7所述的MMSC，其特征在于，所述重試模塊，還用于在向所述業(yè)務(wù)處 理模塊發(fā)送所述滿足預(yù)定觸發(fā)條件的查詢重試消息時(shí)，從所述查詢重試消息中刪除所述滿 足預(yù)定觸發(fā)條件的查詢重試消息。
全文摘要
本發(fā)明公開了一種用戶信息的查詢方法及多媒體消息中心。上述多媒體消息中心包括業(yè)務(wù)處理模塊和重試模塊，上述方法包括當(dāng)用戶信息查詢失敗時(shí)，業(yè)務(wù)處理模塊確定發(fā)起查詢重試流程，向重試模塊發(fā)送用戶信息的查詢重試消息；重試模塊將接收到的查詢重試消息中滿足預(yù)定觸發(fā)條件的查詢重試消息發(fā)送至業(yè)務(wù)處理模塊；業(yè)務(wù)處理模塊重新發(fā)起查詢滿足預(yù)定觸發(fā)條件的查詢重試消息對(duì)應(yīng)的用戶信息的流程。根據(jù)本發(fā)明提供的技術(shù)方案，可以有效提高M(jìn)MSC下發(fā)多媒體消息的成功率，從而提高了用戶體驗(yàn)。
文檔編號(hào)H04W4/12GK101909256SQ20101026282
公開日2010年12月8日 申請(qǐng)日期2010年8月19日 優(yōu)先權(quán)日2010年8月19日
發(fā)明者張劍 申請(qǐng)人:中興通訊股份有限公司