Understanding LTE Opnet

Understanding LTE Model Internals and Interfaces
R&D Solutions for Commercial and Defense Networks

CONFIDENTIAL RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any CONFIDENTIAL format RESTRICTED ACCESS: This information may notTechnologies, be disclosed, copied, or transmitted in any without the prior written consent of OPNET Inc. format without the prior written Technologies, consent of OPNET 2007 OPNET Inc. Technologies, Inc. 2010 OPNET Technologies, Inc.
Session 1581
1581 Understanding LTE Model Internals and Interfaces
Abstract
CONFIDENTIAL RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc. 2010 OPNET Technologies, Inc.
Brief Technology Introduction

Goals
To improve the UMTS standard to cope with future technology evolutions User demand for higher data rates and QoS

~300 Mbps downlink, ~100 Mbps uplink
Continued demand for cost reduction (CAPEX and OPEX) Low complexity Compatibility and inter-working with earlier 3GPP Releases
Introduced in 3GPP specification Release 8 and can be found in the 36-series

OFDMA in the downlink SC-FDMA in the uplink
The resulting architecture is called EPS and comprises

E-UTRAN on the radio access side EPC on the core side
Marketed as 4G
Actually a 3.9G technology Doesnt fully comply with the IMT Advanced 4G requirements.

OPNET's Model Development Consortia

LTE Model Development Consortium
Prominent
network equipment manufacturers, service providers, defense organizations Benefits to Consortium Members Early access to LTE model Opportunity to influence design requirements Phased release schedule Phases I and II released so far Phase III very close to completion Phase IV and other advanced features planned Some current members include Aerospace Corporation, AT&T, DoCoMo Euro-Labs, InterDigital, NIST, Samsung, and Sony
Successful past consortia

WiMAX,
UMTS, MANET, MPLS, and DOCSIS
LTE Model Features Up to Phase II

PHY
OFDMA for downlink & SC-FDMA for uplink Supported channels: PDCCH, PUCCH, PHICH, PDSCH, PUSCH, PRACH BLER modulation curves with turbo coding and circular buffer rate matching algorithm for each modulation and coding scheme (MCS) Multiple path loss models Multipath channel model for uplink and downlink Interference on data channels from other data and control channels Intra- and inter-cell interference HARQ Synchronous retransmissions with implicit grants on uplink Asynchronous retransmissions on downlink Type-II incremental redundancy ACK to NACK and NACK to ACK error modeling
MAC
Scheduling Requests Buffer Status Reporting Admission Control
RLC
Acknowledged, Unacknowledged and Transparent Modes Segmentation of retransmitted PDUs in case of small grants into PDU segments Configurable RLC parameters for each radio bearer for each direction PDCP: Compression for TCP/IP and UDP/IP headers EPS Mobility Management (EMM) EPS Session Management (ESM) S1 Signaling and EPS Bearer Setup/Modification/Release
General
Efficiency mode to disable PHY layer Tagged EPS/radio bearer related statistics 3 and 6 sector eNodeBs Router UE node
MAC
GBR/Non-GBR EPS bearers Logical and Transport Channels Random Access Procedure Frame generation and Scheduler
LTE Model Proposed Roadmap*

Phase-III: Channel Dependent Modulation and Scheduling

Future Phases Subject to Change Based on Customer Requirements
Other features
Channel dependent scheduling CQI and rate adaptation Energy consumption model Single-cell downlink broadcast LTE Network Deployment Wizard Initial cell selection

Phase-IV: Mobility and Handovers

Intra-E-UTRAN and intra-frequency handover with and without X2 support GGSN services by EPC to legacy SGSNs Application Delay Tracking Multimedia Broadcast Multicast Service (MBMS)
MIMO 2x2 Spatial multiplexing IPv6 support Device Creator support Power savings LTE_IDLE state PCCH and PCH Dynamic failure/recovery of base stations
* This information is provided for planning purposes only and is subject to change without notice. This does not represent a commitment by OPNET to deliver any or all capabilities in any particular timeframe.
Agenda
LTE Network Architecture LTE Node and Process Models
UE Architecture eNodeB Architecture Lab 1: Admission Control Customization EPC Architecture Global Attribute Definer Object Demo 1: LTE Channel Capacity EPS, EMM, PDCP, RLC MAC eNodeB: Frame Generator, Scheduler and HARQ Lab 2: Scheduler Customization UE: Buffer Status Reporting and Random Access PHY Architecture and MAC to PHY interface PHY Features Lab 3: Pathloss Customization
LTE Features
Documentation References
Typical Modeled Network Architecture
UE with complete TCP/IP stack eNodeBs (1, 3 and 6 sectors) Evolved Packet Core Network with IP/GTP Support
Data Traffic Flow in LTE Networks

IP packets entering the LTE network are mapped to GTP tunnels
uplink data on radio bearer
data uplink g n i y r car tunnel P T G g ondin corresp

nel TP tun G n i a t nk da downli
corresponding radio bearer carrying the downlink data
GTP Encapsulation/Decapsulation
EPS Bearer Radio Bearer S1 Bearer

Simulation Model Entities

LTE eNodeB lte_enodeb_atm4_ethernet4_slip4 lte_enodeb_ethernet4 lte_enodeb_slip4 lte_enodeb_3sector_slip4 lte_enodeb_6sector_slip4 LTE configuration node lte_attr_definer
LTE EPC Node lte_epc_atm8_ethernet8_slip8 LTE UE lte_wkstn lte_server
LTE UE Router lte_ue_ethernet_gtwy
10
Agenda
UE Architecture eNodeB Architecture Lab 1: Admission Control Customization EPC Architecture Global Attribute Definer Object Demo 1: LTE Channel Capacity
LTE Features
EPS, EMM, PDCP, RLC MAC eNodeB: Frame Generator, Scheduler and HARQ Lab 2: Scheduler Customization UE: Buffer Status Reporting and Random Access PHY Architecture and MAC to PHY interface PHY Features Lab 3: Pathloss Customization
11
UE NAS
Initiates the attachment procedure to the network (EPC) Controls activation/deactivation of EPS bearers depending upon traffic activity
While the EPS bearer is setup, data packets mapped to that bearer are queued
lte_ue_nas.pr.m
Sends ESM modify dedicated EPS bearer REQUEST message to EPC
Sends ESM Activate dedicated EPS bearer ACCEPT message to EPC Sends ESM Deactivate dedicated EPS bearer ACCEPT message to EPC Flushes the buffer of an inactive EPS bearer
12
UE AS
Requests bandwidth for higher layer data Sends Uplink data in assigned grants
Performs HARQ and RLC retransmissions for Uplink MPDUs in error
Processes Downlink data
lte_ue_as.pr.m
Steady state connected to an eNodeB Requests bandwidth using PUCCH
Requests bandwidth using RACH
13
UE AS: Random Access Process

Child process of lte_ue_as.pr.m Sends a preamble on the random access channel

Sends an uplink MPDU in the grant contained within the random access response message Performs HARQ retransmissions of the uplink MPDU until contention resolution message is received or the timer expires
lte_rach.pr.m
Awaiting random access response message from the eNodeB
Awaiting initial preamble transmission
Awaiting contention resolution message from the eNodeB
14
Agenda
LTE Features
15
eNodeB S1
Exchanges S1 messages with the EPC Acts as a translator between the core (EPC) and radio (EUTRAN) domains Communicates UE NAS messages to the core side Translates the core NAS message for the radio side: e.g. bearer activate, deactivate etc.
Communication TO the core side
lte_s1.pr.m
Communication FROM the core side
16
eNodeB AS
Keeps a record of all admitted UEs Performs admission control to manage radio resources for GBR bearers Communicates with S1 for this purpose Creates Uplink and Downlink subframes for sending/receiving traffic on the wireless medium

Performs scheduling of traffic on radio resources Manages uplink/downlink HARQ retransmissions. Performs HARQ and RLC retransmissions for Downlink MPDUs in error
Receives Uplink MPDUs and sends Downlink MPDUs

lte_enb_as.pr.m
UL/DL framing every TTI (1 ms)
17
EPS Bearer Activation/Deactivation/Modification

Bearers can be activated, deactivated, and modified on-the-fly
Activation: Activation begins at the higher layer (NAS) Both the network-initiated and UE-initiated cases supported Deactivation: Bearer deactivation can begin at the NAS or radio level In OPNET, bearer deactivation is supported for idle bearers, which starts at the radio level at the eNodeB Bearers can also be preempted, in which case, they are torn down from the system in a similar way as the inactive bearers Modification: Modification of the bearers QoS parameters is defined at the higher layer in the standard (NAS) In OPNET, QoS parameters are not modified at the EPS or radio level, although bearer modification message is used when it is rejected at the setup In lab 1, bearer modification will be achieved at the radio layer
18
Admission Control in LTE

Starts at the NAS layer of the UE or the core network
A chain of ESM and RRC messages needs to be exchanged Applicable only for the GBR bearers Non GBR bearers are admitted by default
A brief functional overview

The core communicates EPS ID and QoS parameters of the bearer to the eNodeB eNodeB S1 translates the EPS information to the radio information (EPS_ID RB_ID) for the eNodeB AS eNodeB AS uses a custom procedure to calculate if this GBR bearer should be admitted by looking at the available radio resources If the bearer can be admitted, the eNodeB AS exchanges RRC messages with the UE AS Else the NAS at the core is informed about the rejection of EPS bearer ESM messages are created for the core to indicate that the radio part of the bearer is active Finally, the core network starts sending traffic mapped to this bearer
19
A Typical Bearer Activation Message Exchange Chart

UE eNodeB AS
Admission control: Decision = ADMIT UE receives ESM bearer ACTIVE message RRC Reconfiguration: (RB ID)
eNodeB S1
EPC core
Downlink traffic arrives
Translator for the AS: (command: Activate, RB ID, QoS profile)
ESM bearer activation message: EPS ID, QoS profile
RRC Reconfiguration Accept: (RB ID) Admission control can preempt a lower priority bearer in the process
Translator for the S1: (command: Activate, EPS ID)
ESM bearer activation ACCEPT message: EPS ID Begin sending downlink traffic
Translator for the S1: (command: Release, EPS ID)
ESM bearer deactivation REQUEST message: EPS ID
Begin the bearer deactivation process by sending the ESM bearer deactivation, which will eventually be communicated via RRC messages to the appropriate UE.
The radio side of each GBR EPS bearer goes through admission control. The code is implemented in lte_admit_control_support.ex.c
20
Bearer Activation: UE Initiated Case

UE
Uplink traffic arrives
eNodeB AS
eNodeB S1
EPC core
ESM bearer resource mo dification request
Begin the bearer activation process using the same messaging as was used in the downlink data arrival case as shown on the previous slide
ESM bearer resource modification request

Sent using the signaling bearer on the uplink radio access to the eNodeB eNodeB forwards to S1, which sends it to the EPC core in the usual GTP tunnel Does not modify QoS parameters even if rejected Keeps trying until maximum attempts are exceeded
21
Lab 1: Admission Control Customization
Objectives
Understand
how the admission control algorithm monitors radio resources and admits/rejects/preempts radio bearers Customize the admission control algorithm with a certain objective Analyze the admission control logic using detailed traces and statistics
Time: 40 minutes
22
Lab 1: Take away points

OPNET supports dynamic activation, and deactivation of EPS bearers It is possible to modify the bearer QoS at the radio level
It
is possible to easily interface with the admission control module without needing any additional work in communication with the core side Bearer QoS can be modified locally at the radio level IMPORTANT: In this lab, we are not modeling EPS bearer modification process. The bearer QoS is changed locally at the eNodeB AS. Ideally, such a change would trigger the EPS modification message, but it is not important for our purposes, and hence not modeled Using detailed traces and statistics, the admission control module can be easily analyzed
23
Agenda
LTE Features
24
EPC
EPC S1/NAS mainly:

Exchanges S1 messages with the eNodeB mainly carrying NAS messages Exchanges NAS messages with the UE for initial network attachment Exchanges NAS messages with the UE for bearer activation/deactivation/modification Provides UE subscription and EPS bearer mapping information to GTP to perform tunnel encapsulation
lte_s1_nas.pr.m
25
Agenda
LTE Features
26
Global LTE Config Attributes

EPS bearers
Each UE that configures an EPS bearer with this name borrows the QoS configured here Can run a simulation without needing PHY effects Ideal for capacity studies/error free channel conditions
Efficiency attributes
PHY profiles
Each profile should be configured with both UL/DL The channel bandwidth influences the capacity of the channel the most
27
LTE Frame Structure in Time Domain

Type I FDD frame is supported
Frame
Length: 10 ms Subframe length:1 ms Scheduling and frame generation happens every subframe Slot length: 0.5 ms Slots consist of either 6 or 7 ODFM symbols, depending on whether the normal or extended cyclic prefix is employed.
28
LTE Frame Structure in Frequency Domain

A resource block consists of 12 subcarriers, each 15 kHz wide
A pair of two Resource Blocks (RBs) is the minimum allocation unit used by the scheduler while determining the allocations on a frame

The pairing is in time domain, making the allocation unit one subframe (1 ms) in length The term transport block (TB) is sometimes used for the pair. Some resources use the term resource block to refer to the transport block
Downlink reference symbols occupy 4 resource elements in each RB Uplink reference symbols occupy 12 resource elements in each RB This overhead is accounted for while computing the frame capacity for the admission control procedure
29
LTE Channel Capacity

Capacity depends upon:

Modulation and coding index (MCS) the higher the MCS index, the more the capacity Number of free resource elements per transport block for the downlink, this number can vary in each subframe
The standard (36.213) provides a table (7.1.7.2.1-1) of mapping between number of RBs and capacity in bits using 120 resource elements per block (REs) as a baseline
A Downlink channel with 2 transmitters and 3 columns taken by the PDCCH would have 120 REs per block If the REs of a block are different, the bit carrying capacity is scaled proportionally
At the end of the simulation, for each eNodeB, a table is created to give you an estimate of the channel capacity
A capacity estimate used by the admission control module is also given separately
30
Demo 1: LTE Capacity Planning Study

The OT table capacity estimate is nice, BUT

It is an estimate with the assumption that a single UE occupies the whole channel Typically multiple UEs share the channel Different MCS indexes, different traffic requirements Estimate is based upon ideal conditions and cannot account for dynamic changes Extra allocations required due to channel errors Map application traffic to GBR bearers and set up a traffic contract to closely match the application requirements + lower layer overheads Admission control: Acts as the first filter in capacity estimation: Find out how many GBR bearers are active Monitor the shared channel usage statistics to understand how they are utilized Uplink and Downlink should be analyzed separately Find out if one of them acts as a bottleneck Implement possible customizations to improve performance We will learn some tricks in lab 2 Draw inferences, make adjustments and find the configurations that give satisfactory results
How to use OPNET Modeler for planning studies

31
Demo 1: A Planning Study Example

Inputs:

eNodeB with a 3 MHz UL and DL channel Each UE has an FTP upload/download application 96 Kbps for both upload and download The initial planning committee made some advanced calculations and determined that UEs with the following characteristics should be supported:
MCS Index 0 9 20 28
Number of UEs 1 6 16 31
Requirements:
SLA requirement is that each upload/download should occur in less than 1 second Can this be done? If not, how many UEs can really be served without violating the SLA?
Planning question:
32
Demo 1: Planning Approach

First use the admission control module to figure out how many UEs should be served
Admission control provides rough estimates only Scenario: capacity_planning_demo: 53 were admitted using 96 Kbps contract The initial planning committee was pretty close in their estimate Results: SLA violated delays ~ 30 seconds Reason: The uplink is saturated! Uplink also carries extra signaling overhead (for HARQ ACKs) that we shall study later
Now make the admission criterion stricter

Make the loading factor < 1 First decreased to 0.75 (Scenario: capacity_planning_demo2): Still large delays At 0.6 loading factor (Scenario: capacity_planning_demo3), stable performance was observed with 33 admissions Uplink is pretty close to the saturation point Hence 33 UEs is the best we can do under the circumstances! You can improve scheduling algorithmshere is an idea: Schedule on the Downlink only if the probability of getting scheduled on the Uplink is highthis minimizes wastage on the Uplink and it wont be the bottleneck!
33
Of course there is R&D

Agenda
LTE Features
34
EPS Mobility Management (EMM)

Registration of UEs to the LTE network via EMM Attach procedure is modeled An eNodeB can serve multiple EPCs Once the attachment is completed, UEs remain in the LTE_Active state, the IN_SYNC sub-state, and in the RRC_Connected state The attachment procedure is implemented based on Figure 5.3.2.1-1: "Attach Procedure" in 3GPP TS 23.401 "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access".
35
EPS Session Management (ESM)

Dedicated Bearer Activation Procedure MME initiated Dedicated Bearer Deactivation Procedure GTP Tunneling Between eNodeB and EPC Nodes
GTP
tunnels carry the EPS bearers in the core network. A GTP tunnel is dynamically established for each EPS bearer. The GTP layer is located at the eNodeB and EPC nodes as follows:
IP
datagrams are sent through the corresponding GTP tunnels in the LTE core network with the following encapsulation headers:
36
LTE Packet Transmission in OPNET

IP Traffic TCP/IP and UDP/IP header compression (optional) Traffic classification
RLC operation: - Segmentation - Concatenation - Reordering - Re-transmissions - Status reports
IP Payload
lte_pdcp_pdu
IP Payload
lte_pdcp_pdu
IP Payload
lte_pdcp_pdu
Classifier (IP packet EPS bearer)

RLC buffer, bearer a RLC buffer, bearer b RLC buffer, bearer a RLC buffer, bearer c
lte_rlc_amd_pdu
lte_rlc_umd_pdu
lte_rlc_amd_pdu
lte_rlc_umd_pdu
Scheduler
lte_mac_sdu
lte_mac_sdu
lte_mac_sdu
lte_mac_sdu
Frame Generator HARQ Subframe n Radio Transmission
lte_mac_pdu HARQ process j
lte_mac_pdu HARQ process k (j) Subframe n+1
MPDU transmission
MPDU transmission
37
PDCP Features and Related Code

PDCP overhead of 16 bits is added to all higher-layer packets. PDCP header compression is performed for UDP/IP and TCP/IP headers for all higher-layer packets. Encapsulation: All packets entering LTE go through PDCP encapsulation

lte_pdcp_pdu Encapsulation occurs in lte_support_pdcp_higher_layer_to_pdcp_pdu_convert() in lte_support.ex.c Compression supported conditionally for TCP/IP and UDP/IP lte_support_pdcp_header_comp_size_compute() in lte_support.ex.c does the compression job Compression algorithm: A compression factor generated using a configured distribution Compression reflected by setting the a negative bulk size for lte_pdcp_pdu Simply recovers original packet its size was never changed lte_support_pdcp_pdu_to_higher_layer_convert() in lte_support.ex.c
Decapsulation:
38
RLC Features
Segmentation and concatenation procedures are performed using a dynamic PDU size that is determined by the scheduler decisions. The model supports the following RLC modes:
Transparent modeNo RLC header is included in this mode. Unacknowledged modeThis mode ensures in-sequence delivery of SDUs to the higher layers. Acknowledged modeThis mode ensures retransmission of missing SDUs in addition to in-sequence delivery of SDUs to the higher layers. While transmitting PDUs, an RLC entity in acknowledged mode follows this priority order: status report PDU > retransmitted PDU(s) > PDU with new data While retransmitting RLC AMD PDUs, segmentation of the retransmitted PDUs in cases of small maximum allowed PDU sizes is supported SRBs use RLC UM mode The RLC mode of the data radio bearers is configurable separately for uplink and downlink Default bearer always uses UM CCCH transmissions use transparent mode, and TM is used only by CCCH transmissions

39
RLC Code
All RLC functionality resides in models/std/lte/rlc_support.ex.c The MACRO RLCC_MAX_TX_SDU_COUNT defined in rlc_support.h controls the RLC buffer size
Modeled as a constant with a capacity of 1500 packets for each radio bearer: Packets can be of any size, though typical TCP/IP packets will be at most 1500 bytes rlc_support_rlc_sdu_enqueue() rlc_support_lte_rlc_pdu_create() rlc_support_tx_queue_size_in_bits_get(): Get the size of the queue. This is how the scheduler would know if the queue is empty. rlc_support_is_tx_window_stalled(): This is important for the scheduler to know. A stalled RLC window is treated the same as empty buffer rlc_support_lte_min_pdu_header_size_get(): This is important for the frame generator. If it does not have resources to allocate even the minimum RLC PDU header, it should not allocate any resources at all.
Enqueue/dequeue functions:

Other important functions

40
Agenda
LTE Features
41
LTE MAC Implementation Overview: eNodeB

Process model lte_enb_as.pr.m
UL
and DL framing all functions in the same process model Scheduling Most of the functionality in lte_sched_support.ex.c and externally callable functions are called from the process model Support functionality in lte_support.ex.c Mapping bits to allocation blocks and vice versa Managing the database of control channel elements in PDCCH Managing all control channels such as PDCCH, PUCCH, and RACH HARQ functionality some functionality in harq_support.ex.c and some in the same process model RLC functionality: RLC functions are called from this process model Admission control Most of the functionality in lte_admit_control_support.ex.c, and the externally callable functions are called from the process model Uplink received data processing all functions in the same process model
42
LTE MAC Implementation Overview: UE

Process model lte_ue_as.pr.m
Child
process model lte_rach.pr.m handles random access procedure exclusively SR/BSR all functions in the same process model Grant processing all functions in the same process model UE uses the same scheduler as the eNodeB to fill its grants from various radio bearer queues HARQ functionality some functionality in harq_support.ex.c and some in the same process model RLC functionality: RLC functions are called from this process model Downlink received data processing all functions in the same process model
43
Scheduler Support at the eNodeB

Frame generator, and the scheduler are distinct entities

Frame generator deals with the framing and understands the resources available for data, how bits can be mapped to these resources etc Scheduler is oblivious to the frame Ideally, you should be able to use the scheduler package for any entity Scheduler only finds the identity and optionally the number of bits of the next queue to serve By default, the scheduler is even oblivious to RLC (data buffers), although this need not be the case Scheduler can recommend infinity, and the frame generator will decide exactly how many bits are served If the scheduler does specify a finite number, the frame generator treats it as the upper limit of the amount of bits to be served Frame generator is a client of the scheduler Very complexneeds to manage multiple RBs per UE, decide termination criterion etc Can block/unblock some scheduler queues to exclude/include them in scheduling Scheduler code is implemented in lte_sched_support.ex.c and lte_sched_sup.h Frame generator code is in lte_enb_as.pr.m: DL function: lte_enb_as_dl_frame_generate() UL function: lte_enb_as_ul_frame_generate()
44
Scheduler code:

Technical Paper Published on the LTE Consortium Website A technical paper describing the frame generator/scheduler concepts and detailed code description/interfaces published on the LTE consortium website
LTE
Frame Generator and Scheduler Description
45
DL Frame Generator Block Diagram

Frame Generator
Set Scheduler callbacks (depending upon the pass) Reset the scheduler (erase transient memory) Makes group1 current
Scheduler
Q1 Q2 Q3 Q4 Q5 Q6
Group 1
Group 2
Group 3
Get next queue Get (Qi, Ri) Ri being the recommended bits to serve VALID Qi Calculate Ni, the maximum number of incremental allocation blocks that can be given to this queue and Si, the corresponding bits that can be served Ask the RLC module to return one or more RLC PDUs not exceeding (Si MAC overheads) Recalculate Ni <= Ni as the actual number of allocation blocks taken by this queue Dont terminate Update the subframe state Evaluate termination in the current pass Terminate INVALID Qi Assign PRBs to all MPDUs Return (Qi, Ri) and also send any custom information. If all queues in all groups are either empty or blocked, return INVALID
Start at the current group, use callbacks to find Qi and Ri Slide to the next group if the current group is done
Actual number of bits and blocks consumed by this queue in the current subframe
Process feedback from the frame generator. Update the permanent state of Qi that can be used to influence future selection of queues
Appendix B gives function names corresponding to various blocks for the DL frame generator
46
Understanding How to Interface to the DL Frame Generator

Entry function: lte_enb_as_frame_dl_frame_for_harq_tx_generate()
Pass 1: Called for all queues. For GBR queues, only a maximum of contract bits served. Pass 2: Called only for the GBR queues. Excess traffic in GBRs served. Pass 3: Called if PDCCH gets congested before PDSCH. In order to prevent creating new control channel elements, all unserved UEs are blocked, and remaining PDSCH resources are distributed only to the served UEs.
At the start of the framing, set scheduling callbacks:

lte_sched_support_q_selection_proc_set()
Procedure that finds the next queue
lte_sched_support_bit_selection_proc_set()
Procedure that recommends bits to be taken from the queues buffer Thats pretty much it! Interface reduced potentially to 2 lines only
Frame generator in turn calls (until resources remain, or buffers are nonempty):

lte_sched_support_next_q_get(): Gets the queue ID (crnti, RB) and the recommended bits
Frame generator has the ability to determine termination, reset the scheduler system, potentially set different callbacks each time, exclude/include queues in the scheduling process etc! We recommend you leave the frame generator undisturbed!
47
Downlink Framing Sequence

Set PDCCH symbol times = 3 (# of columns anticipated for PDCCH) Create random access responses. Adjust number of RBs available for data. Create CCCH messages. Adjust number of RBs available for data. Place HARQ retransmission MPDUs on the DL. Adjust number of RBs available for data. Schedule new MPDUs. Adjust the number of RBs available for data.
More RTX and no more RBs
Attempt to resize the PDCCH size into 1 or 2 columns
Attempt to resize the PDCCH size into 1 or 2 columns
No more RBs AND PDCCH NOT resized already
PDCCH resized to 1 or 2 symbols
All buffers empty OR PDCCH resized already
PDCCH cannot be resized
EXIT
48
Summarizing the Best Practices for Interfacing a Custom DL Scheduler

Most recommended approach: Adhere to the OPNET architecture
Let
OPNETs frame generator take care of the actual framing for you Refer to Appendix C for a non-recommended interfacing example Write two scheduler callbacks of type (declared in lte_sched_sup.h) :

LteT_Scheduling_Q_Selection_Proc LteT_Scheduling_Bit_Selection_Proc Pass 3 should always be used. Passes 1 and 2 can be combined into a single pass, if your scheduling algorithm had different objectives
Set
the custom callbacks at the beginning of lte_enb_as_dl_frame_generate() function (defined in lte_enb_as.pr.m).

Output of the DL frame generator

Created
MPDUs UE context, Number of resource blocks, MCS index, Downlink MPDU, HARQ context
The trace lte_low_level gives detail information about how each MPDU was constructed
Use the trace lte_frm to examine how the frame is constructed

49
HARQ Support for DL

Asynchronous adaptive HARQ
An
open HARQ process must be found for new MPDU transmissions Eight HARQ processes supported. HARQ context is exclusively signaled on the control channel Signaling occurs on PDCCH. DCI format 1 is set for downlink carrying HARQ process ID, NDI bit and the redundancy version HARQ retransmission can be scheduled any time at any location on the frame starting from n+8 Technically it can also carry any MCS index, although it is not done by default
All retransmissions served before any new transmission Acknowledgment mechanism:

Either
PUCCH or PUSCH channel is used for sending ACK back If PUCCH is absent at n+4, the DL frame generator also reserves 1 resource block for this UE on PUSCH, which may be reused by the UL frame generator
50
HARQ Process Management on DL

0 1 2 3 4 5 6 7 8 9 10
New tx: process 0
New tx: process 1
NACK: process 0
NACK: process 1
RTX process 0 failed due to insufficient resources! Can happen for any of PDSCH, PUSCH or PDCCH
RTX process 0 succeeded RTX process 1 pushed to next subframe
RTX process 1 succeeded
In the above example, HARQ process 1 transmission occurred after 9 subframes instead of 8. The minimum gap between transmissions on a process is 8 subframes. It can be indefinitely larger than that It is extremely unlikely that HARQ RTX blocked for 8 consecutive subframes, in which case, an open HARQ process for transmission cannot be found at all! Appendix D gives a flow chart along with function names showing how DL HARQ retransmissions are served
51
UL Frame Generator at the eNodeB

Very similar to the DL frame generator
Called
in the same 3 phases Uses the same scheduler and callback functions Does not deal with RLC, since it is the UEs job Only creates grants, and understands how many bits could fill the space allocated in a grant The eNodeB knows the UEs needs from BSRs Conditionally reuses some grants created by the DL Frame Generator for HARQ acknowledgment purposes In case the scheduler does not choose such UEs, the UL frame generator is aware that 1 allocation block would eventually be given to the above UE. Does not use the space allocated to the control channels, such as PUCCH and RACH Function: lte_enb_as_ul_frame_generate()
52
Uplink Segments
PUCCH Synchronous HARQ RTX
1b
loc k
For every contiguous segment, UL frame generator is run separately

In this example, no UE can get more than 6 allocation blocks, although a total of 13 blocks are free
6 blo
cks
Synchronous HARQ RTX
PUCCH
A typical 5 MHz Uplink Subframe
4 blo
cks
2b
loc ks
RACH
A UE scheduled in one segment cannot be scheduled again in another segment due to SCFDMA When all UEs in one segment are scheduled, their bursts are also placed in that segment Grants created for DL HARQ ACKs can go in any segment in the end. It is guaranteed that UL frame generator will leave enough space to allocate them. lte_enb_as_frame_ul_frame_for_harq_tx_gener ate() to enter the whole UL frame generation process lte_subframe_free_prb_segments_create() to find the number of free segments lte_subframe_free_prb_segments_next_seg_get () to find the dimension of next free segment (in terms of start index and number of alloc. Blocks)
53
The Uplink Framing Sequence

Uplink framing is relatively simpler than the downlink framing, since the space occupied by the control channels is fixed PUCCH and RACH allocations are made first All non-adaptive synchronous HARQ retransmission elements are scheduled next If an HARQ retransmission collided with RACH, it is fitted in an open segment large enough to accommodate it. All such adaptive HARQ retransmissions are scheduled next All msg3 grants given in the random access response (msg2) messages of the random access procedure are scheduled next Finally, new grants are given in the remaining open segments to the UEs that are not already under retransmissions
54
HARQ Support for UL

Synchronous non-adaptive/adaptive HARQ
Synchronous:
HARQ process number fixed. PID = (10*frame_number + subframe_number) modulo 8 Non-adaptive: The eNodeB does not signal HARQ RTX control information on PDCCH. Implicit RTX made by UE Adaptive: The eNodeB may have a valid reason to move the retransmission somewhere else in the subframe E.g. if the RTX burst collides with RACH Adaptive RTX has the cost of having extra control information in PDCCH If RTX cannot be scheduled, the UE remains blocked for this subframe! Different from downlink in downlink, a new TX would have happened on a new process RTX can remain blocked for a long time in pathological cases
Appendix E gives the Uplink HARQ retransmission processing flow chart along with function names
55
Recapping the DL and UL Frames

Exactly 1 allocation per UE in DL and UL
Allocation represented as a burst identified as (Start index, Number of allocation blocks, Start time, Delay, MCS index)
DL MPDU must not be created if no HARQ feedback mechanism on the UL can be ensured
If the UE does not have PUCCH in n+4, a UL grant must exist: if the UE has not requested data, or if the scheduler does not schedule this UE, this grant will consist of a minimum 1 allocation block and will be used exclusively for sending control information (HARQ ACK/NACK)
DL data (PDSCH) and control (PDCCH) space is shared. PDCCH can be resized to make bigger space for the data
A scheduler can aim to reduce the amount of control channel elements by restricting the number of UEs served in the same subframe, which can create more space for downlink data
For uplink, both non-adaptive and adaptive HARQ retransmissions are supported For downlink, asynchronous HARQ retransmissions are supported, in which retransmission can happen in any subframe >= n+8
56
HARQ retransmissions are part of the framing process

Agenda
LTE Features
57
Lab 2: Downlink Scheduler Customization Objectives

Understand
how a custom scheduler function can impact the application performance Monitor control channel overhead and draw inferences Write and interface a custom scheduler function with a certain objective to the downlink frame generator Analyze the performance of the downlink scheduler by using detailed traces and statistics
Time: 40 minutes
You
can stick around after the session to finish the extra credit portion of the lab if running short of time
58
Lab 2: Take Away Points

Using the frame generator/scheduler architecture, it is simple to interface custom schedulers to the software
Interface
can be minimized to 1 line in the standard models code, while you implement a whole new scheduler
Using detailed traces and statistics, the downlink channel can be analyzed and its impact on the application performance can be readily explained Your scheduler function should consider the impact on the Downlink control channel (PDCCH)
Use
OPNETs ability to dynamically resize the PDCCH to implement the scheduler in a way that minimizes the demands put on PDCCH code is very easy to interface to, even if you do not follow our recommendations
59
Refer to Appendix C if you want to interface differently

OPNET
Agenda
LTE Features
60
Buffer Status Reporting (BSR) for the Uplink Data

UE sends BSRs as a MAC subheader in an uplink MPDU Short (16 bits) or the long BSRs (32 bits) are sent as per the standard After reading the BSR contents, eNodeB sends grants to serve that traffic, in which new BSRs can be sent, and so on. When buffers are empty, the UE reports 0 traffic, at which point the eNodeB stops issuing grants. However in order to send the BSR, it needs an initial grant. There are 2 ways in which the UE gets it: Case 1: UE has a dedicated uplink control channel (PUCCH): In this case, it sends a scheduling request (SR) bit at the first opportunity. The eNodeB issues it a grant of a predefined size, in which the UE can send the BSR. Case 2: The UE has no dedicated uplink control channel. It this case, it uses the random access channel and the random access procedure to get the initial grant. When the UE is waiting for a new grant, it stays in either: SR_TR or BW_REQ_VIA_RACH A UE can go in only 1 of these 2 red states depending upon whether it has PUCCH allocation or not.
61
The Buffer Status Report Process
Higher layer data arrival PUCCH period or RACH timer expiry
Request initial grant using PUCCH or RACH
Request initial grant using PUCCH or RACH
Send initial grant Send BSR + Uplink data
BSR retransmission timer = typically 2560 subframes Send BSR + Uplink Data
Send Uplink grant Send Uplink data and more BSR if necessary
62
The Random Access Procedure

All UEs use it for initial attachment UEs without PUCCH allocation use it for sending bandwidth requests Implemented in lte_rach.pr.m, a child process of lte_ue_as.pr.m Exchange of 4 messages between the UE and the eNodeB
or preamble: UE sends to the eNodeB (lte_rach process model) msg2 or the random access response: eNodeB sends to the UE Function lte_enb_as_random_access_responses_generate() in lte_enb_as.pr.m Message carries an uplink grant within itself msg3: UE sends to the eNodeB from lte_rach process Uses the UL grant that comes with the random access response message Has HARQ support msg4 or the contention resolution message: terminates the random access procedure successfully
msg1
63
Uplink Grant Processor at the UE Uses the same scheduler as the eNodeB to allocate resources to various RBs
Simpler,
because resources already expressed in bits Handles all MAC and RLC headers Also inserts BSR subheader to indicate its queue sizes Function: lte_ue_as_mpdu_form()
64
Agenda
LTE Features
65
The PHY Module and the Process Model
PHY modeled as a separate process All PHY related attributes are under the PHY process When promoting, on LTE node models, they will be promoted under the LTE.PHY group
66
The PHY Module Functions

Accept a packet from MAC and perform transmission on OFDM resources
wrls_phy_pk_send() wrls_phy_mcarrier_pk_send() in wrls_phy_support.ex.c
Physical layer effects in pipeline stages

Most LTE pipeline stages are wrls_* under the models/std/wireless folder Effects such as pathloss, multipath, interference are modeled in pipelines Open architecture allows users to create custom pathloss and multipath models easily (lab 3)
Set up transmitter and receiver specific PHY information for easy information sharing
wrls_phy_tx_info_init_first_phase() and wrls_phy_tx_info_init_second_phase() in wrls_phy_support.ex.c
Collect various statistics

Pathloss, SNR, received power, dropped packets etc. Promoted statistics are under the LTE PHY group
Support advanced PHY features (upcoming and future planned)

Measurements and notifications to the MAC upon crossing of a threshold Monitoring energy consumption at a node
67
Sending LTE MPDU via the PHY Interface

lte_mac_pdu created at lte_enb_as.pr.m, lte_ue_as.pr.m, and lte_rach.pr.m lte_support_phy_burst_ici_info_pk_install_from_dci() called to create an ICI of type wrls_phy_mac_interface PHY extracts the burst information from the ICI and prepares the packet for the PHY transmission in wrls_phy_pk_send() by adding 2 unnamed fields
lte_mac_pdu
WrlsT_Phy_Mcarrier_Burst_Info Burst dimensions: Start time, transmission delay, start frequency, end frequency, PRB start index, #PRBs etc.
WrlsT_Phy_Chnl_Info Wireless channel information: WrlsT_Pathloss_Info* MultipathT_Channel_Instance* WrlsT_Phy_Antenna_Info* WrlsT_Phy_Profile* Stathandles for physical layer Etc.
68
The Purpose of PHY Unnamed Fields

Unnamed fields are read only Burst Information (WrlsT_Phy_Mcarrier_Burst_Info):
Provides
information about how the packet is mapped on the OFDM resources in form of a rectangle Used in interference calculations by determining the overlap between a pair of rectangles Also pathloss computations need frequency information to compute the pathloss accurately
Channel Information (WrlsT_Phy_Chnl_Info):

Carries
information about the specific wireless channel modeled by each UE Each UE can customize its own pathloss and multipath models Different UEs can be connected to different eNodeBs, and the physical layer profiles of those eNodeBs can be different Also carries stathandles for recording the PHY statistics Ideal place to insert various customization elements Custom information for custom pathloss, multipath models etc.
69
Agenda
LTE Features
70
Overview of PHY Features in Phase II

Support for variable bandwidth

1.4MHz, 3Mhz, 5Mhz, 10Mhz 15Mhz and 20Mhz PDSCH, PDCCH, PRACH, PUSCH and PUCCH Freespace, Suburban Macrocell, Urban Macrocell, Urban Microcell, Erceg, Pedestrian and Vehicular ITU Pedestrian A & B and ITU Vehicular A & B
Modeling of physical channels Pathloss models
Multipath models
Modulation and coding schemes Interference modeling

Time and frequency overlaps among different bursts are detected Interference is proportional to the overlap Interference may cause burst drops for PUSCH and PDSCH bursts Interference effects for control channels are based on a probability distribution function. Type II incremental redundancy Asynchronous retransmissions on the downlink Synchronous retransmissions on the uplink
HARQ
Asynchronous in case of collision of synchronous retransmissions
Disabling PHY layer for faster simulations Support for antenna models
71
Propagation Effects: Multipath and Pathloss

Pathloss called from the pipeline wrls_power.ps.c
Function
wrls_phy_packet_pathloss_compute() defined in wrls_phy_support.ex.c Burst information of the packet carries the pathloss model configured at the UE: Can easily be customized (lab 3) wrls_phy_effective_snr_get defined in wrls_phy_support.ex.c Calls wrls_phy_mpath_effective_snr_compute() In turn calls a user extensible callback function passed during the initialization of the receiver element: wrls_phy_mpath_lte_init_proc() defined in wrls_phy_support.ex.c The multipath function used for LTE is wrls_phy_mpath_lte_effective_snr_compute() defined in wrls_phy_support.ex.c
Multipath model called from the pipeline wrls_snr.ps.c

Function

72
Modulation and Coding Schemes

Modulation/coding curves created for MCS indexes from 0 to 28

For some indexes, separate curves defined for the uplink and the downlink Curves created by a bit-level Monte Carlo simulation by assuming transmission of 1 allocation block A document has been published on the LTE consortium website describing our methodology KP op_tbl_modulation_get() Function wrls_phy_mcs_info_init() in wrls_phy_support.ex.c Tables loaded in global arrays for UL and DL separately wrls_ber pipeline: BLER accessed using the KP op_tbl_mod_ber() wrls_error pipeline: Calls wrls_phy_burst_decode_success_compute() defined in wrls_phy_support.ex.c If the burst consists N blocks, and if BLER is p, the probability of successful decoding is (1-p)N
73
Loading the tables in the software

Computing BLER and packet drop probability in PHY

Physical Layer Packet Combining of HARQ

All packets tagged as valid are forwarded to the MAC whether they are decoded correctly by the PHY or not
HARQ module is implemented in MAC for its extensive MAC functionality, although its physical layer component is responsible for combining the packets Type II incremental redundancy simulated Logic: 2 types of gains: SNR gain can be simply found by adding effective SNRs of successive packets. Coding gain simulated as SNR gain by adding the SNR of the extra bits stuffed into the MPDU Example: MPDU of size 128, corresponding burst has 4 allocation blocks. The maximum bit carrying capacity of the burst = 192. Thus 64 extra bits can be carried within the burst, which can provide an extra gain at the receiver Packet receiving and processing functions: lte_enb_as_mpdu_decode_with_harq() : At lte_enb_as.pr.m lte_ue_as_mpdu_decode_with_harq(): At lte_ue_as.pr.m Efficiency support: Possible to characterize PHY by drop probability parameters If first transmission, drop probability = p (configurable attribute) If nth retransmission, drop probability = p *1/nk k is a configurable parameter idea is that the drop probability reduces exponentially with each retransmission attempt
74
Agenda
LTE Features
75
Lab 3: Pathloss Customization

Objectives
Understand
attributes Analyze the custom pathloss model with physical layer statistics
how to implement a custom pathloss model which requires custom
Time: 15 minutes Take away points

Using
the generic physical architecture, it is easy to add ones own custom physical layer algorithms in OPNET Each UE can be configured with a unique physical environment allowing for the possibility of simulating UEs in various environments Using the physical layer statistics, one can readily validate the custom physical layer
76
Agenda
LTE Features
77
Documents
Some important 3GPP Standards

36213-880: for the physical layer 36300-910: for the overall description of E-UTRAN 36321-900: for the MAC operation 36322-870: for the RLC operation 36331-900: for the RRC protocol 23203-830: for the policy and control architecture 23401-860: for the EUTRAN access network LTE Phase I Requirements Document LTE Phase II Requirements Document LTE Frame Generator and Scheduler Description LTE Modulation Models LTE Multipath Fading Models Coming soon: LTE Phase III Requirements Document
78
OPNET Published (LTE consortium website)

Resources and Model Support

Technical Support
www.opnet.com/support Link to OPNETWORK proceedings FAQs and FAQ search Link to latest Modeler product releases Link to the Modeler user forum Link to the Modeler training videos www.opnet.com/university_program Links to the contributed papers and contributed models support@opnet.com www.opnet.com/LTE Access to OPNET LTE Consortium Website Models > Model Library > LTE
79
OPNET LTE Specialized Model

Modeler Product Documentation

Related Sessions
1571: Planning WiMAX Network Deployments
Covers
planning use cases in more detail of the sister technology WiMAX
1530: Modeling Custom Wireless Effects - Introduction 1580: Modeling Custom Wireless Effects Advanced
Covers
advanced physical layer concepts on antenna modeling, node mobility modeling, OFDMA transmission framework, MCS curve generation methodology, interference computations, pathloss models, multipath modeling framework etc.
1586: Building Realistic Application Models for Discrete Event Simulation 1576: Verifying Statistical Validity of Discrete Event Simulations 1550: Accelerating Simulations Using Efficient Modeling Techniques
80
Take-Away Points
OPNET implements various LTE features
More
features are on the way
Being a part of OPNET LTE consortium can help

Early
models access can help you get familiarize to the models code You can influence LTE features release priorities
OPNET Modeler can be used in LTE planning exercises

Capacity
planning, application performance etc.
OPNET Modeler can be used in LTE R&D

Callback
based architecture allows easy customizations API based architecture allows easy interfacing to the standard models code
OPNET provides standard models code that is modular and easy to customize
81
Appendix A: Acronyms
3GPP: 3rd Generation Partnership Project QoS: Quality of Service OFDMA: Orthogonal Frequency-Division Multiple Access SC-FDMA: Single-Carrier Frequency-Division Multiple Access LTE: Long Term Evolution
4G: 4th Generation 3G: 3rd Generation
UMTS: Universal Mobile Telecommunications System

EPS: Evolved Packet System EPC: Evolved Packet Core E-UTRAN: Evolved UMTS Terrestrial Radio Access Network GTP: GPRS Tunneling Protocol eNodeB: Enhanced NodeB UE: User Equipment PDCP: Packet Data Convergence Protocol RLC: Radio Link Control HARQ: Hybrid Automatic Repeat reQuest
82
Appendix B: DL Frame Generator Code

lte_enb_as_dl_frame_generate():
Concept of a scheduling pass Ability set up a different scheduling callback
lte_enb_as_dl_frame_gen_blocks_and_bits_compute()
Computes the upper limit on the allocation blocks given to the queue Creates 1 or more MAC SDUs by contacting the RLC queue for the selected RB Computes the actual number of resources consumed in allocation blocks (<= upper limit) Also finds an HARQ process identifier for transmission if not already found Checks if PUCCH exists at n+4 for the UE. Else checks if the UE is performing an HARQ retransmission at n+4. Else checks if a UL allocation can be created on PUSCH for 1 allocation block. This may also require a new control channel element on PDCCH. If yes, a UL allocation is created. This will be reused by the UL scheduler if it finds the same UE for scheduling purposes. Creates an HARQ context of transmission. This means that after 8 subframes, we will check whether for this UE and HARQ process, an ACK/NACK was received or not. Sends the MAC PDU to the UE (efficiency or PHY method).
lte_enb_as_dl_mac_sdu_create()

lte_enb_as_harq_ack_schedule()

lte_enb_as_mac_pdu_dl_send()

83
Appendix C: What if Your Scheduler Doesnt Produce the Next Queue

Case study: My scheduler already decided all the UEs to schedule and all the associated RBsI also know how many blocks are given to each RBhow do I interface my system to OPNET?
This
problem can be solved as follows: Step 1: Overwrite the output of lte_sched_support_next_q_get() with your own (c_rnti, rb_id), so that frame generator will service your queue instead of letting the callback choose one for you When you are done, assign the variable return_ q_id the value LTEC_SCHED_Q_INVALID for termination Step 2: Overwrite the calculation of the variables num_alloc_blocks_ptr and small_alloc_blocks_ptr in the function lte_enb_as_dl_frame_gen_blocks_and_bits_compute() Small allocation blocks is important to know for subframes with special channels such as primary/secondary synchronizations and BCCH. Thats pretty much it! As long as you have produced a correct frame (i.e. not allocating more resources than what actually exist), things will work fine
84
Appendix D: Handling of DL HARQ Retransmissions

lte_enb_as_dl_frame_harq_rtx_process()
Find all UEs that should have received and processed their acknowledgements by now: (UEs that transmitted at n-8, and all NACKed UEs that got pushed to the current SF). Find the HARQ context of the UE.
ACK || max RTX exceeded Else
Free the HARQ process for new transmissions.
Examine if resources are available on PDSCH, PDCCH and conditionally PUSCH: lte_enb_as_dl_harq_rxmt_dci_obtain()
All resources available Else
Perform retransmission in the current subframe
Find a future subframe for retransmission: No other HARQ process for this UE should be scheduled for retransmission in that SF. lte_enb_as_async_dl_harq_rtx_perform()
85
Appendix E: Handling of UL HARQ Retransmissions

lte_enb_as_ul_frame_harq_rtx_process() Find all UEs that transmitted at n-8
(ACK || max RTX exceeded) && (UE made a correct transmission)* Else if UE made an incorrect transmission* Else
Free the HARQ process for new transmissions.
Send a fake ACK to this UE to stop further retransmissions and mark for adaptive retransmission
Attempt synchronous retransmission: lte_enb_as_ul_frame_harq_implicit_rtx_process()
Failed due to collision with another RTX or RACH
Else
For each open segment, attempt adaptive retransmission: lte_enb_as_ul_frame_harq_explicit_rtx_process()

Failed Succeeded
Send NACK. The UE will retransmit implicitly
Send a fake ACK to stop retransmission
Send NACK and a grant for RTX with NDI = 0
*Incorrect transmission: An incorrect transmission is a consequence of the following scenario: ACK to NACK and lost grant for new data. In this case, the UE retransmits using a previous grant instead of doing a transmission using the new grant. In real systems, HARQ/PHY can detect this by noting reception of a packet on wrong frequencies.
86

Understanding LTE Opnet

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Understanding LTE Opnet

Uploaded by

Copyright:

Available Formats

Understanding LTE Model Internals and Interfaces

R&D Solutions for Commercial and Defense Networks

1581 Understanding LTE Model Internals and Interfaces

1581 Understanding LTE Model Internals and Interfaces

Brief Technology Introduction

~300 Mbps downlink, ~100 Mbps uplink

Introduced in 3GPP specification Release 8 and can be found in the 36-series

The resulting architecture is called EPS and comprises

1581 Understanding LTE Model Internals and Interfaces

OPNET's Model Development Consortia

Successful past consortia

UMTS, MANET, MPLS, and DOCSIS

1581 Understanding LTE Model Internals and Interfaces

LTE Model Features Up to Phase II

1581 Understanding LTE Model Internals and Interfaces

LTE Model Proposed Roadmap*

Future Phases Subject to Change Based on Customer Requirements

Phase-IV: Mobility and Handovers

1581 Understanding LTE Model Internals and Interfaces

1581 Understanding LTE Model Internals and Interfaces

Typical Modeled Network Architecture

1581 Understanding LTE Model Internals and Interfaces

Data Traffic Flow in LTE Networks

uplink data on radio bearer

data uplink g n i y r car tunnel P T G g ondin corresp

corresponding radio bearer carrying the downlink data

EPS Bearer Radio Bearer S1 Bearer

1581 Understanding LTE Model Internals and Interfaces

Simulation Model Entities

LTE EPC Node lte_epc_atm8_ethernet8_slip8 LTE UE lte_wkstn lte_server

LTE UE Router lte_ue_ethernet_gtwy

1581 Understanding LTE Model Internals and Interfaces

1581 Understanding LTE Model Internals and Interfaces

Sends ESM modify dedicated EPS bearer REQUEST message to EPC

1581 Understanding LTE Model Internals and Interfaces

Performs HARQ and RLC retransmissions for Uplink MPDUs in error

Processes Downlink data

Steady state connected to an eNodeB Requests bandwidth using PUCCH

Requests bandwidth using RACH

1581 Understanding LTE Model Internals and Interfaces

UE AS: Random Access Process

Awaiting random access response message from the eNodeB

Awaiting initial preamble transmission

Awaiting contention resolution message from the eNodeB

1581 Understanding LTE Model Internals and Interfaces

1581 Understanding LTE Model Internals and Interfaces

1581 Understanding LTE Model Internals and Interfaces

Receives Uplink MPDUs and sends Downlink MPDUs

1581 Understanding LTE Model Internals and Interfaces

EPS Bearer Activation/Deactivation/Modification

1581 Understanding LTE Model Internals and Interfaces

Admission Control in LTE

A brief functional overview

1581 Understanding LTE Model Internals and Interfaces

A Typical Bearer Activation Message Exchange Chart

Translator for the AS: (command: Activate, RB ID, QoS profile)

ESM bearer activation message: EPS ID, QoS profile

Translator for the S1: (command: Activate, EPS ID)

Translator for the S1: (command: Release, EPS ID)

ESM bearer deactivation REQUEST message: EPS ID

1581 Understanding LTE Model Internals and Interfaces

Bearer Activation: UE Initiated Case

ESM bearer resource mo dification request