SR (Scheduling Request)

Basic funcationality and mechanism for NR SR is almost same as LTE SR. If you are familiar with LTE SR, it would not be difficult to understand SR in NR and easier to understand NR SR by comparision with LTE SR.

Example 1
Example 2
Example 3

RRC Parameters

What is SR ?

SR stands for Scheduling Request. It is a special uplink control message that UE uses when it needs UL resource but does not have a proper UL grant yet. Putting it other way, SR is a short message from UE to Network, saying "I have something to send to you. Would you send me some grant for me to send the data ?".

SR itself does not carry the actual user data and it does not carry BSR value either. It is just a request for uplink scheduling. After receiving SR, gNB may send an UL Grant by PDCCH, usually DCI Format 0_0 or 0_1. Then UE can transmit the actual MAC PDU, BSR, RRC message or user data on PUSCH using that grant.

So the role of SR can be summarized as follows.

Item	Description
Who sends it ?	UE sends SR to gNB.
Why UE sends it ?	UE has UL data or BSR pending, but does not have suitable PUSCH resource.
Where is it sent ?	SR is sent on PUCCH using an SR resource configured by RRC.
What does it request ?	It requests UL Grant from gNB.
What happens after SR ?	gNB may send UL Grant on PDCCH, and UE can transmit data/BSR on PUSCH.
What SR does not do ?	SR does not carry the actual UL data. It only asks for a grant.

One important point is that SR is not transmitted any time UE wants. RRC configures when and where UE can transmit SR. If UE has pending SR, UE waits for a configured SR occasion and transmits positive SR on the configured PUCCH resource.

When is SR triggered / transmitted ?

There are roughly two different things to think of about SR. One is when SR is triggered and the other is when SR can be transmitted. These two are closely related, but they are not the same thing.

Necessity based case means that UE triggers SR when it has some data to transmit but does not have any proper UL grant from Network. Putting it another way, MAC layer says "I have something to send, but I don't have PUSCH resource for it. Let me ask gNB for UL grant". This is the actual triggering condition of SR in most practical cases.

Periodicity part does not mean that UE triggers and transmits SR periodically regardless of whether it has data or not. What is periodic is SR transmission opportunity. RRC configures periodic PUCCH occasions for SR by periodicityAndOffset. UE can transmit SR only at those configured occasions, but it transmits positive SR there only when SR is already pending. If UE has no data to send and no SR is pending, UE does not send a positive SR just because the periodic occasion comes.

So the overall logic can be summarized as follows. First, UE has UL data or BSR pending. Second, UE does not have any suitable UL grant. Then SR becomes pending. After that, UE waits until a configured SR occasion comes. If all other conditions are OK, UE transmits positive SR on PUCCH. Then gNB may send UL Grant by DCI 0_0 or 0_1, and UE can transmit BSR and/or data on PUSCH.

Following illustration shows overal process for necessity based SR transmission with periodic SR opportunities configured by RRC.

Physical Channel to Carry SR

How UE send SR message ? UE send it on a PUCCH (or on UCI part on PUSCH). Not all PUCCH format can carry the SR. Some PUCCH format can carry SR and some other don't. UE is using a certain PUCCH format depending on situations to send SR. (For the detailed PUCCH format that can carry SR, refer to PUCCH format page).

In NR, PUCCH format 0 or 1 carrySR.

==> 38.213 - 9.2.4 states : A UE can be configured by SchedulingRequestResourceConfig a set of configurations for SR in a PUCCH transmission using either PUCCH format 0 or PUCCH format 1

Who is controlling the SR process ?

Even though SR message itself is a kind of physical layer message, it is controlled by MAC layer process (it is similar to many other physical layer channel are controlled by MAC layer)

Overall SR process (when to send SR) is controlled by MAC layer as illustrated below. (See 38.321 5.4.4 for details)

When SR is not triggered/pre-empted ?

There are some cases where UE does not trigger SR even when it may trigger it otherwise. Followings are the list of those cases where UE does not send SR. These are all based on 38.321-5.4.4)

UE already received UL Grant
SR Opportunity falls into measurement gap period
SR Prohitbit timer is running
SR_COUNTER reaches the sr-TransMax
PUCCH Resources for SR overlaps with the resources of PUSCH
SR Occasion is in the same slot as PUSCH// this is what I checked with a few experts, but I haven't found any explicit statement in 3GPP spec yet. It make sense to me that SR would not be transmitted in the same slot as PUSCH since UE already got the resource to transmit data, but not 100% sure in case of periodic SR. Is UE expected not to send SR at all ? or is still expected to send SR (at least Negative SR) ?

Positive SR vs Negative SR

This is one of the most confusing concept to me regarding 5G SR. At first, I thought negative SR means UE sends some kind of SR signal at every configured SR occasion when it has nothing to send. But this is not the right way to understand it. The clearer way to understand it is as follows.

Positive SR means UE is requesting UL grant. Negative SR means UE is not requesting UL grant.

In the simplest SR-only case, positive SR and negative SR are very different in terms of actual PHY transmission.

Positive SR : UE transmits PUCCH on the configured SR resource. This means "I need UL grant".
Negative SR : UE does not transmit SR on the configured SR resource. This means "I do not need UL grant".

So if there is a configured periodic SR occasion but UE has no pending SR, UE does not transmit a standalone PUCCH just to say "I have nothing to send". In this case, negative SR is more like a logical state, not an actual SR-only transmission.

Then why does the specification talk about negative SR ? The main reason is multiplexing with other UCI. If UE already needs to transmit PUCCH for HARQ-ACK or CSI in the same occasion, the SR state may be considered together with that PUCCH transmission. In that case, positive SR and negative SR can affect which PUCCH resource is used or what bits are appended to the UCI payload.

Putting it another way, the meaning can be summarized as follows.

SR-only occasion + SR pending : positive SR. UE transmits SR on PUCCH.
SR-only occasion + no SR pending : negative SR. UE normally transmits nothing for SR.
HARQ/CSI PUCCH overlaps SR occasion + SR pending : positive SR is multiplexed or represented together with HARQ/CSI according to the PUCCH format and multiplexing rule.
HARQ/CSI PUCCH overlaps SR occasion + no SR pending : negative SR is considered together with the HARQ/CSI PUCCH. UE still may transmit PUCCH, but that PUCCH is for HARQ/CSI, not for requesting UL grant.

As part of learning process, I will put down what is described in 3GPP specification and put my own questions. It will be appreciated if any of you let me learn via email or linkedIn.

38.213-9.2.4 UE procedure for reporting SR

The UE transmits a PUCCH in the PUCCH resource for the corresponding SR configuration only when the UE transmits a positive SR.

==> Does this imply that UE does NOT transmit PUCCH when UE transmit a negative SR ? Does negative SR mean 'No PUCCH / NO SR' ?

For a positive SR transmission using PUCCH format 0, the UE transmits the PUCCH by obtaining m_0 as described for HARQ-ACK information and by setting m_cs = 0. For a positive SR transmission using PUCCH format 1, the UE transmits the PUCCH as described in by setting b (0) = 0

==> Does this imply that there is no specific bit value in UCI dedicated for SR ? SR is encoded as a special case of HARQ Ack/Nack bits ?

38.213 - 9.2.5.1 UE procedure for multiplexing HARQ-ACK or CSI and SR in a PUCCH

If a UE would transmit a PUCCH with positive SR and at most two HARQ-ACK information bits in a resource using PUCCH format 0, the UE transmits the PUCCH in the resource using PUCCH format 0 in PRB(s) for HARQ-ACK information

If the UE would transmit negative SR and a PUCCH with at most two HARQ-ACK information bits in a resource using PUCCH format 0, the UE transmits the PUCCH in the resource using PUCCH format 0 for HARQ-ACK information

==> What is the difference between the two statements ? It sounds same to me.

If a UE would transmit a PUCCH with O_ACK HARQ-ACK information bits in a resource using PUCCH format 2 or PUCCH format 3 or PUCCH format 4 in a slot, ceil[log2(K+1)] bits representing a negative or positive SR, in ascending order of the values of schedulingRequestResourceId and a schedulingRequestResourceId associated with schedulingRequestID-BFR-SCell, are appended to the HARQ-ACK information bits and the UE transmits the combined O_UCI = O_ACK + ceil[log2(K+1)] UCI bits in a PUCCH using a resource with PUCCH format 2 or PUCCH format 3 or PUCCH format 4 that the UE determines. If one of the SRs is a positive LRR, the value of the ceil[log2(K+1)] bits indicates the positive LRR(Link Recovery Request). An allzero value for the ceil[log2(K+1)] bits represents a negative SR value across all SRs.

==> Does this imply that SR can be transmitted via PUCCH format 2,3,4 as well as format 0,1 ? Is it going against the statement 'The UE transmits a PUCCH in the PUCCH resource for the corresponding SR configuration only when the UE transmits a positive SR.' from 38.213-9.2.4 ?

If a UE would transmit a PUCCH with O_CSI report bits in a resource using PUCCH format 2 or PUCCH format 3 or PUCCH format 4 in a slot, ceil[log2(K+1)] bits representing a negative or positive SR, in ascending order of the values of schedulingRequestResourceId and a schedulingRequestResourceId associated with schedulingRequestID-BFR-SCell, are appended to the HARQ-ACK information bits and the UE transmits the combined O_UCI = ceil[log2(K+1)] + O_CSI UCI bits in a PUCCH using a resource with PUCCH format 2 or PUCCH format 3 or PUCCH format 4 that the UE determines. If one of the SRs is a positive LRR(Link Recovery Request), the value of the ceil[log2(K+1)] bits indicates the positive LRR. An allzero value for the ceil[log2(K+1)] bits represents a negative SR value across all SRs.

38,213 - 9 UE procedure for reporting control information :

If a UE would transmit on a serving cell a PUSCH without UL-SCH that overlaps with a PUCCH transmission on a serving cell that includes positive SR information, the UE does not transmit the PUSCH.

==> Does this imply that if aperiodic CSI report occasion and SR occasion overlaps, the aperiodic CSI report should drop ?

My current understanding / interpretation is as follows.

Standalone SR resource : UE transmits PUCCH only for positive SR. If SR is negative, UE does not transmit a standalone SR PUCCH.
PUCCH format 0 or 1 with HARQ-ACK : positive SR may change the PUCCH resource or sequence/cyclic shift behavior. Negative SR means UE does not request UL grant, but UE may still transmit PUCCH for HARQ-ACK.
PUCCH format 2, 3 or 4 with HARQ-ACK/CSI : SR state can be represented by additional UCI bits. In this case, an all-zero SR field represents negative SR across the configured SRs.
Most important point : negative SR does not mean UE sends a separate SR signal just to say "no data". It means "no positive SR request". It becomes visible only when it is multiplexed with another UCI transmission.

Another confusing point is whether there is any special PHY sequence for negative SR. My understanding is No. Negative SR itself does not have a special standalone sequence. For an SR-only occasion, negative SR means UE does not transmit SR PUCCH. For PUCCH format 0 or 1 multiplexed with HARQ-ACK, negative SR means the UE transmits the HARQ-ACK PUCCH without adding a positive SR request. For PUCCH format 2, 3 or 4 multiplexed with HARQ-ACK or CSI, the SR state is represented by ceil(log2(K+1)) UCI bits, and all-zero value represents negative SR across all K SRs. So negative SR is not a special sequence. It is either no SR transmission or an all-zero SR indication field when SR is multiplexed with other UCI.

Chat with an Expert 1

: As mentioned above, I got much clearer understanding than before after chat with PHY/L1 Guru. I think the form of live dialog as quoted below would be better than I am trying to summarize it.

[Q] what would be the definition of negative SR ? 'No SR from UE' ? or 'SR from UE with bit field set to 0' ?

[A] it means "No SR". It is just that in NR, on certain PUCCH format and/or multiplexing rule, the UE sometimes send a SR bit if there is a SR occasion, even if UL Grant is not required

[Q] what do you mean by this "the UE sometimes send a SR bit if there is a SR occasion" ?

UE send SR with bit = 0 ?

[A] yes, but only when SR is not alone

[Q] 'only when SR is not alone' mean 'only the case where SR is scheduled together with other UCI' ?

[A] yes

[Q] What if a periodic SR is scheduled at slot N, No data to send from UE side. No other UCI is scheduled

at slot N... in this case UE should skip SR ? or send Negative SR ?

[A] The UE skips SR. 38.213 - 9.2.4 : The UE transmits a PUCCH in the PUCCH resource for the corresponding SR configuration only when the UE transmits a positive SR.

[Q] I see... but I got confused by other statements from 9.2.5.1

[A] 9.2.5.1 states what happens when you have collision with other resources

-> PUCCH Format 0 : a positive SR changes the cyclic shift values

-> PUCCH Format 1: put the HARQ in the SR resources for positive SR

-> Long PUCCH format: SR bits are appended to the payload

Chat with an Expert 2

This is a nice chat with another expert, Xinya Shen. He kindly reached out to me to help me with the detailed understanding and allowed me to share this discussion with readers. I tried not to summarize anything and share the chat as it is so that you can have a kind of first hand experience with our chat and follow through the thread of chat (thought process) in real context.

[Xingya] In general, the SR resource is called Positive SR when the UE has a demand for SR transmission on the SR resource, and the SR resource is called Negative SR when the UE has no demand for SR transmission on the SR resource.

[Sharetechnote] Assuming this is periodic SR case, Does "the UE has no demand for SR transmission on the SR resource" mean that 'UE has no demand for SR transmission because it already has enough UL grant or no data to transmit' ?

[Xingya] Yes, your understanding is correct.

[38.213-9.2.4] The UE transmits a PUCCH in the PUCCH resource for the corresponding SR configuration only when the UE transmits a positive SR.

[Sharetechnote] Does this imply that UE does NOT transmit PUCCH when UE transmit a negative SR ? Does negative SR mean 'No PUCCH / NO SR' ?

[Xingya] This statement means that the UE transmits PUCCH on the SR resource ("PUCCH resource of the corresponding SR configuration") only if both PUCCH transmission and SR transmission are present.

When the UE does not need to transmit SR but only PUCCH, the UE transmits on the PUCCH resource, at this time, the SR resource is called negative SR

[38.213 - 9.2.5.1] If a UE would transmit a PUCCH with positive SR and at most two HARQ-ACK information bits in a resource using PUCCH format 0, the UE transmits the PUCCH in the resource using PUCCH format 0 in PRB(s) for HARQ-ACK information

[Sharetechnote] What is the difference between the two statements ? It sounds same to me.

[Xingya] The difference between these two statements is the meaning of "resource". In the first statement, the "resource" refers to SR resource, while in the second statement, "resource" refers to PUCCH resource.

[Sharetechnote] Does this imply that SR can be transmitted via PUCCH format 2,3,4 as well as format 0,1 ? Is it going against the statement 'The UE transmits a PUCCH in the PUCCH resource for the corresponding SR configuration only when the UE transmits a positive SR.' from 38.213-9.2.4 ?

[Xingya] Yes. if the SR is transmitted via PUCCH fomat 2,3,4 it should be encoded with the ACK/NACK bits. For format 0, different m_cs value are used to distinguish the cases betwenn PUCCH with positive SR and PUCCH without SR. For PUCCH format 1, PUCCH with positive SR should be transmitted on SR resource.

[38.213 - 9] If a UE would transmit on a serving cell a PUSCH without UL-SCH that overlaps with a PUCCH transmission on a serving cell that includes positive SR information, the UE does not transmit the PUSCH.

[Sharetechnote] Does this imply that if aperiodic CSI report occasion and SR occasion overlaps, the aperiodic CSI report should drop ?

[Xingya] Yes

[Sharetechnote] Sometimes you use 'SR Resources' and 'PUCCH Resources' in different meaning which confuses me a little bit. Since SR is carried by PUCCH, I thought SR Resource is also a type of PUCCH Resource as in following statement The difference between these two statements is the meaning of "resource". In the first statement, the "resource" refers to SR resource, while in the second statement, "resource" refers to PUCCH resource.

When you say SR Resources, does it mean 'a type of PUCCH resource allocated for PUCCH' and when you say PUCCH resources, does it mean the PUCCH resource allocated only for Ack/Nack ?

[Xingya] Yes, your understanding is correct. The SR resource I mentioned refers to a type of PUCCH resource, configured by IE "Resource" in IE "SchedulingRequestResourceConfig", where IE "Resource" is associated to "PUCCH-ResourceId". The PUCCH resource is the resource that carry ACK/NACK.

SR Configurations

Followings are Configurations and Interdependancies among the parameters regarding SR (NOTE : You may need further understandings on pucch-Config. Refer to this note for pucch config details)

The important point is that SR configuration is not defined by a single IE. There is a logical SR configuration, there is an SR transmission resource configuration, and there is a PUCCH resource definition. These are connected by IDs.

schedulingRequestId in SchedulingRequestToAddMod defines one logical SR configuration. This part defines MAC level parameters such as sr-ProhibitTimer and sr-TransMax.
schedulingRequestResourceId in SchedulingRequestResourceConfig identifies one SR resource configuration. This is the configuration for a specific SR occasion/resource.
schedulingRequestID in SchedulingRequestResourceConfig points back to the logical schedulingRequestId. This is the orange arrow in the diagram.
periodicityAndOffset in SchedulingRequestResourceConfig defines when the SR occasion comes, for example every N slots/symbols with a certain offset.
resource in SchedulingRequestResourceConfig points to a PUCCH-ResourceId in pucch-Config/resourceToAddModList. This is the green arrow in the diagram.

So the overall chain is as follows.

SchedulingRequestToAddMod.schedulingRequestId

--> SchedulingRequestResourceConfig.schedulingRequestID

--> SchedulingRequestResourceConfig.periodicityAndOffset and resource

--> pucch-Config.resourceToAddModList.PUCCH-ResourceId

In other words, schedulingRequestId tells which SR logical process this resource belongs to, and resource tells which actual PUCCH resource is used to transmit the SR.

Examples

The examples in this section show how SR configuration in RRC is related to the actual SR transmission in PHY log. The important chain is : logical SR configuration --> SR resource configuration --> PUCCH resource definition --> actual PUCCH carrying positive SR.

Example 1 : Positive SR transmitted on configured PUCCH format 1 resource

This example is based on the UE log. In this case, RRC configures one SR logical configuration with schedulingRequestId 0. Then RRC configures one SR transmission resource with schedulingRequestResourceId 1, links it back to schedulingRequestID 0, sets periodic SR occasions by periodicityAndOffset sl40: 8, and points it to PUCCH-ResourceId 12. Later, UE transmits a positive SR on that PUCCH resource.

The overall summary is as follows.

Item	Value / Log	Meaning
Logical SR	schedulingRequestId 0	Defines the SR process controlled by MAC.
SR resource	schedulingRequestResourceId 1, schedulingRequestID 0, periodicityAndOffset sl40:8, resource 12	Maps SR process 0 to a periodic SR occasion and PUCCH resource 12.
PUCCH resource	PUCCH-ResourceId 12, format 1, PRB 50/0, CS 9, 14 symbols, OCC 2	Defines the actual physical PUCCH resource used for SR.
PHY result	PUCCH: format=1 prb=50 prb2=0 symb=0:14 cs=9 occ=2 sr=1	UE transmits positive SR on the configured PUCCH resource.
After SR	DCI 0_1 UL grant, then PUSCH	gNB provides UL grant and UE uses it to transmit UL data/BSR.

The overall sequence is summarized as follows.

Step	Layer / Channel	Log / Configuration	Meaning for SR
1	RRC / MAC config	schedulingRequestId 0, sr-TransMax n64	Defines the logical SR process controlled by MAC.
2	RRC / PUCCH config	schedulingRequestResourceId 1, schedulingRequestID 0, periodicityAndOffset sl40:8, resource 12	Maps SR process 0 to a periodic SR occasion and PUCCH resource 12.
3	RRC / PUCCH resource	PUCCH-ResourceId 12 = format 1, PRB 50/0, CS 9, OCC 2	Defines the actual physical PUCCH resource used for SR.
4	PHY / PUCCH	PUCCH: format=1 prb=50 prb2=0 symb=0:14 cs=9 occ=2 sr=1	UE transmits positive SR on the configured PUCCH resource.
5	PHY / PDCCH	PDCCH: dci=0_1	gNB sends UL grant after receiving/handling SR.
6	MAC/PHY / PUSCH	MAC UL with SBSR, then PUSCH	UE uses the UL grant to transmit MAC data/BSR on PUSCH.

Step 1 : RRC configures SR logical configuration

The following part configures schedulingRequestId 0. This is the logical SR configuration used by MAC. In this log, sr-TransMax n64 is configured, meaning the maximum number of SR transmissions is n64.

mac-CellGroupConfig {
  schedulingRequestConfig {
    schedulingRequestToAddModList {
      {
        schedulingRequestId 0,
        sr-TransMax n64
      }
    }
  },
  bsr-Config {
    periodicBSR-Timer sf20,
    retxBSR-Timer sf320
  }
}

The logical channel configuration also refers to schedulingRequestID 0. This means this logical channel can use the SR logical configuration with ID 0 when it needs UL resource.

mac-LogicalChannelConfig {
  ul-SpecificParameters {
    priority 1,
    prioritisedBitRate infinity,
    bucketSizeDuration ms5,
    logicalChannelGroup 0,
    schedulingRequestID 0,
    logicalChannelSR-Mask FALSE,
    logicalChannelSR-DelayTimerApplied FALSE
  }
}

Step 2 : RRC configures PUCCH and maps SR to one PUCCH resource

Yes, the PUCCH configuration is essential here. The SR resource does not define PRB/symbol/format by itself. It only has resource 12, and this value points to PUCCH-ResourceId 12 in the same pucch-Config. The following snippet shows both parts together : the actual PUCCH resource definition in resourceToAddModList and the SR mapping in schedulingRequestResourceToAddModList.

pucch-Config setup: {
  resourceToAddModList {
    ...
    {
      pucch-ResourceId 12,
      startingPRB 50,
      intraSlotFrequencyHopping enabled,
      secondHopPRB 0,
      format format1: {
        initialCyclicShift 9,
        nrofSymbols 14,
        startingSymbolIndex 0,
        timeDomainOCC 2
      }
    }
    ...
  },
  format1 setup: {
  },
  schedulingRequestResourceToAddModList {
    {
      schedulingRequestResourceId 1,
      schedulingRequestID 0,
      periodicityAndOffset sl40: 8,
      resource 12  // points to pucch-ResourceId 12 above
    }
  }
}

In this configuration, schedulingRequestResourceId 1 identifies the SR transmission resource. schedulingRequestID 0 links it back to the SR logical configuration in Step 1. periodicityAndOffset sl40: 8 defines the periodic SR occasions. resource 12 selects PUCCH-ResourceId 12, which is PUCCH format 1 using startingPRB 50, secondHopPRB 0, initialCyclicShift 9, nrofSymbols 14, startingSymbolIndex 0 and timeDomainOCC 2.

Step 3 : UE transmits positive SR on the configured PUCCH resource

The following PHY line shows the actual SR transmission. The field sr=1 is the log indication for positive SR. The transmitted PUCCH matches PUCCH-ResourceId 12 configured above : format=1, prb=50, prb2=0, symb=0:14, cs=9 and occ=2.

20:10:28.613 [PHY] UL 0001 00 4628   100.8 PUCCH: format=1 prb=50 prb2=0 symb=0:14 cs=9 occ=2 sr=1 p=-40

Step 4 : gNB sends UL grant and UE transmits PUSCH

After the positive SR, the gNB sends an uplink grant by DCI 0_1. Then UE transmits PUSCH. In this PUSCH, MAC includes SRB1 data and also a Short BSR. This is the expected next step after SR : SR asks for UL grant, and the grant enables UE to send UL MAC/RLC/PDCP data on PUSCH.

20:10:28.618 [PHY] DL 0001 00 4628  100.15 PDCCH: ss_id=2 cce_index=6 al=2 dci=0_1 k2=4
        rb_alloc=0x4b3
        time_domain_rsc=1
        mcs=0
        harq_process=0
        tpc_command=1
        ul_sch_indicator=1
20:10:28.618 [MAC] UL 0001 00 LCID:1 len=36 SBSR:lcg=0 bs=0 SE PHR:ph=63 pc=40 PAD:len=89
        Short BSR:
          LCG ID: 0 Buffer Size: 0 (0)
20:10:28.618 [PHY] UL 0001 00 4628  100.19 PUSCH: harq=0 prb=20:29 symb=0:14 CW0: tb_len=133 mod=2 rv_idx=0 cr=0.12 retx=0 p=-40

Example 2 : Negative SR case

This is an illustrative example using the same SR configuration as Example 1. The point of this example is a little tricky because negative SR does not usually appear as a standalone PHY transmission. If the SR occasion comes but UE has no pending SR, UE normally does not transmit an SR-only PUCCH. So for a standalone negative SR, what we should look for in the log is not a special sr=0 line. We should expect that there is no PUCCH ... sr=1 transmission at that SR occasion.

The same configuration from Example 1 is assumed here.

The overall summary is as follows.

Case	UE behavior	How to read it in log
Standalone positive SR	UE transmits PUCCH with sr=1.	A PUCCH line with sr=1 appears on the configured SR resource.
Standalone negative SR	UE does not transmit SR-only PUCCH.	No special sr=0 line is expected. We just do not see PUCCH ... sr=1 at that SR occasion.
Negative SR with HARQ/CSI	UE may still transmit PUCCH, but for HARQ/CSI, not for SR request.	PUCCH may appear with HARQ/CSI information, but without positive SR indication.
Format 2/3/4 multiplexing	SR state can be represented by UCI bits.	All-zero SR indication bits represent negative SR across configured SRs.

The overall sequence for a standalone negative SR case can be summarized as follows.

Step	Condition / Event	Expected UE behavior	What we expect in log
1	RRC configures SR occasion by periodicityAndOffset sl40:8 and resource 12.	UE knows where/when SR can be transmitted.	RRC shows SchedulingRequestResourceConfig and PUCCH-ResourceId 12.
2	No UL data or BSR is pending, or UE already has a proper UL grant.	SR is not pending.	No MAC indication that SR is triggered.
3	The configured SR occasion arrives.	UE does not transmit standalone SR PUCCH.	No PUCCH line with sr=1 on resource 12.
4	Since there is no positive SR request.	gNB does not need to send an UL grant because of SR.	No SR-triggered DCI 0_0/0_1 is expected.

pucch-Config setup: {
  resourceToAddModList {
    ...
    {
      pucch-ResourceId 12,
      startingPRB 50,
      intraSlotFrequencyHopping enabled,
      secondHopPRB 0,
      format format1: {
        initialCyclicShift 9,
        nrofSymbols 14,
        startingSymbolIndex 0,
        timeDomainOCC 2
      }
    }
    ...
  },
  schedulingRequestResourceToAddModList {
    {
      schedulingRequestResourceId 1,
      schedulingRequestID 0,
      periodicityAndOffset sl40: 8,
      resource 12
    }
  }
}

Case A : SR-only negative SR

For this case, the log does not show a special negative SR sequence. The expected log is basically the absence of a positive SR PUCCH at the SR occasion. In other words, we should not expect a line like this.

// This line is NOT expected for standalone negative SR
// [PHY] UL ... PUCCH: format=1 prb=50 prb2=0 symb=0:14 cs=9 occ=2 sr=1 p=...

So in this case, negative SR means no positive SR transmission. It is not a separate PUCCH signal with a special negative SR sequence.

Case B : Negative SR multiplexed with other UCI

Negative SR becomes visible only when SR state is considered together with another UCI transmission, for example HARQ-ACK or CSI. In that case, UE may still transmit PUCCH, but the PUCCH is transmitted for HARQ-ACK/CSI. The SR part means "no positive SR request".

// Imaginary HARQ-ACK PUCCH overlapping an SR occasion, but SR is not pending
[PHY] UL ... PUCCH: format=1 prb=50 prb2=0 symb=0:14 cs=1 occ=0 ack=1 p=-40
// No sr=1 is shown. The PUCCH is for HARQ-ACK, not for positive SR.

For PUCCH format 2, 3 or 4, the SR state can be represented by additional UCI bits. In that case, an all-zero SR indication field represents negative SR across all configured SRs considered in that slot.

// Imaginary long PUCCH case
O_ACK = HARQ-ACK bits
K = number of SRs considered in the slot
SR indication bits = ceil(log2(K+1))

SR indication bits = all zero  // negative SR across all K SRs
O_UCI = O_ACK + ceil(log2(K+1))

Example 3 : Negative SR considered together with HARQ/CSI PUCCH

This is an illustrative example for the case where HARQ/CSI PUCCH overlaps with an SR occasion, but UE has no pending SR. In this case, UE may still transmit PUCCH because HARQ-ACK or CSI has to be transmitted. But this PUCCH is not a positive SR request. From SR point of view, it is a negative SR case.

The overall summary is as follows.

Item	Condition / Value	Meaning
SR occasion	Configured periodic SR resource exists.	UE has an opportunity to send SR in this slot.
SR state	No SR is pending.	SR is negative. UE is not requesting UL grant.
Other UCI	HARQ-ACK or CSI needs to be transmitted in the same slot.	UE may still transmit PUCCH because of HARQ/CSI.
Format 0/1 behavior	HARQ-ACK PUCCH is transmitted without positive SR indication.	PUCCH is for HARQ-ACK, not for SR request.
Format 2/3/4 behavior	SR indication bits are all zero.	All-zero SR indication represents negative SR.

The overall sequence is summarized as follows.

Step	Condition / Event	Expected UE behavior	Meaning
1	SR occasion comes from SchedulingRequestResourceConfig.	UE checks whether SR is pending.	SR opportunity exists, but this alone does not force transmission.
2	No UL data/BSR pending, or UE already has a proper UL grant.	SR state is negative.	UE does not request UL grant.
3	HARQ-ACK or CSI is scheduled in the same slot.	UE still transmits PUCCH for HARQ-ACK/CSI.	PUCCH exists, but not because of positive SR.
4	SR state is multiplexed/considered with that PUCCH.	Negative SR is represented by no positive SR indication, or by all-zero SR indication bits for long PUCCH.	Negative SR means no UL grant request.

Case A : PUCCH format 0/1 with HARQ-ACK and negative SR

For PUCCH format 0 or 1, if HARQ-ACK is transmitted and SR is negative, UE transmits the PUCCH for HARQ-ACK. There is no separate negative SR sequence. In many logs, you would just see HARQ-ACK PUCCH without sr=1.

// Imaginary example : HARQ-ACK PUCCH overlaps SR occasion, but SR is not pending
[PHY] UL ... PUCCH: format=1 prb=50 prb2=0 symb=0:14 cs=1 occ=0 ack=1 p=-40

// Interpretation
// - PUCCH is transmitted because HARQ-ACK is required.
// - No sr=1 is shown, so this is not a positive SR request.
// - From SR point of view, this corresponds to negative SR.

Case B : PUCCH format 2/3/4 with HARQ-ACK or CSI and negative SR

For PUCCH format 2, 3 or 4, SR state can be represented by additional UCI bits when SR is multiplexed with HARQ-ACK or CSI. If there are K SRs considered in the slot, the SR indication field has ceil(log2(K+1)) bits. An all-zero value represents negative SR across all K SRs.

// Imaginary example : long PUCCH with CSI and negative SR
O_CSI = 7 bits
K = 1 SR considered in this slot
SR indication bits = ceil(log2(1+1)) = 1 bit

SR indication bit = 0  // negative SR
O_UCI = O_CSI + 1 = 8 bits

[PHY] UL ... PUCCH: format=4 prb=49 prb2=1 symb=0:14 occ=0 csi=0xxxxxxx p=-40

// Interpretation
// - PUCCH is transmitted because CSI is required.
// - The SR indication bit is 0, meaning negative SR.
// - UE is not asking for UL grant.

RRC Parameters

SchedulingRequestConfig ::= SEQUENCE {

schedulingRequestToAddModList SEQUENCE (SIZE (1..maxNrofSR-ConfigPerCellGroup)) OF

SchedulingRequestToAddMod OPTIONAL,

schedulingRequestToReleaseList SEQUENCE (SIZE (1..maxNrofSR-ConfigPerCellGroup)) OF

SchedulingRequestId OPTIONAL -- Need N

}

SchedulingRequestToAddMod ::= SEQUENCE {

schedulingRequestId SchedulingRequestId,

sr-ProhibitTimer ENUMERATED {ms1, ms2, ms4, ms8, ms16,

ms32, ms64, ms128}

sr-TransMax ENUMERATED {n4, n8, n16, n32, n64,

spare3, spare2, spare1}

}

schedulingRequestId : Used to modify a SR configuration and to indicate, in LogicalChannelConfig, the SR configuration to which a logical channel is mapped and to indicate, in SchedulingRequestresourceConfig, the SR configuration for which a scheduling request resource is used.

sr-ProhibitTimer : Timer for SR transmission in ms on PUCCH

sr-TransMax : Maximum number of SR transmissions

SchedulingRequestResourceConfig ::= SEQUENCE {

schedulingRequestResourceId SchedulingRequestResourceId,

schedulingRequestID SchedulingRequestId,

periodicityAndOffset CHOICE {

sym2 NULL,

sym6or7 NULL,

sl1 NULL, -- Recurs in every slot

sl2 INTEGER (0..1),

sl4 INTEGER (0..3),

sl5 INTEGER (0..4),

sl8 INTEGER (0..7),

sl10 INTEGER (0..9),

sl16 INTEGER (0..15),

sl20 INTEGER (0..19),

sl40 INTEGER (0..39),

sl80 INTEGER (0..79),

sl160 INTEGER (0..159),

sl320 INTEGER (0..319),

sl640 INTEGER (0..639)

} OPTIONAL, -- Need M

resource PUCCH-ResourceId OPTIONAL -- Need M

}

SchedulingRequestResourceConfig-v1610 ::= SEQUENCE {

phy-PriorityIndex-r16 ENUMERATED {p0, p1} OPTIONAL, -- Need M

...

}

periodicityAndOffset : SR periodicity and offset in number of symbols or slots (see TS 38.213 [13], clause 9.2.4) The following periodicities may be configured depending on the chosen subcarrier spacing:

SCS = 15 kHz: 2sym, 7sym, 1sl, 2sl, 4sl, 5sl, 8sl, 10sl, 16sl, 20sl, 40sl, 80sl

SCS = 30 kHz: 2sym, 7sym, 1sl, 2sl, 4sl, 8sl, 10sl, 16sl, 20sl, 40sl, 80sl, 160sl

SCS = 60 kHz: 2sym, 7sym/6sym, 1sl, 2sl, 4sl, 8sl, 16sl, 20sl, 40sl, 80sl, 160sl, 320sl

SCS = 120 kHz: 2sym, 7sym, 1sl, 2sl, 4sl, 8sl, 16sl, 40sl, 80sl, 160sl, 320sl, 640sl

sym6or7 corresponds to 6 symbols if extended cyclic prefix and a SCS of 60 kHz are configured, otherwise it corresponds to 7 symbols.

For periodicities 2sym, 7sym and sl1 the UE assumes an offset of 0 slots.

phy-PriorityIndex : Indicates whether this scheduling request resource is high or low priority in PHY prioritization / multiplexing handling. Value p0 indicates low priority and value p1 indicates high priority.

(38.213-9.2.4) The UE can be provided, by phy-PriorityIndex in SchedulingRequestResourceConfig, a priority index 0 or a priority index 1 for the SR. If the UE is not provided a priority index for SR, the priority index is 0.

resource : ID of the PUCCH resource in which the UE shall send the scheduling request. The actual PUCCH-Resource is configured in PUCCH-Config of the same UL BWP and serving cell as this SchedulingRequestResourceConfig. The network configures a PUCCH-Resource of PUCCH-format0 or PUCCH-format1

schedulingRequestID : The ID of the SchedulingRequestConfig that uses this scheduling request resource.

LogicalChannelConfig ::= SEQUENCE {

ul-SpecificParameters SEQUENCE {

priority INTEGER (1..16),

prioritisedBitRate ENUMERATED {kBps0, kBps8, kBps16, kBps32,

kBps64, kBps128, kBps256, kBps512,

kBps1024, kBps2048, kBps4096,

kBps8192, kBps16384, kBps32768,

kBps65536, infinity},

bucketSizeDuration ENUMERATED {ms5, ms10, ms20, ms50, ms100, ms150,

ms300, ms500, ms1000,

spare7, spare6, spare5, spare4,

spare3,spare2, spare1},

allowedServingCells SEQUENCE (SIZE (1..maxNrofServingCells-1)) OF

ServCellIndex OPTIONAL,

allowedSCS-List SEQUENCE (SIZE (1..maxSCSs)) OF SubcarrierSpacing

maxPUSCH-Duration ENUMERATED {ms0p02, ms0p04, ms0p0625, ms0p125,

ms0p25, ms0p5, spare2, spare1}

configuredGrantType1Allowed ENUMERATED {true} OPTIONAL,

logicalChannelGroup INTEGER (0..maxLCG-ID) OPTIONAL, -- Need R

schedulingRequestID SchedulingRequestId OPTIONAL, -- Need R

logicalChannelSR-Mask BOOLEAN,

logicalChannelSR-DelayTimerApplied BOOLEAN,

...,

bitRateQueryProhibitTimer ENUMERATED { s0, s0dot4, s0dot8, s1dot6,

s3, s6, s12,s30} OPTIONAL -- Need R

} OPTIONAL, -- Cond UL

...

}

logicalChannelSR-Mask : Controls SR triggering when a configured uplink grant of type1 or type2 is configured. true indicates that SR masking is configured for this logical channel

logicalChannelSR-DelayTimerApplied : Indicates whether to apply the delay timer for SR transmission for this logical channel. Set to false if logicalChannelSR-DelayTimer is not included in BSR-Config.

38.213-9.2.4 UE procedure for reporting SR

38.213 - 9.2.5.1 UE procedure for multiplexing HARQ-ACK or CSI and SR in a PUCCH

38,213 - 9 UE procedure for reporting control information :

Reference