Understanding LTE Opnet

CONFIDENTIAL ─ RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.

© 2007 OPNET Technologies, Inc.

Understanding LTE ModelInternals and Interfaces

R&D Solutions for Commercial and Defense Networks

Session 1581

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.

2

1581 Understanding LTE Model Internals and Interfaces

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.

Abstract

3



Brief Technology Introduction

GoalsTo improve the UMTS standard to cope with future technology evolutionsUser demand for higher data rates and QoS

~300 Mbps downlink, ~100 Mbps uplinkContinued 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-seriesOFDMA in the downlinkSC-FDMA in the uplink

The resulting architecture is called EPS and comprisesE-UTRAN on the radio access sideEPC on the core side

Marketed as 4GActually a 3.9G technologyDoesn’t fully comply with the IMT Advanced 4G requirements.

4



OPNET's Model Development Consortia

LTE Model Development ConsortiumProminent network equipment manufacturers, service providers, defense organizationsBenefits to Consortium Members

Early access to LTE modelOpportunity to influence design requirements

Phased release schedulePhases I and II released so farPhase III very close to completionPhase IV and other advanced features planned

Some current members include Aerospace Corporation, AT&T, DoCoMoEuro-Labs, InterDigital, NIST, Samsung, and Sony

Successful past consortia WiMAX, UMTS, MANET, MPLS, and DOCSIS

5



LTE Model Features Up to Phase II

PHYOFDMA for downlink & SC-FDMA for uplinkSupported channels: PDCCH, PUCCH, PHICH, PDSCH, PUSCH, PRACHBLER modulation curves with turbo coding and circular buffer rate matching algorithm for each modulation and coding scheme (MCS)Multiple path loss modelsMultipath channel model for uplink and downlinkInterference on data channels from other data and control channelsIntra- and inter-cell interference

HARQSynchronous retransmissions with implicit grants on uplinkAsynchronous retransmissions on downlinkType-II incremental redundancyACK to NACK and NACK to ACK error modeling

MACGBR/Non-GBR EPS bearersLogical and Transport Channels Random Access ProcedureFrame generation and Scheduler

MACScheduling RequestsBuffer Status ReportingAdmission Control

RLC Acknowledged, Unacknowledged and Transparent ModesSegmentation of retransmitted PDUs in case of small grants into PDU segmentsConfigurable RLC parameters for each radio bearer for each direction

PDCP: Compression for TCP/IP and UDP/IP headersEPS Mobility Management (EMM)EPS Session Management (ESM)

S1 Signaling and EPS Bearer Setup/Modification/Release

GeneralEfficiency mode to disable PHY layerTagged EPS/radio bearer related statistics3 and 6 sector eNodeBsRouter UE node

6



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

Phase-III: Channel Dependent Modulation and Scheduling

Channel dependent schedulingCQI and rate adaptationEnergy consumption modelSingle-cell downlink broadcastLTE Network Deployment WizardInitial cell selection

Phase-IV: Mobility and HandoversIntra-E-UTRAN and intra-frequency handover with and without X2 supportGGSN services by EPC to legacy SGSNs Application Delay TrackingMultimedia Broadcast Multicast Service (MBMS)

Other featuresMIMO

2x2Spatial multiplexing

IPv6 supportDevice Creator supportPower savings

LTE_IDLE statePCCH and PCH

Dynamic failure/recovery of base stations

LTE Model Proposed Roadmap*Future Phases – Subject to Change Based on Customer Requirements

7



Agenda

LTE Network ArchitectureLTE Node and Process Models

UE ArchitectureeNodeB Architecture

Lab 1: Admission Control CustomizationEPC ArchitectureGlobal Attribute Definer Object

Demo 1: LTE Channel CapacityLTE Features

EPS, EMM, PDCP, RLCMAC

eNodeB: Frame Generator, Scheduler and HARQLab 2: Scheduler CustomizationUE: Buffer Status Reporting and Random Access

PHYArchitecture and MAC to PHY interfacePHY FeaturesLab 3: Pathloss Customization

Documentation References

8



UE with complete TCP/IP

stackeNodeBs (1, 3 and 6 sectors) Evolved Packet Core

Network withIP/GTP Support

Typical Modeled Network Architecture

9



Data Traffic Flow in LTE Networks

GTP Encapsulation/Decapsulation

EPS BearerRadio Bearer S1 Bearer

IP packets entering the LTE network are mapped to GTP tunnels

uplink data on radio bearer

corresponding GTP tunnel carrying uplink data

downlink data in GTP tunnel

corresponding radio bearer carrying the downlink data

10



LTE eNodeBlte_enodeb_atm4_ethernet4_slip4lte_enodeb_ethernet4lte_enodeb_slip4lte_enodeb_3sector_slip4lte_enodeb_6sector_slip4

LTE UElte_wkstnlte_server

LTE configuration nodelte_attr_definer

LTE EPC Nodelte_epc_atm8_ethernet8_slip8

LTE UE Routerlte_ue_ethernet_gtwy

Simulation Model Entities

11



Agenda









12



UE NAS

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

Sends ESM “modify dedicated EPS bearer REQUEST” message to EPC

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

13



UE AS

Requests bandwidth using PUCCH

Requests bandwidth using RACH

Steady state – connected to an eNodeB

Requests bandwidth for higher layer dataSends Uplink data in assigned grants

Performs HARQ and RLC retransmissions for Uplink MPDUs in errorProcesses Downlink data

lte_ue_as.pr.m

14



UE AS: Random Access Process

lte_rach.pr.m

Awaiting initial preamble transmission

Awaiting random access response message from the eNodeB

Awaiting contention resolution message from the eNodeB

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

Sends an uplink MPDU in the grant contained within the random access response messagePerforms HARQ retransmissions of the uplink MPDU until contention resolution message is received or the timer expires

15



Agenda









16



eNodeB S1

Communication TO the core side

Communication FROM the core side

Exchanges S1 messages with the EPCActs as a translator between the core (EPC) and radio (EUTRAN) domainsCommunicates UE NAS messages to the core sideTranslates the core NAS message for the radio side: e.g. bearer activate, deactivate etc.

lte_s1.pr.m

17



eNodeB AS

UL/DL framing – every TTI (1 ms)

Keeps a record of all admitted UEsPerforms admission control to manage radio resources for GBR bearersCommunicates with S1 for this purposeCreates Uplink and Downlink subframes for sending/receiving traffic on the wireless medium

Performs scheduling of traffic on radio resourcesManages uplink/downlink HARQ retransmissions.

Receives Uplink MPDUs and sends Downlink MPDUsPerforms HARQ and RLC retransmissions for Downlink MPDUs in error

lte_enb_as.pr.m

18



EPS Bearer Activation/Deactivation/Modification

Bearers can be activated, deactivated, and modified on-the-flyActivation:

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 eNodeBBearers 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 bearer’s 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

19



Admission Control in LTE

Starts at the NAS layer of the UE or the core networkA chain of ESM and RRC messages needs to be exchanged Applicable only for the GBR bearers

Non GBR bearers are admitted by defaultA brief functional overview

The core communicates EPS ID and QoS parameters of the bearer to the eNodeBeNodeB S1 translates the EPS information to the radio information (EPS_ID RB_ID) for the eNodeB ASeNodeB AS uses a custom procedure to calculate if this GBR bearer should be admitted by looking at the available radio resourcesIf 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 bearerESM 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

20



A Typical Bearer Activation Message Exchange Chart

EPC coreeNodeB S1eNodeB ASUE

ESM bearer activation message: EPS ID, QoS profile

Downlink traffic arrivesTranslator for the AS: (command: Activate, RB ID, QoS profile)

Admission control: Decision = ADMIT

RRC Reconfiguration: (RB ID)

RRC Reconfiguration Accept: (RB ID)

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

ESM bearer activation ACCEPT message: EPS ID

Begin sending downlink trafficAdmission control

can preempt a lower priority bearer in the process

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

UE receives ESM bearer ACTIVE message

21



Bearer Activation: UE Initiated Case

EPC coreeNodeB S1eNodeB ASUE

Uplink traffic arrives

ESM bearer resource modification 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 requestSent using the signaling bearer on the uplink radio access to the eNodeBeNodeB forwards to S1, which sends it to the EPC core in the usual GTP tunnelDoes not modify QoS parameters even if rejected

Keeps trying until maximum attempts are exceeded

22



Lab 1: Admission Control Customization

ObjectivesUnderstand how the admission control algorithm monitors radio resources and admits/rejects/preempts radio bearersCustomize the admission control algorithm with a certain objectiveAnalyze the admission control logic using detailed traces and statistics

Time: 40 minutes

23



Lab 1: Take away points

OPNET supports dynamic activation, and deactivation of EPS bearersIt 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 sideBearer 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

24



Agenda









25



EPC

EPC S1/NAS mainly:Exchanges S1 messages with the eNodeB mainly carrying NAS messagesExchanges NAS messages with the UE for initial network attachmentExchanges NAS messages with the UE for bearer activation/deactivation/modificationProvides UE subscription and EPS bearer mapping information to GTP to perform tunnel encapsulation

lte_s1_nas.pr.m

26



Agenda









27



Global LTE Config Attributes

EPS bearersEach UE that configures an EPS bearer with this name borrows the QoS configured here

Efficiency attributesCan run a simulation without needing PHY effects

Ideal for capacity studies/error free channel conditions

PHY profilesEach profile should be configured with both UL/DLThe channel bandwidth influences the capacity of the channel the most

28



LTE Frame Structure in Time Domain

Type I FDD frame is supportedFrame Length: 10 msSubframe length:1 ms

Scheduling and frame generation happens every subframeSlot length: 0.5 msSlots consist of either 6 or 7 ODFM symbols, depending on whether the normal or extended cyclic prefix is employed.

29



LTE Frame Structure in Frequency Domain

A resource block consists of 12 sub-carriers, 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 lengthThe 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 RBUplink reference symbols occupy 12 resource elements in each RBThis overhead is accounted for while computing the frame capacity for the admission control procedure

30



LTE Channel Capacity

Capacity depends upon:Modulation and coding index (MCS) – the higher the MCS index, the more the capacityNumber 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 blockIf 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

31



Demo 1: LTE Capacity Planning Study

The OT table capacity estimate is nice, BUTIt is an “estimate” with the assumption that a single UE occupies the whole channelTypically multiple UEs share the channel

Different MCS indexes, different traffic requirementsEstimate is based upon ideal conditions and cannot account for dynamic changes

Extra allocations required due to channel errorsHow to use OPNET Modeler for planning studies

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 utilizedUplink and Downlink should be analyzed separatelyFind out if one of them acts as a bottleneck

Implement possible customizations to improve performanceWe will learn some tricks in lab 2

Draw inferences, make adjustments and find the configurations that give satisfactory results

32



Demo 1: A Planning Study Example

Inputs:eNodeB with a 3 MHz UL and DL channelEach UE has an FTP upload/download application

96 Kbps for both upload and downloadThe initial planning committee made some advanced calculations and determined that UEs with the following characteristics should be supported:

3128

1620

69

10

Number of UEsMCS Index

Requirements:SLA requirement is that each upload/download should occur in less than 1 second

Planning question:Can this be done? If not, how many UEs can really be served without violating the SLA?

33



Demo 1: Planning Approach

First use the admission control module to figure out how many UEs “should” be served

Admission control provides rough estimates onlyScenario: capacity_planning_demo: 53 were admitted using 96 Kbps contract

The initial planning committee was pretty close in their estimateResults: 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 stricterMake the loading factor < 1

First decreased to 0.75 (Scenario: capacity_planning_demo2): Still large delaysAt 0.6 loading factor (Scenario: capacity_planning_demo3), stable performance was observed with 33 admissionsUplink is pretty close to the saturation pointHence 33 UEs is the best we can do under the circumstances!

Of course there is R&DYou can improve scheduling algorithms…here is an idea: Schedule on the Downlink only if the probability of getting scheduled on the Uplink is high…this minimizes wastage on the Uplink and it won’t be the bottleneck!

34



Agenda









35



EPS Mobility Management (EMM)

Registration of UEs to the LTE network via EMM Attach procedure is modeledAn eNodeB can serve multiple EPCsOnce the attachment is completed, UEs remain in the LTE_Active state, the IN_SYNC sub-state, and in the RRC_Connected stateThe 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".

36



EPS Session Management (ESM)

Dedicated Bearer Activation ProcedureMME initiated Dedicated Bearer Deactivation ProcedureGTP 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:

37



Classifier (IP packet EPS bearer)

LTE Packet Transmission in OPNET

IP Payload

lte_pdcp_pdu

IP Payload

lte_pdcp_pdu

IP Payload

lte_pdcp_pdu

lte_rlc_amd_pdu lte_rlc_umd_pdu lte_rlc_amd_pdu lte_rlc_umd_pdu

lte_mac_sdu lte_mac_sdu lte_mac_sdu lte_mac_sdu

lte_mac_pdu lte_mac_pdu

HARQ process j

MPDU transmission

HARQ process k (≠j)

MPDU transmission

TCP/IP and UDP/IP header compression (optional)

RLC operation:- Segmentation- Concatenation - Reordering- Re-transmissions- Status reports

Scheduler

Frame Generator

Subframe n Subframe n+1

RLC buffer, bearer a RLC buffer, bearer b RLC buffer, bearer a RLC buffer, bearer c

IP Traffic

Traffic classification

HARQ

Radio Transmission

38



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_pduEncapsulation occurs in lte_support_pdcp_higher_layer_to_pdcp_pdu_convert() inlte_support.ex.cCompression 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 distributionCompression reflected by setting the a negative bulk size for lte_pdcp_pdu

Decapsulation:Simply recovers original packet – its size was never changed

lte_support_pdcp_pdu_to_higher_layer_convert() in lte_support.ex.c

39



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 mode—No RLC header is included in this mode.Unacknowledged mode—This mode ensures in-sequence delivery of SDUs to the higher layers.Acknowledged mode—This 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 dataWhile retransmitting RLC AMD PDUs, segmentation of the retransmitted PDUs in cases of small maximum allowed PDU sizes is supported

SRBs use RLC UM modeThe RLC mode of the data radio bearers is configurable separately for uplink and downlink

Default bearer always uses UMCCCH transmissions use transparent mode, and TM is used only by CCCH transmissions

40



RLC Code

All RLC functionality resides in models/std/lte/rlc_support.ex.cThe MACRO RLCC_MAX_TX_SDU_COUNT defined in rlc_support.hcontrols 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

Enqueue/dequeue functions:rlc_support_rlc_sdu_enqueue()rlc_support_lte_rlc_pdu_create()

Other important functionsrlc_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 bufferrlc_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.

41



Agenda









42



LTE MAC Implementation Overview: eNodeB

Process model lte_enb_as.pr.mUL and DL framing – all functions in the same process modelScheduling – Most of the functionality in lte_sched_support.ex.c and externally callable functions are called from the process modelSupport functionality in lte_support.ex.c

Mapping bits to allocation blocks and vice versaManaging the database of control channel elements in PDCCHManaging all control channels such as PDCCH, PUCCH, and RACH

HARQ functionality – some functionality in harq_support.ex.c and some in the same process modelRLC functionality: RLC functions are called from this process modelAdmission control – Most of the functionality in lte_admit_control_support.ex.c, and the externally callable functions are called from the process modelUplink received data processing – all functions in the same process model

43



LTE MAC Implementation Overview: UE

Process model lte_ue_as.pr.mChild process model lte_rach.pr.m handles random access procedure exclusivelySR/BSR – all functions in the same process modelGrant 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 modelRLC functionality: RLC functions are called from this process modelDownlink received data processing – all functions in the same process model

44



Scheduler Support at the eNodeB

Frame generator, and the scheduler are distinct entitiesFrame generator deals with the “framing” and understands the resources available for data, how bits can be mapped to these resources etcScheduler is oblivious to the “frame”

Ideally, you should be able to use the scheduler package for any entityScheduler 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 servedIf 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 schedulerVery complex…needs to manage multiple RBs per UE, decide termination criterion etcCan block/unblock some scheduler queues to exclude/include them in scheduling

Scheduler code:Scheduler code is implemented in lte_sched_support.ex.c and lte_sched_sup.hFrame 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()

45



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”

46



DL Frame Generator Block Diagram

Frame Generator Scheduler

Set Scheduler callbacks (depending upon the pass)

Reset the scheduler (erase transient memory)

Q1 Q2 Q3 Q4 Q5 Q6

Group 1 Group 2 Group 3Makes group1 current

Get (Qi, Ri) Ri being the recommended bits to serve

Start at the current group, use callbacks to find Qi and Ri

Slide to the next group if the current group is doneCalculate 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 N’i <= Ni as the actual number of allocation blocks taken by

this queue

Update the subframe state

Evaluate termination in the current pass

Don’t terminate

Process feedback from the frame generator. Update the permanent

state of Qi that can be used to influence future selection of queues

Return (Qi, Ri) and also send any custom information. If all queues in all groups are either empty or blocked, return INVALID

Actual number of bits and blocks consumed

by this queue in the current subframe

Assign PRBs to all MPDUs

Terminate

VALID Qi

INVALID Qi

Get next queue

Appendix B gives function names corresponding to various blocks for the DL frame generator

47



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 queue’s bufferThat’s 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!

48



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.

Attempt to resize the PDCCH size into 1 or 2 columns

Schedule new MPDUs. Adjust the number of RBs available

for data.

EXIT

All buffers empty OR PDCCH resized already

No more RBs AND PDCCH NOT resized already

PDC

CH

can

not b

e re

size

d

Attempt to resize the PDCCH size into 1 or 2 columns

PDCCH resized to 1 or 2 symbols

More RTX and no more RBs

49



Summarizing the Best Practices for Interfacing a Custom DL Scheduler

Most recommended approach: Adhere to the OPNET architectureLet OPNET’s frame generator take care of the actual framing for you

Refer to Appendix C for a non-recommended interfacing exampleWrite two scheduler callbacks of type (declared in lte_sched_sup.h) :

LteT_Scheduling_Q_Selection_ProcLteT_Scheduling_Bit_Selection_Proc

Set the custom callbacks at the beginning of lte_enb_as_dl_frame_generate() function (defined in lte_enb_as.pr.m).

Pass 3 should always be used. Passes 1 and 2 can be combined into a single pass, if your scheduling algorithm had different objectives

Output of the DL frame generatorCreated MPDUs

UE context, Number of resource blocks, MCS index, Downlink MPDU,HARQ context

Use the trace lte_frm to examine how the frame is constructedThe trace lte_low_level gives detail information about how each MPDU was constructed

50



HARQ Support for DL

Asynchronous adaptive HARQAn open HARQ process must be found for new MPDU transmissions

Eight HARQ processes supported.HARQ context is exclusively signaled on the control channelSignaling 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 transmissionAcknowledgment mechanism:

Either PUCCH or PUSCH channel is used for sending ACK backIf 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

51



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

52



UL Frame Generator at the eNodeB

Very similar to the DL frame generatorCalled in the same 3 phasesUses the same scheduler and callback functionsDoes not deal with RLC, since it is the UE’s job

Only creates grants, and understands how many bits could fill the space allocated in a grant – The eNodeB knows the UE’s 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 RACHFunction: lte_enb_as_ul_frame_generate()

53



Uplink “Segments”

A typical 5 MHz Uplink Subframe

RACH

PUCCH

PUCCH

Synchronous HARQ RTX

Synchronous HARQ RTX

1 block

6 blocks

2 bl

ocks

4 bl

ocks

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

A UE scheduled in one segment cannot be scheduled again in another segment due to SCFDMAWhen all UEs in one segment are scheduled, their bursts are also placed in that segmentGrants 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_generate() to enter the whole UL frame generation processlte_subframe_free_prb_segments_create() to find the number of free segmentslte_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)

54



The Uplink Framing Sequence

Uplink framing is relatively simpler than the downlink framing, since the space occupied by the control channels is fixedPUCCH and RACH allocations are made firstAll non-adaptive synchronous HARQ retransmission elements are scheduled nextIf 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 nextAll msg3 grants given in the random access response (msg2) messages of the random access procedure are scheduled nextFinally, new grants are given in the remaining open segments to the UEs that are not already under retransmissions

55



HARQ Support for UL

Synchronous non-adaptive/adaptive HARQSynchronous: HARQ process number fixed.

PID = (10*frame_number + subframe_number) modulo 8Non-adaptive: The eNodeB does not signal HARQ RTX control information on PDCCH.

Implicit RTX made by UEAdaptive: The eNodeB may have a valid reason to move the retransmission somewhere else in the subframe

E.g. if the RTX burst collides with RACHAdaptive 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 processRTX can remain blocked for a long time in pathological cases

Appendix E gives the Uplink HARQ retransmission processing flow chart along with function names

56



Recapping the DL and UL Frames

Exactly 1 allocation per UE in DL and ULAllocation 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

HARQ retransmissions are part of the framing processFor uplink, both non-adaptive and adaptive HARQ retransmissions are supportedFor downlink, asynchronous HARQ retransmissions are supported, in which retransmission can happen in any subframe >= n+8

57



Agenda









58



Lab 2: Downlink Scheduler Customization

ObjectivesUnderstand how a custom scheduler function can impact the application performanceMonitor control channel overhead and draw inferencesWrite and interface a custom scheduler function with a certain objective to the downlink frame generatorAnalyze the performance of the downlink scheduler by using detailed traces and statistics

Time: 40 minutesYou can stick around after the session to finish the extra credit portion of the lab if running short of time

59



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 explainedYour scheduler function should consider the impact on the Downlink control channel (PDCCH)

Use OPNET’s ability to dynamically resize the PDCCH to implement the scheduler in a way that minimizes the demands put on PDCCH

Refer to Appendix C if you want to interface differentlyOPNET code is very easy to interface to, even if you do not follow our recommendations

60



Agenda









61



Buffer Status Reporting (BSR) for the Uplink Data

UE sends BSRs as a MAC subheader in an uplink MPDUShort (16 bits) or the long BSRs (32 bits) are sent as per the standardAfter 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 orBW_REQ_VIA_RACHA UE can go in only 1 of these 2 red states depending upon whether it has PUCCH allocation or not.

62



The Buffer Status Report Process

Higher layer data arrival Request initial grant using PUCCH or RACH

PUCCH period or RACH timer expiry 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

63



The Random Access Procedure

All UEs use it for initial attachmentUEs without PUCCH allocation use it for sending bandwidth requestsImplemented in lte_rach.pr.m, a child process of lte_ue_as.pr.mExchange of 4 messages between the UE and the eNodeB

msg1 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.mMessage carries an uplink grant within itself

msg3: UE sends to the eNodeB from lte_rach processUses the UL grant that comes with the random access response messageHas HARQ support

msg4 or the contention resolution message: terminates the random access procedure successfully

64



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 bitsHandles all MAC and RLC headersAlso inserts BSR subheader to indicate its queue sizesFunction: lte_ue_as_mpdu_form()

65



Agenda









66



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

67



The PHY Module Functions

Accept a packet from MAC and perform transmission on OFDM resourceswrls_phy_pk_send() wrls_phy_mcarrier_pk_send() in wrls_phy_support.ex.c

Physical layer effects in pipeline stagesMost LTE pipeline stages are wrls_* under the models/std/wireless folderEffects 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 statisticsPathloss, 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 thresholdMonitoring energy consumption at a node

68



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 WrlsT_Phy_Chnl_Info

Burst dimensions:

Start time, transmission delay, start frequency, end frequency, PRB start index, #PRBs etc.

Wireless channel information:

•WrlsT_Pathloss_Info*

•MultipathT_Channel_Instance*

•WrlsT_Phy_Antenna_Info*

•WrlsT_Phy_Profile*

•Stathandles for physical layer

•Etc.

69



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 rectanglesAlso 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 modelsDifferent 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 statisticsIdeal place to insert various customization elements

Custom information for custom pathloss, multipath models etc.

70



Agenda









71



Overview of PHY Features in Phase II

Support for variable bandwidth1.4MHz, 3Mhz, 5Mhz, 10Mhz 15Mhz and 20Mhz

Modeling of physical channelsPDSCH, PDCCH, PRACH, PUSCH and PUCCH

Pathloss modelsFreespace, Suburban Macrocell, Urban Macrocell, Urban Microcell, Erceg, Pedestrian and Vehicular

Multipath modelsITU Pedestrian A & B and ITU Vehicular A & B

Modulation and coding schemesInterference modeling

Time and frequency overlaps among different bursts are detectedInterference is proportional to the overlapInterference may cause burst drops for PUSCH and PDSCH burstsInterference effects for control channels are based on a probability distribution function.

HARQType II incremental redundancyAsynchronous retransmissions on the downlinkSynchronous retransmissions on the uplink

Asynchronous in case of collision of synchronous retransmissionsDisabling PHY layer for faster simulationsSupport for antenna models

72



Propagation Effects: Multipath and Pathloss

Pathloss called from the pipeline wrls_power.ps.cFunction 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)

Multipath model called from the pipeline wrls_snr.ps.cFunction 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

73



Modulation and Coding Schemes

Modulation/coding curves created for MCS indexes from 0 to 28For some indexes, separate curves defined for the uplink and the downlinkCurves 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

Loading the tables in the softwareKP op_tbl_modulation_get()

Function wrls_phy_mcs_info_init() in wrls_phy_support.ex.cTables loaded in global arrays for UL and DL separately

Computing BLER and packet drop probability in PHYwrls_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

74



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 packetsType 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.mlte_ue_as_mpdu_decode_with_harq(): At lte_ue_as.pr.m

Efficiency support:Possible to characterize PHY by drop probability parametersIf 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

75



Agenda









76



Lab 3: Pathloss Customization

ObjectivesUnderstand how to implement a custom pathloss model which requires custom attributesAnalyze the custom pathloss model with physical layer statistics

Time: 15 minutesTake away points

Using the generic physical architecture, it is easy to add one’s own custom physical layer algorithms in OPNETEach UE can be configured with a unique physical environment allowing for the possibility of simulating UEs in various environmentsUsing the physical layer statistics, one can readily validate the custom physical layer

77



Agenda









78



Documents

Some important 3GPP Standards36213-880: for the physical layer36300-910: for the overall description of E-UTRAN36321-900: for the MAC operation36322-870: for the RLC operation36331-900: for the RRC protocol23203-830: for the policy and control architecture23401-860: for the EUTRAN access network

OPNET Published (LTE consortium website)LTE Phase I Requirements DocumentLTE Phase II Requirements DocumentLTE Frame Generator and Scheduler DescriptionLTE Modulation ModelsLTE Multipath Fading ModelsComing soon: LTE Phase III Requirements Document

79



Resources and Model Support

Technical Support www.opnet.com/support

Link to OPNETWORK proceedingsFAQs and FAQ search Link to latest Modeler product releasesLink to the Modeler user forumLink to the Modeler training videoswww.opnet.com/university_program

Links to the contributed papers and contributed [email protected]

OPNET LTE Specialized Modelwww.opnet.com/LTEAccess to OPNET LTE Consortium Website

Modeler Product DocumentationModels > Model Library > LTE

80



Related Sessions

1571: Planning WiMAX Network DeploymentsCovers planning use cases in more detail of the sister technology WiMAX

1530: Modeling Custom Wireless Effects - Introduction1580: 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 Simulation1576: Verifying Statistical Validity of Discrete Event Simulations1550: Accelerating Simulations Using Efficient Modeling Techniques

81



Take-Away Points

OPNET implements various LTE featuresMore features are on the way

Being a part of OPNET LTE consortium can helpEarly models access can help you get familiarize to the models codeYou can influence LTE features release priorities

OPNET Modeler can be used in LTE planning exercisesCapacity planning, application performance etc.

OPNET Modeler can be used in LTE R&DCallback based architecture allows easy customizationsAPI based architecture allows easy interfacing to the standard models code

OPNET provides standard models code that is modular and easy to customize

82



Appendix A: Acronyms

3GPP: 3rd Generation Partnership ProjectQoS: Quality of ServiceOFDMA: Orthogonal Frequency-Division Multiple AccessSC-FDMA: Single-Carrier Frequency-Division Multiple AccessLTE: Long Term Evolution

4G: 4th GenerationUMTS: Universal Mobile Telecommunications System

3G: 3rd GenerationEPS: Evolved Packet SystemEPC: Evolved Packet CoreE-UTRAN: Evolved UMTS Terrestrial Radio Access NetworkGTP: GPRS Tunneling ProtocoleNodeB: Enhanced NodeBUE: User EquipmentPDCP: Packet Data Convergence ProtocolRLC: Radio Link ControlHARQ: Hybrid Automatic Repeat reQuest

83



Appendix B: DL Frame Generator Code

lte_enb_as_dl_frame_generate(): Concept of a “scheduling pass”

Ability set up a different scheduling callbacklte_enb_as_dl_frame_gen_blocks_and_bits_compute()

Computes the upper limit on the allocation blocks given to the queuelte_enb_as_dl_mac_sdu_create()

Creates 1 or more MAC SDUs by contacting the RLC queue for the selected RBComputes the actual number of resources consumed in allocation blocks (<= upper limit)Also finds an HARQ process identifier for transmission if not already found

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

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

84



Appendix C: What if Your Scheduler Doesn’t Produce the “Next Queue”

Case study: My scheduler already decided all the UEs to schedule and all the associated RBs…I also know how many blocks are given to each RB…how 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.

That’s 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

85



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.

Free the HARQ process for new transmissions.

ACK || max RTX exceeded

Examine if resources are available on PDSCH, PDCCH and conditionally

PUSCH: lte_enb_as_dl_harq_rxmt_dci_obtain()

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

Else

All resources available Else

86



Appendix E: Handling of UL HARQ Retransmissions

lte_enb_as_ul_frame_harq_rtx_process()

Find all UEs that transmitted at n-8

Free the HARQ process for new transmissions.

(ACK || max RTX exceeded) && (UE made a “correct” transmission)*

Send a fake ACK to this UE to stop further retransmissions and mark for

“adaptive” retransmission

Else if UE made an “incorrect”transmission*

Attempt synchronous retransmission: lte_enb_as_ul_frame_harq_implicit_rtx_process()

Else

For each open “segment”, attempt adaptive retransmission:

lte_enb_as_ul_frame_harq_explicit_rtx_process()

Failed due to collision with another RTX or RACH

Send a fake ACK to stop retransmission Send NACK and a grant for RTX with NDI = 0

Failed Succeeded

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

Send NACK. The UE will retransmit

implicitly

Else

Understanding LTE Opnet

Documents

Transcript of Understanding LTE Opnet