In LteSchedulerEnb.h, the use of unsigned int allocatedCws(MacNodeId nodeId) will create an entry for nodeId in the map-type variable allocatedCws_ if this entry doesn’t exist, but this function should only fetch the value, not create one.
This bug doesn't really harm the simulation, because the incorrectly created entry has a mapped value of 0, which is actually true. But still, it's better the modify unsigned int allocatedCws(MacNodeId nodeId), or you will unintentionally create an entry for nodeId.
In void LteMacEnbRealistic::handleSelfMessage() of LteMacEnbRealistic.cc, hit and het are firstly declared and used as harqRxBuffers_'s beginning and ending iterators to cycle through harqRxBuffers_. They are used later for the same purpose, but without reinitiating the value of hit. So the second cycle through harqRxBuffers_ is never executed.
A SERIOUS BUG by tiny mistake. The observed problem is described in https://groups.google.com/forum/#!topic/omnetpp/_Xo0Yofoaao. The cause of the issue is: in unsigned int LteSchedulerEnb::scheduleGrant of LteSchedulerEnb.cc, RLC_HEADER_UM was not added to toServe in the first place, so toServe-MAC_HEADER-RLC_HEADER_UM<vQueueFrontSize is always true, thus the eNB always thought there were 2 bytes left within Ue.
This issue won't manifest if toServe-MAC_HEADER-RLC_HEADER_UM is smaller than 0 because the expression is unsigned int type. This is why you don't observe this problem when you run the original [Config VoIP-UL] in demo.
eNB will schedule for a Ue, even though it knew that Ue reports a 0-sized BSR. I'm not sure if it's a bug or it's intended. But scheduling for 0-buffered Ue is clearly unnecessary.
In unsigned int LteSchedulerEnb::scheduleGrant of LteSchedulerEnb.cc, I think an action of setting active to false for empty conn is needed under "if ((direction == UL || direction == D2D || direction_ == D2D_MULTI) && b == size-1)".
Inconsistency with the standards:
The timing interval between a Grant and Data transmission is 2 ms, but it should be 4 ms, as specified by the standards.
Bugs:
In LteSchedulerEnb.h, the use of unsigned int allocatedCws(MacNodeId nodeId) will create an entry for nodeId in the map-type variable allocatedCws_ if this entry doesn’t exist, but this function should only fetch the value, not create one. This bug doesn't really harm the simulation, because the incorrectly created entry has a mapped value of 0, which is actually true. But still, it's better the modify unsigned int allocatedCws(MacNodeId nodeId), or you will unintentionally create an entry for nodeId.
In void LteMacEnbRealistic::handleSelfMessage() of LteMacEnbRealistic.cc, hit and het are firstly declared and used as harqRxBuffers_'s beginning and ending iterators to cycle through harqRxBuffers_. They are used later for the same purpose, but without reinitiating the value of hit. So the second cycle through harqRxBuffers_ is never executed.
A SERIOUS BUG by tiny mistake. The observed problem is described in https://groups.google.com/forum/#!topic/omnetpp/_Xo0Yofoaao. The cause of the issue is: in unsigned int LteSchedulerEnb::scheduleGrant of LteSchedulerEnb.cc, RLC_HEADER_UM was not added to toServe in the first place, so toServe-MAC_HEADER-RLC_HEADER_UM<vQueueFrontSize is always true, thus the eNB always thought there were 2 bytes left within Ue.
This issue won't manifest if toServe-MAC_HEADER-RLC_HEADER_UM is smaller than 0 because the expression is unsigned int type. This is why you don't observe this problem when you run the original [Config VoIP-UL] in demo.
eNB will schedule for a Ue, even though it knew that Ue reports a 0-sized BSR. I'm not sure if it's a bug or it's intended. But scheduling for 0-buffered Ue is clearly unnecessary.
In unsigned int LteSchedulerEnb::scheduleGrant of LteSchedulerEnb.cc, I think an action of setting active to false for empty conn is needed under "if ((direction == UL || direction == D2D || direction_ == D2D_MULTI) && b == size-1)".
Inconsistency with the standards: