Bugzilla – Bug 2840
Wrong configuration of eNBs and UEs
Last modified: 2018-08-30 10:25:43 EDT
Created attachment 2983 [details] Test Script Hi, It is not possible to configure the attributes per eNBs or UEs. For example, it is not possible to configure the different EARFCN or bandwidth per eNB or UE. The reason for this behaviour is the following code in the function InstallSingleEnbDevice of lteHelper. if (m_componentCarrierPhyParams.size() == 0) { DoComponentCarrierConfigure (dev->GetUlEarfcn (), dev->GetDlEarfcn (), dev->GetUlBandwidth (), dev->GetDlBandwidth ()); } When the first eNB is installed it stores its configuration and uses the same configuration for the rest of eNBs. Similarly, it uses the same map to configure the UEs, thus, the configuration of the UEs also remain static. I am attaching the test script here. I tested this script on ns-3.26 and the behaviour is as expected, i.e., eNBs and UEs are configured properly. Kind regards, Zoraze
Created attachment 2984 [details] patch Hi, Here is the patch to address this bug. The idea is the following, 1. Get rid of "if (m_componentCarrierPhyParams.size() == 0)" condition and we don't store/retrieve the configuration of eNB in/from the m_componentCarrierPhyParams map. Once an eNB is configured we clear this map to configure the next one. 2. For the configuration of UEs, we don't rely on this map any more, instead, if user wants to use CA he/she needs to configure the three new attributes (UeUlCcBandwidth, UeDlCcBandwidth, UeUlCcEarfcn) of lteHelper. LteUeNetDevice already have the attribute DlEarfcn, which could be configured through LteHelper::SetUeDeviceAttribute. If CA is not used these attributes are set to the default values similar to the one used in LteEnbNetDevice. By using this patch eNB and UE configuration is not static any more. The attached example shows that each UE successfully attaches to the correct eNB as per configured downlink EARFCN. For the next step, I would like to test a scenario with CA enabled. Kind regards, Zoraze
Created attachment 3050 [details] Updated Patch Hi, The main problem is that for CA to work the MACs and PHYs of each component carrier must be initialized through LteHelper. eNB configuration is easy to handle because LteEnbNetDevice have all the parameters, however LteUeNetDevice don’t have access to UlEarfcn, UlBandwidth and DlBandwidth. That is why the initial implementation was using m_componentCarrierPhyParams, which stores eNB parameters, to configure UEs aswell. And, we ended up with static configuration of all the eNBs and UEs in the simulation. I am attaching an updated patch to solve this issue. The logic is as follows, 1. Update the condition "if (m_componentCarrierPhyParams.size() == 0)" to "if (m_componentCarrierPhyParams.size() <= m_noOfCcs)". This implies that m_componentCarrierPhyParams map will be used by over writing it for every eNB. For a single eNB this map size would always be equal to the number of component carriers. Thus, if by mistake someone do a insert operation on it and its size exceed, an assert will be hit. 2. For UE configuration we use the same map by over writing it for each UE. The main difference is that for the parameters UlEarfcn, UlBandwidth and DlBandwidth we are using some initial hard coded values. This is needed for the sake of initializing/configuring MACs and PHYs of each component carrier. These values should be updated once the UE is attached to the eNB and receives RRC Connection Reconfiguration message. In case of primary carrier or a single carrier, these values will be updated once the UE will receive SIB2 and MIB. The attached patch also contains a Test to test the following two cases, 1. When CA is enabled and UE carriers configuration is different than the default one, we check that the UE is configured properly once it receives RRC Connection Reconfiguration message from the eNB. 2. A user can configure 2 or more eNBs and UEs with different configuration parameters, i.e, each eNB and UE can have different EARFCN and Bandwidths and a UE connects to an eNB with similar DL EARFCN. Here we check it with CA enabled but the end results will be the same if CA is not enabled and we have more than one eNBs and UEs with different configurations. Kind regards, Zoraze
Patch looks good to me; please remember to patch RELEASE_NOTES and to add a section in the lte-testing.rst documentation to describe the new test. It probably deserves patching also the CHANGES.html to describe new or changed behavior from a user perspective.
Created attachment 3051 [details] Updated Patch with somemodifications
Created attachment 3052 [details] lte-testing.rst patch
Created attachment 3053 [details] Release Notes update patch
Created attachment 3061 [details] Final Patch
Created attachment 3068 [details] Patch for eNB/UE configuration This patch merges previous patches from Zoraze, plus removes useless SetCcPhyParams method in LteHelper
Patch commited in: changeset: 13349:630714cb054c changeset: 13348:898a099b80cb
Hi, for personal matters, I could not follow up the resolution of this bug. I do not agree with the removal of SetCcParams function, because the purpose of this function was to allow configuration of a custom component carrier map, i.e. of an arbitrary number of component carriers where each carrier may have an arbitrary carrier frequency (not limited to equally spaced as is now in the code) and may have different bandwidths. Actually, by using this function it was possible to change the CC configuration at any time in the program so that eNb or UE that are afterward installed would use this custom configuration and not the simple equally spaced configuration that is currently being used. There is also some code related to LAA that needs this function when used with CA, i.e. primary carrier is on a typical LTE earfcn, and secondary carriers are on some of 802.11n frequencies. Also, there is a GSoC 2017 CA patch by A.Krotov that shall be merged to ns-3-dev and is also using in some of the tests this function. Cheers, Biljana