5G上行调度内容是什么？
首先需要明确的是，数据信道中数据传输的持续时间可以在调度数据传输的PDCCH中进行半静态配置或动态指示。在层2上，负责调度的是MAC层。
MAC实体为什么需要TTI持续时间/numerology的信息？这个问题与NR中LCP的设计更相关，NR中LCP与LTE的区别在于，逻辑信道可以映射到一个或多个不同的numerology/TTI持续时间。因此，为了确定哪些逻辑信道被允许分配具有特定numerology/TTI持续时间的资源，MAC实体需要知道numerology/TT1持续时间。对于下行链路，MAC实体可以通过实现从PHY知道numerology/TTI持续时间。然而，对于上行链路，它应该通过指示从网络获得。对于以下讨论，我们关注上行链路，即UE中的MAC实体如何从gNB获得numerology/TTI持续时间。
在LTE中，为了调度上行链路传输，UE从DCI获得上行链路许可，其中MAC实体可以从PHY获得HARQ信息。NR也可以这么做，并且HARQ信息应至少包括NDI、TBS、RV和HARQ process ID。如果在HARQ信息中添加额外的信令，例如，与PUSCH上当前HARQ传输的numerology/TTI持续时间相关的信令，应该没有问题。但我们真的需要在DCI中添加这个额外的信令吗？
根据我们的理解，对于从网络到UE的numerology/TTI指示，应至少有两种选择：
选项1：它可以是RRC信令的隐式指示，UE可以从其他信息隐式地获得当前HARQ传输的numerology/TTI持续时间。例如，每个分量载波的一个或多个BWP配置可以半静态地用信号通知给UE。需要注意的是，BWP的配置可能包括numerology。因此，基于每个UE配置的BWP，MAC实体可以获得numerology。
选项2：它也可以是DCI中的显式指示，例如，信令可以是所述HARQ信息的一部分。除了当前商定的信息之外，可以在HARQ信息中添加额外的信令。额外信令与当前上行链路授权资源的numerology/TTI持续时间相关。在HARQ信息中，指示TTI持续时间而不是numerology。某一numerology可以对应于一个或多个TTI持续时间，例如，在当前LTE 15KHz numerology中，它不仅包含1ms TTI，还包含mini-slot TTI。如果由于某些原因需要显示numerology，则该指数应包含在与特定numerology相对应的DCI中。然而，除了TTI持续时间之外，很难说numerology本身有什么好处。需要对DCI中的信令细节进行更多调查。
事实上，可能还有另一种选择，即显式和隐式指示的组合。考虑到隐式指示不灵活且效率低的分析，DCI中的显式指示可根据具体情况设计。例如，对于资源和numerology，DCI中的显式指示默认为关闭，在这种情况下，如果存在显式指示，则UE将从映射获得numerology/TTI持续时间，否则从DCI信令获得。此外，对于HARQ process ID和numerology映射，UE从HARQ信息中的HARQ进程标识获得numerology/TTI持续时间，否则从DCI中的显式指示（如果存在的话）获得。这种组合设计可以提高灵活性，DCI中的开销相对较低。
SPS是从Release8开始为LTE引入的。RRC至少配置了SPS周期，但提供给UE的SPS的频率资源、MCS等取决于PHY。动态授权的UL skipping应该是可配置的。从UE功耗的角度来看，如果UE总是能够在空缓冲区期间跳过UL发送，即没有RRC UL skipping配置，则这是简单且有帮助的。如果UE在空缓冲器期间总是可以跳过UL发送，则不需要PDCCH激活和隐式无授权资源释放。
与LTE一样，SPS UL的DRX行为应该是在传输UL数据时重新启动不活动计时器，而不是在未使用SPS UL授权时重新启动。这种行为取决于DRX设计的结果。
然而，基于LTE MAC规范，drx-InactivityTimer的启动或重新启动仅取决于PDCCH指示，这与PDSCH/PUSCH发送有关。因为drx-InactivityTimer的动机应该是基于PDCCH的新数据调度来延长活动时间，所以希望将drx-InctivityTimer保留为LTE drx功能。
TS 36.321
- if the PDCCH indicates a new transmission (DL, UL or SL):
- except for NB-IoT, start or restart drx-InactivityTimer.
HARQ RTT定时器和DRX重传定时器与重传有关，SPS UL的DRX行为应是在传输UL数据时重新启动HARQ RTT/DRX重定时器，而在未使用SPS UL授权时不重新启动。这种行为也取决于DRX设计的结果。
基于竞争的传输通常会带来不确定性。至少确定了两个failure案例。在case A中，gNB未能对来自UE的数据进行解码，但仍然可以识别已发送数据的UE。在Case B中，由于基于竞争的资源分配，gNB通常无法检测特定共享资源块的UE身份。应当研究gNB知道和不知道UE身份的这两种情况。对于case A，gNB可以通过专用授权来调度UE，对于case B，RACH过程应该在N次失败之后被触发。
