CN112313894A - 数据传输涉及的用户设备和基站 - Google Patents

数据传输涉及的用户设备和基站 Download PDF

Info

Publication number
CN112313894A
CN112313894A CN201980041563.6A CN201980041563A CN112313894A CN 112313894 A CN112313894 A CN 112313894A CN 201980041563 A CN201980041563 A CN 201980041563A CN 112313894 A CN112313894 A CN 112313894A
Authority
CN
China
Prior art keywords
user equipment
data
transmission window
window size
data packet
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
CN201980041563.6A
Other languages
English (en)
Inventor
陶明宏
R.沙
铃木秀俊
A.巴姆里
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.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
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 Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Publication of CN112313894A publication Critical patent/CN112313894A/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/1867—Arrangements specially adapted for the transmitter end
    • H04L1/187—Details of sliding window 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/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/1607—Details of the supervisory signal
    • H04L1/1685—Details of the supervisory signal the supervisory signal being transmitted in response to a specific request, e.g. to a polling signal
    • 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
    • H04L1/188—Time-out mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • 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
    • H04L2001/0092—Error control systems characterised by the topology of the transmission link
    • H04L2001/0097—Relays

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

本公开涉及一种用户设备(UE)，包括发送器，该发送器基于具有发送窗口大小的发送窗口来发送至少一个数据分组。UE的接收器接收关于至少一个所发送的数据分组的接收反馈。UE的处理电路至少基于所接收的接收反馈来确定是否改变至少要用于发送进一步的数据分组的发送窗口大小。

Description

数据传输涉及的用户设备和基站
技术领域
本公开涉及诸如3GPP通信系统的通信系统中的方法、设备和制品。
背景技术
目前，第三代合作伙伴项目(3GPP)致力于下一代蜂窝技术(也称为第五代(5G))的技术规范。
一个目标是提供单一的技术框架来解决所有的使用场景、需求和部署场景(例如，参见TR 38.913版本15.0.0第6节，其通过引用并入本文)，至少包括增强型移动宽带(eMBB)、超可靠低等待时间通信(URLLC)、大规模机器类型通信(mMTC)。例如，eMBB部署场景可以包括室内热点、密集的城市、农村、市区宏小区和高速；URLLC部署场景可以包括工业控制系统、移动医疗(远程监测、诊断和治疗)、车辆实时控制、智能电网广域监控系统；mMTC部署场景可以包括具有大量具有非时间关键数据传输的设备(诸如智能穿戴设备和传感器网络)的场景。eMBB和URLLC服务的相似之处在于它们都需要非常宽的带宽，然而不同之处在于URLLC服务可能优选地需要超低的等待时间。
第二个目标是实现前向兼容性。不需要向长期演进(LTE，LTE-A)蜂窝系统的后向兼容性，这有助于全新的系统设计和/或引入新的特征。
物理层信号波形将基于OFDM，其可能支持非正交波形和多路接入。例如，进一步考虑了诸如DFT-S-OFDM和/或DFT-S-OFDM的变体和/或滤波/窗口化的在OFDM之上的附加功能。在LTE中，基于CP的OFDM和DFT-S-OFDM分别用作下行链路和上行链路传输的波形。NR中的设计目标之一是为下行链路、上行链路和侧行链路寻求尽可能多的公共波形。
发明内容
非限制性和示例性实施例有助于提供发送数据的改进过程。
在一个一般的第一示例中，这里公开的技术特征在于一种用户设备，包括根据以下所述的接收器、发送器和处理电路。发送器基于具有发送窗口大小的发送窗口来发送至少一个数据分组。接收器接收关于至少一个所发送的数据分组的接收反馈。处理电路至少基于所接收的接收反馈来确定是否改变至少要用于发送进一步的数据分组的发送窗口的发送窗口大小。
在一个一般的第一示例中，这里公开的技术特征在于一种由用户设备执行的包括以下步骤的方法。该步骤包括：
基于具有发送窗口大小的发送窗口来发送至少一个数据分组，
接收关于至少一个所发送的数据分组的接收反馈，
至少基于所接收的接收反馈来确定是否改变至少要用于发送进一步的数据分组的发送窗口的发送窗口大小。
在一个一般的第一示例中，这里公开的技术特征在于一种服务基站，包括根据以下所述的接收器和处理电路以及发送器。发送器基于具有发送窗口大小的发送窗口来发送至少一个数据分组。接收器接收关于至少一个所发送的数据分组的接收反馈。处理电路至少基于所接收的接收反馈来确定是否改变至少要用于发送进一步的数据分组的发送窗口的发送窗口大小。
应当注意，一般或特定实施例可以实现为系统、方法、集成电路、计算机程序、存储介质或其任何选择性组合。
公开的实施例和不同实施例的附加益处和优点将从说明书和附图中显而易见。这些益处和/或优点可以通过说明书和附图的各种实施例和特征单独获得，为了获得一个或多个这样的益处和/或优点，不需要全部提供这些实施例和/或优点。
附图说明
在以下示例性实施例中，参考附图和附图更详细地描述。
图1示出了3GPP NR系统的示例性架构；
图2示出了LTE eNB、gNB和UE的示例性用户和控制平面架构；
图3示出了AM RLC实体的简化和示例模型；
图4示出了在RLC层的AM数据传送；
图5示出了当使用12比特序列号时的示例性RLC状态报告；
图6是集成接入回程的示意图，包括IAB提供者(donor)、中间IAB节点和UE；
图7示出了IAB场景的架构选项1a；
图8和图9示出了架构组1的示例用户平面协议架构；
图10-图15以简化的方式示出了在流控制之前(左侧)和之后(右侧)上行链路和下行链路中的不同的拥塞场景；
图16示出UE和gNB的示例性和简化结构；
图17示出了示例性上行链路数据业务路由场景；
图18是根据实施例的示例性实施方式的发送侧(这里示例为UE)的行为的流程图；
图19示出了根据实施例的示例性实施方式的UE的结构；
图20示出了发送侧(这里示例为UE)和接收侧(这里示例为IAB提供者)之间的数据分组交换；
图21示出了示例性下行链路数据业务路由场景；以及
图22是根据实施例的另一示例性实施方式的发送侧(这里示例为UE)的行为的流程图。
具体实施方式
5G NR系统架构和协议栈
如背景部分所呈现的，3GPP正致力于第五代蜂窝技术(简称5G)的下一个版本，包括开发一种新的无线电接入技术(NR)，其在范围高达100GHz的频率下操作。3GPP必须识别和开发成功标准化NR系统所需的技术组件，以及时满足紧迫的市场需求和更长期的需求。为了实现这一目标，在研究项目“New Radio Access Technology”中考虑了无线电接口以及无线电网络架构的演进。技术报告TR 38.804 v14.0.0中收集了结果和协议，其通过引用整体并入本文。
除其他外，整个系统架构假设NG-RAN(下一代无线电接入网络)，其包括gNB，提供朝向UE的NG无线电接入用户平面(SDAP/PDCP/RLC/MAC/PHY)和控制平面(RRC)协议终端。gNB通过Xn接口相互连接。gNB还通过下一代(NG)接口连接到NGC(下一代核心)，更具体地，通过NG-C接口连接到AMF(接入和移动性管理功能)(例如，执行AMF的特定核心实体)和通过NG-U接口连接到UPF(用户平面功能)(例如，执行UPF的特定核心实体)。NG-RAN架构如图1所示(例如，参见3GPP TS 38.300v15.2.0第4节，其通过引用并入本文)。
可以支持各种不同的部署场景(例如，参见3GPP TR 38.801 v14.0.0，其通过引用并入本文)。例如，其中呈现了非集中式部署场景(例如，参见TR 38.801第5.2节；第5.4节中说明了集中式部署)，其中可以部署支持5G NR的基站。图2示出了示例性非集中式部署场景(例如，参见所述TR 38.801的图5.2.-1)，同时还示出了LTE eNB以及连接到gNB和LTE eNB两者的用户设备(UE)。NR 5G的新eNB可以被示例性地称为gNB。eLTE eNB是eNB的演进，其支持与EPC(演进分组核心)和NGC(下一代核心)的连接。
NR的用户平面协议栈(例如，参见3GPP TS 38.300 v15.2.0第4.4.1节，其通过引用并入本文)包括PDCP(分组数据聚合协议)、RLC(无线电链路控制)和MAC(介质接入控制)子层，它们在网络侧上的gNB中终止。此外，在PDCP之上引入新的接入层(AS)子层(服务数据适配协议SDAP)(例如，参见3GPP TS 38.300版本15.2.0的第6.5子条款，其通过引用并入本文)。关于NR的控制平面协议栈的更多信息，请参见例如TS 38.300第4.4.2节。在TS 38.300的第6子条款给出层2功能概述。在TS 38.300的第6.4、6.3和6.2节中分别列出了PDCP、RLC和MAC子层的功能。在TS 38.300的第7子条款中列出了RRC层的功能。TS 38.300的上述章节通过引用并入本文。
示例性地为5G系统假设的新NR层可以基于LTE(-A)通信系统中当前使用的用户平面层结构。
NR的用例/部署场景可以包括增强的移动宽带(eMBB)、超可靠的低等待时间通信(URLLC)、大规模机器类型通信(mMTC)，它们在数据速率、等待时间和覆盖范围方面有不同的要求。例如，eMBB预期支持在三倍于IMT-高级所提供的峰值数据速率和用户体验的数据速率的量级的峰值数据速率(对于上行链路，为20Gbps和对于下行链路，为10Gbps)和用户体验的数据速率。另一方面，对于URLLC，对超低等待时间(对于用户平面等待时间，UL和DL各自为0.5ms)和高可靠性(1ms内为1-10-5)提出了更严格的要求。最后，mMTC可以优选地要求高连接密度(在城市环境中为1000000个设备/km2)、在恶劣环境中覆盖范围大、并且对于低成本设备需要极长寿命的电池(15年)。
因此，适用于一种用例的OFDM参数集(例如，子载波间隔、OFDM符号持续时间、循环前缀(CP)持续时间、每一调度间隔的符号数量)可能不用于另一种用例。例如，与mMTC服务相比，低等待时间服务可以优选地要求更短的符号持续时间(并且因此需要更大的子载波间隔)和/或每一调度间隔(又称为TTI)更少的符号。此外，具有较大信道延迟扩展的部署场景比与具有较小延迟扩展的场景优选地要求更长的CP持续时间。应该相应地优化子载波间隔，以保持类似的CP开销。NR可以支持多于一个的子载波间隔。相应地，目前正在考虑15kHz、30kHz、60kHz……的子载波间隔。符号持续时间Tu和子载波间隔Δf通过公式Δf＝1/Tu直接相关。以与LTE系统中类似的方式，术语“资源元素”可以用于表示对于一个OFDM/SC-FDMA符号的长度由一个子载波组成的最小资源单元。
在新无线电系统5G-NR中，对于每个参数集和载波，分别为上行链路和下行链路定义子载波和OFDM符号的资源网格。资源网格中的每个元素被称为一个资源元素，并基于频域中的频率索引和时域中的符号位置进行标识。如从通过引用并入到本文的3GPP TS38.211 v15.2.0中已经明显地获得了一些定义。
RLC层中的ARQ(自动重复请求)
RLC层具有被赋予不同功能的AM RLC实体(确认模式RLC实体)(例如，参见无线电链路控制RLC协议规范3GPP TS 38.322版本15.2.0，其通过引用并入本文)。
对于在gNB处配置的RLC实体，在UE处配置了对等RLC实体，反之亦然。具体地，AMRLC实体包括发送侧和接收侧。AM RLC实体的发送侧从上层接收RLC SDU，并经由较低层将RLC PDU发送给其对等AM RLC实体。AM RLC实体的接收侧将RLC SDU传递到上层，并经由较低层从其对等AM RLC实体接收RLC PDU。
图3示出了AM RLC实体的简化和示例性模型(例如，参见TS 38.322版本15.2.0第4.2.1.3节)。如图所示，RLC PDU通过逻辑信道DL/UL DCCH(专用控制信道)或DL/UL DTCH(专用业务量信道)来发送和接收。
RLC层的AM数据传送涉及发送窗口的使用(例如，参见TS 38.322版本15.2.0第5.2.3节“AM data transfer”，包括发送和接收操作，其通过引用并入本文)。具体地，AMRLC实体的发送侧维护发送窗口，以取决于序列号(SN)是否落在发送窗口之内或之外来控制(和限制)RLC PDU的传输。例如，不发送落在发送窗口之外的RLC PDU(具有SN)，而可以发送位于发送窗口之内的RLC PDU(具有SN)。发送窗口大小由参数(例如，名为AM_Window_Size)给出，其可以是固定的，并且可以被设置为2048(例如，当使用12比特序列号时)或131072(例如，当使用18比特SN时)(例如，参见3GPP TS 38.322版本15.2.0第7.2.0节“Constants”，其通过引用并入本文)。
在图4中以简化和示例性的方式示出RLC层的AM数据传送。为了便于说明，假设发送窗口大小是10个PDU。因此，发送窗口将可以被发送的PDU(也可以在此上下文中示例性地称为数据分组(而无需接收对先前发送的数据分组的肯定确认)的量限制为10个PDU。发送窗口可以是滑动窗口，当在发送窗口的下边缘接收到PDU的肯定确认时其被向前移动。因此，下边缘对应于具有SN的PDU，其在最后按顺序完全接收的RLC PDU之后。在所选择的示例中，具有SN 11-20的PDU被放置在发送窗口中并且可以被发送到接收侧。进一步假设在接收侧仅成功地接收到具有SN 11、13和20的PDU(具有SN 12、14-19的其余PDU无法被成功地解码，例如，因为它们在无线电链路上丢失)。
如稍后将更详细说明的，AM RLC层包括称为ARQ的纠错机制，其允许向发送侧提供接收反馈(例如，ACK和/或NACK)，并允许发送侧对那些被否定确认的PDU执行重传。
在图4中，因为针对SN＝11接收到ACK，因此发送窗口被滑动一个PDU，SN＝11是此时发送窗口的下边缘。因此，具有SN＝21的PDU现在落在发送窗口内(SN＝12-SN＝21)，并且可以被发送到接收侧，例如，与具有SN-12、14-19的PDU的重传一起。
由RLC层使用ARQ(自动重复请求)实施纠错功能。具体地，RLC实体的发送侧支持数据的重传，并且RLC实体的接收侧继而支持检测较低层的数据丢失以及向其对等RLC实体的重传请求(例如，参见TS 38.322版本15.2.0第5.3节“ARQ procedures”，其通过引用并入本文)。ARQ功能基于由接收侧发送到RLC层的发送侧的状态消息(也称为状态报告)。状态消息可以包括RLC PDU的肯定和/或否定确认(接收失败和接收成功的通知)。状态消息可以提供RLC PDU的不成功和/或成功接收的反馈，允许发送侧至少标识哪些RLC PDU被成功地发送到接收RLC侧以及哪些没有。
状态报告的一个示例包括否定确认的RLC PDU的序列号(NACK_SN)以及对于肯定确认的一个序列号(ACK_SN)，其中，ACK_SN被设置为在得到的状态报告(累积确认)中未指示为丢失的下一个未接收的RLC SDU的序列号。RLC实体的发送侧解释状态报告，使得已经由其对等RLC实体接收所有但不包括SN＝ACK_SN的RLC SDU的所有RLC SDU，在状态报告中用NACK_SN指示的那些RLC SDU除外。基于使用具有12比特的序列号用于通信的假设，在图5中示出了这样的状态报告的示例(例如，参见TS 38.322版本15.2.0第5.3.4、6.2.3.10-6.2.3.17节，其通过引用并入本文)
发送RLC实体可以轮询其对等RLC实体，以便触发RLC状态消息的传输，用以获得所发送的RLC PDU的接收反馈(接收状态，诸如成功与否)。RLC状态轮询可以由不同的条件触发，诸如以下一个或多个条件：
·上次(the last)轮询后已经发送一定数量的PDU，
·上次轮询后已经发送一定数量的字节，
·发送缓冲区中的最后的PDU被发送，
·轮询重传计时器到期，其指示上次轮询后的时间，
·当ARQ窗口暂停时。
通过相应地设置AMD PDU中的对应字段(例如，1比特P字段设置为值“1”；P字段设置为值“0”表示不请求状态报告)并将AMD PDU发送到接收侧来轮询(请求)RLC状态消息。
相应地，RLC实体的接收侧在接收到这样的轮询请求时向其对等RLC实体(发送侧)发送状态报告，该状态报告包含序列号小于或等于设置轮询比特的所接收的AMD PDU的PDU的接收状态。
IAB-5G中的集成接入和回程
基于毫米波的蜂窝接入提供了更高的空间复用并实现了更高的带宽，是新的5GNR的一个组成部分。然而，基于毫米波的蜂窝接入主要适用于小小区网络，因为经由毫米波频带发送的信号遭受高路径损耗。为许多小小区提供有线回程可能会增加部署的成本和复杂性。另一方面，无线回程有助于网络运营商在不产生任何额外光纤部署成本的情况下灵活地部署小小区基站，并进一步促进在网络推出(rollout)的早期阶段进行增量部署。具体地，光纤可以被部署到基站(锚节点)的子集，并且剩余基站的接入业务量可以被无线回程到锚节点。
集成接入和回程(IAB)是一种实施无线回程的技术，其中接入和回程通信使用相同的标准无线电技术(例如，5G NR)，从而允许来自不同制造商的不同基站之间的互操作性，这是灵活部署密集小区网络的重要标准。IAB可以通过带内和带外中继两者部署，并且可以在室内和室外网络两者中使用。
IAB可以支持独立(SA)和非独立(NSA)部署，其中IAB节点可以在SA或NSA模式下操作。多跳回程比单跳提供了更多的范围扩展，并且由于其有限的范围，对于6-GHz以上的频率尤其有益。部署中的最大跳数预计取决于许多因素，诸如频率、小区密度、传播环境和业务量负载。
图6示出了用于集成接入回程的示例性参考图，包含一个IAB提供者和多个IAB节点以及可以连接到不同节点从而建立具有两个或更多跳的数据业务路由的UE。例如，IAB提供者可以被视为单个逻辑节点，其包括与基站(服务基站gNB)类似的功能集。
不同的层2(L2)和层3(L3)中继架构是可能的，例如，在接口上所需的修改和/或所需的附加功能(例如，以完成多跳转发)方面是不同的。架构可以分为两个架构组，架构组1，其利用IAB提供者中的中央单元(CU)/分布式单元(DU)拆分(split)，以及架构组2，其中跨中间节点的逐跳转发使用高层用户平面协议(例如，GTP-U、UDP或IP嵌套隧道)。
应当注意，中间节点的存在对UE是透明的，即UE不知道UE和IAB提供者(服务基站)之间存在中间节点。
第一架构组的架构1a使用适配层或与适配层组合的GTP-U用于回程F1-U。图7示例性示出了架构选项1a(例如，参见TR 38.874版本0.4.0第6.3.1.1节，其通过引用并入本文)。对于架构组1，可以考虑几个用户平面方面，诸如适配层的布置、适配层所支持的功能、多跳RLC的支持、对调度器和QoS的影响等。为了选择一个单用户平面协议架构，可能会在这些不同方面之间进行权衡。图8和图9示出了架构组1的示例用户平面协议架构(例如，参见TR 38.874版本0.4.0第8.2.1节，其通过引用并入本文)。由此可见，示例性地假设层2中继使用自适应层(而不是使用与自适应层组合的GTP-U)来执行，所适配层示例性地放置在RLC层之上或MAC层之上。此外，示例性地假设RLC层不在RLC ARQ功能和(多个)其他功能(诸如RLC分段)之间拆分。然而，这种用户平面协议架构只是在这个应用程序中可以同等考虑的许多不同选项中的一个。
适配层(图中的示例性“适配”)可以支持不同的功能(例如，参见TR38.874版本0.4.0第8.2.2节“Adaptation Layer”，其通过引用并入本文)。在上述架构选项1a中，这些功能可以包括以下一个或多个：
·用于PDU的UE承载的标识
·跨无线回程拓扑的路由
·由调度器在无线回程链路上的DL和UL上的QoS强制执行(enforcement)
·UE用户平面PDU到回程RLC信道的映射
IAB致力于重用5G NR中已经定义的现有功能和接口用于接入，除了诸如多跳转发的附加功能外，还应确识别和定义对这些功能和接口的修改或增强。
如发明人所认定的，改进的RLC ARQ设计可以针对集成接入和回程场景而定义。通常，ARQ可以分为端到端(E2E)和逐跳(HBH)解决方案，但也可以分为其他更复杂的解决方案。使用E2E还是HBH ARQ还取决于所实施的协议架构。使用上述RLC适配层的协议架构(参见图8)只能支持逐跳ARQ，而使用上述MAC适配层的协议架构(参见图9)可以支持逐跳ARQ和端到端ARQ两者。对于两个适配层放置(MAC之上、RLC之上)，可以在发送侧(TX侧)对RLC ARQ进行预处理。可以对适配层放置进行其他观察(例如，参见TR 38.874版本0.4.0第8.2.2节，其通过引用并入本文)。
端到端ARQ在这里应理解为在数据业务路由的两个端节点(诸如UE和IAB提供者节点)之间执行RLC ARQ。仅存在一个ARQ处理用于遍历中间节点的整个数据业务路由。应当注意，MAC层的HARQ(混合ARQ)仍然可以在每个跳处使用。由于RLC ARQ是在数据业务路由的两个端节点(例如，UE和IAB提供者)之间执行的，所以中间节点简单地将RLC PDU以及ACK/NACK(在其他方向上)中继到目的地。在任何一个中继跳上丢失分组的情况下，(由接收侧向发送侧发送NACK的)丢失的分组必须在所有中继跳上重新传输，这可以被认为是低效的，因为PDU在之前已经成功地发送PDU的跳上不必要地重传。
此外，为了使PDU的重传工作于端到端ARQ，接收反馈(例如，ACK/NACK)还需要成功地遍历从接收器返回到发送器的路上的所有中继跳。可以使用状态报告消息来发送ACK/NACK(参见上面关于RLC ARQ STATUS PDU的讨论)，以肯定和否定地确认RLC PDU。作为结果，如果在任何一个中继跳上丢失任何这样的状态报告消息，则它可能不必要地触发在所有中继跳上已经成功地发送的PDU的重传。
另一方面，在逐跳ARQ中，分别在直接相邻的两个节点(即单跳的实体)之间执行ARQ功能(例如，参见图8)。因此，被NACK的PDU只能在确定了否定确认的跳上被重传，这比E2E ARQ选项更有效(尤其对于在无线无线电接入和无线回程链路之间共享相同带宽的带内系统)。然而，HBH-ARQ实际上导致整个RLC层(更准确地说，至少是它的RLC ARQ部分)部署在所有IAB节点上，不仅包括IAB提供者，还包括中间节点。因此，由于附加ARQ状态机，中间节点可能变得更复杂和更昂贵；这可以被以下益处抵消，即：当光纤最终可用时，促进IAB中间节点升级到IAB提供者。
E2E ARQ和HBH ARQ针对他们对3GPP规范的影响也不同，诸如，可能需要在RLC层扩展序列号空间以便容纳E2E ARQ中多跳中继的较长往返时间(RTT)或RLC协议中的附加功能，以减轻使用E2E ARQ时跨多跳丢失RLC状态报告的影响。
多跳数据业务路由中的流控制
在上述讨论的多跳IAB回程场景中(但也在与IAB不直接相关的其它用例中，诸如LTE-A中继部署)，数据拥塞可能发生在一个或多个中间节点上。数据拥塞可以广义地理解为指节点的传入数据速率高于传出数据速率的场景。作为结果，该节点内的缓冲区将增加，并最终导致缓冲区溢出和分组丢弃。流控制机制可以解决或缓解数据拥塞问题。如下面将说明的，一种解决方案可以是向上游节点授权较少的资源(例如，中间节点向UE授权较少的上行链路无线电资源)，以减少传入的数据业务量。
例如，在上行链路上，中间IAB节点充当到其他上游IAB节点的gNB，并且可以通过调整UL授权来控制来自上游IAB节点(或UE)的上行链路数据量，即，当前的传输/调度机制控制朝向IAB节点的上行链路数据速率。这是一种缓解上行链路拥塞的机制。
在下行链路上，到下游IAB节点或UE的链路的容量可以小于到上游IAB节点的回程链路的容量。上游IAB节点的DU(分发单元)侧可能不知道其下游IAB节点的下行链路缓冲状态，这可能导致在该中间下游IAB节点处的下行链路数据拥塞和分组丢弃。对于逐跳ARQ，丢弃的PDU不会被重传，并且下游UE上的PDCP实体在按顺序将PDU传递给上层之前将等待t重排序计时器。这种延迟可能会对上层产生不利影响，例如，可能导致TCP慢启动。对于端到端ARQ，丢弃的PDU将在上游在之前已经成功地发送的链路上被重传。这不必要地消耗回程链路的容量。
可以定义用于避免和处理上行链路和下行链路数据拥塞的附加流控制机制。
图10-图15以简化和示例性的方式示出在流控制之前(左侧)和之后(右侧)上行链路和下行链路中的不同的示例性拥塞场景。
从图10和图11中的上行链路示例中可见，假设拥塞和分组丢弃发生在中间节点2中，示例性地由两个中间节点1和2之间的弱链路引起(由虚线箭头示出)。具体地，连接到中间节点1的中间节点2的侧(例如，如图8和图9所示，移动终端MT，I-节点2的侧)处上行链路传输缓冲区可能经历导致分组丢弃的缓冲区溢出。流控制可以导致上游节点UE1降低数据传输速率以匹配在弱链路处可用的传输容量，从而在中间节点2处解决拥塞问题(用虚线箭头示出)。
图12和图13中的上行链路示例示例性地假设由于与IAB提供者的弱无线电链路，而导致中间节点1处的上行链路数据业务的分组拥塞。使用虚线箭头示出由于流控制而产生的中间节点2和UE1处上行链路数据传输的自适应。
从图14和图15中的下行链路示例中可见，假设拥塞和分组丢弃发生在中间节点2中，这示例性地由到UE1的最后一跳上的弱链路引起。具体地，连接到UE的中间节点2的侧(例如，图8和图9所示的DU侧)可能经历下行链路传输缓冲区溢出。在该示例性场景中，将授权适配为解决拥塞问题的流控制机制是不可能的，因为I-节点1不知道I-节点2的缓冲状态，并且I-节点2对该情况没有控制。在任何情况下，如上文针对其他两个场景所讨论的，流控制可能理想地具有以下结果：为了解决拥塞问题，一些或全部上游节点(中间节点1和源节点，例如，IAB提供者)减少数据传输(用虚线箭头示出)。因此，到达中间节点2的数据更少，并且假设中间节点2现在能够通过最后的链路向UE1发送足够的数据，拥塞问题得到解决，并且不需要因此而丢弃任何数据。
尽管上述流控制实现了解决拥塞问题，但是发明人已经认识到在所述连接中的几个问题。例如，流控制可能很晚进行，即当拥塞和/或分组丢失已经发生时。在拥塞和分组丢弃发生之前没有流控制。并且，流控制是每跳(per-hop)流控制，使得拥塞问题可能从拥塞节点缓慢地传播到源节点。例如，如果一个中间节点(例如，图13中的I-节点1)首先向下一个中间节点(例如，图13中的I-节点2)授权较少的上行链路机会，则可以在该节点(即I-节点1)中缓解拥塞。但是，这可能导致I-节点2拥塞。以此类推，使得拥塞从拥塞节点缓慢地传播到源节点。作为结果，减少来自源节点的数据需要时间。此外，需要下行链路中的流控制机制。
本公开人已经认识到需要定义有效的流控制过程，以便于在下行链路和上行链路中避免或减轻上述拥塞问题。
在下文中，将针对为5G移动通信系统设想的新无线电接入技术描述UE、基站和满足这些需求的过程。还将说明不同的实施方式和变体。以下披露是由上述讨论和发现促成的，并且可以例如至少基于其中的一部分。
然而，通常，应当注意，本文中已经作出了许多假设，以便能够以清晰易懂的方式解释本公开的基本原理。然而，这些假设应被理解为本文中仅用于说明目的的示例，不应限制本公开的范围。技术人员将意识到，以下公开的原理和如权利要求中所述的原理可以应用于不同的场景，并且以本文未明确描述的方式来应用。
此外，下面使用的过程、实体、层等的一些术语与LTE/LTE-A系统或当前3GPP 5G标准化中使用的术语密切相关，尽管接下来的3GPP 5G通信系统的新无线电接入技术中使用的具体术语尚未完全确定。因此，可以在将来改变术语，而不影响实施例的功能。因此，技术人员意识到，实施例及其保护范围不应由于缺乏更新的或最终商定的术语而限于本文示例性使用的特定术语，而是应根据本公开的功能和原理所依据的功能和概念来更广泛地理解。
例如，移动站或移动节点、用户终端或用户设备(UE)是通信网络中的物理实体(物理节点)。一个节点可以有多个功能实体。功能实体是指实施和/或向相同或另一节点或网络的其他功能实体提供预定功能集的软件或硬件模块。节点可以具有一个或多个接口，这些接口将节点附接到节点可以进行通信的通信设施或介质上。类似地，网络实体可以具有将功能实体附接到通信设施或介质的逻辑接口，在该通信设施或介质上它可以与其他功能实体或对应节点进行通信。
这里的术语“基站”或“无线电基站”是指通信网络内的物理实体。与移动站一样，基站可以具有多个功能实体。功能实体是指实施和/或向相同或另一节点或网络的其他功能实体提供预定功能集的软件或硬件模块。物理实体执行关于通信设备的一些控制任务，包括调度和配置中的一个或多个。注意，基站功能性和通信设备功能性也可以集成在单个设备内。例如，移动终端也可以为其他终端实施基站的功能。LTE中使用的术语是eNB(或eNodeB)，而目前5G NR的术语是gNB。
在权利要求和说明书中使用的表述“接收反馈”应广义地解释为意指从接收侧对先前由发送侧发送到接收侧的数据分组的成功或不成功接收的任何适当反馈。示例性实施方式可以基于现有机制，诸如上文针对5G NR描述的RLC状态报告，但可以是其变体或完全不同。在描述各种实施例时，提供关于如何示例性地实施接收反馈的进一步信息。
权利要求书和说明书中使用的术语“发送窗口”应广义地解释为用于发送数据分组(例如，RLC PDU)的机制。在一个示例中，发送窗口限制可以发送的数据分组的数量，因为发送窗口大小决定可以发送多少数据分组。此外，发送窗口可以示例性地实施为滑动窗口，使得当数据分组被成功地发送时，发送窗口被滑动(即移动)。一个示例性实施方式可以基于现有机制，诸如上文针对5G NR描述的RLC AM窗口。然而，也可以使用其他实施方式。在描述各种实施例时，提供了关于如何示例性地实施发送窗口的进一步信息。
图16示出了用户设备(也称为通信设备)和调度设备(这里示例性地假设位于基站中，例如，eLTE eNB(或者称为ng-eNB)或5G NR中的gNB)的一般、简化和示例性框图。UE和eNB/gNB分别使用收发器通过(无线)物理信道彼此通信。
通信设备可以包括收发器和处理电路。收发器进而可以包括和/或用作接收器和发送器。处理电路可以是一个或多个硬件，诸如一个或多个处理器或任何LSI。在收发器和处理电路之间有输入/输出点(或节点)，处理电路可以在输入/输出点上控制收发器，即控制接收器和/或发送器并交换接收/发送数据。作为发送器和接收器的收发器可以包括RF(射频)前端，包括一个或多个天线、放大器、RF调制器/解调器等。处理电路可以实施控制任务，诸如控制收发器来发送由处理电路提供的用户数据和控制数据和/或接收由处理电路进一步处理的用户数据和控制数据。处理电路还可以负责执行诸如确定、决定、计算、测量等其他处理。发送器可以负责执行发送处理和与之相关的其他处理。接收器可以负责执行接收处理和与之相关的其他处理，诸如监视信道。
在本情况中，正如从下面对不同实施例及其变体的公开将变得明显的那样，处理器因此可以被示例性地配置为至少部分地执行确定发送窗口大小的步骤，例如，在适当时增大和减小它。处理电路还可以至少部分地执行操作计时器的步骤，例如，开启、监视、停止计时器并确定其到期。可以至少部分地由处理电路执行的另一任务是评估诸如ACK、NACK的反馈信号，以确定是否在接收侧成功地接收到数据分组。
发送器可以被配置为能够至少部分地执行发送数据分组的步骤。
接收器可以继而被配置为能够至少部分地执行从接收侧接收关于先前发送的数据分组的接收反馈的步骤。
以下所提供的解决方案主要适用于新的5G NR标准化(独立和非独立)，尤其是IAB扩展，但也可能适用于诸如LTE中的中继的其他系统。此外，下面的解决方案主要呈现在IAB场景的背景下，其中多跳数据业务路由涉及UE作为一个端节点(其间有一个或多个IAB中间节点)以及IAB提供者作为另一端节点。不过，这主要是为了便于说明和解释解决方案。因此，如下所述的解决方案不需要仅用于IAB场景，还可以用于具有多跳数据业务路由的其他场景，诸如LTE中继。
此外，尽管不是主要的使用场景，但是以下解决方案也可以应用于单跳场景，例如，UE直接连接到基站(例如，gNB)的情况。图17示出了下面示例性假设的简化IAB场景，包括两个数据业务路由，一个是UE1–中间节点2(I-节点2)–中间节点1(I-节点1)–结束节点(例如，IAB提供者)，另一个是UE2–中间节点3(I-节点3)–中间节点1(I-节点1)–结束节点(例如，IAB提供者)。进一步示例性地假设上行链路传输场景，根据该场景，由UE向端节点发送数据，从而遍历相应的无线电接入和回程链路。
然而，所讨论的解决方案也可以应用于下行链路数据业务路由，其具有相应的侧的变化，例如，UE是数据接收侧而不是数据发送侧。相应地，在端到端ARQ解决方案中，UE是接收RLC ARQ实体，并且IAB提供者是发送RLC ARQ实体。
此外，该解决方案可以应用于端到端ARQ架构以及逐跳ARQ架构，如下所说明的。
将参考图18说明一个示例性解决方案，图18示出了在UE侧执行的处理序列(例如，图17中的UE1和/或UE2)。然而，应当注意，UE在这里被视为数据业务路由的发送侧。因此，相同的行为可以用于不是UE的发送侧，例如，服务基站、IAB提供者。在这种情况下，UE将是接收侧。
例如，取决于实施的ARQ架构选项(是E2E还是HBH ARQ)，接收反馈可以由数据业务路由的中间节点(HBH情况)或端节点(E2E情况)来发送。首先，将主要针对E2E ARQ选项来说明该解决方案，即使该解决方案适用于E2E和HBH ARQ选项两者。
简而言之，以下解决方案引入了动态发送窗口大小机制，其允许基于针对先前发送的数据分组确定的接收反馈，使发送窗口大小适应数据业务路由上的数据业务状况。
从图18可见，示例性和简化的UE过程从用户设备经由IAB无线回程向端节点发送数据分组开始。由UE基于发送窗口执行传输。随后，UE接收关于那些先前发送的数据分组的接收反馈，例如，以肯定和/或否定确认的形式。
假设在该示例场景中的E2E ARQ解决方案，数据业务路由的目的地节点(即IAB提供者)将接收反馈发送到数据业务路由的源节点(即UE)。数据分组由中间IAB节点(I-节点1-3)转发到IAB提供者，IAB提供者是确定和发送这些数据分组的接收反馈的实体。
UE在接收到接收反馈之后，可以使用该接收反馈来确定是否需要改变(用于发送数据分组的)发送窗口大小，例如，它是否仍然适合于数据业务路由。
UE可以决定改变发送窗口大小，并基于具有所调整的大小的发送窗口来继续发送数据分组。另一方面，UE可以决定保持发送窗口大小不变，并基于具有不变大小的发送窗口来继续发送数据分组。
在该解决方案中，当由发送侧分析时，接收反馈可以用作关于下游中可能的或即将发生的拥塞的指示符，或者更广泛地，关于在下游可用的数据吞吐量的指示符。例如，UE可以根据反馈的等待时间(例如，肯定的或否定的ACK)来确定排队延迟和吞吐量限制。换言之，UE分析(例如，从接收侧接收的)先前发送的数据分组的接收状态，以便标识有利于调整发送窗口大小的情况(例如，拥塞情况、低数据吞吐量情况等)。
例如，在下游节点(诸如中间节点I-节点1)中的拥塞或即将发生的拥塞可以例如通过例如由中间节点和下一下游节点之间的弱链路(例如，在图17中，I-节点1和端节点、IAB提供者之间的无线回程链路)引起的许多否定确认的数据分组来表征。数据分组可以在中间节点I-节点1处丢弃，从而使得对于那些数据分组的否定确认从接收侧(例如，IAB提供者)发送到发送侧(即UE)。为了便于避免或解决拥塞，UE在此基础上可以决定调整发送窗口大小作为流控制机制的一部分。
另一方面，许多肯定确认的数据分组暗示了强数据通信路由(强意指例如良好的无线电链路)，可能允许更多的数据分组被发送。
UE行为能够在多跳数据业务路由的无线回程和接入链路上灵活地适应数据传输的变化。例如，UE可以减小发送窗口大小，从而降低数据分组的传输速率。这允许数据业务能够适应无线电链路(假设为弱)上的(拥塞的)中间节点所经历的传输能力的降低。因此，中间节点可以一开始不拥塞，或者如果已经拥塞，则可以促进中间节点减少或解决拥塞。
另一方面，为了增加数据吞吐量，UE可以增大发送窗口大小。例如，在UE已经以减小的发送窗口大小(例如，在之前已经减小了发送窗口并因此减小了数据吞吐量之后)进行操作的情况下，以便在解决拥塞之后恢复先前的数据吞吐量(例如，由于较少的干扰，没有更多的弱链路)，则这可能是有利的。例如，在流控制之后，UE没有接收到许多否定确认，而是接收到许多肯定确认，从而可以得出不再需要减小发送窗口大小(例如，解决了拥塞)的结论。然而，增大发送窗口大小以增加数据吞吐量也可能是有利的，而无需事先减小发送窗口大小，例如，在可以通过数据业务路由进一步增加数据吞吐量的情况下(例如，在流畅的数据业务路由的情况下)。
总的来说，可以通过减小发送窗口大小(例如，弱无线电链路、拥塞)(可选地不小于最小值)来降低数据吞吐量，并且可以通过增大发送窗口大小(例如，良好的无线电链路、无拥塞)来增加数据吞吐量(可选地不超过最大值)。
减小和增大发送窗口大小可以按照不同的步骤和步长逐步进行，例如，每次增加/减少5个PDU。如上所述，发送窗口大小的这种逐步调整可以被最大(例如，5000，但是任何其他合适的数量也同样可能)和最小(例如，1个PDU，但是任何其他合适的数量也同样可能)发送窗口大小而限制。
可以关于如何至少基于接收反馈来标识增大或减小发送窗口大小的需要而定义不同准则和条件，例如，拥塞和/或被限制的数据分组吞吐量。在另外的示例性变体中，除了接收反馈之外，还可以将其他信息用于所述确定，以便于将其他场景与数据拥塞区分开。例如，对于先前发送的数据分组的接收反馈不仅可以从接收侧接收，而且还可以由UE例如基于计时器自主地确定，稍后将更详细地说明。作为另一示例，UE还可以从下游节点获得关于例如信道质量报告、拥塞报告的其他信息(例如，经由适配层)，UE可以使用这些信息来执行确定。
在一个变体中，一个条件基于针对由UE先前发送的数据分组而确定的连续肯定或否定确认的数量(例如，连续的，在某种意义上，确认是指连续的数据分组，即具有连续序列号)。要检查的条件是连续否定确认的数量是否高于预定阈值，如果高于预定阈值，则UE可以减小发送窗口的大小。相反，如果不高于预定阈值，则UE可以不减小发送窗口大小，而是保持发送窗口大小不变，并且可以使用发送窗口继续数据分组的传输。
相应地，UE可以进一步针对肯定确认执行类似的检查，使得UE确定连续肯定确认的数量是否高于预定阈值(与用于与连续否定确认进行比较的阈值相同或不同)，并且如果高于预定阈值，则UE可以增大发送窗口大小。相反，如果不高于预定阈值，则UE可以不增大发送窗口大小，而是保持发送窗口大小不变，并且可以使用发送窗口继续发送数据分组。
要由UE检查的另外的替代或附加条件可以指在预定时间段内确定的肯定和/或否定确认的数量。具体地，UE监视在一段时间内所接收的肯定和否定确认(在这种情况下，这些确认可以指或不指连续的数据分组)。与刚才针对先前的条件所说明的情况类似，如此监视的肯定确认的数量可以与阈值进行比较，以确定是否增大发送窗口大小；反之亦然，UE可以将如此监视的否定确认的数量与相同或另一阈值进行比较，以确定是否减小发送窗口大小。例如，UE在x秒的时间段期间(例如，其中x是3秒或更长时间)连续监视是否接收到多于y个肯定/否定确认(例如，其中y还取决于发送的分组的数量和监视时段x的长度)。
此外，要由UE检查的另外的替代或附加条件可以是，当与发送的数据分组的总数进行比较时，确定肯定和/或否定确认的关系。例如，UE跟踪数据分组的总数，并监视针对这些发送的数据分组而确定的肯定和/或否定确认。例如，关系(例如，以百分比表示，诸如NACK/数据分组和ACK/数据分组)可以由UE确定并与相应的阈值进行比较。如果百分比高于阈值，则UE确定分别减小(如果NACK百分比高于NACK阈值)或增大(如果ACK百分比高于ACK阈值)发送窗口大小。
以上讨论的条件仅作为示例理解。本领域技术人员可以同样地定义这些条件的变体或完全不同的条件。
此外，上述描述分别描述了用于确定是否改变发送窗口大小的这些条件。然而，解决方案的其他变体可以依赖于必须满足这些条件中的一个或多个，以便UE确定必须改变发送窗口大小。这可以提高标识诸如拥塞或即将发生的拥塞的场景的可靠性。
用于执行确定是否改变发送窗口大小的步骤的这些条件和/或对应参数(例如，阈值)可以在UE处预先确定，例如，由网络侧(例如，IAB提供者；例如，使用高层配置消息，诸如RRC层的一部分)或者可以硬编码到UE中(例如，经由SIM卡硬编码到UE中或根据3GPP规范编程)。
上述解决方案已经通过基于针对先前发送的数据分组而确定的接收反馈适当地确定的逐步增大和减小发送窗口大小的方式来描述。然而，除了逐步增大和减小发送窗口大小之外，同样有可能使用至少两个不同的发送窗口大小来实施解决方案，该至少两个不同的发送窗口大小可以由UE基于针对先前发送的数据分组而获得的接收反馈来选择。
根据一个示例性实施方式，只能定义两个发送窗口大小，UE取决于接收反馈在这两个窗口之间切换。例如，UE可以使用初始发送窗口大小来开始数据分组传输。在确定减小发送窗口大小(例如，在接收到太多否定确认的情况下)之后，UE可以使用减小的发送窗口大小(例如，将初始发送窗口大小减半)用于进一步的数据分组传输。反过来，UE可以最终确定再次将发送窗口大小增大到最初使用的窗口大小，依此类推。
相反地，初始发送窗口大小可以是较低的值，使得UE以较低的数据吞吐量开始，在确定增大发送窗口大小的条件发生时，可以通过增大发送窗口大小来增加数据吞吐量。
然而，虽然上面只描述了两个不同的发送窗口大小，但是其他示例性实施方式可以使用UE可以从中选择的多于两个合适的发送窗口大小。具有更多的发送窗口大小也可以可选地受益于实施用于基于所确定的接收反馈来确定减小或增大多少发送窗口大小的多于一个阈值。这可能有助于实施更精确、更精细和仍快速的流控制机制。
图19示出了根据上述解决方案的简化和示例性UE结构。图19中所示的UE的各种结构元件可以例如与对应的输入/输出节点(未示出)彼此互连，以便例如交换控制和用户数据以及其他信号。虽然未示出用于说明目的，但是UE可以包括进一步的结构元件。
由此可见，UE包括基于发送窗口(例如，在更新发送窗口大小之前和之后)发送数据分组的数据分组发送器。UE还包括接收反馈接收器，用于接收关于至少一个发送的数据分组的接收反馈。UE还包括用于基于接收由反馈接收器所接收的接收反馈来确定发送窗口大小的电路(图19中的发送窗口大小确定器电路)。
图20示出了根据上述示例性解决方案之一的示例性数据分组交换。示例性地假设UE(作为发送侧和源节点)在向IAB提供者(作为目的地节点和接收侧)发送数据分组时使用10个PDU大小的发送窗口。这些分组将由中间节点I-节点2和中间节点I-节点1转发。还示例性地假设中间节点I-节点1经历拥塞(可能是由于到IAB提供者的弱无线电链路)，这导致只能发送一些传入的数据分组(例如，分组11、12和20)。假设在IAB提供者处实际成功地接收到数据分组11、12和20；进一步假设具有SN＝20的数据分组还包括RLC状态轮询请求。假设该轮询请求在接收侧触发对应的反馈，则IAB提供者向发送侧(UE)发送接收反馈，其指示具有序列号11、12和20的数据分组已经被成功地接收(参见图中的ACK)，而具有序列号13-19的数据分组则否定确认(参见图中的NACK)。
UE可以从NACK的数量来确定在数据业务路由内正在发生拥塞，并将发送窗口大小减小一半(例如，在这种情况下为5)。此外，滑动发送窗口，使得下边缘位于SN＝13(即12+1)，并且上边缘为SN＝17。相应地，在假设数据业务路由能够向IAB提供者发送13-17时，从UE侧发送具有序列号13-17的数据分组。再者，假设在接收侧触发对应的接收反馈(例如，分组17中的轮询比特)，并将具有序列号13、14和17的数据分组的肯定确认和具有序列号15和16的数据分组的否定确认通知给UE。
因此，数据吞吐量适应于最后一个中间节点(存在拥塞)的可用吞吐量能力。
如以上针对各种解决方案所说明的，发送窗口大小是动态的，并且可以基于由发送侧针对先前发送的数据获得的接收反馈而调整。当(ARM RLC实体的)发送侧调整发送窗口大小时，接收侧不必以相同的方式改变其自身的接收窗口大小。接收侧可以保持与之前相同的接收窗口大小，例如，初始化时的大小。例如，接收窗口被初始化为可能的最大大小，并且即使发送侧(例如，UE)减小其发送窗口大小也不会改变。在这样的解决方案中，甚至不会意识到发送侧减小了发送窗口大小。
在其它示例性实施方式中，可以同步发送窗口大小和接收窗口大小，使得在发送窗口大小和接收窗口大小以相同的程度和(几乎)同时而增大和减小的情况下。发送窗口和接收窗口大小的同步可以防止接收侧不正确地保留和/或丢弃PDU，从而导致不同的窗口滑动行为。
在一个示例性实施方式中，接收侧可以做出与发送侧相同的确定，即是否基于接收反馈来增大或减小或保持(即不变)发送窗口大小。在所述情况下，发送侧和接收侧可以有利地具有相同的确定基础(即接收反馈)。
同步发送窗口大小和接收窗口大小的另一解决方案是使用显式信令，例如，关于新发送窗口大小的信息被发送到接收侧，例如，作为数据分组的一部分(例如，以与状态报告轮询比特相同或类似的方式)。利用该信息，接收侧(例如，上行链路场景中的IAB提供者)可以以相同的方式来调整接收窗口的大小。
此外，如果接收侧知道确认计时器即将到期，则接收侧可以进一步改变接收反馈的发送优先级(例如，将接收反馈优先于其他传输，诸如用户数据)。例如，如果接收侧知道确认计时器已经到期，则接收侧可以进一步将接收反馈的传输优先级降低。所发送的数据分组可以例如包括时间戳，如当从发送侧发送时那样，使得接收侧可以预测发送侧的对应确认计时器何时到期。
在上述描述中，主要从发送侧(例如，图17中假设的上行链路场景中的UE)的角度来描述使用自适应发送窗口的解决方案。
图21以与图17类似的方式示出了下行链路数据业务路由的示例性IAB方案。在图21的该示例性场景中，UE是接收数据分组的实体。进一步示例性地假设实施E2E ARQ，根据该E2E ARQ，UE包括接收RLC ARQ实体，并且IAB提供者包括发送RLC ARQ实体。UE向发送侧(例如，在这种场景中的IAB提供者)报告接收反馈。另一方面，发送侧然后基于对于先前发送的数据分组的接收反馈来执行发送窗口大小的调整。所描述的由UE(作为上行链路场景中的发送侧)和IAB提供者(作为上行链路场景中的接收侧)执行的各种解决方案同样适用于IAB提供者(作为下行链路场景中的发送侧)和UE(作为下行链路场景中的接收侧)的行为。
简而言之，作为概述，IAB提供者基于发送窗口向UE发送数据分组，而UE针对所接收的数据分组返回接收反馈给IAB提供者(取决于数据分组是否能够被成功地解码，其是肯定确认还是否定确认)。基于该接收反馈(可能具有进一步的信息)，IAB提供者确定是否改变其发送窗口大小，例如，通过增大、减小发送窗口大小或保持其不变而进行改变。IAB提供者基于具有增大的、减小的或与保持与之前相同的大小的发送窗口来继续在下行链路中发送数据分组。
如将在下文中说明的，上文描述的根据图18的解决方案主要被描述为E2E ARQ架构的一部分，但也可以应用于HBH ARQ架构，其中ARQ在每跳处被执行。因此，可以在数据业务路由的任意两个节点之间实施该解决方案，诸如UE和下一个中间节点之间、两个中间节点之间、以及中间节点和IAB提供者之间。这些可以在相应的适用节点上实施，诸如UE、中间节点和IAB提供者。
更具体地，当支持HBH ARQ时，UE之后的数据业务路由中的第一中间节点(例如，图17中对于UE 1的I-节点2或对于UE 2的I-节点3)接收先前发送的数据分组，并将关于接收数据分组的反馈返回给UE1。如上文关于端到端解决方案详细说明的，UE因此可以基于所接收的接收反馈来调整发送窗口大小。为了避免重复，读者可以参考上面描述E2E解决方案的章节。
上述解决方案也适用于单跳场景，其中两个端节点将是UE和作为服务基站的gNB。对于这种单跳场景，不需要区分E2E ARQ和HBH ARQ解决方案，因为只有一个跳。或者，换句话说，单跳上的ARQ基本上同时是E2E和HBH。相应地，数据分组的预期接收者将是UE的服务基站(例如，gNB)，并且接收反馈将由服务基站(例如，gNB)发送到UE。
在解决方案的其它变体中，可以针对特定时机或场景选择性地激活基于自适应(adaptive)发送窗口大小的上述改进的流控制机制。如上所述，虽然解决方案可以应用于多跳场景(诸如IAB)或单跳场景，但是拥塞问题通常发生在多跳解决方案中。因此，当UE处于多跳场景时，网络侧可以决定仅激活这样的流控制机制。
根据一种解决方案，网络侧可以决定是否使用这种改进的流控制机制，并相应地在所述方面配置用户设备。例如，服务基站(例如，IAB提供者)可以使用RRC信令来激活功能，例如，RRC重新配置消息、或者RRC建立和RRC重建消息。
应当注意，根据实际实施方式，数据是否通过多跳场景被发送对UE是透明的，即UE不知道任何中间节点，并且假设它直接连接到服务基站(IAB提供者)。相应地，在这样的场景中，UE可能不会自主地激活这样的功能，因为它仅仅不知道特定的使用场景。
使用自适应发送窗口大小的改进的流控制机制已经在上面被一般地说明。在具体实施方式中，这些机制和解决方案可以在现有和未来的5G NR框架以及LTE框架中实施。例如，可以结合当前为5G NR定义的RLC层来实施这些解决方案。如前所说明的，RLC层为其AM数据传送提供ARQ功能，包括将要执行的重传和将作为RLC状态报告实施的接收反馈(参见图5)。
当将解决方案实施到RLC AM协议功能中时，RLC AM数据传送使用具有动态大小(AM_Window_Size)的发送窗口，而不是固定的窗口。
下面将说明一个非常具体的示例性实施方式。最大窗口大小(Max_AM_Window_Size)以及不同的初始窗口大小(Init_AM_Window_size)(例如，参见3GPP TS 38.322版本15.2.0的第9.2节)：
Max_AM_Window_Size：
该常数由每个AM RLC实体的发送侧和接收侧两者使用。当使用12比特SN时，Max_AM_Window_Size＝2048；当使用18比特SN时，Max_AM_Window_Size＝131072。
Init_AM_Window_Size：
Init_AM_Window_Size等于Max_AM_Window_Size的一半。
此外，发送侧上的AM数据传送定义可以被修改为以下内容(例如，参见3GPP TS38.322版本15.2.0第5.2.3.1.1节)：
最初，AM_Window_Size等于Init_AM_Window_Size，并在接收到状态PDU时根据5.3.2而更新。
…
当接收到具有SN＝x的RLC SDU的肯定确认时，AM RLC实体的发送侧应该：
-如果已经收到连续的Npos肯定确认，并且如果AM_Window_Size<Max_AM_Window_ Size
-AM_Window_Size＝AM_Window_Size*2
...
此外，发送侧上的ARQ过程定义可以被修改为以下内容(例如，参见3GPP TS38.322版本15.2.0的第5.3.2节)：
当从其对等AM RLC实体接收到通过STATUS PDU的对于RLC SDU或RLC SDU分段的否定确认时，AM RLC实体的发送侧应该：
-如果已经接收到连续的Nneg否定确认
-AM_Window_Size＝AM_Window_Size/2
…
接收侧上的AM数据传送定义可以被修改以使其使用Max_AM_Window_Size作为其接收窗口大小。
此外，可以基于根据为RLC层定义的触发条件之一触发的轮询比特来执行从发送侧到接收侧的接收反馈请求的发送。如前所说明的，从接收侧轮询RLC状态报告可能涉及从发送侧向接收侧发送PDU中的轮询比特。根据上述解决方案的进一步变体，用于从接收侧轮询状态报告的一些触发条件可以适应所调整的发送窗口大小。这可以促进发送ARQ侧能够在合理的时间内获得先前发送的PDU的接收状态。
例如，考虑到发送窗口大小强烈地影响可以发送的数据量，基于发送的数据量的那些触发取决于所调整的发送窗口大小。因此，当确定这些数据量触发条件是否满足时，用户设备可以考虑当前发送窗口大小。
例如，UE确定在已经轮询了最后的RLC状态报告之后是否已经发送至少一定数量的数据分组或字节，并基于用于发送这些数据分组的(多个)发送窗口大小来缩放数据分组和字节的数量。
一个特定实施方式使用缩放因子来根据需要放大或缩小触发条件。具体地，缩放因子可以反映例如最大发送窗口大小和所使用的发送窗口大小之间的关系。例如，如果使用发送窗口大小的一半，则用于触发RLC状态报告的条件也可以是一半(例如，一半数据PDU和/或一半字节)，反之亦然。
类似地，用于轮询RLC状态报告的另一触发条件是控制发送最后的轮询之后的时间的轮询重传时间的到期。通过还根据发送窗口大小来缩放该计时器，有可能在发送窗口为小时更频繁地发送轮询。这可能具有有助于避免窗口暂停的优点，因为RLC状态报告内的确认被更早地接收，并且相应地，可以更早地滑动发送窗口。
以上已经对触发条件的适配进行了一般性说明。在具体实施方式中，它可以在现有和未来的5G NR框架以及LTE框架中实施。例如，这些解决方案可以结合当前为5G NR定义的RLC层来实施。
例如，可以在现有定义中添加新的缩放因子定义(参见3GPP TS 38.322版本15.2.0的第7.4节)：
d)轮询IAB缩放(pollIABScale)
每个AM RLC实体的发送侧使用该参数来放大或缩小参数pollPDU和pollByte以及t-PollRetransmit。
相应地，通过将部分或全部触发条件适应于所调整的发送窗口大小，接收反馈的轮询(请求)更合适，并且可以根据需要在时间上来回移动。
根据另一组变体，发送节点(例如，UE)可以控制用于先前发送的数据分组的计时器(例如，在下面的确认计时器中被调用)。例如，UE可以控制每一发送的数据分组一个计时器，以便控制对于数据分组的肯定或否定确认。
在一个示例性实施方式中，发送节点(例如，UE)可以在发送数据分组时开启一个确认计时器。当接收到关于所述数据分组(即为其开启计时器的数据分组)的接收状态的反馈时，计时器停止。反馈可以是例如在RLC状态报告内接收到的肯定确认或否定确认。
在没有接收到针对数据分组的反馈的情况下，对应的确认计时器最终到期，在这种情况下，发送侧确定接收侧没有正确地接收到相应的数据分组。相应地，发送侧确定对于该数据分组的NACK。
根据一个示例性变体，NACK可以由发送侧以与从接收侧接收的NACK(例如，在RLC状态报告内)相同的方式使用。从这样的确认计时器确定的NACK以及从接收侧接收的NACK可以被发送侧用于确定是否改变发送窗口大小。具体地，上述的一些条件依赖于为先前发送的数据分组而获得的NACK的数量。
确认计时器及其时间值可以例如由网络侧预先配置，例如，通过向发送侧(例如，UE)发送合适的配置消息来配置。在一个示例中，确认计时器及其值可以通过RRC重新配置、RRC建立或RRC重新建立消息中的一个或多个来配置。
另一方面，另外或可替代地，确认计时器及其时间值可以被预定为SIM的一部分或被定义为3GPP规范的一部分。
通过从网络侧配置而有助的一个好处是，计时器的值可以适应发送侧(例如，UE)和接收侧(例如，IAB提供者)之间的跳数。具体地，路由越长(例如，跳数更多)，确认计时器的值可以设置得越长，反之，路由越短(例如，跳数越少)，确认计时器可以设置得越短。
另一好处是，确认计时器的值可以适应与数据分组相关联的服务类型。服务类型可以是例如视频会议服务或尽力而为的服务(电子邮件、FTP)，并对带宽和等待时间提出某些要求。例如，服务的优先级越高，就意味着需要更多的带宽，在这种情况下，优先级越高，计时器值可以设置得越长。
可选地，当确认计时器到期时由发送侧获得的NACK也可以用于触发发送侧针对所述丢失的数据分组的重传。
新的确认计时器机制已经在上面作了一般性说明。在具体实施方式中，它可以在现有和未来的5G NR框架以及LTE框架中实施。例如，这些解决方案可以结合当前为5G NR定义的RLC层来实施。
例如，可以在现有定义中添加新的计时器定义(参见3GPP TS 38.322版本15.2.0的第7.3节)：
d)t-IAB_NACK
该计时器由AM RLC实体的发送侧使用，以便在计时器到期时确定PDU处于被NACK的状态。
图22示出了使用自适应发送窗口以及确认计时器的示例性解决方案，其描绘了在UE(作为发送侧)处执行的处理的流程图。与图18的流程图相比，图22更具体在于它是指增大和减小发送窗口大小的实施方式，在于它操作对于每个数据分组的确认计时器，并且用于在其各自到期后生成对于数据分组的附加否定确认。附加否定确认然后可以用于做出对增大、减小发送窗口大小或保持发送窗口大小不变的确定。
如图22所示，UE因此可以为每个发送的数据分组开启确认计时器，并且可以控制该计时器是停止(例如，通过所接收的接收反馈，诸如ACK或NACK)还是到期。在确认计时器到期时，UE确定对应的数据分组(为其开启计时器)不能成功地发送，并且认为该数据分组被否定确认(被NACK)。
然后，该计时器NACK可以与从接收侧接收的接收反馈一起使用，以适应发送窗口。在所述方面，可以对照接收反馈检查上述任一条件，以确定是否以及如何适应发送窗口大小。取决于结果，发送窗口大小增大、减小或不改变。在任何情况下，UE的过程继续使用发送窗口来发送数据分组(可以是具有增大的、减小的或与之前相同的大小)。
下面将说明进一步的解决方案。发明人所标识的HBH ARQ(例如，在诸如IAB的多跳场景中)的一个问题是，单跳中的ARQ操作与另一跳中的ARQ操作隔离。例如，当假设在图8的IAB节点2处的下行链路中存在拥塞时，DU侧缓冲区在从UE接收许多NCK时开始溢出，并且仍然从IAB节点2的MT侧接收传入PDU。IAB节点2和IAB节点1之间的ARQ操作正常，因为IAB节点1只接收来自IAB节点2MT的ACK。
取决于该节点是发送数据分组还是接收数据分组，在跳的两个节点(分别是该跳的发送节点和接收节点)之间可以使用以下解决方案。例如，在下行链路情况下，UE可以是接收节点，并且第一中间节点可以是发送节点；在上行链路情况下，UE将是发送节点，并且第一中间节点将是接收节点。该逻辑同样适用于其他跳，例如，涉及两个中间节点的跳，或涉及一个中间节点和IAB节点的跳。为了有助于对以下情况的讨论和描述，假设在UE之后的第一中间节点处在上行链路中发生拥塞(图8中的I-节点2)的示例性场景。在I-节点2和I-节点1之间执行HBH ARQ，并且在UE和I-节点2之间执行HBH ARQ。在这种情况下，I-节点2将向UE提供拥塞信息。
然而，尽管将在关于UE和I-节点2之间的第一跳的这样的上行链路场景的上下文中描述解决方案，但是对于读者来说显而易见的是，这些解决方案可以同样地应用于其他跳和下行链路场景中。
一个示例性解决方案基于中间节点(诸如假设场景的I-节点2)的DU侧和MT侧内的内部信令。如上所示，在中间节点的一侧发生拥塞的情况下，中间节点的另一侧继续确认传入的数据分组。因此，通过在内部向另一侧指示正在发生或将发生拥塞，中间节点的另一侧可以停止(例如，从UE)发送对于进一步的传入数据分组的ARQ反馈。例如，确认传入数据分组的停止可以被限于诸如由另一侧内部指示的时间量，或者可以被预先配置。相应地，上游节点(例如，假设场景中的UE，或在其他场景中的另一中间节点或IAB提供者)将减少其对进一步数据分组的发送，因为在没有来自跳的接收侧的肯定确认的情况下，它不能滑动其发送窗口。因此，这种隐式指示可以解决或避免拥塞问题。
根据替代或附加解决方案，当执行逐跳ARQ时，在跳的两个节点之间显式地发送拥塞信息，特别是从经历拥塞的中间节点(例如，中间节点)到其发送数据的上游节点(例如，假设场景中的UE，或者在另一场景中的另一中间节点或IAB提供者)。
该拥塞信息可以例如作为接收反馈的一部分被接收(例如，RLC ARQ信息)。拥塞信息可以短至一比特，在这种情况下，它将区分下游节点(例如，假设场景中的I-节点2)是否拥塞。可替代地，拥塞信息可以是几比特长，在这种情况下，它可以提供关于拥塞的更详细的信息。例如，拥塞信息可以区分拥塞的不同原因，诸如由于到下一个下游节点的弱无线电链路而引起的拥塞，或者由于下游节点所提供的非常有限的授权而引起的拥塞。拥塞信息还可以指示拥塞的严重程度，这将允许接收拥塞信息的节点(例如，假设场景中的UE)以适当的方式作出反应，例如，数据速率降低了多少。发送侧(例如，假设场景中的UE)至少在一时间段内降低向跳的接收侧发送数据的速率。
在解决方案的进一步的变体中，跳的发送侧(例如，假设场景中的UE)基于从跳的接收侧接收的接收反馈(例如，ACK；NACK)来分析拥塞信息。例如，肯定确认和/或否定确认的分布允许发送侧(例如，UE)区分由拥塞引起的分组丢失和由无线电干扰引起的分组丢失。例如，在某种程度上均匀分布在所传送的数据分组中的否定确认可能指示分组丢失是由拥塞引起的。另一方面，一组连续NACK(即指参考连续序列号)可以指示分组丢失是由无线电干扰引起的。
取决于该情况，跳的发送侧(例如，UE)可能对所接收的拥塞信息作出不同的反应。例如，如果分组丢失主要是由下游节点的拥塞引起的，则发送侧(例如，UE)可以减小发送窗口的大小；另一方面，如果分组丢失主要是由无线电干扰引起的，则发送侧可以保持发送窗口大小不变。
根据进一步的示例性实施方式，对于HBH ARQ，拥塞的中间节点可以利用由端节点(IAB提供者)给出的信息来改变其聚合策略，以最小化拥塞的影响。通过F1-AP接口携带IAB提供者所给出的信息，并且指示某一服务类型的等待时间增加了不少。然后，拥塞的中间节点可以决定基于服务类型聚合数据承载，并且只关注/优先处理某个服务类型的聚合承载的传输。
其他方面
根据第一方面，提供一种用户设备，包括发送器，基于具有发送窗口大小的发送窗口来发送至少一个数据分组。UE包括接收器，接收关于至少一个发送的数据分组的接收反馈。UE包括处理电路，至少基于所接收的接收反馈来确定是否改变至少要用于发送进一步的数据分组的发送窗口的发送窗口大小。
根据除第一方面之外提供的第二方面，在处理电路确定要改变发送窗口大小的情况下，发送器基于具有改变的发送窗口大小的发送窗口来发送进一步的数据分组。
根据除第一或第二方面之外提供的第三方面，至少一个数据分组通过无线电链路被直接发送到作为用户设备的服务基站的基站，并且从基站接收接收接收反馈。
可替代地，至少一个数据分组被发送到具有至少两跳的数据业务路由的第一中间节点。数据业务路由还包括作为源节点的用户设备和作为目的地节点的接收实体。数据由用户设备发送到接在用户设备之后的第一中间节点，并由第一中间节点转发到目的地节点。在一个可选实施方式中，接收反馈从第一中间节点被接收，并且指示至少一个数据分组是否被目的地节点正确地接收，或者在另一可选实施方式中，接收反馈从第一中间节点被接收，并且指示至少一个数据分组是否被第一中间节点正确地接收。
根据除第一至第三方面中的任何一个之外提供的第四方面，当确定是否改变发送窗口大小时，处理电路：
基于针对由用户设备先前发送的数据分组而确定的肯定和/或否定确认来确定增大或减小发送窗口大小。
在一个可选实施方式中，发送窗口大小不能增大到最大发送窗口大小以上，并且在另一可选实施方式中，发送窗口大小不能减小到最小发送窗口大小以下。
根据除第四方面之外提供的第五方面，当确定增大或减小发送窗口大小时，处理电路：
确定在以下情况下增大发送窗口大小：
-在对于由用户设备先前发送的数据分组的接收反馈内接收到一定数量的肯定确认，一定数量的肯定确认是指连续的数据分组，和/或
-在定义的时间段内接收到一定数量的肯定确认，和/或
-肯定确认相比于发送的数据分组的数量的百分比高于阈值，
确定在以下情况下减小发送窗口大小：
-在对于由用户设备先前发送的数据分组的接收反馈内接收到一定数量的否定确认，一定数量的否定确认是指连续的数据分组，和/或
-在定义的时间段内接收到一定数量的否定确认，和/或
-否定确认相比于发送的数据分组的数量的百分比高于阈值。
根据除第一至第五方面中的任何一个之外提供的第六方面，由用户设备使用发送窗口来确定要发送哪些数据分组，在可选实施方式中，处理电路确定在所述数据分组与发送窗口内的序列号相关联的情况下可以发送数据分组，并且确定在所述数据分组与发送窗口之外的序列号相关联的情况下不能发送数据。
根据除第一至第六方面中的任何一个之外提供的第七方面，接收器接收配置消息以配置用户设备是否启动基于接收反馈改变发送窗口大小的机制。在可选实施方式中，从用户设备的服务基站接收配置消息，服务基站是数据业务路由的目的地节点。
根据除第一至第七方面中的任何一个之外提供的第八方面，接收反馈是指示对于先前发送的至少一个数据分组的肯定或否定确认的状态报告。在可选实施方式中，接收反馈被发送，作为在用户设备和接收侧之间使用的自动重复请求ARQ机制的一部分，以基于重传被否定确认的数据分组来实施传输纠错。在可选实施方式中，ARQ机制是无线电链路控制RLC层的一部分。
根据除第一至第八方面中的任何一个之外提供的第九方面，处理电路开启对于所发送的至少一个数据分组中的每一个的确认计时器。当接收到对于相应的数据分组的接收反馈时，处理电路停止确认计时器。在确认计时器到期时，处理电路确定相应的数据分组没有被接收侧正确地接收，并且可选地确定重传被确定为未被正确地接收的相应的数据分组。在可选实施方式中，当确定是否改变发送窗口的发送窗口大小时，对相应的数据分组未被正确地接收的确定被用作否定确认。
根据除第九方面之外提供的第十方面，接收器从用户设备的服务基站接收配置消息，该配置消息包括用于配置确认计时器的值的信息。在可选实施方式中，确认计时器的值与作为数据业务路由的源节点的用户设备和目的地节点之间的数据业务路由的跳数成比例。在可选实施方式中，确认计时器的值取决于与由用户设备发送的至少一个数据分组相关联的服务类型。
根据除第一至第十方面中的任何一个之外提供的第十一方面，处理电路确定至少一个触发条件是否触发向接收侧发送用于发送对于所发送的至少一个数据分组的接收反馈的接收反馈请求。至少一个触发条件包括以下至少一个：
·在最后的接收反馈请求之后，至少已经发送一定数量的数据分组，
·在最后的接收反馈请求之后，至少已经发送一定数量的数据字节，
·接收反馈请求计时器到期，其指示发送最后的接收反馈请求之后的时间。
当确定触发条件中的至少一个是否触发接收反馈请求的发送时，处理电路考虑由用户设备用于发送数据分组的发送窗口大小。
根据除第一至第十一方面中的任何一个之外的第十二方面，至少一个数据分组被发送到具有至少两跳的数据业务路由的第一中间节点。数据业务路由还包括作为源节点的用户设备和作为目的地节点的接收实体。接收器接收与对于先前发送的数据分组的接收反馈一起的拥塞信息，拥塞信息指示数据业务路由的至少一个节点遭受数据拥塞。处理电路控制发送器在一时间段内发送较少的数据分组。在可选实施方式中，接收反馈内的拥塞信息是一比特在可选实施方式中，拥塞信息是从诸如确认的分布的接收反馈中的模式被解释的。
根据第十三方面，提供了一种方法，包括由用户设备执行的以下步骤。基于具有发送窗口大小的发送窗口来发送至少一个数据分组。接收关于至少一个所发送的数据分组的接收反馈。至少基于所接收的接收反馈，确定是否改变至少要用于发送进一步的数据分组的发送窗口的发送窗口大小。
根据第十四方面，提供了一种服务基站。服务基站的发送器基于具有发送窗口大小的发送窗口来发送至少一个数据分组。服务基站的接收器接收关于所发送的至少一个数据分组的接收反馈。服务基站的处理电路至少基于所接收的接收反馈，确定是否改变至少要用于发送进一步的数据分组的发送窗口的发送窗口大小。
根据在第十四方面之外提供的第十五方面，服务基站是集成接入和回程IAB提供者，可选地，其中IAB提供者是下行链路数据业务路由中的源节点，在下行链路数据业务路由中用户设备是数据的目的地节点，并在下行链路数据业务路由中至少存在一个中间IAB节点。
本公开的硬件和软件实施方式
本公开可以通过软件、硬件或软件与硬件配合来实施。在上述每个实施例的描述中使用的每个功能块可以由诸如集成电路的LSI部分地或全部地实现，并且在每个实施例中描述的每个过程可以由相同的LSI或LSI的组合部分地或全部地控制。LSI可以单独地形成为芯片，或者可以形成一个芯片以包括部分或全部功能块。LSI可以包括耦合到其的数据输入和输出。根据集成度的不同，这里的LSI可以被称为IC(集成电路)、系统LSI、超级LSI或超LSI。然而，实现集成电路的技术不限于LSI，并且可以通过使用专用电路、通用处理器或专用处理器来实现。另外，可以使用在制造LSI之后可以编程的FPGA(现场可编程门阵列)或其中可以重新配置布置在LSI内部的电路单元的连接和设置的可重新配置处理器。本公开可以实现为数字处理或模拟处理。如果由于半导体技术或其他衍生技术的发展而使未来的集成电路技术取代LSI，则可以使用未来的集成电路技术来集成功能块。生物技术也可以应用。
此外，各种实施例也可以借助于软件模块来实施，该软件模块由处理器执行或者直接在硬件中执行。软件模块和硬件实施方式的组合也是可能的。软件模块可以存储在任何种类的计算机可读存储介质上，例如，RAM、EPROM、EEPROM、闪存、寄存器、硬盘、CD-ROM、DVD等。还应注意的是，不同实施例的各个特征可以单独地或任意地组合在另一实施例中。
本领域技术人员应理解，如在具体实施例中所示，可以对本公开进行许多变化和/或修改。因此，在所有方面，本实施例被认为是说明性的而不是限制性的。

Claims (15)

1.一种用户设备，包括：
发送器，基于具有发送窗口大小的发送窗口来发送至少一个数据分组，
接收器，接收关于所发送的至少一个数据分组的接收反馈，
处理电路，至少基于所接收的接收反馈来确定是否改变至少要用于发送进一步的数据分组的发送窗口的发送窗口大小。
2.根据权利要求1所述的用户设备，其中，在所述处理电路确定要改变所述发送窗口大小的情况下，所述发送器基于具有所改变的发送窗口大小的发送窗口来发送进一步的数据分组。
3.根据权利要求1或2所述的用户设备，其中，所述至少一个数据分组是通过无线电链路被直接发送到作为所述用户设备的服务基站的基站，并且所述接收反馈是从所述基站被接收的，或者
其中，所述至少一个数据分组被发送到具有至少两跳的数据业务路由的第一中间节点，所述数据业务路由还包括作为源节点的用户设备和作为目的地节点的接收实体，其中，所述数据由所述用户设备发送到接在所述用户设备之后的所述第一中间节点，并且由所述第一中间节点转发到所述目的地节点，
可选地，其中，所述接收反馈是从所述第一中间节点被接收的，并且指示所述至少一个数据分组是否被所述目的地节点正确地接收，或者
可选地，其中，所述接收反馈是从所述第一中间节点被接收的，并且指示所述至少一个数据分组是否被所述第一中间节点正确地接收。
4.根据权利要求1至3中任一项所述的用户设备，其中，所述处理电路在确定是否改变所述发送窗口大小时：
基于针对由所述用户设备先前发送的所述数据分组而确定的肯定和/或否定确认来确定增大或减小所述发送窗口大小，
可选地，其中，所述发送窗口大小不能增大到最大发送窗口大小以上，以及
可选地，其中，所述发送窗口大小不能减小到最小发送窗口大小以下。
5.根据权利要求4所述的用户设备，其中，所述处理电路在确定增大或减小所述发送窗口大小时：
确定在以下情况下增大所述发送窗口大小：
·在对于由所述用户设备先前发送的所述数据分组的接收反馈内接收到一定数量的肯定确认，所述一定数量的肯定确认是指连续的数据分组，和/或
·在定义的时间段内接收到一定数量的肯定确认，和/或
·肯定确认相比于所发送的数据分组的数量的百分比高于阈值，
确定在以下情况下减小所述发送窗口大小：
·在对于由所述用户设备先前发送的所述数据分组的接收反馈内接收到一定数量的否定确认，所述一定数量的否定确认是指连续的数据分组，和/或
·在定义的时间段内接收到一定数量的否定确认，和/或
·否定确认相比于所发送的数据分组的数量的百分比高于阈值。
6.根据权利要求1至5中任一项所述的用户设备，其中，所述发送窗口被所述用户设备用来确定要发送哪些数据分组，
可选地，其中，所述处理电路确定在数据分组与所述发送窗口之内的序列号相关联的情况下可以发送所述数据分组，以及确定在所述数据分组与所述发送窗口之外的序列号相关联的情况下不能发送数据。
7.根据权利要求1至6中任一项所述的用户设备，其中，所述接收器接收配置消息，以配置所述用户设备是否启动基于所述接收反馈改变所述发送窗口大小的机制，
可选地，其中，所述配置消息是从所述用户设备的服务基站被接收的，所述服务基站是数据业务路由的目的地节点。
8.根据权利要求1至7中任一项所述的用户设备，其中，所述接收反馈是指示对于所述先前发送的至少一个数据分组的肯定或否定确认的状态报告，
可选地，其中，所述接收反馈被发送，作为在所述用户设备和接收侧之间使用的自动重复请求ARQ机制的一部分，以基于重传被否定确认的数据分组来实施传输纠错，可选地，其中所述ARQ机制是无线电链路控制RLC层的一部分。
9.根据权利要求1至8中任一项所述的用户设备，其中，所述处理电路开启对于所发送的至少一个数据分组中的每一个的确认计时器，其中，当接收到对于相应的数据分组的接收反馈时，所述处理电路停止所述确认计时器，以及
其中，在所述确认计时器到期时，所述处理电路确定所述相应的数据分组没有被接收侧正确地接收，并且可选地确定重传被确定为未被正确地接收的所述相应的数据分组，
可选地，其中，当确定是否改变所述发送窗口的发送窗口大小时，对所述相应的数据分组未被正确地接收的确定被用作否定确认。
10.根据权利要求9所述的用户设备，其中，所述接收器从所述用户设备的服务基站接收配置消息，所述配置消息包括用于配置所述确认计时器的值的信息，
可选地，其中，所述确认计时器的值与作为数据业务路由的源节点的用户设备和目的地节点之间的数据业务路由的跳数成比例，
可选地，其中，所述确认计时器的值取决于与由所述用户设备发送的所述至少一个数据分组相关联的服务类型。
11.根据权利要求1至10中任一项所述的用户设备，其中，所述处理电路确定至少一个触发条件是否触发向所述接收侧发送用于发送对于所发送的至少一个数据分组的接收反馈的接收反馈请求，其中，所述至少一个触发条件包括以下至少一个：
·在最后的接收反馈请求之后，至少已经发送一定数量的数据分组，
·在最后的接收反馈请求之后，至少已经发送一定数量的数据字节，
·接收反馈请求计时器到期，所述接收反馈请求计时器指示发送最后的接收反馈请求之后的时间，
其中，当确定所述触发条件中的至少一个是否触发所述接收反馈请求的发送时，所述处理电路考虑由所述用户设备用于发送数据分组的发送窗口大小。
12.根据权利要求1至11中任一项所述的用户设备，其中，所述至少一个数据分组被发送到具有至少两跳的数据业务路由的第一中间节点，所述数据业务路由还包括作为所述源节点的用户设备和作为所述目的地节点的接收实体，
其中，所述接收器接收与对于先前发送的数据分组的接收反馈一起的拥塞信息，所述拥塞信息指示所述数据业务路由的至少一个节点遭受数据拥塞，
其中，所述处理电路控制所述发送器在一时间段内发送较少的数据分组，
可选地，其中，所述接收反馈内的所述拥塞信息是一比特，
可选地，其中，所述拥塞信息是从诸如确认的分布的所述接收反馈中的模式被解释的。
13.一种方法，包括由用户设备执行的以下步骤：
基于具有发送窗口大小的发送窗口来发送至少一个数据分组，
接收关于至少一个所发送的数据分组的接收反馈，
至少基于所接收的接收反馈来确定是否改变至少要用于发送进一步的数据分组的发送窗口的发送窗口大小。
14.一种服务基站，包括：
发送器，基于具有发送窗口大小的发送窗口来发送至少一个数据分组，
接收器，接收关于所发送的至少一个数据分组的接收反馈，
处理电路，至少基于所接收的接收反馈来确定是否改变至少要用于发送进一步的数据分组的发送窗口的发送窗口大小。
15.根据权利要求14所述的服务基站，其中，所述服务基站是集成接入和回程IAB提供者，可选地，其中，所述IAB提供者是下行链路数据业务路由中的源节点，在所述下行链路数据业务路由中用户设备是数据的目的地节点，并且在所述下行链路数据业务路由中至少存在一个中间IAB节点。
CN201980041563.6A 2018-09-25 2019-09-09 数据传输涉及的用户设备和基站 Pending CN112313894A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP18196683.9 2018-09-25
EP18196683.9A EP3629505A1 (en) 2018-09-25 2018-09-25 User equipment and base station involved in transmission of data
PCT/EP2019/073973 WO2020064310A1 (en) 2018-09-25 2019-09-09 User equipment and base station involved in transmission of data

Publications (1)

Publication Number Publication Date
CN112313894A true CN112313894A (zh) 2021-02-02

Family

ID=63685604

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201980041563.6A Pending CN112313894A (zh) 2018-09-25 2019-09-09 数据传输涉及的用户设备和基站

Country Status (5)

Country Link
US (1) US11973604B2 (zh)
EP (2) EP3629505A1 (zh)
JP (1) JP7446247B2 (zh)
CN (1) CN112313894A (zh)
WO (1) WO2020064310A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113424511A (zh) * 2018-09-07 2021-09-21 苹果公司 用于无线电接入网络中的拥塞处理的装置和方法
GB2581121B (en) * 2018-10-31 2021-06-02 Tcl Communication Ltd Bearer mapping in a wireless communications network
CN113243130B (zh) * 2018-12-20 2024-04-19 株式会社Ntt都科摩 无线节点以及无线通信方法
CN111490857A (zh) * 2019-01-25 2020-08-04 夏普株式会社 适配实体和rlc实体的无线通信方法及通信设备
US11856450B2 (en) * 2020-02-27 2023-12-26 Qualcomm Incorporated Range extension for radio link control status reporting
US11438269B2 (en) * 2020-05-20 2022-09-06 Verizon Patent And Licensing Inc. Systems and methods for congestion control in an integrated access and backhaul network
WO2022030517A1 (ja) * 2020-08-05 2022-02-10 京セラ株式会社 通信制御方法

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1512710A (zh) * 2002-12-27 2004-07-14 ��ʽ����Ntt����Ħ 发射控制方法和系统
EP1648183A1 (en) * 2003-05-30 2006-04-19 ZTE Corporation The adjusting method for the transmitting window of the radio link layer
CN1771686A (zh) * 2003-04-07 2006-05-10 艾利森电话股份有限公司 Rlc窗口大小的重新配置
US20100260049A1 (en) * 2007-11-01 2010-10-14 Telefonaktiebolaget L M Ericsson (Publ) Limiting RLC Window Size in The HSDPA Flow Control
CN106330412A (zh) * 2015-06-25 2017-01-11 联芯科技有限公司 利用harq ack/nack的rlc pdu发送方法及装置
US20180152267A1 (en) * 2015-05-14 2018-05-31 Cable Laboratories, Inc. Hybrid automatic repeat request (harq) in listen before talk systems
WO2018145787A1 (en) * 2017-02-13 2018-08-16 Telefonaktiebolaget Lm Ericsson (Publ) Technique for monitoring a radio communication

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6778509B1 (en) 1999-11-19 2004-08-17 Hughes Electronics Corporation MAC layer protocol for a satellite based packet switched services
JP3784801B2 (ja) 2002-12-27 2006-06-14 株式会社エヌ・ティ・ティ・ドコモ 伝送制御方法、通信装置、通信システム及びプログラム
EP2051454A1 (en) 2007-10-17 2009-04-22 Nokia Siemens Networks Oy Method and device for data communication and communication system comprising such device
JP2011188429A (ja) 2010-03-11 2011-09-22 Kyocera Corp 無線通信装置
US8363550B1 (en) * 2010-06-15 2013-01-29 Google Inc. Adaptive data unit transmission and acknowledgment
US9271164B2 (en) * 2013-08-05 2016-02-23 Acer Incorporated Method of increasing data throughput of a wireless network system by dynamically adjusting MTU/fragmentation size according to current transmission status
CN108370533B (zh) * 2015-09-14 2022-01-07 联想创新有限公司（香港) 用于竞争窗口大小调整的设备和方法
WO2017050363A1 (en) * 2015-09-23 2017-03-30 Sony Mobile Communications Inc Contention window adjustment in unlicensed cellular radio network
US10708000B2 (en) * 2015-10-20 2020-07-07 Apple Inc. Contention window size adaptation
CN109863782B (zh) * 2016-10-26 2022-04-29 瑞典爱立信有限公司 5g拥塞控制
US10624125B2 (en) * 2016-10-26 2020-04-14 Qualcomm Incorporated Techniques for semi-autonomously scheduling an uplink transmission in a shared radio frequency spectrum band
CN111769968A (zh) * 2016-11-04 2020-10-13 华为技术有限公司 一种混合接入网络中处理报文的方法及网络设备
US10686691B2 (en) * 2017-07-12 2020-06-16 The Board Of Trustees Of The University Of Alabama Intelligent high-speed unmanned vehicle communications via bio-inspired multi-beam pipe transmission
EP3665817A1 (en) * 2017-08-11 2020-06-17 Telefonaktiebolaget LM Ericsson (publ) Methods for autonomous uplink transmissions and retransmissions
EP4037419A1 (en) * 2017-09-25 2022-08-03 Huawei Technologies Co., Ltd. Method for listening on uplink channel and apparatus
US10490059B2 (en) * 2017-12-15 2019-11-26 Comcast Cable Communications, Llc Priority-based wireless collision avoidance and interfering device response
EP3726919B1 (en) * 2018-02-12 2022-06-15 LG Electronics Inc. Method for adjusting size of contention window in wireless communication system, and communication device using method
US10476808B1 (en) * 2018-03-07 2019-11-12 Sprint Spectrum L.P. Dynamic configuration of maximum transmission unit of UE, based on receipt of oversized packet(s) at network entity
US20190327064A1 (en) * 2018-04-19 2019-10-24 Qualcomm Incorporated Repetition-based transmissions for uplink ultra-reliable low latency communication
EP3833128B1 (en) * 2018-08-17 2023-08-09 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Harq information transmission method, network device and terminal device

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1512710A (zh) * 2002-12-27 2004-07-14 ��ʽ����Ntt����Ħ 发射控制方法和系统
CN1771686A (zh) * 2003-04-07 2006-05-10 艾利森电话股份有限公司 Rlc窗口大小的重新配置
EP1648183A1 (en) * 2003-05-30 2006-04-19 ZTE Corporation The adjusting method for the transmitting window of the radio link layer
US20100260049A1 (en) * 2007-11-01 2010-10-14 Telefonaktiebolaget L M Ericsson (Publ) Limiting RLC Window Size in The HSDPA Flow Control
US20180152267A1 (en) * 2015-05-14 2018-05-31 Cable Laboratories, Inc. Hybrid automatic repeat request (harq) in listen before talk systems
CN106330412A (zh) * 2015-06-25 2017-01-11 联芯科技有限公司 利用harq ack/nack的rlc pdu发送方法及装置
WO2018145787A1 (en) * 2017-02-13 2018-08-16 Telefonaktiebolaget Lm Ericsson (Publ) Technique for monitoring a radio communication

Also Published As

Publication number Publication date
US11973604B2 (en) 2024-04-30
EP3629505A1 (en) 2020-04-01
EP3857759A1 (en) 2021-08-04
JP2022500885A (ja) 2022-01-04
US20210075547A1 (en) 2021-03-11
JP7446247B2 (ja) 2024-03-08
EP3857759B1 (en) 2023-11-01
WO2020064310A1 (en) 2020-04-02

Similar Documents

Publication Publication Date Title
US11973604B2 (en) User equipment and base station involved in transmission of data
US11800395B2 (en) Method, system and device for providing flow control in a split bearer environment
US11432223B2 (en) Methods and apparatuses for selecting a first base station or a second base station to transmit a packet data unit (PDU) to a user equipment (UE)
KR20200013576A (ko) 5g 무선 릴레이를 위한 흐름 제어 방법 및 장치
EP2407001B1 (en) Device-to-device communication
KR101564697B1 (ko) 이동 네트워크들에서 ｔｃｐ 성능을 개선시키기 위한 방법 및 장치
US8503436B2 (en) Method of triggering status report in wireless communication system and receiver
US8339962B2 (en) Limiting RLC window size in the HSDPA flow control
CN114788399B (zh) 增强型多连接通信的缓冲区管理技术
KR20040040710A (ko) 무선 링크 제어 프로토콜에 따르는 수신기에서의 알엘씨데이터 수신 윈도우 처리 방법
US11240703B2 (en) Communications devices, method and mobile communications system
EP3497850B1 (en) Dl harq timing with short tti operations in tdd
US9191870B2 (en) Handover method for reducing the amount of data forwarded to a target node
WO2015127608A1 (en) Method and apparatus for triggering acknowledgement status report in wireless communications system
WO2018029637A1 (en) Dl harq timing in tdd with 1 ms tti and reduced processing time
CN107534890B (zh) 适应性tti调整的方法以及用户设备
CN109314608A (zh) 一种数据传输方法、网络设备及终端设备
US9246637B2 (en) Communication terminal device and method for operating a communication terminal device
TW202226879A (zh) 降低多分支傳輸中封包延遲的方法和裝置
CN114731285B (zh) Pdcp重排序定时器配置方法、装置、终端设备和网络设备
KR20170084579A (ko) 저지연 이동통신 시스템에서의 재전송 방법 및 장치
WO2023061588A1 (en) Radio access retransmission control
CN115209468A (zh) Iab网络中的用户装备第2层缓冲区操作

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