Aricent Carrier Aggregation Whitepaper

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



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




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.



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.



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


TDD

Inter-bandFDD

Type of CAand duplex type

CAConfiguration

MaxNumber

of CC

Maximumaggregatedbandwidth

(MHZ)


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


TDD

Inter-bandFDD

Intra-bandnon-contiguous

FDD

4

In R10 three CA configurations are defined as below




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.



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




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




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


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


Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical

layer procedures


Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Medium

Access Control (MAC) protocol specification



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.

[email protected]

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.

Documents

Aricent Carrier Aggregation Whitepaper