LTE 上行调度请求SR0.docxVIP

LTE：上行调度请求（Scheduling?Request，SR） ? (2012-12-27 21:33:51) HYPERLINK javascript:; 转载▼ 标签：? HYPERLINK /?c=blogq=lteby=tag \t _blank lte ? HYPERLINK /?c=blogq=srby=tag \t _blank sr ? HYPERLINK /?c=blogq=schedulingrequestby=tag \t _blank schedulingrequest ? HYPERLINK /?c=blogq=%C9%CF%D0%D0%B5%F7%B6%C8%C7%EB%C7%F3by=tag \t _blank 上行调度请求 分类：? HYPERLINK /s/articlelist_2457665281_1_1.html \t _blank LTE 上行调度请求（Scheduling Request，SR） ??????如果UE没有上行数据要传输，eNodeB并不需要为该UE分配上行资源，否则会造成资源的浪费。因此，?UE需要告诉eNodeB自己是否有上行数据需要传输，以便eNodeB决定是否给UE分配上行资源。为此LTE提供了一个上行调度请求（Scheduling Request，SR）的机制。 ??????UE通过SR告诉eNodeB是否需要上行资源以便用于UL-SCH传输，但并不会告诉eNodeB有多少上行数据需要发送（这是通过BSR上报的）。eNodeB收到SR后，给UE分配多少上行资源取决于eNodeB的实现，通常的做法是至少分配足够UE发送BSR的资源。 ??????eNodeB不知道UE什么时候需要发送上行数据，即不知道UE什么时候会发送SR。因此，eNodeB需要在已经分配的SR资源上检测是否有SR上报。 ??????在载波聚合中，无论配置了多少个上行载波单元（component carrier），都只需要1个SR就够了，毕竟SR的作用只是告诉eNodeB，本UE有上行数据要发送了，你看着给点上行资源吧！由于PUCCH只在PCell上发送，而SR只在PUCCH上发送，也就是说，SR只在PCell上发送。 ??????本文并不介绍SR如何编码并在PUCCH上传输，这会在以后的PUCCH专题中予以介绍。 ??????需要明确的是，只有处于RRC_CONNECTED态且保持上行同步的UE才会发送SR；且SR只能用于请求新传数据（而不是重传数据）的UL-SCH资源。 ??????UE是因为没有上行PUSCH资源才发送SR的，所以UE只能在PUCCH上发送SR。eNodeB可以为每个UE分配一个专用的SR资源用于发送SR。该SR资源是周期性的，每n个子帧出现一次。SR的周期是通过IE：SchedulingRequestConfig的sr-ConfigIndex字段配置的。 ??????由于SR资源是UE专用且由eNodeB分配的，因此SR资源与UE一一对应且eNodeB知道具体的对应关系。也就是说，UE在发送SR信息时，并不需要指定自己的ID（C-RNTI），eNodeB通过SR资源的位置，就知道是哪个UE请求上行资源。SR资源是通过IE：SchedulingRequestConfig的sr-PUCCH-ResourceIndex字段配置的。  SchedulingRequestConfig ::=??????CHOICE { ????release??????????????????????????NULL, ????setup????????????????????????????SEQUENCE { ???????sr-PUCCH-ResourceIndex???????????????INTEGER (0..2047), ???????sr-ConfigIndex???????????????????INTEGER (0..157), ???????dsr-TransMax?????????????????????ENUMERATED { ????????????????????????????????????????????n4, n8, n16, n32, n64, spare3, spare2, spare1} ????} } ? SchedulingRequestConfig-v1020 ::=????SEQUENCE { ????sr-PUCCH-ResourceIndexP1-r10?????INTEGER (0..2047)?????????OPTIONAL???????-- Need OR }  ??????UE在某些情况下可能没有SR资源。场景一