Germany SON RFQ 2014 - Annex 02 - SON-Self-Configuration and Self-Optimi PDF

RQ
Chapter Chapter Name

Number
1 3.1.1 General Requirements





48 3.1.1.1 Storage Requirements
49 3.1.1.1 Storage Requirements

50 3.1.2 National Roaming Requirements

55 3.1.3 OSS Requirements
OSS Project Management and Project

61 3.1.3.1
Documentation Requirements

62 3.1.3.1

63 3.1.3.1

64 3.1.3.1

65 3.1.3.1

66 3.1.3.1
SON Auto/Self-Configuration
67 3.1.4
Requirements
68 3.1.4
Requirements
69 3.1.4
Requirements
70 3.1.4
Requirements
71 3.1.4
Requirements
72 3.1.4
Requirements
73 3.1.4
Requirements
74 3.1.4
Requirements
75 3.1.4
Requirements
76 3.1.4
Requirements
77 3.1.4
Requirements
78 3.1.4
Requirements
79 3.1.4
Requirements
80 3.1.4
Requirements
81 3.1.4
Requirements
82 3.1.4
Requirements
83 3.1.4
Requirements
84 3.1.4
Requirements
85 3.1.4
Requirements
SON Auto/Self-Optimization & Use
86 3.1.5
Cases Requirements
87 3.1.5
Cases Requirements
88 3.1.5
Cases Requirements

89 3.1.5
Cases Requirements
90 3.1.5
Cases Requirements

91 3.1.5
Cases Requirements

92 3.1.5
Cases Requirements

93 3.1.5
Cases Requirements

94 3.1.5
Cases Requirements
95 3.1.5
Cases Requirements
96 3.1.5
Cases Requirements
97 3.1.5
Cases Requirements
98 3.1.5
Cases Requirements
99 3.1.5
Cases Requirements

100 3.1.5
Cases Requirements
101 3.1.5
Cases Requirements
102 3.1.5
Cases Requirements
103 3.1.5
Cases Requirements
104 3.1.5
Cases Requirements
105 3.1.5
Cases Requirements
106 3.1.5
Cases Requirements
107 3.1.5
Cases Requirements

108 3.1.5
Cases Requirements

109 3.1.5
Cases Requirements
110 3.1.5
Cases Requirements
111 3.1.5
Cases Requirements

112 3.1.5
Cases Requirements

113 3.1.5
Cases Requirements

114 3.1.5
Cases Requirements
115 3.1.5
Cases Requirements
116 3.1.5
Cases Requirements

117 3.1.5
Cases Requirements

118 3.1.5
Cases Requirements
119 3.1.5
Cases Requirements
120 3.1.5
Cases Requirements
121 3.1.5
Cases Requirements
122 3.1.5
Cases Requirements
123 3.1.5
Cases Requirements
124 3.1.5
Cases Requirements
125 3.1.5
Cases Requirements

126 3.1.5
Cases Requirements

127 3.1.5
Cases Requirements
128 3.1.5
Cases Requirements
129 3.1.5
Cases Requirements

130 3.1.5
Cases Requirements

131 3.1.5
Cases Requirements

132 3.1.5
Cases Requirements
133 3.1.5
Cases Requirements
134 3.1.5
Cases Requirements

135 3.1.5
Cases Requirements

136 3.1.5
Cases Requirements
137 3.1.5
Cases Requirements

138 3.1.5
Cases Requirements

139 3.1.5
Cases Requirements

140 3.1.5
Cases Requirements

141 3.1.5
Cases Requirements

142 3.1.5
Cases Requirements
143 3.1.5.1 Automatic Neighbor Relations (ANR)
147 3.1.5.2 Mass Event Handling


151 3.1.5.3 Load Balancing

Coverage & Capacity Optimization

158 3.1.5.4
(CCO)

159 3.1.5.4
(CCO)

160 3.1.5.4
(CCO)

161 3.1.5.4
(CCO)

162 3.1.5.4
(CCO)

163 3.1.5.4
(CCO)

164 3.1.5.4
(CCO)
165 3.1.5.4
(CCO)

166 3.1.5.4
(CCO)

167 3.1.5.4
(CCO)

168 3.1.5.4
(CCO)

169 3.1.5.4
(CCO)

170 3.1.5.4
(CCO)

171 3.1.5.4
(CCO)

172 3.1.5.4
(CCO)
173 3.1.5.5 Mobility Robustness Optimization (MRO)

183 3.1.5.6 SON Energy Saving Requirements


SON Self-Healing Requirements & Use

189 3.1.6
Cases

190 3.1.6
Cases

191 3.1.6
Cases

192 3.1.6
Cases

193 3.1.6
Cases

194 3.1.6
Cases
195 3.1.6
Cases
196 3.1.6
Cases
197 3.1.7 Parameter Planning Requirements

SON Integration & Tool Chain

210 3.1.8
Requirements
211 3.1.8
Requirements
212 3.1.8
Requirements
213 3.1.8
Requirements
214 3.1.8
Requirements
215 3.1.8.1 Tool Chain Requirements

220 3.1.8.2 Alarms Requirements

234 3.1.8.3 Client Workstation Requirements

237 3.1.8.4 Firewall Integration Requirements
238 3.1.8.4 Firewall Integration Requirements

General North-bound (i.e.
239 3.1.8.5 Management/OAM) Interface
Requirements
Requirements
Requirements
Requirements
Requirements
Requirements
Requirements
Requirements

Requirements
Integration to the Purchaser (Telefnica)

248 3.1.8.6
DCN Requirements

249 3.1.8.6
DCN Requirements
250 3.1.8.6
DCN Requirements
251 3.1.8.6
DCN Requirements
252 3.1.8.6
DCN Requirements
253 3.1.8.7 Operations Agents Requirements

Resilience and Redundancy
259 3.1.8.8
Requirements
Resilience and Redundancy
260 3.1.8.8
Requirements
261 3.1.8.9 Interworking with the NMS Requirements
SNMP-based Management (North-
262 3.1.8.10
Bound)-Interface Requirements
263 3.1.8.10
264 3.1.8.10
265 3.1.8.10
266 3.1.8.10
267 3.1.8.10
268 3.1.8.10
269 3.1.8.10
270 3.1.8.10
271 3.1.8.10
272 3.1.8.10

273 3.1.8.10

274 3.1.8.10
275 3.1.8.10
276 3.1.8.10
277 3.1.8.10
278 3.1.8.10
279 3.1.8.10
280 3.1.8.10
Backup and Restore Requirements for
281 3.1.8.11 Standalone SON deployment (dedicated-
hardware based)
hardware based)
hardware based)

hardware based)
hardware based)

hardware based)

hardware based)

hardware based)
hardware based)

hardware based)

hardware based)
hardware based)
hardware based)
HP Storage Data Protector Agents
294 3.1.8.11.1
Requirements
295 3.1.8.11.1
Requirements

296 3.1.8.11.1
Requirements

297 3.1.8.11.1
Requirements
298 3.1.8.11.2 Disaster Recovery Requirements

303 3.1.8.12
Virtualized SON deployment

304 3.1.8.12

305 3.1.8.12
306 3.1.8.12

307 3.1.8.12

308 3.1.8.12

309 3.1.8.12

310 3.1.8.12
311 3.1.8.12

312 3.1.8.12

313 3.1.8.12

314 3.1.8.12
315 3.1.8.12
316 3.1.8.12.1 Standard Backup Tools Requirements


328 3.1.9 User Interface Requirements


SON Reports Generation & Export

348 3.1.10
Requirements
SON Reports Generation & Export

349 3.1.10
Requirements
Interoperability between C-SON & D-

350 3.1.11
SON Requirements

351 3.1.11
SON Requirements
352 3.1.11
SON Requirements

353 3.1.11
SON Requirements
354 3.1.11
SON Requirements

355 3.1.11
SON Requirements
SON configuration, policy management,

policies creation & injection Interface,
356 3.1.12
and SON Functions Coordination
Requirements
SON configuration, policy management,

policies creation & injection Interface,
357 3.1.12
and SON Functions Coordination
Requirements
Network & Communication Matrix

358 3.1.13
(Connectivity) Requirements

359 3.1.13

360 3.1.13

361 3.1.13
362 3.1.13

363 3.1.13
364 3.1.13

365 3.1.13

366 3.1.13
367 3.1.13
368 3.1.14 SON Metrics Requirements
369 3.1.15 SON Virtualization Requirements
378 3.1.16 Documentation Requirements






SON System Administration

410 3.1.17
Requirements

411 3.1.17
Requirements
412 3.1.17
Requirements
413 3.1.17
Requirements
414 3.1.17
Requirements
415 3.1.17
Requirements

416 3.1.17
Requirements

417 3.1.17
Requirements
418 3.1.17
Requirements
419 3.1.17
Requirements
420 3.1.18 General Security Requirements



442 3.1.18.1 Application Security Requirements


457 3.1.19.1 SON Platform Hardware Requirements
458 3.1.19.1 SON Platform Hardware Requirements
SON Hardware Upgrade Procedure

459 3.1.19.2
Requirements
460 3.1.19.2
Requirements
461 3.1.19.2
Requirements
462 3.1.19.2
Requirements
463 3.1.19.3 SON Recovery Procedure Requirements
464 3.1.19.3 SON Recovery Procedure Requirements
465 3.1.19.4 SON Software Requirements


477 3.1.19.5 SON Software Upgrade Requirements

482 3.1.20 Conformance to relevant Standards
SON Geo-Redundancy for Resilience

485 3.1.21
Requirements
486 3.1.21
Requirements
487 3.1.21
Requirements
488 3.1.21
Requirements
489 3.1.21
Requirements
490 3.1.21
Requirements
491 3.1.22 C-SON SW Roadmaps Requirements


501 3.1.23 BOM Macro 2G SW
505 3.1.25 BOM Macro LTE SW

506 3.1.25 BOM Macro LTE SW
507 3.1.26.1 Regulatory

512 3.1.26.2 Training Requirements
513 3.1.26.3 Project Management

518 3.1.26.4 Testing & Acceptance
521 3.1.26.5 Connectivity & Power

522 3.1.26.5 Connectivity & Power
Requirement Desription
The solution shall support open loop SON functionality for technologies 2G, 3G and 4G.
The solution shall support at least the functionalities:
ANR (Automatic Neighbours Relation)

Load Balance, including:
MLBO - Mobility Load Balancing Optimization, Power Optimization and CCO - Coverage and Capacity
Optimization)
CCO - Coverage and Capacity Optimization: IR (Interference Reductions)
IR (Interference Reductions)
Scrambling Code Self-Optimization
Physical-layer cell identity Self-Optimization
High traffic event Handler (such as soccer matches, carnival parades, rock concerts, etc.)
MRO (Mobility Robustness Optimisation
Energy Saving
RACH Root Sequence Optimization(L)
Policy Management
Self-Healing - COD/CODR/CODC
SON Visualization
Initial Parameter Organizing(IPO)/Automatic Parameter Optimisation (APO)
Automatic Report Generation
The Vendor is required to explicitly state and describe in detail on the availability of each of these
capabilities.
The solution shall support Centralized SON and interoperability with Distributed SON according to
NGMN and 3GPP Recommendations. The Vendor is required to explicitly state and describe in detail
the architecture that is supported.
The solution shall support the major vendors in the market and will offer continued support for future
version upgrades.: Ericsson; Huawei; NSN; ZTE; ALU 3G/4G Femto
The solution shall always support the latest version of network SW releases, as well as being
backwards compatible.
The solution shall support multiple versions of vendors simultaneously.
The vendor shall provide list of Tier 1 customers having a Commercial, Close loop SON solution and
specify operator name, network size, RAN vendor, applications deployed and deployment date.
SON solution shall have easy extensibility to support large scale network management, UMTS 120,000
Cell or LTE 180,000 Cell or GSM 600,000 TRX
The solution shall be able to handle SIB11 considerations automatically.
The solution shall have user-definable trigger criteria.
The solution shall be able to run in real time with minimum 15 minutes interval
The solution shall support multiple data source: import external signature database , performance data,
MDT, MR
The SON solution should have a replay functionality / Overview to see in a map and in a table what kind
of Changes and how many changes were executed in a specific time frame
The solution must be capable of automated 24x7 call data loading (with at least 15 minutes
interval/rop), processing and storage without any detrimental impact on the solution performance.
The solution must be capable of automated 24x7 call data loading (with at least 15 minutes interval/rop)
without any detrimental impact on existing the Telefnica OSS and network.
The solution should provide flexibility to accept naming formats and deployment variations of the
managed objects in the Telefnica Germany network. [The term "managed objects" here explicitly
refers to sites, cell, neighbours, iurs, etc.]
The solution shall clearly distinguish which of the elements are in service and which are in the different
stages of planning and build.
The Vendor shall provide a solution that can be configured to be fully resilient in the event of hardware
failures.
The solution shall be able to draw terrain profiles based on its own cartography, not needing any DTM
provided by Telefnica
The solution shall be able to perform consistency and integrity checks prior to implementation of
changes to ensure that design and system rules are not compromised;
The supplier must be able to demonstrate a proven track record of this kind of work and be able to give
examples of reference networks and the ability to work between network vendors Ericsson, NSN and
other vendors;
Patches on OS level as a solution for discovered errors must not overwrite or disturb the tuned and
working functionality of the SON application.
OS upgrades within the same major OS release as a solution for discovered errors must not overwrite
or disturb the tuned and working functionality of the SON application.
The SON system shall provide tools to enable automatic data consistency checking to ensure the
integrity of input data supplied to the SON system using its Input Interface of the SON system, is being
maintained. Problems with the consistency should reported in a logfile for further analysis.
The SON multi-vendor solution shall support the border in between two different technology vendors
(cross-RAN vendors). The borders should be supported in between any combination of the 2 vendors
from TGE vendor portfolio.
A rollback for all configuration changes in the access network done by SON should be possible for a
minimum time period of 7 days.
The solution shall support closed loop SON functionality with no manual intervention for technologies
2G, 3G and 4G, but with a possibility to stop the SON System if the users have a problem with the
SONs operations.
All SON functionalities must be able to run in fully closed loop as well as in supervised mode whereby
the user has to accept the actions before being implemented in the network.
The solution shall be able to handle HetNet (small cells) layers and scenarios.
SON solution shall provide the security management of user and right.
SON solution shall record all key actions in system logs whenever a SON algorithm is executed.
The solution shall detect new sites coming on air automatically.
The solution shall differentiate sites that were temporarily turned off manually and then back on.
If deployed in closed loop solution shall be able to provision and implement changes in the network
within 12 hours, depending on the application;
Open loop solution shall be able to complete optimization cycle within 24 hours, depending on the
application.
The solution shall support GIS (Geography Information System) visualization including SON result and
network performance (KPIs).
The solution shall take into account network elements such as Femto cells in its analysis and in
displaying data on maps.
The SON solution shall create automatically network clusters based on user configuration
The solution shall be able to detect and take into consideration inaccurate or missing any of the inputs
required preventing ineffective optimization results.
The SON solution shall be open to changes and specific optimization demands, from the customer,
including but not limited to: thresholds, RF policies, cluster definitions, black lists, white lists etc.
Vendor shall provide a separate document detailing the architecture of the offered C-SON solution
The vendor can assume that Telefnica can provide access to 2G/3G/LTE/Femto CM, PM and FM data
sources. However Telefnica cannot guarantee the availability of all possible data sources from all
vendors especially propriety interfaces. If a feature requires a specific data source for a feature then the
vendor shall clearly state this in the Roadmap TAB (i.e. found in the Excel file/Tab C-SON SW
Roadmaps) , e.g. Layer 3 data, Radio Probe data, Measurement Reports, Call Traces, MME traces
etc.
Close integration is required between the C-SON platform and the RAN/Femto vendors' OSS and other
interfaces. The C-SON vendor shall outline the process used for ensuring compatibility between the C-
SON RAN vendors' OSS and all interfaces needed as a data source. For example working directly with
the RAN vendor, using the operator as a middle-man for information exchange, or following the new
OSSii process with NSN/Huawei and Ericsson ( http://www.ossii.info/about-ossii/ ). Any solutions based
on reverse engineering of any RAN vendors' interfaces which are found to breach any contractual
agreements between Telefnica and our RAN vendors will be rejected.
Vendor shall provide information that indicates how quick the C-SON vendor can adapt their solutions
to address the situation whereby Telefnica introduces new systems such as:
New RAN vendor for equipment (base stations, BSC, transmission, etc.)
New PM Tool (currently MyCom, etc)
New Planning Tool (currently ATOLL and EPOS / ASSET / Trans Tool, etc.)
New Configuration Tool supplier (currently there are many and different tools at O2 and Eplus)
New supplier for the Multi-Vendor alarm monitoring (at operational side of Eplus - ZTES, TeMIP)
Other types of new products that may be introduced
If the trace data is used as a source then the system should anonymize or drop any sensitive subscriber
relevant information as IMSI, MSISDN or IMEI. The cell ID can be used but never in connection with the
subscriber relevant information. The vendor should clarify which anonymization processing is used in
the solution.
The SON solution shall include the flexibility for a second party (for example Telefnica) to develop own
SON modules & algorithms and incorporate/integrate them into the vendors SON system (adding to
those the vendor provides), or to use an interface the SON system can provide for second party SON
modules & algorithms development & integration. Such flexibility shall include for example APIs or any
other means that enable a second party to incorporate own SON algorithmic modules.
The solution shall be able to store raw PM (Performance Management) data for at least 15 days, hourly
data for at least a month, and daily data for at least 15 months
The solution shall be capable of storing parameter history for at least one year, for all network
parameters.
The SON solution shall support the inter PLMN and inter vendor handover.
The supplier should refer to an operator where the ability to perform National Roaming optimization was
successfully demonstrated. Please name the RAN vendors. Please add contact details.
The solution shall support National Roaming scenarios within different RAN vendors.
The solution shall support separated infrastructure National Roaming scenarios. Please explain your
methodology.
The solution shall support shared infrastructure (co-located) National Roaming scenarios. Please
explain your methodology.
The solution shall be capable of sending commands to the OSS automatically without requiring manual
intervention.
The solution shall allow for manual intervention and validation before sending commands to the OSS.
The solution shall be capable of retrieving data from the OSS automatically, with no manual
intervention.
Continued support for version upgrades of third party vendors log files (such as Huawei, Ericsson,
Alcatel-Lucent and NSN) and other necessary OSS data (PM and CM) must be part of the basic scope
of this proposal. The term "log files" here explicitly refers to control-plane messages from the BSC, RNC
and eNode saved in files.
The solution should be able to work alongside with conventional open loop OSS processes to eliminate
implementation collision and discrepancies.
It should be possible to limit the number of plans and/or the number of actions per plan to avoid
potential OSS (NMS) overload.
The Vendor shall provide a dedicated Project Manager as OSS Spoc for all OSS Project Management
issues.
The Vendor shall provide a High level Design Document.
The Vendor shall provide a Detailed Design Document.
The Vendor shall provide a project specific Installation Guideline Document for the SON Solution.
The Vendor shall support the initial implementation of the solution with the provision of suitable trained
and skilled staff.
The Vendor shall ensure the quality of the created documents with the provision of suitable trained and
skilled staff.
The solution shall support automatic NE status check in the deployment process.
The C-SON solution shall be able to monitor, compare and correct parameters and settings in a
centralized manner and independently of RAN vendor.
All configuration parameters and settings of a BS shall be automatically discovered, read and sorted in
a common database by the SON solution.
Parameters (defined by the operator) shall be monitored, audited and checked against planning
(repeating consistency check task).
The repeating consistency check interval shall be with minimum 1hour.
Inconsistencies shall be reported by the SON solution (file report or online report).
According to definable policies (scope, limits, network element white- and black-list) discovered
inconsistencies shall automatically be configured to the network by the SON solution. The target
configuration shall be taken from planning database or be a pre-defined value configurable in the SON
system.
Auto-Configuration tasks shall be able to be scheduled at a certain date (for instance at Saturday, 02:00
a.m.).
Auto-Configuration shall be done automatically or with explicit confirmation by an operator
(configurable).
All configuration changes made by the SON system shall be documented and logged (history, error
protocol, version control based).
A rollback/undo function of completed configuration changes should be able to be triggered by the
operator or automatically when KPI fall off after the changes.
The SONs user access control system should be able to create and administrate users with different
configurable access levels (administrator, operator, read-only).
The solution shall rectify any discrepancies in the parameter settings of new sites coming on air
automatically.
The solution shall automatically generate and provide an initial configuration/commissioning data file
from planning data.
The solution shall ensure the automatic integration of a new cell to existing network according to layer
management strategy operator.
The solution shall configure the neighbour relationship of the new cell automatically directly after the
new cell is on air.
Use Case 1: - LTE eNodeB initial optimisation: The solution shall plan the neighbours related to the
environment of the eNB (see ANR requirements) and implement the correct tilts via RET based on
network data etc..
Use Case 2: 3G NodeB initial optimisation: The solution shall plan all relevant neighbours related to the
environment of the NodeB and shall optimise optionally the CPICH power etc..
Use Case 3: 2G site initial optimisation: The solution shall plan all relevant neighbours related to the
environment of the site.
The solution shall have user-definable periodicity criteria.
The solution shall automatically identify missing neighbours based on network/UE measurements
and/or network performance KPIs.
Delete neighbours which have a negative impact on network performance based on network
performance.
When adding or deleting neighbours the solution shall rank all neighbours to ensure that the best
alternatives are in the neighbour list.
When adding new neighbours to a full neighbour list the solution shall rank all neighbours to be sure the
best alternatives are in the neighbour list.
When adding new neighbours the solution must consider the average distance between the evaluated
sector and their actual neighbours.
Rollbacks of ANR actions which are not performing as expected, degrading the network performance,
must be done based on network performance measurements (KPIs) in a closed loop cycle.
The solution shall optimize & update the neighbour Priority parameter automatically based on a rank of
neighbours.
The solution must consider the impact on the Primary Scrambling Code and Physical-layer cell identity
before making any changes.
The solution shall allow for the blacklisting of sectors that can never be added to a relationship.
The solution shall allow for the whitelisting of sectors that can never be removed from a relationship.
The solution shall allow for the whitelisting of Femto Sectors from other vendors that can never be
removed from a relationship.
The solution shall support intra-carrier neighbour relationships.
The solution shall support inter-carrier neighbour relationships.
The solution shall support following intra-RAT and inter-RAT neighbour relationships, such as:
2G to 2G
2G to 3G
2G to 4G
3G to 2G
3G to 3G
3G to 4G
3G to Femto
3G to Small Cells
4G to 2G
4G to 3G
4G to 4G
4G to Femto
4G to Small Cells
And for each Inter-RAT relationship the vendor shall provide supplementary information on whether
vendor can handle at least the following:
a. Handover (HO)
b. Redirection: - via measurements; - blind
c. Reselection
d. CSFB:- via HO ; - via measurements; - via HO
e. SrVCC
The solution must allow for the definition of the maximum number of total neighbours.
The solution must allow for the definition of the maximum number of inter-carrier neighbours.
The solution must allow for the definition of the maximum number of intra-carrier neighbours.
The solution must allow for the definition of the maximum number of iRAT neighbours.
The solution shall detect and list overshooting sectors that were not added to neighbours.
The solution shall support use good neighbouring cells to replace bad neighbouring celling
automatically when the NRT is full.
The solution should be able to off load traffic to neighbours without degrading the performance of the
selected neighbour and the network.
The solution should support UL, and UL iRAT load balancing.
The solution shall be able to balance the traffic by adjusting: Admission thresholds; CS Power Settings;
PS Power Settings; Handover hysteresis; Reselection thresholds; Idle access/admission thresholds.
The solution will make changes to triggered sector as well as selected neighbours.
The solution shall support intra-frequency load balancing.
The solution shall support inter-frequency load balancing.
The solution shall support balancing between carriers in idle mode.
Rollbacks/Reverts of load balance changes which are not performing as expected, degrading the
network performance, must be done based on network performance measurements (KPIs) in a closed
loop cycle.
The solution shall allow for the definition of the evaluation time period before rollback.
Solution shall contain accelerated load balancing mechanisms to enable faster reactivity to severe
congestion issues.
High traffic event Handler: To handle high traffic events like music festivals, soccer matches, carnival
parades, etc., the solution must support the use of real time PMs (less than 5 minutes periodicity)
reacting to severe congestion issues and balancing the traffic in a closed loop cycle.
The solution shall support RACH parameter optimization to achieve optimal performance when traffic
load is heavy.
The solution shall support long term congestion, tidal effect, traffic burst load problem.
The solution shall support interference reduction by optimization of parameter including power control,
HARQ or CPICH Power or RET.
The solution must consider the impact on network performance before making any changes on Primary
Scrambling Codes.
The solution must not introduce any Primary Scrambling Code conflict when making changes.
The solution must consider the impact on the Primary Scrambling Code before making any changes.
Rollbacks/Reverts of Primary Scrambling Code changes which are not performing as expected,
degrading the network performance, must be done based on network performance measurements
(KPIs) in a closed loop cycle.
The solution shall allow automatic Physical-layer cell identity planning and optimization taking into
account different network layers, such as Macro, Small Cells and in-building.
The solution shall automatically detect and correct any Physical-layer cell identity conflict.
The solution shall allow user-definable Physical-layer cell identity working ranges.
The solution must consider the impact on network performance before making any changes on Physical-
layer cell identities.
Rollbacks/Reverts of Physical-layer cell identity changes which are not performing as expected,
degrading the network performance, must be done based on network performance measurements
(KPIs) in a closed loop cycle.
The new candidate neighbour shall not be added if its distance from the evaluated sector exceeds the
average distance, defined by the solution, between the evaluated sector and their actual neighbours,
and maybe also trigger as an over-shooter.
The solution must not introduce any Primary Scrambling Code / Physical-layer cell identity conflict when
making changes, and should also highlight (indicate/communicate) this conflict.
The solution shall detect sites out of service to prevent unnecessary neighbour deletions, and it should
be possible for the operator to use a logical NBR weight calculation with a sliding time window to avoid
making many changes during a short site outage.
The solution shall support fast ANR with trace data less than 10 minutes.
The solution shall support UMTS Blind Neighbour Relationship.

The solution shall be able to optimize
coverage and capacity by adjusting CPICH Power;
Tilt and Azimuth;
HO parameters;
RAN Feature Optimization:
Traffic Steering features,
Cell Redirection features,
HSPA/HSPA+ features.
Also the number of licenses for each feature must not be exceeded.
The solution shall support optimization for different network layers, such as Macro, Small Cells and in-
building.
3G Scrambling Code Self-Optimization NOTE:
with 512 Codes Scrambling Code Planning is not a big deal
The solution shall allow automatic Primary Scrambling Code planning and optimization taking into
account different network layers, such as Macro, Small Cells and in-building. NOTE: With 512 Codes
Scrambling Code Planning is not a big deal
The solution shall automatically detect and correct any Primary Scrambling Code conflict. NOTE: at
least detection is necessary
4G Physical-layer cell identity Self-Optimization
The SON solution shall support Frequency optimization (2G). Please explain the methodology used and
how many frequencies can be changed. Is it really SON or the old Double BA list rotation algorithm?
Please explain in details.
The SON solution shall support 2G-3G traffic steering methodology.
The solution shall respect the allowed distance in scenarios where one sector faces urban area while
the other one is facing rural/ low density area.
The solution shall support deletion of unutilized neighbours and neighbours with negative contribution to
the KPIs.
When adding or deleting neighbours the solution shall rank all neighbours to ensure optimized
neighbour list.
The solution shall support all types of White/Black Lists.
The supplier shall support planned Mass Event optimization.
The supplier shall refer and show track record in handling a multi thousands people Mass Event within
a tier 1 operator. Please provide the methodology used in details.
The supplier shall support unplanned Mass Event optimization.
The supplier shall refer to a live example. Please state the country and the operator details. Please
provide the methodology used in details.
The module shall not create coverage holes (more than before).
Minimum and maximum ranges CPICH shall be set at the cell, cluster, group of cells or RNC level.
The load balancing mechanism shall have the ability to foresee congestion build-up and react before
critical KPIs are affected.
The SON solution shall consider interference assessment in its algorithm.
The solution shall support MLB in HetNet.
The solution shall be able to balance the traffic by evaluating:
Traffic Usage of the source and target sectors/carriers;
Power Consumption of the source and target sectors/carriers;
Code Usage of the source and target sectors/carriers;
Channel Usage (Hardware) of the source and target sectors/carriers;
The distance between the source and target sectors/carriers.
NOTE: The solution must take into account: (1) that Telefnica has DC activated; (2) HSPA User
balanced.
The solution shall allow for the blacklisting of sectors that can never be used for load balancing. E.g. as
can be necessary for indoor optical system sites.
The Solution shall be able to provide recommendations on physical tilt antenna changes in case no
RET available. Please explain the methodology.
The solution shall have a mechanism to protect against "Ping-Pong" RET toggling.
The solution shall provide a security mechanism that checks the input data, and does not allow for
optimization of neighbourhoods if the necessary information is not available.
The solution shall generate reports on cells in which RET is unusable/faulty.
The solution shall support optimization of UL interference. Please state which parameters can be
changed.
The solution shall track and display changes in KPI as a result of RET Optimization.
The SON solution shall support PCI setting policy ranging between free policy to operators strict
policy.
The SON solution shall consider the effect on the overheads on other channels planning.
The SON solution shall consider vendor specific limitations. Please elaborate per specific vendor.
The SON solution shall consider multi carrier scenarios.
The SON solution shall consider local and general PCI setting constrains.
The SON solution shall perform pre-provisioning analysis (evaluate optimization results, resolved and
new conflicts before implementation).
The solution shall support CCO in UMTS Network.
The solution shall support CCO in LTE Network.
The solution shall support detect and solve weak coverage, pilot pollution, overlapping coverage
problem.
The solution shall support reducing the number of early handovers.
The solution shall support reducing the number of late handovers.
The solution shall support MRO in Ping-Pong scenario.
The solution shall support iRAT MRO including U to G, L to U, L to G.

The solution shall support MRO in UMTS network.
The solution shall support LTE MRO at per-UE level.
The solution shall support MRO in LTE network.
The solution shall support MRO taking into account different network layer, such Marco, small cell,
indoor coverage and etc.
The solution shall support MRO for inter-frequency.
The solution shall support MRO for intra-frequency.
The solution shall enable power-down of the eNB for energy savings.
The solution shall support switching off a cell or network element or restrict the usage of physical
resources for energy saving purposes (GUL, including Macro and small cell).
The solution shall support switching on a cell or network element or resume the usage of physical
resources which have been Energy Saving activated before(GUL, including Macro and small cell).
The solution shall support ES parameter policy adjustment based on network traffic model. (GUL,
including Macro and small cell).
The solution shall support NE energy saving on RF channel level, carrier level, site level.
The solution shall support result evaluation and display for GUL ES.
The solution shall detect cell outages automatically.
The solution shall compensate for a cell experiencing the outage by changing parameters of the
surrounding cells.
The solution actions shall include Neighbours additions/removals.
The solution actions shall include RF adjust.
The solution actions shall include Admission Control Parameters changes.
The solution shall revert changes once the cell outage is over.
The solution shall revert changes that are determined to not be beneficial to the network performance
KPIs.
The solution shall monitor health the cells status and identify faulty cells. The minimum cycle of
monitoring shall be 15 minutes.
Trigger threshold shall be user-definable.
The solution shall allow user-definable parameter ranges (min/max).
The solution shall allow parameter changes by user-definable steps within its range.
In the case of inter-frequency load balancing, the solution shall allow for the definition of separate
parameter ranges for different band carriers.
The solution shall support the definition of different optimization profiles depending on KPIs degradation
levels.
The solution shall allow for the definition of separate parameters and guidelines for different network
layers, such as Macro, Small Cells and in-building.
The solution shall allow the user to select which sectors can be changed and which cannot, with
possibility of exclusion of Border-Cells.
The solution shall allow user-definable Primary Scrambling Code working ranges.
Any return to TOC data (CPM) and maybe to CCM is needed to include SON changes in the planning
process and do not overwrite with new TOC export or CCM deltas.
By adding new adjacencies for 2G the solution must consider the impact on the frequency before
making any changes. The solution
must not introduce any adjacencies if there are any frequency conflicts (e.g. same frequency for both
cells). If SON in this case will find a
new frequency or an Optimizer makes the decision in consultation with the Frequency Planner has to be
defined.
By adding new adjacencies for 3G the solution must consider the impact on the primary scrambling
codes before making any changes. The solution must not
introduce any adjacencies if there are any code conflicts (e.g. same Code for both cells).
If SON in this case will find a new code or an Optimizer makes the decision in consultation with the
Code Planner has to be defined.
If SON will change codes or frequencies in border areas a delimited spectrum has to be respected.
There is an allowed frequency/code list for every cell (supply by Radio Parameter Planning).
The solution shall be able to consider neighbour optimisation of network elements still not on air but in
the planning stage.
The solution shall provide an interface with existing Telefnica tools/network (tools include CPM), in
order to get the network physical data (coord, azimuths, cell ID's, etc) as part of the basic scope of this
proposal.
The Vendor shall dimension and provide the overall system solution and architecture design to meet
Telefnicas deployment scenario/architecture (layer 3).
The Vendor shall implement their solution to interface with the existing Telefnica systems as part of
the basic scope of this proposal. The Vendor shall bear all costs involved to interface their tool with
Telefnicas existing systems.
The solution shall provide output (snapshot) of changes to backfill legacy data build tools (IPD).
The solution shall provide an interface with existing Telefnica planning databases.
The SON solution shall provide an integration interface that enables second-party systems to read data
or events exported by the SON solution. The integration interface shall include an SQL-interface (SQL-
protocol) to access data the SON solution can make accessible to second party tools.
Vendor shall provide a description of the integration interface(s), detailing the following:
Parameters of the SON system or its individual SON modules a second party tool (e.g. CPCM) can
Read or Write (change value), and any limitations on the Read/Write frequency permissible.
Types of data or logs the SON system can export for use by some second party tools, and export
frequency permissible and configurable
Protocols or methods that can be used by a second party tool to interact with the SON system (e.g. by
SQL, file dump in some formats such as XML, or other methods),
A list of second party tools the vendor thinks could make use of data exported by the SON system,
provide input into SON, or read or write SON interface parameters made accessible by the SON
system.
The SON solution shall provide an interface through which a second party Tool like CPCM can poll the
SON system, using SQL, to provide it with data/information about the cells SON is operating on (i.e.
cells under the scope of SON w.r.t. parameters configurations and optimization) at any given time
during the operation of SON. Also, it shall be possible to do the polling of the data/information by the
second party tool by scheduling the polling task or manually initiating the polling at any moment.
In case the whole network (i.e. all necessary network elements and topology) can be imported into the
SON solution's Database, it shall be possible for the SON solution to complementarily interwork with a
second party configuration tool (normally used for traditional non-SON based configurations), e.g.
CPCM, such that given a differentiating factor, the tool (like CPCM) could actually decide which MOCs
(managed objects) it can configure (the old way)while it leaves the other MOCs to be solely configured
and handled by SON (because they are solely managed by SON).
Considering the Tools/Systems on Figure 3 and the associated Table that describes the Tools
(below the figure), vendor shall describe the SON solution capability (at present or in the future) to
integrate with the Tools for planning, configuration, processing, data bases, etc, shown on the figure
and its associated table below it, giving details on what it would take for the SON solution to be able to
work with those Tools.
Any potential or actual impairment of the functionality or traffic handling capability of the Vendors SON
solution or any Services provided shall be detected and raised as alarm.
Any failure of redundant capacities or units shall be raised as an alarm.
Every system component shall be covered by alarms.
Every network component shall be covered by alarms.
Every network connection shall be covered by alarms.
Detailed alarms shall be generated on application failure.
Detailed alarms shall be generated on communication failure.
Detailed alarms shall be generated on process failure.
Detailed alarms shall be generated on connectivity loss.
Detailed alarms shall be generated on quality of service failure.
Detailed alarms shall be generated on hardware error.
Detailed alarms shall be generated on overload situations (capacity alarm).
It shall be possible to suppress a single type of event or alarm on the SON solution in a way that these
events or alarms are not forwarded to the upper Fault-management System.
The Vendors Solution shall be able to provide Alarms via SNMP trap and syslog protocol.
On request by Purchaser (Telefnica) the Vendor shall support Purchaser (Telefnica) in the effort to
integrate the SON Client Applications to the existing Purchasers clients infrastructure.
The Vendor shall provide and support all SON Client Applications for current Citrix version.
The Vendor shall support the integration to Purchaser (Telefnica) internal Citrix environment Solution.
The Vendor shall provide a brief description, not exceeding one page on, how all traffic between the
SON, the Network Elements and the SON Client can be monitored either with a standard stateful packet
inspection firewall or an application gateway. If this description is provided in a separate file please state
a reference here.
The Vendor shall provide a complete Communication Matrix with an detailed description of all relevant
IP connections, ports and protocols.
The Vendors SON Solution shall support North-Bound-Interfaces for Fault management.
Vendor shall be compliant to standards for each Northbound interface delivered as part of the solution.
No Northbound interface shall be proprietary.
All Northbound (Management/OAM) Interfaces shall be open and well documented.
The Vendor shall provide documentation about Northbound Interfaces 3 months before the official
release date of a new software or hardware release. The regulations as laid out in the chapter
Documentation of this RFQ Document shall apply.
The Vendors SON Solution shall support only IP based South-Bound-Interfaces.
The Vendors SON Solution shall support n-2 backward compatibility for all North-Bound Interfaces
without any additional cost.
The Vendors SON Solution shall support the compatibility for all North-Bound Interfaces without any
additional cost, as long as no additional NE features are ordered. (NE meaning a network component
that is part of the SON solution).
For each CORBA interface delivered as part of the solution and declared an open interface for third
party solutions, the Vendor shall support Telefnica and its operational partners in achieving a working
and interoperable solution across the Vendors CORBA interface. In difficult cases, this may require
interoperability testing.
Telefnicas and its operational partners have different Integrated Network Management System (INMS)
for Fault-Management. In General, Operation agents will be installed on managed systems, in this case
the SON Platform Components. The agent monitors file system, CPU occupancy, processes, log files
and interfaces. In addition the agent shall intercept SNMP traps provided by the applications running on
the NMS.
The Vendor shall use the Telefnica IP based DCN for all communication toward the Network
Elements, NMS, SON and Client access.
NOTE: Purchaser (Telefnica) uses an IP based DCN (Data Communication Network) to provide the
Connection to the Network Elements as well as to access the SON Solutions IP connected
elements/components being subject of this RFQ.
All communication between the NMS, SON, the Network Elements and Client Access shall be based on
the Internet Protocol (IP RFC 791).
The SON provided by the Vendor shall connect to the Telefnica DCN using Ethernet Interfaces.
All SON LAN Interfaces shall support 100BaseT and 1000BaseT.

The Vendors SON Solution shall support the change of any Network Addresses, IP or other, used by
the SON System itself. The SON product shall provide means to change the address on all SON
Servers in one configuration step.
The Vendor shall provide all relevant information about existing implementation, inter-working solutions,
and experiences of the Vendors equipment with INMSs (Integrated Network Management Systems) for
Fault-Management, e.g. IBM Netcool, etc.
NOTE: In general, operation agents will be installed on managed systems, in this case the SON
Platform components. The agent monitors file systems, CPU occupancy, processes, log files and
interfaces. In addition the agent shall intercept SNMP traps provided by the applications running on the
NMS.
The server components of the Vendors SON shall consist of standard server hardware running
standard operating systems in such a way that agents can be installed on them.
The Vendor shall accept and support the installation of agents and other required 3rd party software
needed for alarm integration purposes (e.g. SSH packages) by the Purchaser (Telefnica) on any
server of the Vendors SON Solution (depending on The Vendors system architecture). The required
licenses will be provided by the Purchaser (Telefnica).
The evolution of the INMS (and other) third party software is following its own roadmap and cannot
always be synchronized with the evolution of The Vendors system as it is deployed at Telefnica. Also
experience over time shows, that the quality of the third party Software releases is sometimes below
expectation, making an unplanned upgrade mandatory in order to retain the overall system function,
stability and maintainability. The Vendor shall accept upgrade of the agent
software by Telefnica. Following the normal procedure, Telefnica will test
changes to the agent (and other third party) software (first) in the Testlab and (second) in the live
network before making any permanent changes to the system.
In order to help the Vendor understand the main operational states, that an agent can have, the concept
is described in a high level way:
The agent is installed, but not running.
The agent is running, but without configuration (instrumentation). The impact to the host system is
negligible.
The agent is running with a configuration. The configuration and hence the functions performed by the
agent are defined through: templates, plugins, etc.. Depending on the type of configuration the impact
can be substantial.
The servers on which agents shall be installed shall get operating patch level as required by agents.
The Vendors SON Solution shall have no single-point-of-failure.
The Vendors SON shall support redundant Interfaces.

The Vendors shall provide detailed information about how to connect to the NMS and Network
elements, i.e. access details, NMS scripts used, read, write commands, etc..
Vendors SON system shall provide a northbound SNMP alarm forwarding interface.
The Vendor shall state which SNMP Version (e.g. SNMPv1, SNMPv2, SNMPv2c, SNMPv2u or
SNMPv3) is supported by the provided North-bound (management) interface.
The Vendors shall state the relevant IETF RFCs that apply to the provided North-bound (management)
interface. If this information is provided in a separate document, please state a reference here.
Vendors SON system shall generate appropriate SNMP alarms and traps and send them to the
Operators Integrated Network Management System (INMS).
The Management (North-bound)-interface of each of the vendors SON components (seen as IP nodes
in the operators environment) shall provide suitable procedures to ensure the retransmission of SNMP
Traps that could not be send.
The Management (North-bound)-interface shall provide suitable procedures to ensure the
retransmission of SNMP Traps that were lost during DCN transfer.
Alarms shall be propagated via the SNMP Management (North-bound) Interface with a delay less than
5s.
The SON Platforms SNMP Management (North-Bound)-Interface shall support the option to send
SNMP Traps to at least three different destinations simultaneously.
The Vendors SON shall provide the functionality to configure the destinations for the SNMP Traps in
means of IP Address and IP Ports.
The Vendor shall provide detailed specification of the provided SNMP Interface.
The Vendor shall give detailed information about the planned developments (enhancements, changes)
regarding the SNMP interface.
The following information shall be mapped from an Alarm object to the corresponding SNMP Trap.
Unambiguous Notification Id
Alarm Id
Affected object
Alarm text
Additional information supporting
Perceived severity
Timestamp
Any information that is mapped from an Alarm to an SNMP trap shall be represented in a separate
SNMP Trap variable.
On clearance of an Alarm propagated through the SNMP Management (North Bound) Interface a trap
shall be send through the SNMP North Bound Interface containing an unambiguous reference to the
Alarm and trap as well as the severity cleared.
The Vendor shall provide a full alarm list with detailed and precise description of the single trap fields of
the dedicated SNMP traps as part of the Documentation.
The Vendor shall provide complete MIB(s) syntax in electronic format for each component that is
viewed by Network Management as a Network Element.
The Vendors Solution shall support the activation and deactivation of SNMP traps.
The Vendors SON Solution shall provide a GUI to configure all aspects of the SNMP management
(northbound) Interface.
The Vendors SNMP module shall allow changing alarm properties (e.g. the severity of specific traps)
from installed defaults.
Vendor is obliged to work together with Telefnica Germany and its backup software specialists
(eventually Telefnica contractors) in order to plan, implement, test and deliver the HP Data Protector
solution.
The Vendor shall provide all details in an early project phase, to ensure, that backup implementation
can be managed just in time with product introduction. Documentation shall be reviewed and accepted
by Telefnica Germany.
The Vendor shall provide graphical and/or textual documentation that describes the structure and
composition of the system to be integrated into Telefnica Germanys backup system.
Vendors documentation shall give a clear understanding of:

Installed physical disk devices (hardware) and their capacity (including future trends)
Mapping of physical disk devices into the operating system (device level view)
File system and/or data base use of devices including mirror disk and LVM software, etc.
Application level utilisation of available file system / data base capacity, dependencies, future growth
Requested information may be provided in tabular format for each Backup Client and shall include at a
minimum:
Volume of Data
Distribution of Data across Media and file systems
Type / Function / Category / Volatility of data (i.e. database; operating system, ...)
It has to be determined, if an extension of functionality has to be implemented for online backup of
databases.
databases. Integration is installed in order to facilitate online backup of various types of data base
systems. If the Database is not supported by HP Data Protector, then the Vendor must deliver a solution
for online backup that supports backup to file system. This file system must be backed up with DP after
the online part is done from the Vendors solution.
The Vendor is obliged to provide the data path including hardware and software modules needed to
realise the data path.
The Vendor is obliged to ensure, that the additional system load (drivers, hardware, etc.) can be
handled by Vendors system and does not violate intended system application, warranty, or similar.
The network connectivity shall be described in all detail including (but not limited to): network
architecture
LAN cards
IO Bus (expansion slot) usage
Disk capacity (current, future trend)
etc.
In order to ensure a small backup window, to avoid congestion of production networks and to ensure
saturation of backup tape devices a dedicated backup data path (Backup-LAN) shall be provided
(implemented) for each BC. The following choices exist:
1 Gbit/s Ethernet connection
The management of the backup system is done via Ethernet (min. 1 Gbit/s).
The overall backup solution is subject to Telefnica Germanys acceptance procedure.
Telefnica Germanys automated and centralised backup solution is based on the HP Storage Data
Protector system. The version actually in use by Telefnica Germany is A.6.21.
The server components of the Vendors SON system shall comprise of standard server hardware
running standard operating systems in such a way that HP Storage Data Protector components can be
installed on them.
The Vendor shall be obliged to allow installation of HP Storage Data Protector client components (Disk
Agent and Media Agent) and if needed for backup purposes other 3rd party software (e.g. Data Base
Online Integration) by Telefnica Germany on any server of Vendors system (depending on Vendors
system architecture). Installation of the client components must be done with super user rights. The
needed licenses will be provided by Telefnica Germany.
The servers on which HP Storage Data Protector clients shall be installed shall get operating patch level
as required by HP Storage Data Protector clients. For details see HP Homepage.
The Vendor shall provide a Disaster-Recovery-Procedure (DRP).
The Vendors Disaster /Recovery procedure shall:

Ensure complete System Recovery.
Allow to remotely create and restore OS-Images (per Server) of all Systems of the deployed solution.
Ensure that the HP-Dataprotector Agent is included in the Image.
The DRP shall ensure recovery after partial and complete failure of any mass storage (including core
system disks) of the Vendors solution.
The Vendors SON Solution shall include all Hardware, Software and Licences to ensure the Disaster-
Recovery-Procedure (DRP) can be executed.
Including, but not limited to:
in the case of multiple systems (>=2): an Image/Install-Server shall be used
in the case of a single system (=1): Image-DVD, Image-USB-Stick or an Image/Install-Server shall be
used
The Vendor shall provide a step-by-step detailed description and usage

instruction of the DRP as part of the Documentation.
The description shall cover every aspect of the DRP, including but not limit to:
How to create remotely a Backup (Image per Server) of each delivered System.
Where the Image-Backup is stored (DVD; USB-Stick or Image/Install-Server)?
How to recover remote every delivered system after a complete loss of OS (Harddisk failure)
How to enable/synchronise remotely Node/Cluster/Rac/DataGuard after a DR, if used on the system
The Vendors documentation shall give a clear understanding of:

The vendor shall provide a documentation that explains how to achieve DRP, and shall provide the
required resources to achieve this.
The DRP procedure is required to support the HP Storage Data Protector solution in the following way,
whereby the Vendor shall deliver a solution up to Second step (3rd bullet):
Loss of system disk (i.e. system cannot be booted automatically; HP Storage Data Protector backup
and (tested) disaster recovery procedure exist);
First step: repair all hardware faults, install new disk(s);
Second step : enter disaster recovery procedure, i.e. boot the system into a state in which the HP
Storage Data Protector client software can operate and interact with the HP Storage Data Protector
server;
Third step: restore all required parts of the system from the latest backup available on the HP Data
Protector server.
Vendor is obliged to work together with Telefnica Germany and its backup software specialists
(eventually Telefnica contractors) in order to plan, implement, test and deliver the HP Data Protector
solution.
The Vendor shall provide all details in an early project phase, to ensure, that backup implementation
can be managed just in time with product introduction. Documentation shall be reviewed and accepted
by Telefnica Germany.
The Vendor shall provide graphical and/or textual documentation, which describes the structure and
composition of the system to be integrated into Telefnica Germanys backup system.
Vendors documentation shall give a clear understanding of:
Installed physical disk devices (hardware) and their capacity (including future trends)
Mapping of physical disk devices into the operating system (device level view)
File system and/or data base use of devices including mirror disk and LVM software, etc.
Application level utilisation of available file system / data base capacity, dependencies, future growth
The requested information may be provided in tabular format for each Backup Client (BC) and shall
include at a minimum:
Volume of Data
Distribution of Data across Media and file systems
Type / Function / Category / Volatility of data (i.e. database; operating system, ...)
databases.
If the system utilises a data base, the Vendor shall allow that a Data Base Online Integration is installed
in order to facilitate online backup of various types of data base systems. If the Database is not
supported by HP Data Protector, then the Vendor must deliver a solution for online backup that
supports backup to file system. This file system must be backed up with DP after the online part is done
from the Vendors solution.
The Vendor is obliged to provide the data path including hardware and software modules needed to
realise the data path.
The Vendor is obliged to ensure, that the additional system load (drivers, hardware, etc.) can be
handled by Vendors system and does not violate intended system application, warranty, or similar.
The network connectivity shall be described in all detail including (but not limited to) network
architecture:
LAN cards
IO Bus (expansion slot) usage
Disk capacity (current, future trend)
etc.
In order to ensure a small backup window, to avoid congestion of production networks and to ensure
saturation of backup tape devices a dedicated backup data path (Backup-LAN) shall be provided
(implemented) for each BC. The following choices exist:
1 Gbit/s Ethernet connection;
For environments with greater datasets (more than 1TB) is a higher network bandwidth required 4 x
1 Gbit/s Bond or 10 Gbits/s Ethernet connection
For blade center a higher network bandwidth (10 Gbits/s Ethernet connection) is required, if the
backup destination is outside of the blade center.
The management of the backup system is done via Ethernet (min. 100Mbit/s).
The overall backup solution is subject to Telefnica Germanys acceptance procedure.

Telefnica Germanys automated and centralised backup solution is based on the HP Storage Data
Protector system. The version actually in use by Telefnica Germany is A.6.21.
The Vendor shall be obliged to allow installation of HP Storage Data Protector client components (Disk
Agent and Media Agent) and if needed for backup purposes other 3rd party software (e.g. Data Base
Online Integration) by Telefnica Germany on any server of Vendors system (depending on Vendors
system architecture). Installation of the client components must be done with super user rights. The
needed licenses will be provided by Telefnica Germany.
Telefnica Germanys automated and centralised backup solution for virtualized environments
(Microsoft HyperV, VMware vSphere) is based on Veeam Backup &Recovery. The version actually in
use is 6.5.
For the backup with Veeam, Veeam does provide appropriate resources in a given environment, but the
SON vendor shall be responsible for providing an additional server with sufficient Storage capacity,
SAN connections and Network connections.
For Online Application like MS SQL Database, Oracle Database on virtual hosts the Integration of HP
Data Protector Online Integration is used. Maybe the SON application
Vendor can provide a verified backup solution with Veeam Backup & Replication, and the Vendor shall
successfully demonstrate and test the Backup/Restore Procedure according the delivered Step-by-Step
Documentation.
The Vendor shall provide a Disaster-Recovery-Procedure (DRP).
The Vendors Disaster /Recovery procedure shall:

Ensure complete System Recovery.
Allow to remote create and restore OS-Images (per Server) of all Systems of the deployed solution.
Ensure that the HP-Data protector Agent is included in the Image.
The DRP shall ensure recovery after partial and complete failure of any mass storage (including core
system disks) of the Vendors solution.
The Vendors SON Solution shall include all Hardware, Software and Licences to ensure the Disaster-
Recovery-Procedure (DRP) can be executed.
Including, but not limited to:
in the case of multiple systems (>=2): an Image/Install-Server shall be used
in the case of a single system (=1): Image-DVD, Image-USB-Stick or an Image/Install-Server shall be
used
The Vendor shall provide a step-by-step detailed description and usage

instruction of the DRP as part of the Documentation.
The description shall cover every aspect of the DRP, including but not limit to:
How to create remotely a Backup (Image per Server) of each delivered System.
Where the Image-Backup is stored (DVD; USB-Stick or Image/Install-Server)?
How to recover remote every delivered system after a complete loss of OS (Harddisk failure)
How to enable/synchronise remotely Node/Cluster/Rac/DataGuard after a DR, if used on the system.
The vendor shall provide a documentation that explains how to achieve DRP, and shall provide the
required resources to achieve this.
The previous two procedures are required to support the HP Storage Data Protector solution in the
following way, whereby the Vendor shall deliver a solution up to Second step (3rd bullet):
Loss of system disk (i.e. system cannot be booted automatically; HP Storage Data Protector backup
and (tested) disaster recovery procedure exist)
First step: repair all hardware faults, install new disk(s)
Second step : enter disaster recovery procedure, i.e. boot the system into a state in which the HP
Storage Data Protector client software can operate and interact with the HP Storage Data Protector
server
Third step: restore all required parts of the system from the latest backup available on the HP Data
Protector server
The Vendor shall successfully demonstrate and test the Disaster/Recovery Procedure according the
delivered Step-by-Step Documentation.
DRP is subject to Telefnica Germanys acceptance procedure.
The solutions user interface shall be accessible from any computer, on a web-based support from
standard web browsers.
SON system shall support single user interface to manage multiple RAN vendor SON features from the
same platform.
The solution shall feature a map display supporting web-based mapping data.
The solution shall support the definition of regions subject to changes.
The solution shall support the definition of blacklisted cells.
The solution shall support the definition of whitelisted cells.
The solution shall display a log of all changes at the RNC level.
The solution shall display a log of all changes at the area level.
The solution shall display a log of all changes at the sector level.
The solution shall display a KPIs view.
The solution shall display any changes within the KPIs view.
The solution shall provide the user with the ability to perform KPIs trending on any of the available KPIs
and visually display performance information.
The solution shall provide the user with the ability to perform aggregated KPIs trending on any of the
available KPIs and visually display performance information.
The solution shall support the definitions of various user types.
The solution shall support different permissions and access for each user type.
The solution shall assign logins for individual users.
The solution shall support a web based Graphical User Interface (GUI) to monitor and operate.
The solution shall support definition of optimisation areas/regions.
The solution shall provide geographic display of optimization process and result based on Google map,
Open Street map.
The UI shall be running on common browsers (e.g. Chrome, IE, Firefox).
The solution shall support to export optimization report, the report shall include:
Basic information (Configuration parameter, mission status, etc.)
Optimization suggestion ( including executing suggestion and executed suggestions)
Mission detail historic processing record
Mission exception record
The SON system shall report all configuration activities to a third party system. The report / interface
shall provide information about each single configuration activity. It is not sufficient to provide only a
statistic report. The vendor shall provide detailed information about the content and the technical
implementation of the report / interface.
It shall be possible to interwork Centralized SON (C-SON) with Distributed SON (D-SON):
(1) Vendor can provide information on the Parameters of D-SON functions that are configurable by
Centralized SON or can be controlled using policies.
(2) And vendor can answer the question of whether a Centralized SON Solution from a non-RAN
vendor shall configure (or policy) the D-SON functions.
It shall be possible to de-activate D-SON or any SON functions in eNBs in order for the operator to rely
on Centralized SON (C-SON) functions from a centralized SON solution vendor.
SON vendor can demonstrate the extent to which they can address interoperability issues and the
recommended remedies in NGMN Alliances Recommended Practices for Multi-vendor SON
Deployment Deliverable D2, while taking into account the implementation options for SON and vendor
architecture combination options for which interoperability issues can be addressed. C-SON for LTE
features should work with the D-SON features enabled.
In general, vendor shall indicate the SON related 3GPP standards the vendor conforms to.
Vendor C-SON Solution shall "prohibit X2 HO related behavior for some policy cases the operator may
choose to enforce", as this is sometimes done by the operator using centralized automation tools for
controlling NR behavior.
Vendor shall indicate how the C-SON solution handles an interoperability aspect involving D-SON on a
small-cell that should interwork with a macro-cell, whereby the macro-cell vendor may not have
supported SON related X2 signalling and/or IEs.
If the vendor were to provide a SON solution, the solution provides an interface through which SON
functions can be activated or deactivated and be configured using SON policies and profiles in the
cases where it is possible. The SON Policy Definition Interface Specification document, with the
parameters that can be used in policy definition by the operator (on the fly) should be provided by the
vendor.
The SON solution should also provide a means for SON policies creation or generation and the means
for conflict detection and resolution on SON policies. The SON solution shall be able to communicate
back to the user if some policies cannot be implemented (enforced) and should include the reasons
why.
The Vendor shall provide a Network Architecture/Planning guideline document where DCN connectivity
and DCN Network requirements including traffic matrix and scaling aspects are explained in detail
(related RQ363-RQ365).
All elements of the Vendors SON-hosting system shall support 1GE Ethernet over copper (RJ45
connector) for the connection to the network.
a) Fibre interface to the network is optional
b) 10GE interfaces are also optional
The SON-hosting system must support the IP network protocol. No other network layer protocols will be
supported.
a) All protocol connections must use IPv4.
b) The System shall use only private IPv4 addresses (according to IANA) for the network
communication.
c) IP configuration (address and mask, routing) must be changeable and not hard-coded into the
system.
The SON-hosting system (and it IP connected elements/components) interfaces must support MTU
discovery. Explain the function including which RFC is supported.
For connection to remote NEs or devices in a less secure Zone, all standard IP protocols which use
well-known TCP or UDP ports must be encrypted. For example we shall use SSH and SCP/SFTP
instead of Telnet/FTP.
The SON system must be able to be distributed geographically over two or more sites for resiliency
reasons.
a) Explain this mechanism in detail (active/standby, load balanced, etc).
b) The combined bandwidth requirements of the network interconnection must be defined including the
calculation used.
Local systems must interface to the network in a redundant fashion.
a) Explain this mechanism in detail (cluster, L2 switch access/trunk, L3 routed port, Etherchannel,
active/standby or load balanced, miimon, arpmon, etc.).
b) Explain the L3 routing function between end system and the network.
Define the system traffic matrix.

a) Specifically who talks to whom (physical elements server, N.E.), with which protocols, requiring
how much bandwidth (in table form).
The system must be scalable. Explain which protocol relations based on the defined traffic matrix
which grows with subscriber growth.
Remote maintenance and support of system must be served by a personalized VPN connection
(Telefnica internal system) from a jump server in the Telefnica Service Zone. No direct connection
from outside is possible.
While NGMN Alliances Recommended Practices for Multi-vendor SON Deployment Deliverable D2
defines a number of performance metrics that apply to each SON function, the vendor shall
demonstrate with figures all the Self-Configuration and Self-Optimization related performance metrics
(including any other types of performance metrics of relevance the vendor may have).
NOTE: The metrics convey the value SON brings in OPEX reduction, in enabling the operator to
improve their business operations and ability to innovate services based on the automation and error-
reduction in configurations that SON brings.
It shall be possible to install and operate the Vendors SON solution on a virtualized data center
infrastructure.
The Purchaser (Telefnica) may choose to integrate the Vendors SON solution into his existing
virtualized datacenter infrastructure. If the Purchaser (Telefnica) chooses to integrate the SON
Solution to his virtualized datacenter infrastructure, the Vendor shall support the integration.
The vendor shall support VM-Ware for the virtualization of his SON solution.
The Vendor shall fulfill the same functionalities for the virtualized SON solution as for his alternative
standalone (dedicated-hardware based) SON solution, according to the requirements in this Annex.
In case of virtualization ofthe Vendors SON solution, the virtualized SON solution shall have the same
maintenance service level as the Vendors alternative standalone (dedicated-hardware based) SON
solution.
The Vendor shall provide all necessary information, (e.g. CPU load, SW versions, database version )
which is needed to virtualize the Vendors SON solution on the Purchaser (Telefnica) environment.
The Vendor shall state, if the vendor has already installed virtualized SON solutions in other network
providers.
If the Vendors SON Solution does not yet support virtualization, the vendor shall clearly state the
availability of this functionality on his roadmap.
The Vendors SON shall comprise of standard IT Servers. The Purchaser (Telefnica) shall have the
possibility to choose the 3rd party Hardware for the SON System solution.
The Vendor shall provide all information necessary for the Integration in to the Telefnica Germanys
NMS. This includes the complete specification and description of the Interface(s) on all network and
protocol layers. The Information shall be provided in a well-structured and comprehensive way.
The Vendor shall provide information about all implemented Interfaces of the Network Elements (i.e.
network components of the SON solution). The NEs shall not have undocumented Interfaces.
The Vendor shall provide full specifications of all external interfaces for any 3rd party components
supplied as part of the Vendors solution.
Full operational maintenance procedure documentation should be available to allow the Purchaser
(Telefnica Germany) to rectify any problems with the Vendor's equipment.
Full technical documentation shall be provided. Technical documentation will cover all aspects of the
design, implementation and integration of the delivered solution.
Full User documentation shall be provided. User documentation will cover all aspects of the supplied
solution.
Full support documentation shall be provided. Support documentation will cover all aspects of the
support and maintenance of the delivered solution.
All documentation shall be provided in electronic format.
All documentation shall be managed via change control.
Each new edition of a Document shall contain a section describing the changes against the last
provided document edition.
All documentation shall be reproducible by the Purchaser (Telefnica) for internal use by both its own
employees and assigned agents.
All documentation shall be supplied in English.
The Vendor shall provide a complete description of the functions and features supported by its solution
including those which are not explicitly called for in this Annex. These shall be clearly identified and the
Vendor shall detail their relevance and benefits to the Purchaser (Telefnica).
The Vendor shall provide support for the distribution of all on-line support documentation.
All electronic documentation shall support web publication.
All documentation shall be provided 3 months in advance of any software or hardware delivery or
Upgrade or Update.
The Vendor's documentation shall clearly state which configuration parameters fall into the following
categories for his Network Elements:
Parameters that can be changed 'on the fly'
Parameters that require the locking of an object prior to change
Parameters which will lead to service disruption or performance reduction.
The Vendor shall provide detailed documentation about the SON Systems Hard- and Software
resilience.
The Vendor shall document in detail how redundancy is provided in the management of the SON
solution and the procedures to be followed in the event of a SON system failure.
Communication protocols utilized between client and server components of the Vendor's solution shall
be fully documented and disclosed.
The vendor shall provide to TGE detailed technical hardware and software documentation and
specifications, which fully describes all delivered equipment covered by the contract. All
features/functionality that are/is optional shall be clearly stated. Where the required technical
information is contained in another document, a reference to the relevant section of this document shall
be given and the document provided to TGE.
The vendor shall provide documentation for Operation & Support, in electronic format to TGE
operations personnel. The documentation shall include:
User, advanced user and administration manuals and guidelines: every configurable parameter of the
application shall be described in detail.
Backup and Recovery instructions for all the system components (probes and servers)
Detailed documentation about the systems IP infrastructure layout
The vendor shall provide a detailed dictionary for all network nodes configuration parameters. This shall
include at least the following:
Complete Functional Description of the parameter/features
Engineering Rules for the parameter
Parameter Range [from to] / where applicable
feature name and number,
commercially standard or optional,
hardware, software and firmware dependencies,
available in which network element
all core network requirements and dependencies
all O&M requirements and dependencies
The documentation shall be revised and reissued following every change made to the platform.
The vendor shall provide documentation for new releases which always shall include a fully specified
delta documentation that specifies all changes between the current and the new release. This
documentation shall be made available latest 6 months prior to first delivery of the new release to TGE.
The vendor shall provide access to complete draft or preliminary customer documentation prior to first
release specifically relating to feature roadmaps, high level designs and product specifications.
The vendor shall provide a complete set of feature notes (detailed description of how the feature works,
including all associated O&M interactions / counters / statistics / configuration information) for each
feature contained in the vendors Feature Planning Guide (list of all features in the release).
The features notes shall also be provide in draft/preliminary versions. The feature notes shall be
provided not later than the release when the feature content is first fixed.
The vendor shall provide a complete and detailed upgrade strategy (MOP - method of procedure)
including a detailed timeline of each upgrade step.
The vendor shall identify each individual feature by a code that is unique to the feature and its version.
The vendor shall provide detailed specifications of all the external O&M interfaces available on the
platform.
The vendor shall deliver for each bug fix a detailed description and documentation.
All user relevant documentation (e.g. guidelines, designs, system description) is stored and accessible
from the system. The vendor shall describe what documentation is available and accessible for the
users.
The solution shall provide a generic housekeeping process as follows:
The housekeeping process shall be able to archive or delete aged data
The retention period for the data shall be configurable.
The housekeeping process shall deal with all types of data files the system generates and stores
data files
log files
database tables
All applications and processes shall write log information.
The log information shall be formatted in the same structure for all applications and processes.
The log information shall be human readable.

The log structure shall be designed so that an automatic analysis is possible. Logs which can be
interpreted only by humans are not allowed.
Whenever technically possible the log information shall be stored centrally even if the solution is
distributed over several servers.
The log information shall be categorized in the levels:
Error
Warning
Information
Debug
It shall be possible to configure which log level categories are reported in the logs.
The log housekeeping shall be part of the general housekeeping
In case of system upgrades (HW, OS) the existing on-site configuration shall be archived and
automatically migrated /updated to the new software level by the vendors upgrade procedure.
The vendor`s SON solution shall be protected according to the security guidelines and policies of the
purchaser (Telefnica).
The vendor`s SON solution shall be protected against any unauthorized access.
The vendor shall provide means of protection against malicious code for SON Platform.
The vendor shall describe how the SON solution is protected against malicious code.
None of the Servers in the vendors SON solution shall accept remote logins for privileged accounts
(e.g. root or administrator).
The vendors SON shall be hardened using tools comparable to the CIS hardening suite see
www.cisecurity.org. A score of 75% or more shall be achieved in each section.
The SON vendor shall support/ fulfil the requirements described in the generic Security Annex included
along with the RFQ as a separate document [2].
No regular system or application access shall involve the use of shared accounts. No applications shall
use system, root, or otherwise privileged accounts.
The vendor shall provide a document description for the current security mechanism (of the offered
system).
Different levels of user accounts are required with different abilities to read or amend configuration
parameters and data. In all cases there should be a super user which enables the current status
protections to be over-ridden in emergencies or support for over-riding business reasons.
Login shall be secured by password, to provide access rights for multiple users and to support multiple
levels of user access rights for access to the application(s).
The vendor shall specify the user concept. (User Access Level, Users groups, how many users, facility,
security level) per node and central system does solution have.
The system, including but not limited to operating system and application(s), shall check each users
access privileges at login, and automatically disable or enable client functions (in real time) based upon
the users profile. This shall be configurable and available at the lowest level of the operating system
and application.
The system shall have component-level security, to be able to define security roles, assign users to
those roles and grant component-level security privileges to specific roles.
The system shall easily accommodate a mechanism to grant/revoke security privileges to the regulated
community who uses this system.
Each of the user group shall have a list of sub users. Each of the user shall have own login and
Password.
For every communication across system components and end clients it shall possible to adopt also an
encrypted communication protocol. (e.g. SSH, SFTP, HTTPS, etc.).
The vendor should provide the system network installation in a high security network LAN/WAN
environment (Protocols, Win-Domain, Antivirus, Patch, and Backup).
The Vendor shall co-operate in all security related testing and shall supply all information that may be
required by the Security team to complete testing.
The vendor shall confirm that the vendor is enforcing platform hardening, by implementing security
configuration benchmarks. Embedded required
CIS Benchmarks that are the only consensus-based, best-practice security configuration guides both
developed and accepted by government, business, industry, and academia. For this the vendor shall
consider the following references [3][4][5].
The vendor shall provide a detailed description of any Hardware and Software needed to implement the
solution including a system diagram.
The vendor shall provide the HW dimensioning for the C-SON solution related to TEF network size and
OSS layer (number of NEs & NMS systems in TEF network).
User names and passwords shall be stored encrypted.
All access shall be password protected.
Each user account should be characterized by a user ID, a password, and a user profile.
Access to SON functionality should be controlled by user profiles.
Different levels of user accounts are required with different abilities to use SON in open or closed loop
with different modules. In all cases there should be a super user which enables the current status
protections to be overridden in emergencies or support for business reasons.
It shall be possible to assign read-only access to a user or group profile for any combination of
application or system resource. Specific users
may have restricted access or a requirement to access only parts of the overall system and network
elements, which can be affected by SON.
Access restriction for users shall be possible on several levels:
Technology (e.g.2G, 3G, 4G)
Vendor of Technology
Region or network area
SON Module
It shall be possible to limit the number of parameter changes done by SON per user profile.
A system administrator shall be able to invoke and configure password ageing on a per user or account
basis.
A System administrator shall be able to modify a user or group profile to meet specific business or
operational needs. This shall include the ability to assign administrative and management capabilities
that exclude the ability to manage user accounts.
All unauthorized attempts to access the solution should be logged.
An audit trail of any security relevant activity (e.g. changing SON configuration for ANR) initiated by any
user should be logged and maintained on-line for rolling period of one month. It must be possible to
store these audit trails off line for an indefinite time period.
To keep an audit log of any changes to significant data inside the SON application.
The solution shall also provide functionality to use external LDAP platforms or Active Directory systems
for the user authentication procedure (e.g. to support single sign on).
The solution must have the possibility to deactivate and delete user accounts by a configurable period
of inactivity.
The Vendors SON shall comprise of standard IT Servers.
Please give a brief description of the SON Systems Hardware Architecture. Please consider that the
aim of this description is to give Purchaser (Telefnica) an overview, therefore the description shall not
exceed one page! If the description is provided in a separate file please state a reference here.
The Vendor shall provide a Hardware Upgrade Procedure for each SON Hardware Upgrade.
The Hardware Upgrade Procedure provided by the Vendor shall prevent any SON Outage Times during
Hardware Upgrade.
The Hardware Upgrade Procedure provided by the Vendor shall prevent the loss of any SON related
Data. This includes, but is not limited to, Fault Management Data, Hardware Management Data and
Inventory Management Data.
The Hardware Upgrade or Hardware Update Procedure shall not require additional Software Licences
for temporary Systems used during the Upgrade.
The Vendor shall provide a SON Recovery Procedure, describing the actions to be taken to recover
each Server of the SON after breakdown.
The Vendor shall state the Time the Recovery Procedure will take from start of the Procedure to full
availability of the SON Service.
The Vendor shall state the version and revision level of all software components of the SON solution,
including third Vendor software components.
The Vendor shall state all limits that originated in Software licenses, including also third Vendor
software licenses.
If the Vendor uses SW / Feature Licenses based on network growth, these licenses shall be only
adapted one year.
The Vendors SON solution shall include automatic clean-up procedures to prevent the NMS servers
from resource leaks.
The Vendors SON solutions clean-up procedures shall be configurable using the Systems GUI.
The Vendor shall supply tools and applications to support the administration and maintenance tasks on
the delivered SON.
The duration of downtime during software upgrade shall be kept to a minimum and during such a period
the Vendor shall propose temporary SON measures as appropriate.
Unavailability of the SON shall not affect the functionality of the Network Elements.
SON functions and actions shall in no way degrade the performance of the network elements.
The SON shall provide functionality to ensure that the operator is warned before actions that, in fact or
potentially, affect the performance or functionality of Network Elements are executed.
The Vendors SON shall provide a GUI supporting all OAM Tasks.
The Vendor shall ensure that all processes necessary for the SON functionality are automatically
started after Server reboot without manual activation.
The Vendor shall provide a Software Upgrade or Update Procedure for each SON Software Upgrade or
Update.
The Software Upgrade or Update Procedure provided by the Vendor shall prevent any SON Outage
Times during Software Upgrade or Software Update.
The Software Upgrade or Software Update Procedure provided by the Vendor shall prevent the loss of
any SON related Data. This includes, but is not limited to, Fault Management Data, Software
Management Data, etc..
The Software Upgrade or Software Update Procedure shall not require additional SON Hardware for
temporary Systems used during the Upgrade or Update.
The Software Upgrade or Software Update Procedure shall not require additional Software Licences for
temporary Systems used during the Upgrade or Update.
The Vendors SON Solution and its Interfaces shall comply to all appropriate SON-related as well as
Management-related 3GPP, IETF, ITU-T and ETSI standards like:
ITU-T, 1996, "M.3010 Principles for a telecommunications management network"
ITU-T, 1997, "M.3400 TMN management functions"
ITU-T, "M.3050 Enhanced Telecom Operations Map (eTOM) The business process framework"
ITU-T, X.700 : Management framework for Open Systems Interconnection (OSI) for CCITT
applications
The security architecture for systems providing end-to-end communications is provided in
Recommendation X.805. A comprehensive set of detailed security frameworks covering aspects of
security such as authentication, access control, non-repudiation, confidentiality, integrity, and security
audit and alarms has been established (X.810, X.811, X.812, X.813, X.814, X.815 and X.816)
But not limited to the above standards.
Each item in the Vendors feature guide and future roadmap shall be mapped to the appropriate
standard and version of that standard.
All interface stacks shall be implemented according to the stated standards and any other relevant
standards. Release details related to standards versions and implementation will be fully documented
by the Vendor.
The Vendors SON Architecture shall provide the option to implement multiple SON instances to provide
Geo-Redundancy.
Please state the maximum number of SON instances that might be integrated to a Geo-Redundancy
Solution.
Please state the maximum physical distance between the SON instances of the Geo-Redundancy
Solution.
In case of failure of one SON instance within a SON Geo-redundancy Solution the other SON
instance(s) within the SON Geo-Redundancy Solution shall provide the SON functionality managed by
the failed instance.
In case SON Functionality is taken over from a failed SON instance the SON functionality connected to
the active SON instance shall not be impaired.
Recovery from component or site failure shall not impact system availability.
Using the Matrix Tables provided in the Excel file/Tab C-SON SW Roadmaps, Vendor shall provide
information about SON Software Features, with a clear distinction of the Standardized SON Use Cases
(as part of the software features), using terminology from the relevant standards from 3GPP/NGMN,
and also those SON Use Cases that are proprietary to the vendor, and along with that the vendor shall
describe the following details for each feature (e.g. ANR, MRO, MLB, other features):
The Data Sources needed by the algorithms associated with the feature, with indications of the
mandatory data sources as well as the optional data sources that provide added value to SON
algorithms, as requested in the Tables
Any estimations of bandwidth requirements imposed on the underlying network and the data sources
by the individual SON features shall be indicated by the vendor (the features/SON Use Case that are
standardized are indicated with terminology from the standards while distinguishing them with
proprietary ones).
Roadmap for the availability of the feature as requested in the Tables
SON Performance metrics (using data or figures)associated with the feature, or a pointer to a
supplementary document that contains performance metrics for the feature.
Vendor shall complete all tables on this sheet. The roadmaps to be included are up to the end of 2015.
NOTE/Remark: The same requirement is found in the Tab C-SON SW Roadmaps of the Excel File
with all the Requirements. Vendor shall also complete the compliance checks in that Tab.
The C-SON vendor shall only provide supported dates for when a feature will be commercially available
i.e. it will have been developed, tested with a specific RAN vendor and can be commercially deployed
with that vendor in a live network.
For the "Date Supported" field the Vendor shall use one of the following options:
1. The Vendor shall state the quarter and the year the feature will be supported e.g. 2Q 2015 for each of
Telefnicas RAN Vendors shown.
2. The Vendor shall state No Plan if a particular Vendor is not planned to be supported for a particular
feature.
3. The Vendor shall state Already Supported if a feature is already supported for a particular RAN
vendor.
Only features supporting Closed-Loop shall be listed. Closed-Loop means no manual intervention is
needed to execute commands on the OSS or to collect data.
The vendor shall state all data sources required per vendor e.g. OSS PM/FM/CM data, Layer 3 data
(GPEH, MegaMon, CHR data, Measurement Reports, Analyser, Call trace, Probe data etc.).
Input data sources are split into Mandatory Data Sources and Optional Data Sources. Mandatory Data
Sources are the essential data sources that are needed for the feature to work. Optional data sources
are not essential for the feature to work, but if the data source is available it could be used to improve
the performance of the feature. For Example CM, PM and FM data sources may be Mandatory for a
specific feature and Layer 3 Data may be an optional data source that could be used to improve the
performance for the feature.
Border cell support (i.e. ability to support operation ACROSS vendor A and B as shown in Figure 1)
(located in the Tab mentioned in the Note below) is expected for all scenarios.
For the "RAN software supported" field this refers to the specific RAN vendors RAN software release
that is supported by the feature.
Vendor to add more lines if needed.

The vendor shall respond to all areas in blue in this section based on the specification shown in the
Figure on the right (located in the Tab mentioned in the Note below).
NOTE/Remark: The same requirement is found in the Tab BOM Macro 2G SW of the Excel File with
all the Requirements. Vendor shall also complete the compliance checks in that Tab.
The vendor shall list all 2G C-SON software features to support both Vendor A and B with the number
of cells shown in the Figure (located in the Tab mentioned in the Note below).
The vendor shall list all MACRO 3G C-SON software features to support both Vendor A and B with the
number of cells shown in the Figure (located in the Tab mentioned in the Note below).
NOTE/Remark: The same requirement is found in the Tab BOM Macro LTE SW of the Excel File with
The vendor shall list all MACRO LTE C-SON software features to support both Vendor A and B with the
number of cells shown in the Figure (located in the Tab mentioned in the Note below).
NOTE/Remark: The same requirement is found in the Tab BOM Macro LTE SW of the Excel File with
The system shall be SOX compliant.

The vendors system components shall be compliant to the relevant country specific regulatory
requirements and the valid EU requirements regarding: Climatic conditions, Electromagnetic and
electrostatic conditions, Mechanical conditions, Acoustic conditions, Restriction of Hazardous
Substances (ROHS).
The system shall be compliant with Germany data protection security laws.
The Vendors network shall support all legal and regulatory requirements to which TGE is subject
(including self-regulatory initiatives).
The Vendor shall commit to ensuring that TGE remains in compliance with any changes to the
regulatory requirements and will work with TGE to incorporate any development in a timely manner.
The vendor shall include information about system database structure in his trainings.
The vendor shall provide after PO, a Statement of Work fully covering all the aspects of the project
delivery (e.g. complete solution description, high level design, detailed design, requirements for site
preparation, responsibility matrix, change requests, project plan with delivery dates and acceptance
milestones). In addition the Vendor shall provide a plan of work for delivering the solution. This plan of
work shall address scope of work, activities, resources, timescales, deliverables, milestones,
dependencies, assumptions, risks and constraints. The Vendor shall produce a costed resource profile
for each phase in the plan.
The vendor shall provide ATP and Acceptances Procedure and documents for each System Level
(Protocol, Probes, system, and application reporting).
The vendor shall provide, and keep updated at every change, detailed documentation about supported
Network Interfaces, about Protocol specifications versions, and about all implemented correlations and
full description of correlation methods.
The vendor shall provide all needed Onsite support for timely complete the projects.
The vendor shall provide, and keep updated, an inventory list with all delivered SW components, fully
detailing part numbers and licenses installed.
The Vendor shall describe their proposed strategy for testing and acceptance of the solution including
systems, process and organizational change considerations.
Under the Change Control Procedure, the Vendor shall produce a test strategy. This will identify the key
verification and validation tasks that will take place within the lifecycle model. Where, in an activity,
changes are being made to existing capability, regression testing should be included within the activity.
The test strategy should also include a TGE operational testing activity to ensure the implementation
into the live environment has completed successfully and the appropriate business systems are
functional.
The vendor shall provide sufficient resource to ensure that planned test activities are completed to the
agreed plan. The resource plan is to be communicated to TGE.
The vendor shall describe all ports which shall be opened in the firewalls across system components in
order to ensure full operations.
The vendor should provide a complete Communication Matrix for their system.
The vendor shall provide details about IP addressing and peak bandwidth requirements for the
integration and operation of all the different elements of the system, in order to support all applications
(e.g. Admins, KPI calculation, Reports, Web accesses, etc.), without any possible delay due to
bandwidth bottlenecks.
The Vendor shall provide clear bandwidth information for the whole SON solution which is required for
the TGE O&M Network (DCN).
Answer
F - fully compliant
P - partly
Comment
compliant
N - not compliant
NA - not available
Ericsson RAN supports multiple SON features including ANR,

Load balancing features, number of Energy Savings , MRO and
P Self Healing features. In addition, there are features in future
roadmap to support additional functionalities. Please refer to
clause responses below for more details on feature availability
Ericsson RAN supports SON functionality through various features

currently available and includes multiple SON features planned in
P
roadmap to further enhance SON functionality .Please refer to
clause responses below for more details on feature availability
Ericsson supports this fucntionality with " RBS Autointegration"
feature in which Configuration data based on planning results are
F
prepared in OSS-RC using the Base Station Integration Manager
(BSIM).Please refer to "RBS Autointegration.pdf" for further details
Ericsson "RBS Autointegration" feature reduces workload for

preparations, on-site activities, and work-staff coordination for the
process of integrating RBSs with a network. Only a limited amount
P
of data must be scanned or entered on-site to initiate the
automated integration bringing an RBS into service.Please refer to
"RBS Autointegration.pdf" for further details
ANR (Automated Neighbor Relations) feature adds neighbor

relations to the cells when User Equipment (UE) measurement
reports indicate that a possible new neighbor relationship has
been identified. When this occurs, the RBS requests the UE to
P
report the unique Cell Global Identity (CGI) of the potential
neighbor cell. Using this information, the RBS automatically
creates a neighbor relation between the serving cell and the new
neighbor cell and mobility is facilitated.
Ericsson RAN supports this functionality based upon UE

F
measurements
Ericsson RAN supports deletion of Neighbor cell after not being
N
used for a configurable time
In Ericsson RAN, New neighbor cells are evaluated regarding
relevance before included in the neighbor cell list. The new
neighbor cells must meet criteria regarding handover success rate.
P
It is valid for intra-frequency, inter-frequency and IRAT neighbors.
Neighbor cell is removed after not being used for a configurable
time
P
It is valid for intra-frequency, inter-frequency and IRAT neighbors.

N
It is valid for intra-frequency, inter-frequency and IRAT neighbors

P
It is valid for intra-frequency, inter-frequency and IRAT neighbors
Ericsson supports Integrated small cellsand consider it as a better

solution as compared to Femto Cells. Other neighbor relations are
P
supported. Also, HO, redirection, reselection, CSFB (LTE to
2G/3G) and SRVCC(LTE to 2G/3G) are supported
F
P This functionality would be supported in future releases for RAN
Ericsson supports this functionality with features "Inter-Frequency

Load Sharing" in 3G and "Inter-frequency Load Balancing" in LTE.
F Please refer to "Inter-Frequency Load Sharing.pdf" and "Inter-
frequency Load Balancing.pdf" for further details on this
functionality
F
functionality
functionality
Ericsson supports this functionality with "Improved RACH

Coverage" in WCDMA and "Automated RACH Root Sequence
F Allocation" in LTE. Please refer to "Improved RACH Coverage.pdf"
and "Automated RACH Root Sequence Allocation.pdf" for further
details on this functionality
Ericsson suports "PCI Conflict Reporting" feature which detects
PCI conflicts and reports the same to OSS for correction purpose.
P
Please refer to "PCI Conflict Reporting.pdf" for further details on
this functionality
F
F
Ericsson would support tis functionality in WCDMA in future
P release with feature "Mobility with Scrambling Code Reuse"
planned in W16A
Ericsson would support tis functionality in WCDMA in future
P release with feature "Mobility with Scrambling Code Reuse"
planned in W16A
Ericsson suports "PCI Conflict Reporting" feature which detects
PCI conflicts and reports the same to OSS for correction purpose.
F
Please refer to "PCI Conflict Reporting.pdf" for further details on
this functionality
Frequency Optimization eXpert (FOX) is an optional feature that

helps the operator achieve good frequency allocations and
minimize the interference levels in the radio network with a
minimum of effort. By monitoring the up- and downlink interference
environment, FOX finds poor frequency allocations, both for BCCH
and TCH carriers, and replaces them with better ones.
F
FOX in Automatic Mode operates in a closed loop: measured data
are analyzed and beneficial frequency changes are performed
without any operator interaction. FOX in Recommendation Mode
(open loop operation) requires a confirmation from the operator
before the changes are implemented.
Ericsson ANR (Automated Neighbor Relations) feature adds

neighbor relations to the cells when User Equipment (UE)
measurement reports indicate that a possible new neighbor
relationship has been identified. When this occurs, the RBS
N
requests the UE to report the unique Cell Global Identity (CGI) of
the potential neighbor cell. Using this information, the RBS
automatically creates a neighbor relation between the serving cell
and the new neighbor cell and mobility is facilitated.
Ericsson supports deletion of Unutilized Neighbor cells after not
P
being used for a configurable time
P relevance before included in the neighbor cell list. The new
neighbor cells must meet criteria regarding handover success rate
F
Ericsson supports this functionality with "Load Triggered Access

Class Barring" in WCDMA and "Load-Based Access Barring" in
F
LTE. Please refer to "Load Triggered Access Class Barring.pdf"
and "Load-Based Access Barring,pdf"
Ericsson supports this functionality with "Load Triggered Access
Class Barring" in WCDMA and "Load-Based Access Barring" in
F
LTE. Please refer to "Load Triggered Access Class Barring.pdf"
and "Load-Based Access Barring,pdf"
F
Ericsson supports this functionality in LTE RAN with features " UE
Level Oscillating Handover Minimization" and "Automated Mobility
F Optimization". Please refer to "UE Level Oscillating Handover
Minimization.pdf" and "Automated Mobility Optimization.pdf" for
further details on this functionality


Ericsson supports this functionality from RAN in LTE . Please refer
to "UE Level Oscillating Handover Minimization.pdf" and
F
"Automated Mobility Optimization.pdf" for details on this
functionality
Ericsson supports this functionality from RAN in LTE . Please refer
to "UE Level Oscillating Handover Minimization.pdf" and
F
"Automated Mobility Optimization.pdf" for details on this
functionality

further details
further details
Ericsson supports Powering down of PA and Load based
automatic MIMO to SIMO and back switching for saving energy
N during low traffic functionality. Please refer to "Micro Sleep
TX.pdf" and "MIMO Sleep Mode.pdf" for further details on this
functionality
Ericsson supports this functionality in RAN with the following
features:
GRAN:
-Discontinuous Transmission
-Channel Allocation Optimization
-Time Slot Power Savings
-BCCH Power Savings
-BTS Power Savings
-MCPA TX Power Saving
-PSU Power Savings
P LTE RAN:
-Micro Sleep TRX
-MIMO Sleep Mode
WCDMA RAN would support Energy Savings feature "Traffic
Aware Power Save " in W15A.
Please refer to "Reduced Power consumpton in GSM RAN,pdf",
Discontinuous Transmission.pdf", "Channel Allocation
Optimization.pdf" for details on GRAN functionality and "Micro
Sleep TX.pdf" and "mimo_sleep_ mode.pdf" for details on LTE
functionality
Ericsson supports this functionality in RAN with the following
features:
GRAN:
-Discontinuous Transmission
-Channel Allocation Optimization
-Time Slot Power Savings
-BCCH Power Savings
-BTS Power Savings
-MCPA TX Power Saving
-PSU Power Savings
P LTE RAN:
-Micro Sleep TRX
-MIMO Sleep Mode
WCDMA RAN would support Energy Savings feature "Traffic
Aware Power Save " in W15A.
Please refer to "Reduced Power consumpton in GSM RAN,pdf",
Discontinuous Transmission.pdf", "Channel Allocation
Optimization.pdf" for details on GRAN functionality and "Micro
Sleep TX.pdf" and "mimo_sleep_ mode.pdf" for details on LTE
functionality
Ericsson supports Cell outage for sleeping cells as part of feature

"Advanced Cell Supervision". The feature supports self-healing by
automatically trying to recover the suspected sleeping cells.
F Please refer to "Advanced Cell Supervision.pdf" for further details
on this functionality
P
Ericsson supports "Self-healing RAN" features in future releases
P
P
P
Ericsson supports Cell outage for sleeping cells as part of feature
"Advanced Cell Supervision". The feature supports self-healing by
automatically trying to recover the suspected sleeping cells.
F Please refer to "Advanced Cell Supervision.pdf" for further details
on this functionality
Internal Comments
Region to support the response
This is not a specific RAN functionality. O&M

uses Traces, CM, PM parameters, and NBI
standard information and based on this CCO is
implemented for 3G and 4G
doc

Germany SON RFQ 2014 - Annex 02 - SON-Self-Configuration and Self-Optimi PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Germany SON RFQ 2014 - Annex 02 - SON-Self-Configuration and Self-Optimi PDF

Загружено:

Авторское право:

Доступные форматы

RQ

Chapter Chapter Name

1 3.1.1 General Requirements

2 3.1.1 General Requirements

3 3.1.1 General Requirements

4 3.1.1 General Requirements

5 3.1.1 General Requirements

6 3.1.1 General Requirements

8 3.1.1 General Requirements

9 3.1.1 General Requirements

14 3.1.1 General Requirements

16 3.1.1 General Requirements

17 3.1.1 General Requirements

18 3.1.1 General Requirements

19 3.1.1 General Requirements

20 3.1.1 General Requirements

21 3.1.1 General Requirements

22 3.1.1 General Requirements

23 3.1.1 General Requirements

24 3.1.1 General Requirements

25 3.1.1 General Requirements

26 3.1.1 General Requirements

27 3.1.1 General Requirements

28 3.1.1 General Requirements

29 3.1.1 General Requirements

35 3.1.1 General Requirements

36 3.1.1 General Requirements

37 3.1.1 General Requirements

38 3.1.1 General Requirements

41 3.1.1 General Requirements

42 3.1.1 General Requirements

43 3.1.1 General Requirements

44 3.1.1 General Requirements

45 3.1.1 General Requirements

46 3.1.1 General Requirements

47 3.1.1 General Requirements

48 3.1.1.1 Storage Requirements

49 3.1.1.1 Storage Requirements

51 3.1.2 National Roaming Requirements

52 3.1.2 National Roaming Requirements

54 3.1.2 National Roaming Requirements

55 3.1.3 OSS Requirements

56 3.1.3 OSS Requirements

57 3.1.3 OSS Requirements

58 3.1.3 OSS Requirements

59 3.1.3 OSS Requirements

60 3.1.3 OSS Requirements

OSS Project Management and Project

OSS Project Management and Project

OSS Project Management and Project

OSS Project Management and Project

OSS Project Management and Project

OSS Project Management and Project

SON Auto/Self-Optimization & Use

SON Auto/Self-Optimization & Use

SON Auto/Self-Optimization & Use

SON Auto/Self-Optimization & Use

SON Auto/Self-Optimization & Use

SON Auto/Self-Optimization & Use

SON Auto/Self-Optimization & Use

SON Auto/Self-Optimization & Use

SON Auto/Self-Optimization & Use

SON Auto/Self-Optimization & Use