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-7-27
Ошибка! Неизвестное имя свойства
документа.
Page 1 of 23
Request For Information of Project “XXX”
Security Level:
Table of Contents
1
Introduction ............................................................................................................................... 4
2
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 ................................................................. Ошибка! Закладка не определена.
3.2 Transport QoS ...................................................... Ошибка! Закладка не определена.
3.3 Transport Security ................................................ Ошибка! Закладка не определена.
3.4 Transport Reliability ............................................ Ошибка! Закладка не определена.
3.5 Transport Operation and Maintenance ................. Ошибка! Закладка не определена.
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 .......... Ошибка! Закладка не определена.
4.9.4 Green Power source ............................................................................................. 14
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
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 .......................................... Ошибка! Закладка не определена.
5.6 Header Compression ............................................ Ошибка! Закладка не определена.
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........................................ Ошибка! Закладка не определена.
5.14 RAN Sharing (Optional) ...................................... Ошибка! Закладка не определена.
5.14.1 Common Carrier eRAN sharing ................ Ошибка! Закладка не определена.
5.14.2 Dedicated Carrier eRAN sharing ............... Ошибка! Закладка не определена.
5.15 LTE-Advanced Feature .................................................................................................. 21
5.15.1 LTE Carrier Aggregation Basic Function（Only for Macro eNodeB） ............. 21
5.15.2 LTE Carrier Aggregation Performance Enhancement（Only for Macro eNodeB）
22
6
Other requirements .................................................................................................................. 23
6.1 Software Management ................................................................................................... 23
6.2 Fault Management ......................................................................................................... 23
6.3 Performance Management ............................................................................................. 23
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
Page 3 of 23
Request For Information of Project “XXX”
Security Level:
1 Introduction
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,
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.
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
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 vendor’s offer should be submitted to:
"[Click here and type information]"
The vendor should address any clarification requirements directly to:
"[Click here and type information]"
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
Page 5 of 23
Request For Information of Project “XXX”
Security Level:
2.2 Scope
2.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.
2.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.
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.
2)
For each release, the vendor should provide a short product description for each
available eNodeB type, including the available configurations, dimensions, output
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
Page 6 of 23
Request For Information of Project “XXX”
Security Level:
power, and flexible indoor/outdoor installation capability.
3)
The vendor should delivered eNodeB which support smooth evolution to LTE-A by
software upgrade.
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
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).
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
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.
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.
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.
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
Page 9 of 23
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
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
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
Page 10 of 23
Request For Information of Project “XXX”
Security Level:
2.6G, 75M;
1.8G, 75M;
800M, 30M;
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
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.
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
Page 11 of 23
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 -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.
4.7 High 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.
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.
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
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.
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.
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.
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.
7)
Multiple system antenna systems for multiple bands should be supported.
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
Page 13 of 23
Request For Information of Project “XXX”
Security Level:
4.9 Green Power Solution
4.9.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.
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, biodiesel…etc
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.
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
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).
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
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 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.
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/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.
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
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.
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.
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
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
Page 16 of 23
Request For Information of Project “XXX”
2)
Security Level:
In active mode LTE – UMTS

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)
X2 and S1 Handover should be supported.
8)
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.
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.
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
Page 17 of 23
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
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.
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 operator’s 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
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
Page 18 of 23
Request For Information of Project “XXX”
Security Level:
according to real deployment environment before deployment.
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)
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
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 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
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),
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
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.
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
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
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 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 .
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
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.
2023-7-27
Ошибка! Неизвестное имя свойства
документа.
Page 23 of 23