Scheduling request in NrUeMac

[Maria Eduarda Veras Martins]

Hi everyone,

I am studying how the uplink works in NR. My goal is to use a different type of buffer in the RLC, and to do that, I need to understand how the ReportBufferStatus works and its consequences. I found the following section in the NrUeMac documentation:



My biggest challenge is with the last part. I managed to identify the functions responsible for the parts marked in green, pink, and blue. However, I couldn't understand how the PHY sends the message (SR) to the GNB and how it works from there...

P.S. In my logs, there is no call to the DoSchedUlMacCtrlInfoReq function. I saw in the documentation that this function is crucial for updating the LCG in the uplink...

Kind Regards,
Maria.

[Kent Huns]

Hi Maria,

SchedulingRequest is one of the control signals that UE transmits always before uploading its user data(PUSCH).

Based on SR, gNB informs the UE of the time and frequency to transmit PUSCH.

But according to the link below, SR should be sent regularly, even in situations where there is no data to upload.

https://www.sharetechnote.com/html/5G/5G_SR.html#When_is_SR_triggered

(I'm not sure how far this simulator reproduces this feature)

Anyway, the relevant functions are as follows.

■Transmit : nr-ue-mac.cc

void

NrUeMac::DoSlotIndication(const SfnSf& sfn)

{

    if (m_srState == TO_SEND)

    {

        NS_LOG_INFO("Sending SR to PHY in slot " << sfn);

        SendSR();

        m_srState = ACTIVE;

    }

}

void

NrUeMac::SendSR() const

{

    if (m_rnti == 0)

    {

        NS_LOG_INFO("MAC not initialized, SR deferred");

        return;

    }

    // create the SR to send to the gNB

    Ptr<NrSRMessage> msg = Create<NrSRMessage>();

    msg->SetSourceBwp(GetBwpId());

    msg->SetRNTI(m_rnti);

    m_macTxedCtrlMsgsTrace(m_currentSlot, GetCellId(), m_rnti, GetBwpId(), msg);

    m_phySapProvider->SendControlMessage(msg);

}

■Receive : nr-gnb-mac.cc

void

NrGnbMac::DoReceiveControlMessage(Ptr<NrControlMessage> msg)

{

    switch (msg->GetMessageType())

    {

    case (NrControlMessage::SR): {

        // Report it to the CCM. Then he will call the right MAC

        Ptr<NrSRMessage> sr = DynamicCast<NrSRMessage>(msg);

        m_ccmMacSapUser->UlReceiveSr(sr->GetRNTI(), GetBwpId());

        break;

    }

    case (NrControlMessage::DL_CQI): {

    }

    case (NrControlMessage::DL_HARQ): {

    }

Thanks

[Maria Eduarda Veras Martins]

Hi Kent, 
My problem persists, I don't know how to update the UEs in the uplink. I noticed in my simulation that the PHY only sends the SR once and that there is never an active UE in ComputeActiveUE. I don't know where I should modify to update this data...

This problem causes the DoNotifyTxOpportunity to never be called for the uplink, as for the other layers, the UE still does not have data, even though it does.

--
You received this message because you are subscribed to the Google Groups "5G-LENA-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 5g-lena-user...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/5g-lena-users/8b5b5c4d-2ac4-4b68-9eac-8a8e03e42fa3n%40googlegroups.com.

[Kent Huns]

Maybe all UEs don't have their user data packets to upload.

So, check your configuration about packet generation. We once talked about it, but that was downlink at that time.

https://groups.google.com/g/5g-lena-users/c/hboIaJehkA4/m/8LsT2O7BAwAJ

The example of uplink simulation is here.

https://cttc-lena.gitlab.io/nr/html/cttc-nr-notching_8cc.html

Thanks,

[Maria Eduarda Veras Martins]

Hello Kent,

I remember this conversation we had but I believe the problem is not that. The uplink packets arrive at the RLC buffer and are stacked up, but the call to the DoNotifyTxOpportunity function never happens, it's like the scheduling process is not being completed. I am studying more about the DoScheduleUl function in NrSchedulerNs3 to understand this process better... My main doubts so far are how the functions related to the buffer report work, such as BSRReceivedFromUe(), at what point does this function come into play in the uplink?

To view this discussion, visit https://groups.google.com/d/msgid/5g-lena-users/15a0a108-806d-49ec-a345-5a73d56d2457n%40googlegroups.com.

[Kent Huns]

I don't know much about UL scheduling, but it seems a good opportunity for me to learn.

Despite the name, DoScheduleUl() is the last step of UL scheduling process.

It entirely depends on the SR and BSR received immediately before.

So I think it's better to check nr-gnb-mac.cc = the processes that precede DoScheduleUl().

And moreover, the SR/BSR transmission is triggered on UE side before the gnb-MAC process.

After all ... It's hard to predict whether the problem is the UE's transmission or the gNB's reception as you know.

[Maria Eduarda Veras Martins]

Thank you very much, I will study this topic!

To view this discussion, visit https://groups.google.com/d/msgid/5g-lena-users/2595837a-7d3c-4831-99c9-450de1a4bce8n%40googlegroups.com.

[Gabriel Ferreira]

There was an issue with the BSR being lost and things getting stuck. We just merged a fix for this.
It can also get stuck if the number of bytes to send in the buffer is too small.
I'm working on fixes, as this is required by real RRC protocol (which is required to properly test upcoming handover).

UE sends SR
gNB receives SR (NrGnbMac::DoReceiveControlMessage->UlReceiveSr)
gNB informs the scheduler (NrGnbMac::DoSlotUlIndication->SchedUlSrInfoReq)
gNB schedules BSR grant (NrGnbMac::DoSlotUlIndication->SchedUlTriggerReq->NrMacSchedulerNs3::DoSchedUlTriggerReq->ScheduleUl->DoScheduleUl->DoScheduleUlSr)
gNB transmits UL DCI

UE sends BSR (this is where Ana and me were working on bugs)

gNB receives BSR (NrGnbMac::DoReceivePhyPdu->NrGnbMac::ReceiveBsrMessage->NrNoOpComponentCarrierManager::DoUlReceiveMacCe->NrGnbMac::DoReportMacCeToScheduler)
gNB informs scheduler about BSR (NrGnbMac::DoSlotUlIndication->NrMacSchedulerNs3::DoSchedUlMacCtrlInfoReq->BSRReceivedFromUe)
gNB scheduler decides who to give resources (NrGnbMac::DoSlotUlIndication->SchedUlTriggerReq->NrMacSchedulerNs3::DoSchedUlTriggerReq->ScheduleUl->DoScheduleUl)

Then UL DCI indicates to UE how many resources they have, they perform txops to distribute to their LCs and presto!

[Kent Huns]

Thank you for the information, Gabriel! I'll check them.

[Maria Eduarda Veras Martins]

Hi Gabriel!
Thank you for the explanation.

I am trying to implement a new buffer in the RLC that has two queues instead of just one. The issue I am facing is in the "DoScheduleUlSr" function, specifically in the part where it updates the UE's LCG with the 12 bytes. Since I have two queues, I thought about updating each queue with 6 bytes, but when I did that, my simulation returned the error "NS_ASSERT failed, cond="m_dcBit == DATA_PDU". This error has appeared a few times throughout my study, and I am unsure of how to work around it.

If you have any ideas or tips on what I can do to resolve this, it would be greatly appreciated. Thank you in advance.
Best regards,
Maria.

To view this discussion, visit https://groups.google.com/d/msgid/5g-lena-users/f1c0d3c9-8823-4f3e-8eb2-9d584b6318f2n%40googlegroups.com.

[Gabriel Ferreira]

I don't get how does that take sense. If 12 bytes are necessary for each LCG BSR, you are supposed to add 12 bytes per queue, no? 

If you're trying to deserialize 12 bytes, but only transmitted 6 of the actual BSR, you will end up deserializing adjacent memory containing garbage. This neatly explains the assert you got. 

Em sex., 13 de dez. de 2024 18:42, Maria Eduarda Veras Martins <me...@cin.ufpe.br> escreveu:

Hi Gabriel!
Thank you for the explanation.

I am trying to implement a new buffer in the RLC that has two queues instead of just one. The issue I am facing is in the "DoScheduleUlSr" function, specifically in the part where it updates the UE's LCG with the 12 bytes. Since I have two queues, I thought about updating each queue with 6 bytes, but when I did that, my simulation returned the error "NS_ASSERT failed, cond="m_dcBit == DATA_PDU". This error has appeared a few times throughout my study, and I am unsure of how to work around it.

I will be attaching the log file for reference.

If you have any ideas or tips on what I can do to resolve this, it would be greatly appreciated. Thank you in advance.
Best regards,
Maria.

Em qua., 11 de dez. de 2024 às 17:40, Gabriel Ferreira <gabriel...@gmail.com> escreveu:

To view this discussion, visit https://groups.google.com/d/msgid/5g-lena-users/f1c0d3c9-8823-4f3e-8eb2-9d584b6318f2n%40googlegroups.com.