Huawei LTE RFP

Request For Information of Project “XXX” Security Level:

Request For Information

Project “XXX”

Section x.0

Guide to FDD LTE RFI section eUTRAN

Oct 30, 2012

2023-4-17 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Page 1 of 21


Table of Contents1 Introduction...............................................................................................................................6

2 General Requirement................................................................................................................7

2.1 Purpose of this Request for Proposal...............................................................................7

2.1.1 Background Information........................................................................................7

2.1.2 Language and Response........................................................................................7

2.1.3 Responses and Questions.......................................................................................7

2.1.4 Contact Information...............................................................................................7

2.2 Scope...............................................................................................................................8

2.2.1 Standard Compliance.............................................................................................8

2.2.2 Contribution to Standardization [Optional]...........................................................9

2.2.3 End-to-End Capability.........................................................................................10

2.2.4 Multi Vendor Environment..................................................................................11

2.3 Roadmap and Network Evolution..................................................................................11

3 Transmission...........................................................................................................................14

3.1 General...........................................................................................................................14

3.2 Transport QoS................................................................................................................15

3.3 Transport Security..........................................................................................................19

3.4 Transport Reliability......................................................................................................22

3.5 Transport Operation and Maintenance...........................................................................24

3.6 GSM/UMTS/LTE Co-transmission...............................................................................26

3.7 Synchronisation design & strategy................................................................................28

4 Site design...............................................................................................................................32

4.1 General...........................................................................................................................32

4.2 eNodeB Architecture and Configuration........................................................................32

4.3 eNodeB Capacity Requirement......................................................................................35

4.4 Multi-antenna strategy...................................................................................................41

4.5 Distributed eNodeB.......................................................................................................44

4.6 Micro eNodeB...............................................................................................................46

4.7 High Reliability Design.................................................................................................49

4.8 Co-site / Co-location......................................................................................................53

4.9 Green Power Solution....................................................................................................55

4.9.1 Power Amplifier (PA)..........................................................................................55

4.9.2 Green design........................................................................................................56

4.9.3 Power Saving Feature Requirement....................................................................56

4.9.4 Green Power source.............................................................................................60

4.10 Technology Convergence and Future Expansion...........................................................60

5 Feature....................................................................................................................................62

5.1 RF Power Management requirement.............................................................................62

5.2 Admission and congestion control requirement.............................................................63

5.3 Scheduling requirement.................................................................................................64


Page 2 of 21


5.4 Mobility Management requirement...............................................................................66

5.4.1 UE camping & cell reselection............................................................................66

5.4.2 PS handover.........................................................................................................68

5.4.3 Voice Continuity..................................................................................................73

5.5 High Speed Coverage....................................................................................................75

5.6 Header Compression......................................................................................................76

5.7 Security Mechanism......................................................................................................76

5.8 Adaptive Modulation Requirement................................................................................78

5.9 Smart Phone Solution....................................................................................................78

5.10 Self-Organizing Network (SON)...................................................................................79

5.10.1 Network Planning Features..................................................................................79

5.10.2 Network Deployment Features............................................................................80

5.10.3 Network Optimization Features...........................................................................82

5.10.4 Network Maintenance Features...........................................................................86

5.10.5 Adaptive ICIC.....................................................................................................89

5.11 Traffic Steering..............................................................................................................89

5.12 Interference Coordination..............................................................................................92

5.13 Coverage Enhancement.................................................................................................92

5.14 RAN Sharing (Optional)................................................................................................94

5.14.1 Common Carrier eRAN sharing..........................................................................94

5.14.2 Dedicated Carrier eRAN sharing.........................................................................98

5.15 LTE-Advanced Feature................................................................................................100

5.15.1 LTE Carrier Aggregation Basic Function（Only for Macro eNodeB）............100

5.15.2 LTE Carrier Aggregation Performance Enhancement （ Only for Macro

eNodeB）.....................................................................................................................102

6 Other requirements...............................................................................................................104

6.1 Software Management.................................................................................................104

6.2 Fault Management.......................................................................................................104

6.3 Performance Management...........................................................................................104

This document contains the Technical Requirements defined from [The Operator’s name]

for the Vendor technical assessment.

[The Operator’s name] seeks the proposals of Long Term Evolution (LTE) network

architecture solution, which will consist of both the Evolved UMTS Terrestrial Radio

Access Network (E-UTRAN) and the Evolved Packet Core (EPC) network. The optimal

LTE solution will need to support future high rate packet data applications on a reliable,


Page 3 of 21

1 Introductio

n


scalable, and cost-effective platform. (please modify according to the practical project

requirement)

[The Operator’s name] requires the proposals on the equipment (Hardware and

corresponding software) to satisfy all expressed requirements. In case a

feature/requirement has dependency on the proposed equipment hardware part, then

this should be clarified and the corresponding hardware to support the

feature/requirement should be included in the proposal.

[The Operator’s name] reserve the interpretation and modification right of the RFI

document.

1.1 Purpose of this Request for Proposal

"[Click here and type information]"

1.1.1 Background Information


1.1.2 Language and Response


1.1.3 Responses and Questions


1.1.4 Contact Information

The vendor’s offer should be submitted to:


The vendor should address any clarification requirements directly to:



Page 4 of 21

2 General

Requirement


1.2 Scope

1.2.1 Standard Compliance

1) The vendor should offer LTE System comply with 3GPP R10 specifications.

2) The vendor should declare which global standards that the eNodeB compliance to.

The list should include but not limited to: 3GPP, ETSI, IEC, ISO, EMC.

3) The Vendor should provide a specific declaration that all aspects of conformity

assessment and documentation to achieve CE Conformity marking have been, or

should be achieved, before product is delivered to XXX operator for test purposes.

1.2.2 Contribution to Standardization [Optional]

1) The vendor should state the number of patents held/filed in LTE

2) The vendor should describe the participation and contributions to the major

standards bodies (3GPP, ITU, IEEE); please list the principle participants, committee

affiliations, and major contributions for each.

3) The vendor should provide the reference list which includes at least xx networks

commercially launched, announced by third party.

1.2.3 End-to-End Capability

The vendor should clearly describe the End-to-End capability of whole system portfolio,

including the LTE/SAE system, Mobile Broadband Backhaul, and Terminals.

1.2.4 Multi Vendor Environment

The Vendor shall have the abundant interoperability tests (IOT) experience with other

vendors’ EPC and terminal devices to guarantee the stable and reliable IOT

performance. The Vendor should provide reference with other vendors in LTE

commercial network to guarantee IOT quality.


Page 5 of 21


1.3 Roadmap and Network Evolution

1) The vendor should provide product roadmap of up to future 2 years by highlighting

the main features of each evolution step.

2) For each release, the vendor should provide a short product description for each

available eNodeB type, including the available configurations, dimensions, output

power, and flexible indoor/outdoor installation capability.

3) The vendor should delivered eNodeB which support smooth evolution to LTE-A by

software upgrade.

1.4 GSM/UMTS/LTE Co-transmission

When the current GSM/UMTS/LTE network are deployed by one vendor, the base station

should support co-transmssion.

1) GSM/UMTS/LTE co-transmission should be supported to provide the operators better

resources utilization and OPEX reduction.

2) UMTS and LTE dynamically share the bandwidth resources with condition should be

supported. In the case of transmission resource congestion in MBTS, UMTS and LTE

high-priority services should be guaranteed. When the demand for UMTS services

decreases or even becomes unnecessary, the bandwidth should be gradually

occupied by LTE services.

1.5 Synchronisation design & strategy

1) The eNodeB should support IEEE1588V2 clock synchronization over IPv4 network to

provide frequency and time synchronization.

2) The eNodeB should support the synchronization with Ethernet(ITU-T G.8261).


Page 6 of 21

3 Transmissio

n


1.6 General

The vendor should show compliance to the 3GPP specifications with the associated

baseline and date, for each eNodeB configuration type (where applicable).

1.7 eNodeB Architecture and Configuration

1) The vendor should describe its eNodeB Portfolio, and the date of availability of

the eNodeB should be provided.

2) One BBU should support GSM/UMTS/LTE three modes.

3) BBU and Remote Radio Unit should support CPRI 4.2 and backward compatible

with CPRI 3.0. The CPRI throughput should support 1.25 / 2.5 / 4.9Gbps.

4) The Base Band Unit (BBU) should be modularly assembled to meet different

requirements of network capacity and faulty board replacement.

5) The BBU should have an expansion capability by inserting cards without

impacting the running service and system performance.

6) The vendor should provide the dimensions of all used equipment / modules.

Confirm the LTE BBU can be installed in the existing outdoor BTS with 2U free

space. The vendor should explain his multi-mode and multi-frequency solution.

7) The vendor should provide the exhaustive list and definition of all the internal

cards of the eNodeB for each eNodeB configuration type. The vendor should

specify all the functionalities supported by each cards.

8) The RRU unit can be installed on a pole, wall, or stand. In addition, the RRU

can be installed close to the antenna to shorten feeder length, reduce signal

loss, and improve system coverage.

1.8 eNodeB Capacity Requirement

1) Per user maximum throughput should support DL:150Mbps(2*2MIMO),

UL:50Mbps(1*2SIMO/1*4SIMO). Per base band board maximum throughput

should support DL:450Mbps(2*2MIMO), UL: 225Mbps.


Page 7 of 21

4 Site

design


2) Per baseband board should support maximum 3600 active users

(RRC_connected) at bandwidth 5M/10M/15M/20M. Per cell should support

maximum 1200 active users (RRC_connected) at bandwidth

10M/15M/20M.

3) Per eNodeB should support maximum 10800 active users (RRC_connected) at

bandwidth 5M/10M/15M/20M

4) At least 64 X2 interface supported by per eNodeB

5) At least 16 S1-flex interface supported by per eNodeB

6) 1800Mhz RRU should support 2×60W output per unit at the top of cabinet.

7) 1800Mhz Macro eNodeB should support 2×80W output per RF unit at the top

of cabinet

8) 2600Mhz/800Mhz RRU should support 2×40W output per unit at the top of

cabinet.

9) 2600Mhz/800Mhz Macro eNodeB should support 2×80W output per RF unit at

the top of cabinet

10) The eNodeB should support scalable bandwidth configuration of

1.4M/3M/5M/10M15M/20M

11) Macro eNodeB should support the UL CoMP within the same eNodeB.

12) The eNodeB should be able to allocate resource blocks (RBs) at the

frequency center to PUCCH to enhance PUCCH coverage and improving

PUCCH demodulation performance.

13) The eNodeB should support Control channel interference rejection

combining (IRC) to protect physical uplink control channel (PUCCH) and

physical random access channel (PRACH) from inter-cell interference.

14) One RF module should support Instantaneous Bandwidth (IBW) list below:

2.6G, C/E:20M, D:30M (RFU, Single-Carrier);

2.6G, 40M (RRU, Dual-Carrier);

1.8G, 40M (Dual-Carrier);

800M, 30M (RFU, Dual-Carrier);

800M, 30M (RRU, Single-Carrier).

15) One RF module should support the whole bandwidth

2.6G, 75M;

1.8G, 75M;


Page 8 of 21


800M, 30M;

1.9 Multi-antenna strategy

The Vendor should support requirements for Multi-Antenna system. This should include

but not limited to:

1) MIMO should be supported:

a) DL 2x2 MIMO: Vendor should support DL 2x2 MIMO, 2-Antenna transmit

Diversity and Adaptive MIMO schemes between UE and eNodeB improving

system downlink performance. Adaptive MIMO, if two transmit antennas are

configured in the eNodeB, the eNodeB adaptively selects one of the four

following modes based on the UE rate and channel quality, including

transmit diversity, open-loop spatial multiplexing, closed-loop spatial

multiplexing, closed-loop rank-1 pre-coding.

1.10Distributed eNodeB

1) The distributed RF unit should support to be placed close to the antenna to reduce

feeder loss and improve eNodeB performance

2) The weight of one fully equipped BBU should be less than 12Kg and can be installed

in 2U space.

3) One RRU should support at least 2Tx/2Rx per module.

4) The volume of RRU with cover should be less than 12 liters and weight should be

less than 15Kg.

5) The fully loaded (100%) and typical (50%) traffic loaded power consumption of

different eNodeB Portfolio should be provided.

6) RRU should support daisy chain topology, for daisy chain at least 3 RRUs can be

cascaded and the distance should reach 20KM as the minimum requirement..

7) BBU should support -48V power supply, RRU should support -48V power supply.

8) The distributed eNodeB should support environment temperature from -40°C to

50°C.


Page 9 of 21


1.11Micro eNodeB

1. The Micro eNodeB should support Bandwidth of 5M/10M/15M/20 MHz.

2. The Micro eNodeB should support at least 2 Receive Diversity Paths and 2

Transmit Diversity Paths.

3. The Micro eNodeB should support Composite RF Power per Transmit Path of

1W.

4. The volume of Micro eNodeB with cover should be less than 12 liters and weight

should be less than 13Kg including the sunshade and internal antenna.

5. The power consumption of Micro eNodeB should be less than 180W including the

power consumption by the Micro module and PoE (Power over Ethernet)

equipment.

6. The Micro eNodeB should be operational from -40°C to 50°C.

7. The Micro eNodeB should support operating from AC mains power only from

normal consumer socket.

8. The Micro eNodeB should support load balancing based on transport QoS.

9. The Micro eNodeB should support Point-to-Point Protocol over Ethernet

(PPPoE).

10. One Micro eNodeB maximum throughput should support downlink 150Mbps and

uplink 50Mbps as the minimum requirement.

1.12High Reliability Design

1) The vendor should describe the redundancy principle for each eNodeB configuration

type.

2) The eNodeB should support channel failure detection under multi-antenna

configuration. It should be able to fall back to single antenna mode when failure

happens to promote the system reliability.

3) The vendor should provide fully reliable deployment of network, including backup

solution in terms of different network hierarchy, and load sharing protection.

4) The working temperature of the outdoor eNodeB cabinet should be -40℃～+55℃.

5) The availability of eNodeB should be higher than 99.999%, the MTBF should be

larger than 155,000 hours, the MTTR should be less than 1hour.


Page 10 of 21


6) The eNodeB should support S1-flex to allow an eNodeB connect to multiple

MMEs in a pool. S1-Flex provides network redundancy and load sharing across

multiple MMEs and SGWs by creating a pool of MMEs and SGWs.

7) The eNodeB should support SCTP (Stream Control Transmission Protocol)

multi-homing to provide fault recovery by failover between redundant network

paths of the S1/X2 interface.

8) The eNodeB should support Intra-baseband Card Resource Pool. The baseband

processing board of the eNodeB should consist of several processing resources.

The processing resources are aggregated into a resource pool to be shared for

user data processing by multiple cells. The new user should be assigned to a

resource which has the least load. When a resource becomes overloaded or in

outage, the eNodeB should reduce the load of the individual resource or move

its existing users to other resources.

1.13Co-site / Co-location

1) The eNodeB should support the co-site or co-location with existing GSM/UMTS

Base Stations, concerning antenna and feeders sharing. Especially reuse of

antenna system methods under Software Defined Radio mode.

2) The vendor should support to provide the LTE solution with the reuse of

existing GSM/UMTS transmission resources.

3) The vendor should support combine GSM, UMTS and LTE components in the

same cabinet. One cabinet should support 3 modes and maximum 18 radio

units in both indoor and outdoor scenarios.

4) Combined Base Station equipment (GSM/EDGE/UMTS/LTE) should be stated:

1. Possibility and limitations for combined eNodeB solution for GSM, EDGE,

UMTS and LTE in the same cabinet. 2. Availability and time schedule for the

combined Base Station solution.

5) The vendor should support common use of equipment when sharing sites

between UMTS, GSM and LTE, e.g. common battery back-up, shared

transmission, shared antenna and feeders should be supported.

6) Isolation requirement for the antenna when co-locate with existing GSM

antenna(s) and/or UMTS antennas should be stated.


Page 11 of 21


7) Multiple system antenna systems for multiple bands should be supported.

1.14Green Power Solution

1.14.1 Power Amplifier (PA)

1) The vendor should adopt Doherty technology in Power Amplifier.

2) The eNodeB should support dynamically adjustable output power to reduce power

consumption.

1.14.2 Green design

The RRU should support the natural cooling mechanism instead of fan.

1.14.3 Green Power source

The vendor should support the alternate energy solutions, such as solar, wind-power, bio-

diesel…etc

1.15Technology Convergence and Future Expansion

1) The BBU should support any combination of two technology of GSM/UMTS/LTE at

the same time. The process capability of each mode (GSM/UMTS and LTE) in one

BBU should be configured respectively to meet different capacity requirement during

network deployment. The vendor should provide the detailed information on how it is

achieved.

2) The RF unit (RRU&RFU) should be hardware ready to support dual technology on

single PA if required in the future. Vendor should clearly specified the RF

performance e.g. carrier quantity ,each carrier power output, for the scenarios of GL

and UL combination. Feature

1.16RF Power Management requirement

1) The eNodeB should support uplink power control, it is essential in controlling the

uplink transmit power of UE by eNodeB, It should also control the interference with

the neighboring cells to improve the system throughput. Uplink control power applies

to Physical Uplink Shared Channel (PUSCH), Physical Uplink Control Channel

(PUCCH), Sounding Reference Signal (SRS), and Physical Random Access

Channel (PRACH).


Page 12 of 21


2) Dynamic downlink power allocation should be supported, this feature should allow

an eNodeB to dynamically set the transmit power at downlink channels to reduce

power consumption while maintaining the quality of radio links. It should provide

flexible power allocation for downlink channels based on the user’s channel quality

and maintains acceptable quality of the downlink connections.

3) DRX (Discontinuous Reception) should be supported; this feature can reduce the

power consumption of UEs and enhances the usage of system control channel.

1.17Admission and congestion control requirement

1) The eNodeB should support admission control function to ensure the system

stability and guarantee the QoS performance by controlling the establishment of the

connections within the maximum resource utilization while satisfying the QoS

requirements. This function will reduce the risk of cell instability by controlling the

number of admitted calls; also it will achieve an optimal tradeoff between maximizing

resource utilization and ensuring QoS by avoiding overload case by checking QoS

satisfaction.

2) The eNodeB should support congestion control through low-priority services release

to adjust the system loading when the system is in congestion or the QoS can not be

met. It can guarantee the QoS for the admitted services while achieving the

maximum radio resource utilization.

3) The vendor should provide operators with a method to differentiate users according

to their priority. High priority users can obtain the system resources in case of

resource limitation. In this way, operators can provide better service to those high

priority users when the network is congested.

1.18Scheduling requirement

1) The eNodeB should support flexibility scheduling algorithm for the operator to select,

such as MAX C/I，Round Robin and PF(Proportional Fair) algorithm..

2) The traditional AMC feature reinforcement through downlink Channel Quality

Indicator (CQI) adjustment under closed-loop mechanism should be supported.

3) The eNodeB should support dynamic scheduling feature, which provides the

function that guarantees the user QoS and achieves efficient resource utilization.

The fairness between different UEs is also considered in the function. The dynamic

scheduling algorithm mainly focuses on the GBR and non-GBR services.

4) The eNodeB should support aperiodic CQI reported on PUSCH and the UE can be

configured to report periodic CQI and aperiodic CQI together or individually.


Page 13 of 21


Aperiodic CQI can offer more detailed channel quality information which may make

the scheduler more efficient.

5) The eNodeB should support UE category 1/2/3/4 as the minimum requirement. The

proposed LTE system needs to respect the signaled UE radio access capability

parameters when configuring the UE and when scheduling the UE. There are five

categories defined in 3GPP TS 36.306.

6) The eNodeB should support Delay-based DL packet bundling which introduces

delay control and bundles DL packets before transmission.

1.19Mobility Management requirement

1.19.1 UE camping & cell reselection

1) The UE camping policy should be supported:

Camping on LTE, where LTE coverage is available

Camping on UMTS or GSM, where no LTE coverage is available but UMTS and

GSM.

Camping on GSM, where only GSM coverage is available

2) The eNodeB should support intra-frequency and inter-frequency cell

selection/reselection function; it is a mechanism for user equipment (UE) to select a

cell to camp in idle mode and to receive the most appropriate service support upon

session activation.

3) In idle mode, the mobility LTE ó UMTS (cell reselection) in both directions should be

supported from day one.

4) In idle mode, mobility LTE ó GSM (cell reselection) in both directions should be

supported from day one.

1.19.2 PS handover

1) In active mode LTE – GSM

Network assisted handover brings interruption down to <1s

PS handover from LTE to GSM should be supported in the first phase

2) In active mode LTE – UMTS

Once LTE coverage is left, the service will be continued in UMTS/HSPA, till end

of the data transfer.


Page 14 of 21


PS handover from UMTS/HSPA to LTE should be supported from day one

3) The coverage-based inter-frequency Handover should be supported. The coverage-

based inter-frequency handover based on UL power also should be supported. It

guarantees service continuity in limited power when a UE moves to the cell edge.

Meanwhile, the signal quality in the serving cell has become too poor to provide the

service for the UE, the eNodeB should support urgent direction function, which

blindly redirects the UE to a neighboring GERAN, UTRAN, or E-UTRAN cell.

4) The eNodeB should support the handover with an inter-RAT GSM/UMTS cell for the

reason of the cell coverage.

5) The eNodeB (with measurement) with an inter-frequency in co-coverage cell to

offload from a heavy loaded cell.

6) The eNodeB should support the handover (with measurement) with an inter-RAT

GSM/UMTS cell to offload from a heavy loaded cell.

7) X2 and S1 Handover should be supported.

8) Data forwarding process is should be supported in PS handover.

1.19.3 Voice Continuity

1) The eNodeB should support CS fall back to GSM/UMTS. In order to increase the

success rate of CS fallback to UMTS, the eNodeB should support perform CS

fallback to UMTS based on UMTS cell load information.

2) The eNodeB should support RIM(RAN Information Management) procedure

according to 3GPP with SIB CS fall back to GSM/UMTS to provide a decreased

delay on CS access. When coverage is different between E-UTRAN and GERAN or

UTRAN, the eNodeB should also support adaptive blind CS fallback function for cell

center users and cell edge users to reduce the CSFB delay.

3) The eNode should support CS fallback to a specified RAT or inter-RAT frequency

based on network requirements such as the network plan and load balancing.

4) The SRVCC solution should be supported for the LTE’s voice service after the IMS

being deployed; to enable LTE system supports voice service and better user

experience. The vendor should provide the roadmap for different phase deployment.

5) The eNodeB should support SRVCC from E-UTRAN only to the highest-priority

UTRAN frequency or to an LCS-supporting UTRAN for VoIP services.


Page 15 of 21


1.20Security Mechanism

1) The eNodeB should support encryption protection for both signaling data and user

data between the eNodeB and the UE. The 3GPP TS36.331 supports two types of

ciphering protection, EIA1 (SNOW3G) , EIA2 (AES) and ZUC. The vendor should

comply with these security mechanisms in the 3GPP specifications.

1.21Adaptive Modulation Requirement

The eNodeB should support DL/UL QPSK, DL/UL 16QAM, and DL/UL 64QAM, this

feature provides a wide range of modulation schemes based on the channel condition.

Higher order modulation schemes, such as 64QAM, can be used under excellent channel

conditions to achieve higher data rates, which can improve the system throughput and

spectral efficiency.

1.22 Smart Phone Solution

1) The eNodeB should support dynamic discontinuous reception (DRX) to keep

smartphones always online but in a low-power state.

2) The eNodeB should support switching a high-mobility UE from the always-online

state to idle mode to reduce signaling and protect the network signaling storm.

The Self-Organizing Network (SON) can assist to improve the LTE network to be a highly

intelligent network. The planning, deployment, optimization, and maintenance SON

processes should increase the operational efficiency of the LTE network and assist in

reducing operator’s OPEX. The following requirements are expected in a self organizing

network.

1.22.1 Network Planning Features

How does your self-planning solution address the following different aspects of the

planning process?

1. Automatic generation of all planning data including RF parameters, radio network

specific data and RRM control parameters with minimum manual intervention

according to real deployment environment before deployment.

2. Automatic adjustment of the planning data, e.g. PCI, neighbor relation, TA


Page 16 of 21

4.1 Self-Organizing Network (SON)


according to concrete detection of radio environment after initial deployment with

default values.

3. Iterative planning and adjustment, i.e. updating planning data including RF

parameters, radio network specific data and RRM control parameters when a

new eNodeB is added into or when a current eNodeB is removed from the

existing network.

1.22.2 Network Deployment Features

How does your SON solution address the following different aspects of the deployment

process?

After the physical installation of the eNodeB hardware and the cable connections are

completed, the eNodeB power can be switched on, then the SON algorithms should

trigger the following configuration processes automatically, please explain how your

system works with respect to:

1. Auto discovery and self installation required

2. Node Authentication

3. Backhaul Transmission Setup

4. Software and configuration file download

5. Self testing

1.22.3 Network Optimization Features

There are many operational parameters in a LTE system. Most are determined through

laboratory simulation and further adjusted in trial networks. Usually, the values of the

parameters are categorized according to a set of typical deployment scenarios. It should

be understood that it should be necessary to optimize frequently these parameters

according to real deployment scenario in order to maximize network performance.

Manual optimization of these parameters generally involves extensive site surveys and

drive testing, analysis of the performance data and re-configuration of the parameters.

SON algorithms automate these processes by diagnosing network problems, identifying

the faults, and invoking the appropriate SON algorithms to resolve the problems.

The vendor should describe whether the SON algorithms address the following key

mechanisms:

1. Support Intra-RAT Automatic neighbor relation (ANR)

2. Support Inter-RAT Automatic neighbor relation(ANR)

3. Support Mobility Robust Optimization Aimed at avoiding ping-pong handover,

handover too early, handover too late, corner phenomenon, and needle

phenomenon, typical mobility control parameters optimization, which includes cell


Page 17 of 21


individual offset, need to be considered to improve the user’s experience.

4. Support intra-RAT MLB (Mobility Load Balancing, MLB), which the eNodeB traffic

load, PRB usage per QCI, HW load should be considered.

5. Support inter-RAT MLB (Mobility Load Balancing, MLB), which the eNodeB traffic

load, PRB usage per QCI, HW load should be considered.

6. TA (Tracking area) is automatically planned and optimized/ maintained in the

entire lifecycle of eNodeB

7. Support PCI conflict detection

8. Support RACH Optimization

1.22.4 Network Maintenance Features

After the planning and deployment stages, the eNodeB will be ready to provide active

services. The maintenance stage will also start. Based on previous field experience, the

maintenance work costs are more due to increased labour and human intervention. The

SON should automate the maintenance processes as much as possible.

Please describe how your SON algorithms address the following key mechanisms:

1. Self Software Upgrade

2. Service verification after upgrade

3. Customized upgrade policy

4. Automatic rollback to previous software version

5. Automatic Inventory

6. Subscriber and equipment trace

7. Cell Outage Compensation should be supported, which provides automatic

detection of cell outage, and automatic adjustment of surrounding cells’ RRM/RF

parameters to compensate outage cells. It solves and shortens the duration of

cell outage that is a critical situation in the network, especially if there is only one

frequency/RAT.

8. Support antenna fault detection

9. Real-time Performance Management and Reporting

1.22.5 Adaptive ICIC

The eNodeB should support Adaptive ICIC (Inter-Cell Interference Coordination),

which can further improve inter-cell interference cancellation performance and

improve cell edge throughput.


Page 18 of 21


1.23Traffic Steering

The eNodeB should support LTE intra/inter frequency load balancing to offload to

neighbor cell which is intra frequency or inter frequency with low load.

The eNodeB should support Inter-RAT load balancing from LTE to GSM/UMTS,

which can offload to neighbor GSM or UMTS cell with low load.

The eNodeB should support Service based handover (or redirection) to UMTS.

When UE initiate a voice call in LTE, serving cell can handover (or redirection) it

into a UMTS neighbor cell to guarantee the voice call more robust.

The eNodeB should support Camp and Handover Based on SPID (Subscriber

Profile ID for RAT/Frequency Priority), which can help to control

subscribers to camp in, redirect or handover to a suitable RAT. In

RRC_CONNECTED mode, when UE triggers an inter-frequency or inter-

RAT handover, eNodeB should can not only choose a suitable target from

the cells but also choose a HPLMN cell for national roaming subscribers

according to the priorities indexed by its SPID.

The eNodeB should support UL Pre-allocation Based on SPID to assign different

UL pre-allocation capability for different subscriber. UL pre-allocation is used

when the cell is in a light load situation to achieve the small latency for a certain

UE.

1) The eNodeB should provide UL Interference Rejection Combining (IRC in 2 way

and 4 way receive) to effectively overcome the inter-cell interference. The

method can be used with receiving diversity and can be used for MIMO decoding

in any scenario.

1.24LTE-Advanced Feature

1.24.1 LTE Carrier Aggregation Basic Function（Only for Macro

eNodeB）

1. The eNodeB should support intra-band carrier aggregation (CA) to allocate up to


Page 19 of 21

4.2 Interference Coordination


a 40 MHz downlink bandwidth for two downlink carriers.

2. The eNodeB should support inter-band carrier aggregation (CA) to allocate up to

a 40MHz downlink bandwidth for two downlink carriers.

1.24.2 LTE Carrier Aggregation Performance Enhancement（Only for

Macro eNodeB）

1. The eNodeB should support carrier aggregation for UEs of Category 6.One

single UE of Category 6 can reach a peak data rate of 300Mbps in downlink and

50Mbps in the uplink.

2. The eNodeB should support differentiated scheduling to carrier aggregation (CA)

UEs and non-CA UEs, thereby CA UEs can achieve better service quality than non-

CA UEs.

3. The eNodeB should support to activate or deactivate the secondary serving cell

(SCell) of a CA UE according to data traffic of the primary serving cell (PCell) of the

UE .


Page 20 of 21


2 Other requirements

2.1 Software Management

The eNodeB should support the hot patches so that the software bugs can be fixed

without interrupting the ongoing services.

2.2 Fault Management

The eNodeB should support the automatic fault supervision of the equipment in the

network elements. With real-time alarm lists and alarm logs, operators can have a

comprehensive view of the actual status of the network at any time. Fault

management should involve fault detection, fault handling, fault correlation, and fault

reporting. With these features, operators can be informed as soon as the fault occurs

in the network and take proper actions to minimize or prevent service disruption.

2.3 Performance Management

1) The eNodeB should support performance management function to monitor the

network performance so that network troubleshooting and optimization can be

implemented, and the real-time KPI monitoring is a more efficient feature.

1) The eNodeB should support Real-time Monitoring of System Running

Information, to diagnose faults through precise information about cells,

subscribers and links with the help of real-time monitoring and graphical

representation of system operation information and quality.


Page 21 of 21

Documents

Huawei LTE RFP