--- a/doc/manual/lte.texi Thu Aug 12 15:58:57 2010 +0200
+++ b/doc/manual/lte.texi Mon Sep 06 10:15:18 2010 +0200
@@ -2,12 +2,23 @@
@chapter LTE Module
@anchor{chap:lte}
-Long Term Evolution (LTE) 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.
+This chapter describes the ns-3 LteNetDevice and related models.
+By adding LteNetDevice objects to ns-3 nodes, one can create models of 3GPP E-UTRAN infrastructure
+and Long Term Evolution (LTE) networks.
+
+Below, we list some more details about what
+ns-3 LTE models cover but, in summary, the most important features
+of the ns-3 model are:
+@itemize @bullet
+@item a standard compliant physical layer and channel model
+@item a Radio Resouce Control (RRC) entity for the LTE net device
+@item a MAC layer for both User Equipment (UE) and evolved Node B (eNB) devices
+@item an efficient Adaptive Modulation and Coding (AMC) scheme for the downlink
+@item an implementation of radio bearer, bearer qos parameters, MAC queue, and Radio Link Control Entity
+@item an outdoor E-UTRAN propagation loss model
+@item Channel Quality Indicator (CQI) management and ideal control messages
+@end itemize
+
@menu
* lte-Model Description::
@@ -31,83 +42,115 @@
@node lte-Design
@subsection Design
-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.
+The LTE model has been developed in order to simulate a downlink transmission over the E-UTRAN network interfacei (composed by two type of nodes: the User Equipment (UE) and evolved Node B (eNB)). To this aim, the definition of standard compliant PHY and MAC models were a crucial rule the module design.
+
+
+The PHY layer, has been developed extending the Spectrum Frameworki [1]. The MAC model, instead, as been developed extending and adding some features to the base class @code{ns3::NetDevice}.
@subsubsection Physical layer
-The PHY layer has been designed as in the follows.
+A @code{ns3::LtePhy} class models the LTE PHY layer.
-All functionalities (send/receive packets to/from the channel; compute the SINR of the received signal etc ...) of the LTE physical layer have been developed into the LteSpectrumPhy class.
-
-In order to implement a FDD channel access, each device uses a couple of LteSpectrumPhy; one for the downlink and one for the uplink.
+Basic functionalities of the PHY layer are: (i) transmit packets coming from the device to the channel; (ii) receive packets from the channel; (ii) evaluate the quality of the channel from the Signal To Noise ratio of the received signal; and (iii) forward received packets to the device.
-For each LTE device the LtePhy object is defined to store both downlink and uplink LteSpectrumPhy elements. Moreover, in LtePhy class are stored other informations about the physical layer (such as list of uplink and downlink sub channels for both UE and eNB and a list of sub channel to use for the uplink for only the UE).
-
-It is important to note that both UE and eNB devices work differently. For this reason, it is necessary to customize all functionalities for each of these devices. To this aim, dedicated classes have been inherited from ones described before. In particular, both UePhy and EnbPhy classes are inherited from the LtePhy to implement the complete physical layer for UE and eNB, respectively. In the same way, UeLteSpectrumPhy and EnbLteSpectrumPhy classes have been inherited from the LteSpectrumPhy in order to implement the functionalities of the physical layer for both UE and eNB respectively.
+Both the PHY and channel have been developed exending @code{ns3::SpectrumPhy} and @code{ns3::SpectrumChannel} classes, respectively.
+
+The module implements an FDD channel access. In FDD channel access, downlink and uplink transmissions work together in the time but using a different set of frequencies.
+Since DL and UL are indipendent between them, the PHY is composed by couple of LteSpectrumPhy object (i.e., implemented into the @code{ns3::LteSpectrumPhy} class); one for the downlink and one for the uplink.
+The LtePhy stores and manages both downlink and uplink LteSpectrumPhy elements.
-How different physical layers can exchange packets through the channel ? The following figure shows this issue.
+In order to customize all physical functionalities for both UE and eNB devices, dedicated classes have been inherited from ones described before. In particular, UePhy and EnbPhy classes, inherited from the LtePhy class, implement the PHY layer for the UE and the eNB, respectively. In the same way, UeLteSpectrumPhy and EnbLteSpectrumPhy classes, inherited from the LteSpectrumPhy, implement the downlink/uplink spectrum channel for the UE and the eNB, respectively.
+
+Fig, @ref{fig:lte-transmission} shows how UE and eNB can exchange packets througth the considered PHY layer.
-
-We note that in the LTE Module there are two channel: the downlink channel and the upplink channel. Both UE and eNB are attached to one of this channels with a proper LteSpectrumPhy object.
+@float Figure,fig:lte-transmission
+@caption{DL and UL transmision on the LTE network}
+@image{figures/lte-transmission,,3in}
+@end float
For the downlink, when the eNB whants to send packets, it calls StartTx function to send them into the downlink channel. Then, the downlink channel delivers the burst of packets to all the UeLteSpectrumPhy attached to it, handling the StartRx function. When the UE receives packets, it executes the follos tasks:
@itemize @bullet
@item compute the SINR for all the sub channel used in the downlink
-@item delives the computed SINRs to the device (these values will be used to obtaine CQI feedbacks)
-@item forward the packet to the device
+@item create and send CQI feedbacks
+@item forward all the received packets to the device
@end itemize
-For the uplink, packets transmission is similar. Furthermore, in this case, only the eNB receives packets sent by an UE.
-
-@subsubsection Mac layer
-
-The UE and the eNB devices have been implemented into the UeNetDevice and EnbNetDevice classed respectively. Both of these class have been inherited from the LteNetDevice which provides a basic implementation for a generic LTE device.
-
-The LTE device has been conceived as a container of several entities such as MAC, RRC, RLC etc .. For each of these entity a dedicated class has been developed.
+The uplink works similary to the previous one.
-For each device are defined the following entity/element
-@itemize @bullet
-@item physical layer
-@item rrc entity
-@item mac entity
-@item rlc entity
-@item ip classifier
-@end itemize
-
-Enqueueing of packets coming from the upper layer and MAC framing
-
-At this moment, in fact, the module is already able to support udp packets transmission between eNB and UE. In other words, it is possible to attach a client/server application to each device.
-
-When a packet arrives to the device, it is enqueued into the MAC queue of the default bearer (the functionalities of the ip classifier will not be implemented during the GSoC).
-
-For the downlink, the eNB manage the MAC framing handling the StartFrame () and StratSubFrame () every 10 ms and 1 ms respectively. At the beginning of each sub frame, it takes the first packet form the default queue and sends it to the physical layer.
@subsubsection Propagation Loss Models
-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:
+A proper propagation loss model has been developed for the LTE E-UTRAN interface [2][3].
+It is used by the PHY layer to compute the loss due to the propagation.
+
+The LTE propagation loss model is composed by 4 different models (shadowing, multipath, penetration loss and path loss) [2]:
@itemize @bullet
@item Pathloss: PL = 128.1 + (37.6 * log10 (R)), where R is the distance between the UE and the eNB in Km.
@item Multipath: Jakes model
@item PenetrationLoss: 10 dB
-@item Shadowing: log-normal distribution (mean=0dB, standard deviation=8dB)
+@item Shadowing: log-normal distribution (mean=0dB, standard deviation=8dB)
@end itemize
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.
+@subsubsection LTE Devices
+
+All the common functionalities of the LTE network devices have been defined into the @code{ns3::LteNetDevice} class. Moreover, the LTE device has been conceived as a container of several entities such as MAC, RRC, RLC etc .. For each of these entity a dedicated class has been developed.
+
+For each device are defined the following entity/element
+@itemize @bullet
+@item the LTE PHY layer (described in the previous sub section)
+@item rrc entity
+@item mac entity
+@item rlc entity
+@end itemize
+
+The module is perfectly integrated into the whole ns-3 project: it is already possible to attach to each device a TCP/IP protocol stack and all the implemented applications (i.e., udp client/server, trace based, etc..).
+
+
+@subsubsection The RRC Entity
+
+The RRC entity manages all active downlink and uplink radio bearer for a given device.
+For each radio bearer, a MAC queue has been developed to store packets coming
+from the upper layer and that whait for the transmission.
+In general, to each flow should be created a dedicated radio bearer. Furthermore, actually only one radio bearer has been created for each device. All packet that arrive from the upper layer, will be enqueued into this default bearer, independently form the aplication whose generated it.
+
+
+@subsubsection The MAC Entity
+Class @code{ns3::MacEntity} provides a basic implementation of the MAC entity for the LTE device. Moreover, @code{ns3::EnbMacEntity} and @code{ns3::UeMacEntity} classes, inherited from the previous one, provides an implementation for the eNB and the UE MAC entity, respectively.
+In all MAC entities is defined the AMC module [4]. Furthermore, into the @code{ns3::EnbMacEntity} class are defined also both uplink and downlink schedulers.
+
+Every time the PHY layer of the UE receives a packet form the channel, it calls the AMC module, define into the MAC entity, in order to convert the SINR of the received signal to CQI feedbacks.
+Every sub frame, the eNB performs both uplink and downlink radio resource allocation. Actually only a simple packet scheduler has been implemented that is able to send, every sub frame, only one packet in the downlink.
+
+
+@subsubsection The RLC Entity
+The RLC entity performs an interface between the MAC layer and the MAC queue for a given bearer. Actually, only the RLC Transport Mode has been implemented.
+
+
@subsubsection 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.
+Using ideal control messages, both UE and eNB can exchange control information without simulating a realistic transmission over the LTE channel.
+
+Two types of control messages have been implemented: the Pdcch Map Ideal Control Message and the Cqi Ideal Control Message. The first one is used by the eNB to send the uplink and downlink resource mapping to all registered UE. In particular, this message carries information about UEs that have been scheduled in the ul/dl, a list of assigned sub channels and the selected MCS for the transmission.
+The second one, instead, is used by the UE to send CQI feedbacks to the eNB.
+
+
@node lte-Scope and Limitations
@subsection Scope and Limitations
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).
+Moreover, actually, only a downlink transmission has been implemented.
+
@node lte-Future Work
@subsection Future Work
+In the future, other features will be implemented, such as packets classification, downlink packet schedulers, uplink packet schedulers, rlc modes, etc..
@node lte-References
@subsection References
@@ -128,10 +171,10 @@
interact with the LTE models is through the helper API and through
the publicly visible attributes of the model.
-The helper API is defined in @code{src/helper/...{cc,h}}.
+The helper API is defined in @code{src/helper/lte-helper{cc,h}}.
The example @code{examples/lte/} contain some basic
-code that shows how to set up the model....
+code that shows how to set up the model in order to simualte an E-UTRAN downlink transmission.
@menu
* lte-Examples::
@@ -145,7 +188,101 @@
@node lte-Examples
@subsection Examples
-@node lte-Helpers
+@code{examples/lte/lte.device.cc} shows how it is possible to set up the LTE module:
+
+@smallformat
+@example
+
+ NodeContainer ueNodes;
+ NodeContainer enbNodes;
+
+ ueNodes.Create (1);
+ enbNodes.Create (1);
+
+ LteHelper lte;
+
+ NetDeviceContainer ueDevs, enbDevs;
+ ueDevs = lte.Install (ueNodes, LteHelper::DEVICE_TYPE_USER_EQUIPMENT);
+ enbDevs = lte.Install (enbNodes, LteHelper::DEVICE_TYPE_ENODEB);
+
+@end example
+@end smallformat
+
+The helper method @code{Install} creates LTE device, the DL, UL physical layer and attach the to proper LTE channels.
+
+
+Moreover, to simulate a complete LTE system, it is necessary to define other information, as expressed in what follows:
+
+(i) install IP protocol stack
+@smallformat
+@example
+ InternetStackHelper stack;
+ stack.Install (ueNodes);
+ stack.Install (enbNodes);
+ Ipv4AddressHelper address;
+ address.SetBase ("10.1.1.0", "255.255.255.0");
+ Ipv4InterfaceContainer UEinterfaces = address.Assign (ueDevs);
+ Ipv4InterfaceContainer ENBinterface = address.Assign (enbDevs);
+@end example
+@end smallformat
+
+
+(ii) register UE to a given eNB
+@smallformat
+@example
+ Ptr<EnbNetDevice> enb = enbDevs.Get (0)->GetObject<EnbNetDevice> ();
+ Ptr<UeNetDevice> ue = ueDevs.Get (i)->GetObject<UeNetDevice> ();
+ lte.RegisterUeToTheEnb (ue, enb);
+@end example
+@end smallformat
+
+
+(ii) create the mobility model for each device
+@smallformat
+@example
+ Ptr<ConstantPositionMobilityModel> enbMobility = new ConstantPositionMobilityModel ();
+ enbMobility->SetPosition (Vector (0.0, 0.0, 0.0));
+ lte.AddMobility (enb->GetPhy (), enbMobility);
+
+ Ptr<ConstantVelocityMobilityModel> ueMobility = new ConstantVelocityMobilityModel ();
+ ueMobility->SetPosition (Vector (30.0, 0.0, 0.0));
+ ueMobility->SetVelocity (Vector (30.0, 0.0, 0.0));
+ lte.AddMobility (ue->GetPhy (), ueMobility);
+@end example
+@end smallformat
+
+
+(iii) define a set of sub channels to use for dl and ul transmission
+@smallformat
+@example
+ std::vector<int> dlSubChannels;
+ for (int i = 0; i < 25; i++)
+ {
+ dlSubChannels.push_back (i);
+ }
+ std::vector<int> ulSubChannels;
+ for (int i = 50; i < 100; i++)
+ {
+ ulSubChannels.push_back (i);
+ }
+
+ enb->GetPhy ()->SetDownlinkSubChannels (dlSubChannels);
+ enb->GetPhy ()->SetUplinkSubChannels (ulSubChannels);
+ ue->GetPhy ()->SetDownlinkSubChannels (dlSubChannels);
+ ue>GetPhy ()->SetUplinkSubChannels (ulSubChannels);
+@end example
+@end smallformat
+
+
+(iv) define a channel realization for the PHY model
+@smallformat
+@example
+lte.AddDownlinkChannelRealization (enbMobility, ueMobility, ue->GetPhy ());
+@end example
+@end smallformat
+
+
+@node Helpers
@subsection Helpers
@node lte-Attributes