- 1 Project Background
- 2 Approach
- 3 Project Details
- 4 Schedule
- 5 Deliverables
- 6 Weekly Reports
- 7 References
Long Term Evolution represents an emerging and promising technology for providing a broadband ubiquitous Internet access. For this reason, several research groups are working on LTE to provide newer and innovative solutions, able to optimize its performance. The aim of this project is the development of a framework to simulate LTE networks on ns-3, composed by both PHY and MAC models.
The development of the LTE module for ns-3 is composed by two consecutive steps. The first one is the development of the PHY model and the second one is the development of the MAC mode. The module will be implemented into the src/device/lte folder.
Regarding the PHY model, starting from the Nicola's spectrum framework proposed in  will be implemented the following features: (i) a new PHY spectrum for the LTE, (ii) the LTE spectrum model, and (iii) the LTE propagation Loss model. For the PHY model, a couple of half-duplex PHY will be defined, one for the downlink and one for the uplink. In this way it is possible to provide the support for the FDD channel access. The LTE spectrum model will take into the account that the whole LTE bandwidth (20Mhz @ 2GHz) is divided into 100 sub channel of 180 KHz. The the LTE propagation Loss model will be used to obtain the received spectrum spectrum. According to , four models (shadowing, multipath, path loss, and penetration loss) will be chained into a single model. For wath concern the spactrum channel, it will be used the SingleModelSpectrum Channel proposed with the spectrum framework.
Regarding the MAC model, the LTE network devices (eNB and UE) will be implemented. For each device will be defined the following elements: (i) the LTE Spectrum Physical, (ii) the AMC Module, (iii) the Bearer Manager. For the eNB will be defined also the following elements: (i) Downlink Scheduler, (ii) Frame Manager, and (iii) list of registered UE. A bearer class will be implemented to manage one LTE flow between eNB and UE. For each Bearer a MAC queue will be also developed.
The framework is designed to simulate only data transmissions. For the transmission of control messages (such as CQI feedback, PDCCH, etc..) will be used an ideal control channel).
Details about the PHY model:
The LTE PHY model is created starting from the Spectrum Framework proposed in . In particular, to define a LTE spectrum model mean specify the LteSpectrumModel, the LteSpectrumPHY, and the LteSpectrumPropagationLossModel.
The LteSpectrumModel is created in order to define a set of LTE sub channels (100 for 20MHz of bandwidth).
The LtePhy represents the physical layer of a LTE device and it is responsible of the transmission and the reception of packets belonging to the device or coming from the channel. In LtePhy, two LteSpectrumPhy are defined, in order to model at the same time both DL and UL physical layer. All physical elements are attached to the channel. In particular two type of channel , one for the downlink and one for the uplink, will be used.
The LtePropagationLossModel will be developed in order to compute the power of the received signal. The propagation losswill be obtained considering 4 different models (shadowing, multipath, penetration loss and path loss). As proposed in , these models are decribed in the following:
- Pathloss: PL = 128.1 + (37.6 * log10 (R)), where R is the distance between the UE and the eNB in Km.
- Multipath: Jakes model
- PenetrationLoss: 10 dB
- Shadowing: log-normal distribution (mean=0dB, standard deviation=8dB)
Every time that the LteSpectrumPHY::StartRx () function is called, the SpectrumInterferenceModel is used to computed the SINR, as proposed in . Then, the network device uses the AMC module to map the SINR to a proper CQI and to send it to the eNB using the ideal control channel.
Details about the MAC model:
EnbNetDevice and UeNetDevice (that are inherited from the LTENetDevice) classes are created to model both eNB and UE devices. The most important component I inted to develop for both devices are the LTE Spectrum Physical, the AMC Module, and the Bearer Manager. Furthermore, for the eNB will be defined also the following elements: the Downlink Scheduler, the Frame Manager, and a list of registered UE (used to store information about registered UEs and CQI feedbacks received from them). A bearer class will be implemented to manage one LTE flow between eNB and UE. For each Bearer, both MACQueue and QoSParametersSet will be also developed.
In order to support the Adaptive Modulation and Coding scheme, the AmcModule will be implemented. In LTE networks, the UE measures periodically the channel quality and sends a feedback, the CQI, to the eNB. In this project, the SINR will be obtained mathematically every time that the LteSpectrumPhy::StartRx () function is called and for all sub channels. The CQI is obtained using the mapping function defined in . The CQI feedbacks will be "sent" to the eNB, using the ideal control channel. The eNB uses these feedbacks to take scheduling decisions and select a proper MCS (Modulation and Coding Scheme), as proposed in .
Details about the ideal control channel:
Control channel keeps a very important role in LTE networks. In fact, it is responsible of the transmission of several information (i.e., CQI feedback, allocation map, etc...). For this reason, also in a framework oriented to data transmision, it is necesary to find a tecnique for exchange these information. To this aim, an ideal control channel will be developed.
24/5 - 6/6: framework design, including API and doxygen
7/6 - 20/6: development of LteSpectrumPHY, LteSpectrumModel and related test suite
21/6 - 4/7: development of LTE network devices and related test suite
5/7 - 18/7: development of the LteSpectrumPropagationModel
19/7 - 25/7: development of the AMC module and related test suite
26/6 - 8/8: development of Bearer component, MACQueue, Bearer Manager and related test suites
8/8 - 16/8: scrub code, write tests, improve documentation, etc...
For the mid-term evaluations deadline I should deliver to the community all components developed until the 4/7, including framework design. doxigen, developed components and related test suites.
What I have done: Framework design and development of the API.
The most important developed classes are the follows: LteNetDevice, UeNetDevice and EnbNetDevice LtePhy and LteSpectrumPhy AmcModule Bearer, BearerManager and QoSParameter UeRecord and UeManager
Good progress towards the next milestone which is the API definition (due at the end of week 2). We discussed about some API-related issues, such as the class hierarchy and the definition of some methods. In parallel, Giuseppe also did significant progress on the implementation (several .cc files already started with basic functionality in place).
At the end of the second week I finished the API design of the LTE module. In particular I defined methods and variables of the following classes:
- LteNetDevice: models the LTE net device;
- EnbNetDevice: models the eNB net device;
- UeNetDevice: models the UE net device;
- UeManager: manages all UE registered in the target eNB;
- UeRecord: implements the single record managed by the UeManager;
- LtePhy: models the LTE physical layer, composed by both downlink and uplink;
- LteSpectrumPhy: models the downlink and the uplink physical layer;
- LteSpectrumModel: define the Spectrum Model for the LTE;
- LtePropagationLossModel: implements the LTE propagation loss model;
- Bearer: models the one-way data flow between eNB and UE;
- BearerManager: manages all active bearers into the LTE device;
- IpClassifier: classifies packets into a proper bearer
- QosParameters: set of QoS parameters associated to a particular bearer;
- MacQueue: models a MAC queue for each bearer;
- RlcEntity: models the RLC entiry for each MAC queue;
- AmcModule: implements the AMC module;
- PacketScheduler: implements a basic implementation of the MAC packet scheduler;
Furthermore, several methods have been already implemented. The code, available under my repository, compiles without any errors.
The API proposed at the end of Week 1 is functional, but the class architecture and naming departs a little bit from the LTE standard. After discussion with the student, it is agreed to modify the class architecture according to the following principles:
- there will be classes that correspond to the main LTE entities, in particular the RRC, the RLC, the MAC and the PHY
- the LteNetDevice class will act more as a container for those entities, rather than implementing particular functionalities
Furthermore, several minor issues in the code base (mostly about coding style) were pointed out and fixed.
During the third week, I have modified the module architecture, according to the discussion effectued with my mentor.
I also started the development of the LTE physical layer.
At the end of the 4-th week I finished the implementation of the LTE physical layer, as proposed in the preliminary work plain.
The class LtePhy provides a basic implementation of the LTE physical layer. Futhermore, some methods have been custom for both eNB and UE devices in the EnbLtePhy and UeLtePhy classes, respectively.
Each physical layer maintains two LteSpectrumPhy, one for the downlink and one for the uplink. Both of them are developed in order to implement packets transmission/reception.
According to the spectrum framework, the LTE spectrum model and several methods that manage both transmitted signal and noise power spectral density (PSD) have been designed.
So far, the module is able to implement the transmission of packets in the downlink and in the uplink, and to evaluate the SINR measured by the UE in the downlink. Simple examples have been developed in the example/lte folder. Moreover, a test suite for LTE physical layer has been also implemented.
In weeks 3 and 4 the LTE Spectrum Model and Phy have been developed, in accordance with the original schedule. Some aspects of the recently developed code need to be revised a bit (in particular there are some concerns regarding the difference in the SpectrumModel for the uplink and the downlink), but however the overall status of the project is good.
Weeks 5 and 6
In these weeks I have implemented several features for both eNB and UE network devices. Now, it is possible to
(i) create eNB and UE network device;
(ii) create a proper physical layer for each of these devices;
(iii) define a list of sub channels to use in downlink and in uplink;
(iv) send packet from eNB to the UE and viceversa. For example in example/lte/lte-device.cc has been implemented an udp-client-server application between eNB and UE.
Now I'm starting the development of test suite, in order to present a complete code for the mid-term evaluation.
Weeks 7 and 8
In these weeks a propagation loss model for the downlink has been developed. This model is use to compute the loss of the transmitted signal due to the propagation. To this aim, the LtePropagationLossModel class has been properly implemented.
For each couple of eNB and UE, a dedicated ChannelRealizzation object is created and stored into the LtePropagationLossModel class. As described int section Project Details, the channel realizzation considers 4 different model: path losss, multipath, shadowing, and penetration loss models. These models are used to compute the loss of the transmitted signal.
A test suite for propagation loss model has been created into the lte-propagation-loss-model-test.cc file. Moreover, to analyze how the model works, it is recommended to run lte-channel-model as an example.
Another feature I implemented is the evaluation of the received SINR for the downlink, and the sending of the CQI feedbacks control messages. In details, when the UE receives a burst of packet form the eNB, it computes the SINR for each sub channel used for the transmission. Then, the UE use the AMC module, part of the MAC entity, to map each SINR to a proper CQI value. An ideal control message, containing a list of computed CQIs is sent to the eNB. The eNB stores these informations into a UeRecord in order to choose a proper MCS for the future transmission.
In this week the follows features have been implemented :
- the AMC module
- the SINR evaluation at the UE
- the creation of CQI feedbacks
- the ideal send of these feedbacks (they are sent at the MAC layer from the UE to the eNB)
- the ideal reception of these feedbacks at the eNB
- the simple schedule
- the creation and the transmission of the ideal PDCCH allocation map message
In details, when a UE receives a signal form the downlink channel, it computes the SINR for all sub-channel used for the downlink transmission. Then, its use the AMC module to compute a list of CQI (Channel Quality Indicator) feedbacks, that will be sent to the eNB using the ideal control channel.
When the eNB receives a CqiIdealControlMessage, it stores the CQI informations into a proper UeRecord, associated to the UE which have sent a feedback.
At the beginning of each Sub-Frame, only a simple downlink packet scheduler is executed. It works into the eNB at the MAC layer. This scheduler worsk as follows:
(i) it selects the first packet to transmit form the MAC queue;
(ii) it looks the destination UE and creates for them a PDCCH allocation map;
(iii) into the PdcchMapIdealControlMessage are stored a list of sub-channels used for the transmission and the selected MCS (modulation and coding scheme) for each sub-channel.
(iv) the eNB uses the AMC module to map the CQI feedback into a proper MCS.
(v) finally, the MAC layer sends the PdcchMapIdealControlMessage using an indeal control channel and start the packet transmission.
During this week, I have also modified several part of the code, according to Nicola.s reviews.
 N. Baldo and M. Miozzo, Spectrum-aware Channel and PHY layer modeling for ns3, Proceedings of ICST NSTools 2009, Pisa, Italy.
 3GPP TS 25.814 ( http://www.3gpp.org/ftp/specs/html-INFO/25814.htm )
 Giuseppe Piro, Luigi Alfredo Grieco, Gennaro Boggia, and Pietro Camarda", A Two-level Scheduling Algorithm for QoS Support in the Downlink of LTE Cellular Networks", Proc. of European Wireless, EW2010, Lucca, Italy, Apr., 2010 ( draft version is available on http://telematics.poliba.it/index.php?option=com_jombib&task=showbib&id=330 )
 3GPP R1-081483 (available on http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_52b/Docs/R1-081483.zip)