Post on 06-Feb-2018
7/21/2019 Aricent Carrier Aggregation Whitepaper
http://slidepdf.com/reader/full/aricent-carrier-aggregation-whitepaper 1/10
SANDEEP KUMAR JINDAL
Senior Engineering Project Manager
LTE Advanced: Implementing
Carrier Aggregation (CA) forMaximizing Bandwidth
7/21/2019 Aricent Carrier Aggregation Whitepaper
http://slidepdf.com/reader/full/aricent-carrier-aggregation-whitepaper 2/10
1LTE Advanced: Implementing Carrier Aggregation (CA) for Maximizing Bandwidth
LTE Advanced promised peak data rate of 1 GBPS for downlink and 500 MBPS for uplink.Such data rates cannot be achieved through the current 20 MHz bandwidth. CA is a solutionthat was proposed by 3GPP, which not only makes it possible to achieve high data ratesmentioned above, but is also backward compatible with previous releases such as Rel 8 / 9.CA aggregates multiple component carriers to achieve a large transmission bandwidth.
CA enables Communication Equipment Providers (CEPs) and Communication Service Pro-
viders (CSPs) to not only deliver high bandwidths but also helps them maintain backwardcompatibility with previous releases. CA, thus, enables the use of spectrum bandwidth fromdifferent parts of frequency space -- irrespective of their size -- and also provides the abilityto manage control channel interference between high-power macrocell and low-powersmall cell transmissions.
This whitepaper defines CA and delves into its benefits and how it can be leveraged by Com-munication Equipment Providers (CEPs) and Communication Service Providers (CSPs).The whitepaper also discusses the impact of CA on design and implementation of UserEquipment (UE) modem protocol stack.
LTE Advanced: ImplementingCarrier Aggregation (CA) forMaximizing Bandwidth
7/21/2019 Aricent Carrier Aggregation Whitepaper
http://slidepdf.com/reader/full/aricent-carrier-aggregation-whitepaper 3/10
2LTE Advanced: Implementing Carrier Aggregation (CA) for Maximizing Bandwidth
What is CA
CA was introduced as a feature of LTE Advanced in
Release-10 of 3GPP Specifications.
LTE Advanced uses CA of multiple Component Carriers (CCs)
to achieve high-bandwidth transmission (and hence high
data rate). Release 8 LTE carriers have a maximum
bandwidth of 20 MHz. LTE Advanced provides a bandwidth of
upto 100 MHz by supporting aggregation of upto five 20 MHz
CCs.
CA is leveraged in LTE Advanced to increase bandwidth and,
thereby, increase bit rate. To maintain backward compatibility
with Release 8 and Release 9 UEs, aggregation is based on
Release 8/Release 9 carriers.
Each aggregated carrier is referred to as a as a CC, which can
have a bandwidth of 1.4, 3, 5, 10, 15 or 20 MHz and a
maximum of five CCs can be aggregated, hence the
maximum aggregated bandwidth can be 100 MHz. In FDD the
number of aggregated carriers can be different in DL and UL.
However, the number of UL component carriers is always
equal to or lower than the number of DL component carriers.
Individual CCs can also be of different bandwidths. For TDD,
the number of CCs as well as the bandwidths of each CC will
normally be the same for DL and UL.
For UE, each CC appears as a separate cell. UE selects one of
the available cells during cell search procedure and that cell
is called Primary Cell (PCell). So PCell is the one which is
selected by the UE during cell search and used for RRC
connection establishment. Security and mobility procedures
happen only on PCell. Once connection is established,
network can assign additional cells/CCs as additional
resources to the UE. These cells are called Secondary /
Serving cells (SCell) and they are selected by the network
based on the UE capability and the position/location of the
UE. SCells serve the UE simultaneously along with PCell.
The PCell can never be deactivated. There is only one PCell
per mobile device. SCells are activated /deactivated by MAC
layer and get assigned to the mobile device by higher
layers.There can be more than one SCell per mobile device.
The CCs corresponding to the PCell are referred to as the
Primary Component Carriers (PCC) and the CCs correspond-
ing to an SCell are referred to as Secondary Component
Carriers (SCCs).
A terminal may simultaneously receive or transmit on one or
multiple CCs depending on its capabilities like CA support, band
combinations support, cross carrier support etc.
Types of Carrier Aggregation (CA)
CA is allowed between the CCs from same or different bands. The
CCs can be adjacent to each other in frequency domain or not. CA
is also allowed with different CCs in the uplink and downlink. As per
the combination, following CA types are defined:
Intra-Band Contiguous: The CA using the contiguous CCs
within the same operating frequency band (as defined for LTE) is
called intra-band contiguous carrier aggregation. This might not
always be possible, due to operator frequency allocation scenarios.
Intra-Band non-Contiguous: The CA using the CCs from the
same operating frequency band, but having gap(s), in between is
called Intra-Band non-Contiguous CA.
Inter-Band non-Contiguous: The CA having the CCs belonging
to different operating frequency bands is called Inter-Band
non-Contiguous CA.
7/21/2019 Aricent Carrier Aggregation Whitepaper
http://slidepdf.com/reader/full/aricent-carrier-aggregation-whitepaper 4/10
3LTE-Advanced: Implementing Carrier Aggregation (CA) for Maximizing Bandwidth
Symmetric Aggregation: If the number of CCs in both the
uplink and downlink are the same then it is called symmetric
CA.
Asymmetric Aggregation: If the number of CCs in
downlink is more than that of uplink then it is said to beasymmetric CA.
Note: Currently only downlink-heavy asymmetries are
supported, the number of uplink CCs configured for a terminal
is always equal to or smaller than the number of configured
downlink CCs.
Cross-Carrier Scheduling & Non-Cross Carrier
Scheduling
Each CC may use PDCCH to schedule resources for an individ-
ual UE that receives multiple carriers in downlink. This sched-
uling method is backward compatible to LTE Release 8.
Additionally and optionally cross carrier scheduling was
introduced. This method uses the common PDCCH in order to
schedule resources on multiple CCs by using the new carrier
indicator field (CFI),
Cross Carrier Scheduling
The scheduling commands are sent to the UE from the PDCCH
channel of a CC different from the CC where the actual data
gets transmitted on PDSCH/PUSCH channels. Cross- carrier
scheduling is used to schedule resources on SCC withoutPDCCH. Note: PCell cannot be cross-scheduled, it is always
scheduled through its own PDCCH
Non-Cross Carrier Scheduling
The scheduling commands are sent to the UE from the PDCCH
channel of the same CC where data gets transmitted /received on
PDSCH/PUSCH channels. UE is require to listen to all the PDCCH on
all the configured CCs
! !
LTE UE CategoriesIndependent from the LTE Advanced technology components, new UE
categories 6, 7 and 8 are added into LTE Release 10
Search Spaces Search Spaces
CC#1
CC#1
CC#1
CC#1 CC#2 CC#3 CC#4
PDCCH
PDCCH
PDSCH/
PUSCH
PDSCH/PUSCH
CC#3
CC#2
CC#2
#3#4
#1#2
#1 #2
Category 2
Category 1
Category 3
Category 4
Category 5
Category 6
Category 7
Category 8
10296
51024
102048
150752
299552
301504
301504
2998560 1497760
102048
51024
75376
51024
25456
5160 No 1
No 2
No 2
No 2
Yes 4
No 2 or 4
No 2 or 4
8Yes
51024
MaximumDL
Throughput(Bits)
MaximumDL
Throughput(Bits)
Supportfor 64QAMin UL
MaximumNumber ofSupportedLayers for
SpatialMultiplexing
in DL
UECategory
Categories 6 and 7 support peak data rate of 300 Mbps and both support
MIMO 2x2 and/or 4x4. Category 8 is the highest category, which supports
8x8 MIMO and a peak data rate of 3 Gbps. Uplink category 8 leads to 1.5
Gbps data rate. Note: UE category significantly exceeds the IMT
Advanced requirements which provide a peak data rate of up to 1Gbps.
7/21/2019 Aricent Carrier Aggregation Whitepaper
http://slidepdf.com/reader/full/aricent-carrier-aggregation-whitepaper 5/10
LTE Advanced: Implementing Carrier Aggregation (CA) for Maximizing Bandwidth
A. UE CA Bandwidth Classes
New UE bandwidth classes applicable to CA are specified below.
Bandwidth classes are defined in terms of number of resource
blocks with the aggregated transmission bandwidth and the
maximum number of CCs supported. Six UE bandwidth classes
are foreseen, whereas only three are fully specified up to now. R10
and R11. Only 2 CCs are supported till now.
CA Configurations
The requirements for CA in the specification are defined for CA
configurations with associated bandwidth combination sets. For
inter-band CA, a CA configuration is a combination of operating
bands, each supporting a CA bandwidth class. For intra-band
contiguous CA, a CA configuration is a single operating band
supporting a CA bandwidth class.
CA configuration indicates a combination of E-UTRA operating
bands and CA bandwidth classes, for example the configuration
CA_40C indicates intra-band contiguous CA on E-UTRA operating
band 40 and CA bandwidth class C, CA_1A_1A, indicates
intra-band non-contiguous CA on band 1 with one CC on each side
of the intra-band gap. Finally, CA_1A_5B indicates inter-band CA,
on operating band 1 with bandwidth class A and operating band 5with bandwidth class B.
In R11, a large number of additional CA configurations are
defined, as shown below.
B
A
C
D
E
F FFS
FFS
2
2
1 0.05BWChannel(1)
FFS
0.05 max(BW
Channel1(1)BW
(Channel(2)
FFS
FFS
FFS
FFS
Aggregated
TransmissionBandwidthConfiguration
Max
No ofCC
NominalGuardBandBW
GB
CA
BandwidthClass
100NRB,agg
100NRB,agg
[300]200 <NRB,agg
[400][300] <NRB,agg
200100 <NRB,agg
[400] <NRB,agg [500]
Type of CAand duplex type
CAConfiguration
MaxNumber
of CC
Maximumaggregatedbandwidth
(MHZ)
Intra-bandcontiguous
FDD
CA_IC 40
40
20
2
2
1+1
CA_40C
CA_1A_5A
Intra-bandcontiguous
TDD
Inter-bandFDD
Type of CAand duplex type
CAConfiguration
MaxNumber
of CC
Maximumaggregatedbandwidth
(MHZ)
Intra-bandcontiguous
FDD
CA_IC 40
40
20
2
CA_7C 40 2
2
1+1
CA_38C
40 2CA_40C
40 2CA_41C
CA_1A_5A
35 1+1CA_1A_18A
35 1+1CA_1A_19A
35 1+1CA_1A_21A
20 1+1CA_2A_17A
20 1+1CA_2A_29A
20 1+1CA_3A_5A
30 1+1CA_3A_7A
20 1+1CA_4A_12A
30 1+1CA_4A_13A
20 1+1CA_4A_17A
20 1+1CA_4A_29A
20 1+1CA_5A_12A
20 1+1CA_5A_17A
30 1+1CA_7A_20A
20 1+1CA_8A_20A
25 1+1CA_11A_18A
20 1+1CA_25A_25A
Intra-bandcontiguous
TDD
Inter-bandFDD
Intra-bandnon-contiguous
FDD
4
In R10 three CA configurations are defined as below
7/21/2019 Aricent Carrier Aggregation Whitepaper
http://slidepdf.com/reader/full/aricent-carrier-aggregation-whitepaper 6/10
5LTE Advanced: Implementing Carrier Aggregation (CA) for Maximizing Bandwidth
Note that for both R10 and R11 any UL CC will have the same
bandwidth as the corresponding DL CC. Also, for inter-band CA
there will only be ONE UL CC, i.e. no UL CA.
Why CA1. The primary reason for introducing CA in LTE Advanced is the
requirement of the IMT Advanced specifications to meet a 1Gbps
downlink (DL) peak data rate. In LTE Release 8, the peak data rate
that can be reached is around 300 Mbps even with all the best
features utilized. So, methods that can boost the peak DL data rate
were studied and CA was proposed.
In LTE Release 8, bandwidth supported was from 20 MHz till 1.4
MHz. CA is a method by which multiple carriers/channels can be
aggregated to realize a large bandwidth for achieving higher peak
data rates. Thus instead of defining new continuous channel
bandwidths to meet the IMT Advanced peak data rate require-
ments, CA was proposed for smooth interoperability with legacy
Release 8 and Release 9 devices.
2. Another reason was the flexibility CA provides to operators in
choosing the bandwidth and band of different carrier components.
In CA, carrier components with different sizes and different bands
can be combined. Many operators have already obtained different
bandwidths in different bands for existing technologies
(2G/3G/LTE), which can thus be reused for CA. So CA gives theflexibility to the operators that plan to reframe 2G and 3G
spectrum and use LTE Advanced technology.
3. There exists inter-cell interference in heterogeneous network
environment, for example where small cells are deployed inside
Macro cell region for better spectrum efficiency. One of the
problems in deploying small cells with macrocells is the interfer-
ence management especially for control channels like PDCCH. To
avoid this problem, CA cross-carrier scheduling feature can be
used effectively to manage the situation. The control channels of
the macro and picocells can be kept in different CCs while the data
transmission can intelligently use the combined CA capability of
multiple carriers.
Impact of CA on design and implementation at each layer is
described below
1.NAS
There is no impact on NAS protocols. However, changes at
OAM to configure the support of CA and other CA-related
functionality to the lower layers.
2. RRC
UE Capability
During LTE Registration procedure, UE reports CA capability
in UE Capability Information Message.
Impact of CA on Design and Imple-mentation of UEs
Introduction of carrier aggregation impacted mainly RRC, MAC
and the physical layer protocols. While RRC layer impacts are
reasonable, there are almost no changes in PDCP/RLC for CA
except supporting large buffers for higher categories of UEs.
There are significant changes at MAC and Phy In order to keep
Release 8/Release 9 compatibility the protocol changes have
been kept to a minimum. Basically each component carrier is
treated as a Release 8 carrier.
7/21/2019 Aricent Carrier Aggregation Whitepaper
http://slidepdf.com/reader/full/aricent-carrier-aggregation-whitepaper 7/10
LTE Advanced: Implementing Carrier Aggregation (CA) for Maximizing Bandwidth
To configure CA, network send SCell configuration to only
those UEs which are at least release 10 compatible and
support CA. The CA-related information sent by the UE is
summarized below:
• UE category – CA support is implied by UE categories 6, 7,
and 8. However it does not indicate the support for a particular
CA configuration, which is signalled separately.
• Supported band combinations – Indicates the specific
frequency band and channel bandwidth configurations that
the UE support for CA.
• Cross-carrier scheduling support – Indicates that the UE
support cross-carrier scheduling.
•
Simultaneous PUCCH and PUSCH transmission support –For CA-capable UEs, this implies that the UE can simultane-
ously support PUCCH and PUSCH transmission on different
CCs.
• Multi-cluster PUSCH within a CC support – Indicates
baseband (non-band-specific) support for multi-cluster
PUSCH transmission within CCs.
• Non-contiguous uplink resource allocation within a CC
support – Indicates UE support for non-contiguous uplink
resource allocations within CCs.
• Measurement Reporting Event A6 support – Indicates that
the UE support measurement reporting at the trigger of Even
6, which occurs when a neighbour cell becomes stronger than
a serving SCell by an offset.
• Periodic SRS transmission on all CCs support – Indicates
that the UE can transmit periodic SRSs on all SCells.
• SCell addition within the Handover to EUTRA procedure
support – Indicates that the UE can support E-UTRAN inbound
inter-radio access technology (IRAT) handover directly into CAmode.
SCell Addition, Deletion
The CA additional SCells cannot be activated immediately at
the time of RRC establishment. Thus, there is no provision in
the RRC Connection Setup procedure for SCells. They are
added and removed from the set of serving cells through the
RRC Connection Reconfiguration procedure. In the connected
mode, in order to add SCell or modify SCell, network sends
RRCConnectionReconfiguration message having SCellToAdd-
ModList IE to add/modify SCells. To release SCell network
sends RRCConnectionReconfiguration message having SCellToRe-
leaseList.
Note: SCells are added or deleted through RRC signaling whereas
activation/deactivation of SCell is done at MAC layer.
UE does not read SI of SCell. RRC Connection Reconfiguration carries
all the mandatory information for Scell, required to access/configure
the cell like SCell BW, Antenna information, PHICH configuration,
PDSCH/PUSCH configuration, SRS configuration, uplink Power
Control information, PUSCH/PRACH configuration, SCell CQI report-
ing configuration etc.
RRC Connection Reconfiguration also carrier Cross-carrier schedul-
ing configuration for the SCell which indicates, if scheduling for the
referenced SCell is handled by that SCell or by another cell.
Measurement Events
One new measurement event ‘Event A6’is introduced for CA. As
indicated in the UE capability section, event A6 occurs when a
neighboring cell’s strength becomes better than SCell’s strength by
an offset.
Handover
Handover processing for LTE in Release 10 is largely the same as
Releases 8 and 9, except that clarifications are made to refer to PCell
in the measurement-related RRC signaling messages. Handover for
SCell is also possible while keeping the same PCell through the event
A6.
3. PDCP Impact
There is no impact on PDCP protocol
4. RLC Impact
There is not much impact on RLC protocol. Only change at RLC layer
is to provide higher data rates by having a larger buffer size
5. MAC Impact
Introduction of CA mainly influences MAC and the physical layer
protocol. MAC must be able to handle scheduling on a number ofCCs. The MAC layer plays the role of multiplexing entity for the aggre-
gated CCs. Each MAC entity will provide to its corresponding CC its
own Physical Layer (PHY) entity, providing resource mapping, data
modulation, HARQ, and channel coding.
Following are the design considerations/impact at MAC layer:
SCell Activation and Deactivation
A new Mac Control (activation/deactivation) element of 1 Byte is
defined which is a bit map of the configured SCells. For activation of
an SCell the corresponding bit has to be set to 1 for activation. For
deactivation both explicit as well as implicit mechanisms are provid-
ed in
6
7/21/2019 Aricent Carrier Aggregation Whitepaper
http://slidepdf.com/reader/full/aricent-carrier-aggregation-whitepaper 8/10
8LTE Advanced: Implementing Carrier Aggregation (CA) for Maximizing Bandwidth
the specification. Note: Configuration of SCell is done through
RRC signalling as described in the RCC impact section
Cross-Carrier Scheduling
Cross-Carrier scheduling is an optional feature for the UE
introduced in Release 10, UE indicates its support through the RRCsignaling during the UE capability transfer procedure. Cross-carri-
er scheduling is used to schedule resources on an SCell without
PDCCH. A carrier indication field (3 bits) is added to the DCI
formats providing the index of the CC for which the scheduling
grant/scheduling assignment is valid. The Carrier indication field
is optional in the DCI formats. A higher layer provides this informa-
tion to the mobile device. For non-cross carrier scheduling, CIF is
not present. If cross carrier-scheduling is configured for SCell then
UE is not required to decode the PCFICH on that SCell anymore.
Cross Carrier scheduling information contains the starting OFDM
symbol of PDSCH for the concerned SCell.
Uplink HARQ Ack/Nack for DL
The PUCCH channel is always on the Primary CC and not on all
uplink CCs. So, the HARQ Ack/Nack will be sent on this channel if
there is no grant for PUSCH transmission. But there are some
challenges due to CA.
The maximum number of bits to be sent for FDD HARQ Ack/Nack
can be 10 now instead of 2 previously. This function is not depend-
ent upon whether the downlink assignments are cross carrier or
non –cross carrier if HARQ Ack/Nacks are transmitted on PUCCH
channel. Therefore the existing UCI formats like 1, 1a, 1b, 2, 2a and
2b are not sufficient for HARQ Ack/Nack sending. A new UCI
format is defined named UCI format 3 which allows sending more
uplink Ack/Nack bits. As a special case, up to two CC Ack/Nack
can be sent using existing 1b format known as PUCCH format 1b
with channel selection. The higher layer configures the format to
be used either PUCCH format 1b with channel selection or PUCCH
format 3. The order of information transmitted using PUCCH
format 3 is Ack/Nack bits, scheduling request bit and CQI bits.
Simultaneous PUCCH and PUSCHs Now, it is possible that a mobile device is capable of transmitting
PUCCH and PUSCH channels simultaneously. This adds complexi-
ty to existing mechanism along with CA. There are now four
possible cases, namely:
1. Single Carrier with no Simultaneous PUCCH and PUSCH
2. Single Carrier with Simultaneous PUCCH and PUSCH
3. Multiple Carrier with no Simultaneous PUCCH and PUSCH
4. Multiple Carrier with Simultaneous PUCCH and PUSCH
Scheduling Request
There is no major change in the working of this scheduling request
functionality except that scheduling request can also be sent in
UCI format 3.
Downlink CQI reportingThe mobile device shall now report CQI for all the CCs where
PDSCH data gets transmitted. The CQI can either be reported on
PUCCH channel or PUSCH channel. Now, CQI gets reported per
CC wise.
SRS transmission
Now, it is also possible to configure SRS transmission on SCell as
well as on PCell per mobile device by higher layers. The support of
this functionality may not be supported by devices.
Downlink Ack/Nack for UL
In LTE advanced, 4x4 UL MIMO transmission is allowed. This
MIMO transmission results in Multiple Transport Blocks(TB)
getting transmitted in the Uplink direction. The PHICH channels
shall support Ack/Nack support for multiple Transport Blocks.
There is one PHICH channel transmitted per TB.
PDCCH/PHICH channels are bundled for scheduling grants. It
implies that the same CC will carry Ack/Nack which provided the
uplink scheduling grant.
Uplink Transmit Power Control for PUCCH/PUSCH
channels
The TPC power control commands for the PUCCH channel is only
through PCell. The TPC commands for the PUSCH channel will be
through the serving cell which provides the scheduling grant to the
device.
Synchronisation
In Release 10, PCell and SCell are synchronized with the same
single Timing Advance(TA). With Release 11, it is possible to handle
CA with CCs requiring different TA, for example combining CC
from eNB with CC from remote radio heads, So with R11 it is
possible that the PCell and SCell may have different TA values foruplink synchronisation. It implies that a mechanism shall be
defined to compute the SCell TA values as the device only
transmits on the PRACH channel on Pcell.
In R11, it is possible to command the mobile device to initiate
PRACH transmission on any S-Cell using PDCCH channel of the
PCell by sending PDCCH order for the SCell. Now, there is a
concept of Timing Advance Group (TAG). Each and every SCell
7/21/2019 Aricent Carrier Aggregation Whitepaper
http://slidepdf.com/reader/full/aricent-carrier-aggregation-whitepaper 9/10
9LTE Advanced: Implementing Carrier Aggregation (CA) for Maximizing Bandwidth
will belong to a TAG, allocated by higher layers.
The mobile device will initiate PRACH on the SCell based upon
the PDCCH order received on the PCell. The SCell will compute
the TA for the mobile device for the SCell.
The TA for the SCell will be communicated to the device using
MAC layer control element along with TAG.
Aricent Offering
Aricent provides end-to-end support for Modem Stack
development and maintenance. Aricent has deep domain
expertise in the CA space and can provides outsourcing for CA
in the following areas
Maintenance Bug Fixing
• Management and Delivery of Incoming Defects
• Support Verification
New Feature Development
• Delivery of Features / Enhancements
• Planned Optimizations and Performance Improvements
System Integration and System Testing
• Build, Patch , Hot fix & Release management
• Continuous Integration & Environment Automation
• Smoke Test & Integration Test
HW Customization
• New Platform Bring-Up
• Support and Integrate with new RF Engines / Customiza
tions
Customer Support
• Provide On-site / Off-Site Technical Support for Board
Bring-up, Verification and Type Approval
• Plan and Deliver Project Specific Customizations
Other Activities
• Project Planning
• Status Reporting and Alignment with Customer
• Project Operation and Monitoring
• SW Correction Propagations
• Technical Workshops
Aricent has implemented CA on network side for eNodeB and
has its own femto/pico eNodeB IPR which supports CA.
Conclusion
CA is one of the most crucial features of LTE Advanced. The
peak data rate is improved according to the number of aggre-
gate carriers (up to five), with a related impact on the UE
complexity. Impact of CA on design and implementation of
protocol stack is a challenge for user equipment.
Aricent has good understanding and capabilities on CA and also
provides femto/pico eNodeB software enablers which supports CA.
Aricent provides end-to-end support for Modem Stack develop-
ment and maintenance for CA.
About the Author
Sandeep Kumar Jindal is a Senior Project Manager
and has 14 years of experience in the wireless
communication protocols domain. He has signifi-
cant knowledge on UE designing, developing,
functional testing and conformance testing of
various protocols at different layers of LTE, GSM,
GPRS and 3G in NAS and AS.
References
1. 3GPP. Carrier Aggregation explained. http://www.3gpp.org/technolo-
gies/keywords-acronyms/101-carrier-aggregation-explained.
2. 3GPP TR 36.912, Technical Specification Group Radio Access
Network; Feasibility study for further advancements for E-UTRA (LTEAd-
vanced),
3. 3GPP TS 36.331, Technical Specification Group Radio Access
Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
4. 3GPP TS 36.300, Technical Specification Group Radio Access
Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and
Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall
description; Stage 2
5. 3GPP TR 36.913, Technical Specification Group Radio Access
Network; Requirements for further advancements for Evolved Universal
Terrestrial Radio Access (E-UTRA) LTE-Advanced
6. GPP TS 36.211, Technical Specification Group Radio Access Network;
Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels
and Modulation
7. 3GPP TS 36.212, Technical Specification Group Radio Access Network;
Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and
channel coding
8. 3GPP TS 36.213, Technical Specification Group Radio Access
Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures
9. 3GPP TS 36.321, Technical Specification Group Radio Access
Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Medium
Access Control (MAC) protocol specification
7/21/2019 Aricent Carrier Aggregation Whitepaper
http://slidepdf.com/reader/full/aricent-carrier-aggregation-whitepaper 10/10
5
© 2014 Aricent. All rights reserved.
All Aricent brand and product names are service marks, trademarks, or registered marks of Aricent in the United States and other countries.
frog, the global leader in innovation and design, based in San Francisco is part of Aricent.
The company’s key investors are Kohlberg Kravis Roberts & Co. and Sequoia Capital.
info@aricent.com
Aricent is the world’s premier engineering services and software company.
We specialize in inventing, developing and maintaining our clients’ most ambitious
initiatives. Combining more than 20 years of engineering expertise with a force of
more than 10,000 dedicated product engineers, Aricent is the only company in the
world that offers the scale, experience and proven technologies necessary to
deliver for a growing list of global companies, bringing the next generation of break-
through, innovative products to market.