Bugzilla – Bug 1057
LTE Bearers issue
Last modified: 2012-05-19 11:08:05 EDT
There is a problem with Bearers differentiation. In the scheduler, all the bearers (either GBR or NGBR) go to Default Bearer section. However, in the scheduler they must be scheduled on their respective sections (defined for loops). Iffat
fix pulled from Giuseppe's repository, pushed as changeset: 8dc11dc385fe
I'm holding out this portion of the changeset related to wimax IpcsClassifierRecord: http://code.nsnam.org/giuseppepiro/lte-for-3_12/diff/7348bb627074/src/wimax/model/ipcs-classifier-record.cc Discussion of this change to wimax is here in item 2) http://mailman.isi.edu/pipermail/ns-developers/2011-March/008769.html The reason that I did not commit it is that it fails the wimax-tlv test. FAIL: Test Suite "wimax-tlv" (0.000) FAIL: Test Suite "Test the CS parameters tlv implementation." (0.000) Details: Message: The classifier address did not match. Condition: !classifier.CheckMatch (Ipv4Address ('10.1.1.1'), Ipv4Address ('16.1.1.1'), 1050, 3050, 17) (actual) == false (limit) Actual: 1 Limit: 0 File: ../src/wimax/test/wimax-tlv-test.cc Line: 118 After patching ipcs-classifier-record.cc, if you run this test as follows: NS_LOG="*" ./waf --run "test-runner --suite=wimax-tlv" You will see: IpcsClassifierRecord:CheckMatchProtocol(): proto check match: pkt=17 cls=17 IpcsClassifierRecord:CheckMatchDstPort(): dst port check match: pkt=3050 cls= [3000 TO 3100] IpcsClassifierRecord:CheckMatchSrcPort(): src port check match: pkt=1050 cls= [1000 TO 1100] IpcsClassifierRecord:CheckMatchDstAddr(): dst addr check match: pkt=16.1.1.1 cls=11.0.0.0/255.0.0.0 IpcsClassifierRecord:CheckMatchDstAddr(): dst addr check match: pkt=16.1.1.1 cls=16.0.0.0/255.0.0.0 IpcsClassifierRecord:CheckMatchDstAddr(): NOT OK! Note that the patch forces a comparison between 16.1.1.1 and 16.0.0.0, whereas the current ns-3-dev code will mask 16.1.1.1 with 255.0.0.0 and compare to 16.0.0.0. I have to assume that the original wimax-tlv-test writer checked that this was the correct behavior (to mask and then compare) so I am reluctant to change this until we can get clarification of this.
With the LENA code merge the scheduler API and implementations have completely changes, hence the bug does not affect any more the lte module. I am reassigning this to the wimax module for the maintainer to check whether the wimax code is still affected by the bug.