專利名稱：移動(dòng)通信系統(tǒng)、服務(wù)器、移動(dòng)終端及其數(shù)據(jù)發(fā)送方法
技術(shù)領(lǐng)域：
本發(fā)明涉及移動(dòng)通信系統(tǒng)、服務(wù)器、移動(dòng)終端及應(yīng)用在其上的數(shù)據(jù)發(fā)送方法，尤其涉及用于更新移動(dòng)電話中的軟件的數(shù)據(jù)發(fā)送方法。
背景技術(shù)：
在近來(lái)的移動(dòng)電話系統(tǒng)中，移動(dòng)電話服務(wù)的訂戶已在迅速增加，并已出現(xiàn)了已經(jīng)售出的移動(dòng)電話被召回以修復(fù)其故障的情況。
為了包括避免召回移動(dòng)電話在內(nèi)的多種目的，3GPP2(第3代合作伙伴計(jì)劃2)已在研究OTASP(空中業(yè)務(wù)提供)，用于經(jīng)由無(wú)線電來(lái)重寫(xiě)或更新移動(dòng)終端中的軟件(例如參見(jiàn)非專利文獻(xiàn)1)。
在此情況下，尋呼(paging)可以用作指定要重寫(xiě)軟件的移動(dòng)終端的技術(shù)。在尋呼技術(shù)中，當(dāng)有傳入移動(dòng)終端的呼叫或數(shù)據(jù)時(shí)，需要將該呼叫通知給移動(dòng)終端，并通過(guò)廣播將該呼叫通知給該移動(dòng)終端注冊(cè)了位置的位置注冊(cè)區(qū)域內(nèi)的所有移動(dòng)終端。因此，移動(dòng)終端識(shí)別出對(duì)其的尋呼，這是因?yàn)槠湟恢痹诒O(jiān)視尋呼信道，即使在空閑模式中也是如此(例如參見(jiàn)非專利文獻(xiàn)2)。
然而，將數(shù)據(jù)逐個(gè)轉(zhuǎn)發(fā)到每個(gè)移動(dòng)終端是低效的，因此提出了將數(shù)據(jù)廣播到所有需要重寫(xiě)軟件的移動(dòng)終端的技術(shù)(例如參見(jiàn)專利文獻(xiàn)1和2)。
專利文獻(xiàn)1日本專利申請(qǐng)?jiān)缙诠_(kāi)第2001-28787號(hào)(第7和第8段，圖1)專利文獻(xiàn)2日本專利申請(qǐng)?jiān)缙诠_(kāi)第2003-51796號(hào)(第6至第8段，圖1)非專利文獻(xiàn)12000年6月，3GPP2 Access Network InterfaceInteroperability Specification Release A
非專利文獻(xiàn)2“W-CDMA Mobile Communications System，Chapter 4Network Technologies，Chapter 4-3Network control and signaling scheme”Keiji Tachikawa編著，2001年6月25日由Maruzen Co.，Ltd.出版，第254-256頁(yè)發(fā)明內(nèi)容本發(fā)明要解決的問(wèn)題在上述的3GPP2所審閱的OTASP中，針對(duì)每個(gè)移動(dòng)終端發(fā)送數(shù)據(jù)，該技術(shù)并未充分利用無(wú)線電的如下特性，即多個(gè)移動(dòng)終端可以同時(shí)接收相同的數(shù)據(jù)。逐個(gè)地向每個(gè)移動(dòng)終端發(fā)送數(shù)據(jù)，這導(dǎo)致了移動(dòng)通信系統(tǒng)中的擁塞。
此外，根據(jù)將數(shù)據(jù)向所有需要重寫(xiě)軟件的移動(dòng)終端廣播的技術(shù)，無(wú)需重寫(xiě)軟件的移動(dòng)終端也接收數(shù)據(jù)，并在確定出不需要該數(shù)據(jù)時(shí)必須丟棄該數(shù)據(jù)。換言之，該技術(shù)所具有的問(wèn)題在于，即使不需要重寫(xiě)其軟件，移動(dòng)終端也必須接收數(shù)據(jù)并對(duì)該數(shù)據(jù)的必要性進(jìn)行確定，這導(dǎo)致移動(dòng)終端功耗的增加。
因此，本發(fā)明的目的在于提供一種移動(dòng)通信系統(tǒng)、服務(wù)器、移動(dòng)終端及應(yīng)用在其上的數(shù)據(jù)發(fā)送方法，其能夠高效地僅在需要重寫(xiě)軟件時(shí)更新目標(biāo)終端群組中的軟件。
解決問(wèn)題的手段根據(jù)本發(fā)明的一個(gè)方案，提供了一種移動(dòng)通信系統(tǒng)，其中經(jīng)由無(wú)線電在服務(wù)器和移動(dòng)終端之間發(fā)送/接收數(shù)據(jù)，其中所述服務(wù)器至少包括如下裝置，該裝置用于通過(guò)向目標(biāo)移動(dòng)終端發(fā)送附有關(guān)于移動(dòng)終端類型的信息的請(qǐng)求來(lái)對(duì)所述目標(biāo)移動(dòng)終端進(jìn)行尋呼。
根據(jù)本發(fā)明的另一方案，提供了一種移動(dòng)通信系統(tǒng)，其中執(zhí)行OTASP(空中業(yè)務(wù)提供)以基于從服務(wù)器經(jīng)由無(wú)線電發(fā)送來(lái)的數(shù)據(jù)來(lái)重寫(xiě)和更新移動(dòng)終端中的軟件，其中所述服務(wù)器包括如下裝置，該裝置用于在要執(zhí)行OTASP時(shí)，通過(guò)向目標(biāo)移動(dòng)終端發(fā)送附有關(guān)于移動(dòng)終端類型和軟件版本的信息的請(qǐng)求來(lái)對(duì)所述目標(biāo)移動(dòng)終端進(jìn)行尋呼。
根據(jù)本發(fā)明的另一方案，提供了一種經(jīng)由無(wú)線電向移動(dòng)終端發(fā)送數(shù)據(jù)和從移動(dòng)終端接收數(shù)據(jù)的服務(wù)器，其至少包括如下裝置，該裝置用于通過(guò)向目標(biāo)移動(dòng)終端發(fā)送附有關(guān)于移動(dòng)終端類型的信息的請(qǐng)求來(lái)對(duì)所述目標(biāo)移動(dòng)終端進(jìn)行尋呼。
根據(jù)本發(fā)明的另一方案，提供了一種服務(wù)器，該服務(wù)器經(jīng)由無(wú)線電發(fā)送數(shù)據(jù)，其用于執(zhí)行OTASP(空中業(yè)務(wù)提供)以重寫(xiě)移動(dòng)終端中的軟件，所述服務(wù)器包括如下裝置，該裝置用于在要執(zhí)行OTASP時(shí)，通過(guò)向目標(biāo)移動(dòng)終端發(fā)送附有關(guān)于移動(dòng)終端類型和軟件版本的信息的請(qǐng)求來(lái)對(duì)所述目標(biāo)移動(dòng)終端進(jìn)行尋呼。
根據(jù)本發(fā)明的另一方案，提供了一種移動(dòng)通信系統(tǒng)中的移動(dòng)終端，在所述移動(dòng)通信系統(tǒng)中執(zhí)行OTASP(空中業(yè)務(wù)提供)，以基于從服務(wù)器經(jīng)由無(wú)線電發(fā)送來(lái)的數(shù)據(jù)重寫(xiě)移動(dòng)終端中的軟件，所述移動(dòng)終端包括用于基于在要執(zhí)行OTASP時(shí)接收到的請(qǐng)求所附有的終端類型和軟件版本信息確定該請(qǐng)求是否指向所述終端的裝置；以及用于在確定了所述請(qǐng)求是指向所述終端時(shí)，基于從服務(wù)器發(fā)送來(lái)的數(shù)據(jù)更新軟件的裝置。
根據(jù)本發(fā)明的另一方案，提供了一種應(yīng)用于移動(dòng)通信系統(tǒng)的數(shù)據(jù)發(fā)送方法，在所述移動(dòng)通信系統(tǒng)中經(jīng)由無(wú)線電在服務(wù)器和移動(dòng)終端之間發(fā)送/接收數(shù)據(jù)，所述方法在服務(wù)器側(cè)至少包括如下步驟通過(guò)向目標(biāo)移動(dòng)終端發(fā)送附有關(guān)于移動(dòng)終端類型的信息的請(qǐng)求來(lái)對(duì)所述目標(biāo)移動(dòng)終端進(jìn)行尋呼。
根據(jù)本發(fā)明的另一方案，提供了一種應(yīng)用于移動(dòng)通信系統(tǒng)的數(shù)據(jù)發(fā)送方法，在所述移動(dòng)通信系統(tǒng)中執(zhí)行OTASP(空中業(yè)務(wù)提供)，以基于從服務(wù)器經(jīng)由無(wú)線電發(fā)送來(lái)的數(shù)據(jù)重寫(xiě)移動(dòng)終端中的軟件，所述方法在服務(wù)器側(cè)包括如下步驟在要執(zhí)行OTASP時(shí)，通過(guò)向目標(biāo)移動(dòng)終端發(fā)送附有關(guān)于移動(dòng)終端類型和軟件版本的信息的請(qǐng)求來(lái)對(duì)所述目標(biāo)移動(dòng)終端進(jìn)行尋呼。
如上所述，本發(fā)明的移動(dòng)通信系統(tǒng)的特征在于，在移動(dòng)通信廣播或多播中，服務(wù)器在沒(méi)有來(lái)自目標(biāo)移動(dòng)終端群組的請(qǐng)求的情況下將數(shù)據(jù)分發(fā)到所述目標(biāo)移動(dòng)終端群組，從而更新移動(dòng)終端中的軟件。此外，已被更新一次的軟件不會(huì)被重復(fù)更新。
一般而言，在廣播情況下，所有移動(dòng)終端都可接收數(shù)據(jù)。然而，根據(jù)本發(fā)明，只有目標(biāo)移動(dòng)終端可以接收數(shù)據(jù)。
此外，一般而言，在多播情況下，移動(dòng)終端的用戶根據(jù)他/她自己的意愿加入業(yè)務(wù)以接收數(shù)據(jù)。然而，本發(fā)明提出服務(wù)器使用唯一地標(biāo)識(shí)移動(dòng)終端的信息，從網(wǎng)絡(luò)側(cè)對(duì)該移動(dòng)終端進(jìn)行尋呼，所述信息例如是IMEI-SV(國(guó)際移動(dòng)臺(tái)設(shè)備標(biāo)識(shí)和軟件版本號(hào))。
另外，根據(jù)本發(fā)明，檢查軟件的完好性。因此，在成功更新軟件的情況下不再接收相同的數(shù)據(jù)，而在失敗的情況下可以再次接收相同的數(shù)據(jù)。
在使用廣播的OTASP(空中業(yè)務(wù)提供)中，網(wǎng)絡(luò)側(cè)不需要確認(rèn)目標(biāo)移動(dòng)終端的存在，并且不接收來(lái)自移動(dòng)終端的響應(yīng)。因此，可以減少網(wǎng)絡(luò)側(cè)的負(fù)擔(dān)。然而，存在即使該區(qū)域中沒(méi)有駐留的目標(biāo)移動(dòng)終端也發(fā)送了數(shù)據(jù)的情況。在這種情況下，執(zhí)行OTASP以基于從服務(wù)器經(jīng)由無(wú)線電發(fā)送的數(shù)據(jù)來(lái)重寫(xiě)移動(dòng)終端中的軟件。
另一方面，在使用多播的OTASP中，網(wǎng)絡(luò)側(cè)必須確認(rèn)目標(biāo)移動(dòng)終端的存在，因此接收來(lái)自移動(dòng)終端的響應(yīng)。因此，網(wǎng)絡(luò)側(cè)的負(fù)擔(dān)增加。然而，可以在沒(méi)有駐留的目標(biāo)移動(dòng)終端的情況下避免將數(shù)據(jù)發(fā)送到該區(qū)域。
在最初的若干次中，可以使用廣播，這是因?yàn)轭A(yù)期會(huì)存在多個(gè)目標(biāo)移動(dòng)終端。然后，在使用廣播若干次之后，可以使用多播。從而，可以實(shí)現(xiàn)高效的OTASP。
3GPP當(dāng)前正在審閱MBMS(多媒體廣播/多播業(yè)務(wù))。MBMS致力于通過(guò)將數(shù)據(jù)發(fā)送給區(qū)域中所有移動(dòng)終端的廣播，以及將數(shù)據(jù)僅發(fā)送給希望接收數(shù)據(jù)的移動(dòng)終端群組的多播，來(lái)高效地利用無(wú)線電資源。該技術(shù)使得能將必需的數(shù)據(jù)僅發(fā)送給特定移動(dòng)終端的群組。
在當(dāng)前的3GPP規(guī)約中，每個(gè)移動(dòng)終端檢查該終端已注冊(cè)到的尋呼指示信道(PICH)的一個(gè)比特。當(dāng)該比特指示“1”時(shí)，移動(dòng)終端從尋呼信道(PCH)中讀取信息，以確定傳入數(shù)據(jù)是否去往該終端。根據(jù)本發(fā)明，與3GPP規(guī)約一樣，處于空閑模式的移動(dòng)終端根據(jù)來(lái)自網(wǎng)絡(luò)的指令間歇地接收尋呼指示信道。
為了更新特定移動(dòng)終端中的軟件，網(wǎng)絡(luò)向?qū)ず糁甘拘诺赖拿總€(gè)比特寫(xiě)“1”，以使得所有移動(dòng)終端可以接收數(shù)據(jù)。此外，網(wǎng)絡(luò)使尋呼信道包含關(guān)于目標(biāo)移動(dòng)終端類型(終端類別或分類)以及需要更新的移動(dòng)終端軟件的當(dāng)前版本的信息。
已被尋呼指示信道指示接收尋呼信道的所有移動(dòng)終端中的每一個(gè)都將其類型(終端類別)和軟件版本與尋呼信道中所包含的相比較。作為比較結(jié)果，如果它們不匹配，則移動(dòng)終端此時(shí)返回空閑模式。如果它們匹配，則移動(dòng)終端基于來(lái)自尋呼信道的信息，通過(guò)多播或廣播來(lái)接收必需的數(shù)據(jù)。要使用多播還是廣播，這是在網(wǎng)絡(luò)側(cè)設(shè)定的，以便由移動(dòng)終端在尋呼時(shí)識(shí)別。
在多播情況下，如果即便只有一個(gè)來(lái)自移動(dòng)終端的響應(yīng)，則也開(kāi)始數(shù)據(jù)發(fā)送，而如果沒(méi)有響應(yīng)，則OTASP終止。
當(dāng)成功更新了軟件版本時(shí)，移動(dòng)終端更新其中的軟件版本信息。另一方面，當(dāng)未能更新軟件版本時(shí)，移動(dòng)終端丟棄接收到的數(shù)據(jù)，并且不更新其中的軟件的版本信息。從而，已成功更新了軟件版本的移動(dòng)終端不會(huì)再次接收相同的數(shù)據(jù)，而未能更新軟件版本的移動(dòng)終端可以再次接收相同的數(shù)據(jù)，直到其成功更新軟件版本。
本發(fā)明的效果如上所述，根據(jù)本發(fā)明，每個(gè)移動(dòng)終端都不浪費(fèi)其功率，并且可以高效地僅在需要重寫(xiě)軟件時(shí)才更新目標(biāo)終端群組中的軟件。


圖1示出了根據(jù)本發(fā)明實(shí)施方式的移動(dòng)通信系統(tǒng)的操作實(shí)施例。
圖2示出了根據(jù)本發(fā)明實(shí)施方式的移動(dòng)通信系統(tǒng)的操作實(shí)施例。
圖3的框圖示出了根據(jù)本發(fā)明實(shí)施方式的移動(dòng)通信系統(tǒng)的構(gòu)造。
圖4的框圖示出了圖3所示的服務(wù)器的構(gòu)造。
圖5的框圖示出了圖3所示的移動(dòng)終端的構(gòu)造。
圖6示出了根據(jù)本發(fā)明的PICH的構(gòu)造，以及PICH與PCH之間的關(guān)系。
圖7示出了PCH中的UE標(biāo)識(shí)符的改變的圖像。
圖8示出了PCH中的UE標(biāo)識(shí)符的改變的圖像。
圖9示出了PCH中的UE標(biāo)識(shí)符的改變的圖像。
圖10的流程圖示出了圖3所示的服務(wù)器的操作。
圖11的流程圖示出了圖3所示的移動(dòng)終端的操作。
圖12的順序圖示出了根據(jù)本發(fā)明實(shí)施方式的OTASP數(shù)據(jù)發(fā)送處理。
圖13的順序圖示出了根據(jù)本發(fā)明實(shí)施方式的OTASP數(shù)據(jù)發(fā)送處理。
圖14的流程圖示出了圖3所示的服務(wù)器側(cè)的操作。
圖15的流程圖示出了圖3所示的移動(dòng)終端的數(shù)據(jù)處理操作。
具體實(shí)施例方式
現(xiàn)在參照附圖，將詳細(xì)給出對(duì)本發(fā)明優(yōu)選實(shí)施方式的說(shuō)明。圖1和圖2示出了根據(jù)本發(fā)明實(shí)施方式的移動(dòng)通信系統(tǒng)的操作實(shí)施例。在圖1所示的該實(shí)施方式的移動(dòng)通信系統(tǒng)中，在移動(dòng)通信廣播或多播時(shí)，服務(wù)器(未示出)將數(shù)據(jù)分發(fā)到目標(biāo)移動(dòng)終端1-1至1-5的群組而無(wú)需來(lái)自這些移動(dòng)終端的請(qǐng)求，從而更新移動(dòng)終端1-1至1-5中的軟件。另外，已被更新一次的軟件將不被重復(fù)更新。
在普通廣播的情況下，所有移動(dòng)終端1-1至1-5都可以接收數(shù)據(jù)。同時(shí)，在本實(shí)施方式中，僅目標(biāo)移動(dòng)終端1-1和1-3可以接收數(shù)據(jù)。
此外，在普通多播的情況下，移動(dòng)終端1-1至1-5的用戶按其自己的意愿加入業(yè)務(wù)以接收數(shù)據(jù)。同時(shí)，在本實(shí)施方式中，服務(wù)器使用唯一標(biāo)識(shí)移動(dòng)終端1-1至1-5的信息從網(wǎng)絡(luò)側(cè)對(duì)這些移動(dòng)終端進(jìn)行尋呼，所述信息例如是IMEI-SV(國(guó)際移動(dòng)臺(tái)設(shè)備標(biāo)識(shí)和軟件版本號(hào))。對(duì)“IMEI-SV”的說(shuō)明可以在3GPP TS23.003V5.5.1(2003-1)，chapter 6.2.2中找到。
移動(dòng)終端1-1至1-5具有檢查軟件完好性的功能，以便在成功更新了軟件時(shí)不接收相同的數(shù)據(jù)，并在未能更新軟件時(shí)接收相同的數(shù)據(jù)。
在圖1中，數(shù)據(jù)(用于A型終端的關(guān)于版本為“n”的軟件的數(shù)據(jù))通過(guò)節(jié)點(diǎn)B(基站)發(fā)送到移動(dòng)終端(UE用戶設(shè)備)1-1至1-5。所述數(shù)據(jù)僅被軟件版本為“n”的A型移動(dòng)終端1-1和1-3接收，而不被B型移動(dòng)終端1-4、軟件版本早于“n”的A型移動(dòng)終端1-2和軟件版本晚于“n”的A型移動(dòng)終端1-5所接收。
在使用廣播的OTASP(空中業(yè)務(wù)提供)中，網(wǎng)絡(luò)側(cè)不需要確認(rèn)目標(biāo)移動(dòng)終端1-1和1-3的存在，并且不從其接收響應(yīng)。因此，可以減少網(wǎng)絡(luò)側(cè)的負(fù)擔(dān)。然而存在如下情況即使目標(biāo)移動(dòng)終端1-1和1-3未駐留于該區(qū)域內(nèi)，也發(fā)送了數(shù)據(jù)。在這種情況下，執(zhí)行OTASP，以基于從服務(wù)器經(jīng)由無(wú)線電發(fā)送的數(shù)據(jù)來(lái)重寫(xiě)移動(dòng)終端1-1至1-5中的軟件。對(duì)“OTASP”的說(shuō)明可以在3GPP TR23.8466.1.0(2002-12)中找到。
另一方面，在使用多播的OTASP中，網(wǎng)絡(luò)側(cè)必須確認(rèn)目標(biāo)移動(dòng)終端1-1和1-3的存在，因而接收來(lái)自所述移動(dòng)終端中每一個(gè)的響應(yīng)。因此，網(wǎng)絡(luò)側(cè)的負(fù)擔(dān)增加了。然而，可以避免向目標(biāo)移動(dòng)終端1-1和1-3未駐留的區(qū)域發(fā)送數(shù)據(jù)。
因此，在本實(shí)施方式中，在最初的若干次中使用廣播，這是因?yàn)轭A(yù)期會(huì)存在多個(gè)目標(biāo)移動(dòng)終端。然后，在使用廣播若干次之后，使用多播。從而，可以實(shí)現(xiàn)高效的OTASP。
圖2示出了根據(jù)該實(shí)施方式的廣播和多播的應(yīng)用實(shí)施例。在圖2的實(shí)施例中，移動(dòng)終端UE#1至UE#10中的軟件被重寫(xiě)，軟件版本從“3”更新到“4”。
第一天，服務(wù)器廣播關(guān)于版本為“4”的軟件的數(shù)據(jù)。當(dāng)對(duì)終端進(jìn)行尋呼時(shí)，服務(wù)器利用當(dāng)前版本“3”。類型和軟件版本與服務(wù)器所指示的相匹配的終端對(duì)廣播進(jìn)行響應(yīng)。在圖2中，移動(dòng)終端UE#1、UE#5，以及UE#7至UE#9是開(kāi)機(jī)的，并將從服務(wù)器接收到的關(guān)于版本為“4”的軟件的數(shù)據(jù)寫(xiě)入其中。其它移動(dòng)終端UE#2至UE#4、UE#6和UE#10是關(guān)機(jī)的，因此不向其中寫(xiě)入來(lái)自服務(wù)器的關(guān)于版本為“4”的軟件的數(shù)據(jù)。
隨后，第二天，服務(wù)器還廣播關(guān)于版本為“4”的軟件的數(shù)據(jù)。此時(shí)，由于數(shù)據(jù)已經(jīng)寫(xiě)入到移動(dòng)終端UE#1、UE#5，以及UE#7至UE#9，因此其軟件版本與服務(wù)器所指示的不匹配，這些終端不對(duì)廣播進(jìn)行響應(yīng)。此外，移動(dòng)終端UE#2至UE#4是開(kāi)機(jī)的，并將從服務(wù)器接收到的關(guān)于版本為“4”的軟件的數(shù)據(jù)寫(xiě)入其中。其它移動(dòng)終端UE#6和UE#10仍關(guān)機(jī)，因此不向其中寫(xiě)入來(lái)自服務(wù)器的關(guān)于版本為“4”的軟件的數(shù)據(jù)。
在預(yù)設(shè)的N-1天使用廣播之后，在第N天，服務(wù)器向移動(dòng)終端UE#6和UE#10多播關(guān)于版本為“4”的軟件的數(shù)據(jù)。此時(shí)，由于數(shù)據(jù)已被寫(xiě)入移動(dòng)終端UE#1至UE#5以及UE#7至UE#9，因此這些終端不對(duì)多播進(jìn)行響應(yīng)。
圖3的框圖示出了根據(jù)本發(fā)明實(shí)施方式的移動(dòng)通信系統(tǒng)的構(gòu)造。參照?qǐng)D3，本實(shí)施方式的移動(dòng)通信系統(tǒng)包括移動(dòng)終端(UE)1、節(jié)點(diǎn)B(基站)2-1和2-2、RNC(無(wú)線電網(wǎng)絡(luò)控制器)3、SGSN[服務(wù)GPRS(通用分組無(wú)線電業(yè)務(wù))支持節(jié)點(diǎn)]4、GGSN(網(wǎng)關(guān)GPRS支持節(jié)點(diǎn))5、服務(wù)器6和IP(因特網(wǎng)協(xié)議)網(wǎng)絡(luò)100。
在以下說(shuō)明中，為簡(jiǎn)單起見(jiàn)，將尋呼指示信道稱為PICH，將尋呼信道稱為PCH，并利用3GPP(第3代合作伙伴計(jì)劃)中的通用術(shù)語(yǔ)。
圖4的框圖示出了圖3所示的服務(wù)器6的構(gòu)造。參照?qǐng)D4，服務(wù)器6包括數(shù)據(jù)輸入/輸出部件61、數(shù)據(jù)存儲(chǔ)裝置62、數(shù)據(jù)發(fā)送控制器(調(diào)度器)63、多播部件64和廣播部件65。
數(shù)據(jù)輸入/輸出部件61從其它設(shè)備(例如提供諸如安裝在移動(dòng)終端1中的控制程序和應(yīng)用程序之類的程序的程序生產(chǎn)商的設(shè)備)接收用于更新程序等的數(shù)據(jù)，并將該數(shù)據(jù)存儲(chǔ)在數(shù)據(jù)存儲(chǔ)裝置62中。此外，數(shù)據(jù)輸入/輸出部件61還讀出存儲(chǔ)在數(shù)據(jù)存儲(chǔ)裝置62中的數(shù)據(jù)，并將其發(fā)送到數(shù)據(jù)發(fā)送控制器63，以發(fā)出用于基于該數(shù)據(jù)進(jìn)行更新的指令。
數(shù)據(jù)發(fā)送控制器63從數(shù)據(jù)輸入/輸出部件61接收數(shù)據(jù)，并創(chuàng)建如前所述地通過(guò)廣播和多播分發(fā)數(shù)據(jù)的時(shí)間表。根據(jù)該時(shí)間表，數(shù)據(jù)發(fā)送控制器63將數(shù)據(jù)饋送到多播部件64或廣播部件65。
多播部件64根據(jù)數(shù)據(jù)發(fā)送控制器63創(chuàng)建的時(shí)間表將數(shù)據(jù)發(fā)送到GGSN 5，以將數(shù)據(jù)多播到移動(dòng)終端1。多播部件64需要等待來(lái)自GGSN 5的響應(yīng)。當(dāng)未接收到響應(yīng)時(shí)，多播部件64確定出不存在屬于該服務(wù)器的目標(biāo)終端，并且將不執(zhí)行數(shù)據(jù)發(fā)送。廣播部件65根據(jù)數(shù)據(jù)發(fā)送控制器63創(chuàng)建的時(shí)間表將數(shù)據(jù)發(fā)送到GGSN 5，以將數(shù)據(jù)廣播到移動(dòng)終端1。與多播部件64不同，廣播部件65無(wú)需等待來(lái)自GGSN 5的響應(yīng)。多播部件64和廣播部件65每個(gè)都在預(yù)定時(shí)間段之后開(kāi)始數(shù)據(jù)發(fā)送，在所述預(yù)定時(shí)間段期間每個(gè)終端可能已做好接收數(shù)據(jù)的準(zhǔn)備。
圖5的框圖示出了圖3所示的移動(dòng)終端(UE)1的構(gòu)造。參照?qǐng)D5，移動(dòng)終端1包括天線11、無(wú)線電通信部件12、控制器13、基帶部件18、語(yǔ)音輸入/輸出部件19、顯示器20和鍵操作部件21。每個(gè)組件的操作是公知的，因此不在這里說(shuō)明。
控制器13包括CPU(中央處理單元)14、存儲(chǔ)器15、傳送方法確定部件16和數(shù)據(jù)傳送控制器17，其中所述存儲(chǔ)器15用于存儲(chǔ)CPU 14所執(zhí)行的諸如控制程序和應(yīng)用程序之類的程序。
傳送方法確定部件16判斷用于升級(jí)軟件版本等的數(shù)據(jù)是要從服務(wù)器6廣播還是多播。CPU 14和數(shù)據(jù)傳送控制器17根據(jù)判斷結(jié)果進(jìn)行操作。
當(dāng)用于升級(jí)軟件版本等的數(shù)據(jù)要從服務(wù)器6廣播或多播時(shí)，CPU 14和數(shù)據(jù)傳送控制器17將終端的軟件版本與來(lái)自服務(wù)器6的數(shù)據(jù)所指示的版本相比較。如果版本不匹配，則CPU 14和數(shù)據(jù)傳送控制器17終止操作。如果版本匹配，則CPU 14和數(shù)據(jù)傳送控制器17在要使用多播時(shí)向網(wǎng)絡(luò)側(cè)發(fā)送響應(yīng)，而在要使用廣播時(shí)不向網(wǎng)絡(luò)側(cè)進(jìn)行發(fā)送，并準(zhǔn)備接收數(shù)據(jù)。
在此情況下，移動(dòng)終端1僅需要監(jiān)視尋呼信道以及執(zhí)行上述比較，并向接收數(shù)據(jù)所必需的部件供電。與傳統(tǒng)的廣播數(shù)據(jù)接收不同，移動(dòng)終端1無(wú)需向所有部件供電。
圖6示出了根據(jù)本發(fā)明的PICH的構(gòu)造，以及PICH與PCH之間的關(guān)系。在圖6中，無(wú)法單獨(dú)與RNC 3通信的移動(dòng)終端1{空閑，小區(qū)/URA[UTRAN(UMTS陸地?zé)o線電接入網(wǎng))注冊(cè)區(qū)域]_PCH}在RNC 3所指示的定時(shí)間歇地接收PICH。該操作是移動(dòng)終端1接收數(shù)據(jù)所必需的。
移動(dòng)終端1接收PICH的定時(shí)是從其標(biāo)識(shí)符[IMSI(國(guó)際移動(dòng)用戶標(biāo)識(shí))]等的值計(jì)算出的。PICH的一個(gè)幀包含300個(gè)比特，其最后12個(gè)比特被保留。
此外，移動(dòng)終端1所監(jiān)視的PICH的一個(gè)比特也是從其標(biāo)識(shí)符(IMSI)等的值計(jì)算出的。當(dāng)移動(dòng)終端1所監(jiān)視的PICH的比特指示“1”時(shí)，移動(dòng)終端1接收對(duì)應(yīng)于PICH的PCH。
在當(dāng)前的3GPP規(guī)約中，每個(gè)移動(dòng)終端檢查該終端已注冊(cè)到的尋呼指示信道(PICH)的一個(gè)比特。當(dāng)該比特指示“1”時(shí)，移動(dòng)終端從尋呼信道(PCH)中讀取信息，以確定傳入數(shù)據(jù)是否指向該終端。在本實(shí)施方式中，與3GPP規(guī)約一樣，處于空閑模式的移動(dòng)終端根據(jù)來(lái)自網(wǎng)絡(luò)的指令間歇地接收尋呼指示信道(見(jiàn)圖6和7)。
圖7至9示出了PCH中UE標(biāo)識(shí)符的改變的圖像。在圖7至9中，由于PICH的幀號(hào)(0到4095)和比特?cái)?shù)(288)的數(shù)值受限，因此PICH的每個(gè)比特并不總是分配給一個(gè)UE。
例如，如果PICH的一個(gè)比特被分配給3個(gè)UE，則通過(guò)將該比特設(shè)定為“1”，而使這3個(gè)UE接收一個(gè)PCH。然而，這3個(gè)UE極少會(huì)同時(shí)接收傳入數(shù)據(jù)，必需指示該比特“1”應(yīng)用于它們中的哪一個(gè)。這種指示是通過(guò)包含在PCH中的UE標(biāo)識(shí)符來(lái)提供的。在接收到PCH之后，每個(gè)UE必須檢查UE標(biāo)識(shí)符以確定傳入數(shù)據(jù)是不是去往該UE的。
這里，假定發(fā)送一個(gè)數(shù)據(jù)，并且多個(gè)UE同時(shí)接收該數(shù)據(jù)。即，數(shù)據(jù)要發(fā)送到的多個(gè)UE(軟件為特定版本的特定類型的UE)需要同時(shí)接收數(shù)據(jù)。每個(gè)UE具有不同的標(biāo)識(shí)符，因此PICH的每個(gè)比特都被設(shè)定為“1”以使得所有UE都可以接收數(shù)據(jù)。然而，在當(dāng)前PCH中的UE標(biāo)識(shí)符的情況下，對(duì)單獨(dú)的UE設(shè)定UE標(biāo)識(shí)符，這不適用于多個(gè)UE同時(shí)接收數(shù)據(jù)的情況。
因此，向UE標(biāo)識(shí)符添加了IMEI-SV，并將數(shù)據(jù)要發(fā)送到的UE的類型和軟件版本用作UE標(biāo)識(shí)符。從而，可以將目標(biāo)UE分成群組。雖然IMEI-SV包含標(biāo)識(shí)每個(gè)UE的序列號(hào)，但這里并未使用序列號(hào)信息，這是因?yàn)橄Ｍ囟║E的群組同時(shí)接收數(shù)據(jù)。
此外，如果如上所述，PICH的每個(gè)比特都被設(shè)定為“1”，則目標(biāo)UE一起對(duì)尋呼消息或請(qǐng)求進(jìn)行響應(yīng)，這可能對(duì)上行鏈路無(wú)線電容量造成壓力，同時(shí)還增加網(wǎng)絡(luò)側(cè)的處理負(fù)擔(dān)。因此，將PICH的每個(gè)比特都設(shè)定為“1”可能不是最佳方式。例如，要設(shè)定為“1”的PICH的比特可以每幾分鐘移位10比特，在所述的幾分鐘期間軟件的下載很可能已完成。
另外，通過(guò)將IMEI-SV以外的參數(shù)設(shè)定為UE標(biāo)識(shí)符，就例如可以將上述技術(shù)應(yīng)用于中間設(shè)備或應(yīng)用的更新。
在本實(shí)施方式中，如前所述，為了更新特定移動(dòng)終端中的軟件，網(wǎng)絡(luò)向?qū)ず糁甘拘诺赖拿總€(gè)比特寫(xiě)“1”，以使得所有移動(dòng)終端都可以接收數(shù)據(jù)。此外，網(wǎng)絡(luò)使尋呼信道包含關(guān)于目標(biāo)移動(dòng)終端類型以及需要更新的移動(dòng)終端軟件的當(dāng)前版本的信息(見(jiàn)圖7至9)。
圖10的流程圖示出了圖3所示的服務(wù)器6的操作。參照?qǐng)D1至10，將對(duì)根據(jù)本發(fā)明實(shí)施方式的服務(wù)器6的操作進(jìn)行說(shuō)明。當(dāng)要為版本升級(jí)等改變軟件時(shí)(圖10，步驟S1)，服務(wù)器6在被預(yù)設(shè)為廣播分發(fā)時(shí)間的時(shí)刻(例如在移動(dòng)終端1較少使用的午夜)(圖10，步驟S2)，通過(guò)廣播部件65來(lái)廣播軟件改變的內(nèi)容(圖10，步驟S3)。
在廣播分發(fā)被執(zhí)行預(yù)設(shè)的次數(shù)(＝L)之前，服務(wù)器6重復(fù)以上處理(圖10，步驟S4)。此外，在被預(yù)設(shè)為廣播分發(fā)周期(例如一周、一個(gè)月等)的天數(shù)(＝M)期間，服務(wù)器6在每天的廣播分發(fā)時(shí)間執(zhí)行以上處理(圖10，步驟S5)。
在作為廣播分發(fā)周期的天數(shù)(＝M)過(guò)去以后(圖10，步驟S5)，服務(wù)器6在被預(yù)設(shè)為多播分發(fā)時(shí)間的時(shí)刻(圖10，步驟S6)，多播OTASP請(qǐng)求(圖10，步驟S7)。
如果即便只有一個(gè)終端對(duì)請(qǐng)求進(jìn)行響應(yīng)(圖10，步驟S8)，則服務(wù)器6也通過(guò)多播部件64多播軟件改變的內(nèi)容(圖10，步驟S9)。在被預(yù)設(shè)為多播分發(fā)周期(例如一周、一個(gè)月等)的天數(shù)(＝K)期間，服務(wù)器6在每天的多播分發(fā)時(shí)間執(zhí)行以上處理(圖10，步驟S10)。
在完成軟件的多播分發(fā)之后，可以提示每個(gè)終端利用諸如位置注冊(cè)信息之類的信息來(lái)更新軟件版本。
圖11的流程圖示出了圖3所示的移動(dòng)終端1的操作。參照?qǐng)D1至9和圖11，將對(duì)根據(jù)本發(fā)明實(shí)施方式的移動(dòng)終端1的操作進(jìn)行說(shuō)明。
移動(dòng)終端1按與上述相同的方式接收PCH(圖11，步驟S21至S23)。移動(dòng)終端1對(duì)接收到的PCH進(jìn)行分析，以識(shí)別是要執(zhí)行傳統(tǒng)數(shù)據(jù)接收、傳統(tǒng)MBMS(多媒體廣播/多播業(yè)務(wù))、廣播OTASP還是多播OTASP(圖11，步驟S24和S25)。這里，尚未確定MBMS的規(guī)約，并且可以使用PCH以外的CH。對(duì)“MBMS”的說(shuō)明可以在3GPP TS23.246V0.32.01(2002-06)中找到。
在廣播OTASP(圖11，步驟S24)的情況下，由于網(wǎng)絡(luò)側(cè)不需要確認(rèn)接受OTASP的移動(dòng)終端的存在，因此移動(dòng)終端1不發(fā)送對(duì)來(lái)自網(wǎng)絡(luò)側(cè)的信號(hào)的響應(yīng)，并準(zhǔn)備接收OTASP數(shù)據(jù)(圖11，步驟S30)。PCH包含用于接收數(shù)據(jù)的信息。
另一方面，在多播OTASP(圖11，步驟S25)的情況下，由于網(wǎng)絡(luò)側(cè)必須確認(rèn)接受OTASP的移動(dòng)終端的存在，因此移動(dòng)終端1發(fā)送RRC(無(wú)線電資源控制)連接請(qǐng)求，作為對(duì)尋呼消息或請(qǐng)求的響應(yīng)(圖11，步驟S27)。此后，移動(dòng)終端1準(zhǔn)備接收OTASP數(shù)據(jù)(圖11，步驟S28)。
順帶提及，在廣播OTASP或多播OTASP的情況下，移動(dòng)終端1將其類型(終端類別)和軟件版本與PCH中所包含的相比較(圖11，步驟S26至S29)。
作為比較的結(jié)果，如果它們不匹配，則移動(dòng)終端1在此時(shí)返回空閑模式。如果它們匹配，則移動(dòng)終端基于來(lái)自PCH的信息，通過(guò)多播或廣播接收必要的數(shù)據(jù)(圖11，步驟S28和S30)。是使用多播還是廣播是在網(wǎng)絡(luò)側(cè)設(shè)定的，以便由移動(dòng)終端1在尋呼時(shí)識(shí)別。
圖12的順序圖示出了根據(jù)本發(fā)明實(shí)施方式的數(shù)據(jù)發(fā)送處理(當(dāng)OTASP通過(guò)多播執(zhí)行時(shí)的處理)。參照?qǐng)D3和圖12，將對(duì)OTASP通過(guò)多播被執(zhí)行時(shí)的處理進(jìn)行說(shuō)明。
當(dāng)存在需要更新軟件版本的移動(dòng)終端(UE#1、UE#2)時(shí)，服務(wù)器6將OTASP請(qǐng)求發(fā)送到GGSN 5(圖12，a1)。該消息包含終端類型和軟件版本信息，還包含服務(wù)器6的標(biāo)識(shí)符，以使得來(lái)自移動(dòng)終端(UE#1、UE#2)的響應(yīng)可被轉(zhuǎn)發(fā)到服務(wù)器6。在此情況下，指定數(shù)據(jù)傳送模式，并且RNC 3的操作根據(jù)傳送模式而變化。例如，這里設(shè)定多播作為傳送模式。
在接收到來(lái)自服務(wù)器6的OTASP請(qǐng)求之后，GGSN 5使用GTP(GPRS隧道傳送協(xié)議)-C消息將該請(qǐng)求轉(zhuǎn)發(fā)到SGSN 4(圖12，a2)。
在接收到來(lái)自GGSN 5的OTASP請(qǐng)求之后，SGSN 4使用RANAP(無(wú)線電接入網(wǎng)絡(luò)應(yīng)用部分)尋呼消息將該請(qǐng)求轉(zhuǎn)發(fā)到RNC 3(圖12，a3)。
當(dāng)RNC 3識(shí)別出目標(biāo)移動(dòng)終端(UE#1、UE#2)時(shí)，使用多播。因此，RNC 3將RRC尋呼消息發(fā)送到移動(dòng)終端(UE#1、UE#2)(圖12，a4)，并等待來(lái)自其的響應(yīng)。該尋呼是以前面結(jié)合圖6至圖9所描述的方式執(zhí)行的。
在多播情況下，移動(dòng)終端(UE#1、UE#2)將RRC連接請(qǐng)求發(fā)送到RNC 3。在本實(shí)施方式中，移動(dòng)終端(UE#1、UE#2)將其類型及軟件版本與尋呼信道中所包含的相比較，并且如果它們匹配(圖12，a5)，則將RRC連接請(qǐng)求發(fā)送到RNC 3。
此后，移動(dòng)終端(UE#1、UE#2)配置缺省隧道(圖12，a7)以加入服務(wù)器6，并從而加入服務(wù)器6以指示出接收OTASP數(shù)據(jù)的意圖(圖12，a8)。該處理是基于3GPP MBMS標(biāo)準(zhǔn)來(lái)執(zhí)行的。
當(dāng)接收到即使只來(lái)自一個(gè)移動(dòng)終端(UE#1、UE#2)的加入響應(yīng)時(shí)，服務(wù)器6也會(huì)開(kāi)始OTASP數(shù)據(jù)的發(fā)送(圖12，a9)。網(wǎng)絡(luò)上的每個(gè)設(shè)備項(xiàng)基于MBMS來(lái)發(fā)送數(shù)據(jù)。
在OTASP數(shù)據(jù)發(fā)送完成之后，服務(wù)器6使用OTASP完成消息將數(shù)據(jù)發(fā)送的完成通知GGSN 5(圖12，a10)。OTASP完成消息包含OTASP請(qǐng)求中包含的終端類型和軟件版本信息。
在接收到來(lái)自服務(wù)器6的OTASP完成消息之后，GGSN 5使用GTP-C消息將該消息轉(zhuǎn)發(fā)到SGSN 4(圖12，a11)。在接收到來(lái)自GGSN 5的OTASP完成消息之后，SGSN 4使用RANAP消息將該消息轉(zhuǎn)發(fā)到RNC 3(圖12，a12)。
在接收到來(lái)自SGSN 4的OTASP完成消息之后，RNC 3使用RRC消息將OTASP完成消息發(fā)送到目標(biāo)移動(dòng)終端(UE#1、UE#2)，以將數(shù)據(jù)發(fā)送的完成告知終端(圖12，a13)。前面結(jié)合圖6至圖9描述的方法也適用于此消息。
當(dāng)正確接收到OTASP數(shù)據(jù)并完成了軟件更新時(shí)，移動(dòng)終端(UE#1、UE#2)更新其中的軟件版本信息(圖12，a14)。
圖13的順序圖示出了根據(jù)本發(fā)明實(shí)施方式的數(shù)據(jù)發(fā)送處理(當(dāng)OTASP通過(guò)廣播執(zhí)行時(shí)的處理)。參照?qǐng)D3和圖13，將對(duì)OTASP通過(guò)廣播執(zhí)行時(shí)的處理進(jìn)行說(shuō)明。
當(dāng)存在需要更新軟件版本的移動(dòng)終端(UE#1、UE#2)時(shí)，服務(wù)器6將OTASP請(qǐng)求發(fā)送到GGSN 5(圖13，a21)。該消息包含終端類型和軟件版本信息。此外，指定了數(shù)據(jù)傳送模式，并且RNC 3的操作根據(jù)傳送模式而變化。在此情況下，服務(wù)器6不需要接收來(lái)自移動(dòng)終端(UE#1、UE#2)的信號(hào)，因此該消息不包含用于將信號(hào)轉(zhuǎn)發(fā)到服務(wù)器6的信息。
在接收到來(lái)自服務(wù)器6的OTASP請(qǐng)求之后，GGSN 5使用GTP-C消息將該請(qǐng)求轉(zhuǎn)發(fā)到SGSN 4(圖13，a22)。在接收到來(lái)自GGSN 5的OTASP請(qǐng)求之后，SGSN 4使用RANAP尋呼消息將該請(qǐng)求轉(zhuǎn)發(fā)到RNC 3(圖13，a23)。
當(dāng)無(wú)需識(shí)別目標(biāo)移動(dòng)終端(UE#1、UE#2)時(shí)，使用廣播。因此，RNC 3發(fā)送廣播尋呼消息而非通常的尋呼消息，所述通常的尋呼消息包含等待來(lái)自目標(biāo)移動(dòng)終端(UE#1、UE#2)的響應(yīng)的指示(圖13，a24)。前面結(jié)合圖6至圖9描述的方法也適用于此消息。此外，該處理是基于3GPP MBMS標(biāo)準(zhǔn)來(lái)執(zhí)行的。
如上所述，移動(dòng)終端(UE#1、UE#2)將其類型及軟件版本與尋呼信道中所包含的相比較，并且如果它們匹配(圖13，a25)，則準(zhǔn)備接收OTASP數(shù)據(jù)(圖13，a26)。該處理是基于3GPP MBMS標(biāo)準(zhǔn)來(lái)執(zhí)行的。
此后，服務(wù)器6開(kāi)始OTASP數(shù)據(jù)的發(fā)送(圖13，a27)。網(wǎng)絡(luò)上的每個(gè)設(shè)備項(xiàng)基于3GPP MBMS標(biāo)準(zhǔn)來(lái)發(fā)送數(shù)據(jù)。
在OTASP數(shù)據(jù)發(fā)送完成之后，服務(wù)器6使用OTASP完成消息將數(shù)據(jù)發(fā)送的完成通知GGSN 5(圖13，a28)。OTASP完成消息包含OTASP請(qǐng)求中所包含的終端類型和軟件版本信息。
在接收到來(lái)自服務(wù)器6的OTASP完成消息之后，GGSN 5使用GTP-C消息將該消息轉(zhuǎn)發(fā)到SGSN 4(圖13，a29)。在接收到來(lái)自GGSN 5的OTASP完成消息之后，SGSN 4使用RANAP消息將該消息轉(zhuǎn)發(fā)到RNC 3(圖13，a30)。
在接收到來(lái)自SGSN 4的OTASP完成消息之后，RNC 3使用RRC消息將OTASP完成消息發(fā)送到目標(biāo)移動(dòng)終端(UE#1、UE#2)，以將數(shù)據(jù)發(fā)送的完成告知終端(圖13，a31)。前面結(jié)合圖6至圖9描述的方法也適用于此消息。
當(dāng)正確接收到OTASP數(shù)據(jù)并完成了軟件更新時(shí)，移動(dòng)終端(UE#1、UE#2)更新其中的軟件版本信息(圖13，a32)。
圖14的流程圖示出了圖3所示的服務(wù)器6側(cè)的操作(當(dāng)OTASP通過(guò)多播執(zhí)行時(shí)的操作)。參照?qǐng)D3和圖14，將對(duì)OTASP通過(guò)多播執(zhí)行時(shí)在服務(wù)器6側(cè)的處理進(jìn)行說(shuō)明。
在多播情況下，當(dāng)不存在目標(biāo)移動(dòng)終端1時(shí)，不發(fā)送數(shù)據(jù)。因此，服務(wù)器6激活定時(shí)器(未示出)，以等待與OTASP請(qǐng)求的發(fā)送同時(shí)的來(lái)自移動(dòng)終端1的響應(yīng)(圖14，步驟S41)。
如果在定時(shí)器超時(shí)前沒(méi)有接收到來(lái)自移動(dòng)終端1的響應(yīng)(圖14，步驟S42和S43)，則服務(wù)器6終止OTASP(圖14，步驟S45)。所述定時(shí)器用于檢查目標(biāo)移動(dòng)終端1的存在，以及收集來(lái)自目標(biāo)移動(dòng)終端群組的響應(yīng)。
如果在定時(shí)器超時(shí)前接收到了來(lái)自移動(dòng)終端1的響應(yīng)(圖14，步驟S42和S43)，則服務(wù)器6開(kāi)始OTASP數(shù)據(jù)的發(fā)送(圖14，步驟S44)。
當(dāng)執(zhí)行多播時(shí)，如上所述，即使僅接收到一個(gè)來(lái)自移動(dòng)終端的響應(yīng)，服務(wù)器6也開(kāi)始OTASP數(shù)據(jù)的發(fā)送，而如果沒(méi)有響應(yīng)，則其不發(fā)送數(shù)據(jù)，并終止OTASP。
在以上說(shuō)明中，多播尋呼被用來(lái)更新終端的軟件版本。然而，多播尋呼還可被用來(lái)獲得使用特定版本軟件的終端數(shù)量的統(tǒng)計(jì)數(shù)據(jù)，或者用來(lái)向終端提供特定軟件。上述多播尋呼的應(yīng)用僅僅是示例性而非限制性地引用的。
圖15的流程圖示出了圖3所示的移動(dòng)終端1的數(shù)據(jù)處理操作。參照?qǐng)D3和圖15，將對(duì)移動(dòng)終端1的數(shù)據(jù)處理操作進(jìn)行說(shuō)明。
在OTASP數(shù)據(jù)接收開(kāi)始時(shí)，考慮到消息不到達(dá)的情況，移動(dòng)終端1激活定時(shí)器以等待OTASP完成消息(圖15，步驟S51和S52)。
在通過(guò)RRC消息被通知OTASP的完成(圖15，步驟S53)，并且成功更新軟件(圖15，步驟S54)之后，移動(dòng)終端1更新其中的軟件的版本信息(圖15，步驟S55)。
OTASP完成消息包含OTASP請(qǐng)求中所包含的終端類型和軟件版本信息。因此，如果在接收到OTASP完成消息之前重寫(xiě)了軟件版本信息，則移動(dòng)終端1無(wú)法接收該消息。
如果OTASP完成定時(shí)器超時(shí)(圖15，步驟S52)或在成功更新軟件之前報(bào)告了OTASP的完成(圖15，步驟S53和S54)，則移動(dòng)終端1丟棄在該時(shí)刻之前接收到的OTASP數(shù)據(jù)(圖15，步驟S56)。然后，移動(dòng)終端1終止操作，并使用先前的終端類型和軟件版本信息。可以引用如下情形作為軟件更新失敗的例子移動(dòng)終端1在完成數(shù)據(jù)接收之前被通知OTASP完成。
如上所述，在成功更新了軟件之后，移動(dòng)終端1更新其中的軟件版本信息。另一方面，當(dāng)未能更新軟件時(shí)，移動(dòng)終端1丟棄接收到的數(shù)據(jù)，并且不更新其中的軟件版本信息。
從而，移動(dòng)終端1如果成功更新了軟件則不會(huì)再次接收同樣的數(shù)據(jù)，而移動(dòng)終端1如果未能更新軟件版本則可以再次接收同樣的數(shù)據(jù)，這是因?yàn)樗诔晒Ω萝浖安粫?huì)更新軟件版本信息。
如上所述，根據(jù)本實(shí)施方式，MBMS被應(yīng)用于OTASP，以用于重寫(xiě)程序以更新軟件版本等。因此，每個(gè)移動(dòng)終端不浪費(fèi)其功率，并且可以高效地僅在軟件需要重寫(xiě)時(shí)才更新目標(biāo)終端群組中的軟件。
另外，利用了唯一地標(biāo)識(shí)移動(dòng)終端的信息(例如包含在IMEI-SV中的關(guān)于終端類型和軟件版本的信息)。從而，可以高效地將移動(dòng)終端分成群組。
此外，完成了軟件更新的移動(dòng)終端更新其中的軟件版本信息。因此，移動(dòng)終端可以避免對(duì)相同數(shù)據(jù)的重復(fù)接收。
權(quán)利要求
1.一種移動(dòng)通信系統(tǒng)，在該移動(dòng)通信系統(tǒng)中經(jīng)由無(wú)線電在服務(wù)器和移動(dòng)終端之間發(fā)送/接收數(shù)據(jù)，其中所述服務(wù)器至少包括如下裝置，該裝置用于通過(guò)向目標(biāo)移動(dòng)終端發(fā)送附有關(guān)于移動(dòng)終端類型的信息的請(qǐng)求來(lái)對(duì)所述目標(biāo)移動(dòng)終端進(jìn)行尋呼。
2.如權(quán)利要求1所述的移動(dòng)通信系統(tǒng)，其中所述請(qǐng)求除了關(guān)于移動(dòng)終端類型的信息以外，還附有關(guān)于移動(dòng)終端中的軟件版本的信息。
3.一種移動(dòng)通信系統(tǒng)，在該移動(dòng)通信系統(tǒng)中執(zhí)行空中業(yè)務(wù)提供，以基于從服務(wù)器經(jīng)由無(wú)線電發(fā)送來(lái)的數(shù)據(jù)來(lái)重寫(xiě)移動(dòng)終端中的軟件，其中所述服務(wù)器包括如下裝置，該裝置用于通過(guò)在要執(zhí)行空中業(yè)務(wù)提供時(shí)向目標(biāo)移動(dòng)終端發(fā)送附有關(guān)于移動(dòng)終端類型和軟件版本的信息的請(qǐng)求，來(lái)對(duì)所述目標(biāo)移動(dòng)終端進(jìn)行尋呼。
4.如權(quán)利要求3所述的移動(dòng)通信系統(tǒng)，其中所述移動(dòng)終端包括用于基于所述終端類型和軟件版本信息來(lái)確定所述請(qǐng)求是否指向所述終端的裝置；以及用于在確定了所述請(qǐng)求是指向所述終端之后基于從所述服務(wù)器發(fā)送來(lái)的數(shù)據(jù)來(lái)更新所述軟件的裝置。
5.如權(quán)利要求3或4所述的移動(dòng)通信系統(tǒng)，其中所述移動(dòng)終端包括用于基于所述請(qǐng)求所附有的信息來(lái)確定所述數(shù)據(jù)是要被多播還是廣播到所述終端的裝置；用于在確定了所述數(shù)據(jù)要被多播之后，在接收所述數(shù)據(jù)之前發(fā)送對(duì)所述請(qǐng)求的響應(yīng)的裝置；以及用于在確定了所述數(shù)據(jù)要被廣播之后，接收所述數(shù)據(jù)而不發(fā)送對(duì)所述請(qǐng)求的響應(yīng)的裝置。
6.如權(quán)利要求5所述的移動(dòng)通信系統(tǒng)，其中所述服務(wù)器重復(fù)地廣播所述數(shù)據(jù)，并且此后多播所述數(shù)據(jù)。
7.如權(quán)利要求3至6中任一項(xiàng)所述的移動(dòng)通信系統(tǒng)，其中，所述移動(dòng)終端包括如下裝置，該裝置用于在所述軟件已基于所述數(shù)據(jù)被更新之前防止所述軟件的版本信息被更新。
8.一種經(jīng)由無(wú)線電向移動(dòng)終端發(fā)送數(shù)據(jù)和從移動(dòng)終端接收數(shù)據(jù)的服務(wù)器，該服務(wù)器至少包括如下裝置，該裝置用于通過(guò)向目標(biāo)移動(dòng)終端發(fā)送附有關(guān)于移動(dòng)終端類型的信息的請(qǐng)求來(lái)對(duì)所述目標(biāo)移動(dòng)終端進(jìn)行尋呼。
9.如權(quán)利要求8所述的服務(wù)器，其中所述請(qǐng)求除了關(guān)于移動(dòng)終端類型的信息以外，還附有關(guān)于移動(dòng)終端中的軟件版本的信息。
10.一種經(jīng)由無(wú)線電發(fā)送數(shù)據(jù)的服務(wù)器，該服務(wù)器用于執(zhí)行空中業(yè)務(wù)提供以重寫(xiě)移動(dòng)終端中的軟件，所述服務(wù)器包括如下裝置，該裝置用于通過(guò)在要執(zhí)行空中業(yè)務(wù)提供時(shí)向目標(biāo)移動(dòng)終端發(fā)送附有關(guān)于移動(dòng)終端類型和軟件版本的信息的請(qǐng)求，來(lái)對(duì)所述目標(biāo)移動(dòng)終端進(jìn)行尋呼。
11.如權(quán)利要求10所述的服務(wù)器，所述服務(wù)器重復(fù)地廣播所述數(shù)據(jù)，并且此后多播所述數(shù)據(jù)。
12.一種移動(dòng)終端，該移動(dòng)終端在接收到包含至少關(guān)于其終端類型和軟件版本的信息的尋呼消息之后進(jìn)行操作。
13.一種用于如下移動(dòng)通信系統(tǒng)中的移動(dòng)終端，在所述移動(dòng)通信系統(tǒng)中執(zhí)行空中業(yè)務(wù)提供，以基于從服務(wù)器經(jīng)由無(wú)線電發(fā)送來(lái)的數(shù)據(jù)來(lái)重寫(xiě)移動(dòng)終端中的軟件，所述移動(dòng)終端包括用于基于在要執(zhí)行空中業(yè)務(wù)提供時(shí)接收到的請(qǐng)求所附有的終端類型和軟件版本信息來(lái)確定該請(qǐng)求是否指向所述終端的裝置；以及用于在確定了所述請(qǐng)求是指向所述終端之后基于從所述服務(wù)器發(fā)送來(lái)的數(shù)據(jù)來(lái)更新所述軟件的裝置。
14.如權(quán)利要求13所述的移動(dòng)終端，還包括用于基于所述請(qǐng)求所附有的信息確定所述數(shù)據(jù)是要被多播還是廣播到所述終端的裝置；用于在確定了所述數(shù)據(jù)要被多播之后，在接收所述數(shù)據(jù)之前發(fā)送對(duì)所述請(qǐng)求的響應(yīng)的裝置；以及用于在確定了所述數(shù)據(jù)要被廣播之后，接收所述數(shù)據(jù)而不發(fā)送對(duì)所述請(qǐng)求的響應(yīng)的裝置。
15.如權(quán)利要求13或14所述的移動(dòng)終端，還包括如下裝置，該裝置用于在所述軟件已基于所述數(shù)據(jù)被更新之前防止所述軟件的版本信息被更新。
16.一種應(yīng)用于如下移動(dòng)通信系統(tǒng)的數(shù)據(jù)發(fā)送方法，在所述移動(dòng)通信系統(tǒng)中經(jīng)由無(wú)線電在服務(wù)器和移動(dòng)終端之間發(fā)送/接收數(shù)據(jù)，所述方法在所述服務(wù)器側(cè)至少包括如下步驟通過(guò)向目標(biāo)移動(dòng)終端發(fā)送附有關(guān)于移動(dòng)終端類型的信息的請(qǐng)求來(lái)對(duì)所述目標(biāo)移動(dòng)終端進(jìn)行尋呼。
17.如權(quán)利要求16所述的數(shù)據(jù)發(fā)送方法，其中所述請(qǐng)求除了關(guān)于移動(dòng)終端類型的信息以外，還附有關(guān)于移動(dòng)終端中的軟件版本的信息。
18.一種應(yīng)用于如下移動(dòng)通信系統(tǒng)的數(shù)據(jù)發(fā)送方法，在所述移動(dòng)通信系統(tǒng)中執(zhí)行空中業(yè)務(wù)提供，以基于從服務(wù)器經(jīng)由無(wú)線電發(fā)送來(lái)的數(shù)據(jù)來(lái)重寫(xiě)移動(dòng)終端中的軟件，所述方法在所述服務(wù)器側(cè)包括如下步驟通過(guò)在要執(zhí)行空中業(yè)務(wù)提供時(shí)向目標(biāo)移動(dòng)終端發(fā)送附有關(guān)于移動(dòng)終端類型和軟件版本的信息的請(qǐng)求，來(lái)對(duì)所述目標(biāo)移動(dòng)終端進(jìn)行尋呼。
19.如權(quán)利要求18所述的數(shù)據(jù)發(fā)送方法，在所述移動(dòng)終端側(cè)包括如下步驟基于所述終端類型和軟件版本信息確定所述請(qǐng)求是否指向所述終端；以及在確定了所述請(qǐng)求是指向所述終端之后，基于從所述服務(wù)器發(fā)送來(lái)的數(shù)據(jù)來(lái)更新所述軟件。
20.如權(quán)利要求18或19所述的數(shù)據(jù)發(fā)送方法，在所述移動(dòng)終端側(cè)還包括如下步驟基于所述請(qǐng)求所附有的信息確定所述數(shù)據(jù)是要被多播還是廣播到所述終端；在確定了所述數(shù)據(jù)要被多播之后，在接收所述數(shù)據(jù)之前發(fā)送對(duì)所述請(qǐng)求的響應(yīng)；以及在確定了所述數(shù)據(jù)要被廣播之后，接收所述數(shù)據(jù)而不發(fā)送對(duì)所述請(qǐng)求的響應(yīng)。
21.如權(quán)利要求20所述的數(shù)據(jù)發(fā)送方法，其中所述服務(wù)器重復(fù)地廣播所述數(shù)據(jù)，并且此后多播所述數(shù)據(jù)。
22.如權(quán)利要求18至21中任一項(xiàng)所述的數(shù)據(jù)發(fā)送方法，在所述移動(dòng)終端側(cè)包括如下步驟在所述軟件已基于所述數(shù)據(jù)被更新之前，防止所述軟件的版本信息被更新。
全文摘要
一種移動(dòng)通信系統(tǒng)，其能夠僅在需要軟 件重寫(xiě)時(shí)高效地更新相關(guān)終端的軟件。當(dāng)便攜式終端(UE#1，UE#2)的軟件必須被更新時(shí)，服務(wù)器將包含終端類型和軟件版本信息在內(nèi)的OTASP請(qǐng)求發(fā)送到GGSN。OTASP請(qǐng)求經(jīng)由GGSN、SGSN和RNC被傳送到便攜式終端(UE#1，UE#2)。便攜式終端(UE#1，UE#2)將其終端類型和軟件版本與尋呼信道中所包含的終端類型和軟件版本相比較，如果它們匹配，則將RRC連接請(qǐng)求發(fā)送到RNC。
文檔編號(hào)H04W8/22GK1795694SQ20048001462
公開(kāi)日2006年6月28日 申請(qǐng)日期2004年5月26日 優(yōu)先權(quán)日2003年5月28日
發(fā)明者板羽直人, 田村利之, 坂田正行 申請(qǐng)人:日本電氣株式會(huì)社