专利名称：移动通信系统、服务器、移动终端及其数据发送方法
技术领域：
本发明涉及移动通信系统、服务器、移动终端及应用在其上的数据发送方法，尤其涉及用于更新移动电话中的软件的数据发送方法。
背景技术：
在近来的移动电话系统中，移动电话服务的订户已在迅速增加，并已出现了已经售出的移动电话被召回以修复其故障的情况。
为了包括避免召回移动电话在内的多种目的，3GPP2(第3代合作伙伴计划2)已在研究OTASP(空中业务提供)，用于经由无线电来重写或更新移动终端中的软件(例如参见非专利文献1)。
在此情况下，寻呼(paging)可以用作指定要重写软件的移动终端的技术。在寻呼技术中，当有传入移动终端的呼叫或数据时，需要将该呼叫通知给移动终端，并通过广播将该呼叫通知给该移动终端注册了位置的位置注册区域内的所有移动终端。因此，移动终端识别出对其的寻呼，这是因为其一直在监视寻呼信道，即使在空闲模式中也是如此(例如参见非专利文献2)。
然而，将数据逐个转发到每个移动终端是低效的，因此提出了将数据广播到所有需要重写软件的移动终端的技术(例如参见专利文献1和2)。
专利文献1日本专利申请早期公开第2001-28787号(第7和第8段，图1)专利文献2日本专利申请早期公开第2003-51796号(第6至第8段，图1)非专利文献12000年6月，3GPP2 Access Network InterfaceInteroperability Specification Release A
非专利文献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页发明内容本发明要解决的问题在上述的3GPP2所审阅的OTASP中，针对每个移动终端发送数据，该技术并未充分利用无线电的如下特性，即多个移动终端可以同时接收相同的数据。逐个地向每个移动终端发送数据，这导致了移动通信系统中的拥塞。
此外，根据将数据向所有需要重写软件的移动终端广播的技术，无需重写软件的移动终端也接收数据，并在确定出不需要该数据时必须丢弃该数据。换言之，该技术所具有的问题在于，即使不需要重写其软件，移动终端也必须接收数据并对该数据的必要性进行确定，这导致移动终端功耗的增加。
因此，本发明的目的在于提供一种移动通信系统、服务器、移动终端及应用在其上的数据发送方法，其能够高效地仅在需要重写软件时更新目标终端群组中的软件。
解决问题的手段根据本发明的一个方案，提供了一种移动通信系统，其中经由无线电在服务器和移动终端之间发送/接收数据，其中所述服务器至少包括如下装置，该装置用于通过向目标移动终端发送附有关于移动终端类型的信息的请求来对所述目标移动终端进行寻呼。
根据本发明的另一方案，提供了一种移动通信系统，其中执行OTASP(空中业务提供)以基于从服务器经由无线电发送来的数据来重写和更新移动终端中的软件，其中所述服务器包括如下装置，该装置用于在要执行OTASP时，通过向目标移动终端发送附有关于移动终端类型和软件版本的信息的请求来对所述目标移动终端进行寻呼。
根据本发明的另一方案，提供了一种经由无线电向移动终端发送数据和从移动终端接收数据的服务器，其至少包括如下装置，该装置用于通过向目标移动终端发送附有关于移动终端类型的信息的请求来对所述目标移动终端进行寻呼。
根据本发明的另一方案，提供了一种服务器，该服务器经由无线电发送数据，其用于执行OTASP(空中业务提供)以重写移动终端中的软件，所述服务器包括如下装置，该装置用于在要执行OTASP时，通过向目标移动终端发送附有关于移动终端类型和软件版本的信息的请求来对所述目标移动终端进行寻呼。
根据本发明的另一方案，提供了一种移动通信系统中的移动终端，在所述移动通信系统中执行OTASP(空中业务提供)，以基于从服务器经由无线电发送来的数据重写移动终端中的软件，所述移动终端包括用于基于在要执行OTASP时接收到的请求所附有的终端类型和软件版本信息确定该请求是否指向所述终端的装置；以及用于在确定了所述请求是指向所述终端时，基于从服务器发送来的数据更新软件的装置。
根据本发明的另一方案，提供了一种应用于移动通信系统的数据发送方法，在所述移动通信系统中经由无线电在服务器和移动终端之间发送/接收数据，所述方法在服务器侧至少包括如下步骤通过向目标移动终端发送附有关于移动终端类型的信息的请求来对所述目标移动终端进行寻呼。
根据本发明的另一方案，提供了一种应用于移动通信系统的数据发送方法，在所述移动通信系统中执行OTASP(空中业务提供)，以基于从服务器经由无线电发送来的数据重写移动终端中的软件，所述方法在服务器侧包括如下步骤在要执行OTASP时，通过向目标移动终端发送附有关于移动终端类型和软件版本的信息的请求来对所述目标移动终端进行寻呼。
如上所述，本发明的移动通信系统的特征在于，在移动通信广播或多播中，服务器在没有来自目标移动终端群组的请求的情况下将数据分发到所述目标移动终端群组，从而更新移动终端中的软件。此外，已被更新一次的软件不会被重复更新。
一般而言，在广播情况下，所有移动终端都可接收数据。然而，根据本发明，只有目标移动终端可以接收数据。
此外，一般而言，在多播情况下，移动终端的用户根据他/她自己的意愿加入业务以接收数据。然而，本发明提出服务器使用唯一地标识移动终端的信息，从网络侧对该移动终端进行寻呼，所述信息例如是IMEI-SV(国际移动台设备标识和软件版本号)。
另外，根据本发明，检查软件的完好性。因此，在成功更新软件的情况下不再接收相同的数据，而在失败的情况下可以再次接收相同的数据。
在使用广播的OTASP(空中业务提供)中，网络侧不需要确认目标移动终端的存在，并且不接收来自移动终端的响应。因此，可以减少网络侧的负担。然而，存在即使该区域中没有驻留的目标移动终端也发送了数据的情况。在这种情况下，执行OTASP以基于从服务器经由无线电发送的数据来重写移动终端中的软件。
另一方面，在使用多播的OTASP中，网络侧必须确认目标移动终端的存在，因此接收来自移动终端的响应。因此，网络侧的负担增加。然而，可以在没有驻留的目标移动终端的情况下避免将数据发送到该区域。
在最初的若干次中，可以使用广播，这是因为预期会存在多个目标移动终端。然后，在使用广播若干次之后，可以使用多播。从而，可以实现高效的OTASP。
3GPP当前正在审阅MBMS(多媒体广播/多播业务)。MBMS致力于通过将数据发送给区域中所有移动终端的广播，以及将数据仅发送给希望接收数据的移动终端群组的多播，来高效地利用无线电资源。该技术使得能将必需的数据仅发送给特定移动终端的群组。
在当前的3GPP规约中，每个移动终端检查该终端已注册到的寻呼指示信道(PICH)的一个比特。当该比特指示“1”时，移动终端从寻呼信道(PCH)中读取信息，以确定传入数据是否去往该终端。根据本发明，与3GPP规约一样，处于空闲模式的移动终端根据来自网络的指令间歇地接收寻呼指示信道。
为了更新特定移动终端中的软件，网络向寻呼指示信道的每个比特写“1”，以使得所有移动终端可以接收数据。此外，网络使寻呼信道包含关于目标移动终端类型(终端类别或分类)以及需要更新的移动终端软件的当前版本的信息。
已被寻呼指示信道指示接收寻呼信道的所有移动终端中的每一个都将其类型(终端类别)和软件版本与寻呼信道中所包含的相比较。作为比较结果，如果它们不匹配，则移动终端此时返回空闲模式。如果它们匹配，则移动终端基于来自寻呼信道的信息，通过多播或广播来接收必需的数据。要使用多播还是广播，这是在网络侧设定的，以便由移动终端在寻呼时识别。
在多播情况下，如果即便只有一个来自移动终端的响应，则也开始数据发送，而如果没有响应，则OTASP终止。
当成功更新了软件版本时，移动终端更新其中的软件版本信息。另一方面，当未能更新软件版本时，移动终端丢弃接收到的数据，并且不更新其中的软件的版本信息。从而，已成功更新了软件版本的移动终端不会再次接收相同的数据，而未能更新软件版本的移动终端可以再次接收相同的数据，直到其成功更新软件版本。
本发明的效果如上所述，根据本发明，每个移动终端都不浪费其功率，并且可以高效地仅在需要重写软件时才更新目标终端群组中的软件。
图1示出了根据本发明实施方式的移动通信系统的操作实施例。
图2示出了根据本发明实施方式的移动通信系统的操作实施例。
图3的框图示出了根据本发明实施方式的移动通信系统的构造。
图4的框图示出了图3所示的服务器的构造。
图5的框图示出了图3所示的移动终端的构造。
图6示出了根据本发明的PICH的构造，以及PICH与PCH之间的关系。
图7示出了PCH中的UE标识符的改变的图像。
图8示出了PCH中的UE标识符的改变的图像。
图9示出了PCH中的UE标识符的改变的图像。
图10的流程图示出了图3所示的服务器的操作。
图11的流程图示出了图3所示的移动终端的操作。
图12的顺序图示出了根据本发明实施方式的OTASP数据发送处理。
图13的顺序图示出了根据本发明实施方式的OTASP数据发送处理。
图14的流程图示出了图3所示的服务器侧的操作。
图15的流程图示出了图3所示的移动终端的数据处理操作。
具体实施例方式
现在参照附图，将详细给出对本发明优选实施方式的说明。图1和图2示出了根据本发明实施方式的移动通信系统的操作实施例。在图1所示的该实施方式的移动通信系统中，在移动通信广播或多播时，服务器(未示出)将数据分发到目标移动终端1-1至1-5的群组而无需来自这些移动终端的请求，从而更新移动终端1-1至1-5中的软件。另外，已被更新一次的软件将不被重复更新。
在普通广播的情况下，所有移动终端1-1至1-5都可以接收数据。同时，在本实施方式中，仅目标移动终端1-1和1-3可以接收数据。
此外，在普通多播的情况下，移动终端1-1至1-5的用户按其自己的意愿加入业务以接收数据。同时，在本实施方式中，服务器使用唯一标识移动终端1-1至1-5的信息从网络侧对这些移动终端进行寻呼，所述信息例如是IMEI-SV(国际移动台设备标识和软件版本号)。对“IMEI-SV”的说明可以在3GPP TS23.003V5.5.1(2003-1)，chapter 6.2.2中找到。
移动终端1-1至1-5具有检查软件完好性的功能，以便在成功更新了软件时不接收相同的数据，并在未能更新软件时接收相同的数据。
在图1中，数据(用于A型终端的关于版本为“n”的软件的数据)通过节点B(基站)发送到移动终端(UE用户设备)1-1至1-5。所述数据仅被软件版本为“n”的A型移动终端1-1和1-3接收，而不被B型移动终端1-4、软件版本早于“n”的A型移动终端1-2和软件版本晚于“n”的A型移动终端1-5所接收。
在使用广播的OTASP(空中业务提供)中，网络侧不需要确认目标移动终端1-1和1-3的存在，并且不从其接收响应。因此，可以减少网络侧的负担。然而存在如下情况即使目标移动终端1-1和1-3未驻留于该区域内，也发送了数据。在这种情况下，执行OTASP，以基于从服务器经由无线电发送的数据来重写移动终端1-1至1-5中的软件。对“OTASP”的说明可以在3GPP TR23.8466.1.0(2002-12)中找到。
另一方面，在使用多播的OTASP中，网络侧必须确认目标移动终端1-1和1-3的存在，因而接收来自所述移动终端中每一个的响应。因此，网络侧的负担增加了。然而，可以避免向目标移动终端1-1和1-3未驻留的区域发送数据。
因此，在本实施方式中，在最初的若干次中使用广播，这是因为预期会存在多个目标移动终端。然后，在使用广播若干次之后，使用多播。从而，可以实现高效的OTASP。
图2示出了根据该实施方式的广播和多播的应用实施例。在图2的实施例中，移动终端UE#1至UE#10中的软件被重写，软件版本从“3”更新到“4”。
第一天，服务器广播关于版本为“4”的软件的数据。当对终端进行寻呼时，服务器利用当前版本“3”。类型和软件版本与服务器所指示的相匹配的终端对广播进行响应。在图2中，移动终端UE#1、UE#5，以及UE#7至UE#9是开机的，并将从服务器接收到的关于版本为“4”的软件的数据写入其中。其它移动终端UE#2至UE#4、UE#6和UE#10是关机的，因此不向其中写入来自服务器的关于版本为“4”的软件的数据。
随后，第二天，服务器还广播关于版本为“4”的软件的数据。此时，由于数据已经写入到移动终端UE#1、UE#5，以及UE#7至UE#9，因此其软件版本与服务器所指示的不匹配，这些终端不对广播进行响应。此外，移动终端UE#2至UE#4是开机的，并将从服务器接收到的关于版本为“4”的软件的数据写入其中。其它移动终端UE#6和UE#10仍关机，因此不向其中写入来自服务器的关于版本为“4”的软件的数据。
在预设的N-1天使用广播之后，在第N天，服务器向移动终端UE#6和UE#10多播关于版本为“4”的软件的数据。此时，由于数据已被写入移动终端UE#1至UE#5以及UE#7至UE#9，因此这些终端不对多播进行响应。
图3的框图示出了根据本发明实施方式的移动通信系统的构造。参照图3，本实施方式的移动通信系统包括移动终端(UE)1、节点B(基站)2-1和2-2、RNC(无线电网络控制器)3、SGSN[服务GPRS(通用分组无线电业务)支持节点]4、GGSN(网关GPRS支持节点)5、服务器6和IP(因特网协议)网络100。
在以下说明中，为简单起见，将寻呼指示信道称为PICH，将寻呼信道称为PCH，并利用3GPP(第3代合作伙伴计划)中的通用术语。
图4的框图示出了图3所示的服务器6的构造。参照图4，服务器6包括数据输入/输出部件61、数据存储装置62、数据发送控制器(调度器)63、多播部件64和广播部件65。
数据输入/输出部件61从其它设备(例如提供诸如安装在移动终端1中的控制程序和应用程序之类的程序的程序生产商的设备)接收用于更新程序等的数据，并将该数据存储在数据存储装置62中。此外，数据输入/输出部件61还读出存储在数据存储装置62中的数据，并将其发送到数据发送控制器63，以发出用于基于该数据进行更新的指令。
数据发送控制器63从数据输入/输出部件61接收数据，并创建如前所述地通过广播和多播分发数据的时间表。根据该时间表，数据发送控制器63将数据馈送到多播部件64或广播部件65。
多播部件64根据数据发送控制器63创建的时间表将数据发送到GGSN 5，以将数据多播到移动终端1。多播部件64需要等待来自GGSN 5的响应。当未接收到响应时，多播部件64确定出不存在属于该服务器的目标终端，并且将不执行数据发送。广播部件65根据数据发送控制器63创建的时间表将数据发送到GGSN 5，以将数据广播到移动终端1。与多播部件64不同，广播部件65无需等待来自GGSN 5的响应。多播部件64和广播部件65每个都在预定时间段之后开始数据发送，在所述预定时间段期间每个终端可能已做好接收数据的准备。
图5的框图示出了图3所示的移动终端(UE)1的构造。参照图5，移动终端1包括天线11、无线电通信部件12、控制器13、基带部件18、语音输入/输出部件19、显示器20和键操作部件21。每个组件的操作是公知的，因此不在这里说明。
控制器13包括CPU(中央处理单元)14、存储器15、传送方法确定部件16和数据传送控制器17，其中所述存储器15用于存储CPU 14所执行的诸如控制程序和应用程序之类的程序。
传送方法确定部件16判断用于升级软件版本等的数据是要从服务器6广播还是多播。CPU 14和数据传送控制器17根据判断结果进行操作。
当用于升级软件版本等的数据要从服务器6广播或多播时，CPU 14和数据传送控制器17将终端的软件版本与来自服务器6的数据所指示的版本相比较。如果版本不匹配，则CPU 14和数据传送控制器17终止操作。如果版本匹配，则CPU 14和数据传送控制器17在要使用多播时向网络侧发送响应，而在要使用广播时不向网络侧进行发送，并准备接收数据。
在此情况下，移动终端1仅需要监视寻呼信道以及执行上述比较，并向接收数据所必需的部件供电。与传统的广播数据接收不同，移动终端1无需向所有部件供电。
图6示出了根据本发明的PICH的构造，以及PICH与PCH之间的关系。在图6中，无法单独与RNC 3通信的移动终端1{空闲，小区/URA[UTRAN(UMTS陆地无线电接入网)注册区域]_PCH}在RNC 3所指示的定时间歇地接收PICH。该操作是移动终端1接收数据所必需的。
移动终端1接收PICH的定时是从其标识符[IMSI(国际移动用户标识)]等的值计算出的。PICH的一个帧包含300个比特，其最后12个比特被保留。
此外，移动终端1所监视的PICH的一个比特也是从其标识符(IMSI)等的值计算出的。当移动终端1所监视的PICH的比特指示“1”时，移动终端1接收对应于PICH的PCH。
在当前的3GPP规约中，每个移动终端检查该终端已注册到的寻呼指示信道(PICH)的一个比特。当该比特指示“1”时，移动终端从寻呼信道(PCH)中读取信息，以确定传入数据是否指向该终端。在本实施方式中，与3GPP规约一样，处于空闲模式的移动终端根据来自网络的指令间歇地接收寻呼指示信道(见图6和7)。
图7至9示出了PCH中UE标识符的改变的图像。在图7至9中，由于PICH的帧号(0到4095)和比特数(288)的数值受限，因此PICH的每个比特并不总是分配给一个UE。
例如，如果PICH的一个比特被分配给3个UE，则通过将该比特设定为“1”，而使这3个UE接收一个PCH。然而，这3个UE极少会同时接收传入数据，必需指示该比特“1”应用于它们中的哪一个。这种指示是通过包含在PCH中的UE标识符来提供的。在接收到PCH之后，每个UE必须检查UE标识符以确定传入数据是不是去往该UE的。
这里，假定发送一个数据，并且多个UE同时接收该数据。即，数据要发送到的多个UE(软件为特定版本的特定类型的UE)需要同时接收数据。每个UE具有不同的标识符，因此PICH的每个比特都被设定为“1”以使得所有UE都可以接收数据。然而，在当前PCH中的UE标识符的情况下，对单独的UE设定UE标识符，这不适用于多个UE同时接收数据的情况。
因此，向UE标识符添加了IMEI-SV，并将数据要发送到的UE的类型和软件版本用作UE标识符。从而，可以将目标UE分成群组。虽然IMEI-SV包含标识每个UE的序列号，但这里并未使用序列号信息，这是因为希望特定UE的群组同时接收数据。
此外，如果如上所述，PICH的每个比特都被设定为“1”，则目标UE一起对寻呼消息或请求进行响应，这可能对上行链路无线电容量造成压力，同时还增加网络侧的处理负担。因此，将PICH的每个比特都设定为“1”可能不是最佳方式。例如，要设定为“1”的PICH的比特可以每几分钟移位10比特，在所述的几分钟期间软件的下载很可能已完成。
另外，通过将IMEI-SV以外的参数设定为UE标识符，就例如可以将上述技术应用于中间设备或应用的更新。
在本实施方式中，如前所述，为了更新特定移动终端中的软件，网络向寻呼指示信道的每个比特写“1”，以使得所有移动终端都可以接收数据。此外，网络使寻呼信道包含关于目标移动终端类型以及需要更新的移动终端软件的当前版本的信息(见图7至9)。
图10的流程图示出了图3所示的服务器6的操作。参照图1至10，将对根据本发明实施方式的服务器6的操作进行说明。当要为版本升级等改变软件时(图10，步骤S1)，服务器6在被预设为广播分发时间的时刻(例如在移动终端1较少使用的午夜)(图10，步骤S2)，通过广播部件65来广播软件改变的内容(图10，步骤S3)。
在广播分发被执行预设的次数(＝L)之前，服务器6重复以上处理(图10，步骤S4)。此外，在被预设为广播分发周期(例如一周、一个月等)的天数(＝M)期间，服务器6在每天的广播分发时间执行以上处理(图10，步骤S5)。
在作为广播分发周期的天数(＝M)过去以后(图10，步骤S5)，服务器6在被预设为多播分发时间的时刻(图10，步骤S6)，多播OTASP请求(图10，步骤S7)。
如果即便只有一个终端对请求进行响应(图10，步骤S8)，则服务器6也通过多播部件64多播软件改变的内容(图10，步骤S9)。在被预设为多播分发周期(例如一周、一个月等)的天数(＝K)期间，服务器6在每天的多播分发时间执行以上处理(图10，步骤S10)。
在完成软件的多播分发之后，可以提示每个终端利用诸如位置注册信息之类的信息来更新软件版本。
图11的流程图示出了图3所示的移动终端1的操作。参照图1至9和图11，将对根据本发明实施方式的移动终端1的操作进行说明。
移动终端1按与上述相同的方式接收PCH(图11，步骤S21至S23)。移动终端1对接收到的PCH进行分析，以识别是要执行传统数据接收、传统MBMS(多媒体广播/多播业务)、广播OTASP还是多播OTASP(图11，步骤S24和S25)。这里，尚未确定MBMS的规约，并且可以使用PCH以外的CH。对“MBMS”的说明可以在3GPP TS23.246V0.32.01(2002-06)中找到。
在广播OTASP(图11，步骤S24)的情况下，由于网络侧不需要确认接受OTASP的移动终端的存在，因此移动终端1不发送对来自网络侧的信号的响应，并准备接收OTASP数据(图11，步骤S30)。PCH包含用于接收数据的信息。
另一方面，在多播OTASP(图11，步骤S25)的情况下，由于网络侧必须确认接受OTASP的移动终端的存在，因此移动终端1发送RRC(无线电资源控制)连接请求，作为对寻呼消息或请求的响应(图11，步骤S27)。此后，移动终端1准备接收OTASP数据(图11，步骤S28)。
顺带提及，在广播OTASP或多播OTASP的情况下，移动终端1将其类型(终端类别)和软件版本与PCH中所包含的相比较(图11，步骤S26至S29)。
作为比较的结果，如果它们不匹配，则移动终端1在此时返回空闲模式。如果它们匹配，则移动终端基于来自PCH的信息，通过多播或广播接收必要的数据(图11，步骤S28和S30)。是使用多播还是广播是在网络侧设定的，以便由移动终端1在寻呼时识别。
图12的顺序图示出了根据本发明实施方式的数据发送处理(当OTASP通过多播执行时的处理)。参照图3和图12，将对OTASP通过多播被执行时的处理进行说明。
当存在需要更新软件版本的移动终端(UE#1、UE#2)时，服务器6将OTASP请求发送到GGSN 5(图12，a1)。该消息包含终端类型和软件版本信息，还包含服务器6的标识符，以使得来自移动终端(UE#1、UE#2)的响应可被转发到服务器6。在此情况下，指定数据传送模式，并且RNC 3的操作根据传送模式而变化。例如，这里设定多播作为传送模式。
在接收到来自服务器6的OTASP请求之后，GGSN 5使用GTP(GPRS隧道传送协议)-C消息将该请求转发到SGSN 4(图12，a2)。
在接收到来自GGSN 5的OTASP请求之后，SGSN 4使用RANAP(无线电接入网络应用部分)寻呼消息将该请求转发到RNC 3(图12，a3)。
当RNC 3识别出目标移动终端(UE#1、UE#2)时，使用多播。因此，RNC 3将RRC寻呼消息发送到移动终端(UE#1、UE#2)(图12，a4)，并等待来自其的响应。该寻呼是以前面结合图6至图9所描述的方式执行的。
在多播情况下，移动终端(UE#1、UE#2)将RRC连接请求发送到RNC 3。在本实施方式中，移动终端(UE#1、UE#2)将其类型及软件版本与寻呼信道中所包含的相比较，并且如果它们匹配(图12，a5)，则将RRC连接请求发送到RNC 3。
此后，移动终端(UE#1、UE#2)配置缺省隧道(图12，a7)以加入服务器6，并从而加入服务器6以指示出接收OTASP数据的意图(图12，a8)。该处理是基于3GPP MBMS标准来执行的。
当接收到即使只来自一个移动终端(UE#1、UE#2)的加入响应时，服务器6也会开始OTASP数据的发送(图12，a9)。网络上的每个设备项基于MBMS来发送数据。
在OTASP数据发送完成之后，服务器6使用OTASP完成消息将数据发送的完成通知GGSN 5(图12，a10)。OTASP完成消息包含OTASP请求中包含的终端类型和软件版本信息。
在接收到来自服务器6的OTASP完成消息之后，GGSN 5使用GTP-C消息将该消息转发到SGSN 4(图12，a11)。在接收到来自GGSN 5的OTASP完成消息之后，SGSN 4使用RANAP消息将该消息转发到RNC 3(图12，a12)。
在接收到来自SGSN 4的OTASP完成消息之后，RNC 3使用RRC消息将OTASP完成消息发送到目标移动终端(UE#1、UE#2)，以将数据发送的完成告知终端(图12，a13)。前面结合图6至图9描述的方法也适用于此消息。
当正确接收到OTASP数据并完成了软件更新时，移动终端(UE#1、UE#2)更新其中的软件版本信息(图12，a14)。
图13的顺序图示出了根据本发明实施方式的数据发送处理(当OTASP通过广播执行时的处理)。参照图3和图13，将对OTASP通过广播执行时的处理进行说明。
当存在需要更新软件版本的移动终端(UE#1、UE#2)时，服务器6将OTASP请求发送到GGSN 5(图13，a21)。该消息包含终端类型和软件版本信息。此外，指定了数据传送模式，并且RNC 3的操作根据传送模式而变化。在此情况下，服务器6不需要接收来自移动终端(UE#1、UE#2)的信号，因此该消息不包含用于将信号转发到服务器6的信息。
在接收到来自服务器6的OTASP请求之后，GGSN 5使用GTP-C消息将该请求转发到SGSN 4(图13，a22)。在接收到来自GGSN 5的OTASP请求之后，SGSN 4使用RANAP寻呼消息将该请求转发到RNC 3(图13，a23)。
当无需识别目标移动终端(UE#1、UE#2)时，使用广播。因此，RNC 3发送广播寻呼消息而非通常的寻呼消息，所述通常的寻呼消息包含等待来自目标移动终端(UE#1、UE#2)的响应的指示(图13，a24)。前面结合图6至图9描述的方法也适用于此消息。此外，该处理是基于3GPP MBMS标准来执行的。
如上所述，移动终端(UE#1、UE#2)将其类型及软件版本与寻呼信道中所包含的相比较，并且如果它们匹配(图13，a25)，则准备接收OTASP数据(图13，a26)。该处理是基于3GPP MBMS标准来执行的。
此后，服务器6开始OTASP数据的发送(图13，a27)。网络上的每个设备项基于3GPP MBMS标准来发送数据。
在OTASP数据发送完成之后，服务器6使用OTASP完成消息将数据发送的完成通知GGSN 5(图13，a28)。OTASP完成消息包含OTASP请求中所包含的终端类型和软件版本信息。
在接收到来自服务器6的OTASP完成消息之后，GGSN 5使用GTP-C消息将该消息转发到SGSN 4(图13，a29)。在接收到来自GGSN 5的OTASP完成消息之后，SGSN 4使用RANAP消息将该消息转发到RNC 3(图13，a30)。
在接收到来自SGSN 4的OTASP完成消息之后，RNC 3使用RRC消息将OTASP完成消息发送到目标移动终端(UE#1、UE#2)，以将数据发送的完成告知终端(图13，a31)。前面结合图6至图9描述的方法也适用于此消息。
当正确接收到OTASP数据并完成了软件更新时，移动终端(UE#1、UE#2)更新其中的软件版本信息(图13，a32)。
图14的流程图示出了图3所示的服务器6侧的操作(当OTASP通过多播执行时的操作)。参照图3和图14，将对OTASP通过多播执行时在服务器6侧的处理进行说明。
在多播情况下，当不存在目标移动终端1时，不发送数据。因此，服务器6激活定时器(未示出)，以等待与OTASP请求的发送同时的来自移动终端1的响应(图14，步骤S41)。
如果在定时器超时前没有接收到来自移动终端1的响应(图14，步骤S42和S43)，则服务器6终止OTASP(图14，步骤S45)。所述定时器用于检查目标移动终端1的存在，以及收集来自目标移动终端群组的响应。
如果在定时器超时前接收到了来自移动终端1的响应(图14，步骤S42和S43)，则服务器6开始OTASP数据的发送(图14，步骤S44)。
当执行多播时，如上所述，即使仅接收到一个来自移动终端的响应，服务器6也开始OTASP数据的发送，而如果没有响应，则其不发送数据，并终止OTASP。
在以上说明中，多播寻呼被用来更新终端的软件版本。然而，多播寻呼还可被用来获得使用特定版本软件的终端数量的统计数据，或者用来向终端提供特定软件。上述多播寻呼的应用仅仅是示例性而非限制性地引用的。
图15的流程图示出了图3所示的移动终端1的数据处理操作。参照图3和图15，将对移动终端1的数据处理操作进行说明。
在OTASP数据接收开始时，考虑到消息不到达的情况，移动终端1激活定时器以等待OTASP完成消息(图15，步骤S51和S52)。
在通过RRC消息被通知OTASP的完成(图15，步骤S53)，并且成功更新软件(图15，步骤S54)之后，移动终端1更新其中的软件的版本信息(图15，步骤S55)。
OTASP完成消息包含OTASP请求中所包含的终端类型和软件版本信息。因此，如果在接收到OTASP完成消息之前重写了软件版本信息，则移动终端1无法接收该消息。
如果OTASP完成定时器超时(图15，步骤S52)或在成功更新软件之前报告了OTASP的完成(图15，步骤S53和S54)，则移动终端1丢弃在该时刻之前接收到的OTASP数据(图15，步骤S56)。然后，移动终端1终止操作，并使用先前的终端类型和软件版本信息。可以引用如下情形作为软件更新失败的例子移动终端1在完成数据接收之前被通知OTASP完成。
如上所述，在成功更新了软件之后，移动终端1更新其中的软件版本信息。另一方面，当未能更新软件时，移动终端1丢弃接收到的数据，并且不更新其中的软件版本信息。
从而，移动终端1如果成功更新了软件则不会再次接收同样的数据，而移动终端1如果未能更新软件版本则可以再次接收同样的数据，这是因为它在成功更新软件之前不会更新软件版本信息。
如上所述，根据本实施方式，MBMS被应用于OTASP，以用于重写程序以更新软件版本等。因此，每个移动终端不浪费其功率，并且可以高效地仅在软件需要重写时才更新目标终端群组中的软件。
另外，利用了唯一地标识移动终端的信息(例如包含在IMEI-SV中的关于终端类型和软件版本的信息)。从而，可以高效地将移动终端分成群组。
此外，完成了软件更新的移动终端更新其中的软件版本信息。因此，移动终端可以避免对相同数据的重复接收。
权利要求
1.一种移动通信系统，在该移动通信系统中经由无线电在服务器和移动终端之间发送/接收数据，其中所述服务器至少包括如下装置，该装置用于通过向目标移动终端发送附有关于移动终端类型的信息的请求来对所述目标移动终端进行寻呼。
2.如权利要求1所述的移动通信系统，其中所述请求除了关于移动终端类型的信息以外，还附有关于移动终端中的软件版本的信息。
3.一种移动通信系统，在该移动通信系统中执行空中业务提供，以基于从服务器经由无线电发送来的数据来重写移动终端中的软件，其中所述服务器包括如下装置，该装置用于通过在要执行空中业务提供时向目标移动终端发送附有关于移动终端类型和软件版本的信息的请求，来对所述目标移动终端进行寻呼。
4.如权利要求3所述的移动通信系统，其中所述移动终端包括用于基于所述终端类型和软件版本信息来确定所述请求是否指向所述终端的装置；以及用于在确定了所述请求是指向所述终端之后基于从所述服务器发送来的数据来更新所述软件的装置。
5.如权利要求3或4所述的移动通信系统，其中所述移动终端包括用于基于所述请求所附有的信息来确定所述数据是要被多播还是广播到所述终端的装置；用于在确定了所述数据要被多播之后，在接收所述数据之前发送对所述请求的响应的装置；以及用于在确定了所述数据要被广播之后，接收所述数据而不发送对所述请求的响应的装置。
6.如权利要求5所述的移动通信系统，其中所述服务器重复地广播所述数据，并且此后多播所述数据。
7.如权利要求3至6中任一项所述的移动通信系统，其中，所述移动终端包括如下装置，该装置用于在所述软件已基于所述数据被更新之前防止所述软件的版本信息被更新。
8.一种经由无线电向移动终端发送数据和从移动终端接收数据的服务器，该服务器至少包括如下装置，该装置用于通过向目标移动终端发送附有关于移动终端类型的信息的请求来对所述目标移动终端进行寻呼。
9.如权利要求8所述的服务器，其中所述请求除了关于移动终端类型的信息以外，还附有关于移动终端中的软件版本的信息。
10.一种经由无线电发送数据的服务器，该服务器用于执行空中业务提供以重写移动终端中的软件，所述服务器包括如下装置，该装置用于通过在要执行空中业务提供时向目标移动终端发送附有关于移动终端类型和软件版本的信息的请求，来对所述目标移动终端进行寻呼。
11.如权利要求10所述的服务器，所述服务器重复地广播所述数据，并且此后多播所述数据。
12.一种移动终端，该移动终端在接收到包含至少关于其终端类型和软件版本的信息的寻呼消息之后进行操作。
13.一种用于如下移动通信系统中的移动终端，在所述移动通信系统中执行空中业务提供，以基于从服务器经由无线电发送来的数据来重写移动终端中的软件，所述移动终端包括用于基于在要执行空中业务提供时接收到的请求所附有的终端类型和软件版本信息来确定该请求是否指向所述终端的装置；以及用于在确定了所述请求是指向所述终端之后基于从所述服务器发送来的数据来更新所述软件的装置。
14.如权利要求13所述的移动终端，还包括用于基于所述请求所附有的信息确定所述数据是要被多播还是广播到所述终端的装置；用于在确定了所述数据要被多播之后，在接收所述数据之前发送对所述请求的响应的装置；以及用于在确定了所述数据要被广播之后，接收所述数据而不发送对所述请求的响应的装置。
15.如权利要求13或14所述的移动终端，还包括如下装置，该装置用于在所述软件已基于所述数据被更新之前防止所述软件的版本信息被更新。
16.一种应用于如下移动通信系统的数据发送方法，在所述移动通信系统中经由无线电在服务器和移动终端之间发送/接收数据，所述方法在所述服务器侧至少包括如下步骤通过向目标移动终端发送附有关于移动终端类型的信息的请求来对所述目标移动终端进行寻呼。
17.如权利要求16所述的数据发送方法，其中所述请求除了关于移动终端类型的信息以外，还附有关于移动终端中的软件版本的信息。
18.一种应用于如下移动通信系统的数据发送方法，在所述移动通信系统中执行空中业务提供，以基于从服务器经由无线电发送来的数据来重写移动终端中的软件，所述方法在所述服务器侧包括如下步骤通过在要执行空中业务提供时向目标移动终端发送附有关于移动终端类型和软件版本的信息的请求，来对所述目标移动终端进行寻呼。
19.如权利要求18所述的数据发送方法，在所述移动终端侧包括如下步骤基于所述终端类型和软件版本信息确定所述请求是否指向所述终端；以及在确定了所述请求是指向所述终端之后，基于从所述服务器发送来的数据来更新所述软件。
20.如权利要求18或19所述的数据发送方法，在所述移动终端侧还包括如下步骤基于所述请求所附有的信息确定所述数据是要被多播还是广播到所述终端；在确定了所述数据要被多播之后，在接收所述数据之前发送对所述请求的响应；以及在确定了所述数据要被广播之后，接收所述数据而不发送对所述请求的响应。
21.如权利要求20所述的数据发送方法，其中所述服务器重复地广播所述数据，并且此后多播所述数据。
22.如权利要求18至21中任一项所述的数据发送方法，在所述移动终端侧包括如下步骤在所述软件已基于所述数据被更新之前，防止所述软件的版本信息被更新。
全文摘要
一种移动通信系统，其能够仅在需要软 件重写时高效地更新相关终端的软件。当便携式终端(UE#1，UE#2)的软件必须被更新时，服务器将包含终端类型和软件版本信息在内的OTASP请求发送到GGSN。OTASP请求经由GGSN、SGSN和RNC被传送到便携式终端(UE#1，UE#2)。便携式终端(UE#1，UE#2)将其终端类型和软件版本与寻呼信道中所包含的终端类型和软件版本相比较，如果它们匹配，则将RRC连接请求发送到RNC。
文档编号H04W8/22GK1795694SQ20048001462
公开日2006年6月28日 申请日期2004年5月26日 优先权日2003年5月28日
发明者板羽直人, 田村利之, 坂田正行 申请人:日本电气株式会社