Understanding LTE Model Internals and Interfaces

Session 1581Understanding LTE ModelInternals and InterfacesR&D Solutions for Commercial andDefense NetworksCONFIDENTIAL ─ RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in anyCONFIDENTIAL ─ format RESTRICTED without the ACCESS: prior written This information consent of OPNET may not Technologies, be disclosed, copied, Inc. or transmitted in anyformat without © the 2007 prior OPNET written Technologies, consent of OPNET Inc. Technologies, Inc.© 2010 OPNET Technologies, Inc.

1581 Understanding LTE Model Internals and InterfacesAbstractCONFIDENTIAL ─ 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 InterfacesBrief 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• Doesn’t fully comply with the IMT Advanced 4G requirements.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.3

1581 Understanding LTE Model Internals and InterfacesOPNET's Model Development Consortia• LTE Model Development Consortium• Prominent network equipment manufacturers, service providers, defenseorganizations• 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, DoCoMoEuro-Labs, InterDigital, NIST, Samsung, and Sony• Successful past consortia• WiMAX, UMTS, MANET, MPLS, and DOCSISCONFIDENTIAL ─ 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.4

1581 Understanding LTE Model Internals and InterfacesLTE 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 andcircular buffer rate matching algorithm for eachmodulation and coding scheme (MCS)• Multiple path loss models• Multipath channel model for uplink anddownlink• Interference on data channels from other data andcontrol channels• Intra- and inter-cell interference• HARQ• Synchronous retransmissions with implicit grantson uplink• Asynchronous retransmissions on downlink• Type-II incremental redundancy• ACK to NACK and NACK to ACK errormodeling• MAC• GBR/Non-GBR EPS bearers• Logical and Transport Channels• Random Access Procedure• Frame generation and Scheduler• MAC• Scheduling Requests• Buffer Status Reporting• Admission Control• RLC• Acknowledged, Unacknowledged andTransparent Modes• Segmentation of retransmitted PDUs in case ofsmall grants into PDU segments• Configurable RLC parameters for each radiobearer for each direction• PDCP: Compression for TCP/IP and UDP/IPheaders• EPS Mobility Management (EMM)• EPS Session Management (ESM)• S1 Signaling and EPS BearerSetup/Modification/Release• General• Efficiency mode to disable PHY layer• Tagged EPS/radio bearer related statistics• 3 and 6 sector eNodeBs• Router UE nodeCONFIDENTIAL ─ 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.5

1581 Understanding LTE Model Internals and InterfacesLTE Model Proposed Roadmap*Future Phases – Subject to Change Based on Customer Requirements• Phase-III: Channel DependentModulation and Scheduling• 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 handoverwith and without X2 support• GGSN services by EPC to legacy SGSNs• Application Delay Tracking• Multimedia Broadcast Multicast Service(MBMS)• Other features• MIMO• 2x2• Spatial multiplexing• IPv6 support• Device Creator support• Power savings• LTE_IDLE state• PCCH and PCH• Dynamic failure/recovery of basestations* This information is provided for planning purposes only and is subject to change without notice. This does not represent acommitment by OPNET to deliver any or all capabilities in any particular timeframe.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.6

1581 Understanding LTE Model Internals and InterfacesAgenda• 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• 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• Documentation ReferencesCONFIDENTIAL ─ 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.7

1581 Understanding LTE Model Internals and InterfacesTypical Modeled Network ArchitectureUE withcomplete TCP/IPstackeNodeBs (1, 3 and 6 sectors)Evolved Packet CoreNetwork withIP/GTP SupportCONFIDENTIAL ─ 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.8

1581 Understanding LTE Model Internals and InterfacesData Traffic Flow in LTE Networksuplink dataon radiobearercorresponding GTP tunnel carrying uplink datadownlink data in GTP tunnelIP packets entering the LTE networkare mapped to GTP tunnelscorresponding radio bearercarrying the downlink dataGTP Encapsulation/DecapsulationEPS BearerRadio BearerS1 BearerCONFIDENTIAL ─ 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.9

1581 Understanding LTE Model Internals and InterfacesSimulation 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_gtwyCONFIDENTIAL ─ 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.10

1581 Understanding LTE Model Internals and InterfacesUE NAS• Initiates the attachment procedure to the network (EPC)• Controls activation/deactivation of EPS bearers depending upon trafficactivity• While the EPS bearer is setup, data packets mapped to that bearer are queuedlte_ue_nas.pr.mSends ESM “modifydedicated EPS bearerREQUEST” message to EPCSends ESM “Activatededicated EPS bearerACCEPT” message to EPCSends ESM “Deactivatededicated EPS bearerACCEPT” message to EPCFlushes the buffer of aninactive EPS bearerCONFIDENTIAL ─ 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.12

1581 Understanding LTE Model Internals and InterfacesUE 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 datalte_ue_as.pr.mSteady state – connectedto an eNodeBRequests bandwidth usingPUCCHRequests bandwidth usingRACHCONFIDENTIAL ─ 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.13

1581 Understanding LTE Model Internals and InterfacesUE 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 isreceived or the timer expireslte_rach.pr.mAwaiting random access response messagefrom the eNodeBAwaiting initial preambletransmissionAwaiting contention resolution message fromthe eNodeBCONFIDENTIAL ─ 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.14


1581 Understanding LTE Model Internals and InterfaceseNodeB 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 thecore sidelte_s1.pr.mCommunication FROMthe core sideCONFIDENTIAL ─ 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.16

1581 Understanding LTE Model Internals and InterfaceseNodeB 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 thewireless medium• Performs scheduling of traffic on radio resources• Manages uplink/downlink HARQ retransmissions.• Receives Uplink MPDUs and sends Downlink MPDUs• Performs HARQ and RLC retransmissions for Downlink MPDUs in errorlte_enb_as.pr.mUL/DL framing – everyTTI (1 ms)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.17

1581 Understanding LTE Model Internals and InterfacesEPS BearerActivation/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 theradio level at the eNodeB• Bearers can also be preempted, in which case, they are torn down from thesystem in a similar way as the inactive bearers• Modification:• Modification of the bearer’s QoS parameters is defined at the higher layer in thestandard (NAS)• In OPNET, QoS parameters are not modified at the EPS or radio level, althoughbearer modification message is used when it is rejected at the setup• In lab 1, bearer modification will be achieved at the radio layerCONFIDENTIAL ─ 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.18

1581 Understanding LTE Model Internals and InterfacesAdmission 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 admittedby looking at the available radio resources• If the bearer can be admitted, the eNodeB AS exchanges RRC messages with the UEAS• 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 isactive• Finally, the core network starts sending traffic mapped to this bearerCONFIDENTIAL ─ 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.19

1581 Understanding LTE Model Internals and InterfacesA Typical Bearer Activation MessageExchange ChartUEeNodeB ASeNodeB S1EPC coreUE receivesESM bearerACTIVEmessageAdmission control:Decision = ADMITRRC Reconfiguration:(RB ID)RRC ReconfigurationAccept: (RB ID)Translator for the AS:(command: Activate,RB ID, QoS profile)Translator for the S1:(command: Activate,EPS ID)ESM bearer activationmessage: EPS ID, QoSprofileESM bearer activationACCEPT message:EPS IDDownlink traffic arrivesAdmission controlcan preempt a lowerpriority bearer in theprocessTranslator for the S1:(command: Release,EPS ID)ESM bearerdeactivationREQUEST message:EPS IDBegin sending downlinktrafficBegin the bearer deactivation process by sending the ESM bearerdeactivation, which will eventually be communicated via RRC messagesto the appropriate UE.The radio side of each GBR EPS bearer goes through admission control. The code isimplemented in lte_admit_control_support.ex.cCONFIDENTIAL ─ 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.20

1581 Understanding LTE Model Internals and InterfacesBearer Activation: UE Initiated CaseUEeNodeB ASeNodeB S1EPC coreUplink trafficarrivesESM bearer resource modification requestBegin the bearer activation process using the same messaging as was usedin 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 exceededCONFIDENTIAL ─ 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.21

1581 Understanding LTE Model Internals and InterfacesLab 1: Admission Control Customization•Objectives•Understand how the admission control algorithm monitors radioresources and admits/rejects/preempts radio bearers•Customize the admission control algorithm with a certainobjective•Analyze the admission control logic using detailed traces andstatistics•Time: 40 minutesCONFIDENTIAL ─ 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.22

1581 Understanding LTE Model Internals and InterfacesLab 1: Take away points•OPNET supports dynamic activation, and deactivation of EPSbearers•It is possible to modify the bearer QoS at the radio level• It is possible to easily interface with the admission control module withoutneeding 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 modificationprocess. The bearer QoS is changed locally at the eNodeB AS. Ideally, sucha change would trigger the EPS modification message, but it is notimportant for our purposes, and hence not modeled• Using detailed traces and statistics, the admission control module can be easilyanalyzedCONFIDENTIAL ─ 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.23


1581 Understanding LTE Model Internals and InterfacesEPC• 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 performtunnel encapsulationlte_s1_nas.pr.mCONFIDENTIAL ─ 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.25


1581 Understanding LTE Model Internals and InterfacesGlobal LTE Config Attributes• EPS bearers• Each UE that configures anEPS bearer with this nameborrows the QoS configuredhere• Efficiency attributes• Can run a simulation withoutneeding PHY effects• Ideal for capacitystudies/error free channelconditions• PHY profiles• Each profile should beconfigured with both UL/DL• The channel bandwidthinfluences the capacity of thechannel the mostCONFIDENTIAL ─ 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.27

1581 Understanding LTE Model Internals and InterfacesLTE 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 thenormal or extended cyclic prefix is employed.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.28

1581 Understanding LTE Model Internals and InterfacesLTE Frame Structure in FrequencyDomain• A resource block consists of 12 subcarriers,each 15 kHz wide• A pair of two Resource Blocks (RBs) isthe minimum allocation unit used by thescheduler while determining theallocations on a frame• The pairing is in time domain, making theallocation unit one subframe (1 ms) in length• The term transport block (TB) is sometimesused for the pair. Some resources use the termresource block to refer to the transport block• Downlink reference symbols occupy 4resource elements in each RB• Uplink reference symbols occupy 12resource elements in each RB• This overhead is accounted for whilecomputing the frame capacity for theadmission control procedureCONFIDENTIAL ─ 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.29

1581 Understanding LTE Model Internals and InterfacesLTE 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 ineach subframe• The standard (36.213) provides a table (7.1.7.2.1-1) of mapping between number of RBsand 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 REsper 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 ofthe channel capacity• A capacity estimate used by the admission control module is also given separatelyCONFIDENTIAL ─ 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.30

1581 Understanding LTE Model Internals and InterfacesDemo 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• How to use OPNET Modeler for planning studies• Map application traffic to GBR bearers and set up a traffic contract to closely match theapplication requirements + lower layer overheads• Admission control: Acts as the first filter in capacity estimation: Find out how many GBRbearers 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 resultsCONFIDENTIAL ─ 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.31

1581 Understanding LTE Model Internals and InterfacesDemo 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 followingcharacteristics should be supported:MCS Index092028Number of UEs161631• 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?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.32

1581 Understanding LTE Model Internals and InterfacesDemo 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 performancewas observed with 33 admissions• Uplink is pretty close to the saturation point• Hence 33 UEs is the best we can do under the circumstances!• Of course there is R&D• You can improve scheduling algorithms…here is an idea: Schedule on theDownlink only if the probability of getting scheduled on the Uplink is high…thisminimizes wastage on the Uplink and it won’t be the bottleneck!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.33


1581 Understanding LTE Model Internals and InterfacesEPS Mobility Management (EMM)• Registration of UEs to the LTE network via EMM Attach procedure ismodeled• An eNodeB can serve multiple EPCs• Once the attachment is completed, UEs remain in the LTE_Activestate, 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 AccessNetwork (E-UTRAN) access".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.35

1581 Understanding LTE Model Internals and InterfacesEPS 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 corenetwork with the following encapsulation headers: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.36

1581 Understanding LTE Model Internals and InterfacesLTE Packet Transmission in OPNETIP TrafficIP PayloadIP PayloadIP PayloadTCP/IP and UDP/IP headercompression (optional)lte_pdcp_pdulte_pdcp_pdulte_pdcp_pduTraffic classificationRLC operation:-Segmentation- Concatenation- Reordering- Re-transmissions-Status reportsClassifier (IP packet EPS bearer)RLC buffer, bearer a RLC buffer, bearer b RLC buffer, bearer a RLC buffer, bearer clte_rlc_amd_pdu lte_rlc_umd_pdu lte_rlc_amd_pdu lte_rlc_umd_pduSchedulerlte_mac_sdu lte_mac_sdu lte_mac_sdu lte_mac_sduFrame Generatorlte_mac_pdulte_mac_pduHARQHARQ process jHARQ process k (≠j)Radio TransmissionSubframe n MPDUSubframe n+1transmissionMPDUtransmissionCONFIDENTIAL ─ 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.37

1581 Understanding LTE Model Internals and InterfacesPDCP 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 forall 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() inlte_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 thecompression job• Compression algorithm: A compression factor generated using aconfigured distribution• Compression 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.cCONFIDENTIAL ─ 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.38

1581 Understanding LTE Model Internals and InterfacesRLC Features• Segmentation and concatenation procedures are performed using a dynamicPDU 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 thehigher layers.• Acknowledged mode—This mode ensures retransmission of missing SDUs in additionto in-sequence delivery of SDUs to the higher layers.• While transmitting PDUs, an RLC entity in acknowledged mode follows this priorityorder: status report PDU > retransmitted PDU(s) > PDU with new data• While retransmitting RLC AMD PDUs, segmentation of the retransmitted PDUs incases 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 anddownlink• Default bearer always uses UM• CCCH transmissions use transparent mode, and TM is used only by CCCHtransmissionsCONFIDENTIAL ─ 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.39

1581 Understanding LTE Model Internals and InterfacesRLC Code• All RLC functionality resides in models/std/lte/rlc_support.ex.c• The 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: Packetscan 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 functions• rlc_support_tx_queue_size_in_bits_get(): Get the size of the queue. This is how thescheduler would know if the queue is empty.• rlc_support_is_tx_window_stalled(): This is important for the scheduler to know. Astalled RLC window is treated the same as empty buffer• rlc_support_lte_min_pdu_header_size_get(): This is important for the framegenerator. If it does not have resources to allocate even the minimum RLC PDUheader, it should not allocate any resources at all.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.40


1581 Understanding LTE Model Internals and InterfacesLTE 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 andexternally 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 thesame process model• RLC functionality: RLC functions are called from this process model• Admission control – Most of the functionality inlte_admit_control_support.ex.c, and the externally callable functions are calledfrom the process model• Uplink received data processing – all functions in the same process modelCONFIDENTIAL ─ 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.42

1581 Understanding LTE Model Internals and InterfacesLTE MAC Implementation Overview: UE•Process model lte_ue_as.pr.m• Child process model lte_rach.pr.m handles random access procedureexclusively• 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 variousradio bearer queues• HARQ functionality – some functionality in harq_support.ex.c and some in thesame process model• RLC functionality: RLC functions are called from this process model• Downlink received data processing – all functions in the same process modelCONFIDENTIAL ─ 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.43

1581 Understanding LTE Model Internals and InterfacesScheduler 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, howbits 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 thecase• Scheduler can recommend “infinity”, and the frame generator will decide exactly howmany bits are served• If the scheduler does specify a finite number, the frame generator treats it as the “upperlimit” of the amount of bits to be served• Frame generator is a client of the scheduler• Very complex…needs to manage multiple RBs per UE, decide termination criterion etc• Can 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.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()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.44

1581 Understanding LTE Model Internals and InterfacesTechnical Paper Published on the LTEConsortium Website•A technical paper describing the framegenerator/scheduler concepts and detailed codedescription/interfaces published on the LTE consortiumwebsite•“LTE Frame Generator and Scheduler Description”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.45

1581 Understanding LTE Model Internals and InterfacesDL Frame Generator Block DiagramFrameGeneratorSchedulerSet Scheduler callbacks (dependingupon the pass)Reset the scheduler (erase transientmemory)Makes group1 currentQ 1Q 2Q 3Q 4Q 5Q 6Group 1 Group 2 Group 3Don’tterminateINVALID Q iGet (Q i , R i ) R i being therecommended bits to serveVALID Q iCalculate N i , the maximum number ofincremental allocation blocks that canbe given to this queue and S i , thecorresponding bits that can be servedAsk the RLC module to return one ormore RLC PDUs not exceeding (S i –MAC overheads)Recalculate N’ i

1581 Understanding LTE Model Internals and InterfacesUnderstanding How to Interface to the DLFrame 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 areblocked, 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 buffer• That’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 “recommendedbits”• Frame generator has the ability to determine termination, reset the scheduler system, potentiallyset different callbacks each time, exclude/include queues in the scheduling process etc!• We recommend you leave the frame generator undisturbed!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.47

1581 Understanding LTE Model Internals and InterfacesDownlink Framing SequenceSet PDCCH symbol times = 3(# of columns anticipated forPDCCH)Create random accessresponses. Adjust number ofRBs available for data.Create CCCH messages.Adjust number of RBsavailable for data.Place HARQ retransmissionMPDUs on the DL. Adjustnumber of RBs available fordata.Schedule new MPDUs. Adjustthe number of RBs availablefor data.More RTX and no more RBsAttempt to resize the PDCCHsize into 1 or 2 columnsNo more RBs AND PDCCH NOT resized alreadyPDCCH resized to 1 or 2 symbolsAttempt to resize the PDCCHsize into 1 or 2 columnsPDCCH cannot be resizedEXITAll buffers empty OR PDCCH resized alreadyCONFIDENTIAL ─ 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.48

1581 Understanding LTE Model Internals and InterfacesSummarizing the Best Practices forInterfacing a Custom DL Scheduler• Most recommended approach: Adhere to the OPNET architecture• Let OPNET’s 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• 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, ifyour scheduling algorithm had different objectives• Output of the DL frame generator• Created MPDUs• UE context, Number of resource blocks, MCS index, Downlink MPDU,HARQ context• Use the trace lte_frm to examine how the frame is constructed• The trace lte_low_level gives detail information about how each MPDU wasconstructedCONFIDENTIAL ─ 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.49

1581 Understanding LTE Model Internals and InterfacesHARQ 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 carryingHARQ process ID, NDI bit and the redundancy version• HARQ retransmission can be scheduled any time at any location on the framestarting from n+8• Technically it can also carry any MCS index, although it is not done bydefault• 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 resourceblock for this UE on PUSCH, which may be reused by the UL frame generatorCONFIDENTIAL ─ 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.50

1581 Understanding LTE Model Internals and InterfacesHARQ Process Management on DL0 1 2 3 4 5 6 7 8 9 10New tx:process 0New tx:process 1NACK:process 0NACK:process 1RTX process0 failed due toinsufficientresources!Can happenfor any ofPDSCH,PUSCH orPDCCHRTXprocess 0succeededRTXprocess 1pushed tonextsubframeRTXprocess 1succeeded• 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 thanthat• It is extremely unlikely that HARQ RTX blocked for 8 consecutive subframes, in which case, an openHARQ process for transmission cannot be found at all!• Appendix D gives a flow chart along with function names showing how DL HARQ retransmissions areservedCONFIDENTIAL ─ 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.51

1581 Understanding LTE Model Internals and InterfacesUL 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 UE’s job• Only creates grants, and understands how many bits could fill the spaceallocated in a grant – The eNodeB knows the UE’s needs from BSRs• Conditionally reuses some grants created by the DL Frame Generator forHARQ acknowledgment purposes• In case the scheduler does not choose such UEs, the UL frame generator isaware 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 andRACH• Function: lte_enb_as_ul_frame_generate()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.52

1581 Understanding LTE Model Internals and InterfacesUplink “Segments”PUCCHSynchronousHARQ RTXRACHSynchronousHARQ RTXPUCCHA typical 5 MHz Uplink Subframe1 block4 blocks6 blocks2 blocks• For every “contiguous segment”, UL framegenerator is run separately• In this example, no UE can get more than 6allocation blocks, although a total of 13 blocks arefree• A UE scheduled in one segment cannot bescheduled again in another segment due toSCFDMA• When all UEs in one segment are scheduled,their bursts are also placed in that segment• Grants created for DL HARQ ACKs can go inany segment in the end. It is guaranteed that ULframe generator will leave enough space toallocate them.• lte_enb_as_frame_ul_frame_for_harq_tx_generate() to enter the whole UL frame generationprocess• lte_subframe_free_prb_segments_create() tofind the number of free segments• lte_subframe_free_prb_segments_next_seg_get() to find the dimension of next free segment (interms of start index and number of alloc.Blocks)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.53

1581 Understanding LTE Model Internals and InterfacesThe Uplink Framing Sequence• Uplink framing is relatively simpler than the downlink framing, sincethe space occupied by the control channels is fixed• PUCCH and RACH allocations are made first• All non-adaptive synchronous HARQ retransmission elements arescheduled next• If an HARQ retransmission collided with RACH, it is fitted in an open“segment” large enough to accommodate it. All such adaptive HARQretransmissions are scheduled next• All msg3 grants given in the random access response (msg2) messagesof the random access procedure are scheduled next• Finally, new grants are given in the remaining open segments to theUEs that are not already under retransmissionsCONFIDENTIAL ─ 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.54

1581 Understanding LTE Model Internals and InterfacesHARQ 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 informationon PDCCH.• Implicit RTX made by UE• Adaptive: The eNodeB may have a valid reason to move the retransmissionsomewhere 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 ona new process• RTX can remain blocked for a long time in pathological cases• Appendix E gives the Uplink HARQ retransmission processing flowchart along with function namesCONFIDENTIAL ─ 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.55

1581 Understanding LTE Model Internals and InterfacesRecapping 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 allocationblocks, Start time, Delay, MCS index)• DL MPDU must not be created if no HARQ feedback mechanism on the UL canbe ensured• If the UE does not have PUCCH in n+4, a UL grant must exist: if the UE has notrequested data, or if the scheduler does not schedule this UE, this grant will consist of aminimum 1 allocation block and will be used exclusively for sending controlinformation (HARQ ACK/NACK)• DL data (PDSCH) and control (PDCCH) space is shared. PDCCH can be resizedto make bigger space for the data• A scheduler can aim to reduce the amount of control channel elements by restricting thenumber of UEs served in the same subframe, which can create more space for downlinkdata• HARQ retransmissions are part of the framing process• For uplink, both non-adaptive and adaptive HARQ retransmissions are supported• For downlink, asynchronous HARQ retransmissions are supported, in which retransmissioncan happen in any subframe >= n+8CONFIDENTIAL ─ 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.56


1581 Understanding LTE Model Internals and InterfacesLab 2: Downlink Scheduler Customization•Objectives•Understand how a custom scheduler function can impact theapplication performance•Monitor control channel overhead and draw inferences•Write and interface a custom scheduler function with a certainobjective to the downlink frame generator•Analyze the performance of the downlink scheduler by usingdetailed traces and statistics•Time: 40 minutes•You can stick around after the session to finish the extra creditportion of the lab if running short of timeCONFIDENTIAL ─ 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.58

1581 Understanding LTE Model Internals and InterfacesLab 2: Take Away Points•Using the frame generator/scheduler architecture, it is simple tointerface custom schedulers to the software• Interface can be minimized to 1 line in the standard models code, whileyou implement a whole new scheduler•Using detailed traces and statistics, the downlink channel can beanalyzed and its impact on the application performance can bereadily explained•Your scheduler function should consider the impact on theDownlink control channel (PDCCH)• Use OPNET’s ability to dynamically resize the PDCCH to implement thescheduler in a way that minimizes the demands put on PDCCH•Refer to Appendix C if you want to interface differently• OPNET code is very easy to interface to, even if you do not follow ourrecommendationsCONFIDENTIAL ─ 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.59


1581 Understanding LTE Model Internals and InterfacesBuffer Status Reporting (BSR) for theUplink 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 whichnew BSRs can be sent, and so on.• When buffers are empty, the UE reports 0 traffic, at which point the eNodeB stopsissuing grants.• However in order to send the BSR, it needs an “initial grant”. There are 2 ways in whichthe UE gets it:• Case 1: UE has a dedicated uplink control channel (PUCCH): In this case, it sends ascheduling request (SR) bit at the first opportunity. The eNodeB issues it a grant of apredefined size, in which the UE can send the BSR.• Case 2: The UE has no dedicated uplink control channel. It this case, it uses therandom 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 hasPUCCH allocation or not.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.61

1581 Understanding LTE Model Internals and InterfacesThe Buffer Status Report ProcessHigher layer data arrivalPUCCH period orRACH timer expiryRequest initial grant using PUCCH or RACHRequest initial grant using PUCCH or RACHSend initial grantSend BSR + Uplink dataBSR retransmissiontimer = typically2560 subframesSend BSR + Uplink DataSend Uplink grantSend Uplink data and more BSR if necessaryCONFIDENTIAL ─ 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.62

1581 Understanding LTE Model Internals and InterfacesThe Random Access Procedure•All UEs use it for initial attachment•UEs without PUCCH allocation use it for sending bandwidthrequests•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• 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() inlte_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 accessprocedure successfullyCONFIDENTIAL ─ 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.63

1581 Understanding LTE Model Internals and InterfacesUplink Grant Processor at the UE•Uses the same scheduler as the eNodeB to allocateresources 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()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.64


1581 Understanding LTE Model Internals and InterfacesThe 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 groupCONFIDENTIAL ─ 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.66

1581 Understanding LTE Model Internals and InterfacesThe 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 modelseasily (lab 3)• Set up transmitter and receiver specific PHY information for easy informationsharing• wrls_phy_tx_info_init_first_phase() and wrls_phy_tx_info_init_second_phase() inwrls_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 nodeCONFIDENTIAL ─ 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.67

1581 Understanding LTE Model Internals and InterfacesSending LTE MPDU via the PHY Interfacelte_mac_pdu created at lte_enb_as.pr.m, lte_ue_as.pr.m, and lte_rach.pr.mlte_support_phy_burst_ici_info_pk_install_from_dci() called to create an ICIof type wrls_phy_mac_interfacePHY extracts the “burst information” from the ICI and prepares the packetfor the PHY transmission in wrls_phy_pk_send() by adding 2 unnamed fieldslte_mac_pdu WrlsT_Phy_Mcarrier_Burst_Info WrlsT_Phy_Chnl_InfoBurst dimensions:Start time,transmission delay,start frequency, endfrequency, PRB startindex, #PRBs etc.Wireless channel information:•WrlsT_Pathloss_Info*•MultipathT_Channel_Instance*•WrlsT_Phy_Antenna_Info*•WrlsT_Phy_Profile*•Stathandles for physical layer•Etc.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.68

1581 Understanding LTE Model Internals and InterfacesThe 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 resourcesin form of a rectangle• Used in interference calculations by determining the overlap between a pairof rectangles• Also pathloss computations need frequency information to compute thepathloss 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 layerprofiles 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.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.69


1581 Understanding LTE Model Internals and InterfacesOverview of PHY Features in Phase II• Support for variable bandwidth• 1.4MHz, 3Mhz, 5Mhz, 10Mhz 15Mhz and 20Mhz• Modeling of physical channels• PDSCH, PDCCH, PRACH, PUSCH and PUCCH• Pathloss models• Freespace, Suburban Macrocell, Urban Macrocell, Urban Microcell, Erceg, Pedestrian and Vehicular• Multipath models• ITU Pedestrian A & B and ITU Vehicular A & B• 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.• HARQ• Type II incremental redundancy• Asynchronous retransmissions on the downlink• Synchronous retransmissions on the uplink• Asynchronous in case of collision of synchronous retransmissions• Disabling PHY layer for faster simulations• Support for antenna modelsCONFIDENTIAL ─ 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.71

1581 Understanding LTE Model Internals and InterfacesPropagation Effects: Multipath andPathloss• Pathloss called from the pipeline wrls_power.ps.c• Function wrls_phy_packet_pathloss_compute() defined inwrls_phy_support.ex.c• “Burst information” of the packet carries the pathloss model configured atthe UE: Can easily be customized (lab 3)• Multipath model called from the pipeline wrls_snr.ps.c• Function 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 theinitialization of the receiver element: wrls_phy_mpath_lte_init_proc()defined in wrls_phy_support.ex.c• The multipath function used for LTE iswrls_phy_mpath_lte_effective_snr_compute() defined inwrls_phy_support.ex.cCONFIDENTIAL ─ 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.72

1581 Understanding LTE Model Internals and InterfacesModulation 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 assumingtransmission of 1 allocation block• A document has been published on the LTE consortium websitedescribing our methodology• Loading the tables in the software• 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• Computing BLER and packet drop probability in PHY• 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 ofsuccessful decoding is (1-p) NCONFIDENTIAL ─ 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.73

1581 Understanding LTE Model Internals and InterfacesPhysical Layer Packet Combining ofHARQ• All packets tagged as “valid” are forwarded to the MAC whether they are decodedcorrectly by the PHY or not• HARQ module is implemented in MAC for its extensive MAC functionality, although its physicallayer 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 ofsuccessive packets. Coding gain – simulated as SNR gain by adding the SNR of the “extrabits” stuffed into the MPDU• Example: MPDU of size 128, corresponding burst has 4 allocation blocks. The maximumbit 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 n th retransmission, drop probability = p *1/n k• k is a configurable parameter – idea is that the drop probability reduces exponentially witheach retransmission attemptCONFIDENTIAL ─ 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.74


1581 Understanding LTE Model Internals and InterfacesLab 3: Pathloss Customization• Objectives• Understand how to implement a custom pathloss model which requires customattributes• Analyze the custom pathloss model with physical layer statistics• Time: 15 minutes• Take away points• Using the generic physical architecture, it is easy to add one’s own customphysical layer algorithms in OPNET• Each UE can be configured with a unique physical environment allowing forthe possibility of simulating UEs in various environments• Using the physical layer statistics, one can readily validate the custom physicallayerCONFIDENTIAL ─ 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.76


1581 Understanding LTE Model Internals and InterfacesDocuments• 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• OPNET Published (LTE consortium website)• 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 DocumentCONFIDENTIAL ─ 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.78

1581 Understanding LTE Model Internals and InterfacesResources 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• OPNET LTE Specialized Model• www.opnet.com/LTE• Access to OPNET LTE Consortium Website• Modeler Product Documentation• Models > Model Library > LTECONFIDENTIAL ─ 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.79

1581 Understanding LTE Model Internals and InterfacesRelated 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 mobilitymodeling, OFDMA transmission framework, MCS curve generationmethodology, interference computations, pathloss models, multipath modelingframework etc.• 1586: Building Realistic Application Models for Discrete EventSimulation• 1576: Verifying Statistical Validity of Discrete Event Simulations• 1550: Accelerating Simulations Using Efficient Modeling TechniquesCONFIDENTIAL ─ 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.80

1581 Understanding LTE Model Internals and InterfacesTake-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 tocustomizeCONFIDENTIAL ─ 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.81

1581 Understanding LTE Model Internals and InterfacesAppendix A: Acronyms• 3GPP: 3 rd 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: 4 th Generation• UMTS: Universal Mobile Telecommunications System• 3G: 3 rd Generation• 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 reQuestCONFIDENTIAL ─ 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.82

1581 Understanding LTE Model Internals and InterfacesAppendix 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• lte_enb_as_dl_mac_sdu_create()• 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 (

1581 Understanding LTE Model Internals and InterfacesAppendix C: What if Your SchedulerDoesn’t Produce the “Next Queue”• Case study: My scheduler already decided all the UEs to schedule andall the associated RBs…I also know how many blocks are given toeach 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 yourown (c_rnti, rb_id), so that frame generator will service your queue insteadof letting the callback choose one for you• When you are done, assign the variable return_ q_id the valueLTEC_SCHED_Q_INVALID for termination• Step 2: Overwrite the calculation of the variables “num_alloc_blocks_ptr”and “small_alloc_blocks_ptr” in the functionlte_enb_as_dl_frame_gen_blocks_and_bits_compute()• “Small allocation blocks” is important to know for subframes withspecial 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 moreresources than what actually exist), things will work fineCONFIDENTIAL ─ 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.84

1581 Understanding LTE Model Internals and InterfacesAppendix D: Handling of DL HARQRetransmissionslte_enb_as_dl_frame_harq_rtx_process()Find all UEs that should have receivedand processed their acknowledgementsby now: (UEs that transmitted at n-8, andall NACKed UEs that got “pushed” tothe current SF). Find the HARQ contextof the UE.ACK || max RTX exceededElseFree the HARQ process for newtransmissions.Examine if resources are available onPDSCH, PDCCH and conditionallyPUSCH:lte_enb_as_dl_harq_rxmt_dci_obtain()All resources availableElsePerform retransmission in the currentsubframeFind a future subframe for retransmission:No other HARQ process for this UE shouldbe scheduled for retransmission in that SF.lte_enb_as_async_dl_harq_rtx_perform()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.85

1581 Understanding LTE Model Internals and InterfacesAppendix E: Handling of UL HARQRetransmissionslte_enb_as_ul_frame_harq_rtx_process()Find all UEs that transmitted at n-8(ACK || max RTX exceeded) && (UEmade a “correct” transmission)*Else if UE made an “incorrect”transmission*ElseFree the HARQ process for newtransmissions.Send a fake ACK to this UE to stopfurther retransmissions and mark for“adaptive” retransmissionAttempt synchronous retransmission:lte_enb_as_ul_frame_harq_implicit_rtx_process()Failed due to collision with anotherRTX or RACHFor each open “segment”, attempt adaptiveretransmission:lte_enb_as_ul_frame_harq_explicit_rtx_process()ElseSend NACK. TheUE will retransmitimplicitlyFailedSend a fake ACK to stop retransmissionSucceededSend NACK and a grant forRTX with NDI = 0*Incorrect transmission: An incorrect transmission is a consequence of the following scenario: ACK to NACK and lost grant fornew data. In this case, the UE retransmits using a previous grant instead of doing a transmission using the new grant. In realsystems, HARQ/PHY can detect this by noting reception of a packet on wrong frequencies.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.86

Understanding LTE Model Internals and Interfaces

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?