Difference between revisions of "User:Lcarl"
| Line 1: | Line 1: | ||
== LENA-MBMS Project == | == LENA-MBMS Project == | ||
The purpose of the project LENA-MBMS is to implement the MBMS framework within LENA.<br />A simple example is in <tt>src/lte/examples/lte-simple-epc-mbms.cc</tt> in the repositories.You can download the repository from [[link repositories]] | The purpose of the project LENA-MBMS is to implement the MBMS framework within LENA.<br />A simple example is in <tt>src/lte/examples/lte-simple-epc-mbms.cc</tt> in the repositories.You can download the repository from [[link repositories]] | ||
| − | === | + | |
| + | === Overview === | ||
In order to simulate the multicast traffic the following changes have been introduced within the simulator.The initialization of the MBMS is carried out thanks to the function <code>ActivateEpsBearerMbms</code>; this function creates a MBMS bearer and the information related to that stream is propagated to the eNodeB and UEs of the MBMS Area through <tt>MbmsAreaConfiguration</tt> message.<br />In this first release we suppose the BM-SC integrated within the class <code>EpcSgwPgwApplication</code>; when a multicast packet is received from TUN device is directly sent to <code>EpcMbmsGwApplication</code> class. Actually <code>EpcMbmsGwApplication</code> only sends multicast streams to the eNodeB belonging to the MBMS area through M1 interface.<br />Within the class <code>LteEnbRrc</code> each flow is handled by the <code>MbmsManager</code> class; at MAC layer multicast and unicast packets are placed in two different buffers. There are two implementations of the method <tt>SchedDlTriggerReq</tt>: the first for the management of unicast traffic, the latter for the management of multicast traffic.The scheduler allocates the MBMS traffic within the subframe defined in the standard (1,2,3,6,7,8). The MCS used in transmission and the number of subframe used for MBMS traffic is currently fixed and passed as a ''GetTypeId'' parameter.<br />Actually the MBMS signalling is not implemented completely; to overcome this issue and to inform the UEs they're going to receive a MBMS packet we use the DCI message. On the receiver side, UE checks the information contained within the DCI message with those of received TB; if they are equal, the UE send the TB to the upper levels.<br />The multicast streams are distinct from those of unicast through the use of M-RNTI (Multicast-Radio Network Temporary Identifier).<br />The statistics of multicast traffic are collected through a modified version of the <code>FlowMonitor</code> class, called <code>MbmsStatsCalculator</code>. This class calculates average throughput, delay, jitter and dropping for multicast traffic. | In order to simulate the multicast traffic the following changes have been introduced within the simulator.The initialization of the MBMS is carried out thanks to the function <code>ActivateEpsBearerMbms</code>; this function creates a MBMS bearer and the information related to that stream is propagated to the eNodeB and UEs of the MBMS Area through <tt>MbmsAreaConfiguration</tt> message.<br />In this first release we suppose the BM-SC integrated within the class <code>EpcSgwPgwApplication</code>; when a multicast packet is received from TUN device is directly sent to <code>EpcMbmsGwApplication</code> class. Actually <code>EpcMbmsGwApplication</code> only sends multicast streams to the eNodeB belonging to the MBMS area through M1 interface.<br />Within the class <code>LteEnbRrc</code> each flow is handled by the <code>MbmsManager</code> class; at MAC layer multicast and unicast packets are placed in two different buffers. There are two implementations of the method <tt>SchedDlTriggerReq</tt>: the first for the management of unicast traffic, the latter for the management of multicast traffic.The scheduler allocates the MBMS traffic within the subframe defined in the standard (1,2,3,6,7,8). The MCS used in transmission and the number of subframe used for MBMS traffic is currently fixed and passed as a ''GetTypeId'' parameter.<br />Actually the MBMS signalling is not implemented completely; to overcome this issue and to inform the UEs they're going to receive a MBMS packet we use the DCI message. On the receiver side, UE checks the information contained within the DCI message with those of received TB; if they are equal, the UE send the TB to the upper levels.<br />The multicast streams are distinct from those of unicast through the use of M-RNTI (Multicast-Radio Network Temporary Identifier).<br />The statistics of multicast traffic are collected through a modified version of the <code>FlowMonitor</code> class, called <code>MbmsStatsCalculator</code>. This class calculates average throughput, delay, jitter and dropping for multicast traffic. | ||
| − | === | + | |
| + | === Future developments === | ||
In the near future the following additions will be made: | In the near future the following additions will be made: | ||
* Multi-cell coordination and scheduling (Core Network) | * Multi-cell coordination and scheduling (Core Network) | ||
Revision as of 10:01, 27 June 2013
LENA-MBMS Project
The purpose of the project LENA-MBMS is to implement the MBMS framework within LENA.
A simple example is in src/lte/examples/lte-simple-epc-mbms.cc in the repositories.You can download the repository from link repositories
Overview
In order to simulate the multicast traffic the following changes have been introduced within the simulator.The initialization of the MBMS is carried out thanks to the function ActivateEpsBearerMbms; this function creates a MBMS bearer and the information related to that stream is propagated to the eNodeB and UEs of the MBMS Area through MbmsAreaConfiguration message.
In this first release we suppose the BM-SC integrated within the class EpcSgwPgwApplication; when a multicast packet is received from TUN device is directly sent to EpcMbmsGwApplication class. Actually EpcMbmsGwApplication only sends multicast streams to the eNodeB belonging to the MBMS area through M1 interface.
Within the class LteEnbRrc each flow is handled by the MbmsManager class; at MAC layer multicast and unicast packets are placed in two different buffers. There are two implementations of the method SchedDlTriggerReq: the first for the management of unicast traffic, the latter for the management of multicast traffic.The scheduler allocates the MBMS traffic within the subframe defined in the standard (1,2,3,6,7,8). The MCS used in transmission and the number of subframe used for MBMS traffic is currently fixed and passed as a GetTypeId parameter.
Actually the MBMS signalling is not implemented completely; to overcome this issue and to inform the UEs they're going to receive a MBMS packet we use the DCI message. On the receiver side, UE checks the information contained within the DCI message with those of received TB; if they are equal, the UE send the TB to the upper levels.
The multicast streams are distinct from those of unicast through the use of M-RNTI (Multicast-Radio Network Temporary Identifier).
The statistics of multicast traffic are collected through a modified version of the FlowMonitor class, called MbmsStatsCalculator. This class calculates average throughput, delay, jitter and dropping for multicast traffic.
Future developments
In the near future the following additions will be made:
- Multi-cell coordination and scheduling (Core Network)
- Implementation of signalling between: eNb-MCE (M2 interface), MME-MCE (M3 interface), MBMS-GW-MME (Sm interface)
- Physical Layer - Single Frequency Network
- Improvements in MBMS stats calculator
