SANDEEP KUMAR JINDAL

Senior Engineering Project Manager

LTE Advanced: Implementing
Carrier Aggregation (CA) for
Maximizing Bandwidth
1
LTE 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 solution
that was proposed by 3GPP, which not only makes it possible to achieve high data rates
mentioned 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 backward
compatibility with previous releases. CA, thus, enables the use of spectrum bandwidth from
diferent parts of frequency space -- irrespective of their size -- and also provides the ability
to manage control channel interference between high-power macrocell and low-power
small cell transmissions.
This whitepaper denes CA and delves into its benets 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 User
Equipment (UE) modem protocol stack.
LTE Advanced: Implementing
Carrier Aggregation (CA) for
Maximizing Bandwidth
2
LTE 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 Specications.
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 ve 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 ve CCs can be aggregated, hence the
maximum aggregated bandwidth can be 100 MHz. In FDD the
number of aggregated carriers can be diferent 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 diferent 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 diferent bands. The
CCs can be adjacent to each other in frequency domain or not. CA
is also allowed with diferent CCs in the uplink and downlink. As per
the combination, following CA types are dened:
Intra-Band Contiguous: The CA using the contiguous CCs
within the same operating frequency band (as dened 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 diferent operating frequency bands is called Inter-Band
non-Contiguous CA.
3 LTE-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 be
asymmetric CA.
Note: Currently only downlink-heavy asymmetries are
supported, the number of uplink CCs congured for a terminal
is always equal to or smaller than the number of congured
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 eld (CFI),
Cross Carrier Scheduling
The scheduling commands are sent to the UE from the PDCCH
channel of a CC diferent from the CC where the actual data
gets transmitted on PDSCH/PUSCH channels. Cross- carrier
scheduling is used to schedule resources on SCC without
PDCCH. 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 congured CCs
!
!
!
!
!
!

LTE UE Categories
Independent 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
8 Yes
51024
Maximum
DL
Throughput
(Bits)
Maximum
DL
Throughput
(Bits)
Support
for 64
QAM
in UL
Maximum
Number of
Supported
Layers for
Spatial
Multiplexing
in DL
UE
Category
Intra-Band Contiguous: The CA using the contiguous CCs
within the same operating frequency band (as dened 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 diferent operating frequency bands is called Inter-Band
non-Contiguous CA.
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 signicantly exceeds the IMT
Advanced requirements which provide a peak data rate of up to 1Gbps.
LTE Advanced: Implementing Carrier Aggregation (CA) for Maximizing Bandwidth
A. UE CA Bandwidth Classes
New UE bandwidth classes applicable to CA are specied below.
Bandwidth classes are dened 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 specied up to now. R10
and R11. Only 2 CCs are supported till now.
CA Congurations
The requirements for CA in the specication are dened for CA
congurations with associated bandwidth combination sets. For
inter-band CA, a CA conguration is a combination of operating
bands, each supporting a CA bandwidth class. For intra-band
contiguous CA, a CA conguration is a single operating band
supporting a CA bandwidth class.
CA conguration indicates a combination of E-UTRA operating
bands and CA bandwidth classes, for example the conguration
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 5
with bandwidth class B.
In R11, a large number of additional CA congurations are
dened, as shown below.
B
A
C
D
E
F FFS
FFS
2
2
1
0.05BW
Channel(1)
FFS
0.05 max
(BW
Channel1(1)
BW
(Channel(2)
FFS
FFS
FFS
FFS
Aggregated
Transmission
Bandwidth
Conguration
Max
No of
CC
Nominal
Guard
Band
BW
GB
CA
Bandwidth
Class
100 N
RB,agg
100 N
RB,agg
[300]
200 <N
RB,agg
[400]
[300] <N
RB,agg
200 100 <N
RB,agg
[400] <N
RB,agg
[500]
Type of CA
and duplex type
CA
Conguration
Max
Number
of CC
Maximum
aggregated
bandwidth
(MH
Z
)
Intra-band
contiguous
FDD
CA_IC 40
40
20
2
2
1+1
CA_40C
CA_1A_5A
Intra-band
contiguous
TDD
Inter-band
FDD
Type of CA
and duplex type
CA
Conguration
Max
Number
of CC
Maximum
aggregated
bandwidth
(MH
Z
)
Intra-band
contiguous
FDD
CA_IC 40
40
20
2
CA_7C 40 2
2
1+1
CA_38C
40 2 CA_40C
40 2 CA_41C
CA_1A_5A
35 1+1 CA_1A_18A
35 1+1 CA_1A_19A
35 1+1 CA_1A_21A
20 1+1 CA_2A_17A
20 1+1 CA_2A_29A
20 1+1 CA_3A_5A
30 1+1 CA_3A_7A
20 1+1 CA_4A_12A
30 1+1 CA_4A_13A
20 1+1 CA_4A_17A
20 1+1 CA_4A_29A
20 1+1 CA_5A_12A
20 1+1 CA_5A_17A
30 1+1 CA_7A_20A
20 1+1 CA_8A_20A
25 1+1 CA_11A_18A
20 1+1 CA_25A_25A
Intra-band
contiguous
TDD
Inter-band
FDD
Intra-band
non-contiguous
FDD
4
In R10 three CA congurations are dened as below
5
LTE 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 CA
1. The primary reason for introducing CA in LTE Advanced is the
requirement of the IMT Advanced specications 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 dening 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 exibility CA provides to operators in
choosing the bandwidth and band of diferent carrier components.
In CA, carrier components with diferent sizes and diferent bands
can be combined. Many operators have already obtained diferent
bandwidths in diferent bands for existing technologies
(2G/3G/LTE), which can thus be reused for CA. So CA gives the
exibility 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 efciency. 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 efectively to manage the situation. The control channels of
the macro and picocells can be kept in diferent 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 congure 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 bufers for higher categories of UEs.
There are signicant 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.
LTE Advanced: Implementing Carrier Aggregation (CA) for Maximizing Bandwidth
To congure CA, network send SCell conguration 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 conguration, which is signalled separately.
Supported band combinations Indicates the specic
frequency band and channel bandwidth congurations 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 diferent
CCs.
Multi-cluster PUSCH within a CC support Indicates
baseband (non-band-specic) 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 ofset.
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 CA
mode.
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 Reconguration procedure. In the connected
mode, in order to add SCell or modify SCell, network sends
RRCConnectionReconguration message having SCellToAdd-
ModList IE to add/modify SCells. To release SCell network
sends RRCConnectionReconguration 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 Reconguration carries
all the mandatory information for Scell, required to access/congure
the cell like SCell BW, Antenna information, PHICH conguration,
PDSCH/PUSCH conguration, SRS conguration, uplink Power
Control information, PUSCH/PRACH conguration, SCell CQI report-
ing conguration etc.
RRC Connection Reconguration also carrier Cross-carrier schedul-
ing conguration 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 A6is introduced for CA. As
indicated in the UE capability section, event A6 occurs when a
neighboring cells strength becomes better than SCells strength by
an ofset.
Handover
Handover processing for LTE in Release 10 is largely the same as
Releases 8 and 9, except that clarications 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 bufer size
5. MAC Impact
Introduction of CA mainly inuences MAC and the physical layer
protocol. MAC must be able to handle scheduling on a number of
CCs. 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
dened which is a bit map of the congured 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
8
LTE Advanced: Implementing Carrier Aggregation (CA) for Maximizing Bandwidth
the specication. Note: Conguration 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 RRC
signaling during the UE capability transfer procedure. Cross-carri-
er scheduling is used to schedule resources on an SCell without
PDCCH. A carrier indication eld (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 eld
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 congured 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 sufcient for HARQ Ack/Nack sending. A new UCI
format is dened 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 congures 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 reporting
The 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 congure 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 diferent 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 diferent TA values for
uplink synchronisation. It implies that a mechanism shall be
dened 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
9
LTE 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 Ofering
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 Verication
New Feature Development
Delivery of Features / Enhancements
Planned Optimizations and Performance Improvements
System Integration and System Testing
Build, Patch , Hot x & 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 / O-Site Technical Support for Board
Bring-up, Verication and Type Approval
Plan and Deliver Project Specic 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 ve), 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 signi-
cant knowledge on UE designing, developing,
functional testing and conformance testing of
various protocols at diferent 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 Specication Group Radio Access
Network; Feasibility study for further advancements for E-UTRA (LTEAd-
vanced),
3. 3GPP TS 36.331, Technical Specication Group Radio Access
Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specication
4. 3GPP TS 36.300, Technical Specication 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 Specication Group Radio Access
Network; Requirements for further advancements for Evolved Universal
Terrestrial Radio Access (E-UTRA) LTE-Advanced
6. GPP TS 36.211, Technical Specication Group Radio Access Network;
Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels
and Modulation
7. 3GPP TS 36.212, Technical Specication Group Radio Access Network;
Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and
channel coding
8. 3GPP TS 36.213, Technical Specication Group Radio Access
Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures
9. 3GPP TS 36.321, Technical Specication Group Radio Access
Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Medium
Access Control (MAC) protocol specication
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 companys key investors are Kohlberg Kravis Roberts & Co. and Sequoia Capital.
info@aricent.com

Aricent is the worlds 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 ofers 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.