CN115052252B - 一种ota升级方法、系统及装置 - Google Patents

一种ota升级方法、系统及装置 Download PDF

Info

Publication number
CN115052252B
CN115052252B CN202210953014.XA CN202210953014A CN115052252B CN 115052252 B CN115052252 B CN 115052252B CN 202210953014 A CN202210953014 A CN 202210953014A CN 115052252 B CN115052252 B CN 115052252B
Authority
CN
China
Prior art keywords
multicast
mobile terminal
ota
upgrading
base station
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202210953014.XA
Other languages
English (en)
Other versions
CN115052252A (zh
Inventor
陈瑞欣
宋怡昕
林力
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangdong Shiju Network Technology Co ltd
Original Assignee
Guangzhou Shiju Network Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guangzhou Shiju Network Technology Co Ltd filed Critical Guangzhou Shiju Network Technology Co Ltd
Priority to CN202210953014.XA priority Critical patent/CN115052252B/zh
Publication of CN115052252A publication Critical patent/CN115052252A/zh
Application granted granted Critical
Publication of CN115052252B publication Critical patent/CN115052252B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/08—User group management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056—Systems characterized by the type of code used
    • H04L1/0057—Block codes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本发明涉及互联网技术领域，具体涉及一种OTA升级方法、系统及装置，具体包括移动终端、基站和核心网；其中移动终端完成移动终端与核心网之间的通用业务传输建立和核心网与基站之间的组播会话建立；移动终端根据软件升级周期，定时发送软件版本升级查询请求至OTA服务器；OTA服务器通过核心网接收并发送软件系统预升级请求；移动终端接收软件系统预升级请求并获得系统版本标记字段进行升级判断；若判断为假，则移动终端进入下一次软件升级周期；若判断为真，移动终端发送软件版本升级请求至OTA服务器进行组播会话传输完成OTA升级；本发明能够最大程度地节省OTA升级过程中的业务数据流量，并实现点对多点的组播传输。

Description

一种OTA升级方法、系统及装置
技术领域
本发明涉及移动通信、互联网技术领域，具体涉及一种OTA升级方法、系统及装置。
背景技术
目前移动终端的软件版本升级提供的标准方式一般基于OTA（Over the air，空间下载）技术，是通过移动通信(GSM或CDMA)的空中接口对SIM卡数据及应用进行远程管理的技术。OTA方案是采用在现有软件系统固件基础上添加代码实现的，移动终端的软件升级包部署在OTA服务器上；即移动终端通过无线的传输手段如蜂窝网络等，自动或手动在OTA服务器上下载相应的软件版本升级包，即可完成本机软件版本升级。
但是现有的OTA技术无法直接使用在移动终端的生产线上，在OTA升级方式上具有一些限制。首先，移动终端的软件升级包文件通常较大，一般可达5G至10G字节的文件大小；而移动终端的生产线上在较短时间内完成大量的移动终端软件升级包的下载会带来超大的吞吐量需求，对于传统的无线传输手段而言将是一个极大的挑战；因此目前大多移动终端的生产线都需要额外增加软件版本升级的工序，采取有线的方式为移动终端完成软件升级，会耗费较多的时间与人力成本。
其次，在现有的OTA升级方式中，为了避免出现升级失败、中途断网或断电等异常情况，系统均采用要求存储介质大于两倍当前固件大小的方式，即在不修改现有固件的基础上将待升级的固件保存在系统的空闲空间中，等待下载完成后才替换原本的旧固件；此方式在一定程度上占用了大量存储资源，且容易出现众多终端同时集中访问而导致服务器过载的问题。因此，为了解决现有OTA升级方式的问题和适应生产线上大量移动终端的OTA软件升级需求，亟需提出一种新型的OTA升级的方法、系统及装置。
发明内容
本发明的目的在于提出一种OTA升级方法、系统及装置，以解决现有技术中所存在的一个或多个技术问题，至少提供一种有益的选择或创造条件。
为了实现上述目的，根据本发明的一方面，提供一种OTA升级方法，所述方法包括以下步骤：
S100，移动终端采用3GPP的标准入网过程发起通用会话，完成移动终端与核心网之间的通用业务传输建立；
S200，移动终端发起组播会话的NAS会话建立请求，完成核心网与基站之间的组播会话建立；
S300，移动终端的OTA客户端应用程序根据软件升级周期，定时发送软件版本升级查询请求至OTA服务器；
S400，OTA服务器通过通用业务传输接收软件版本升级查询请求，并向对应的移动终端发送软件系统预升级请求；其中所述软件系统预升级请求包括OTA服务器对应的系统版本标记字段；
S500，移动终端接收软件系统预升级请求获得OTA服务器对应的系统版本标记字段，并与移动终端的OTA客户端应用程序对应的系统版本标记字段进行升级判断；若判断为假，则移动终端结束本次软件版本升级查询请求，进入下一次软件升级周期时发送软件版本升级查询请求至OTA服务器，跳转至S400；若判断为真，则移动终端通过通用业务传输向OTA服务器发送软件版本升级请求；
S600，OTA服务器接收软件版本升级请求，与移动终端进行组播会话传输完成OTA升级。
进一步地，在S100中，移动终端采用3GPP的标准入网过程发起通用会话，完成移动终端与核心网之间的通用业务传输建立的方法为：移动终端与基站之间进行RRC连接建立和RRC重配并完成过程，依次完成移动终端与核心网之间的NAS（Network AttachedStorage，网络附属存储）注册、双向鉴权、安全配置、通用会话建立的过程，最终完成移动终端与核心网之间的通用业务传输建立。
进一步地，在S200中，移动终端发起组播会话的NAS会话建立请求，完成核心网与基站之间的组播会话建立的方法为：
S201，移动终端配置组播DNN（数据网络名），通过NAS上行直传至基站发起组播会话，核心网接受对应的NAS会话建立请求，并为各个移动终端的组播会话分配对应的组播业务IP地址；
S202，核心网为各个移动终端的组播会话分配对应的QOS流，并向基站发送NAS会话建立接受消息和PDU会话建立请求信息，基站接受并完成组播会话承载建立，为移动终端分配相应的组播DRB；其中，各个移动终端的组播会话对应的组播业务IP地址封装于所述NAS会话建立接受消息中；所述PDU会话建立请求信息中添加组播会话身份标记字段；
S203，基站根据各个移动终端的组播会话对应的组播DRB分配相应的组播信道完成组播资源配置，并将对应的组播资源配置和NAS会话建立接受消息一并封装于RRC重配信息中，发送至各个移动终端；其中，所述组播信道的物理信道传输不区分通用DRB和组播DRB，但能够区分并兼容两者的物理信道配置；
S204，各个移动终端获得RRC重配信息应用对应的组播资源配置，并获得NAS会话建立接受消息得到相应的组播业务IP地址，则完成RRC重配，向基站发送RRC重配完成消息。
S205，基站为各个移动终端的组播会话分配相同的下行组播GTP隧道，并向核心网发送PDU会话建立响应消息，核心网完成组播隧道配置；其中，所述组播隧道配置包括传输对应的组播业务IP地址以及GTP隧道标识符；所述PDU会话建立响应消息中添加组播GTP隧道标识字段，令核心网可区分各个移动终端的组播会话对应的下行组播GTP隧道（基站为各个移动终端分配相同的GTP隧道，使不同的移动终端均采用相同的GTP隧道发送下行组播业务数据，能有效地节省了GTP隧道的业务数据流量）。
进一步地，在S203中，基站根据各个移动终端的组播会话对应的组播DRB分配相应的组播信道，其物理信道传输不区分通用DRB和组播DRB，但能够区分并兼容两者的物理信道配置的方法为：在PDCCH中分别配置通用DRB和组播DRB对应的控制资源集CORESET，分别采用不同的扰码进行加扰，将扰码表示为Cinit，其计算公式为：
Figure DEST_PATH_IMAGE002_5A
；
其中，nRNTI为CORESET配置中无线网络临时标识符RNTI的加扰码；nID为PDCCH所在当前小区的物理小区标记码；mod表示为求余运算； N1和N2分别为二进制编码的扰码位数，N1∈[8,16]，N2∈[16,32]（基站为各个移动终端完成RRC重配，并能够区分与兼容通用DRB与组播DRB的信道传输，允许各个移动终端使用相同的信道配置完成组播下行业务数据传输，能最大程度地节省OTA升级过程中的业务数据流量，无需额外增加软件版本升级的工序，解决了现有移动终端的生产线上采取有线的方式完成软件升级会耗费较高的时间与人力成本的问题）。
其中，在S203中，基站根据各个移动终端的组播会话对应的组播DRB能够区分并兼容两者的物理信道配置，在PDCCH中分别配置通用DRB和组播DRB对应的控制资源集CORESET的方法为：
对于组播DRB的CORESET配置：基站不配置 pdcch-DMRS-ScramblingID参数，根据3GPP协议，此时nRNTI 为0，nID为当前小区的物理小区ID，因此当前物理小区下的所有移动终端计算得到的Cinit均相等，均可解扰组播PDCCH；
对于通用DRB的CORESET配置：将pdcch-DMRS-ScramblingID参数配置为当前小区的物理小区ID，根据3GPP协议，此时nRNTI 为S100中所述移动终端在通用业务传输过程中使用的C-RNTI，为非0值，nID为当前小区的物理小区ID，因此当前物理小区下的所有移动终端计算得到的Cinit均不相等，且与组播DRB计算的Cinit也不相等，当前小区下的所有移动终端，均只能解扰其各自的通用PDCCH。
进一步地，在S400中，所述软件系统预升级请求包括OTA服务器对应的系统版本标记字段；其中，系统版本标记字段包括OTA服务器中的软件系统版本编号字符和版本时间标签。
进一步地，在S500中，移动终端接收软件系统预升级请求获得OTA服务器对应的系统版本标记字段，并与移动终端的OTA客户端应用程序对应的系统版本标记字段进行升级判断的方法为：
S501，将OTA服务器对应的系统版本标记字段中的软件系统版本编号字符和版本时间标签分别记作Version1和Time1，移动终端对应的系统版本标记字段中的软件系统版本编号字符和版本时间标签分别记作Version2和Time2；
S502，计算升级等级指示记作UGS，UGS=mod{[ln(Version1)-ln(Version2)]/(Time1- Time2)}；其中mod{ }表示为对“{}”内的表达式进行求余运算，ln为自然对数；
S503，当升级等级指示小于或等于0时，则升级判断为假；否则升级判断为真。
由于在实际的OTA升级传输中可能会出现升级失败的异常情况，以上方法并不能避免，可能会出现OTA升级中占用大量存储资源，且容易出现服务器过载的现象，所以本发明提供了以下方法以解决该问题，具体为：
优选地，在S500中，移动终端接收软件系统预升级请求获得OTA服务器对应的系统版本标记字段，并与移动终端的OTA客户端应用程序对应的系统版本标记字段进行升级判断的方法为：
将OTA服务器对应的系统版本标记字段中的软件系统版本编号字符和版本时间标签分别记作Version1和Time1，移动终端对应的系统版本标记字段中的软件系统版本编号字符和版本时间标签分别记作Version2和Time2；
当移动终端出现升级失败时，移动终端与OTA客户端应用程序断开连接，当重新开始升级后，计算移动终端Mob1中的当前的升级等级指示记作UGS，计算UGS的方法为：
Figure DEST_PATH_IMAGE004A
；
设系统升级指数为UGSC，系统升级指数UGSC=mod{[ln(Version1)-ln(Version2)]/(Time1- Time2)}；其中mod{ }表示为对“{}”内的表达式进行求余运算，ln为自然对数；
i为累加变量，N1是OTA服务器中所有的软件系统版本（当前的软件升级包的软件系统版本和历史所有的软件升级包的软件系统版本）的数量；UGSCi为OTA服务器中第i个历史软件系统版本的系统升级指数；UGSCAVG为OTA服务器中所有的软件系统版本的系统升级指数的算术平均值，UGSCR为当前的系统升级指数；
如果当前的升级等级指示UGS小于或等于0时，则升级判断为假；否则升级判断为真；或者，如果当前的升级等级指示UGS小于或等于上一次升级失败时的升级等级指示时，则升级判断为假；否则升级判断为真。（本发明通过以上方法新增所述系统版本标记字段进行升级判断，通过避开升级失败的断点的升级等级指示，解决了传统OTA升级方法中占用大量存储资源，且容易出现服务器过载的问题）。
进一步地，在S600中，OTA服务器接收软件版本升级请求，与移动终端进行组播会话传输完成OTA升级的方法为：
S601，OTA服务器完成分组数据生成与发送：OTA服务器网元与核心网共址部署，OTA服务端应用程序采用UDP组播的方式持续发送分组数据包；其中，OTA服务器上的OTA服务应用采用喷泉编码将OTA软件升级包生成分组数据；UDP组播采用的组播IP地址即为步骤S201中所述核心网为各个移动终端分配对应的组播业务IP地址；
S602，核心网通过下行隧道传输发送分组数据至基站：核心网验证该分组数据为组播业务的组播地址，则OTA服务器通过步骤S205获得的下行组播GTP隧道，通过组播会话承载将分组数据发送至基站；
S603，基站与移动终端进行组播会话传输：基站按分组数据的接收顺序逐个发送至移动终端的OTA客户端直至全部传输完毕；
S604，移动终端的OTA客户端完成分组数据接收与重组：各个移动终端的OTA客户端应用程序加入UDP组播，采用UDP多播的方式完成组播下行业务数据的传输；其中，各个移动终端利用与基站之间的空中接口持续接收基站发送的分组数据包，并采用喷泉码译码重新恢复OTA软件升级包；当OTA软件升级包完成恢复，则各个移动终端的OTA客户端完成OTA升级。
目前3GPP协议正在更新换代，在新一代的5G技术体制中移动终端无法支持或适用点对多点的组播传输方式；而在应用层面，OTA技术一般需要采用http协议等，而其往往需要基于TCP协议，但TCP协议是面向连接的点对点的传输，无法完成广播与多播，移动终端采用TCP协议架构无法支持点对多点的组播传输需求；因此，为了实现点对多点的组播传输，本发明在步骤S604中采用UDP多播的方式完成组播下行业务数据的传输。
但是，由于各个移动终端进入组播的时间不一，且下行传输不依赖上行的反馈导致下行组播的分组数据的丢包率较高，基站接收到的分组数据可能会出现SN不能连续的情况；因此，为了解决以上问题，本发明对步骤S603中基站与移动终端进行组播会话传输的配置方法进一步改进。
进一步地，在S603中，基站与移动终端进行组播会话传输的方法为：基站持续接收OTA服务器发送的分组数据包，并持续分配序列号（SN）；其中，所述基站持续接收OTA服务器发送的分组数据包的配置方法具体为：
S6031，基站PDCP层传输配置：基站的PDCP层采用打开乱序提交，或者减少重排定时器时间和减少SN长度的方式；
S6032，基站RLC层传输配置：基站的RLC层采用非确认的UM模式以及减少SN长度的方式；其中，利用步骤S3031~S3032能够有效提高移动终端到达正确的SN接收窗口的成功率，以及正常接收分组数据包的接收效率；
S6033，基站MAC层传输配置：基站的MAC（Medium Access Control，介质访问控制）层根据通用业务情况进行通用上行、或下行调度；而对于组播业务，基站仅进行组播下行调度。
本发明还提供一种OTA升级系统，具体实现一种OTA升级方法中的所有步骤。
本发明还提供包含所述一种OTA升级系统的一种OTA升级装置，具体包括：移动终端、基站和核心网；其中，所述移动终端中内设OTA客户端应用程序，并设定软件升级周期，根据软件升级周期，各个移动终端向OTA服务器定时发送软件版本升级查询请求；当所述移动终端的OTA客户端应用程序完成分组数据接收与重组OTA软件升级包后，则各个移动终端的OTA客户端完成OTA升级。
如上所述，本发明所述的一种OTA升级方法、系统及装置，具有以下有益效果：（1）OTA服务端和客户端均采用喷泉码编码、译码OTA软件升级包数据，并采用UDP多播的方式完成组播下行业务数据的传输，实现点对多点的组播传输需求；（2）基站为移动终端分配相同的GTP隧道，使不同的移动终端均采用相同的GTP隧道发送下行组播业务数据，节省了GTP隧道的业务数据流量；（3）基站对RRC重配信息的组播资源配置参数能在一定程度上保证了下行信道单次传输的可靠性，以及维持正常的上行信道状态；（4）基站能够区分与兼容通用DRB与组播DRB的信道传输，允许各个移动终端使用相同的信道配置完成组播下行业务数据传输，能最大程度地节省OTA升级过程中的业务数据流量，无需额外增加软件版本升级的工序。
附图说明
通过对结合附图所示出的实施方式进行详细说明，本发明的上述以及其他特征将更加明显，本发明附图中相同的参考标号表示相同或相似的元素，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图，在附图中：
图1所示为一种OTA升级方法的流程图；
图2所示为一种OTA升级方法的移动终端采用3GPP的标准入网过程示意图；
图3所示为一种OTA升级方法的移动终端发起组播会话的NAS会话建立请求并完成核心网与基站之间的组播会话建立过程示意图；
图4所示为一种OTA升级系统结构图。
具体实施方式
以下将结合实施例和附图对本发明的构思、具体结构及产生的技术效果进行清楚、完整的描述，以充分地理解本发明的目的、方案和效果。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。
如图1所示为一种OTA升级方法的流程图，下面结合图1来阐述根据本发明的实施方式的一种OTA升级方法，所述方法包括以下步骤：
S100，移动终端采用3GPP的标准入网过程发起通用会话，完成移动终端与核心网之间的通用业务传输建立；
S200，移动终端发起组播会话的NAS会话建立请求，完成核心网与基站之间的组播会话建立；
S300，移动终端的OTA客户端应用程序根据软件升级周期，定时发送软件版本升级查询请求至OTA服务器；
S400，OTA服务器通过通用业务传输接收软件版本升级查询请求，并向对应的移动终端发送软件系统预升级请求；其中所述软件系统预升级请求包括OTA服务器对应的系统版本标记字段；
S500，移动终端接收软件系统预升级请求获得OTA服务器对应的系统版本标记字段，并与移动终端的OTA客户端应用程序对应的系统版本标记字段进行升级判断；若判断为假，则移动终端结束本次软件版本升级查询请求，进入下一次软件升级周期时发送软件版本升级查询请求至OTA服务器，跳转至S400；若判断为真，则移动终端通过通用业务传输向OTA服务器发送软件版本升级请求；
S600，OTA服务器接收软件版本升级请求，与移动终端进行组播会话传输完成OTA升级。
进一步地，在S100中，移动终端采用3GPP的标准入网过程发起通用会话，完成移动终端与核心网之间的通用业务传输建立的方法为：移动终端与基站之间进行RRC连接建立和RRC重配并完成过程，依次完成移动终端与核心网之间的NAS（Network AttachedStorage，网络附属存储）注册、双向鉴权、安全配置、通用会话建立的过程，最终完成移动终端与核心网之间的通用业务传输建立。
优选地，在本具体实施例中，如图2所示为移动终端采用3GPP的标准入网过程示意图；在S100中，移动终端采用3GPP的标准入网过程发起通用会话的方法为：
S101，移动终端配置通用的DNN（Data Network Name，数据网络名）以及移动终端采用的DNN；
S102，移动终端发送RRC连接建立请求至基站，基站发送对应移动终端的NAS注册请求至核心网；核心网将对应的移动终端进行开户记为组播用户，核心网仅允许属于组播用户的移动终端进行NAS注册接受并完成；
S103，移动终端优先发送给通用DNN的NAS会话建立请求至核心网，核心网与各个移动终端之间建立对应的通用会话，核心网为各个移动终端的通用会话分配通用业务IP地址并初始上下文建立；其中，将各个移动终端对应的通用业务IP地址封装于NAS会话建立接受消息中，发送至对应的移动终端完成NAS会话建立接受和安全命令；具体地，所述核心网与各个移动终端之间建立对应的通用会话的过程具体为：所述核心网通过NAS上行/下行直传方式完成与各个移动终端之间对应的NAS身份请求与响应、NAS鉴权请求与响应、NAS安全命令与完成，以及NAS注册接受与完成的过程；
S104，基站与移动终端之间完成AS安全配置，包括能力信息查询与响应和RRC重配并完成过程，将所述NAS会话建立接受消息封装于RRC重配消息中，至此初始上下文建立完成；其中各个移动终端对应的安全密钥不同，基站的控制面仅启用完整性保护、不启用加密，基站的用户面均不启用完整性保护与加密；
S105，基站为各个移动终端建立通用DRB（Data Radio Bearer，数据无线承载），各个移动终端在NAS会话建立接受消息中获得OTA服务器分配的通用业务IP地址，完成移动终端与核心网之间的通用业务传输建立；其中，核心网能为移动终端提供业务传输服务。
优选地，各个移动终端可以发起多个通用会话，可以由步骤S101~S105建立多个通用会话对应的通用DRB以及通用业务IP地址。
进一步地，在S200中，移动终端发起组播会话的NAS会话建立请求，完成核心网与基站之间的组播会话建立的方法为：
S201，移动终端配置组播DNN（数据网络名），通过NAS上行直传至基站发起组播会话，核心网接受对应的NAS会话建立请求，并为各个移动终端的组播会话分配对应的组播业务IP地址；
S202，核心网为各个移动终端的组播会话分配对应的QOS流，并向基站发送NAS会话建立接受消息和PDU会话建立请求信息，基站接受并完成组播会话承载建立，为移动终端分配相应的组播DRB；其中，各个移动终端的组播会话对应的组播业务IP地址封装于所述NAS会话建立接受消息中；所述PDU会话建立请求信息中添加组播会话身份标记字段；
S203，基站根据各个移动终端的组播会话对应的组播DRB分配相应的组播信道完成组播资源配置，并将对应的组播资源配置和NAS会话建立接受消息一并封装于RRC重配信息中，发送至各个移动终端；其中，所述组播信道的物理信道传输不区分通用DRB和组播DRB，但能够区分并兼容两者的物理信道配置；
S204，各个移动终端获得RRC重配信息应用对应的组播资源配置，并获得NAS会话建立接受消息得到相应的组播业务IP地址，则完成RRC重配，向基站发送RRC重配完成消息。
S205，基站为各个移动终端的组播会话分配相同的下行组播GTP隧道，并向核心网发送PDU会话建立响应消息，核心网完成组播隧道配置；其中，所述组播隧道配置包括传输对应的组播业务IP地址以及GTP隧道标识符；所述PDU会话建立响应消息中添加组播GTP隧道标识字段，令核心网可区分各个移动终端的组播会话对应的下行组播GTP隧道（基站为各个移动终端分配相同的GTP隧道，使不同的移动终端均采用相同的GTP隧道发送下行组播业务数据，能有效地节省了GTP隧道的业务数据流量）。
优选地，如图3所示为本发明的具体实施例中，移动终端发起组播会话的NAS会话建立请求并完成核心网与基站之间的组播会话建立过程示意图。
优选地，在S203中，所述RRC重配信息中对应的组播资源配置参数的方法为：
S2031，MCS-C-RNTI配置：在PCCC（physical Cell Group Config，物理层小区组配置）中，为各个移动终端分配相同的MCS-C-RNTI（Modulcation Coding Scheme Cell RNTI，调制和编码方案小区的无线网络临时标识符）配置；
S2032，帧结构配置：帧结构配置采用DDDSU时隙配比的下行时隙（由于组播上行传输无需保证吞吐量，在确保移动终端的链路状态能够维持的情况下，为了增加移动终端下行传输的吞吐量，采用获得较多的下行时隙尽可能减少组播链路的上行调度传输）；
S2033，PDCCH配置：各个移动终端的组播会话的下行及上行的调度信息均由下行控制信息（DCI）提供，PDCCH（Physical Downlink Control Channel，物理下行链路控制通道）为承载DCI的物理信道；其中，PDCCH的搜索空间候选集聚合等级采用4或以上的等级，CORESET的频域资源配置满足聚合等级需要的资源块（尽可能增强下行组播的每个协议子层的单次传输的可靠性，提高了 PDCCH传输的成功率）；
S2034，PDSCH配置：PDSCH（Physical Downlink Shared Channel，物理下行共享信道下行物理共享信道）采用POS2或POS3解调参考信号（DMRS）的附加位置，以此增加DMRS符号个数；其中，在满足组播吞吐量要求的情况下，设置最大Layer数限制为1（由于组播下行传输的可靠性不依赖上行反馈，为了增加下行传输的单次传输成功率，在满足组播吞吐量要求的情况下，尽可能增强下行组播的每个协议子层的单次传输的可靠性）；
S2035，PUCCH配置：各个移动终端允许配置不同的PUCCH（Physical UplinkControl Channel，物理上行控制信道）资源，可以提供调度请求（SR）与混合自动重传（HARQ）的反馈；其中在SR资源配置中采用较大的SR周期，如sl80以上（为了尽可能减少上行调度传输）；
S2036，PUSCH配置：PUSCH（Physical Uplink Shared Channel，物理上行共享信道）将最大Rank数限制为1（由于各个组播会话的组播上行传输无需保证吞吐量）；
S2037，下行信号配置：启用CSI-RS资源配置（NZP-CSI-RS-Resource Set），并启用时频跟踪信号，其中trs-Info配置为true（尽可能增强下行组播的每个协议子层的单次传输的可靠性，为了增加下行传输的单次传输成功率）；
S2038，组播上行信号配置：无需配置SRS信号（由于各个组播会话无需获得组播上行信道质量）；
S2039，组播上行调度配置：配置数值为64或以上的SR禁止定时器（SR-ProhibitTimer）、逻辑信道SR延迟定时器（logical Channel SR-Delay Timer）以及SR最大传输请求次数（SR-Trans Max）（为了尽可能减少组播上行调度传输）；
S20310，RLC配置：在RLC（Radio Link Control，无线链路控制）中DRB配置为非确认模式（UM）；下行SN长度配置为12（由于组播会话不依赖反馈进行传输，在满足组播吞吐量要求的情况下尽可能增强组播下行的单次传输可靠性）；
S20311，PDCP配置：在PDCP（Packet Data Convergence Protocol，分组数据汇聚协议）中，配置数值为5或以下的重排定时器（T-Reordering），乱序提交开关（out Of OrderDelivery）配置为true，以及下行SN长度配置为12（为了避免组播下行出现丢包事件，在满足组播吞吐量要求的情况下尽可能保证单次传输的可靠性）。
基站为各个移动终端完成RRC重配，并通过步骤S2031~S20311中对所述RRC重配信息的组播资源配置参数，能在一定程度上保证了下行信道单次传输的可靠性，以及维持正常的上行信道状态。
进一步地，在S203中，基站根据各个移动终端的组播会话对应的组播DRB分配相应的组播信道，其物理信道传输不区分通用DRB和组播DRB，但能够区分并兼容两者的物理信道配置的方法为：在PDCCH中分别配置通用DRB和组播DRB对应的CORESET（ControlResource Set，控制资源集），分别采用不同的扰码进行加扰，将扰码表示为Cinit，其计算公式为：
Figure DEST_PATH_IMAGE006A
；
其中，nRNTI为CORESET配置中RNTI（Radio Network Temporary Identifier，无线网络临时标识符）的加扰码；nID为PDCCH所在当前小区的物理小区标记码；mod表示为求余运算； N1和N2分别为二进制编码的扰码位数，N1∈[8,16]，N2∈[16,32]（基站为各个移动终端完成RRC重配，并能够区分与兼容通用DRB与组播DRB的信道传输，允许各个移动终端使用相同的信道配置完成组播下行业务数据传输，能最大程度地节省OTA升级过程中的业务数据流量，无需额外增加软件版本升级的工序，解决了现有移动终端的生产线上采取有线的方式完成软件升级会耗费较高的时间与人力成本的问题）。
优选地，在本具体实施例中，根据3GPP协议，N1=16，N2=31；
优选地，对于组播DRB的CORESET配置：基站不配置 pdcch-DMRS-ScramblingID参数，根据3GPP协议，此时nRNTI 为0，nID为当前小区的物理小区ID，因此当前物理小区下的所有移动终端计算得到的Cinit均相等，均可解扰组播PDCCH；
优选地，对于通用DRB的CORESET配置：将pdcch-DMRS-ScramblingID参数配置为当前小区的物理小区ID，根据3GPP协议，此时nRNTI 为S100中所述移动终端在通用业务传输过程中使用的C-RNTI，为非0值，nID为当前小区的物理小区ID，因此当前物理小区下的所有移动终端计算得到的Cinit均不相等，且与组播DRB计算的Cinit也不相等，当前小区下的所有移动终端，均只能解扰其各自的通用PDCCH。
进一步地，在S400中，所述软件系统预升级请求包括OTA服务器对应的系统版本标记字段；其中，系统版本标记字段包括OTA服务器中的软件系统版本编号字符和版本时间标签。
进一步地，在S500中，移动终端接收软件系统预升级请求获得OTA服务器对应的系统版本标记字段，并与移动终端的OTA客户端应用程序对应的系统版本标记字段进行升级判断的方法为：
S501，将OTA服务器对应的系统版本标记字段中的软件系统版本编号字符和版本时间标签分别记作Version1和Time1，移动终端对应的系统版本标记字段中的软件系统版本编号字符和版本时间标签分别记作Version2和Time2；
S502，计算升级等级指示记作UGS，UGS=mod{[ln(Version1)-ln(Version2)]/(Time1- Time2)}；其中mod{ }表示为对“{}”内的表达式进行求余运算，ln为自然对数；
S503，当升级等级指示小于或等于0时，则升级判断为假；否则升级判断为真。
由于在实际的OTA升级传输中可能会出现升级失败的异常情况，以上方法并不能避免，可能会出现OTA升级中占用大量存储资源，且容易出现服务器过载的现象，所以本发明提供了以下方法以解决该问题，具体为：
优选地，在S500中，移动终端接收软件系统预升级请求获得OTA服务器对应的系统版本标记字段，并与移动终端的OTA客户端应用程序对应的系统版本标记字段进行升级判断的方法为：
将OTA服务器对应的系统版本标记字段中的软件系统版本编号字符和版本时间标签分别记作Version1和Time1，移动终端对应的系统版本标记字段中的软件系统版本编号字符和版本时间标签分别记作Version2和Time2；
当移动终端出现升级失败时，移动终端与OTA客户端应用程序断开连接，当重新开始升级后，计算移动终端Mob1中的当前的升级等级指示记作UGS，计算UGS的方法为：
Figure DEST_PATH_IMAGE008A
；
设系统升级指数为UGSC，系统升级指数UGSC=mod{[ln(Version1)-ln(Version2)]/(Time1- Time2)}；其中mod{ }表示为对“{}”内的表达式进行求余运算，ln为自然对数；
i为累加变量，N1是OTA服务器中所有的软件系统版本（当前的软件升级包的软件系统版本和历史所有的软件升级包的软件系统版本）的数量；UGSCi为OTA服务器中第i个历史软件系统版本的系统升级指数；UGSCAVG为OTA服务器中所有的软件系统版本的系统升级指数的算术平均值，UGSCR为当前的系统升级指数；
如果当前的升级等级指示UGS小于或等于0时，则升级判断为假；否则升级判断为真；或者，如果当前的升级等级指示UGS小于或等于上一次升级失败时的升级等级指示时，则升级判断为假；否则升级判断为真。（本发明通过以上方法新增所述系统版本标记字段进行升级判断，通过避开升级失败的断点的升级等级指示，解决了传统OTA升级方法中占用大量存储资源，且容易出现服务器过载的问题）。
进一步地，在S600中，OTA服务器接收软件版本升级请求，与移动终端进行组播会话传输完成OTA升级的方法为：
S601，OTA服务器完成分组数据生成与发送：OTA服务器网元可以与核心网共址部署，OTA服务端应用程序采用UDP组播的方式持续发送分组数据包；其中，OTA服务器上的OTA服务应用可以采用喷泉编码将OTA软件升级包生成分组数据，如业务数据或用户面数据；UDP组播采用的组播IP地址即为步骤S201中所述核心网为各个移动终端分配对应的组播业务IP地址；
S602，核心网通过下行隧道传输发送分组数据至基站：核心网验证该分组数据为组播业务的组播地址，则核心网通过步骤S205获得的下行组播GTP隧道，通过组播会话承载将分组数据发送至基站；
S603，基站与移动终端进行组播会话传输：基站按分组数据的接收顺序逐个发送至移动终端的OTA客户端直至全部传输完毕；
S604，移动终端的OTA客户端完成分组数据接收与重组：各个移动终端的OTA客户端应用程序加入UDP组播，采用UDP多播的方式完成组播下行业务数据的传输；其中，各个移动终端利用与基站之间的空中接口持续接收基站发送的分组数据包，并采用喷泉码译码重新恢复OTA软件升级包；当OTA软件升级包完成恢复，则各个移动终端的OTA客户端完成OTA升级。
由于目前3GPP协议在更新换代的过程中，在新一代的5G技术体制中移动终端无法支持或适用点对多点的组播传输方式；而在应用层面，OTA技术一般需要采用http协议等，而其往往需要基于TCP协议，但TCP协议是面向连接的点对点的传输，无法完成广播与多播，移动终端采用TCP协议架构无法支持点对多点的组播传输需求；因此，为了实现点对多点的组播传输，本发明在步骤S604中采用UDP多播的方式完成组播下行业务数据的传输。
但是，由于各个移动终端进入组播的时间不一，且下行传输不依赖上行的反馈导致下行组播的分组数据的丢包率较高，基站接收到的分组数据可能会出现SN不能连续的情况；因此，为了解决以上问题，本发明对步骤S603中基站与移动终端进行组播会话传输的配置方法进一步改进。
进一步地，在S603中，基站与移动终端进行组播会话传输的方法为：基站持续接收OTA服务器发送的分组数据包，并持续分配序列号（SN）；其中，所述基站持续接收OTA服务器发送的分组数据包的配置方法具体为：
S6031，基站PDCP层传输配置：基站的PDCP层采用打开乱序提交，或者减少重排定时器时间和减少SN长度的方式；
S6032，基站RLC层传输配置：基站的RLC层采用非确认的UM模式以及减少SN长度的方式；其中，利用步骤S3031~S3032能够有效提高移动终端到达正确的SN接收窗口的成功率，以及正常接收分组数据包的接收效率；
S6033，基站MAC层传输配置：基站的MAC（Medium Access Control，介质访问控制）层根据通用业务情况进行通用上行、或下行调度；而对于组播业务，基站仅进行组播下行调度。
优选地，根据步骤S2033中的PDCCH配置，基站通过增加集聚合等级提高PDCCH中组播下行单次传输的可靠性，并对通用DRB和组播DRB调度采用不同的PDCCH扰码加扰：所有移动终端均可以解扰组播PDCCH，但只能解扰各自的PDCCH。
优选地，根据步骤S2033中的PDCCH配置，基站对调度的DCI也采用不同的扰码加扰：组播下行调度DCI采用MCS-C-RNTI加扰，允许所有移动终端均可解扰组播DCI；通用的DCI调度采用C-RNTI加扰，当前小区下的移动终端只能解扰各自的通用DCI。
优选地，根据步骤S2033中的PDCCH配置，基站通过增加DMRS数目与降低Layer数，提升组播PDSCH中单次传输的可靠性；并对通用DRB和组播DRB调度采用不同的PDSCH扰码加扰：组播采用MCS-C-RNTI计算扰码加扰，允许所有移动终端均可解扰组播PDSCH；通用的DCI调度采用C-RNTI计算扰码加扰，当前小区下的移动终端只能解扰各自的通用PDSCH。
优选地，根据步骤S2033中的PDCCH配置，基站的组播下行调度仍会指示移动终端进行下行HARQ反馈，而由于组播业务不进行上行调度，即无PUSCH信道，下行HARQ反馈将承载在PUCCH上；基站监测各个移动终端在不同PUCCH资源上的HARQ反馈（ACK或NACK），若不同移动终端的NACK达到了设定的比例阈值，则基站MAC启动HARQ重传机制。
本发明的实施例还提供了一种OTA升级系统，如图4所示为本发明的一种OTA升级系统结构图，该实施例的具体包括：
通用业务传输建立模块，用于各个移动终端采用3GPP的标准入网过程发起通用会话，完成移动终端与核心网之间的通用业务传输建立；
移动终端会话建立模块，用于移动终端发起组播会话的NAS会话建立请求，完成核心网与基站之间的组播会话建立；
软件升级查询请求发送模块，用于移动终端的OTA客户端应用程序设定软件升级周期，移动终端根据软件升级周期定时发送软件版本升级查询请求至OTA服务器；以及当升级判断为真时，移动终端通过核心网向OTA服务器发送软件版本升级请求；
软件预升级请求处理模块，用于OTA服务器通过核心网接收软件版本升级查询请求，并向对应的移动终端发送软件系统预升级请求；其中所述软件系统预升级请求包括OTA服务器对应的系统版本标记字段；
系统版本标记升级判断模块，用于移动终端接收软件系统预升级请求获得OTA服务器对应的系统版本标记字段，并与移动终端的OTA客户端应用程序对应的系统版本标记字段进行升级判断；
OTA升级完成模块，用于 OTA服务器接收软件版本升级请求，并与移动终端进行组播会话传输完成OTA升级。
本发明的实施例还提供了一种OTA升级装置，该实施例的具体包括：移动终端、基站和核心网；其中，所述移动终端中内设OTA客户端应用程序，并设定软件升级周期，根据软件升级周期，各个移动终端通过向OTA服务器定时发送软件版本升级查询请求；当所述移动终端的OTA客户端应用程序完成分组数据接收与重组OTA软件升级包后，则各个移动终端的OTA客户端完成OTA升级。
本领域技术人员可以理解，所述例子仅仅是一种OTA升级系统的示例，并不构成对一种OTA升级系统和一种OTA升级装置的限定，可以包括比例子更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述一种OTA升级系统还可以包括输入输出设备、网络接入设备、处理器、总线等。
优选地，其中，本发明中所有未定义的变量，若未有明确定义，均可为人工设置的阈值。
尽管本发明的描述已经相当详尽且特别对几个所述实施例进行了描述，但其并非旨在局限于任何这些细节或实施例或任何特殊实施例，从而有效地涵盖本发明的预定范围。此外，上文以发明人可预见的实施例对本发明进行描述，其目的是为了提供有用的描述，而那些目前尚未预见的对本发明的非实质性改动仍可代表本发明的等效改动。

Claims (10)

1.一种OTA升级方法，其特征在于，所述方法包括以下步骤：
S100，移动终端采用3GPP的标准入网过程发起通用会话，完成移动终端与核心网之间的通用业务传输建立；
S200，移动终端发起组播会话的NAS会话建立请求，完成核心网与基站之间的组播会话建立；
S300，移动终端的OTA客户端应用程序根据软件升级周期，定时发送软件版本升级查询请求至OTA服务器；
S400，OTA服务器通过通用业务传输接收软件版本升级查询请求，并向对应的移动终端发送软件系统预升级请求；其中所述软件系统预升级请求包括OTA服务器对应的系统版本标记字段；
S500，移动终端接收软件系统预升级请求获得OTA服务器对应的系统版本标记字段，并与移动终端的OTA客户端应用程序对应的系统版本标记字段进行升级判断；若判断为假，则移动终端结束本次软件版本升级查询请求，进入下一次软件升级周期时发送软件版本升级查询请求至OTA服务器，跳转至S400；若判断为真，则移动终端通过通用业务传输向OTA服务器发送软件版本升级请求；
S600，OTA服务器接收软件版本升级请求，与移动终端进行组播会话传输完成OTA升级。
2.根据权利要求1所述的一种OTA升级方法，其特征在于，在S100中，移动终端采用3GPP的标准入网过程发起通用会话，完成移动终端与核心网之间的通用业务传输建立的方法为：移动终端与基站之间进行RRC连接建立和RRC重配并完成过程，依次完成移动终端与核心网之间的NAS注册、双向鉴权、安全配置、通用会话建立的过程，最终完成移动终端与核心网之间的通用业务传输建立。
3.根据权利要求1所述的一种OTA升级方法，其特征在于，在S200中，移动终端发起组播会话的NAS会话建立请求，完成核心网与基站之间的组播会话建立的方法为：
S201，移动终端配置组播DNN，通过NAS上行直传至基站发起组播会话，核心网接受对应的NAS会话建立请求，并为各个移动终端的组播会话分配对应的组播业务IP地址；
S202，核心网为各个移动终端的组播会话分配对应的QOS流，并向基站发送NAS会话建立接受消息和PDU会话建立请求信息，基站接受并完成组播会话承载建立，为组播会话分配相应的组播DRB；其中，各个移动终端的组播会话对应的组播业务IP地址封装于所述NAS会话建立接受消息中；所述PDU会话建立请求信息中添加组播会话身份标记字段；
S203，基站根据各个移动终端的组播会话对应的组播DRB分配相应的组播信道完成组播资源配置，并将对应的组播资源配置和NAS会话建立接受消息一并封装于RRC重配信息中，发送至各个移动终端；其中，所述组播信道的物理信道传输不区分通用DRB和组播DRB，但能够区分并兼容两者的物理信道配置；
S204，各个移动终端获得RRC重配信息应用对应的组播资源配置，并获得NAS会话建立接受消息得到相应的组播业务IP地址，则完成RRC重配，向基站发送RRC重配完成消息；
S205，基站为各个移动终端的组播会话分配相同的下行组播GTP隧道，并向核心网发送PDU会话建立响应消息，核心网完成组播隧道配置；其中，所述组播隧道配置包括传输对应的组播业务IP地址以及GTP隧道标识符；所述PDU会话建立响应消息中添加组播GTP隧道标识字段，令核心网可区分各个移动终端的组播会话对应的下行组播GTP隧道。
4.根据权利要求3所述的一种OTA升级方法，其特征在于，在S203中，基站根据各个移动终端的组播会话对应的组播DRB分配相应的组播信道，其物理信道传输不区分通用DRB和组播DRB，但能够区分并兼容两者的物理信道配置的方法为：在PDCCH中分别配置通用DRB和组播DRB对应的控制资源集CORESET，分别采用不同的扰码进行加扰，将扰码表示为Cinit，其计算公式为：
Figure DEST_PATH_IMAGE002
；
其中，nRNTI为CORESET配置中无线网络临时标识符RNTI的加扰码；nID为PDCCH所在当前小区的物理小区标记码；mod表示为求余运算； N1和N2分别为二进制编码的扰码位数，N1∈[8,16]，N2∈[16,32]；
其中，在S203中，基站根据各个移动终端的组播会话对应的组播DRB能够区分并兼容两者的物理信道配置，在PDCCH中分别配置通用DRB和组播DRB对应的控制资源集CORESET的方法为：
对于组播DRB的CORESET配置：基站不配置 pdcch-DMRS-ScramblingID参数，根据3GPP协议，此时nRNTI 为0，nID为当前小区的物理小区ID，因此当前物理小区下的所有移动终端计算得到的Cinit均相等，均可解扰组播PDCCH；
对于通用DRB的CORESET配置：将pdcch-DMRS-ScramblingID参数配置为当前小区的物理小区ID，根据3GPP协议，此时nRNTI 为S100中所述移动终端在通用业务传输过程中使用的C-RNTI，为非0值，nID为当前小区的物理小区ID，因此当前物理小区下的所有移动终端计算得到的Cinit均不相等，且与组播DRB计算的Cinit也不相等，当前小区下的所有移动终端，均只能解扰其各自的通用PDCCH。
5.根据权利要求1所述的一种OTA升级方法，其特征在于，在S400中，所述软件系统预升级请求包括OTA服务器对应的系统版本标记字段；其中，系统版本标记字段包括OTA服务器中的软件系统版本编号字符和版本时间标签。
6.根据权利要求1所述的一种OTA升级方法，其特征在于，在S500中，移动终端接收软件系统预升级请求获得OTA服务器对应的系统版本标记字段，并与移动终端的OTA客户端应用程序对应的系统版本标记字段进行升级判断的方法为：
S501，将OTA服务器对应的系统版本标记字段中的软件系统版本编号字符和版本时间标签分别记作Version1和Time1，移动终端对应的系统版本标记字段中的软件系统版本编号字符和版本时间标签分别记作Version2和Time2；
S502，计算升级等级指示记作UGS，UGS=mod{[ln(Version1)-ln(Version2)]/(Time1-Time2)}；其中mod{ }表示为对“{}”内的表达式进行求余运算，ln为自然对数；
S503，当升级等级指示小于或等于0时，则升级判断为假；否则升级判断为真。
7.根据权利要求3所述的一种OTA升级方法，其特征在于，在S600中，OTA服务器接收软件版本升级请求，与移动终端进行组播会话传输完成OTA升级的方法为：
S601，OTA服务器完成分组数据生成与发送：OTA服务器网元与核心网共址部署，OTA服务端应用程序采用UDP组播的方式持续发送分组数据包；其中，OTA服务器上的OTA服务应用采用喷泉编码将OTA软件升级包生成分组数据；UDP组播采用的组播IP地址即为步骤S201中所述核心网为各个移动终端分配对应的组播业务IP地址；
S602，核心网通过下行隧道传输发送分组数据至基站：核心网验证该分组数据为组播业务的组播地址，则核心网通过步骤S205获得的下行组播GTP隧道，通过组播会话承载将分组数据发送至基站；
S603，基站与移动终端进行组播会话传输：基站按分组数据的接收顺序逐个发送至移动终端的OTA客户端直至全部传输完毕；
S604，移动终端的OTA客户端完成分组数据接收与重组：各个移动终端的OTA客户端应用程序加入UDP组播，采用UDP多播的方式完成组播下行业务数据的传输；其中，各个移动终端利用与基站之间的空中接口持续接收基站发送的分组数据包，并采用喷泉码译码重新恢复OTA软件升级包；当OTA软件升级包完成恢复，则各个移动终端的OTA客户端完成OTA升级。
8.根据权利要求7所述的一种OTA升级方法，其特征在于，在S603中，基站与移动终端进行组播会话传输的方法为：基站持续接收OTA服务器发送的分组数据包，并持续分配序列号；其中，所述基站持续接收OTA服务器发送的分组数据包的配置方法具体为：
S6031，基站PDCP层传输配置：基站的PDCP层采用打开乱序提交，或者减少重排定时器时间和减少SN长度的方式；
S6032，基站RLC层传输配置：基站的RLC层采用非确认的UM模式以及减少序列号长度的方式；
S6033，基站MAC层传输配置：基站的MAC层根据通用业务情况进行通用上行、或下行调度；而对于组播业务，基站仅进行组播下行调度。
9.一种OTA升级系统，其特征在于，实现权利要求1至8中的任意一种所述的一种OTA升级方法中的步骤，具体包括：
通用业务传输建立模块，用于各个移动终端采用3GPP的标准入网过程发起通用会话，完成移动终端与核心网之间的通用业务传输建立；
移动终端会话建立模块，用于移动终端发起组播会话的NAS会话建立请求，完成核心网与基站之间的组播会话建立；
软件升级查询请求发送模块，用于移动终端的OTA客户端应用程序设定软件升级周期，移动终端根据软件升级周期定时发送软件版本升级查询请求至OTA服务器；以及当升级判断为真时，移动终端通过核心网向OTA服务器发送软件版本升级请求；
软件预升级请求处理模块，用于OTA服务器通过核心网接收软件版本升级查询请求，并向对应的移动终端发送软件系统预升级请求；其中所述软件系统预升级请求包括OTA服务器对应的系统版本标记字段；
系统版本标记升级判断模块，用于移动终端接收软件系统预升级请求获得OTA服务器对应的系统版本标记字段，并与移动终端的OTA客户端应用程序对应的系统版本标记字段进行升级判断；
OTA升级完成模块，用于 OTA服务器接收软件版本升级请求，并与移动终端进行组播会话传输完成OTA升级。
10.一种包含权利要求9所述的一种OTA升级系统的OTA升级装置，其特征在于，包括：移动终端、基站和核心网；其中，所述移动终端中内设OTA客户端应用程序，并设定软件升级周期，根据软件升级周期，各个移动终端向OTA服务器定时发送软件版本升级查询请求；当所述移动终端的OTA客户端应用程序完成分组数据接收与重组OTA软件升级包后，则各个移动终端的OTA客户端完成OTA升级。
CN202210953014.XA 2022-08-10 2022-08-10 一种ota升级方法、系统及装置 Active CN115052252B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210953014.XA CN115052252B (zh) 2022-08-10 2022-08-10 一种ota升级方法、系统及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210953014.XA CN115052252B (zh) 2022-08-10 2022-08-10 一种ota升级方法、系统及装置

Publications (2)

Publication Number Publication Date
CN115052252A CN115052252A (zh) 2022-09-13
CN115052252B true CN115052252B (zh) 2022-11-04

Family

ID=83167940

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210953014.XA Active CN115052252B (zh) 2022-08-10 2022-08-10 一种ota升级方法、系统及装置

Country Status (1)

Country Link
CN (1) CN115052252B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118075256B (zh) * 2024-04-19 2024-06-25 北京飞利信信息安全技术有限公司 一种物联网电表升级方法、系统、终端及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106469077A (zh) * 2015-08-20 2017-03-01 青岛海信移动通信技术股份有限公司 一种ota升级控制方法及装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050033829A1 (en) * 2003-08-04 2005-02-10 Nokia Corporation System and method for wireless multicast downloading
EP1528723A1 (en) * 2003-10-31 2005-05-04 Siemens Mobile Communications S.p.A. Method and apparatus for mass software download in mobile communication systems, and mobile communication system supporting the mass software download
US8515412B2 (en) * 2009-11-25 2013-08-20 At&T Mobility Ii Llc Method and apparatus for maintaining user settings for over-the-air upgrades
US10419291B2 (en) * 2014-07-23 2019-09-17 Huawei Technologies Co., Ltd. Terminal upgrade method and related device with multicast program
CN106411540A (zh) * 2015-07-27 2017-02-15 中兴通讯股份有限公司 软件版本管理方法及装置
CN116709284A (zh) * 2019-03-06 2023-09-05 乐鑫信息科技（上海）股份有限公司 用于对蓝牙Mesh网络中的节点进行OTA固件升级的方法
CN111443927A (zh) * 2020-02-25 2020-07-24 厦门亿联网络技术股份有限公司 一种dect漫游系统设备间克隆升级的方法和系统

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106469077A (zh) * 2015-08-20 2017-03-01 青岛海信移动通信技术股份有限公司 一种ota升级控制方法及装置

Also Published As

Publication number Publication date
CN115052252A (zh) 2022-09-13

Similar Documents

Publication Publication Date Title
US11601956B2 (en) Method and device in wireless communication
US8995397B2 (en) Pseudo wires for mobility management
CN104159257B (zh) 用于多用户复用的系统和方法
CN102685913B (zh) 无线通讯系统中改善上行链路传输的方法
CN110831075A (zh) 数据传输方法及装置，业务切换方法及装置
US20130294283A1 (en) Facilitating device-to-device communication
US8995466B2 (en) Communications methods and apparatus for using a single logical link with multiple physical layer connections
EP3267721B1 (en) Air-interface protocol stack configuration method, and data transmission method and device
WO2012121782A2 (en) Reducing power consumption for m2m communications in wireless networks
WO2013029534A1 (zh) 一种数据传输的方法、终端和网络侧设备
CN105165105A (zh) 用于传输源标识的系统和方法
CN105122890A (zh) 在无线通信系统中控制来自无线局域网的小区连接以及提供关于外围无线局域网接入点的有效信息的方法和设备
CN110710304B (zh) 一种配置传输参数的方法、设备及系统
CN108696340B (zh) 反馈信息的发送、接收方法及装置
EP3709686B1 (en) Data transmission control method and related product
CN115052252B (zh) 一种ota升级方法、系统及装置
WO2018014704A1 (zh) 一种基于harq的传输方法和装置
CN104685959A (zh) 具有统一接口的无源无线电链路控制实体
CN113544987B (zh) 通信方法、装置、设备及可读存储介质
US20230180340A1 (en) Method and apparatus for small data transmission
US8477683B2 (en) Configuring a host device by way of MMP
CN110856120B (zh) 一种报文发送、接收方法及装置
JP7295100B2 (ja) ネットワーク構成方法、装置、ネットワーク要素及びシステム
CN108234092B (zh) 一种信令配置方法、rrc实体以及pdcp实体
JP2021520106A (ja) アップリンク制御情報の伝送方法及び装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
CP03 Change of name, title or address

Address after: 519000, Room 101, 201, 301, 401, Building 6, No. 1099 Jinzhou Road, Tangjiawan Town, High tech Zone, Zhuhai City, Guangdong Province

Patentee after: Guangdong Shiju Network Technology Co.,Ltd.

Country or region after: China

Address before: Room 611, 1st Floor, Block C, Building 24, Science and Technology Innovation Park, No.1 Jintang Road, Tangjiawan Town, High tech Zone, Zhuhai City, Guangdong Province, 519000

Patentee before: Guangdong Shiju Network Technology Co.,Ltd.

Country or region before: China

Address after: Room 611, 1st Floor, Block C, Building 24, Science and Technology Innovation Park, No.1 Jintang Road, Tangjiawan Town, High tech Zone, Zhuhai City, Guangdong Province, 519000

Patentee after: Guangdong Shiju Network Technology Co.,Ltd.

Country or region after: China

Address before: 510000 self compiled a, unit 1902, No. 374 BIS, Beijing Road, Yuexiu District, Guangzhou, Guangdong Province

Patentee before: Guangzhou Shiju Network Technology Co.,Ltd.

Country or region before: China