Skip to content
This repository has been archived by the owner on Feb 20, 2024. It is now read-only.

D2D Multicast : MAC receives feedback on an unexisting H-ARQ tx buffer #44

Open
procodemechanics opened this issue Nov 24, 2019 · 1 comment

Comments

@procodemechanics
Copy link

procodemechanics commented Nov 24, 2019

I am running D2D Multicast car simulation for 100 Cars with Alert application. I have assigned 50 cars as AlertSenders and rest as AlertReceivers. I have a highway map of 1 km in length.
When running the simulation, I receive an error for Sender Node which receives a packet from lower layer and raises the below error -

Error: Mac::fromPhy(): Received feedback for an unexisting H-ARQ tx buffer -- in module (LteMacUeRealisticD2D) Highway.car[5].lteNic.mac (id=415), at t=25.051s, event #14073776

Upon going through LteMacBase.cc under the method void LteMacBase::fromPhy(cPacket *pkt), I notice that the above error is arising because there are no more harqTxBuffers to retrieve. See below section of code -

`
{
if (userInfo->getFrameType() == HARQPKT)

{

    // H-ARQ feedback, send it to TX buffer of source

    HarqTxBuffers::iterator htit = harqTxBuffers_.find(src);

    EV << NOW << "Mac::fromPhy: node " << nodeId_ << " Received HARQ Feedback pkt" << endl;

    if (htit == harqTxBuffers_.end())

    {

        // if a feedback arrives, a tx buffer must exists (unless it is an handover scenario where the harq buffer was deleted but feedback was in transit) // this case must be taken care of

       if (binder_->hasUeHandoverTriggered(nodeId_) || binder_->hasUeHandoverTriggered(src))
            return;

        throw cRuntimeError("Mac::fromPhy(): Received feedback for an unexisting H-ARQ tx buffer");

    }
    LteHarqFeedback *hfbpkt = check_and_cast<LteHarqFeedback *>(pkt);

    htit->second->receiveHarqFeedback(hfbpkt);

}`

What could be the reason for H-ARQ buffer to be empty?
I have read research papers talking about how H-ARQ buffer primarily stores MAC PDUs that are being sent and received in HARQ Tx and HARQ Rx buffers respectively. Reception is notified via H-ARQ feedback messages and here this feedback message generates the error.
Why is the H-ARQ Tx buffer for the transmitted MAC PDU by vehicle node 5 deleted before the feedback could arrive? Or was the buffer never filled with this entry?

@procodemechanics
Copy link
Author

procodemechanics commented Nov 25, 2019

Upon running more trials and experimenting with the distribution of number of sender and receiver nodes, the main take away is that increasing the size of packet and the number of vehicles in the simulation results in this error. I also observe the following :

  1. For less dense network of vehicles, the above problem only arises when a lot of senders are grouped together.
    For example, suppose I have 100 cars in the simulation where the Alert packet sent is of size 10 bytes,
    `.car[0..49].udpApp[].typename = "AlertSender"

.car[49..99].udpApp[].typename = "AlertReceiver"`

If the senders are grouped in smaller groups and uniformly distributed amongst the receiver nodes, the error is not encountered. For example,
`.car[0..4].udpApp[].typename = "AlertSender"

.car[5..9].udpApp[].typename = "AlertReceiver"

.car[10..14].udpApp[].typename = "AlertSender"

.car[15..19].udpApp[].typename = "AlertReceiver"

...`

If the Alert packet size is increased to 300 bytes, this above distribution of 50 Senders and 50 Receivers encounters the same error. However, if I reduce the number of senders to 25 and have 75 receivers instead of 50, the simulation works without error.

  1. For highly dense vehicle network, with suppose 400 vehicles, and packet size of 300 bytes, this sender to receiver ratio (as seen in point 1 to be 25:75) needs to drop even further to somewhere about 5:75 to have a proper simulation run.

Why is this behavior observed when the only thing changing is the number of vehicles?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant