一种用于用户设备UE的无线通信方法，包括：从基站接收数据传输；

将所述数据传输存储在所述UE的应用处理器AP的存储器中；

由所述UE的所述AP至少部分地基于调制解调器缓冲区的大小来识别上行链路许可；

由所述AP至少部分地基于所识别的上行链路许可来确定是否向所述调制解调器发送数据；以及当所识别的上行链路许可超过阈值时由所述AP发送所述数据。

基于提供的对比文件分析，没有对比文件毫无疑义的公开或等同公开或实质公开了技术特征D。

以下是详细的分析：

技术特征D的内容：
“由所述UE的所述AP至少部分地基于调制解调器缓冲区的大小来识别上行链路许可”

结合权利要求1的上下文理解：
根据权利要求1的整体逻辑（特别是特征E“由所述AP至少部分地基于所识别的上行链路许可来确定是否向所述调制解调器发送数据”），技术特征D中的“上行链路许可”并非传统意义上基站发送给UE用于空中接口传输的调度许可（Network Uplink Grant），而是指UE内部应用处理器（AP）与调制解调器（Modem）之间的一种流控机制。即，AP根据调制解调器缓冲区（Modem Buffer）的大小，确定AP被允许向调制解调器发送多少数据（即“上行链路许可”）。说明书（例如[0101]-[0103]段）也印证了这一点，指出流控消息可能包含供第二层（AP）向第一层（Modem）发送数据的“上行链路许可”。

对比文件分析：

1. 对比文件1 (US11856447B2)

   • 公开内容： 涉及IAB节点（集成接入和回传节点）的缓冲区状态报告（BSR）。它讨论了如何计算包含RLC层和适配层数据量的BSR并发送给网络。

   • 差异： 该文件关注的是UE/IAB节点向网络报告缓冲区状态以申请空中接口资源，完全不涉及UE内部AP与Modem之间的流控，更没有公开AP根据Modem缓冲区大小来识别用于AP向Modem发数据的“上行链路许可”。

2. 对比文件2 (US2012127930A1)

   • 公开内容： 涉及随机接入过程（RACH）。UE接收基站的随机接入响应（包含上行链路许可），并判断该许可是否足以清空UE的数据缓冲区。

   • 差异： 这里的“上行链路许可”是基站发出的空中接口许可。虽然涉及基于缓冲区大小的判断（判断许可是否足够），但这是为了决定是否在Msg3中发送所有数据给基站，而不是AP为了决定是否向调制解调器发送数据。该文件未公开AP层级的内部流控机制。

3. 对比文件3 (US2015215738A1)

   • 公开内容： 涉及车辆上的数据通信，特别是利用多个链路（绑定链路）进行通信。涉及云端服务器与车载服务器之间的链路管理。

   • 差异： 主要关注链路聚合和外部网络通信，未涉及UE内部AP根据Modem缓冲区大小识别许可的技术特征。

4. 对比文件4 (US2015271809A1)

   • 公开内容： 涉及逻辑信道到传输信道的映射和优先级处理（LCP），以及载波聚合下的数据分发。

   • 差异： 这是MAC层（通常位于Modem内）的处理逻辑，未涉及AP层如何基于Modem缓冲区大小来获取向Modem发送数据的许可。

5. 对比文件5 (US2016050686A1)

   • 公开内容： 涉及多SIM卡设备的发射机冲突管理。处理器通过发送虚假增加的BSR来诱导网络发送多个上行链路许可，从而选择不会与其他SIM卡冲突的许可进行传输。

   • 差异：

     • 虽然涉及“基于缓冲区大小”（生成BSR）和“识别上行链路许可”（从网络接收并筛选），但其逻辑是：Modem/处理器向网络报告BSR -> 网络分配空中接口许可 -> 处理器筛选这些许可用于发送数据到网络。

     • 这与特征D的逻辑完全不同。特征D是AP监测Modem缓冲区大小 -> AP识别出内部传输许可 -> AP发送数据到Modem。对比文件5没有公开这种UE内部基于Modem缓冲区状态的AP流控机制。

结论：
所有对比文件均关注UE与网络之间的通信（获取网络调度、报告状态、链路管理），没有一份文件公开了UE内部应用处理器（AP）基于调制解调器缓冲区大小来识别用于内部数据传输的“上行链路许可”这一技术手段。因此，技术特征D未被公开。

基于提供的对比文件分析，没有任何对比文件的组合可以公开技术特征D。

以下是详细的组合分析与理由：

1. 技术特征D的核心逻辑回顾

技术特征D：“由所述UE的所述AP至少部分地基于调制解调器缓冲区的大小来识别上行链路许可”。

结合权利要求1的整体方案（AP向Modem发送数据），该特征描述的是一种UE内部的流控机制：

• 主体： 应用处理器（AP）。

• 依据： 调制解调器（Modem）的缓冲区大小。

• 结果： 识别出一个“上行链路许可”（即AP被允许向Modem发送的数据量）。

• 目的： 控制AP向Modem的数据输送速率，防止溢出或优化内存。

2. 对比文件的技术领域与“上行链路许可”定义的根本差异

所有提供的对比文件（1-5）虽然都涉及“缓冲区”、“数据传输”和“许可（Grant）”，但它们处于完全不同的通信层级：

• 对比文件1-5中的“上行链路许可”： 均指**网络侧（基站）**通过空中接口下发给UE的调度指令（Network Uplink Grant），用于指示UE可以在何时、以何种频率资源向基站发送数据。

• 技术特征D中的“上行链路许可”： 特指UE内部生成的、用于协调AP与Modem之间数据流动的许可。

3. 具体组合分析

即使尝试将对比文件进行组合，也无法得出特征D的技术方案：

组合尝试 A：对比文件5（处理器管理冲突）+ 对比文件2（基于许可判断缓冲区）

• 对比文件5 (US2016050686A1)：公开了处理器（可以视为AP）为了避免双卡冲突，可能会操纵BSR（缓冲区状态报告）来从网络获取多个“上行链路许可”，然后选择一个合适的许可用于发送数据。

  • 缺失点： 这里的许可来源是网络，AP只是在筛选网络给的许可，而不是基于Modem缓冲区大小“识别/生成”一个内部许可。

• 对比文件2 (US2012127930A1)：公开了UE判断收到的网络许可大小是否足以清空缓冲区。

  • 缺失点： 这仍然是针对网络许可的判断，且是为了决定是否结束RACH过程。

• 组合结果： 即使组合这两者，得到的方案是“AP通过欺骗网络获取更多空中接口许可，并判断该许可是否满足发送需求”。这依然是UE-网络层面的交互。并没有公开“AP监测Modem缓冲区 -> AP据此确定向Modem发多少数据”这一AP-Modem层面的内部流控逻辑。

组合尝试 B：对比文件4（MAC层处理）+ 公知常识

• 对比文件4 (US2015271809A1)：涉及MAC层（通常在Modem内）如何处理数据。

• 分析： 即使结合公知常识（如通用的流控机制XON/XOFF），通用的流控通常是“缓冲区满则停止发送”，而不是特征D所述的特定机制——“基于缓冲区大小来识别一个具体的上行链路许可（Grant）”。特征D暗示了一种基于信用的流控（Credit-based flow control）或类似机制，将“许可”这一概念引入到了内部总线通信中。对比文件均未通过教导这种将空中接口概念（许可）内化为芯片间通信机制的方案。

4. 结论

不存在可以公开技术特征D的对比文件组合。

主要原因在于：

1. 方向性错误： 所有对比文件都在解决“如何让数据从UE发出去（到基站）”的问题，而技术特征D解决的是“如何让数据从AP传到Modem（在UE内部）”的问题。

2. 概念不重合： 对比文件中的“Grant”必须由基站分配；本申请特征D中的“Grant”是由AP基于Modem状态识别出的内部传输权限。这是两个完全不同的技术手段。

因此，技术特征D具有新颖性，且在现有对比文件范围内，通过组合也无法显而易见地得到，具有创造性支持。

基于提供的对比文件分析，没有对比文件毫无疑义的公开或等同公开或实质公开了技术特征D。

以下是详细分析：

1. 技术特征D的理解

技术特征D：“由所述UE的所述AP至少部分地基于调制解调器缓冲区的大小来识别上行链路许可；”

• 执行主体：UE的应用处理器（AP）。

• 动作：识别“上行链路许可”。

• 依据：至少部分地基于“调制解调器缓冲区的大小”。

• 结合权利要求1整体语境：权利要求1描述的是UE内部AP与Modem之间的交互。特征B是接收基站数据，特征C是AP存储数据，特征D和E是AP决定是否向Modem发数据，特征F是AP发送数据。因此，这里的“上行链路许可”并非通常意义上基站发给UE的空中接口调度许可（Network Uplink Grant），而是指UE内部的一种流控机制或许可，用于控制AP向Modem发送数据的速率或时机，以避免Modem缓冲区溢出或欠载。说明书（例如段落[0007]-[0010]）也印证了这一点，指出这是一种改进的内部流控方法。

2. 对比文件分析

• 对比文件1 (US2017310433A1)

  • 内容：涉及3GPP LTE/NR中的调度请求（SR）、缓冲区状态报告（BSR）和功率余量报告（PHR）机制。主要讨论UE如何向基站报告缓冲区状态（BSR）以获取空中接口的上行链路许可（UL Grant），特别是针对不同类型的逻辑信道和无线资源类型的映射限制。

  • 分析：该文件中的“上行链路许可”是指基站发给UE的空中资源调度。虽然涉及“缓冲区状态”，但它是用于触发向基站发送BSR，而非用于AP内部识别向Modem发送数据的许可。该文件未涉及UE内部AP与Modem之间的流控。

• 对比文件2 (US2018279173A1)

  • 内容：涉及PDCP PDU的路由，特别是在分离承载（Split Bearer）场景下。描述了移动设备检测分离承载配置，并在RLC/MAC层路由PDU。

  • 分析：该文件关注的是多连接场景下的数据路由，不涉及AP基于Modem缓冲区大小来识别内部传输许可的技术方案。

• 对比文件3 (US2019182896A1)

  • 内容：涉及NR系统中的URLLC调度请求处理。讨论了TCP拥塞控制优化，提到“紧耦合无线感知TCP拥塞控制”。其中图5和相关描述（段落[0138]-[0144]）提到UE Modem向基站发送IP缓冲区状态报告，基站基于此确定传输块大小（TBS）并在上行许可中发送给UE，UE Modem再向IP层（可能位于AP）请求对应大小的数据。

  • 分析：虽然涉及AP（IP层）与Modem的交互，但其逻辑是：Modem收到基站的空中接口许可（包含TBS） -> Modem向AP请求数据。这里的“许可”源自基站，且AP发送数据的依据是Modem转发的基站指令，而非AP主动监测Modem缓冲区大小来“识别”一个内部许可。这与特征D中AP基于Modem缓冲区大小自主识别许可的机制不同。

• 对比文件4 (US7406546B1)

  • 内容：涉及一种长距离同步总线，使用基于信用的流控机制（Credit-based Flow Control）。发送单元（Sender）维护一个信用计数器，接收单元（Receiver）释放信用，发送单元仅在有信用时发送数据。

  • 分析：虽然这是一种基于接收端缓冲区状态（通过信用反映）的流控机制，但它属于通用的硬件总线通信技术。它没有公开特定的“AP”和“调制解调器”场景，也没有涉及“识别上行链路许可”这一特定概念（虽然Credit类似许可，但技术领域和具体实现有差异）。更重要的是，它无法与无线通信中的“上行链路许可”这一特定术语及其在权利要求1语境下的特定含义（AP与Modem间的流控）直接对应或显而易见地结合。

• 对比文件5 (WO2017193274A1)

  • 内容：与对比文件3内容高度相似（实际上对比文件3可能是其同族或后续申请），讨论无线感知的TCP拥塞控制。

  • 分析：结论同对比文件3。

3. 结论

• 没有公开：没有任何一份对比文件公开了“由UE的AP至少部分地基于调制解调器缓冲区的大小来识别上行链路许可”这一特征。

• 实质差异：现有技术（如对比文件1、3、5）中的“上行链路许可”通常指基站发出的空中接口调度，或者（如对比文件3/5）虽然涉及AP与Modem交互，但逻辑是Modem请求AP发送数据（基于基站的许可），而非AP基于Modem缓冲区状态自主识别许可。对比文件4虽有流控，但属于通用总线技术，未涉及本申请特定的AP-Modem架构及基于此的许可识别机制。

因此，没有对比文件毫无疑义的公开或等同公开或实质公开了技术特征D。

基于提供的对比文件分析，没有对比文件毫无疑义的公开或等同公开或实质公开了技术特征E。

以下是详细的分析：

技术特征E的内容：
“由所述AP至少部分地基于所识别的上行链路许可来确定是否向所述调制解调器发送数据；”

结合权利要求1的上下文理解：
这一特征描述了UE内部应用处理器（AP）与调制解调器（Modem）之间的交互逻辑。AP首先基于Modem缓冲区状态识别出一个内部的“上行链路许可”（特征D），然后依据这个许可来决策是否向Modem推送数据。这是一种UE内部的流控机制，目的是防止Modem缓冲区溢出或优化数据传输效率。

对比文件分析：

1. 对比文件1 (US11856447B2)

   • 公开内容： 涉及IAB节点向网络报告缓冲区状态（BSR）。它关注的是如何计算包含RLC层和适配层数据量的BSR并发送给网络，以获取网络的调度许可。

   • 差异： 该文件未涉及UE内部AP与Modem之间的流控决策，即未公开AP基于内部许可决定是否向Modem发送数据的机制。

2. 对比文件2 (US2012127930A1)

   • 公开内容： 涉及随机接入过程（RACH）。UE接收基站的随机接入响应（Msg2，包含上行链路许可），并判断该许可是否足以清空UE的数据缓冲区，从而决定是否在Msg3中发送所有数据并结束RACH过程。

   • 差异：

     • 这里的“上行链路许可”来自基站。

     • 决策主体是UE整体（相对于基站），决策内容是“是否在Msg3中发送所有数据给基站”以及“是否继续RACH过程”。

     • 这与特征E中“AP基于内部许可决定是否向Modem发送数据”属于完全不同的层级和逻辑。

3. 对比文件3 (US2015215738A1)

   • 公开内容： 涉及车载数据通信的链路聚合（Bonding）。讨论了根据链路特性（如带宽、成本）动态分配数据到不同的链路。

   • 差异： 虽然涉及数据发送决策，但其依据是外部链路的质量和策略，而非Modem缓冲区的状态或AP识别出的内部许可。未涉及AP-Modem间的特定流控逻辑。

4. 对比文件4 (US2015271809A1)

   • 公开内容： 涉及MAC层的逻辑信道优先级（LCP）处理和载波聚合下的数据分发。

   • 差异： 这是MAC层（通常位于Modem内）将数据映射到传输信道的过程。它处理的是已经到达MAC层的数据如何分发到不同的小区（Cell），而不是AP层决定是否将数据发送给MAC/Modem层。

5. 对比文件5 (US2016050686A1)

   • 公开内容： 涉及多SIM卡设备的发射机冲突管理。处理器通过发送虚假BSR获取多个网络许可，然后判断即将进行的传输是否会与其他SIM卡的传输冲突，从而决定是否使用某个许可发送数据到网络。

   • 差异：

     • 决策依据不同： 对比文件5是基于“是否与另一SIM卡传输冲突”来决定是否发送；特征E是基于“所识别的上行链路许可（基于Modem缓冲区大小）”来决定。

     • 决策对象不同： 对比文件5决定的是是否向网络发送数据；特征E决定的是是否向调制解调器发送数据。

     • 许可来源不同： 对比文件5的许可是基站发的；特征E的许可是AP基于缓冲区状态识别的内部许可。

结论：
所有对比文件均未公开应用处理器（AP）基于调制解调器缓冲区状态所识别出的内部许可，来决定是否向调制解调器发送数据这一特定的内部流控机制。因此，技术特征E未被公开。

基于提供的对比文件分析，没有对比文件毫无疑义的公开或等同公开或实质公开了技术特征E。

以下是详细的分析：

技术特征E的内容：
“由所述AP至少部分地基于所识别的上行链路许可来确定是否向所述调制解调器发送数据”

结合权利要求1的上下文理解：
这一特征是紧接在特征D（由AP基于Modem缓冲区大小识别上行链路许可）之后的步骤。它描述了UE内部应用处理器（AP）与调制解调器（Modem）之间的一种流控决策机制。即，AP根据内部识别出的“上行链路许可”（代表Modem可接收数据的能力），来决定此刻是否应该向Modem的数据缓冲区写入数据。如果许可足够（特征F提及的超过阈值），则发送；否则可能暂停或缓存。这是一种防止Modem内部缓冲区溢出的主动管理机制。

对比文件分析：

1. 对比文件1 (US2017156157A1)

   • 公开内容： 涉及网络侧（eNodeB）对调度请求（SR）的自适应检测。通过调整检测阈值来减少误检SR导致的不必要上行授权（Grant）发送。

   • 差异：

     • 主体不同： 该文件关注的是网络侧（基站）的行为，以及UE对基站授权的响应（发送数据或填充包）。

     • “许可”含义不同： 这里的Grant是基站发给UE的空中接口调度许可。

     • 决策内容不同： 未涉及UE内部AP根据Modem状态决定是否向Modem发数据的逻辑。

2. 对比文件2 (US2017310433A1)

   • 公开内容： 涉及UE向基站发送调度请求（SR）和缓冲区状态报告（BSR）的机制，特别是针对不同无线资源类型（如授权/非授权频谱）的路由限制。

   • 差异：

     • 重点在于UE如何向基站报告缓冲区状态以获取空中资源。

     • 没有涉及AP与Modem之间的内部数据传输决策。UE的MAC层（通常在Modem中）决定是否触发SR/BSR，而不是AP层决定是否向MAC层发数据。

3. 对比文件3 (US2018279173A1)

   • 公开内容： 涉及PDCP PDU的路由，特别是在分离承载（Split Bearer）场景下，UE在收到上行许可前将部分PDCP PDU预路由到RLC/MAC层进行预处理。

   • 差异：

     • 虽然涉及数据从上层（PDCP）到下层（RLC/MAC）的流动，但其主要目的是为了在收到基站Grant时能快速传输（预处理）。

     • 并没有公开“AP基于Modem缓冲区大小识别出一个许可，并据此决定是否发送”这一特定的流控逻辑。它的逻辑是基于“数据分割阈值”和“路由阈值”来决定预处理多少数据，这是一种基于数据量的策略，而非基于动态“识别出的许可”的反馈控制。

4. 对比文件4 (US2019182896A1)

   • 公开内容： 涉及URLLC的调度请求处理，以及无线感知的TCP拥塞控制。其中提到UE Modem向基站发送IP缓冲区状态，基站基于此计算传输块大小（TBS）并在上行许可中发回，Modem再据此向IP层请求数据。

   • 差异：

     • 这里的逻辑是：Modem收到基站的Grant（包含TBS） -> Modem向IP层（可能在AP）请求数据。

     • 因果关系不同： 特征E是AP自主识别（基于Modem缓冲区）许可 -> AP决定发送。对比文件4是基站给许可 -> Modem通知AP -> AP发送。对比文件4的“许可”源头是基站，且是Modem“拉取”数据，而非AP基于缓冲区状态“推送”决策。

5. 对比文件5 (US7406546B1)

   • 公开内容： 涉及一种长距离同步总线的流控机制。发送单元（Sender）维护一个信用计数器（Credit Counter），接收单元（Receiver）释放信用，发送单元仅在有信用时发送数据。

   • 分析：

     • 这是一种基于信用的硬件流控机制。如果将AP视为Sender，Modem视为Receiver，逻辑上有相似之处（Sender基于Receiver的Credit决定是否发送）。

     • 但是：

       • 技术领域差异： 这是一个通用的总线硬件电路设计，非特定于无线通信UE的AP-Modem架构。

       • 术语差异： 它使用的是“Credit”，而本申请使用的是“Uplink Grant”（上行链路许可）。在无线通信领域，“上行链路许可”通常特指基站给的调度。本申请独特地将这一概念内化用于AP-Modem流控。

       • 结合困难： 即使认为功能相似，对比文件5并未公开“由AP识别上行链路许可”这一特定步骤（它是硬件计数器逻辑），也未结合无线通信的特定背景（如Modem缓冲区）。

       • 显而易见性： 将通用的总线流控（对比文件5）应用到UE内部AP-Modem接口，并将其中的流控信号命名为“上行链路许可”，并非毫无疑义的公开，也存在非显而易见的创造性步骤（重新定义了无线术语在内部接口的用途）。

结论：

所有对比文件均未公开“由AP至少部分地基于所识别的上行链路许可来确定是否向调制解调器发送数据”这一具体的技术特征。

• 对比文件1-4关注的是UE与基站间的交互或Modem内部的MAC/RLC层处理。

• 对比文件4虽有AP-Modem交互，但方向和控制逻辑（Modem基于基站指令请求AP数据）与本申请（AP基于Modem缓冲区主动决策）相反。

• 对比文件5属于通用总线技术，未涉及本申请特定的无线通信设备内部架构及术语定义。

因此，没有对比文件毫无疑义的公开或等同公开或实质公开了技术特征E。

基于提供的对比文件分析，没有对比文件毫无疑义的公开或等同公开或实质公开了技术特征E。

以下是详细的分析：

技术特征E的内容：
“由所述AP至少部分地基于所识别的上行链路许可来确定是否向所述调制解调器发送数据；”

结合权利要求1的上下文理解：
这一特征描述了UE内部应用处理器（AP）与调制解调器（Modem）之间的一种流控决策机制。AP首先基于Modem缓冲区状态识别出一个内部的“上行链路许可”（特征D），然后依据这个许可来决策是否向Modem推送数据。这是一种UE内部的流控机制，目的是防止Modem缓冲区溢出或优化数据传输效率。

对比文件分析：

1. 对比文件1 (WO2017193274A1)

   • 公开内容： 涉及一种无线感知的TCP拥塞控制优化方法。具体来说，它公开了一种“请求-授予”（request-grant）机制来替代传统的TCP拥塞控制。

     • UE的Modem将IP缓冲区状态报告（BSR）发送给基站。

     • 基站基于BSR、信道状态等确定传输块大小（TBS），并通过上行链路许可（Uplink Grant）发送给UE Modem。

     • UE Modem收到许可后，向IP层（可能位于AP中）发送包含TBS的数据请求。

     • IP层根据请求，从IP缓冲区检索对应大小的数据发送给Modem。

   • 差异分析：

     • 决策主体与方向不同： 对比文件1中，是Modem收到基站许可后，主动向AP（IP层）请求数据（Pull模式）；而技术特征E描述的是AP基于识别出的许可，确定是否发送数据给Modem（Push模式的决策）。

     • “许可”的来源与性质不同： 对比文件1中的许可是基站发出的空中接口许可，AP（IP层）发送数据是响应Modem的请求；而技术特征E中的许可是AP基于Modem缓冲区状态自主识别的内部许可（参考特征D），AP据此自主决策是否发送。

     • 未公开特征E的核心逻辑： 对比文件1没有公开AP主动监测Modem缓冲区并据此生成内部许可来控制发送的逻辑，而是公开了基于基站调度指令的被动响应机制。

结论：
虽然对比文件1涉及AP（IP层）向Modem发送数据的控制，但其控制逻辑（基于Modem的请求，源于基站调度）与本申请权利要求1的技术特征E（AP基于自主识别的内部许可决定发送）存在实质性差异。因此，对比文件1并未毫无疑义地公开或等同公开技术特征E。

由于我无法直接访问或搜索实时的 3GPP 规范数据库、非专利文献数据库或最新的专利数据库，我的分析仅基于我训练数据中包含的知识（截止到 2025 年 1 月），且仅基于您提供的对比文件进行分析。

基于您提供的对比文件 1-5，结合对 3GPP 规范（如 3GPP TS 36.321, 38.321 等）的通常理解，分析如下：

1. 3GPP 规范的常规内容 vs. 权利要求技术特征

• 技术特征 A、B (UE 接收基站数据): 这是 3GPP 规范（如 LTE/NR PHY/MAC 层协议）的基础功能，毫无疑问是公知的。

• 技术特征 C (数据存储在 AP 存储器): 这是 UE 内部架构实现的范畴，虽然 3GPP 规范主要定义空口行为，不详细规定 UE 内部 AP 与 Modem 的具体存储实现，但这属于本领域的常规设计选择。

• 技术特征 D (AP 基于 Modem 缓冲区大小识别上行链路许可):

  • 3GPP 规范： 通常定义 UE 作为一个整体向网络报告 BSR (Buffer Status Report)，以及 UE 接收网络的 UL Grant (上行授权)。规范不涉及 AP 如何“识别”一个内部的“上行链路许可”来控制向 Modem 的数据流。

  • 差异： 权利要求中的“上行链路许可”在特征 D 和 E 的语境下，明显是指 UE 内部 AP 到 Modem 的流控许可。3GPP 规范不涉及这种芯片间的私有流控协议。

• 技术特征 E (AP 基于识别的许可确定是否向 Modem 发送数据):

  • 3GPP 规范： 规范关注的是数据到达 MAC 层后，如何根据逻辑信道优先级 (LCP) 映射到传输信道并发送给基站。规范不规定 AP 何时将数据推送到 Modem/MAC 层。

  • 差异： 这是 UE 内部实现的专有流控逻辑，不在 3GPP 标准化范围内。

• 技术特征 F (许可超过阈值时 AP 发送数据):

  • 3GPP 规范： 无此规定。

  • 差异： 同上，这是内部流控的具体策略。

2. 3GPP 规范作为现有技术的考量

虽然 3GPP 规范是无线通信领域最核心的现有技术，但本申请权利要求 1 保护的方案侧重于 UE 内部的应用处理器 (AP) 与调制解调器 (Modem) 之间的数据交互与流控机制。

• 结论： 3GPP 规范（如 TS 36.321, TS 38.321, TS 38.300 等）并未公开技术特征 D、E 和 F 所描述的特定内部流控机制。3GPP 规范主要定义网络与 UE 之间的空口行为（Peer-to-Peer 协议），而将 UE 内部的实现细节（如 AP 与 Modem 的交互）留给厂商自行实现。

总结：

基于现有信息，3GPP 规范并未公开权利要求 1 的核心技术特征（特别是特征 D、E、F）。这些特征涉及 UE 内部 AP 与 Modem 之间的特定流控方法，属于设备内部实现细节，而非标准化的空口协议内容。

如权利要求1所述的方法，其中，识别所述上行链路许可包括从所述调制解调器接收上行链路许可。

如权利要求1所述的方法，其中，识别所述上行链路许可包括由所述AP确定上行链路许可。

如权利要求1所述的方法，其中，所述数据包括与数据传输相关联的传输控制协议TCP数据或TCP确认ACK反馈。

如权利要求1所述的方法，其中，所述数据包括传输控制协议TCP确认ACK反馈、蜂窝车联网C‑V2X数据、虚拟现实VR数据、扩展现实XR数据、超可靠低延迟通信ULLC数据或任何特定的业务类型/模式。

如权利要求1所述的方法，其中，为了确定是否从所述AP向所述调制解调器发送数据，所述AP被配置为：至少基于所述调制解调器缓冲区的一个或多个阈值来管理从所述AP到所述调制解调器的数据流量。

如权利要求1所述的方法，其中，所述数据包括与由所述调制解调器识别的指定应用相对应的任何所识别的应用数据。

如权利要求1所述的方法，其中，当所识别的上行链路许可为0时，由所述AP发送所述数据。

一种用于在用户设备UE处进行无线通信的装置，包括：存储器；以及

至少一个处理器，其耦合到所述存储器并被配置为：从基站接收数据传输；

将所述数据传输存储在所述UE的应用处理器AP的存储器中；

由所述UE的所述AP至少部分地基于调制解调器缓冲区的大小来识别上行链路许可；

由所述AP至少部分地基于所识别的上行链路许可来确定是否向所述调制解调器发送数据；以及当所识别的上行链路许可超过阈值时由所述AP发送所述数据。

如权利要求9所述的装置，其中，为了识别所述上行链路许可，所述至少一个处理器被配置为从所述调制解调器接收上行链路许可。

如权利要求9所述的装置，其中，为了识别所述上行链路许可，所述至少一个处理器被配置为确定上行链路许可。

如权利要求9所述的装置，其中，所述数据包括与所述数据传输相关联的传输控制协议TCP数据或TCP确认ACK反馈。

如权利要求9所述的装置，其中，所述数据包括传输控制协议TCP确认ACK反馈、蜂窝车联网C‑V2X数据、虚拟现实VR数据、扩展现实XR数据、超可靠低延迟通信ULLC数据或任何特定的业务类型/模式。

如权利要求9所述的装置，其中，为了确定是否从所述AP向所述调制解调器发送数据，所述至少一个处理器被配置为：至少基于所述调制解调器缓冲区的一个或多个阈值来管理从所述AP到所述调制解调器的数据流量。

如权利要求9所述的装置，其中，所述数据包括与由所述调制解调器识别的指定应用相对应的任何所识别的应用数据。

如权利要求9所述的装置，其中，当所识别的上行链路许可为0时，由所述AP发送所述数据。

一种用于在用户设备UE处进行无线通信的装置，包括：用于从基站接收数据传输的部件；

用于将所述数据传输存储在所述UE的应用处理器AP的存储器中的部件；

用于由所述UE的所述AP至少部分地基于调制解调器缓冲区的大小来识别上行链路许可的部件；

用于由所述AP至少部分地基于所识别的上行链路许可来确定是否向所述调制解调器发送数据的部件；以及用于当所识别的上行链路许可超过阈值时由所述AP发送所述数据的部件。

如权利要求17所述的装置，其中，所述用于识别所述上行链路许可的部件被配置为从所述调制解调器接收上行链路许可。

如权利要求17所述的装置，其中，识别所述上行链路许可包括由所述AP确定上行链路许可。

如权利要求17所述的装置，其中，所述数据包括与所述数据传输相关联的传输控制协议TCP数据或TCP确认ACK反馈。

如权利要求17所述的装置，其中，所述数据包括传输控制协议TCP确认ACK反馈、蜂窝车联网C‑V2X数据、虚拟现实VR数据、扩展现实XR数据、超可靠低延迟通信ULLC数据或任何特定的业务类型/模式。

如权利要求17所述的装置，其中，用于确定是否从所述AP向所述调制解调器发送数据的部件被配置为：至少基于所述调制解调器缓冲区的一个或多个阈值来管理从所述AP到所述调制解调器的数据流量。

如权利要求17所述的装置，其中，所述数据包括与由所述调制解调器识别的指定应用相对应的任何所识别的应用数据。

一种存储计算机可执行代码的计算机可读介质，所述代码在被处理器执行时使所述处理器：从基站接收数据传输；

将所述数据传输存储在用户设备UE的应用处理器AP的存储器中；

由所述UE的所述AP至少部分地基于调制解调器缓冲区的大小来识别上行链路许可；

由所述AP至少部分地基于所识别的上行链路许可来确定是否向所述调制解调器发送数据；以及当所识别的上行链路许可超过阈值时由所述AP发送所述数据。

如权利要求24所述的计算机可读介质，其中，为了识别所述上行链路许可，所述处理器被配置为从所述调制解调器接收上行链路许可。

如权利要求24所述的计算机可读介质，其中，为了识别所述上行链路许可，所述处理器被配置为确定上行链路许可。

如权利要求24所述的计算机可读介质，其中，所述数据包括与所述数据传输相关联的传输控制协议TCP数据或TCP确认ACK反馈。

如权利要求24所述的计算机可读介质，其中，所述数据包括传输控制协议TCP确认ACK反馈、蜂窝车联网C‑V2X数据、虚拟现实VR数据、扩展现实XR数据、超可靠低延迟通信ULLC数据或任何特定的业务类型/模式。

如权利要求24所述的计算机可读介质，其中，为了确定是否从所述AP向所述调制解调器发送数据，所述处理器被配置为：至少基于所述调制解调器缓冲区的一个或多个阈值来管理从所述AP到所述调制解调器的数据流量。

如权利要求24所述的计算机可读介质，其中，所述数据包括与由所述调制解调器识别的指定应用相对应的任何所识别的应用数据。