Long Term Evolution (LTE) is an all-IP wireless protocol that provides increased data rates and improved user response times compared to previous standards. The LTE model simulates key aspects of LTE including EPS bearers, traffic flow classification, session management, broadcast/multicast traffic using MBMS, and protocol layers like PDCP, RLC, MAC and the physical layer for both FDD and TDD schemes. Configuration and analysis of LTE networks is also supported.

1. 1—LTE
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
OPNET Modeler/Release 17.5 LTE-1-1

2. 1—LTE
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
LTE-1-2 OPNET Modeler/Release 17.5

3. 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:
Table 1-1 Standardized QCI Characteristics1
Resource
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.)
1. Source: 3GPP TS 23.203 "Policy and charging control architecture"
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.
QCI
9 9
OPNET Modeler/Release 17.5 LTE-1-3

4. 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
LTE-1-4 OPNET Modeler/Release 17.5

5. 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.
OPNET Modeler/Release 17.5 LTE-1-5

6. 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.
LTE-1-6 OPNET Modeler/Release 17.5

7. 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 Nodes
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 Tunnel
• 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).
OPNET Modeler/Release 17.5 LTE-1-7

8. 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
LTE-1-8 OPNET Modeler/Release 17.5

9. 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.
OPNET Modeler/Release 17.5 LTE-1-9

10. 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.
LTE-1-10 OPNET Modeler/Release 17.5

11. 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
OPNET Modeler/Release 17.5 LTE-1-11

12. 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:
Table 1-2 Mapping of Logical Channels to Transport Channels
Direction Logical Channel Transport Channel Usage
Downlink Common Control Channel
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
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
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.
(CCCH)
(CCCH)
LTE-1-12 OPNET Modeler/Release 17.5

13. 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 Reporting
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
OPNET Modeler/Release 17.5 LTE-1-13

14. 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].
LTE-1-14 OPNET Modeler/Release 17.5

15. 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.
OPNET Modeler/Release 17.5 LTE-1-15

16. 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.
LTE-1-16 OPNET Modeler/Release 17.5

17. 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 DRX
Cycle?
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 DRX
State 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.
OPNET Modeler/Release 17.5 LTE-1-17

18. 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 during
DRX 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.
LTE-1-18 OPNET Modeler/Release 17.5

19. 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 sleep
period 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.)
OPNET Modeler/Release 17.5 LTE-1-19

20. 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.
LTE-1-20 OPNET Modeler/Release 17.5

21. 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
OPNET Modeler/Release 17.5 LTE-1-21

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/TDD
Parameters
• 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 Parameters1
Channel Bandwidth
BWChannel [MHz] 1.4 3 5 10 15 20
NRB 6 15 25 50 75 100
1. 3GPP TS 36.101 "User Equipment (UE) radio transmission and reception
LTE-1-22 OPNET Modeler/Release 17.5

23. 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 Only
Parameters
• 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
Index
Scheme
(Uplink:Downlink) Downlink %
0 3:2 40
1 2:3 60
2 1:41
3 3:7 70
4 2:8 80
5 1:9 90
6 3:3:2:2 50
1. Default value.
80
OPNET Modeler/Release 17.5 LTE-1-23

24. 1—LTE
Figure 1-5 TDD Configurations
0
1
2
3
4
5
6
• 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)
LTE-1-24 OPNET Modeler/Release 17.5

25. 1—LTE
• Physical Downlink Control Channel (PDCCH)—Such as downlink L1/L2
control channel
— Transports Downlink Control Information (DCI) messages, which are as
follows:
3 Allocations for RAR messages
3 Allocations for CCCH
3 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 >
OPNET Modeler/Release 17.5 LTE-1-25

26. 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 the
downlink channel, if the scheduler is expected to use Channel Dependent
Scheduling (by setting the attribute LTE > Scheduling Mode on the eNodeB as
described in Channel Quality Indicator (CQI) and Link Rate Adaptation). No
measurements are collected if the simulation is run in the
efficiency 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.
LTE-1-26 OPNET Modeler/Release 17.5

27. 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.
OPNET Modeler/Release 17.5 LTE-1-27

28. 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 a
jammer 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 the
transmission time of
a jammer packet
configured?
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).
LTE-1-28 OPNET Modeler/Release 17.5

29. 1—LTE
How is the
frequency band of a
jammer packet
configured?
The frequency band of a jammer packet transmission depends on the values of
the “Jammer Band Base Frequency”, “Jammer Bandwidth”, “Bandwidth Usage
Percentage”, 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
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)
Some attributes are further described below. For more information, see
Single-Band Jammer on page WM-12-2 in the Wireless Module User Guide.
OPNET Modeler/Release 17.5 LTE-1-29

30. 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.
LTE-1-30 OPNET Modeler/Release 17.5

31. 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
Jammer nodes can effectively
simulate interference without
costing simulation run time.
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.
OPNET Modeler/Release 17.5 LTE-1-31

32. 1—LTE
The modulation curves pertaining to LTE are available in the LTE models
directory, <reldir>modelsstdlte, 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
LTE-1-32 OPNET Modeler/Release 17.5

33. 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
OPNET Modeler/Release 17.5 LTE-1-33

34. 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>modelsstdwirelesswrls_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 3 3 3 3 3 3 3 3
Uplink 3 3
LTE-1-34 OPNET Modeler/Release 17.5

35. 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:
Table 1-7 Supported MIMO Spatial Multiplexing Configurations
MIMO
Transmission Technique
Transmit Antennas
(eNodeB)
Receive Antennas
(UE)
2 Codewords - 2 Layers 2 2
2 Codewords - 3 Layers 4 4
2 Codewords - 4 Layers 4 4
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.
OPNET Modeler/Release 17.5 LTE-1-35

36. 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 for 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.
LTE-1-36 OPNET Modeler/Release 17.5

37. 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
OPNET Modeler/Release 17.5 LTE-1-37

38. 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:
SINR
k
SINR(i)
= Σ
i
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:
SINRk SINR(i)
= Σ
+ Σ
i
ri – s
s
------------SINR(i)
ri
s
---SINR(i)
= Σ
i
i
• 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
LTE-1-38 OPNET Modeler/Release 17.5

39. 1—LTE
processing delays are assumed to be “at least” 3 subframe for TDD.
Figure 1-10 MPDU Transmission
MPDU Transmission
MPDU Processing
Delay
MPDU Received ACK/NACK
Received
ACK/NACK
Processing Delay
• 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.
Table 1-8 Number of HARQ Processes for Each TDD Frame Type
HARQ Downlink Support
Index Uplink Downlink
0 7 4
1 4 7
2 2 10
3 3 9
4 2 12
5 1 15
6 6 6
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.
OPNET Modeler/Release 17.5 LTE-1-39

40. 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).
LTE-1-40 OPNET Modeler/Release 17.5

41. 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.
OPNET Modeler/Release 17.5 LTE-1-41

42. 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:
ceil
C
8
  – 1
---
 
Channel Quality Indicator (CQI) and Link Rate Adaptation
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.
LTE-1-42 OPNET Modeler/Release 17.5

43. 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
OPNET Modeler/Release 17.5 LTE-1-43

44. 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
LTE-1-44 OPNET Modeler/Release 17.5

45. 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.
OPNET Modeler/Release 17.5 LTE-1-45

46. 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
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.
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.
• 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.
LTE-1-46 OPNET Modeler/Release 17.5

47. 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.
OPNET Modeler/Release 17.5 LTE-1-47

48. 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:
Qrxlevmeasured Qrxlevmin >
Table 1-9 Cell Selection Criteria
Value Description
Qrxlevmeasured Measured cell RX level value (RSRP)
Qrxlevmin
1
Minimum required RX level in the cell (dBm)
1. Mapped to Cell Selection Threshold on the eNodeB
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.
LTE-1-48 OPNET Modeler/Release 17.5

49. 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”.
OPNET Modeler/Release 17.5 LTE-1-49

50. 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.
LTE-1-50 OPNET Modeler/Release 17.5

51. 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
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.
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.
OPNET Modeler/Release 17.5 LTE-1-51

52. 1—LTE
Cell Monitoring and Reselection Process from Idle Mode
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.
LTE-1-52 OPNET Modeler/Release 17.5

53. 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
OPNET Modeler/Release 17.5 LTE-1-53

54. 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.
LTE-1-54 OPNET Modeler/Release 17.5

55. 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.
OPNET Modeler/Release 17.5 LTE-1-55

56. 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.
LTE-1-56 OPNET Modeler/Release 17.5

57. 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.
OPNET Modeler/Release 17.5 LTE-1-57

58. 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.
LTE-1-58 OPNET Modeler/Release 17.5

59. 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.
OPNET Modeler/Release 17.5 LTE-1-59

60. 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.
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
Architectural and Operational Assumptions for Mobility 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
LTE-1-60 OPNET Modeler/Release 17.5

61. 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
OPNET Modeler/Release 17.5 LTE-1-61

62. 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)
LTE-1-62 OPNET Modeler/Release 17.5

63. 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.
OPNET Modeler/Release 17.5 LTE-1-63

64. 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.
LTE-1-64 OPNET Modeler/Release 17.5

65. 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.
OPNET Modeler/Release 17.5 LTE-1-65

66. 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
LTE-1-66 OPNET Modeler/Release 17.5

67. 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 Wireless 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.
OPNET Modeler/Release 17.5 LTE-1-67

68. 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 External Network
Figure 1-20 LTE Topology with Multiple eNodeBs and EPCs
LTE-1-68 OPNET Modeler/Release 17.5

69. 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”.
OPNET Modeler/Release 17.5 LTE-1-69

70. 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.
LTE-1-70 OPNET Modeler/Release 17.5

71. 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
OPNET Modeler/Release 17.5 LTE-1-71

72. 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
LTE-1-72 OPNET Modeler/Release 17.5

73. 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 Configuration 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.)
OPNET Modeler/Release 17.5 LTE-1-73

74. 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.
LTE-1-74 OPNET Modeler/Release 17.5

75. 1—LTE
Figure 1-25 Set EPS Bearer Definition on Mobile Node
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.
OPNET Modeler/Release 17.5 LTE-1-75

76. 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
LTE-1-76 OPNET Modeler/Release 17.5

77. 1—LTE
Figure 1-27 LTE Per-Node Statistics
OPNET Modeler/Release 17.5 LTE-1-77

78. 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
LTE-1-78 OPNET Modeler/Release 17.5

79. 1—LTE
An example usage of this arrangement is shown below.
Figure 1-29 Arrangement by Tags in the Results Browser
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
OPNET Modeler/Release 17.5 LTE-1-79

80. 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.
LTE-1-80 OPNET Modeler/Release 17.5

81. 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
OPNET Modeler/Release 17.5 LTE-1-81

82. 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.
LTE-1-82 OPNET Modeler/Release 17.5

83. 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.
OPNET Modeler/Release 17.5 LTE-1-83

84. 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
LTE-1-84 OPNET Modeler/Release 17.5

85. 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
OPNET Modeler/Release 17.5 LTE-1-85

86. 1—LTE
Table 1-11 Reference Documents (Continued)
Document Title
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)
LTE-1-86 OPNET Modeler/Release 17.5