CN115997461A - 一种处理时延的确定方法、装置、设备及存储介质 - Google Patents

一种处理时延的确定方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN115997461A
CN115997461A CN202280004978.8A CN202280004978A CN115997461A CN 115997461 A CN115997461 A CN 115997461A CN 202280004978 A CN202280004978 A CN 202280004978A CN 115997461 A CN115997461 A CN 115997461A
Authority
CN
China
Prior art keywords
delay
capability information
network side
present disclosure
time slot
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.)
Pending
Application number
CN202280004978.8A
Other languages
English (en)
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.)
Beijing Xiaomi Mobile Software Co Ltd
Original Assignee
Beijing Xiaomi Mobile Software 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 Beijing Xiaomi Mobile Software Co Ltd filed Critical Beijing Xiaomi Mobile Software Co Ltd
Publication of CN115997461A publication Critical patent/CN115997461A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1812—Hybrid protocols; Hybrid automatic repeat request [HARQ]
    • 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/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • 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/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H04W72/044—Wireless resource allocation based on the type of the allocated resource
    • H04W72/0446—Resources in time domain, e.g. slots or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/21—Control channels or signalling for resource management in the uplink direction of a wireless link, i.e. towards the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/51—Allocation or scheduling criteria for wireless resources based on terminal or device properties
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本公开提出一种处理时延的确定方法、装置、设备及存储介质，属于通信技术领域。网络侧设备会获取UE的能力信息，UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延，根据第一时延确定UE的处理时延。由此可知，本公开提供的方法中，网络侧设备基于确定的UE的处理时延指示合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得eRedCap UE正常进行上行传输。

Description

一种处理时延的确定方法、装置、设备及存储介质
技术领域
本公开涉及通信技术领域，尤其涉及一种处理时延的确定方法/装置/设备及存储介质。
背景技术
在通信系统中，UE(User Equipment，用户设备)在PDSCH(Physical DownlinkShared CHannel，物理下行共享信道)传输最后一个符号结束后需要经过处理延时之后，才可以基于网络侧设备指示的进行HARQ-ACK(Hybrid Automatic Repeat request-ACKnowledgement，混合自动重传请求确认)反馈的时隙资源向网络侧设备进行HARQ-ACK反馈。其中，处理时延包括PDSCH的解码时延和PUCCH(Physical Uplink Control CHannel，物理上行链路控制信道)的准备时延。基于此，网络侧设备进行HARQ-ACK反馈的时隙资源指示时，需要考虑终端设备的PDSCH解码时间和PUCCH准备时间。
但是，不同类型的终端设备对应的解码时延和准备时延也不同。其中，eRedCap(enhance Reduced Capability，增强型将低能力)UE的基带处理能力只有5MHz，当eRedCapUE成功接收到超过5MHz的PDSCH(例如，broadcast PDSCH(广播物理下行共享信道))时，eRedCap UE会选择其中5MHz的数据进行解码，如果不能解码成功，则会选择另外5MHz的数据和上一次的数据进行合并后再次进行解码，直至解码成功。由此，eRedCap UE接收PDSCH后可能会进行多次HARQ合并解码，导致网络侧设备无法确定eRedCap UE的处理时延，从而使得网络侧设备指示eRedCap UE的时隙资源可能会出现不合理的情况，进而使得eRedCapUE无法正常进行HARQ-ACK反馈。因此，亟需一种确定eRedCap UE处理时延的方法。
发明内容
本公开提出的处理时延的确定方法/装置/设备及存储介质，用于确定eRedCap UE的处理时延。
第一方面，本公开实施例提供一种处理时延的确定方法，其特征在于，由网络侧设备执行，包括：
获取用户设备UE的能力信息；
所述UE的能力信息指示所述UE为第一类型UE，将第一时延作为所述UE的解码时延；
根据所述第一时延确定所述UE的处理时延。
本公开提供的处理时延的确定方法中，网络侧设备会获取UE的能力信息，UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延，根据第一时延确定UE的处理时延。由此可知，本公开提供的方法中，网络侧设备确定获取到的UE的能力信息指示UE为第一类型UE后，会确定适用于第一类型UE的第一时延，并根据第一时延确定UE的处理时延，然后基于确定的处理时延指示合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得UE可以正常进行上行传输。
第二方面，本公开实施例提供一种处理时延的确定方法，由网络侧设备执行，包括：
为UE分别配置第一上行时隙资源和第二上行时隙资源，其中，所述第二上行时隙资源的晚于所述第一上行时隙资源。
第三方面，本公开实施例提供一种处理时延的确定方法，由UE执行，包括：
向网络侧设备上报所述UE的能力信息。
第四方面，本公开实施例提供一种处理时延的确定方法，由UE执行，包括：
基于网络侧设备配置的第一上行时隙资源或第二上行时隙资源进行上行传输，其中，所述第二上行时隙资源的晚于所述第一上行时隙资源。
第五方面，本公开实施例提供一种通信装置，该装置被配置在网络侧设备中，包括：
获取模块，用于获取用户设备UE的能力信息；
处理模块，用于所述UE的能力信息指示所述UE为第一类型UE，将第一时延作为所述UE的解码时延；
确定模块，用于根据所述第一时延确定所述UE的处理时延。
第六方面，本公开实施例提供一种通信装置，该装置被配置在网络侧设备中，包括：
配置模块，用于为UE分别配置第一上行时隙资源和第二上行时隙资源，其中，所述第二上行时隙资源的晚于所述第一上行时隙资源。
第七方面，本公开实施例提供一种通信装置，该装置被配置在UE中，包括：
上报模块，用于向网络侧设备上报所述UE的能力信息。
第八方面，本公开实施例提供一种通信装置，该装置被配置在UE中，包括：
传输模块，用于基于网络侧设备配置的第一上行时隙资源或第二上行时隙资源进行上行传输，其中，所述第二上行时隙资源的晚于所述第一上行时隙资源。
第九方面，本公开实施例提供一种通信装置，该通信装置包括处理器，当该处理器调用存储器中的计算机程序时，执行上述第一方面至第二方面的任一方面所述的方法。
第十方面，本公开实施例提供一种通信装置，该通信装置包括处理器，当该处理器调用存储器中的计算机程序时，执行上述第三方面至第四方面的任一方面所述的方法。
第十一方面，本公开实施例提供一种通信装置，该通信装置包括处理器和存储器，该存储器中存储有计算机程序；所述处理器执行该存储器所存储的计算机程序，以使该通信装置执行上述第一方面至第二方面的任一方面所述的方法。
第十二方面，本公开实施例提供一种通信装置，该通信装置包括处理器和存储器，该存储器中存储有计算机程序；所述处理器执行该存储器所存储的计算机程序，以使该通信装置执行上述第三方面至第四方面的任一方面所述的方法。
第十三方面，本公开实施例提供一种通信装置，该装置包括处理器和接口电路，该接口电路用于接收代码指令并传输至该处理器，该处理器用于运行所述代码指令以使该装置执行上述第一方面至第二方面的任一方面所述的方法。
第十四方面，本公开实施例提供一种通信装置，该装置包括处理器和接口电路，该接口电路用于接收代码指令并传输至该处理器，该处理器用于运行所述代码指令以使该装置执行上述第三方面至第四方面的任一方面所述的方法。
第十五方面，本公开实施例提供一种通信系统，该系统包括第三方面所述的通信装置至第四方面所述的通信装置，或者，该系统包括第十方面所述的通信装置至第十一方面所述的通信装置，或者，该系统包括第十二方面所述的通信装置至第十三方面所述的通信装置，或者，该系统包括第十四方面所述的通信装置至第十五方面所述的通信装置。
第十六方面，本发明实施例提供一种计算机可读存储介质，用于储存为上述网络设备所用的指令，当所述指令被执行时，使所述终端设备执行上述第一方面至第四方面的任一方面所述的方法。
第十七方面，本公开还提供一种包括计算机程序的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面至第四方面的任一方面所述的方法。
第十八方面，本公开提供一种芯片系统，该芯片系统包括至少一个处理器和接口，用于支持网络设备实现第一方面至第四方面的任一方面所述的方法所涉及的功能，例如，确定或处理上述方法中所涉及的数据和信息中的至少一种。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存源辅节点必要的计算机程序和数据。该芯片系统，可以由芯片构成，也可以包括芯片和其他分立器件。
第十九方面，本公开提供一种计算机程序，当其在计算机上运行时，使得计算机执行上述第一方面至第四方面的任一方面所述的方法。
附图说明
本公开上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
图1为本公开实施例提供的一种通信系统的架构示意图；
图2为本公开另一个实施例所提供的处理时延的确定方法的流程示意图；
图3为本公开再一个实施例所提供的处理时延的确定方法的流程示意图；
图4为本公开又一个实施例所提供的处理时延的确定方法的流程示意图；
图5为本公开另一个实施例所提供的处理时延的确定方法的流程示意图；
图6为本公开再一个实施例所提供的处理时延的确定方法的流程示意图；
图7为本公开又一个实施例所提供的处理时延的确定方法的流程示意图；
图8为本公开一个实施例所提供的处理时延的确定方法的流程示意图；
图9为本公开另一个实施例所提供的处理时延的确定方法的流程示意图；
图10为本公开再一个实施例所提供的处理时延的确定方法的流程示意图；
图11为本公开又一个实施例所提供的处理时延的确定方法的流程示意图；
图12为本公开一个实施例所提供的通信装置的结构示意图；
图13为本公开一个实施例所提供的通信装置的结构示意图；
图14为本公开一个实施例所提供的通信装置的结构示意图；
图15为本公开一个实施例所提供的通信装置的结构示意图；
图16是本公开一个实施例所提供的一种用户设备的框图；
图17为本公开一个实施例所提供的一种网络侧设备的框图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开实施例的一些方面相一致的装置和方法的例子。
在本公开实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开实施例。在本公开实施例和所附权利要求书中所使用的单数形式的“一种”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本公开实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”及“若”可以被解释成为“在……时”或“当……时”或“响应于确定”。
下面详细描述本公开的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的要素。下面通过参考附图描述的实施例是示例性的，旨在用于解释本公开，而不能理解为对本公开的限制。
为了便于理解，首先介绍本申请涉及的术语。
1、物理下行共享信道(Physical Downlink Shared CHannel，PDSCH)
PDSCH用于承载来自DL-SCH(Downlink Shared Channel，下行共享信道)的数据。
2、物理上行链路控制信道(Physical Uplink Control CHannel，PUCCH)
PUCCH用于承载HARQ(Hybrid Automatic Repeat reQuest，混合自动重传请求)的ACK(Acknowledgement，确认)/NACK(Negative Acknowledgement，否定确认)，调度请求(Scheduling Request)，信道质量指示(Channel Quality Indicator)等信息。
本公开实施例中涉及到的各种网元/功能，其既可以是一个独立的硬件设备，也可以是在硬件设备内的通过计算机代码实现的功能，本公开实施例中并不对此做出限定。
请参见图1，图1为本公开实施例提供的一种通信系统的架构示意图。该通信系统可包括但不限于一个网络设备和一个终端设备，图1所示的设备数量和形态仅用于举例并不构成对本公开实施例的限定，实际应用中可以包括两个或两个以上的网络设备，两个或两个以上的终端设备。图1所示的通信系统以包括一个网络设备11、一个终端设备12为例。
需要说明的是，本公开实施例的技术方案可以应用于各种通信系统。例如：长期演进(long term evolution，LTE)系统、第五代(5th generation，5G)移动通信系统、5G新空口(new radio，NR)系统，或者其他未来的新型移动通信系统等。
本公开实施例中的网络设备11是网络侧的一种用于发射或接收信号的实体。例如，网络设备11可以为演进型基站(evolved NodeB，eNB)、发送接收点(transmissionreception point，TRP)、NR系统中的下一代基站(next generation NodeB，gNB)、其他未来移动通信系统中的基站或无线保真(wireless fidelity，WiFi)系统中的接入节点等。本公开的实施例对网络设备所采用的具体技术和具体设备形态不做限定。本公开实施例提供的网络设备可以是由集中单元(central unit，CU)与分布式单元(distributed unit，DU)组成的，其中，CU也可以称为控制单元(control unit)，采用CU-DU的结构可以将网络设备，例如基站的协议层拆分开，部分协议层的功能放在CU集中控制，剩下部分或全部协议层的功能分布在DU中，由CU集中控制DU。
本公开实施例中的终端设备12是用户侧的一种用于接收或发射信号的实体，如手机。终端设备也可以称为终端设备(terminal)、用户设备(user equipment，UE)、移动台(mobile station，MS)、移动终端设备(mobile terminal，MT)等。终端设备可以是具备通信功能的汽车、智能汽车、手机(mobile phone)、穿戴式设备、平板电脑(Pad)、带无线收发功能的电脑、虚拟现实(virtual reality，VR)终端设备、增强现实(augmented reality，AR)终端设备、工业控制(industrial control)中的无线终端设备、无人驾驶(self-driving)中的无线终端设备、远程手术(remote medical surgery)中的无线终端设备、智能电网(smart grid)中的无线终端设备、运输安全(transportation safety)中的无线终端设备、智慧城市(smart city)中的无线终端设备、智慧家庭(smart home)中的无线终端设备等等。本公开的实施例对终端设备所采用的具体技术和具体设备形态不做限定。
可以理解的是，本公开实施例描述的通信系统是为了更加清楚的说明本公开实施例的技术方案，并不构成对于本公开实施例提供的技术方案的限定，本领域普通技术人员可知，随着系统架构的演变和新业务场景的出现，本公开实施例提供的技术方案对于类似的技术问题，同样适用。
下面参考附图对本公开实施例所提供的处理时延的确定方法/装置/设备及存储介质进行详细描述。
图2为本公开实施例所提供的一种处理时延的确定方法的流程示意图，其中，该方法由网络侧设备执行，如图2所示，该处理时延的确定方法可以包括以下步骤：
步骤201、获取UE的能力信息。
其中，在本公开的一个实施例之中，上述获取UE的能力信息的方法可以包括以下至少一种：
接收UE通过separate initial UL BWP(separate initial UpLink BandwidthPart，独立初始上行部分带宽)或者separate PRACH resource(separate PhysicalRandom Access Channel resource，独立物理随机接入信道资源)上报的能力信息；
接收UE通过MSG3上报的能力信息；
接收UE通过RRC(Radio Resource Control，无线资源控制)信令上报的能力信息。
具体地，在本公开的一个实施例之中，网络侧设备可以在RACH(Random accesschannel，随机接入信道)中，通过early indication机制获取UE的能力信息。具体地，在本公开的一个实施例之中，可以接收UE通过separate initial UL BWP或者separate PRACHresource上报的能力信息。
以及，在本公开的一个实施例之中，网络侧设备接收UE通过MSG3上报的能力信息的方法可以包括：通过在MSG3中承载的指示字段接收UE上报的能力信息。在本公开的另一个实施例中，网络侧设备接收UE通过MSG3上报的能力信息的方法可以包括：通过新的CCCH(Common Control Channel，公共控制信道)信道接收UE上报的能力信息。
进一步地，在本公开的一个实施例中，上述能力信息可以包括以下至少之一：
UE的处理能力信息；
UE的终端类型；
UE支持的带宽；
UE的后缓冲器post-FFT buffer的大小
UE的HARQ的合并能力。
其中，在本公开的一个实施例之中，上述UE的能力信息可以用于指示UE对承载SIB1(System information block 1，系统消息1)、OSI(Other system information，其他系统消息)、paging(寻呼)、RAR(Random access response，随机接入响应)、MSGA以及MSG4的PDSCH信道的处理能力。以及，在本公开的另一个实施例之中，上述UE的能力信息可以用于指示UE对全部PDSCH信道的处理能力。
以及，在本公开的一个实施例之中，上述UE的终端类型可以包括legacy UE(传统用户设备)、eRedCap UE中的至少一种。在本公开的一个实施例之中，上述UE支持的带宽是该UE处理数据的带宽(如，5Mhz)。在本公开的一个实施例之中，UE的处理能力信息可以指示一种新定义的处理能力。
需要说明的是，在本公开的一个实施例之中，网络侧设备可以主动获取UE的能力信息，如在RACH过程中，通过early indication机制获取UE的能力信息。以及，在本公开的另一个实施例之中，网络侧设备可以指示UE需要上报该UE的能力信息后，获取UE的能力信息。关于这部分内容会在后续实施例中进行详细介绍。
步骤202、UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延。
其中，在本公开的一个实施例之中，网络侧设备可以根据获取UE的能力信息确定该UE对应的类型。
具体地，在本公开的一个实施例之中，网络侧设备可以根据获取UE的能力信息隐式或显式的确定该UE对应的类型。具体地，在本公开的一个实施例之中，若网络侧设备获取UE的能力信息中包括UE的UE的终端类型，则网络侧设备根据UE的终端类型显式的确定该UE对应的类型。以及，在本公开的另一个实施例之中，若网络侧设备获取UE的能力信息中包括UE的处理能力信息或UE支持的带宽，则网络侧设备根据UE的处理能力信息或UE支持的带宽隐式的确定该UE对应的类型。
以及，在本公开的一个实施例之中，上述第一类型UE可以为eRedCap UE。
以及，在本公开的一个实施例之中，若确定UE为第一类型UE，则确定第一时延，并将第一时延作为UE的解码时延。关于确定第一时延的详细内容会在后续实施例中进行介绍。
步骤203、根据第一时延确定UE的处理时延。
其中，在本公开的一个实施例之中，网络侧设备可以根据第一时延确定UE不同过程的处理时延。
具体地，在本公开的一个实施例之中，网络侧设备可以将第一时延与第一预设值之和作为UE接收到Msg2到发送新的Msg1之间的最小间隔(即上述处理时延)。
示例的，在本公开的一个实施例之中，假设UE在T1时刻接收到Msg2，在T2时刻发送新的Msg1，则T1至T2的最小时间间隔为第一时延与第一预设值之和。
以及，在本公开的另一个实施例之中，网络侧设备可以获取UE的准备时延，并将第一时延、准备时延和第二预设值之和作为UE接收到Msg2到发送Msg3之间的最小时间间隔(即上述处理时延)。
示例的，在本公开的一个实施例之中，假设UE在T3时刻接收到Msg2，在T4时刻发送Msg3，则T3至T4的最小时间间隔为第一时延、准备时延和第二预设值之和。
进一步地，在本公开的又一个实施之中，网络侧设备可以将第一时延与第二预设值之和作为UE收到Msg4到发送HARQ-ACK反馈的最小时间间隔。
示例的，在本公开的一个实施例之中，假设UE在T5时刻接收到Msg4，在T6时刻发送HARQ-ACK反馈，则T5至T6的最小时间间隔为第一时延与第二预设值之和。
在本公开的另一个实施例之中，网络侧设备可以将第一时延与第一预设值之和作为UE接收PDSCH到发送HARQ(Hybrid Automatic Repeat request，混合自动重传请求)反馈之间的最小间隔。
示例的，在本公开的一个实施例之中，假设UE在T7时刻接收到PDSCH，在T8时刻发送HARQ反馈，则T7至T8的最小时间间隔为第一时延与第一预设值之和。
以及，在本公开的一个实施例之中，上述第一预设值可以设置为0.75。以及，在本公开的另一个实施例之中，上述第二预设值可以设置为0.5。
进一步地，在本公开的一个实施例之中，网络侧设备确定UE的处理时延之后，可以根据UE的处理时延指示合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得eRedcap UE可以正常进行上行传输。
综上所述，在本公开实施例提供的处理时延的确定方法中，网络侧设备会获取UE的能力信息，UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延，根据第一时延确定UE的处理时延。由此可知，本公开提供的方法中，网络侧设备确定获取到的UE的能力信息指示UE为第一类型UE后，会确定适用于第一类型UE的第一时延，并根据第一时延确定UE的处理时延，然后基于确定的处理时延指示合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得UE可以正常进行上行传输。
图3为本公开实施例所提供的一种处理时延的确定方法的流程示意图，该方法由网络侧设备执行，如图3所示，该处理时延的确定方法可以包括以下步骤：
步骤301、UE的能力信息指示UE为第一类型UE，通过公式确定第一时延，并将第一时延作为UE的解码时延。
其中，在本公开的一个实施例之中，第一时延可以通过以下任一公式确定：
NT,1_new＝NT,1+delta；
NT,1_new＝m*NT,1；
其中，NT,1_new为第一时延，NT,1为第二时延，delta或m为预设值。
以及，在本公开的一个实施例之中，上述delta或m可以由协议规定。具体地，在本公开的一个实施例之中，协议中规定对于不同HARQ合并的次数，上述delta或m具有不同的取值。其中，在本公开的一个实施例之中，网络侧设备可以基于协议规定确定上述delta或m的取值，并将该delta或m的取值代入上述对应的公式中确定第一时延。
进一步地，在本公开的另一个实施例之中，上述delta或m可以由网络侧设备进行配置。
其中，在本公开的一个实施例之中，上述第二时延可以为现有技术中基于legacyUE确定的一次解码时延，通过上述公式可以得出，第一时延是在第二时延的基础上延长了解码时间，以使得确定的第一时延可以适用于eRedcap UE进行多次HARQ合并译码的过程，以便后续网络侧设备基于第一时延确定适用于eRedcap UE的处理时延。
此外，关于本实施例的其他详细内容可以参考上述实施例描述。
综上所述，在本公开实施例提供的处理时延的确定方法中，网络侧设备会获取UE的能力信息，UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延，根据第一时延确定UE的处理时延。由此可知，本公开提供的方法中，网络侧设备确定获取到的UE的能力信息指示UE为第一类型UE后，会确定适用于第一类型UE的第一时延，并根据第一时延确定UE的处理时延，然后基于确定的处理时延指示合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得UE可以正常进行上行传输。
图4为本公开实施例所提供的一种处理时延的确定方法的流程示意图，该方法由网络设备执行，如图4所示，该处理时延的确定方法可以包括以下步骤：
步骤401、UE的能力信息指示UE为第一类型UE，确定当前网络允许的最多可进行HARQ合并的次数。
其中，在本公开的一个实施之中，网络侧设备可以基于当前网络情况确定允许的最多可进行HARQ合并的次数。
步骤402、根据当前网络允许的最多可进行HARQ合并的次数和第二时延确定第一时延，并将第一时延作为UE的解码时延。
其中，在本公开的一个实施例之中，上述第二时延可以为现有技术中基于legacyUE能力确定的一次解码时延，则根据当前网络允许的最多可进行HARQ合并的次数和第二时延确定第一时延的方法可以包括：第一时延＝最多可进行HARQ合并的次数ⅹ第二时延。在本公开的一个实施例之中，通过上述方法确定的第一时延是当前网络侧设备可以配置给eRedcap UE最长的解码时延，从而确保eRedcap UE可以进行多次HARQ合并译码，保证了后续eRedcap UE可以正常进行上行传输。
此外，关于本实施例的其他详细内容可以参考上述实施例描述。
综上所述，在本公开实施例提供的处理时延的确定方法中，网络侧设备会获取UE的能力信息，UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延，根据第一时延确定UE的处理时延。由此可知，本公开提供的方法中，网络侧设备确定获取到的UE的能力信息指示UE为第一类型UE后，会确定适用于第一类型UE的第一时延，并根据第一时延确定UE的处理时延，然后基于确定的处理时延指示合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得UE可以正常进行上行传输。
图5为本公开实施例所提供的一种处理时延的确定方法的流程示意图，该方法由网络设备执行，如图5所示，该处理时延的确定方法可以包括以下步骤：
步骤501、UE的能力信息指示UE为第二类型UE，将第二时延作为UE的解码时延。
其中，在本公开的一个实施例之中，上述第二时延小于第一时延。
以及，在本公开的一个实施例之中，若UE的能力信息为第二类型UE，则该UE不需要进行多次HARQ合并解码，基于此，上述第二时延可以为现有技术中基于legacy UE确定的一次解码时延。
其中，在本公开的一个实施例之中，上述第二类型UE可以为legacy UE。
步骤502、根据第二时延确定UE的处理时延。
其中，在本公开的一个实施例之中，网络侧设备可以根据第二时延确定UE不同过程的处理时延。
具体地，在本公开的一个实施例之中，网络侧设备可以将第二时延与第一预设值之和作为UE接收到Msg2到发送新的Msg1之间的最小间隔(即上述处理时延)。
示例的，在本公开的一个实施例之中，假设UE在T9时刻接收到Msg2，在T10时刻发送新的Msg1，则T9至T10的最小时间间隔为第二时延与第一预设值之和。
以及，在本公开的另一个实施例之中，网络侧设备可以获取UE的准备时延，并将第二时延、准备时延和第二预设值之和作为UE接收到Msg2到发送Msg3之间的最小时间间隔(即上述处理时延)。
示例的，在本公开的一个实施例之中，假设UE在T11时刻接收到Msg2，在T12时刻发送Msg3，则T11至T12的最小时间间隔为第二时延、准备时延和第二预设值之和。
进一步地，在本公开的又一个实施之中，网络侧设备可以将第二时延与第二预设值之和作为UE收到Msg4到发送HARQ-ACK反馈的最小时间间隔。
示例的，在本公开的一个实施例之中，假设UE在T13时刻接收到Msg4，在T14时刻发送HARQ-ACK反馈，则T13至T14的最小时间间隔为第二时延与第二预设值之和。
在本公开的另一个实施例之中，网络侧设备可以将第二时延与第一预设值之和作为UE接收PDSCH到发送HARQ反馈之间的最小间隔。
示例的，在本公开的一个实施例之中，假设UE在T15时刻接收到PDSCH，在T16时刻发送HARQ反馈，则T15至T16的最小时间间隔为第二时延与第一预设值之和。
以及，在本公开的一个实施例之中，上述第一预设值可以设置为0.75。以及，在本公开的另一个实施例之中，上述第二预设值可以设置为0.5。
此外，关于本实施例的其他详细内容可以参考上述实施例描述。
综上所述，在本公开实施例提供的处理时延的确定方法中，网络侧设备会获取UE的能力信息，UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延，根据第一时延确定UE的处理时延。由此可知，本公开提供的方法中，网络侧设备确定获取到的UE的能力信息指示UE为第一类型UE后，会确定适用于第一类型UE的第一时延，并根据第一时延确定UE的处理时延，然后基于确定的处理时延指示合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得UE可以正常进行上行传输。
图6为本公开实施例所提供的一种处理时延的确定方法的流程示意图，该方法由网络侧设备执行，如图6所示，该处理时延的确定方法可以包括以下步骤：
步骤601、为UE分别配置第一上行时隙资源和第二上行时隙资源。
其中，在本公开的一个实施例之中，上述第二上行时隙资源的晚于第一上行时隙资源。
其中，在本公开的一个实施例之中，网络侧设备执行步骤601的前提是网络侧设备未获取到UE的能力信息，也即是网络侧设备不能确定当前UE的类型是否为第一类型UE，基于此，网络侧设备向所有UE均配置第一上行时隙资源和第二上行时隙资源，且第二上行时隙资源的晚于第一上行时隙资源，从而使得UE可以根据自身的处理能力从第一上行时隙资源和第二上行时隙资源中选择合适的时隙资源。
具体地，在本公开的一个实施例之中，当UE的类型不是第一类型UE时，此时该UE不需要进行多次HARQ合并解码，所需的处理时延较短，则该UE可以选择第一上行时隙资源进行上行传输；当UE的类型为第一类型UE时，此时该UE进行多次HARQ合并解码，所需的处理时延较长，则该UE可以选择第二上行时隙资源进行上行传输。通过上述步骤701的方法，可以使得UE选择合适的时隙资源进行上行传输，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得eRedcap UE可以正常进行上行传输。
此外，关于本实施例的其他详细内容可以参考上述实施例描述。
综上所述，在本公开实施例提供的处理时延的确定方法中，网络侧设备会获取UE的能力信息，UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延，根据第一时延确定UE的处理时延。由此可知，本公开提供的方法中，网络侧设备确定获取到的UE的能力信息指示UE为第一类型UE后，会确定适用于第一类型UE的第一时延，并根据第一时延确定UE的处理时延，然后基于确定的处理时延指示合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得UE可以正常进行上行传输。
图7为本公开实施例所提供的一种处理时延的确定方法的流程示意图，该方法由网络侧设备执行，如图7所示，该处理时延的确定方法可以包括以下步骤：
步骤701、基于处理时延对第一类型UE和第二类型UE进行调度。
其中，在本公开的一个实施例之中，在某些场景下，即使是基于第一类型UE(如，eRedcap UE)的能力确定的处理时延，同样也可以适用于第二类UE(legacy UE)。基于此，使得无论UE是第一类型UE还是第二类型UE，网络侧设备均可以基于该处理时延为UE分配合理的时隙资源，由此该UE基于分配的时隙资源进行上行传输，并且网络侧设备基于该处理时延调度时隙资源，进而使得eRedcap UE可以正常进行上行传输，即在该处理时延内可实现对第一类型终端的调度，也实现对第二类型终端的调度。
此外，关于本实施例的其他详细内容可以参考上述实施例描述。
综上所述，在本公开实施例提供的处理时延的确定方法中，网络侧设备会获取UE的能力信息，UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延，根据第一时延确定UE的处理时延。由此可知，本公开提供的方法中，网络侧设备确定获取到的UE的能力信息指示UE为第一类型UE后，会确定适用于第一类型UE的第一时延，并根据第一时延确定UE的处理时延，然后基于确定的处理时延指示合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得UE可以正常进行上行传输。
图8为本公开实施例所提供的一种处理时延的确定方法的流程示意图，该方法由网络设备执行，如图8所示，该处理时延的确定方法可以包括以下步骤：
步骤801、向UE发送上报能力指示信息。
其中，在本公开的一个实施例之中，上述上报能力指示信息用于指示UE是否需要上报能力信息。
以及，在本本公开的一个实施例之中，上述上报能力指示信息可以包括N个比特位，其中N为正整数。示例的，在本公开的一个实施例之中，假设上报能力指示信息包括1个比特位，其中，当比特位为1时，则上报能力指示信息指示UE需要上报能力信息；当比特位为0时，则上报能力指示信息指示UE不需要上报能力信息。
进一步地，在本公开的一个实施例之中，当上述上报能力指示信息指示UE需要上报能力信息时，网络侧设备获取或未获取UE上报的能力信息，对应确定UE的处理时延的方法也不相同。
具体地，在本公开的一个实施例之中，当上述上报能力指示信息指示UE需要上报能力信息时，且网络侧设备获取UE上报的能力信息，则可以通过上述实施例确定UE的处理时延。
以及，在本公开的一个实施例之中，当上述上报能力指示信息指示UE需要上报能力信息时，且网络侧设备未获取UE上报的能力信息，也即是网络侧设备不能确定当前UE是否为第一类型UE，基于此，网络侧设备通过上述步骤601或步骤701为UE分配合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得eRedcap UE可以正常进行上行传输。
此外，关于本实施例的其他详细内容可以参考上述实施例描述。
综上所述，在本公开实施例提供的处理时延的确定方法中，网络侧设备会获取UE的能力信息，UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延，根据第一时延确定UE的处理时延。由此可知，本公开提供的方法中，网络侧设备确定获取到的UE的能力信息指示UE为第一类型UE后，会确定适用于第一类型UE的第一时延，并根据第一时延确定UE的处理时延，然后基于确定的处理时延指示合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得UE可以正常进行上行传输。
图9为本公开实施例所提供的一种处理时延的确定方法的流程示意图，该方法由UE执行，如图9所示，该处理时延的确定方法可以包括以下步骤：
步骤901、向网络侧设备上报UE的能力信息。
其中，在本公开的一个实施例之中，上述向网络侧设备上报UE的能力信息的方法可以包括以下至少一种：
通过separate initial UL BWP或者separate PRACH resource向网络侧设备上报UE的能力信息；
通过MSG3向网络侧设备上报UE的能力信息；
通过RRC信令向所述网络侧设备上报UE的能力信息。
以及，在本公开的一个实施例之中，UE可以在RACH过程中，通过early indication机制向网络侧设备上报UE的能力信息。具体地，在本公开的一个实施例之中，可以通过separate initial UL BWP或者separate PRACH resource向网络侧设备上报UE的能力信息。
进一步地，在本公开的一个实施例之中，UE通过MSG3向网络侧设备上报UE的能力信息的方法可以包括：通过在MSG3中承载的指示字段向网络侧设备上报UE的能力信息。在本公开的另一个实施例中，通过MSG3上报的能力信息的方法可以包括：通过新的CCCH信道向网络侧设备上报UE的能力信息。
进一步地，在本公开的一个实施例之中，上述能力信息可以包括以下至少之一：
UE的处理能力信息；
UE的终端类型；
UE支持的带宽；
UE的post-FFT buffer的大小；
UE的HARQ的合并能力。
进一步地，在本公开的一个实施例之中，UE可以根据自身的处理能力对PDSCH进行处理，并在对PDSCH处理完成后，基于网络侧设备指示的时隙资源向网络侧设备进行上行传输。
以及，在本公开的一个实施例之中，网络侧设备获取UE的能力信息之后，可以基于UE的能力信息确定UE的类型，并基于UE的类型确定UE是否为第一类型UE，以确定对应的处理时延，再根据处理时延为UE分配合适的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得eRedcap UE可以正常进行上行传输。
需要说明的是，在本公开的一个实施例之中，UE可以主动主动向网络侧设备上报UE的能力信息，如在RACH过程中，通过early indication机制上报UE的能力信息。以及，在本公开的另一个实施例之中，UE可以当网络侧设备指示UE需要上报该UE的能力信息时，上报UE的能力信息。关于这部分内容会在后续实施例中进行详细介绍。
此外，关于本实施例的其他详细内容可以参考上述实施例描述。
综上所述，在本公开实施例提供的处理时延的确定方法中，网络侧设备会获取UE的能力信息，UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延，根据第一时延确定UE的处理时延。由此可知，本公开提供的方法中，网络侧设备确定获取到的UE的能力信息指示UE为第一类型UE后，会确定适用于第一类型UE的第一时延，并根据第一时延确定UE的处理时延，然后基于确定的处理时延指示合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得UE可以正常进行上行传输。
图10为本公开实施例所提供的一种处理时延的确定方法的流程示意图，该方法由UE执行，如图10所示，该处理时延的确定方法可以包括以下步骤：
步骤1001、接收网络侧设备发送的上报能力指示信息。
其中，在本公开的一个实施例之中，上述上报能力指示信息可以用于指示UE是否需要上报能力信息。
以及，在本本公开的一个实施例之中，上述上报能力指示信息可以包括N个比特位，其中N为正整数。示例的，在本公开的一个实施例之中，假设上报能力指示信息包括1个比特位，其中，当比特位为1时，则上报能力指示信息指示UE需要上报能力信息；当比特位为0时，则上报能力指示信息指示UE不需要上报能力信息。
进一步地，在本公开的一个实施例之中，当上报能力指示信息指示UE需要上报能力信息时，UE可以上报能力信息或者不上报能力信息。
此外，关于本实施例的其他详细内容可以参考上述实施例描述。
综上所述，在本公开实施例提供的处理时延的确定方法中，网络侧设备会获取UE的能力信息，UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延，根据第一时延确定UE的处理时延。由此可知，本公开提供的方法中，网络侧设备确定获取到的UE的能力信息指示UE为第一类型UE后，会确定适用于第一类型UE的第一时延，并根据第一时延确定UE的处理时延，然后基于确定的处理时延指示合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得UE可以正常进行上行传输。
图11为本公开实施例所提供的一种处理时延的确定方法的流程示意图，该方法由UE执行，如图11所示，该处理时延的确定方法可以包括以下步骤：
步骤1101、基于网络侧设备配置的第一上行时隙资源和第二上行时隙资源进行上行传输。
其中，在本公开的一个实施例之中，上述第二上行时隙资源的晚于第一上行时隙资源。
以及，在本公开的一个实施例之中，UE可以根据自身的类型从第一上行时隙资源和第二上行时隙资源中选择合适的时隙资源。
具体地，在本公开的一个实施例之中，当UE的类型为第二类型UE时，此时该UE不需要进行多次HARQ合并解码，所需的处理时延较短，则该UE可以选择第一上行时隙资源进行上行传输；当UE的类型为第一类型UE时，此时该UE不进行多次HARQ合并解码，所需的处理时延较长，则该UE可以选择第二上行时隙资源进行上行传输。通过上述步骤1101的方法，可以使得UE选择合适的时隙资源进行上行传输，使得eRedcap UE可以正常进行上行传输。
此外，关于本实施例的其他详细内容可以参考上述实施例描述。
综上所述，在本公开实施例提供的处理时延的确定方法中，网络侧设备会获取UE的能力信息，UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延，根据第一时延确定UE的处理时延。由此可知，本公开提供的方法中，网络侧设备确定获取到的UE的能力信息指示UE为第一类型UE后，会确定适用于第一类型UE的第一时延，并根据第一时延确定UE的处理时延，然后基于确定的处理时延指示合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得UE可以正常进行上行传输。
图12为本公开实施例所提供的一种通信装置的结构示意图，如图12所示，装置可以包括：
获取模块1201，用于获取UE的能力信息；
处理模块1202，用于UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延；
确定模块1203，用于根据第一时延确定UE的处理时延。
综上所述，在本公开实施例提供的通信装置中，网络侧设备会获取UE的能力信息，UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延，根据第一时延确定UE的处理时延。由此可知，本公开提供的方法中，网络侧设备确定获取到的UE的能力信息指示UE为第一类型UE后，会确定适用于第一类型UE的第一时延，并根据第一时延确定UE的处理时延，然后基于确定的处理时延指示合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得UE可以正常进行上行传输。
可选的，在本公开的一个实施例之中，上述装置还用于：
UE的能力信息指示UE为第二类型UE，将第二时延作为UE的解码时延，其中，第二时延小于第一时延；
根据第二时延确定UE的处理时延。
可选的，在本公开的一个实施例之中，上述处理模块1202还用于通过以下任一公式获得第一时延：
NT,1_new＝NT,1+delta；
NT,1_new＝m*NT,1；
其中，NT,1_new为第一时延，NT,1为第二时延，delta或m为预设值。：
可选的，在本公开的一个实施例之中，delta或m由协议规定，或者由网络侧设备配置获得。
可选的，在本公开的一个实施例之中，上述处理模块1202，还用于
确定当前网络允许的最多可进行HARQ合并的次数；
根据当前网络允许的最多可进行HARQ合并的次数和第二时延确定第一时延。
可选的，在本公开的一个实施例之中，上述确定模块1901还用于：
将第一时延或第二时延与第一预设值之和作为UE接收到Msg2到发送新的Msg1之间的最小间隔；
获取UE的准备时延，并将第一时延或第二时延、准备时延和第二预设值之和作为UE接收到Msg2到发送Msg3之间的最小时间间隔；
将第一时延或第二时延与第二预设值之和作为UE收到Msg4到发送HARQ-ACK反馈的最小时间间隔；
将第一时延或第二时延域与第一预设值之和作为UE接收到PDSCH到发送HARQ反馈之间的最小间隔。
可选的，在本公开的一个实施例之中，上述获取模块1201还用于以下至少一种：
接收UE通过separate initial UL BWP或者separate PRACH resource上报的能力信息；
接收UE通过MSG3上报的能力信息；
接收UE通过RRC信令上报的所述能力信息。
可选的，在本公开的一个实施例之中，上述装置还用于：
向UE发送上报能力指示信息，上报能力指示信息用于指示UE是否需要上报能力信息。
可选的，在本公开的一个实施例之中，能力信息包括以下至少一种：
UE的处理能力信息；
UE的终端类型；
UE支持的带宽；
UE的post-FFT buffer的大小；
UE的HARQ的合并能力。
可选的，在本公开的一个实施例之中，上述装置还用于：基于处理时延对第一类型UE和第二类型UE进行调度。
可选的，在本公开的一个实施例之中，第一类型UE为eRedcap UE，第二类型UE为legacy UE。
图13为本公开实施例所提供的一种通信装置的结构示意图，如图13所示，装置可以包括：
配置模块1301，用于为UE分别配置第一上行时隙资源和第二上行时隙资源，其中，第二上行时隙资源的晚于第一上行时隙资源。
综上所述，在本公开实施例提供的通信装置中，网络侧设备会获取UE的能力信息，UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延，根据第一时延确定UE的处理时延。由此可知，本公开提供的方法中，网络侧设备确定获取到的UE的能力信息指示UE为第一类型UE后，会确定适用于第一类型UE的第一时延，并根据第一时延确定UE的处理时延，然后基于确定的处理时延指示合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得UE可以正常进行上行传输。
图14为本公开实施例所提供的一种通信装置的结构示意图，如图14所示，装置可以包括：
上报模块1401，用于向网络侧设备上报UE的能力信息。
综上所述，在本公开实施例提供的通信装置中，网络侧设备会获取UE的能力信息，UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延，根据第一时延确定UE的处理时延。由此可知，本公开提供的方法中，网络侧设备确定获取到的UE的能力信息指示UE为第一类型UE后，会确定适用于第一类型UE的第一时延，并根据第一时延确定UE的处理时延，然后基于确定的处理时延指示合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得UE可以正常进行上行传输。
可选的，在本公开的一个实施例之中，上述上报模块1401还用于以下至少之一：
通过separate initial UL BWP或者separate PRACH resource向网络侧设备上报UE的能力信息；
通过MSG3向网络侧设备上报UE的能力信息；
通过RRC信令向网络侧设备上报UE的能力信息。
可选的，在本公开的一个实施例之中，上述装置还用于：
接收网络侧设备发送的上报能力指示信息，上报能力指示信息用于指示UE是否需要上报能力信息。
可选的，在本公开的一个实施例之中，能力信息包括以下至少一种：
UE的处理能力信息；
UE的终端类型；
UE支持的带宽；
UE的post-FFT buffer的大小；
UE的HARQ的合并能力。
图15为本公开实施例所提供的一种通信装置的结构示意图，如图15所示，装置可以包括：
传输模块，用于基于网络侧设备配置的第一上行时隙资源或第二上行时隙资源进行上行传输，其中，第二上行时隙资源的晚于第一上行时隙资源。
综上所述，在本公开实施例提供的通信装置中，网络侧设备会获取UE的能力信息，UE的能力信息指示UE为第一类型UE，将第一时延作为UE的解码时延，根据第一时延确定UE的处理时延。由此可知，本公开提供的方法中，网络侧设备确定获取到的UE的能力信息指示UE为第一类型UE后，会确定适用于第一类型UE的第一时延，并根据第一时延确定UE的处理时延，然后基于确定的处理时延指示合理的时隙资源，从而避免出现“网络侧设备指示eRedCap UE的时隙资源不合理”的情况，进而使得UE可以正常进行上行传输。
请参见图16，图16是本申请实施例提供的一种通信装置1600的结构示意图。通信装置1600可以是网络设备，也可以是终端设备，也可以是支持网络设备实现上述方法的芯片、芯片系统、或处理器等，还可以是支持终端设备实现上述方法的芯片、芯片系统、或处理器等。该装置可用于实现上述方法实施例中描述的方法，具体可以参见上述方法实施例中的说明。
通信装置1600可以包括一个或多个处理器1601。处理器1601可以是通用处理器或者专用处理器等。例如可以是基带处理器或中央处理器。基带处理器可以用于对通信协议以及通信数据进行处理，中央处理器可以用于对通信装置(如，基站、基带芯片，终端设备、终端设备芯片，DU或CU等)进行控制，执行计算机程序，处理计算机程序的数据。
可选的，通信装置1600中还可以包括一个或多个存储器1602，其上可以存有计算机程序1604，处理器1601执行所述计算机程序1604，以使得通信装置1600执行上述方法实施例中描述的方法。可选的，所述存储器1602中还可以存储有数据。通信装置1600和存储器1602可以单独设置，也可以集成在一起。
可选的，通信装置1600还可以包括收发器1605、天线1606。收发器1605可以称为收发单元、收发机、或收发电路等，用于实现收发功能。收发器1605可以包括接收器和发送器，接收器可以称为接收机或接收电路等，用于实现接收功能；发送器可以称为发送机或发送电路等，用于实现发送功能。
可选的，通信装置1600中还可以包括一个或多个接口电路1607。接口电路1607用于接收代码指令并传输至处理器1601。处理器1601运行所述代码指令以使通信装置1600执行上述方法实施例中描述的方法。
通信装置1600为终端设备：收发器1605用于执行图3中的步骤301-步骤302；图4中的步骤401至步骤402；图5中的步骤501至步骤503；图6a中的步骤601a至步骤603a；图6b中的步骤601b至步骤602b。处理器1601用于执行图2中的步骤201；图3中的步骤303-步骤304；图4中的步骤403；图5中的步骤504和步骤505；图6a中的步骤604a；图6b中的步骤603b；图7中的步骤701-步骤702。
通信装置1600为网络设备：收发器1605用于执行图11a中的步骤1102a。处理器1601用于执行图8中的步骤801；图9中的步骤901至步骤904；图10中的步骤1001至步骤1005；图11a中的步骤1101a；图11b中的步骤1101b和步骤1102b。
在一种实现方式中，处理器1601中可以包括用于实现接收和发送功能的收发器。例如该收发器可以是收发电路，或者是接口，或者是接口电路。用于实现接收和发送功能的收发电路、接口或接口电路可以是分开的，也可以集成在一起。上述收发电路、接口或接口电路可以用于代码/数据的读写，或者，上述收发电路、接口或接口电路可以用于信号的传输或传递。
在一种实现方式中，处理器1601可以存有计算机程序1603，计算机程序1603在处理器1601上运行，可使得通信装置1600执行上述方法实施例中描述的方法。计算机程序1603可能固化在处理器1601中，该种情况下，处理器1601可能由硬件实现。
在一种实现方式中，通信装置1600可以包括电路，所述电路可以实现前述方法实施例中发送或接收或者通信的功能。本申请中描述的处理器和收发器可实现在集成电路(integrated circuit，IC)、模拟IC、射频集成电路RFIC、混合信号IC、专用集成电路(application specific integrated circuit，ASIC)、印刷电路板(printed circuitboard，PCB)、电子设备等上。该处理器和收发器也可以用各种IC工艺技术来制造，例如互补金属氧化物半导体(complementary metal oxide semiconductor，CMOS)、N型金属氧化物半导体(nMetal-oxide-semiconductor，NMOS)、P型金属氧化物半导体(positive channelmetal oxide semiconductor，PMOS)、双极结型晶体管(bipolar junction transistor，BJT)、双极CMOS(BiCMOS)、硅锗(SiGe)、砷化镓(GaAs)等。
以上实施例描述中的通信装置可以是网络设备或者终端设备，但本申请中描述的通信装置的范围并不限于此，而且通信装置的结构可以不受图16的限制。通信装置可以是独立的设备或者可以是较大设备的一部分。例如所述通信装置可以是：
(1)独立的集成电路IC，或芯片，或，芯片系统或子系统；
(2)具有一个或多个IC的集合，可选的，该IC集合也可以包括用于存储数据，计算机程序的存储部件；
(3)ASIC，例如调制解调器(Modem)；
(4)可嵌入在其他设备内的模块；
(5)接收机、终端设备、智能终端设备、蜂窝电话、无线设备、手持机、移动单元、车载设备、网络设备、云设备、人工智能设备等等；
(6)其他设备。
对于通信装置可以是芯片或芯片系统的情况，可参见图17所示的芯片的结构示意图。图17所示的芯片包括处理器1701和接口1702。其中，处理器1701的数量可以是一个或多个，接口1702的数量可以是多个。
可选的，芯片还包括存储器1703，存储器1703用于存储必要的计算机程序和数据。
本领域技术人员还可以了解到本申请实施例列出的各种说明性逻辑块(illustrative logical block)和步骤(step)可以通过电子硬件、电脑软件，或两者的结合进行实现。这样的功能是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用，可以使用各种方法实现所述的功能，但这种实现不应被理解为超出本申请实施例保护的范围。
本申请还提供一种可读存储介质，其上存储有指令，该指令被计算机执行时实现上述任一方法实施例的功能。
本申请还提供一种计算机程序产品，该计算机程序产品被计算机执行时实现上述任一方法实施例的功能。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机程序。在计算机上加载和执行所述计算机程序时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机程序可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机程序可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，高密度数字视频光盘(digital video disc，DVD))、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。
本领域普通技术人员可以理解：本申请中涉及的第一、第二等各种数字编号仅为描述方便进行的区分，并不用来限制本申请实施例的范围，也表示先后顺序。
本申请中的至少一个还可以描述为一个或多个，多个可以是两个、三个、四个或者更多个，本申请不做限制。在本申请实施例中，对于一种技术特征，通过“第一”、“第二”、“第三”、“A”、“B”、“C”和“D”等区分该种技术特征中的技术特征，该“第一”、“第二”、“第三”、“A”、“B”、“C”和“D”描述的技术特征间无先后顺序或者大小顺序。
本申请中各表所示的对应关系可以被配置，也可以是预定义的。各表中的信息的取值仅仅是举例，可以配置为其他值，本申请并不限定。在配置信息与各参数的对应关系时，并不一定要求必须配置各表中示意出的所有对应关系。例如，本申请中的表格中，某些行示出的对应关系也可以不配置。又例如，可以基于上述表格做适当的变形调整，例如，拆分，合并等等。上述各表中标题示出参数的名称也可以采用通信装置可理解的其他名称，其参数的取值或表示方式也可以通信装置可理解的其他取值或表示方式。上述各表在实现时，也可以采用其他的数据结构，例如可以采用数组、队列、容器、栈、线性表、指针、链表、树、图、结构体、类、堆、散列表或哈希表等。
本申请中的预定义可以理解为定义、预先定义、存储、预存储、预协商、预配置、固化、或预烧制。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (24)

1.一种处理时延的确定方法，其特征在于，所述方法由网络侧设备执行，包括：
获取用户设备UE的能力信息；
所述UE的能力信息指示所述UE为第一类型UE，将第一时延作为所述UE的解码时延；
根据所述第一时延确定所述UE的处理时延。
2.如权利要求1所述的方法，其特征在于，还包括：
所述UE的能力信息指示所述UE为第二类型UE，将第二时延作为所述UE的解码时延，其中，所述第二时延小于所述第一时延；
根据所述第二时延确定所述UE的处理时延。
3.如权利要求1所述的方法，其特征在于，所述第一时延通过以下任一公式获得：
NT,1_new＝NT,1+delta；
NT,1_new＝m*NT,1；
其中，NT,1_new为所述第一时延，NT,1为所述第二时延，所述delta或m为预设值。
4.如权利要求3所述的方法，其特征在于，所述delta或m由协议规定，或者由所述网络侧设备配置。
5.如权利要求1所述的方法，其特征在于，所述第一时延通过以下步骤确定：
确定当前网络允许的最多可进行混合自动重传请求HARQ合并的次数；
根据所述当前网络允许的最多可进行HARQ合并的次数和所述第二时延确定所述第一时延。
6.如权利要求1或2所述的方法，其特征在于，所述根据所述第一时延或所述第二时延确定所述UE的处理时延，包括以下至少一项：
将所述第一时延或第二时延与第一预设值之和作为所述UE接收到Msg2到发送新的Msg1之间的最小间隔；
获取所述UE的准备时延，并将所述第一时延或第二时延、所述准备时延和第二预设值之和作为所述UE接收到所述Msg2到发送Msg3之间的最小时间间隔；
将所述第一时延或第二时延与第二预设值之和作为所述UE收到Msg4到发送HARQ-ACK反馈的最小时间间隔；
将所述第一时延或第二时延域与所述第一预设值之和作为所述UE接收到物理下行共享信道PDSCH到发送HARQ反馈之间的最小间隔。
7.如权利要求1所述的方法，其特征在于，所述获取用户设备UE的能力信息，包括以下至少一种：
接收所述UE通过独立初始上行部分带宽separate initial UL BWP或者独立物理随机接入信道资源separate PRACH resource上报的所述能力信息；
接收所述UE通过MSG3上报的所述能力信息；
接收UE通过无线资源控制RRC信令上报的所述能力信息。
8.如权利要求1所述的方法，其特征在于，所述方法还包括：
向所述UE发送上报能力指示信息，所述上报能力指示信息用于指示所述UE是否需要上报能力信息。
9.如权利要求1-8任一所述的方法，其特征在于，所述能力信息包括以下至少一种：
所述UE的处理能力信息；
所述UE的终端类型；
所述UE支持的带宽；
所述UE的后缓冲器post-FFT buffer的大小；
所述UE的HARQ的合并能力。
10.如权利要求1所述的方法，其特征在于，所述方法还包括：
基于所述处理时延对所述第一类型UE和所述第二类型UE进行调度。
11.如权利要求1至10任一所述的方法，其特征在于，所述第一类型UE为增强型能力降低eRedcap UE，所述第二类型UE为传统legacy UE。
12.一种处理时延的确定方法，其特征在于，所述方法由网络侧设备执行，包括：
为UE分别配置第一上行时隙资源和第二上行时隙资源，其中，所述第二上行时隙资源的晚于所述第一上行时隙资源。
13.一种处理时延的确定方法，其特征在于，所述方法由UE执行，包括：
向网络侧设备上报所述UE的能力信息。
14.如权利要求13所述的方法，其特征在于，所述向网络侧设备上报所述UE的能力信息，包括以下至少一种：
通过separate initial UL BWP或者separate PRACH resource向所述网络侧设备上报所述UE的所述能力信息；
通过MSG3向所述网络侧设备上报所述UE的所述能力信息；
通过RRC信令向所述网络侧设备上报所述UE的所述能力信息。
15.如权利要求13所述的方法，其特征在于，所述方法还包括：
接收所述网络侧设备发送的上报能力指示信息，所述上报能力指示信息用于指示所述UE是否需要上报能力信息。
16.如权利要求13-15任一所述的方法，其特征在于，所述能力信息包括以下至少一种：
所述UE的处理能力信息；
所述UE的终端类型；
所述UE支持的带宽；
所述UE的post-FFT buffer的大小；
所述UE的HARQ的合并能力。
17.一种处理时延的确定方法，其特征在于，所述方法由UE执行，包括：
基于网络侧设备配置的第一上行时隙资源和第二上行时隙资源进行上行传输，其中，所述第二上行时隙资源的晚于所述第一上行时隙资源。
18.一种通信装置，被配置在网络侧设备中，包括：
获取模块，用于获取用户设备UE的能力信息；
处理模块，用于所述UE的能力信息指示所述UE为第一类型UE，将第一时延作为所述UE的解码时延；
确定模块，用于根据所述第一时延确定所述UE的处理时延。
19.一种通信装置，被配置在网络侧设备中，包括：
配置模块，用于为UE分别配置第一上行时隙资源和第二上行时隙资源，其中，所述第二上行时隙资源的晚于所述第一上行时隙资源。
20.一种通信装置，被配置在UE中，包括：
上报模块，用于向网络侧设备上报所述UE的能力信息。
21.一种通信装置，被配置在UE中，包括：
传输模块，用于基于网络侧设备配置的第一上行时隙资源或第二上行时隙资源进行上行传输，其中，所述第二上行时隙资源的晚于所述第一上行时隙资源。
22.一种通信装置，其特征在于，所述装置包括处理器和存储器，其中，所述存储器中存储有计算机程序，所述处理器执行所述存储器中存储的计算机程序，以使所述装置执行如权利要求1至12中任一项所述的方法，或所述处理器执行所述存储器中存储的计算机程序，以使所述装置执行如权利要求13至17中任一项所述的方法。
23.一种通信装置，其特征在于，包括：处理器和接口电路，其中：
所述接口电路，用于接收代码指令并传输至所述处理器；
所述处理器，用于运行所述代码指令以执行如权利要求1至12中任一项所述的方法，或用于运行所述代码指令以执行如权利要求13至17中任一项所述的方法。
24.一种计算机可读存储介质，用于存储有指令，当所述指令被执行时，使如权利要求1至12中任一项所述的方法被实现，或当所述指令被执行时，使如权利要求13至17中任一项所述的方法被实现。
CN202280004978.8A 2022-11-11 2022-11-11 一种处理时延的确定方法、装置、设备及存储介质 Pending CN115997461A (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/131562 WO2024098430A1 (zh) 2022-11-11 2022-11-11 一种处理时延的确定方法、装置、设备及存储介质

Publications (1)

Publication Number Publication Date
CN115997461A true CN115997461A (zh) 2023-04-21

Family

ID=85993916

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202280004978.8A Pending CN115997461A (zh) 2022-11-11 2022-11-11 一种处理时延的确定方法、装置、设备及存储介质

Country Status (2)

Country Link
CN (1) CN115997461A (zh)
WO (1) WO2024098430A1 (zh)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114071745A (zh) * 2020-08-07 2022-02-18 华为技术有限公司 一种无线接入的方法以及装置
CN114071750B (zh) * 2020-08-07 2024-09-06 华为技术有限公司 频域资源的确定方法、设备及存储介质
CN115004835A (zh) * 2022-04-26 2022-09-02 北京小米移动软件有限公司 一种终端设备调度方法及其装置
WO2023206107A1 (zh) * 2022-04-26 2023-11-02 北京小米移动软件有限公司 一种终端设备调度方法及其装置

Also Published As

Publication number Publication date
WO2024098430A1 (zh) 2024-05-16

Similar Documents

Publication Publication Date Title
WO2023206107A1 (zh) 一种终端设备调度方法及其装置
CN113273286B (zh) 一种时域资源分配的方法及装置
CN115004835A (zh) 一种终端设备调度方法及其装置
CN113287263B (zh) 一种跳频方法及装置
CN113597804B (zh) 一种跨载波的波束使用时间的确定方法及其装置
WO2024000203A1 (zh) 一种传输配置指示tci状态使用时间的确定方法及其装置
CN115191145B (zh) 一种多prach传输方法及其装置
CN114008964B (zh) Mbs业务中sps对应hpn的确定方法及其装置
CN115004596B (zh) 混合自动重传请求harq反馈的处理方法及其装置
WO2023231035A1 (zh) 一种非授权频段下传输资源的确定方法及装置
WO2022205005A1 (zh) 一种数据接收的处理方法及其装置
WO2024098430A1 (zh) 一种处理时延的确定方法、装置、设备及存储介质
CN115336222B (zh) 一种混合自动重传请求harq反馈的确定方法及其装置
WO2024000201A1 (zh) 一种指示方法及装置
WO2024016360A1 (zh) 一种随机接入方法/装置/设备及存储介质
WO2024011637A1 (zh) 一种轨道角动量oam模态切换方法、装置、设备及存储介质
CN114026907B (zh) 一种上行波束的测量方法及其装置
WO2022266926A1 (zh) 一种定时关系调整方法及其装置
US20240340879A1 (en) Semi-persistent scheduling method and apparatus for multicast broadcast service (mbs)
WO2023029058A1 (zh) 一种时间偏移量的确定方法及其装置
WO2023206572A1 (zh) 小区状态配置方法及其装置
WO2024000202A1 (zh) 一种信道状态信息csi反馈的确定方法及其装置
WO2023050211A1 (zh) 一种混合自动重传请求进程号的确定方法及其装置
CN116325582A (zh) 一种混合自动重传请求harq的配置方法及装置
CN114503751A (zh) 一种时域资源传输位置的确定方法和装置

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