專利名稱：Gs接口的消息處理方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，特別涉及碼分多址通信系統(tǒng)中的Gs接口的消息處理技術(shù)。
背景技術(shù)：
在碼分多址(Code Division Multiple Access，簡(jiǎn)稱″CDMA″)系統(tǒng)中，一個(gè)合法簽約用戶可以在分組域和電路域同時(shí)附著，由此能夠同時(shí)進(jìn)行分組域和電路域的通信業(yè)務(wù)。舉例而言，在打電話的同時(shí)可以上網(wǎng)。對(duì)于配置了Gs接口，即通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)(Serving GPRS Support Node，簡(jiǎn)稱″SGSN″)與移動(dòng)交換中心(Mobile Switching Center，簡(jiǎn)稱″MSC″)/拜訪位置寄存器(Visitor Location Register，簡(jiǎn)稱″VLR″)之間的接口的情況，移動(dòng)臺(tái)(Mobile Station，簡(jiǎn)稱″MS″)可以通過向分組域?qū)嶓wSGSN發(fā)送聯(lián)合附著等方式，實(shí)現(xiàn)同時(shí)在分組域?qū)嶓wSGSN、以及電路域?qū)嶓wMSC/VLR附著。具體的說，當(dāng)合法簽約用戶要求上述聯(lián)合附著時(shí)，分組域?qū)嶓wSGSN通過向電路域體MSC/VLR發(fā)送一條″BSSAP+-LOCATION-UPDATE-REQUEST″消息，完成用戶在電路域的附著。
圖1示出現(xiàn)有技術(shù)中，典型的聯(lián)合附著過程。如圖所示，在步驟110，MS向SGSN發(fā)送″attach request″消息，要求聯(lián)合附著。此后，在步驟120，SGSN向MSC/VLR發(fā)送″BSSAP+-LOCATION-UPDATE-REQUEST″消息，要求位置更新。
接著，在步驟130，如果MSC/VLR接受位置更新請(qǐng)求，則向SGSN反饋″BSSAP+-LOCATION-UPDATE-ACCET″消息；另一方面，如果MSC/VLR不接受位置更新請(qǐng)求，則在步驟135中，向SGSN發(fā)送″BSSAP+-LOCATION-UPDATE-REJECT″消息。
此后，進(jìn)入步驟140，SGSN向用戶發(fā)送附著″attach accept″消息，通知MS聯(lián)合附著結(jié)果是否成功，或僅僅在分組域附著成功，而在電路域附著失敗。
其中，步驟120中的″BSSAP+-LOCATION-UPDATE-REQUEST″消息結(jié)構(gòu)如表1所示，表1中各個(gè)信元具體結(jié)構(gòu)可參見第三代合作伙伴項(xiàng)目(3rdGeneration Partnership Project，簡(jiǎn)稱″3GPP″)29018協(xié)議相關(guān)章節(jié)。
表1″BSSAP+-LOCATION-UPDATE-REQUEST″消息內(nèi)容

需要說明的是，表1中的″New Cell global identity″信元包含該合法簽約用戶當(dāng)前所在的位置區(qū)(LA)。
在步驟130中的″BSSAP+-LOCATION-UPDATE-ACCEPT″消息結(jié)構(gòu)如表2所示。其中，各信元具體結(jié)構(gòu)參見3GPP 29018協(xié)議相關(guān)章節(jié)。
表2BSSAP+-LOCATION-UPDATE-ACCEPT消息內(nèi)容


需要說明的是，表2中的″Location area identity″信元指示來自SGSN的″BSSAP+-LOCATION-UPDATE-REQUEST″消息中，″New Cell globalidentity″信元包含的MS當(dāng)前所在的位置區(qū)信息。這就說明，SGSN接收到″BSSAP+-LOCATION-UPDATE-ACCEPT″消息后，可以通過將該消息中的″Location Area Identity″信元和自身發(fā)送的″BSSAP+-LOCATION-UPDATE-REQUEST″消息中的″New Cell globalidentity″信元包含的位置區(qū)對(duì)比，根據(jù)對(duì)比的結(jié)果，能夠判定該″BSSAP+-LOCATION-UPDATE-ACCEPT″消息是否是本身發(fā)送的″BSSAP+-LOCATION-UPDATE-REQUEST″消息的響應(yīng)。步驟135中的″BSSAP+-LOCATION-UPDATE-REJECT″消息結(jié)構(gòu)如表3所示。其中，各信元具體結(jié)構(gòu)參見3GPP 29018協(xié)議相關(guān)章節(jié)。
表3BSSAP+-LOCATION-UPDATE-REJECT消息內(nèi)容

如表3所示，MSC/VLR發(fā)送給SGSN的″BSSAP+-LOCATION-UPDATE-REJECT″消息中，不包含該用戶的位置信息。
在實(shí)際應(yīng)用中，上述方案存在以下問題在實(shí)際環(huán)境中由于用戶是處在不停的移動(dòng)過程中，而從SGSN通知MSC/VLR進(jìn)行位置更新到MSC/VLR更新完成給SGSN回響應(yīng)間需要一定的時(shí)間，因此在這個(gè)時(shí)間段內(nèi)，如果由于用戶移動(dòng)，MS又發(fā)起了聯(lián)合附著過程，則SGSN將又要向MSC/VLR發(fā)起位置更新過程，這就引發(fā)了Gs接口上的位置更新流程沖突。
具體而言，在3GPP 29018-440協(xié)議中的相關(guān)描述如下1如果用戶新的LA和原來的相同，SGSN應(yīng)該不向VLR發(fā)送″BSSAP+-LOCATION-UPDATE-REQUEST″消息，而是繼續(xù)處理上一次的更新流程；2如果用戶新的LA和原來的不同，則SGSN應(yīng)該忽略VLR發(fā)送的第一個(gè)位置更新請(qǐng)求的任何響應(yīng)(包括接收和拒絕)，并且向Gs接口發(fā)送一個(gè)新的″BSSAP+-LOCATION-UPDATE-REQUEST″消息，重新啟動(dòng)Gs接口上的位置更新流程。
上述描述可能有兩種情況第一種是VLR接受了SGSN第一次位置更新請(qǐng)求；另一種是VLR拒絕了SGSN第一次位置更新請(qǐng)求。
如果是第一種情況，從前面可以看出，SGSN能夠區(qū)分出VLR發(fā)送到SGSN的″BSSAP+-LOCATION-UPDATE-ACCEPT″消息是SGSN發(fā)送的第一條位置更新請(qǐng)求消息的響應(yīng)還是第二條的響應(yīng)。如果SGSN發(fā)現(xiàn)是第一條的響應(yīng)，那么根據(jù)協(xié)議描述，SGSN應(yīng)該忽略之，SGSN可以做到按照協(xié)議描述正確處理。
如果是第二種情況，也就是VLR不接受SGSN的第一條位置更新請(qǐng)求，向SGSN發(fā)送了″BSSAP+-LOCATION-UPDATE-REJECT″消息，由于其中沒有任何信息讓SGSN判斷該拒絕消息是第一條請(qǐng)求消息的響應(yīng)還是第二條請(qǐng)求消息的響應(yīng)，因此SGSN將無法準(zhǔn)確處理。
由此可見，現(xiàn)有協(xié)議無法保證SGSN在Gs接口沖突流程中做到正確處理。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種Gs接口的消息處理方法，使得保證SGSN在Gs接口更新沖突流程中能夠根據(jù)實(shí)際情況進(jìn)行正確處理。
為實(shí)現(xiàn)上述目的，本發(fā)明提供了一種Gs接口的消息處理方法，包含以下步驟D當(dāng)移動(dòng)交換中心/拜訪位置寄存器拒絕來自通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)的一條用戶位置更新請(qǐng)求時(shí)，所述移動(dòng)交換中心/拜訪位置寄存器向通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)發(fā)送拒絕消息，并且，所述拒絕消息中包含所述用戶位置更新請(qǐng)求中該用戶當(dāng)時(shí)的位置信息；E所述通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)根據(jù)所述位置信息，確定該拒絕消息所對(duì)應(yīng)的那條用戶位置更新請(qǐng)求。
其中，所述方法還包含以下步驟F所述通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)向用戶轉(zhuǎn)發(fā)該位置更新請(qǐng)求的拒絕消息。
所述方法還包含以下步驟A用戶向通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)發(fā)送附著請(qǐng)求；B所述通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)向移動(dòng)交換中心/拜訪位置寄存器發(fā)送位置更新請(qǐng)求。
所述步驟D還包含以下步驟當(dāng)移動(dòng)交換中心/拜訪位置寄存器接受來自通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)的一條位置更新請(qǐng)求時(shí)，向該通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)發(fā)送接受消息，其中，所述接受消息中包含所述用戶位置更新請(qǐng)求中該用戶當(dāng)時(shí)的位置信息。。
通過比較可以發(fā)現(xiàn)，本發(fā)明的技術(shù)方案與現(xiàn)有技術(shù)的區(qū)別在于，當(dāng)移動(dòng)交換中心/拜訪位置寄存器拒絕來自通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)的一條用戶位置更新請(qǐng)求時(shí)，在反饋的拒絕消息中包含該用戶位置更新請(qǐng)求消息中該用戶當(dāng)時(shí)的位置信息。
這種技術(shù)方案上的區(qū)別，帶來了較為明顯的有益效果，不但避免了SGSN直接將接收到的拒絕消息當(dāng)作第二條請(qǐng)求消息的響應(yīng)，并進(jìn)行處理；也避免了SGSN認(rèn)為該拒絕消息是第一條請(qǐng)求消息的響應(yīng)，從而丟棄。由此確保了SGSN在Gs接口更新流沖突流程中根據(jù)實(shí)際情況進(jìn)行正確處理。
另外，雖然在先行協(xié)議版本中，″BSSAP+-LOCATION-UPDATE-REJECT″消息中并沒有″location area identity″信元，但是采納本技術(shù)方案后不會(huì)導(dǎo)致采用本方案和沒有采用本方案的設(shè)備間的互聯(lián)互通問題。根據(jù)3GPP 29018的描述，SGSN和VLR都應(yīng)該忽略接收到的Gs消息中的未知信元和非預(yù)期信元(見29018-440協(xié)議16.5節(jié)描述)。對(duì)于未采用本方案的SGSN而言，如果″BSSAP+-LOCATION-UPDATE-REQUEST″消息中出現(xiàn)了″location areaidentity″信元，那么SGSN將認(rèn)為是未知信元，并忽略之，繼續(xù)按照其自身處理方案處理，不會(huì)導(dǎo)致其他異常。。


圖1是現(xiàn)有技術(shù)中典型的聯(lián)合附著過程示意圖；圖2是根據(jù)本發(fā)明的一個(gè)實(shí)施例的聯(lián)合附著過程示意圖；圖3是根據(jù)本發(fā)明的一個(gè)實(shí)施例的更具體的聯(lián)合附著過程示意圖。
具體實(shí)施例方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點(diǎn)更加清楚，下面將結(jié)合附圖對(duì)本發(fā)明作進(jìn)一步地詳細(xì)描述。
根據(jù)本發(fā)明的原理，要解決在WCDMA移動(dòng)通信系統(tǒng)中移動(dòng)用戶在電路域和分組域聯(lián)合附著過程中出現(xiàn)的Gs接口上的位置更新流程沖突問題。通過對(duì)移動(dòng)交換中心(Mobile Switching Center，簡(jiǎn)稱″MSC″)/拜訪位置寄存器(Visitor Location Register，簡(jiǎn)稱″VLR″)向通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)(Serving GPRS Support Node，簡(jiǎn)稱″SGSN″)返回拒絕聯(lián)合附著的消息中增加一個(gè)″Location area identifier″信元，使得系統(tǒng)能正確處理更新流程，而不至于產(chǎn)生異常情況。圖2示出了根據(jù)本發(fā)明的一個(gè)聯(lián)合附著過程。這個(gè)聯(lián)合附著過程主要由MS20、SGSN21和MSC/VLR22來完成的。
其中，MS20是用戶的移動(dòng)設(shè)備。熟悉本領(lǐng)域的人員應(yīng)該知道，MS20可以是手機(jī)、個(gè)人掌上電腦、筆記本、等終端移動(dòng)設(shè)備。
SGSN21主要是負(fù)責(zé)傳輸移動(dòng)網(wǎng)絡(luò)內(nèi)的數(shù)據(jù)分組，以及完成對(duì)終端的移動(dòng)性管理和數(shù)據(jù)傳輸相關(guān)的會(huì)話管理等功能。
MSC/VLR22是交換中心和一個(gè)數(shù)據(jù)庫(kù)，它們?cè)贛S20的當(dāng)前位置為其提供電路交換業(yè)務(wù)。
下面根據(jù)本發(fā)明的原理，具體描述聯(lián)合附著過程。
如圖2所示，首先在步驟210中，MS20向SGSN21發(fā)送″attach request″消息，要求聯(lián)合附著，并進(jìn)入步驟220。
在步驟220，SGSN21向MSC/VLR22發(fā)送″BSSAP+-LOCATION-PDATE-REQUEST″消息，要求位置更新，該消息結(jié)構(gòu)如下表4所示表4


需要說明的是，在上述表1中″Message type″信元表示消息類型，″IMSI″信元表示國(guó)際移動(dòng)用戶識(shí)別碼，″SGSN number″信元表示服務(wù)GPRS支持節(jié)點(diǎn)數(shù)目，″Update type″信元表示更新類型，″New Cell globalidentity″信元表示新小取新小區(qū)全球識(shí)別碼，它包含該合法簽約用戶當(dāng)前所在的位置區(qū)(LA)信息，″Mobile station classmark″信元表示基站種類標(biāo)記，″Old location areaidentifier″信元表示原位置區(qū)識(shí)別號(hào)，″TMSI status″信元表示臨時(shí)移動(dòng)用戶識(shí)別號(hào)，″New service area identification″信元表示新服務(wù)區(qū)識(shí)別碼。
隨后，在步驟230中，如果MSC/VLR22接受位置更新請(qǐng)求，則向SGSN21返回一個(gè)″BSSAP+-LOCATION-UPDATE-ACCET″消息；而另一方面，如果MSC/VLR22不接受該位置更新請(qǐng)求，則在步驟235中，向SGSN21發(fā)送″BSSAP+-LOCATION-UPDATE-REJECT″消息。
其中，″BSSAP+-LOCATION-UPDATE-ACCET″消息結(jié)構(gòu)如下表5所示。
表5

需要說明的是，表5中的″New TMSI，or IMSI″信元表示新的臨時(shí)移動(dòng)用戶識(shí)別號(hào)或者國(guó)際移動(dòng)用戶識(shí)別碼，″Location area identifier″信元?jiǎng)t指示來自SGSN21的″BSSAP+-LOCATION-UPDATE-REQUEST″消息中的″New CellGlobal Identity″信元包含的MS20當(dāng)前所在的位置區(qū)LA1信息。
這樣，SGSN21接收到″BSSAP+-LOCATION-UPDATE-ACCEPT″消息后，可以通過將該消息中的″Location area identifier″信元和自身發(fā)送的″BSSAP+-LOCATION-UpDATE-REQUEST″消息中的″New Cell GlobalIdentity″信元包含的位置區(qū)對(duì)比，根據(jù)對(duì)比的結(jié)果，能夠判定該″BSSAP+-LOCATION-UPDATE-ACCEPT″消息是否是本身發(fā)送的″BSSAP+-LOCATION-UPDATE-REQUEST″消息的響應(yīng)。
而在步驟135中，如果MSC/VLR22決定拒絕SGSN21發(fā)過來的″BSSAP+-LOCATION-UPDATE-REQUEST″請(qǐng)求，則MSC/VLR22應(yīng)該從″BSSAP+-LOCATION-UPDATE-REQU-EST″消息中取出MS20所在的位置區(qū)LA1信息，并將該LA1信息填寫到″BSSAP+-LOCATION-UPDATE-REJECT″消息中去。因此MSC/VLR22向SGSN21發(fā)送的拒絕聯(lián)合附著消息″BSSAP+-LOCATION-UPDATE-REJECT″消息結(jié)構(gòu)如下表6所示。
表6

表6中的″Location area identifier″信元指示出了MSC/VLR22從″BSSAP+-LOCATION-UPDATE-REQUEST″消息中取出的MS20所在的位置區(qū)LA1信息，而″Reject cause″信元?jiǎng)t表明了拒絕原因。SGSN21接受到這個(gè)″BSSAP+-LOCATION-UPDATE-REJECT″消息，就可以根據(jù)其中的″Locationarea identity″信元了解到MSC/VLR22拒絕了MSC20在步驟210中發(fā)出的″attach request″請(qǐng)求。
最后，在步驟240，SGSN21向MS20發(fā)送聯(lián)合附著″attach accept″消息，通知MS20聯(lián)合附著結(jié)果是成功，還是僅僅在分組域附著成功，而在電路域附著失敗。
下面參照?qǐng)D3，進(jìn)一步描述本發(fā)明的一個(gè)聯(lián)合附著的具體過程。
如圖所示，在步驟310中，MS30向SGSN31發(fā)送″attach request″消息1，請(qǐng)求聯(lián)合附著，隨后，進(jìn)入步驟320。
在步驟320，SGSN31向MSC/VLR32發(fā)送″BSSAP+-LOCATION-PDATE-REQUEST″消息，要求位置更新，該消息結(jié)構(gòu)如表4所示，此時(shí)，表4中的″New Cell Global Identity″信元包含MS30當(dāng)前所在的位置區(qū)LA2信息。
在實(shí)際環(huán)境里，由于MS30是在不間斷的移動(dòng)過程中的，而從SGSN31通知MSC/VLR32進(jìn)行位置更新到MSC/VLR32更新完成給SGSN31回響應(yīng)間需要一定的時(shí)間，因此在這個(gè)時(shí)間段內(nèi)，由于用戶移動(dòng)，MS30又發(fā)起了聯(lián)合附著過程。即在步驟330，MS30向SGSN31又發(fā)送了一個(gè)″attach request″消息2。
需要說明的是，這個(gè)″attach request″消息2可能是MS30在原來的位置區(qū)LA2發(fā)過來的附著請(qǐng)求消息，也可能是MS30移動(dòng)到了新的位置區(qū)LA3后發(fā)過來的附著請(qǐng)求消息。
在隨后的步驟340，SGSN31接收到了由MSC/VLR32發(fā)過來的″BSSAP+-LOCATION-UPDATE-REJECT″消息，該消息結(jié)構(gòu)正如前面的表6所示?！錌SSAP+-LOCATION-UPDATE-REJECT″消息中的″Location area identifier″信元指示出了位置區(qū)LA1信息。
如果在步驟330中，MS30向SGSN31發(fā)送的″attach request″消息2是MS30在原來的位置區(qū)LA2發(fā)過來的附著請(qǐng)求消息，則在接下來的步驟350中，SGSN31通過分析″BSSAP+-LOCATION-UPDATE-REJECT″消息中的″Location areaidentifier″信元了解到MSC/VLR32拒絕的是MS30在位置區(qū)LA2發(fā)過來的附著請(qǐng)求，按照3GPP 29018-440協(xié)議中的規(guī)定，SGSN31應(yīng)該不向MSC/VLR32發(fā)送″BSSAP+-LOCATION-UPDATE-REQUEST″消息，而是繼續(xù)處理上一次的更新流程，從而進(jìn)入步驟360。在步驟360，SGSN31向MS30發(fā)送一個(gè)″attach reject″消息，表明MSC/VLR32拒絕附著請(qǐng)求。于是聯(lián)合附著過程處理完畢。
另一方面，如果在步驟330中，MS30向SGSN31發(fā)送的″attach request″消息2是MS30在移動(dòng)到了新的位置區(qū)LA3后發(fā)過來的附著請(qǐng)求消息，則在接下來的步驟350中，SGSN31通過分析″BSSAP+-LOCATION-UPDATE-REJECT″消息中的″Location area identifier″信元了解到MSC/VLR32拒絕的是MS30在步驟310中由原先的位置區(qū)LA2發(fā)過來的附著請(qǐng)求，則SGSN31應(yīng)該忽略MSC/VLR32發(fā)送的第一個(gè)位置更新請(qǐng)求的任何響應(yīng)，并進(jìn)入步驟365。在步驟365，SGSN31向MSC/VLR32發(fā)送一個(gè)新的″BSSAP+-LOCATION-UPDATE-REQUEST″消息，重新啟動(dòng)Gs接口上的位置更新流程，為了文章的簡(jiǎn)明，對(duì)接下去的重新啟動(dòng)的位置更新流程就不在重復(fù)敘述了。
從上面的說明，可以看出，本發(fā)明保證了SGSN在Gs接口更新沖突流程中能夠根據(jù)實(shí)際情況進(jìn)行正確處理。既避免了SGSN直接將接收到的拒絕消息當(dāng)作第二條請(qǐng)求消息的響應(yīng)，并進(jìn)行處理；也避免了SGSN認(rèn)為該拒絕消息是第一條請(qǐng)求消息的響應(yīng)，從而丟棄。由此確保了SGSN在Gs接口更新流沖突流程中根據(jù)實(shí)際情況進(jìn)行正確處理。另外，雖然在先行協(xié)議版本中，″BSSAP+-LOCATION-UPDATE-REJECT″消息中并沒有″Location areaidentifier″信元，但是采納本發(fā)明方案后不會(huì)導(dǎo)致采用本發(fā)明方案和沒有采用本發(fā)明方案的設(shè)備間的互聯(lián)互通問題。根據(jù)3GPP 29018的描述，SGSN和VLR都應(yīng)該忽略接收到的Gs消息中的未知信元和非預(yù)期信元。對(duì)于未采用本發(fā)明方案的SGSN而言，如果″BSSAP+-LOCATION-UPDATE-REQUEST″消息中出現(xiàn)了″Location area identifier″信元，那么SGSN將認(rèn)為是未知信元，并忽略之，繼續(xù)按照其自身處理方案處理，不會(huì)導(dǎo)致其他異常。
雖然通過參照本發(fā)明的某些優(yōu)選實(shí)施例，已經(jīng)對(duì)本發(fā)明進(jìn)行了圖示和描述，但本領(lǐng)域的普通技術(shù)人員應(yīng)該明白，可以在形式上和細(xì)節(jié)上對(duì)其作各種各樣的改變，而不偏離所附權(quán)利要求書所限定的本發(fā)明的精神和范圍。
權(quán)利要求
1.一種Gs接口的消息處理方法，其特征在于，包含以下步驟D當(dāng)移動(dòng)交換中心/拜訪位置寄存器拒絕來自通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)的一條用戶位置更新請(qǐng)求時(shí)，所述移動(dòng)交換中心/拜訪位置寄存器向通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)發(fā)送拒絕消息，并且，所述拒絕消息中包含所述用戶位置更新請(qǐng)求中該用戶當(dāng)時(shí)的位置信息；E所述通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)根據(jù)所述用戶當(dāng)時(shí)的位置信息，確定該拒絕消息所對(duì)應(yīng)的那條用戶位置更新請(qǐng)求。
2.根據(jù)權(quán)利要求1所述的Gs接口的消息處理方法，其特征在于，所述方法還包含以下步驟F所述通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)向用戶轉(zhuǎn)發(fā)該位置更新請(qǐng)求的拒絕消息。
3.根據(jù)權(quán)利要求1所述的Gs接口的消息處理方法，其特征在于，所述方法還包含以下步驟A用戶向通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)發(fā)送附著請(qǐng)求；B所述通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)向移動(dòng)交換中心/拜訪位置寄存器發(fā)送位置更新請(qǐng)求。
4.根據(jù)權(quán)利要求1所述的Gs接口的消息處理方法，其特征在于，所述步驟D還包含以下步驟當(dāng)移動(dòng)交換中心/拜訪位置寄存器接受來自通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)的一條用戶位置更新請(qǐng)求時(shí)，向該通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)發(fā)送接受消息，其中，所述接受消息中包含所述用戶位置更新請(qǐng)求中該用戶當(dāng)時(shí)的位置信息。
全文摘要
本發(fā)明涉及通信領(lǐng)域，公開了一種Gs接口的消息處理方法，能夠保證SGSN在Gs接口更新沖突流程中能夠根據(jù)實(shí)際情況進(jìn)行正確處理。這種Gs接口的消息處理方法包含以下步驟當(dāng)移動(dòng)交換中心/拜訪位置寄存器拒絕來自通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)的一條用戶位置更新請(qǐng)求時(shí)，移動(dòng)交換中心/拜訪位置寄存器向通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)發(fā)送拒絕消息，并且，拒絕消息中包含用戶位置更新請(qǐng)求消息中該用戶當(dāng)時(shí)的位置信息；通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(diǎn)根據(jù)位置信息，確定該拒絕消息所對(duì)應(yīng)的那條用戶位置更新請(qǐng)求。
文檔編號(hào)H04W4/12GK1700787SQ20041004430
公開日2005年11月23日 申請(qǐng)日期2004年5月21日 優(yōu)先權(quán)日2004年5月21日
發(fā)明者張勇 申請(qǐng)人:華為技術(shù)有限公司