Section Description Compliance In this offer Reference

1

2

3 Scope of Work

3.1.

3.1.1. TSC LTE RFP content consists:

3.1.1.A.

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.

Avaiable Date /SW Ver.

Mandatory orOptional

INTRODUCTION This document is TSC’s 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 vendor’s 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 vendor’s answers.Each vendor is requested to provide the information according to 3GPP Reference Architecture defined in Section 5 of this RFP document.

Date to ResponseProposals 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.

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.

This Main Document: contains all General RFP information and requirement such as Tender scope, schedule, and Tenderer’s Qualification & Technical specification

3.1.2.

Table 1.1 Statement Of Compliance (SoC) table example

3.1.3.

Tenderer DocumentsTenderer 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:Tenderer’s QualificationEnclosure 2:Technical Proposal for the response for Project related deliverablesStatement of Compliance (SoC): Tenderer shall provide point-to-point response andfill in compliance table for every item stated in RFP Note: All exceptions with deviations from T&C or technical requirements requested in RFP. Documents shall be noted and stated in SoW. Those who failure to do so shall be deemed as “Fully Comply” with this RFP and TSC’s terms and instructions. Statement of Work (SoW): Including all project related working items, R&R, Project Management Plan and service scope Bill of Material (BoM) Supporting Documents for all technical requirementsEnclosure 3: Price Proposal Price ScheduleTenderer 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 complianceMandatory 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 anyExplanation: statement of compliance.

Tenderer’s QualificationTenderer'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.

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 release’s courses)

3.1.4.B. Equipment Hardware and Software Documentation.

3.1.5.

3.1.6.

Price ProposalPrice 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 Buyer’s 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 Buyer’s premise or the Buyer’s 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 Buyer’s 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:

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.

Contact InformationMaterials regarding this RFP shall be delivered either personally or via registered mail to :Engineering department:Brian Tseng Mobile: 0935150872Email: brian0935150872@gmail.com

3.2.

3.2.1.

3.2.2.

3.2.3.

3.2.4.

3.2.5.

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

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.

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 Buyer’s 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• Supplier’s 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

Implementation ServicesThe 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 …) Site engineering excluding all the licenses / authorisation. Landlord contract / authorisation will be coordinated by Tender’s team Site acquisition, permits, construction works, transmission step-up are exclude in this offer and will be coordinated by Buyer’s team

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.

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

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

3.3.1.

3.3.1.1.

3.3.1.2.

3.3.1.3.

3.3.1.4.

3.3.1.5.

3.3.1.6.

3.3.1.7.

Engineering Support and ServicesThe purpose of this chapter is to specify engineer and operations support network requirement for the deploy-ment of LTE in Buyer

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:

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: New HW Equipment site integration Acceptance Integration testing Test equipment to demonstrate compliance (with Buyer) of Transmission and Synchronisation. New Software Release local Acceptance (test plant and live network) Migration Plan Acceptance, End-to-End local Acceptance

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)

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.

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.

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

Test Equipment and ToolsSupport 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

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.

3.3.1.9.

3.3.1.10.

3.3.1.11.

3.3.2. General Requirement

3.3.2.1.

3.3.2.2.

3.3.2.3.

Engineering on Site AssistanceWith 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.

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 Tenderer’s 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.

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.

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.

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.

OSS Configuration The Tenderer shall implement the parameter changes that are issued by the Buyer’s 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.

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.

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

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:

3.5.

(*) 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 SLA’s.• 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 SLA’s fro the Technical Support Service are:

The Tenderer shall clearly state if proposes different from above target SLA’s 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.

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.

3.5.2.

3.6.

3.6.1.

3.6.2.

3.6.2.1.

Installation checklist

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”

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 SLA’s.• 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”

The Target SLA’s: Lead Time for Delivery The quotation should target the Lead Time for delivery presented (days in calendar days):

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

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• AcceptanceThe zone acceptance will be the official handoff point of OAM from the Tenderer responsibility to Buyer, if all criteria for acceptance are met.

Site AcceptancePurpose: 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.

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.

Punch list will feature no blocking issues

3.6.2.2.

All sectors are checked, on air and unlocked

OMC Alarms are OK

Absence of crossed sectors

3.6.3.

3.6.3.A. Pilot Cluster accepted

3.6.3.B. Performance as per KPIs agreed

3.7.

3.6.2.1.F.

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:

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

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 acceptedB. Performance as per KPIs agreed

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.

3.7.2.

3.8.

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

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.

Auxiliary RF Equipment RequirementsIn 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.

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.

3.9. Project & Services

3.9.1.

3.9.2.

3.9.3.

3.9.4.

3.9.5.

4

4.1.

4.2. Network Cabling and Racks

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.

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)

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

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.

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.

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.

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

4.2.1.

4.2.2.

4.3.

4.4.

4.5.

4.6.

5 Time Plan

5.1.

6 Services

6.1.

7 Training, Documentation and Workshops

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

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

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

Network Dimensioning / Capacity Planning The Tenderer shall detail all dimensioning and capacity rules / assumptions.

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

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

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.

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

7.1.

7.2.

8

9 Radio Access Network (RAN) Technical Requirement

9.1.

9.2. SOLUTION ARCHITECTURE

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

Q.4

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

Q.6

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

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

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

E-UTRAN Technical RequirementThis 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.

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.

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.

Q.10

Q.11

Q.12

Q.13

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

Q.14.(A). RAN Option 1

Scenario 1: 700MHz

Scenario 2: 900MHz

Scenario 3: 1800MHz

Scenario 4: 700MHz + 1800MHz

Scenario 5: 900MHz + 1800MHz

Tenderer shall provide Multi-Standard Radio (MSR) solution within same frequency band in single radio hardware.

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

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

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.

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.

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.(A).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 platform (Single RAN) to minimize the cost/foot print/ power as possible. Remote RF Unit can be one of approaches to achieve above goals.

Q.14.(A).b.

Q.14.(A).c.

Tender with possibility of reusing / co-using existing network equipment to achieve above requirements for Single RAN, MUST identify/ remark the individual reuse / co-use items with its cost saving in Pricing Sheet To demonstrate Tenderer’s 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.

In Phase 1-3, Buyer may consider covering site construction & civil work for site readiness based on own resource & experience.

Tenderer shall subject to TSC new spectrum acquired to provide plan adjustment and BoM modification.

Tenderer shall provide future expansion / upgrade plan to LTE 4x4 MIMO and 3G downlink 84Mbps base 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 End-to-End Turn-key I&C and all professional services if proposed to Swap existing U2100 Network.

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 future expansion / upgrade plan for 3G Downlink 84Mbps based on offered single RAN /MSR base station platform

Tenderer shall provide WCDMA multi-band multi-carrier feature for 900MHz and 2100MHz

Q.14.(C). Main Software pack and optional features in every element node

Q.14.(D). Operation, Administration and Maintenance (OAM) or Element Management System (EMS)

Q.14.(E). Test UE device and planning / testing tools

Q.14.(F). IOT / MVI

LTE / UMTS Lab Setup

Q.14.(H). Warranty & Maintenance

Q.14.(I). 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

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

Q.14.(A).f.

Tenderer shall provide interworking / IOT service between offered 900MHz WCDMA network and shall provide interworking / IOT service between offered 900MHz WCDMA network and Buyer’s incumbent WCDMA system (Core and RAN if Buyer would have) and LTE system (Core and RAN) without KPI degradation.

Q.14.(A).g.

Tenderer shall fully utilize Buyer’s existing network elements in physical site to minimize the potential CapEx and provide relevant site construction work, I&C and professional services to assure end-to-end performance.

Q.14.(A).h.

Q.14.(A).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 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)

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

Tenderer shall provide interworking / IOT service between offered 2100MHz WCDMA network and Buyer’s in-cumbent WCDMA system (Core and RAN) and LTE system (Core and RAN) without KPI degradation

Q.14.(B).(f).Q.14.(B).(g).

Q.14.(G).

Tenderer shall provide without cost in Buyer’s 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.19 Tenderer shall describe all distributed eNodeB types

Q.20

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

Q.28

Q.29

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

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.

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.

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.

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

Q.69.A. Dedicated mode.

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

Q.70

Q.71

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

Q.75

Q.76

9.5.7. Mobility & Handover

Q.77

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 be able to support Multi-technology operation of 3G and LTE simultaneously in the different configurations, fully configurable by the Operator through software.

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

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.

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”

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”

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”

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.

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

Q.82

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

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:

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

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

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

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 RAT’s

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

9.5.9. Capacity and Performance

Q.108

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

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

Q.113

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

Q.113.B. Is it possible to share Power Supply components?

Q.113.C. Is it possible to share RF feeders and Antenna?

Q.113.D. Is it possible to share physical transport interfaces?

Q.113.E. Is it possible to share any other items?

Q.114

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.

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.

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.

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

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

Q.115.B. Width

Q.115.C. Depth

Q.115.D. Free access space required for different cabinet scenarios

Q.115.E. 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

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

Q.123 Tenderer shall detail how your E-UTRAN support IPv6 on IP (X2, S1) interface in which Software Release?

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 .

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

Q.137

Q.138 If your eNodeB’s 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

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

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

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.

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?

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?

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)

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.

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

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.154 Product Buyer the Compliance of Standard:

Q.154.A. EU Directives: 73/23/EEC Low Voltage Directive

Q.154.B. Code of Federal Regulation 21 CFR 1040.10 and 1040.11

Q.154.C. EN 60 950-1/EC 60.950-1:2001 and IEC 60 950:1999

Q.154.D. EN 60 215/IEC 60 215:1987

Q.154.E. ANSI/UL 60 950-1/CSA C22.2 No. 60 950-1-03

Q.154.F. IEC 60 825-1/EN 60 825-1

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. Normal operation: Max. 0.02 m2/s3

Q.156.B. Exceptional operation Max. 0.08 m2/s3

Q.156.C. Non-destructive Max. 0.15 m2/s3

Q.156.D. Shock Max. 30 m/s2

Q.157 Ingress Protection Rating, IP55 requirements according to the standard IEC/EN 60 529

Q.158

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

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. Connectivity interface requirement (such as: LTE-Uu, S1-MME, S11, S6a, C1 and so on)

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.

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

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 25ºC SHALL NOT exceeed 54dB.

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.164.B. Mobility management (TAI assignment, connected mode, Idle mode and so on)

Q.164.C. Service and emergency service

Q.164.D. SON / SCN requirement

Q.164.E. 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 vendor’s HeNB, or SmallCell Gateway) in live network

Q.168 Tenderer’s 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

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

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.

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

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

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

Q.179

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

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

Q.188

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

9.6. E-UTRAN / UTRAN Features

Q.190

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

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. HSDPA+ DC

Q.193.B. MIMO 84M

Q.193.C. Provide Maximus Channel element (more than 1500 channel element per node B)

Q.193.D. 3 separate scheduler(Each separated package schedule for each sector, without reduce the HSDPA+ coding channel elements)

Q.193.E. HSDPA: 21M x 3 sectors (2 carriers) & 72 users

Q.193.F. HSUPA: 5.8Mbps x 3 sectors (2 carriers) & 72 users

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.

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)

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.

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.

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.

Tenderer shall comply with the features defined in 3GPP R10 (Backward compatible to R9, R8 and UMTS) and Buyer’s 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 corre-sponding table.

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.

Q.193.G. R99: 30 user per BTS

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

Q.195

Q.196

Q.197

Q.198

Q.199

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

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 Buyer’s 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 Buyer’s WCDMA / LTE system.

Q.208

Q.209

Q.210 Tenderer offered SON solutions shall be aligned / upgraded with future SW version of all buyer’s 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.

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 Buyer’s potential would have WCDMA Core Network.

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.

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)

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.

Tenderer if awarded Buyer’s 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.

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)

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

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.216 Tenderer shall detail how your SON algorithms workable for the following key maintenance mechanisms:

Q.216.A. Self software upgrade

Q.216.B. Service verification after upgrade

Q.216.C. Customized upgrade policy, ex: for use MML (Man-Machine Language) commands or GUI and so on.

Q.216.D. 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

9.9.3. Self-Optimization (MLB / MRO / CCO)

Q.218 Tenderer shall comply 3GPP TS32.521 Self-Optimization

Q.219

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

9.10.2. Network Scope

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.

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

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)

Q.235 Here the “Network” means Buyer’s new LTE network and existing 3G migration Network (also including IRAT, HetNet and WiFi)

Q.236 Tenderer shall plan and optimize Buyer’s network to achieve the KPI’s requested by Buyer

Q.237

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

9.10.3. Network Coverage & Capacity Dimensioning

9.10.3.1. Coverage Dimensioning

Area & Population Coverage Target

Q.239 Tenderer shall provide recommended “Area & Population Coverage Percentage Target” based on global reference

Q.240

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

Link Budget

Q.244 Tenderer shall provide the link budget tool to buyer

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.

Tenderer shall base on Buyer’s 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.1.1.

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

9.10.3.1.2.

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.

Cell Radius

Q.249 Tenderer shall provide the calculation of cell radius based on buyer requirement (such as different band, different channel bandwidth)

Simulation Result (for whole Taiwan)

Q.250

Q.251 Tenderer shall provide the simulation print-out plots based on buyer requirement 9.10.3.2. Capacity Dimensioning

Traffic & Subscriber Demand

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.

Cell Capacity

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

Spectrum Efficiency

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

Q.260 Tenderer shall fill in the average spectrum efficiency

Required Capacity Sites

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

9.10.3.1.3.

9.10.3.1.4.

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

9.10.3.2.1.

9.10.3.2.2.

9.10.3.2.3.

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.

9.10.3.2.4.

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

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

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

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 buyer’s 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 buyer’s requirement

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

9.10.10. Initial Tuning & Optimization

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.

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.

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.

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

Q.303

Q.304

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

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 Tenderer’s initial tuning analysis engineer and planning engineer must at least have 3 year experience in UMTS & HSPA network RF planning and optimization.

Q.309

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

Q.313 Tenderer shall provide the LTE coverage benchmark drive test per quarterly in Tenderer’s 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.

Q.314.C. General signaling (control) channel performance

Q.314.D. Handover performance

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

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

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.

Tenderer’s 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.

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.

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.

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.E. Traffic utilization

Q.314.F. Random access signaling

9.10.11. Network Performance Monitoring & KPI Commitment

Q.315

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

Q.317

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

Q.320

Q.321

9.11. Network Evolution & Migration

9.11.1. Network and Technology Evolution

Q.322

Q.323

9.11.2. Spectrum Migration Strategy with different RAT

Q.324

Q.325

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.

Traffic Offloading Architecture & Flow (HS 2.0)

Q.331 Tenderer shall detail the traffic offloading architecture and ANQP message flow then comply with WiFi Alliance HotSpot / HotSpot 2.0 requirement.

Traffic Offloading Architecture & Flow (3GPP – ANDSF)

Q.332 Tenderer shall detail the latest complete 3GPP approach for controlling offloading between 3GPP and non-3GPP access networks (such as WiFi)

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.

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.

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

Tenderer if awarded both Buyer’s 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.

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.

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

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.

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.

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

9.11.3.1.1.

9.11.3.1.2.

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

User Authentication

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.

Network Selection & Connection Management

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

Traffic Offloading Performance Evaluation

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

SamallCell Architecture & Flow

Q.340 Tenderer shall detail smallcell architecture and node function

SmallCell Integration

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)

Traffic Offloading Performance Evaluation

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

Other Offloading Approach

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

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

9.11.3.1.3.

9.11.3.1.4.

9.11.3.1.5.

9.11.3.2.1.

9.11.3.2.2.

9.11.3.2.3.

9.11.3.2.4.

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

Q.358

Q.359

Q.360

Q.361

Q.362

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

Q.371

Q.372

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

9.13.1. General Requirement

Q.375

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.

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

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.

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.

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.

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.

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

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.

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

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.

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 Buyer’s existing network system.

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.379 Tenderer shall provide hardware server include rack installation for operation post process and the server specification shall be confirmed by Buyer.

Q.380

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

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

9.13.2. E-UTRAN Element Management System (EMS)

Q.385 The system shall provide 24 hours uninterrupted service.

Q.386

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. Support Hot-plugged HD

Q.393.B. Support Hot-plugged power supply

Q.393.C. Normal total Disk usage can not over 50%

Q.393.D. Normal total CPU usage can not over 60%

Q.393.E. Normal total Memory usage can not over 70%

Q.394 Tenderer shall provide facility requirement include power and cabling for NMS / EMS installation.

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. Standard Unix / Linux Hardware (HP, Oracle-SUN)

Q.396.B. Standard OS (Linux, HP Unix, Solaris, AIX)

Q.396.C. Standard disc portioning (Raid 10)

Q.396.D. Full configuration from central server without local site configuration needs

Q.396.E. No hidden license cost and 3rd part integrated software cost.

9.13.3. Alarm Management

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.

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.

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 Buyer’s operation and maintenance, also in Software / Hardware upgrade period.

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

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

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

Q.402.A.

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

Q.404

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.

Q.407.B. Tenderer need provide the system and NE health check function for hardware, application program and service status.

Q.407.C. Network Management Tools requirements

Q.407.D. Tenderer need provide network management tools in which can execute mass parameters change, add, delete and move cell at same profile.

Q.407.E.

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. Managed Object Type

Q.410.B. Managed Object Name

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.

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.

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.

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.

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.

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)

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.410 C. Alarm Description

Q.410 D. Probable Cause

Q.410 E. Specific Problem

Q.410 F. Perceived Severity

Q.410 G. Additional Text

Q.410 H. Additional Information

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

Q.411 B. Authentication Failure

Q.411 C. Call Setup Failure

Q.411 D. Protocol Error

Q.411 E. Link Failure

Q.411 F. Network Element Data Corruption Error

Q.411 G. Mass Call, Overload and Congestion

Q.411 H. Network Element Failure

Q.411 I. Facility Failure

Q.411 J. Trunk Failure

Q.411 K. Hardware / Software Failure.

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

Q.413

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

Q.418

Q.419

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

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.

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.

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)

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.

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.

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

Q.426

Q.427

Q.428

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.

Q.435

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

9.13.4.1. Alarm Analysis and Alarm Correlation

Q.438

Q.439

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

Q.444

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.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, don’t 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. Customer: Registered Customer, Attached Customer.

Q.459 B. Available: Network element available

Q.459 C. Accessibility: RRC connection success rate, S1 connection setup success rate, E-RAB setup success rate, attach success rate, service request success rate

Q.459 D. Retainability: drop cell rate, handover success rate

Q.459 E. Throughput: user throughput, network element throughout

Q.459 F. Quality: Latency, Jitter, Packet Loss.

Q.459 G. Traffic: Traffic loading, Transmit bandwidth

Q.460 Weekly measurement data availability must be over 99%

Q.461

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

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

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.

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

Q.477 B. Performance event

Q.477 C. Event statistics

Q.477 D. Counters

Q.477 E. Performance thresholds

Q.477 F. Measurements

Q.477 G. Measurement interval

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

Q.478 A. Graphical Report

Q.478 B. Table Report

Q.478 C. Raw data display

Q.478 D. Counters display

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

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

9.13.5.7. Performance Monitoring

Q.481

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 buyer’s 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 buyer’s integrated performance system in 5 minutes

Q.485 PM data is real-time transferred to the buyer’s 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.

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.

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. Identification / Authentication

Q.491 B. Access Control

Q.491 C. Command Log

Q.491 D. Confidentiality

Q.491 E. Integrity

Q.491 F. Audit Mechanism

Q.491 G. Audit Mechanisms Anti-virus solution.

Q.491 H. Once any system is based on Microsoft Windows operation system, Tenderer shall provide automatic patch update, software management solution.

Q.492

Q.493

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

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.

Q.495 B.

Q.496

Q.497

Q.498 Tenderer shall provide the consultancy in between NMS / EMS and the Buyer’s system following factory standard

Q.499

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

Q.501 All the alarm data’s schema & MIB shall be provided for alarm integrated.

Q.502 All of the Configuration data’s schema & MIB shall be provided for Buyer operation DB integrated

Q.503

Q.504

9.13.9. Self Organizing Network (SON) integration

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.

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.

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 buyer’s evaluation.

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.

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

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.

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

All of the provision data’s 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.

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.

Q.505

Q.506

Q.507

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

Q.509

Q.510 The SON system shall provide the function (include the GUI and Command Line Interface) for users to change O&M user’s 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

Q.517

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. Protection against permanent data loss.

Q.521 B. Backup policy definition (DB: online full backup, AP & OS: Incremental).

Q.521 C. Backup schedule (Daily)

Q.521 D. Detailed backup procedures.

Q.521 E. Detailed recovery procedures

Q.521 F. Backup and recovery test plan.

Q.521 G. Maintenance of backup hardware.

Q.521 H. Plan for minimizing Directory downtime in the event of a disaster

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

Account management of SON server shall be well integrated into Buyer’s 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

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 user’s password.

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), time-stamp.

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.

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.522 Tenderer shall provide the health check procedure, let buyer to perform regular healthy check.

Q.522 A. Daily check procedure

Q.522 B. Weekly check procedure

Q.522 C. Monthly check procedure

Q.522 D. Quarterly Check procedure

Q.523

Q.523 A. Use of reliable components.

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

Q.523 C. Parallel architecture for scalability and failover.

Q.523 D. Automated load balancing and error handling for redundant components.

Q.524 The SON system must have redundancy architecture. Tenderer shall state the offered solution whether 2N or N+1 or HA redundancy architecture.

Q.525

Q.526 The SON system shall provide 24 hours uninterrupted service.

Q.527

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

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

Q.530

Q.531

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. Description of Operations and Maintenance practices.

Q.533 B. Man-machine commands and functional descriptions.

Q.533 C. Alarm printout manuals, including indications of alarm classes and recommended problem solving pro-cedures.

Q.533 D. Fault diagnosis manuals.

Q.533 E.

Q.533 F. Descriptions of procedures for changing exchange data and cell parameters

Q.533 G. Description of all network supervision functions

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:

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.

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)

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.

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.

Routing including: • Operation routines • Emergency routines (specified in detail)

Q.533 H. Description of database schema

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 K. Tables for routing, billing and signaling shall be clearly set out and arranged in a way that makes them easy to use or change.

9.13.10. Software and Patch Upgrade or Maintenance

General Requirement

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 Buyer’s 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

Q.539

Q.540

Completeness of Software Upgrade Procedure

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

Q.541 A. Preparing Phase

Q.541 B. Lab Trial Phase

Q.541 C. Live Field Trial Phase

Q.541 D. Rollout Phase

Q.542

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

Q.546

Q.547

Documentation

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.

9.13.10.1.

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

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 Buyer’s RAN

Tenderer must send notice mail and message to buyer’s online account if any problem and technical note update related to Buyer’s current and future RAN software version.

9.13.10.2.

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.

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.

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.

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

9.13.10.3.

Q.550

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

Q.552

System Outage & Failure caused by Software and Patch Upgrade

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

Q.555

Q.556

Q.557

Service Downtime during Software and Patch Upgrade

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

Q.559

Q.560

Q.561

Q.562

9.14. User Authentication

Q.563 Based on offered solution and device, Tenderer shall provide:

Q.563 A. End to end User Authentication / Registration procedure and message flow

Q.563 B. User Authentication approach, mechanism and involved Standard

Q.563 C. User Encryption mechanism

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

Q.565

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

Q.569 Tenderer shall detail how to ensure the service in:

Q.569 A. E-UTRAN QoS

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

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

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.

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 Buyer’s War Room before system outage be resolved.

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.

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

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.

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.

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.

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.

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.

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 B. Transport QoS

Q.569 C. Core Network QoS

Q.569 D. Application / service QoS

Q.570 Tenderer shall provide the mapping table for

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

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

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

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

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. Protect 1. eNodeB: Theft, remove or loss of information and/or other resources: theft of eNodeB hard-ware

Q.572 B. Protect 1. eNodeB: Disclosure of information: unauthorized access to important information such as the keys, software, and configuration file of the eNodeB

Q.572 C. Protect 1. eNodeB: Corruption of information: loading invalid software or illegally controlling the eNodeB through the local commissioning Ethernet port

Q.572 D. 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 E. Protect 2. Uu interface: Disclosure of information: unauthorized access to important user information by interception of signals on the Uu interface.

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. Protect 3. S1 interface: Disclosure of information: unauthorized access to important user information by interception of data from the transport network

Q.572 H.

Q.572 I.

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 K. Protect 5. OM interface: Disclosure of information: interception of the important eNodeB information that is transmitted over the OM interface

Q.572 L.

Q.572 M.

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

Q.573 Tenderer shall comply with below 3GPP security related standards.

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

Protect 4. X2 interface: Disclosure of information: unauthorized access to important user information by interception of handover-related data from the transport network

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.

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

Q.573 B.

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

Q.573 D. 3GPP TS21.103: “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Integration Guidelines”.

Q.573 E.

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.

Q.573 H.

Q.573 I.

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 Tenderer’s 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

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

Q.580

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. CSFB, SRVCC and VoLTE

Q.581 B. Short Message Service (SMS)

Q.581 C. Multimedia Messaging Service (MMS)

Q.581 D. Ring Back Tone (RBT)

Q.581 E. Voice Mail Service (VMS) / Missed Call Alert (MCA)

Q.581 F. Mobile Position Services (MPS) / Location Service (LCS)

Q.581 G. Rich Communication Service (RCS)

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

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

3GPP TS33.120: “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security Principles and Objectives”.

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

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

3GPP TS33.310: “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Network Domain Security (NDS); Authentication Framework (AF)”.

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 buyer’s cus-tomers.

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 Buyer’s network and business requirement.

Q.581 H. Evolved Multimedia Broadcast / Multicast Service (eMBMS)

Q.581 I. Cell Broadcast Service (CBS): including Public Warning Service (PWS)

Q.582

Q.583

Q.584

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

Q.589

Q.590

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 NCC’s coverage & population require-ment.

Q.594

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 NCC’s to fulfill regulatory requirement

Q.597 Tenderer shall support Buyer’s to pass CIB and NCC inspection.

Q.598 Tenderer shall support Buyer’s 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.

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 (ITU-R M.2134) and 3GPP

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

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.

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

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

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.

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

9.18.5. Lawful Interception

Q.602

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

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

Q.613 Tenderer shall support to provide the test plan and document for NCC’s 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 NCC’s 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 Regulator’s 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

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.

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.

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

This chapter stipulates the requirement of future E-UTRAN / UTRAN to integrate with Buyer’s existing 3G network. As buyer’s 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 Buyer’s existing EPC supplier. (e.g. consultant, protocol analyze, tools…)

Q.626

9.19.2. Interoperability Test (IOT)

Q.627

Q.627 A. MME contains different eNodeB (S1-MME)

Q.627 B. eNodeB integrates to other MME (S1-MME)

Q.627 C. S-GW contains different eNodeB (S1-U)

Q.627 D. eNodeB integrate to other S-GW (S1-U)

Q.627 E. Inter-Vendor intra-LTE Mobility Tests over X2

Q.627 F. Inter-Vendor IRAT Mobility Tests between LTE and UMTS

Q.627 G. Self-Organizing Network (SON)

Q.628

Q.628 A. RNC contains different NodeB (lub)

Q.628 B. NodeBs integrates to other RNC (lub)

Q.628 C. SGSN contains different RNC (lu-PS)

Q.628 D. RNCs integrate to other SGSN (lu-PS)

Q.628 E. RNC connect to other RNC (lu-r)

Q.628 F. RNC connect to other LTE S-GW (S12)

Q.628 G. RNC connect to other MSC (lu-CS)

Q.628 H. 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

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

Q.633 Tenderer shall support to integrate with Buyer’s Public Warning System.

Q.634 Tender shall support to integrate with Buyer’s LCS system, Buyer’s SMS system.

Q.635 The offered E-UTRAN solution shall provide S1-MME interface to/and integrate with Buyer’s 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.

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 Buyer’s 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 turn-key solution offered without an y additional charge to the Buyer.

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.

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.

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

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

Q.638

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 Buyer’s EPC for optimize the CSFB

9.19.3. Multi Vendor Integration (MVI)

Q.644

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 Buyer’s MVI activity in Buyer’s LAB for the Buyer’s assigned EPC vendors.

Q.648 Tenderer shall provide the list and test detail of successful Network IOT with Tenderer’s E-UTRAN / UTRAN equipment

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

9.19.4. Inter-Radio Access Technology (IRAT)

Q.650

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. IRAT E-UTRAN to UTRAN (LTE > UMTS)

Q.651 B. IRAT UTRAN to E-UTRAN (UMTS > LTE)

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

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.

9.20. Acceptance Test Plan (ATP)

Q.655

Q.655 A. Node Acceptance Test (NAT)

Q.655 B. System Acceptance Test (SAT)

Q.655 C. User Acceptance Test (UAT, only in live network)

Q.656

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

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

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.

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.

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

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.

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

Q.660

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

Q.662

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

9.20.2. SAT

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

Q.666

Q.667

9.20.2.1. Functionality Test

Q.668

Q.669

Q.670

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

Q.673

Q.674

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. 3G and 4G Radio Network planning tool.

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

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.

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.

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.

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 Contractor’s 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.

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.

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.

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.

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.

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

If major faults such as inter-working problems between the offered LTE E-UTRAN (or UMTS UTRAN) and the Buyer’s existing systems, other operator’s 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.

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.

Q.675 B. Field Measurement / Drive-Test Tool

Q.675 C. Miscellaneous Tool Requirement

Q.676

Q.676 A. LTE FDD measurement

Q.676 B. 3G (3.5G) measurement

Q.676 C. Wi-Fi measurement

Q.676 D. Others

Q.677 The RAN tool shall measures service quality directly from different types of devices and provide number of tools (include Buyer’s Lab needs) as below:

Q.677 A.

Q.677 B. Outdoor Drive Test Tool with LTE Data card & LTE Phone

Q.677 C. Modulized Outdoor Drive Test Tool with LTE Data card & LTE Phone

Q.677 D. Scanning receiver

Q.677 E. External GPS

Q.677 F. Other (i.e. accessory)

Q.678 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. Supports Evolved UTRA (3GPP Release 10 LTE Advance) Networks

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

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

All tools shall support LTE Downlink at least 100Mpbs, Uplink at least 50Mbps.

Q.684 B. Various frequency bands

Q.684 C. Scalable channel bandwidths

Q.684 D. Resource blocks per channel and sampling frequencies

Q.684 E. FDD and TDD frame structures

Q.684 F. Half-frame / Full-frame switching point periodicities for TDD

Q.684 G. Normal and extended cyclic prefixes

Q.684 H. Downlink and uplink control channels and overheads (Downlink and uplink reference signals, P-SCH, S-SCH, PBCH, PDCCH, PUCCH, etc…)

Q.684 I. Physical cell IDs

Q.684 J. Signal level based coverage planning

Q.684 K. CINR based coverage planning

Q.684 L. Network capacity analysis using Monte Carlo simulations

Q.684 M. Scheduling and resource allocation in two-dimensional frames

Q.684 N. Multiple Input Multiple Output (MIMO) systems

Q.684 O. Transmit and Receive Diversity

Q.684 P. Single-User MIMO (Spatial Multiplexing)

Q.684 Q. Adaptive MIMO Switch (AMS)

Q.684 R. Multi-User MIMO (Collaborative MIMO) in uplink

Q.684 S. Automatic allocation of neighbors, physical cell IDs, and frequencies (AFP) (optional)

Q.684 T. Network verification possible using test mobile data

Q.684 U. Tenderer shall help buyer to run the simulation based on the NCC requirement

Q.685 The radio planning tool shall be able to input buyer existing drive tool and output the result based on buyer 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. Database with site and antenna sharing.

Q.686 B. Multi-service traffic model

Q.686 C. Monte-Carlo simulator

Q.686 D. Display UMTS and LTE networks simultaneously

Q.686 E. Automatically allocate neighbors between UMTS and LTE network

Q.686 F. Support inter-technology interference analysis

9.21.5. Field Measurement Tool

Q.687 Tenderer RAN tool shall measures service quality directly from different type of devices as below but not limited:

Q.687 A. Smartphones (Android & iOS)

Q.687 B. Tablet (Android & iOS)

Q.687 C. Modulized Outdoor Drive-test Tool

Q.687 D. Non-Modulized Outdoor Drive-Test Tool (Mobile / Dongle direct connected)

Q.688 The RAN tool shall instantly delivery LTE and 3G QoE insight to tablet or laptop – in real-time.

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. LTE FDD / TDD measurement

Q.692 The RAN tools shall Support test UEs

Q.692 A. Mobile Phone

Q.692 B. Data Card

Q.692 C. Scanning Receiver

Q.692 D. External GPS

Q.693 The RAN tool shall Support to edit script and repeat the following test items:

Q.693 A. FTP DL / UL

Q.693 B. HTTP DL / UL for data transfer.

Q.693 C. ICMP Ping

Q.693 D. Web browsing

Q.693 E. Video Streaming (RTSP)

Q.693 F. Youtube streaming (HTTP)

Q.693 G. VoIP call (Voice Quality)

Q.693 H. IP capture

Q.694 The RAN tool shall Support benchmarking test.

Q.694 A. Support at least 4 operators’ networks benchmarking and measure 4 operators’ network KPI at same time.

Q.694 B.

Q.694 C. Support scanning receiver test

Q.695 The RAN tool shall support forcing features.

Q.695 A. System lock (lock to LTE FDD / TDD)

Q.695 B. Band lock (Lock to LTE FDD / TDD specific band such as 700, 900, 1800, 2100, 2600 MHz)

Q.696 The RAN tool shall support outdoor (Mobility) / indoor (Stationary) measurement.

Support MapInfo for outdoor map.

Q.696 B. Support BTS file into show on map.

Q.697 The RAN tool shall support CSFB and VoLTE test (Voice Quality)

Q.698 The RAN tool shall support KPIs measurement.

Q.698 A. Cell Measurement (for each cell): • Band • Chanel number (EARFCN) • Physical cell identity • RSSI • RSRP • RSRQ

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.

Q.696 A.

Q.698 B.

Q.698 C.

Q.698 D.

Q.698 E.

Q.698 F.

Q.698 G.

Q.698 H.

Q.698 I.

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

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

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

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

LTE measurement event • Event A1 ~ A5 • Event B1, B2

Q.698 J.

9.21.6. 4G Lab Requirement

Q.699

Q.699 A.

Q.699 B. NTP with GPS

Q.699 C. OSS

Q.699 D. SON

Q.699 E. Antenna & Accessory (attenuator, splitter …)

Q.699 F. MSR

Q.699 G. IRAT / CSFB

Q.700

Q.701

Q.701 A. RNC

Q.701 B. Node B (at least 2 sets for different type including Macro, Remote and SmallCell with 3 sectors).

Q.701 C. EMS or OSS

Q.701 D. Antenna & Accessory (attenuator, splitter …)

Q.701 E. MSR

Q.702 Tenderer shall list the required Hardware, Software and Service item in the BOM for buyer’s approval.

Q.703

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 eNodeB’s frequency and bandwidth shall be the same with live system and list as following

Q.706 A. Band 3 (1800 MHz FDD mode) for UMTS / LTE

Q.706 B. Band 8 (900 MHz FDD mode) for UMTS / LTE

Scanning receiver parameters • RSRP • RSRQ • CINR • Antenna port • Ch / PCI • Decode BCCH info (SIBs – Cell id…)

Tenderer shall provide one LTE RAN system including OAM and SON feature for Buyer’s Lab. LTE RAN Network shall include but not limited to the following elements and functions as the same with Live system:

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)

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

Tenderer shall provide one 3G RAN system including OAM for Buyer’s Lab. LTE RAN Network shall include but not limited to the following elements and functions as the same with Live system:

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.706 C. Band 28 (APT700 FDD mode) for LTE

Q.706 D.

Q.707 The NodeB’s frequency and configuration shall be the same with live system and list as following

Q.707 A. 900MHz (Band 8) for 2 + 2 + 2 configuration

Q.707 B. 2100MHz for 3 + 3 + 3 configuration

Q.708 Tenderer shall provide 2x2 MIMO equipment for above LTE & 3G RAN system and they are for future 4x4 reuse and expandable.

Q.709 Tenderer shall provide complete SON function with OSS system which is the same with live system

Q.710

Q.711

Q.712 Tenderer shall successfully integrate the LTE-RAN with Buyer’s existing lab 3rd party LTE EPC system.

Q.713 Tenderer shall successfully integrate the 3G RAN system with Buyer’s existing Lab LTE EPC system for i-RAT / CSFB capability.

Q.714

Q.715 Tenderer shall successfully integrate the 3G RAN system with Buyer’s existing lab 3G network and Wi-Fi system for traffic offload availability

Q.716 Tenderer shall include Lab’s 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 Buyer’s approval.

Q.718

Q.719 Tenderer shall provide the Lab acceptance test plan including but not limited to NAT, SAT for buyer’s ap-proval.

Q.720

Q.721

9.22. Technical Documentation

9.22.1. General Requirements

Q.722

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

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

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.

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.

Tenderer shall successfully integrate the LTE RAN system with Buyer’s existing 3G network for i-RAT / CSFB capability and Wi-Fi system for traffic offload available. (Optional)

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 Buyer’s approval

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.

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.

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 Buyer’s personnel to operate and maintain the system in an efficient and correct manner.

9.22.2. Documentation Language

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

9.22.3.2. Installation Documentation

Q.732

Q.732 A.

Q.732 B.

Q.732 C. Power supply diagram

Q.732 D.

9.22.3.3. Hardware Documentation

Q.733

Q.734 The following shall be included in the documentation:

Q.734 A. Survey schematics and module descriptions

Q.734 B.

Q.734 C.

Q.734 D. Floor layout plan

Q.734 E. Layout plan showing the position of the units within the racks

9.22.3.4. Software Documentation

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.

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.

Installation Drawings • Floor plans • Assembly drawings

Cabling plans / wiring drawings • Cable route lists • Cable connection schematics • Bay connection diagram • Rack connection diagram

Test instructions / procedures • Test points with indication of normal values • Recommended measuring equipment • Measuring procedures

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.

Functional diagrams • Block diagrams • Logic diagrams

Top-level diagram • System diagram • Other top-level diagrams

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.

Q.735 B. Provide feature description (word format) of every software feature whichever is purchased / not-purchased, enable / not-enabled, or basic / optional

Q.735 C. Provide total basic and optional list (excel format) for recommended SW version and future version of feature / roadmap with two years.

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

Q.738

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. Paper and electrical manual with on-line help instructions

Q.740 B. Trouble shooting manual, standard process and necessary tools

Q.740 C. User’s manual for each type of equipment monitored by the OMC or NMC

Q.740 D. Man-machine commands and functional descriptions of these

Q.740 E. Alarm printout manuals, including indications of alarm classes

Q.740 F. Fault diagnosis manuals

Q.740 G.

Q.740 H. Descriptions of procedures foe changing system configuration data

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

9.22.3.7. Training Documentation

Q.746

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

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.

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.

Routines including: • Operation routines • Emergency routines (specified in detail)

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.

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

9.22.3.9. Requirements for Updating Documentation

Q.748

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

10.4. MME Functional Requirement

Q.756

Q.757 Hardware and Software Requirements

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:

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.

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.

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

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

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

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.

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.

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

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

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.

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

Q.828

Q.829

Q.830

Q.831 The proposed MME shall support simultaneous multiple PDN connectivity to one or multiple PDNs. The maximum value shall be configurable.

Q.832

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

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 it’s 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.

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.

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.

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.

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.

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

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

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

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.

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.

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.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. VLR failure procedure

Q.886 B. MME failure procedure

Q.886 C. HSS failure procedure

Q.886 D. MM information procedure

Q.886 E. NAS messages tunneling procedure

Q.886 F. Service request procedure

Q.887

Q.888

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

Q.892 The Tenderer shall provide a description of the hardware platform used to implement its S/P-GW functionality.

Q.893

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

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.

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.

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.

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.

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.

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.903 The Tenderer will indicate the number of boards dedicated to the administrative tasks of the node.

Q.904

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.

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

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

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

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.

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.

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

Q.950

Q.951

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.

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.

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.

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

Q.989 Please provide the list of protocols and applications which can be detected using DPI.

Q.990

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.

The P-GW (PCEF) shall provide appropriate configuration framework which allows administrator to specify customized DPI rules based on following criteria: Layer-4 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.

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

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

Q.1020

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.

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.

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-Rule-Definition requested by the PCRF.

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

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

Q.1047

Q.1048

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?

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.

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?

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.

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

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

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

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.

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

Q.1099

Q.1100

Q.1101 The PCRF MUST be capable of handling quota usage based on

Volume

Time

Volume and Time

Location based (Cell_id based)

Q.1102 How are the PCC rules provisioned on the PCRF? Please explain both for pre-defined as well as dynamic PCC rules.

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

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.

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.

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 re-directed 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 A.

Q.1101 B.

Q.1101 C.

Q.1101 D.

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

Q.1108

Q.1109

Q.1110

Q.1111

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

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

Q.1117

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:

Add Policy Rules

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

Q.1120 Policy server shall have both GUI and CLI administrative console.

Q.1121 The proposed solution shall support of geographical redundancy and load sharing.

Q.1122 Can the PCRF support interfacing to several Subscriber Database (Spr’s) for rules evaluation of one sub-scriber.

Q.1123

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

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.

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.

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.

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.

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.

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

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.1119 A.Q.1119 B.Q.1119 C.Q.1119 D.Q.1119 E.Q.1119 F.Q.1119 G.

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.

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

Q.1127

Q.1128

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:

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.

Happy Hour concept where all subscribers get improved bandwidth at a certain time (e.g. global triggers)

Q.1133 The PCRF shall support Account Controls such as:

Corporate Account Control - Allow business customers to control voice, data and web usage for em-ployees, during and out of business hours

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

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

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

Q.1145 Bidders must describe how the proposed system is scalable.

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.

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.

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

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

Q.1133 B.

Q.1133 C.

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

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.

The Proponent’s 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.

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

Q.1149

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 –

Converged voice, data and video services

Real time conversational services

Streaming and content based services

Messaging

Web based services and

Other multimedia, combinational and converged Services.

Q.1154 The proposed system must satisfy the following specifications.

3GPP IMS Release 9/10

IETF RFC

GSMA VoLTE

ETSI TISPAN

Q.1155

UTRAN (UMTS)

GSM

WLAN

DSL

LTE

Q.1156 The proposed system must provide all VoLTE supplementary services of GSMA.

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

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

Q.1153 B.

Q.1153 C.

Q.1153 D.

Q.1153 E.

Q.1153 F.

Q.1154 A.

Q.1154 B.

Q.1154 C.

Q.1154 D.

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

Q.1155 B.

Q.1155 C.

Q.1155 D.

Q.1155 E.

Q.1157 The following basic IMS Services are to be supported.

Media Connection Service during call

Presence based Services

Location Information connection services

Support of conferencing and announcement services

RCS connection service

Web Interworking Service

Roaming Service

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 IOT’s 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

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

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

Standard SIP headers and message body

Non-standard SIP message and body types

shall be supported in an IMS scenario

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

Q.1157 A.

Q.1157 B.

Q.1157 C.

Q.1157 D.

Q.1157 E.

Q.1157 F.

Q.1157 G.

Q.1157 H.

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

Q.1168 B.

Q.1168 C.

Q.1170

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

Q.1175

Q.1176

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:

Cx interface and associated functional behavior as described in 3GPP TS 29.228 and 3GPP TS 29.229 to the HSS.

Mw interface to the P-CSCF and S-CSCF and associated functional behavior as described in 3GPP TS 24.229

Q.1181 The vendor shall provide detail of the following particular aspects of the I-CSCF behavior:

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.

Forwarding of SIP messages appropriately according to SIP method, registration status of the relevant subscriber, and appropriate routing mechanism.

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

Q.1183

Q.1184 The IMS core must support the following RFC’s.

IETF RFC 2327; SDP Session Description Protocol.

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.

Q.1184 I. 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.

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.

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.

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?

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

Q.1180 B.

Q.1181 A.

Q.1181 B.

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 A.Q.1184 B.Q.1184 C.Q.1184 D.Q.1184 E.Q.1184 F.Q.1184 G.Q.1184 H.

Q.1184 J.Q.1184 K.Q.1184 L.Q.1184 M.

Q.1185 SIP call processing must provide both domain-based routing and prefix based routing.

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

Q.1191

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

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.

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

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.

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.

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.

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.

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

Q.1221

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:

Party registers successfully in SIP Control Domain (AKA Digest)

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)

Q.1227

Q.1228

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:

IMS solution shall support Fixed access

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

11.4. Network element features

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.

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.

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.1226 A.Q.1226 B.Q.1226 C.Q.1226 D. Q.1226 E.Q.1226 F.Q.1226 G.

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.

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.

Q.1230 A.

Q.1230 B.

Q.1230 C.

Q.1230 D.

Q.1230 E.

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

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

Q.1248 The Diameter Agent shall support following three roaming configuration:

Direct tunneling of Diameter Client and Server of Nat Cos without own DEA. (see also Multi Tenancy).

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.

Q.1249

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

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

Q.1255

Q.1256 The vendor is invited to state the compliance of DRA /DSC with 3GPP standards for applicable diameter interfaces:

Gx, Gxx and Sd as defined in TS 29.212 & 23.203

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

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.

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 A.Q.1248 B.Q.1248 C.

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.

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.

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.

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 A.Q.1256 B.Q.1256 C.Q.1256 D.

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

Q.1256 I. 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

11.6. Subscriber Authentication

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

11.9. Security

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.

Q.1256 E.Q.1256 F.Q.1256 G.Q.1256 H.

Q.1256 J.Q.1256 K.Q.1256 L.

The solution shall support the Bootstrapping Architecture to establish a security association between an end-user device and the Bootstrapping Server Function (BSF).

11.12. Charging

Q.1279

Q.1280

Q.1281 CDR shall be generated for unsuccessful call

Q.1282 The vendor shall provide detailed description of content included in the CDR’s.

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

Q.1289

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 product’s 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:

location of the alarm

time the alarm occurred

perceived severity of the alarm

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.

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.

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.

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.

Q.1300 A.Q.1300 B.Q.1300 C.

alarm description

alarm category

alarm type

the NE and any subordinate resource (if applicable)

previous state

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

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

Q.1306 The solution must support full and incremental updates.

Q.1307

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 RFC’s

RFC 3953 ENUM Registration for Presence Services

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

RFC 5067 Infrastructure ENUM Requirements

Q.1309 I. 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

Q.1300 D.Q.1300 E.Q.1300 F.Q.1300 G.Q.1300 H.

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.

Please give a description of your company’s view on ENUM and its role in number porting for this moment and your vision on ENUM developments for the coming years.

Q.1309 A.Q.1309 B.Q.1309 C.Q.1309 D.Q.1309 E.Q.1309 F.Q.1309 G.Q.1309 H.

Q.1309 J.Q.1309 K.Q.1309 L.Q.1309 M.Q.1309 N.Q.1309 O.Q.1309 P.Q.1309 Q.

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

AA. RFC 3966 The tel URI for Telephone Numbers

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

This solution shall be undetectable by the LI target.

This solution shall be undetectable by the operator’s 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.

Q.1314

This solution shall be undetectable by the LI target.

This solution shall be undetectable by the operator’s staff (staff not involved in LI provisioning).

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.

Q.1315

This solution shall be undetectable by the LI target.

This solution shall be undetectable by the operator’s staff (staff not involved in LI provisioning).

The supplier shall describe the LI solution in Roaming-Out use case (Home Routed).

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.

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.

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 A.Q.1314 B.Q.1314 C.Q.1314 D.

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:

Q.1315 A.Q.1315 B.Q.1315 C.

The supplier shall detail the role of each component involved in the LI solution.

Q.1316 If the supplier proposes its own Mediation Function platform, LI database shall be encrypted.

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:

How many AS are invoked (PSI or iFC) by the S-CSCF

How many HLR or HSS interactions (which operations do you use) considering that the SCC, MMTEL and IM-SSF are used.

Q.1321

IETF RFC 3261

3GPP TS 23.218

3GPP TS 24.229

Q.1322 The AS (MMTEL AS and IM-SSF) shall support SIP header transparency. The AS (MMTEL AS and IM-SSF) shall support SDP transparency.

Q.1323

Q.1324 The vendor shall describe any proprietary mechanisms (protocol extensions, SIP headers…).

Q.1325

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.

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:

Communication Forwarding Unconditional

Communication Forwarding on Busy

Communication Forwarding on not Reachable

Communication Forwarding on No Reply

Q.1315 D.

Q.1320 A.Q.1320 B.

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

Q.1321 A.Q.1321 B.Q.1321 C.

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

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.1332 A. Q.1332 B. Q.1332 C. Q.1332 D.

Communication deflection

Q.1333

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

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

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.

The following types of call barring shall be supported:

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

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

Q.1344 The offered MMTel function shall be compliant with 3GPP TS 24.623, Release 10.

Q.1332 E.

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

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 A. Q.1339 B. Q.1339 C. Q.1339 D. Q.1339 E.

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.

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

Q.1346

Q.1347 The vendor shall state whether it’s 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

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

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

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

Q.1362

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:

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

Q.1365

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

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.

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.

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.

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.

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

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.

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 A. Q.1363 B. Q.1363 C. Q.1363 D.

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.

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

MMTEL AS – MRF

IM-SSF – MRF

Q.1368 The proposed MRF function shall support 3GPP TS 23.218 and 3GPP TS 24.229 requirements:

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

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:

For audio announcements

For audio recordings (if supported)

For audio/video announcements

For audio/video recordings (if supported)

Q.1374

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.

Announcements / tones (during the communication or early-media).

Conference (CONF service)

Other (DTMF collection, recording, ...)

The vendor shall describe how MMTel AS use MRF audio functionalities.

Q.1376 The offered MRF solution shall support audio conferencing. Please describe the audio conferencing capa-bilities of the offered MRF solution.

Q.1377

ApplyCharging with PlayTone (in ReleaseIfDurationExceeded)

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.

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

TS 23.218:o §8 Functional requirements of the MRFC

Q.1368 A.

TS 24.219:o Application usage of SIP §5.8: Procedures at the MRFC (AS)o Media Control §10.2: Procedures at the AS §10.3: Procedures at the MRFC

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.1373 A. Q.1373 B. Q.1373 C. Q.1373 D.

The offered MRF solution shall support the playback of audio announcements. The vendor shall list all supported audio codecs available for announcement playback

Q.1375 A. Q.1375 B. Q.1375 C.

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.

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

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

Q.1400 The proposed IM-MGW shall support in-band transport of DTMF tones and information between the PSTN and the IMS.

In case of BICC is used on the CS side

In case of ISUP is used on the CS side

Q.1401 The proposed IM-MGW shall support T.38 FAX over IP and FAX interworking with the PSTN.

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

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

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

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 A. Q.1400 B.

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

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

Q.1422

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

Q.1428 The monitoring tool shall be able to produce the following reports:

Successful and erroneous attaches and detaches, as well as routing area updates. Events are reported immediately as they appear.

Successful and erroneous PDP context activations, deactivations, and modifications. Events are reported immediately as they appear.

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.

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.

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.

The solution shall be able to produce trend statistics and calculate KPI’s 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 (1)Q.1428 (2)Q.1428 (3)

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

Information on users attached through the Gb and Iu interfaces, open PDP contexts per priority class, and several properties of open PDP contexts.

Information on open CDRs for each CDR type.

Information on RA-level pagings over the Iu and Gb interfaces.

Information on SGSN-level pagings over the Iu and Gb interfaces.

Q.1429 Please list any other additional reports that are available through real-time monitoring tool and not listed above.

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

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

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)

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

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)

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)

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.

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.

16 Number Portability System

Q.1452

Q.1453 The vendor should provide the detail call scenario/flow for TSC non-NP subscriber, NP-out users and NP-in TSC’s subscriber

Q.1454 The provide NP system should be able to support more than 50M number data without performance degrade.

Q.1455

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

3GPP standards

TM Forum MTNM

OSS/J

Other

Q.1458

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

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

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 machine’s local/remote (console, EMS, NMS) management method and its maximum connection figure.

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 Taiwan’s Number Portability Administration Center (NPAC) with require OSS integration effort

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

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.

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.

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.

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

Q.1477 Please suggest additional software and hardware solution needed for manage, maintain, optimized various system.

Q.1478

17.2. Fault Management

Q.1479

Q.1480

Q.1481 The NMS shall be possible to define alarms based on statistics.

Q.1482

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

Q.1489

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 tool’s detail description.

17.3. Performance Management

Q.1494

Q.1495

Q.1496

Q.1497 The NMS shall provide statistics on events in all NEs and on the related interfaces.

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

Please provide network elements, EMS, NMS full on line backup and restore (including OS & Application & data), where this operation won’t impact to user service, detail execution plan.

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

The fault monitoring solution shall provide open interfaces to allow integration to companies 'umbrella' monitoring system. The vendor shall describe the available interfaces.

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 user-level. Descriptions of available alarm filtering shall be provided.

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

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.

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.

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.

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

Performance data

Performance event

Event statistics

Counters

Performance thresholds

Measurements

Measurement interval

Load on NEs, number of service executions

Network Performance Key Performance Indicator (KPI)

Q.1500 The NMS shall be possible to activate and deactivate counters, to choose different measuring intervals and to automatically produce statistical reports.

Q.1501 Automatic data deletion shall be possible.

Q.1502 Describe the retention period for storing performance measurement data.

Q.1503

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

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.1499 A. Q.1499 B. Q.1499 C. Q.1499 D. Q.1499 E. Q.1499 F. Q.1499 G. Q.1499 H. Q.1499 I.

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.

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

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

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:

By NE name, including the use of wild cards

Operator_id, including the use of wild cards

By NE, shelf, board type

By SW version

Q.1532 Please advice how to confirm immediate execution or batch execution result is correct and complete.

17.5. Security Management

Q.1533

Q.1534 Provide network elements security access control mechanism.

Q.1535

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

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

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.

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.1531 A. Q.1531 B. Q.1531 C. Q.1531 D.

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.

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.

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.

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

17.7. Logging

Q.1552 All NEs shall have local logging of relevant events and operations. The following types of logs shall be im-plemented as minimum;

Command log

Alarm and event log

Performance log (CPU and memory availability per processor)

Logs showing abnormal interaction with other systems

Q.1553 Local logging of relevant events and operations shall be written to a non-volatile storage.

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

Q.1561

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

17.9. Self Organizing Networks (SON)

Q.1565 Please provide LTE SON and network element’s architecture and standard followed.

Q.1566

Q.1567 The offered ANR function shall support to implement SON - Automatic Neighbor Relation for LTE.

Q.1568

Q.1569

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.

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.

Q.1552 A. Q.1552 B. Q.1552 C. Q.1552 D.

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

Provide a solution able to support multiple operating personnel query different MSISDN and network ele-ments call tracing and debugging without inference each other.

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.

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.

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.

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.1572 Please provide DCN bandwidth requirement for collecting SON related data.

Q.1573 Please provide eNodeB and EPC’s Self-Configuration, self-optimization, self-healing’s 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

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:

High Availability, Reliability, and Resilience

High Scalability and Extensibility

Flexibility

Fast Processing

Q.1578 The supplier shall state the kind of database standard chosen for subscriber database.

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

Q.1586

Q.1587 The database shall have the following features:

Direct Interface in order to perform queries in the data by operator without Supplier intervention.

Allow queries in a text based.

Q.1588

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

Q.1593

Q.1594 The supplier must provide all hardware specifications of database solution. The supplier shall describe the hardware platform used for the Database Layer.

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.1577 A. Q.1577 B. Q.1577 C. Q.1577 D.

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.

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 A. Q.1587 B.

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.

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.

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

18.2. Technical Requirements

Q.1596 The supplier shall explain the architecture of the provisioning system.

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

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 Supplier’s 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 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.

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.

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 in-memory data base to disk as a one-to-one replica).

Q.1624

Q.1625

Q.1626 Data (subscriber) model shall be extendable in order to be used by other applications.

Q.1627

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

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

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)

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

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.

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

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

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

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

18.10. Network Interfaces and Protocols

Q.1671

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.

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.

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"

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.

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

Q.1683 The supplier must provide the details about how the synchronization and data integrity is retained amongst the proposed servers.

Q.1684

Q.1685 The supplier shall support secure communications protocols for all Network Element Access.

Q.1686

18.11. Roadmap Requirements

Q.1687 Please specify a roadmap of subscriber database management standard basic and optional features and their timelines.

Q.1688

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

Q.1704 Ability to support TCP/IP interface.

Q.1705 Ability to support HTTP interface.

The system must support dynamic transactions (read only, write only, mixed operations, etc.) from the Ap-plications/Clients and meet the traffic volume expectation.

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.

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.

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.

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

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

Q.1730

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

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.

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.

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.1734 The ability to be configured to allow different collection plans for different days of the week and different times of day.

Q.1735

Q.1736

Q.1737

Q.1738 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).

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

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.

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.

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

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

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

Q.1765

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

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.

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.

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.

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

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

Q.1799

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

Q.1806

Q.1807

Q.1808

Q.1809

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

Q.1812 The ability of the device to process zero length files.

Q.1813

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.

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

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

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.

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.

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

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.

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

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.

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.

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

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

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

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

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

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

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

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.

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.

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.

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.

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.

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.

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

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

Q.1888

Q.1889

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

Q.1894

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

Q.1898

Q.1899 Provision for resubmitted events to be processed in the same way as original events.

Q.1900

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.

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

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.

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

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.

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.

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.

The ability to define known error repair rules to automatically detect and correct known error patterns and to automatically resubmit those records for re-processing.

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.

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

Q.1929

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.

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

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

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

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

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

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

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

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.

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

The ability to provide data for creating user definable dashboards containing statistics tables, graphs, queue information and other available statistical or monitoring information

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

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

Q.1960

Q.1961

Q.1962

Q.1963

Q.1964

Q.1965

Q.1966

Q.1967

Q.1968

19.13. Security & Compliance

Q.1969

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Q.1982

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

Q.1985

Q.1986

Q.1987

19.15. Availability

Q.1988 The entire system shall remain operational during normal backups.

Q.1989

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 Buyer’s 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

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.

3GPP TS23.003

3GPP TS29.303

IETF RFC 1035

IETF RFC 2181

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.

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.

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

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

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

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

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.

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.2002 A. Q.2002 B. Q.2002 C. Q.2002 D.

IETF RFC 2606

20.2. Functional Requirements

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

Q.2009

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.

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

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.

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

21.2. Platform Functions

Q.2036 For NAPT capacity and requirement expansion, the system shall support module expansion in single chassis.

Q.2037

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

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

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

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

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.

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.

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

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.

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

Q.2059

Q.2060

Q.2061

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

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)

RFC 5305, IS-IS Extensions for Traffic Engineering

RFC 1058, Routing Information Protocol

RFC 2082, RIP-2 MD-5 Authentication

RFC 2453 RIPv2

Q.2066 The proposed system shall support BGP routing protocol and compliance to the following RFC standards

RFC 1772, Application of the Border Gateway Protocol in the Internet

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

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.

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.

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.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. Q.2065 O. Q.2065 P. Q.2065 Q. Q.2065 R.

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

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

Q.2067 The proposed system shall support IPv6 routing protocol and compliance to the following RFC standards

RFC 1981, Path MTU Discovery for IP version 6

RFC 2080, RIPng for IPv6

RFC 2081, RIPng Protocol Applicability Statement

RFC 2283, Multiprotocol Extensions for BGP-4

RFC 2373, IP Version 6 Addressing Architecture

RFC 2460, Internet Protocol, Version 6 (IPv6) Specification

RFC 2461 or RFC 4861 Neighbor Discovery for IP Version 6 (IPv6)

RFC 2462, IPv6 Stateless Address Auto configuration

RFC 2463, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification

RFC 2464, Transmission of IPv6 Packets over Ethernet Networks

RFC 2465, Management Information Base for IP Version 6: Textual Conventions and General Group

RFC 2472, IP Version 6 over PPP

RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

RFC 2491, IPv6 Over Non-Broadcast Multiple Access (NBMA) networks

RFC 2526, Reserved IPv6 Subnet Anycast Addresses

RFC 2545, Use of BGP-4 Multi-Protocol Extensions for IPv6 Inter-Domain Routing

RFC 2578, Structure of Management Information Version 2 (SMIv2)

RFC 2675, IPv6 Jumbograms

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 A. Q.2067 B. Q.2067 C. Q.2067 D.

Q.2067 E.

Q.2067 F.

Q.2067 G.

Q.2067 H.

Q.2067 I.

Q.2067 J.

Q.2067 K.

Q.2067 L.

Q.2067 M.

Q.2067 N.

Q.2067 O.

Q.2067 P.

Q.2067 Q.

Q.2067 R.

RFC 2710, Multicast Listener Discovery (MLD) for IPv6

RFC 2711, IPv6 Router Alert Option

RFC 2740, OSPF for IPv6

RFC 2893, Transition Mechanisms for IPv6 Hosts and Routers

RFC 3484, Default Address Selection for Internet Protocol version 6 (IPv6)

RFC 3513, Internet Protocol Version 6 (IPv6) Addressing Architecture

RFC 3587, IPv6 Global Unicast Address Format

RFC 3768, Virtual Router Redundancy Protocol (VRRP)

RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) for IPv6

RFC 4291, IP Version 6 Addressing Architecture

RFC 4443, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification

RFC 4552, Authentication/Confidentiality for OSPFv3

RFC 4659, BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN

RFC 4862, IPv6 Stateless Address Autoconfiguration

RFC 4884, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 Specification

RFC 5308, Routing IPv6 with IS-IS

Q.2068 The proposed system shall support MPLS features and compliance to the following RFC standards

RFC 3031, Multiprotocol Label Switching Architecture

RFC 3032, MPLS Label Stack Encoding

RFC 3209, RSVP-TE: Extensions to RSVP for LSP Tunnels

RFC 3212, Constraint-Based LSP Setup using LDP

RFC 3478, Graceful Restart Mechanism for Label Distribution Protocol

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

Q.2069 The proposed system shall support QoS features

Q.2067 S.

Q.2067 T.

Q.2067 U.

Q.2067 V.

Q.2067 W.

Q.2067 X.

Q.2067 Y.

Q.2067 Z.

Q.2067 AA.

Q.2067 BB.

Q.2067 CC.

Q.2067 DD.

Q.2067 EE.

Q.2067 FF.

Q.2067 GG.

Q.2067 HH.

Q.2068 A.

Q.2068 B. Q.2068 C. Q.2068 D. 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)

Can recognize the following classification IP and MPLS header:

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.

Q.2070 The proposed system shall support the following Multicast features

IGMP v2 (RFC 2236)

IGMP v3 (RFC 3376)

PIM Sparse Mode (RFC 4601)

MSDP (RFC 3618)

PIM SSM (RFC 3569)

23.2. Core Node

Q.2071 The proposed Core Router platform must support at least 8Tbps system switching capacity.

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

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 A. Q.2070 B. Q.2070 C.

Q.2070 D.

Q.2070 E.

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

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

Q.2079

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:

4Million route entries (RIB)

1Million forwarding entries (FIB)

250 BGP peers

250 OSPF adjacencies

250 MPLS VRFs capacity

Q.2082 The proposed system shall support the following GE and 10GE Interface Type

1000 Base-T

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

Q.2083

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.

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

Q.2089

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.

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.

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.

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.2081 A. Q.2081 B. Q.2081 C. Q.2081 D. Q.2081 E.

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.

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.

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.

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

Q.2092

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:

4Million route entries (RIB)

1Million forwarding entries (FIB)

250 BGP peers

250 OSPF adjacencies

1000 MPLS VRFs capacity

Q.2095 The proposed system shall support the following GE and 10GE Interface Type

1000 Base-T

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

Q.2096

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.

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

Q.2102

Q.2103

Q.2104

Q.2105

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.

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.2094 A. Q.2094 B. Q.2094 C. Q.2094 D. Q.2094 E.

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.

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.

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.

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.

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.

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.

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

Q.2107 The proposed system shall support at least the following scaling figure:

4Million route entries (RIB)

1Million forwarding entries(FIB)

250 BGP peers

250 OSPF adjacencies

1000 MPLS VRFs capacity

Q.2108 The proposed system shall support the following GE and 10GE Interface Type

1000 Base-T

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

Q.2109

23.5. Technical Specifications for Border Gateway Router

Q.2110

Q.2111

Q.2112 The proposed Border Gateway platform shall have redundant power supply.

Q.2113

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

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.

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 A. Q.2107 B. Q.2107 C. Q.2107 D. Q.2107 E.

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.

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.

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.

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.

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.

The proposed Border Gateway platform shall support OSPFv3 、IS-IS and BGPv4 for IPv6

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:

CLI via console

CLI via telnet and ssh.

Out-band management via Fast Ethernet interface.

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

Voltage :–42V to –56V

Temperature: 5 ~ 40 ℃

Humidit : 20 ~ 80 %

Q.2125 Safety and Electronic Standard: Please describe the safety and electronic standard

24 CBC Solution

24.1. General Requirement

Q.2126 The Bidder shall describe technical architecture for CBC.

Q.2127 CBC solution will be responsible to broadcast messages to the Buyer’s subscribers on 4G (LTE) networks.

Q.2128 The CBC shall be interworking with Buyer’s 4G (LTE) network vender.

Q.2129

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

Q.2134 Allocation of serial numbers;

Q.2121 A. Q.2121 B. Q.2121 C.

Q.2124 A. Q.2124 B. Q.2124 C.

Cell Broadcast messages shall be distributed to mobile phones located in a certain area, as specified by authorized person in Buyer or the regulator.

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.2135 Modifying or deleting CBS messages held by the MME;

Q.2136

Q.2137

Q.2138 Determining the time at which a CBS message shall commence being broadcast;

Q.2139

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

Q.2143 The architecture of the CBC system for content submission must be completely separated from the topology of the Buyer’s 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

Q.2147

Q.2148

Q.2149

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

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.

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.

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;

Determining the time at which a CBS message shall cease being broadcast and subsequently instructing each MME to cease broadcast of the CBS message;

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.

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.

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.

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.

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.

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

Q.2166 The CBE and CBC interface shall support the following functions:

CBC Login

CBC Logout

Change Password

Create Roles (that possessed a collection of Permissions)

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

Get All MMEs

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

Q.2166 B.

Q.2166 C.

Q.2166 D.

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

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.

Q.2166 M.

Get MME Gateway Status

Get Cells Counters & Status

Get BSC Vendors Information

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

Q.2172 After the priority messages have finished, the original commercial messages will automatically be restarted.

Q.2173 The system shall comply with the 3GPP standards as mentioned below:

3GPP

3GPP TS 22 268, PWS Requirements

3GPP TS 23.038 version 9.1.1 Alphabets and language-specific information or later.

3GPP TS 23 041, Technical realization of Cell Broadcast Service (CBS)

3GPP TS 25 419, UTRAN Iu-BC Interface: Service Area Broadcast Protocol

3GPP TS 29 168, Cell Broadcast Centre interfaces with Evolved Packet Core

3GPP TS 48 049, Base Station Controller - Cell Broadcast Centre (BSC-CBC) interface specifi-cation

Q.2174 The system shall comply with the CMAS standards as mentioned below:

ATIS-0700006 - CMAS via GSM-UMTS

ATIS-0700010 - CMAS via EPC

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

Q.2178

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

250K Subscriber

100 Message Delivery Attempt per second

CDR Log Storage for at least 15 days

25.2. Operation, Alarm & Monitoring

Q.2166 N.

Q.2166 O.

Q.2166 P.

When a priority message is submitted, all non-priority messages that are currently being broadcast in the area where the warning message shall be broadcasted, will be stopped temporarily.

Q.2173 A. Q.2173 A. (i) Q.2173 A. (ii) Q.2173 A. (iii) Q.2173 A. (iv) Q.2173 A. (v) Q.2173 A. (vi)

Q.2174 A. Q.2174 B.

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.

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.2183 A. Q.2183 B. Q.2183 C.

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

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 Operator’s Centralized Alarm server.

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

Q.2193

Q.2194

Q.2195

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.

There are two options for Alarm triggering:Option 1 – Alarm LogTo generate Alarm log in specific formatOption 2 - SNMP ModuleIt 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

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.

Operating system and Lawful Interception Solution access must be authenticated separately. Describe the authentication methods available (local, LDAP, etc).

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.

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

Q.2197

Q.2198

Q.2199

Q.2200

Q.2201

Q.2202

Q.2203

Q.2204

Q.2205

Q.2206

Q.2207 The solution must be in compliance with the 3GPP lawful intercept architecture standards such as TS 33.107.

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.

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.

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.

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.

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.

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.

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.

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.

The solution must differentiate the lawful intercept tasks and access to different user roles (such as System Administrator, Users Administrator, Target Administrator).

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.

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.

Explanation Owner

SE/GS

CT

GS

SE/CSSC

Test case ID (if applicable)

Scoping(CT/SE/CSSSC/GS)

SE/GS/CSSC/CT

SE/GS/CSSC/CT

SE/GS/CSSC

Region/RA/EPC

GS/CT

CT

CT/GS/SE/CSSC

CT/GS/SE/CSSC

CT/GS/SE/CSSC

CT

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

CT

CT

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

SE/GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

SE/CSSC

GS

Region/all BL

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS

GS/BM

CT

CSSC RA

CSSC/GS

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

RA/Service

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

SE/CSSC

CSSC RA

CSSC RA

Region/RA

CSSC/GS

GS Service

GS Service

CSSC/GS

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC/GS

CSSC RA

CSSC RA

CSSC RA

CSSC OSS

GS Service

GS Service

GS Service

GS Service

GS Service

CSSC/GS

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

RA/Service

RA/Service

RA/Service

RA/Service

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

SE Region

SE Region

CSSC RA

CSSC RA

SE Region

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

GS Service

GS Service

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

GS Service

GS Service

GS Service

GS Service

GS Service

GS/CSSC

GS Service

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

Service/RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

SE/GS

GS Service

Region/Service

GS Service

GS Service

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE/GS

SE/GS

Region/Service

Region/Service

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GSSE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

SE/GS

GS Service

GS Service

Region/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/Service

Region/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/Service

Region/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/ServiceRegion/Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

CSSC RA

CSSC RA

CSSC RA

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

CSSC/GS

SE/CSSC

SE/CSSC

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

RA/Service

Region/RA

Region/RA

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS/RA

CSSC OSS/RA

CSSC OSS/RA

CSSC OSS/RA

CSSC OSS/RA

CSSC OSS/RA

CSSC OSS/RA

CSSC OSS/RA

CSSC OSS/RA

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

CSSC RA/OSS

CSSC RA/OSS

CSSC RA/OSS

CSSC RA/OSS

CSSC RA/EPC

CSSC RA/EPC

CSSC RA/EPC

CSSC RA/EPC

CSSC RA/EPC

CSSC RA/EPC

CSSC RA/IMS

CSSC RA/EPC

CSSC RA/EPC

CSSC RA

CSSC RA

CSSC

CSSC RA

SE/CSSC

CSSC

CSSC RA

SE/CSSC

CSSC RA

SE/CSSC

SE/CSSC

CSSC RA

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

Region/IP(Neha Aneja)EPC/R4/IMS

RA/EPC/R4/IMS/IP(Neha Aneja)

Region/RA

Region/Abhishek Pandy (Sahil Bharara)

Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil

Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Region/Abhishek Pandy (Sahil Bharara)

CSSC RA

CSSC RA

CSSC RA

CSSC RA

CSSC RA

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

Region/RA

Region/RA

Region/RA

Region/RA

Region/RA

Region/RA

Region/RA

Region/RA

Region/RA

Region/RARegion/RA

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE Region

SE Region

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE Region

SE Region

GS Service

GS Service

GS Service

SE/CT/GS

SE/CT/GS

SE Region

Region/RA

Region/RA

Region/EPC/R4/IMSRegion/RA

Region/RA

Region/RA

Region/RA

Region/EPC

Region/RA

Region/RA

CT

SE Region

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

GS Service

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

CSSC EPC

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC HSS/HLR

CSSC HSS/HLR

CSSC HSS/HLR

CSSC HSS/HLR

CSSC HSS/HLR

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC IMS/CG

CSSC IMS/CG

CSSC IMS/CG

CSSC IMS/CG

CSSC IMS/CG

CSSC IMS/CG

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC HSS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC HSS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

LIMS/CSSC R4/IMS

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

R4/HSS/HLR

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC

CSSC R4

CSSC R4

CSSC

CSSC

CSSC R4

CSSC R4

CSSC R4

R4/HSS/HLR

R4/HSS/HLRR4/HSS/HLR

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)

Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)

SE/CSSC

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

Region/IP(Neha Aneja)

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC R4

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC EPC

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC IMS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC OSS

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC SDM

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

CSSC CG

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE/CSSC

SE/CSSC

SE/CSSC

Region/IP(Neha Aneja)

Region/IP(Neha Aneja)Region/IP(Neha Aneja)

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

Region/IP(Neha Aneja)

Region/IP(Neha Aneja)

Region/IP(Neha Aneja)

Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)

Region/IP(Neha Aneja)

Region/IP(Neha Aneja)

Region/IP(Neha Aneja)

Region/IP(Neha Aneja)

Region/IP(Neha Aneja)

Region/IP(Neha Aneja)

Region/IP(Neha Aneja)

Region/IP(Neha Aneja)

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

Region/IP(Neha Aneja)

Region/IP(Neha Aneja)Region/IP(Neha Aneja)

Region/IP(Neha Aneja)

Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

Region/IP(Neha Aneja)

Region/IP(Neha Aneja)

Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)

Region/IP(Neha Aneja)

Region/IP(Neha Aneja)Region/IP(Neha Aneja)

Region/IP(Neha Aneja)

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

Region/IP(Neha Aneja)

Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)

Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)Region/IP(Neha Aneja)

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

SE Region

LIMS/CSSC

LIMS/CSSC

LIMS/CSSC

LIMS/CSSC

LIMS/CSSC

R4/EPC/IMSR4/EPC/IMS

R4/EPC/IMS

R4/EPC/IMS

R4/EPC/IMS

LIMS/CSSC

LIMS/CSSC

LIMS/CSSC

LIMS/CSSC

LIMS/CSSC

LIMS/CSSC

LIMS/CSSC

LIMS/CSSC

LIMS/CSSC

LIMS/CSSC

LIMS/CSSC

LIMS/CSSC

R4/EPC/IMS

R4/EPC/IMS

R4/EPC/IMS

R4/EPC/IMS

R4/EPC/IMS

R4/EPC/IMS

R4/EPC/IMS

R4/EPC/IMS

R4/EPC/IMS

R4/EPC/IMS

R4/EPC/IMS

R4/EPC/IMS