Lte model drx

1—LTE

OPNET Modeler/Release 17.5 LTE-1-1

1 LTE

Long Term Evolution (LTE) is a 3rd Generation Partnership Project (3GPP), all-IP wireless protocol that evolved from GSM. Some of the features that LTE provides are as follows:

• Increased data rates and high efficiency versus pre-4G networks

• Increased signal range with better user response times

• Interoperability with circuit-switched legacy networks

This section includes the following LTE modeling topics:

• LTE Model Features on page LTE-1-2

• LTE Model Assumptions on page LTE-1-59

• LTE Model Limitations on page LTE-1-61

• LTE Model Unsupported Features on page LTE-1-62

• LTE Node Models on page LTE-1-63

• Configuring LTE on page LTE-1-65

• Analyzing LTE Networks on page LTE-1-76

• LTE Reference Documents on page LTE-1-85

1—LTE

LTE-1-2 OPNET Modeler/Release 17.5

LTE Model Features

This section provides a list of the main features available in the LTE model:

• EPS Bearer Definitions

• Service Data Flow Classification on page LTE-1-5

• EPS Session Management (ESM) on page LTE-1-6

• Broadcast and Multicast Traffic on page LTE-1-8

— Multimedia Multicast Broadcast Service (MBMS)

• Packet Data Convergence Protocol (PDCP) on page LTE-1-10

• Radio Link Control (RLC) on page LTE-1-10

• Medium Access Control (MAC) on page LTE-1-11

• Physical Layer on page LTE-1-21

— FDD and TDD Schemes

• Hybrid Automatic Retransmission Request (HARQ) on page LTE-1-38

• Channel Quality Indicator (CQI) and Link Rate Adaptation on page LTE-1-42

• Admission Control on page LTE-1-43

• EPS Mobility Management (EMM) on page LTE-1-45

• eNodeB Failure and Recovery Support on page LTE-1-58

EPS Bearer Definitions

An Evolved Packet System (EPS) bearer is a transmission path of defined quality, capacity, delay, and so on. The following describes support for EPS bearer definitions in the LTE model:

• Up to eight EPS bearers, including the Default bearer, per User Equipment (UE), are supported

• At a minimum, each UE has one non-guaranteed bit rate (Non-GBR) type EPS bearer, which is called the Default bearer

• The Default bearer is established as soon as the UE gets attached to an Evolved Packet Core (EPC)

• Higher layer traffic that could not be mapped to any of the configured EPS bearers is served by the Default bearer

1—LTE


• The following parameters are used to define the EPS bearers and are configurable in the following attribute: LTE Config Node > EPS Bearer Definitions.

— Allocation Retention Priority (ARP)—Used by admission control for GBR bearers only

— Uplink/Downlink Guaranteed Bit Rate (GBR)—For GBR bearers only

— QoS Class Identifier (QCI)—Associates the bearer with a QoS Class Definition. QoS Class Definitions consist of three parameters: bearer (resource) type, L2 packet delay budget, and L2 packet loss budget. The QCI corresponding to each QoS Class Definition is as follows:

The bearer type parameter has two values: GBR and non-GBR. GBR bearers have minimum rate guarantees and are required to go through admission control when their radio bearers are created. Non-GBRs are best effort bearers with no resource guarantees at all.

The L2 Packet Delay Budget (L2PDB) parameter describes the maximum time that packets shall spend transiting through radio link control (RLC) and MAC layers within the network and the terminal. It shall be interpreted as a maximum delay with a confidence level of 98 percent. This parameter is applicable only for GBR bearers.

Table 1-1 Standardized QCI Characteristics 1

QCIResource Type Priority

Packet Delay Budget

Packet Error Loss Rate Example Services

1 GBR 2 100 ms 10-2 Conversational Voice

2 4 150 ms 10-3 Conversational Video (live streaming)

3 3 50 ms 10-3 Real-Time Gaming

4 5 300 ms 10-6 Non-Conversational Video (buffered streaming)

5 Non-GBR 1 100 ms 10-6 IMS Signaling

6 6 300 ms 10-6 • Video (Buffered Streaming)

• TCP-based (e.g., web, e-mail, chat, FTP, point-to-point file sharing, progressive video, etc.)

7 7 100 ms 10-3 • Voice

• Video (Live Streaming)

• Interactive Gaming

8 8 300 ms 10-6 • Video (Buffered Streaming)

• TCP-based (e.g., web, e-mail, chat, FTP, point-to-point file sharing, progressive video, etc.)

9 9

1. Source: 3GPP TS 23.203 "Policy and charging control architecture"

1—LTE


The L2 Packet Loss Rate (L2PLR) parameter describes the maximum ratio of Layer-2 packets that have not been successfully delivered to the peer entity. This parameter is not supported in LTE simulations.

• Values of the EPS bearer parameters listed in this section are among the inputs used by eNodeB schedulers. The parameter values are also inherited by other entities mapped to a given EPS bearer across different sublayers in the LTE system as required (for example, radio bearers and logical, transport, and physical channels).

• The LTE model assumes that complete configurations of all the EPS bearers of the UEs are known by the LTE core network at the beginning of the simulation. Therefore an EPC node will always be able to identify the EPS bearer of arriving downlink data traffic even if that bearer is inactive at that moment and was never activated.

• An EPS bearer and its radio and S1 bearers are created when that EPS bearer has at least one active service data flow (SDF). Note the following:

— Higher layer data packets are queued while the bearers are being created

— Non-GBR EPS bearers are not destroyed or deactivated once they are created

— Requests for radio bearers of GBR EPS bearers go through the admission control procedure, since there will be a certain amount of cell resources reserved for those bearers.

Data flow activity through GBR EPS bearers is monitored. If a bearer becomes inactive for a certain period (configurable via the LTE > Admission Control Parameters > Inactive Bearer Timeout attribute on the eNodeB), then its radio bearer is torn down and the cell resources reserved for it are released. This makes the EPS bearer inactive. When the EPS bearer has at least one active SDF again, then it is re-activated.

If the request to create a radio bearer for a GBR EPS bearer is rejected by admission control, then queued packets of that EPS bearer are flushed (unless they are switched to the Default bearer). Later, if any of that bearer's SDF becomes active again, the radio bearer creation procedure is re-initiated.

Preemption by admission control is also modeled. When the cell is congested, GBR radio bearers with high ARP (low priority) are preempted if that is needed and sufficient to accept a radio bearer request for an EPS bearer with a low ARP (high priority).

When the link adaptation procedure changes the MCS index of the UE based on channel conditions, and if the magnitude of this change exceeds a threshold, resources required by the active GBR bearers of that UE are reevaluated by the admission control entity of its eNodeB. If the new MCS index is lower, the resources needed by the active GBR

1—LTE


bearers of that UE to guarantee the quality of service required by those bearers may not be available anymore in the cell under current load conditions. In that case, the eNodeB may release the bearers, using a procedure similar to releasing a bearer during inactivity or preemption.

Key Concept—Note the following in regard to the implications of reevaluation. (1) One or more lower priority bearers are preempted if the reevaluated bearer requires more cell resources. (2) The reevaluated bearer is released if there are not enough resources to sustain the bearer.

EPS bearers are considered bidirectional. The values of the EPS bearer parameters that do not have a type of “bit rate” are taken into account for both directions. On the other hand, there will be separate values specified for the GBR and maximum bit rate (MBR) parameters for uplink and downlink.

Service Data Flow Classification

The following features are supported for Service Data Flows.

• Support for Traffic Flow Template (TFT)

• End-to-End EPS Bearer Mapping on page LTE-1-6

Support for Traffic Flow Template (TFT)

• One TFT is associated with each EPS bearer and is defined as part of the bearer's configuration at UE nodes in the following attribute: LTE > EPS Bearer Configurations > TFT Packet Filters

• Multiple packet filters can be defined per TFT. Each filter can be uplink only, downlink only, or bidirectional.

• Each packet filter specifies an IP Service Data Flows (SDF) based on one of the following:

— Type of service / traffic class

— Source IP address (host or network)

— Destination IP address (host or network)

— Protocol

— Source port (single value or range)

— Destination port (single value or range)

• SDFs with no matching filter under any EPS bearer use the Default bearer

• SDFs with matching filters for which the corresponding EPS/radio bearer is rejected by admission control may use the Default bearer instead of being dropped. This can be specified by setting the corresponding attribute while configuring the EPS bearer at UE nodes.

1—LTE


End-to-End EPS Bearer Mapping

In the uplink direction, the data messages are routed into the corresponding EPS bearer and EPS bearer subcomponents by using the following mapping:

• UE: SDF—>TFT. At the UE the SDF information (e.g. ToS, source port, etc.) is mapped to a TFT.

• UE: TFT—>RB-ID. For any given TFT there is a corresponding RB-ID that identifies the radio bearer which transports the user data over the radio to the eNodeB.

• eNodeB: RB-ID—>S1-TEID. For a given RB-ID at the eNodeB a tunnel ID on the S1 interface is available towards the EPC.

In the downlink direction, the data messages are routed into their corresponding EPS bearer and EPS bearer subcomponents by using the following mapping:

• P-GW (EPC): SDF —>TFT. At the EPC the SDF information (e.g. ToS, source port, etc.) is mapped to a TFT.

• P-GW (EPC): TFT—>S1-TEID. Any given TFT in the EPC has a corresponding tunnel ID on the S1 interface that transports the data traffic towards the corresponding eNodeB.

• eNodeB: S1-TEID—>RB-ID. Once the data traffic reaches the eNodeB the S1 tunnel ID is mapped to a corresponding RB-ID, which is the radio bearer that will deliver the data traffic to the corresponding UE.

EPS Session Management (ESM)

The following topics are covered in this section:

• EPS Bearer Creation/Activation

• GTP Tunneling Between eNodeB and EPC Nodes on page LTE-1-7

EPS Bearer Creation/Activation

The EPS bearer creation/activation is modeled based on Figure 5.4.1-1: “Dedicated Bearer Activation Procedure” in 3GPP TS 23.401, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”. If the UE wants to trigger creation or activation of a bearer, the UE communicates with the PCRF entity in the EPC node using an ESM Bearer Resource Modification Request message, and from that point on, the same procedure is executed to create or activate the requested EPS bearer.

1—LTE


The procedure used to deactivate GBR-type EPS bearers and their radio bearers is implemented based on Figure 5.4.4.2-1: “MME initiated Dedicated Bearer Deactivation Procedure” in 3GPP TS 23.401 “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”. The procedure is initiated by eNodeBs. An eNodeB deactivates a GBR bearer and frees its radio resources either due to inactivity of the bearer or to admit a higher priority GBR bearer (for example, because of preemption triggered by admission control).

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 shown below:

Figure 1-1 GTP Tunneling Between eNodeB and EPC No des

IP datagrams are sent through the corresponding GTP tunnels in the LTE core network with encapsulation headers as illustrated in the figure below.

Figure 1-2 IP Datagram Encapsulation Over GTP Tunn el

• The IP ToS value for the outer IP header inside the GTP tunnel is inherited from the IP ToS value of the original IP datagram sent by the user (that is, the value contained in the inner IP header).

1—LTE


• GTP-C is used instead to model the control plane between the UE, eNodeB, and MME (S1-C interface). A pair of GTP tunnels (one uplink and one downlink) is therefore established between the eNodeB and EPC for each UE that is registered in the network in order to carry the management messages to and from that UE.

• The S1-TEID uniquely identifies a GTP tunnel, and due to one-to-one mapping between S1-TEIDs and RB-IDs, the S1-TEID also forms the association between a GTP tunnel and its radio bearer (RB-ID)

Broadcast and Multicast Traffic

Downlink broadcast and multicast traffic are supported.

Broadcast Traffic

Broadcast packets received at the EPC are forwarded to all eNodeBs (served by the EPC) and UEs in the subnet only if the destination address is the broadcast IP address of that EPC subnet.

Multicast Traffic

The Multimedia Broadcast Multicast Service (MBMS) model is supported to provide delivery of multicast traffic to the UEs.

The following components of MBMS are supported:

• MBSFN Area Profiles—(Multi-Media Broadcast over a Single Frequency Network) An MBMS area includes the definition of the frame resources reserved for MBMS services and the list of MBMS bearers that will use those resources. MBSFN Area profiles are defined in the LTE Configuration Utility attribute “MBSFN Area Profiles” and can be associated with any eNodeB by setting this attribute on the eNodeB: LTE > MBMS > MBSFN Area.

The common allocation period defines the frame and subframe patterns of the reserved resources. The common allocation period is configured in the LTE Configuration Utility attributes MBSFN Area Profiles > Common Subframe Allocation and MBSFN Area Profiles > Common Subframe Allocation Pattern.

• MBMS Bearers—The MBMS bearers belonging to a given profile are defined in the attribute MBSFN Area Profiles > MBMS Bearer List. For each MBMS bearer, you must specify an IP multicast address. This IP multicast address must match the address associated with the multicast application deployed to the UEs. IP multicast addresses should not be repeated across different MBSFN area profiles.

Note that allocation of the MBMS bearers into the common allocation period is done by the simulation, based on the bearer's attributes (downlink maximum bit rate, allocation delay, and modulation and coding scheme index). The allocation of each MBMS bearer is distributed across multiple frames occupying a maximum of one subframe per frame. This allows the simulation to evenly distribute the delay of the radio subframes occupied by

1—LTE


each MBMS bearer, although a single MBMS bearer may be prevented from occupying the full capacity that an MBSFN area may offer. Given that a maximum of six subframes per frame can be used by MBMS services (if configured accordingly in the common subframe allocation pattern), then the full capacity of an MBSFN area can be achieved by configuring six MBMS bearers in that area (assuming all six subframes are in use).

• MBMS Single Frequency Network (MBSFN)—MBSFN enforces synchronization of all MBMS transmissions across all eNodeBs that are configured under the same MBSFN area profile. Transmissions are synchronized in both time and frequency, creating a macro-diversity effect on which MBMS packets sent from different eNodeBs—within the same MBSFN area—do not interfere with each other. Instead, the eNodeBs reinforce each other due to a combining gain.

The model supports a time synchronization mechanism that aligns the multicast data packets so they are sent at the same subframe time by all the eNodeBs using the same MBSFN area profile. To accomplish this, each MBSFN area profile has an attribute called “Synchronization Delay”. The data packets will be considered for transmission by the eNodeBs on the next MBMS subframe after the delay indicated by this attribute. If the delay of an MBMS packet between the EPC and an eNodeB is greater than the synchronization delay, then that data packet will be dropped.

• IGMP Snooping—eNodeB and EPC nodes use IGMP join messages sent by the UEs to “activate” the corresponding MBMS bearers and the pre-allocated resources for each MBMS bearer. IGMP leave messages are used to “deactivate” the MBMS bearers and their resources. The unused subframes can then be used by DSCH to transport non-GBR unicast traffic.

• MBMS Gateway—The MBMS gateway functionality is located at the EPC node. The EPC node forwards multicast traffic in a given MBMS area only to the eNodeBs that are currently serving UEs that have joined a particular MBMS bearer. This forwarding stops when all clients of the MBMS bearer leave the multicast service in that eNodeB. When no more multicast clients are in any eNodeBs, the EPC node stops forwarding to that MBMS bearer.

• Mobility and MBMS—As the UEs with active multicast applications move across the network and change their serving eNodeBs, the MBMS system updates the number of active users of the given MBMS bearers at the eNodeBs and EPC. As a result of the updates, the EPC/MBMS gateway may stop forwarding MBMS traffic to eNodeBs where all subscribers of a given MBMS bearer (or bearers) have left, or start forwarding the MBMS traffic to the eNodeBs where the active subscribers are now attached. eNodeB failure will cause the interruption of MBMS services on that eNodeB.

• Multi-sector eNodeBs support MBMS services, although all sectors in the eNodeB must be subscribed to the same MBSFN area. Then multi-sector eNodeBs' MBMS configuration can be found independently from the LTE sectors' attributes, under LTE > MBMS.

1—LTE


• Multicast packets that are received at the EPC (when MBMS is not configured) are forwarded to all eNodeBs and UEs in the subnet. When a UE is not a member of the given multicast group, it simply ignores the transmission. If the EPC receives packets for a multicast address not associated with any of the MBMS bearers in the MBMS area, the multicast traffic is broadcast to all eNodeBs and UEs in the subnet without using MBMS resources.

Note—You must configure IP multicast in your network before you can run LTE multicast operations in the network model. See IP Multicast for more information.

Packet Data Convergence Protocol (PDCP)

The PDCP layer in the model supports transfer of uplink and downlink packets during normal operation and during re-establishment. The model performs assignment and maintenance of sequence numbers, header compression/decompression, duplicate detection, and packet-dropping based on the discard timer.

During PDCP re-establishment, the model performs in-sequence delivery of PDUs to the higher layer, and for bearers mapped on RLC AM, unacknowledged packets are retransmitted to the lower layer.

A constant 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 arriving in the LTE layer of the corresponding LTE nodes. The header compression ratio is estimated based on a probability distribution function.

PDCP header compression parameters specified in 3GPP TS 36.323 are configurable at the UE and eNodeB nodes via the attribute LTE > PDCP Compression. Compression ratios for UDP/IP and TCP/IP are configured separately.

Radio Link Control (RLC)

Segmentation and concatenation procedures are performed using a dynamic PDU size that is determined by the scheduler decisions (allocation sizes) based on the subframe capacity and relative priorities of the radio bearers with non-empty transmission queues.

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.

1—LTE


• 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 data

— Upon successful delivery of higher layer PDUs, an indication is sent to the PDCP layer

— Upon reaching the retransmission threshold, an indication is sent to the higher layer

— While retransmitting RLC AMD PDUs, segmentation of the retransmitted PDUs in cases of small maximum allowed PDU sizes is supported

RLC parameters specified in 3GPP TS 36.322 are configurable in the attribute LTE > EPS Bearer Configurations > Radio Bearer RLC Configuration.

Signaling radio bearers (SRBs) use RLC acknowledged mode (AM). The RLC mode of the data radio bearers is configurable separately for uplink and downlink, and the selection is between unacknowledged mode (UM) and AM, with the exception that the Default bearer always uses UM. Only CCCH transmissions use transparent mode, and all CCCH transmissions use this mode.

The model supports the RLC re-establishment procedure as specified in section 5.4 of 3GPP TS 36.322.

Medium Access Control (MAC)

This section describes LTE model support for the MAC layer and includes the following sections:

• Channel Mapping

• Random Access Procedure on page LTE-1-13

• Scheduling Requests on page LTE-1-13

• Buffer Status Reporting (BSR) on page LTE-1-13

• Frame Generation and Scheduler on page LTE-1-14

• Discontinuous Reception (DRX) in Connected Mode on page LTE-1-16

• Channel Dependent Scheduling on page LTE-1-15

1—LTE


Channel Mapping

• Mapping of EPS/radio bearers into logical channels is performed

• Mapping of logical channels into transport channels is performed

The following table shows the logical channels that are modeled together with their transport channels and usage:

The “starting” modulation and coding rate of the UE for both DL-SCH and UL-SCH is determined by the “Modulation and Coding Rate” attribute configured on the UE. If the simulation is run in the efficiency mode “PHY Disabled”, this MCS index does not change during the simulation duration. Otherwise, the MCS index for each UL-SCH and DL-SCH adapts itself depending upon the channel conditions.

• MCS index values and their mapping to TBS indices are based on table 7.1.7.1-1 for PDSCH and table 8.6.1-1 for PUSCH in [36.213]

• The transport block size, in bits, is determined by applying the TBS index (ITBS) and the number of transport blocks (NPRB) in table 7.1.7.2.1-1 of [36.213]

Between each UE and its eNodeB, SRB0 and SRB1 are the radio bearers of CCCH and DCCH, respectively. There is a separate radio bearer for the Default bearer and each active EPS bearer.

Table 1-2 Mapping of Logical Channels to Transport Channels

Direction Logical Channel Transport Channel Usage

Downlink Common Control Channel (CCCH)

Downlink Shared Channel (DL-SCH) Control messages sent before UE's RRC connection

Dedicated Traffic Channel (DTCH)

Downlink user data

Dedicated Control Channel (DCCH)

Downlink control information

Uplink Common Control Channel (CCCH)

Uplink Shared Channel (UL-SCH) Control message sent before RRC connection

Dedicated Traffic Channel (DTCH)

Uplink user data

Dedicated Control Channel (DCCH)

Uplink control information

1—LTE


Random Access Procedure

Random access procedure is implemented as follows:

• A UE MAC uses random access procedure to send CCCH messages to eNodeB until the setup of the RRC connection during the network attachment is complete, and to send buffer status reports to eNodeB if the UE does not have any slot assigned on PUCCH to transmit scheduling requests.

• Number and format of random access (RA) preambles, number of RA resources per frame, the values of RA related timers, and maximum back-off duration are attributes of each eNodeB, and these are retrieved and used by the eNodeB's UEs.

The relevant attributes are in LTE > Random Access Parameters on eNodeBs. For TDD mode, the set of random access parameters configurable for each type of physical profile is restricted. If you configure random access attributes that cannot be used for the given TDD physical profile, the parameters are changed internally and a DES log message notifies you of the change.

Scheduling Requests

A UE MAC can make Scheduling Request (SR) transmissions in order to request UL-SCH resources for new uplink transmissions when the surrounding UE has slots assigned on PUCCH for this purpose.

Buffer Status Reporting (BSR)

Buffer Status Reporting is configurable on eNodeB in the following compound attribute: LTE > Buffer Status Report Parameters

• Short and long BSRs are supported

• Regular, periodic, and padding BSRs are implemented

• The mapping of the bearers to the four Logical Channel Groups (LCGs) for the purpose of buffer status reporting is based on the QCI values of the bearers. The QCI-to-LCG mapping is as follows:

Table 1-3 QCI-to-LCG Mapping for Buffer Status Rep orting

LCG QCI Values Description

0 0, 5 This LCG represents the signaling bearer (QCI 0) and the high priority non-GBR bearers (QCI 5)

1 1, 2, 3, 4 Used for GBR bearers

2 6, 7, 8 Used for non-GBR bearers, except the Default bearer

3 9 Used for non-GBR Default bearer

1—LTE


Frame Generation and Scheduler

A common scheduler is used for the following tasks:

• At eNodeBs, while generating the MPDUs of a downlink subframe

• At eNodeBs, while creating the uplink grants for an uplink subframe

• At UEs, while filling an uplink grant with the data of active bearers

The scheduler operates based on the following main rules:

• Signaling bearers (that is, bearers carrying protocol packets) have higher priority over data bearers

• GBR bearers have priority over non-GBR bearers. One exception is that non-GBR bearers with a QCI of “5” have higher priority over GBR bearers.

• Frame capacity is expected to be sufficient to handle all the GBR bearer traffic, since their radio bearers are accepted only through admission control. The scheduling algorithm used for servicing the GBR bearers is proportional fair scheduling, which guarantees a minimum transport of the bit rate specified in the EPS bearer contract with delays below the values that are specified in Table 1-1 on page LTE-1-3. Traffic contract for an uplink logical channel group is the combination of the individual traffic contracts of its GBR bearer members. The combined bit rate is the sum of the individual bearers' bit rates. The combined delay is the minimum of the individual bearers' delays.

— The remaining frame capacity is given to non-GBR bearers. The non-GBR bearers are serviced using a fairness scheduling scheme, in which available resources are shared equally among bearers with data when they have the same QCI.

• In some cases, GBR bearers have traffic that exceeds their contract due to underestimation of RLC and MAC layer overheads or due to a higher than expected load from higher layers. In such cases, the excess traffic of GBR bearers are served by the scheduler the same way the traffic of non-GBR bearers is served but only after all the traffic of regular non-GBR bearers is handled.

— The frame generator is run in every subframe for the FDD mode. For the TDD mode, the frame generator is run only when the present subframe is downlink. Grants for future uplink subframes are signaled in the present downlink subframe. For the FDD, grants are signaled for an uplink four subframes from now. For the TDD, this is determined by Table 10.1-1 in standard [36.213].

1—LTE


• While creating a subframe, the frame generator at eNodeB services the pending Random Access Responses (RARs) as the highest priority by placing them into the DL subframe and creating the corresponding UL grants within the UL subframe. Queued CCCH messages are placed into the DL subframe as the second highest priority. From that point on, the scheduler is used to fill the rest of the subframes.

— Pending RARs that could not be served in the next subframe are not queued for the following subframes, and they are discarded.

• The DL subframe is shared between the Physical Downlink Control Channel (PDCCH) and the Physical Downlink Shared Channel (PDSCH). OPNET's frame generator algorithm supports flexible resizing of the DL control channel. PDCCH can take anywhere between one and three symbol times, with the exact number depending on the number of control channel elements (CCEs) in that subframe. If PDCCH is resized to one or two symbol times, extra space is created for PDSCH, which can then be used to send more data.

• The eNodeB UL scheduler services individual uplink logical channel groups; however, allocations in a subframe for all the bearers belonging to the same UE are provided to the UE as a single uplink grant.

For more information about frame generation and scheduling as it relates to HARQ, see Hybrid Automatic Retransmission Request (HARQ) on page LTE-1-38.

Note—LTE Consortium members can find the design document for frame generation and scheduling here: http://www.opnet.com/LTE_members/materials/LTE%20Frame%20Generator%20and%20Scheduler.pdf.

Channel Dependent Scheduling

Channel dependent scheduling is supported. LTE uses channel variations as input to the scheduler. By taking into account the channel conditions at each time and subband, the scheduler has the option of scheduling UEs in their preferred subbands.This can improve performance for some UEs, as well as the performance of the overall cell. To perform channel dependent scheduling, eNodeB needs information of each specific subband, which the UEs provide by means of CQI feedback.

See also Channel Quality Indicator (CQI) and Link Rate Adaptation on page LTE-1-42.

http://www.opnet.com/LTE_members/materials/LTE%20Frame%20Generator%20and%20Scheduler.pdf

1—LTE


Discontinuous Reception (DRX) in Connected Mode

DRX in connected mode is a power-saving method that exists in LTE. DRX is a method by which the UE can switch off its receiver for a period of time, thereby saving energy, while remaining in the RRC_Connected state.

Note—For details on how DRX timing is modeled, see DRX Timing on page LTE-1-17.

Values of DRX parameters used in a cell are advertised by the eNodeB. These values can be configured on the eNodeB under LTE > DRX Parameters. The ability to perform DRX procedures is a UE capability and is configured on the UE under LTE > DRX Parameters > DRX Capability. The model also allows UEs to use their own DRX parameters, configured under LTE > DRX Parameters instead of the ones advertised in the cell.

Note—To use the UE-specific parameters, “Use Cell DRX Parameters” must be Disabled on the UE. Otherwise the UE-specific DRX parameters are ignored, and the UE receives the DRX configuration from the eNodeB to which it attaches.

In the following example, the UE will respect the DRX parameters on the eNodeB, because “Use Cell DRX Parameters” is Enabled.

Figure 1-3 DRX Parameters

If the DRX parameters are configured as shown on this UE, it will use the DRX parameters configured on the eNodeB to which it connects.

1—LTE


DRX Timing This section describes the way the DRX timing is modeled. The following figure illustrates DRX timing. Note the significant power savings during DRX Sleep and Active periods, as compared to DRX Inactive periods (when data are being transmitted).

Figure 1-4 DRX Timing

What is the DRXCycle?

Note that the DRX Cycle to which we refer comprises two periods: Active and Sleep. When the UE is configured for DRX but is not running the DRX cycle, then the UE is considered to be in the DRX Inactive (Normal) state.

How is the DRXState of the UE

Determined?

The DRX state of the UE is determined by the following logic:

Note—More detail is provided in the section that follows.

• Normal or DRX Inactive —(Corresponding to the red bands in Figure 1-4.) During the Inactive cycle, the UE either runs the inactivity timer or has uplink data.

1—LTE


• DRX Active —(Corresponding to the yellow bands in Figure 1-4.) During the Active period of the DRX cycle, the UE does not have uplink data.

• DRX Sleep—(Corresponding to the green bands in Figure 1-4.) During the Sleep period of the DRX cycle, the UE does not have uplink data.

UE States duringDRX Operation

Different DRX states are illustrated in Figure 1-4. From this figure, you can understand the relative power consumption based on the DRX state of a UE. This section describes more details of the various DRX states and timers, and the power savings you can expect:

• DRX Inactive/Normal —In the DRX Inactive (or Normal) state, power consumption is highest. The UE enters the Normal state when it either suspends its DRX cycle and starts the inactivity timer or receives higher layer data that needs to be transported to the eNodeB on the uplink.

— An inactivity timer starts after the reception of a packet on the downlink. The length of this timer is set in the attribute “Inactivity Timer (subframes).”

— If the UE receives a new downlink packet while it is running the inactivity timer, the inactivity timer is restarted. You can see this in the figure where the two red bands overlap.

— If no other packets are received before the timer expires, the UE enters the DRX cycle, thus beginning a power savings mode.

— The UE may still enter the Normal state while it is running the DRX cycle (in either an Active or Sleep period) when it receives higher layer data, depending on the setting of the “Wake-Up Policy for Uplink Data” attribute. (More details about this attribute are provided in the description of DRX Sleep, later in this section.) This behavior is characterized by the last red band in Figure 1-4, and the simultaneous operation of the DRX cycle is characterized by the yellow/green bands in the background of the figure.

Key Concept—When a UE is running the DRX cycle but enters the Normal state, as indicated above, no power savings are realized.

1—LTE


• DRX Active—When the UE enters the RRC_Connected state, it starts the DRX cycle that consists of the On duration (when it is in the “DRX Active” period) and the Off duration (when it is in the “DRX Sleep” period). The DRX cycle may be suspended when higher layer downlink data is received (as stated in the “DRX Inactive/Normal” details, above) and is restarted when the downlink activity is silent for the duration of the inactive timer. Note the following:

— The “On Duration Timer” is configurable in subframes, where 1 subframe = 1 ms.

— A noticeable power savings is achieved in the DRX Active period versus the Normal state.

— During the DRX Active period, the UE scans the PDCCH for any downlink control indicators (DCI) that indicate downlink MPDUs to be received from the eNodeB. If such a packet arrives, the UE terminates the DRX cycle and enters the Normal state (shown in red in the figure).

• DRX Sleep—When the “On Duration Timer” expires, if no MPDUs are being received, the UE enters the DRX sleep state (shown in green in Figure 1-4), which provides maximum power savings.

— When the UE enters the sleep period, the sleep timer starts.

— During the DRX sleep period, the UE does not receive any downlink data. The eNodeB caches data until the UE enters the DRX Active period again.

— Only the arrival of higher-layer uplink data or the expiration of sleep period will end the short DRX cycle. If the UE receives a new uplink transmission while in the DRX sleep period, one of two actions will occur, depending on the setting of the “Wake-Up Policy for Uplink Data” attribute.

- The UE requests bandwidth immediately, irrespective of the DRX mode (default behavior).

- The UE caches uplink packets and waits until the current DRX sleepperiod expires.

Note— If the eNodeB detects uplink activity for the UE, the eNodeB will take the opportunity to send downlink packets to the UE as well, which can result in lower downlink delays.

— At the end of the short DRX sleep period, the UE enters the DRX active period again and scans for transmissions. You can see this in Figure 1-4.

— If “Use Short DRX Cycle” is disabled, the UE will enter a long DRX cycle instead. (See DRX Long Sleep, below, for more details.)

1—LTE


• DRX Long Sleep —When no MPDUs have been received during the DRX Active period following the short DRX sleep period, the UE enters a long DRX sleep period. The behavior of the UE is the same in both short and long DRX sleep periods. The only exception to this is that the UE runs the long DRX sleep cycle timer during the long DRX sleep periods.

Note—The duration of the long DRX cycle is a product of the value of the “Short DRX Cycle Timer” and the value of the “Long DRX Cycle Multiplication Factor.” For example, if the short cycle is configured for a duration of 20 subframes and the multiplication factor is 4, then the long cycle is 80 subframes in duration.

Power Consumption Measurement on UE

Power consumption during the UE’s operation is configurable in the following attributes under LTE > Operational Power Settings on the UEs.

• Operating Power in Normal State —Specifies the power consumption rate of the UE during the Normal state (i.e., when the UE is fully capable of transmitting and receiving). Default: 100 mW.

• Operating Power in Active State —Specifies the power consumption rate of the UE during the active period of the DRX cycle (i.e., when the UE is running the DRX cycle and is only scanning the PDCCH to detect data intended for the UE). Default: 40 mW.

• Operating Power in Sleep State —Specifies the power consumption rate of the UE during the sleep period of the DRX cycle (i.e., when the UE is running the DRX cycle but is not scanning or transmitting and is not capable of receiving). Default: 10 mW.

In addition, the battery capacity of a UE is used to calculate the remaining battery life on a UE (or at what time during the simulation the battery of the UE is fully consumed) in the Power Consumption Report after a simulation. To configure the battery capacity of a UE, choose LTE > PHY > Battery Capacity.

• Battery Capacity —Specifies the power capacity of the battery for a given device in watt-hours.

At the end of a simulation, output tables display the results. See Power Consumption Report on page LTE-1-82 for more information.

1—LTE


Physical Layer

Packets are transmitted through the air interface, and wireless impairments are considered. Physical layer effects over the transmitted wireless bursts are supported as described in this section. Another purpose of the physical layer implementation is to have a complete configuration of the LTE operational channel to estimate the frame capacity, which is used by the admission control algorithm and the schedulers at the MAC layer of eNodeBs.

The following topics are discussed in this section:

• Frame Structure on page LTE-1-21

• Physical Channels on page LTE-1-24

• Physical Layer Measurements on page LTE-1-25

• Transmission Power on page LTE-1-26

• Power Consumption Measurement for eNodeB on page LTE-1-26Antenna on page LTE-1-27

• Pathloss on page LTE-1-27

• Interference on page LTE-1-27

• Modulation and Block Error Rate on page LTE-1-31

• Multipath Fading on page LTE-1-33

• Multiple-Input/Multiple-Output (MIMO) on page LTE-1-34

• Efficiency Mode on page LTE-1-36

Frame Structure

An eNodeB can deploy a physical profile either supporting FDD (Frequency Division Duplex) or TDD (Time Division Duplex) technology. For FDD, both uplink and downlink need their own spectra for operation, while for TDD, uplink and downlink share the same radio spectrum. The TDD mode provides 7 different configurations to divide the radio resources between uplink and downlink to support asymmetric traffic requirements, and can result in better usage of resources due to its flexibility (see Table 1-5 on page LTE-1-23).

The following parameters define the frame structure, the duplexing scheme, and the operational spectrum:

• Fixed Parameters on page LTE-1-22

• Configurable Parameters on LTE Config Node on page LTE-1-22

1—LTE


Fixed Parameters

• Frame Structure Type: Type 1

— Frame Length: 10 ms

— Subframe length:1 ms

— Slot length: 0.5 ms

• Frequency Domain

— A resource block consists of 12 sub-carriers, each 15 kHz wide. The length of a resource block is one slot.

— A resource element is a tile that is one symbol wide and one sub-carrier high. Therefore a resource block has 84 or 72 resource elements depending on the configured cyclic prefix length.

— A pair of two Resource Blocks (RBs) is the minimum allocation unit used by the scheduler while determining the allocations on a frame. The pairing is in time domain, making the allocation unit one subframe (1 ms) in length.

— Downlink reference symbols occupy four resource elements in each RB of the downlink channel. This overhead is accounted for while computing the frame capacity for the admission control procedure.

— Uplink reference symbols occupy 12 resource elements in each RB of the uplink channel. This overhead is accounted for while computing the frame capacity for the admission control procedure.

Configurable Parameters on LTE Config Node

• Duplexing Scheme—Both Frequency Division Duplex (FDD) and Time Division Duplex (TDD) are modeled. FDD Profiles are configured under LTE PHY Profiles > FDD Profiles and TDD Profiles are configured under LTE PHY Profiles > TDD Profiles.

FDD/TDDParameters

• Bandwidth—Allowed values are 1.4, 3.0, 5.0, 10.0, 15.0, and 20.0 MHz. For FDD profiles, this is configurable under FDD Profiles > UL SC-FDMA Channel Configuration > Bandwidth for uplink and FDD Profiles > DL OFDMA Channel Configuration > Bandwidth for downlink. For TDD profiles, this is configurable under TDD Profiles > TDD Channel Configuration > Bandwidth. The respective number of resource blocks NRB is as follows:

Table 1-4 Channel Bandwidth Parameters 1

1. 3GPP TS 36.101 "User Equipment (UE) radio transmission and reception

Channel Bandwidth BWChannel [MHz] 1.4 3 5 10 15 20

NRB 6 15 25 50 75 100

1—LTE


• Base Frequency—Determines the operational frequency of the channel together with the channel bandwidth. For FDD profiles, this is configurable under FDD Profiles > UL SC-FDMA Channel Configuration > Base Frequency for uplink and FDD Profiles > DL OFDMA Channel Configuration > Base Frequency for downlink. For TDD profiles, this is configurable under TDD Profiles > TDD Channel Configuration > Base Frequency.

• Cyclic Prefix Length—Allowed values include normal cyclic prefix and extended cyclic prefix, which result in seven and six symbols per slot, respectively. For FDD profiles, this is configurable under FDD Profiles > UL SC-FDMA Channel Configuration > Cyclic Prefix Length for uplink and FDD Profiles > DL OFDMA Channel Configuration > Cyclic Prefix Length for downlink. For TDD profiles, this is configurable under TDD Profiles > TDD Channel Configuration > Cyclic Prefix Length.

TDD OnlyParameters

• TDD Channel Index—Determines the "type" of TDD physical profile. Seven types are defined in standard [36.213]. Each type differentiates itself from the others in how the Uplink and Downlink subframes repeat within one frame. This is configurable under TDD Profiles > TDD Channel Configuration > TDD Channel Index.

Table 1-5 TDD Configurations

IndexScheme (Uplink:Downlink) Downlink %

0 3:2 40

1 2:3 60

2 1:41

1. Default value.

80

3 3:7 70

4 2:8 80

5 1:9 90

6 3:3:2:2 50

1—LTE


Figure 1-5 TDD Configurations

• Downlink Symbols in Special Subframes—Determines the number of slots used by the Downlink in "special" subframes. A special subframe is a downlink subframe, which is immediately followed by an uplink subframe. This is configurable under TDD Profiles > TDD Channel Configuration > Downlink Symbols in Special Subframes.

As described above, the FDD and TDD physical profiles are specified on the LTE Attribute Config utility node under the group attribute LTE PHY Profiles. Each physical profile is uniquely identified by its name, which is specified under the sub-attribute Name. To deploy a physical profile on an eNodeB, choose the desired physical profile under the attribute LTE > PHY > PHY Profile. All profiles configured on the LTE Attribute Config node will be available for selection.

Physical Channels

The following physical channels are modeled:

• Primary Broadcast Channel (PBCH)—All messages on this channel are modeled without interference, that is, packet reception is always successful. The following messages are sent on this channel:

— Primary Synchronization Signal (PSS)

— Secondary Synchronization Signal (SSS)

— Master Information Block (MIB)

• Physical Downlink Shared Channel (PDSCH)

— DL data messages

— System Information Block (SIB)

0

1

2

3

4

5

6

1—LTE


• Physical Downlink Control Channel (PDCCH)—Such as downlink L1/L2 control channel

— Transports Downlink Control Information (DCI) messages, which are as follows:

✓ Allocations for RAR messages

✓ Allocations for CCCH

✓ Allocations for unicast uplink and downlink signaling and data messages (from the scheduler)

— While computing the DCI capacity of PDCCH, the overhead of Physical Control Format Indicator Channel (PCFICH) is taken into account

• Physical Random Access Channel (PRACH)

— Contention-based random access is supported

— The number and format of sequences available in the cell that can be used for the random access preamble transmission is configurable via an eNodeB attribute, and the default is 64. The model assumes that each cell has a distinct set of sequence numbers.

— The number of random access resources available in each frame in the cell is configurable using the corresponding attribute of the eNodeB nodes

— Preamble collisions and contention resolution are modeled

— Random Access Channel parameters can be configured in eNodeB attribute LTE > Random Access Parameters

• Physical Uplink Shared Channel (PUSCH)

— UL data messages

• Physical Uplink Control Channel (PUCCH)—Such as uplink L1/L2 control channel

Transmission of scheduling requests (SRs), HARQ ACKs/NACKs, and CQI messages via PUCCH are supported

— PUCCH capacity is configurable via eNodeB’s attribute LTE > L1/L2 Control Parameters > PUCCH Configuration

— When a UE attaches to the network, eNodeB grants a PUCCH allocation to the UE, when available, to be used for SR transmissions. UEs that do not obtain an allocation will use RACH to make a scheduling request.

Physical Layer Measurements

Physical layer measurements of SINR are supported for both UL-SCH and DL-SCH. A measurement entity is created for each UE, which records instantaneous values of SINR and smooths them using a measurement window. Thus, the measurement module computes a moving average and the size of the measurement window can be controlled by configuring LTE >

1—LTE


Link Adaptation Parameters > Measurement Window Size. For more information about this attribute, see Channel Quality Indicator (CQI) and Link Rate Adaptation on page LTE-1-42.

For the downlink, separate measurements are collected for each subband of thedownlink channel, if the scheduler is expected to use Channel DependentScheduling (by setting the attribute LTE > Scheduling Mode on the eNodeB asdescribed in Channel Quality Indicator (CQI) and Link Rate Adaptation). No measurements are collected if the simulation is run in theefficiency mode “PHY Disabled”.

Note—The measurement entity described above is not listed in or required by the LTE specifications but is part of the OPNET Modeler modeling design.

Physical layer measurements of RSRP and RSRQ are supported. A measurement entity for RSRP and another for RSRQ is created for each audible eNodeB, thus the UE continuously measures RSRP and RSRQ for all eNodeBs within range in the operating frequency.

Reference signals are not transmitted or received in the model, therefore RSRP and RSRQ measurements are performed on the PSS/SSS signals. Thus, the physical layer updates RSRP and RSRQ every 5ms.

The physical layer also sends indications to the higher layers if the measured RSRQ (averaged over 200ms) violates configured thresholds.

Transmission Power

Maximum transmission power is configurable in watts (W) via the Maximum Transmission Power attribute under LTE > PHY on the UE and eNodeB models.

Maximum power is the transmission power of the device over the entire LTE channel bandwidth. Actual burst transmissions use a transmission power proportional to its assigned portion of the bandwidth.

Power Consumption Measurement for eNodeB

Power consumption measurement is supported and is configurable in the following attributes under LTE > PHY on the eNodeB:

• Operating Power—User-specified power consumption rate, in watts (W), of non-transmission activities

• Battery Capacity—User-specified power capacity of the battery for a given device in watt-hours. A value of “Unlimited” may be selected for eNodeB devices that are connected to AC power.

1—LTE


Power consumption comprises the sum of the following: total energy consumed by the device for transmission plus non-transmission activities. Power consumption measurement calculates both components and produces a sum at the end of a simulation.

At the end of a simulation, output tables display the results. See Power Consumption Report on page LTE-1-82 for more information.

Antenna

• Single-sector eNodeB models use a default gain of 14 dB at boresight

• UE models use a default gain of -1 dB

You can configure the gain via an attribute, LTE > PHY > Antenna Gain (dBi) or by use of the antenna model. For eNodeBs with multiple sectors, only the antenna model can be used, as it describes the directionality of the antenna on each of the sectors.

Pathloss

Relevant pathloss attributes are configurable under LTE > PHY > Pathloss Parameters on the UE nodes.

Note—Certain pathloss models permit additional customization in the Model Arguments sub-attribute; however, many of the pathloss models are fixed.

For information on the pathloss models, as well as shadow fading, see Pathloss Parameters on page AWP-1-6 in the Advanced Wireless Package section of this user guide.

Interference

The interference model is supported as follows:

• Interference module detects time and frequency overlaps among different bursts

• Interference is proportional to the amount of burst overlap

• Interference may cause burst drops for PUSCH and PDSCH bursts

• Interference effects for control channels are based on a probability distribution function.

— PUCCH, PDCCH, and PHICH may carry different control signals. Errors in the transmission of those signals are based on uniform distribution functions with configurable average values for each type of control signal (e.g., SR, HARQ-ACK, UL-DCI, DL-DCI, and so on) under LTE > L1/L2 Control Parameters on eNodeB.

1—LTE


• Interference is computed among nodes using the same or different LTE PHY profiles

— The frequency attributes of a given LTE PHY profile are accounted for computing interference

— Interference among different cells (e.g., eNodeBs) can be reduced or eliminated by assigning different LTE PHY profiles with non-overlapping frequency bands to each cell

• Burst representation

— PUSCH and PDSCH assumes contiguous resource block allocations for each individual burst (e.g., per UE)

— PUSCH burst duration is one subframe

— PDSCH burst lasts from the end of PDCCH until end of subframe

Modeling Interference Using Jammer Nodes

LTE nodes are compatible with jammer node models. Packet transmissions from a jammer node can interfere with the reception of LTE packets. With jammer nodes, you can realize the effect of interference due to adjacent cells, other wireless technologies or a malicious node. By using jammer nodes instead of LTE nodes to model co-channel interference due to adjacent cells, you can realize the following benefits:

• Reduce simulation time and memory

• Reduce model configuration time (versus configuring many individual nodes)

When should I use ajammer node

model?

The use of single band jammer node is especially recommended when you are trying to model co-channel interference from adjacent cells (see Single-Band Jammer on page WM-12-2). The attributes in a single band jammer model can be configured such that the jammer packet transmissions are similar to the transmission from adjacent interfering UEs or eNodeBs.

Note—To see an example of an LTE network that is configured with jammer node models, open the LTE example project and view the “video_perf_under_coch_interference_w_jammers” scenario.

How is thetransmission time of

a jammer packetconfigured?

The transmission time of a jammer packet is equal to the value of the Jammer Packet Size attribute divided by the value of the Jammer Data Rate attribute. Usually, LTE transmissions (UL or DL) last for a subframe. To configure a jammer node model to cause co-channel interference as if it were another LTE node, configure Jammer Packet Size and Jammer Data Rate attributes such that the duration of a jammer packet is equal to one LTE subframe (1 millisecond).

1—LTE


How is thefrequency band of a

jammer packetconfigured?

The frequency band of a jammer packet transmission depends on the values of the “Jammer Band Base Frequency”, “Jammer Bandwidth”, “Bandwidth UsagePercentage”, and “Transmission Band Position” attributes.

• In FDD, UL and DL subframes are usually configured to operate with different base frequencies, although the total bandwidth is generally the same.

• In TDD, UL and DL subframes operate with the same base frequencies and total bandwidth.

Key Concept—Note the Base Frequency and Bandwidth from the FDD (UL or DL) or TDD profile, and set them in the jammer node model, as depicted in the example shown in Figure 1-6.

The example shown below provides guidance for configuring the jammer node model. Note that the attributes work synergistically to create the interference you wish to model.

Figure 1-6 Example Jammer Node Configuration

Some attributes are further described below. For more information, see Single-Band Jammer on page WM-12-2 in the Wireless Module User Guide.

For example, in this FDD Profile for DL, the Bandwidth is 5MHz, and the Base Frequency is 2110MHz.

To configure the jammer to interfere with DL transmissions: Set the jammer attributes accordingly to simulate this behavior.

- Jammer Band Base Frequency: 2,110- Jammer Bandwidth: 5.0- Jammer Transmission Band Position: Top (since the DL-subframes follow a top-down fashion)

1—LTE


Jammer Bandwidth Usage Percentage In a typical cellular communication system, such as LTE, the entire bandwidth is not always in use; rather, it exhibits random peaks and valleys. When using jammer node models to model interference due to a neighbor UE or eNodeB, you can set the “Jammer Bandwidth Usage Percentage” to reflect a realistic percentage of bandwidth utilized by jammer packet transmissions.

Note—Although you can select “Full Bandwidth” as an option, it is not recommended when a jammer node is used to model interference due to a neighbor UE or eNodeB. Use a distribution instead, to model realistic behavior.

Jammer Transmission Band Position Allows you to configure where exactly the jammer packet should be in the frequency axis.

• In UL subframes, the frequency assignment is performed in a bottom-up fashion. Therefore, when trying to interfere with UL subframes, it is preferable to introduce the jammer packet at the “Bottom” of the transmission band.

• In DL subframes, the frequency assignment is in either a top-down or a bottom-up fashion. Therefore, when trying to interfere with DL subframes, it is preferable to introduce the jammer packet at the “Top or Bottom” of the transmission band.

• For TDD, since there is a mixture of top or bottom, you can also optionally set to "Top or Bottom" setting.

• If you use the “Random” setting, the minimum frequency of the jammer packet transmissions can be anywhere between the Jammer Base Frequency and Jammer Base Frequency + Jammer Bandwidth.

For a thorough explanation and illustration of this concept for the jammer model, see Jammer Bandwidth Band Position on page WM-12-4 in the Wireless Module User Guide.

1—LTE


The following figure shows a typical LTE model with single-band jammers configured to model interference.

Figure 1-7 Jammer Nodes in LTE Model

Modulation and Block Error Rate

Modulation and Coding Scheme The Modulation and Coding Scheme (MCS) Index is configurable via the LTE > PHY > Modulation and Coding Scheme Index attribute on UE nodes and remains fixed during the entire simulation. This attribute does not affect the simulation when the LTE > Scheduling Mode attribute on the eNodeB is set to “Link Adaptation Only” or “Link Adaptation and Channel Dependent Scheduling”. In each of these cases, the MCS index is dynamically changed based on the link adaptation procedure.

Modulation Curves Modulation curves plotting the signal-to-noise ratio (SNR) versus block error rate (BLER) are available for all modulation and coding indices except for modulation and coding index 6. Convolutional turbo coding with circular rate matching algorithm are implemented in obtaining the modulation curves.

Jammer nodes can effectively simulate interference without costing simulation run time.

1—LTE


The modulation curves pertaining to LTE are available in the LTE models directory, <reldir>\models\std\lte, and are name as follows, depending on function, where <x> refers to the modulation and coding index number:

• lte_mcs<x>_bler.md.m—Common to uplink and downlink

• lte_mcs<x>_dl_bler.md.m—Downlink only

• lte_mcs<x>_ul_bler.md.m—Uplink only

The modulation curves can be viewed using the Modulation Curve editor, as described in the following procedure.

Procedure 1-1 View Modulation Curves

1 Choose File > Open in the Project Editor.

2 Select Modulation Curve from the drop-down menu.

3 Select the modulation curve model.

4 Click OK to view the selected modulation curve.

End of Procedure 1-1

1—LTE


Multipath Fading

The model supports ITU Multipath Channel models Pedestrian A, Pedestrian B, Vehicular A, and Vehicular B. You can add more multipath channel models in the LTE configuration node under the attribute “Multipath Channel Definitions”.

Selecting Multipath Fading Definitions in the UE The Multipath Channel Model is selectable on each UE in the following attributes:

• LTE > PHY > Multipath Channel Model (Downlink) and

• LTE > PHY > Multipath Channel Model (Uplink)

By default, LTE OFDMA ITU Pedestrian B and LTE SCFDMA ITU Pedestrian B multipath channel models are configured, respectively.

Defining the Multipath Channel Models You can define multipath channels in the LTE configuration utility node that can be selected on each UE node, as described above. You can either specify the multipath parameters manually or import the parameters from a file.

Figure 1-8 Setting Multipath Parameters on the LTE Config Node

Key Concept—If you create a directory containing custom files (for example, custom probability matrixes or Signal-to-Noise [SNR] mapping functions), you must add this directory to the model directories (mod_dirs) in OPNET Modeler.

Custom probability matrix files and SNR mapping files must be formatted according to the supported type. For example, “mpath_tpm” (Transition Probability Matrix) or “mpath_snr” prefixes must be used in the file names, respectively. These files are text files with the extension gdf, which contain

1—LTE


comma-separated values to indicate each row in the transition probability matrix or the coefficients of each polynomial for the SNR translation functions.

To see an example, look at the input files provided in the following location: <release_dir>\models\std\wireless\wrls_phy_mpath_data_files.

Multiple-Input/Multiple-Output (MIMO)

Two antenna models are supported in LTE: single-input/single-output (SISO) and MIMO. SISO systems permit only one antenna at the transmitter and one antenna at the receiver, while MIMO systems permit multiple antennas to be used, as described in this section.

The model supports MIMO in the following ways:

• Antenna Diversity

• Spatial Multiplexing on page LTE-1-35

Antenna Diversity MIMO Antenna Diversity is supported on both uplink and downlink. Antenna diversity reduces the effect of multipath fading on the SNR of the received signal. Therefore, to use this feature, multipath fading must be enabled.

The following attribute on the eNodeB lets you configure the MIMO method to be used in the downlink. To use antenna diversity in the downlink, Transmit Diversity (default) must be selected.

• LTE > MIMO Transmission Technique

The following attributes on the eNodeB and the UE let you configure the number of transmit and receive antennas.

• PHY > Number of Transmit Antennas

• PHY > Number of Receive Antennas

The following diversity configurations are supported:

Table 1-6 MIMO Antenna Diversity

Antenna Configuration (Transmit x Receive)

1x2 1x4 2x1 2x2 2x4 4x1 4x2 4x4

Downlink ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Uplink ✓ ✓

1—LTE


By default, the eNodeB supports two transmit antennas and two receive antennas, and the UE supports one transmit antenna and two receive antennas.

Spatial Multiplexing Open Loop Spatial Multiplexing using Large Delay CDD (Cyclic Delay Diversity) is supported on the downlink only. Multi-codeword spatial multiplexing used in LTE effectively increases the capacity of downlink transmissions by allowing two simultaneous codeword (MPDU) transmissions, which have the same time and frequency information. The codewords are transmitted by one downlink HARQ process. Two ACK/NACK bits, one per codeword, are transmitted by the UE for acknowledgement purposes.

The following spatial multiplexing configurations are supported:

The following attributes on the eNodeB and the UE let you configure the number of transmit and receive antennas.

• LTE > PHY > Number of Receive Antennas

• LTE > PHY > Number of Transmit Antennas

To enable spatial multiplexing in the cell, one of the spatial multiplexing modes must be selected from the following eNodeB attribute.

• LTE > MIMO Transmission Technique

Note—The MIMO Transmission Technique attribute can also be configured on the UE nodes. For UEs that prefer to use their own settings rather than what is configured in their serving cells, the MIMO Transmission Technique attribute must be set on the UE.

Note— If a UE does not have the minimum required number of receive antennas to support spatial multiplexing (see Table 1-7), the eNodeB will use antenna diversity instead when communicating with the UE.

Table 1-7 Supported MIMO Spatial Multiplexing Conf igurations

MIMO Transmission Technique

Transmit Antennas(eNodeB)

Receive Antennas(UE)

2 Codewords - 2 Layers 2 2



1—LTE


Note the following.

• When MIMO spatial multiplexing is used with the efficiency mode set to “Efficiency Enabled” on the LTE configuration node, only the increase in downlink subframe capacity will be modeled.

• When MIMO spatial multiplexing is used with the efficiency mode set to “Physical Layer Enabled” on the configuration node, both the increase in downlink subframe capacity and the physical layer effects of using MIMO spatial multiplexing will be modeled. However, multipath fading must be enabled on the UE to realize the physical layer effects accurately.

Note—The physical layer effects of using spatial multiplexing may increase the block error rate and therefore the drop probability of a packet at the physical layer.

Each multipath channel definition (shown in Figure 1-8 on page LTE-1-33) is composed of a set of multipath channel models for different MIMO combinations. In the attribute table where these individual channel models are defined, you can also specify the corresponding number of transmit and receive antennas and the MIMO Transmission Technique (highlighted in the figure below) for each of the multipath channel models.

Figure 1-9 MIMO Antenna Diversity Configuration fo r Multipath Fading

Efficiency Mode

Efficiency mode can be enabled and configured in the LTE configuration node under the attribute “Efficiency Attributes”. Efficiency attributes control the mode in which the simulation is run.

• If set to Physical Layer Enabled, each packet goes through wireless pipelines, and all physical layer effects are simulated. This increases accuracy at the cost of simulation speed.

1—LTE


• If set to Efficiency Enabled, packets are directly delivered to the recipient. This mode is useful when the expected average frame drop probability is already known. You can tune various related attributes to cause random packet drops and make the simulation as realistic as possible. In this mode

— Simulation run-times are decreased

— Data frame drops are based on probability distributions (e.g., instead of detailed collision detection)

— Features based on PHY layer modeling (such as Link Adaptation and Channel Dependent Scheduling) are not available

1—LTE


Hybrid Automatic Retransmission Request (HARQ)

HARQ is supported for both uplink and downlink. HARQ support is described in this section.

• Features Common to Uplink and Downlink Support

• HARQ Downlink Support on page LTE-1-39

• HARQ Uplink Support on page LTE-1-41

• Other Model Features on page LTE-1-42

Features Common to Uplink and Downlink Support

The following features are supported in the LTE model for both uplink and downlink:

• Packet Combining—Type II incremental redundancy is supported. To find the SNR and coding gains, we first give the formula for calculating the SNR gains using chase combining only:

Where:

— SINRk denotes the SINR of the packet after combining k retransmitted copies

— and SINR(i) denotes the SINR of ith retransmitted copy

For type II incremental redundancy, we assume that the "additional" bit carrying capacity in transport blocks is used by the parity bits, which provide an extra SNR gain at the receiver. If there are no parity bits, no extra SNR boost is observed, and we get the same gain as in the Chase combining. Thus, type II incremental redundancy performs at least as good as the chase combining in all cases.

The total gain at the receiver is shown below:

• Processing Delays—Each received packet experiences a processing delay. According to the LTE standard, we assume a constant processing delay of 3 subframes for received MPDUs and the same delay of three subframes to process HARQ ACKs/NACKs in both the uplink and the downlink (see Figure 1-10). For FDD, the HARQ round trip time (RTT) is 8 subframes as shown below. For TDD, the HARQ round trip time depends upon the TDD frame type and the subframe in which the transmission scheduled. The

SINRk

SINR i( )

i

∑=

SINRk SINR i( )

i

∑ri s–

s------------SINR i( )

ri

s---SINR i( )

i

∑=

i

∑+=

1—LTE


processing delays are assumed to be “at least” 3 subframe for TDD.

Figure 1-10 MPDU Transmission

• Multiple HARQ Processes—The UE supports multiple HARQ processes to enable parallel transmission for uninterrupted communication.

• Protocol Constants—For FDD physical profiles, at most eight parallel HARQ processes are required for uninterrupted communication to the UE, as shown in the figure below. For TDD, the number of HARQ processes is different for uplink and downlink for each TDD frame type as given in the following table.

HARQ Downlink Support

In addition to support common to both direction, the downlink features supported in the model are as follows:

• Downlink HARQ transmission on LTE channels

— HARQ Process Selection—In downlink mode, an unblocked HARQ process must be found on which to transmit the data. Once an HARQ process is selected, it is signaled on the PDCCH to associate it with the corresponding MPDU(s).

— Multi-Codeword Spatial Multiplexing—If the UE is capable of supporting spatial multiplexing, each HARQ process is then capable of transmitting two codewords simultaneously.

Table 1-8 Number of HARQ Processes for Each TDD Fr ame Type

Index Uplink Downlink

0 7 4

1 4 7

2 2 10

3 3 9

4 2 12

5 1 15

6 6 6

MPDU Transmission

MPDU Processing Delay

MPDU Received ACK/NACK Received

ACK/NACK Processing Delay

1—LTE


• Downlink HARQ scheduler at the eNodeB

— Downlink Scheduler Sequence—The downlink scheduler adheres to the following order: a) Random access response messages, b) CCCH messages, c) All HARQ retransmissions, and d) All new data transmissions.

— Dynamic Retransmissions—All retransmissions are scheduled dynamically. A DCI is created on PDCCH to signal the HARQ process ID for the retransmission element.

Note—Retransmissions are adaptive, and although adaptive modulation and coding is supported, retransmissions by default use the same MCS index as the original transmissions.

• HARQ transmission on LTE channels

— MPDU Transmission—HARQ MPDUs are transmitted on PDSCH. Control information is signaled on PDCCH. The following information is signaled: HARQ process identifier (three bits), New Data Indicator (one bit), Redundancy Version (two bits).

If multi-codeword spatial multiplexing is used, then the above information will be available in PDCCH for each of the two codewords transmitted. If multi-codeword spatial multiplexing is used, then two ACK/NACK bits, one per each codeword, will be generated; otherwise only one ACK/NACK bit will be generated as the response to HARQ transmissions.

— Acknowledgements—Downlink HARQ ACKs are either sent on PUCCH or PUSCH. If no PUCCH resource exists for the UE at frame n+k (where k is 4 for FDD and is given by Table 10.1-1, standard [36.213] for TDD), eNodeB creates a grant with the minimum block size (one allocation block). If the grant is successful, the uplink scheduler can reuse this grant for data transmission. In this case, the HARQ ACK bits will be multiplexed with uplink data.

For TDD, multiple downlink HARQ processes can be ACKed by a single ACK bit per codeword on the uplink. This scheme is called ACK bundling. Table 10.1-1, standard [36.213] details which HARQ transmissions are ACKed on the current uplink subframe. In the worse case (for TDD index 5), up to nine downlink MPDUs can be acked by a single bit.

— Attributes—Maximum Number of Retransmissions (allowable values: 1-9, default: 3).

1—LTE


HARQ Uplink Support

In addition to features common to both directions, the uplink features supported in the model are as follows:

• Uplink HARQ transmission on LTE channels

— Attributes—Maximum Number of Retransmissions (allowable values: 1-9, default: 3).

— HARQ Process Selection—In uplink, the HARQ process ID is implicit and is not signaled on PDCCH. The process ID (for FDD) is calculated as follows:

10*frame_number + subframe_number modulo 8

— For TDD, since the number of HARQ processes is different from 8, the process ID is not calculated using the formula above. Rather it is obtained using a static table lookup that is a function of the current subframe number. For the cases of TDD index 0 or 6, the HARQ process ID also depends upon the current frame number.

• MPDU Transmission—HARQ MPDU is transmitted on PUSCH. If control information needs to be signaled, it is signaled on PDCCH. In the latter case, the following information is signaled: New Data Indicator (one bit), Redundancy Version (two bits).

• Uplink HARQ scheduler at eNodeB

— Persistent/Synchronous Retransmissions—On uplink, only synchronous mode is supported. This means an initial transmission determines all future retransmissions in advance. All retransmissions occur after eight subframes, and if TTI bundling is enabled, retransmissions occur after 16 subframes. Reception of an ACK on PHICH or reception of a new grant with NDI = 1 stops the synchronous retransmissions.

— In some cases, adaptive retransmission may be performed on the uplink, in which case a new control element (DCI) is signaled on the PDCCH with the NDI bit set to 0. This DCI may carry a different location on the uplink subframe relative to the original transmission.

Uplink HARQ ACKs are sent on PHICH. Reception of a new grant (NDI = 0 stands for NACK, and NDI = 1 stands for ACK) also implicitly signals the ACK for the previous MPDU transmission and takes a higher priority over the ACK communicated via PHICH. There is no dedicated space in the frame for PHICH, rather HARQ ACK bits are modulated and spread over the entire downlink spectrum. HARQ ACKs are always sent at frame n+4, for FDD, and at frame n+k, for TDD, where k is obtained using Table 8-2, standard [36.213]. A user-specified error rate is used to model the error probability on the PHICH channel.

1—LTE


In particular, the downlink subframe 0 carries acknowledgments for uplink subframes 4 and 7. Also, the downlink subframe 5 carries acknowledgments for uplink subframes 9 and 3 (belonging to the next frame). An HARQ ACK that comes in one of these two downlink subframes is distinguished by a special field called the “msb bit” to help identify which uplink subframe it is acknowledging.

Other Model Features

• Modeling of Errors and Drops on Control Channels—The following types of errors and drops are modeled:

— PHICH: ACK—>NACK and NACK—>ACK errors are modeled

— PDCCH: Drop probability for the DCIs is modeled separately for the uplink grants and downlink information elements.

— PUCCH: ACK—>NACK and NACK—>ACK errors are modeled

Each of these probabilities is configurable separately per cell. The relevant attributes are in LTE > L1/L2 Control Parameters on eNodeB.

• Support for Random Access Procedure—In the random access procedure, HARQ is used on msg3 on the uplink and msg4 on the downlink. The number of retransmissions for these messages is calculated separately. For msg3, the number of retransmissions can be manually configured between 1 and 8 or can be left auto-assigned, in which case it will be calculated from the contention resolution timer as follows, where C is the contention resolution time in subframes:

Channel Quality Indicator (CQI) and Link Rate Adapt ation

Downlink Measurement Support

The target link quality is defined by the maximum acceptable block error rate (BLER). Based upon the target link quality, an SNR metric (sample mean) determines the best operating MCS index for the link. An MCS index is then mapped to a CQI index. Thus, the best operating CQI index at the UE is a function of target link quality and the current SNR statistic (sample mean).

When the link quality improves, CQI is increased, meaning a higher MCS index can be supported for the specified target link quality. Similarly, when the link quality deteriorates, CQI is reduced.

ceilC

8----

1–

1—LTE


Configuration of the eNodeB is in the compound attribute LTE > CQI Transmission Parameters.

• Periodic Configuration Index—Controls the periodicity of CQI reporting from the UE over PUCCH

• Subband Report Repetition Count (k)—Controls the periodicity of subband reporting before the next wide-band CQI is reported

Configuration of the UE is in the compound attribute LTE > Link Adaptation Parameters.

• Measurement Window Size—Sets the length of time (in seconds) of the sliding window to collect SNR sample points. The sample mean is computed from all sample points within the window.

• Downlink Target Link Quality—Sets the desired target link quality. Allowable values are 0.01%, 0.1%, 1%, 5%, or 10%.

See also Channel Dependent Scheduling on page LTE-1-15.

Admission Control

The admission control procedure is executed by each eNodeB for its cell. All requests for GBR radio bearers go through admission control. When a GBR radio bearer is created, cell resources allocated for it is deducted from available cell resources. Similarly, when such a bearer is released, its resources are added back to the common pool.

The admission control procedure admits a GBR radio bearer only if it is possible to allocate requested resources for that bearer in the cell for both the uplink and downlink direction. Being able to allocate resources in one direction only is not sufficient to admit the bearer.

The admission control procedure has the ability to start the preemption procedure for one or more low priority GBR radio bearers to be able to accept a radio bearer request for a high priority EPS bearer.

• The relative priority of radio bearers is decided based on the value of the ARP parameter of their EPS bearers (lower numerical ARP value means higher priority).

• Preemption does not happen for any radio bearer if there are not enough resources to admit the new bearer even after preempting all the low priority bearers.

• Preemption procedure first creates an initial preemption list of bearers. It starts adding the bearers that have the lowest priority to this list and stops when there are sufficient free resources to admit the new bearer when the resources coming from bearers preempted up to that point are taken into account. In some cases, the resources coming from bearers preempted up

1—LTE


to this point might be more than necessary and it might be possible to avoid the preemption of some bearers. Therefore, once the initial preemption list is prepared, the preemption procedure will always execute a second pass through the list to minimize the number of preempted bearers. During this pass, starting from the higher priority bearers (excluding the last one added), bearers are removed from the list if there will still be sufficient resources in the cell to admit the new bearer, even when that bearer is not preempted and all the ones that are still in the list are preempted.

• The accept response is sent to the requesting entity without waiting for the completion of preemption procedures, if any are triggered by the radio bearer creation request.

While computing the frame capacity (i.e., initially available amount of cell resources), admission control procedure takes the following overheads into account:

• Downlink

— Downlink reference symbols—Four resource elements per RB

— PDCCH (downlink L1/L2 control channel)—The size of PDCCH for admission control purposes is configurable via an eNodeB attribute

• Uplink

— Uplink reference symbols—12 resource elements per RB

— PUCCH (uplink L1/L2 control channel—The size of PUCCH is obtained from eNodeB's PUCCH configuration attribute

— PRACH—12 RBs per random access resource, where the number of RA resources per frame depends on the configuration of the random access parameters of eNodeB

Oversubscription and undersubscription are allowed. You can enable this by configuring the loading factor attribute at eNodeBs. Setting this attribute to "No Admission Control" disables the admission control for the cell of that eNodeB. An admission control report table is created at the end of the simulation.

An estimated frame capacity report table is created, shown in Figure 1-31 on page LTE-1-80.

• This table is created for both uplink and downlink. Estimated capacity is reported for a subset of MCS index values. The table has two rows:

— The first row is the raw estimated capacity for each of the selected MCS index values. The estimated capacity is computed by assuming a single UE saturating the channel.

— The second row reports the estimated channel capacity used by the admission control, which also takes the loading factor into account

1—LTE


EPS Mobility Management (EMM)

Mobility management functions track the location and activity of a UE in the network. The following topics are contained in this section:

• EMM UE State Management

• EMM Attach Procedure Support on page LTE-1-47

• Initial Cell Search and Selection on page LTE-1-47

• Attributes Affecting Cell Selection on page LTE-1-48

• Attributes Affecting UE Transition to Idle Mode on page LTE-1-50

• UE Transition from Idle Mode on page LTE-1-50

• Cell Monitoring and Reselection Process from Idle Mode on page LTE-1-52

• Tracking Area Updates on page LTE-1-52

• Handover on page LTE-1-54

• Radio Link Monitoring and Failure on page LTE-1-57

EMM UE State Management

As a UE participates in an LTE network, it may change EMM states (see Figure 1-11) in order to conserve energy. The core network needs to know the location of a UE for traffic transmission, but if the UE is in the idle state, the core network only knows a general location (tracking area) for the UE.

1—LTE


EMM UE States As shown in the following figure, the UE can be in one of three states. These states are discussed below.

Figure 1-11 EMM UE States

• EMM_Deregistered —A UE is in this state when it is waiting to finish the EMM Attachment procedure with the EPC.

• EMM_Connected —A UE enters the EMM_Connected state when the registration and attach process is complete. While in this state, the exact location of the UE is known to the core network.

Note—A UE in the EMM_Connected state can achieve power savings by using DRX in RRC_Connected mode. For more information, see Discontinuous Reception (DRX) in Connected Mode on page LTE-1-16.

• EMM_Idle—When the UE enters the EMM_Idle state, it can achieve significant power savings; however, the location of the UE is only known by the granularity of the tracking area.

Note—To learn more about how a UE transitions to the idle state, see Tracking Area Updates on page LTE-1-52.

When in the EMM_Connected state, the exact location of the UE is known by the core network.

When in the EMM_Idle state, only the tracking area of the UE is known. When downlink traffic is received by the core network for the UE, paging messages are sent in order to make the UE transition to the connected state before sending the traffic.

If a UE is in the EMM_Idle state and has uplink traffic to send, receives paging messages, or initiates the tracking area update procedure (TAU), it transitions to the EMM_Deregistered state and initiates the EMM attach procedure to connect to the network.

1—LTE


EMM Attach Procedure Support

Registration of UEs to the LTE network via the EMM Attach procedure is modeled, and 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”.

The model supports connecting an eNodeB to multiple EPCs. In such topologies, the selection of an EPC for a UE is via the configuration of the “Serving EPC ID” attribute on that UE.

Note—A diagram of the various states supported for a UE is shown in Figure 1-11 on page LTE-1-46.

Initial Cell Search and Selection

Cell search and selection procedures are performed during initial attachment.

PLMN Selection In the LTE model, the UE is configured with a single home public land mobile network (HPLMN).

• The HPLMN identifier is the LTE > Serving EPC ID attribute

• Cell search is only performed for the configured HPLMN

• If suitable cells are not found for the HPLMN, then the UE continues to search for a suitable cell

Cell Search and Synchronization Once an EPC has been selected, the UE performs a cell search by scanning the DL frequencies of all eNodeBs that serve this EPC to determine a suitable eNodeB.

Note—When an explicit eNodeB is specified in LTE > Serving eNodeB ID on the UE, rather than the value “Perform Cell Search”, the cell search begins with that carrier frequency.

• Cell Synchronization—In each carrier frequency, the UE attempts to synchronize with the cells. The model supports explicit transmission of Primary Synchronization Signal (PSS), Secondary Synchronization Signal (SSS), Master Information Block (MIB), and System Information Block (SIB). During cell search, the UE will synchronize with the strongest cell in each carrier frequency.

• Cell Measurement—The UE supports the measurement of RSRP for each cell to aid in the cell selection process. Reference Symbols are not supported. Instead RSRP is measured for the MIB packets.

1—LTE


• Cell Selection—Once a UE has chosen a candidate cell, that is, the strongest cell, for a carrier frequency, it evaluates the cell selection criteria.

— Cell Selection Threshold—LTE > eNodeB Selection Threshold (configured on the eNodeB) specifies the minimum signal power for a UE to join the eNodeB.

— Cell Selection Criteria—The following criteria is evaluated for a cell to be selected as the serving cell:

Note—The cell should belong to the HPLMN of the UE. Cell-barring and TAC conditions are not supported.

• Attach Procedure—Once the UE-AS has selected the cell, it conveys this information to the NAS to initiate the network attach procedure.

• Cell Selection Failure—If a suitable cell is not found for the HPLMN, the UE continues cell search and selection indefinitely.

Attributes Affecting Cell Selection

EPCs Served Configured on the eNodeB. Specifies the list of PLMNs (EPCs) that this eNodeB can service. If set to “All” (default), then this eNodeB can service all PLMNs (EPCs) in the network. When “All” PLMNs are supported by an eNodeB, the UE considers this eNodeB as a valid eNodeB for cell selection.

eNodeB Selection Threshold Configured on the eNodeB. Specifies the minimum RSRP threshold for a UE to select this eNodeB.

eNodeB Selection Policy Configured on the UE. This attribute specifies the eNodeB selection policy during cell search.

• First Suitable eNodeB: Results in the UE selecting the first eNodeB that matches the cell selection criteria

• Best Suitable eNodeB: Results in the UE selecting the best eNodeB from eNodeBs meeting cell selection criteria in all frequencies belonging to this PLMN.

Table 1-9 Cell Selection Criteria

Value Description

Qrxlevmeasured Measured cell RX level value (RSRP)

Qrxlevmin1

1. Mapped to Cell Selection Threshold on the eNodeB

Minimum required RX level in the cell (dBm)

Qrxlevmeasured Qrxlevmin>

1—LTE


Serving EPC ID Configured on the UE. Specifies to which EPC node this UE will be connected. (See also EPCs Served on page LTE-1-48).

Serving eNodeB Configured on the UE. Specifies the eNodeB selection method. The use of this attribute depends on the efficiency mode setting (see Efficiency Mode on page LTE-1-36).

Figure 1-12 Serving eNodeB Attribute

• Efficiency Enabled—In this mode, the following behavior applies.

— When an explicit eNodeB is specified, and the eNodeB services the EPC configured on the UE, the UE selects this eNodeB irrespective of distance or power.

— If the eNodeB does not service the EPC, then the UE defaults to “Perform Cell Search”, in which case the UE selects the best eNodeB (based on distance) from the eNodeBs that service the EPC configured on the UE.

• Physical Layer Enabled—In this mode, the following behavior applies.

— When an explicit eNodeB is specified, and the eNodeB services the EPC configured on the UE, the UE searches the frequency of the specified eNodeB first. The eNodeB is selected if it meets “Cell Selection Criteria”, even if it is not the best eNodeB.

— If the specified eNodeB does not service the EPC, does not meet the cell selection criteria, or is not discovered, the UE will default to “Perform Cell Search”.

1—LTE


Attributes Affecting UE Transition to Idle Mode

When the attach procedure is completed, the UE enters into the connected state. An inactive UE in connected state may transition to the idle mode based on the settings of the following attributes within LTE > Idle Mode Parameters.

Note—The term “idle mode” is used throughout this section to refer to the EMM_Idle state.

• Idle Mode Support —Specifies if the UE supports the idle mode. Values are Enabled, Disabled, or eNodeB Triggered (meaning that the eNodeB tells the UE when to enter the idle mode). If this attribute is set to “eNodeB Triggered”, the UE transitions to the idle mode based on the setting of a timer on the eNodeB. See RRC Connection Release Timer (on eNodeB) on page LTE-1-50 for more information

• Timers

— T3440—Specifies the length of an inactivity period, after which the UE enters the idle state. If the Idle Mode Support value is set to “eNodeB Triggered,” this timer is ignored and the setting of the RRC Connection Release Timer on the eNodeB is used instead.

RRC Connection Release Timer (on eNodeB) Specifies the length of inactivity (in seconds) after which a UE will be placed into the idle mode by initiating the procedure of releasing that UE's RRC connection, if Idle Mode Support on the UE is set to “eNodeB Triggered” or “Enabled”. The value for this timer is generally set for a shorter period of time than the T3440 timer on the UE, making this the preferred timer for use in placing UEs into the idle state.

UE Transition from Idle Mode

A UE will leave the idle mode and re-initiate the attachment procedure in case of any of the following events:

• Uplink Traffic. When the UE has traffic to send, it reattaches to the core network. No paging traffic is required.

• Tracking Area Update. If the UE moves into a different tracking area, or the T3412 timer expires (explained below), the UE will leave the idle mode and will send a TAU to the EPC with its current tracking area. For more information, see Tracking Area Updates on page LTE-1-52.

1—LTE


• Paging. The eNodeB sends broadcast paging messages on a known frame when it has traffic for a UE that is in the idle mode. At the designated interval, the UE listens for the paging messages, whether or not there is traffic for it. The UE leaves the idle mode to receive the traffic when it sees its identification included in the paging message. The following parameter specifies the duration of the paging cycle.

— DRX Parameter —Specifies (in frames) the length of the paging cycle, after which the UE wakes up to listen for broadcast paging messages. The default value is 256 frames, which is equivalent to 2.56 seconds. This is the “worst case” length of time for the UE to wake up and sense paging messages. You can specify a value on the UE or choose “Use EPC Configured Value” to let the EPC set the length of the paging cycle. See RRC Connection Release Timer (on eNodeB) on page LTE-1-50 for a comparison of the settings on the UE and on the EPC.

Figure 1-13 EMM Paging Cycle

Note—Although the idle mode can result in significant power savings for the UE, the need for the UE to reattach upon leaving the idle mode results in more signaling traffic in the backbone network.

Notice that this UE is configured to use the EPC’s settings for the periodicity of paging messages.

You can also specify for the UE to use its own paging interval, overriding the interval of the EPC.

In this example, the EPC is set to send exactly one paging message (one frame) every 256 frames (equivalent to every 2.56 seconds) for the UEs that follow the EPC's paging cycle. Idling UEs know the periodicity of the frames carrying paging messages and wake up temporarily from the idle state to listen to them.

1—LTE


Cell Monitoring and Reselection Process from Idle M ode

While a UE is in the idle mode, it monitors the signal strength of the cell on which it is camped so that when the UE needs to leave the idle mode, it knows which cell to select. Ordinarily, the UE would use the handover procedure to select a new cell, but the process differs for a UE in the idle mode. The following parameters under LTE > Cell Reselection Parameters control the cell monitoring and reselection process.

Note—A UE in the idle mode continually assesses cells but does not select a cell until it needs to wake up from the idle mode.

• RSRP Measure Period —Controls how often, in frames, a UE that is in the idle state measures the RSRP of the cell it is camped on. The default value is 10, meaning that every tenth frame, the UE will check the RSRP of the cell on which it is camping.

• Measurement Threshold —Specifies the low RSRP threshold (in dBm) that determines if a UE in idle mode should begin to search for a new cell on which to camp. This threshold is only used in the idle mode; if the UE is in the RRC_Connected state, attributes under Handover Parameters will be used.

• Hysteresis for Serving Cell —In conjunction with the Measurement Threshold attribute (shown above), this attribute helps to determine whether a cell will be selected as a potential serving cell by a UE in idle mode. The RSRP of the new cell should be greater than the RSRP of the current cell by at least this value for the cell reselection to proceed.

For example, if this attribute is set to 2 dBm, and the Measurement Threshold attribute is set to -112 dBm, assuming the RSRP measured in the current cell is just below the threshold, then a cell must have a signal of at least -110 dBm to be selected (-112 + 2 dBm = -110 dBm)

Tracking Area Updates

The location of an idling UE is known by the core network at the granularity of a tracking area. A tracking area is a collection of eNodeBs and their sectors and can represent a logical or geographic subset of the LTE network (for example, Boston or Region 3). UEs may remain within a tracking area or move into other tracking areas over time. Periodically, or when it changes tracking areas, a UE in idle mode sends tracking area update (TAU) messages to the core network.

The UE setting in LTE > Idle Mode Parameters > Timers > T3430 specifies the maximum allowable time between the transmission of the tracking update from the UE and the receipt of an accept message from the core network. If the timer expires without the receipt of an accept message, the UE begins the tracking area update process again.

1—LTE


The following figure, taken from the “idle_mode_study” scenario of the LTE example project, shows two tracking areas: one highlighted in yellow and the other in green. Tracking areas are specified in the LTE > Tracking Area ID attribute of the eNodeB.

Figure 1-14 LTE Tracking Areas

1—LTE


The periodicity of the TAUs is determined by the T3412 timer on the EPC. This can be set to a period from 6 minutes to 196 minutes, as specified in section 10.2 of 3GPP TS 24.301. The timer is restarted when a TAU is sent in case of the UE moving into a new tracking area as a result of the cell reselection procedure.

Figure 1-15 T3412 Timer

Handover

LTE handovers allow for smooth transitions from one cell to the next as the mobile node moves through the network. The most common driver for a handover is deteriorating signal quality.

Handover (mobility management in the Connected state) is initiated and controlled by the eNodeB, with assistance from the UE. The modeling of LTE handovers is supported, as follows.

• Handover Capabilities —The model supports all handover procedures described in the LTE standard. Specifically, we support the following capabilities, including a standards-based implementation of all control messages, and of UE, eNodeB, and EPC procedures.

— Intra- and inter-frequency handover is supported

— Handover between cells using FDD and TDD is supported

If the handover type is set to *Intra-frequency,* you must select the same *center frequency* for the Downlink FDD channel and the TDD channel. For more information on setting frequencies, see FDD/TDD Parameters on page LTE-1-22.

1—LTE


If the above requirement is not satisfied, the handover type must be set to *Inter-frequency*.

— Handover between cells using S1 interface is supported

— Handover between cells using the X2 interface is supported

— Handover data forwarding is supported and configurable on the individual bearers

• UE Measurement and Reporting —The model supports Layer-3 (AS) measurement of RSRP and RSRQ based on physical layer RSRP and RSRQ measurements. Every 200ms, the UE obtains the latest measurements from the physical layer and updates its Layer-3 measurement module. The Layer-3 measurement module filter coefficients can be configured via attributes.

The model supports inter-frequency measurements using “measurement gaps”.

— If inter-frequency handover is enabled, the serving eNodeB will periodically stop all transmissions to the UE. Simultaneously, the UE will stop all its current actions and will scan the list of carrier frequencies to measure detected eNodeBs. Upon completion of the measurement gap, the UE returns to normal operation.

The model supports all the measurement reporting techniques described in the standard (periodic, Event A1-A5).

— Periodic reporting is based on report_interval and number of reports

— Event triggered reports (A1-A5) use RSRP and/or RSRQ thresholds and hysteresis values to determine if a report should be generated and what contents should be in the report. The report_interval and num_reports attributes govern the number of reports sent to the eNodeB.

— The transmission/reception of measurement configuration information is explicitly modeled. UE measurement and reporting configuration can be specified via attributes.

• Handover Decisions —The Serving eNodeB receives reports from the UE either due to periodic reporting or event-triggered reporting. When the reported measurements violate the handover triggers, the serving eNodeB decides to handover the UE to a different cell. The serving eNodeB selects a set of potential target eNodeBs and initiates handover.

Support in OPNET Modeler is as follows:

— Handover Triggers —Handover at the serving eNodeB can be triggered either due to RSRP threshold violation and/or RSRQ threshold violation.

Handover trigger thresholds are user-configurable.

— Target eNodeB Selection —Once a handover trigger is violated, the serving eNodeB selects a list of potential target eNodeBs based on the measurements reported by the UE.

1—LTE


- The serving eNodeB ranks the neighbor eNodeBs based on the RSRP and RSRQ measurements reported by the UE. The RSRP and RSRQ ranking weights are configurable via attributes.

- Only eNodeBs in the same PLMN are considered for selection

— Cell Selection —The cell selection operation is invariant to FDD or TDD technology, since subframes 0 and 5 are always downlink for all TDD frame types (see Figure 1-5).

• Handover Procedure —Once a target eNodeB is selected, the serving eNodeB initiates the handover procedures as defined in the standard.

In the handover preparation phase, if an X2 interface is available, then an X2 handover is initiated. Otherwise, an S1 handover is initiated.

The target eNodeB accepts the UE if at least one non-GBR bearer is accepted.

Upon successful completion of the handover preparation phase, the serving eNodeB initiates the handover execution phase by sending the Handover command message to the UE. The serving eNodeB also initiates status transfer and data forwarding to the target eNodeB. Note that data forwarding is configurable on a per-bearer basis.

— Downlink data forwarding is supported for RLC UM-based bearers

— Uplink and downlink data forwarding is supported for RLC AM-based bearers

— Direct data forwarding using X2 and indirect data forwarding using S1 are supported

— When the UE joins the target eNodeB, the target eNodeB starts the Handover Completion phase, wherein all data bearers are established with the EPC. The UE context is also released at the original serving eNodeB.

• Handover Failure —During handover, the procedure may fail. The following failure scenarios and remedial action are supported:

— Target eNodeB Responds with Handover_Failure —Admission control at the target eNodeB cannot accept this UE.

The serving eNodeB selects another target eNodeB and proceeds with the handover. If all potential target eNodeBs are exhausted, then the handover procedure is terminated. In this case, the UE may eventually perform radio link failure and re-attach to another eNodeB.

— Incomplete Handover —UE loses coverage with serving eNodeB before receiving the Handover_Command message.

The UE will detect the radio link failure and recovery procedure. If the selected cell is a "prepared" cell, then the RRC Connection Re-establishment procedure will succeed, and the UE is successfully handed over to the new eNodeB.

1—LTE


If the selected cell is not a "prepared" eNodeB, then the Connection Re-establishment procedure will fail, and the UE will detach and perform the initial cell selection procedure. If the selected cell is the serving cell, then handover is cancelled, and the eNodeB continues to serve the UE.

• Handover Cancel —The handover procedure is protected by timers. If handover fails due to loss of control messages, then upon timer expiry, the Handover Cancel procedure will be executed.

Radio Link Monitoring and Failure

The model supports radio link failure detection and recovery based on the procedures in 3GPP TS 36.331.

The UE continuously monitors the downlink signal quality of the serving cell and detects radio link failure based on link monitoring and other triggers.

• Radio Link Monitoring —The physical layer of the UE continuously monitors the signal quality (RSRQ) of the serving cell. The physical layer sends an out-of-sync indication to the AS process if the measured RSRQ is lower than Qout. An in-sync indication is sent if the measured RSRQ is greater than the Qin threshold [Section 7.6 in 3GPP TS 36.133].

The model supports detection of radio link problems upon receiving N310 continuous out-of-sync indications and recovery from radio layer problem upon receiving N311 continuous in-sync indications.

Qin, Qout, N310, and N311 are configurable attributes.

• Radio Link Failure Triggers —The model supports all of the radio link failure detection triggers specified in the standard [Section 5.3 in 3GPP TS 36.331].

— Detection of radio link failure upon expiry of T310

— Detection of radio link failure upon RACH failure

— Detection of radio link failure upon retransmission threshold reached indication from RLC AM

• Radio Link Recovery —The model supports the RRC Connection Re-establishment procedure as specified in Section 5.3.7 in 3GPP TS 36.331.

Upon detection radio link failure, a UE will reset MAC and PHY parameters, and then perform cell search and selection to determine a suitable cell.

Once a cell has been selected, the UE will perform the Connection Re-establishment procedure. If the procedure is successful, the UE continues with normal operation.

• Radio Link Recovery Failure —After a radio link failure detection—due to either a suitable cell not found during cell selection or the failure of the RRC Connection Re-establishment procedure—the UE moves to the RRC Idle state.

1—LTE


The model does not support Idle mode procedures, therefore the UE will detach from the network upon entering the RRC Idle state.

The NAS layer then performs the PLMN selection and initial cell search and selection procedures.

eNodeB Failure and Recovery Support

LTE functionality at the eNodeB can be failed and recovered based on configured attributes. LTE-specific eNodeB failure and recovery is supported as follows:

• The eNodeB radio layer, as well as S1 layer functionality, is failed when an eNodeB fails

• Upon recovery, an eNodeB will reset all states (reboot) and recover at the subframe boundary

• A UE detects an eNodeB failure based on Layer-3 (AS) measurements of RSRP. Upon an eNodeB failure detection, the UE performs radio link failure procedures.

1—LTE


LTE Model Assumptions

The following assumptions exist in this release of the LTE model:

• General Assumptions

• Architectural and Operational Assumptions for Mobility Management on page LTE-1-60

General Assumptions

• Once the UEs are EMM-attached and RRC-connected, they preserve their status until the end of the simulation

• Random access preambles are not divided into set-A and set-B preambles. Currently, all of the preambles are assumed to belong to set-A.

• The modulation curve models used by the LTE physical layer represent SNR versus block error rate (BLER). The block size assumed by those models is one LTE allocation block (i.e., two LTE resource blocks). The drop probability of a packet that is transmitted over multiple allocation blocks is computed by combining the individual block error rate of the blocks composing that transmission.

• The MIMO antenna diversity implementation assumes no antenna correlation; therefore there will be no difference in performance between transmit diversity with two antennas and four antennas.

• The length of sequence numbers in RLC AM PDUs is always 10 bits, but specifications provide an option between 5-bit and 10-bit sequence numbers for RLC UM PDUs. The model ignores this option and assumes that sequence numbers in RLC PDU headers are always 10 bits whether it is AM or UM.

• While evaluating GBR-type bearers, admission control does not take RLC and MAC overheads into account. It assumes that the requested uplink and downlink GBR values for a bearer already account for those overheads.

• The MPDU processing delay and the ACK/NACK processing delay for both the uplink and downlink is assumed to be exactly three subframes each (adjusted for the propagation delays). For FDD, this translates to the HARQ round trip being exactly 8 ms, and to sustain uninterrupted communication, exactly eight HARQ processes are defined for both uplink and downlink. For TDD, the number of HARQ processes is given in Table 1-8 on page LTE-1-39. These are derived from the same requirement, in that uninterrupted communication with the UE is desired. The HARQ round trip time is not a constant for TDD neither in uplink or downlink (except in some special cases) and is rather a function of the current subframe.

• Handover of a UE between eNodeBs supporting FDD and TDD is allowed.

1—LTE


• Only DCI format 1A or DCI format 2A is used for downlink scheduling assignments, which are assumed to be contiguous. DCI format 2A is assumed to be used only for spatial multiplexing transmissions.

• The HARQ blanking mechanism is assumed to be used for multi-codeword spatial multiplexing transmissions. In the HARQ blanking mechanism, new transmissions will not begin until the HARQ process for both of the codewords are completed.

• Interference on data channels is produced by other data channels and control channels

• Interference effects for control channels are based on a probability distribution function

• PUSCH and PDSCH do not interfere with each other. LTE designates non-overlapping uplink and downlink frequency band ranges for each given geographical region. Therefore the model will not account for interference between uplink and downlink channels regardless of their frequency configuration.

• In a given LTE PHY profile, the guard bands for uplink and downlink channels are indicated in the table below. The same guard band value is applied at the beginning and at the end of the channel.

Architectural and Operational Assumptions for Mobil ity Management

• A single EPC device models the MME, serving gateway (Gw), and packet data network gateway (PDN Gw)

• EPCs represent PLMNs. An eNodeB can serve multiple EPCs, and an EPC can be served by multiple eNodeBs. A UE belongs to only one LTE mobile network (PLMN), as specified with its "Serving EPC ID" attribute. During the cell selection process, a UE selects an appropriate eNodeB from the set of eNodeBs that serve its EPC.

• Only mobility management in the “active” state is modeled; “idle” mode procedures are not supported

• Only intra-EPC handover is supported

— During handover source and target MME are the same

— During handover source and target SGws are the same

Table 1-10 Guard Band Parameters

Channel BW (MHz) 1.4 3.0 5.0 10.0 15.0 20.0

Guard Band (KHz) 160.0 150.0 250.0 500.0 750.0 1000.0

1—LTE


LTE Model Limitations

The following limitations exist in this release of the LTE model:

• The sizes of RRC messages are approximated

• The sizes of S1 messages are approximated

• The header compression capability of the PDCP sub-layer is modeled using a probability distribution function based statistical model rather than an explicit model

• ACKs/NACKs sent on the physical hybrid indicator channel (PHICH) are presently not sent via the physical layer mechanism, since the exact method of sending this information to the UE is currently undecided in the latest LTE standard. Rather, the ACKs/NACKs are delivered directly to the recipient UE. However, for realistic behavior, the misinterpretation of these transmissions by the recipient (i.e., ACK-to-NACK and NACK-to-ACK errors) can be modeled probabilistically via preconfigured attributes.

• Closed loop spatial multiplexing and multiuser MIMO are not supported

1—LTE


LTE Model Unsupported Features

The following features are not supported in this release:

• Inter-EPC handovers

• Semi-persistent scheduling

• Stream Control Transmission Protocol (SCTP)

1—LTE


LTE Node Models

LTE models are included on the LTE object palette, shown below.

• LTE configuration object, which allows you to define parameters used in the model and simulation

• LTE UE router model

• LTE eNodeB models (1, 3, and 6 sector models are supported)

• LTE EPC model

• LTE server models (fixed and mobile)

• LTE workstation models (fixed and mobile)

Figure 1-16 LTE Object Palette

Note—The LTE UE router node contains a special attribute—Advertised IP Address List—that is not available on the other nodes. This attribute specifies the list of host IP addresses that will be advertised by this UE router, which is required for downlink traffic to reach the nodes behind this UE router. This information is passed to the EPC node during the attachment procedure.

1—LTE


Creating Custom LTE Node Models

You can also use Device Creator to create custom LTE node models. The following node types are available for customized creation in Device Creator:

• 1, 3, or 6 sector eNodeB

• EPC

For more information about Device Creator, see Creating Custom Models with Device Creator on page SPU-6-87.

1—LTE


Configuring LTE

This section describes how to configure LTE in your network model. The typical configuration steps include

• Creating the LTE Topology

• Viewing the LTE Configuration on page LTE-1-71

• Adding Network Traffic to an LTE Model on page LTE-1-72

• Running a Simulation for LTE on page LTE-1-72

Creating the LTE Topology

LTE topologies cannot be created using the import features in the software (such as import from VNE Server or device configuration files). You must create these topologies with the Wireless Network Deployment Wizard, as described in Deploying an LTE Network Automatically on page LTE-1-65, or manually, as described in Manual LTE Network Creation on page LTE-1-67.

Deploying an LTE Network Automatically

The preferred method for deploying LTE or other wireless technology-based networks is by using the Wireless Network Deployment wizard. The wizard lets you build, configure, and deploy your wireless network segments quickly and easily.

Note—For a full description of the Wireless Network Deployment Wizard, its usage and capabilities, see Wireless Network Deployment on page WM-2-43 of the Wireless Module user guide.

1—LTE


Figure 1-17 Wireless Network Deployment Wizard

In the Technology screen of the wizard, select LTE as your wireless technology. You can then specify the following parameters (shown in Figure 1-18 on page LTE-1-67):

• UE Transmission Power (W)—Provide the transmission power (in wattage) to use for each UE

• eNodeB Transmission Power (W)—Provide the transmission power (in wattage) to use for each eNodeB

1—LTE


• PHY Profile—Provide the PHY profile that will be used by the deployed LTE network

• Pathloss Model—Choose the Pathloss Model to use for each UE. This will also set the Shadow Fading Standard Deviation.

Figure 1-18 LTE Technology Specification in Wirele ss Network Deployment Wizard

Manual LTE Network Creation

When you create the network model, you can specify certain characteristics such as the geographic size of the model. Creating a network topology for LTE is similar to creating any other network topology. Be aware that to set geographic size for the model, you must select the following in the Startup Wizard:

• Initial Topology—Choose Create Empty Scenario

• Choose Enterprise, Campus, or Office. You are prompted for dimensions.

You can add nodes to your network model several ways:

• Manually, by dragging and dropping objects from the object palette into the Project Editor workspace.

• Manually, using the Topology > Rapid Configuration... command from the menu bar to specify and build a complete network topology quickly.

1—LTE


Supported LTE Topologies

The following LTE topologies are supported:

• An eNodeB node can communicate with one or more UEs and with one or more EPCs

• An EPC node can communicate with one or more eNodeBs

• Applications can be configured to communicate UE to UE, UE to external network, and external network to UE

Figure 1-19 LTE Topology with Communication to Ext ernal Network

Figure 1-20 LTE Topology with Multiple eNodeBs and EPCs

1—LTE


Support for UMTS Networks Support is also provided for EPCs to connect to serving GPRS support nodes (SGSN) in place of a gateway GPRS support node (GGSN). This provides legacy support to UMTS networks, while letting you model end-to-end application performance through 3G and 4G networks. Note the following in regard to configuration:

• UMTS networks support only one GGSN node in the simulation network model. Therefore, if an EPC is connected to a UMTS network to serve as a GGSN, only one EPC node will be allowed in the whole network.

• Set the “GGSN ID” attribute on the SGSN to the EPC ID of the serving EPC

• SGSN ID numbers must be unique from the EPC ID. That is, if an EPC ID is “0”, no SGSN can use the ID of “0”.

1—LTE


Notice in the figure below that a single EPC serves eNodeBs in the LTE network and SGSNs in the UMTS network simultaneously. Only one EPC is allowed in this type of topology, as described above.

Figure 1-21 LTE and UMTS in a Network Model

For more information about UMTS networks, see UMTS on page STM-39-1.

1—LTE


Viewing the LTE Configuration

You can apply a network view to visualize LTE information in your network. To apply the LTE view, choose one of the following menu options:

• View > Set View for Subnet > LTE (sets view for this subnet only)

• View > Set View for Network > LTE (sets view for all subnets)

Either action will place an icon on UEs that denote their Serving EPC ID, an icon on eNodeBs that denote the EPCs served by them, and an icon on the EPCs that denote their EPC ID. This view will also enable balloons on each LTE node that will show a summary of important LTE attributes configured on that node, as shown in the figure below.

Note—To use this feature, be sure the “Enable Balloons” preference is set to TRUE.

Figure 1-22 LTE Visualization in Network

Related Topics

• Balloons on page ITG-7-15

• Network Views on page ITG-7-17

1—LTE


Adding Network Traffic to an LTE Model

After you have created the LTE network topology, you can introduce traffic into the model. You can do this through the use of discrete application traffic (including standard application models such as FTP and E-mail, custom applications, and application demands). The model does not support raw packet generation.

Application support is included in the UEs (workstation and server models). For more information, see Applications on page STM-1-1.

Network Addressing Support

Both IPv4 and IPv6 addressing are supported. Note the following:

• The loopback interface address of the EPC and UE must be in the same network

• A given LTE network may only have one technology in use at a time (IPv4 or IPv6). In other words, an EPC with all of its eNodeBs and UEs must use the same technology.

• Auto-assignment of IP addresses is supported for LTE networks that use IPv4 technology. In LTE networks that use IPv6 technology, IP addresses must be manually assigned.

Application Delay Tracking

The LTE model supports Application Delay Tracking (ADT), which can help you identify the sources of application delay in a discrete event simulation. For more information about using ADT, see Tracking Application Delays on page RN-17.1-47.

Running a Simulation for LTE

Use the following procedure to configure LTE in the network model.

Procedure 1-2 Configuring LTE

1 Open a new project in OPNET Modeler, as described above.

2 Add nodes to the network model.

2.1 Launch the LTE object palette by clicking on the icon in the toolbar.

2.2 Select and add network elements to the model. The minimum configuration must contain the following:

• LTE Configuration node

• eNodeB

• EPC

1—LTE


• One or more mobile stations

2.3 Configure LTE options on the LTE Configuration node. Modify existing or create new EPS Bearer Definitions or LTE PHY Profiles for use in configuring the model.

Figure 1-23 Configure LTE Options on LTE Configura tion Node

2.4 Configure the eNodeB and EPC IDs per your network configuration, as shown in the following figure. (See Attributes Affecting Cell Selection on page LTE-1-48.)

1—LTE


Figure 1-24 EPC and eNodeB ID Settings

2.5 Set the eNodeB Selection Policy to “First Suitable eNodeB” or “Best Suitable eNodeB” per your network configuration.

2.6 Set the EPS Bearer Definition on the mobile node(s) as shown in the following figure.

1—LTE


Figure 1-25 Set EPS Bearer Definition on Mobile No de

3 Add link objects from the object palette to establish connectivity between nodes (i.e., 100BaseT link from ethernet link models).

4 Configure traffic in the network model.

Note—Only explicit traffic demands are supported. Background traffic is not supported.

5 Run a discrete event simulation.

End of Procedure 1-2

See Available Reports for LTE on page LTE-1-80.

1—LTE


Analyzing LTE Networks

To analyze LTE performance, you can collect several statistics and analyze reports about LTE behavior in a scenario. You can also visualize LTE in the network model (see Visualizing LTE in the Project Editor on page LTE-1-83).

LTE Statistics

To analyze the performance of the LTE protocol, several statistics can be collected during simulation execution. Statistics can be collected on a global or per-node basis.

Note the following:

• LTE statistics are available on mobile nodes only

• LTE Admission Control statistics are available on eNodeB

• EPS Bearer Traffic and RLC Traffic statistics make use of tags (see Using Tags in Traffic Statistics on page LTE-1-78)

Figure 1-26 LTE Global Statistics

1—LTE


Figure 1-27 LTE Per-Node Statistics

1—LTE


Using Tags in Traffic Statistics

EPS Bearer Traffic and RLC Traffic statistics have the following tags. You can arrange these statistics using these tags in any way that provides convenient access to the results in which you are interested.

• IMSI

• Bearer

• Direction (Uplink or Downlink)

Note—Refer to Procedure 17.1-2 Defining an Arrangement in the Results Browser on page RN-17.1-7 for more information about using tags.

Arrangements can be saved and reused. A sample arrangement, "lte_imsi_by_bearer", is available for use in the Results Browser as shown below:

Figure 1-28 Arranging Statistics by Using Tags

1—LTE


An example usage of this arrangement is shown below.

Figure 1-29 Arrangement by Tags in the Results Bro wser

To see the details of this arrangement and to modify it, if desired, click on the Edit... button to open the Statistic Tree Arrangement window.

Figure 1-30 Editing an Arrangement in the Results Browser

1—LTE


Available Reports for LTE

Frame Capacity Reports

Two Frame Capacity reports—eNodeB DL Frame Capacity Report (shown below) and eNodeB UL Frame Capacity Report,—are available for the eNodeB. You can view the results in the DES run tables as shown in the following figure.

Figure 1-31 LTE eNodeB DL Frame Capacity Reports

Note— In this example, additional information is shown because MBMS is configured and enabled in the network. See the “Estimated PMCH Capacity for Data in MBSFN (Mbps)” row.

The Frame Capacity Report for PDSCH shows a range of estimated data rates depending on the number of symbol times taken by PDCCH. PDCCH can take anywhere between one and three symbol times.

1—LTE


Neighbor Cell Frequency Overlap Report

The following figure shows the eNodeB Neighbor Cell Frequency Overlap report. This report indicates the amount of frequency overlap (in MHz and percentage) with all of the other eNodeBs in the network. The corresponding PHY profiles are listed in the table, and if any eNodeB in the list uses the same profile as the eNodeB that owns the table, then *** is used instead of the name A foot note is included in the report to clarify. The overlap is reported for uplink and downlink bandwidths.

Figure 1-32 eNodeB Neighbor Cell Frequency Overlap Report

1—LTE


Power Consumption Report

The output of the power consumption feature is shown below.

Figure 1-33 Power Consumption Report

The output is in two separate tables, one for all UEs and one for all eNodeBs, which will contain the following fields calculated at the end of the simulation:

• Node—Displays the node name

• Time Spent in Normal State—Total time, in seconds, spent in the Normal (DRX Inactive) state

• Time Spent in Active State—(UE only) Total time, in seconds, spent in the DRX Active state

• Time Spent in Sleep State—(UE only) Total time, in seconds, spent in a DRX sleep cycle

• Operating Power Consumption—Total energy consumed during the simulation based on the time that the UE has spent in each state and the given operating power consumption rate for each state.

1—LTE


• Tx Power Consumption—Total energy consumed by all transmissions during the simulation.

• Total Power Consumption—Sum of the Operating Power Consumption and Tx Power Consumption during the simulation.

• Battery Capacity—Value of the Battery Capacity attribute is provided for reference in the output table.

• Estimated Life Time—An estimate of the time it will take for the battery to be completely depleted.

Visualizing LTE in the Project Editor

A network view is a predefined set of visualization settings. You can apply a network view to reduce visual clutter and to highlight information of interest in your model.To visualize LTE information in your network, choose one of the following menu options:

• View > Set View for Subnet > LTE (sets view for this subnet only)

• View > Set View for Network > LTE (sets view for all subnets)

Note—To use this feature, be sure the “Enable Balloons” preference is set to TRUE.

1—LTE


Either action will place an icon on UEs that denote their Serving EPC ID, an icon on eNodeBs that denote the EPCs served by them, and an icon on the EPCs that denote their EPC ID. This view will also enable balloons on each LTE node that will show a summary of important LTE attributes configured on that node, as shown in the figure below.

Figure 1-34 LTE Visualization in Network

1—LTE


LTE Reference Documents

LTE models are based on the following reference documents.

Table 1-11 Reference Documents

Document Title

3GPP TS 23.122 Non-Access Stratum (NAS) functions related to Mobile Station (MS) in idle mode

3GPP TS 23.203 Policy and charging control architecture (Release 8)

3GPP TS 23.246 Multimedia Broadcast Multicast Service; Architecture and Functional Description (Release 9)

3GPP TS 23.303 UE functions and interlayer procedures in connected mode (Release 8)

3GPP TS 23.401 General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 8)

3GPP TS 24.301 Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS) (Release 8)

3GPP TS 25.996 Spatial channel model for Multiple Input Multiple Output (MIMO) simulations (Release 8)

3GPP TS 29.274 Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3 (Release 8)

3GPP TS 36.101 Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) radio transmission and reception (Release 8)

3GPP TS 36.133 Evolved Universal Terrestrial Radio Access (E-UTRA); Requirements for support of radio resource management

3GPP TS 36.211 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and modulation (Release 8)

3GPP TS 36.212 Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and channel coding (Release 8)

3GPP TS 36.213 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer: Procedures (Release 8)

3GPP TS 36.214 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer: Measurements (Release 8)

3GPP TS 36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 9)

3GPP TS 36.304 Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) procedures in idle mode

1—LTE


3GPP TS 36.321 Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification (Release 9)

3GPP TS 36.322 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol specification (Release 8)

3GPP TS 36.323 Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification (Release 8)

3GPP TS 36.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification (Release 8)

3GPP TS 36.410 Evolved Universal Terrestrial Access Network (E-UTRAN); S1 General aspects and principles (Release 8)

3GPP TS 36.413 Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) (Release 8)

Table 1-11 Reference Documents (Continued)

Document Title

Education

Lte model drx