CN116133068B - 上行资源分配方法、用户设备、存储介质及通信系统 - Google Patents

Abstract

本申请提供了一种上行资源分配方法、用户设备、存储介质及通信系统。该方法包括：向第一小区发起随机接入请求前，判断当前是否满足预设的发起条件，第一小区为用户设备当前接入的小区，随机接入请求用于请求第一小区为用户设备要发送的上行数据分配上行资源；在不满足发起条件时，向第一小区发送RRC重建立请求，使第一小区为用户设备重新配置资源；在RRC重建立成功后，若第一小区未为用户设备配置上行调度请求资源，触发网络切换，并在设定时长内，禁止重选至第一小区。避免不断向第一小区发起随机接入请求申请上行资源导致对其他用户设备传输上行数据时使用的上行资源的抢占，以及上行数据传输卡顿，失败的问题发生。

Description

上行资源分配方法、用户设备、存储介质及通信系统

技术领域

本申请涉及通信技术领域，尤其涉及一种上行资源分配方法、用户设备、存储介质及通信系统。

背景技术

eNodeB（Evolved Node B），即演进型Node B，简称eNB，是4G LTE、5G与用户设备（User Equipment，UE）通信的无线基站名称。对于eNodeB，为了避免上行资源浪费，eNodeB不会主动为接入其的UE分配上行资源。因此，UE需要告诉当前接入的小区（具体为eNodeB可以覆盖的一个小区）自己是否有上行数据需要传输，以便eNodeB决定是否给UE分配上行资源。为此LTE提供了一个上行调度请求（Scheduling Request，SR）的机制，并规定了上行调度请求（后续称为：SR请求）的最大重传（max transmission）次数。

然而，实际作业中，往往存在SR请求超过最大重传次数，依旧没有获得eNodeB为其分配的上行资源的情况。对于这种情况，根据3GPP协议，UE会使用物理随机接入信道（Physical Random Access Channel，PRACH）申请上行资源，直到申请到上行资源，或者离开当前eNodeB所在小区，切换到其他eNodeB。

虽然，通过PRACH能够申请到上行资源，但是通过PRACH申请到的上行资源往往很少，这就导致UE通过申请到的上行资源传输上行数据的过程中，会存在卡顿，甚至通话建立失败、断续的问题。

发明内容

为了解决上述技术问题，本申请提供一种上行资源分配方法、用户设备、存储介质及通信系统，旨在为用户设备合理分配上行资源，避免持续通过PRACH申请上行资源导致对其他用户设备传输上行数据时使用的上行资源的抢占，同时也避免因PRACH申请上行资源导致上行数据传输卡顿，失败的问题发生。

第一方面，本申请提供一种上行资源分配方法，应用于用户设备。该方法包括：向第一小区发起随机接入请求前，判断当前是否满足预设的发起条件，第一小区为用户设备当前接入的小区，随机接入请求用于请求第一小区为用户设备要发送的上行数据分配上行资源；在不满足发起条件时，向第一小区发送RRC重建立请求，使第一小区为用户设备重新配置资源；在RRC重建立成功后，若第一小区未为用户设备配置上行调度请求资源，触发网络切换，并在设定时长内，禁止重选至第一小区。

由此，通过设定发起条件，设置用户设备在没有可用的上行调度请求资源可用的情况下，每次向第一小区发起随机接入请求前，均先确定当前是否满足发起条件，在满足时才发起，而在不满足向第一小区继续发送随机接入请求，同时通过RRC重建第一小区也没有为用户设备配置上行调度请求资源的情况下，通过Bar掉第一小区设定时长，即在设定时长内不接入第一小区，有效避免持续通过PRACH申请上行资源导致对其他用户设备传输上行数据时使用的上行资源的抢占，同时也避免因PRACH申请上行资源导致上行数据传输卡顿，失败的问题发生。

根据第一方面，判断当前是否满足预设的发起条件，包括：获取使用物理随机接入信道向第一小区发起随机接入请求的累计次数；在累计次数大于设定的次数阈值时，确定不满足发起条件。

由此，通过设定次数阈值，判断次数阈值内是否得到可用的上行调度请求资源，在没有可用的上行调度请求资源时，才确定不满足触发条件，进行向第一小区发送RRC重建立请求，触发第一小区为用户设备重新分配上行调度请求资源，从而减少了RRC重建次数，降低用户设备等待第一小区为其分配上行资源的时长。

根据第一方面，或者以上第一方面的任意一种实现方式，方法还包括：在累计次数不大于设定的次数阈值时，获取当前系统时间和上一次向第一小区发起随机接入请求的历史时间；在系统时间和历史时间之间的时间差值大于设定的时间阈值时，确定不满足发起条件。

由此，通过综合考虑累计次数和时间差值，使得判断结果更加精准，能够更好的适用于实际的使用场景。

根据第一方面，或者以上第一方面的任意一种实现方式，判断当前是否满足预设的发起条件，包括：获取当前系统时间和上一次向第一小区发起随机接入请求的历史时间；在系统时间和历史时间之间的时间差值大于设定的时间阈值时，确定不满足发起条件。

由此，通过设定时间阈值，判断时间阈值内是否得到可用的上行调度请求资源，在没有可用的上行调度请求资源时，才确定不满足触发条件，进行向第一小区发送RRC重建立请求，触发第一小区为用户设备重新分配上行调度请求资源，从而减少了RRC重建次数，降低用户设备等待第一小区为其分配上行资源的时长。

根据第一方面，或者以上第一方面的任意一种实现方式，方法还包括：在系统时间和历史时间之间的时间差值不大于设定的时间阈值时，获取使用物理随机接入信道向第一小区发起随机接入请求的累计次数；在累计次数大于设定的次数阈值时，确定不满足发起条件。

由此，通过综合考虑时间差值和累计次数，使得判断结果更加精准，能够更好的适用于实际的使用场景。

根据第一方面，或者以上第一方面的任意一种实现方式，在禁止重选至第一小区之后，方法还包括：在检测到第二小区时，接入第二小区，第二小区为除第一小区外，用户设备当前所在位置可以接入的小区；向第二小区为要发送的上行数据申请上行资源。

示例性的，第二小区例如可以是eNodeB。对于这种情况，用户设备在接入第二小区后，可以采用应用在第一小区上的上行资源分配方法，向第二小区为要发送的上行数据申请上行资源。

示例性的，第二小区还可以是NodeB，即会为接入的用户设备直接分配上行资源的小区。对于这种情况，用户设备可以直接使用第二小区分配的上行资源发送上行数据。

由此，在Bar掉第一小区的设定时长内，用户设备通过接入其他可以访问的第二小区，并通过向新接入的第二小区申请发送上行数据申请上行资源，从而能够保证用户设备能够将要发送的上行数据发送出去。

根据第一方面，或者以上第一方面的任意一种实现方式，方法还包括：在满足发起条件时，向第一小区发起随机接入请求。

由此，可以减少RRC重建次数，降低用户设备等待第一小区为其分配上行资源的时长。

根据第一方面，或者以上第一方面的任意一种实现方式，第一小区为eNodeB覆盖的小区。

第二方面，本申请提供了一种用户设备。该用户设备包括：存储器和处理器，存储器和处理器耦合；存储器存储有程序指令，程序指令由处理器执行时，使得所述用户设备执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第二方面以及第二方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第二方面以及第二方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第三方面，本申请提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第三方面以及第三方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第三方面以及第三方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第四方面，本申请提供了一种计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第四方面以及第四方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第四方面以及第四方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第五方面，本申请提供了一种芯片，该芯片包括处理电路、收发管脚。其中，该收发管脚、和该处理电路通过内部连接通路互相通信，该处理电路执行第一方面或第一方面的任一种可能的实现方式中的方法，以控制接收管脚接收信号，以控制发送管脚发送信号。

第五方面以及第五方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第五方面以及第五方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第六方面，本申请提供了一种通信系统。该通信系统包括eNodeB覆盖的小区和上述第二方面中提供的用户设备。

示例行的，该通信系统中包括的eNodeB覆盖的小区例如为上述所说的第一小区。

第六方面以及第六方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第六方面以及第六方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

附图说明

图1为示例性示出的一种通信网络架构；

图2为示例性示出的一种用户设备的硬件结构示意图；

图3为示例性示出的一种申请上行资源的流程示意图；

图4为示例性示出的本申请实施例提供的一种上行资源分配方法的流程示意图；

图5至图8为示例性示出的通信场景示意图；

图9为示例性示出的本申请实施例提供的又一种上行资源分配方法的流程示意图；

图10为示例性示出的本申请实施例提供的又一种上行资源分配方法的流程示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个系统是指两个或两个以上的系统。

在对本申请实施例的技术方案说明之前，首先对本申请实施例可以适用于的通信系统进行例举。

示例性的，本申请实施例可以适用但不限于以下通信系统：窄带物联网（NarrowBand-Internet Of Things，NB-IoT）系统、无线局域网（Wireless Local Access Network，WLAN）系统、长期演进（Long Term Evolution，LTE）系统、车用无线通信系统（vehicle toX，V2X）、第五代移动通信（5th Generation Mobile Networks Or 5th GenerationWirelessSystems，5G）也称为新空口（New Radio，NR）系统、或者5G之后的通信系统，例如6G系统、设备到设备（Device To Device，D2D）通信系统等。

为了便于理解上述通信系统的通信网络架构，以下结合图1对本申请实施例适用于的通信系统的信网络架构进行说明。

示例性的，图1以5G系统的网络服务架构为例展示了网络功能和实体之间的交互关系以及对应的接口，该5G系统的第三代合作伙伴项目（The 3rd GenerationPartnership Project，3GPP）基于服务的网络架构（Service-Based Architecture，SBA）包含的网络功能和实体主要包括：用户设备（User Equipment，UE）、接入网（Access Network，AN）或无线接入网（Radio Access Network，RAN）、用户面功能（User Plane Function，UPF）、数据网络（Data Network，DN）、接入管理功能（Access Management Function，AMF）、会话管理功能SMF、认证服务功能（Authentication Server Function，AUSF）、策略控制功能（Policy Control Function，PCF）、应用功能（Application Function，AF）、网络切片选择功能（Network Slice Selection Function，NSSF）、统一数据管理（Unified DataManagement，UDM）、网络开放功能（Network Exposure Function，NEF）和网络存储功能（Network Repository Function，NRF）。

其中，UE、AN/RAN、UPF和DN一般被称为用户面网络功能和实体（或者用户面网元），其它的部分则一般被称为控制面网络功能和实体（或者控制面网元）。控制面网元由3GPP定义了在一个网络里的处理功能，控制面网元具有3GPP定义的功能行为和3GPP定义的接口，网络功能能够作为一个运行在专有硬件上的网络元素，或者运行在专有硬件上的软件实例，或者在一个合适平台上进行实例化的虚拟功能，比如在一个云基础设备被实施。

下面对各个网元的主要功能做具体介绍。

AN/RAN：AN/RAN可以是各种形式的基站，例如：宏基站，微基站（也称为“小站”），分散单元-控制单元（Distribute Unit-Control Unit，DU-CU）等。另外，上述基站还可以是云无线接入网络（Cloud Radio Access Network，CRAN）场景下的无线控制器，或者中继站、接入点、车载设备、可穿戴设备或者未来演进的公共陆地移动网络（Public Land MobileNetwork，PLMN）网络中的网络设备等。AN/RAN也可以是宽带网络业务网关（BroadbandNetwork Gateway，BNG），汇聚交换机，非3GPP接入设备等。AN/RAN主要负责空口侧的无线资源管理、上下行数据分类、服务质量（Quality Of Service，QoS）管理、数据压缩和加密、与控制面网元完成信令处理或与用户面功能网元完成数据转发等功能。本申请实施例对AN/RAN的具体形态和结构不做限定。如，在采用不同的无线接入技术的系统中，具备基站功能的设备的名称可能会有所不同。例如，基站可以是LTE中的演进型通用陆地无线接入网（Evolved Universal TerrestrialRadio Access Network，E-UTRAN）设备，如演进型节点B（Evolutional NodeB，eNB或e-NodeB），也可以是5G系统中的下一代无线接入网（NextGeneration Radio AccessNetwork，NG-RAN）设备（如gNB）等。

UPF：主要负责分组路由和转发，以及用户面数据的QoS处理或计费信息统计等。UPF中为UE提供服务的传输资源和调度功能由SMF管理和控制。

DN：DN是用于传输数据的网络。例如：DN可以是运营商服务网络、互联网接入或第三方服务网络等。

AMF：主要负责控制面消息的处理，例如：接入控制、移动性管理、合法监听、接入鉴权/授权等。具体的，AMF的功能主要有：1）对接入网控制面进行处理；2）对NAS消息进行处理，负责NAS加密保护和完整性保护；3）注册管理；4）连接管理；5）接入性管理；6）移动性管理；7）合法信息截获；8）在UE与SMF之间提供会话管理消息；9）对于路由的会话管理（SM）消息实现透传，类似透传代理；10）接入鉴权；11）接入授权；12）在UE与短消息服务功能SMSF之间转发SMS消息（短消息）；13）与AUSF和UE交互，获得UE鉴权中间密钥；14）计算接入网络的特定密钥。

SMF：主要用于会话管理，UE的网络互连协议（Internet Protocol，IP）地址分配和管理，选择可管理用户平面功能，策略控制和收费功能接口的终结点，下行数据通知等。

PCF：主要用于向UE，AMF或SMF分别提供UE策略规则，AM策略规则以及SM策略规则相关的参数，管理用户订阅信息，对接UDM以访问与策略决策相关的订阅用户信息等。

NRF：主要用于提供内部/外部寻址功能，接收其它网元对某类网元的查询请求并返回相关网元的信息等。

AUSF：主要负责网络安全，用于产生密钥，实现对于UE的双向鉴权，支持统一的鉴权框架。

AF：用于提供服务，主要用于：1）对于业务路由的应用影响；2）访问网络能力曝光；3）与策略框架交互进行策略管控。

NSSF：主要用于网络切片实例（Network Slice Instance，NSI）的选择和管理，确定允许的网络切片信息与使用的网络切片信息的映射，以及确定已配置的网络切片信息与已订阅的网络切片信息的映射。

NEF：是网络内部与外部实体进行信息双向交互的接口网元，同时也是内部信息分发汇总的逻辑单元，主要包含三种能力：监控能力、供给能力、策略/计费能力。

UDM：由两部分构成，一部分叫应用前端（FE），另一部分叫用户数据仓库（UDR）。

其中，待传输数据可以通过UE和DN之间建立的PDU会话（即说明书中所述的通信承载）进行传输，传输会经过（R）AN和UPF这两个网络功能实体，UE和（R）AN之间采用某种空口技术相互通信，N1为UE和AMF之间的接口，N2为（R）AN和AMF之间的接口，N3为（R）AN和UPF之间的接口，N4为SMF和UPF之间的接口，N6为UPF为DN之间的接口；Namf为AMF展现的基于服务的接口，Nsmf为SMF展现的基于服务的接口，Nausf为AUSF展现的基于服务的接口，Nnssf为NSSF展现的基于服务的接口，Nnef为NEF展现的基于服务的接口，Nnrf为NRF展现的基于服务的接口，Npcf为PCF展现的基于服务的接口，Nudm为UDM展现的基于服务的接口，Naf为AF展现的基于服务的接口。

对于UPF、DN、AUSF、NSSF、NEF、NRF和UDM等网元的功能等的介绍，可以参考常规技术中的解释和说明，这里不做赘述。

此外，需要说明的是，在本申请实施例中使用的“系统”和“网络”这样的用语可以互换使用。

此外，在本申请实施例中，UE可以是具有无线连接功能的桌面型设备、膝上型设备、手持型设备、可穿戴设备、智能家居设备、计算设备等。例如，上网本、平板电脑、AR/VR设备等，此次不再一一列举。

另，本申请实施例对UE的具体类型和结构等不作限定。

为了便于理解本申请实施例提供的技术方案中涉及的UE，以下结合图2对一种UE的硬件结构进行说明。

示例性的，在一些实施例中，UE的结构可以如图2所示，如包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线（universal serial bus，USB）接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块（subscriberidentificationmodule，SIM）卡接口195等。

示例性的，在一些实现方式中，传感器模块180可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器，骨传导传感器等，此处不再一一例举，本申请对此不作限制。

可以理解的是，本实施例示意的结构并不构成对UE的具体限定。在另一些实施例中，UE可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

示例性的，在一些实现方式中，处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器（application processor，AP），调制解调处理器，图形处理器（graphics processing unit，GPU），图像信号处理器（image signal processor，ISP），控制器，存储器，视频编解码器，数字信号处理器（digital signal processor，DSP），基带处理器，和/或神经网络处理器（neural-network processing unit，NPU）等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

可理解的，控制器可以是用户设备100的神经中枢和指挥中心。在实际应用中，控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

此外，还需要说明的是，处理器110中还可以设置存储器，用于存储指令和数据。在一些实现方式中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

示例性的，在一些实现方式中，处理器110可以包括一个或多个接口。接口可以包括集成电路（inter-integrated circuit，I2C）接口，集成电路内置音频（inter-integrated circuit sound，I2S）接口，脉冲编码调制（pulse code modulation，PCM）接口，通用异步收发传输器（universal asynchronousreceiver/transmitter，UART）接口，移动产业处理器接口（mobile industry processorinterface，MIPI），通用输入输出（general-purpose input/output，GPIO）接口，用户标识模块（subscriber identitymodule，SIM）接口，和/或通用串行总线（universal serial bus，USB）接口等。

继续参见图2，示例性的，充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实现方式中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。在一些无线充电的实现方式中，充电管理模块140可以通过用户设备100的无线充电线圈接收无线充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为用户设备供电。

继续参见图2，示例性的，电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏194，摄像头193，和无线通信模块160等供电。电源管理模块141还可以用于监测电池容量，电池循环次数，电池健康状态（漏电，阻抗）等参数。在其他一些实现方式中，电源管理模块141也可以设置于处理器110中。在另一些实现方式中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。

继续参见图2，示例性的，用户设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

需要说明的是，天线1和天线2用于发射和接收电磁波信号。用户设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实现方式中，天线可以和调谐开关结合使用。

继续参见图2，示例性的，移动通信模块150可以提供应用在用户设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器（low noise amplifier，LNA）等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实现方式中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实现方式中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

此外，需要说明的是，调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备（不限于扬声器170A，受话器170B等）输出声音信号，或通过显示屏194显示图像或视频。在一些实现方式中，调制解调处理器可以是独立的器件。在另一些实现方式中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

继续参见图2，示例性的，无线通信模块160可以提供应用在用户设备100上的包括无线局域网（wireless local area networks，WLAN）（如无线保真（wireless fidelity，Wi-Fi）网络），蓝牙（bluetooth，BT），全球导航卫星系统（global navigation satellitesystem，GNSS），调频（frequency modulation，FM），近距离无线通信技术（near fieldcommunication，NFC），红外技术（infrared，IR）等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

具体到本申请实施例提供的技术方案中，用户设备100可通过移动通信模块150或无线通信模块160与当前接入的小区进行通信，如向小区发送上行数据，以及接收小区发送的下行数据等。

此外，还需要说明的是，用户设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。

继续参见图2，示例性的，显示屏194用于显示图像，视频等。UE的显示屏194上可以显示一系列图形用户界面（graphical user interface，GUI）。

此外，还需要说明的是，用户设备100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。

此外，还需要说明的是，摄像头193用于捕获静态图像或视频。

继续参见图2，示例性的，外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展用户设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

继续参见图2，示例性的，内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行用户设备100的各种功能应用以及数据处理。

此外，还需要说明的是，用户设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

继续参见图2，示例性的，用户设备100还可以包括按键190、马达191、指示器192等。

此外，还需要说明的是，用户设备100中的SIM卡接口195用于连接SIM卡。SIM卡可以通过插入SIM卡接口195，或从SIM卡接口195拔出，实现和UE的接触和分离。用户设备100可以支持1个或N个SIM卡接口，N为大于1的正整数。SIM卡接口195可以支持Nano SIM卡，Micro SIM卡，SIM卡等。同一个SIM卡接口195可以同时插入多张卡。SIM卡接口195也可以兼容外部存储卡。用户设备100通过SIM卡和网络交互，实现通话以及数据通信等功能。

另外，在上述部件之上，运行有操作系统，例如鸿蒙操作系统、iOS操作系统，Android操作系统，Windows操作系统等。在该操作系统上可以安装运行应用程序。在另一些实施例中，用户设备100内运行的操作系统可以有多个。

应当理解的是，图2所示用户设备包括的硬件模块只是示例性地描述，并不对UE的具体结构做出限定。事实上，本申请实施例提供的用户设备中还可以包含其它与图中示意的硬件模块具有交互关系的其它硬件模块，这里不作具体限定。例如，用户设备还可以包括闪光灯、微型投影装置等。又如，若用户设备是PC，那么用户设备还可以包括键盘、鼠标等部件。

为了更好的说明本申请实施例提供的技术方案，以上述通信系统中与UE进行通信的网络节点为eNodeB为例，对UE需要传输上行数据时，向eNodeB申请上行资源的过程进行具体说明，然在实际应用中，本申请实施例提供的技术方案同样可以适用于其他通信系统，即其他不预先为接入的UE分配上行资源的通信系统。

参见图3，示例性示出一种网络节点为eNodeB的通信系统中，UE向eNodeB申请发送上行数据的上行资源的流程示意图，具体包括：

S101，UE是否有上行数据需要发送。

可理解的，根据现有协议可知，对于UE当前接入的小区为eNodeB等不预先为接入的UE分配上行资源的基站覆盖的小区时，UE想要在当前接入的小区获得eNodeB为其分配的上行资源，需要是在UE有需要发送的上行数据时实现。因此，UE会检测当前是否有上行数据需要发送。为了便于说明，以下均以eNodeB表示UE当前接入的小区，即本申请中UE与eNodeB的交互，实质均是UE与当前接入的小区进行的，而该小区的资源又是由对应的eNodeB控制的。

相应地，如果有需要发送的上行数据，才会基于SR请求向eNodeB申请发送该上行数的上行资源。反之，则继续检测是否有需要发送的上行数据。

需要说明的是，在UE接入某一小区对应的eNodeB后，UE与该eNodeB之间建立的信道，例如可以包括物理下行控制信道（Physical Downlink Control Channel，PDCCH，后续称为：下行控制信道）、物理下行共享信道（Physical Downlink Shared Channel，PDSCH，后续称为：下行数据信道）、物理上行控制信道（Physical Uplink Control Channel，PUCCH，后续称为：上行控制信道）、物理上行共享信道（Physical Uplink Shared Channel，PUSCH，后续称为：上行数据信道）等。

可理解的，其中数据信道是用来真正传输数据的。例如上行数据信道用来传输上行数据，即UE发送给eNodeB的数据；下行数据信道用来传输下行数据，即eNodeB发送给UE的数据。

还应当理解的，控制信道是用来传输信令（还可以是请求、响应等），告知对方在哪个调度周期（TTI），使用哪一位置的资源，通过数据信道传输数据。

示例性的，在一些实现方式中，对于下行控制信道发送的传输指令，如无线资源控制（Radio Resource Control，RRC）信令，可以用于指示UE在哪个调度周期（TTI），使用哪一位置的资源，通过上行数据信道发送数据，或者通过下行数据信道接收数据。

示例性的，在一些实现方式中，对于上行控制信道发送的传输内容，如SR请求，可以用于请求eNodeB为发送该SR请求的UE分配上行资源，以及该上行资源的调度周期等信息。

相应地，eNodeB根据SR请求为UE分配的上行资源以及该上行资源的调度周期等信息，就可以通过下行控制信道告知UE，从而使得UE能够在该上行资源对应的调度周期，使用该上行资源，通过上行数据信道将上行数据发送给eNodeB。

通过上述描述可知，对于上行数据信道发送上行数据时所需的上行资源，eNodeB是没有分配的，而在接收到UE通过上行控制信道发送的SR请求后，为UE分配的。为了保证UE有上行数据需要发送时，UE能够与eNodeB通信申请发送上行数据的上行资源，根据现有协议，eNodeB会为每一个接入的UE分配一个专用的SR资源。这样，UE就可以在该SR资源的调度周期内，使用该SR资源，通过上行控制信道向eNodeB发送SR请求。

此外，需要说明的是，由于SR资源是eNodeB为UE分配的，且不同的UE对应了不同的SR资源，即SR资源与UE是一一对应的，且eNodeB知道SR资源与UE的具体对应关系。因此，对于UE而言，UE在使用eNodeB为其分配的SR资源发送SR请求时，不需要指定自己的身份标识号码（ID），如小区无线网络临时标识符（Cell-RadioNetworkTemporaryIdentifier，C-RNTI），eNodeB根据SR资源的具体位置信息就可以确定是哪一个UE要请求上行资源。

关于eNodeB为接入的UE分配的SR资源，以及及SR资源的调度周期等信息，例如可以通过上行调度请求分配文件（SchedulingRequestConfig）中的字段实现。

示例性的，对于SR资源的位置信息，例如通过SchedulingRequestConfig的sr-PUCCH-ResourceIndex字段分配；对于SR资源的调度周期，例如通过SchedulingRequestConfig的sr-ConfigIndex字段分配。具体的实现细节，可以参见现有协议标准，此处不再赘述。

S102，当前是否有可用的SR资源。

通过上述描述可知，每一个UE对应的SR资源是在其接入eNodeB时，由eNodeB为其分配的，并且eNodeB在为其分配SR资源时，会分配好该UE可以使用的SR资源的具体位置，以及该SR资源的调度周期，并通过下行控制信道告知UE。故而，当UE检测到当前有需要发送的上行数据时，会检测当前是否有可用的SR资源。

关于UE对可用SR资源的检测，具体可以先检测是否接收到eNodeB为其分配的SR资源的相关信息，如SR资源的具体位置信息、调度周期等。

相应地，若UE为接收到eNodeB为其分配的SR资源的相关信息，则可以确定当前没有可用的SR资源；若UE已经接收到了eNodeB为其分配的SR资源的相关信息，则进一步检测当前是否处于该SR资源的调度周期。

相应地，若当前处于该SR资源的调度周期，则可以确定当前有可用的SR资源。

此外，对于接收到eNodeB为其分配的SR资源的相关信息，但当前不处于该SR资源的调度周期的场景，同样可以确定当前有可用的SR资源，只是该SR资源的使用需要等待到达其对应的调度周期时才可用。即对于这种场景，UE需要在该SR资源的下一个调度周期时，才能执行后续的步骤，如步骤S103。

此外，需要说明的是，根据现有协议标准，对于eNodeB没有给UE分配SR资源的场景，该UE可以通过随机接入（Random Access，RA）过程来获取UL grant，进而获得eNodeB为其分配的用于发送上行数据的上行资源。

可理解的，上述所说的随机接入过程，例如为图3中示出的步骤S107，UE初始化PRACH流程。

此外，可理解的，所谓UL grant是一种来自eNodeB的物理控制信息，用于告诉UE可以发送上行数据了，更准确的说是用于告诉UE在收到这个UL Grant后的4ms后，即4个子帧后，可以发送上行数据了。

此外，需要说明的是，UE初始化PRACH流程，向eNodeB申请发送上行数据的上行资源时，eNodeB为UE分配的上行资源可在随机接入响应（Random AccessResponse，RAR）中设置，即eNodeB接收到UE通PRACH发送的随机接入请求，作出UL grant后，会重新分配与UE之间的上行控制信道和半静态调度资源，并通过RAR告知为UE分配的上行资源，以使UE能够通过上行数据信道发送上行数据。

此外，还需要说明的是，根据现有协议标准，通过SR资源发送的SR请求的次数是有限制的，即即便当前有可用的SR资源，但UE使用该SR资源发送SR请求的次数超过设定的最大重传次数，UE将无法再使用该SR资源向eNodeB发送SR请求，向eNodeB申请发送上行数据的上行资源。故而，UE在判定当前有可用的SR资源时，需要进一步判断使用该SR资源发送的SR请求是否超过最大重传次数。

也就是说，UE执行步骤S102后，若检测到有可用的SR资源，则执行步骤S103，否则执行步骤S107。

S103，SR请求是否超过最大重传次数。

示例性的，在一些实现方式中，SR请求的最大重传次数，可以根据实际业务场景，由eNodeB确定后通过下行控制信道告知UE，也可以由eNodeB根据当前可分配的资源确定后通过下行控制信道告知UE。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

相应地，若未超过最大重传次数，则执行步骤S104。反之，若超过最大重传次数，则执行步骤S107。

S104，UE通过SR资源向eNodeB发送SR请求，申请发送上行数据的上行资源。

S105，UE是否接收到eNodeB根据SR请求为UE分配的上行资源。

示例性的，在一些实现方式中，可能存在UE在SR资源的调度周期内，使用SR资源通过上行控制信道向eNodeB发送SR请求后，eNodeB没有可用的资源分配给该UE，这种情况下UE将无法接收到eNodeB根据SR请求为UE分配的上行资源。

示例性的，在另一些实现方式中，可能因为UE与eNodeB之间下行控制信道出现异常，从而导致UE无法接收到eNodeB根据SR请求为UE分配的上行资源。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

为了保证UE能够通过eNodeB分配的上行资源发送上行数据，因此UE在使用SR资源向eNodeB发送SR请求后，需要判断UE是否接收到eNodeB根据SR请求为UE分配的上行资源。

相应地，若接收到，则执行步骤S106。否则，可以返回步骤S103，即在判定当前没有超过最大重传次数时，重新使用SR资源向eNodeB发送SR请求，申请上行资源。

S106，UE通过上行资源，向eNodeB发送上行数据。

可理解的，eNodeB为UE分配的上行资源，同样指示了具体的位置信息和调度周期。因此，UE通过上行资源，向eNodeB发送上行数据时，同样需要检测当前是否满足该上行资源的调度周期，在满足该上行资源的调度周期时，根据位置信息使用指定的上行资源，通过上行数据信道将需要发送的上行数据发送给eNodeB。

S107，初始化PRACH流程，申请发送上行数据的上行资源。

即，UE通过PRACH实现随机接入，向eNodeB申请发送上行数据的上行资源。而eNodeB则通过RAR告知为UE分配的上行资源，并发送UL Grant，告知UE可以使用RAR中分配的上行资源，通过上行数据信道发送上行数据。

S108，是否申请到发送上行数据的上行资源。

通过上述描述可知，UE触发PRACH流程，申请到eNodeB发送的ULgrant后，正常情况下，eNodeB会重新分配与UE之间的上行控制信道和半静态调度资源，并通过RAR告知为UE分配的上行资源，以使UE能够通过上行数据信道发送上行数据。但在实际作业中，eNodeB可能没有重配上行控制信道和半静态调度资源。对于这种情况，根据现有协议标准，UE会重复使用PRACH向eNodeB申请发送上行数据的上行资源。

也就是说，SR请求最大重传时，MAC层会通知RRC层释放上行控制信道占用的资源，并触发PRACH，即初始化PRACH流程，向eNodeB申请UL grant。相应地，在接收到UL grant后，认为PRACH成功，等待eNodeB重配上行控制信道对应的资源和半静态调度资源后作出的RAR，若没有重配上行控制信道对应的资源和半静态调度资源，UE将持续使用PRACH申请上行资源。即，根据现有协议标准，若经步骤S108的判断后，UE没有申请到发送上行数据的上行资源，将持续使用PRACH向eNodeB申请发送上行数据的上行资源，如循环执行步骤S107和步骤S108，直到申请到上行资源，进入步骤S106，或者离开当前eNodeB所在小区，切换到其他eNodeB。

虽然，通过PRACH能够申请到上行资源，但是通过PRACH申请到的上行资源往往很少，这就导致UE通过申请到的上行资源传输上行数据的过程中，会存在卡顿，甚至通话建立失败、断续的问题。

有鉴于此，本申请提供了一种上行资源分配方法，旨在为用户设备合理分配上行资源，避免持续通过PRACH申请上行资源导致对其他用户设备传输上行数据时使用的上行资源的抢占，同时也避免因PRACH申请上行资源导致上行数据传输卡顿，失败的问题发生。

为了更好好的说明本申请提供的上行资源分配方法，以图2示出的硬件结构的用户设备为例，针对网络节点为eNodeB的通信系统中，UE向eNodeB申请上行资源的流程进行具体说明。

需要说明的是，UE与eNodeB之间的通信需要基于Modem协议栈的处理实现，故而在实现本申请各实施例提供的上行资源分配方法时，可将用户设备所遵循的策略、处理逻辑以控制点的形式设置在Modem协议栈中。即，下述各实施例提供的上行资源分配方法，由UE执行的操作，均是在Modem协议栈中完成。其中，涉及判决的过程，可以在MAC层完成，判决之后实际执行的操作可以在RRC层或NAS层完成。

关于Modem协议栈的具体结构，以及每一层能够实现的功能，具体可以参见Modem协议栈的标准文件，此处不再赘述。本申请仅对涉及上行资源分配的流程进行说明。

参见图4，本申请实施例提供的上行资源分配方法，具体包括：

S201，向第一小区发起随机接入请求前，判断当前是否满足预设的发起条件。

具体的说，在本实施例中，第一小区为用户设备当前接入的小区，具体为4G LTE、5G与用户设备（User Equipment，UE）通信的无线基站（eNodeB）覆盖的一个小区。由于eNodeB不会主动为接入其的UE分配上行资源，因此用户设备在确定当前接入的第一小区没有为其配置可用的上行调度请求资源，即SR资源时，会使用物理随机接入信道PRACH向第一小区发起随机接入请求。

通过上述实施例的描述可知，对于没有可用SR资源的场景，例如为第一小区原本就没有为用户设备配置SR资源，还例如为配置了SR资源，但是通过SR资源发送SR请求的次数超过了设置的最大重传次数。

此外，通过上述实施例的描述可知，根据现有协议标准，用户设备在使用PRACH向第一小区发起随机接入请求后，如果没有申请到发送上行数据的上行资源会重复使用PRACH向第一小区申请发送上行数据的上行资源。因此，为了避免这种情况发生，本实施例中，用户设备在向第一小区发起随机接入请求前，会先判断当前是否满足预设的发起条件。

相应地，在确定不满足发起条件时，执行步骤S202，在满足发起条件时才使用PRACH向第一小区发起随机接入请求。

示例性的，在一些实现方式中，预设的发起条件，例如是判断用户设备使用PRACH向第一小区发起随机接入请求的累计次数是否大于设定的次数阈值来确定。例如，通过设置累计次数大于设定的次数阈值时，确定不满足发起条件。

相应地，在累计次数不大于设定的次数阈值时，确定满足发起条件。

示例性的，在另一些实现方式中，预设的发起条件，例如是判断用户设备使用PRACH向第一小区发起随机接入请求的间隔时间是否大于设定的时间阈值来确定。例如，通过设置间隔时间大于设定的时间阈值时，确定不满足发起条件。

相应地，在间隔时间不大于设定的时间阈值时，确定满足发起条件。

示例性的，在另一些实现方式中，预设的发起条件，还可以综合考虑时间和次数两个条件。

例如，在累计次数不大于设定的次数阈值时，进一步确定间隔时间是否大于设定的时间阈值。

相应地，在累计次数不大于设定的次数阈值，间隔时间大于设定的时间阈值时，确定不满足发起条件。反之，在累计次数不大于设定的次数阈值，间隔时间不大于设定的时间阈值时，确定满足发起条件。

还例如，在间隔时间不大于设定的时间阈值时，进一步确定累计次数是否大于设定的次数阈值。

相应地，在间隔时间不大于设定的时间阈值，累计次数大于设定的次数阈值时，确定不满足发起条件。反之，在间隔时间不大于设定的时间阈值，累计次数不大于设定的次数阈值时，确定满足发起条件。

关于上述间隔时间的确定，例如可以是通过获取当前系统时间和上一次向第一小区发起随机接入请求的历史时间，进而根据系统时间和历史时间确定的时间差值。

示例性的，在一些实现方式中，该时间可以通过启动定时器或计时器获得。

此外，关于次数阈值、时间阈值的设置可以根据实际需求进行设置，例如将次数阈值设置为5次，时间阈值设置为2秒。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

S202，在不满足发起条件时，向第一小区发送RRC重建立请求，使第一小区为用户设备重新配置资源。

具体的说，在用户设备向第一小区发起的随机接入请求的累计次数大于次数阈值，和/或发起随机接入请求的时间大于时间阈值时，如果用户设备一直没有接收到第一小区为其重新配置的可用的SR资源，或者没有接收到第一小区为其分配的用于发送上行数据的上行资源。通常情况下，继续向第一小区发起随机接入请求，获得SR资源、上行资源的可能性也较小，这样不仅会造成对其他接入第一小区的用户设备使用的上行资源的抢占，并且即便获得了SR资源、上行资源，其资源也较小，使用其进行上行数据的传输也会存在卡顿，甚至通话建立失败、断续的问题。因此，本实施例中，用户设备在确定当前不满足向第一小区发起随机接入请求的发起条件时，通过第一小区发送RRC（Radio Resource Control，无线资源控制）重建立请求，使得第一小区能够通过一定的策略和手段进行无线资源管理、控制和调度，在满足服务质量的要求下，能够为该用户设备重新配置资源，例如用于发送SR请求的SR资源。

这样，在有可用的SR资源后，用户设备就无需在通过PRACH向第一小区发起随机接入请求，而是直接使用重新配置的SR资源发送SR请求，向第一小区为要发送的上行数据申请上行资源。

S203，在RRC重建立成功后，若第一小区未为用户设备配置上行调度请求资源，触发网络切换，并在设定时长内，禁止重选至第一小区。

具体的说，用户设备在与第一小区重新进行RRC后，若第一小区依旧没有为用户设备配置SR资源，即用户设备依旧无法使用SR资源向第一小区发送SR请求，以使第一小区为用户设备分配发送上行数据的上行资源，为了避免用户设备继续使用PRACH向第一小区发起随机接入请求，继续抢占其他用户设备使用的上行资源，本实施例通过设置用户设备主动进行网络切换，并且为了避免用户设备重新接入第一小区，会设置用户设备在设定时长内，如5分钟，禁止重选至第一小区。即，将Bar掉第一小区5分钟。

相应地，在Bar掉第一小区的设定时长内容，如果用户设备检测到当前位置有其他可以访问的小区（为了区分，将其称为第二小区），则可以接入第二小区，并向第二小区为要发送的上行数据申请上行资源。

需要说明的是，用户设备在当前位置检测到的可以接入的第二小区可以是一个也可以是多个。对于检测到的第二小区只有一个的场景，可以直接选择该第二小区接入。对于检测到的小区有多个的场景，可以通过测报的形式由第一小区为其指定一个网络质量较优的第二小区接入。

此外，需要说明的是，在实际应用中，用户设备检测到的多个小区，可以对应的是同一个基站，也可以是不同的基站。为了便于说明，本实施例以每一个基站对应一个小区为例。

示例性的，参见图5至图8，假设基站A覆盖的小区（后续称为：小区A）、基站B覆盖的小区（后续称为：小区B）和基站C覆盖的小区（后续称为：小区C）为用户设备当前所在位置可以访问的小区。以用户设备当前接入的第一小区为小区A为例，若用户设备有需要发送的上行数据时，经上述步骤的处理后，一直没有得到小区A为其分配的上行资源，在Bar掉小区A时，一种可行的方式是，用户设备直接盲定向到小区B和小区C这两个第二小区中的其中一个。对于盲定向的方式，用户设备可能会接入到网络质量较差的小区，如图6中示出的断开了与小区A之间的连接，切换到网络质量差的小区B。

另一种可行的方式是，用户设备通过向小区A反馈测报结果，告知确定小区B和小区C这两个小区的网络质量的参数信息，以使得小区A能够从中确定一个合适的小区，如网络质量好的小区，并通知小区A切换到网络质量好的小区，例如图7和图8所示。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，需要说明的是，对于用户设备在Bar掉第一小区的时间内，接入的第二小区，在一些实现方式中，其类型可能与第一小区的类型相同，即也是eNodeB。对于这种情况，用户设备在接入第二小区后，向第二小区为要发送的上行数据申请上行资源的流程，可以参见本实施例中用户设备向第一小区为要发送的上行数据申请上行资源的流程，此处不再赘述。

示例性的，在另一些实现方式中，对于接入的第二小区与第一小区的类型不相同，如第二小区为3G LTE中与用户设备通信的NodeB对应的小区时，第二小区会为接入的用户设备分配的上行资源，用户设置在接入该第二小区后，可以直接使用第二小区要发送的上行数据申请上行资源，发送上行数据。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

由此，通过设定发起条件，设置用户设备在没有可用的上行调度请求资源可用的情况下，每次向第一小区发起随机接入请求前，均先确定当前是否满足发起条件，在满足时才发起，而在不满足向第一小区继续发送随机接入请求，同时通过RRC重建第一小区也没有为用户设备配置上行调度请求资源的情况下，通过Bar掉第一小区设定时长，即在设定时长内不接入第一小区，有效避免持续通过PRACH申请上行资源导致对其他用户设备传输上行数据时使用的上行资源的抢占，同时也避免因PRACH申请上行资源导致上行数据传输卡顿，失败的问题发生。

为了更好了理解，不同发起条件下，用户设备判断当前是否满足发起条件的实现流程，以下分别以发起条件中的设置的阈值参数为次数阈值和时间阈值为例，结合图9和10进行具体说明。

参加图9，示例性示出发起条件中的设置的阈值参数为次数阈值时，上行资源分配方法的实现流程。在该实现流程中，具体包括：

S301，UE是否有上行数据需要发送。

S302，当前是否有可用的SR资源。

S303，SR请求是否超过最大重传次数。

S304，UE通过SR资源向eNodeB发送SR请求，申请发送上行数据的上行资源。

S305，UE是否接收到eNodeB根据SR请求为UE分配的上行资源。

S306，UE通过上行资源，向eNodeB发送上行数据。

S307，初始化PRACH流程，申请发送上行数据的上行资源。

不难发现，本实施例中的步骤S301至步骤S307与上述实施例中示出的步骤S101至步骤S107大致相同，具体实现细节可以参见上述实施例，此处不再赘述。

S308，是否申请到发送上行数据的上行资源。

具体的说，在本实施例中，当用户设备通过PRACH流程从eNodeB申请到发送上行数据的上行资源时，用户设备可以直接使用申请到的上行资源发送需要发送的上行数据，即执行步骤S306。否则，执行步骤S309。

需要说明的是，本实施例中描述的用户设备通过PRACH流程未从eNodeB申请到发送上行数据的上行资源的场景指的是用户设备通过PRACH向eNodeB（当前接入的小区，可能与触发PRACH流程前接入的小区相同，也可能不相同）发送随机接入请求后，eNodeB针对该随机接入请求作出了应答，如上述所说的UL grant，但是第一小区并未为用户设备分配上行资源，也没有重新配置可用的SR资源。

可理解的，对于PRACH前后接入的eNodeB为同一个的情况，在该eNodeB没有为用户设备重新分配SR资源，或者发送上行数据的上行资源时，在重新触发PRACH流程时，即重新使用PRACH发起随机接入请求前，就需要考虑用户设备向同一个eNodeB发起的随机接入请求的累计次数是否大于设定的次数阈值，即需要执行步骤S310。而对于PRACH前后接入的eNodeB为不是同一个的情况，PRACH流程后接入的eNodeB为首次接入，因此其对应的累计次数是小于设备的次数阈值的，即满足发起条件，无需执行步骤S310。

故而，对应用户设备通过PRACH流程未从eNodeB申请到发送上行数据的上行资源的场景场景，在进行发起条件判断，即执行步骤S310前，需要先确定当前接入的eNodeB是否与之前的eNodeB相同，即执行步骤S309。

S309，当前接入的eNodeB是否与之前的eNodeB相同。

可理解的，每一个小区（eNodeB，NodeB等）均有自己的标识，如cellID。因此，在确定当前接入的eNodeB是否与之前的eNodeB相同时，可以通过比对PARCH流程前后接入的eNodeB对应的cellID，进而确定当前接入的eNodeB是否与之前的eNodeB相同。

相应地，在确定前接入的eNodeB与之前的eNodeB相同时，执行步骤S310，否则执行步骤S307，初始化PRACH流程，向新接入的eNodeB申请上行资源。

S310，向同一eNodeB发起PRACH流程次数是否大于次数阈值。

可理解的，用户设备在每次发起PRACH流程时，都会记录向当前cellID对应的eNodeB发起的次数，这样在进行是否满足发起条件的判断时，直接获取记录的累计次数，并将累计次数与设定的次数阈值进行比较即可。

示例性的，在一些实现方式中，用户设备向当前cellID对应的eNodeB发起PRACH流程时，可以初始化累计次数这一变量，例如PRACH_UL_Grant=0，在发起PRACH流程后，对PRACH_UL_Grant进行累加，即PRACH_UL_Grant=PRACH_UL_Grant++。这样，在进行是否满足发起条件的判断时，直接获取当前记录的PRACH_UL_Grant的取值即可。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

相应地，若累计次数大于次数阈值，则执行步骤S311，否则执行步骤S307，初始化PRACH流程，继续向该eNodeB申请上行资源。

S311，触发RRC重建。

即，用户设备会向发起PRACH流程次数（累计次数）大于次数阈值的eNodeB发送RRC重建立请求，以使第该eNodeB为用户设备重新配置资源。

S312，是否接入的是同一个eNodeB，并且为UE重新分配了SR资源。

示例性的，如果RRC重建后，用户设备接入的小区为新的eNodeB，对于新的eNodeB，其要执行的流程与之前的eNodeB类似，即会从步骤S302开始，依次按照处理流程进行，不会在新接入的eNodeB没有为用户设备分配SR资源的情况下，直接Bar掉该eNodeB。因此，本实施例主要考虑RRC重建后，用户设备接入的eNodeB依旧为RRC重建前接入的，累计次数大于次数阈值的eNodeB。

具体的，对于RRC重建后，用户设备接入的eNodeB依旧为RRC重建前接入的，累计次数大于次数阈值的eNodeB的场景，可能存在eNodeB为用户设备重新分配SR资源的情况，也可能存在没有为用户设备重新分配SR资源的情况。

示例性的，对于eNodeB为用户设备重新分配SR资源的情况，可以从步骤S303开始，重新执行本实施例提供的上行资源分配方法的流程。

应当理解的，由于RRC重建后，该eNodeB之前累计的SR请求的重传次数清零，因此对于RRC重建后，首次通过SR资源向eNodeB发送SR请求的场景，可以不用判断SR请求是否超过最大重传次数，即RRC重建后，首次通过SR资源向eNodeB发送SR请求时，可以跳过步骤S303，直接执行步骤S304。后续开始累计SR请求的重传次数后，在进行步骤S303的判断。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

示例性的，对于eNodeB没有为用户设备重新分配SR资源的情况，则执行步骤S313。

S313，Bar小区设定时长。

即，上述实施例中所说的，在设定时长，如5分钟内，禁止用户设备重选至该eNodeB。

由此，通过设定次数阈值，判断次数阈值内是否得到可用的上行调度请求资源，在没有可用的上行调度请求资源时，才确定不满足触发条件，进行向第一小区发送RRC重建立请求，触发第一小区为用户设备重新分配上行调度请求资源，从而减少了RRC重建次数，降低用户设备等待第一小区为其分配上行资源的时长。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，在步骤S310中确定累计次数不大于次数阈值，重新执行步骤S307前，可以引入时间阈值进一步进行判断。关于引入时间阈值的判断流程可以参见图10所示实施例，此处不再赘述。这样，通过综合考虑累计次数和时间差值，使得判断结果更加精准，能够更好的适用于实际的使用场景。

此外，在本实施例中出现的eNodeB也是用于表示用户设备当前接入的该eNodeB覆盖的小区。

参加图10，示例性示出发起条件中的设置的阈值参数为时间阈值时，上行资源分配方法的实现流程。在该实现流程中，具体包括：

S401，UE是否有上行数据需要发送。

S402，当前是否有可用的SR资源。

S403，SR请求是否超过最大重传次数。

S404，UE通过SR资源向eNodeB发送SR请求，申请发送上行数据的上行资源。

S405，UE是否接收到eNodeB根据SR请求为UE分配的上行资源。

S406，UE通过上行资源，向eNodeB发送上行数据。

S407，初始化PRACH流程，申请发送上行数据的上行资源。

不难发现，本实施例中的步骤S401至步骤S407与上述实施例中示出的步骤S101至步骤S107大致相同，具体实现细节可以参见上述实施例，此处不再赘述。

S408，启动计时器。

示例性的，在一些实现方式中，根据时间阈值进行的判断，可以通过设置用户设备在每次初始化PRACH流程后，启动一个计算器进行计时。这样，在等待eNodeB为用户设备配置的SR资源的过程中，通过将计算器记录的时间值与设定的时间阈值进行比较，便可以确定时间阈值内eNodeB是否为用户设备重新分配了SR资源。

示例性的，在另一些实现方式中，也可以设置用户设备在每次触发PRACH流程后，记录一下对应的系统时间（历史时间），然后在等待eNodeB为用户设备配置的SR资源的过程中，按照周期或实时获取当前的系统时间，进而根据系统时间和上一次触发PRACH流程时对应的历史时间，确定二者之间的时间差值，进而将确定时间差值与设定的时间阈值进行比较，便可以确定时间阈值内eNodeB是否为用户设备重新分配了SR资源。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

S409，时间阈值内eNodeB是否为UE重新分配了SR资源。

具体的说，若时间阈值内eNodeB没有为用户设备重新分配SR资源，则执行步骤S410；否则，执行步骤S403。

S410，触发RRC重建。

S411，是否接入的是同一个eNodeB，并且为UE重新分配了SR资源。

S312，Bar小区设定时长。

不难发现，本实施例中的步骤S410至步骤S413与上述实施例中的示出的步骤S311至步骤S313大致相同，具体实现细节可以参见上述实施例，此处不再赘述。

由此，通过设定时间阈值，判断时间阈值内是否得到可用的上行调度请求资源，在没有可用的上行调度请求资源时，才确定不满足触发条件，进行向第一小区发送RRC重建立请求，触发第一小区为用户设备重新分配上行调度请求资源，从而减少了RRC重建次数，降低用户设备等待第一小区为其分配上行资源的时长。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，在步骤S409中确定时间差值不大于时间阈值，重新执行步骤S403前，可以引入次数阈值进一步进行判断。关于引入次数阈值的判断流程可以参见图9所示实施例，此处不再赘述。这样，通过综合考虑时间差值和累计次数，使得判断结果更加精准，能够更好的适用于实际的使用场景。

此外，在本实施例中出现的eNodeB也是用于表示用户设备当前接入的该eNodeB覆盖的小区。

此外，可以理解的是，用户设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

此外，需要说明的是，在实际的应用场景中由用户设备实现的上述各实施例提供的上行资源分配方法，也可以由用户设备中包括的一种芯片系统来执行，其中，该芯片系统可以包括处理器。该芯片系统可以与存储器耦合，使得该芯片系统运行时调用该存储器中存储的计算机程序，实现上述用户设备执行的步骤。其中，该芯片系统中的处理器可以是应用处理器也可以是非应用处理器的处理器。

另外，本申请实施例还提供一种计算机可读存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在用户设备上运行时，使得用户设备执行上述相关方法步骤实现上述实施例中的上行资源分配方法。

另外，本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在用户设备上运行时，使得用户设备执行上述相关步骤，以实现上述实施例中的上行资源分配方法。

另外，本申请的实施例还提供一种芯片（也可以是组件或模块），该芯片可包括一个或多个处理电路和一个或多个收发管脚；其中，所述收发管脚和所述处理电路通过内部连接通路互相通信，所述处理电路执行上述相关方法步骤实现上述实施例中的上行资源分配方法，以控制接收管脚接收信号，以控制发送管脚发送信号。

另外，本申请的实施例还提供了一种通信系统，该系统包括eNodeB覆盖的小区和用户设备。其中，eNodeB覆盖的小区例如可以包括上文所说的第一小区，用户设备即上述所说的UE。

此外，通过上述描述可知，本申请实施例提供的用户设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (11)

1.一种上行资源分配方法，其特征在于，应用于用户设备，所述方法包括：

向第一小区发起随机接入请求前，判断当前是否满足预设的发起条件，所述第一小区为所述用户设备当前接入的小区，所述随机接入请求用于请求所述第一小区为所述用户设备要发送的上行数据分配上行资源；

在不满足所述发起条件时，向所述第一小区发送RRC重建立请求，使所述第一小区为所述用户设备重新配置资源；

在所述RRC重建立成功后，若所述第一小区未为所述用户设备配置上行调度请求资源，不向所述第一小区发起所述随机接入请求，触发网络切换，并在设定时长内，禁止重选至所述第一小区。

2.根据权利要求1所述的方法，其特征在于，所述判断当前是否满足预设的发起条件，包括：

获取使用物理随机接入信道向所述第一小区发起所述随机接入请求的累计次数；

在所述累计次数大于设定的次数阈值时，确定不满足所述发起条件。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

在所述累计次数不大于设定的次数阈值时，获取当前系统时间和上一次向所述第一小区发起所述随机接入请求的历史时间；

在所述系统时间和所述历史时间之间的时间差值大于设定的时间阈值时，确定不满足所述发起条件。

4.根据权利要求1所述的方法，其特征在于，所述判断当前是否满足预设的发起条件，包括：

获取当前系统时间和上一次向所述第一小区发起所述随机接入请求的历史时间；

在所述系统时间和所述历史时间之间的时间差值大于设定的时间阈值时，确定不满足所述发起条件。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

在所述系统时间和所述历史时间之间的时间差值不大于设定的时间阈值时，获取使用物理随机接入信道向所述第一小区发起所述随机接入请求的累计次数；

在所述累计次数大于设定的次数阈值时，确定不满足所述发起条件。

6.根据权利要求1至5任一项所述的方法，其特征在于，在禁止重选至所述第一小区之后，所述方法还包括：

在检测到第二小区时，接入所述第二小区，所述第二小区为除所述第一小区外，所述用户设备当前所在位置可以接入的小区；

向所述第二小区为要发送的所述上行数据申请上行资源。

7.根据权利要求1至5任一项所述的方法，其特征在于，所述方法还包括：

在满足所述发起条件时，向所述第一小区发起随机接入请求。

8.根据权利要求1至5任一项所述的方法，其特征在于，所述第一小区为eNodeB覆盖的小区。

9.一种用户设备，其特征在于，所述用户设备包括：存储器和处理器，所述存储器和所述处理器耦合；所述存储器存储有程序指令，所述程序指令由所述处理器执行时，使得所述用户设备执行如权利要求1至8任意一项所述的上行资源分配方法。

10.一种计算机可读存储介质，其特征在于，包括计算机程序，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1至8任意一项所述的上行资源分配方法。

11.一种通信系统，其特征在于，包括：eNodeB覆盖的小区和如权利要求9所述的用户设备。