Section

Description

INTRODUCTION
This document is TSCs Request For Proposal (RFP) on LTE Mobile Broadband Network based on the 3GPP standards. The primary goal of this RFP is for each
Vendor to describe the complete offered solution, including features and functions, key advantages, anticipated enhancements of their LTE solution. A vendors
response to the requirements of this RFP will allow Taiwan Star Cellular Corporation to understand:
What products and services are proposed,
Availability, technical maturity, timing, and pricing of the proposed products.
The document only contains a list of requirements on the functionalities mainly requested for a 3GPP LTE network. For each requirement, exact conditions,
characteristics, roadmap and limitations must be reported in the vendors answers.
Each vendor is requested to provide the information according to 3GPP Reference Architecture defined in Section 5 of this RFP document.

Date to Response
Proposals must be received in Taipei, Taiwan prior to 14:00 Oct 7, 2013. Late submission and incomplete of the proposal may be considered invalid.
Responses arriving before this date could expedite evaluations. All documents shall be sealed, marked with Sellers name, address, and con-tact point.Proposals
shall be sent by verifiable means. No responsibility or allowance for delay will be made for any documents by mail.

Scope of Work

3.1.

Introduction
The Tenderer is required to quote the supply of LTE implementation network infrastructure and all re-lated services. The Tenderer shall consider within the Scope
of Work all related services such as Preparation, Implementation, Installation, Commissioning, Network Adaptation, Testing, Optimisation and Elaboration of
detailed Documentation. The Tenderer shall also include within the Scope of Work, a proposal for Workshop, Training, Warranty and Technical / Maintenances
Support.

3.1.1.

TSC LTE RFP content consists:

3.1.1.A. This Main Document: contains all General RFP information and requirement such as Tender scope, schedule, and Tenderers Qualification & Technical
specification
3.1.1.B. Attchemetn 1: LTE feature list and UMTS feature list and feature roadmap need to response
3.1.1.C. Attachment 2: Terms & Conditions.

Compliance

Avaiable Date /
SW Ver.

Mandatory or
Optional

In this offer

Reference

3.1.2.

Tenderer Documents
Tenderer shall fill out and submit its Tender response proposal in One hardcopies &
Three softcopies (CD Rom) to the Buyer which contains three separate enclosures as follows:
Enclosure 1:Tenderers Qualification
Enclosure 2:Technical Proposal for the response for Project related deliverables
Statement of Compliance (SoC): Tenderer shall provide point-to-point response andfill in compliance table for every item stated in RFP
do so shall be deemed as Fully Comply with this RFP and TSCs terms and instructions.

Enclosure 3:

Tenderer shall provide the proposal with standard MS Office 2010 (ex. Word or Excel or Project) format.
Buyer may request the Chinese version of response or description for specific items.
The offered technology shall, in all aspects, to be compliant with the latest relevant ITU-T, 3GPP and ETSI standards. Proprietary solutions shall not be
accepted.The Tenderer shall quote all network element that will be proposed.
Tenderer shall respond to each and every alphanumeric item in the same order contained in this RFP. Before the item-by-item responses are described in details
in the Technical Proposal, a Statement Of Compliance (SoC) table shall be submitted as summary at the beginningof the Technical Proposal according to the
format described as follows:
Compliance: FC (Fully Compliance), PC (Partially Compliance), or NC (Not Compliance).If the item is requested for information only, Tenderer shall fully comply
with information provided.
Available date: date of commercially available for compliance
Mandatory or Optional (M/O)
In this Offer: Yes (within scope of supply / service in this Proposal); No (out of scope of supply / service in this Proposal)
Reference: supporting documents of reference information if any
Explanation: statement of compliance.
Table 1.1 Statement Of Compliance (SoC) table example

3.1.3.

Tenderers Qualification
Tenderer's qualification should include the following documents:
Documents evidencing the legal identity of Tenderer, such as certificate of incorporation and business registration or license. (including the permit statement for
Radio Equipment Sales & Import for LTE Base Station and User Equipment)
A letter duly executed by Tenderer authorizing a representative (natural person) to act for Commercial in Cofidence Tender in the Tender process

3.1.4.

Price Proposal
Price quotation contained in the Price Proposal shall be made to fulfill the scope of the Works to satisfy the technical requirements as stipulated in this RFP based
on the terms and conditions set forth in Attachment 2. Each item listed in the submitted Price Proposal shall be consistent with the BoM in the submitted Technical
Proposal and indicate the unit price and quantified price. The hardware price shall be quoted with breakdown to function level, sub-function level and board level.
The software price shall be quoted on per software feature basis including both basic and optional features. The service items including implementation service
shall be quoted with the information of how many man-days estimated. The services to be offered during and after the warranty period shall be quoted
respectively, and explain how these services are quoted.
The price quoted in the proposal shall be the total and full value of the Contract and shall cover all costs, ex-penses, and risks of whatever nature incurred in
connection with the Contract. Such costs and expenses include but are not limited to all equipment, facilities and materials for delivery, shipment, installation,
integration, testing and completion of the Works; all expenses incurred in planning, design, programming and coordination of the Works; overheads, taxes;
liabilities, obligations and risks under the Contract; and all other matters necessary for completion of the Works as set forth or implied in the Contract.
Tenderer shall bear the risks of omission or insufficiency of the work items listed in BoM and Price Proposal. Such omission or insufficiency shall not affect the
Contractor's obligations to complete the Works and fulfill all requirements under the Contract with the Contact Price; the Contractor shall not be entitled to any
price increase or compensation for such omission or insufficiency.
All license fees or expenses of whatever nature for use of software necessary for operation of the Works shall be specified in the Price Proposal and included in
the Contract Price.
Prices for the portion of the Works to be provided and/or performed within R.O.C. shall be quoted in New Taiwan Dollars (NTD). Prices for the portion of the
Works to be provided and/or performed outside R.O.C. shall be quoted in United States Dollar (USD). Unless otherwise specified, all prices quoted for imported
goods and/or services shall be made on the basis of DDP (Delivered Duty Paid) at the Buyers premise and be quoted in United States Dollars (USD); Tenderer
shall also provide the price quotation for FOB cost, freight, insurance premium and applicable import duties separately.
Unless otherwise specified, all prices quoted for goods and/or services to be supplied within R.O.C. shall be made on the basis of delivery at the Buyers premise
or the Buyers designated storage area or site.
Such price shall include both inland and offshore of local transportation, temporary storage, loading and unloading cost and be quoted in New Taiwan Dollars
(NTD).
Tenderer is encouraged to propose its financial support on payment term such as but not limited to payment structure, performance assurance etc. to effectively
reduce the Buyers risk due to the technology and market uncertainties.
All the requirements requested in RFP will be deemed as Mandatory request unless there is an Optional notice specified in the statement.
The Tenderer shall also quote in detail all project requirement services such as but not limited to:

3.1.4.A. Installation and Commissioning (including cranes)

3.1.4.B. Network Migration Services and related Documentation
3.1.4.C. Test plant Installation and Commissioning
The Tenderer shall quote technical support service as below, but not limited to:
3.1.4.A. Technical Support
3.1.4.B. Spares Parts Management Service
3.1.4.C. Operation & Maintenance Support Services
The Tenderer shall quote a proposal for Workshop, Training, and Hardware / Software Documentation:
3.1.4.A. Training and Course Materials (Including delta releases courses)
3.1.4.B. Equipment Hardware and Software Documentation.
3.1.5.

No Compensation
Tenderer shall bear all costs, expendes and risks for prepration and submisssion of Tenderer. Tenderer is not entitled to any claim or compensation against the
Buyer in relation to prepration or submission of Tenderer.
Tenderer's non-compliance with the RFP may be a cause of the Buyer's rejection or disqualification of the Tender. Furthermore, the Buyer may deem any or all
Tenders disqualified on any grounds without giving any reason. Tenderer shall be not object to and is not entitled to any claim or compensation against the Buyer
for such determination during the process of evaluation of Tenderers, award of the Contract or performance of the Contract.

3.1.6.

Contact Information
Materials regarding this RFP shall be delivered either personally or via registered mail to :
Engineering department:
Brian Tseng
Mobile: 0935150872
Email: [email protected]

3.2.

Project Description and Requirement

The Buyer will be responsible for Site Acquisition and site rental contract. The Tenderer shall take responsibility of the implementation project including spares
management during the implementation period, until formal acceptance of all items is agreed.

3.2.1.

Project Management Coordination

Tenderer shall provide a dedicated project management service during all the implementation phases. The project management functions shall ensure:
That the Tenderer project organization works in close cooperation with the Buyers organization
That the Local Supplier activities are followed up and performed according to the agreed quality requirements and time schedule.
That the Contractual obligations and requirements are met and are followed-up on a daily basis.
Tenderer is responsible for the project planning, control and reporting.
Lead-time for delivery would be kept.
That Buyer receives adequate periodic reporting on project status and deliveries according to its request
The forecast and ordering the equipment, installation materials and installation and commissioning ser-vices.
Operation support & Escalation
Suppliers third party Supplier Management
That the project documentation is prepared and provided to Buyer according to the contract provisions.
Some quality criteria and value should be established and followed during the implementation project:
Marco planning criteria (day of implementation site vs. performed)
Site by site down time. The supplier will be required to select solutions with minimal impact for the clients

3.2.2.

Implementation Services
The main services that must be provided by Supplier are described herein but not limited to:
Implementation Preparation & Negotiation: implementation site preparation documentation. Negotia-tion is also to be performed by Tenderer in case of new LTE
sites.
Site Survey: Includes the survey activity required to anticipate eNodeB installation. A site survey report shall be delivered by the Tenderer.
Site engineering & Civil Works (Stability Studies, Lease )

3.2.3.

Tools
The Tenderer is responsible to provide all necessary tools required to perform his job autonomously. These tools should comply with Buyer reporting and
interworking requirements.

3.2.4.

Training
The Tenderer is required to provide training courses to the BUYER Engineers (internal and O&M field out-sources).

3.2.5.

Documentation Operation & Maintenance

The Tenderer shall provide Buyer at least 1 (one) month before the beginning of implementation activities the documentation containing a least:

3.2.5.A. Maintenance technical procedures (HW replacement, etc.)

3.2.5.B. Troubleshooting document based on Alarm Handling
3.2.5.C. Configuration and Performance tools manuals, CM and PM database schema
3.2.5.D. System Administration containing all O&M procedures, troubleshooting methods
3.2.5.E. Preventive Maintenance recommendations and procedures
3.2.5.F. Operational procedures for network reconfiguration
3.2.5.G. Alarms description
3.2.5.H. Spare parts and compatibility documents
3.2.6.

Documentation Engineering Optimization and Performance

The Tenderer shall commit to provide Buyer at least 1 (one) month before the beginning of activities to docu-mentation containing at least:

3.2.6.A. LTE parameter directory, Describing the parameter function, the Range, The object type associated and the default setting value
3.2.6.B. LTE parameters engineering rules
3.2.6.C. MM, CM, SM, PDP context management
3.2.6.D. LTE optimization techniques
3.2.6.E. Counter dictionary with counter description

3.2.6.F. Signalling flow chart should show the involved LTE procedures, and precisely which message triggers the counter increment
3.2.6.G. KPI mapping and monitoring
3.3.
Engineering Support and Services
The purpose of this chapter is to specify engineer and operations support network requirement for the deploy-ment of LTE in Buyer
3.3.1.

Engineering Support
The objective of this support is to guarantee the objective of improving the network performance. The Engi-neering and Planning Support services that are
detailed in the following sub-sections shall be included in the scope of the RFP answer. Engineering and Planning Support shall be required for, but shall not be
limited to, the following activities:

3.3.1.1.

Acceptance and Demonstration

The Tenderer shall provide appropriately skilled personnel to support the implementation process and to support Buyer personnel during all the stages of the
project. A Network Element Acceptance of each element shall be per-formed before it is handed over to Buyer (the acceptance procedures are detailed with
Acceptance Processes and Criteria)
Acceptance includes the following activities:

3.3.1.2.

Planning and Dimensioning

As part of the Dimensioning process, Engineering Support for LTE Network Planning is required as part of the RFP services (including documentation):
LTE Default Parameter Settings elaboration
LTE network Optimisation (guidelines)
LTE network Dimensioning (guidelines)

3.3.1.3.

Configuration
Whenever Hardware or Software is introduced, modified or modernised, its configuration (e.g. software, pa-rameters, cabling, combiner selection, etc.) shall be
tailored for deployment on the Buyer network. The Tenderer shall perform this process to ensure that requirement of product are respected and the benefits of the
Product are maxi-mised.

3.3.1.4.

Site Design
Whenever equipment (e.g. DDF, Cabling, Site Support Cabinet, Antennas) is introduced, modified or modern-ised, the application and impact of this equipment
on all site designs shall be carefully considered. The Tenderer shall perform this process to ensure that optimum performance is obtained from the equipment,
and that all installation and operation requirements are respected.

3.3.1.5.

Features
The Tenderer shall arrange a workshop to present all products and new functionalities / features to engineering and O&M departments. The purpose of the
workshop is to establish whether the new features are aligned with the current and planned network and business objectives.

3.3.1.6.

Test Equipment and Tools

Support shall be provided to ensure that the operation of all (test) equipment and software tools is fully under-stood by one or more key users within Buyer

3.3.1.7.

SLA for responses

Tenderer must provide in a maximum of 7 (seven) days proper answers to requests from Engineering (product description), Planning, and feature behaviour /
parameters.

3.3.1.8.

Engineering on Site Assistance

With the deployment and optimization scope, on-site assistance may be required but limited to the LTE network design, engineering and reconfiguration actions
such as:
Network parameters template definition to be the baseline for deployment
Assistance for introduction of new software features and parameters configuration
Assistance related network architecture, such as definition, service interactions analysis, signalling network definition, etc.
Assistance for procedures related to major network re-arrangement or reconfiguration, such as analysis net-work configuration, parameters settings, consistency
check, perform statistics, etc.
Assistance for the launch of new services
Assistance in the deployment, such as integration, interfacing, optimization of the LTE network performance.
Network Architecture Design
Network Optimisation and 3G inter-working
Tenderer is free to propose any other type of engineering services that it may feel required guaranteeing the successful completion of this LTE deployment
project.

3.3.1.9.

LTE Network Configuration

The Tenderer is responsible for defining the initial hardware configuration, such as Antenna type , electrical and mechanical tilts, and Azimuths. Buyer shall
approve the configuration that has impact on UTRAN network.(If Buyer would have UMTS network at implement time)
The complete responsibility of configuring the LTE Network and all LTE connections needed to carry all types of traffic will lie on Tenderers responsibility. The
parameter Template must be approved by Buyer based on Tenderer proposal and any change to baseline Template shall be reported to Buyer.
The Tenderer is responsible to do the planning of initial E-UTRAN radio parameters, such as PCI, Neighbours, RACH Root Sequences, etc. Buyer will be provided
the eNodeB ID, Cell ID, and TAC.
Each action to be performed needs previous creation and approval of a Planned Work. The Tenderer is required to create and send for approval to Buyer of all
Planned Work that might be needed during the whole implementation project.

3.3.1.10. OAM Platform

All services and activities needed in order to design, dimension, implement and commission of the Network Management System will be performed by the
Tenderer. Common agreed documentation will be validated before actual implementation of the proposed solution based on Buyer requirements.
3.3.1.11. End-to-End Quality of Service
The Tenderer is responsible for the End-to-End Quality of Service of all types of traffic inserted and transported via the new E-UTRAN Network, to be created
according to the traffic contract and SLA to be provided by Buyer (mu-tually agreed before configuration and implementation) Buyer will provided reference KPI
indicators and values for values for the Tenderer reference before acceptance and optimisation works.
3.3.2.

General Requirement

3.3.2.1.

RAN Configuration
Hardware Configuration: The Tenderer is responsible for defining the initial hardware configuration, such as Antenna type, Electrical and Mechanical tits, and
Azimuths.
Parameter Template: The E-UTRAN network shall be configured in accordance with parameter baseline ap-proved by Buyer based on the Tenderer proposal.
Any change to baseline template shall be reported to Buyer.
Initial Planning: The Tenderer is responsible to do the planning of initial E-UTRAN radio parameters, such as PCI, Neighbours, RACH Root Sequences, etc.
Buyer will provide eNodeB ID, Cell ID and TAC.
Network Optimization: The Tenderer is responsible for all the optimization activities, such as KPI analysis, drive tests, etc. All hardware and parameter changes
shall be reported and the ones that could have impact in GERAN and / or UTRAN networks shall be previously validated by Buyer.
Performance Reporting: The Tenderer shall update a weekly performance report and comment the KPI evo-lution. The report must include at least the KPI
proposed, the statistical data with daily and week aggregation of each acceptance level: Cell, Cluster and Zone, Drive Test result of each Cluster, list of hardware
and software changes, list of alarms, tracking list of Site I&C and other incidents that might have impact on the performance.

3.3.2.2.

OSS Configuration
The Tenderer shall implement the parameter changes that are issued by the Buyers optimization team in E-UTRAN OSS, such as parameters, neighbour relation,
etc.
The Tenderer shall provide Buyer the parameter changes that are implemented in E-UTRAN OSS, in a com-prehensive format and in a short time frame, to
enable Buyer to adapt those changes on other systems.

3.3.2.3.

Equipment and Tools

Supplier is responsible to provide all necessary equipment and tools required to perform its job. These tools should comply with Buyer reporting and interworking
requirements. This compliance includes import and export formats from other tools issued by the Buyer at the duration of the project.

3.3.2.4.

Team Constitution
The Tenderer is expected to have a Well Dimensioned Team with good technical knowledge and preferably with previous experience in similar projects.
The project manager responsible for the E-UTRAN deployment and optimization must be senior Engineer and for the entire life time of the project.
The Buyer reserves the right to have one or more of its own Engineers following all RAN optimization tasks, such as the measurement tests, data processing and
analysis.

3.4.

Technical Support
In this sub-chapter, the Tenderer should include temporary or permanent maintenance services and system support like fault report handling, software and
hardware updates, technical periodic audits of the network and assist the Buyer to handle system network modifications.
Technical Support should target all system proposed (eNodeB, OSS, other third party equipment)
On-site Technical Assistance
Emergency Support: Emergency Technical Assistance (Hardware and Software): Root Cause / Outage Analysis with preliminary and final outage reports
providing root cause of the resolved issue.
According to Maintenance Services, please clearly state what the different support levels that are provided.
Investigation and Resolution of all non-emergency software and hardware problems: Investigation and resolution of all non-emergency software and hardware
problems: Root Cause / Outage Analysis with preliminary and final outage reports providing root cause of the resolved issue
Advise / Consultancy, detection and resolution of software / hardware related problems.
Technical support for network integration
Problem report handling service / trouble report guideline
SLA for Problem report handling for product change requests:

(*) In case that resolution time exceeds Max Resolution Time, the occurrence must not be excluded from Resolution Time calculation.
The Tenderer shall clearly state if different from proposed target SLAs.
Advance Notice of Future Software Releases and Roadmap
Software updates services: Software updates services (delivery, installation, commissioning & testing, FOA and Rollout) with local and remote support.
Local assistance during new software updates delivery, test and rollout
Local assistance during new release delivery, delivery, test and rollout
Local assistance during functional acceptance
Detail Consultation services available
Detail Escalation procedures.
All the items related to this service shall be quoted as an annual fee (according to quotation guidelines)
The Tenderer shall clearly state the conditions appliance in and out of warranty period.
Please define all expressions and acronyms used in the Technical Support contract and service (e.g. AC Approved Correction, Emergency Call-up time) for
future common understanding.
The Tenderer must clearly describe the project team allocated and their organization in Local office and Remote cen-tres to cope with the requirement presented
by the Buyer, namely (but not excluding others):
Organization
Skills / Experience
Local and Remote Competences
Place(s) of work
Escalation Procedures
The target SLAs fro the Technical Support Service are:

The Tenderer shall clearly state if proposes different from above target SLAs Nevertheless must always consider this scenario.
(*) In case that restore time exceeds Max resolution Time, the occurrence must not be excluded from Resolution Time calculation.
3.5.

Spare Parts Management Services (SPMS)

Spare Parts Management Service must ensure the availability, storing, pick-up, repair and delivery of the spare parts to Buyer when and where needed.
The Tenderer takes ownership of spare parts and best practices for network evolution.
The Tenderer shall describe the service including handling of Buyer service requests, repair and all logistics issues associated. The pick-up and delivery of spare
parts to Buyer should consider in several locations, normally the Buyer O&M Centres; the replacement of the faulty units on site shall be under Buyer Technicians
responsibility.

3.5.1.

Spare Parts Management Service Requires

The Tenderer shall describe the spare part management process.
The Tenderer shall assure a spare part of all equipment including non-reparable items (HW, cables, back-planes, fuses, vendor consumables, etc.) All the spare
parts shall be Tenderer property.
Spare part list will be dimensioned based on MTBF and Installed base by analysing failure rate. Non-reparable items considered as consumable is not considered
under spare list.
The Tenderer spare parts must be maintained and kept up to date to face network growth and evolution, en-suring spares availability both in terms of quantities
and right revision states and spare storage that enables to delivery replacement Units with accuracy and speed, all according to pre-determined SLAs.
Hardware and Software replacement: The Tenderer shall describe the service including handling of Buyer service requests, testing, repair, transport and delivery
of the faulty Units to Buyer technicians.
Report and Statistics: The Tenderer shall provide monthly statistics / reports of replaced fault Units and provide quarterly the updated list of all the spares
identify the critical and non-critical spares

3.5.2.

The Target SLAs: Lead Time for Delivery

The quotation should target the Lead Time for delivery presented (days in calendar days):

3.6.

Acceptance Processes and Criteria

This chapter defines the Scope of Work required by Buyer for the acceptance process within the LTE deployment project.

3.6.1.

Acceptance Levels
Acceptance will be carried out based on Statistic KPI, Alarms, Interface Tracing and Field Measurements (drive tests). The following acceptance levels apply:

Site Acceptance
Acceptance
The zone acceptance will be the official handoff point of OAM from the Tenderer responsibility to Buyer, if all criteria for acceptance are met.

3.6.2.

Site Acceptance
Purpose: Guarantee that the site is correctly installed, commissioned and integrated with the minimum levels of quality so that regression is not needed.
Description: Buyer will audit the sites in order to check and validate the quality of the deployment. The site formal acceptance will be held together with Cluster
acceptance, as long as deliveries are ready and in case of the acceptance criteria is fulfilled.

3.6.2.1.

Commissioning Document
Procedure: Installation shall meet Buyer installation guidelines. The Tenderer shall provide evidence of this, including installing checklist, photographs and punch
list.
Acceptance Criteria: These include at minimum:

3.6.2.1.
A.
3.6.2.1.
B.
3.6.2.1.
C.
3.6.2.1.
D.
3.6.2.1.
E.
3.6.2.1.
F.
3.6.2.2.

Installation checklist

3.6.2.2.
A.
3.6.2.2.
B.
3.6.2.2.
C.
3.6.3.

All sectors are checked, on air and unlocked

Any site modifications will be according to Buyer requirements

A photographic report of the installation shall be sent (including HW replacement photo, photos of cable labeis)
Radio commissioning report
Site documentation update (and respective update in Database) As Built
Punch list will feature no blocking issues
Site Verification and Check
According to Installation and Commissioning (I&C) level of requirements, the Tenderer will check that the sites are in good conditions so as to perform End-to-End
tests:

OMC Alarms are OK

Absence of crossed sectors
Acceptance
Purpose: Verify that LTE deployment processes are correctly defined and can be scaled up. Validate in live network the software release features, performance
and configuration template, already drafted in test plant phase.
POC Acceptance Criteria:
A. Pilot Cluster accepted
B. Performance as per KPIs agreed

3.6.3.A. Pilot Cluster accepted

3.6.3.B. Performance as per KPIs agreed

3.7.

Responsibility Matrix
The table included below is the responsibility matrix for the rollout period activities. All works will be performed according to relevant national laws and mutually
agreed. Please provide as per line compliance status verification, and additional comments when required.

3.7.1.

Infrastructure Implementation
Any deviations from the Technical Specifications, or other applicable documents or instructions by Buyer can only be enforced after the previous approval of
Buyer.
The Tenderer must comply with laws, regulations and statutes applicable to the activity and as expressed in the Contract of Services.
The supply of equipment and materials should follow the provisions of the Contract of Services and the Technical Specifications.
The Tenderer pledges to engage in the works of the site implementation human and technical resources nec-essary for the implementation on a continuous and
timely manner.
Under the terms defined in this document, the works of site implementation should be continuously monitored by a Work Coordinator, appointed by the
Tenderer.
At any time, Buyer can access the work area in order to supervise the evolution of the works and may require the presence of the Work Coordinator of the
Tenderer to review the progress of the work and transmit Buyer guidelines, particularly in relation to abnormalities / deviations detected.

3.7.2.

Works for the supply of Electricity at Low and Medium Tension

Build power cabling, in duct, aerial or inside buildings, when so requested by Buyer will be responsibility of Tenderer. The price should include this work as
optional on unitary basis.

3.8.

Auxiliary RF Equipment Requirements

In this context, together with the proposed eNodeB solutions, the Tenderer shall quote the delivery and installation of macro sites, suited to work within the
specified frequency bands for LTE. Additionally, proper antennas shall be delivered and installed as well, together with other equipment RF cabling, etc.
Detailed requirements are given in the following sections.

3.8.1.

Antenna Requirements
The proposed antenna products shall obey to the following general requirement:
Connectors: 7/16 female is preferred for radio components.
The proposed LTE antennas shall be compliant with the following characteristics:
Dual Linear polarisation (+/- 45) or vertical polarisation as required.
Minimum gain should be 18dBi. Proposals providing gains above 20dBi will be positively discriminated. Minimum 16.5dBi for antennas.
Nominal input impedance is 50 Ohms.
Input return loss should be less than -17dBi (VSWR less than 1.328) for all ports, over all tilt range.
Azimuth beamwidth shall equal to 65 with a tolerance margin of +/- 5.
Front-to-Back ratio must be below -30dB, over frequencies, over tilt range.
Elevation Beamwidth shall be within [4 ; 6] with a tolerance margin of +/- 0.5.
Electrical variable tilt range shall be within [0;6] with higher ranges being positively discriminated, as well as optional mechanical tilt. Electrical down-tilt
accuracy must be with 0.5. RET and AISG shall be supported.
Isolation shall be no less than 30dB.
The Tenderer will be requested to provide information (test results) on antenna performance under different environ-mental conditions, especially under rain
conditions.
LTE solutions ready to support future deployment of DL MIMO 4x2 or DL MIMO 4x4 will be positively discriminated.

3.8.2.

Feeders and Jumpers

When distributed eNodeBs are proposed, the Tenderer shall provide the necessary jumpers in order to connect the remote radios to the antennas, according to
Buyer requirements, summarised below:
Coaxial cable with foam dielectric (polyethylene).
Impedance 50 ohms.
The maximum allowed jumper + connector losses is 1.25 dB.
Recommended brands / references
When traditional macro solutions are proposed and no diplexer / triplexes are to be used, beyond the installation of top jumpers, new feeders and bottom jumpers
shall be installed as well. These shall comply with the following require-ments:
Coaxial cable with foam dielectric (polyethylene).
Impedance 50 ohms.
The maximum allowed jumper + connector losses is 3dB.
Allowed brands / references.

The proposed connectors shall be compliant with the following general requirements:
Resistant to twist, temperature extremes, vibration and tension forces.
Consistent connector-to-cable bond.
Secure mechanical attachment, provide stable RF performance without degradation over time.
Strong mechanical attachment, reducing service issues such as loose or broken connectors.
Compliant with the used feeders / jumpers.
100% water proof.
Proposals including supply and installation of PPC connectors, based on patented compression technology, will be positively discriminated.

3.9.

Project & Services

3.9.1.

Technical Support & OAM Services

The Tenderer shall quote the Technical Support as specified in the Scope of Work. Add other relevant services costs, e.g. Consulting: the Tenderer is requested
to give the price for a consultant per day (per subsystem or per Network Element if different)

3.9.2.

Test Tools
The Tenderer is requested to quote all the test tools necessary as per Scope of Work to manage and optimize the network. The Tenderer shall detail in this
document the list of tools quoted for each subsystem.

3.9.3.

Training
The Tenderer shall quote training as per Scope of Work. Additionally a lump price per people and per day shall be provided. This price shall be valid for Buyer
and Tenderer; as well as for sub-contracted companies working in Buyer Network e.g. Tenderer Access Network Field Maintenance.

3.9.4.

Spare Parts Management Service

The Tenderer shall quote the Spare Parts Management Service for the network according to the lead times purposed in Scope of Work.

3.9.5.

Additional Services (Radio Planning & Others)

The Tenderer may quote additional services than the previous ones required. In this case, the additional services shall be quoted and detailed here.

Solution Proposed & Dimensioning

The Tenderer shall also make evidence that will provide to Buyer the tools, services and mechanisms needed to address a smooth implementation without service
disruption of 2G/3G.

4.1.

Network Equipment
The Tenderer shall detail all unitary hardware configurations identifying, per site, all platforms components.

4.2.
4.2.1.

Network Cabling and Racks

Cabling
The Tenderer shall describe the cabling scheme necessary to implement the solution, namely:
Type of cabling
Explain how cabling is addressed in the rack and equipment

4.2.2.

Racks
The Tenderer shall describe the racks proposed for installing all the different equipment proposed within the solution, namely:
Type of Rack
Dimensions ( H x W x D)
Physical Layout
Air Removal System
Power Distribution System
Cabling Management

4.3.

Network Topology
The Tenderer shall describe the network topology proposed assuring and addresses all requirement defined by Buyer, namely:
High-Availability
Efficient Traffic Engineering
IP Interfaces Compliance

4.4.

Network Dimensioning / Capacity Planning

The Tenderer shall detail all dimensioning and capacity rules / assumptions.

4.5.

Network Implementation Services

The Tenderer should provide below service and detail description:
Project Management
Telecom Implementation
Customer Logistics
Power Solution
Antenna Solution

4.6.

Care Services
The Tenderer should provide end-to-end care service and detail description.

Time Plan

5.1.

LTE Network Implementation Time Plan

The Tenderer shall provide a draft project time plan that includes all phases and major activities related to the project with regards of LTE planning, site adaption
and implementation. The Object is Tenderer to provide a maximum number of LTE sites integrated per week, optimisation services duration, etc.
The Tenderer should provide an over view and description of resources dedicated to this LTE project, specifying local and remote resources separately.

Services

6.1.

LTE Network Implementation Services

The Tenderer shall list and describe in detail services steps / resources / SLAs, with as much granularity as possible:
Network Implementation
Staging, Installation and Commissioning
Functional Acceptance Tests
Network Optimisation
Test Plant Installation and Commissioning
Technical Support
SPMS

Training, Documentation and Workshops

7.1.

LTE Network Training

The Tenderer is required to provide training courses to the Buyer Engineers and in the least cover the following topics:
Hardware Integration
OSS Platform Theory
OSS Platform Practical operation
LTE HW Operation and Administration courses
LTE Radio Access Network Essentials
OSS Administration
LTE: Radio Planning Essentials
LTE: Radio Planning Specialist
Radio Access Network Parameter.
LTE Functionalities Course.
Counter Monitoring and Implementation
Delta Courses
The courses should target the different levels of skills and should also be available to Buyer partners (Buyer / Outsourcers). All trainings should be scheduled
during year 0.
The Tenderer shall propose a training plan. Number of participants per course will be subject to Buyer requirements. The exact amount of training should be
defined in the detailed training plan. Please quote courses individually.
The Tenderer shall provide a list of training sessions proposed in this RFP for LTE Network. The Tenderer shall provide information for each training session
proposed, namely:
Contents, Duration, Maximum Number of participants
Course HW / SW / Logistic Requisites (test plant nodes, room, projectors, etc.)

7.2.

LTE Network Documentation

The Tenderer shall list and describe in detail what kind of documentation regarding the equipment hardware and software manuals that will be delivered to
Buyer. The Tenderer shall also describe the methods available to access the documentation like Web or Documentation CD.
The Tenderer shall detail if there are equipment and software manuals that will not be provided within the RFP project to Buyer.

COMPANY INFORMATION
Q.1 Provide company profile, including wireless research and development organization that support the proposed product development.
Q.2 Describe your Taiwan based operation including technical support and service organization

Radio Access Network (RAN) Technical Requirement

9.1.

E-UTRAN Technical Requirement

This chapter contains all Technical Requirement of LTE Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and UMTS Terrestrial Radio Access
Network (UTRAN) with its associated network elements, network design, operation and regulatory requirement. The Tenderer is invited and requested to provide
your formal Point-to-Point responses with explanation and supporting document for Questions and Requirement listed in the following sub-sections of this
document.

9.2.

SOLUTION ARCHITECTURE

Q.3

Vendor shall provide a 3GPP compliant LTE solution architecture diagram showing all logical interfaces.

Q.4

Vendor shall provide a Solution Overview document, which includes the system architecture and each network element of the Radio Access Network, the network
management system and the backhaul.

Q.5

Vendor shall describe the benefits of their solution if any in a Solution Overview document.

Q.6

The deployed solution shall support 3GPP compliant, software configurable Frequency Division Duplex (FDD) [or TDD] channel bandwidths. Channel bandwidth
of 10MHz and 15MHz [and/or 20MHz] should be supported in the initial commercial release.

9.3.

Hardware Roadmap

Q.7

Vendor shall provide 3-year hardware roadmap for E-UTRAN and UTRAN equipment.

Q.8

Vendor should describe all hardware dependencies for 3GPP features available in the roadmap.

Q.9

Vendor should indicate the E-UTRAN and UTRAN hardware phase-out and product Life-Cycle plan for 3 year at least.

9.4.

General Requirement

Q.10

E-UTRAN/ UTRAN 3GPP Compliance: The LTE E-UTRAN & UMTS UTRAN solution offered by Tenderer shall fully comply with 3GPP Release 10 LTE
Advanced standard (final stage 3 or above) and UMTS Release 10. The Tenderer shall apply your commercial available software & product (by the end of Y2013,
R10 ready) to respond to the requirements requested in RFP.
(Note: if Tenderer plans to apply the S/W or product not yet commercialized for compliance, Tenderer shall provides free upgrade without adding any additional
cost to Buyer.)

Q.11

E-UTRAN/ UTRAN 3GPP Backward Compatibility: Tenderer shall comply with theoverall feature set identified in 3GPP Release 10, (also backward compatible to
R10 below) and the E-UTRAN/ UTRAN feature requirement (but not limited to.

Q.12

E-UTRAN/ UTRAN Roadmap: Tender shall provide your E-UTRAN/ UTRAN and associated OAM Roadmap which identifying each major/minor Software Release
with is 3GPP compliance, all hardware product supporting the Software Release, and all features included in each Software Release. Tenderer shall respond your
main complied Software Release and roadmap within coming two year.

Q.13

Product & Feature Description: Tenderer shall provide detailed Product Description of offered software & hardware in BoM including LTE E-UTRAN/ UMTS
UTRAN and EMS-related equipment. The product Description should cover both Hardware and Software Architecture and identify the major hardware and
software component functions of this architecture. Tenderer shall also provided detailed Feature Description of offered complied features listed or identified in the
Product Plan and the subsequent RFP responses.

Q.14

TSC 2013 RAN RFP Scope: This RFP scope will be included but not limited to:

Q.14.(A) RAN Option 1

.

Q.14.(A) Tenderer shall provide best cost-effective and space/energy saving solution for the frequency combination of below 3 possible scenarios in single Base Station
.a.
platform (Single RAN) to minimize the cost/foot print/ power as possible. Remote RF Unit can be one of approaches to achieve above goals.
Scenario 1: 700MHz
Scenario 2: 900MHz
Scenario 3: 1800MHz
Scenario 4: 700MHz + 1800MHz
Scenario 5: 900MHz + 1800MHz

Q.14.(A) Tenderer shall provide Multi-Standard Radio (MSR) solution within same frequency band in single radio hardware.
.b.
Q.14.(A) Tender with possibility of reusing / co-using existing network equipment to achieve above requirements for Single RAN, MUST identify/ remark the individual reuse
.c.
/ co-use items with its cost saving in Pricing Sheet To demonstrate Tenderers capability on cost-saving. The Tenderer shall provide Pricing Tables with and
without reusing/ co-using existing network equipment for different options.
Q.14.(A)
.d.
Q.14.(A)
.e.
Q.14.(A)
.f.

Tenderer shall provide 2x2 MIMO ready equipment (and feature 4x4 upgradable / expandable) for above re-quirement.
Tenderer shall provide UMTS RNC to support offered 900MHz-WCDMA network
Tenderer shall provide interworking / IOT service between offered 900MHz WCDMA network and shall provide interworking / IOT service between offered
900MHz WCDMA network and Buyers incumbent WCDMA system (Core and RAN if Buyer would have) and LTE system (Core and RAN) without KPI
degradation.

Q.14.(A) Tenderer shall fully utilize Buyers existing network elements in physical site to minimize the potential CapEx and provide relevant site construction work, I&C and
.g.
professional services to assure end-to-end performance.
Q.14.(A) In Phase 1-3, Buyer may consider covering site construction & civil work for site readiness based on own resource & experience.
.h.
Q.14.(A) Tenderer shall subject to TSC new spectrum acquired to provide plan adjustment and BoM modification.
.i.
Q.14.(A)
.j.
Q.14.(A)
.k.
Q.14.(A)
.l.
Q.14.(A)
.m.
Q.14.(A)
.n.
Q.14.(B)
.
Q.14.(B)
.(a).

Tenderer shall provide future expansion / upgrade plan to LTE 4x4 MIMO and 3G downlink 84Mbps base on offered single RAN / MSR base station platform.

Q.14.(B)
.(b).
Q.14.(B)
.(c).
Q.14.(B)
.(d).
Q.14.(B)
.(e).

Tenderer shall provide End-to-End Turn-key I&C and all professional services if proposed to Swap existing U2100 Network.

Q.14.(B)
.(f).
Q.14.(B)
.(g).
Q.14.(C)
.
Q.14.(D)
.
Q.14.(E)
.
Q.14.(F)
.
Q.14.(G)
.
Q.14.(H)
.
Q.14.(I).

Tenderer shall provide future expansion / upgrade plan for 3G Downlink 84Mbps based on offered single RAN /MSR base station platform

RF bandwidth: 15MHz per sector

MIMO 2X2(20W+20W) per sector
Throughput 150/50(DL/UL) per eNB
50 active users per eNB
RAN Option 2
Tenderer shall provide Single RAN solution for offered 2100MHz WCDMA network and also shall provide Single RAN solution together with offered for option 1 in
same area. (WCDMA 2100MHz network: swap 2000 sites and 2000 new sites)

Tenderer shall provide Swap service without any additional cost to Buyer for offered 2100MHz WCDMA network.
Tenderer shall provide 2x2 MIMO ready equipment (and feature 4x4 upgradable / expandable) for above re-quirements.
Tenderer shall provide interworking / IOT service between offered 2100MHz WCDMA network and Buyers in-cumbent WCDMA system (Core and RAN) and LTE
system (Core and RAN) without KPI degradation

Tenderer shall provide WCDMA multi-band multi-carrier feature for 900MHz and 2100MHz
Main Software pack and optional features in every element node
Operation, Administration and Maintenance (OAM) or Element Management System (EMS)
Test UE device and planning / testing tools
IOT / MVI
LTE / UMTS Lab Setup
Warranty & Maintenance
Training
(Note: All aforementioned deliverables will be based on end-to-end scope / solution that Tenderer plans to offer Buyer to fulfill all RFP requirements)

9.5.

LTE E-UTRAN

Q.15

Tenderer shall complete the eNodeB Technical Requirements included in Attachment 2: LTE& UMTS feature list and feature roadmap

Q.16

Tenderer shall provide eNodeB which support MSR technology for UMTS / LTE and comply with 3GPP TS37.104, TS37.113, TS37.141, TS37.900 standards.

Q.17

Tenderer shall provide without cost in Buyers Lab regarding your Base-Band Unit and Radio Unit to support Multi Radio Access Technology platform (i.e. UMTS,
LTE) in single platform in Buyer designated frequency band (ex 700MHz, 900MHz, 1800MHz, and 2100MHz)

Q.18

Tenderer shall provide eNodeB which comply with 3GPP TS36.104 and TS36.141 Base Station associated re-quirements.

Q.19

Tenderer shall describe all distributed eNodeB types

Q.20

Tenderer shall provide full E-UTRAN roadmap for all products family including eNodeB types and the related Baseband Unit (BU) and Radio Unit (RU) board
information.

Q.21

Tenderer shall detail your eNodeB hardware expansion paths and software capacity upgrade possibilities

Q.22

Tenderer shall describe all outdoor eNodeB types

Q.23

Tenderer shall describe all indoor eNodeB types

Q.24

Tenderer shall detail your Hardware functionality and the Software release for a full working MSR radio module.

Q.25

Tender shall detail the specification and limitation of your Multi Carrier Power Amplifier (MCPA) in eNodeB as below:

Q.25.A. MCPA IBW (Instantaneous Bandwidth, i.e. how much Bandwidth does the RU support)
Q.25.B. MCPA IBW shall support CA scenarios
Q.25.C. What IBW is supported when running mixed Multi-RAT configuration?
Q.25.D. For MCPA nominal output power, if it is used for one carrier or multi-carrier configuration?
Q.25.E. MCPA aging marginal, filter loss compensation marginal, temperature drift marginal and power saturation shall be taken into consideration in the design.
Q.25.F.

Please state if the MCPA has a power back off when 64 QAM modulation is used?

9.5.1.

eNode B Architecture

Q.26

Tenderer shall provide the full range of eNodeB equipment include Macro / Micro / Small Cell and Distributed eNodeB solutions

Q.27

Tenderer shall detail if your offering includes a Module-Based eNodeB against a Cabinet-Based architecture. Tenderer shall describe on detailed module
architecture and its specific benefits.

Q.28

The hardware modules / unites offered by Tenderer shall support all site installation and physical requirements such as indoor / outdoor / wall-mount / pole /
cabinet / feeder less and distributed type.

Q.29

Tenderer shall support eNodeB RF Hardware that can freely applied and upgraded from 1xTX SIMO to MIMO 2x2. Please provide the capacity upgrade
description from basic SIMO to 2x2 and 4x4 MIMO

Q.30

Tenderer shall offer eNodeB configurations based on distributed architecture, comprised Baseband Unit (BBU) and a software-defined remote radio unit (RRU)

Q.31

The eNodeB shall support Common Public Radio Interface (CPRI) or OBASI(Open BaseStation Architecture Initiative) for interfacing the BBU with the RRU

Q.32

Tenderer shall detail the Max. power of each frequency band for new model and MSR ready RRU and Macro eNodeB

Q.33

Tender shall detail the functionality and technical specification of all sub- components for each available eNodeB models presented.

Q.34

Tenderer shall state the maximum distance supported between RRU and BBU

Q.35

The eNodeB shall support indoor and outdoor deployment for both the BBU and RRU.

Q.36

The eNodeB shall support from one up to nine sectors per site

Q.37

The eNodeB shall support 32 external alarms

Q.38

The eNodeB shall support a software reboot time of less than 2 minutes 30 seconds

Q.39

The eNodeB shall support an outage during software upgrade of less than 2 minutes 30 seconds

Q.40

Tenderer shall specify circuit breaker capacity required for outdoor eNodeB

Q.41

Tenderer shall provide the following data for each available eNodeB type (ex. Macro / Micro / Small cell and Distributed eNodeB) listed as shown below

Q.41.A. PA output power

Q.41.B. Nominal Power at BTS antenna connector
Q.41.C. Number of PAs in one RF unit
Q.41.D. Size and weight of unit
Q.41.E. Power consumption per sector / carrier
Q.42

The offered eNodeB by Tenderer shall deploy natural cooling mechanism instead of fan in the cabinet.

Q.43

The offered eNodeB by Tenderer shall deploy power saving feature for green power application

Q.43.A. Adaptive Power Consumption

Q.43.B. Low Power Consumption Mode
Q.43.C. Power Consumption Monitoring
9.5.2.

Remote Radio Unit (RRU) Requirements

Q.44

The RRU module shall support following installation options:

Q.44.A. Installed in a shelter

Q.44.B. Installed on a pole
Q.44.C. Outdoor installation at the base of the tower
Q.44.D. Installation on the tower masts / platforms in close proximity to the antennas.
Q.45

The RRU shall support QPSK modulation.

Q.46

The RRU shall support 16-QAM modulation

Q.47

The RRU shall support 64-QAM modulation

Q.48

Tenderer shall state the maximum instantaneous bandwidth supported by offered RRU

Q.49

Vender shall state the maximum output power level in watts per MIMO branch at the antenna connector of the RRU

Q.50

The RRU output power per MIMO branch shall be software configurable in steps of 0.1dB

Q.51

The RRU shall support adaptive 2x2 MIMO on the DL

Q.52

Tenderer shall specify the RRU physical interfaces supported and the connector types

Q.53

Tenderer shall state the receiver noise figure of the offered RRU.

Q.54

Tenderer shall indicate the power consumption of the offered RRU.

Q.55

Tenderer shall provide the physical dimensions for the offered RRU.

Q.56

Tenderer shall indicate the weight of the offered RRU

Q.57

Tenderer shall indicate the operating temperature range for the offered RRU

Q.58

Tenderer shall indicate the protection level for the offered RRU

9.5.3.

Macro eNodeB Radio Unit Requirements

Q.59

Tenderer shall include in the offer radio modules designed to operate inside indoor or outdoor eNodeB cabinets.

Q.60

The radio unit shall support QPSK modulation.

Q.61

The radio unit shall support 16-QAM modulation.

Q.62

The radio unit shall support 64-QAM modulation

Q.63

Tenderer shall state the maximum instantaneous bandwidth supported by offered modules.

Q.64

The offered module shall support adaptive 2x2 MIMO on the DL.

Q.65

Tenderer shall state the maximum output power level in watts per MIMO branch at the antenna connector of the offered modules.

Q.66

The RF module output power per MIMO branch shall be software configurable in steps of 01.dB.

9.5.4.

Configuration Requirement

Q.67

The offered eNodeB shall support initial low capacity, large area coverage situation with a clearly defined up-grade path for higher capacity solutions.

Q.68

Tenderer shall provide a general description of max. eNodeB configuration can contain, but not limited to below subjects:

Q.68.A. Description of minimum and maximum configuration of each available eNodeB models
Q.68.B. The Number of sectors per eNodeB (Omni site, 2 sector site, 3 sectors site, 6 sectors site)
Q.68.C. The number of eNodeB modules that can be cascaded
Q.68.D. Maximum baseband capacity per eNodeB.
Q.69

The offered eNodeB shall be able to support Multi-technology operation of 3G and LTE simultaneously in the different configurations, fully configurable by the
Operator through software.

Q.69.A. Dedicated mode.

Q.69.B. Concurrent mode (supported by Hardware).
Q.70

Tender shall provide the eNodeB that the Carrier Frequency Bandwidth can be flexibly expand and set upon Buyers demand (i.e. from 1.4MHz ~ 20MHz)
without any license control for additional cost and any Software or Hardware upgrade required.

Q.71

The eNodeB offered by Tenderer shall be worked properly under Taiwan environment temperature without the requirement for an additional air conditioning
system and configurations in order to minimize Capital and Operational Expense.

Q.72

Tenderer shall provide the maximum optical fiber distance (in meters) between your BBU and RRU in case of distributed site solution?

9.5.5.

Frequency Bands Support

Q.73

The offered eNodeB shall support following mandatory 3GPP frequency bands.

Q.73.A. Band 3 (1800 MHZ FDD MODE) for UMTS / LTE

Q.73.B. Band 8 (900 MHz FDD MODE) for UMTS / LTE
Q.73.C. Band 28 (APT 700 FDD MODE) for LTE
Q.73.D. Band 1 (2100 MHz FDD MODE) for UMTS / LTE
9.5.6.

Software Feature Support & Roadmap

Q.74

Tenderer shall comply the eNodeB / NodeB feature requirement which defined by Buyer and listed in Attachment 2. Please fill in feature compliance in
Attachment 2: LTE& UMTS feature list and feature roadmap

Q.75

Tenderer shall provide current available (for compliance) & later release (within two years) of RAN Software and Hardware roadmap. Please fill in the product
roadmap / feature list in Attachment 2:LTE & UMTS feature and feature roadmap

Q.76

Tenderer shall comply the E-UTRAN / UTRAN Feature List defined in 3GPP R8 ~ R10. Please fill in feature compliance in Attachment 2: LTE& UMTS feature list
and feature roadmap

9.5.7.

Mobility & Handover

Q.77

The offered eNodeB shall support IRAT selection priority for LTE and UMTS broadcasted in system information. Please provide the details for IRAT Handover
based on different handover conditions or criteria.

Q.78

The offered eNodeB shall support Intra and Inter eNodeB handover with neighbor cell-specific handover pa-rameters.

Q.79

The offered eNodeB shall support neighbor cell-specific blacklists for Inter eNodeB handover

Q.80

The offered eNodeB shall support IRAT handover for UE with multiple EPS bearers by using handover param-eters per QCI. The handover shall be done when
the first EPS bearer triggers.

Q.81

The offered eNodeB shall support handover to best cell based on DL Reference Symbol Received Power (RSRP) measurements and thresholds for intrafrequency handover procedures.

Q.82

The offered eNodeB shall support handover to best cell based on DL Reference Symbol Received Quality (RSRQ) measurements and thresholds for intrafrequency handover procedures

Q.83

The offered eNodeB shall support blind handover as inter-frequency handover

Q.84

The offered eNodeB shall support gap-assisted handover measurements for inter-frequency handover.

Q.85

The offered eNodeB shall support configurable gap patterns for gap-assisted handovers.

Q.86

The offered eNodeB shall support bad coverage method based on RSRP and RSRQ with below trigger events for inter-frequency handover:

Q.86.A. Based on bad coverage

Q.86.B. Based on Load
Q.86.C. Based on Service
Q.86.D. Based on subscription (SPID information from MME)
Please specify the details and its roadmap
Q.87

Tenderer shall provide roadmap details about support for Contention-free RACH for intra-LTE handover.

Q.88

The offered eNodeB shall support Inter eNodeB handover: over S1 interface (no X2 interface between serving and target eNodeB)

Q.89

The offered eNodeB shall support Inter eNodeB handover: over X2 interface.

Q.90

The offered eNodeB shall support connection re-establishment procedure (Source eNodeB maintain context; ready for UE return; until UE confirmed on target
cell).

Q.91

The offered eNodeB shall support following types of Intra eNodeB handover:

Q.91.A. Intra frequency,

Q.91.B. Inter frequency: same band
Q.91.C. Inter frequency: different band
Please specify the detail and its roadmap
Q.92

The offered eNodeB shall support following types of Inter eNodeB handover:

Q.92.A. Intra Frequency

Q.92.B. Inter frequency: same band
Q.92.C. Inter frequency: different band
Q.92.D. Intra MME and SGW
Q.92.E. Inter MME
Q.92.F.

Inter MME and SGW

Q.92.G. Inter SGW

Please specify the details and its roadmap.
Q.93

The offered eNodeB shall support cell reselection based on:

Q.93.A. Broadcast priority indication

Q.93.B. Broadcast cell-specific reselection parameters
Q.93.C. Broadcast cell-specific blacklists
Q.93.D. Access class baring parameters

Please specify the detail and its roadmap.

Q.94

The offered eNodeB shall support inter frequency reselection priority based on:

Q.94.A. Broadcast of system information

Q.94.B. Per UE (priority signaling to UE at RRC release with validity time specified)
Please specify the details and its roadmap.
Q.95

The offered eNodeB shall support inter PLMN reselection.

Q.96

The offered eNodeB shall support GAP-assisted or Configurable GAP patterns for IRAT handover measure-ments. Please specify the details and its roadmap.

Q.97

In regards to configurable IRAT measurement and handover priority per QCI class. The offered eNodeB shall support the below scenarios:

Q.97.A. Measure on preferred RAT if the UE supports it, otherwise select the best server of used RAT
Q.98

Tenderer shall provide the details based on your roadmap about the support of build handover for IRAT using pre-configured neighbors.

Q.99

Tenderer shall detail if Blind handover without measurements be supported

Q.100

Tenderer shall detail the roadmap regarding blind IRAT handover to different RATs

Q.101

Tenderer shall detail the roadmap about the capabilities to secure efficient configuration and consistency of IRAT parameters

Q.102

Tenderer shall provide the Max. Speed (Km/Hr) that offered Base Station can support

9.5.8.

Regulatory & Standard Compliance

Q.103

The offered eNodeB MUST comply with local regulatory requirement which defined and requested by Na-tional Communications Commission (NCC)

Q.104

The offered eNodeB MUST comply with 3GPP R10, CEPT, EC, CE, UL specifications.

Q.105

Tenderer shall declare which global standards that eNodeB compliance to. The list shall include but not limited to: 3GPP, ETSI, IEC, ISO, EMC, etc.

Q.106

The offered eNodeB shall comply with IP outdoor water Ingress protection standard.

Q.107

Tenderer shall provide a specific declaration that all aspects of conformity assessment and documentation to achieve CE Conformity making have been, or shall
be achieved, before product is delivered to Buyer for test purposes.

9.5.9.

Capacity and Performance

Q.108

Tenderer shall provide the details of Max. VoIP capacity / Concurrent PS user / cell Aggregate Throughput . Furthermore, Tenderer shall provide the assumption
and methodology on how these Max. Capacity number had been calculated.

Q.109

Tenderer shall provide the reference of network KPI that offered E-UTRAN software & Hardware can achieve.

Q.110

Tenderer shall comply with 3GPP TR36.913 requirement in spectrum efficiency and cell edge user throughput.

9.5.10.

Installation Requirement

Q.111

The eNodeB shall support Remote Electrical Tilting (RET) Antenna System which complies with 3GPP interface specifications TS25.460, TS25.461, TS25.462,
and TS25.466. The Antenna tilting can be remotely adjusted in centralized EMS via BTS transmission.

Q.112

The eNodeB shall support Tower Mounted Amplifier (TMA) which complies with 3GPP specification of TS25.466

Q.113

For each hardware component, please specify in co-located sites which inter-working scenarios would be possible for new LTE equipment and existed UMTS
equipment(if TSC would have)?

Q.113.A
.
Q.113.B
.
Q.113.C
.
Q.113.D
.
Q.113.E
.
Q.114

Is it possible to share low noise Tower Mounted / Mast-head Amplifiers (TMAs)?

Is it possible to share Power Supply components?
Is it possible to share RF feeders and Antenna?
Is it possible to share physical transport interfaces?
Is it possible to share any other items?
Tenderer shall provide test equipment to measurement the engineering quality of site working during installation / optimization then guarantee the defined KPI
performance

Q.115

Tenderer shall provide following RAN characteristics and specification, nothing variations across various models in eNodeB / NodeB portfolio.

Q.115.A
.
Q.115.B
.
Q.115.C
.
Q.115.D
.
Q.115.E
.

Height
Width
Depth
Free access space required for different cabinet scenarios
Weight
Total weight, fully configured
Per Cabinet
For each range of battery backup capacity offered
For main-remote state the weight of its individual main components

Q.116

Tenderer shall state clearly your eNodeB backhaul connectivity options.

9.5.11.

eNodeB Backhaul Requirement

Q.117

Tenderer shall detail proposed solutions of backhaul and transport capabilities across different eNodeB portfolio.

Q.118

Tenderer shall provide the roadmap for eUTRAN Transport feature / functions

Q.119

Tenderer shall provide the transport solution for an eNodeB co-sited with UMTS Base Station considering a mixed IP & ATM connection and a pure IP connection
.

Q.120

Tenderer shall detail what physical interfaces for X2/S1 and O&M does the eNodeB provide?

Q.121

The offered eNodeB shall support Native Ethernet in eNodeB.

Q.122

The offered eNodeB shall support IPv4 and be hardware-prepared for IPv6 for all traffic interfaces in eNodeB. Tenderer shall provide the solution and
considerations to support the transition of IPv4 to IPv6 in the future.

Q.123
Q.124

Tenderer shall detail how your E-UTRAN support IPv6 on IP (X2, S1) interface in which Software Release?
The offered eNodeB shall support Gigabit Ethernet Optical and/or Electrical port in eNodeB

Q.125

Tenderer shall detail the number and type of communications ports available for local Q&M connectivity.

Q.126

The offered eNodeB shall support traffic separation between Signaling & Data flow.

Q.127

The offered eNodeB shall support Quality of Service (QoS) on the IP respective Ethernet layer for all eNodeB traffic in eNodeB; this shall be described in detail.

Q.128

The offered eNodeB shall IPsec and IKEv2 for the traffic according to the 3GPP specification in eNodeB.

Q.129

Tenderer shall detail the support for Call Admission control to manage backhaul limited traffic conditions.

Q.130

Tenderer shall detail the standards supported for the eNodeB transport solution

Q.131

Tenderer shall detail the requirements on the backhaul from an X2 interface connectivity and characteristics perspective.

Q.132

Tenderer shall detail the synchronization solutions supported by the eNodeB for LTE FDD.

Q.133

Tenderer shall detail the O&M system that monitors the real-time IP traffic measurements.

Q.134

Tenderer shall detail the maximum number of Transmission interfaces that an eNodeB can support?

Q.135

Tenderer shall detail the transport QoS handing in eNodeB

Q.136

Tenderer shall detail how the traffic classification with making and QoS enforcement work in eNodeB via S1 and X2 interfaces. If it could be mapping and
configurable via OA&M?

Q.137

Tenderer shall detail if eNodeB S1 and X2 scheduler support different QoS categories as specified in 3GPP standards? If your eNodeB support queuing and
forwarding using priority information?

Q.138

If your eNodeBs S1 and X2 interface support traffic shaping taking into account end-toend delay budget?

Q.139

Tenderer shall detail the maximum and minimum downstream / upstream peak bandwidth support on eNodeB S1 and X2 interfaces.

Q.140

If your eNodeB supports IP header compression and payload compression in order to improve bandwidth efficiency? (Note: it is not RoHC for VoIP header that is
meant)

Q.141

If your eNodeB performs admission control based on current availability and performance of transport backhaul resources?

Q.142

Tenderer shall detail the redundancy mechanisms available on S1/X2 link failures

Q.143

Tender shall detail the maximum number of GigE, optical, electrical ports available on S1/X2 links of the eNodeB?

9.5.12.

Physical & Environmental Requirement

9.5.12.1. General Requirement

Q.144

Tenderer shall state if your eNodeB is fully, partially or not comply with 3GPP TS36.104 and TS36.141

Q.145

Tenderer shall provide a full roadmap for all your commercially available radio products, including all eNodeB types and associated sub-unit products (i.e. RRU,
BBU etc), frequency bands and bandwidth, antennas, tower mounted amplifiers, external power / battery backup solutions, RET products etc.

Q.146

Tenderer shall provide an overview description of the eNodeB portfolio, including current /future commercial deployments.

9.5.12.2. Power Consumption and Energy Savings

Q.147

Tenderer shall detail power supply input for each eNodeB type.

Q.148

Tenderer shall indicate if your equipment can be powered with 24V or -48VDC power source without the use of an external AC/DC converter.

Q.149

Tenderer shall state the power consumption for different eNodeB types under different RF load conditions including both typical and maximum values. Please
also indicate conditions assumed for typical consumption, including transmit power levels, carrier bandwidths, operating spectrum, ambient temperature, or other
factors with significant impact on power consumption.

Q.150

Tenderer shall state the eNodeB battery backup solution for each eNodeB type.

Q.151

Tenderer shall indicate if there is power management software to provide energy saving.

Q.152

The maximum radio configuration (radio and baseband units) in an eNodeB cabinet shall not limit by the power supply type (e.g. if is 24V DC or -48V DC) or
battery configuration (half or full equipped) in the same eNodeB cabinet.

9.5.12.3. Environmental Conditions

The eNodeB shall conform to the Environmental Standards, Directive and Electromagnetic Compatibility (EMC) listed below:
Q.153

Storage Requirements Compliance:

For indoor eNodeB equipment:

Q.153.A ETS class 1.2 weather Protected, Not Temperature Controlled Storage Locations in ETS 300 019-1-1
.
Q.153.B The indoor NodeB shall comply with ETS class 2.3 Public Transportation in ETS 300 019-1-2
.
For outdoor eNodeB equipment:
Q.153.(
B).A.

The outdoor eNodeB shall comply with ETS class 1.2 Weather Protected, Not Temperature Controlled Storage Location in ETS 300 019-1-1 and ETS class 2.3
Public Transportation in ETS 300 019-1-2

Q.153.(
B).B.

The outdoor eNodeB shall be compliant with ETS class 4.1E (extended to 45 C). Non Weather Protected Locations as follows: ETS 300 019-1-4 & IEC/EN 60
721-3-4

Q.154

Product Buyer the Compliance of Standard:

Q.154.A
.
Q.154.B
.
Q.154.C
.
Q.154.D
.
Q.154.E
.
Q.154.F.

EU Directives: 73/23/EEC Low Voltage Directive

Q.155

The eNodeB shall conform to the following standards IEC/EN 60 068-2-57 on earthquake protection.

Q.156

The vibration resistance vs. Specification are shown as below:

Q.156.A
.
Q.156.B
.
Q.156.C
.
Q.156.D
.
Q.157

Normal operation: Max. 0.02 m2/s3

Q.158

Acoustic Noise Requirements (maximum sound pressure level): the measurement method is according to EN ISO 11201, at a bystander position one meter from
the cabinet in a free field at a room temperature of 25C SHALL NOT exceeed 54dB.

Code of Federal Regulation 21 CFR 1040.10 and 1040.11

EN 60 950-1/EC 60.950-1:2001 and IEC 60 950:1999
EN 60 215/IEC 60 215:1987
ANSI/UL 60 950-1/CSA C22.2 No. 60 950-1-03
IEC 60 825-1/EN 60 825-1

Exceptional operation Max. 0.08 m2/s3

Non-destructive Max. 0.15 m2/s3
Shock Max. 30 m/s2
Ingress Protection Rating, IP55 requirements according to the standard IEC/EN 60 529

9.5.12.4. SmallCell and HeNet Support

Q.159

Tenderer shall support different types of SmallCell base-station such as Micro, Pico, and FemtoCell.

Q.160

Tenderer shall provide the SamllCell product and detail how to integrate with MarcoCells.

Q.161

Tenderer shall provide the value propositions of SmallCell

Q.162

Tenderer shall detail your 3GPP HeNet solution and product plan which contains Network Architecture, HeNB Gateway and HeNB Base Station. (refer to 3GPP
TS36.921)

Q.163

Tenderer shall detail describe HeNB, HeNB GW, SeGW functionality

Q.164

Tenderer shall detail describe the HeNB requirement as below but not limit to

Q.164.A
.
Q.164.B
.
Q.164.C
.
Q.164.D
.
Q.164.E
.

Connectivity interface requirement (such as: LTE-Uu, S1-MME, S11, S6a, C1 and so on)
Mobility management (TAI assignment, connected mode, Idle mode and so on)
Service and emergency service
SON / SCN requirement
LIPA (Local IP access) / SIPTO (Selected IP Traffic offload) requirement

Q.164.F. Radio access control

Q.164.G FDD radio transmission and reception (3GPP 36.104 36.141)
.
Q.164.H CSG List (closed subscriber group)
.
Q.164.I. QoS
Q.164.J. Security Gateway architecture
Q.164.K QAM requirement, CM, PM, FM, SM
.
Q.165
Tenderer shall provide the SamllCell backhaul solution including xDSL, microwave, but not limit wire and wireless backhaul.
Q.166

Tenderer shall provide the SamllCell backhaul security solution (including IP attack, Hiker or environment security)

Q.167

Tenderer shall do IOT between existing UMTS / LTE network and 3rd party equipment (e.g. Other vendors HeNB, or SmallCell Gateway) in live network

Q.168

Tenderers SmallCell solution shall comply Lawful Interception for System Inspection to CIB if needed.

9.5.13.

Carrier Aggregation (CA)

Q.169

Tenderer shall detail the mechanism how your Software or Product CA.

Q.170

Tenderer shall provide the supported Frequency Band Combination and Bandwidth Combination for CA in recommended Software version and later Software
release (within two years)

Q.171

Tenderer shall comply the CA band & bandwidth options stated in TS36.104 / 36.101 / 36.307 / 36.141

Q.172

Tenderer shall provide the reference document of latest confirmed / studied frequency band and BW com-bination in 3GPP

Q.173

Tenderer shall provide eNodeB support both CA and Non-CA UE working properly in the Buyers network. The terminal with CA capability (ex. Category 6) can
support max. downlink / uplink throughput to

Q.174

To meet current Taiwan 4G Frequency bands, Tenderer shall comply the CA of:

Q.174.A Intra-Band: (Bandwidth combination from 5+5MHz up to max. 20+20MHz)

.
Band 3 (1800MHz FDD mode) for UMTS or LTE
Band 8 (900MHz FDD mode) for UMTS or LTE
Band 28 ( APT700MHz FDD mode) for LTE
Band 1 (2100MHz FDD mode) for UMTS or LTE
Q.174.B Inter-Band: (BW combination from min. 5+5MHz to Max. 20+20MHz)
.
Band 3 + 28 for LTE
Band 3 + 8 for UMTS or LTE
Band 8 + 28 for LTE
Band 1 + 8 for UMTS + UMTS or LTE + LTE
Band 1 + 3 for UMTS or LTE
Band 1 + 28 for LTE
9.5.14.

Antenna Requirement & Solution

Q.175

Tenderer shall offer an antenna system including antenna / RET / Remote Control Unit / TMA (optional) / Antenna Control & Monitor System.

Q.176

Tenderer shall offer the antenna system engineering included RF feeder / duplex / Biastie / optical fiber etc. site work.

Q.177

Tenderer shall provide the global reference regarding the type, usage and site-work of Disguised Antenna.

Q.178

Tenderer shall provide the recommended various types of antenna for different applicable scenarios for implementing. These antennas shall pass the certification
test in Global or NCC authorized lab.

Q.179

All antennas and TMA must comply with TSC RAN-OSS AISG 2.0 operation and backward compatibility with AISG1.1 provide with IOT pass evidence for
reference.
Tenderer shall detail how to use the multiple antenna technologies (i.e. open or closed loop MIMO or Beam-forming). The roadmap shall include but not be limited
to the number of antennas and transmission schemes supported. The transmission schemes shall include 3GPP defined transmission mode (TM)

9.5.15.

Network Synchronization

Q.180

Tenderer shall detail eNodeB synchronization concept in an all-IP network. The Synchronization using GPS or Galileo (or both) shall be supported.

Q.181

The offered eNodeB shall support the NTP synchronization over IP and IEEE 1588v2 in eNodeB

Q.182

The offered eNodeB shall support synchronization via external interface in eNodeB

Q.183

If multiple methods for synchronization are supported, please comment on which is recommended and why.

Q.184

Tenderer shall detail all types of synchronization mechanisms supported by eNodeB. Tenderer shall detail the holdover time supported after loss of external timing
signal or internal synchronization from other network element nodes.

9.5.16.

Miscellaneous Requirements

Q.185

Tenderer shall provide the MTBF (Mean Time Between Failure) of all offered E-UTRAN products.

Q.186

Tenderer shall provide the timeframe of product EOS (End of Support) and EOL (End of Life)

Q.187

Tenderer shall list recommended Product Maintenance Schedule of every eNodeB elements, the service duration & impacts during replacement and any
Professional Service can be provided by Tenderer.

Q.188

Tenderer shall identify redundant elements and type such 1+1, N+1, and detail resource pooling for each element node. If service interruption will be occurred
during failover, please provide the service interruption time.

Q.189

Tenderer shall provide the network Prevention & Recovery mechanism / plan for potential Network Outage.

9.6.

E-UTRAN / UTRAN Features

Q.190

Tenderer shall comply with the features defined in 3GPP R10 (Backward compatible to R9, R8 and UMTS) and Buyers feature request list. This compliance will
be included LTE E-UTRAN and UMTS UTRAN. Please Tenderer fill in the E-UTRAN / UTRAN Feature Compliance following the template requested in the corresponding table.

Q.191

Tenderer shall provide your Compliance Table with latest version or future supported roadmap which map-ping to 3GPP (R8, R9 and R10) standard.

Q.192

All the complied features and specification responded in corresponding table would be deemed as the overall offering in this Tender without any additional
compensation or license control on the capacity or usage.

9.7.

UMTS UTRAN

Q.193

Tenderer should provide latest version UTRAN with all feature and hardware needed to meet the following requirement.

Q.193.A
.
Q.193.B
.
Q.193.C
.
Q.193.D
.
Q.193.E
.
Q.193.F.

HSDPA+ DC
MIMO 84M
Provide Maximus Channel element (more than 1500 channel element per node B)
3 separate scheduler(Each separated package schedule for each sector, without reduce the HSDPA+ coding channel elements)
HSDPA: 21M x 3 sectors (2 carriers) & 72 users
HSUPA: 5.8Mbps x 3 sectors (2 carriers) & 72 users

Q.193.G R99: 30 user per BTS

.
Q.194
The major technical requirement for UMTS UTRAN UTRAN node, RNC and OAM.
Q.195

Tenderer shall provide either brand-new Multi-Standard Radio (MSR) Single RAN platform, which can ac-commodate Multi-RAT (ex. LTE-Advanced / UMTS ),
Multi-Band (ex. 700 / 900 / 1800 / 2100 MHz) requirement and future demands. The 3G BTS controller (i.e. RNC which support coming 3 years RAN traffic
demand) shall be also included in the scope to integrate to Buyers potential would have WCDMA Core Network.

Q.196

Tenderer shall provide a solution proposal to detail how your UMTS UTRAN to co-locate with TSC 3G equipment and sharing with existing antennas and feeders.
Please provide the cabling plot from NodeB module to Antenna side to support Multi-RAT and antenna sharing.

Q.197

Tenderer could add-on diplexer / combiner for antenna sharing but shall take full responsibility of all cabling to ensure the network performance. (Note: Buyer can
provide existing antenna specification sheet to Tenderer by demand for reference)

Q.198

Tenderer shall detail if your Base-Band Unit support Software Define Radio (SDR) which can apply same hardware with only software change to support different
RAT combination.

Q.199

Tenderer if awarded Buyers MSR RAN contract shall provide all initial tuning, frequency re-planning and optimization service for offered Access Technology (i.e.
UMTS and LTE) to ensure end-to-end KPI performance.

9.8.

Reuse of Existing Network Equipment

Q.200

Tenderer shall fully utilize existing facility to reuse or expand the modules in existing racks and site engi-neering.

Q.201

Tenderer shall provide the proposal and RF performance impact evaluation for all reused & upgradable re-source (e.g. Base Station, Transport Router, Antenna,
Feeder / Jumper / Duplex) in existing site (if Buyer would have exist sites). (Note: Buyer reserves the right to determine which element to allow Tenderer to
reuse or not)

Q.202

Tenderer shall support maximum re-use of the existing equipment to demonstrate your advantage in terms of cost, space and energy saving.

Q.203

Tenderer shall propose a solution / migration proposal to deal or handle Buyers existing U2100 Network with your offered MSR platform

9.9.

Self Organizing Network (SON)

9.9.1.

General Requirement

Q.204

Tenderer shall comply 3GPP SON requirement and detailed explain each of SON features (including: monitor counters, change parameters, flow, etc.)

Q.205

Tenderer shall comply 3GPP (TS32.500, TS32.501, TS35.502, TS32.503, TS32.521, TS35.522, TS32.526, TS32.541, and TS36.902)

Q.206

Tenderer shall reply the detail action / reaction time / work flow of each of SON function

Q.207

Tenderer shall provide the detailed multi-RAT SON solution description to integrate with Buyers WCDMA / LTE system.

Q.208

Tenderer shall provide the SON solution, but not limit standard such as ANR (Automatic Neighbor Relation), MLB (Inter RAT / Inter and intra frequency Mobility
load balance), MRO (Mobility Robustness Optimization), Inter-RAT MLB Multiple Cell load report, Inter-RAT unnecessary handover report, Automatic TA (Tracking
area), Automatic PCI (Physical C. II ID) configuration, Automatic SC (Scrambling Code) configuration, RACH Optimization, eICIC (Enhanced Inter Cell Interference
Coordination), CCO (Capacity and Coverage Optimization), CODC (Cell Outage Detecting and Compensation), Cell Supervision, Energy Savings

Q.209

Tender SON solution shall be able to address to Coverage, Capacity and Quality in combined manner al-lowing Buyer to select and set policy / weighting which
area they would like to focus on.

Q.210

Tenderer offered SON solutions shall be aligned / upgraded with future SW version of all buyers mul-ti-vendor mobile system.

9.9.2.

Self-Configuration (ANR)

Q.211

Tenderer shall comply 3GPP TS32.501 Self Establishment of new eNodeB

Q.212

Tenderer shall comply 3GPP TS32.511 Automatic Neighbor Relation Management

Q.213

The offered ANR function shall support to implement SON Automatic Neighbor Relation for LTE , UMTS

Q.214

A SON feature shall have the capability to detect the HO failures, identify the reason / impact on overall network performance and take remedial actions.

Q.215

Tenderer shall provide an algorithm controlled automated SON function which optimized QoS related pa-rameters (ex. QCI) at each node.

Q.216

Tenderer shall detail how your SON algorithms workable for the following key maintenance mechanisms:

Q.216.A
.
Q.216.B
.
Q.216.C
.
Q.216.D
.

Self software upgrade

Service verification after upgrade
Customized upgrade policy, ex: for use MML (Man-Machine Language) commands or GUI and so on.
Automatic rollback to previous software version

Q.216.E Automatic Inventory

.
Q.216.F. Subscriber and equipment trace
Q.216.G Support antenna fault detection
.
Q.216.H Real-time Performance Management and Reporting
.
Q.216.I. Indicate how SON support for Minimum Drive Test
Q.217

Tenderer shall detail their implementation for ICIC (or enhanced ICIC) and 2 years roadmap to support Adaptive ICIC (Inter-Cell Interference Coordination), which
can further improve inter-cell interference cancellation performance and improve cell edge throughput.

9.9.3.

Self-Optimization (MLB / MRO / CCO)

Q.218

Tenderer shall comply 3GPP TS32.521 Self-Optimization

Q.219

Tenderer shall detail your Mobility Load Balancing (MLB), Mobility Robustness Optimization (MRO), Coverage and Capacity Optimization (CCO) and other
related Self-Optimization feature solution and roadmap

Q.220

Tenderer shall detail the related counters / parameters and methodology of MLB, MRO, COO

Q.221

Tenderer shall detail MLB work flow and train buyer how to use this feature, but not limit to for example: IRAT.

Q.222

Tenderer shall provide the recommended value for different area of MLB, MRO, CCO

Q.223

Tenderer shall train buyer to operate the MLB, MRO, COO and help buyer to optimize the network

Q.224

Tenderer shall detail MRO work flow and train buyer how to use this feature, but not limit to for example: IRAT.

Q.225

Tenderer shall detail COO work flow and train buyer how to use this feature, but not limit to for example: IRAT.

9.9.4.

Self-Healing (Minimization of drive tests MDT)

Q.226

Tenderer shall comply the 3GPP TS32.541 Self-Healing

Q.227

Tenderer shall detail how to automatically detect and remove failures and automatic adjustment of parameters

Q.228

Tenderer shall detail how automatic correction of capacity problem depending on slowly changing environment, like seasonal variations.

Q.229

Tenderer shall explain how to minimize the drive test effort of buyer.

9.10.

Network Planning & Optimization

9.10.1.

General Requirement

Q.230

Tenderer shall provide the detailed network planning & optimization guideline and service to Buyer (including IRAT & HeNet, existing Network, etc.)

Q.231

Tenderer shall detail the methodology and tool for network planning and optimization

Q.232

Tenderer shall introduce and train buyer how to plan, dimension and optimize the network

Q.233

Tenderer shall provide the site naming rule suggestion and PCI, Tracking Area, Neighboring planning suggestion

Q.234

Tenderer shall provide the methodology on how to plan / dimension a dual over-layer network with two fre-quency bands (e.g. possible high frequency band plus
how low frequency band)

9.10.2.

Network Scope

Q.235

Here the Network means Buyers new LTE network and existing 3G migration Network (also including IRAT, HetNet and WiFi)

Q.236

Tenderer shall plan and optimize Buyers network to achieve the KPIs requested by Buyer

Q.237

Tenderer shall base on below frequency optional scenarios to come out the simulation result for the total base station required to fulfill the Taiwan island-wide
99% population coverage.

Q.237.A LTE 700MHz (10 / 15 / 20 MHz): Provide MSR eNodeB to support including LTE at 700MHz with up to 20MHz bandwidth.
.
Q.237.B LTE 1800MHz (10 / 15 / 20 MHz): Provide MSR eNodeB to support including LTE at 1800MHz with up to 20MHz bandwidth
.

Q.237.C LTE 900MHz or U900MHz (10 / 15 /20 MHz): Provide MSR eNodeB to support including LTE & UMTS at 900MHz with up to 20 MHz bandwidth
.
Q.238
Tenderer shall base on Buyers assumption a below to come out simulation result in different frequency band scenarios to fulfill Taiwan island-wide 99%
population coverage.

Note: Above assumption is for Taiwan island-wide simulation purpose (i.e. to get total required BTS Qty), which is not associated with the BTS quantity, provided
in Ch.9.4
9.10.3.

Network Coverage & Capacity Dimensioning

9.10.3.1. Coverage Dimensioning

9.10.3.1. Area & Population Coverage Target
1.
Q.239
Tenderer shall provide recommended Area & Population Coverage Percentage Target based on global reference
Q.240

Tenderer shall run the simulation to get the actual and target Area & Population Coverage Percentage based on buyers requirement (i.e. 99% Population
Coverage Percentage)

Q.241

Tenderer shall provide the simulation assumption and parameters for reference and further inspection.

Q.242

Tenderer shall prove the simulation accuracy of final output result

Q.243

Tenderer shall help buyer to run the simulation result based on NCC requirement stated in 4G auction reg-ulation

9.10.3.1. Link Budget

2.
Q.244

Tenderer shall provide the link budget tool to buyer

Q.245

Tenderer shall provide the Downlink / Uplink link budget table to buyer

Q.246

Tenderer shall provide the training and reference value to explain buyer how to use your Link Budget tool.

Q.247

Tenderer shall prove the accuracy of link budget result

Q.248

Tenderer shall provide the accurate Propagation Model (i.e. K Parameters) to buyer that is fully verified with model tuning in Taiwan.

9.10.3.1. Cell Radius

3.
Q.249
Tenderer shall provide the calculation of cell radius based on buyer requirement (such as different band, different channel bandwidth)
9.10.3.1. Simulation Result (for whole Taiwan)
4.

Q.250

Tenderer shall provide the simulation result based on buyer requirement (whole Taiwan, different band, dif-ferent bandwidth, different scenario, Coverage and
Capacity sites)

Q.251
Tenderer Dimensioning
shall provide the simulation print-out plots based on buyer requirement
9.10.3.2.
Capacity
9.10.3.2. Traffic & Subscriber Demand
1.
Q.252
Tenderer shall provide buyer capacity dimensioning guideline and case study based on buyer requirement
Q.253

Tenderer shall provide the global traffic and subscriber forecast reference by 2020.

Q.254

Tenderer shall provide the global per user data user (Mbps) by device type 2020 for reference.

9.10.3.2. Cell Capacity

2.
Q.255
Tenderer shall provide the reference of Cell Capacity.
Q.256

Tenderer shall provide the simulation assumption and result to prove the cell capacity in different condition which based on buyer requirement

9.10.3.2. Spectrum Efficiency

3.
Q.257
Tenderer shall provide the definition and formula of Downlink and Uplink spectrum efficiency.
Q.258

Tenderer shall provide the spectrum efficiency in different channel bandwidth (1.4MHz ~ 20MHz)

Q.259

Tenderer shall provide the spectrum efficiency comparison among different RATs (including but not limit to: LTE-TDD, LTE-FDD, HSPA+, EV-DO, 802.16m /
WIMAX2, UMTS) for reference.

Q.260

Tenderer shall fill in the average spectrum efficiency

9.10.3.2. Required Capacity Sites

4.
Q.261
Tenderer shall provide the Multi-RAT planning methodology to integrate the CS / PS traffic demand across different RAT (LTE / UMTS / WiFi) network
Q.262

Tenderer shall provide the overall capacity simulation result across LTE / UMTS / WiFi network based on buyer requirement

Q.263

Tenderer shall consider if the traffic offload (or upload) to (from) UMTS in the capacity dimensioning result

Q.264

Tenderer shall consider if the traffic offload to WiFi in the capacity dimensioning result

Q.265

Tenderer shall provide the total quantity of capacity site counts in very district

9.10.3.3. Overall Network Dimension Result

Q.266

Tenderer shall provide the overall network dimension result based on buyer requirement

Q.267

Tenderer shall explain and provide the overall network dimensioning report and output to buyer

9.10.4.

Frequency Planning & Strategy

Q.268

Tenderer shall provide the frequency planning and strategy based on buyer requirement

Q.269

Tenderer shall provide the result and report of frequency planning and strategy

Q.270

Tenderer shall explain and compare the pro and con of different frequency reuse scenarios.

9.10.5.

Interference & Guard-Band Consideration

Q.271

Tenderer shall take full responsibility to support buyer to resolve potential interference issues.

Q.272

Tenderer shall provide the interference study reference (ex. Standard or research / field test report) of & Guard-Band suggestion to buyer

Q.273

Tenderer shall provide the minimized Guard band solution of all products (not limit Marco / Micro / Pico between technology (U+L))

9.10.5.1. 700MHz Band

Q.274

Tenderer shall take full responsibility to support buyer to resolve potential interference issues.

Q.275

Tenderer shall provide the 700MHz interference test report or reference between LTE and other wireless technologies (ex. DTV/Low PWR transmitter to LTE but
not limited to) and provide corresponding suggestion for Guard band.

Q.276

Tenderer shall provide the latest global APT-700MHz license release, BTS/UE readiness and operator im-plementation reference

9.10.5.2. 900MHz Band

Q.277

Tenderer shall provide the Guard-Band reference and suggestion for potential 900MHz interference.

Q.278

Tenderer shall provide the 900Mhz interference test report or reference between LTE and other wireless technologies (ex. GSM / UMTS / WCDMA to LTE but not
limited to) and provide corresponding suggestion for Guard band.

9.10.5.3. 1800MHz Band (GSM / UMTS vs. LTE)

Q.279

Tenderer shall provide the Guard-band reference and suggestion for potential 1800MHz interference.

Q.280

Tenderer shall provide the 1800MHz interference test report or reference between LTE and other wireless technologies (ex. GSM / UMTS to LTE but not limited
to) and provide corresponding suggestion for Guard band.

9.10.6.

ICIC & EICIC

Q.281

Tenderer shall detail your ICIC & enhanced ICIC solution and roadmap

Q.282

Tenderer shall prove the advantage and efficiency of ICIC & EICIC either via trial or global reference

9.10.7.

Frequency Scanning for Interferer

Q.283

Tenderer shall provide the related methodology & guideline for spectrum scanning for interference.

Q.284

Tenderer shall provide the related existing interference result or reference according to Taiwan band plan.

Q.285

Tenderer shall support buyer to find out potential interference.

9.10.8.

PCI, Tracking Area (TA) and PRACH Planning

Q.286

Tenderer shall provide the mechanism and guideline regarding how to plan PCI, TA and PRACH.

Q.287

Tenderer shall provide PCI, TA and PRACH planning result once awarded for whole buyers Taiwan sites based on assumptions agreed by Buyer

Q.288

Tenderer shall state the design relation and criteria between TA & LAC

Q.289

Tenderer shall provide the real planning case study on PCI, TA and PRACH from global reference or experience

9.10.9.

Neighbor Relation Planning

Q.290

Tenderer shall run the Neighboring Planning based on buyers requirement

Q.291

Tenderer shall help buyer updating the neighboring after Network initial tuning.

9.10.10. Initial Tuning & Optimization

Q.292

Tenderer shall provide your Network Optimization Guideline which detail all the monitoring and improve-ment KPI with its optimization methodology and actions.

Q.293

Tenderer shall detail the tuning methodology from Preparation Phase / Test Phase / Analysis Phase and Report Generation to Cluster Finished.

Q.294

Tenderer shall detail network checks included site available and site design check in Preparation Phase.

Q.295

Tenderer shall detail site checks included correct PCI and swapped feeder/antenna analysis in Preparation Phase.

Q.296

Tenderer shall detail parameter consistency checks included the neighbor relation and the parameter check in Preparation Phase.

Q.297

Tenderer shall detail feature checks in Preparation Phase.

Q.298

Tenderer shall detail testing preparations included drive test rout and Hot Spot location in the Preparation Phase.

Q.299

Tenderer shall detail mobility and Hot Spot tuning included coverage / quality in Test Phase.

Q.300

Tenderer shall detail problem analysis and report generation in Analysis Phase.

Q.301

Tenderer shall provide new site planning, technical site survey and initial tuning that are required for new site acceptance.

Q.302

Tenderer shall provide site survey report parameter planning data, and initial tuning report. (including drive test results, call event analysis) for new integrated site,
and above reports are required to be reviewed and approved by buyer

Q.303

Tenderer shall provide the initial Tuning Drive Test and change request verification Drive Test, both of IT and DT shall be continuing till the new site RF coverage
& performance KPIs are all achieved. (The reasonable initial KPI shall refer to global commercial LTE network and defined by Buyer & Tenderer than approved by
Buyer finally.)

Q.304

Tenderer shall in charge to prepare the adequate resources for new site drive test. The resources shall in-clude drive test tool, scanner, user end device, laptop
computer, vehicle, driver personnel and derive test technicians and so on.

Q.305

Tenderer shall proposed drive test route planning and it shall include new site surrounding area and over-lapped with first circle neighbors

Q.306

Tenderers initial Tuning Drive Test works have to include signaling analysis for any occurred cell event and proposed Antenna Change Request & Parameter
Change Request are also needed, besides a verification drive test and cell level KPI monitoring shall be performed after CR executing.

Q.307

All initial tuning analysis by Tenderer must be in detail, and the proposed actions have to be discussed with Buyer in charge engineer for CR approval.

Q.308

Tenderers initial tuning analysis engineer and planning engineer must at least have 3 year experience in UMTS & HSPA network RF planning and optimization.

Q.309

For any AR/CR change, Tenderer (vendor) has to make the verification to make sure the new site is in good RF condition than allow Tenderer to activate the new
site and put it on air.

Q.310

Tender shall provide initial tuning report (include drive test results, call event analysis in 3 calendar days after new site on air.

Q.311

Tenderer is required to provide adequate drive test resources to meet the rollout schedule.

Q.312

UMTS RAN equipment vendor shall cover all initial tuning, frequency re-planning and optimization service to ensure end-to-end KPI performance which shall not
be worse than before.

Q.313

Tenderer shall provide the LTE coverage benchmark drive test per quarterly in Tenderers awarded area during rollout period.

Q.314

Tenderer shall provide the LTE coverage benchmark analysis report and improvement suggestions to Buyer for each time drive test.

Q.314.A General network performance (coverage, capacity, quality , ect)

.
Q.314.B General traffic channel performance (peak / average bear access rate, BER BLER, peak/average power, RSRP RSRQ, SINR, accessibly. The quality of voice,
.
packet date etc)
Q.314.C
.
Q.314.D
.
Q.314.E
.
Q.314.F.

General signaling (control) channel performance

Handover performance
Traffic utilization
Random access signaling

9.10.11. Network Performance Monitoring & KPI Commitment

Q.315

To assure the network performance, Tenderer shall comply with 3GPP Standard and KPIs Tenderer is en-couraged to provide more reference KPI items and
higher KPI criteria to Buyer to demonstrate your product capability.

Q.316

Tenderer shall provide the complete description / formula (with recommended value) of E-UTRAN / UTRAN PM counters

Q.317

Tender shall provide the recommended value / formula of major Network Performance KPI (in PMs) and of Field Drive-Test KPI (both for Moving & Static) from
global reference.

Q.318

Tenderer shall propose the test plan in ATP to confirm the network KPI had been achieved for the ac-ceptance test.

Q.319

To minimize the call setup time during CSFB, Tenderer shall provide your signaling processing time in eNodeB part from your reference network and support
Buyers to minimize the end-to-end set-up time.

Q.320

Tenderer if awarded both Buyers Core and RAN network, shall guarantee the CSFB KPI Buyer reserves the right to determine if the KPI is acceptable with
convincing supportive justification provided by vendor.

Q.321

Final UMTS RAN equipment vendor shall assure that end-to-end KPI performance shall not be worse than before (Compare before and after result of one week
and one month of PM report). Buyer reserves the right to determine if the KPI downgrade is acceptable with convincing supportive justification provided by vendor.

9.11.

Network Evolution & Migration

9.11.1.

Network and Technology Evolution

Q.322

Tenderer shall state and propose Buyer how to migrate and evolve existing 3G network(If TSC would have 3G network) and technology to next generation
network

Q.323

Tenderer shall propose Buyer the Inter-RAT strategy which depicts the timeframe (within 5 years) with which Technology for CS & PS service and Inter-RAT
handover.

9.11.2.

Spectrum Migration Strategy with different RAT

Q.324

Tenderer shall provide Buyer the Spectrum Migration Strategy for future 10 years timeframe with existing 900/1800/2100/2600MHz spectrum in hand & future
potential LTE spectrum.

Q.325

Tenderer shall support Buyer to evaluate the bandwidth requirement for very RAT in Buyers network (ex. U2100, L700/900/1800) for future forecast or existing
traffic trend.

Q.326

Tenderer shall provide the deployment scenarios for different spectrum and access technology

9.11.3.

Traffic Offloading

Q.327

Tenderer shall detail the main complementary network technologies used for mobile data offloading like WiFi, SmallCell and other offloading approaches.

Q.328

Tenderer shall prove the traffic offloading effect via trial or other ways (reference report)

9.11.3.1. WiFi offloading (WFA HS 2.0 ANQP)

Q.329

Tenderer shall detail WiFi offloading methodology between WiFi AP and user device by WiFi Alliance / Hot Spot 2.0 requirement

Q.330

Tenderer shall detail WiFi offloading methodology between cellular and WiFi network by 3GPP standards requirement.

9.11.3.1. Traffic Offloading Architecture & Flow (HS 2.0)

1.
Q.331
Tenderer shall detail the traffic offloading architecture and ANQP message flow then comply with WiFi Alliance HotSpot / HotSpot 2.0 requirement.
9.11.3.1. Traffic Offloading Architecture & Flow (3GPP ANDSF)
2.
Q.332
Tenderer shall detail the latest complete 3GPP approach for controlling offloading between 3GPP and non-3GPP access networks (such as WiFi)
Q.333

Tenderer shall detail the traffic offloading architecture and ANDSF message flow then comply with 3GPP ANDSF standard Release 10.

9.11.3.1. User Authentication

3.
Q.334
Tenderer shall detail the support of any kind of automatic WiFi access authentication in user authentication.
Q.335

Tenderer shall provide the authentication flow and detailed description.

9.11.3.1. Network Selection & Connection Management

4.
Q.336
Tenderer shall detail the Network Selection methodology that can automatically switch to WiFi network if the user device detects a known Wi-Fi network.
Q.337

Tenderer shall detail your connection manager solution that can automatically switch to WiFi network if the connection manager detects a known WiFi network

9.11.3.1. Traffic Offloading Performance Evaluation

5.
Q.338
Tenderer shall detail your methodology to prove traffic offloading performance evaluation
Q.339

Tenderer shall detail the performance KPIs of the traffic offloading performance evaluation

9.11.3.2. SmallCell & HetNet Traffic Offloading

9.11.3.2. SamallCell Architecture & Flow
1.
Q.340
Tenderer shall detail smallcell architecture and node function
9.11.3.2. SmallCell Integration
2.
Q.341
Tenderer shall provide the smallcell integration rule and steps
Q.342

Tenderer shall provide the smallcell integration plans and suggestions

Q.343

Tenderer shall provide the smallcell integration scenario (HetNet, indoor, hot spot)

9.11.3.2. Traffic Offloading Performance Evaluation

3.
Q.344
Tenderer shall provide a free trial to prove the smallcell traffic offloading
Q.345

Tenderer shall provide the small celltraffic offloading performance evaluation rule and what KPI to monitor

9.11.3.2. Other Offloading Approach

4.
Q.346
Tenderer shall detail to support of any kind of offloading approach besides WiFi and smallcell
9.12.

Transport Requirement

9.12.1.

General Requirement

Q.347

Tenderer shall detail the available transmission interfaces and capabilities of the eNodeB product portfolio.

Q.348

Tenderer shall detail the backhaul bandwidth dimension methodology and list bandwidth requirement in each phase

Q.349

The eNodeB shall support versatile Ethernet types of interfaces, such as GE (optical or electrical) to meet different network deployment scenarios.

Q.350

The eNodeB shall must support Ethernet Jumbo Frame with the MTU value for transport IP packet up to 1600 for IPv4 or IPv6

Q.351

The eNodeB shall support transmission topologies such as Tree topology, Star topology and Chain topology to meet different requirement

Q.352

The eNodeB shall support virtual IP address, physical interface IP addressing and VLAN addressing to support traffic separation on layer 2 and 3.

Q.353

The eNodeB shall support flexible configuration of IP address and VLAN in order to allow all combination between U-plane, C-plane, M-plane, and S-plane
addressing.

Q.354

The eNodeB shall support multiple VLANs, at least 4 VLANs for U-plane, C-plane, M-plane and S-plane

Q.355

The eNodeB shall support IPV4 or IPv6 and list each complies standard.

Q.356

The eNodeB shall to integrate with Buyer existing Carrier Ethernet Backhaul Network

Q.357

The eNodeB shall support authentication to the transport network using 802.1x (Port-based Network Access Control), between eNodeB and buyer existing LANSwitch, improving security in network domain.

Q.358

The eNodeB shall support Access Control List (ACL) on both layer 2 and layer 3. The proposed eNodeB shall provide packages filtering based on Access Control
List to prevent some attacks.

Q.359

The eNodeB shall support PKI (Public Key infrastructure), which could be a framework to support certificate authentication which is applied to IPSec Tunnel
between eNodeB and security gateway.

Q.360

The eNodeB shall support IPSec Tunnel backup which provides prime and back IPSec tunnels from on eNodeB to 2 security gateways (Se-GW) to improve the
reliability of eNodeB transportation paths protected by IPSec tunnels.

Q.361

The eNodeB shall support Security Socket Layer (SSL) which is a layer between the TCP layer and the O&M application layer, SSL provides the secured data
transfer function between the eNodeB and the O&M server.

Q.362

Tenderer shall provide E2E transport connectivity monitoring Bidirectional Forwarding Detection is required for instance to check connectivity between eNodeB
and intermediate transport network elements.

Q.363

The eNodeB shall support Ethernet Link Aggregation (802.3ad) to bind several Ethernet links to one logical link.

Q.364

The eNodeB shall support Ethernet OAM (IEEE 802.3ah)

Q.365

The eNodeB shall support Ethernet OAM (IEEE 802.1ag)

Q.366

The eNodeB shall support Ethernet OAM (Y. 1731)

9.12.2.

Transport QoS

Q.367

Tenderer shall state the IP transport requirement for LTE E2E QoS

Q.368

The eNodeB must support an integrated functionality to perform E2E IP performance monitoring.

Q.369

The eNodeB must support traffic shaping: It guarantees that the total available traffic bandwidth is not larger than the total configured bandwidth.

Q.370

The eNodeB shall support transport admission control function, which is designed to prevent the shortage in order to admit users for certain traffic quality
guarantee.

Q.371

The NodeB shall support DiffServ QoS feature to provide QoS guarantee by classifying and managing dif-ferent traffic types in the network. The QCI and DSCP
relationship can be configured by operator

Q.372

The eNodeB shall support transmission overbooking with the enhanced admission control mechanism and QoS mechanism (Traffic shaping and congestion
control) to guarantee the transmission quality.

Q.373

Tenderer shall detail the available queue size and list the queuing algorithms supported in transport interface of eNodeB

9.13.

Operation Administration and Maintenance

Q.374

This is to detail the requirement for Operation Administration and Maintenance (OAM), which is required for the efficient operation, administration and
maintenance of the LTE E-UTRAN & UMTS UTRAN system, and all of its Network Element (NEs) (e.g. eNodeB, HeNB / HeNB GW, NodeB / RNC, SON and core
network elements if provided etc.), and the said OAM for efficient operation and management of the overall network, including the Buyers existing network
system.

9.13.1.

General Requirement

Q.375

If the awarded Tenderer of RAN is same with Tenderer of EPC core, the NMS of RAN and NMS of EPC must be the same one. All of LTE Network Elements
(NEs) specified in part 8 (e.g. eNodeB MME, S-GW, PDN-GW, HSS/HLR etc.) shall be managed and integrated by one NMS.

Q.376

The NMS / EMS shall have the capability to allow at least 100 concurrent staffs to access simultaneously.

Q.377

The NMS / EMS shall provide online help functions.

Q.378

Tenderer shall provide the NMS / EMS administrator / operation training.

Q.379

Tenderer shall provide hardware server include rack installation for operation post process and the server specification shall be confirmed by Buyer.

Q.380

The NMS / EMS function shall support a location transparent distributed approach, which will allow staff to manage all of the NEs within the LTE System from any
workstation through appropriate authorized procedure.

Q.381

Tenderer shall provide surveillance mechanism for monitoring the IP devices such as switch / router / firewall which are build for the LTE network system.

Q.382

The NMS / EMS shall be a single system with the multiple capabilities to perform the configuration man-agement, fault management, performance management
and security management functions via Graphic User Interface (GUI) and Command Line Interface (CLI). Tenderer shall detail in detail with sufficient information
and documents.

Q.383

In case of NMS / EMS is out of service, the network operations and services to the customers shall not be interrupted.

Q.384

Tenderer shall provide complete training course which include but not limited the NMS / EMS / OJT (on job training) Network Element (include network
architecture) training course for the Buyers operation and maintenance, also in Software / Hardware upgrade period.

9.13.2.

E-UTRAN Element Management System (EMS)

Q.385

The system shall provide 24 hours uninterrupted service.

Q.386

The system unavailability means the status of the system being in non-operation. It is defined as percentage of average repair duration to the period between
repairs. Less than 0.05% is acceptable (system availability of 99.5% or higher)

Q.387

The NMS / EMS shall provide activity-activity HA (High Availability) solution, including hardware, software and implementation.

Q.388

Then NME / EMS system fail-over impact time less than 10 minutes.

Q.389

Tenderer shall provide HA System full UAT including Configuration Management, Fault Management, Per-formance management and Security management

Q.390

The NMS / EMS shall use the relational / object-oriented database to store and hold the necessary infor-mation for parameters used in the NMS / EMS.

Q.391

The NMS / EMS database shall include fault data, configuration data, maintenance data and performance / QoS data.

Q.392

Tenderer shall provide the details of the provided database, information of database structure, and database application development software.

Q.393

The NMS / EMS equipment shall meet at least the following requirement:

Q.393.A
.
Q.393.B
.
Q.393.C
.
Q.393.D
.
Q.393.E
.
Q.394

Support Hot-plugged HD

Q.395

When NMS / EMS server reach max dimension support, system overall loading cannot over 80%

Q.396

In order to take advantage of industry wide improvement and migration, commodity hardware is preference.

Q.396.A
.
Q.396.B
.
Q.396.C
.
Q.396.D
.
Q.396.E
.
9.13.3.

Standard Unix / Linux Hardware (HP, Oracle-SUN)

Q.397

The NMS or EMS shall provide the capability to check current and abnormal traffic in network element (e.g. the quantity or traffic decrease or increase to
threshold value) and immediately display the abnormal traffic alarm.

Q.398

The NMS or EMS shall provide NE trouble shooting tool and NE provision tool.

Q.399

The NMS or EMS shall provide capabilities for verification the operation of each NE and service.

Q.400

The NMS or EMS shall be able to activate scheduled and unscheduled test, diagnostics and fault localiza-tion programs in the NEs. The capability of transceiver
loop test function is preferable.

Q.401

In EMS and NMS, the alarm severity can be redefined by operator. The severity type must match between EMS and NMS.

Q.402

Tenderer need provide Software management tools in NMS / EMS

Support Hot-plugged power supply

Normal total Disk usage can not over 50%
Normal total CPU usage can not over 60%
Normal total Memory usage can not over 70%
Tenderer shall provide facility requirement include power and cabling for NMS / EMS installation.

Standard OS (Linux, HP Unix, Solaris, AIX)

Standard disc portioning (Raid 10)
Full configuration from central server without local site configuration needs
No hidden license cost and 3rd part integrated software cost.
Alarm Management

Q.402.A The Software management tool shall provide all of software management functions in one and the functions include management multi NE software version,
.
provide multi NE software install, provide multi NE software upgrade, provide multi software correlation and multi NE software remove function.
Q.402.B The software management tool need provide automatically and manually to synchronize with latest network element configuration data.
.
Q.402.C The software management tool can automatically and manually export the information of current soft-ware version of all NEs.
.

Q.403

The NMS / EMS shall provide alarm and NE configuration data export tool, which export data shall be summarized and format shall be .xls, .csv or .txt, NE
configuration data can be filtered by operator.

Q.404

The Self Organizing Network (SON) shall provide policy rule and NE configuration data export tool, which export data shall be summarized and format shall be
.xls, .csv, and .txt, policy rule and NE configuration data can be filtered by operator.

Q.405

The NMS / EMS shall provide automatically update topology manage object within near real-time

Q.406

The NMS / EMS shall provide NE and system backup function.

Q.407

System Healthy Check & Consistency Check requirements

Q.407.A Tenderer shall provide Consistency Check tool. Consistency check on the parameters between NE (filtered by NE, able to export all parameters of the filtered NE,
.
update parameter and then reload back to DB)
Q.407.B
.
Q.407.C
.
Q.407.D
.
Q.407.E
.

Tenderer need provide the system and NE health check function for hardware, application program and service status.
Network Management Tools requirements
Tenderer need provide network management tools in which can execute mass parameters change, add, delete and move cell at same profile.
Tenderer need provide hardware management tool in which can execute hardware and firmware version upgrade and type control and it can automatically and
manually export hardware management data.

Q.407.F. Tenderer shall provide command-handing & GUI tools for operator used to execute configuration check, provision and trouble-shooting.
Q.408

Call Tracing Requriement

Q.408.A Tenderer shall provide call tracing (position locate) interface and function
.
Q.408.B Call tracing function shall include current & history & operator logs
.
9.13.4. E-UTRAN Fault & Alarm Management
Q.409

Tenderer shall provide 45 man-days on job training for fault management

Q.410

The NMS / EMS function shall provide fault management messaging:

Q.410.A
.
Q.410.B
.
Q.410
C.
Q.410
D.
Q.410
E.
Q.410 F.

Managed Object Type

Managed Object Name
Alarm Description
Probable Cause
Specific Problem
Perceived Severity

Q.410
Additional Text
G.
Q.410
Additional Information
H.
Q.410 I. Alarm Set-time & Update-time
Q.410 J. Alarm Clear Time
Q.411

In NMS / EMS, the fault management shall include, but not be limited to the following audit items:

Q.411
A.
Q.411
B.
Q.411
C.
Q.411
D.

Routing Error
Authentication Failure
Call Setup Failure
Protocol Error

Q.411
Link Failure
E.
Q.411 F. Network Element Data Corruption Error
Q.411
Mass Call, Overload and Congestion
G.
Q.411
Network Element Failure
H.
Q.411 I. Facility Failure
Q.411 J. Trunk Failure
Q.411
K.
Q.412

Hardware / Software Failure.

Q.413

The alarm message can identify affected manage object. There shall be a short and long description field in the NMS Alarm Viewer. Short description must match
with the same alarm message in EMS.

Q.414

The alarm in NMS / EMS can be acknowledged and unacknowledged.

Q.415

The alarm can be manually and automatically cleared in alarm view but alarm still need to be stored in system DB.

Q.416

In NMS / EMS, when the events is recovered then need provide clear status to update the original alarm.

Q.417

In NMS / EMS, the alarms shall be able to display by different color depend on severity. The severity in NMS must match with the same in EMS. (Alarm Severity
and Color: Critical is Red; Major is Orange; Minor is Yellow; Warning is Light Blue; Clear is Green)

Q.418

The alarm viewer column in NMS / EMS can be customized and the customized setting can be saved by users. The alarm viewer columns could be switched in
different positions.

Q.419

The alarm severities shall be reflected on the topology map in EMS and NMS. When multiple severities occur in the same NE, it shall always reflect the highest
severity.

Q.420

The NMS / EMS receive and display alarm shall be with network element within near real-time

Q.421

The NMS / EMS need provide alarm statistics tool for current and history alarm to generate and export alarm report. Alarm report format shall be .xls, .csv, .txt.

Q.422

NMS / EMS shall provide a sequence sorting function on the NE list in the Tree view and Topology views. NE name on the Tree view and Topology view shall be
listed by sequence.

Q.423

In NMS / EMS, specific NE alarm can be displayed from NE list in the Tree view and Topology views.

Q.424

The NMS / EMS shall detect and screen repeated alarms.

Q.425

Upon receipt of alarms, the NMS / EMS alarm view shall attract the attention of the operator. On the User Interface, new alarms shall be announced with a
different bold word type, and automatic update to the alarm view window and network map to reflect the alarm.

Q.426

In NMS / EMS, the alarm severity shall in different types. Only such as critical alarms, major alarms, minor alarms, warning alarms and cleared alarms. And alarm
could be filtered and displayed on alarm view by different types of severities.

Q.427

In NMS / EMS, and alarm summary window shall provide statistics of received alarms, critical alarms, major alarms, minor alarms, warning alarms and cleared
alarms, etc.

Q.428

The NMS / EMS shall continue to display all un-discharged and active alarms until it receives an alarm cleared message which coming from the network element
or manually discharged by the operator.

Q.429

The NMS / EMS can filter any column field and parameter of alarm message and filter any network element type.

Q.430

The NMS / EMS shall provide monitor on specific NEs area (ex: central area, south area, Taichung county area)

Q.431

NMS shall receive all NE alarms which in LTE network

Q.432

The NMS / EMS need provide alarm viewer for alarm surveillance and pump up the window of alarm viewer shall be within 5 seconds.

Q.433

The NMS alarm viewer can open at least 3 sub-windows on same window.

Q.434

The NMS / EMS shall be able store and print the detailed alarm log with related information.

Alarm (include alarm description, severity time ) between NMS / EMS shall be in synchronization.

Q.435

In NMS / EMS, the alarm can link to relative operation process of online help guide. Online help is referring to the NE troubleshooting guide on how to fix the
alarm. The guide is preferred in the form of web link.

Q.436

The NMS / EMS alarm can link to command tools & GUI of relative manage object and pump up command screen within 5 seconds

Q.437

The Managed Object Name or User Label can be labeled by customer, the label can be defined at least 30 characters, and these Labels can be show on Alarm
information when the alarm generated. These objects shall be included but not limit as following list: NE Name, Trunk Name, Link Name, and Interface Name.

9.13.4.1. Alarm Analysis and Alarm Correlation

Q.438

The NMS / EMS shall provide event correlation tools for root cause analyze, reduce alarm, modify alarm severity and automatically trigger recovery process. The
correlated alarm shall reflect the highest severity.

Q.439

The NMS / EMS shall provide tools to create the rules or scripts for the event analysis engine. The rules shall take immediate effect after the changes. The rules
are the actions on how to react to the various alarms.

9.13.4.2. Log Management Requirements

Q.440

The NMS / EMS shall store alarms and events to an historical database.

Q.441

In NMS / EMS, all event from the NE (Network Element) shall be received and logged into the database. The data shall be kept on-line for at least 6 month.

Q.442

NMS / EMS shall provide user access NE log command log and operation log. And these log can be ex-ported in .xls, .csv, .txt file format.

9.13.5.

E-UTRAN Performance Management

9.13.5.1. Performance Management System

Q.443

Tenderer shall propose the comprehensive traffic data, their statistics and report format in detail for the Buyers evaluation. The Buyer reserves the right to modify
and choose during the rollout period and the modification shall be performed by Tenderer at Tenderers expense.

Q.444

The system shall be able to perform trend and statistical analysis to allow comparisons of real-time and historical measurement values. It shall be able to perform
standard statistical metric, such as average, median, maximum, minimum, standard deviations, etc., for all the data collected.

Q.445

The system shall be able to collect all performance indicators to show network availability, accessibility, retainability, quantity, quality, utilization and efficiency.

9.13.5.2. Performance Measurement Job

Q.446

Provide text-mode script file tool to create & modify Performance Measurement Jobs.

Q.447

The script file shall can be exported & imported so that one script file can be applied to all Network Elements

Q.448

PM jobs shall still work normally even if parts of counters do not work at current Software version

Q.449

PM jobs shall still work normally even if some Measurement objects do not work normally

Q.450

PM jobs shall still work normally even if some Measurement objects are added, removed or disabled.

Q.451

PM jobs shall provide detailed information of fault and reason in case the job fails.

Q.452

The NMS shall have sufficient capability to receive, store, and process all the PM data.

Q.453

PM data is processed completely into PM database in 5 minutes.

Q.454

O&M tool command response time within 5 sec.

9.13.5.3. Performance Data / Counter

Q.455

NMS needs to comply the standards with 3GPP TS32.425, 3GPP TS32.426, 3GPP TS32.450, 3GPP TS32.455 of the counters and formulas.

Q.456

Counter value only accumulate value within measurement period, dont accumulate value from the starting time of measurement job.

Q.457

To collection period for event counters and statistics shall be under control of the operator in the range from 15 minutes to 1 hour.

Q.458

Performance counter file support XML or CSV format or TXT format.

Q.459

Performance counter must include following but not limited to:

Q.459
A.
Q.459
B.
Q.459
C.

Customer: Registered Customer, Attached Customer.

Available: Network element available
Accessibility: RRC connection success rate, S1 connection setup success rate, E-RAB setup success rate, attach success rate, service request success rate

Q.459
Retainability: drop cell rate, handover success rate
D.
Q.459
Throughput: user throughput, network element throughout
E.
Q.459 F. Quality: Latency, Jitter, Packet Loss.
Q.459
G.
Q.460

Traffic: Traffic loading, Transmit bandwidth

Q.461

The NMS shall provide accurate event counters and statistics that permit assessment of all aspects of the performance. Event counters shall permit manual and
automatic rest.

Weekly measurement data availability must be over 99%

9.13.5.4. Performance Database

Q.462

The system shall use the relation / object-oriented database to store and hold the necessary information for the parameters used in the system.

Q.463

Allow user use ODBC and standard SQL to access database

Q.464

Tenderer shall detail the details of the provided database, information of database structure, and database application development software.

Q.465

The NMS / EMS aggregate the raw data into daily table, weekly table, monthly table.

Q.466

Hourly data kept to 6 months, daily data kept 13 months, weekly data kept 3 years, and monthly data kept 3 years.

9.13.5.5. Performance Reporting

Q.467

Provide performance indicator definition and formula and health range of all measurement counters.

Q.468

Provide sufficient predefined performance reports to cover all the KPI in 3GPP TS32.455 and TS32.450

Q.469

The predefined reports cover hourly, daily, weekly, monthly report

Q.470

Report designing tool shall be able to create or modify report with system database tables as well as us-er-defined tables, and make relation between these two
kinds of database tables.

Q.471

Reporting interface should comply with factory standard and the exported file can be opened with Microsoft Excel

Q.472

Provide Counter Increment / Decrement operation flowchart

Q.473

NMS / EMS provide the ability to generate the graph report and table report for evaluating the performance.

9.13.5.6. Performance Measurement Specific Functionalities

Q.474

A web reporting application shall be available in NMS.

Q.475

Users shall be able to query on any counter at any object group level on any summary level

Q.476

Users shall be able to combine any counter into any user defined KPI formula.

Q.477

The following performance management data shall as a minimum be supported:

Q.477
A.
Q.477
B.
Q.477
C.
Q.477
D.
Q.477
E.
Q.477 F.

Performance data

Q.477
G.
Q.478

Measurement interval

Q.478
A.
Q.478
B.

Graphical Report

Performance event
Event statistics
Counters
Performance thresholds
Measurements

The NMS shall as a minimum provide the ability to generate the following reports for evaluating the network performance:

Table Report

Q.478
C.
Q.478
D.
Q.479

Raw data display

Q.480

The offered solution shall handle a situation where performance measurements are suspended or interrupted. The Tenderer shall describe how this achieved.

Counters display
The performance management reports shall be possible to schedule in 15, 30 or 60 minutes interval, daily interval, weekly and monthly interval.

9.13.5.7. Performance Monitoring

Q.481

The system shall allow the setting of thresholds for every network performance indicators, i.e. WARNING and CRITICAL level. It will automatically, report the
event and alarm to responsible engineer.

Q.482

The NMS / EMS shall have the ability to generate the following types of performance alarms.

Q.482 1. Real-time network alarms

Q.482 2. Historical alarms analyze current data against historical data (daily, weekly and monthly sum-maries)
9.13.5.8. Performance Integration
Q.483

The buyers would have performance system that measure the performance of the network. Tenderer shall integrate performance data into the buyer system.

Q.484

PM data shall be transferred completely to the buyers integrated performance system in 5 minutes

Q.485

PM data is real-time transferred to the buyers integrated performance system by trigger method.

9.13.6.

Backup & Recovery Mechanism

Q.486

The NMS / EMS shall provide full Backup / Restore solution including hardware, software and implementa-tion.

Q.487

The NMS / EMS system shall be able to restore data by using backup data mentioned above and get back to normal operation, as the time data were backup.

Q.488

The NMS / EMS outline full / incremental backup shall not affect the normal operation of the system.

Q.489

The backup policy shall support at least full backup per week and keep backup data 3 months for ISO27001 audit.

9.13.7.

EMS Operation

Q.490

All kinds of account type of each network element can be managed by single centralized NMS / EMS system

Q.491

The NMS / EMS servers shall provide security management for network administration. The following type of security management function shall include:

Q.491
A.
Q.491
B.
Q.491
C.
Q.491
D.
Q.491
E.
Q.491 F.

Identification / Authentication

Q.491
G.
Q.491
H.
Q.492

Audit Mechanisms Anti-virus solution.

Q.493

All access logs and command logs of each network element can be managed by single centralized system and stored in centralized system with readable text
(ASCII) file format.

Q.494

All access logs and command logs shall keep at least 1 year at NMS / EMS for IOS27001 audit.

Access Control
Command Log
Confidentiality
Integrity
Audit Mechanism

Once any system is based on Microsoft Windows operation system, Tenderer shall provide automatic patch update, software management solution.
The NMS / EMS shall provide all user access NE log command log, activity log. Each type of log must at least include user account name, access time, NE, name,
command data.

9.13.8.

EMS / NMS Integration

Q.495

The LTE system NEs shall provide interfaces to the NMS / EMS and the LMTs interface to NMS / EMS

Q.495
A.

The communication links between the NMS / EMS and the LTE system NEs shall be interconnected via industry Standards such as SNMP, the ITU-T Q3 or
CORBA interface. Tenderer shall clearly detail the proposed interface and protocol stack for the buyers evaluation.

Q.495
B.

Tenderer and other equipment vendor shall provide all the equipment such as interface circuit, modem, wire and cable, accessories, etc., expect the transmission
facilities, if required for interconnections be-tween NMS / EMS and NEs.

Q.496

The LMTs shall be connected to the LTE system through the Buyers existing Local Area Network (LAN) using the industry Standard protocols. Additionally
terminals and printers shall be connected via high-speed protocol.

Q.497

The MMI (Man Machine Interface) manages the dialogue between the user and the LTE system. It shall provide a user interface, which is easy to handle and
helps to avoid user input errors. The MMI shall be structured according to ITU-T Z.300 series Recommendations.

Q.498

Tenderer shall provide the consultancy in between NMS / EMS and the Buyers system following factory standard

Q.499

The NMS shall have alarm northbound interface and can be integrated to Buyers TSC NMS. Alarm between NMS and TSC NMS shall be 100% synchronized.
Tenderer shall provide consultancy on the integration

Q.500

All the alarm between NMS / EMS and TSC NMS shall be synchronized.

Q.501

All the alarm datas schema & MIB shall be provided for alarm integrated.

Q.502

All of the Configuration datas schema & MIB shall be provided for Buyer operation DB integrated

Q.503

All of the provision datas schema & MIB shall be provided for Buyer operation DB integrated. Provision data include Circuit data, Patch data, Trail data Routing
data, E-UTRAN Radio data, IP transport network data etc.

Q.504

The NMS shall be able to manual export and scheduled export provision data to other formats. (i.e. Excel, CSV, TXT, XML). Provision data include Circuit data,
Path data, Trail data, Routing data, E-UTRAN Radio data, IP transport network data etc.

9.13.9.

Self Organizing Network (SON) integration

Q.505

The SON system shall provide security management, including identification, authentication, authorization, access control, and command log, confidentiality,
integrity, and audit mechanisms.

Q.506

Account management of SON server shall be well integrated into Buyers LTE NMS. All AAA (Authentication, Authorization and Accounting) must be centralized
management by LTE NMS. Tenderer shall provide the con-sultancy on the integration required

Q.507

The SON system shall provide the security control as same as LTE NMS, User ID shall be locked if user type the wrong password for three times, users will be
forced to change their password over three months, system administrators have the function to reset the password but can't get users password.

Q.508

The SON system shall provide Web GUI and command line mode interfaces for operation and maintenance.

Q.509

The SON system shall have the ability to track user operation activity. Any users (include administrator) access the platform shall be logged in the SON system
and store at least one month. The stored data shall in-clude necessary attributes but not limited to: user identifier, command / responses (executed result), timestamp.

Q.510

The SON system shall provide the function (include the GUI and Command Line Interface) for users to change O&M users password by themselves.

Q.511

The SON system shall provide the function (include the GUI and Command Line Interface) for administrator / root to change password by themselves.

Q.512

If SON system data is stored at more than on location, the database changes must be synchronized across the different sites.

Q.513

The SON system shall have some of the key statistics (CPU, MEMORY, DISK I/O, FILE SYSTEM USAGE) that system produces for system loading analysis,

Q.514

The SON system shall have some of the key alarms that system produces to indicate error conditions.

Q.515

Tenderer shall detail the overall test method, including but not limited to:

Q.515
A.

The self-diagnosis functionality

Q.515
B.

Stress test for function and con-current user session limitation test.

Q.516

The SON system shall have the ability to define different levels of administrator access to the system. The system shall have different user defined access
profiles. The system shall have different security level definition to specific sites.

Q.517

The system shall have house keeping function to ensure that the system is able to perform at its optimal level. House keeping policy: file system usage can not
over 70%

Q.518

Tenderer shall provide automatic online backup of the database, and configuration data, operation system.

Q.519

Tenderer shall provide the function of archiving and purging of log files into external storage / tape backup system.

Q.520

Tenderer shall provide backup solution, including hardware, software configuration and recommendation on backup frequency.

Q.521

Tenderer shall provide the following topics in backup and recovery design. These items shall be provided in detail documents.

Q.521
A.
Q.521
B.
Q.521
C.
Q.521
D.
Q.521
E.
Q.521 F.

Protection against permanent data loss.

Q.521
G.
Q.521
H.
Q.522

Maintenance of backup hardware.

Q.522
A.
Q.522
B.
Q.522
C.
Q.522
D.
Q.523

Daily check procedure

Q.523
A.
Q.523
B.
Q.523
C.
Q.523
D.
Q.524

Use of reliable components.

Q.525

The SON system shall include a special process that monitors aliveness of the entire server. That process will restart the relational programs to recover service
and alarm will be sent out through SMS or email automatically.

Q.526

The SON system shall provide 24 hours uninterrupted service.

Q.527

The system unavailability means the status of system being in no-operation. It is defined as percentage of average repair duration to the period between repairs.
Less than 0.01% is acceptable (system availability of 99.99% or higher)

Q.528

Under maximum dimension management of network elements, the SON system average loading cannot over 60% and CPU IO wait cannot over 10%

Backup policy definition (DB: online full backup, AP & OS: Incremental).
Backup schedule (Daily)
Detailed backup procedures.
Detailed recovery procedures
Backup and recovery test plan.

Plan for minimizing Directory downtime in the event of a disaster

Tenderer shall provide the health check procedure, let buyer to perform regular healthy check.

Weekly check procedure

Monthly check procedure
Quarterly Check procedure
The SON system shall be designed for fail-safe and malfunction recovery, tis means that server must be able to operate with good redundancy mechanism for
hardware and software respectively. The design follows these key principles:

Redundant components and no single point of failure within the architecture.

Parallel architecture for scalability and failover.
Automated load balancing and error handling for redundant components.
The SON system must have redundancy architecture. Tenderer shall state the offered solution whether 2N or N+1 or HA redundancy architecture.

Q.529

Tenderer shall provide 30 man-days on job training for SON operation and system administration.

Q.530

The Operations and Maintenance documentation shall cover all functions for network operations and maintenance. The supplied documentation shall contain
information that enables the operations and maintenance staff to easily identify and isolate network failures. The documentation shall direct the user through the
step-by-step measures and the diagnosis program to use, if necessary.

Q.531

Man-machine commands and expected responses to these shall be easy to find. Normally, it shall not be necessary to take notes or make calculations manually
during these operations. SON system should also provide user friendly Graphical User Interface (GUI) so the operations can be implemented and executed with
ease.

Q.532

A complete set of documentation for system restart shall also be provided. This shall be function oriented and in alphabetical order.

Q.533

Documentation of operations and maintenance shall include:

Q.533
A.
Q.533
B.
Q.533
C.
Q.533
D.
Q.533
E.

Description of Operations and Maintenance practices.

Man-machine commands and functional descriptions.
Alarm printout manuals, including indications of alarm classes and recommended problem solving pro-cedures.
Fault diagnosis manuals.
Routing including:
Operation routines
Emergency routines (specified in detail)

Q.533 F. Descriptions of procedures for changing exchange data and cell parameters
Q.533
Description of all network supervision functions
G.
Q.533
Description of database schema
H.
Q.533 I. Description of API and/or protocol interface with sample call flow
Q.533 J. All tables for operation of the equipment shall be delivered ready for use. They shall be arranged in a way that makes them easy to use and easy to change.
Q.533
Tables for routing, billing and signaling shall be clearly set out and arranged in a way that makes them easy to use or change.
K.
9.13.10. Software and Patch Upgrade or Maintenance
9.13.10. General Requirement
1.
Q.534
All hardware elements in eNodeB and RAN that Tenderer provides must have the ability to be upgrade software and patch remotely from OMC.
Q.535

Tenderer shall propose eNodeB Software Upgrade Strategy based on the schedule of Buyers RAN new function requirement.

Q.536

Tenderer shall fulfill all Software Upgrade Procedure required by Buyer

Q.537

Tenderer shall provide Software upgrade related document that required by Buyer, including impact, Data report and Global Problem Reference.

Q.538

Tenderer shall provide software upgrade related training to well describe software Delta (the difference be-tween original and target software version). Including
any problem fix, change in function, parameter, counter and KPI

Q.539

Tenderer must provide on-line account that Buyer can directly query any problem and technical not related to current and future software version used on Buyers
RAN

Q.540

Tenderer must send notice mail and message to buyers online account if any problem and technical note update related to Buyers current and future RAN
software version.

9.13.10. Completeness of Software Upgrade Procedure

2.
Q.541
General Software Upgrade Procedure must be separated to below phase:

Q.541
A.
Q.541
B.
Q.541
C.
Q.541
D.
Q.542

Preparing Phase

Q.543

Tenderer shall provide Lab Trial Report that verified time plan, procedure, script and impact was as expected in Lab Trial Phase

Q.544

Tenderer shall provide Live Field Trial Report that verified all procedure, script, impact and KPI was as ex-pected in Live Field Trial Phase

Q.545

Tenderer shall provide Check Report to verify if any unexpected change in parameter, counter, KPI, feature switch (and license) after upgrade in any Live Node in
Live Field Trial and Rollout Phase.

Q.546

Tenderer shall provide at least two dedicated qualified on-site engineers responsible for Upgrade related task during Upgrade period in Lab Trial, Live Field Trial
and Rollout Phase. And provide at least one more day with at least one on site baby-sitting engineer after the day Upgrade is performed.

Q.547

Tenderer must put in at least one week KPI monitoring period after Upgrade is performance. KPI monitoring report must be instituted and confirmed by Buyers
Software & Patch Upgrade team.

Lab Trial Phase

Live Field Trial Phase
Rollout Phase
Tenderer shall provide Implementation Plan before kick-off meeting of upgrade project in Preparing Phase. Implementation Plan must include overall schedule,
related Test Plan, Rollback Plan, instruction script and all required document addressed in Documentation chapter sector.

9.13.10. Documentation
3.
Q.548
Tenderer must provide the most updated official hardware, software and maintenance document before software and patch upgrade project start.
Q.549

Tenderer must provide detail Impact Report that well describe if any expected impact on service, maintenance or environment.

Q.550

Tenderer must provide detail Delta report that list all difference (such as problem fix, change in function, parameter, counter and KPI) between original and target
software version. Related solution must be provided if any Delta be expected to cause any service or maintenance impact

Q.551

Tenderer must provide detail Global Problem Reference that complete list all Known Problem and related solution with roadmap

Q.552

Tenderer must verify and prove the completeness in Global Problem Reference of target software version via the on-line account provided to Buyer during
Preparing Phase.

9.13.10. System Outage & Failure caused by Software and Patch Upgrade
4.
Q.553
Tenderer is responsible for related System Outage & Failure during (but not limited) one week KPI monitoring period cause by Software & Patch Upgrade
Q.554

Tenderer shall be on-site of any System Outage & Failure within four (4) hours of outage notification and provide required urgent maintenance and outage
resolve.

Q.555

Tenderer must assign a team with PM to discuss solution, monitor KPI and report status of System Outage & Failure every day in the meeting of Buyers War
Room before system outage be resolved.

Q.556

Tenderer must continuously worked with Buyer for any System Outage & Failure happened during (but not limited) KPI monitoring period until the System Outage
& Failure is resolved and service has been restored.

Q.557

Buyer can postpone Software Upgrade and Patch Upgrade related acceptance procedure if any System Outage & Failure caused by Upgrade still not be
resolved.

9.13.10. Service Downtime during Software and Patch Upgrade

5.
Q.558
Tenderer shall provide detail service downtime analysis report that well describes service downtime during Software and Patch Upgrade.
Q.559

Tenderer must provide Pre-Scheduling Function for RAN software Upgrade on OSS or SON that Buyer can schedule upgrade task per eNodeB by demanded
area.

Q.560

Tenderer must provide related SON function that can automatically group eNodeB by different coverage for scheduling upgrade task by coverage group. The
ability to adjust Coverage group manually must be included.

Q.561

Tenderer must provide related SON function that can reduce coverage loss of target eNodeB by automatic adjust RF parameter of neighbor eNobeB during
service downtime.

Q.562

Tenderer must provide related SON function that can automatic verify status of eNodeB hardware, software and traffic of service, perform auto recovery, than
perform automatic rollback to previous software version if any failure after Software and Patch Upgrade.

9.14.

User Authentication

Q.563

Based on offered solution and device, Tenderer shall provide:

Q.563
A.
Q.563
B.
Q.563
C.
Q.564

End to end User Authentication / Registration procedure and message flow

Q.565

Tenderer shall comply with 3GPP R8 or later release IMS/ISMI standards to support CSCF of IMS Core to finish USIM-based IMS-AKA and ISIM-based IMS-AKA
authentication from which equipped with the operator UICC card (that is, a 3G SIM card) with USIM or ISIM capability.

9.15.

QoS Assurance

Q.566

Tenderer shall detail how to ensure E2E QoS across every network node.

Q.567

Tenderer shall detail the mechanism of admission & congestion control in offered solution.

Q.568

Tenderer shall depict how the Downlink / Uplink MAC scheduler work in offered solution (providing advanced scheduler features for effective resource allocation is
a plus)

Q.569

Tenderer shall detail how to ensure the service in:

Q.569
A.
Q.569
B.

E-UTRAN QoS

Q.569
C.

Core Network QoS

Q.569
D.
Q.570

Application / service QoS

Q.570
A.
Q.570
B.

Vertical QoS mapping (i.e. MAC <-> IP <-> Application)

Q.570
C.
Q.571

IRAT QoS mapping (i.e. LTE <-> UMTS <-> WiFi)

9.16.

Network Security

Q.572

Tenderer shall provide security mechanisms to protect E-UTRAN in below associated network path or in-terface

Q.572
A.
Q.572
B.
Q.572
C.
Q.572
D.

Protect 1. eNodeB: Theft, remove or loss of information and/or other resources: theft of eNodeB hard-ware

User Authentication approach, mechanism and involved Standard

User Encryption mechanism
The offered E-UTRAN solution shall support EPS AKA procedure as specified in TS 33.401 for UE authen-tication.

Transport QoS

Tenderer shall provide the mapping table for

Horizontal QoS mapping (i.e. RAN <-> Transport <-> Core)

Tenderer shall provide the global reference that how Operator apply QoS for their Marketing or Business promotion (provide three reference cases)

Protect 1. eNodeB: Disclosure of information: unauthorized access to important information such as the keys, software, and configuration file of the eNodeB
Protect 1. eNodeB: Corruption of information: loading invalid software or illegally controlling the eNodeB through the local commissioning Ethernet port
Project 1. eNodeB: Interruption of services: launching Denial of Service (DoS) attacks on the eNodeB to make the eNodeB go out of service.

Q.572
Protect 2. Uu interface: Disclosure of information: unauthorized access to important user information by interception of signals on the Uu interface.
E.
Q.572 F. Protect 2. Uu interface: Corruption of information: accessing the network with a false user identity through simulated Uu signaling
Q.572
G.
Q.572
H.

Protect 3. S1 interface: Disclosure of information: unauthorized access to important user information by interception of data from the transport network
Protect 3. S1 interface: Corruption of information: modifying related contents of the data that is inter-cepted on the transport network and accessing the network
with forged user identity

Q.572 I. Protect 4. X2 interface: Disclosure of information: unauthorized access to important user information by interception of handover-related data from the transport
network
Q.572 J. Protect 4. X2 interface: Corruption of information: modifying contents of the handover-related data that is intercepted on the transport network
Q.572
Protect 5. OM interface: Disclosure of information: interception of the important eNodeB information that is transmitted over the OM interface
K.
Q.572 L. Protect 5. OM interface: Theft, removal or loss of information and/or other resources: interception or removal of the important data of the eNodeB by using the OM
interface. For example, the interception or removal of the configuration file or version information. This threat is from unauthorized logins followed by unauthorized
operations of the system / eNodeB.
Q.572
M.

Protect 5. OM interface: Corruption or modification of information: unauthorized logins followed by un-authorized operations of the system / eNodeB through the
OM interface. This is major threat to the OM channel.

Q.572
N.
Q.573

Protect 5. Clock Server: Corruption or modification of information: attacks from invalid time sources on the eNodeB

Q.573
A.

3GPP TS32.210: Technical Specification Group Services and System Aspects; 3G Security; Network domain Security (NDS); IP network layer security (Release
10)

Q.573
B.

3Gpp TS21.133: 3Rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security Threats and
Requirements.

Q.573
C.
Q.573
D.
Q.573
E.

3GPP TS33.102: 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security Architecture.

Tenderer shall comply with below 3GPP security related standards.

3GPP TS21.103: 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Integration Guidelines.
3GPP TS33.120: 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security Principles and
Objectives.

Q.573 F. 3GPP TS33.203: 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Access Security for IP-based services.
Q.573
G.

3GPP TS21.133: 3rd Generation Partnership Projects; Technical Specification Group Services and System Aspects; 3G security; Security Threats and
Requirements.

Q.573
H.

3GPP TS33.401: 3rd Generation Partnership Projects; Technical Specification Group Services and System Aspects; 3GPP System Architecture Evolution (SAE);
Security Architecture.

Q.573 I. 3GPP TS33.310: 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Network Domain Security (NDS);
Authentication Framework (AF).
Q.573 J. 3GPP TS33.320: 3Rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Security of Home Node B (HNB) and HeNB.

9.16.1.

Smartphone Signaling & Traffic Handling

Q.574

Tenderer shall provide TSC broadband traffic forecast (ex. GB or TB per year) from 2013 to 2030 based on the Tenderers own study or global reference.

Q.575

Tenderer shall provide latest Market trend of LTE devices, users, and applications.

Q.576

Tenderer shall provide the design guideline, mechanism and solution for Buyers to deal with abrupt increasing Smartphone signaling and traffic.

Q.577

Tenderer shall provide the real case study on potential Smartphone Signaling & Traffic issues and how op-erator to handle or prevent the issues in advance.

9.17.

Application & Service

9.17.1.

General Requirement

Q.578

From end-to-end performance viewpoint, the Tenderer shall assure the service performance and quality of offered E-UTRAN or UTRAN network (If TSC would
have) to deliver the best quality of service for buyers cus-tomers.

Q.579

Tenderer shall support Buyer on the integration of E-UTRAN or UTRAN network and Service Platform if connected and required.

Q.580

Tenderer shall support to tune and optimize the QoS relevant parameters in E-UTRAN or UTRAN (and QoS mapping to other element nodes or layers) based on
Buyers network and business requirement.

9.17.2.

Service Scope & Performance

Q.581

The initial services that require Tenderer to support to ensure E2E performance via E-UTRAN & UTRAN are listed below but not limited to:

Q.581
A.
Q.581
B.
Q.581
C.
Q.581
D.
Q.581
E.
Q.581 F.

CSFB, SRVCC and VoLTE

Short Message Service (SMS)
Multimedia Messaging Service (MMS)
Ring Back Tone (RBT)
Voice Mail Service (VMS) / Missed Call Alert (MCA)
Mobile Position Services (MPS) / Location Service (LCS)

Q.581
Rich Communication Service (RCS)
G.
Q.581
Evolved Multimedia Broadcast / Multicast Service (eMBMS)
H.
Q.581 I. Cell Broadcast Service (CBS): including Public Warning Service (PWS)
Q.582

Tenderer shall assure the RF and Service performance in offered E-UTRAN and UTRAN network to achieve or be better than the requirement defined in ITU (ITUR M.2134) and 3GPP

Q.583

Tenderer shall support and comply with Cell Broadcast Service (CBS) which defined in 3GPP. Please detail your MBMS mechanism, function description and
feature readiness.

Q.584

Tenderer shall provide your detailed Evolved Multimedia Broadcast / Multicast Service (eMBMS) solution which including solution architecture, working
mechanism, SW / HW readiness and 3GPP standard compliance.

9.18.

Regulatory Requirements

Q.585

Tenderer has the obligation & responsibility to support Buyer to fulfill National Communications Commission (NCC) requirement

9.18.1.

4G License Responsibility

Q.586

Tenderer shall fully comply the national regulatory requirement for 700MHz / 900MHz / 1800MHz network deployment.

Q.587

All the task and cost to fulfill National Regulatory requirement shall be included in this RFP scope for Tenderer to propose their network implantation plan.

Q.588

Tenderer shall provide the eNodeB which has the capability to support > 100Mbps throughput (Single-Sectors) with 15MHz above bandwidth to meet regulatory
requirement.

Q.589

Tenderer shall provide the average eNodeB single cell capacity and spectral efficiency (under >70% loading) in different bandwidth i.e. 5MHz, 10MHz, 15MHz and
20MHz

Q.590

Tenderer shall provide the certificate and verification report of >100Mbps throughput capability in Single Cell to prove to National Communications Commission
(NCC) for the BTS performance requirement.

Q.591

The offered eNodeB product shall be complied with the category and requirement requested in ITU IMT-Advanced (i.e. 4G) and 3GPP Standard (R10 and above)

Q.592

The offered eNodeB should support mobility speed > 350km/hr in open space.

9.18.2.

Coverage & Population Requirement

Q.593

Tenderer shall provide Buyer the detailed deployment plan to meet NCCs coverage & population require-ment.

Q.594

The network deployment plan and population coverage target per year need to be negotiated and accepted by Buyers to meet NCCs coverage requirement (i.e.
50% population coverage within five years)

9.18.3.

System Inspection

Q.595

Tenderer shall provide the detailed plan for preparation (i.e. > 250x eNodeB readiness) and pre-test for NCC system inspection

Q.596

Tenderer shall follow the inspection rule detailed in NCCs to fulfill regulatory requirement

Q.597

Tenderer shall support Buyers to pass CIB and NCC inspection.

Q.598

Tenderer shall support Buyers to get Network Construction Permit.

9.18.4.

Type Approval

Q.599

The offered eNodeB, user terminal and RAN related products shall pass LTE type approval verification in NCC authorized test institute of lab

Q.600

All the offered LTE products to Buyer need to get the national sales permit in Taiwan.

Q.601

The final Contractor has to provide the qualification or certificate of passing type approval to Buyer before network deployment.

9.18.5.

Lawful Interception

Q.602

The Lawful Interception which may be imposed by regulatory parties in Taiwan (include CIB, MJIB, NCC, etc) shall be supported by Contractor if involved LTE
RAN.

Q.603

Tenderer shall provide associated Lawful Interception (LI) feature supported in RAN to fulfill CIB / MJIB re-quirement.

Q.604

Tenderer shall provide the document of RAN feature description to support LI

Q.605

All the LI system interface and functional requirement must be complied to 3GPP (TS33.106, TS33.107, TS33.108) standards, ETSI (TS103.232) standards, and
CIB / MJIB requirements.

Q.606

Tenderer shall support to deliver a comprehensive LI System Construction Proposal in Chinese for NCC & CIB / MJIB inspection purpose and get approval.

Q.607

Tenderer shall support the implementation and integration with Core Network for LI system according to the requirement of CIB / MJIB

Q.608

Tenderer shall support to provide the test plan and document for CIB / MJIB s LI function inspection.

Q.609

Tenderer shall support the self-evaluation test and official inspection task to pass the CIB / MJIB LI function inspection.

9.18.6.

Emergency Call (EC)

Q.610

Tenderer shall provide the document of RAN feature to support Emergency Call.

Q.611

Tenderer shall support the implementation and integration with core network for Emergency Call according to the requirement of NCC.

Q.612

Tenderer proposed RAN shall handle the Emergency Call with highest priority, and the Tenderer shall provide the documents to describe the priority processing
mechanism.

Q.613

Tenderer shall support to provide the test plan and document for NCCs Emergency Call function inspection.

Q.614

Tenderer shall support to the self-evaluation test and official inspection task to pass NCC EC function in-spection.

9.18.7.

Public Warning System (PWS)

Q.615

Tenderer shall provide the solution documents of E-UTRAN / UTRAN features to support Public Warning System.

Q.616

Tenderer shall include the PWS feature supported in E-UTRAN / UTRAN in this RFP scope

Q.617

Tenderer shall support the implementation and integration with core network for PWS according to the re-quirement of NCC.

Q.618

The offered solution shall support the Public warning System (PWS) as defined by the 3GPP Ts22.268

Q.619

The offered solution shall support the Cell Broadcast Service (CBC) as defined by the 3GPP TS23.041

Q.620

Tenderer shall support to provide the test plan and document for NCCs PWS function inspection.

Q.621

Tenderer shall support to self-evaluation test and official inspection task to pass the NCC PWS function in-spection.

9.18.8.

User Performance Assurance & Speed Test

Q.622

The final Contractor shall be obligated to assist Buyer achieved the Regulators target of User Performance Assurance & Speed Test

Q.623

Tenderer shall provide the methodology and solution on how to monitor User Performance and Quality.

9.19.

Network Integration

9.19.1.

General Requirement

Q.624

This chapter stipulates the requirement of future E-UTRAN / UTRAN to integrate with Buyers existing 3G network. As buyers E-UTRAN or UTRAN supplier, the
contractor shall have the responsibility and capability to support buyer to complete the network integration to provide best network synergy.

Q.625

Tender shall cover the potential cost to resolve the MVI / IOT open issues with the Buyers existing EPC supplier. (e.g. consultant, protocol analyze, tools)

Q.626

Tenderer is responsible to interconnect, integrate, and perform all related tasks and tests of inter-working and interoperability to ensure a smooth inter-working
between the LTE EPC. During the Contract period, in case that any of equipment with associated software or materials necessary for the integration with Buyers
LTE EPC is found not listed in the Price Proposal and BOM, Tenderer shall supplement the necessary equipment with associated software or materials as a turnkey solution offered without an y additional charge to the Buyer.

9.19.2.

Interoperability Test (IOT)

Q.627

Tenderer if offered LTE E-UTRAN shall pass below IOT scenarios and provide Buyer the detailed IOT in-formation and plan (ex. test case, test plan, and test
result) via different network interfaces.

Q.627
A.
Q.627
B.
Q.627
C.
Q.627
D.
Q.627
E.
Q.627 F.

MME contains different eNodeB (S1-MME)

Q.627
G.
Q.628

Self-Organizing Network (SON)

Q.628
A.
Q.628
B.
Q.628
C.
Q.628
D.
Q.628
E.
Q.628 F.

RNC contains different NodeB (lub)

Q.628
G.
Q.628
H.

RNC connect to other MSC (lu-CS)

eNodeB integrates to other MME (S1-MME)

S-GW contains different eNodeB (S1-U)
eNodeB integrate to other S-GW (S1-U)
Inter-Vendor intra-LTE Mobility Tests over X2
Inter-Vendor IRAT Mobility Tests between LTE and UMTS

Tenderer if offered UMTS UTRAN shall pass below IOT scenarios and provide Buyer the detailed IOT in-formation and plan (ex. test case, test plan, and test
results) via different network interface.

NodeBs integrates to other RNC (lub)

SGSN contains different RNC (lu-PS)
RNCs integrate to other SGSN (lu-PS)
RNC connect to other RNC (lu-r)
RNC connect to other LTE S-GW (S12)

LTE CSFB to U900MHz / U2100MHz

Q.628 I. Inter-Vendor IRAT Mobility Tests between LTE and UMTS

Q.628 J. U900 / U2100 integrate with Self-Organizing Network (SON)
Q.629

The offered UTRAN / E-UTRAN solution shall be integrated with designated Core Network and verified in Buyers Lab or Live network before contract to ensure
the Interoperability capability with other network elements.

Q.630

The offered UTRAN / E-UTRAN solution shall describe your End-to-End QoS solution & mapping across Core, Transport and RAN network.

Q.631

The offered UTRAN / E-UTRAN solution shall detail how to support and implement SON features across Core and RAN network.

Q.632

The offered E-UTRAN solution shall detail how to support and implement MME pool features across Core and RAN network. And describe how the eNodeB
selects the MME for load balancing for according to the Weighting factor.

Q.633

Tenderer shall support to integrate with Buyers Public Warning System.

Q.634

Tender shall support to integrate with Buyers LCS system, Buyers SMS system.

Q.635

The offered E-UTRAN solution shall provide S1-MME interface to/and integrate with Buyers MME as speci-fied in 3GPP TS23.401, TS36.300 and TS36.413.

Q.636

The offered E-UTRAN solution shall support MME to delivery NAS message to/from UE as specified in 3GPP TS23.401, TS23.301.

Q.637

The offered E-UTRAN solution shall support functions, information flows and procedures as specified in 3GPP TS23.401 (GPRS enhancements for E-UTRAN
access), TS33.401 (3GPP SAE-Security Architecture), TS36.300 (E-UTRA and E-UTRAN overall description), TS23.272 (Circuit Switched Fall Back in EPS),
TS23.041 (Technical Realization of Cell Broadcast Service), TS23.271 (Functional Stage 2 Description of Location Services)

Q.638

The offered E-UTRAN solution shall support functions, information flows and procedures as specified in 3GPP TS23.216 (Single Radio Voice Call Continuity)
(Optional)

Q.639

The offered E-UTRAN solution shall support LPPa protocol (as specified 3GPP TS36.455) and integrate with E-SMLC via MME

Q.640

The offered E-UTRAN solution shall support E-SMLC to relay LPP protocol message to/from UE as specified in 3GPP TS36.355 via MME.

Q.641

The offered E-UTRAN solution shall support X2 handover

Q.642

The offered solution shall detail describe the error handling mechanism while MME node is out of service to provide service continuously.

Q.643

The offered RAN solution shall support the RIM (RAN Information Management) and integrate with Buyers EPC for optimize the CSFB

9.19.3.

Multi Vendor Integration (MVI)

Q.644

Tenderer shall provide your global MVI reference list with other Tenderer (ex. Country, Operator, IOT with which vendor / schedule / hardware & software) in LTE
or UMTS commercial network.

Q.645

Tenderer shall provide the evidence (ex. Certificate of IOT Forum) to prove the MVI / IOT had been suc-cessfully completed.

Q.646

Tenderer shall state the reference site / network scenario for MVI with other vendors.

Q.647

Tenderer shall pass the Buyers MVI activity in Buyers LAB for the Buyers assigned EPC vendors.

Q.648

Tenderer shall provide the list and test detail of successful Network IOT with Tenderers E-UTRAN / UTRAN equipment

Q.649

Tenderer shall provide the list and test details of successful UE IOT with Tenderers E-UTRAN (or UTRAN) via Uu interface.

9.19.4.

Inter-Radio Access Technology (IRAT)

Q.650

Tenderer shall offer LTE System comply with all IRAT relevant requirement stated in 3GPP standard (ex. 3GPP TS36.300, R10). Please detail the standard
compliance for every IRAT scenario.

Q.651

Tenderer shall provide detailed IRAT message flow, mechanism and global reference (ex. test case, test plan and test results) regarding below IRAT scenarios

Q.651
A.
Q.651
B.
Q.652

IRAT E-UTRAN to UTRAN (LTE > UMTS)

Q.653

Tenderer shall state the CSFB / SRVCC / VoLTE message flow and time consuming under IRAT mobility or handover

Q.654

Tenderer shall detail the feature support (Software version & Timeframe) for IRAT mobility and handover based on coverage / loading / environment / distance.

IRAT UTRAN to E-UTRAN (UMTS > LTE)

Tenderer shall state the Voice / PS flow under IRAT mobility or handover

9.20.

Acceptance Test Plan (ATP)

Q.655

Tenderer, under Buyers witness, shall provide & perform Acceptance Test Plan, in Lab first before in live network, with the following tests for each time of
upgrade

Q.655
A.
Q.655
B.
Q.655
C.
Q.656

Node Acceptance Test (NAT)

Q.657

The Buyer reserves the right to add or modify the test objects and cases before ATP plan is approved and signed by Buyer and final Contractor.

Q.658

The final Contractor shall be responsible for preparation of all the test tools, test instruments, test terminals / handsets, manpower resource, vehicles and other
whichever are needed for the aforesaid tests during test period.

Q.659

The final Contractor shall be responsible to complete the aforesaid tests through passing all the test cases with the Buyers approval without any additional cost to
the buyer.

Q.660

All the test records of the aforesaid tests shall be signed by the Contractor and countersigned by the Buyer after it has been proved that the system is
successfully tested and verified in accordance with the Contract. The signed copies of the test records shall be both retained by the Buyer and the Contractor.

Q.661

The ATP process in illustrated as the diagram below necessary activities and reports / lists / records.

Q.662

In additional to ATP plan proposed by Contractor, Contractor also need to include the test plan to comply the KPI criteria , Buyer reserves the right to determine if
the KPI is acceptable with convincing supportive justification provided by vendor.

9.20.1.

NAT

Q.663

The contractor shall perform the NAT for each and every network element / node offered as per the SA plan signed by Buyer and Contractor.

Q.664

Before NAT is conducted, the on-site checkup for the furnished network elements / nodes shall be performed including hardware, software and relevant
documents etc. all of the checklists and test records shall be signed by the Contractor and countersigned by the Buyer after it has been proved that the element /
nodes is delivered, installed, and successfully tested and verified with stand-alone functions in accordance with the Contract. The signed copies of the checklists
and the test records shall be both retained by the Buyer and the Contractor.

9.20.2.

SAT

Q.665

SAT shall consist of Functionality Test and Load Test shall be carried out as follows:

Q.666

Contractor shall coordinate with the Buyer for commencement of the Functionality Test after completion of the Works. If the NCC & CIB/MJIB inspection is
required for the Works, the Buyer will then apply for the NCC & CIB/MJIB Inspection with the Contractors support after Functionality Test. The Contractor and the
Buyer shall then jointly commerce the Load Test for one week after the NCC & CIB/MJIB inspection, or directly after Func-tionality Test if NCC & CIB/MJIB
inspection is not required.

Q.667

In the case of any other software upgrade, one week of Load Test shall be carried out directly after Func-tionality Test for each time of the software major
upgrade.

System Acceptance Test (SAT)

User Acceptance Test (UAT, only in live network)
Tenderer shall submit the ATP document to state how to proceed NAT, SAT, and UAT, which shall include the test objects and associated test cases, test
methods and steps, test environment and instruments / tools re-quired, test schedule and duration, repeated times per test case, and pass / fail criteria, before the
ATP is con ducted.

9.20.2.1. Functionality Test

Q.668

When all works are completed and ready for the Functionality Test, the Contractor shall notify the Buyer. The Buyer well, upon receiving notification from the
Contractor, decide and inform the Contractor of the date for Functionality Test.

Q.669

If major faults occurred in the supplied equipment and/or installation, which may adversely affect the system operation. The Buyer will assume that the system is
not ready for the Load Test unless the faults have been cured.

Q.670

The Functionality Test will be deemed as Pass by the Buyer. If no fault or only minor fault, shortage defi-ciencies, occurred in the supplied equipment and/or
installation, which may not adversely affect the system operation. The Buyer reserves the rights to judge the aforesaid minor fault and/or deficiencies and the
minor fault, shortage, and/or deficiencies and shall be supplemented or re-fumished before the UAT.

9.20.2.2. Load Test

Q.671

The Buyer will decide and inform the Contractor of the date for the Load Test after the Functionality Test is Pass

Q.672

During the Load Test, real or simulated traffic shall be loaded onto the LTE-UTRAN (or UMTS UTRAN) & Core Network nodes to prove the performance of the
offered LTE E-UTRAN (or UMTS UTRAN) to meet the requirement on continuous operation under traffic loaded for one week

Q.673

If major faults such as inter-working problems between the offered LTE E-UTRAN (or UMTS UTRAN) and the Buyers existing systems, other operators mobile
and fixed networks are found, all of the which adversely affect the system operation, the Contractor shall repeat the Load Test for another one weeks at his
expense after the faults have been cleared. The system will be deemed as having failed the Load Test unless major faults have been cured.

Q.674

The Load Test will be deemed as Pass by the Buyer, if no fault or only minor fault or deficiencies, which may not adversely affect the system commercial
operation. The Buyer reserves the right to judge the aforesaid minor fault and/or deficiencies and shall be supplemented or re-furnished by the Contractor.

9.21.

Test Tools for Field Measurement

9.21.1.

General Requirement

Q.675

This section includes tools for 3G and 4G Network related requirement; Tenderer shall provide tools as below, but not limit to

Q.675
A.
Q.675
B.
Q.675
C.
Q.676

3G and 4G Radio Network planning tool.

Q.676
A.
Q.676
B.
Q.676
C.
Q.676
D.
Q.677

LTE FDD measurement

Q.677
A.

Portable tools:
Smartphone (Android & iOS & others)
Tablet (Android & iOS & others)

Q.677
B.
Q.677
C.
Q.677
D.
Q.677
E.
Q.677 F.

Outdoor Drive Test Tool with LTE Data card & LTE Phone

Q.678

Field Measurement / Drive-Test Tool

Miscellaneous Tool Requirement
Tenderer provided tools shall have general requirement as below but not limit.
Support technologies

3G (3.5G) measurement
Wi-Fi measurement
Others
The RAN tool shall measures service quality directly from different types of devices and provide number of tools (include Buyers Lab needs) as below:

Modulized Outdoor Drive Test Tool with LTE Data card & LTE Phone
Scanning receiver
External GPS
Other (i.e. accessory)

All tools shall support LTE Downlink at least 100Mpbs, Uplink at least 50Mbps.
The RAN tool shall instantly delivers LTE and 3G QoE insight to tablet or laptop in real-time.

Q.679

Tool can test LTE 4G, 3G and Wi-Fi QoE performance, with all the KPIs, graphs and charts from Stationary test, Walk test, Drive test,

Q.680

The RAN tools shall include post-processing analysis system.

9.21.4.

Radio Network Planning Tool

Q.681

Tenderer shall provide the radio network planning tool in each region (i.e. 4 for each region and 1 in head quarter)

Q.682

Tenderer shall introduce and train buyer how to use the tool

Q.683

The radio networking planning tool shall include but not limited 3G, 4G, and beyond 4G

Q.684

The radio network planning tool shall include but not limit

Q.684
A.
Q.684
B.
Q.684
C.
Q.684
D.
Q.684
E.
Q.684 F.

Supports Evolved UTRA (3GPP Release 10 LTE Advance) Networks

Various frequency bands
Scalable channel bandwidths
Resource blocks per channel and sampling frequencies
FDD and TDD frame structures
Half-frame / Full-frame switching point periodicities for TDD

Q.684
Normal and extended cyclic prefixes
G.
Q.684
Downlink and uplink control channels and overheads (Downlink and uplink reference signals, P-SCH, S-SCH, PBCH, PDCCH, PUCCH, etc)
H.
Q.684 I. Physical cell IDs
Q.684 J. Signal level based coverage planning
Q.684
CINR based coverage planning
K.
Q.684 L. Network capacity analysis using Monte Carlo simulations
Q.684
M.
Q.684
N.
Q.684
O.
Q.684
P.
Q.684
Q.
Q.684
R.
Q.684
S.
Q.684 T.

Scheduling and resource allocation in two-dimensional frames

Q.684
U.
Q.685

Tenderer shall help buyer to run the simulation based on the NCC requirement

Q.686

The planning toll have to support Multi-RAT planning and below functions in a unified GSM / UMTS / LTE network

Q.686
A.
Q.686
B.
Q.686
C.
Q.686
D.
Q.686
E.
Q.686 F.

Database with site and antenna sharing.

9.21.5.

Field Measurement Tool

Multiple Input Multiple Output (MIMO) systems

Transmit and Receive Diversity
Single-User MIMO (Spatial Multiplexing)
Adaptive MIMO Switch (AMS)
Multi-User MIMO (Collaborative MIMO) in uplink
Automatic allocation of neighbors, physical cell IDs, and frequencies (AFP) (optional)
Network verification possible using test mobile data

The radio planning tool shall be able to input buyer existing drive tool and output the result based on buyer requirement

Multi-service traffic model

Monte-Carlo simulator
Display UMTS and LTE networks simultaneously
Automatically allocate neighbors between UMTS and LTE network
Support inter-technology interference analysis

Q.687

Tenderer RAN tool shall measures service quality directly from different type of devices as below but not limited:

Q.687
A.
Q.687
B.
Q.687
C.
Q.687
D.
Q.688

Smartphones (Android & iOS)

Q.689

Tool can test LTE 4G, 3G and Wi-Fi QoE performance across network, with all the KPIs, graphs and charts from Walk test. Drive test. Stationary test.

Q.690

The RAN tool shall measure times and KPIs as below but not limited:

Q.691

Support technologies:

Q.691
A.
Q.692

LTE FDD / TDD measurement

Q.692
A.
Q.692
B.
Q.692
C.
Q.692
D.
Q.693

Mobile Phone

Q.693
A.
Q.693
B.
Q.693
C.
Q.693
D.
Q.693
E.
Q.693 F.

FTP DL / UL

Q.693
G.
Q.693
H.
Q.694

VoIP call (Voice Quality)

Q.694
A.
Q.694
B.

Support at least 4 operators networks benchmarking and measure 4 operators network KPI at same time.

Q.694
C.
Q.695

Support scanning receiver test

Q.695
A.
Q.695
B.
Q.696

System lock (lock to LTE FDD / TDD)

Q.696
A.
Q.696
B.
Q.697

Support MapInfo for outdoor map.

Q.698

The RAN tool shall support KPIs measurement.

Tablet (Android & iOS)

Modulized Outdoor Drive-test Tool
Non-Modulized Outdoor Drive-Test Tool (Mobile / Dongle direct connected)
The RAN tool shall instantly delivery LTE and 3G QoE insight to tablet or laptop in real-time.

The RAN tools shall Support test UEs

Data Card
Scanning Receiver
External GPS
The RAN tool shall Support to edit script and repeat the following test items:

HTTP DL / UL for data transfer.

ICMP Ping
Web browsing
Video Streaming (RTSP)
Youtube streaming (HTTP)

IP capture
The RAN tool shall Support benchmarking test.

Outdoor drive-test tool shall support at least 4 UEs for LTE data DL / UL throughput test. Modulized Outdoor Drive-test Tool shall support at least 8 UEs for LTE
data DL / UL throughput test.

The RAN tool shall support forcing features.

Band lock (Lock to LTE FDD / TDD specific band such as 700, 900, 1800, 2100, 2600 MHz)
The RAN tool shall support outdoor (Mobility) / indoor (Stationary) measurement.

Support BTS file into show on map.

The RAN tool shall support CSFB and VoLTE test (Voice Quality)

Q.698
A.
Q.698
B.

Q.698
C.

Q.698
D.

Q.698
E.

Cell Measurement (for each cell): Band Chanel number (EARFCN) Physical cell identity RSSI RSRP RSRQ
Current Cell information:
Chanel number (EARFCN)
Cell identity
Tracking area code
MCC / MNC
MME group ID
MME code
M-TMSI
RRC state
Cell bandwidth
Transmission mode
Automatic neighbor relations (ANR) CGI reporting
TDD DL / UL configuration
Detected antenna port
Service status
CQI:
Wideband CQI per codeword
Subband CQI per codeword
Requestdt rank.
Signaling message:
RRC message
NAS message

Physical channel information:

PDSCH throughput
PDSCH BLER
PUSCH throughput
PUSCH TX power
LTE precoding matrix indicator (PMI)
SNR

Q.698 F. Link adaptation (for one modulation / PRB allocation per sample duration):
PDSCH / PCSCH rank
PDSCH / PCSCH modulation and MCS per codeword
PDSCH / PCSCH PRB allocation
PDSCH / PCSCH DTX TTIs
Q.698
G.

RACH parameters:
RACH type
RACH reason.
RACH result
RACH access delay
RACH contention resolution failures
RACH preamble count
RACH preamble initial TX power
RACH preamble index

Q.698
H.

Cell reselection / handover / tracking area parameters:

Cell reselection event
Handover events (attempt / success / failure)
Handover type
Tracking area update events (attempt / success / failure)
Tracking area update type
Tracking area update failure cause
Handover duration

Q.698 I. LTE measurement event

Event A1 ~ A5
Event B1, B2

Q.698 J. Scanning receiver parameters

RSRP
RSRQ
CINR
Antenna port
Ch / PCI
Decode BCCH info (SIBs Cell id)
9.21.6.

4G Lab Requirement

Q.699

Tenderer shall provide one LTE RAN system including OAM and SON feature for Buyers Lab. LTE RAN Network shall include but not limited to the following
elements and functions as the same with Live system:

Q.699
A.

eNodeB (at least 2 sets for different type of model including outdoor / indoor, Macro / Micro, Compact and Distributed type, and each configuration shall be with 3
sectors)

Q.699
B.
Q.699
C.
Q.699
D.
Q.699
E.
Q.699 F.

NTP with GPS

Q.699
G.
Q.700

IRAT / CSFB

Q.701

Tenderer shall provide one 3G RAN system including OAM for Buyers Lab. LTE RAN Network shall include but not limited to the following elements and functions
as the same with Live system:

Q.701
A.
Q.701
B.
Q.701
C.
Q.701
D.
Q.701
E.
Q.702

RNC

Q.703

Tenderer shall provide the identical equipment to Live System including all the hardware, software, interface, configuration, capacity, services and functions with
license but not accept temporary. All provided hardware / software version, interface, services and functions of the lab system shall be exactly identical to the
production system.

Q.704

The eNodeB shall comply with the overall feature set identified in 3GPP R10 and backward compatible to R9 and R8 as the same with live.

Q.705

The eNodeB shall provide the CA (Carrier Aggregation) as the same with live and support Frequency band combination and Bandwidth Combination for CA.

Q.706

The eNodeBs frequency and bandwidth shall be the same with live system and list as following

Q.706
A.
Q.706
B.
Q.706
C.

Band 3 (1800 MHz FDD mode) for UMTS / LTE

OSS
SON
Antenna & Accessory (attenuator, splitter )
MSR

Tenderer shall provide best combination of 3 scenarios below in single Base Station platform (Single RAN) as the same with Live system and consider remote RF
unit solution.
Scenario 1: 900MHz + 1800MHz
Scenario 2: 700MHz + 1800MHz
Scenario 3: 700MHz + 900MHz + 1800MHz

Node B (at least 2 sets for different type including Macro, Remote and SmallCell with 3 sectors).
EMS or OSS
Antenna & Accessory (attenuator, splitter )
MSR
Tenderer shall list the required Hardware, Software and Service item in the BOM for buyers approval.

Band 8 (900 MHz FDD mode) for UMTS / LTE

Band 28 (APT700 FDD mode) for LTE

Q.706
D.

Band 1 (2100 MHz FDD mode) for UMTS and LTE

Channel Bandwidth shall support flexible modification between 5MHz, 10MHz, 15MHz and 20MHz as the same with live

Q.707

The NodeBs frequency and configuration shall be the same with live system and list as following

Q.707
A.
Q.707
B.
Q.708

900MHz (Band 8) for 2 + 2 + 2 configuration

Q.709

Tenderer shall provide complete SON function with OSS system which is the same with live system

Q.710

Tenderer shall provide all required L2 / L3 switch for eNodeB and 3G RAN system setup and shall support Gigabyte Ethernet, have both electric interface and
fiber interface (totally at least 24 ports) for extension ability and have redundancy design include power and system board.

Q.711

The eNodeB and 3G RAN system shall support work in multiple clock synchronization modes and support multiple synchronization mechanism including GPS,
IEEE1588v2, Sync E, IP clock, Bits, E1 / T! and shall provide the same synchronization mechanism to Lab system with live system. Tenderer shall set up and
complete the Lab system prior to the installation of the live system and provide the test tool equipment, documentation, procedures and technical support for
verifying all the services and features.

Q.712

Tenderer shall successfully integrate the LTE-RAN with Buyers existing lab 3rd party LTE EPC system.

Q.713

Tenderer shall successfully integrate the 3G RAN system with Buyers existing Lab LTE EPC system for i-RAT / CSFB capability.

Q.714

Tenderer shall successfully integrate the LTE RAN system with Buyers existing 3G network for i-RAT / CSFB capability and Wi-Fi system for traffic offload
available. (Optional)

Q.715

Tenderer shall successfully integrate the 3G RAN system with Buyers existing lab 3G network and Wi-Fi system for traffic offload availability

Q.716

Tenderer shall include Labs acceptance as part of live network acceptance.

Q.717

Tenderer shall provide the Lab Project Plan including but not limited to the scope, schedule, for the Buyers approval.

Q.718

Tenderer shall provide the Lab engineering plan including but not limited to network architecture and MoP and shall be updated upon the changes of the plan
within one week for the Buyers approval

Q.719

Tenderer shall provide the Lab acceptance test plan including but not limited to NAT, SAT for buyers ap-proval.

Q.720

Tenderer shall provide the training courses for all Lab elements include but not limited to the system from basic level to specialist level in hardware, software,
system planning, installation, operations and maintenance, and testing shall be provided.

Q.721

Tenderer shall provide the Lab service support including but not limited to hardware and software, O&M service without any extra cost when the Lab system has
troubles.

9.22.

Technical Documentation

9.22.1.

General Requirements

Q.722

Documentation is defined as all necessary written and visual documentation fro the offered RAN equipment and associated training that final Contractor have to
deliver to Buyers when shipping equipment. The docu-mentation shall contain sufficient details, presented clearly and concisely, to enable the Buyers personnel
to operate and maintain the system in an efficient and correct manner.

Q.723

The documentation shall be provided both in electronic from (CD-ROM / diskette) and paper (hard copy) as needed and requested by the Buyer.

Q.724

The Tenderer shall provide a minimum of 5x printed copies and 10x CD-ROM of all documentation.

Q.725

The buyer reserves the right to copy the documentation for its own use.

Q.726

All text in documentation shall be typed.

Q.727

The timing for documentation delivery should be stated in provided Project Plan and be granted by Buyer

9.22.2.

Documentation Language

2100MHz for 3 + 3 + 3 configuration

Tenderer shall provide 2x2 MIMO equipment for above LTE & 3G RAN system and they are for future 4x4 reuse and expandable.

Q.728

All documentation shall be provided in English or Chinese.

Q.729

All terms and abbreviations shall be in accordance with international standards, when existing.

Q.730

The Tenderer shall provide the document in Chinese for those regulatory requirements requested by NCC or Government departments.

9.22.3.

Documentation Composition

9.22.3.1. System Survey

Q.731

The system survey is the high level part of documentation and describes the main functions and components of the equipment. The system survey shall contain,
among other items, survey drawings and general descriptions of the system and shall contain references to move detailed descriptions.

9.22.3.2. Installation Documentation

Q.732

In additional to paper and CD-ROM copies of installation documentation, the Tenderer shall also supply electronic copies of floor plans and diagrams in Computer
Aided Design (CAD) from and grant to the Buyer permission to allow architects of sites to use such CAD diagrams in their architectural design of site locations.
Architects will be obliged to sign non-disclosure agreements covering such information.

Q.732
A.

Installation Drawings
Floor plans
Assembly drawings

Q.732
B.

Cabling plans / wiring drawings

Cable route lists
Cable connection schematics
Bay connection diagram
Rack connection diagram

Q.732
C.
Q.732
D.

Power supply diagram

Test instructions / procedures
Test points with indication of normal values
Recommended measuring equipment
Measuring procedures

9.22.3.3. Hardware Documentation

Q.733

The hardware documentation shall contain diagrams, drawings, and descriptions of all hardware and It shall be easy to use. There shall be a table of contents and
complete list and index of all diagrams, drawings, and figures for each set of documentation.

Q.734

The following shall be included in the documentation:

Q.734
A.
Q.734
B.

Survey schematics and module descriptions

Q.734
C.

Top-level diagram
System diagram
Other top-level diagrams

Functional diagrams
Block diagrams
Logic diagrams

Q.734
Floor layout plan
D.
Q.734
Layout plan showing the position of the units within the racks
E.
9.22.3.4. Software Documentation
Q.735

The software documentation listed below shall be regarded as a minimum. The buyer reserves the right to require more detailed documentation when needed.

Q.735
A.

Software feature list with indication as follows: Basic or optional Purchased or not-purchased Enabled or not enabled Correlation with other necessary
features to together fulfill specific functionality

Q.735
Provide feature description (word format) of every software feature whichever is purchased / not-purchased, enable / not-enabled, or basic / optional
B.
Q.735
Provide total basic and optional list (excel format) for recommended SW version and future version of feature / roadmap with two years.
C.
9.22.3.5. Operations and Maintenance Documentation
Q.736

The Operations and Maintenance documentation shall cover all functions for network operations and maintenance.

Q.737

The supplied documentation shall contain information that enables the operations and maintenance staff to easily identify and isolate network failures. The
documentation shall direct the user through the step-by-step measures and the diagnosis program to use, if necessary.

Q.738

Man-machine commands and expected responses to these shall be easy to find. Normally, it shall not be necessary to take notes or make calculations manually
during these operations.

Q.739

A complete set of documentation for system restart shall also be provided. This shall be function oriented and in alphabetical order.

Q.740

Documentation for operations and maintenance shall at least include:

Q.740
A.
Q.740
B.
Q.740
C.
Q.740
D.
Q.740
E.
Q.740 F.

Paper and electrical manual with on-line help instructions

Q.740
G.

Routines including:
Operation routines
Emergency routines (specified in detail)

Trouble shooting manual, standard process and necessary tools

Users manual for each type of equipment monitored by the OMC or NMC
Man-machine commands and functional descriptions of these
Alarm printout manuals, including indications of alarm classes
Fault diagnosis manuals

Q.740
Descriptions of procedures foe changing system configuration data
H.
Q.740 I. Description of how traffic measurements are derived and what data is presented to user
Q.740 J. Description of all network supervision functions
Q.741

All tables for operation of the equipment shall be delivered ready for use. They shall be arranged in a way that makes them easy to use and easy to change.

Q.742

Tables for routing, billing and signaling shall be clearly set out and arranged in a way that makes them easy to use or change.

Q.743

The Tenderer shall provide: Hardware Service Unit List (SUL)

Q.744

The Tenderer shall provide: Spare Part List

9.22.3.6. System Dimensioning and Parameters

Q.745

Documentation shall be available for dimensioning rule or principle, dimensioning or radio tuning parameters, system limitations, and procedures for changing
system configuration caused by extensions of the equipment or introduction of new facilities / functions.

9.22.3.7. Training Documentation

Q.746

Course documents from basic level to specialist level in hardware, software, system planning, installation, operations and maintenance, and testing shall be
provided.

9.22.3.8. Documentation Delivery Time

Q.747

The Contractor shall offer in a timely manner all necessary manuals and drawings for the system to be de-livered. Unless otherwise agreed upon on an individual
basis, the documentation shall be delivered as described in the table that follows:

9.22.3.9. Requirements for Updating Documentation

Q.748

In the event of physical or functional revisions or changes in the system, the revised document to reflect the system revisions / changes shall be supplied by the
Tenderer no later than 1 month after the revisions / changes are done.

Q.749

The synchronization performance shall be tested and accepted by the Buyer with test result in live network

10

Evolved Packet Core (EPC) Technical Requirement

10.1.

Evolved Packet System (EPS) Architecture

Q.750

The Tenderer shall provide the logical architecture for 3GPP access of its overall EPC solution for non-roaming and roadmap scenarios

Q.751

The Tenderer shall provide the logical architecture for secure interworking with trusted and un-trusted non-3GPP access with the proposed overall EPC solution.

10.2.

Evolved Packet Core (EPC) Roadmap

Q.752

The Tenderer shall provides its software detailed product development plans fro the MME and S-GW / P-GW.

Q.753

The Tenderer shall provides its hardware detailed product development plans for the MME and S-GW / P-SW.

10.3.

Evolved Packet Core (EPC) IOT Experience

Q.754

The Tenderer shall provide the details successfully performed interoperability test (IOT) of 3GPP reference point.

Q.755

The Tenderer must commit to supporting initiation IOT testing for the relevant 3GPP reference points as well as long term commercial support of multi-operator,
inter-operability and on-going testing required as new soft-ware versions are release by other Vendors.

10.4.

MME Functional Requirement

Q.756

The Tenderer shall provide the logical architecture of its MME product. The Tenderer shall indicate whether MME is a new standalone product and planned
evolution to support legacy SGSN in one system. Please provide the roadmap.

Q.757

Hardware and Software Requirements

Q.758

The Tenderer shall provide a description of MME hardware platform.

Q.759

The Tenderer shall indicate the maximum capacity of the MME.

Q.760

The Tenderer shall indicate if each board is a plug-in unit for the node.

Q.761

The Tenderer shall describe the redundancy techniques supported by plug-in units.

Q.762

The Tenderer shall list single point of failure (SPOF), and will detail and explain how SPOFs are prevented. The Tenderer will also identify the impact on the user
traffic.

Q.763

The Tenderer shall describe the dimensions of the MME chassis.

Q.764

The Tenderer shall explain how the high availability of MME platform is ensured.

Q.765

The Tenderer shall indicate how the context and session continuity are maintained after the failure of hardware component in the proposed MME equipment.

Q.766

The Tenderer shall list down the supported environment standards by the MME equipment.

Q.767

The Tenderer shall specify the procedure to upgrade the equipment from HW N to HW N+1. In particular, the Tenderer will specify the impacts of the upgrade on
the hardware configuration (e.g. boards, processor to be changed, etc.)

Q.768

The Tenderer shall indicate which middleware / operating system is used in the MME software.

Q.769

The Tenderer shall present an overview description of the MME software architecture. The Tenderer will describe the main software module functions.

Q.770

The Tenderer shall provide the description of the minimum configuration platform.

Q.771

The Tenderer shall provide the description of the maximum configuration platform.

Q.772

The Tenderer shall explain how the scalability of its overall solution is ensured.

Q.773

The Tenderer will describe how 99.999% availability could be ensured with its solution.

Q.774

The Tenderer will provide high availability figures (MTBF, MMTR) for the MME system configuration.

Q.775

The Tenderer shall support the fail-over / switch-over mechanisms.

Q.776

The Tenderer shall describe power distribution on the chassis with DC power supply.

Q.777

The Tenderer shall indicate if the equipment is designed to achieve reduced power consumption targets on the whole system as well as individual components,
within the constraint of the operational specifications.

Q.778

The Tenderer shall provide the details of functional units which support load balancing or load sharing.

Q.779

The Tenderer shall support the redundancy and recovery mechanism used by the MME.

Q.780

The Tenderer will describe the different software failure and / or restart levels of the node

Q.781

The Tenderer will give the duration of service interruption in the case of a node restart.

Q.782

The Tenderer shall support the overload protection mechanism used in the case of overload situations.

Q.783

The Tenderer will detail how new user transactions are processed in case of traffic overload.

Q.784

The Tenderer shall specify the capacity and performance of its MME and HW flexibility.

Q.785

In case of combined MME / SGSN, the Tenderer will indicate how the capacity is shared between MME and SGSN functions: is it statically configured or is.

Q.786

The proposed MME shall support S1-MME reference point toward E-UTRAN based on S1-AP / SCTP.

Q.787

The proposed MME shall support NAS signaling with the UE.

Q.788

The proposed MME shall support Gn /Gp reference point towards Pre Release 8 SGSN for inter-3GPP mo-bility based on GTP-C / UDP protocol.

Q.789

The proposed MME shall support S6a reference point towards HSS for transfer of subscription and authentication data based on Diameter / SCTP protocol.

Q.790

The proposed MME shall support S13 reference point towards EIR for ME identity check based on Diameter / SCTP protocol as optional.

Q.791

The proposed MME shall support S10 reference point towards another MME for relocation and MME-to-MME information transfer based on GTP-C / UDP
protocol.

Q.792

The proposed MME shall support S11 reference point towards SGW based on GTP-C / UDP protocol.

Q.793

The proposed MME shall support SGs reference point towards legacy network VLR based on SGs-AP / SCTP protocol.

Q.794

The proposed MME shall support Sv reference point towards legacy network MSC based on GTP-C / UDP protocol.

Q.795

The proposed MME shall support SLg reference point towards legacy network GMLC for location based services.

Q.796

The proposed MME shall support SLs reference point towards legacy network E-SMLC for location based services.

Q.797

The proposed MME node shall support 3GPP defined standard interfaces.

Q.798

The proposed MME shall support non-roaming architecture.

Q.799

The proposed MME shall support roaming architecture for Home Routed traffic.

Q.800

The proposed MME shall support roaming architecture for Local Breakout.

Q.801

The proposed MME shall be able to inter-work with Release 7 SGSN.

Q.802

The proposed MME shall be able to inter-work with Release 8 SGSN.

Q.803

The proposed MME shall support CS Fallabck (CSFB) for SMS.

Q.804

The proposed MME shall support CS Fallback (CSFB) for voice.

Q.805

The proposed MME shall support UEs with IMS voice PS session

Q.806

The proposed MME shall support Sv interface for SRVCC

Q.807

The proposed MME shall support MOCN.

Q.808

The proposed MME shall support MORAN feature and describe any impact on the MME.

Q.809

The proposed MME shall support MME pool area.

Q.810

The proposed MME shall support Globally Unique MME identifier (GUMMEI)

Q.811

The proposed MME shall support overload procedure on S-1 interface.

Q.812

The Tenderer will describe how overload in the signaling-plane is prevented.

Q.813

The Tenderer shall describe how overload is handled if it occurs in the element.

Q.814

The Tenderer shall describe how overload would affect the gateway, its sessions and the interaction with other nodes.

Q.815

The Tenderer will detail what actions are taken toward new user transactions in case of traffic overload in the PGW.

Q.816

The proposed MME shall support emergency services in overload condition.

Q.817

The proposed MME shall support load balancing in the network by providing appropriate weight factor to the eNodeB.

Q.818

The proposed MME shall support the selection of a PDN-GW as specified in TS23.401.

Q.819

The proposed MME shall support the selection of and S-GW as specified in TS23.401.

Q.820

Describe the PDN-GW selection procedure supported by the MME.

Q.821

Describe the S-GW selection procedure supported by the MME.

Q.822

The proposed MME shall support the SGW selection procedure under the S1-Flex architecture with multiple S-GW in the MME pool.

Q.823

The proposed MME shall update the HSS with the selected PDN GW identity, as well as information that identifies the PLMN in which the PDN GW is located.

Q.824

The proposed MME shall select a SGW based on network topology and Weight Factor of SGW

Q.825

The proposed MME shall support PDN type IPv4, IPv6 and IPv4v6 to UE.

Q.826

The proposed MME shall support comparison of requested PDN type by UE to the PDN type stored in the subscription data received from the HSS for an APN.

Q.827

The proposed MME shall set the PDN Type for a PDN connection as requested PDN Type by UE if it is al-lowed by the subscription data received from the HSS
corresponding to that PDN.

Q.828

If requested PDN Type for a PDN connection is IPv4v6 by UE and if subscription data from HSS only allow PDN Type IPv4 or only allows PDN Type IPv6, then
MME shall set the PDN Type according to the subscribed value. A reason cause shall be returned indicating that only the assigned PDN Type is allowed.

Q.829

If requested PDN type for a PDN connection is IPv4 or IPv6 by UE and if subscription data from HSS neither allows the requested PDN Type nor PDN IPv4v6,
then the MME shall reject the requested PDN connection re-quest.

Q.830

If requested PDN type for a PDN connection is IPv4v6 by UE and if subscription data from HSS allows both PDN Type IPv4 and PDN Type IPv6 but not allows
IPv4v6, then the MME shall set the PDN type to either IPv4 or IPv6.

Q.831

The proposed MME shall support simultaneous multiple PDN connectivity to one or multiple PDNs. The maximum value shall be configurable.

Q.832

The proposed MME shall support security mechanisms for cryptographically protecting NAS signaling ex-changed between the UE and MME in compliance with
3GPP TS33.401

Q.833

The proposed MME shall support EPS-AKA as the authentication and key agreement procedure.

Q.834

The proposed MME shall support authentication and key agreement in compliance with 3GPP TS33.401.

Q.835

The proposed MME shall support user identity confidentiality by supporting M-TMSI.

Q.836

The proposed MME shall support user data and signaling confidentiality by supporting ciphering and integrity to NAS signaling.

Q.837

The proposed MME shall be able to select NAS Integrity Protection and Ciphering algorithm(s).

Q.838

The proposed MME shall support ME identity check procedure.

Q.839

The proposed MME shall support intra-RAT security context transfer in compliance with 3GPP TS33.401.

Q.840

The proposed MME shall obtain the authentication vectors as part of the bearer context from the old MME via the MME Context procedures. If the new MME
cannot obtain any usable authentication vector from the old MME it will obtain authentication vectors from the HSS using the Authentication Request procedure.

Q.841

The proposed MME shall support security context transfer to/from GERAN and UTRAN in compliance with 3GPP TS23.401.

Q.842

The proposed MME shall support the AS security mode command procedure as defined in TS33.401.

Q.843

The proposed MME shall support the NAS Security Mode Command procedure as defined in TS33.401.

Q.844

The proposed MME shall check the IMEI provided by the UE against the EIP and terminate service to the UE if the IMEI is blacklisted.

Q.845

The proposed MME shall support the ability to request a UE to provide its IMEI in the NAS Security Mode Complete message.

Q.846

If APN provided by UE corresponding to a PDN for a PDN connection is not subscribed then the proposed MME shall reject attach procedure.

Q.847

The proposed MME shall support GUTI allocation and reallocation.

Q.848

The proposed MME shall support allocation and reallocation of Tracking Area Identity list.

Q.849

The proposed MME shall support Tracking Area Update (TAU) Procedures with / without SGW change.

Q.850

The proposed MME shall support Tracking Area Update (TAU) with / without MME change.

Q.851

The proposed MME shall support Routing Area Update with MME interaction and with / without SGW change.

Q.852

The proposed MME shall release all EPS bearers corresponding to a default bearer if that default bearer is not accepted by the eNodeB.

Q.853

The proposed MME shall support eNodeB and MME initiated S1 release procedure.

Q.854

The proposed MME shall support UE-initiated detach procedure with / without ISR activated.

Q.855

The proposed MME shall support implicit as well as explicit MME-initiated detach procedure.

Q.856

The proposed MME shall support SGSN-initiated detach procedure.

Q.857

The proposed MME shall support HSS-initiated detach procedure.

Q.858

The proposed MME shall deactivate all the non-emergency PDN connection in case of HSS-initiated detach procedure.

Q.859

The proposed MME shall support Purge Function to inform HSS about the deletion of subscription data.

Q.860

The proposed MME shall support for mapping between EPS and pre Release-8 QoS parameters.

Q.861

The proposed MME shall support mapping from EPS bearer QoS parameters to derive corresponding PDP context parameters if the network supports mobility to
UTRAN or GERAN.

Q.862

The proposed MME shall support dedicated bearer activation procedure.

Q.863

The proposed MME shall support PGW initiated bearer modification with & without bearer QoS update.

Q.864

The proposed MME shall support HSS initiated subscribed QoS modification with bearer QoS update.

Q.865

The proposed MME shall support PGW initiated bearer de-activation.

Q.866

The proposed MME shall support UE requested bearer resource modification.

Q.867

The proposed ME shall support restoration and recovery procedures.

Q.868

The proposed MME shall support X-2 based handover with / without SGW relocation. The proposed MME shall support S-1 based handover with / without SGW
relocation. MME may or may not relocate.

Q.869

The proposed MME shall support handover from E-UTRAN to UTRAN, UTRAN to E-UTRAN, E-UTRAN to GERAN, and GERAN to E-UTRAN network.

Q.870

The MME shall support Lawful Interception in accordance with 3GPP TS33.107

Q.871

The proposed MME shall support LI architecture for signaling and data path interception.

Q.872

The proposed MME shall support ENB Configuration Transfer procedure.

Q.873

The proposed MME shall support MME Configuration Transfer procedure.

Q.874

The proposed MME shall support addressing, routing and relaying functionality.

Q.875

The proposed MME shall be fully transparent fro Configuration Transfer procedure.

Q.876

The proposed MME shall support MME to 3G SGSN combined hard handover and SRNS relocation pro-cedure.

Q.877

The proposed MME shall support 3G SGSN to MME combined hard handover and SRNS relocation pro-cedure.

Q.878

The proposed MME shall support Gn / Gp SGSN to MME Tracking Area Update.

Q.879

The proposed MME shall support mapping between EPS and release 99 QoS parameters.

Q.880

The proposed MME shall support Paging for non-EPS services procedure.

Q.881

The proposed MME shall support Location update for non-EPS services procedure.

Q.882

The proposed MME shall support Non-EPS alert procedure.

Q.883

The proposed MME shall support Explicit IMSI detach from EPS services procedure

Q.884

The proposed MME shall support Explicit IMSI detach from non-EPS services procedure.

Q.885

The proposed MME shall support Implicit IMSI detach from non-EPS services procedure.

Q.886

The proposed MME shall support following procedures:

Q.886
A.
Q.886
B.
Q.886
C.
Q.886
D.
Q.886
E.
Q.886 F.

VLR failure procedure

Q.887

The proposed MME shall support PDN connection towards any APN requested by the UE with dynamic PGW allocation if one of the PDN subscription contexts of
the user contains a wild card APN.

Q.888

The proposed MME shall support authorization of UE to connect to APNs which are not present in subscription context if wildcard APN is present in subscription
context.

Q.889

The proposed MME shall support SBc interface for information with Cell Broadcasting Center (CBC)

10.5.

S/P-GW Functional Requirements

10.5.1.

General Requirement

Q.890

The Tenderer shall provide the logical architecture of its S/P GW product.

Q.891

The Tenderer will indicate if its S/P GW is a new standalone product, or is an evolution from legacy GGSN product, or if both possibilities are available. Provide
the roadmap.

Q.892

The Tenderer shall provide a description of the hardware platform used to implement its S/P-GW functionality.

Q.893

The Tenderer shall indicate if different HW configurations are possible. For each HW configuration, the Tenderer will indicate the capacity, number of chassis,
dimensioning parameters, etc.

Q.894

The Tenderer will indicate the type of external interfaces supported by S/P-GW

Q.895

The Tenderer will indicate if each board is a plug-in unit for the node.

Q.896

The Tenderer shall describe the redundancy techniques supported by plug-in units.

Q.897

The Tenderer will list single point of failure (SPOF), and will detail and explain how SPOFs are prevented. The Tenderer will also identify the impact on the user
traffic.

Q.898

The Tenderer will indicate if it is possible to stack several network elements together inside same rack. Please indicate the number of equipment per rack.

Q.899

The Tenderer shall describe the dimensions of the S/P-GW chassis.

Q.900

The Tenderer shall list down the supported environmental standards by the equipment

Q.901

The Tenderer will indicate which middleware / operating system is used in S/P-GW software

Q.902

The Tenderer will present an overview description of the S/P-GW software architecture. The Tenderer will describe the main software module functions.

Q.903

The Tenderer will indicate the number of boards dedicated to the administrative tasks of the node.

Q.904

The Tenderer will provide a logical diagram describing the mapping between the hardware units and the functional units. The interaction between the different
functional units shall also be described.

Q.905

The Tenderer will provide the description of the minimum configuration platform.

Q.906

The Tenderer will provide the description of the maximum configuration platform.

Q.907

The Tenderer will detail what are the operations to scale from minimum to maximum configuration.

Q.908

The Tenderer will explain how the scalability of its overall solution is ensured.

Q.909

The Tenderer will provide high availability figures (MTBF) for the S/P-GW node.

MME failure procedure

HSS failure procedure
MM information procedure
NAS messages tunneling procedure
Service request procedure

Q.910

The Tenderer will describe how 99.999% availability could be ensured with its solution.

Q.911

The Tenderer will define the network requirements of PGW pool to perform service continuity.

Q.912

The Tenderer will define the network requirements of SGW pool to perform service continuity.

Q.913

The Tenderer will detail the different fall-over/switch-over mechanisms implemented within its solution and specify the fail-over/switch-over duration and the
session context continuity.

Q.914

The Tenderer will describe the replication mechanisms that are implemented within its solution.

Q.915

The Tenderer shall describe power distribution on the chassis with DC power supply.

Q.916

The Tenderer shall indicate if the equipment is designed to achieve reduced power consumption targets on the whole system as well as individual components,
within the constraint of the operational specifications.

Q.917

The Tenderer will identify elements in charge of load balancing or load sharing. For each of them, the Tenderer will explain implementation and the rule of them.

Q.918

The Tenderer shall describe the redundancy and recovery mechanism used by the S/P-GW.

Q.919

The Tenderer will describe the different software failure and/or restart levels of the node.

Q.920

The Tenderer will give the duration of service interruption in the case of a node restart.

Q.921

The Tenderer will describe the overload protection mechanism used in the case of overload situations.

Q.922

The Tenderer will detail how new user transactions are processed in case of traffic overload.

Q.923

The Tenderer shall specify the capacity and performance of its S/P-GW and HW flexibility

Q.924

The Tenderer will provide what is the capacity in terms of packet per second forwarding with mean packet size?

Q.925

The Tenderer shall state the impact on CPU of L7 deep packet inspection to 100% of the traffic compared to no DPI activated at all in the PGW.

Q.926

The Tenderer shall state the number of rules that can simultaneously be activated for one user.

Q.927

The Tenderer shall state the number of filters that can be stored in the PGW.

Q.928

The S-GW shall support GTPv2-C protocol to carry signaling messages between S-GW and SGSN over S4 interface for interworking with 3G access.

Q.929

The S-GW shall support GTPv2-C protocol to carry signaling messages between S-GW and S-GW over S5/S8 interface.

Q.930

The S-GW MAY support PMIPv6/PMIPv4 protocol between S-GW and S-GW over S5/S8 interface.

Q.931

The S-GW shall support GTPv2-C protocol to carry signaling messages between MME and S-GW over S11 interface.

Q.932

The S-GW shall support GTPv1-U protocol to carry bearer packet between SGSN and S-GW over S4 in-terface.

Q.933

The S-GW shall support GTP protocol to carry signaling and bearer packet between S-GW and SGSN over S12 interface for interworking with 3G access using
direct tunneling.

Q.934

The S-GW shall support DIAMETER protocol to carry signaling messages between S-GW (PCEF) and PCRF over Gxc interface for PMIP based S8 interface.

Q.935

The P-GW shall support S5 and S8 interface over GTP protocols.

Q.936

The P-GW MAY support S8 interface over PMIPv6 protocol.

Q.937

The P-GW shall support S2a interface over PMIPv6 protocol for trusted non-3GPP IP access.

Q.938

The P-GW shall support S2b interface over PMIPv6 protocol for un-trusted non-3GPP IP access.

Q.939

The P-GW shall support S6b interface over Diameter or RADIUS protocol to communicate with AAA server for user authentication and IP address allocation.

Q.940

The P-GW shall support Gy interface over Diameter protocol for OCS.

Q.941

The P-GW shall support Gz interface over Diameter protocol for OFCS.

Q.942

The P-GW shall support SGi interface over Application protocol over IP.

Q.943

The P-GW shall support Gn/Gp interface over GTP protocol for pre-release 8 SGSN.

10.5.2.

Physical Interface Requirement

Q.944

The S/P-GW shall provide Gigabit optical and electrical interfaces.

Q.945

The S/P-GW may provide 10 Gig optical interfaces.

Q.946

The S/P-GW shall provide separate physical interfaces for control traffic and data traffic.

10.5.3.

P-GW Functionality and Feature Requirements

Q.947

The P-GW shall support IPv4 address allocation and IPv5 parameter configuration.

Q.948

The P-GW shall support IPv6 / IPv4 address allocation to UE via default bearer activation.

Q.949

The P-GW shall act as DHCPv6 client, if there is external DHCPv6 server exists in the network, when it al-locates IPv6 address to the UE through DHCPv6
procedure.

Q.950

The P-GW shall act as DHCPv4 Server, if there is no external DHCPv4 server in the network, when it allocates IPv4 address to the UE through DHCPv4
procedure.

Q.951

The P-GW shall act as DHCPv6 Server, if there is no external DHCPv6 server in the network, when it allocates IPv6 address to the UE through DHCPv6
procedure.

Q.952

The P-GW shall support IPv4 address release and renewal for a UE

Q.953

The P-GW shall support IPv6 address release and renewal for a particular UE.

Q.954

The P-GW shall support the usage of same IP address allocated to UE during default connection for the dedicated bearer connection within the same PDN.

Q.955

The P-GW shall support allocation of static IPv4 address and/or a static IPv6 prefix based on subscription data in the HSS.

Q.956

The P-GW shall function as a RADIUS Client towards Radius Server if IP allocation to the UE is via RADIUS procedure.

Q.957

The P-GW shall function as a DIAMETER Client towards DIAMETER Server to allocate IP address to the UE is via DIAMETER procedure.

Q.958

The P-GW shall support static routing functionality.

Q.959

The P-GW shall support dynamic routing functionality, please specify which routing protocols are supported by the element.

Q.960

The P-GW shall support access control list (ACL) feature.

Q.961

The P-GW shall support MPLS / BGP feature.

Q.962

The P-GW shall support GTP tunnel on S5 / S8 interface.

Q.963

The P-GW shall support separate GTP tunnel for default bearer and for each dedicated bearer per user on S5 / S8 interface.

Q.964

The P-GW MAY support GRE tunnel on S8 interface.

Q.965

The P-GW shall support GRE tunnel on S2a interface.

Q.966

The P-GW shall provide GRE tunnel on S2b interface.

Q.967

The P-GW shall support GRE encapsulation applicable for PMIPv6.

Q.968

The P-GW shall support user plane tunneling and tunnel management over S5 interface.

Q.969

The P-GW shall support GPRS Tunneling Protocol for the control plane (GTP-C) over S5 / S8 interface.

Q.970

The P-GW shall support GPRS Tunneling Protocol for the user plane (GTP-U) over S5 / S8

Q.971

The MTU size in P-GW shall be configurable through man-machine interface.

Q.972

The configuration of MTU in P-GW shall not be service affected.

Q.973

If the PMIP protocol is configured in P-GW for S5 / S8 interface, the GRE tunnel shall be used between P-GW and S-GW.

Q.974

The P-GW shall support congestion control and congestion avoidance policies.

Q.975

The P-GW shall perform admission control even for non-GBR bearer.

Q.976

The P-GW shall be capable to deny a new GBR bearer request when there is scarcity of resources in the system to provide such service.

Q.977

The P-GW shall support providing VPN / VPLS services to enterprise operators.

Q.978

The P-GW shall support IPSec based enterprise VPNs.

Q.979

The P-GW shall support L2TP based enterprise VPNs.

Q.980

The P-GW shall support GRE based enterprise VPNs.

Q.981

The P-GW shall support MPLS based enterprise VPNs.

Q.982

The P-GW (PCEF) shall use the DL TFT for mapping traffic to an EPS bearer in the downlink.

Q.983

The P-GW shall make it possible for an operator to use the default bearer for traffic that does not match any of the filters associated with the dedicated bearers.

Q.984

The P-GW (PCEF) shall support Deep Packet Inspection feature.

Q.985

The P-GW (PCEF) shall support appropriate configuration of DPI rule sets the applicability subscrib-er-association of which can be controlled from PCRF.

Q.986

The P-GW shall support IPv6 DPI functions.

Q.987

The P-GW shall support stateful L3 L7 DPI capabilities.

Q.988

The P-GW (PCEF) shall provide appropriate configuration framework which allows administrator to specify customized DPI rules based on following criteria: Layer4 protocol (i.e. TCP, UDP), Layer-4 ports (list and ranges of sources and destination, ports), Layer-7 protocol, HTTP host list or URL list for HTTP-based layer-7
protocols.

Q.989

Please provide the list of protocols and applications which can be detected using DPI.

Q.990

Using the DPI capabilities, P-GW (PCEF) shall be able to specific gating and charging policies to detected applications (e.g. blocking certain applications,
charging certain applications differently, etc.) within the 3GPP defined PCC framework.

Q.991

The Tenderer MUST commit to 90% detection usage in term of bandwidth, number of sessions, number of sessions / sec.

Q.992

The solution MUST support heuristic detection.

Q.993

Please explain the procedure of upgrade and the impact in term of availability.

Q.994

The P-GW shall provide the feature of Personal Firewall

Q.995

The P-GW shall act as the user plane anchor for mobility between 3GPP access and non-3GPP access.

Q.996

For PMIP-based S5 interface, the P-GW shall act as a LMA according to the PMIPv6 specifications.

Q.997

For PMIP-based S8 interface, the P-GW shall act as a LMA according to the PMIPv6 specifications.

Q.998

The P-GW shall support bearer tunnel establishment with multiple S-GW

Q.999

The P-GW shall implement PCEF functionalities as defined by 3GPP specifications.

Q.1000

The PCEF functionalities must be triggered by an external PCRF.

Q.1001

If the PCRF is not available, the PCEF component must support a default behavior.

Q.1002

PCEF functions shall be applicable to IPv4, IPv6 and IPv4v6PDP contexts and bearers in the same way.

Q.1003

PCEF functions embedded in the PDN-GW shall be applicable to all accesses.

Q.1004

Each feature MUST have a priority level in order to stop the lowest priority services in case of peak of load or service unavailability. Those lists shall be
configurable.

Q.1005

The solution must support configurable static and dynamic PCC rules.

Q.1006

The vendor is invited to explain how static PCC rules are configured in the PGW?

Q.1007

Please describe how dynamic and static PCC rules could be associated?

Q.1008

The vendor is invited to indicate the maximum number of simultaneous active PCC rules?

Q.1009

Please detail the impact on solution sizing?

Q.1010

The vendor is invited to give the limitation of the PGW in terms of number of pre-defined PCC rules?

Q.1011

Please specify if your solution proposes simplification mechanisms (e.g. use of wildcard) for the definitions of the pre-configured PCC rule or detection points?

Q.1012

The vendor will detail his implementation regarding detection points and PCC rule definition in his PCEF.

Q.1013

The PGW shall be able to trigger a Gx session to retrieve Policy and Charging rules from the PCRF before IP CAN session is established.

Q.1014

The PGW shall be able to active a pre-defined group of PCC rules which will be activated depending on the Charging Rule Name Base retrieved from the PCRF.

Q.1015

The PGW shall be able to define a default pre-defined group of PCC rules when the Charg-ing-Rule-Name-Base cannot be retrieved on the Gx interface.

Q.1016

The PGW shall be able to update single PCC rule, group of pre-defined PCC rules and/or dynamic PCC rules when it is required by the PCRF.

Q.1017

The PGW shall be able to install a new pre-defined group of PCC rules when required by the PCRF.

Q.1018

The PGW shall be able to apply IP CAN bearer modification when the PCRF provides new QoS information.

Q.1019

The PGW shall be able to perform bandwidth-limitation/traffic-shaping for a specific service data flow de-pending on QoS information within the Charging-RuleDefinition requested by the PCRF.

Q.1020

The PGW shall be able to deny or to allow access to a specific service or group of services based on user profile provided by the PCRF, and also other
parameters related to session (i.e. roaming status...)

Q.1021

The PDN-GW shall be able to push information about the session towards an external AAA server, using Radius protocol.

Q.1022

The vendor will specify how the Radius server interaction (host name can be configured in the PDN-GW (per APN, other).

Q.1023

The vendor will indicate all session attributes that can be forwarded by the PDN-GW to an external AAA server using Radius Protocol

Q.1024

The vendor will specify how the operator can configure Radius request types to forward to the external AAA server.

Q.1025

The Vendor will list all the parameters taken from session information (MSISDN, IMSI, RAT type, APN, Lo-cation information, Roaming information) that can be
used for HTTP header enrichment.

Q.1026

The PCEF shall support HTTP redirections (301, 302), based on PCEF static configuration.

Q.1027

The P-GW shall support UE attach procedure.

Q.1028

The P-GW shall support the Tracking Area Update procedure with S-GW change.

Q.1029

The P-GW shall support detach procedure.

Q.1030

The P-GW shall support X2-based handover without S-GW relocation.

Q.1031

The P-GW shall support X2-based handover with S-GW relocation.

Q.1032

The P-GW shall support S1-based handover with S-GW relocation.

Q.1033

The P-GW shall support S1-based handover without S-GW relocation.

Q.1034

The P-GW shall support activation/modification/deletion of default bearer and dedicated bearers. The P-GW shall support operations for non-GBR default bearer.

Q.1035

The P-GW shall support operations for non-GBR dedicated bearer.

Q.1036

The P-GW shall support operations for GBR dedicated bearer.

Q.1037

The P-GW shall initiate a bearer update procedure, if the PCRF response leads to an EPS bearer modifica-tion.

Q.1038

The P-GW shall support dedicated bearer activation procedure for a GTP based S5/S8.

Q.1039

The P-GW shall support P-GW initiated bearer modification procedure (including EPS Bearer QoS update) for a GTP based S5/S8.

Q.1040

The P-GW shall support HSS Initiated Subscribed QoS Modification for a GTP-based S5/S8.

Q.1041

The P-GW shall support P-GW initiated bearer modification without bearer QoS update.

Q.1042

The P-GW shall be able to provide charging functionality for each UE.

Q.1043

The Vendor shall indicate whether IPv4, IPv6 and IPv4andIPv6 end user addresses are supported over Gy interface?

Q.1044

The solution shall be able to perform credit control at service level.

Q.1045

The Vendor shall specify which network events can trigger start of the Gy session?

Q.1046

In case where the operator wants to charge data services by using "flow based charging" principles, please specify if it is possible to trigger the Gy session on
reception of the first packet related to the first service de-tected?

Q.1047

P-GW without a Gx interface shall be able to support flow based online and offline charging based on local configuration and interaction with the Online and
Offline Charging Systems.

Q.1048

The P-GW shall be able to collect and report, for each UE, accounting information, i.e. the amount of data transmitted in uplink and downlink direction categorized
with the QCI and ARP pair per UE per PDN connection.

Q.1049

The P-GW shall be able to collect and report, accounting information per UE and per bearer for GTP-based S5/S8.

Q.1050

The P-GW shall receive Charging Characteristics from the Serving GW through GTP-S5/S8, or through PMIP for PMIP-based S5/S8.

Q.1051

The vendor will provide the list of the QoS parameters (including UMTS/2G specific parameters) which are supported?

Q.1052

The vendor shall detail the use of each QoS parameters (QCI ARP, MBR) in each core node: MME, S-GW, P-GW for admission control?

Q.1053

Please provide a list as well as a short summary of all QoS control features by nodes (shaping, gating, prioritization, admission control). Please provide the
involved QoS parameters for each feature.

Q.1054

Please provide the list of QOS functionalities supported by the offered elements.

Q.1055

The P-GW shall support IPSec to connect to remote network over SGi interface.

Q.1056

The P-GW shall act as the user plane anchor for mobility between 3GPP access and non-3GPP access. Please describe different supported accesses.

10.6.

S-GW Functionality and Feature Requirements

Q.1057

The S-GW shall support E-UTRAN initiated UE Attach procedure.

Q.1058

The S-GW shall support UTRAN/GERAN initiated UE Attach procedure.

Q.1059

The S-GW shall support UE, SGSN, MME, S-GW and HSS initiated UE Detach procedure.

Q.1060

The S-GW shall support the Tracking Area Update procedure with S-GW change and without S-GW change.

Q.1061

The S-GW shall support the Routing Area Update procedure with MME interaction and with or without S-GW change.

Q.1062

The S-GW shall support UE triggered Service Request procedure.

Q.1063

The S-GW shall support Network triggered Service Request procedure.

Q.1064

The S-GW shall support S1 Release procedure.

Q.1065

The S-GW shall support HSS Initiated Subscribed QoS Modification for a GTP-based S5/S8.

Q.1066

The S-GW shall support creation, modification and deactivation of dedicated bearer for a GTP based S5/S8 interface.

Q.1067

The S-GW shall support creation, modification and deactivation of default bearer for a PMIP based S5/S8 interface.

Q.1068

The S-GW shall support creation, modification and deactivation of dedicated bearer for a PMIP based S5/S8 interface.

Q.1069

In case of default bearer deactivation to a particular PDN connection, the S-GW shall deactivate all dedicated bearer associated to that PDN connection also. This
shall irrespective of GTP based or PMIP based S5/S8 interface.

Q.1070

The S-GW shall support X2-based handover without S-GW relocation.

Q.1071

The S-GW shall support X2-based handover with S-GW relocation.

Q.1072

The S-GW shall support S1-based handover without S-GW relocation.

Q.1073

The S-GW shall support S1-based handover with S-GW relocation.

Q.1074

The S-GW shall support E-UTRAN to UTRAN Iu mode Inter RAT handover.

Q.1075

The S-GW shall support UTRAN Iu mode to E-UTRAN Inter RAT handover.

Q.1076

The S-GW shall support E-UTRAN to GERAN A/Gb Inter RAT handover.

Q.1077

The S-GW shall support GERAN A/Gb to E-UTRAN Inter RAT handover.

Q.1078

The S-GW shall support location change reporting procedure.

Q.1079

The local Mobility Anchor point for inter-eNodeB handover.

Q.1080

The S-GW shall support static routing functionality.

Q.1081

The S-GW shall support dynamic routing functionality

Q.1082

The S-GW shall support access control list (ACL) feature.

Q.1083

The S-GW MAY support MPLS/BGP feature.

Q.1084

The S-GW shall support the connectivity with multiple P-GW.

Q.1085

For a single UE with multiple tunnels, the S-GW shall be capable to establish tunnel with different P-GW.

Q.1086

The S-GW shall be capable to allow high priority traffic and drop low priority traffic when the system is overloaded.

Q.1087

It shall be possible to configure the overload control parameters in the S-GW based on which the system behavior can be defined.

Q.1088

The S-GW shall support GTP tunnel on S5/S8 interface.

Q.1089

The S-GW MAY support GRE tunnel on S8 interface.

Q.1090

The S-GW shall support GRE encapsulation applicable for PMIPv6.

Q.1091

The S-GW shall support GPRS Tunneling Protocol for the control plane (GTP-C) over S5/S8 interface.

Q.1092

The S-GW shall support GPRS Tunneling Protocol for the user plane (GTPv1-U) over S5/S8 interface.

10.7.

Conformance to 3GPP Specifications

Q.1093

Please specify the state of compliance of EPC products with 3GPP standards.

10.8.

PCRF

Q.1094

Describe how the PCRF solution as defined by 3GPP is implemented in the solution.

Q.1095

Provide a diagram of how your solution integrates into LTE network architecture. The PCRF MUST act as a central policy rules engine towards multiple services

Q.1096

The PCRF shall support the establishment of Voice and non-Voice Bearers and the control of the core-network and radio network regarding required QoS.

Q.1097

The PCRF shall support all Gx Specific Diameter AVPs as described in 3GPP TS 29.212.

Q.1098

The PCRF shall be able to use the Source IP of the bearer as an input for the policy decision. Proposer shall describe which interface/protocol/information
element is used to transport the information.

Q.1099

The PCRF must control the QoS for the bearer session, validating the assigned QoS agrees with the estab-lished requirements set by the Owner on a per
subscriber basis and modify the QoS dynamically based on policies/rules defined in the PCRF.

Q.1100

The Proponent PCRF must be able to send subscriber notifications using email, SMS, MMS or combination of or all forms of notifications or the subscriber is redirected to a notification server or the subscriber will view the message via a URL redirect. The Proponent PCRF must also support usage reporting and
notifications to PCRF on the Gx interface as per 3GPP TS 29.212.

Q.1101

The PCRF MUST be capable of handling quota usage based on

Q.1101
A.
Q.1101
B.
Q.1101
C.
Q.1101
D.
Q.1102

Volume

Q.1103

The Vendor shall explain how are PCC rules managed on your system? How does an operator create, find, edit, and delete rules?

Q.1104

How granular and flexible is PCC rules derivation? Can we use a PCC rule as a input to derive a new set of PCC rules

Q.1105

How flexible is your counter hierarchy. How many levels can operator define?

Q.1106

The PCRF shall be able to use User Location / Roaming Status (MNC, MCC, RAC, LAC, Cell Id) as an input for the policy decision.

Q.1107

The PCRF shall be able to use Network Technology Information (RAT-Type (UTRAN, GERAN, WLAN), re-quested QoS, Bit rate) as an input for the policy
decision. Proposer shall describe which inter-face/protocol/information is used to transport the information.

Q.1108

The PCRF shall be able to use session information transported over Rx as an input for the policy decision. Proposer shall describe which
interface/protocol/information is used to transport the information.

Q.1109

The PCRF shall be able to use user information transported over Sp as an input for the policy decision. Proposer shall describe which
interface/protocol/information is used to transport the information.

Q.1110

The PCRF shall be able to use Online Time consumption triggers as an input for the policy decision. Proposer shall describe which interface/protocol/information
is used to transport the information.

Q.1111

The PCRF may be able to use Signaling of Cell congestions / overloads (static/dynamic, per configured subscriber) as an input for the policy decision. Proposer
shall describe how the information about congested cells is transported to the PCRF, and how the congested cell can be relieved from overload.

Q.1112

The PCRF shall be able to use internal Timers (start and expiry) as an input for the policy decision.

Q.1113

The PCRF shall be able to use the Time of Day, Day of Week/Month, Weekday, Workday, Weekend as an input for the policy decision.

Q.1114

The PCRF shall provide a roaming network identification, using an internal mapping table between the SGSN / S-GW IP address (IPv4 / IPv6) and the visited
network, in which the SGSN / S-GW is located.

Q.1115

The PCRF shall support the allocation of a pre-defined default policy in the event of unavailability of adjunct systems (such as SPR).

Q.1116

It shall be possible to apply more than one volume limit per subscriber with corresponding data rate limit. For example, the initial downlink bandwidth is 2Mbps; the
bandwidth will be throttled to 1Mbps in case of the usage accumulated to 80%, 512kbps in case of the usage accumulated to 95%.

Time
Volume and Time
Location based (Cell_id based)
How are the PCC rules provisioned on the PCRF? Please explain both for pre-defined as well as dynamic PCC rules.

Q.1117

The PCRF shall support volume counting based policy decision through standard Gx interface for quota installation from PCRF to PCEF and volume reporting
from PCEF to PCRF.

Q.1118

The PCRF shall support Online Charging System Selection (OCS Host Load Sharing, pri/sec event-charging-function-name) in the policy output

Q.1119

Does the PCRF support a GUI that allows the operations team to:

Q.1119
A.
Q.1119
B.
Q.1119
C.
Q.1119
D.
Q.1119
E.
Q.1119
F.
Q.1119
G.
Q.1120

Add Policy Rules

Q.1121

The proposed solution shall support of geographical redundancy and load sharing.

Q.1122

Can the PCRF support interfacing to several Subscriber Database (Sprs) for rules evaluation of one sub-scriber.

Q.1123

The PCRF shall be able to be informed for purchasing extra data volume packages, alternatively notify the subscriber that the limit has been reached and guide
the subscriber to a site where extra data volume packages can be bought.

Q.1124

PCRF shall accept input for decision-making from the PCEF for dynamic policy changes

Q.1125

The PCRF shall be able to use the connection status, established/failed, (e.g. TCP, Diameter Watchdog, LDAP session) of a policy-push interface (see Policy
Engine Output) as an input for the policy decision.

Q.1126

Given a certain volume (time and/or usage), if a user reached that volume before ending the billing cycle, then it shall be possible that traffic generated by that
user be blocked, throttled or redirected to a web portal/landing page. It shall also be possible to top-up (pre-paid or post-paid) as well as define any leniency
period with the flexibility to define leniency on criteria such as VIP customers only.

Q.1127

The PCRF shall support Tiered Service Controls where subscribers can subscribe to different tiers of service (e.g. gold, silver and bronze) that provide them with
the ability to get the speed (e.g. 1Mbps, 512 Kbps), usage limits (e.g.10 GB, 5 GB), time (e.g. month, week, day), priority (e.g. business, government or consumer
class) or any combination of dimensions.

Q.1128

PCRF shall support Service Passes where subscribers looking for data access for a small period of time can easily access network and be redirected to landing
page. The landing page offers time and/or volume limits (e.g. airport WIFI model, etc)

Q.1129

A threshold is applied to certain services (e.g. P2P) for one or all subscribers at specific times of the day (e.g. busy hour) or for a period of time.

Q.1130

PCRF shall be able to cache information received from SPR.

Q.1131

It shall be possible to apply different QoS depending on service, subscriber or both. For example internet VoIP may get a higher QoS than P2P and/or HTTP.

Q.1132

The PCRF shall support Bandwidth on Demand where:

Q.1132
A.

Subscribers are provided an increase in speed for a specific period of time. This is typically done when a subscriber has opted in via a web portal.

Q.1132
B.

It shall also be possible to redirect a subscriber to the portal at session startup offering a "free" upgrade for "X" number of days (e.g. silver subscribers receive
gold speeds over weekend) as part of a promotion. This is an up-sale opportunity.

Q.1132
C.
Q.1133

Happy Hour concept where all subscribers get improved bandwidth at a certain time (e.g. global triggers)

Q.1133
A.

Corporate Account Control - Allow business customers to control voice, data and web usage for em-ployees, during and out of business hours

Delete Policy Rules

Modify Policy Rules
Read Policy rules
Utilize scripting and GUI tools to perform the above activities.
The Configuration Manager must provide validity / consistency checking capability of all rules entered by the operator to ensure no errors are introduced.
The Policy Management Function must support generations of configuration for the Policy Rule set from within the administration GUI
Policy server shall have both GUI and CLI administrative console.

The PCRF shall support Account Controls such as:

Q.1133
B.
Q.1133
C.

Time of Day/Day of Week Controls including controls triggered by prayer times

Q.1134

Vendor shall describe all multiple PCEF scenario supported cover GGSN and DPI systems.

Q.1135

It shall be possible for the PCC architecture to support conflict resolution in the PCRF when the authorized bandwidth associated with multiple PCC rules exceeds
the Subscribed Guaranteed bandwidth.

Q.1136

PCS shall support Volume and Quota based policies.

Q.1137

PCS shall support location based or roaming based policies.

Q.1138

PCS shall support Device based policies.

Q.1139

The Proponents PCRF must offer a carrier grade solution which provides 99.999% availability. The Pro-ponent must detail the reliability and availability figures
for your PCRF solution.

Q.1140

System shall support so-called "hitless" upgrades?

Q.1141

Proposer shall detail which redundancy models (1+1, 2n, 3n etc) are supported by Proposer solution.

Q.1142

The proposed solution shall support of geographical redundancy and load sharing.

Q.1143

The proposed solution shall support PCRF overload control. Proposer shall describe overload mechanisms and PCRF behavior during overload.

Q.1144

Bidders must describe all methods ensuring the high availability of the system. The zero downtime upgrade capacity must be detailed and illustrated by
examples taken from live systems implemented by Bidders. Equipments must guarantee 99.999% availability of all the active parts

Q.1145

Bidders must describe how the proposed system is scalable.

Q.1146

Vendor shall provide architectural evidence that the policy solution can scale horizontally and vertically using off the shelf hardware and software components.

Q.1147

The hardware shall be universal and shall be modular extendable according to capacity demand (preferable extension via HW-card).

Q.1148

Proposer shall provide details information of the PCRF, including but not limited to: model, dimension, ca-pacity per hardware unit, number of module slots per
chassis, interface module (I/O), internal communication concept, operating system, middleware and application software design concept

Q.1149

Proposer shall specify how internal traffic separation is implemented to ensure internal traffic management (e.g. Media-, Signaling-, O&M traffic, etc. Please
explain in detail: - VPN separation of services and management

Q.1150

The system shall provide N+1 redundancy for internal boards/cards. However both N+1 and 1+1 redundancy shall be supported.

Q.1151

The Bidder shall offer the system which is future proof. The system shall have the ability to be migrated to next system generation.

11

IMS Solution

11.1.

IP Multimedia Subsystem (IMS) Architecture Requirement

Q.1152

The Tenderer shall describe support of a layered architecture made up of mainly transport layer, control layer and service layer.

Q.1153

The IMS architecture shall support

Q.1153
A.
Q.1153
B.
Q.1153
C.
Q.1153
D.

Converged voice, data and video services

Parental Control where parents have the ability to disable services (specific pre- defined or user definable URL and/or application) during time of day or days of
week where the time period can be pre-defined or configurable by the subscriber. For example parents may not want to allow data services for their children
during school hours and/or after 10 PM at night). It shall also be possible to extend this capability to presence based such that for e.g., a subscriber cannot
access a data service whilst on school premises. In case of any violations then appropriate configurable trigger notifications to the parent shall be sent

Real time conversational services

Streaming and content based services
Messaging

Q.1153
E.
Q.1153
F.
Q.1154

Web based services and

Q.1154
A.
Q.1154
B.
Q.1154
C.
Q.1154
D.
Q.1155

3GPP IMS Release 9/10

Q.1155
A.

UTRAN (UMTS)

Q.1155
B.

GSM

Q.1155
C.

WLAN

Q.1155
D.

DSL

Q.1155
E.

LTE

Q.1156

The proposed system must provide all VoLTE supplementary services of GSMA.

Q.1157

The following basic IMS Services are to be supported.

Q.1157
A.

Media Connection Service during call

Q.1157
B.

Presence based Services

Q.1157
C.

Location Information connection services

Q.1157
D.

Support of conferencing and announcement services

Q.1157
E.

RCS connection service

Q.1157
F.

Web Interworking Service

Q.1157
G.

Roaming Service

Q.1157
H.

Emergency Call Processing

Q.1157
I.

Set of integrated features, e.g. Generic Address Translation, Prefix Insertion, and Service Authorization

Q.1158

Tenderer must explain the IOTs conducted with different vendors and provide references and provide mul-tivendor references:

Q.1159

The offered IMS solution shall be successfully pass interoperability tests with terminals.

11.2.

CSCF Functional Requirements

Q.1160

In IMS Solution, state all the Call Session Control Functional Elements supported

Other multimedia, combinational and converged Services.

The proposed system must satisfy the following specifications.

IETF RFC
GSMA VoLTE
ETSI TISPAN
Supplier must include support for successful interoperability testing for the access networks discussed in this section as part of their proposal. Specifically, the
following types of access networks are required to be supported.

Q.1161

In IMS scenario, Proxy Call Session Control Function (P-CSCF) shall be supported and act as entry gate for subscribers.

Q.1162

The P-CSCF shall support Confidentiality Protection according to 3GPP TS 29.002, TS 33.204 for IMS AKA.

Q.1163

The P-CSCF must support integrity protection on access network for Digest authentication and key agree-ment.

Q.1164

The P-CSCF shall support Offline Charging using the Rf-interface on the P-CSCF. This is required for ses-sions (e.g. voice calls) and events (e.g. SIP based
Instant Messages). The P-CSCF shall be able to generate CDRs according to the version of the 3GPP standards.

Q.1165

The P-CSCF must support QoS precondition signaling as specified in 3GPP TS 24.229 and detailed in 3GPP TS 24.228

Q.1166

The P-CSCF must support SIP signaling compression as specified in IETF RFCs 3321 and 3486.

Q.1167

I-BCF function can be integrated in P-CSCF.

Q.1168

Freely programmable message manipulation support for all SIP messages which includes:-

Q.1168
A.
Q.1168
B.
Q.1168
C.
Q.1169

Standard SIP headers and message body

Q.1170

The P-CSCF shall be able to detect emergency calls The P-CSCF shall be able to identify and correctly handle emergency calls as per 3GPP TS 24.229, and
prioritize emergency calls in high priority to ensure emergency calls be served even in congestion situations.

Q.1171

P-CSCF must suggest I-CSCF Finding scheme using domain name.

Q.1172

If there is no subscriber information in called P-CSCF, a method of routing SIP message must be suggested.

Q.1173

P-CSCF must provide support for Lawful Interception.

Q.1174

The IMS core supports 3GPP standard IMS Roaming deployment: IMS Roaming includes the deployment of a standalone P-CSCF in the Visited Network
(Access). The PCRF (and/or SPDF) is also deployed there for the QoS Authorization (or for the BGF control, respectively). I-/S-CSCF is however always deployed
in the Home Network of the IMS Subscriber.

Q.1175

In case of a sudden packet bearer loss (e.g. subscriber drives into a tunnel) the P-CSCF is informed by the PCRF via the Rx interface. The vendor shall describe
the behavior of the P-CSCF within such a scenario. In particular, does the P-CSCF de-register the subscriber in the HSS within this scenario?

Q.1176

In case one or more functions share the same hardware with the offered P-CSCF function please explain the resource management in detail. In particular, how
does the vendor ensure that each function only gets the granted hardware resources?

Q.1177

The vendor shall describer what P-Headers are supported by the P-CSCF.

Q.1178

The vendor shall list all supported security algorithms on the P-CSCF.

Q.1179

The vendor shall explain the performance sensitivity of the offered P-CSCF and detail all performance rel-evant parameters

Q.1180

The vendor shall describe the degree of compliance of your I-CSCF for the following interfaces as defined within the current 3GPP specifications:

Q.1180
A.
Q.1180
B.
Q.1181

Cx interface and associated functional behavior as described in 3GPP TS 29.228 and 3GPP TS 29.229 to the HSS.

Q.1181
A.

The role of the I-CSCF in the S-CSCF selection process for subscribers with no SCSF- allocated and in case of S-CSCF Failover.

Non-standard SIP message and body types

shall be supported in an IMS scenario
The P-CSCF must be compatible with UEs that do not support SigComp. That is, the P-CSCF must support uncompressed mode of operation for SIP signaling.

Mw interface to the P-CSCF and S-CSCF and associated functional behavior as described in 3GPP TS 24.229
The vendor shall provide detail of the following particular aspects of the I-CSCF behavior:

Q.1181
B.
Q.1182

Forwarding of SIP messages appropriately according to SIP method, registration status of the relevant subscriber, and appropriate routing mechanism.

Q.1183

Serving Call Session Control Function (S-CSCF); The proposed system must provide the entire AS triggering and interworking described in 3GPP IMS standard
3GPP TS 23.228 and TS 24.229.

Q.1184

The IMS core must support the following RFCs.

Q.1184
A.
Q.1184
B.
Q.1184
C.
Q.1184
D.
Q.1184
E.
Q.1184
F.
Q.1184
G.
Q.1184
H.
Q.1184
I.
Q.1184
J.
Q.1184
K.
Q.1184
L.
Q.1184
M.
Q.1185

IETF RFC 2327; SDP Session Description Protocol.

Q.1186

For interworking with HSS regarding subscriber information, Shared IFC must be provided.

Q.1187

The S-CSCF must be able to route SIP messages to the appropriate AS(s) based on initial Filter Criteria obtained from the HSS.

Q.1188

IMS core shall provide support for the following interfaces Mj/Mg, Mw, Mx, Ic, ISC, Cx, Dx, Dh, Gm, Ic, Ml, Ma, Mk Interfaces.

Q.1189

IMS core shall provide SCTP support on the following interfaces Mj/Mg, Mw, Mx, Ic, , Cx, Dx Interfaces.

Q.1190

The vendor shall explain the mechanism to distinguish between ISC interface traffic and Mw/Mi/Mg/Mr traffic, in particular, are there any differences in usage of
SIP? If so, detail the distinguishing features. are there any differences in usage of SDP? If so, detail the distinguishing features.

Q.1191

The S-CSCF shall be able to behave as a SIP Proxy and to behave as a SIP Registrar for all SIP User Agents belonging to the IMS platform and with public user
identities not barred by the IMS platform Network. The Tenderer shall state and list the mechanisms to perform this.

Q.1192

The proposed system must provide 3GPP Initial Registration, Implicit Registration, Re-Registration and De-Registration.

Q.1193

The proposed system must provide accommodation of multi domain subscribers.

Q.1194

Registration of multiple devices for the same public user identity must be supported to provide one phone number for multiple phones service and forking feature
must be provided.

Q.1195

The S-CSCF must have Load control to prevent registration flooding

Q.1196

Provide detailed description of different authentication schemes supported.

Q.1197

IMS Core shall support Registration Procedures according to 3GPP TS 23.228, TS 24.229.

Q.1198

The registration expiration interval is configurable as per TS 23.228 and TS 24.229

Q.1199

IMS Core shall support Re-Registration Procedures according to 3GPP TS 23.228 and TS 24.229.

Q.1200

IMS core shall support assignment of an alternative S-CSCF for a registered user, when his previously as-signed S-CSCF is not available anymore.

Q.1201

According to 3GPP TS 23.228 TS 24.229, the S-CSCF supports de-registration triggered by IMS HSS FE or S-CSCF internal events.

Q.1202

If calling or called party is unregistered status, each call procedure must be provided and a related method must be suggested.

Q.1203

The proposed system must provide both local number and global number format for Tel-URI number pro-cessing.

Q.1204

The proposed system must provide conversion between Tel-URI and SIP-URI through ENUM interworking.

If the user registration status response doesn't contain any Server-Capabilities AVP, the I-CSCF shall select an S-CSCF based on local configuration.

IETF RFC 2396; Uniform Resource Identifiers (URI): Generic Syntax.

IETF RFC 3261; SIP: Session Initiation Protocol.
IETF RFC 3262; Reliability of Provisional Responses in SIP.
IETF RFC 3264; An Offer/Answer Model with the SDP.
IETF RFC 3311; The SIP Update Method.
IETF RFC 3323; A Privacy Mechanism for the Session Initiation Protocol (SIP).
IETF RFC 3325; Private Extensions to SIP for Asserted Identity within Trusted Networks.
IETF RFC 3345:Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)
IETF RFC 3966; The Tel URI for Telephone Numbers.
IETF RFC 4904; Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs).
IETF RFC 4960; An Introduction to the Stream Control Transmission Protocol (SCTP).
IETF RFC 3588; Diameter Base Protocol.
SIP call processing must provide both domain-based routing and prefix based routing.

Q.1205

Describe detail routing scheme of Domain routing and prefix routing with distinguishing IMS and legacy network based on ENUM query results.

Q.1206

The proposed system must provide call processing with MSISDN-based Tel-URI and SIP-URI format and Alphanumeric SIP-URI address system.

Q.1207

If HSS interworking is failed, when request for re-registration is made, transmission of success response to the terminal without diameter query through HSS must
be suggested.

Q.1208

The proposed system must suggest a method of redirecting an incoming message to P-CSCF based on setting (subscriber prefix, terminal capability, etc.)

Q.1209

The proposed system must provide routing control scheme depending on terminal capability registered for the requested service.

Q.1210

IMS Core shall support SigComp according to RFC 3320 RFC 3485 RFC 4896. It shall be possible to deac-tivate SigComp.

Q.1211

The proposed system must provide call forking in case of multi binding is required and a specific method must be suggested.

Q.1212

IMS core shall support of forking control for RCS

Q.1213

Provide high level call flow for IMS based Number Portability uses DNS ENUM.

Q.1214

The E-CSCF, Emergency Call Session Control Function must support emergency call handling for both registered and unregistered subscribers.

Q.1215

Provide detailed description of Emergency call handling and location information support.

Q.1216

The E-CSCF must support the Ml interface toward location retrieval function (LRF).

Q.1217

The E-CSCF must route the call to the Public safety answering point (PSAP) according to information re-ceived from routing decision function (RDF).

Q.1218

The vendor shall describe the solution for Emergency Callback Support provided by S-CSCF.

Q.1219

The offered solution for emergency sessions in the SIP control domain shall fulfill the emergency principles and requirements of 3GPP TS 22.101 and TS 22.228.

Q.1220

An emergency call usually requires location information as the SIP Control Domain needs to determine which Public Safety Answering Point (PSAP) serves the
area where the UE is currently located. Furthermore, national regulations require delivering the location information of the subscriber to the PSAP. The vendor
shall describe the capabilities of the offered solution to determine the correct PSAP and to deliver the location information to the PSAP.

Q.1221

In case the IMS network is neither directly serving the calling nor the called subscriber a SIP request is routed towards the Transit Control Function (TRCF),
being responsible for interconnecting neighboring networks. The transit support shall comprise of routing, service triggering.

Q.1222

TRCF must provide support for Rf interface.

Q.1223

TRCF must provide support for Lawful Interception.

11.3.

VoLTE Solution

Q.1224

The vendor shall describe VoLTE solution.

Q.1225

VoLTE service means to provide GSMA VoLTE standard based voice call, video call and SMS/MMS.

Q.1226

The vendor shall provide call flow charts for the SMS and VoLTE call scenarios as listed below:

Q.1226
A.
Q.1226
B.
Q.1226
C.
Q.1226
D.
Q.1226
E.
Q.1226
F.
Q.1226
G.
Q.1227

Party registers successfully in SIP Control Domain (AKA Digest)

Q.1228

The Vendor shall indicate the future evolution of the proposed solutions based on the respective product roadmap.Note: Vendor shall specify his corresponding
SW releases and timescale for every new release.

Party registered in home SIP Control Domain calls B-Party registered in the same SIP Control Domain
Party registered in home SIP Control Domain send an SMS to B-Party registered in the same SIP Control Domain
Party registered in home SIP Control Domain calls B-Party registered in the same SIP Control Domain. B-Party has activated call forwarding to voice mail.
Party registered in home SIP Domain calls own voice mail account and changes settings through the use of DTMF tones.
Party registered in home SIP Control Domain send an SMS to B-Party registered in the same SIP Control Domain, but B-party do not have coverage
Party registered in home SIP Control Domain calls ported B-Party registered in the same SIP Control Domain (Note: MNP shall be considered for B-party)
The vendor shall describe the load sharing capabilities and redundancy concepts of the offered solution for VoLTE. Please elaborate on all network functions that
are part of the solution.

Q.1229

IMS NE shall support VoIP and VIP services prioritization in a VoLTE scenario.

Q.1230

Following types of access networks shall be supported:

Q.1230
A.
Q.1230
B.
Q.1230
C.
Q.1230
D.
Q.1230
E.
11.4.

IMS solution shall support Fixed access

Q.1231

The vendor shall describe overload protection mechanism.

Q.1232

The vendor shall describe Load Balancing and failover mechanism.

Q.1233

The vendor shall describe Scalability mechanism.

11.5.

HSS Functional Requirements

Q.1234

The HSS shall support LTE (as defined in TS23.401) including S6a- and SWx interface.

Q.1235

The vendor shall provide detailed information about this component (HW type, OS type, DB SW type, logical and physical function and interfaces).

Q.1236

Describe HSS behavior in the IMS System Environment

Q.1237

The vendor shall provide one or more architecture diagrams with explanatory text depicting the HSS archi-tectural proposal. Ensure that the physical
implementation, modularity and scalability aspects are covered and explained.

Q.1238

The vendor shall describe AuC/HSM function in HSS

Q.1239

Protocol Stack supported in the various layers for the various interfaces shall be described.

Q.1240

The vendor shall describe the functionalities supported by the DRA solution.

Q.1241

The Diameter agent shall support Diameter interconnection to other networks.

Q.1242

The DRA Solution shall be able to control Roaming Agreements

Q.1243

The DRA solution shall be able to perform Admission Control

Q.1244

The DRA solution shall be able to perform Load Control

Q.1245

The vendor shall provide the strengths and advantages of the offered DRA solution.

Q.1246

The vendor shall provide a detailed listing of supported specifications and interface requirements of the offered diameter agent solution.

Q.1247

The Diameter agent shall support LTE roaming. That means support of outbound roaming from TSCC mobile subscribers in VPLMNs and inbound roaming from
international or national mobile subscribers. All LTE roaming related diameter traffic will be routed via a Diameter Edge Agent (DEA). The routing mechanism shall
follow RFC 5729.

Q.1248

The Diameter Agent shall support following three roaming configuration:

Q.1248
A.
Q.1248
B.
Q.1248
C.
Q.1249

Direct tunneling of Diameter Client and Server of Nat Cos without own DEA. (see also Multi Tenancy).

IMS Solution shall support Cable access

IMS solution shall support 2G/3G mobile access
IMS solution shall support Long Term Evolution mobile access
IMS solution shall support WLAN access via PDGW
Network element features

Direct tunneling to Diameter Edge Agent of roaming partner.

Diameter Connection to DRA of IPX provider (IR.88). IP provider distributed to DRA of other IPX provider or to DEA of roaming partner diameter networks.
The Diameter Agent at the edge of the network would be suited best to perform message screening ac-cording to an operator-defined policy. The Agent anyhow
needs to understand 3GPP-specific protocol exten-sions, and it shall be configured to accept the individual roaming partners. The Bidder shall describe the
solution of roaming agreement validation.

Q.1250

Diameter Agent shall have robust Diameter and SCTP protocol implementations that are able to handle exceptional input and protocol syntax/format violations.

Q.1251

Diameter Agent shall control the access that only accepts traffic from established roaming partners, based on IP address ranges and logical identities like e.g.
Visited PLMN ID, ORIG REALM, Peer node, IMSI ranges, requested APN shall which forward this message. Diameter Agent shall verification that IP source
addresses allowed VPLMN IDs and other identities match the policy. It shall be administrable that unexpected messages are to discard or to reject.

Q.1252

Diameter Agent shall support of alarming and logging in case of policy or protocol violations.

Q.1253

The Diameter Agent shall support voice over LTE as well as internet multimedia subsystem as required in GSMA PRD IR.92.

Q.1254

The Diameter agent shall prevent server overload by setup of thresholds to avoid load peaks. It shall be configurable that the messages in case of overload: are
discarded or route to a other server or rejected to client.

Q.1255

The vendor shall provide the possibility to integrate a SIP proxy according RFC 3261 in the Diameter agent platform solution. The Bidder shall explain the benefit
of the solution.

Q.1256

The vendor is invited to state the compliance of DRA /DSC with 3GPP standards for applicable diameter interfaces:

Q.1256
A.
Q.1256
B.
Q.1256
C.
Q.1256
D.
Q.1256
E.
Q.1256
F.
Q.1256
G.
Q.1256
H.
Q.1256
I.
Q.1256
J.
Q.1256
K.
Q.1256
L.
11.6.

Gx, Gxx and Sd as defined in TS 29.212 & 23.203

Q.1257

The IMS shall support the SIP/HTTP Digest authentication method used for Subscriber authentication.

Q.1258

The system shall support authentication t intended for use with early IMS end-user devices that are not equipped with a UMTS subscriber identity module.

Q.1259

The solution must support IP address- based authentication intended for SIP/HTTP Digest Users.

Q.1260

The IMS system shall support the Digest Authentication and Key Agreement over IPSec.

Q.1261

The IMS solution shall support Digest authentication and Key agreement over TLS.

11.7.

HSS Features/HLR features

Q.1262

HSS shall support EPS AKA Authentication retrieval from legacy HLR using MAP. Explain the interworking scenario.

Q.1263

If vendor provide UMTS solution should also provide HLR solution for one million subscribers in this tender.

Q.1264

HSS shall be able to retrieve the UMTS-AKA quintuplet or GSM-AKA triplet from HLR using SAI message

Q.1265

The vendor shall describe the emergency call handling procedure with the proposed HSS.

11.8.

Access Authentication

Q.1266

The IMS system shall support the Evolved Packet System AKA.

Q.1267

The IMS Solution shall support EAP-AKA for the Evolved Packet System.

Q.1268

The solution shall support the Bootstrapping Architecture to establish a security association between an end-user device and the Bootstrapping Server Function
(BSF).

11.9.

Security

Gy as defined in TS 32.299 , TS 32.251 & RFC 4006

Rx as defined in TS 23.203 & TS 29.214
Cx as defined in TS 29.228 & TS29.229
Rf as defined in RFC 4006, TS 32.225 & 32.299
Ro as defined in RFC 4006, TS 32.225 & 32.299
S9 as defined in TS 23.203 & 29.215
S6a as defined in TS 29.272
S6d as defined in TS 29.272
Sh interface as defined in TS 29.328 and TS 29.329
Dx interface as defined in 3GPP TS 29.228 & TS 29.229
S13 and S13bis interfaces ad defined in 3GPP TS 29.272
Subscriber Authentication

Q.1269

Authentication between IMS subscriber and IMS network shall follow IMS AKA (Authentication and Key Management) as specified in TS 33.203.

11.10.

Session and Service Control Functionality

Q.1270

The IMS Solution shall support Session Control.

Q.1271

The IMS Solution shall support Service Control.

Q.1272

The IMS solution shall support Service Triggering with Initial Filter Criteria.

11.11.

Routing.

Q.1273

The vendor shall explain the routing principles used in the HSS.

Q.1274

The HSS shall support Realm-based Routing used when there is a Diameter relay or Proxy to support multiple HSS In the IMS configuration

Q.1275

The HSS-FE shall also act as a Diameter Relay for HSSd Outgoing Requests

Q.1276

The HSS shall support Evolved Packet System Access Point Name Control to control the use of access point names for subscribers using LTE access.

Q.1277

The HSS shall support Operator-determined barring for the Evolved Packet System as specified in 3GPP TS 23.015. Explain in Detail.

Q.1278

The HSS shall support Subscriber tracing.

11.12.

Charging

Q.1279

The vendor shall describe the offline charging architecture in IMS solution. Mapping of 3GPP standard functionalities (e.g. CCF) to physical nodes/functions
involved in charging shall be detailed.

Q.1280

The vendor shall describe the online charging architecture in IMS solution. Mapping of 3GPP standard functionalities to physical nodes/functions involved in online
charging shall be detailed.

Q.1281

CDR shall be generated for unsuccessful call

Q.1282

The vendor shall provide detailed description of content included in the CDRs.

Q.1283

The vendor shall suggest a method of mutual settlement between carriers.

11.13.

IP Network Features

Q.1284

The vendor shall explain the extent of your current support of IPv6 and your roadmap for future support

11.14.

Network Element Features

Q.1285

The vendor shall provide detailed functionality when a site is down due to disaster.

Q.1286

Describe how a client can connect to the geo-redundant site in case of a disaster.

Q.1287

HSS system shall support local redundancy

11.15.

Capacities and Performance

Q.1288

For each individual network element, platform or type of node composing the IMS solution the vendor shall indicate all capacity related limits in each node and
interface.

Q.1289

The IMS architecture shall be scalable in terms of adding nodes in new sites as well as in already existing sites. The vendor shall explain how this can be
achieved.

11.16.

Scalability

Q.1290

The vendor shall describe the scability mechanism of VoLTE system.

11.17.

Interfaces and Protocols

Q.1291

The vendor shall provide detailed description of S6a interface specifying your products compliance with the 3GPP requirements.

Q.1292

The vendor shall provide detailed description of your HSS system including all data schemas as well as access interfaces and protocols.

Q.1293

HSS Front-End system shall support Cx interface as defined in 3GPP TS 29.228 release 10 or later.

Q.1294

HSS shall support all the Diameter parameter definitions as defined in 3GPP TS 29.230 release 10 or later.

Q.1295

HSS shall be compliant with IR.94 IMS Profile for Conversational Video Service.

Q.1296

HSS shall be compliant with 3GPP Presence Architecture specification 23.141 rel 10.

Q.1297

HSS Front-End shall support all IMS interfaces and behavior for HSS as defined in 3GPP TS 23.228 release 10 or later.

Q.1298

HSS Front-End system shall support storing and recalling Service Continuity data as defined in 3GPP TS 23.237 release 10 or later.

11.18.

Operation, Administration and maintenance

Q.1299

HSS will provide the alarms & OMs necessary for monitoring the status and health of the platform.

Q.1300

The NE will provide detailed alarm information in the alarm notification sent to the EMS Notifications shall include:

Q.1300
A.
Q.1300
B.
Q.1300
C.
Q.1300
D.
Q.1300
E.
Q.1300
F.
Q.1300
G.
Q.1300
H.
Q.1301

location of the alarm

11.19.

ENUM Functional Requirements

Q.1302

The solution must support DNS based lookup to TEL and SIP NAPTRs, please describe the information flows between operators and your solution.

Q.1303

What additional service types and NAPTR fields do you support and advice for this implementation?

Q.1304

The offered ENUM shall support all possible formats of Tel-URL (international, national, local format).

Q.1305

The Tenderer shall state the maximum capacity of the ENUM component. The proposal shall describe how scalable is the ENUM component and what standards
and protocols are required to achieve further scalability if any.

Q.1306

The solution must support full and incremental updates.

Q.1307

Please give a description of your companys view on ENUM and its role in number porting for this moment and your vision on ENUM developments for the coming
years.

Q.1308

Provide high level call flow for IMS based Number Portability uses DNS ENUM.

Q.1309

ENUM servers configure the offered shall support the following RFCs

Q.1309
A.
Q.1309
B.
Q.1309
C.
Q.1309
D.
Q.1309
E.
Q.1309
F.
Q.1309
G.

RFC 3953 ENUM Registration for Presence Services

time the alarm occurred

perceived severity of the alarm
alarm description
alarm category
alarm type
the NE and any subordinate resource (if applicable)
previous state
The NE will be capable of buffering at least 48 hours of accounting data, to ensure continuity in case where the transport to upstream systems is not available.

RFC 4002 IANA Registration for Enum service 'web' and 'ft'
RFC 4355 IANA Registration for Enum services email, fax, mms, ems, and sms
RFC 4415 IANA Registration for Enum service Voice
RFC 4769 IANA Registration for an Enum service Containing PSTN Signaling Information
RFC 4969 IANA Registration for vCard Enum service
RFC 5028 ENUM Service Registration for Instant Messaging (IM) Services

Q.1309
H.
Q.1309
I.
Q.1309
J.
Q.1309
K.
Q.1309
L.
Q.1309
M.
Q.1309
N.
Q.1309
O.
Q.1309
P.
Q.1309
Q.
Q.1309
R.
Q.1309
S.
Q.1309
T.
Q.1309
U.
Q.1309
V.
Q.1309
W.
Q.1309
X.
Q.1309
Y.
Q.1309
Z.
AA.

RFC 5067 Infrastructure ENUM Requirements

11.20.

Lawful Interception

Q.1310

The solution shall support the LI functionality defined in 3GPP TS 33.107 and 3GPP TS 33.108.

Q.1311

P-CSCF must provide support for Lawful Interception.

Q.1312

The supplier shall describe all the possible proprietary fields inserted in SIP messages used to implement the Lawful Interception solution.

Q.1313

In call forwarding use cases (unconditional, sequential ringing, busy), the supplier shall implement a Lawful Interception (LI) solution to enable interception of
signaling and communication content.
This solution shall be effective even when in normal condition (no LI activation) the CC would not transit through IMS network (i.e. in some specific cases of call
forwarding, anchoring the media at IMS level in an interception point).
Un-detectability:

Q.1313
A.
Q.1313
B.
Q.1313
C.
Q.1313
D.
Q.1314

This solution shall be undetectable by the LI target.

Q.1314
A.

This solution shall be undetectable by the LI target.

RFC 5278 IANA Registration of Enum services for Voice and Video Messaging
RFC 5333 IANA Registration of Enum services for Internet Calendaring
RFC 5346 Operational Requirements for ENUM-Based Softswitch Use
RFC 5483 ENUM Implementation Issues and Experiences
RFC 5527 Combined User and Infrastructure ENUM in the e164.arpa Tree
RFC 1034 Domain Names concepts and facilities
RFC 1035 Domain Names concepts and facilities
RFC 2535 Domain Name System Security Extensions
RFC 2915 The Naming Authority Pointer (NAPTR) DNS Resource Record
RFC 2916 E.164 number and DNS (actually this RFC is obsolete by RFC 3761)
RFC 3401 Dynamic Delegation Discovery System (DDDS) Part One
RFC 3402 Dynamic Delegation Discovery System (DDDS) Part Two
RFC 3403 Dynamic Delegation Discovery System (DDDS) Part Three
RFC 3404 Dynamic Delegation Discovery System (DDDS) Part Four
RFC 3596 DNS Extensions to support IP Version 6 (towards network elements)
RFC 3597 Handling of Unknown DNS Resource Record (RR) Types
RFC 3761 The E.164 to Uniform Resource Identifiers (URI)
RFC 3764 ENUM service registration for Session Initiation Protocol (SIP) address-of-record
RFC 3966 The tel URI for Telephone Numbers

This solution shall be undetectable by the operators staff (staff not involved in LI provisioning).
The supplier shall describe the LI solution in these use cases.
The supplier shall detail the role of each component involved in the LI solution.
In Roaming-In use case (a user of another operator uses TSCC mobile IMS network, this user is a LI target in the visited network), the supplier shall implement a
Lawful Interception (LI) solution to enable interception of signaling and communication content of this roaming-in user.
Un-detectability:

Q.1314
B.
Q.1314
C.
Q.1314
D.
Q.1315

This solution shall be undetectable by the operators staff (staff not involved in LI provisioning).

Q.1315
A.
Q.1315
B.
Q.1315
C.
Q.1315
D.
Q.1316

This solution shall be undetectable by the LI target.

Q.1317

When reporting LI event, target identities shall be encrypted in logs of the IMS solution equipment

11.21.

Conformance to Standard Specifications

Q.1318

Describe major improvement, differentiations and value added provided by your solution and implementation with respect to the 3GPP standards

12

TAS (MMTEL, IM-SSF, MRF, MGCF/IM-MGW, BGW)

12.1.

Telephony Application Server

Q.1319

The vendor shall describe the offered TAS functions. Please also elaborate on the hard- and software ar-chitecture that has been chosen.

Q.1320

For the following scenario, please provide these information:

Q.1320
A.
Q.1320
B.
Q.1321

How many AS are invoked (PSI or iFC) by the S-CSCF

Q.1321
A.
Q.1321
B.
Q.1321
C.
Q.1322

IETF RFC 3261

Q.1323

The AS shall support all media in SDP offer/response and particularly the media profile defined in the GSMA IR.92 and IR .92 and GSMA IR.94.The SCC AS,
MMTel AS or IM-SSF shall accept HD Audio and Video com-munications

Q.1324

The vendor shall describe any proprietary mechanisms (protocol extensions, SIP headers).

Q.1325

Please detail your strategy and recommendations on co-location of various functions and services. Ideally, co-location provides advantages like signaling
optimization (reduce the load on external nodes), better services interactions, more compact platform, etc.

Q.1326

The proposed solution shall support redundancy on network element level (e.g. high availability cluster, pooling, hot-standby concept).

12.2.

MMTEL AS; STANDARD SUPPLEMENTARY SERVICES

Q.1327

The vendor shall describe the offered MMTel function in detail. Supplementary services must be supported as defined as in GSMA and 3GPP specifications.

Q.1328

The offered MMTel function shall be compliant with 3GPP TS 22.173 and TS 24.173, Release 10. All non-compliances shall be explicitly mentioned.

Q.1329

The vendor solution shall support Originating Identification Presentation (OIP) service according to 3GPP TS 24.607.

The supplier shall describe the LI solution in Roaming-In use case.

The supplier shall detail the role of each component involved in the LI solution.
In Roaming-Out use case based on home routing without Optimal Media Routing (TSCC mobile IMS user in VPLMN, this Roaming-Out user is a LI target for home
network), the supplier shall implement a Lawful Interception (LI) solution to enable interception of signaling and communication content of this roaming-out user.
Un-detectability:

This solution shall be undetectable by the operators staff (staff not involved in LI provisioning).
The supplier shall describe the LI solution in Roaming-Out use case (Home Routed).
The supplier shall detail the role of each component involved in the LI solution.
If the supplier proposes its own Mediation Function platform, LI database shall be encrypted.

How many HLR or HSS interactions (which operations do you use) considering that the SCC, MMTEL and IM-SSF are used.
Strategy & Compliancy with GSMA and 3GPP standards:
The proposed Application Server shall comply with classical 3GPP and GSMA standards. The AS (SCC AS, MMTEL AS, IM-SSF) and MRF shall support SIP ISC
as defined in

3GPP TS 23.218
3GPP TS 24.229
The AS (MMTEL AS and IM-SSF) shall support SIP header transparency. The AS (MMTEL AS and IM-SSF) shall support SDP transparency.

Q.1330

The vendor solution shall support Originating Identification Restriction (OIR) service according to 3GPP TS 24.607.

Q.1331

The vendor solution shall support OIR per call.

Q.1332

Communication Diversion (CDIV); The MMTel AS shall support the SIP procedures as described in 3GPP TS 24.604 and GSMA IR92 recommended options.
The following list of call diversion shall be supported:

Q.1332
A.
Q.1332
B.
Q.1332
C.
Q.1332
D.
Q.1332
E.
Q.1333

Communication Forwarding Unconditional

Q.1334

The vendor shall describe the behaviour when the number of diversions exceeds a given limit and describe behaviour for the Call Diversion to the voicemail.

Q.1335

The vendor shall indicate if CDIV can be managed over an Ut interface using XCAP protocol as described in 3GPP TS 24.623, and the XML schema defined in
24.604, for conditions and actions listed below:

Q.1336

Communication Hold (HOLD): The MMTel AS shall support the SIP procedures as described in 3GPP TS 24.610.

Q.1337

Communication Waiting (CW); The MMTel AS shall support the SIP procedures as described in 3GPP TS 24.615

Q.1338

Please indicate if the Call Waiting activation and deactivation can be managed over an Ut interface using XCAP protocol as described in 3GPP TS 24.623 and
the XML schema defined in TS 24.615.

Q.1339

Communication Barring (CB); The MMTel AS shall support the SIP procedures as described in 3GPP TS 24.611 and GSMA IR92 recommended options.

Communication Forwarding on Busy

Communication Forwarding on not Reachable
Communication Forwarding on No Reply
Communication deflection
The proposed MMTel AS shall use the History-Info header (RFC 4244) in conjunction with the "cause" pa-rameter (RFC 4458) and the Diversion header (IETF
Draft) to carry diversion information in the forwarded INVITE.

The following types of call barring shall be supported:

Q.1339
A.
Q.1339
B.
Q.1339
C.
Q.1339
D.
Q.1339
E.

Barring of All Incoming Calls

Barring of All Outgoing Calls
Barring of Outgoing International Calls
Barring of Outgoing International Calls ex Home Country
Barring of Incoming Calls - When Roaming

Q.1340

As an option, the proposed solution shall be able to play an announcement to the barred user when his call is rejected, by using early-media procedure, for all the
types of call barring.

Q.1341

Conference (CONF); The MMTel AS shall support the SIP procedures as described in 3GPP TS 24.605, TS 24.147 and GSMA IR.92 recommended options.

Q.1342

The proposed MRF solution is able to mix a maximum of 6 communications.

Q.1343

MMTel AS shall provide Ut interface using XCAP as described in 3GPP TS 24.623. Please detail the use of this interface (which services use it, compliance
IR92...)

Q.1344

The offered MMTel function shall be compliant with 3GPP TS 24.623, Release 10.

Q.1345

MMTel AS shall be able to send notification upon each data modification (especially the user configuration with Ut). Please detail your mechanism, options,
configurations and protocols.

Q.1346

MMTel AS shall be able to receive notification about data modification (especially the user service configu-rations). Please detail your mechanism, options,
configurations and protocols.

Q.1347

The vendor shall state whether its recommended to include an Authentication Proxy in the Ut interface path

Q.1348

The vendor shall describe how MMTEL AS retrieves location information and uses it.

Q.1349

For terminating calls, the MMTEL AS shall retrieve subscriber location and use it as necessary (for Com-munication Barring while roaming, charging...).

Q.1350

For terminating calls, when retrieving the location information, the vendor shall describe how to manage the case of multiple devices registered with the same
IMPU, and potential call forking.

Q.1351

Please list down all the interfaces supported, indicate the 3GPP and RFC list of compliant standard for each interface.

Q.1352

The proposed MMTel AS shall support Sequential ringing service.

Q.1353

The proposed MMTel AS shall support Simultaneous ringing.

Q.1354

A subscriber may have several devices and SIM. In the CS+VoLTE context, each SIM may be associated to a specific phone number, but outgoing calls shall
display the same phone number. Do you support a One Number service? Describe your solution.

Q.1355

The offered MMTel function shall support the Sh interface compliant with 3GPP TS 29.328, Release 10.

Q.1356

MMTel AS shall be data less and shall store data in a common database repository. Also please detail your general DB schema.

12.3.

IM-SSF

Q.1357

The vendor shall describe the offered IM-SSF function in detail.

Q.1358

The offered IM-SSF function shall support the Si interface as per 3GPP TS 23.278, Release 10

Q.1359

The IM-SSF shall support Diameter Sh as defined in 3GPP TS 29.328 and 3GPP TS 29.329. The vendor shall detail a list of all the messages and proprietary
AVP. Please detail the usage of this interface: CSI, location info ...

Q.1360

The IM-SSF uses an MRF for media functions (like play tone). The IM-SSF shall use standard interfaces and protocols to interact with the MRF.

Q.1361

The vendor shall describe how the offered IM-SSF function is able to retrieve subscription information for IN services in case of originating and terminating calls in
the SIP domain.

Q.1362

The vendor shall explain how the offered IM-SSF function is able to retrieve location information like the VLR number for a call terminating to a SIP Control (i.e.
VoLTE) registered subscriber.

Q.1363

The IM-SSF shall retrieve the IMSI when the subscriber is on IMS or when he is on CS. The following methods shall be supported:

Q.1363
A.
Q.1363
B.
Q.1363
C.
Q.1363
D.

Third party registration on IMS

HLR/HSS interrogation (when the IMSI is not known)
The following methods may be supported:
Retrieve the IMSI from the SCC AS (it may be provided by the IN service used for CAMEL anchoring of originating / terminating calls)
Please detail which approach you are using. When the HLR/HSS is interrogated, precise the operations that you are using

Q.1364

The IM-SSF shall support the retrieval of parameters from the HLR/HSS including but not limited to MSC address, LocationInformation / VLR Number,
LocationNumber, using MAP or Sh.

Q.1365

For all scenarios of calls including MOC, MTC, MFC, and for all network access types i.e. CS, VoLTE/IMS. The vendor shall describe how these parameters are
retrieved for type of calls and network access types

Q.1366

The IM-SSF shall be able to control an MRF to play the tone seamlessly to the subscriber. The vendor shall describe how this is achieved

12.4.

MRF

Q.1367

The verdor shall provide details of the MRF architecture in conjunction with 3GPP. Precise the proposed solution for both cases (architecture & interfaces,
protocols on those interfaces)

Q.1367
A.
Q.1367
B.
Q.1368

MMTEL AS MRF

Q.1368
A.

TS 23.218:
o 8 Functional requirements of the MRFC

Q.1368
A.

TS 24.219:
o Application usage of SIP

IM-SSF MRF
The proposed MRF function shall support 3GPP TS 23.218 and 3GPP TS 24.229 requirements:

o Media Control

Q.1369

The MRF shall support the media profile defined in GSMA IR.92 (IMS Profile for Voice and SMS), chapter 9 IMS Media.

Q.1370

The MRF shall support the media profile defined in GSMA IR.94 (IMS Profile for conversational video service), chapter 9 IMS Media

Q.1371

The offered MRFC shall support the Mp interface. The protocol used on the interface shall be based on H.248 as per IUT-T recommendation Gateway Control
Protocol

Q.1372

The vender shall list audio and video codes, DTMF mechanisms supported by MRF solution.

Q.1373

The vendor shall provide the file formats (containers and codecs) used by MRF:

Q.1373
A.
Q.1373
B.
Q.1373
C.
Q.1373
D.
Q.1374

For audio announcements

Q.1375

The MRF is used for all the MMTEL AS services that require media support. The MMTel AS shall rely on MRF for all the services requiring audio media.

Q.1375
A.
Q.1375
B.
Q.1375
C.

Announcements / tones (during the communication or early-media).

Q.1376

The offered MRF solution shall support audio conferencing. Please describe the audio conferencing capa-bilities of the offered MRF solution.

Q.1377

The MRF is used by the IM-SSF for all IN operations that require media support. The MRF can be used by the IM-SSF for the following operations (see IM-SSF
chapter)

Q.1377
A.
Q.1377
B.

ApplyCharging with PlayTone (in ReleaseIfDurationExceeded)

For audio recordings (if supported)

For audio/video announcements
For audio/video recordings (if supported)
The offered MRF solution shall support the playback of audio announcements. The vendor shall list all supported audio codecs available for announcement
playback

Conference (CONF service)

Other (DTMF collection, recording, ...)
The vendor shall describe how MMTel AS use MRF audio functionalities.

Connect (to an announcement)

Q.1378

The vendor shall describe supported IN operations for IM-SSF and MRF.

12.5.

MGCF/IM-MGW

Q.1379

The vendor shall describe the hardware and software architecture of the proposed MGCF/IM-MGW.

Q.1380

The vendor shall provide the supported codecs from the proposed MGCF/IM-MGW.

Q.1381

The proposed MGCF/IM-MGW shall be compliant to the Mn interface as specified in 3GPP TS 29.332.

Q.1382

The proposed MGCF shall support the Mg interface to the S-CSCF in accordance with 3GPP TS 24.229

Q.1383

The proposed MGCF shall support the Mj interface to the BGCF in accordance with 3GPP TS 24.229

Q.1384

The IM-MGW shall support IPv6 (RFC 2460) at the Mb interface

Q.1385

The proposed MGCF function shall be compliant to 3GPP TS 29.163, Release 10. All noncompliances shall be listed explicitly.

Q.1386

The proposed MGCF shall support protocol interworking between SIP specified in 3GPP TS 24.229 and BICC as specified in Q.1902.1-6

Q.1387

The proposed MGCF shall support protocol interworking between SIP specified in 3GPP TS 24.229 and ISUP as specified in ITU-T Recommendations Q.761 to
Q.764

Q.1388

The vendor shall explain the MGCF behavior with unsupported SIP Methods

Q.1389

The vendor shall describe how MGCF perform codec negotiation when transcoding is required in the IM-MGW.

Q.1390

The MGCF shall support the control of tones and announcements to be played towards a user registered in the SIP control domain

Q.1391

The MGCF shall be able to convert an E.164 ISUP Called Party Address into a SIP based URI.

Q.1392

The MGCF shall support SIP based on SCTP/IP

Q.1393

The MGCF shall support SCTP multi-homing

Q.1394

The MGCF shall support SIP over TCP

Q.1395

The MGCF shall support M3UA/SCTP/IP for BICC and ISUP signaling

Q.1396

The MGCF shall support ISUP signaling based on TDM

Q.1397

The vendor shall list supported P-Headers by the proposed MGCF.

Q.1398

The vendor shall explain how the offered MGCF determines the SIP route header for initiated SIP-INVITE messages?

Q.1399

The proposed CS-MGW and IM-MGW functionality can be supported within one single network element, i.e. can one physical Multimedia Gateway provide both
functionalities at the same time.

Q.1400

The proposed IM-MGW shall support in-band transport of DTMF tones and information between the PSTN and the IMS.

Q.1400
A.
Q.1400
B.
Q.1401

In case of BICC is used on the CS side

13

Border Gateway

Q.1402

The vendor shall describe the hardware and software architecture of the offered Border Gateway

Q.1403

The vendor shall describe the hardware the defense capabilities of the offered SBC over all protocol layers

Q.1404

The offered SBC shall be able to support IMS-ALG and Transition Gateway functionality compliant to 3GPP TS 23.228

Q.1405

The offered A-SBC shall support access control by means of pinholing media approved during session setup. Please describe your implementation in detail.

Q.1406

The offered SBC shall be capable of protecting against DoS and DDoS attacks. Please describe the im-plemented functionality in detail

In case of ISUP is used on the CS side

The proposed IM-MGW shall support T.38 FAX over IP and FAX interworking with the PSTN.

Q.1407

The vendor shall list all monitoring, statistics and reports of events provided by the offered SBC

Q.1408

The offered SBC shall support IP version interworking between IPv4 and IPv6

Q.1409

The vendor shall describe the transcoding capabilities of the offered SBC and shall list all supported codecs.

Q.1410

The vendor shall describe the redundancy concept of the offered SBC solution

Q.1411

To increase link reliability the offered SBC shall support Bi-directional Forwarding Detection (BFD)

14

MSS server

14.1.

MSS server platform

Q.1412

The offer MSC server should support VLR function to be able handle 200M subscriber if Buyer have UMTS 900M network.

Q.1413

System Architecture should be distributed.(at least two node ,North and south) Explain the architecture and functional units of your system

Q.1414

The MSC server shall be provided with embedded Service Switching Point (SSP) functionality.

Q.1415

IN Protocol should be supported, specify the capabilities of the system. Camel Phase 4 must be supported.

Q.1416

SS7 on IP shall be supported using M3UA.

Q.1417

The MSS system should comply to 3GPP 29.002, Mobile Application Part Specification

14.2.

Features

Q.1418

The following feature should be supported by the system

14.3.

Geo Redundancy

Q.1419

The CS Core System shall have the capability of automatically detecting any occurrence of unbalanced uti-lization of VLR capacity among all MSS included in the
MSS Pool, as well as automatically initiating subscriber redistribution in order to achieve balanced utilization of VLR capacity among all MSS. The Bidder shall
provide detailed explanation on how this can be achieved.

Q.1420

VLR backup functionality should be supported in order to support immediate terminating service after a VLR restarts or loss of MSS

15

UMTS Package core

15.1.

SGSN

15.1.1.

SGSN function

Q.1421

The Vendor shall provide a description of the offered SGSN evolution for LTE. The description must take into account: the architectural, functional and
technological aspects making reference to the target 3GPP release it will be based on.

Q.1422

The Vendor shall provide the roadmap of capacity and performance matrix of its SGSN element. Please highlight all the relevant key capacity indicators that are
important to plan and dimension the network.

Q.1423

Vendor shall support centralized and distributed CGF in SGSN.

Q.1424

Vendor shall detail to which 3GPP TS its charging solution comply.

Q.1425

The vendor shall support HSDPA+ in 3G environments with bit rate up to 168 Mbps

Q.1426

The vendor shall support HSUPA+ in 3G environments with bit rate up to 84 Mbps

Q.1427

The solution shall be able to produce trend statistics and calculate KPIs for the network planning engineers and executive management. The statistics shall be
available for review in a real-time monitoring and trouble-shooting tool providing detailed reports on all call attempts made in the network, as well as real-time
information about your services

Q.1428

The monitoring tool shall be able to produce the following reports:

Q.1428
(1)
Q.1428
(2)
Q.1428
(3)

Successful and erroneous attaches and detaches, as well as routing area updates. Events are reported immediately as they appear.

Q.1428
(4)

Information on data sent in the uplink and downlink directions, and on the negotiated QoS. Events are reported at a minimum interval of three times per second
per PAPU.

Successful and erroneous PDP context activations, deactivations, and modifications. Events are reported immediately as they appear.
Number of GTP packets and bytes sent in uplink and downlink directions, the GTP buffer filling ratio, and the amount of discarded GTP packets. Events are
reported every minute per PAPU.

Q.1428
(5)

Information on BSSGP buffer utilisation per priority class, lost BSSGP downlink data per priority class, and BSSGP packets dropped due to redundancy
elimination.

Q.1428
(6)

Information on the amount of data passed and discarded by the BSSGP MS-BVC flow control. Events are reported at a minimum interval of ten times in every 15
minutes per PAPU. Values are given on cell level.

Q.1428
(7)

Information on users attached through the Gb and Iu interfaces, open PDP contexts per priority class, and several properties of open PDP contexts.

Q.1428
(8)

Information on the number of generated and discarded Gb and Iu CDRs for each CDR type, the CDR recovery buffer utilisation, and the number of CDRs re-sent
to the charging gateway. Events are reported every minute.

Q.1428
(9)
Q.1428
(10)
Q.1428
(11)
Q.1429

Information on open CDRs for each CDR type.

Q.1430

For increased reliability, SGSN shall support interface to a redundant combination of additional elements

Q.1431

Please explain the mechanism to protect your system from overload situation.

Q.1432

SGSN shall be able to integrate to EPC environment with 3GPP Rel.7 interfaces (Gn). That includes smart PDN GW selection for LTE devices. Describe the
solution and timeframe when such integration is possible.

Q.1433

SGSN shall be able to integrate to EPC environment with 3GPP Rel.8 interfaces (S4, S3, S16, S6d, S12).

Q.1434

Describe packet core evolution steps to introduce LTE radio access in addition to 2G and 3G radio accesses

15.2.

GGSN

15.2.1.

GGSN function

Q.1435

The vendor shall state how the Gateway capacity can support wireless broadband networks 2G, 3G, HSPA/HSPA+, LTE in optimized way for both control plane
and user plane.

Q.1436

The gateway shall be optimized to support always-on terminals.

Q.1437

The gateway shall support multi-core packet processor (MPP) technolog

Q.1438

The GGSN deployment option shall support the GTP access protocol over the Gn and Gp interfaces for GERAN, UTRAN, HSPA, HSPA+, and EHSPA traffic

Q.1439

The GGSN deployment option shall support flat architecture connections with Internet high-speed packet access (EHSPA) and direct tunnel (DT).

Q.1440

The GGSN deployment option shall provide Gi interface towards packet data networks (PDN).

Q.1441

The GGSN deployment option shall support Generic Routing Encapsulation (GRE) in the Gi interface.

Q.1442

The GGSN deployment option shall support Radius protocol towards AAA server in the Gi interface

Q.1443

The GGSN deployment option shall support Bp interface for off-line metering to enable on-demand transfer of charging data.

Q.1444

The GGSN deployment option shall support X1_1, X2 and X3 interfaces towards Lawful Interception system.

Q.1445

The GGSN deployment option shall support GTP version GTPv1.

Q.1446

The GGSN deployment option shall provide PDP context management functions (creating, maintaining and deleting of PDP contexts)

Information on RA-level pagings over the Iu and Gb interfaces.

Information on SGSN-level pagings over the Iu and Gb interfaces.
Please list any other additional reports that are available through real-time monitoring tool and not listed above.

Q.1447
15.3.

Lawful interception

Q.1448

The vendor shall support ICE interfaces X1_1, X2 and X3 according 3GPP TS 33.106 and TS 33.107

Q.1449

The vendor shall support ADMF, DF2 and DF3 according 3GPP TS 33.106, TS 33.108, TS 33.108 and ETSI TS 101.671

Q.1450

The vendor shall support IRI and CC data

Q.1451

The vendor shall support IMSI, IMEI and MSISDN as an interception target

16

Number Portability System

Q.1452

The vendor should provide the NP subsystem or integrated with IMS Enum to support both circuit switch system and IMS core network to comply Taiwan
Telecommunication Number Portability mechanism. Also need to take the responsibility of the integration work with Taiwans Number Portability Administration
Center (NPAC) with require OSS integration effort

Q.1453

The vendor should provide the detail call scenario/flow for TSC non-NP subscriber, NP-out users and NP-in TSCs subscriber

Q.1454

The provide NP system should be able to support more than 50M number data without performance degrade.

Q.1455

The provide NP system should be able to handle 6M TSC subscriber in rush hour(heavy load signaling condition, i.e. 0.02 erlang per each 6M user call/ a hour
with 2% blocking ).

17

OSS Solution

17.1.

General Requirement

Q.1456

Please provide EMS, NMS layer architecture managing LTE, IMS and SDM network with redundancy support.

Q.1457

The Vendor shall comment on existing and planned compliance/non-compliance with network management and element management information model
standards and where in the systems architecture the following standards will apply:

Q.1457
A.
Q.1457
B.
Q.1457
C.
Q.1457
D.
Q.1458

3GPP standards

Q.1459

Dependencies to particular product versions across value chains shall be kept to a minimum.

Q.1460

It shall be possible to install and operate the Vendors NMS solution on a virtualized data centre infrastructure.

Q.1461

The Purchaser may choose to integrate the Vendors NMS solution into his existing virtualized datacenter infrastructure. If the Purchaser chooses to integrate the
NMS Solution to his virtualized datacenter infrastructure, the Vendor shall support the integration.

Q.1462

The vendor shall support VM-Ware for the virtualization of his NMS solution.

Q.1463

The Vendor shall fulfill the same functionalities for the virtualized NMS as for his standalone NMS solution, according to the requirements in this Annex.

Q.1464

In case of integration to higher level Umbrella system the notification of alarms and events shall be done in strict order of occurrence in the managed Network.

Q.1465

The Vendor shall provide all necessary information, (e.g. CPU load, SW versions, database version ) which is needed to virtualize the Vendors NMS solution.

Q.1466

Every alarm, measurement, configuration, operation and maintenance data stored in the database shall be able to be accessed using external tools.

Q.1467

Provide system schematic diagram about network management how to manage, maintain and optimize eNodeB, EPC, IMS and transmission network.

Q.1468

The NMS shall support storing of all data in Oracle or other relational database based on SQL standard.

Q.1469

Provide all network element and NMS related Local/Remote console, EMS, NMS interface information. Also, How graphical man to machine interface and
command line interface (Machine to Machine, Man to Machine) function for multiuser purpose (please list out maximum user/connection number).

Q.1470

The NMS shall have a layered structure focusing on scalability, flexibility and openness.

Q.1471

Describe Logical Structure of the Hardware Platform.

Q.1472

Describe Software Structure of the NMS solution.

Q.1473

Explain Overload and Congestion Control of NMS solution.

Q.1474

What is the Power Supply and Power Consumption of the offered management solution?

Q.1475

Please provide machine to machines local/remote (console, EMS, NMS) management method and its maximum connection figure.

Q.1476

Please provide LTE, IMS and transmission EMS, NMS system dimension principle and system maximum capacity figure with relevant hardware specification and
operation system information (Unix base).

TM Forum MTNM
OSS/J
Other
It shall be supported to perform automatic monitoring of the NMS behavior (including all HW and SW com-ponents) through use of monitoring agents (own - or
3rd. party). Monitoring agents could communicate with a remote NMS over a DCN (Data Communication Network) by means of a management protocol, such as
SNMP, EJB, XML/JMS or Web Services.

Q.1477

Please suggest additional software and hardware solution needed for manage, maintain, optimized various system.

Q.1478

Please provide network elements, EMS, NMS full on line backup and restore (including OS & Application & data), where this operation wont impact to user
service, detail execution plan.

17.2.

Fault Management

Q.1479

Please state how system can let operating personnel able to view 1st level fault monitor screen alarm and automatically forward alarm with footnotes through
northbound interface to designate NMS system and receiving

Q.1480

The fault monitoring solution shall provide open interfaces to allow integration to companies 'umbrella' monitoring system. The vendor shall describe the available
interfaces.

Q.1481

The NMS shall be possible to define alarms based on statistics.

Q.1482

It shall be possible to search in the alarm history for certain alarms by filtering on any alarm information. It shall be possible to filter out alarms at system and userlevel. Descriptions of available alarm filtering shall be provided.

Q.1483

The NMS shall be possible to define alarms.

Q.1484

The NMS shall be possible to pre-define alarm thresholds.

Q.1485

The NMS shall be possible to define different alarm categories and levels.

Q.1486

The NMS shall be possible to activate/deactivate the different alarms.

Q.1487

The NMS shall be possible to automatically delete alarms.

Q.1488

The NMS shall support the capability to detect abnormal traffic in each NE (e.g., the quantity of traffic de-crease or increase below/above defined threshold
values).

Q.1489

The NMS will provide post-processing capabilities for the collected information related to the fault man-agement reports to show the current and history alarm
situation of the network.

Q.1490

The Vendor shall describe which alarms that are stored in the NMS alarm database and that can be exported to another data source for further processing.

Q.1491

Please provide EMS, NMS southbound Alarm Resynchronization minimum interval and needed time for Alarm Resynchronization mechanism.

Q.1492

Please provide network elements, EMS, NMS collecting data minimum interval, generating data time and exporting to northbound time.

Q.1493

Please provide other trouble shooting tools detail description.

17.3.

Performance Management

Q.1494

In minimum the vendor needs to provide service usage reporting as currently used reporting suite does. The reporting needs to include reports for service (HLR,
HSS, EIR... etc) use in network in Front-End, -and Back-End level. The network level service usage reporting across all service Front-Ends need to be
consolidated into one report, as is the case on current reporting structure. The reporting system need to allow easy addition of new Front-Ends with above
mentioned reporting levels. It is expected that the reporting is provided on easy to un-derstand format, i.e. no post processing is needed on reported values. E.g.
SIGTRAN measurement results needs to be presented as current narrowband SS7 signaling values are. Signaling reporting and statistics in-formation needs to
be available on demand from the system for trouble shooting purposes. The statistical in-formation for trouble shooting purpose needs to be available directly
from all parts of the CSDB solution.

Q.1495

Please state management, maintenance, optimization LTE, IMS and transmission related network report. Also, provide management report generating shortest
interval, times need to generate for each report and transmit to designate location.

Q.1496

Please advice what PM data needed for calculating average throughput of each user Forward & Reserve based on each base station Sector & Carrier and how
this can be calculated.

Q.1497

The NMS shall provide statistics on events in all NEs and on the related interfaces.

Q.1498

NMS shall have performance reporting functionality and user shall be able to query to performance database using that functionality.

Q.1499

The following performance management data shall as a minimum be supported:

Q.1499
A.

Performance data

Q.1499
B.
Q.1499
C.
Q.1499
D.
Q.1499
E.
Q.1499
F.
Q.1499
G.
Q.1499
H.
Q.1499
I.
Q.1500

Performance event

Q.1501

Automatic data deletion shall be possible.

Q.1502

Describe the retention period for storing performance measurement data.

Q.1503

The NMS shall export statistics automatically in common formats from NE to NMS and to other external systems, such as data warehouses and CRM systems.
The specific export format shall be described.

Q.1504

The vendor shall describe, for each set of performance measurement counters, at what granularity the counters can be reported.

Q.1505

The vendor shall provide a description of the performance management functionality and all performance measurement counters available

Q.1506

The Vendor shall describe how automatic solutions and procedures for measuring the traffic with respect to quality, capacity, performance, usage and availability
are supported.

Q.1507

The NMS shall monitor its own resource requirements and raise an alarm if any of these are in danger of being breached.

Q.1508

Provide network element PM interface to EMS, NMS architecture.

Q.1509

Please provide network elements, EMS, NMS south bound minimum interval collection time.

17.4.

Configuration Management

Q.1510

Please provide retrieving CM data mechanism and architecture.

Q.1511

Configurations changes shall be possible to plan at any network level defined in the NMS.

Q.1512

Preparing and activating multiple plans shall be possible independently and simultaneously.

Q.1513

Full traceability at any configuration changes must be ensured in NMS.

Q.1514

The NMS shall have functionality for automatic import of configuration data on a predefined format.

Q.1515

Any configuration changes in the network must be done through an open and fully documented interface such as XML.

Q.1516

The NMS shall maintain the configuration inventory for all changeable parameters in the network.

Q.1517

Activating plans to the network shall be done in a transaction oriented process with both commit and rollback mechanisms.

Q.1518

The Vendor shall list any configuration tasks that are available via CLI only

Q.1519

The vendor shall list any configuration tasks that are available via GUI only.

Q.1520

The network topology and object relationships shall be stored in the NMS

Q.1521

The vendor shall list all configuration tasks that can be performed via scripts or configuration files.

Q.1522

The NMS shall be provided with visualization for all configuration data stored in each managed NE that properly reflects the actual data stored in the managed
NE.

Q.1523

When the operational state of a managed entity within a NE changes, the NMS shall provide notification and log.

Q.1524

The NE entity or functionality shall allow for version control and tracking for configuration files and software load files

Q.1525

Please provide EMS, NMS southbound CM data collecting minimum interval and needed time for collecting data.

Q.1526

Please provide network elements, EMS, NMS collection data complete minimum interval, generate consol-idated data time, and exporting to northbound time

Event statistics
Counters
Performance thresholds
Measurements
Measurement interval
Load on NEs, number of service executions
Network Performance Key Performance Indicator (KPI)
The NMS shall be possible to activate and deactivate counters, to choose different measuring intervals and to automatically produce statistical reports.

Q.1527

Please provide how system generates object software release number and hardware (Chassis/Slot/Daughter card) inventory data via CM interface.

Q.1528

Please provide provision and change management interface and method.

Q.1529

Please advice solution how EMS, NMS execute single provision command multiple times or schedule pro-vision command and able getting provision result back
immediately and provide performance figure on exe-cuting immediate batch command (number of provision task complete in one second).

Q.1530

The NMS shall support to gather and store all relevant NEs or devices information as inventory type infor-mation.

Q.1531

The NMS shall be possible to retrieve lists of filtered information about all relevant NEs and devices. For example, following filters are expected:

Q.1531
A.
Q.1531
B.
Q.1531
C.
Q.1531
D.
Q.1532

By NE name, including the use of wild cards

17.5.

Security Management

Q.1533

As part of the NMS, security management functions shall be supported to avoid and protect against unau-thorized access and manipulation in conformance to
governing security policy.

Q.1534

Provide network elements security access control mechanism.

Q.1535

The NMS shall identify the users by a unique user ID. Describe the rule which all user ID must satisfy e.g. minimum length of character and the use of numbers
and alphabetical characters.

Q.1536

The NMS shall require each user ID to have an associated password.

Q.1537

The NMS shall require users to identify themselves with their assigned user ID and password before per-forming any actions.

Q.1538

The NMS shall internally maintain the identity of all active users.

Q.1539

The NMS shall disable all user IDs that have not been used for a specific period of time.

Q.1540

The NMS shall have an activity log with login and logout information per user and per application. Each add/delete/edit task shall be logged.

Q.1541

The NMS shall not allow any way to bypass authentication mechanisms.

Q.1542

The NMS shall provide configurable password ageing.For example, the NMS password ageing logic shall not allow a user to re-enter a password used in the past
three ageing periods, six months, or the last five password changes, whichever is appropriate.

Q.1543

The number of unsuccessful log-on attempts shall be limited. The NMS shall terminate or lock account such over attempted accounts.

Q.1544

Any component shall not have hard coded or shared sensitive parameters like user account and passwords and/or IP address within the code. If that is the case
passwords cannot appear in plain text in any file i.e. it must be protected by appropriate security mechanism.

Q.1545

An internationally accepted algorithm or method of encryption is employed for keeping of passwords con-tents (e.g. SHA-1).

17.6.

Software Management

Q.1546

It shall be possible to download new software to NE. This operation shall be possible also from a remote site.

Q.1547

The NMS shall support to maintain multiple software versions throughout the network.

Q.1548

It shall be possible to schedule the download and installation of new software to any NE. A description of this functionality shall be provided.

Q.1549

NMS software upgrades shall be done with a formal and predictable software upgrade mechanism.

Q.1550

Provide EMS, NMS southbound network element minimum data collecting interval and data aggregation time.

Q.1551

Please provide south bound and northbound interface specification, protocol and message for all the EMS/NMS (FM, CM, PM, PRM, SM, Call log, Call event,
system log). Also, provide EMS, NMS (FM, CM, M, PRM, SM, Call Log, Call Event, System Log) northbound message management architecture, protocol and
message.
Logging

17.7.

Operator_id, including the use of wild cards

By NE, shelf, board type
By SW version
Please advice how to confirm immediate execution or batch execution result is correct and complete.

Q.1552

All NEs shall have local logging of relevant events and operations. The following types of logs shall be im-plemented as minimum;

Q.1552
A.
Q.1552
B.
Q.1552
C.
Q.1552
D.
Q.1553

Command log

Q.1554

For all log records in log files shall support time-stamps which shall be accurate within a second e.g. xyz.log.20011201230059 (yyyymmddhhmmss).

Q.1555

Log-files shall support to contain all relevant error messages, e.g. status information and performance in-formation.

Q.1556

All log-messages shall be able to be distinguished for each system categories (e.g. OS, Database, inter-faces, application).

Q.1557

The retention period of all log files shall be configurable.

Q.1558

Real- time logging shall be supported.

17.8.

Tracing

Q.1559

How system can provide enough System log to trace command executer and execute history.

Q.1560

Provide a solution that is able to transmitting Signaling Log, Call Log, Trace Log, Per Call Event Log, etc mass data into remote destination without impact to
existing user service (generating in 5 min and reach des-ignate destination in 3 minutes). Where stored data at least 90 days and provide quick query (5 second
getting response back).

Q.1561

Provide a solution able to support multiple operating personnel query different MSISDN and network ele-ments call tracing and debugging without inference each
other.

Q.1562

Provide Call Trace and trouble-shooting function and its limitation.

Q.1563

Provide End-to-End Trace function and user case example.

Q.1564

Provide a solution able to utilized signaling record, call record, tracing record, system record, call event record etc. to optimize network, trouble shooting outage
and showing real time system performance and record.

17.9.

Self Organizing Networks (SON)

Q.1565

Please provide LTE SON and network elements architecture and standard followed.

Q.1566

The neighboring optimization is based on the same inputs as the previous modules, i.e. network configura-tion, performance indicator and interference matrix.
The system shall be able to propose the creation of new neighbor relations and the deletion of useless neighbor relation.

Q.1567

The offered ANR function shall support to implement SON - Automatic Neighbor Relation for LTE.

Q.1568

The neighbor addition or deletion has to be presented in a simple, easy to read format (.txt, .csv or Microsoft Office). The parameters mentioned above have to be
exported in the same file to justify the additions or dele-tions.

Q.1569

Please provide eNodeB and EPC at self-optimization how to retrieve data for pre-execute analysis and to-be-execute tasks. Furthermore, executed result and
benefit analysis.

Q.1570

SON FM, CM, PM: Please provide SON related network management function and explain FM, CM, PM functionality separately.

Q.1571

Please provide SON northbound and southbound API interface input data format.

Q.1572

Please provide DCN bandwidth requirement for collecting SON related data.

Q.1573

Please provide eNodeB and EPCs Self-Configuration, self-optimization, self-healings explanation and their related use case.

Q.1574

Please provide eNode and EPC how self-configuration retrieves data for pre-execute analysis data and setting items. Also, executed result benefit analysis.

Q.1575

Please provide eNodeB and EPC at self-optimization how to retrieve data for pre-execute analysis and to-be-execute tasks. Furthermore, executed result and
benefit analysis.

Alarm and event log

Performance log (CPU and memory availability per processor)
Logs showing abnormal interaction with other systems
Local logging of relevant events and operations shall be written to a non-volatile storage.

Q.1576

Please provide eNodeB and EPC how to retrieve data for self-healing for pre-execute analysis and to-be-execute tasks. Also, executed result and benefit
analysis.

18

Subscriber Data Management Solution

18.1.

General Product Information

Q.1577

The supplier shall state the benefits and advantages of Centralized Subscriber Database Management like:

Q.1577
A.
Q.1577
B.
Q.1577
C.
Q.1577
D.
Q.1578

High Availability, Reliability, and Resilience

Q.1579

The supplier shall provide the description about Directory service concept.

Q.1580

The supplier shall list the functional components of the database and explain in brief about each component.

Q.1581

The supplier shall state all entities and the interfaces from database to other components with diagram.

Q.1582

The supplier shall state the scalability of database in order to accommodate more users in future.

Q.1583

The supplier would ensure highly redundancy of the database.

Q.1584

Administrations and performance monitoring tool shall be supported.

Q.1585

The supplier shall describe the redundancy mode of the geographically separated data stores. Do these stores react to queries sent from Application Layer, e. g.
multi-master mode or master and standby mode or master slave mode respectively Active/Active/Active, Active/Standby/Standby, etc.

Q.1586

The supplier shall state if his system supports multi-country hosting of data, i.e. the hosting of subscriber data of different countries. If yes, please list functional
and legal restrictions available.

Q.1587

The database shall have the following features:

Q.1587
A.
Q.1587
B.
Q.1588

Direct Interface in order to perform queries in the data by operator without Supplier intervention.

Q.1589

Supplier shall support unified provisioning system and unified interface [Provisioning Gateway].

Q.1590

The Supplier shall describe the provisioning applications and hardware needed in detail.

Q.1591

The Supplier shall clarify how its system allows performing the Bulk update for user profiles.

Q.1592

Data (subscriber) model shall be extendable in order to be used by other applications. The Supplier is re-quested to explain how the data model extension is
performed.

Q.1593

The subscriber database Triad shall update all instances of the same data in a synchronous or asynchronous manner such that the Front End Applications have a
consistent view of the data. The Supplier shall detail how this is achieved.

Q.1594

The supplier must provide all hardware specifications of database solution. The supplier shall describe the hardware platform used for the Database Layer.

Q.1595

The supplier shall provide the information on the reliability of the proposed network elements (MTBF), and it shall describe the impact of partial and full hardware
failure and recovery procedure of the potential failure. Also state the Mean Time to Repair (MTTR). The Vendor shall briefly describe here the main benefits of the
offered BSC/TRAU product that the Vendor wishes to highlight.

18.2.

Technical Requirements

Q.1596

The supplier shall explain the architecture of the provisioning system.

High Scalability and Extensibility

Flexibility
Fast Processing
The supplier shall state the kind of database standard chosen for subscriber database.

Allow queries in a text based.

Supplier shall clarify how its system allows performing the dump of part of the database content, using different type of criteria. The output has to be in a readable
& usable format to be used for command batch generation.

Q.1597

The Supplier shall state the provisioning options available for subscriber provisioning.

Q.1598

The Provisioning Front End shall support SPML interface.

Q.1599

The supplier shall state what tools are available for analysis, extraction, manipulation and changing of sub-scriber data.

Q.1600

The supplier shall state different types of SPML requests supported by the Provisioning interface.

Q.1601

The supplier shall support the mechanism used, in case of errors in provisioning.

Q.1602

The supplier shall explain how the Provisioning system can be embedded with operators existing CRM/CCC system.

Q.1603

The Provisioning system shall be able to address subscribers via the IMSI or MSISDN.

Q.1604

The Supplier shall state if provisioning can be done directly to the Database Layer (bulk mode).

Q.1605

The supplier shall state different types of provisioning tasks supported in the solution for provisioning.

Q.1606

The supplier shall state the different types of interfaces supported for subscriber and service data admin-istration.

Q.1607

The supplier needs to specify how CRM/CCC transfers a bulk provisioning command to the database di-rectory.

Q.1608

The supplier shall state SPML requests supported by the Provisioning interface for mass provisioning.

Q.1609

Describe the backup and recovery solutions that will be provided as part of your proposal. The Supplier shall detail hardware, scripts and documentation provided
for this task within their answer.

Q.1610

The supplier shall describe in technical details how the proposed system will be secured (all types of security shall be provided).

Q.1611

The supplier shall explain in details the software/hardware path, and additional roadmap require-ments/features.

18.3.

Supported Standards

Q.1612

The Supplier shall state the compliancy to all the relevant ETSI standards.

Q.1613

The Supplier shall state the compliancy to IETF standards.

Q.1614

The Supplier shall state the compliancy to ITU-T standards.

Q.1615

The Suppliers equipment shall comply with EN 300 386-2, environment class "other than telecommuni-cation centers".

Q.1616

Database hardware shall be complies with RoHS standards in manufacturing and deployment of equipment.

18.4.

Database requirements

Q.1617

The supplier shall state the architecture of the database.

Q.1618

The supplier shall provide the details of interfaces of the database.

Q.1619

The supplier shall explain the authentication mechanism for client accessing the database.

Q.1620

The supplier shall state the scalability of database in order to accommodate more users in future.

Q.1621

The supplier shall state database open standards.

Q.1622

The supplier shall state the Backup and restore (B&R) mechanism present in the database.

Q.1623

The supplier shall describe what database mechanisms are used to generate a persistent back up of a real time in-memory database (e. g. a mirroring of the inmemory data base to disk as a one-to-one replica).

Q.1624

Supplier shall clarify how its system allows performing the dump of part of the database content, using different type of criteria. The output has to be in a readable
& usable format to be used for command batch generation (using scripts for the update).

Q.1625

The Supplier shall clarify how its system allows performing the Bulk update for user profiles, without help of the Supplier. The Supplier shall state type of data can
be updated by batch processing.

Q.1626

Data (subscriber) model shall be extendable in order to be used by other applications.

Q.1627

The subscriber database Triad shall update all instances of the same data in a synchronous or asynchronous manner such that the Front End Applications have a
consistent view of the data.

Q.1628

The database system must be robust to handle database configuration changes in real-time and meet high performance (read/write) expectation.

Q.1629

In any update to the data entries or database, the database system must ensure the data accuracy and consistency.

18.5.

Protocols and Interfaces

Q.1630

The supplier shall state all the protocols between database and other components with diagram. The supplier shall describe the communications protocols used to
access network elements for each component.

Q.1631

The compliancy of the protocols with other Components shall be described.

Q.1632

Detailed information about LDAP shall be provided.

Q.1633

The Database must be flexible to adapt to the rapidly growth of subscriber dynamic changing data/value (attribute growth).

Q.1634

The Database must be flexible to support future network element interfaces and standard protocols for re-trieving data or adaptable to data virtualization.

Q.1635

The Database system must be robust to handle data entries changes, in real-time and meet high performance (read/write) expectation.

Q.1636

The Database system must support LDAP protocol and LDAP security standards defined in the LDAP v3 RFCs.

Q.1637

The Database system must support secure connection for external applications.

Q.1638

The supplier shall support secure communications protocols for all Network Element Access.

18.6.

Hardware information

Q.1639

The supplier must provide all hardware specifications of database solution. The supplier shall describe the hardware platform used for the Database Layer.

Q.1640
Q.1641

The hardware must meet the highest industry standard of high availability, fault tolerance and scalability.

Q.1642

The supplier shall provide the information on the reliability of the proposed network elements (MTBF), and it shall describe the impact of partial and full hardware
failure and recovery procedure of the potential failure. Also state the Mean Time to Repair (MTTR).

Q.1643

The System shall be designed without any single point of failure in term of hardware, software, modules and interfaces.

Q.1644

The Supplier shall describe the provisioning applications and hardware needed (e. g. Provisioning Gateway, etc.) in detail.

18.7.

Other information

Q.1645

The supplier must identify all Operation System, Networking, Application Software and any other software licenses required.

Q.1646

The supplier must provide the operating system details for database solution.

Q.1647

The tenderer shall support and explain overload control mechanism.

Q.1648

The supplier must provide tools to import and export data in different formats (LDIF, XML, CSV, ASCII, logs, etc.).

18.8.

Operations, Administration, Maintenance and Provisioning (OAM&P)

Q.1649

The supplier shall explain the architecture of the provisioning system.

Q.1650

The Supplier shall state the provisioning options available for subscriber provisioning.

Q.1651

The Supplier shall describe his provisioning application and the hardware needed (e. g. Provisioning Gateway, etc.) in detail.

Q.1652

The supplier shall state what tools are available for analysis, extraction, manipulation and changing of sub-scriber data.

Q.1653

The supplier shall state different types of SPML requests supported by the Provisioning interface.

Q.1654

The supplier shall support the mechanism used, in case of errors in provisioning.

Q.1655

The supplier shall explain how the Provisioning system can be embedded with operators existing CRM/CCC system.

Q.1656

The supplier shall state different types of provisioning tasks supported in solution for provisioning.

Q.1657

The supplier shall state the different types of interfaces supported for subscriber and service data admin-istration.

Q.1658

The supplier needs to state if the provisioning application supports graphical management interface.

Q.1659

The Provisioning Front End shall accept and process provisioning requests with commands for bulk operations.

Q.1660

The supplier needs to specify how CRM/CCC transfers a bulk provisioning command to the database di-rectory.

Q.1661

The supplier shall state SPML requests supported by the Provisioning interface for mass provisioning.

Q.1662

By default in which order is the bulk order information displayed. The supplier needs to state if any other method of sorting is supported.

Q.1663

The supplier needs to ensure if bulk update operations can be easily expressed by providing a csv file where each line is dedicated to one subscriber.

Q.1664

Describe the backup and recovery solutions that will be provided as part of your proposal. The Supplier shall detail hardware, scripts and documentation provided
for this task within their answer.

Q.1665

The Supplier shall specify the provisioning interface(s) type.

Q.1666

The supplier shall describe in technical details how the proposed system will be secured (all types of security shall be provided).

18.9.

System Performance and quality indicators

Q.1667

The Supplier shall provide information on the performance of the offered provisioning solution, in terms of capacity and throughput, both at northbound and
southbound of the provisioning gateway. The provisioning solution must be dimensioned to assure the overall performance indicators of the platform specified in
"KPIs"

Q.1668

Functionality for triggering of PM alarms on threshold monitoring of counters and KPIs shall be provided.

Q.1669

Details of QoS handling end-to-end in your solution.

Q.1670

The Supplier shall provide QoS capabilities in order for the operator to obtain a comprehensive quality monitoring. This shall be provided through metrics such as
KPIs.

18.10.

Network Interfaces and Protocols

Q.1671

The supplier shall state all the protocols between database and other components with diagram. The supplier shall describe the communications protocols used to
access network elements for each component.

Q.1672

Detailed information about LDAP shall be provided.

Q.1673

The Database solution shall have logs, error handling, administration, and performance monitoring tool.

Q.1674

The Database must be flexible to adapt to the rapidly growth of subscriber dynamic changing data/value (attribute growth).

Q.1675

The Database must be flexible to support future network element interfaces and standard protocols for re-trieving data or adaptable to data virtualization.

Q.1676

The Database supplier must explain the network element interfaces and the standard protocols and how these elements interface with the Database system.

Q.1677

The Database system must be robust to handle data entries changes, in real-time and meet high performance (read/write) expectation.

Q.1678

The Database system must be robust to handle database configuration changes in real-time and meet high performance (read/write) expectation.

Q.1679

In any update to the data entries or database, the Database system must ensure the data accuracy and consistency.

Q.1680

The Database system must support LDAP protocol and LDAP security standards defined in the LDAP v3 RFCs.

Q.1681

The Database system must support secure connection for external applications.

Q.1682

The system must support dynamic transactions (read only, write only, mixed operations, etc.) from the Ap-plications/Clients and meet the traffic volume
expectation.

Q.1683

The supplier must provide the details about how the synchronization and data integrity is retained amongst the proposed servers.

Q.1684

The supplier must support an optimized to meet the Writes transactions to the database and also meet the Application/Client that performs Read transactions for
the same data attributes.

Q.1685

The supplier shall support secure communications protocols for all Network Element Access.

Q.1686

The Database solution must be able to recover if there is an unexpected system shutdown. All security files, tables, database and applications MUST be able to
survive system restart or power failure.

18.11.

Roadmap Requirements

Q.1687

Please specify a roadmap of subscriber database management standard basic and optional features and their timelines.

Q.1688

The supplier is required to provide the detail of their subscriber database management software roadmap. Application release shall run concurrently from the
release available at the time of this RFQ.

Q.1689

The Supplier shall state the availability roadmap of any such products, and state any interdependencies between them.

19

Mediation Solution

19.1.

LTE Support

Q.1690

Vendor must specify mediation system compatibility with enhanced support for LTE.

Q.1691

Vendor ability to update PGW-CDRs support via both FTP and GTP interfaces.

Q.1692

Specify ability to support SGW-CDRs support via both FTP and GTP interfaces.

Q.1693

Ability to integrate with 3rd party GGSN via Gy interface, Diameter Ro protocol support as per 3GPP rec-ommendation.

Q.1694

Ability to collect relevant information from all sub-areas and to be able to isolate the problem and increase the speed up the investigation of the faults.

Q.1695

Ability to display consolidated view of status of whole product and provide clear view if the product is working properly.

19.2.

Active Mediation

Q.1696

Ability to support online mediation using Diameter protocol.

Q.1697

Ability to integrate with subscriber profiling system through XML/SOAP/LDAP/SQL interface.

Q.1698

Ability to integrate with ISN through DCCA (Diameter credit control application).

Q.1699

Ability to integrate with 3rd party SMSC & MMSC for real-time credit check on the south bound.

Q.1700

Ability to integrate with SMSC & MMSC through IACC interface.

Q.1701

Ability to integrate with SMSC on northbound using SMPP/CIMD interface.

Q.1702

The offered system shall be able to handle convergent mediation (online and offline simultaneously).

Q.1703

The system shall support pre-integrated workflows to process the events and to integrate with standard network elements including but not limited to SMSC,
MMSC, ISN, and GGSN.

Q.1704

Ability to support TCP/IP interface.

Q.1705

Ability to support HTTP interface.

Q.1706

Ability to support CORBA interface.

Q.1707

Ability to interface with external balance holder.

Q.1708

Ability to integrate with multiple third-party online charging systems.

19.3.

Event File Collection

Q.1709

The ability to collect CDR data from MSC platform.

Q.1710

The ability to collect CDR data from Acision SMSC platform.

Q.1711

The ability to collect CDR data from Charging Gateway.

Q.1712

The ability to collect CDR data from MMSC.

Q.1713

The ability to collect data directly from SGSN.

Q.1714

The ability to collect data directly from GGSN.

Q.1715

The ability to collect data directly from Cisco CSG.

Q.1716

The ability to collect data files from generic source platforms using FTP and SFTP.

Q.1717

The ability to support push delivery where the source platform delivers data files to the mediation platform.

Q.1718

The ability to configure an unlimited number of collection sources.

Q.1719

The ability to collect events from multiple devices simultaneously, all processes operating independently from each other.

Q.1720

The ability to stop or disable collection of event data from any one source without effecting event collection from other sources.

Q.1721

The ability to securely store login, password/certificate and addressing details for accessing each device.

Q.1722

The ability to support multiple (different) collection methods for sources of the same type (for example MSC's), for reasons of software version, differing platform
vendor etc.

Q.1723

The ability to log the date, time, source, size and filename of each file collected

Q.1724

In the case of record delimited text files, the ability to count and log the number of records within the col-lected file.

Q.1725

The ability to verify the completeness of the collected file against the original source either via file size, checksum or other method

Q.1726

The ability to support flexible source file naming with no length or content restriction other than that specified by the underlying file system.

Q.1727

The ability to easily configure the collectors' file naming

Q.1728

The ability to archive on the remote (source) system, any files successfully collected (subject to capabilities of the source platform)

Q.1729

The ability to collect many source files and concatenate them (where technically feasible, flat text files with no headers for instance) into one single file for
forwarding to the next processing stage.

Q.1730

The ability to collect packed and/or compressed files (tar.gz for instance) and uncompress and unpack them for forwarding as a series of individual files to the
next processing stage.

Q.1731

The ability to collect zero length files.

Q.1732

Provision for the frequency of polling to be user configurable.

Q.1733

The ability to store an unlimited number of collection plans or schedule configurations

Q.1734

The ability to be configured to allow different collection plans for different days of the week and different times of day.

Q.1735

The ability to configure filename patterns and wildcards for filename matching to enable other files to reside in the same source directories and not be effected by
the file transfer mechanism.

Q.1736

The ability to validate the completeness of a collected file after it has been collected (compare record count with header record counter, hash of file against
header record hash etc).

Q.1737

A mechanism to prevent the loss of a source file in the case of a failure in a previous file transfer (on failure the source file is available for collection on the next
collection run).

Q.1738
Q.1739

A mechanism to prevent the duplicate collection of the same file (for instance, by rename or archiving of the source file after a successful transfer).
The ability to not commit as collected, files on the source platform if file transfer or validation of file com-pleteness fails.

Q.1740

The ability to attempt re-collection of previously failed files.

Q.1741

The ability to log all file collection failures including date/time, source, filename, reason for failure.

Q.1742

The ability to raise an alarm on file collection failure, or after a number of repeated file collection failures.

19.4.

Event File Delivery

Q.1743

The ability to deliver processed events to external systems in real-time.

Q.1744

The ability to deliver processed events to external systems via a file-based batch mechanism.

Q.1745

The ability to securely store login, password/certificate and addressing details for accessing each target system.

Q.1746

The ability to deliver files to local systems (using a locally mounted file system).

Q.1747

The ability to deliver files to remote systems using FTP, SFTP.

Q.1748

The ability to store an unlimited number of delivery plans or schedule configurations.

Q.1749

The ability to be configured to allow different delivery plans for different days of the week and different times of day.

Q.1750

The ability to run an unlimited number of delivery processes in parallel.

Q.1751

The capability of each delivery process to be independent of another (unless one delivery process has been configured to be dependent upon input data from
another delivery process).

Q.1752

The ability to disable one delivery process without effecting other delivery processes

Q.1753

The capability of delivery processes to work independently of the event collection, and event processing processes.

Q.1754

The ability to archive event files after successful transfer.

Q.1755

The ability to remove event files after a successful transfer.

Q.1756

The ability to detect, log and report delivery failures.

Q.1757

The ability to store locally files that fail to deliver.

Q.1758

The ability to repeatedly attempt to re-transmit files that fail delivery (based upon a configurable re-try delay).

Q.1759

The ability for the collection process for a stream to disable itself after a user configurable number of con-secutive delivery attempt failures.

Q.1760

The ability to transfer the same file to multiple target locations, not necessarily on the same remote systems.

Q.1761

The ability to log all file transfers, the date/time, source filename, target server/directory, file size, time take and success/failure status of such transfers.

Q.1762

The ability to configure different delivery schedules for different days of the week and different times of day.

Q.1763

The capability of the event delivery component to be triggered automatically upon the creation of a file as a result of a successful file collection event.

Q.1764

The ability for the mediation component to be optionally capable of creating an empty "trigger" file in a re-mote directory either the same or different to the target
directory for the data file when transferring a data file.

Q.1765

Provision that the file transfer method ensures that the remote file is not available to any other application until the file is fully written and verified. For example by
means of permission manipulation or file renaming.

Q.1766

Provision that the file transfer has a method to verify the remote file after writing to ensure that it is an exact copy of the original file.

Q.1767

The ability of the mediation component to not archive or remove the local file if the file transfer is not suc-cessful.

Q.1768

The ability to compress the target file before or after delivery if so configured.

Q.1769

The ability to remove the remote file in case of incomplete file transfer.

Q.1770

The ability to detect, log and report all typical file transfer errors (file permissions, login failures etc).

Q.1771

The ability to detect, report and recover from disk full events at the remote endpoint when transferring files.

Q.1772

The ability to raise and alarm on file delivery failure, or after a number of repeated file delivery failures.

Q.1773

The ability to re-transmit any files any number of times under the control of the system administrator.

Q.1774

The ability to deliver zero length files.

Q.1775

The ability to concatenate many files (where technically feasible, flat text files with no headers for instance) into one single packed and/or compressed file for
forwarding to the next processing stage.

Q.1776

The ability to pack and/or compressed multiple files (into a tar.gz for instance) and use the resulting file as the object to be delivered.

Q.1777

The ability to transform input filenames to different target filenames during delivery based on configurable pattern rules.

19.5.

Event File Processing (Input)

Q.1778

The ability to process files in ASN.1 format.

Q.1779

The ability to process files in NRTRDE TD.35 format.

Q.1780

The ability to process files in TAP 3.10 format.

Q.1781

The ability to process files in TAP 3.11 format.

Q.1782

The ability to process GTP' CDRs.

Q.1783

The ability to process files in plain text with a single record format.

Q.1784

The ability to process files in plain text with multiple record formats.

Q.1785

The ability to process files in XML format.

Q.1786

The ability to process files in a user definable binary format.

Q.1787

The ability to process files with user definable record terminators.

Q.1788

The ability to process files with fixed length record formats.

Q.1789

The ability to process files with variable length record formats.

Q.1790

The ability to process files with user definable field delimiters.

Q.1791

The ability to validate every event files to ensure that it is complete.

Q.1792

The ability to detect and reject any event files that are duplicates of files previously processed where a file with the same name has been processed before.

Q.1793

The ability to detect and reject any event files that are duplicates of files previously processed where duplicate data is presented in a file with a different filename
(i.e. via hash or checksum).

Q.1794

The ability to log duplicate event files and suspend processing of that file.

Q.1795

The ability to override the duplicate check on a source by source basis.

Q.1796

The ability to override the duplicate check on a file by file basis.

Q.1797

The availability of an easily configurable dup-check key.

Q.1798

Where event files needs to be processed in date time order and the filename contains a date time stamp, the device shall process files in ascending date order
(oldest file first).

Q.1799

Where event files need to be processed in strict sequence and the file indicates a sequence number, the device shall not process event files that are received out
of sequence. Processing shall be suspended until the file with the correct sequence number.

Q.1800

The ability to disable file-sequencing checks via a user parameter.

Q.1801

The ability to process event files in an out of sequence order if so configured.

Q.1802

The ability of the event file processing modules to be independent of the event collector processes.

Q.1803

The ability for event files processing to continue if the event collector process is not running.

Q.1804

The ability for event files processing to continue if the network element is not available.

Q.1805

The ability to run one event file processing program to process all files from all network elements, or one event file processing program for each network element,
or any combination in-between.

Q.1806

The ability to provide event files to the event file-processing module without the file having been collected by the event collector process (i.e. i.e. an event collector
process exists but a file is presented manually to the event file processor, bypassing the collector).

Q.1807

The ability of the event file processing sub system to recognize input files by means of filename masks and wildcards so that different files may be mixed in the
same directory without causing a conflict.

Q.1808

The ability to provide event file processing facilities for an input stream without providing a corresponding event collector process (for push type systems where
event data is delivered to the mediation device).

Q.1809

The ability to disable event file processing from one network element or data source without effecting the processing from other network elements. This feature
shall not be in any way linked or reliant upon an event collection process.

Q.1810

The ability to log details of each file processed, including date and time processing starts, number of records processed and total processing time.

Q.1811

Where event file processing requires the split of records by different record types, or different destination (process, drop, error etc) the ability to log the number of
records of each type processed, and details of their destination within the product.

Q.1812

The ability of the device to process zero length files.

Q.1813

The ability of the device to process event files of the same types or from the same source types with different format version numbers and different record formats
(i.e. where two MSCs are running different software ver-sions and output the same type of data in different formats).

19.6.

Event File Processing (Output)

Q.1814

The ability to output files in ASN.1 format.

Q.1815

The ability to output files in NRTRDE TD.35 format.

Q.1816

The ability to output files in TAP 3.10 format.

Q.1817

The ability to output files in TAP 3.11 format.

Q.1818

The ability to output files in plain text with a single record format.

Q.1819

The ability to output files in plain text with multiple record formats.

Q.1820

The ability to output files in XML format.

Q.1821

The ability to output files in a user definable binary format.

Q.1822

The ability to create files with user definable record terminators.

Q.1823

The ability to create files with fixed length record formats.

Q.1824

The ability to create files with variable length record formats.

Q.1825

The ability to create files with user definable field delimiters.

Q.1826

The ability to support user definable output file names.

Q.1827

The ability to create output files maintaining a unique sequence number for each file created within each output stream.

Q.1828

The ability to embed output file sequence numbers in filenames.

Q.1829

The ability to embed the date and time of file creation in the output filenames (in a user definable format).

Q.1830

The ability to embed any field or any part of a field from the first record in the file, in the output filename.

Q.1831

The ability to embed portions of the input filename in the output filename.

Q.1832

The ability to embed the input stream name or identifier in the output filename.

Q.1833

The ability to embed the output stream name or identifier in the output filename.

Q.1834

The ability to embed the result of a lookup operation in the output filename.

Q.1835

The ability to create output files containing header and trailer control records with a user definable format.

Q.1836

The ability to embed the number of records in the file within a header record.

Q.1837

The ability to embed the number of records in the file within a trailer record.

Q.1838

The ability to embed the filename within a header record.

Q.1839

The ability to embed the filename within a trailer record.

Q.1840

The ability to embed the file creation date and time (in a user definable format) within a header record.

Q.1841

The ability to embed the file creation date and time (in a user definable format) within a trailer record.

Q.1842

Provision for logging the creation of every output file including date and time, filename, details of the module or stream which generated the file, file size and the
number of records contained in the file.

Q.1843

The ability to define the location for the creation of an output file.

Q.1844

Provision for the creation of an output file to optionally be able to automatically trigger a file delivery process.

Q.1845

The ability to automatically compress an output file immediately after creation.

Q.1846

The ability for the file output process to concatenate it's data to the end of an existing output file.

Q.1847

The ability for the file output process to add its data to an existing archive file (i.e. tar).

Q.1848

The ability to detect and fail gracefully on file write failures (permissions issues, directory naming etc) and disk full events during file writing.

Q.1849

The ability to generate log records on failures such as file write failure and disk full events (assuming logs are not stored in the same location as normal file
output).

Q.1850

Provision for the file creation method to ensure that the final file is not available to any other application (by means of permission manipulation or file renaming for
example) until the file is fully written and verified.

Q.1851

The ability of the file creation process to be able to disable itself after a user configurable number of con-secutive file creation failures.

Q.1852

The ability to generate zero length files.

Q.1853

The ability to route input data from one input file to multiple different output files based on logic conditions and the content of the record.

Q.1854

The ability to write output records directly to a local or remote Oracle table instead of creating an output file.

19.7.

Event Processing

Q.1855

The ability to process events from both real-time and file based collection processes.

Q.1856

The ability to ensure that in all cases no records are lost and the device must be able to account for the destination of every record and that the total count for all
destinations equals the total number of records re-ceived.

Q.1857

The ability to validate every event record to ensure that it is complete.

Q.1858

The ability to validate every event record to ensure that data field values are valid.

Q.1859

The ability to process un-collated event records and to combine these event records using configurable parameters or user definable rules to produce a single
combined event record.

Q.1860

The ability to correlate and aggregate records that originate in different devices.

Q.1861

The ability to correlate and aggregate records that originate in geographically separated processes.

Q.1862

The ability to correlate and aggregate events of different source formats.

Q.1863

The ability to perform event correlation and aggregation in as near real-time as possible.

Q.1864

The ability to perform event correlation and aggregation via a file based batch mechanism.

Q.1865

The ability to detect and reject any events that are duplicates of events previously processed.

Q.1866

The ability to log duplicate events and suspend processing of that event.

Q.1867

The ability to override the duplicate check on a source by source basis (e.g. network device, API).

Q.1868

The ability to detect partial event records generated during an event and to combine these records using configurable parameters or user definable rules to
produce a single combined record covering the entire event.

Q.1869

The ability to process event data records that have missing event parts and combine the remaining parts after a user configurable timeout period.

Q.1870

The ability to log any events where an incomplete series of partial events are combined into a single event.

Q.1871

The ability to use rules to detect events matching certain criteria and be able to write those records to a "drop" file, and prevent them from being passed to the
next stage of processing.

Q.1872

The ability to allocate a reason code, to indicate the reason for filtering, to each "dropped" event.

Q.1873

The ability to create one "drop" file for each input file, reusing parts of the input file name to generate the drop file.

Q.1874

The ability to define the format of the drop file records in the same way as any other output file.

Q.1875

The ability to easily determine from a filter reason code which rule or rules were used to determine that the event shall be filtered.

Q.1876

The ability to record all "dropped" events, configurable by the user.

Q.1877

The ability to carry out event filtering in real time.

Q.1878

The ability to carry out event filtering on file based event processing.

Q.1879

The ability to create user defined rules to modify the contents of any field in any record.

Q.1880

The ability to use any normal rule facilities and functions when modifying any event.

Q.1881

The ability to replace the content of a field based upon a lookup.

Q.1882

The ability to take an event record and to replicate it, creating one or more additional records with identical contents (usually so that the duplicated record(s) may
be modified and passed down a different delivery path).

Q.1883

The ability to take an event record and to replicate it, creating one or more additional records in different formats.

Q.1884

The ability for replicated records (subject to any duplicate constraints) to travel down the same logic path as the original record.

Q.1885

The ability to use rules to detect events matching certain error criteria.

Q.1886

The ability to allocate each event in error a reason code to indicate the reason for the error.

Q.1887

The ability to write error records to a table or other repository which is accessible to a mediation administrator for the purposes of examination and possible
correction and re-submission.

Q.1888

The ability to carry out sanity or range checks on all fields which can be validated. Including but not limited to: Dates, Times, Items which have a fixed range of
values or a fixed list of codes (for example record type, basic service code, tariff class etc).

Q.1889

Ability to keep statistics relating to errors trapped including but not limited to: total count of the number of events in error, total count for each reason code, total
count by collection process or network element.

Q.1890

Ability to determine easily from an error reason code which validation routine or which rule or rules were used to determine that the event shall be in error.

Q.1891

The ability to flag events for reprocessing, both individually and in batches specified by user defined criteria.

Q.1892

The ability to modify error or drop events, both individually and in batches specified by user defined criteria.

Q.1893

Provision for all changes to events (regardless of whether the reprocessing flag is set) to be logged including but not limited to: User details, Date and time of the
change, Nature of the change.

Q.1894

The ability to reprocess error and drop events to be based on individual record "reprocessing" flags and shall require no user intervention to reprocess these
events other than to set the flag initially.

Q.1895

The ability for error/drop event correction and resubmission to be via GUI or scripting.

Q.1896

The ability to specify user definable search criteria for resubmission of events.

Q.1897

The ability to define known error repair rules to automatically detect and correct known error patterns and to automatically resubmit those records for reprocessing.

Q.1898

The ability to log details of all event resubmissions including but not limited to: User details, Date/Time of resubmission, Count of records resubmitted, Count of
record destinations/processing outcomes.

Q.1899
Q.1900

Provision for resubmitted events to be processed in the same way as original events.
The ability to support multiple versions of record formats from sources of the same type (where multiple sources of the same type (for example MSC's) are
running different versions of software).

Q.1901

The availability of an easily configurable number analysis component.

19.8.

Validation & Enrichment

Q.1902

The ability to support lookups to flat files within the mediation platform.

Q.1903

The ability to support lookups to database tables local to the mediation platform.

Q.1904

The ability to support lookups to remote Oracle database tables.

Q.1905

The ability to validate any field within an input record by use of scripting rules.

Q.1906

The ability to validate any field within an input record via a look up to a table of allowable values.

Q.1907

The provision of pre-build functions for validated common data items such as dates and times.

Q.1908

The ability to enrich incoming event records by using one or more input fields to look up and return several data items from a lookup table.

19.9.

Reference Data Configuration

Q.1909

The ability to place all configuration/reference data under source code control (i.e. CVS, SVN, etc).

Q.1910

The ability to apply an internal versioning mechanism on all configuration/reference data.

Q.1911
Q.1912

The ability to export an entire configuration/reference data set (for importing to another platform i.e. test or production).

Q.1913

The ability to import an entire configuration/reference data set from another platform.

Q.1914

The ability to use an entire configuration/reference data set to restore back to an earlier version of configu-ration (on the same platform/instance).

Q.1915

The ability to assign a starting and ending date and time for all configuration records and reference data.

Q.1916
Q.1917

The ability to store multiple versions of the same configuration and reference data (with the same keys), but which have different start/end date/time values [i.e.
records are only unique within a particular date/time period].
The ability to select the correct configuration or reference data which is/was valid at the date and time of the event record.

19.10.

Monitoring & Control GUI

Q.1918

A monitoring and control GUI to allow an administrator to stop, start, pause and monitor all mediation pro-cesses.

Q.1919

The ability to view all input and output data/file queues.

Q.1920

The ability to view the status of file collection for each source showing date and time of last collection and name of last file collected.

Q.1921

The ability to view the status of file delivery for each destination, showing date and time of last delivery and name of last file delivered.

Q.1922

The ability to allow the pausing of data collection from any one data source (i.e. one MSC).

Q.1923

The ability to allow the pausing of data collection from any user defined group of data sources (i.e. all MSCs).

Q.1924

The ability to allow the pausing of data delivery to any one delivery destination.

Q.1925

The ability to allow the pausing of data delivery to any user defined group of delivery destinations.

Q.1926

The ability to allow the pausing of core processing for any one data source.

Q.1927

The ability to allow the pausing of core processing for any user defined group of data sources.

Q.1928

The ability to view statistics of performance and data throughput in terms of number of files per minute or hour, number of records per minute or hour per data
point (one input source or one delivery destination).

Q.1929

The ability to view statistics of performance and data throughput in terms of number of files per minute or hour, number of records per minute or hour for a user
defined group of data points [multiple input source or multiple delivery destinations]).

Q.1930

The ability to view statistics of performance and data latency in terms of time to process a file/CDR from collection to distribution.

Q.1931

The ability to view statistics of number and percentage of records in error, dropped and passed for further processing per data source.

Q.1932

The ability to view statistics of number and percentage of records in error, dropped and passed for further processing per user defined group of data sources.

Q.1933

The ability to view statistics of number of events of a specific call scenario, or a set of scenarios, per file.

Q.1934

The ability to detect file volume trends on the collectors.

Q.1935

The ability to configure user definable alarm conditions for all mediation sub processes. For example: - backlog of files for any one network element greater than a
user defined limit, when duplicate files are received, when duplicate events are received, when files are received out of sequence.

Q.1936

Provision for several levels of severity for alarms such that they can be prioritized.

Q.1937

The ability to adjust the number of severity levels.

Q.1938

The ability to filter out alarms of a particular severity.

Q.1939

Provision for all alarms to be logged

Q.1940

The ability of the alarm monitor to allow the operator to drill down to obtain further details of the alarm for diagnostic purposes. The level of information shall be
equal to or greater than that written to log files.

Q.1941

The ability to provide data for alarms to show graphically against the relevant element in the process diagram

Q.1942

Provision for the monitor to be able to be run from remote systems (i.e. not on the mediation platform)

Q.1943

Ability for monitoring of all functions and alarms via an industry standard web browser.

Q.1944

The ability of the device to raise alarms via a variety of protocols. Including but not limited to: TCP/IP socket connection, UDP datagram, SNMP traps.

Q.1945

The ability of the device to raise alarms and send notifications via a variety of signaling devices.

Q.1946

The ability of the device to integrate alarms to an enterprise monitoring solution, i.e. HP Openview/ITO

Q.1947

Provision for a public API to be available for other software to raise alarms to the mediation device alarm monitor.

Q.1948

Provision of facilities for managing batch jobs. Including: A systems management tool for batch jobs including: control, failure reporting and housekeeping
routines, Capability to manually control batch jobs including repeating jobs in full or part after a failure

Q.1949

The ability to limit access to certain functions within the Monitoring & Control GUI on a role basis

Q.1950

The monitoring and control GUI shall be available in multiple languages and instantly switchable

Q.1951

The monitoring and control GUI shall be delivered with English as the default language.

Q.1952

The monitoring and control GUI shall be have French available as a selectable language

Q.1953

The ability to provide data for generating user definable tables and graphs of available statistics and trending metrics

Q.1954

The ability to provide data for creating user definable dashboards containing statistics tables, graphs, queue information and other available statistical or
monitoring information

19.11.

Reporting & Statistics

Q.1955

The ability to access all statistical data stored in the system using standard Oracle SQL tools or tools using a standard ODBC or OLE DB interface.

Q.1956

Ability to interface with any third party system (e.g.: OCH DWH) in order to push statistics and reporting in-formation which will be stored and published at OCH
level

Q.1957

Statistical information retention timeframe shall be configurable (up to a maximum of 6 months of historical data)

19.12.

Trending & Alarming

Q.1958

The ability to configure trending controls to trigger an alarm when dropped file levels (percentage or absolute qty of files) pass outside of user defined limits within
a user defined time window, over a user defined historical period, with separate metrics available for different user definable day of the week and time of day.

Q.1959

The ability to configure trending controls to trigger an alarm when error file levels (percentage or absolute qty of files) pass outside of user defined limits within a
user defined time window, over a user defined historical period, with separate metrics available for different user definable day of the week and time of day.

Q.1960

The ability to configure trending controls to trigger an alarm when dropped event levels (percentage or ab-solute qty of records) pass outside of user defined limits
within a user defined time window, over a user defined historical period, with separate metrics available for different user definable day of the week and time of
day.

Q.1961

The ability to configure trending controls to trigger an alarm when error event levels (percentage or absolute qty of records) pass outside of user defined limits
within a user defined time window, over a user defined his-torical period, with separate metrics available for different user definable day of the week and time of
day.

Q.1962

The ability to configure trending controls to trigger an alarm when input data source traffic levels (percentage or absolute values of files or records) pass outside of
user defined limits within a user defined time window, over a user defined historical period, with separate metrics available for different user definable day of the
week and time of day.

Q.1963

The ability to configure trending controls to trigger an alarm when output data traffic levels (percentage or absolute values) pass outside of user defined limits
within a user defined time period, with separate metrics available for different user definable day of the week and time of day.

Q.1964

The ability to configure trending controls to trigger an alarm when input vs. output data traffic levels (adjusted by dropped, error and duplicated records) vary by
more than user defined limits, within a user defined time period, with separate metrics available for different user definable day of the week and time of day.

Q.1965

The ability to configure trending controls to trigger an alarm when aggregation statistics (percentage or ab-solute values) pass outside of user defined limits within
a user defined time period, with separate metrics available for different user definable day of the week and time of day.
The ability to configure trending controls to trigger an alarm when latency <from file collection to input of core processing> passes outside of user defined limits
within a user defined time window, over a user defined his-torical period, with separate metrics available for different user definable day of the week and time of
day.
The ability to configure trending controls to trigger an alarm when latency <from start to end of core pro-cessing> passes outside of user defined limits within a
user defined time window, over a user defined historical period, with separate metrics available for different user definable day of the week and time of day.

Q.1966

Q.1967

Q.1968

The ability to configure trending controls to trigger an alarm when latency <from output of core processing to delivery> passes outside of user defined limits within
a user defined time window, over a user defined historical period, with separate metrics available for different user definable day of the week and time of day.

19.13.

Security & Compliance

Q.1969

The ability to define and allocate specific users and roles for access to critical mediation configuration functions such as modification of scripts, access to lookup
data, collection and delivery process configuration etc.

Q.1970

The ability to define and allocate specific users and roles for access to the main administration controls (starting & stopping processes, reporting, statistics etc).

Q.1971

The ability to protect access to security related data items such as usernames, passwords and certificates (for collection and delivery processes etc).

Q.1972

The ability to carry out one-way encryption/hashing when storing passwords.

Q.1973

The ability to log all login events to the application.

Q.1974

The ability to log details of all changes to configuration including: user details, date and time of the change, the location of the user (PC identifier or IP address),
an identifier of the configuration item, brief summary of the nature of the change.

Q.1975

The ability to protect all log files to prevent unauthorized changes to the log file contents.

Q.1976

The ability to protect all configuration data in a production environment to prevent accidental or intentional alteration.

Q.1977

The ability to hold previous versions of configuration data so that reversion to integral earlier versions is possible.

19.14.

Performance

Q.1978

The ability for the system to distribute groups of processing components across multiple physical machines and locations (i.e. collection nodes close to network,
remote from central core processing).

Q.1979

The ability for processing components to be scaled, multiplied or run multi-threaded (to allow additional processed to be created to handle increasing load).

Q.1980

The ability to specify a minimum and maximum number of processes allowable per processing component.

Q.1981

The ability to specify a number of additional processing components to automatically start (to share load) when incoming data volumes or processing time
exceeds a user defined threshold.

Q.1982

The ability to specify a number of process components to automatically terminate when incoming data volumes or processing time falls below a user defined
threshold and remains there for more than a user defined time period.

Q.1983

The ability to allow the administrator to manually start and stop additional processing components within the pre-defined minimum and maximum quantities.

Q.1984

Following system outage, a backlog shall be cleared in no longer that the outage period (i.e. 6 hours outage, all backlog shall be cleared within the following 6
hours).

Q.1985

Subject to disk space availability, the system shall be capable of archiving raw input data for 1 year (with no performance penalty on mediation processing and no
exhaustion of resources or failures).

Q.1986

Subject to disk space availability, the system shall be capable of archiving output data for 1 year (with no performance penalty on mediation processing and no
exhaustion of resources or failures).

Q.1987

Subject to disk space availability, the system shall be capable of archiving other output data for 6 months (with no performance penalty on mediation processing
and no exhaustion of resources or failures).

19.15.

Availability

Q.1988

The entire system shall remain operational during normal backups.

Q.1989

In the case of a system failure or corruption it shall be possible to recover from backups and transaction logs to an operational processing state (not necessarily
including archive data) within 1 hour, and full state (with ar-chive data) within 8 hours.

Q.1990

The system shall be designed for "always on" operation, allowing it to run without the need for frequent re-starts or regular scheduled downtime.

Q.1991

The system shall allow for configuration changes to processing components without the need to stop the entire platform.

Q.1992

The system shall allow for script/business logic changes without the need to stop the entire platform.

Q.1993

The ability for the platform to monitor its own processes and to automatically restart processes if they fail.

Q.1994

The ability to produce alerts if a process fails.

19.16.

Scheduler

Q.1995

The ability to create and maintain schedules for timing of automatic process runs (for processes that are not already demonized and always running).

Q.1996

The ability to configure schedules based on year, month, day, day of the week, hour minute and second.

20

DNS Solution

20.1.

General

Q.1997

The Seller shall state whether to deploy a standalone DNS solution, or integrate with Buyers live DNS connected in Gn network.

Q.1998

The Domain Name Service (DNS) solution shall be used to resolve a DNS string into a list of possible EPC-GW addresses which serve the UE's location.

Q.1999

The Seller shall propose a DNS solution which shall include the mechanism of selection of EPS (ie. MME, S-GW,& PDN-GW) and GPRS (ie. SGSN & GGSN)
network entities in the activities of mobility & session man-agement.

Q.2000

The Seller shall provide DNS solution to support the LTE to LTE roaming and LTE to legacy network roaming.

Q.2001

The DNS solution shall include functionality to allow for the retrieval or provision of additional information regarding the EPC-GW capabilities.

Q.2002

The proposed DNS solution shall comply with the following standards.

Q.2002
A.
Q.2002
B.
Q.2002
C.
Q.2002
D.
Q.2002
E.
20.2.

3GPP TS23.003

Q.2003

The DNS shall have the capability to be configured either authoritative (both primary and secondary) or caching DNS.

Q.2004

The DNS shall support both types of query mechanism: Recursive and Forwarding.

Q.2005

The DNS shall return EPC-GW IP address including Weight Factors.

Q.2006

The DNS shall support A and AAAA resource record.

Q.2007

The DNS shall support NAPTR resource record those can be prioritized using embedded order and prefer-ence values defined by the DNS administrator.

Q.2008

The DNS shall support SRV resource record allows DNS administrators to use pool of servers for a single domain with static load balancing to each server, to
move services from host to host, and to designate some hosts as primary servers for a service from a pool of hosts.

Q.2009

The Seller shall explain in detail how load distribution control can be achieved. Flexibility on controlling the MME & S/P-Gw/GGSN load/traffic distribution through
simple parameters change in the DNS solution.

Q.2010

The DNS shall support P-GW Discovering and Selecting for 3GPP access.

Q.2011

The DNS shall support P-GW Discovering and Selecting for non-3GPP access.

Q.2012

The DNS shall support S-GW Discovering and Selecting in 3GPP roaming case.

Q.2013

The DNS shall support S-GW Discovering and Selecting in 3GPP non-roaming case.

Q.2014

The DNS shall support MME Discovering and Selecting.

Q.2015

The DNS shall support SGSN Discovering and Selecting.

Q.2016

The DNS shall support Gateway Selection for SIPTO.

Q.2017

The DNS shall support MSC server Discovering and Selecting.

Q.2018

The DNS shall support APN Operator Identifier Resolution.

Q.2019

The DNS shall support Routing Area Resolution.

3GPP TS29.303
IETF RFC 1035
IETF RFC 2181
IETF RFC 2606
Functional Requirements

Q.2020

The DNS shall support Tracking Area Resolution.

20.3.

Feature Requirements

Q.2021

The DNS shall support IPv6.

Q.2022

The DNS shall support IPv4v6 dual stack.

Q.2023

The DNS shall support GRX/IPX service.

Q.2024

The DNS shall support DNS64.

20.4.

Capacities and Performance

Q.2025

The Seller shall advise how the DNS is being dimensioned.

Q.2026

Performance management shall be provided in term of loading, and traffic statistics.

21

CGNAT Solution

21.1.

NAT Functions

Q.2027

The system shall provide IPv4 and IPv6 Dual Stack at the same time.

Q.2028

The system shall provide NAT44 and NAT64 functions.

Q.2029

The system shall provide Deterministic NAPT function.

Q.2030

The system shall provide DS-lite Tunneling function.

Q.2031

The system shall provide DNS64 function.

Q.2032

The system shall provide the flexibility to define different NAPT timeout period based on different TCP or UDP applications.

Q.2033

The system shall support Application Level Gateways (ALGs) for FTP, TFTP, RTSP, HTTP and SIP function.

Q.2034

The system shall provide network security function to protect external to internal TCP, UDP and ICMP pro-tocol attack.

Q.2035

The system shall support logging function to record NAPT connection mapping information include time stamp, source IP: source port, translation IP: translation
port and destination IP: destination port .

21.2.

Platform Functions

Q.2036

For NAPT capacity and requirement expansion, the system shall support module expansion in single chassis.

Q.2037

The system shall support at least 8 x 10Gbps (SFP+) and 2 x 40Gbps (QSFP+) Ethernet fiber interfaces in single module and support at least 32 x 10Gbps
(SFP+) and 8 x 40Gbps (QSFP+) Ethernet fiber interfaces for full chassis capacity.

Q.2038

The system shall support at least 80Gbps L4 NAT throughput in single module and at least 300Gbps L4 NAT throughput for full chassis capacity.

Q.2039

The system shall support at least 1.4M NAT connection per second (cps) and 36M NAT concurrent con-nections in single module and at least 5.6M NAT
connection per second (cps) and 144M NAT concurrent con-nections for full chassis capacity.

22

Security Solution

Q.2040

The Seller shall state compliance to 3GPP Release TS 33.102 and 33.203 for UMTS packet core.

Q.2041

The Seller shall state compliance to 3GPP TS 33.401 and 33.210 for Evolved Packet Core and IMS.

Q.2042

The Seller is requested to provide information on any additional security mechanisms.

Q.2043

The tendered system shall provide User to Network security which protects the network-to-terminal ex-changes over the radio interface.

Q.2044

The tendered system shall support provide Network domain security (NDS) which protects the interfaces between the EPS and IMS network nodes.

Q.2045

The tendered system shall support algorithm selection and negotiation with Security mode command.

Q.2046

The tendered system shall support user identity confidentiality. The S-TMSI, the shortened form of the GUTI, is used to support the subscriber identity
confidentiality with more efficient radio signalling procedures (e.g. paging and Service Request).

Q.2047

The tendered system shall support both Native and Mapped Security context with the operator configuration control.

Q.2048

The tendered system shall support EPS AKA as the authentication and key agreement procedure.

Q.2049

The tendered system shall support security mechanisms for cryptographically protecting NAS signalling exchanged between the UE and MME in compliance with
3GPP TS 33.401.

Q.2050

The tendered system shall support authentication and key agreement in compliance with 3GPP TS 33.401.

Q.2051

The tendered system shall support user data and signaling confidentiality by supporting ciphering and in-tegrity to NAS signaling.

Q.2052

The tendered system shall be able to select NAS Integrity Protection and Ciphering algorithm(s).

Q.2053

The tendered system shall support intra-RAT security context transfer in compliance with 3GPP TS 33.401.

Q.2054

The tendered system shall support security context transfer to/from GERAN and UTRAN in compliance with 3GPP TS 23.401.

Q.2055

The tendered system shall support the AS security mode command procedure as defined in TS 33.401.

Q.2056

The tendered system shall support the NAS Security Mode Command procedure as defined in TS 33.401.

Q.2057

The proposed MME shall support the ability to request a UE to provide it's IMEI in the NAS Security Mode Complete message.

23

IP Transport Solution

23.1.

General Requirements

Q.2058

The Seller shall build a IP MPLS Backbone that is capable of providing end-to-end transport from core to access network and fulfill LTE various service
requirement
The system architecture of the proposed solution shall be modular, scalable and flexible, in order to allow the future scaling of the equipment capacity in
accordance with the network requirement.

Q.2059

Q.2060

All the Ethernet line interface cards (FE, GE,10G ) must be non blocking architecture. The Seller must de-scribe the equipment hardware architecture in order to
achieve non blocking line interface card.

Q.2061

The proposed system shall be capable to provide the redundancy ability for the routing engine, switching board, management interface, cooling, and power
supplies to minimize network disruptions if a failure occurs.

Q.2062

The proposed system shall support separated data and control planes architecture.

Q.2063

The routing engine, line cards, switching control board and power supplies shall be hot swappable or hot pluggable to minimize service disruption.

Q.2064

The proposed equipment must be able to support QoS with intelligent traffic management.

Q.2065

The proposed system shall support IGP routing protocol and compliance to the following RFC standards

Q.2065
A.
Q.2065
B.
Q.2065
C.
Q.2065
D.
Q.2065
E.
Q.2065
F.
Q.2065
G.
Q.2065
H.
Q.2065
I.
Q.2065
J.
Q.2065
K.
Q.2065
L.
Q.2065
M.
Q.2065
N.

RFC 2328 : OSPF v2,

RFC 2328, OSPF Version 2
RFC 2370, The OSPF Opaque LSA Option
RFC 3101, The OSPF Not-So-Stubby Area (NSSA) Option
RFC 3509, Alternative Implementations of OSPF Area Border Routers
RFC 3623, OSPF Graceful Restart
RFC 3630, Traffic Engineering (TE) Extensions to OSPF Version 2
RFC 4203, OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) (only interface switching)
RFC 4576, Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS Virtual Private Networks (VPNs)
RFC 4577, OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)
RFC 5185, OSPF Multi-Area Adjacency
RFC 5286, Basic Specification for IP Fast Reroute: Loop-Free Alternates
RFC 1195, Use of OSI IS-IS for Routing in TCP/IP and Dual Environments
RFC 3787, Recommendations for Interoperable IP Networks Using Intermediate System to Intermediate System (IS-IS)

Q.2065
O.
Q.2065
P.
Q.2065
Q.
Q.2065
R.
Q.2066

RFC 5305, IS-IS Extensions for Traffic Engineering

Q.2066
A.
Q.2066
B.
Q.2066
C.
Q.2066
D.
Q.2066
E.
Q.2066
F.
Q.2066
G.
Q.2066
H.
Q.2066
I.
Q.2066
J.
Q.2066
K.
Q.2066
L.
Q.2066
M.
Q.2066
N.
Q.2066
O.
Q.2066
P.
Q.2066
Q.
Q.2066
R.
Q.2066
S.
Q.2067

RFC 1772, Application of the Border Gateway Protocol in the Internet

Q.2067
A.
Q.2067
B.
Q.2067
C.
Q.2067
D.

RFC 1981, Path MTU Discovery for IP version 6

Q.2067
E.

RFC 2373, IP Version 6 Addressing Architecture

Q.2067
F.

RFC 2460, Internet Protocol, Version 6 (IPv6) Specification

Q.2067
G.

RFC 2461 or RFC 4861 Neighbor Discovery for IP Version 6 (IPv6)

Q.2067
H.

RFC 2462, IPv6 Stateless Address Auto configuration

Q.2067
I.

RFC 2463, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification

Q.2067
J.

RFC 2464, Transmission of IPv6 Packets over Ethernet Networks

RFC 1058, Routing Information Protocol

RFC 2082, RIP-2 MD-5 Authentication
RFC 2453 RIPv2
The proposed system shall support BGP routing protocol and compliance to the following RFC standards

RFC 1965, Autonomous System Confederations for BGP

RFC 1966, BGP Route Reflection: An Alternative to Full-Mesh IBGP
RFC 1997, BGP Communities Attribute
RFC 2270, Using a Dedicated AS for Sites Homed to a Single Provider
RFC 2283, Multiprotocol Extensions for BGP-4
RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option
RFC 2439, BGP Route Flap Damping
RFC 2545, Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
RFC 2796, BGP Route Reflection
RFC 2858, Multiprotocol Extensions for BGP-4
RFC 2918, Route Refresh Capability for BGP-4
RFC 3065, Autonomous System Confederations for BGP
RFC 3107, Carrying Label Information in BGP-4
RFC 3392, Capabilities Advertisement with BGP-4
RFC 4271, A Border Gateway Protocol 4 (BGP-4)
RFC 4724, Graceful Restart Mechanism for BGP
RFC 4781, Graceful Restart Mechanism for BGP with MPLS
RFC 4893, BGP Support for Four-octet AS Number Space
The proposed system shall support IPv6 routing protocol and compliance to the following RFC standards

RFC 2080, RIPng for IPv6

RFC 2081, RIPng Protocol Applicability Statement
RFC 2283, Multiprotocol Extensions for BGP-4

Q.2067
K.

RFC 2465, Management Information Base for IP Version 6: Textual Conventions and General Group

Q.2067
L.

RFC 2472, IP Version 6 over PPP

Q.2067
M.

RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

Q.2067
N.

RFC 2491, IPv6 Over Non-Broadcast Multiple Access (NBMA) networks

Q.2067
O.

RFC 2526, Reserved IPv6 Subnet Anycast Addresses

Q.2067
P.

RFC 2545, Use of BGP-4 Multi-Protocol Extensions for IPv6 Inter-Domain Routing

Q.2067
Q.

RFC 2578, Structure of Management Information Version 2 (SMIv2)

Q.2067
R.

RFC 2675, IPv6 Jumbograms

Q.2067
S.

RFC 2710, Multicast Listener Discovery (MLD) for IPv6

Q.2067
T.

RFC 2711, IPv6 Router Alert Option

Q.2067
U.

RFC 2740, OSPF for IPv6

Q.2067
V.

RFC 2893, Transition Mechanisms for IPv6 Hosts and Routers

Q.2067
W.

RFC 3484, Default Address Selection for Internet Protocol version 6 (IPv6)

Q.2067
X.

RFC 3513, Internet Protocol Version 6 (IPv6) Addressing Architecture

Q.2067
Y.

RFC 3587, IPv6 Global Unicast Address Format

Q.2067
Z.

RFC 3768, Virtual Router Redundancy Protocol (VRRP)

Q.2067
AA.

RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) for IPv6

Q.2067
BB.

RFC 4291, IP Version 6 Addressing Architecture

Q.2067
CC.

RFC 4443, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification

Q.2067
DD.

RFC 4552, Authentication/Confidentiality for OSPFv3

Q.2067
EE.

RFC 4659, BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN

Q.2067
FF.

RFC 4862, IPv6 Stateless Address Autoconfiguration

Q.2067
GG.

RFC 4884, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 Specification

Q.2067
HH.

RFC 5308, Routing IPv6 with IS-IS

Q.2068

The proposed system shall support MPLS features and compliance to the following RFC standards

Q.2068
A.

RFC 3031, Multiprotocol Label Switching Architecture

Q.2068
B.
Q.2068
C.
Q.2068
D.

RFC 3032, MPLS Label Stack Encoding

RFC 3209, RSVP-TE: Extensions to RSVP for LSP Tunnels
RFC 3212, Constraint-Based LSP Setup using LDP

Q.2068
E.
Q.2068
F.
Q.2068
G.
Q.2068
H.
Q.2068
H. (I)
Q.2068
H. (iI)
Q.2068
H. (Iii)
Q.2068
H. (Iv)
Q.2069

RFC 3478, Graceful Restart Mechanism for Label Distribution Protocol

Q.2069
A.
Q.2069
A. (i)
Q.2069
A. (ii)
Q.2069
A. (iii)
Q.2069
A. (iv)
Q.2069
A. (v)
Q.2069
B.
Q.2069
B. (i)
Q.2069
B. (ii)
Q.2069
B. (iii)
Q.2069
C.
Q.2069
D.
Q.2069
E.
Q.2070

Can recognize the following classification IP and MPLS header:

Q.2070
A.
Q.2070
B.
Q.2070
C.

IGMP v2 (RFC 2236)

Q.2070
D.

MSDP (RFC 3618)

Q.2070
E.

PIM SSM (RFC 3569)

23.2.

Core Node

Q.2071

The proposed Core Router platform must support at least 8Tbps system switching capacity.

RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels

RFC 4124, Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering
Support primary LSPs and secondary LSPs protection mechanism.
The following MPLS-VPN features shall be provided:
RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs)
RFC 4379, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
RFC 4659, BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN
The proposed system shall support QoS features

IP Precedence
DSCP
MPLS experimental bit
Source/Destination IP Address
Source/Destination TCP/UDP Port
Can remark the following IP and MPLS header:
IP Precedence
DSCP
MPLS experimental bit
Support Random Early Detection (RED) and Weighted RED congestion control mechanism.
Support queue Scheduling mechanism, one of them must to be strict priority queue.
Port-based Ingress/Egress Policing.
The proposed system shall support the following Multicast features

IGMP v3 (RFC 3376)

PIM Sparse Mode (RFC 4601)

Q.2072

The proposed Core Router platform must be with at least 3.6Bpps routing forwarding rate.

Q.2073

The proposed Core Router platform must support at least 20 slots for line cards with redundant route pro-cessor configured.

Q.2074

The proposed Core Router platform must support at least 240Gbps throughput per slot.

Q.2075

The proposed equipment shall support redundant route processors. Upon any failure of the primary route processor, it is expected that: Failover to the second
route processor shall be automatic, no manual intervention is required.

Q.2076

The proposed equipment shall have redundant switching fabric. The supplier shall indicate the number of switching fabrics adopted and working mode, either hot
standby mode or load sharing mode.

Q.2077

Upon any failure of one switching fabric, the remaining switching fabrics shall be capable of continuing the forwarding of packets to all cards at wire speed.

Q.2078

The proposed equipment shall have redundant power supply. In case of any failure of one power supply, it is expected that: The remaining power supply must be
able to supply the power requirements of a fully loaded chassis. Removal or Insertion of power supplies can be carried out without any power interruption to the
router. The supplier shall indicate the number of power suppliers and their working mode, either hot standby mode or load sharing mode.

Q.2079

The proposed equipment shall have redundant fans, and upon any failure of one fan, the remaining fans shall provide sufficient airflow to cool a fully populated
chassis.

Q.2080

The proposed system shall support a variety of optical or electrical interfaces, including 100 Gigabit Ether-net,10 Gigabit Ethernet and Gigabit Ethernet.

Q.2081

The proposed system shall support at least the following scaling figure:

Q.2081
A.
Q.2081
B.
Q.2081
C.
Q.2081
D.
Q.2081
E.
Q.2082

4Million route entries (RIB)

Q.2082
A.
Q.2082
B.
Q.2082
C.
Q.2082
D.
Q.2082
E.
Q.2082
F.
Q.2082
G.
Q.2082
H.
Q.2082
I.
Q.2083

1000 Base-T

23.3.

RAN Aggregation Node

Q.2084

The proposed RAN Aggregation Router platform must support at least 5Tbps system switching capacity.

Q.2085

The proposed RAN Aggregation Router platform must be with at least 2Bpps routing forwarding rate.

1Million forwarding entries (FIB)

250 BGP peers
250 OSPF adjacencies
250 MPLS VRFs capacity
The proposed system shall support the following GE and 10GE Interface Type

1000 Base-SX
1000 Base-LX / LH
1000 Base-EX
1000 Base-ZX
10G Base-SR
10G Base-LR
10G Base-ER
10G Base-ZR
The proposed system shall support Graceful Restart or Non-Stopping routing for IGP and BGP protocols to provide the highest level of redundancy and resiliency
to minimize network disruptions if a failure occurs.

Q.2086

The proposed RAN Aggregation Router platform must support at least 8 slots for line cards with redundant route processor configured.

Q.2087

The proposed RAN Aggregation Router platform must support at least 240Gbps throughput per slot.

Q.2088

The proposed equipment shall support redundant route processors. Upon any failure of the primary route processor, it is expected that: Failover to the second
route processor shall be automatic, no manual intervention is required.

Q.2089

The proposed equipment shall have redundant switching fabric. The supplier shall indicate the number of switching fabrics adopted and working mode, either hot
standby mode or load sharing mode.

Q.2090

Upon any failure of one switching fabric, the remaining switching fabrics shall be capable of continuing the forwarding of packets to all cards at wire speed.

Q.2091

The proposed equipment shall have redundant power supply. In case of any failure of one power supply, it is expected that: The remaining power supply must be
able to supply the power requirements of a fully loaded chassis. Removal or Insertion of power supplies can be carried out without any power interruption to the
router. The supplier shall indicate the number of power suppliers and their working mode, either hot standby mode or load sharing mode.

Q.2092

The proposed equipment shall have redundant fans, and upon any failure of one fan, the remaining fans shall provide sufficient airflow to cool a fully populated
chassis.

Q.2093

The proposed system shall support a variety of optical or electrical interfaces, including 100 Gigabit Ether-net,10 Gigabit Ethernet and Gigabit Ethernet.

Q.2094

The proposed system shall support at least the following scaling figure:

Q.2094
A.
Q.2094
B.
Q.2094
C.
Q.2094
D.
Q.2094
E.
Q.2095

4Million route entries (RIB)

Q.2095
A.
Q.2095
B.
Q.2095
C.
Q.2095
D.
Q.2095
E.
Q.2095
F.
Q.2095
G.
Q.2095
H.
Q.2095
I.
Q.2096

1000 Base-T

23.4.

SGi Border Router Node

Q.2097

The proposed Border Router platform must support at least 5Tbps system switching capacity.

Q.2098

The proposed Border Router platform must be with at least 2Bpps routing forwarding rate.

1Million forwarding entries (FIB)

250 BGP peers
250 OSPF adjacencies
1000 MPLS VRFs capacity
The proposed system shall support the following GE and 10GE Interface Type

1000 Base-SX
1000 Base-LX / LH
1000 Base-EX
1000 Base-ZX
10G Base-SR
10G Base-LR
10G Base-ER
10G Base-ZR
The proposed system shall support Graceful Restart or Non-Stopping routing for IGP and BGP protocols to provide the highest level of redundancy and resiliency
to minimize network disruptions if a failure occurs.

Q.2099 The proposed Border Router platform must support at least 8 slots for line cards with redundant route pro-cessor configured.
Q.2100 The proposed Border Router platform must support at least 240Gbps throughput per slot.
Q.2101 The proposed equipment shall support redundant route processors. Upon any failure of the primary route processor, it is expected that: Failover to
the second route processor shall be automatic, no manual intervention is required.
Q.2102 The proposed equipment shall have redundant switching fabric. The supplier shall indicate the number of switching fabrics adopted and working
mode, either hot standby mode or load sharing mode.

Q.2103 Upon any failure of one switching fabric, the remaining switching fabrics shall be capable of continuing the forwarding of packets to all cards at wire
speed.
Q.2104 The proposed equipment shall have redundant power supply. In case of any failure of one power supply, it is expected that: The remaining power
supply must be able to supply the power requirements of a fully loaded chassis. Removal or Insertion of power supplies can be carried out without
any power interruption to the router. The supplier shall indicate the number of power suppliers and their working mode, either hot standby mode or
load sharing mode.
Q.2105 The proposed equipment shall have redundant fans, and upon any failure of one fan, the remaining fans shall provide sufficient airflow to cool a fully
populated chassis.
Q.2106 The proposed system shall support a variety of optical or electrical interfaces, including 100 Gigabit Ethernet, 10 Gigabit Ethernet and Gigabit
Ethernet. Technical Specifications for Border Gateway Router
Q.2107 The proposed system shall support at least the following scaling figure:
Q.2107
A.
Q.2107
B.
Q.2107
C.
Q.2107
D.
Q.2107
E.
Q.2108

4Million route entries (RIB)

Q.2108
A.
Q.2108
B.
Q.2108
C.
Q.2108
D.
Q.2108
E.
Q.2108
F.
Q.2108
G.
Q.2108
H.
Q.2108
I.
Q.2109

1000 Base-T

23.5.

Technical Specifications for Border Gateway Router

1Million forwarding entries(FIB)

250 BGP peers
250 OSPF adjacencies
1000 MPLS VRFs capacity
The proposed system shall support the following GE and 10GE Interface Type

1000 Base-SX
1000 Base-LX / LH
1000 Base-EX
1000 Base-ZX
10G Base-SR
10G Base-LR
10G Base-ER
10G Base-ZR
The proposed system shall support Graceful Restart or Non-Stopping routing for IGP and BGP protocols to provide the highest level of redundancy
and resiliency to minimize network disruptions if a failure occurs.

Q.2110 The proposed equipment shall support redundant route processors. Upon any failure of the primary route processor, it is expected that: Failover to
the second route processor shall be automatic, no manual intervention is required.
Q.2111 The proposed equipment shall have redundant switching fabric. Upon any failure of one switching fabric, the remaining switching fabrics shall be
capable of continuing the forwarding of packets to all cards at wire speed.
Q.2112 The proposed Border Gateway platform shall have redundant power supply.
Q.2113 The proposed Border Gateway platform shall have redundant fans, and upon any failure of one fan, the remaining fans shall provide sufficient airflow
to cool a fully populated chassis.
Q.2114 The proposed Border Gateway platform shall support BGPv4, OSPF, IS-IS routing protocol and BGP 4-byte Autonomous System Numbers (ASN).
Q.2115 The proposed Border Gateway platform shall support OSPFv3 IS-IS and BGPv4 for IPv6

Q.2116 The proposed Border Gateway platform shall support GPRS Tunneling Protocol (GTP) version 0, GTP ver-sion 1 and GTP version 2.
Q.2117 The proposed Border Gateway platform shall support IPSec
Q.2118 The proposed Border Gateway platform shall support GRE Tunnel.
Q.2119 The proposed Border Gateway platform shall support logging feature.
23.6.

Operation and Maintenance (O&M)

Q.2120 The seller shall provide the OAM aggregator switch at each core site.
Q.2121 The following Management access methods must be supported:
Q.2121
A.
Q.2121
B.
Q.2121
C.
Q.2122

CLI via console

CLI via telnet and ssh.
Out-band management via Fast Ethernet interface.
The proposed system shall supports TACACS+ or Radius Authentication protocol

Q.2123 The proposed system shall support SNMP (Simple Network Management Protocol) Agent and SNMP MIB.
23.7.

Environmental Conditions and Safety Standard

Q.2124 Environmental Conditions

Q.2124
A.
Q.2124
B.
Q.2124
C.
Q.2125

Voltage :42V to 56V

24

CBC Solution

24.1.

General Requirement

Temperature: 5 ~ 40
Humidit : 20 ~ 80 %
Safety and Electronic Standard: Please describe the safety and electronic standard

Q.2126 The Bidder shall describe technical architecture for CBC.

Q.2127 CBC solution will be responsible to broadcast messages to the Buyers subscribers on 4G (LTE) networks.
Q.2128 The CBC shall be interworking with Buyers 4G (LTE) network vender.
Q.2129 Cell Broadcast messages shall be distributed to mobile phones located in a certain area, as specified by authorized person in Buyer or the regulator.
Q.2130 The smallest area to be addressed is a single radio cell.
Q.2131 The largest area to be addressed is the complete 4G (LTE) network.
Q.2132 Cell Broadcast messages shall be broadcasted up to 15 pages, each page contains 82 octets.
Q.2133 Any proposed solution shall be standards based.

24.2.

Functionality Requirements
Functionality; The CBC may be connected to several MMEs. The CBC may be connected to several CBEs. The CBC shall be responsible for the
management of CBS messages including:

Q.2134 Allocation of serial numbers;

Q.2135 Modifying or deleting CBS messages held by the MME;
Q.2136 Initiating broadcast by sending fixed length CBS messages to a MME for each language provided by the cell, and where necessary padding the
pages to a length of 82 octets (as per 3GPP TS 23.038); A. The proposed system shall support at least UCS-2 Coding.
Q.2137 Determining the set of cells to which a CBS message shall be broadcast, and indicating within the Serial Number the geographical scope of each
CBS message;
Q.2138 Determining the time at which a CBS message shall commence being broadcast;
Q.2139 Determining the time at which a CBS message shall cease being broadcast and subsequently instructing each MME to cease broadcast of the CBS
message;
Q.2140 Determining the period at which broadcast of the CBS message shall be repeated;
Q.2141 Determining the cell broadcast channel in LTE, on which the CBS message shall be broadcast.
Q.2142 For ETWS, when CBS transmits emergency messages, allocation of "emergency indication" to differentiate it from normal CBS messages, including
the "Cell ID/Service Area ID list" , "warning type", "warning message". If "warning type" is of 'test', only UEs which are specially designed for testing
purposes may display warning message.
Q.2143 The architecture of the CBC system for content submission must be completely separated from the topology of the Buyers existing network.
Q.2144 The architecture of the CBC network is described in CBC high-level architecture of the platform for CBC and its interfaces.
Q.2145 The Bidder shall inform and briefly describe all the constituent components presented in the CBC system.
Q.2146 The Bidder shall submit the list of features (features) available for any part of the CB Platform, indicating, where appropriate, the basic features,
options and those that were listed and necessary for the operation of this solution.
Q.2147 The Bidder must submit / inform CBC system for Traffic: A. The throughput license, support at least 3 mes-sages per minute, can be upgraded to 30
messages per minute without hardware expansion.
Q.2148 The proposed solution must support at least 25 MMEs in total for 4G network in Buyer simultaneously. The maximum number of cell controller shall
be expandable to 2,500 MMEs. The maximum number of radio cell shall be expandable to 500,000 cells.
Q.2149 The interfaces supported, the CBC shall support at least 1 CBE connection, can be expandable up to 1000 CBEs concurrently. The CBC shall
support HTTP/HTTPS interface protocol with the CBE connections.
Q.2150 The CBC must guarantee availability of capacity on the air-interface to the mobile device for public warning type messages.
Q.2151 The proposed solution must support 4G (LTE) connectivity according to the 3GPP TS 23.041, TS 22.268 and TS 29.168 standards
Q.2152 The proposed system shall support ETWS functionality according to 3GPP standards.
Q.2153 The CBC system shall support High Availability and Geographic Redundancy mechanism. The Bidder shall propose active/standby redundant
architecture for the CBC in this tender. The Bidder shall detail the architecture and recovery mechanisms in case of failure of server, signalling and
interface link.
Q.2154 The Bidder shall detail the architecture and mechanisms to support dual node geographic redundancy at different cities as optional.
24.3.

External Interfaces and Management

Q.2155 For LTE, SBc Application Part (SBc-AP) interface between the Mobility Management Entity (MME) and the Cell Broadcast Centre (CBC).

Q.2156 When a CB-message is stopped, the cell controller must report the number of broadcasts per radio cell in the statistics interface.
Q.2157 The following 3GPP standards must be supported: 3GPP TS 23.041, 3GPP TS 48.049, 3GPP TS 25.419, 3GPP TS 29.168.
Q.2158 The proposed system solution must support the MME interfaces of all leading network suppliers (SBc-AP).
Q.2159 The following 3GPP standards must be supported: 3GPP TS 29.168.
Q.2160 The mapping of geographical area information to cells must be a task of the CBC.
Q.2161 The CBE interface must be able to access the functions of the CBC.
Q.2162 The CBC will accept calls from CBEs and addresses cell controllers without operator intervention.
Q.2163 The CBE interface will accept requests, process them and transmit error-messages or confirmations to the CBE.
Q.2164 The CBE interface must support HTTP based protocols with security connection.
Q.2165 The proposed system must be able to report to the CBE on the success/failure of message broadcast within 3 minutes after the message was
submitted.
Q.2166 The CBE and CBC interface shall support the following functions:
Q.2166
A.
Q.2166
B.
Q.2166
C.
Q.2166
D.

CBC Login

Q.2166
E.
Q.2166
F.
Q.2166
G.
Q.2166
H.
Q.2166
H. (i)
Q.2166
H. (ii)
Q.2166
H. (iii)
Q.2166
I.
Q.2166
J.
Q.2166
K.
Q.2166
K. (i)
Q.2166
K. (ii)
Q.2166
K. (iii)
Q.2166
L.

Create Roles (that possessed a collection of Permissions)

CBC Logout
Change Password
Create Permissions (includes Area Manage/View; MME Manage/View; Manage/View CBC Message; Manage Emergency Message; Manage/View
Cells; Execute Cell Loader; Manage/View GSMGateway; View Reports & Manage/View Security Administration).

Create Users & Assign Roles that carries specific Permissions

Assigning Source IP to CBC Users for Security Validation
Create New CBC Message using Predefined Area such as
MME Lists
Cells Lists
Geographical Coordinates (latitudes/longitudes)
Update CBC Message
Kill CBC Message
Create Predefined Area by means of:
MME Lists
Cells Lists
Geographical Coordinates (latitudes/longitudes)
Delete Predefined Area

Q.2166
M.
Q.2166
N.
Q.2166
O.
Q.2166
P.
Q.2167

Get All MMEs

Get MME Gateway Status
Get Cells Counters & Status
Get BSC Vendors Information
The proposed system allows CB messages to be sent directly or to be given a specified start time.

Q.2168 Immediate Execution: The Cell Broadcast Entity (CBE) requests without a start time will be executed as soon as possible.
Q.2169 The proposed system shall support Index Messages
Q.2170 The proposed CBC system must Support for priority messages.
Q.2171 When a priority message is submitted, all non-priority messages that are currently being broadcast in the area where the warning message shall be
willmessages
be stopped
temporarily.
Q.2172 broadcasted,
After the priority
have
finished, the original commercial messages will automatically be restarted.
Q.2173 The system shall comply with the 3GPP standards as mentioned below:
Q.2173 3GPP
A.
Q.2173 3GPP TS 22 268, PWS Requirements
A. (i)
Q.2173
3GPP TS 23.038 version 9.1.1 Alphabets and language-specific information or later.
A.
(ii)
Q.2173
3GPP TS 23 041, Technical realization of Cell Broadcast Service (CBS)
A. (iii) 3GPP TS 25 419, UTRAN Iu-BC Interface: Service Area Broadcast Protocol
Q.2173
A.
(iv) 3GPP TS 29 168, Cell Broadcast Centre interfaces with Evolved Packet Core
Q.2173
A.
(v)
Q.2173
3GPP TS 48 049, Base Station Controller - Cell Broadcast Centre (BSC-CBC) interface specifi-cation
A.
(vi) The system shall comply with the CMAS standards as mentioned below:
Q.2174
Q.2174 ATIS-0700006 - CMAS via GSM-UMTS
A.
Q.2174 ATIS-0700010 - CMAS via EPC
B.
25
SMSC Solution
25.1.

Service Feature Requirement

Q.2175 The SMSC shall be able to store and forward short/long messages
Q.2176 The SMSC system shall support to store and forward long SMS which have length more than 160 characters or 140 bytes.
Q.2177 SMSC shall able to according the pre-defined calling /called numbers and Type of Number and Numbering Plan or global title to route to or modified
the Calling/Called number and Type of Number and Numbering Plan then route to dedicated SMSC or dedicated node.
Q.2178 SMSC is needed to support SMS direct delivery. Mobile-to-mobile and application-to-mobile messages will be first arrived the SMSC which try to
deliver the message directly to the destination (without performing store-and-forward function immediately). If the SMS messages could not be
delivered in the direct delivery, it shall be treated for store and forward delivery.

Q.2179 SMSC system shall support SIGTRAN (M3UA) for telecom interfaces towards traditional 2G/3G GSM Net-work
Q.2180 Being an SMSC for LTE-IMS network, the SMSC shall also support interfacing with IMS network based on 3GPP TS24.229.
Q.2181 Shall support multi-languages with standing protocol (i.e. UTF-8);
Q.2182 System shall be built in a fully high available architecture, supplier shall require to state clearly how HA works in the solution proposal.
Q.2183 Capacity Proposed SMSC shall support at least the following capacity
Q.2183 250K Subscriber
A.
Q.2183 100 Message Delivery Attempt per second
B.
Q.2183 CDR Log Storage for at least 15 days
C.

25.2.

Operation, Alarm & Monitoring

Q.2184 The platform shall provide Graphical-based centralized tools or application program interface (API) for ad-ministrative actions.
Q.2185 The platform shall have the capability to provide traffic performance data on incoming and outgoing route
Q.2186
Q.2187 The system shall have the capability to provide data on its hardware performance such as CPU, memory consumption, disk space, etc.
Q.2188 System Alarm Indications and Automatic System Recovery.Visual alarm display is required providing fault counters for the following fault situations.
Automatic recovery from the below fault situations shall be available.
Q.2188
A.
Q.2188
B.
Q.2188
C.
Q.2188
D.
Q.2188
E.
Q.2188
F.
Q.2188
G.
Q.2188
H.
Q.2188
I.

25.3.

Connection error to external network (E1, TCP/IP, etc..)

System Congestion warning
General Application Flow and error situation behavior
Hard disc usage size warning (over 80%)
Database access error
General System failure
System fault report
Application/internal modules failure
All alarms of each component shall be sent to Operators Centralized Alarm server.
There are two options for Alarm triggering:
Option 1 Alarm Log
To generate Alarm log in specific format
Option 2 - SNMP Module
It shall support SNMP and SNMP module can gather all the system or performance information for the pro-cesses and systems running on various
systems. If a registered entity in the MIB file is down, then the OAM Master raises an alarm with the define criticality for the error to the operator's
SNMP server
Reporting

Q.2189 Overall short message successful rate report (i.e. successful rate of 1st attempt, 2nd attempt, 3rd attempt and rest of attemps)
Q.2190 Hourly Short message report of mobile originating/terminating (Attempts vs Delivery vs failed vs pending)
Q.2191 Hourly Short message report of mobile originating/terminating per SMPP connection (Attempts vs Delivery vs failed vs pending)
26

Lawful Intercept Solution

Q.2192 The system must have an alarm management for operating system tasks and lawful interception tasks (for example lack of space in disk, connection
failures, etc.). The alarms must be visible in a GUI and the possibility to forward them to an external alarm management system must be possible.
Q.2193 Operating system and Lawful Interception Solution access must be authenticated separately. Describe the authentication methods available (local,
LDAP, etc).
Q.2194 The solution must support the capture and transmittal to Law Enforcement Agencies of Call Data and Call Content without the monitored individuals
being aware of it. The solution must support a secure interface for activating such monitoring requirements.
Q.2195 The solution must provide a capability to ensure that the telecommunications to and from a target service be provided to the exclusion of any
telecommunications that do not fall within the scope of the interception authorization.

Q.2196 The solution must provide a capability for Law Enforcement Agencies to obtain data in real- time. This ca-pability must ensure there is a full-time
monitoring capability for the interception of telecommunications. Call associated data shall also be provided in real-time. If call associated data
cannot be made available in real time, Law Enforcement Agencies require the data to be available as soon as possible upon call termination.
Q.2197 The solution must provide a capability to acquire data in a format for transmitting the intercepted communications to the monitoring facility in a
generally available format.
Q.2198 The solution must provide a capability to acquire data in a readable format, if the communication is encoded, compressed or encrypted, the solution
must have the capability to provide intercepted communications in the required format. This is not applicable if the intercepted communication has
encryption used that is outside of the control of the Bidder.
Q.2199 The solution must provide a capability to ensure the interception be designed and implemented to preclude unauthorized or improper use and to
safeguard the information related to the interception with the appropriate security levels and authorization levels.
Q.2200 The solution must provide a capability to ensure the interception will contain the associated data and content from the target service in a way that
allows for the accurate correlation of associated data with content.
Q.2201 The solution must provide a capability so that neither the intercepted target nor any other unauthorized person is aware of any changes made to fulfill
the interception order. The operation of the intercept on the target must appear unchanged to the interception subject so that the look and feel
remains the same prior to the interception.
Q.2202 The solution must provide a capability to ensure the user for software-based intercept implements intercep-tions as quickly as possible. The response
requirements by the TSP to the Law Enforcement Agencies are an-ticipated to be within 2 hours.
Q.2203 The solution must provide a capability to ensure the capability to support simultaneous intercepts for up to five different agencies. Multiple
interceptions may be required for a single target service to allow monitoring by more than one Law Enforcement Agency. In this case, the system
must ensure that the identity of the target is safeguarded and that each agency will not know that the other agency is monitoring that target. This is to
ensure the confidentiality of the investigations.
Q.2204 The solution must differentiate the lawful intercept tasks and access to different user roles (such as System Administrator, Users Administrator,
Target Administrator).
Q.2205 The solution must provide a capability to ensure that the user operating the system has the appropriate logs to conduct audits on the targets setup
and who has implemented each target. These logs will also provide sufficient information to allow for the monitoring and trouble shooting of the
intercepted data in the event there are issues with the interception or delivery of the interception to the appropriate law enforcement agency. The logs
must be stored in an industry standard encrypted manner and must be accessible by authorized users only.
Q.2206 The solution must provide a capability for the Owner to provide a target management system to allow for the targeting and de-targeting of intercepts
locally and remotely by designated authorized personnel. The system must also have the capability to establish targets with a pre determined time for
both the targeting and the de-targeting of the user. Bidder shall provide integration experience.

Q.2207 The solution must be in compliance with the 3GPP lawful intercept architecture standards such as TS 33.107.

Explanation

Test case ID (if

applicable)

Scoping(CT/SE/CSSS
C/GS)

Owner

SE/GS

CT

SE/GS/CSSC/CT
GS

SE/GS/CSSC/CT
SE/GS/CSSC
SE/CSSC
GS/CT

Region/R
A/EPC