專利名稱：：一種終端中彩信中心地址設(shè)置錯(cuò)誤的檢測方法
技術(shù)領(lǐng)域：
：本發(fā)明涉及GN接口信令檢測技術(shù)，尤其涉及一種終端中彩信中心地址設(shè)置錯(cuò)誤的檢測方法。
背景技術(shù)：
：隨著通信技術(shù)的高速發(fā)展，移動(dòng)終端如手機(jī)在人們的日常生活中占據(jù)越來越重要的位置，手機(jī)中所集成的功能也越來越多。目前，通過手機(jī)之間發(fā)送彩信進(jìn)行溝通，已成為用戶間溝通的一種重要手段。用戶使用手機(jī)發(fā)送彩信時(shí)，需要在手機(jī)上設(shè)置正確的彩信中心地址，例如，i史置為http:〃mmsc.monternet.com、或者h(yuǎn)ttp:〃mmsc.myuni.com.cn等。當(dāng)彩信中心地址設(shè)置錯(cuò)誤時(shí)，手機(jī)將無法正常進(jìn)行彩信的發(fā)送和接收。而在網(wǎng)絡(luò)運(yùn)營商一側(cè)的網(wǎng)際協(xié)議(IP,InternetProtocol)信令監(jiān)測系統(tǒng)，一般采用IP采集機(jī)的方式從GN接口的IP信令鏈路上釆集信令數(shù)據(jù)，并對(duì)信令數(shù)據(jù)進(jìn)行整理、分析和統(tǒng)計(jì)，據(jù)此詳細(xì)了解全網(wǎng)的各種上網(wǎng)和收發(fā)彩信過程，并進(jìn)行深層次的網(wǎng)絡(luò)管理、業(yè)務(wù)管理、用戶管理以及網(wǎng)絡(luò)優(yōu)化、網(wǎng)絡(luò)規(guī)劃、網(wǎng)絡(luò)設(shè)計(jì)。上述過程中，對(duì)采集到的信令數(shù)據(jù)通常會(huì)按照一定規(guī)則生成事件詳細(xì)記錄(TDR，TransactionDetailRecord),這個(gè)生成TDR的過程又稱為事件合成，事件合成產(chǎn)生的事件，為信令監(jiān)測系統(tǒng)提供了最基礎(chǔ)的原始數(shù)據(jù)，因此，事件合成是整個(gè)信令監(jiān)測系統(tǒng)進(jìn)行后續(xù)數(shù)據(jù)分析的基礎(chǔ)。如圖1所示，事件合成方法包括如下步驟步驟101:對(duì)GN接口IP信令數(shù)據(jù)進(jìn)行采集。其中，對(duì)于信令數(shù)據(jù)的采集一直持續(xù)進(jìn)行，具體如何進(jìn)行所述數(shù)據(jù)的釆集屬于公知技術(shù)，這里不再贅述。步驟102:讀取所釆集的一條信令，判定該信令在IP層之上是否采用了用戶數(shù)據(jù)報(bào)協(xié)議(UDP,UserDatagramProtocol)、且UDP協(xié)議的端口是否為2152或2123，如果是，則把所述信令數(shù)據(jù)放進(jìn)GN事件合成的處理流程中，執(zhí)行步驟103;否則，丟棄當(dāng)前信令，繼續(xù)讀取采集的下一條信令進(jìn)行本步驟中所述的判定。步驟103:根據(jù)信令的消息類型提取相應(yīng)的特征值，并根據(jù)特征值的組成，建立或填充GNTDR。其中，GN接口的信令可以分為以下消息類型建立分組數(shù)據(jù)協(xié)議上下文請求(CreatePDPContextRequest)、建立分組數(shù)據(jù)協(xié)議上下文回復(fù)(CreatePDPContextResponse)、刪除分組數(shù)據(jù)協(xié)議上下文請求(DeletePDPContextRequest)、刪除分組數(shù)據(jù)協(xié)議上下文回復(fù)(DeletePDPContextResponse)、隧道分組數(shù)據(jù)單元(T-PDU)等；而T-PDU中又包含無線應(yīng)用協(xié)議(WAP,WirelessApplicationProtocol)、超文本4專lii辦i義(HTTP,HypertextTransferProtocol)、多媒體消息服務(wù)環(huán)境(MMSE,MultimediaMessagingServiceEnvironment)等消息類型。WAP又進(jìn)一步包括為無線傳輸協(xié)議(WTP,WirelessTransactionProtocol)和無線會(huì)話協(xié)議(WSP，WirelessSessionProtocol),其中WTP為底層，WSP為上層。如果步驟102中讀取的所述信令是CreatePDPContextR叫uest,則進(jìn)入建立狀態(tài)，根據(jù)SGSN用于數(shù)據(jù)的IP地址(SGSNAddressforusertraffic)、數(shù)據(jù)隧道端點(diǎn)標(biāo)識(shí)(TEIDDATA，TunnelEndpointIdentifierdata)合成特征值1,根據(jù)SGSN用于信令的IP地址(SGSNAddressforsignaling)、控制隧道端點(diǎn)標(biāo)識(shí)(TEIDCONTROLPLANE,TunnelEndpointIdentifiercontrolplane)合成特征值2,建立一個(gè)GNTDR，將信令中GNTDR所需要的信息存入GNTDR中，之后，執(zhí)行步驟102。所述GNTDR所需要的信息包括用戶的移動(dòng)臺(tái)ISDN號(hào)碼(MSISDN,MobileStationISDNNumber)等。如杲信令是CreatePDPContextResponse,根據(jù)目的IP、隧道端點(diǎn)標(biāo)識(shí)符(TEID)合成特征值，根據(jù)特征值查找GNTDR,如果能找到，將信令中GNTDR所需要的信息存入GNTDR,并根據(jù)GGSN用于數(shù)據(jù)的IP地址(GGSNAddressforusertraffic),TEIDDATA合成特征值1,根據(jù)SGSN用于信令的IP地址(GGSNAddressforsignaling)、TEIDCONTROLPLANE合成特征值2,把特征值1和特征值2添加為GNTDR的特征值；之后，執(zhí)行步驟102。在這種情況下，包括GNTDR建立時(shí)所加入的兩個(gè)特征值，GNTDR中將擁有四個(gè)特征值。信令中所述GNTDR所需要的信息包括彩信的發(fā)送號(hào)碼、接收號(hào)碼、發(fā)送時(shí)間等信息。如果信令是DeletePDPContextRequest,根據(jù)源IP、TEID合成特征值1，目的IP、TEID合成特征值2，根據(jù)特征值查找GN的TDR事件，只要其中一個(gè)特征值能找到GN的TDR，填充GNTDR;之后，返回步驟102。如果信令是DeletePDPContextResponse,根據(jù)源IP、TEID合成特征值l，目的IP、TEID合成特征值2，根據(jù)特征值查找GNTDR,只要其中一個(gè)特征值能找到GNTDR,則關(guān)閉GNTDR，如果未找到GNTDR,則丟棄該信令；之后，返回步驟102。如果信令是T-PDU,根據(jù)目的IP、TEID合成特征值，根據(jù)特征值查找GNTDR，如果找到GNTDR，則記錄該信令，否則，丟棄該信令；之后，執(zhí)行步驟102。由以上對(duì)于五種不同消息類型的處理方法的描述可知，事件合成包括三個(gè)狀態(tài)，分別為建立GNTDR、填充GNTDR、以及GNTDR填充結(jié)束并發(fā)送。另外，具體如何進(jìn)行所述特征值的合成、如何根據(jù)特征值建立、或查找GNTDR均屬于公知技術(shù)，這里不再贅述。以上所述為IP信令監(jiān)測系統(tǒng)中的事件合成方法。目前，由于手機(jī)上彩信中心地址錯(cuò)誤造成的事件合成后事件結(jié)果為失敗的情況越來越多，但是，目前尚沒有通過GN接口檢測手機(jī)上彩信中心地址設(shè)置錯(cuò)誤的方法公開。
發(fā)明內(nèi)容有鑒于此，本發(fā)明的主要目的在于提供一種終端中彩信中心地址設(shè)置錯(cuò)誤的檢測方法，能夠通過GN接口檢測各終端中彩信中心地址設(shè)置是否錯(cuò)誤。為達(dá)到上述目的，本發(fā)明的技術(shù)方案是這樣實(shí)現(xiàn)的本發(fā)明提供了一種終端中彩信中心地址設(shè)置錯(cuò)誤的檢測方法，該方法包括確定接收到的信令為隧道分組數(shù)據(jù)單元T-PDU類型，且確定GI事件詳細(xì)記錄GITDR填充結(jié)束后，根據(jù)信令對(duì)應(yīng)的多媒體消息服務(wù)環(huán)境MMSE消息類型、查詢到的事件結(jié)果、以及獲取到的用戶設(shè)置的彩信中心地址，比較并確定當(dāng)前接收到的信令對(duì)應(yīng)的終端的彩信中心地址是否設(shè)置錯(cuò)誤。其中，該方法進(jìn)一步包括在比較終端的彩信中心地址之前，設(shè)置正確的彩信中心地址。所述確定信令對(duì)應(yīng)終端的彩信中心地址是否設(shè)置錯(cuò)誤具體為當(dāng)該信令為MMSE中的彩信發(fā)送消息、事件結(jié)果為失敗、且獲取的所述彩信中心地址與所設(shè)置的正確的彩信中心地址不相符時(shí)，確定該信令對(duì)應(yīng)終端的彩信中心地址設(shè)置錯(cuò)誤。確定接收到的信令為T-PDU之前，該方法進(jìn)一步包括對(duì)GN接口網(wǎng)際協(xié)議IP信令數(shù)據(jù)進(jìn)行采集；讀取所采集的一條信令，確定該信令的IP層之上采用了用戶數(shù)據(jù)報(bào)協(xié)議UDP、且UDP的端口為2152、或2123時(shí)，如果信令的消息類型為T-PDU以外的其他消息類型時(shí)，提取相應(yīng)的特征值，根據(jù)所述特征值的組成，生成或填充GNTDR,之后，返回讀耳又并處理所述信令的下一條信令；如果信令的消息類型為T-PDU時(shí)，根據(jù)相應(yīng)的特征值查找得到GNTDR。確定接收到的信令為T-PDU，與確定GITDR填充結(jié)束之間，該方法進(jìn)一步包括確定所述信令為T-PDU類型中的無線應(yīng)用協(xié)議WAP類型時(shí)，確定該信令在無線傳輸協(xié)議WTP層、和無線會(huì)話協(xié)議WSP層的消息類型，如果所述信令7在WTP層的消息類型為Invoke、WSP層的消息類型為POST時(shí)，根據(jù)特征值建立GITDR,并從GNTDR得到移動(dòng)臺(tái)ISDN號(hào)MSISDN填充到GITDR中，之后，返回讀取并處理所述信令的下一條信令；如果所述信令在WTP層的消息類型為SegmentedInvoke時(shí)，根據(jù)特征值查找GITDR，并將信令中的相關(guān)信息填充到GITDR中，之后，返回讀取并處理所述信令的下一條信令；如果所述信令在WTP層的消息類型為Result,WSP層的消息類型為Reply,關(guān)閉GITDR,確定GITDR填充結(jié)束。所述確定接收到的信令為T-PDU類型，與所述確定GITDR填充結(jié)束之間，該方法進(jìn)一步包括確定所述信令為T-PDU類型中的超文本傳輸協(xié)議HTTP類型時(shí)，確定該信令在HTTP中的消息類型，如果所述信令為POST時(shí)，根據(jù)特征值建立GITDR,并從GNTDR得到信令對(duì)應(yīng)終端的MSISDN填充到GITDR中，之后，返回讀取并處理所述信令的下一條信令；如果所述信令為NULL時(shí)，根據(jù)特征值查找得到GITDR,將該信令與建立所述GITDR的POST信令組合，并將信令中的相關(guān)信息填充到GITDR中，之后，返回讀取并處理所述信令的下一條信令；如果所述信令為HTTP/1.0時(shí)，關(guān)閉GITDR,確定GITDR填充結(jié)束。所述特4正#_的獲耳又方法為如果源IP〉目的IP，則特征^f直為源IP+目的IP+源端口+目的端口；如果源IP<目的IP，則特征值為目的IP+源IP+目的端口+源端口。所述相關(guān)信息包括彩信的接收號(hào)碼、事物ID、以及彩信級(jí)別。本發(fā)明所提供的終端中彩信中心地址設(shè)置錯(cuò)誤的檢測方法，在現(xiàn)有事件合成方法的基礎(chǔ)上，當(dāng)信令為T-PDU類型時(shí)，進(jìn)一步判斷信令類型為T-PDU中的WAP類型還是HTTP類型；并且，確定信令在MMSE中為彩信發(fā)送請求、事件結(jié)果為失敗、且獲:f又到的彩信中心地址與所設(shè)置的正確的彩信中心地址不相符時(shí)，判定對(duì)應(yīng)終端中的彩信中心地址設(shè)置錯(cuò)誤，并可通過終端的MSISDN號(hào)確定設(shè)置錯(cuò)誤的具體終端，從而可以通過一定的方式提醒終端對(duì)應(yīng)用戶進(jìn)行彩信中心地址的修改，并指示正確的設(shè)置方式，增強(qiáng)了用戶體驗(yàn)，增加了用戶滿意度。本發(fā)明中，用戶在進(jìn)行正確的設(shè)置后，可以減少由于彩信中心地址錯(cuò)誤導(dǎo)致的事件結(jié)果為失敗的情況，從而減少了彩信發(fā)送失敗的情況，進(jìn)一步增強(qiáng)了用戶體驗(yàn)，增加了用戶滿意度。圖1為現(xiàn)有技術(shù)事件合成方法流程示意圖2為本發(fā)明終端中彩信中心地址設(shè)置錯(cuò)誤的檢測方法流程示意圖。具體實(shí)施例方式本發(fā)明的基本思想是在現(xiàn)有技術(shù)中事件合成方法的基礎(chǔ)上，全面、綜合地考慮T-PDU中包含的WAP、HTTP和MMSE消息類型之間的共同特征，進(jìn)一步判斷信令類型是否為發(fā)送彩信，且事件結(jié)果為失敗，如果是，表明彩信發(fā)送失敗，此時(shí)，通過比較終端中設(shè)置的彩信中心地址與正確的彩信中心地址來確定是否為由于彩信中心地址設(shè)置錯(cuò)誤導(dǎo)致的彩信無法發(fā)送。通過上述方法，可以減少由于終端中彩信中心地址設(shè)置錯(cuò)誤導(dǎo)致的彩信無法發(fā)送的情況。以下，通過具體實(shí)施例結(jié)合附圖詳細(xì)說明本發(fā)明終端中彩信中心地址設(shè)置錯(cuò)誤檢測方法的實(shí)現(xiàn)。圖2為本發(fā)明終端中彩信中心地址設(shè)置錯(cuò)誤的檢測方法流程示意圖，如圖2所示，該方法包4舌步驟201:配置正確的彩信中心地址。其中，本步驟放在步驟209之前任意步驟均可，但是，由于從步驟202-步驟209為針對(duì)單個(gè)信令進(jìn)行的操作，因此，如將本步驟放在步驟202~步驟209之間執(zhí)行，則在每次處理一個(gè)信令時(shí)，均需進(jìn)行正確的彩信中心地址的配置。由于彩信中心地址是可以長時(shí)間不變的，每處理一個(gè)信令配置一次將會(huì)浪費(fèi)系統(tǒng)資源，且會(huì)增加對(duì)每個(gè)信令的處理時(shí)間，因此，本步驟放在步驟202之前最為合適。其中，所述配置的方法可以為通過數(shù)據(jù)庫配置、或通過配置文件進(jìn)行配置等，當(dāng)后續(xù)步驟209中需查詢正確的彩信中心地址時(shí)，根據(jù)配置的具體方法使用相應(yīng)的查詢方法進(jìn)行查詢即可。步驟202-204:與圖1所示的步驟101~103基本相同，區(qū)別僅在于，當(dāng)信令為T-PDU時(shí)，將繼續(xù)執(zhí)行步驟205。步驟205:根據(jù)信令中包含的目的IP、TEID合成特征值，根據(jù)特征值查找GNTDR，如果能找到，則執(zhí)行步驟206;否則，返回步驟203。步驟206:判斷該信令為T-PDU中的WAP類型還是HTTP類型，如果為WAP類型，則執(zhí)行步驟207;如果為HTTP類型，則執(zhí)行步驟208。步驟207:判斷信令在WTP層和WSP層上的消息類型。首先，列舉出WAP中WTP層、以及WSP層所包含的具體消息類型，其中，如表l所示，為WTP層所包含的消息類型的中英文名稱對(duì)照<table>tableseeoriginaldocumentpage10</column></row><table>表1表2所示為WSP層所包含的消息類型的中英文名稱對(duì)照:<table>tableseeoriginaldocumentpage10</column></row><table>表2當(dāng)彩信數(shù)據(jù)量較大時(shí)，彩信數(shù)據(jù)會(huì)在傳輸時(shí)被分割成1500個(gè)字節(jié)左右的消息進(jìn)行傳輸，其中，對(duì)于WTP層，體現(xiàn)的形式是先有一條Invoke消息，隨后有多條SegmentedInvoke消息，直到彩信數(shù)據(jù)傳輸完畢，完畢時(shí)為Result消息。根據(jù)上述所列出的WTP層、WSP層所包含的消息類型，如圖2所示，步驟207中對(duì)于WAP消息類型的分析包括三種情況WTP層的消息類型為Invoke,WSP層的消息類型為POST時(shí)，根據(jù)特征值建立GITDR，并從對(duì)應(yīng)的GNTDR中得到MSISDN填充到GITDR中，之后，執(zhí)行步驟203。WTP層的消息類型為SegmentedInvoke時(shí)，才艮據(jù)特征值查找GITDR，找到時(shí)，將信令中的彩信的接收號(hào)碼、事物ID、彩信級(jí)別等相關(guān)信息填充到GITDR中，之后，執(zhí)行步驟203。其中，當(dāng)該信令的WTP的消息類型為SegmentedInvoke時(shí)，信令中并不包含WSP層，因此，并不存在對(duì)于WSP層消息類型的限制。WTP層的消息類型為Result,WSP層的消息類型為REPLY,查找GITDR，獲取事件結(jié)果，關(guān)閉GITDR,表明GITDR填充結(jié)束，之后，執(zhí)行步驟209。其中，對(duì)于上述三種情況中，GITDR所對(duì)應(yīng)的GNTDR為信令通過特征值查找到的GNTDR,由于已經(jīng)判斷得到所述信令的消息類型為T-PDU，并在步驟205中通過特征值查找到該信令對(duì)應(yīng)的GNTDR，從而在本步驟中，無需再次查找GNTDR,即可將信令對(duì)應(yīng)的GITDR與步驟205中所查找得到的信令對(duì)應(yīng)的GNTDR關(guān)聯(lián)起來。另外，具體如何建立GITDR、如何存儲(chǔ)、以及如何填充GITDR等均可以使用現(xiàn)有技術(shù)中的GNTDR建立、填充、以及存儲(chǔ)方法完成，這里不再贅述。另外，所述特征值根據(jù)信令中的相關(guān)信息合成，合成方法可以為如果源IP>目的IP,特征值為源IP+目的IP+源端口+目的端口；如果源IP<目的IP，特征值為目的IP+源IP+目的端口+源端口。其中，由于IP地址在存儲(chǔ)時(shí)可以轉(zhuǎn)化成數(shù)字格式，上述IP的比較在所存儲(chǔ)IP的數(shù)字格式對(duì)應(yīng)的值之間完成。步驟208:判斷該信令在HTTP中的消息類型。HTTP包括如表3所示的三種消息類型英文名稱中文名稱POST發(fā)送HTTP/1.0回復(fù)11<table>tableseeoriginaldocumentpage12</column></row><table>表3同樣的，當(dāng)彩信數(shù)據(jù)量較大時(shí)，彩信數(shù)據(jù)會(huì)在傳輸時(shí)被分割成1500個(gè)字節(jié)左右的消息進(jìn)行傳輸，其中，對(duì)于HTTP類型，體現(xiàn)的形式是先有一條POST消息，隨后有多條NULL消息，直到彩信數(shù)據(jù)傳輸完畢，完畢時(shí)為HTTP/1.0消息。由于HTTP包括以上三種消息類型，因此，在本步驟中，對(duì)于HTTP中消息類型的分析，同樣分成三種情況如果所述信令為POST消息，則根據(jù)特征值建立GITDR，并從對(duì)應(yīng)的GNTDR中得到MSISDN填充到GITDR中，之后，執(zhí)行步驟203。如果所述信令為未定義消息，則根據(jù)特征值查找GITDR,當(dāng)查找到相應(yīng)GITDR時(shí)，把所述信令和GITDR對(duì)應(yīng)的POST消息組合在一起，并將所述信令中的彩信的接收號(hào)碼、事物ID、彩信級(jí)別等相關(guān)信息填充到GITDR,之后，執(zhí)行步驟203。具體如何進(jìn)行POST消息和NULL消息的組合屬于公知技術(shù)，這里不再贅述。如果為HTTP/1.0消息，則根據(jù)特征值查找GITDR,如果找到，則獲取事件結(jié)果，關(guān)閉GITDR,表明GITDR填充結(jié)束，之后，執(zhí)行步驟209。其中，所述事件結(jié)果一般保存在相應(yīng)的GITDR的Response-status-value參數(shù)中。步驟209:判斷信令在MMSE中的消息類型，并判斷事件結(jié)果為成功或失敗，如果MMSE中彩信類型為彩信發(fā)送請求(m-send-req),且事件結(jié)果為失敗，則執(zhí)行步驟210;否則，執(zhí)行步驟203。其中，MMSE中的消息類型如表4所示<table>tableseeoriginaldocumentpage12</column></row><table>表4對(duì)于MMSE的事件結(jié)果，在本發(fā)明中涉及的事件結(jié)果類型如表5所示:名稱含義Ok成功其他失敗表5步驟210:從URL字段中獲取用戶設(shè)置的彩信中心地址，與步驟201中設(shè)置的正確的彩信中心地址進(jìn)行比較，判斷彩信中心地址是否設(shè)置錯(cuò)誤，如果是，則輸出設(shè)置錯(cuò)誤的用戶對(duì)應(yīng)的MSISDN,否則，返回步驟203。其中，當(dāng)信令為WAP類型時(shí)，所述URL字段一般在WSP層，當(dāng)信令為HTTP類型時(shí)，所述URL字段一般在信令的頭部。以上所述，僅為本發(fā)明的較佳實(shí)施例而已，并非用于限定本發(fā)明的保護(hù)范圍。權(quán)利要求1、一種終端中彩信中心地址設(shè)置錯(cuò)誤的檢測方法，其特征在于，該方法包括確定接收到的信令為隧道分組數(shù)據(jù)單元T-PDU類型，且確定GI事件詳細(xì)記錄GITDR填充結(jié)束后，根據(jù)信令對(duì)應(yīng)的多媒體消息服務(wù)環(huán)境MMSE消息類型、查詢到的事件結(jié)果、以及獲取到的用戶設(shè)置的彩信中心地址，比較并確定當(dāng)前接收到的信令對(duì)應(yīng)的終端的彩信中心地址是否設(shè)置錯(cuò)誤。2、根據(jù)權(quán)利要求1所述的檢測方法，其特征在于，該方法進(jìn)一步包括在比較終端的彩信中心地址之前，設(shè)置正確的彩信中心地址。3、根據(jù)權(quán)利要求2所述的檢測方法，其特征在于，所述確定信令對(duì)應(yīng)終端的彩信中心地址是否設(shè)置錯(cuò)誤具體為當(dāng)該信令為MMSE中的彩信發(fā)送消息、事件結(jié)果為失敗、且獲取的所述彩信中心地址與所設(shè)置的正確的彩信中心地址不相符時(shí)，確定該信令對(duì)應(yīng)終端的彩信中心地址設(shè)置錯(cuò)誤。4、根據(jù)權(quán)利要求1至3任一項(xiàng)所述的檢測方法，其特征在于，確定接收到的信令為T-PDU之前，該方法進(jìn)一步包括對(duì)GN接口網(wǎng)際協(xié)議IP信令數(shù)據(jù)進(jìn)行采集；讀取所采集的一條信令，確定該信令的IP層之上釆用了用戶數(shù)據(jù)報(bào)協(xié)議UDP、且UDP的端口為2152、或2123時(shí)，如果信令的消息類型為T-PDU以外的其他消息類型時(shí)，提取相應(yīng)的特征值，根據(jù)所述特征值的組成，生成或填充GNTDR，之后，返回讀取并處理所述信令的下一條信令；如果信令的消息類型為T-PDU時(shí)，才艮據(jù)相應(yīng)的特征值查找得到GNTDR。5、根據(jù)權(quán)利要求4所述的檢測方法，其特征在于，確定接收到的信令為T-PDU,與確定GITDR填充結(jié)束之間，該方法進(jìn)一步包括確定所述信令為T-PDU類型中的無線應(yīng)用協(xié)議WAP類型時(shí)，確定該信令在無線傳輸協(xié)議WTP層、和無線會(huì)話協(xié)議WSP層的消息類型，如果所述信令在WTP層的消息類型為Invoke、WSP層的消息類型為POST時(shí)，根據(jù)特征值建立GITDR,并從GNTDR得到移動(dòng)臺(tái)ISDN號(hào)MSISDN填充到GITDR中，之后，返回讀耳又并處理所述信令的下一條信令；如果所述信令在WTP層的消息類型為SegmentedInvoke時(shí)，根據(jù)特征值查找GITDR，并將信令中的相關(guān)信息填充到GITDR中，之后，返回讀取并處理所述信令的下一條信令；如果所述信令在WTP層的消息類型為Result,WSP層的消息類型為Reply,關(guān)閉GITDR，確定GITDR填充結(jié)束。6、根據(jù)權(quán)利要求4所述的檢測方法，其特征在于，所述確定接收到的信令為T-PDU類型，與所述確定GITDR填充結(jié)束之間，該方法進(jìn)一步包括令在HTTP中的消息類型，如果所述信令為POST時(shí)，#^居特征值建立GITDR,并從GNTDR得到信令對(duì)應(yīng)終端的MSISDN填充到GITDR中，之后，返回讀取并處理所述信令的下一條信令；如果所述信令為NULL時(shí)，根據(jù)特征值查找得到GITDR，將該信令與建立所述GITDR的POST信令組合，并將信令中的相關(guān)信息填充到GITDR中，之后，返回讀取并處理所述信令的下一條信令；如果所述信令為HTTP/1.0時(shí)，關(guān)閉GITDR,確定GITDR填充結(jié)束。7、根據(jù)權(quán)利要求5或6所述的檢測方法，其特征在于，所述特征值的獲取方法為如果源IP〉目的IP,則特征值為源IP+目的IP+源端口+目的端口；如果源IP<目的IP，則特征值為目的IP+源IP+目的端口+源端口。8、根據(jù)權(quán)利要求5或6所述的檢測方法，其特征在于，所述相關(guān)信息包括彩信的接收號(hào)碼、事物ID、以及彩信級(jí)別。全文摘要本發(fā)明提供了一種終端中彩信中心地址設(shè)置錯(cuò)誤的檢測方法，包括確定接收到的信令為T-PDU類型，且確定GITDR填充結(jié)束后，根據(jù)信令對(duì)應(yīng)的MMSE消息類型、查詢到的事件結(jié)果、以及獲取到的用戶設(shè)置的彩信中心地址，確定該信令對(duì)應(yīng)終端的彩信中心地址是否設(shè)置錯(cuò)誤。本發(fā)明所述檢測方法能夠通過GN接口檢測各終端中彩信中心地址設(shè)置是否錯(cuò)誤。文檔編號(hào)H04W88/18GK101540977SQ200810084330公開日2009年9月23日申請日期2008年3月18日優(yōu)先權(quán)日2008年3月18日發(fā)明者占治國申請人:中興通訊股份有限公司