GSOC2010MACPHYforLTE: Difference between revisions

From Nsnam
Jump to navigation Jump to search
Line 204: Line 204:


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 example.
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 example.
Another feature I implemented is the evaluation of the received SINR for the downlink, and the sending of the CQI feedbacs control messages.
In details,
when the UE receives a burst of packet form the eNB, it compute 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 store these information into a UeRecord in order to choose a proper MCS for the future transmission.


== References ==
== References ==

Revision as of 11:57, 19 July 2010

Project Background

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.

Approach

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 [1] 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 [2], 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).

Project Details

Details about the PHY model:

The LTE PHY model is created starting from the Spectrum Framework proposed in [1]. 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 [2], 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 [3]. 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 [4]. 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 [3].


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.

Schedule

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...

Deliverables

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.


MID TERM REPORT: http://www.nsnam.org/wiki/index.php/GSOC2010MACPHYforLTE/MidTermReport

Weekly Reports

Week 1

Student Report

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

Mentor Report

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).


Week 2

Student Report

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:

NetDevice

  • 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;

Physical Layer

  • 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;

Flows Management

  • 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;

MAC

  • 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.

Mentor Report

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.

Week 3

Student Report

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.

Week 4

Student Report

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.


Mentor Report

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

Student Report

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

Student Report

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 loss, 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 example.


Another feature I implemented is the evaluation of the received SINR for the downlink, and the sending of the CQI feedbacs control messages. In details, when the UE receives a burst of packet form the eNB, it compute 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 store these information into a UeRecord in order to choose a proper MCS for the future transmission.

References

[1] N. Baldo and M. Miozzo, Spectrum-aware Channel and PHY layer modeling for ns3, Proceedings of ICST NSTools 2009, Pisa, Italy.

[2] 3GPP TS 25.814 ( http://www.3gpp.org/ftp/specs/html-INFO/25814.htm )

[3] 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 )

[4] 3GPP R1-081483 (available on http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_52b/Docs/R1-081483.zip)