 |
问答管理员：
待解决问题
问题答案 ( 7 条 )
:(肿么没有人回答？？？
问题补充:PUCCH信道有多种格式，看文档发现格式2/2a/2b是每个时隙都有的。。。。而对于格式1/1a/1b，在每个时隙至多有一个RB用于支持此种格式，也就是说格式1/1a/1b不是每个时隙都有的。。。而调度请求采用格式1传输。。。当需要发送SR时，可能存在不具有PUCCH资源的情况，看文档中说：
if the UE has no valid PUCCH resource for SR configured in any TTI: initiate a Random Access procedure (see subclause 5.1) on the PCell and cancel all pending SRs;
请问这个in any TTI怎么理解？是UE尝试发送SR多次，如果不能发送成功，才发起随机接入过程发送SR？还是说在当前TTI，如果没有格式1的PUCCH，就发起随机接入？
求牛人解答～～～小女子不胜感激啊～～～
if the UE has no valid PUCCH resource for SR configured in any TTI: initiate a Random Access procedure (see subclause 5.1) on the PCell and cancel all pending SRs;
请问这个in any TTI怎么理解？是UE尝试发送SR多次，如果不能发送成功，才发起随机接入过程发送SR？还是说在当前TTI，如果没有格式1的PUCCH，就发起随机接入？
求牛人解答～～～小女子不胜感激啊～～～
我的理解是PUCCH的周期独占性是指每一个UE的SR资源是独占的，SR在PUCCH资源的分配是由高层配置的，应该在RRC的连接重配置里，如果UE有数据要发，又没有PUSCH资源发送BSR，就会在自己的SR周期的子帧发送SR。
在PRACH上发SR的情况应该很少，我理解PUCCH资源应该是预留出来的，什么情况下会出现既没有PUSCH又没有PUCCH的情况？有了解这块的同学给解惑一下，多谢。
[color=Red]当需要发送SR时，可能存在不具有PUCCH资源的情况，看文档中说：
if the UE has no valid PUCCH resource for SR configured in any TTI: initiate a Random Access procedure (see subclause 5.1) on the PCell and cancel all pending SRs;
请问这个in any TTI怎么理解？是UE尝试发送SR多次，如果不能发送成功，才发起随机接入过程发送SR？还是说在当前TTI，如果没有格式1的PUCCH，就发起随机接入？
[/color]
--------先回答这个问题。这句话应该是这么理解：如果UE在任意子帧内都没有被分配SR资源（SR只在PUCCH上发送），则使用随机接入过程来代替SR。
SR的作用是请求eNodeB为UE分配上行资源（eNodeB会给UE发送一个UL grant），SR只代表1 bit的信息，即UE是否有数据要发，而无法指定需要发送多少数据，这是通过后续的BSR来指定的。eNodeB通常的做法是，当收到SR后，分配一个足够UE发送BSR的上行资源，以便UE把BSR发送上来。
而随机接入过程中的msg 2，即eNodeB发送的RAR里有UL grant这个字段，这个字段可以为UE分配上行资源。也就是说，即使没有SR资源，UE也可以通过随机接入过程，让eNodeB给其分配资源。
从36.331可以看出，SchedulingRequestConfig是一个UE级的可选的IE（optional），默认为release。如果 eNodeB不给某UE配置SR（这取决于不同厂商的实现），则该UE只能通过随机接入来获取UL grant。是否配置SR主要影响用户面的延迟，并不影响上行传输的功能！
if the UE has no valid PUCCH resource for SR configured in any TTI: initiate a Random Access procedure (see subclause 5.1) on the PCell and cancel all pending SRs;
请问这个in any TTI怎么理解？是UE尝试发送SR多次，如果不能发送成功，才发起随机接入过程发送SR？还是说在当前TTI，如果没有格式1的PUCCH，就发起随机接入？
[/color]
--------先回答这个问题。这句话应该是这么理解：如果UE在任意子帧内都没有被分配SR资源（SR只在PUCCH上发送），则使用随机接入过程来代替SR。
SR的作用是请求eNodeB为UE分配上行资源（eNodeB会给UE发送一个UL grant），SR只代表1 bit的信息，即UE是否有数据要发，而无法指定需要发送多少数据，这是通过后续的BSR来指定的。eNodeB通常的做法是，当收到SR后，分配一个足够UE发送BSR的上行资源，以便UE把BSR发送上来。
而随机接入过程中的msg 2，即eNodeB发送的RAR里有UL grant这个字段，这个字段可以为UE分配上行资源。也就是说，即使没有SR资源，UE也可以通过随机接入过程，让eNodeB给其分配资源。
从36.331可以看出，SchedulingRequestConfig是一个UE级的可选的IE（optional），默认为release。如果 eNodeB不给某UE配置SR（这取决于不同厂商的实现），则该UE只能通过随机接入来获取UL grant。是否配置SR主要影响用户面的延迟，并不影响上行传输的功能！
注意：随机接入过程是[color=Red]替代[/color]SR的功能，而不是说随机接入过程中会发送SR。
而且SR也没有周期可言，eNodeB根本无法知道UE什么时候会有上行数据要发，因此也就无法为其配置周期。
而且SR也没有周期可言，eNodeB根本无法知道UE什么时候会有上行数据要发，因此也就无法为其配置周期。
[color=Red]哪位高人能给解释一下PUCCH资源的周期独占性？用户什么时候获得PUCCH资源?是eNB为其分配的吗?所谓周期性是怎么回事？
[/color]
---------在回答一下这个问题。可以认为PUCCH有3类格式：PUCCH format 1/1a/1b、PUCCH format 2/2a/2b、PUCCH format 3（用于载波聚合）。
PUCCH format 1/1a/1b和PUCCH format 3主要用于发送ACK/NACK和SR的，无周期可言，如果没有下行数据和上行数据要发，根本就不需要发送ACK/NACK和SR，也就不需要所谓的周期性发送。
PUCCH format 2/2a/2b主要是用于发送CQI和ACK/NACK的。这里的CQI是周期性上送的CQI。因此对已PUCCH format 2/2a/2b才有周期性可言。这个资源是通过36.331的CQI-ReportConfig的cqi-PUCCH-ResourceIndex字段来配置的，不同UE配置的值是不同的。
[/color]
---------在回答一下这个问题。可以认为PUCCH有3类格式：PUCCH format 1/1a/1b、PUCCH format 2/2a/2b、PUCCH format 3（用于载波聚合）。
PUCCH format 1/1a/1b和PUCCH format 3主要用于发送ACK/NACK和SR的，无周期可言，如果没有下行数据和上行数据要发，根本就不需要发送ACK/NACK和SR，也就不需要所谓的周期性发送。
PUCCH format 2/2a/2b主要是用于发送CQI和ACK/NACK的。这里的CQI是周期性上送的CQI。因此对已PUCCH format 2/2a/2b才有周期性可言。这个资源是通过36.331的CQI-ReportConfig的cqi-PUCCH-ResourceIndex字段来配置的，不同UE配置的值是不同的。
这里有个地方说法有点问题：虽然何时触发SR是不确定的。但是eNodeB可以为SR分配PUCCH资源（通过sr-PUCCH-ResourceIndex来配置），而这个PUCCH资源在每个SR周期内（通过sr-ConfigIndex来配置）的某个子帧被UE所独占，而周期内的其它子帧，该PUCCH资源是可以被其它UE使用的。
热点问题
