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

2013-10-22

Error! Unknown document property name.

Page 1 of 23

Request For Information of Project XXX

Security Level:

Table of Contents
1 2 Introduction ............................................................................................................................... 4 General Requirement ................................................................................................................ 5 2.1 Purpose of this Request for Proposal ............................................................................... 5 2.1.1 Background Information ........................................................................................ 5 2.1.2 Language and Response......................................................................................... 5 2.1.3 Responses and Questions ....................................................................................... 5 2.1.4 Contact Information ............................................................................................... 5 2.2 Scope................................................................................................................................ 6 2.2.1 Standard Compliance ............................................................................................. 6 2.2.2 Contribution to Standardization [Optional] ........................................................... 6 2.2.3 End-to-End Capability ........................................................................................... 6 2.2.4 Multi Vendor Environment .................................................................................... 6 2.3 Roadmap and Network Evolution .................................................................................... 6 3 Transmission ............................................................................................................................. 8 3.1 General ........................................................................... Error! Bookmark not defined. 3.2 Transport QoS ................................................................ Error! Bookmark not defined. 3.3 Transport Security .......................................................... Error! Bookmark not defined. 3.4 Transport Reliability ...................................................... Error! Bookmark not defined. 3.5 Transport Operation and Maintenance ........................... Error! Bookmark not defined. 3.6 GSM/UMTS/LTE Co-transmission.................................................................................. 8 3.7 Synchronisation design & strategy................................................................................... 8 4 Site design ................................................................................................................................. 9 4.1 General ............................................................................................................................. 9 4.2 eNodeB Architecture and Configuration .......................................................................... 9 4.3 eNodeB Capacity Requirement ........................................................................................ 9 4.4 Multi-antenna strategy ................................................................................................... 11 4.5 Distributed eNodeB ....................................................................................................... 11 4.6 Micro eNodeB................................................................................................................ 12 4.7 High Reliability Design ................................................................................................. 12 4.8 Co-site / Co-location ...................................................................................................... 13 4.9 Green Power Solution .................................................................................................... 14 4.9.1 Power Amplifier (PA) .......................................................................................... 14 4.9.2 Green design ........................................................................................................ 14 4.9.3 Power Saving Feature Requirement .................... Error! Bookmark not defined. 4.9.4 Green Power source ............................................................................................. 14
2013-10-22 Error! Unknown document property name. Page 2 of 23

Request For Information of Project XXX

Security Level:

4.10 Technology Convergence and Future Expansion ........................................................... 14 5 Feature..................................................................................................................................... 14 5.1 RF Power Management requirement ............................................................................. 14 5.2 Admission and congestion control requirement ............................................................. 15 5.3 Scheduling requirement ................................................................................................. 15 5.4 Mobility Management requirement ............................................................................... 16 5.4.1 UE camping & cell reselection ............................................................................ 16 5.4.2 PS handover ......................................................................................................... 16 5.4.3 Voice Continuity .................................................................................................. 17 5.5 High Speed Coverage .................................................... Error! Bookmark not defined. 5.6 Header Compression ...................................................... Error! Bookmark not defined. 5.7 Security Mechanism....................................................................................................... 18 5.8 Adaptive Modulation Requirement ................................................................................ 18 5.9 Smart Phone Solution .................................................................................................... 18 5.10 Self-Organizing Network (SON) ................................................................................... 18 5.10.1 Network Planning Features.................................................................................. 18 5.10.2 Network Deployment Features ............................................................................ 19 5.10.3 Network Optimization Features ........................................................................... 19 5.10.4 Network Maintenance Features ........................................................................... 20 5.10.5 Adaptive ICIC...................................................................................................... 20 5.11 Traffic Steering .............................................................................................................. 21 5.12 Interference Coordination .............................................................................................. 21 5.13 Coverage Enhancement.................................................. Error! Bookmark not defined. 5.14 RAN Sharing (Optional) ................................................ Error! Bookmark not defined. 5.14.1 Common Carrier eRAN sharing .......................... Error! Bookmark not defined. 5.14.2 Dedicated Carrier eRAN sharing ......................... Error! Bookmark not defined. 5.15 LTE-Advanced Feature .................................................................................................. 21 5.15.1 LTE Carrier Aggregation Basic FunctionOnly for Macro eNodeB ............. 21 5.15.2 LTE Carrier Aggregation Performance EnhancementOnly for Macro eNodeB 22 6 Other requirements.................................................................................................................. 23 6.1 Software Management ................................................................................................... 23 6.2 Fault Management ......................................................................................................... 23 6.3 Performance Management ............................................................................................. 23

2013-10-22

Error! Unknown document property name.

Page 3 of 23

Request For Information of Project XXX

Security Level:

1 Introduction
This document contains the Technical Requirements defined from [The Operators name] for the Vendor technical assessment. [The Operators 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, scalable, and cost-effective platform. (please modify according to the practical project requirement) [The Operators 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 Operators name] reserve the interpretation and modification right of the RFI document.

2013-10-22

Error! Unknown document property name.

Page 4 of 23

Request For Information of Project XXX

Security Level:

2 General Requirement
2.1 Purpose of this Request for Proposal
"[Click here and type information]"

2.1.1 Background Information

"[Click here and type information]"

2.1.2 Language and Response

"[Click here and type information]"

2.1.3 Responses and Questions

"[Click here and type information]"

2.1.4 Contact Information

The vendors offer should be submitted to: "[Click here and type information]" The vendor should address any clarification requirements directly to: "[Click here and type information]"

2013-10-22

Error! Unknown document property name.

Page 5 of 23

Request For Information of Project XXX

Security Level:

2.2 Scope
2.2.1 Standard Compliance
1) 2) The vendor should offer LTE System comply with 3GPP R10 specifications. 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. 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.

3)

2.2.2 Contribution to Standardization [Optional]

1) 2) The vendor should state the number of patents held/filed in LTE 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. The vendor should provide the reference list which includes at least xx networks commercially launched, announced by third party.

3)

2.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.

2.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.

2.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. For each release, the vendor should provide a short product description for each available eNodeB type, including the available configurations, dimensions, output
2013-10-22 Error! Unknown document property name. Page 6 of 23

2)

Request For Information of Project XXX power, and flexible indoor/outdoor installation capability. 3)

Security Level:

The vendor should delivered eNodeB which support smooth evolution to LTE-A by software upgrade.

2013-10-22

Error! Unknown document property name.

Page 7 of 23

Request For Information of Project XXX

Security Level:

3 Transmission
3.1 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.

3.2 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).

2013-10-22

Error! Unknown document property name.

Page 8 of 23

Request For Information of Project XXX

Security Level:

4 Site design
4.1 General
The vendor should show compliance to the 3GPP specifications with the associated baseline and date, for each eNodeB configuration type (where applicable).

4.2 eNodeB Architecture and Configuration

1) The vendor should describe its eNodeB Portfolio, and the date of availability of the eNodeB should be provided. One BBU should support GSM/UMTS/LTE three modes. 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. The Base Band Unit (BBU) should be modularly assembled to meet different requirements of network capacity and faulty board replacement. The BBU should have an expansion capability by inserting cards without impacting the running service and system performance. 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. 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. 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.

2) 3)

4)

5)

6)

7)

8)

4.3 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.
2013-10-22 Error! Unknown document property name. Page 9 of 23

Formatted: Font: 10.5 pt, English (U.S.) Not Highlight Formatted: Not Highlight

Request For Information of Project XXX 2)

Security Level:

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

Formatted: Font: 10.5 pt, (Asian) Chine (PRC), (Other) English (U.S.), Not Highlight Formatted: Not Highlight

4) 5) 6) 7)

At least 64 X2 interface supported by per eNodeB At least 16 S1-flex interface supported by per eNodeB 1800Mhz RRU should support 260W output per unit at the top of cabinet. 1800Mhz Macro eNodeB should support 280W output per RF unit at the top of cabinet

8)

2600Mhz/800Mhz RRU should support 240W output per unit at the top of cabinet.

9)

2600Mhz/800Mhz Macro eNodeB should support 280W 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
2013-10-22 Error! Unknown document property name. Page 10 of 23

Request For Information of Project XXX 2.6G, 75M; 1.8G, 75M; 800M, 30M;

Security Level:

4.4 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.

4.5 Distributed eNodeB

1) The distributed RF unit should support to be placed close to the antenna to reduce feeder loss and improve eNodeB performance The weight of one fully equipped BBU should be less than 12Kg and can be installed in 2U space. One RRU should support at least 2Tx/2Rx per module. The volume of RRU with cover should be less than 12 liters and weight should be less than 15Kg. The fully loaded (100%) and typical (50%) traffic loaded power consumption of different eNodeB Portfolio should be provided. 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.. BBU should support -48V power supply, RRU should support -48V power supply. The distributed eNodeB should support environment temperature from -40C to 50C.
2013-10-22 Error! Unknown document property name. Page 11 of 23

2)

3) 4)

5)

6)

7) 8)

Request For Information of Project XXX

Security Level:

4.6 Micro 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 -40C to 50C. 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.

4.7 High Reliability Design

1) The vendor should describe the redundancy principle for each eNodeB configuration type. 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.

2)

3)

The vendor should provide fully reliable deployment of network, including backup solution in terms of different network hierarchy, and load sharing protection.
The working temperature of the outdoor eNodeB cabinet should be -40+55. 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.

4) 5)

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.
2013-10-22 Error! Unknown document property name. Page 12 of 23

Request For Information of Project XXX

Security Level:

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. 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.

8)

4.8 Co-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. The vendor should support to provide the LTE solution with the reuse of existing GSM/UMTS transmission resources. 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. 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. 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. Isolation requirement for the antenna when co-locate with existing GSM antenna(s) and/or UMTS antennas should be stated. Multiple system antenna systems for multiple bands should be supported.

2)

3)

4)

5)

6)

7)

2013-10-22

Error! Unknown document property name.

Page 13 of 23

Request For Information of Project XXX

Security Level:

4.9 Green Power Solution

4.9.1 Power Amplifier (PA)
1) 2) The vendor should adopt Doherty technology in Power Amplifier. The eNodeB should support dynamically adjustable output power to reduce power consumption.

4.9.2 Green design

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

4.9.3 Green Power source

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

4.10 Technology 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. 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

2)

4.11 RF 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).

2013-10-22

Error! Unknown document property name.

Page 14 of 23

Request For Information of Project XXX 2)

Security Level:

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 users 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.

4.12 Admission 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.

4.13 Scheduling requirement

1) The eNodeB should support flexibility scheduling algorithm for the operator to select, such as MAX C/IRound Robin and PF(Proportional Fair) algorithm..

2)
3)

The traditional AMC feature reinforcement through downlink Channel Quality Indicator (CQI) adjustment under closed-loop mechanism should be supported. 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.
2013-10-22 Error! Unknown document property name. Page 15 of 23

Request For Information of Project XXX 4)

Security Level:

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. 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.

4.14 Mobility Management requirement

4.14.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. In idle mode, the mobility LTE UMTS (cell reselection) in both directions should be supported from day one. In idle mode, mobility LTE GSM (cell reselection) in both directions should be supported from day one.

3)

4)

4.14.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
Error! Unknown document property name. Page 16 of 23

2013-10-22

Request For Information of Project XXX 2) In active mode LTE UMTS

Security Level:

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

3)

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

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) 8)

X2 and S1 Handover should be supported. Data forwarding process is should be supported in PS handover.

4.14.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. 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. 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. The SRVCC solution should be supported for the LTEs 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.
2013-10-22 Error! Unknown document property name. Page 17 of 23

2)

3)

4)

Request For Information of Project XXX 5)

Security Level:

The eNodeB should support SRVCC from E-UTRAN only to the highest-priority UTRAN frequency or to an LCS-supporting UTRAN for VoIP services.

4.15 Security 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.

4.16 Adaptive 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.

4.17
1)

Smart Phone Solution

The eNodeB should support dynamic discontinuous reception (DRX) to keep smartphones always online but in a low-power state. 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.

2)

4.18 Self-Organizing Network (SON)

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 operators OPEX. The following requirements are expected in a self organizing network.

4.18.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
2013-10-22 Error! Unknown document property name. Page 18 of 23

Request For Information of Project XXX according to real deployment environment before deployment.

Security Level:

2. Automatic adjustment of the planning data, e.g. PCI, neighbor relation, TA 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.

4.18.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

4.18.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)
2013-10-22 Error! Unknown document property name. Page 19 of 23

Request For Information of Project XXX

Security Level:

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 individual offset, need to be considered to improve the users 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

4.18.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

4.18.5 Adaptive ICIC

The eNodeB should support Adaptive ICIC (Inter-Cell Interference Coordination),
2013-10-22 Error! Unknown document property name. Page 20 of 23

Request For Information of Project XXX

Security Level:

which can further improve inter-cell interference cancellation performance and improve cell edge throughput.

4.19 Traffic 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.

Formatted: Not Highlight

4.20 Interference Coordination

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.

4.21 LTE-Advanced Feature

4.21.1 LTE Carrier Aggregation Basic Function Only for Macro eNodeB
1. The eNodeB should support intra-band carrier aggregation (CA) to allocate up to a 40 MHz downlink bandwidth for two downlink carriers. 2. The eNodeB should support inter-band carrier aggregation (CA) to allocate up to
2013-10-22 Error! Unknown document property name. Page 21 of 23

Request For Information of Project XXX

Security Level:

a 40MHz downlink bandwidth for two downlink carriers.

4.21.2 LTE Carrier Aggregation Performance EnhancementOnly 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 .

2013-10-22

Error! Unknown document property name.

Page 22 of 23

Request For Information of Project XXX

Security Level:

5 Other requirements
5.1 Software Management
The eNodeB should support the hot patches so that the software bugs can be fixed without interrupting the ongoing services.

5.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.

5.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.

2013-10-22

Error! Unknown document property name.

Page 23 of 23