Section

Description
INTRODUCTION This document is TSCs Request For Proposal (RFP) on LTE Mobile Broadband Network based on the 3GPP standards. The primary goal of this RFP is for each Vendor to describe the complete offered solution, including features and functions, key advantages, anticipated enhancements of their LTE solution. A vendors response to the requirements of this RFP will allow Taiwan Star Cellular Corporation to understand: What products and services are proposed, Availability, technical maturity, timing, and pricing of the proposed products. The document only contains a list of requirements on the functionalities mainly requested for a 3GPP LTE network. For each requirement, exact conditions, characteristics, roadmap and limitations must be reported in the vendors answers. Each vendor is requested to provide the information according to 3GPP Reference Architecture defined in Section 5 of this RFP document. Date to Response Proposals must be received in Taipei, Taiwan prior to 14:00 Oct 7, 2013. Late submission and incomplete of the proposal may be considered invalid. Responses arriving before this date could expedite evaluations. All documents shall be sealed, marked with Sellers name, address, and con-tact point.Proposals shall be sent by verifiable means. No responsibility or allowance for delay will be made for any documents by mail. Scope of Work 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. TSC LTE RFP content consists:

Compliance

Avaiable Date / SW Ver.

Mandatory or Optional

In this offer

Reference

3 3.1.

3.1.1.

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

3.1.2.

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

Enclosure 3:

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

3.1.3.

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

3.1.4.

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

3.1.4.A. Installation and Commissioning (including cranes) 3.1.4.B. Network Migration Services and related Documentation 3.1.4.C. Test plant Installation and Commissioning The Tenderer shall quote technical support service as below, but not limited to: 3.1.4.A. Technical Support 3.1.4.B. Spares Parts Management Service 3.1.4.C. Operation & Maintenance Support Services The Tenderer shall quote a proposal for Workshop, Training, and Hardware / Software Documentation: 3.1.4.A. Training and Course Materials (Including delta releases courses) 3.1.4.B. Equipment Hardware and Software Documentation. 3.1.5. No Compensation Tenderer shall bear all costs, expendes and risks for prepration and submisssion of Tenderer. Tenderer is not entitled to any claim or compensation against the Buyer in relation to prepration or submission of Tenderer. Tenderer's non-compliance with the RFP may be a cause of the Buyer's rejection or disqualification of the Tender. Furthermore, the Buyer may deem any or all Tenders disqualified on any grounds without giving any reason. Tenderer shall be not object to and is not entitled to any claim or compensation against the Buyer for such determination during the process of evaluation of Tenderers, award of the Contract or performance of the Contract. Contact Information Materials regarding this RFP shall be delivered either personally or via registered mail to : Engineering department: Brian Tseng Mobile: 0935150872 Email: brian0935150872@gmail.com

3.1.6.

3.2.

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

3.2.1.

3.2.2.

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

3.2.3.

Tools The Tenderer is responsible to provide all necessary tools required to perform his job autonomously. These tools should comply with Buyer reporting and interworking requirements. 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.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 3.2.6.E. Counter dictionary with counter description

3.2.6.F. Signalling flow chart should show the involved LTE procedures, and precisely which message triggers the counter increment 3.2.6.G. KPI mapping and monitoring 3.3. Engineering Support and Services The purpose of this chapter is to specify engineer and operations support network requirement for the deploy-ment of LTE in Buyer 3.3.1. Engineering Support The objective of this support is to guarantee the objective of improving the network performance. The Engi-neering and Planning Support services that are detailed in the following sub-sections shall be included in the scope of the RFP answer. Engineering and Planning Support shall be required for, but shall not be limited to, the following activities: Acceptance and Demonstration The Tenderer shall provide appropriately skilled personnel to support the implementation process and to support Buyer personnel during all the stages of the project. A Network Element Acceptance of each element shall be per-formed before it is handed over to Buyer (the acceptance procedures are detailed with Acceptance Processes and Criteria) Acceptance includes the following activities:

3.3.1.1.

3.3.1.2.

Planning and Dimensioning As part of the Dimensioning process, Engineering Support for LTE Network Planning is required as part of the RFP services (including documentation): LTE Default Parameter Settings elaboration LTE network Optimisation (guidelines) LTE network Dimensioning (guidelines) 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. Features The Tenderer shall arrange a workshop to present all products and new functionalities / features to engineering and O&M departments. The purpose of the workshop is to establish whether the new features are aligned with the current and planned network and business objectives. Test Equipment and Tools Support shall be provided to ensure that the operation of all (test) equipment and software tools is fully under-stood by one or more key users within Buyer 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.3.

3.3.1.4.

3.3.1.5.

3.3.1.6.

3.3.1.7.

3.3.1.8.

Engineering on Site Assistance With the deployment and optimization scope, on-site assistance may be required but limited to the LTE network design, engineering and reconfiguration actions such as: Network parameters template definition to be the baseline for deployment Assistance for introduction of new software features and parameters configuration Assistance related network architecture, such as definition, service interactions analysis, signalling network definition, etc. Assistance for procedures related to major network re-arrangement or reconfiguration, such as analysis net-work configuration, parameters settings, consistency check, perform statistics, etc. Assistance for the launch of new services Assistance in the deployment, such as integration, interfacing, optimization of the LTE network performance. Network Architecture Design Network Optimisation and 3G inter-working Tenderer is free to propose any other type of engineering services that it may feel required guaranteeing the successful completion of this LTE deployment project. LTE Network Configuration The Tenderer is responsible for defining the initial hardware configuration, such as Antenna type , electrical and mechanical tilts, and Azimuths. Buyer shall approve the configuration that has impact on UTRAN network.(If Buyer would have UMTS network at implement time) The complete responsibility of configuring the LTE Network and all LTE connections needed to carry all types of traffic will lie on Tenderers responsibility. The parameter Template must be approved by Buyer based on Tenderer proposal and any change to baseline Template shall be reported to Buyer. The Tenderer is responsible to do the planning of initial E-UTRAN radio parameters, such as PCI, Neighbours, RACH Root Sequences, etc. Buyer will be provided the eNodeB ID, Cell ID, and TAC. Each action to be performed needs previous creation and approval of a Planned Work. The Tenderer is required to create and send for approval to Buyer of all Planned Work that might be needed during the whole implementation project.

3.3.1.9.

3.3.1.10. OAM Platform All services and activities needed in order to design, dimension, implement and commission of the Network Management System will be performed by the Tenderer. Common agreed documentation will be validated before actual implementation of the proposed solution based on Buyer requirements. 3.3.1.11. End-to-End Quality of Service The Tenderer is responsible for the End-to-End Quality of Service of all types of traffic inserted and transported via the new E-UTRAN Network, to be created according to the traffic contract and SLA to be provided by Buyer (mu-tually agreed before configuration and implementation) Buyer will provided reference KPI indicators and values for values for the Tenderer reference before acceptance and optimisation works. 3.3.2. 3.3.2.1. General Requirement 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 Buyers optimization team in E-UTRAN OSS, such as parameters, neighbour relation, etc. The Tenderer shall provide Buyer the parameter changes that are implemented in E-UTRAN OSS, in a com-prehensive format and in a short time frame, to enable Buyer to adapt those changes on other systems. 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. Team Constitution The Tenderer is expected to have a Well Dimensioned Team with good technical knowledge and preferably with previous experience in similar projects. The project manager responsible for the E-UTRAN deployment and optimization must be senior Engineer and for the entire life time of the project. The Buyer reserves the right to have one or more of its own Engineers following all RAN optimization tasks, such as the measurement tests, data processing and analysis.

3.3.2.2.

3.3.2.3.

3.3.2.4.

3.4.

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

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

The Tenderer shall clearly state if proposes different from above target SLAs Nevertheless must always consider this scenario. (*) In case that restore time exceeds Max resolution Time, the occurrence must not be excluded from Resolution Time calculation. 3.5. Spare Parts Management Services (SPMS) Spare Parts Management Service must ensure the availability, storing, pick-up, repair and delivery of the spare parts to Buyer when and where needed. The Tenderer takes ownership of spare parts and best practices for network evolution. The Tenderer shall describe the service including handling of Buyer service requests, repair and all logistics issues associated. The pick-up and delivery of spare parts to Buyer should consider in several locations, normally the Buyer O&M Centres; the replacement of the faulty units on site shall be under Buyer Technicians responsibility. Spare Parts Management Service Requires The Tenderer shall describe the spare part management process. The Tenderer shall assure a spare part of all equipment including non-reparable items (HW, cables, back-planes, fuses, vendor consumables, etc.) All the spare parts shall be Tenderer property. Spare part list will be dimensioned based on MTBF and Installed base by analysing failure rate. Non-reparable items considered as consumable is not considered under spare list. The Tenderer spare parts must be maintained and kept up to date to face network growth and evolution, en-suring spares availability both in terms of quantities and right revision states and spare storage that enables to delivery replacement Units with accuracy and speed, all according to pre-determined SLAs. Hardware and Software replacement: The Tenderer shall describe the service including handling of Buyer service requests, testing, repair, transport and delivery of the faulty Units to Buyer technicians. Report and Statistics: The Tenderer shall provide monthly statistics / reports of replaced fault Units and provide quarterly the updated list of all the spares identify the critical and non-critical spares

3.5.1.

3.5.2.

The Target SLAs: 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.

3.6.

3.6.1.

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

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

3.6.2.

Site Acceptance Purpose: Guarantee that the site is correctly installed, commissioned and integrated with the minimum levels of quality so that regression is not needed. Description: Buyer will audit the sites in order to check and validate the quality of the deployment. The site formal acceptance will be held together with Cluster acceptance, as long as deliveries are ready and in case of the acceptance criteria is fulfilled. 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: 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 Punch list will feature no blocking issues Site Verification and Check According to Installation and Commissioning (I&C) level of requirements, the Tenderer will check that the sites are in good conditions so as to perform End-to-End tests: All sectors are checked, on air and unlocked OMC Alarms are OK Absence of crossed sectors Acceptance Purpose: Verify that LTE deployment processes are correctly defined and can be scaled up. Validate in live network the software release features, performance and configuration template, already drafted in test plant phase. POC Acceptance Criteria: A. Pilot Cluster accepted B. Performance as per KPIs agreed

3.6.2.1.

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

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

3.6.3.A. Pilot Cluster accepted 3.6.3.B. Performance as per KPIs agreed

3.7.

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

3.7.1.

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

3.7.2.

3.8.

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

3.8.2.

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

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

3.9. 3.9.1.

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

3.9.2.

Test Tools The Tenderer is requested to quote all the test tools necessary as per Scope of Work to manage and optimize the network. The Tenderer shall detail in this document the list of tools quoted for each subsystem. 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. Network Cabling and Racks Cabling The Tenderer shall describe the cabling scheme necessary to implement the solution, namely: Type of cabling Explain how cabling is addressed in the rack and equipment 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. Time Plan 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.

3.9.3.

3.9.4.

3.9.5.

4.1.

4.2. 4.2.1.

4.2.2.

4.3.

4.4.

4.5.

4.6.

5 5.1.

6 6.1.

Services LTE Network Implementation Services The Tenderer shall list and describe in detail services steps / resources / SLAs, with as much granularity as possible: Network Implementation Staging, Installation and Commissioning Functional Acceptance Tests Network Optimisation Test Plant Installation and Commissioning Technical Support SPMS Training, Documentation and Workshops LTE Network Training The Tenderer is required to provide training courses to the Buyer Engineers and in the least cover the following topics: Hardware Integration OSS Platform Theory OSS Platform Practical operation LTE HW Operation and Administration courses LTE Radio Access Network Essentials OSS Administration LTE: Radio Planning Essentials LTE: Radio Planning Specialist Radio Access Network Parameter. LTE Functionalities Course. Counter Monitoring and Implementation Delta Courses The courses should target the different levels of skills and should also be available to Buyer partners (Buyer / Outsourcers). All trainings should be scheduled during year 0. The Tenderer shall propose a training plan. Number of participants per course will be subject to Buyer requirements. The exact amount of training should be defined in the detailed training plan. Please quote courses individually. The Tenderer shall provide a list of training sessions proposed in this RFP for LTE Network. The Tenderer shall provide information for each training session proposed, namely: Contents, Duration, Maximum Number of participants Course HW / SW / Logistic Requisites (test plant nodes, room, projectors, etc.)

7 7.1.

7.2.

LTE Network Documentation The Tenderer shall list and describe in detail what kind of documentation regarding the equipment hardware and software manuals that will be delivered to Buyer. The Tenderer shall also describe the methods available to access the documentation like Web or Documentation CD. The Tenderer shall detail if there are equipment and software manuals that will not be provided within the RFP project to Buyer. COMPANY INFORMATION Q.1 Provide company profile, including wireless research and development organization that support the proposed product development. Q.2 Describe your Taiwan based operation including technical support and service organization Radio Access Network (RAN) Technical Requirement E-UTRAN Technical Requirement This chapter contains all Technical Requirement of LTE Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and UMTS Terrestrial Radio Access Network (UTRAN) with its associated network elements, network design, operation and regulatory requirement. The Tenderer is invited and requested to provide your formal Point-to-Point responses with explanation and supporting document for Questions and Requirement listed in the following sub-sections of this document.

9 9.1.

9.2. Q.3 Q.4

SOLUTION ARCHITECTURE Vendor shall provide a 3GPP compliant LTE solution architecture diagram showing all logical interfaces. 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. Vendor shall describe the benefits of their solution if any in a Solution Overview document.

Q.5

Q.6

The deployed solution shall support 3GPP compliant, software configurable Frequency Division Duplex (FDD) [or TDD] channel bandwidths. Channel bandwidth of 10MHz and 15MHz [and/or 20MHz] should be supported in the initial commercial release. Hardware Roadmap Vendor shall provide 3-year hardware roadmap for E-UTRAN and UTRAN equipment. Vendor should describe all hardware dependencies for 3GPP features available in the roadmap. Vendor should indicate the E-UTRAN and UTRAN hardware phase-out and product Life-Cycle plan for 3 year at least. General Requirement 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.)

9.3. Q.7 Q.8 Q.9 9.4. Q.10

Q.11

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

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

Q.14.(A) Tenderer shall provide Multi-Standard Radio (MSR) solution within same frequency band in single radio hardware. .b. Q.14.(A) Tender with possibility of reusing / co-using existing network equipment to achieve above requirements for Single RAN, MUST identify/ remark the individual reuse .c. / co-use items with its cost saving in Pricing Sheet To demonstrate Tenderers capability on cost-saving. The Tenderer shall provide Pricing Tables with and without reusing/ co-using existing network equipment for different options. Q.14.(A) .d. Q.14.(A) .e. Q.14.(A) .f. Tenderer shall provide 2x2 MIMO ready equipment (and feature 4x4 upgradable / expandable) for above re-quirement. Tenderer shall provide UMTS RNC to support offered 900MHz-WCDMA network Tenderer shall provide interworking / IOT service between offered 900MHz WCDMA network and shall provide interworking / IOT service between offered 900MHz WCDMA network and Buyers incumbent WCDMA system (Core and RAN if Buyer would have) and LTE system (Core and RAN) without KPI degradation.

Q.14.(A) Tenderer shall fully utilize Buyers existing network elements in physical site to minimize the potential CapEx and provide relevant site construction work, I&C and .g. professional services to assure end-to-end performance. Q.14.(A) In Phase 1-3, Buyer may consider covering site construction & civil work for site readiness based on own resource & experience. .h. Q.14.(A) Tenderer shall subject to TSC new spectrum acquired to provide plan adjustment and BoM modification. .i. Q.14.(A) .j. Q.14.(A) .k. Q.14.(A) .l. Q.14.(A) .m. Q.14.(A) .n. Q.14.(B) . Q.14.(B) .(a). Q.14.(B) .(b). Q.14.(B) .(c). Q.14.(B) .(d). Q.14.(B) .(e). Q.14.(B) .(f). Q.14.(B) .(g). Q.14.(C) . Q.14.(D) . Q.14.(E) . Q.14.(F) . Q.14.(G) . Q.14.(H) . Q.14.(I). Tenderer shall provide future expansion / upgrade plan 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 Single RAN solution for offered 2100MHz WCDMA network and also shall provide Single RAN solution together with offered for option 1 in same area. (WCDMA 2100MHz network: swap 2000 sites and 2000 new sites) Tenderer shall provide 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 interworking / IOT service between offered 2100MHz WCDMA network and Buyers in-cumbent WCDMA system (Core and RAN) and LTE system (Core and RAN) without KPI degradation Tenderer shall provide 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 Main Software pack and optional features in every element node Operation, Administration and Maintenance (OAM) or Element Management System (EMS) Test UE device and planning / testing tools IOT / MVI LTE / UMTS Lab Setup Warranty & Maintenance Training (Note: All aforementioned deliverables will be based on end-to-end scope / solution that Tenderer plans to offer Buyer to fulfill all RFP requirements) 9.5. LTE E-UTRAN

Q.15 Q.16 Q.17

Tenderer shall complete the eNodeB Technical Requirements included in Attachment 2: LTE& UMTS feature list and feature roadmap Tenderer shall provide eNodeB which support MSR technology for UMTS / LTE and comply with 3GPP TS37.104, TS37.113, TS37.141, TS37.900 standards. Tenderer shall provide without cost in Buyers Lab regarding your Base-Band Unit and Radio Unit to support Multi Radio Access Technology platform (i.e. UMTS, LTE) in single platform in Buyer designated frequency band (ex 700MHz, 900MHz, 1800MHz, and 2100MHz) Tenderer shall provide eNodeB which comply with 3GPP TS36.104 and TS36.141 Base Station associated re-quirements. Tenderer shall describe all distributed eNodeB types 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 your eNodeB hardware expansion paths and software capacity upgrade possibilities Tenderer shall describe all outdoor eNodeB types Tenderer shall describe all indoor eNodeB types Tenderer shall detail your Hardware functionality and the Software release for a full working MSR radio module. Tender shall detail the specification and limitation of your Multi Carrier Power Amplifier (MCPA) in eNodeB as below:

Q.18 Q.19 Q.20

Q.21 Q.22 Q.23 Q.24 Q.25

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. 9.5.1. Q.26 Q.27 Please state if the MCPA has a power back off when 64 QAM modulation is used? eNode B Architecture Tenderer shall provide the full range of eNodeB equipment include Macro / Micro / Small Cell and Distributed eNodeB solutions 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 Tenderer shall offer eNodeB configurations based on distributed architecture, comprised Baseband Unit (BBU) and a software-defined remote radio unit (RRU)

Q.28

Q.29

Q.30

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 Q.33 Q.34 Q.35 Q.36

Tenderer shall detail the Max. power of each frequency band for new model and MSR ready RRU and Macro eNodeB Tender shall detail the functionality and technical specification of all sub- components for each available eNodeB models presented. Tenderer shall state the maximum distance supported between RRU and BBU The eNodeB shall support indoor and outdoor deployment for both the BBU and RRU. The eNodeB shall support from one up to nine sectors per site

Q.37 Q.38 Q.39 Q.40 Q.41

The eNodeB shall support 32 external alarms The eNodeB shall support a software reboot time of less than 2 minutes 30 seconds The eNodeB shall support an outage during software upgrade of less than 2 minutes 30 seconds Tenderer shall specify circuit breaker capacity required for outdoor eNodeB 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 Q.43 The offered eNodeB by Tenderer shall deploy natural cooling mechanism instead of fan in the cabinet. 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. Q.44 Remote Radio Unit (RRU) Requirements 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 Q.46 Q.47 Q.48 Q.49 Q.50 Q.51 Q.52 Q.53 Q.54 Q.55 Q.56 Q.57 The RRU shall support QPSK modulation. The RRU shall support 16-QAM modulation The RRU shall support 64-QAM modulation Tenderer shall state the maximum instantaneous bandwidth supported by offered RRU Vender shall state the maximum output power level in watts per MIMO branch at the antenna connector of the RRU The RRU output power per MIMO branch shall be software configurable in steps of 0.1dB The RRU shall support adaptive 2x2 MIMO on the DL Tenderer shall specify the RRU physical interfaces supported and the connector types Tenderer shall state the receiver noise figure of the offered RRU. Tenderer shall indicate the power consumption of the offered RRU. Tenderer shall provide the physical dimensions for the offered RRU. Tenderer shall indicate the weight of the offered RRU Tenderer shall indicate the operating temperature range for the offered RRU

Q.58 9.5.3. Q.59 Q.60 Q.61 Q.62 Q.63 Q.64 Q.65 Q.66 9.5.4. Q.67 Q.68

Tenderer shall indicate the protection level for the offered RRU Macro eNodeB Radio Unit Requirements Tenderer shall include in the offer radio modules designed to operate inside indoor or outdoor eNodeB cabinets. The radio unit shall support QPSK modulation. The radio unit shall support 16-QAM modulation. The radio unit shall support 64-QAM modulation Tenderer shall state the maximum instantaneous bandwidth supported by offered modules. The offered module shall support adaptive 2x2 MIMO on the DL. Tenderer shall state the maximum output power level in watts per MIMO branch at the antenna connector of the offered modules. The RF module output power per MIMO branch shall be software configurable in steps of 01.dB. Configuration Requirement The offered eNodeB shall support initial low capacity, large area coverage situation with a clearly defined up-grade path for higher capacity solutions. Tenderer shall provide a general description of max. eNodeB configuration can contain, but not limited to below subjects:

Q.68.A. Description of minimum and maximum configuration of each available eNodeB models Q.68.B. The Number of sectors per eNodeB (Omni site, 2 sector site, 3 sectors site, 6 sectors site) Q.68.C. The number of eNodeB modules that can be cascaded Q.68.D. Maximum baseband capacity per eNodeB. Q.69 The offered eNodeB shall be able to support Multi-technology operation of 3G and LTE simultaneously in the different configurations, fully configurable by the Operator through software.

Q.69.A. Dedicated mode. Q.69.B. Concurrent mode (supported by Hardware). Q.70 Tender shall provide the eNodeB that the Carrier Frequency Bandwidth can be flexibly expand and set upon Buyers demand (i.e. from 1.4MHz ~ 20MHz) without any license control for additional cost and any Software or Hardware upgrade required. 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 provide the maximum optical fiber distance (in meters) between your BBU and RRU in case of distributed site solution? Frequency Bands Support The offered eNodeB shall support following mandatory 3GPP frequency bands.

Q.71

Q.72 9.5.5. Q.73

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. Q.74 Q.75 Q.76 9.5.7. Q.77 Software Feature Support & Roadmap 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 Mobility & Handover The offered eNodeB shall support IRAT selection priority for LTE and UMTS broadcasted in system information. Please provide the details for IRAT Handover based on different handover conditions or criteria.

Q.78 Q.79 Q.80

The offered eNodeB shall support Intra and Inter eNodeB handover with neighbor cell-specific handover pa-rameters. The offered eNodeB shall support neighbor cell-specific blacklists for Inter eNodeB handover 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. The offered eNodeB shall support handover to best cell based on DL Reference Symbol Received Power (RSRP) measurements and thresholds for intrafrequency handover procedures. The offered eNodeB shall support handover to best cell based on DL Reference Symbol Received Quality (RSRQ) measurements and thresholds for intrafrequency handover procedures The offered eNodeB shall support blind handover as inter-frequency handover The offered eNodeB shall support gap-assisted handover measurements for inter-frequency handover. The offered eNodeB shall support configurable gap patterns for gap-assisted handovers. The offered eNodeB shall support bad coverage method based on RSRP and RSRQ with below trigger events for inter-frequency handover:

Q.81

Q.82

Q.83 Q.84 Q.85 Q.86

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 Q.88 Q.89 Q.90 Tenderer shall provide roadmap details about support for Contention-free RACH for intra-LTE handover. The offered eNodeB shall support Inter eNodeB handover: over S1 interface (no X2 interface between serving and target eNodeB) The offered eNodeB shall support Inter eNodeB handover: over X2 interface. The offered eNodeB shall support connection re-establishment procedure (Source eNodeB maintain context; ready for UE return; until UE confirmed on target cell). The offered eNodeB shall support following types of Intra eNodeB handover:

Q.91

Q.91.A. Intra frequency, Q.91.B. Inter frequency: same band Q.91.C. Inter frequency: different band Please specify the detail and its roadmap Q.92 The offered eNodeB shall support following types of Inter eNodeB handover:

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

Q.92.G. Inter SGW Please specify the details and its roadmap. Q.93 The offered eNodeB shall support cell reselection based on:

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

Please specify the detail and its roadmap. Q.94 The offered eNodeB shall support inter frequency reselection priority based on:

Q.94.A. Broadcast of system information Q.94.B. Per UE (priority signaling to UE at RRC release with validity time specified) Please specify the details and its roadmap. Q.95 Q.96 Q.97 The offered eNodeB shall support inter PLMN reselection. The offered eNodeB shall support GAP-assisted or Configurable GAP patterns for IRAT handover measure-ments. Please specify the details and its roadmap. 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 Q.99 Q.100 Q.101 Q.102 9.5.8. Q.103 Q.104 Q.105 Q.106 Q.107 9.5.9. Q.108 Tenderer shall provide the details based on your roadmap about the support of build handover for IRAT using pre-configured neighbors. Tenderer shall detail if Blind handover without measurements be supported Tenderer shall detail the roadmap regarding blind IRAT handover to different RATs Tenderer shall detail the roadmap about the capabilities to secure efficient configuration and consistency of IRAT parameters Tenderer shall provide the Max. Speed (Km/Hr) that offered Base Station can support Regulatory & Standard Compliance The offered eNodeB MUST comply with local regulatory requirement which defined and requested by Na-tional Communications Commission (NCC) The offered eNodeB MUST comply with 3GPP R10, CEPT, EC, CE, UL specifications. Tenderer shall declare which global standards that eNodeB compliance to. The list shall include but not limited to: 3GPP, ETSI, IEC, ISO, EMC, etc. The offered eNodeB shall comply with IP outdoor water Ingress protection standard. 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. Capacity and Performance 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. Tenderer shall provide the reference of network KPI that offered E-UTRAN software & Hardware can achieve. Tenderer shall comply with 3GPP TR36.913 requirement in spectrum efficiency and cell edge user throughput. Installation Requirement 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. The eNodeB shall support Tower Mounted Amplifier (TMA) which complies with 3GPP specification of TS25.466 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)? Is it possible to share low noise Tower Mounted / Mast-head Amplifiers (TMAs)? Is it possible to share Power Supply components? Is it possible to share RF feeders and Antenna? Is it possible to share physical transport interfaces? Is it possible to share any other items? Tenderer shall provide test equipment to measurement the engineering quality of site working during installation / optimization then guarantee the defined KPI performance

Q.109 Q.110 9.5.10. Q.111

Q.112 Q.113

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

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

Tenderer shall provide following RAN characteristics and specification, nothing variations across various models in eNodeB / NodeB portfolio. Height Width Depth Free access space required for different cabinet scenarios Weight Total weight, fully configured Per Cabinet For each range of battery backup capacity offered For main-remote state the weight of its individual main components

Q.116 9.5.11. Q.117 Q.118 Q.119

Tenderer shall state clearly your eNodeB backhaul connectivity options. eNodeB Backhaul Requirement Tenderer shall detail proposed solutions of backhaul and transport capabilities across different eNodeB portfolio. Tenderer shall provide the roadmap for eUTRAN Transport feature / functions 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 . Tenderer shall detail what physical interfaces for X2/S1 and O&M does the eNodeB provide? The offered eNodeB shall support Native Ethernet in eNodeB. 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. Tenderer shall detail how your E-UTRAN support IPv6 on IP (X2, S1) interface in which Software Release? The offered eNodeB shall support Gigabit Ethernet Optical and/or Electrical port in eNodeB Tenderer shall detail the number and type of communications ports available for local Q&M connectivity.

Q.120 Q.121 Q.122 Q.123 Q.124 Q.125

Q.126 Q.127 Q.128 Q.129 Q.130 Q.131 Q.132 Q.133 Q.134 Q.135 Q.136

The offered eNodeB shall support traffic separation between Signaling & Data flow. 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. The offered eNodeB shall IPsec and IKEv2 for the traffic according to the 3GPP specification in eNodeB. Tenderer shall detail the support for Call Admission control to manage backhaul limited traffic conditions. Tenderer shall detail the standards supported for the eNodeB transport solution Tenderer shall detail the requirements on the backhaul from an X2 interface connectivity and characteristics perspective. Tenderer shall detail the synchronization solutions supported by the eNodeB for LTE FDD. Tenderer shall detail the O&M system that monitors the real-time IP traffic measurements. Tenderer shall detail the maximum number of Transmission interfaces that an eNodeB can support? Tenderer shall detail the transport QoS handing in eNodeB 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 eNodeBs S1 and X2 interface support traffic shaping taking into account end-toend delay budget? Tenderer shall detail the maximum and minimum downstream / upstream peak bandwidth support on eNodeB S1 and X2 interfaces. 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) If your eNodeB performs admission control based on current availability and performance of transport backhaul resources? Tenderer shall detail the redundancy mechanisms available on S1/X2 link failures Tender shall detail the maximum number of GigE, optical, electrical ports available on S1/X2 links of the eNodeB? Physical & Environmental Requirement

Q.137

Q.138 Q.139 Q.140 Q.141 Q.142 Q.143 9.5.12.

9.5.12.1. General Requirement Q.144 Q.145 Tenderer shall state if your eNodeB is fully, partially or not comply with 3GPP TS36.104 and TS36.141 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 provide an overview description of the eNodeB portfolio, including current /future commercial deployments.

Q.146

9.5.12.2. Power Consumption and Energy Savings Q.147 Q.148 Q.149 Tenderer shall detail power supply input for each eNodeB type. Tenderer shall indicate if your equipment can be powered with 24V or -48VDC power source without the use of an external AC/DC converter. 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. Tenderer shall state the eNodeB battery backup solution for each eNodeB type. Tenderer shall indicate if there is power management software to provide energy saving. 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.150 Q.151 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.153.( B).A. Q.153.( B).B. Q.154 Q.154.A . Q.154.B . Q.154.C . Q.154.D . Q.154.E . Q.154.F. Q.155 Q.156 Q.156.A . Q.156.B . Q.156.C . Q.156.D . Q.157 Q.158 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 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 Product Buyer the Compliance of Standard: EU Directives: 73/23/EEC Low Voltage Directive Code of Federal Regulation 21 CFR 1040.10 and 1040.11 EN 60 950-1/EC 60.950-1:2001 and IEC 60 950:1999 EN 60 215/IEC 60 215:1987 ANSI/UL 60 950-1/CSA C22.2 No. 60 950-1-03 IEC 60 825-1/EN 60 825-1 The eNodeB shall conform to the following standards IEC/EN 60 068-2-57 on earthquake protection. The vibration resistance vs. Specification are shown as below: Normal operation: Max. 0.02 m2/s3 Exceptional operation Max. 0.08 m2/s3 Non-destructive Max. 0.15 m2/s3 Shock Max. 30 m/s2 Ingress Protection Rating, IP55 requirements according to the standard IEC/EN 60 529 Acoustic Noise Requirements (maximum sound pressure level): the measurement method is according to EN ISO 11201, at a bystander position one meter from the cabinet in a free field at a room temperature of 25C SHALL NOT exceeed 54dB.

9.5.12.4. SmallCell and HeNet Support Q.159 Q.160 Q.161 Q.162 Tenderer shall support different types of SmallCell base-station such as Micro, Pico, and FemtoCell. Tenderer shall provide the SamllCell product and detail how to integrate with MarcoCells. Tenderer shall provide the value propositions of SmallCell 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) Tenderer shall detail describe HeNB, HeNB GW, SeGW functionality Tenderer shall detail describe the HeNB requirement as below but not limit to Connectivity interface requirement (such as: LTE-Uu, S1-MME, S11, S6a, C1 and so on) Mobility management (TAI assignment, connected mode, Idle mode and so on) Service and emergency service SON / SCN requirement LIPA (Local IP access) / SIPTO (Selected IP Traffic offload) requirement

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

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 Q.167 Q.168 9.5.13. Q.169 Q.170 Tenderer shall provide the SamllCell backhaul security solution (including IP attack, Hiker or environment security) Tenderer shall do IOT between existing UMTS / LTE network and 3rd party equipment (e.g. Other vendors HeNB, or SmallCell Gateway) in live network Tenderers SmallCell solution shall comply Lawful Interception for System Inspection to CIB if needed. Carrier Aggregation (CA) Tenderer shall detail the mechanism how your Software or Product CA. 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 comply the CA band & bandwidth options stated in TS36.104 / 36.101 / 36.307 / 36.141 Tenderer shall provide the reference document of latest confirmed / studied frequency band and BW com-bination in 3GPP Tenderer shall provide eNodeB support both CA and Non-CA UE working properly in the Buyers network. The terminal with CA capability (ex. Category 6) can support max. downlink / uplink throughput to To meet current Taiwan 4G Frequency bands, Tenderer shall comply the CA of:

Q.171 Q.172 Q.173

Q.174

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. Q.175 Q.176 Q.177 Q.178 Antenna Requirement & Solution Tenderer shall offer an antenna system including antenna / RET / Remote Control Unit / TMA (optional) / Antenna Control & Monitor System. Tenderer shall offer the antenna system engineering included RF feeder / duplex / Biastie / optical fiber etc. site work. Tenderer shall provide the global reference regarding the type, usage and site-work of Disguised Antenna. Tenderer shall provide the recommended various types of antenna for different applicable scenarios for implementing. These antennas shall pass the certification test in Global or NCC authorized lab.

Q.179

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

9.5.15. Q.180 Q.181 Q.182 Q.183 Q.184 9.5.16. Q.185 Q.186 Q.187

Network Synchronization Tenderer shall detail eNodeB synchronization concept in an all-IP network. The Synchronization using GPS or Galileo (or both) shall be supported. The offered eNodeB shall support the NTP synchronization over IP and IEEE 1588v2 in eNodeB The offered eNodeB shall support synchronization via external interface in eNodeB If multiple methods for synchronization are supported, please comment on which is recommended and why. 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. Miscellaneous Requirements Tenderer shall provide the MTBF (Mean Time Between Failure) of all offered E-UTRAN products. Tenderer shall provide the timeframe of product EOS (End of Support) and EOL (End of Life) 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 provide the network Prevention & Recovery mechanism / plan for potential Network Outage. E-UTRAN / UTRAN Features Tenderer shall comply with the features defined in 3GPP R10 (Backward compatible to R9, R8 and UMTS) and Buyers feature request list. This compliance will be included LTE E-UTRAN and UMTS UTRAN. Please Tenderer fill in the E-UTRAN / UTRAN Feature Compliance following the template requested in the corresponding table. Tenderer shall provide your Compliance Table with latest version or future supported roadmap which map-ping to 3GPP (R8, R9 and R10) standard. 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. UMTS UTRAN Tenderer should provide latest version UTRAN with all feature and hardware needed to meet the following requirement. HSDPA+ DC MIMO 84M Provide Maximus Channel element (more than 1500 channel element per node B) 3 separate scheduler(Each separated package schedule for each sector, without reduce the HSDPA+ coding channel elements) HSDPA: 21M x 3 sectors (2 carriers) & 72 users HSUPA: 5.8Mbps x 3 sectors (2 carriers) & 72 users

Q.188

Q.189 9.6. Q.190

Q.191 Q.192 9.7. Q.193 Q.193.A . Q.193.B . Q.193.C . Q.193.D . Q.193.E . Q.193.F.

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

Q.196

Tenderer shall provide a solution proposal to detail how your UMTS UTRAN to co-locate with TSC 3G equipment and sharing with existing antennas and feeders. Please provide the cabling plot from NodeB module to Antenna side to support Multi-RAT and antenna sharing. 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 Buyers MSR RAN contract shall provide all initial tuning, frequency re-planning and optimization service for offered Access Technology (i.e. UMTS and LTE) to ensure end-to-end KPI performance. Reuse of Existing Network Equipment Tenderer shall fully utilize existing facility to reuse or expand the modules in existing racks and site engi-neering. 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 support maximum re-use of the existing equipment to demonstrate your advantage in terms of cost, space and energy saving. Tenderer shall propose a solution / migration proposal to deal or handle Buyers existing U2100 Network with your offered MSR platform Self Organizing Network (SON) General Requirement Tenderer shall comply 3GPP SON requirement and detailed explain each of SON features (including: monitor counters, change parameters, flow, etc.) Tenderer shall comply 3GPP (TS32.500, TS32.501, TS35.502, TS32.503, TS32.521, TS35.522, TS32.526, TS32.541, and TS36.902) Tenderer shall reply the detail action / reaction time / work flow of each of SON function Tenderer shall provide the detailed multi-RAT SON solution description to integrate with Buyers WCDMA / LTE system. Tenderer shall provide the SON solution, but not limit standard such as ANR (Automatic Neighbor Relation), MLB (Inter RAT / Inter and intra frequency Mobility load balance), MRO (Mobility Robustness Optimization), Inter-RAT MLB Multiple Cell load report, Inter-RAT unnecessary handover report, Automatic TA (Tracking area), Automatic PCI (Physical C. II ID) configuration, Automatic SC (Scrambling Code) configuration, RACH Optimization, eICIC (Enhanced Inter Cell Interference Coordination), CCO (Capacity and Coverage Optimization), CODC (Cell Outage Detecting and Compensation), Cell Supervision, Energy Savings

Q.197

Q.198

Q.199

9.8. Q.200 Q.201

Q.202 Q.203 9.9. 9.9.1. Q.204 Q.205 Q.206 Q.207 Q.208

Q.209 Q.210 9.9.2. Q.211 Q.212 Q.213 Q.214 Q.215 Q.216 Q.216.A . Q.216.B . Q.216.C . Q.216.D .

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. Tenderer offered SON solutions shall be aligned / upgraded with future SW version of all buyers mul-ti-vendor mobile system. Self-Configuration (ANR) Tenderer shall comply 3GPP TS32.501 Self Establishment of new eNodeB Tenderer shall comply 3GPP TS32.511 Automatic Neighbor Relation Management The offered ANR function shall support to implement SON Automatic Neighbor Relation for LTE , UMTS A SON feature shall have the capability to detect the HO failures, identify the reason / impact on overall network performance and take remedial actions. Tenderer shall provide an algorithm controlled automated SON function which optimized QoS related pa-rameters (ex. QCI) at each node. Tenderer shall detail how your SON algorithms workable for the following key maintenance mechanisms: Self software upgrade Service verification after upgrade Customized upgrade policy, ex: for use MML (Man-Machine Language) commands or GUI and so on. Automatic rollback to previous software version

Q.216.E Automatic Inventory . Q.216.F. Subscriber and equipment trace Q.216.G Support antenna fault detection . Q.216.H Real-time Performance Management and Reporting . Q.216.I. Indicate how SON support for Minimum Drive Test Q.217 Tenderer shall detail their implementation for ICIC (or enhanced ICIC) and 2 years roadmap to support Adaptive ICIC (Inter-Cell Interference Coordination), which can further improve inter-cell interference cancellation performance and improve cell edge throughput. Self-Optimization (MLB / MRO / CCO) Tenderer shall comply 3GPP TS32.521 Self-Optimization 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 detail the related counters / parameters and methodology of MLB, MRO, COO Tenderer shall detail MLB work flow and train buyer how to use this feature, but not limit to for example: IRAT. Tenderer shall provide the recommended value for different area of MLB, MRO, CCO Tenderer shall train buyer to operate the MLB, MRO, COO and help buyer to optimize the network Tenderer shall detail MRO work flow and train buyer how to use this feature, but not limit to for example: IRAT. Tenderer shall detail COO work flow and train buyer how to use this feature, but not limit to for example: IRAT. Self-Healing (Minimization of drive tests MDT) Tenderer shall comply the 3GPP TS32.541 Self-Healing Tenderer shall detail how to automatically detect and remove failures and automatic adjustment of parameters Tenderer shall detail how automatic correction of capacity problem depending on slowly changing environment, like seasonal variations. Tenderer shall explain how to minimize the drive test effort of buyer. Network Planning & Optimization General Requirement Tenderer shall provide the detailed network planning & optimization guideline and service to Buyer (including IRAT & HeNet, existing Network, etc.) Tenderer shall detail the methodology and tool for network planning and optimization Tenderer shall introduce and train buyer how to plan, dimension and optimize the network Tenderer shall provide the site naming rule suggestion and PCI, Tracking Area, Neighboring planning suggestion 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) Network Scope Here the Network means Buyers new LTE network and existing 3G migration Network (also including IRAT, HetNet and WiFi) Tenderer shall plan and optimize Buyers network to achieve the KPIs requested by 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.

9.9.3. Q.218 Q.219

Q.220 Q.221 Q.222 Q.223 Q.224 Q.225 9.9.4. Q.226 Q.227 Q.228 Q.229 9.10. 9.10.1. Q.230 Q.231 Q.232 Q.233 Q.234

9.10.2. Q.235 Q.236 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 Tenderer shall base on Buyers assumption a below to come out simulation result in different frequency band scenarios to fulfill Taiwan island-wide 99% population coverage.

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

9.10.3.1. Coverage Dimensioning 9.10.3.1. Area & Population Coverage Target 1. Q.239 Tenderer shall provide recommended Area & Population Coverage Percentage Target based on global reference Q.240 Tenderer shall run the simulation to get the actual and target Area & Population Coverage Percentage based on buyers requirement (i.e. 99% Population Coverage Percentage) Tenderer shall provide the simulation assumption and parameters for reference and further inspection. Tenderer shall prove the simulation accuracy of final output result Tenderer shall help buyer to run the simulation result based on NCC requirement stated in 4G auction reg-ulation

Q.241 Q.242 Q.243

9.10.3.1. Link Budget 2. Q.244 Q.245 Q.246 Q.247 Q.248 Tenderer shall provide the link budget tool to buyer Tenderer shall provide the Downlink / Uplink link budget table to buyer Tenderer shall provide the training and reference value to explain buyer how to use your Link Budget tool. Tenderer shall prove the accuracy of link budget result Tenderer shall provide the accurate Propagation Model (i.e. K Parameters) to buyer that is fully verified with model tuning in Taiwan.

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

Q.250

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

Q.251 Tenderer Dimensioning shall provide the simulation print-out plots based on buyer requirement 9.10.3.2. Capacity 9.10.3.2. Traffic & Subscriber Demand 1. Q.252 Tenderer shall provide buyer capacity dimensioning guideline and case study based on buyer requirement Q.253 Q.254 Tenderer shall provide the global traffic and subscriber forecast reference by 2020. Tenderer shall provide the global per user data user (Mbps) by device type 2020 for reference.

9.10.3.2. Cell Capacity 2. Q.255 Tenderer shall provide the reference of Cell Capacity. Q.256 Tenderer shall provide the simulation assumption and result to prove the cell capacity in different condition which based on buyer requirement

9.10.3.2. Spectrum Efficiency 3. Q.257 Tenderer shall provide the definition and formula of Downlink and Uplink spectrum efficiency. Q.258 Q.259 Q.260 Tenderer shall provide the spectrum efficiency in different channel bandwidth (1.4MHz ~ 20MHz) 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. Tenderer shall fill in the average spectrum efficiency

9.10.3.2. Required Capacity Sites 4. Q.261 Tenderer shall provide the Multi-RAT planning methodology to integrate the CS / PS traffic demand across different RAT (LTE / UMTS / WiFi) network Q.262 Q.263 Q.264 Q.265 Tenderer shall provide the overall capacity simulation result across LTE / UMTS / WiFi network based on buyer requirement Tenderer shall consider if the traffic offload (or upload) to (from) UMTS in the capacity dimensioning result Tenderer shall consider if the traffic offload to WiFi in the capacity dimensioning result Tenderer shall provide the total quantity of capacity site counts in very district

9.10.3.3. Overall Network Dimension Result Q.266 Q.267 9.10.4. Q.268 Q.269 Q.270 9.10.5. Q.271 Q.272 Q.273 Tenderer shall provide the overall network dimension result based on buyer requirement Tenderer shall explain and provide the overall network dimensioning report and output to buyer Frequency Planning & Strategy Tenderer shall provide the frequency planning and strategy based on buyer requirement Tenderer shall provide the result and report of frequency planning and strategy Tenderer shall explain and compare the pro and con of different frequency reuse scenarios. Interference & Guard-Band Consideration Tenderer shall take full responsibility to support buyer to resolve potential interference issues. Tenderer shall provide the interference study reference (ex. Standard or research / field test report) of & Guard-Band suggestion to buyer Tenderer shall provide the minimized Guard band solution of all products (not limit Marco / Micro / Pico between technology (U+L))

9.10.5.1. 700MHz Band Q.274 Tenderer shall take full responsibility to support buyer to resolve potential interference issues.

Q.275

Tenderer shall provide the 700MHz interference test report or reference between LTE and other wireless technologies (ex. DTV/Low PWR transmitter to LTE but not limited to) and provide corresponding suggestion for Guard band. Tenderer shall provide the latest global APT-700MHz license release, BTS/UE readiness and operator im-plementation reference

Q.276

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

9.10.5.3. 1800MHz Band (GSM / UMTS vs. LTE) Q.279 Q.280 9.10.6. Q.281 Q.282 9.10.7. Q.283 Q.284 Q.285 9.10.8. Q.286 Q.287 Q.288 Q.289 9.10.9. Q.290 Q.291 Tenderer shall provide the Guard-band reference and suggestion for potential 1800MHz interference. 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. ICIC & EICIC Tenderer shall detail your ICIC & enhanced ICIC solution and roadmap Tenderer shall prove the advantage and efficiency of ICIC & EICIC either via trial or global reference Frequency Scanning for Interferer Tenderer shall provide the related methodology & guideline for spectrum scanning for interference. Tenderer shall provide the related existing interference result or reference according to Taiwan band plan. Tenderer shall support buyer to find out potential interference. PCI, Tracking Area (TA) and PRACH Planning Tenderer shall provide the mechanism and guideline regarding how to plan PCI, TA and PRACH. Tenderer shall provide PCI, TA and PRACH planning result once awarded for whole buyers Taiwan sites based on assumptions agreed by Buyer Tenderer shall state the design relation and criteria between TA & LAC Tenderer shall provide the real planning case study on PCI, TA and PRACH from global reference or experience Neighbor Relation Planning Tenderer shall run the Neighboring Planning based on buyers requirement Tenderer shall help buyer updating the neighboring after Network initial tuning.

9.10.10. Initial Tuning & Optimization Q.292 Tenderer shall provide your Network Optimization Guideline which detail all the monitoring and improve-ment KPI with its optimization methodology and actions.

Q.293 Q.294 Q.295 Q.296 Q.297 Q.298

Tenderer shall detail the tuning methodology from Preparation Phase / Test Phase / Analysis Phase and Report Generation to Cluster Finished. Tenderer shall detail network checks included site available and site design check in Preparation Phase. Tenderer shall detail site checks included correct PCI and swapped feeder/antenna analysis in Preparation Phase. Tenderer shall detail parameter consistency checks included the neighbor relation and the parameter check in Preparation Phase. Tenderer shall detail feature checks in Preparation Phase. Tenderer shall detail testing preparations included drive test rout and Hot Spot location in the Preparation Phase.

Q.299 Q.300 Q.301 Q.302

Tenderer shall detail mobility and Hot Spot tuning included coverage / quality in Test Phase. Tenderer shall detail problem analysis and report generation in Analysis Phase. Tenderer shall provide new site planning, technical site survey and initial tuning that are required for new site acceptance. 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 shall proposed drive test route planning and it shall include new site surrounding area and over-lapped with first circle neighbors Tenderers initial Tuning Drive Test works have to include signaling analysis for any occurred cell event and proposed Antenna Change Request & Parameter Change Request are also needed, besides a verification drive test and cell level KPI monitoring shall be performed after CR executing. 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. Tenderers initial tuning analysis engineer and planning engineer must at least have 3 year experience in UMTS & HSPA network RF planning and optimization. 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. Tender shall provide initial tuning report (include drive test results, call event analysis in 3 calendar days after new site on air. Tenderer is required to provide adequate drive test resources to meet the rollout schedule. 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. Tenderer shall provide the LTE coverage benchmark drive test per quarterly in Tenderers awarded area during rollout period. Tenderer shall provide the LTE coverage benchmark analysis report and improvement suggestions to Buyer for each time drive test.

Q.303

Q.304

Q.305 Q.306 Q.307 Q.308 Q.309

Q.310 Q.311 Q.312

Q.313 Q.314

Q.314.A General network performance (coverage, capacity, quality , ect) . Q.314.B General traffic channel performance (peak / average bear access rate, BER BLER, peak/average power, RSRP RSRQ, SINR, accessibly. The quality of voice, . packet date etc) Q.314.C . Q.314.D . Q.314.E . Q.314.F. General signaling (control) channel performance Handover performance Traffic utilization Random access signaling

9.10.11. Network Performance Monitoring & KPI Commitment Q.315 Q.316 Q.317 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. Tenderer shall provide the complete description / formula (with recommended value) of E-UTRAN / UTRAN PM counters 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. Tenderer shall propose the test plan in ATP to confirm the network KPI had been achieved for the ac-ceptance test. To minimize the call setup time during CSFB, Tenderer shall provide your signaling processing time in eNodeB part from your reference network and support Buyers to minimize the end-to-end set-up time.

Q.318 Q.319

Q.320

Tenderer if awarded both Buyers Core and RAN network, shall guarantee the CSFB KPI Buyer reserves the right to determine if the KPI is acceptable with convincing supportive justification provided by vendor. 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.

Q.321

9.11. 9.11.1. Q.322 Q.323 9.11.2. Q.324 Q.325 Q.326 9.11.3. Q.327 Q.328

Network Evolution & Migration Network and Technology Evolution 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. Spectrum Migration Strategy with different RAT 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 Buyers network (ex. U2100, L700/900/1800) for future forecast or existing traffic trend. Tenderer shall provide the deployment scenarios for different spectrum and access technology Traffic Offloading Tenderer shall detail the main complementary network technologies used for mobile data offloading like WiFi, SmallCell and other offloading approaches. 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 Q.330 Tenderer shall detail WiFi offloading methodology between WiFi AP and user device by WiFi Alliance / Hot Spot 2.0 requirement Tenderer shall detail WiFi offloading methodology between cellular and WiFi network by 3GPP standards requirement.

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

9.11.3.1. User Authentication 3. Q.334 Tenderer shall detail the support of any kind of automatic WiFi access authentication in user authentication. Q.335 Tenderer shall provide the authentication flow and detailed description.

9.11.3.1. Network Selection & Connection Management 4. Q.336 Tenderer shall detail the Network Selection methodology that can automatically switch to WiFi network if the user device detects a known Wi-Fi network. Q.337 Tenderer shall detail your connection manager solution that can automatically switch to WiFi network if the connection manager detects a known WiFi network

9.11.3.1. Traffic Offloading Performance Evaluation 5. Q.338 Tenderer shall detail your methodology to prove traffic offloading performance evaluation Q.339 Tenderer shall detail the performance KPIs of the traffic offloading performance evaluation

9.11.3.2. SmallCell & HetNet Traffic Offloading 9.11.3.2. SamallCell Architecture & Flow 1. Q.340 Tenderer shall detail smallcell architecture and node function 9.11.3.2. SmallCell Integration 2. Q.341 Tenderer shall provide the smallcell integration rule and steps Q.342 Q.343 Tenderer shall provide the smallcell integration plans and suggestions Tenderer shall provide the smallcell integration scenario (HetNet, indoor, hot spot)

9.11.3.2. Traffic Offloading Performance Evaluation 3. Q.344 Tenderer shall provide a free trial to prove the smallcell traffic offloading Q.345 Tenderer shall provide the small celltraffic offloading performance evaluation rule and what KPI to monitor

9.11.3.2. Other Offloading Approach 4. Q.346 Tenderer shall detail to support of any kind of offloading approach besides WiFi and smallcell 9.12. 9.12.1. Q.347 Q.348 Q.349 Q.350 Q.351 Q.352 Q.353 Transport Requirement General Requirement Tenderer shall detail the available transmission interfaces and capabilities of the eNodeB product portfolio. Tenderer shall detail the backhaul bandwidth dimension methodology and list bandwidth requirement in each phase The eNodeB shall support versatile Ethernet types of interfaces, such as GE (optical or electrical) to meet different network deployment scenarios. The eNodeB shall must support Ethernet Jumbo Frame with the MTU value for transport IP packet up to 1600 for IPv4 or IPv6 The eNodeB shall support transmission topologies such as Tree topology, Star topology and Chain topology to meet different requirement The eNodeB shall support virtual IP address, physical interface IP addressing and VLAN addressing to support traffic separation on layer 2 and 3. 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. The eNodeB shall support multiple VLANs, at least 4 VLANs for U-plane, C-plane, M-plane and S-plane The eNodeB shall support IPV4 or IPv6 and list each complies standard. The eNodeB shall to integrate with Buyer existing Carrier Ethernet Backhaul Network The eNodeB shall support authentication to the transport network using 802.1x (Port-based Network Access Control), between eNodeB and buyer existing LANSwitch, improving security in network domain. 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.

Q.354 Q.355 Q.356 Q.357

Q.358

Q.359

Q.360

Q.361

Q.362

Tenderer shall provide E2E transport connectivity monitoring Bidirectional Forwarding Detection is required for instance to check connectivity between eNodeB and intermediate transport network elements. The eNodeB shall support Ethernet Link Aggregation (802.3ad) to bind several Ethernet links to one logical link. The eNodeB shall support Ethernet OAM (IEEE 802.3ah) The eNodeB shall support Ethernet OAM (IEEE 802.1ag) The eNodeB shall support Ethernet OAM (Y. 1731) Transport QoS Tenderer shall state the IP transport requirement for LTE E2E QoS The eNodeB must support an integrated functionality to perform E2E IP performance monitoring. The eNodeB must support traffic shaping: It guarantees that the total available traffic bandwidth is not larger than the total configured bandwidth. 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. Tenderer shall detail the available queue size and list the queuing algorithms supported in transport interface of eNodeB Operation Administration and Maintenance This is to detail the requirement for Operation Administration and Maintenance (OAM), which is required for the efficient operation, administration and maintenance of the LTE E-UTRAN & UMTS UTRAN system, and all of its Network Element (NEs) (e.g. eNodeB, HeNB / HeNB GW, NodeB / RNC, SON and core network elements if provided etc.), and the said OAM for efficient operation and management of the overall network, including the Buyers existing network system. General Requirement 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. The NMS / EMS shall have the capability to allow at least 100 concurrent staffs to access simultaneously. The NMS / EMS shall provide online help functions. Tenderer shall provide the NMS / EMS administrator / operation training. Tenderer shall provide hardware server include rack installation for operation post process and the server specification shall be confirmed by Buyer. 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. Tenderer shall provide surveillance mechanism for monitoring the IP devices such as switch / router / firewall which are build for the LTE network system. 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. In case of NMS / EMS is out of service, the network operations and services to the customers shall not be interrupted. Tenderer shall provide complete training course which include but not limited the NMS / EMS / OJT (on job training) Network Element (include network architecture) training course for the Buyers operation and maintenance, also in Software / Hardware upgrade period. E-UTRAN Element Management System (EMS) The system shall provide 24 hours uninterrupted service.

Q.363 Q.364 Q.365 Q.366 9.12.2. Q.367 Q.368 Q.369 Q.370 Q.371 Q.372 Q.373 9.13. Q.374

9.13.1. Q.375

Q.376 Q.377 Q.378 Q.379 Q.380

Q.381 Q.382

Q.383 Q.384 9.13.2. Q.385

Q.386

The system unavailability means the status of the system being in non-operation. It is defined as percentage of average repair duration to the period between repairs. Less than 0.05% is acceptable (system availability of 99.5% or higher) The NMS / EMS shall provide activity-activity HA (High Availability) solution, including hardware, software and implementation. Then NME / EMS system fail-over impact time less than 10 minutes. Tenderer shall provide HA System full UAT including Configuration Management, Fault Management, Per-formance management and Security management

Q.387 Q.388 Q.389

Q.390 Q.391 Q.392 Q.393 Q.393.A . Q.393.B . Q.393.C . Q.393.D . Q.393.E . Q.394 Q.395 Q.396 Q.396.A . Q.396.B . Q.396.C . Q.396.D . Q.396.E . 9.13.3. Q.397

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. The NMS / EMS database shall include fault data, configuration data, maintenance data and performance / QoS data. Tenderer shall provide the details of the provided database, information of database structure, and database application development software. The NMS / EMS equipment shall meet at least the following requirement: Support Hot-plugged HD Support Hot-plugged power supply Normal total Disk usage can not over 50% Normal total CPU usage can not over 60% Normal total Memory usage can not over 70% Tenderer shall provide facility requirement include power and cabling for NMS / EMS installation. When NMS / EMS server reach max dimension support, system overall loading cannot over 80% In order to take advantage of industry wide improvement and migration, commodity hardware is preference. Standard Unix / Linux Hardware (HP, Oracle-SUN) Standard OS (Linux, HP Unix, Solaris, AIX) Standard disc portioning (Raid 10) Full configuration from central server without local site configuration needs No hidden license cost and 3rd part integrated software cost. Alarm Management 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 provide NE trouble shooting tool and NE provision tool. The NMS or EMS shall provide capabilities for verification the operation of each NE and service. 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. In EMS and NMS, the alarm severity can be redefined by operator. The severity type must match between EMS and NMS. Tenderer need provide Software management tools in NMS / EMS

Q.398 Q.399 Q.400 Q.401 Q.402

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

Q.403

The NMS / EMS shall provide alarm and NE configuration data export tool, which export data shall be summarized and format shall be .xls, .csv or .txt, NE configuration data can be filtered by operator. 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. The NMS / EMS shall provide automatically update topology manage object within near real-time The NMS / EMS shall provide NE and system backup function. System Healthy Check & Consistency Check requirements

Q.404

Q.405 Q.406 Q.407

Q.407.A Tenderer shall provide Consistency Check tool. Consistency check on the parameters between NE (filtered by NE, able to export all parameters of the filtered NE, . update parameter and then reload back to DB) Q.407.B . Q.407.C . Q.407.D . Q.407.E . Tenderer need provide the system and NE health check function for hardware, application program and service status. Network Management Tools requirements Tenderer need provide network management tools in which can execute mass parameters change, add, delete and move cell at same profile. Tenderer need provide hardware management tool in which can execute hardware and firmware version upgrade and type control and it can automatically and manually export hardware management data.

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

Q.408.A Tenderer shall provide call tracing (position locate) interface and function . Q.408.B Call tracing function shall include current & history & operator logs . 9.13.4. E-UTRAN Fault & Alarm Management Q.409 Q.410 Q.410.A . Q.410.B . Q.410 C. Q.410 D. Q.410 E. Q.410 F. Tenderer shall provide 45 man-days on job training for fault management The NMS / EMS function shall provide fault management messaging: Managed Object Type Managed Object Name Alarm Description Probable Cause Specific Problem Perceived Severity

Q.410 Additional Text G. Q.410 Additional Information H. Q.410 I. Alarm Set-time & Update-time Q.410 J. Alarm Clear Time Q.411 Q.411 A. Q.411 B. Q.411 C. Q.411 D. In NMS / EMS, the fault management shall include, but not be limited to the following audit items: Routing Error Authentication Failure Call Setup Failure Protocol Error

Q.411 Link Failure E. Q.411 F. Network Element Data Corruption Error Q.411 Mass Call, Overload and Congestion G. Q.411 Network Element Failure H. Q.411 I. Facility Failure Q.411 J. Trunk Failure Q.411 K. Q.412 Q.413 Hardware / Software Failure. Alarm (include alarm description, severity time ) between NMS / EMS shall be in synchronization. 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. The alarm in NMS / EMS can be acknowledged and unacknowledged. The alarm can be manually and automatically cleared in alarm view but alarm still need to be stored in system DB. In NMS / EMS, when the events is recovered then need provide clear status to update the original alarm. 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. The NMS / EMS receive and display alarm shall be with network element within near real-time 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. 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. In NMS / EMS, specific NE alarm can be displayed from NE list in the Tree view and Topology views. The NMS / EMS shall detect and screen repeated alarms. 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. The NMS / EMS can filter any column field and parameter of alarm message and filter any network element type. The NMS / EMS shall provide monitor on specific NEs area (ex: central area, south area, Taichung county area) NMS shall receive all NE alarms which in LTE network The NMS / EMS need provide alarm viewer for alarm surveillance and pump up the window of alarm viewer shall be within 5 seconds. The NMS alarm viewer can open at least 3 sub-windows on same window. The NMS / EMS shall be able store and print the detailed alarm log with related information.

Q.414 Q.415 Q.416 Q.417 Q.418 Q.419 Q.420 Q.421 Q.422

Q.423 Q.424 Q.425 Q.426 Q.427 Q.428 Q.429 Q.430 Q.431 Q.432 Q.433 Q.434

Q.435

In NMS / EMS, the alarm can link to relative operation process of online help guide. Online help is referring to the NE troubleshooting guide on how to fix the alarm. The guide is preferred in the form of web link. The NMS / EMS alarm can link to command tools & GUI of relative manage object and pump up command screen within 5 seconds 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.

Q.436 Q.437

9.13.4.1. Alarm Analysis and Alarm Correlation Q.438 The NMS / EMS shall provide event correlation tools for root cause analyze, reduce alarm, modify alarm severity and automatically trigger recovery process. The correlated alarm shall reflect the highest severity. 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.

Q.439

9.13.4.2. Log Management Requirements Q.440 Q.441 Q.442 9.13.5. The NMS / EMS shall store alarms and events to an historical database. 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. 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. E-UTRAN Performance Management

9.13.5.1. Performance Management System Q.443 Q.444 Q.445 Tenderer shall propose the comprehensive traffic data, their statistics and report format in detail for the Buyers evaluation. The Buyer reserves the right to modify and choose during the rollout period and the modification shall be performed by Tenderer at Tenderers expense. 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. 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 Q.447 Q.448 Q.449 Q.450 Q.451 Q.452 Q.453 Q.454 Provide text-mode script file tool to create & modify Performance Measurement Jobs. The script file shall can be exported & imported so that one script file can be applied to all Network Elements PM jobs shall still work normally even if parts of counters do not work at current Software version PM jobs shall still work normally even if some Measurement objects do not work normally PM jobs shall still work normally even if some Measurement objects are added, removed or disabled. PM jobs shall provide detailed information of fault and reason in case the job fails. The NMS shall have sufficient capability to receive, store, and process all the PM data. PM data is processed completely into PM database in 5 minutes. O&M tool command response time within 5 sec.

9.13.5.3. Performance Data / Counter Q.455 Q.456 Q.457 Q.458 Q.459 Q.459 A. Q.459 B. Q.459 C. NMS needs to comply the standards with 3GPP TS32.425, 3GPP TS32.426, 3GPP TS32.450, 3GPP TS32.455 of the counters and formulas. Counter value only accumulate value within measurement period, dont accumulate value from the starting time of measurement job. To collection period for event counters and statistics shall be under control of the operator in the range from 15 minutes to 1 hour. Performance counter file support XML or CSV format or TXT format. Performance counter must include following but not limited to: Customer: Registered Customer, Attached Customer. Available: Network element available Accessibility: RRC connection success rate, S1 connection setup success rate, E-RAB setup success rate, attach success rate, service request success rate

Q.459 Retainability: drop cell rate, handover success rate D. Q.459 Throughput: user throughput, network element throughout E. Q.459 F. Quality: Latency, Jitter, Packet Loss. Q.459 G. Q.460 Q.461 Traffic: Traffic loading, Transmit bandwidth Weekly measurement data availability must be over 99% 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.

9.13.5.4. Performance Database Q.462 Q.463 Q.464 Q.465 Q.466 The system shall use the relation / object-oriented database to store and hold the necessary information for the parameters used in the system. Allow user use ODBC and standard SQL to access database Tenderer shall detail the details of the provided database, information of database structure, and database application development software. The NMS / EMS aggregate the raw data into daily table, weekly table, monthly table. 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 Q.468 Q.469 Q.470 Q.471 Q.472 Q.473 Provide performance indicator definition and formula and health range of all measurement counters. Provide sufficient predefined performance reports to cover all the KPI in 3GPP TS32.455 and TS32.450 The predefined reports cover hourly, daily, weekly, monthly report 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. Reporting interface should comply with factory standard and the exported file can be opened with Microsoft Excel Provide Counter Increment / Decrement operation flowchart 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 Q.475 Q.476 Q.477 Q.477 A. Q.477 B. Q.477 C. Q.477 D. Q.477 E. Q.477 F. Q.477 G. Q.478 Q.478 A. Q.478 B. A web reporting application shall be available in NMS. Users shall be able to query on any counter at any object group level on any summary level Users shall be able to combine any counter into any user defined KPI formula. The following performance management data shall as a minimum be supported: Performance data Performance event Event statistics Counters Performance thresholds Measurements Measurement interval The NMS shall as a minimum provide the ability to generate the following reports for evaluating the network performance: Graphical Report Table Report

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

Raw data display Counters display The performance management reports shall be possible to schedule in 15, 30 or 60 minutes interval, daily interval, weekly and monthly interval. 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 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. 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 Q.484 Q.485 9.13.6. Q.486 Q.487 Q.488 Q.489 9.13.7. Q.490 Q.491 Q.491 A. Q.491 B. Q.491 C. Q.491 D. Q.491 E. Q.491 F. Q.491 G. Q.491 H. Q.492 Q.493 Q.494 The buyers would have performance system that measure the performance of the network. Tenderer shall integrate performance data into the buyer system. PM data shall be transferred completely to the buyers integrated performance system in 5 minutes PM data is real-time transferred to the buyers integrated performance system by trigger method. Backup & Recovery Mechanism The NMS / EMS shall provide full Backup / Restore solution including hardware, software and implementa-tion. 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. The NMS / EMS outline full / incremental backup shall not affect the normal operation of the system. The backup policy shall support at least full backup per week and keep backup data 3 months for ISO27001 audit. EMS Operation All kinds of account type of each network element can be managed by single centralized NMS / EMS system The NMS / EMS servers shall provide security management for network administration. The following type of security management function shall include: Identification / Authentication Access Control Command Log Confidentiality Integrity Audit Mechanism Audit Mechanisms Anti-virus solution. Once any system is based on Microsoft Windows operation system, Tenderer shall provide automatic patch update, software management solution. The NMS / EMS shall provide all user access NE log command log, activity log. Each type of log must at least include user account name, access time, NE, name, command data. 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. All access logs and command logs shall keep at least 1 year at NMS / EMS for IOS27001 audit.

9.13.8. Q.495 Q.495 A. Q.495 B. Q.496 Q.497 Q.498 Q.499

EMS / NMS Integration The LTE system NEs shall provide interfaces to the NMS / EMS and the LMTs interface to NMS / EMS The communication links between the NMS / EMS and the LTE system NEs shall be interconnected via industry Standards such as SNMP, the ITU-T Q3 or CORBA interface. Tenderer shall clearly detail the proposed interface and protocol stack for the buyers evaluation. 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 Buyers 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. Tenderer shall provide the consultancy in between NMS / EMS and the Buyers system following factory standard The NMS shall have alarm northbound interface and can be integrated to Buyers TSC NMS. Alarm between NMS and TSC NMS shall be 100% synchronized. Tenderer shall provide consultancy on the integration All the alarm between NMS / EMS and TSC NMS shall be synchronized. All the alarm datas schema & MIB shall be provided for alarm integrated. All of the Configuration datas schema & MIB shall be provided for Buyer operation DB integrated All of the provision datas schema & MIB shall be provided for Buyer operation DB integrated. Provision data include Circuit data, Patch data, Trail data Routing data, E-UTRAN Radio data, IP transport network data etc. 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. Self Organizing Network (SON) integration 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 Buyers LTE NMS. All AAA (Authentication, Authorization and Accounting) must be centralized management by LTE NMS. Tenderer shall provide the con-sultancy on the integration required The SON system shall provide the security control as same as LTE NMS, User ID shall be locked if user type the wrong password for three times, users will be forced to change their password over three months, system administrators have the function to reset the password but can't get users password. The SON system shall provide Web GUI and command line mode interfaces for operation and maintenance. The SON system shall have the ability to track user operation activity. Any users (include administrator) access the platform shall be logged in the SON system and store at least one month. The stored data shall in-clude necessary attributes but not limited to: user identifier, command / responses (executed result), timestamp. The SON system shall provide the function (include the GUI and Command Line Interface) for users to change O&M users password by themselves. The SON system shall provide the function (include the GUI and Command Line Interface) for administrator / root to change password by themselves. If SON system data is stored at more than on location, the database changes must be synchronized across the different sites. 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, The SON system shall have some of the key alarms that system produces to indicate error conditions. Tenderer shall detail the overall test method, including but not limited to: The self-diagnosis functionality

Q.500 Q.501 Q.502 Q.503

Q.504

9.13.9. Q.505

Q.506

Q.507

Q.508 Q.509

Q.510 Q.511 Q.512 Q.513 Q.514 Q.515 Q.515 A.

Q.515 B. Q.516 Q.517 Q.518 Q.519 Q.520 Q.521 Q.521 A. Q.521 B. Q.521 C. Q.521 D. Q.521 E. Q.521 F. Q.521 G. Q.521 H. Q.522 Q.522 A. Q.522 B. Q.522 C. Q.522 D. Q.523

Stress test for function and con-current user session limitation test. 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% Tenderer shall provide automatic online backup of the database, and configuration data, operation system. Tenderer shall provide the function of archiving and purging of log files into external storage / tape backup system. Tenderer shall provide backup solution, including hardware, software configuration and recommendation on backup frequency. Tenderer shall provide the following topics in backup and recovery design. These items shall be provided in detail documents. Protection against permanent data loss. Backup policy definition (DB: online full backup, AP & OS: Incremental). Backup schedule (Daily) Detailed backup procedures. Detailed recovery procedures Backup and recovery test plan. Maintenance of backup hardware. Plan for minimizing Directory downtime in the event of a disaster Tenderer shall provide the health check procedure, let buyer to perform regular healthy check. Daily check procedure Weekly check procedure Monthly check procedure Quarterly Check procedure The SON system shall be designed for fail-safe and malfunction recovery, tis means that server must be able to operate with good redundancy mechanism for hardware and software respectively. The design follows these key principles: Use of reliable components. Redundant components and no single point of failure within the architecture. Parallel architecture for scalability and failover. Automated load balancing and error handling for redundant components. The SON system must have redundancy architecture. Tenderer shall state the offered solution whether 2N or N+1 or HA redundancy architecture. 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 SON system shall provide 24 hours uninterrupted service. 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) Under maximum dimension management of network elements, the SON system average loading cannot over 60% and CPU IO wait cannot over 10%

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

Q.526 Q.527 Q.528

Q.529 Q.530

Tenderer shall provide 30 man-days on job training for SON operation and system administration. 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. A complete set of documentation for system restart shall also be provided. This shall be function oriented and in alphabetical order. Documentation of operations and maintenance shall include: Description of Operations and Maintenance practices. Man-machine commands and functional descriptions. Alarm printout manuals, including indications of alarm classes and recommended problem solving pro-cedures. Fault diagnosis manuals. Routing including: Operation routines Emergency routines (specified in detail)

Q.531

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

Q.533 F. Descriptions of procedures for changing exchange data and cell parameters Q.533 Description of all network supervision functions G. Q.533 Description of database schema H. Q.533 I. Description of API and/or protocol interface with sample call flow Q.533 J. All tables for operation of the equipment shall be delivered ready for use. They shall be arranged in a way that makes them easy to use and easy to change. Q.533 Tables for routing, billing and signaling shall be clearly set out and arranged in a way that makes them easy to use or change. K. 9.13.10. Software and Patch Upgrade or Maintenance 9.13.10. General Requirement 1. Q.534 All hardware elements in eNodeB and RAN that Tenderer provides must have the ability to be upgrade software and patch remotely from OMC. Q.535 Q.536 Q.537 Q.538 Q.539 Q.540 Tenderer shall propose eNodeB Software Upgrade Strategy based on the schedule of Buyers RAN new function requirement. Tenderer shall fulfill all Software Upgrade Procedure required by Buyer Tenderer shall provide Software upgrade related document that required by Buyer, including impact, Data report and Global Problem Reference. 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 Buyers RAN Tenderer must send notice mail and message to buyers online account if any problem and technical note update related to Buyers current and future RAN software version.

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

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

Preparing Phase Lab Trial Phase Live Field Trial Phase Rollout Phase Tenderer shall provide Implementation Plan before kick-off meeting of upgrade project in Preparing Phase. Implementation Plan must include overall schedule, related Test Plan, Rollback Plan, instruction script and all required document addressed in Documentation chapter sector. Tenderer shall provide Lab Trial Report that verified time plan, procedure, script and impact was as expected in Lab Trial Phase Tenderer shall provide Live Field Trial Report that verified all procedure, script, impact and KPI was as ex-pected in Live Field Trial Phase 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 Buyers Software & Patch Upgrade team.

Q.543 Q.544 Q.545 Q.546 Q.547

9.13.10. Documentation 3. Q.548 Tenderer must provide the most updated official hardware, software and maintenance document before software and patch upgrade project start. Q.549 Q.550 Q.551 Q.552 Tenderer must provide detail Impact Report that well describe if any expected impact on service, maintenance or environment. 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 provide detail Global Problem Reference that complete list all Known Problem and related solution with roadmap Tenderer must verify and prove the completeness in Global Problem Reference of target software version via the on-line account provided to Buyer during Preparing Phase.

9.13.10. System Outage & Failure caused by Software and Patch Upgrade 4. Q.553 Tenderer is responsible for related System Outage & Failure during (but not limited) one week KPI monitoring period cause by Software & Patch Upgrade Q.554 Tenderer shall be on-site of any System Outage & Failure within four (4) hours of outage notification and provide required urgent maintenance and outage resolve. Tenderer must assign a team with PM to discuss solution, monitor KPI and report status of System Outage & Failure every day in the meeting of Buyers War Room before system outage be resolved. 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.

Q.555

Q.556

Q.557

9.13.10. Service Downtime during Software and Patch Upgrade 5. Q.558 Tenderer shall provide detail service downtime analysis report that well describes service downtime during Software and Patch Upgrade. Q.559 Q.560 Q.561 Q.562 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.

9.14. Q.563 Q.563 A. Q.563 B. Q.563 C. Q.564 Q.565

User Authentication Based on offered solution and device, Tenderer shall provide: End to end User Authentication / Registration procedure and message flow User Authentication approach, mechanism and involved Standard User Encryption mechanism The offered E-UTRAN solution shall support EPS AKA procedure as specified in TS 33.401 for UE authen-tication. 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. QoS Assurance Tenderer shall detail how to ensure E2E QoS across every network node. Tenderer shall detail the mechanism of admission & congestion control in offered solution. Tenderer shall depict how the Downlink / Uplink MAC scheduler work in offered solution (providing advanced scheduler features for effective resource allocation is a plus) Tenderer shall detail how to ensure the service in: E-UTRAN QoS Transport QoS Core Network QoS Application / service QoS Tenderer shall provide the mapping table for Vertical QoS mapping (i.e. MAC <-> IP <-> Application) Horizontal QoS mapping (i.e. RAN <-> Transport <-> Core)

9.15. Q.566 Q.567 Q.568

Q.569 Q.569 A. Q.569 B. Q.569 C. Q.569 D. Q.570 Q.570 A. Q.570 B.

Q.570 C. Q.571 9.16.

IRAT QoS mapping (i.e. LTE <-> UMTS <-> WiFi) Tenderer shall provide the global reference that how Operator apply QoS for their Marketing or Business promotion (provide three reference cases) Network Security

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

Tenderer shall provide security mechanisms to protect E-UTRAN in below associated network path or in-terface Protect 1. eNodeB: Theft, remove or loss of information and/or other resources: theft of eNodeB hard-ware Protect 1. eNodeB: Disclosure of information: unauthorized access to important information such as the keys, software, and configuration file of the eNodeB Protect 1. eNodeB: Corruption of information: loading invalid software or illegally controlling the eNodeB through the local commissioning Ethernet port Project 1. eNodeB: Interruption of services: launching Denial of Service (DoS) attacks on the eNodeB to make the eNodeB go out of service.

Q.572 Protect 2. Uu interface: Disclosure of information: unauthorized access to important user information by interception of signals on the Uu interface. E. Q.572 F. Protect 2. Uu interface: Corruption of information: accessing the network with a false user identity through simulated Uu signaling Q.572 G. Q.572 H. Protect 3. S1 interface: Disclosure of information: unauthorized access to important user information by interception of data from the transport network Protect 3. S1 interface: Corruption of information: modifying related contents of the data that is inter-cepted on the transport network and accessing the network with forged user identity

Q.572 I. Protect 4. X2 interface: Disclosure of information: unauthorized access to important user information by interception of handover-related data from the transport network Q.572 J. Protect 4. X2 interface: Corruption of information: modifying contents of the handover-related data that is intercepted on the transport network Q.572 Protect 5. OM interface: Disclosure of information: interception of the important eNodeB information that is transmitted over the OM interface K. Q.572 L. Protect 5. OM interface: Theft, removal or loss of information and/or other resources: interception or removal of the important data of the eNodeB by using the OM interface. For example, the interception or removal of the configuration file or version information. This threat is from unauthorized logins followed by unauthorized operations of the system / eNodeB. Q.572 M. Q.572 N. Q.573 Q.573 A. Q.573 B. Q.573 C. Q.573 D. Q.573 E. 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. Protect 5. Clock Server: Corruption or modification of information: attacks from invalid time sources on the eNodeB Tenderer shall comply with below 3GPP security related standards. 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.102: 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security Architecture. 3GPP TS21.103: 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Integration Guidelines. 3GPP TS33.120: 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security Principles and Objectives.

Q.573 F. 3GPP TS33.203: 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Access Security for IP-based services. Q.573 G. Q.573 H. 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.

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

9.16.1. Q.574 Q.575 Q.576 Q.577 9.17. 9.17.1.

Smartphone Signaling & Traffic Handling Tenderer shall provide TSC broadband traffic forecast (ex. GB or TB per year) from 2013 to 2030 based on the Tenderers own study or global reference. Tenderer shall provide latest Market trend of LTE devices, users, and applications. Tenderer shall provide the design guideline, mechanism and solution for Buyers to deal with abrupt increasing Smartphone signaling and traffic. 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. Application & Service General Requirement

Q.578 Q.579 Q.580 9.17.2. Q.581 Q.581 A. Q.581 B. Q.581 C. Q.581 D. Q.581 E. Q.581 F.

From end-to-end performance viewpoint, the Tenderer shall assure the service performance and quality of offered E-UTRAN or UTRAN network (If TSC would have) to deliver the best quality of service for buyers cus-tomers. Tenderer shall support Buyer on the integration of E-UTRAN or UTRAN network and Service Platform if connected and required. Tenderer shall support to tune and optimize the QoS relevant parameters in E-UTRAN or UTRAN (and QoS mapping to other element nodes or layers) based on Buyers network and business requirement. Service Scope & Performance The initial services that require Tenderer to support to ensure E2E performance via E-UTRAN & UTRAN are listed below but not limited to: CSFB, SRVCC and VoLTE Short Message Service (SMS) Multimedia Messaging Service (MMS) Ring Back Tone (RBT) Voice Mail Service (VMS) / Missed Call Alert (MCA) Mobile Position Services (MPS) / Location Service (LCS)

Q.581 Rich Communication Service (RCS) G. Q.581 Evolved Multimedia Broadcast / Multicast Service (eMBMS) H. Q.581 I. Cell Broadcast Service (CBS): including Public Warning Service (PWS) Q.582 Tenderer shall assure the RF and Service performance in offered E-UTRAN and UTRAN network to achieve or be better than the requirement defined in ITU (ITUR M.2134) and 3GPP 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. Regulatory Requirements Tenderer has the obligation & responsibility to support Buyer to fulfill National Communications Commission (NCC) requirement 4G License Responsibility Tenderer shall fully comply the national regulatory requirement for 700MHz / 900MHz / 1800MHz network deployment. 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. 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 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.583

Q.584

9.18. Q.585 9.18.1. Q.586 Q.587 Q.588

Q.589

Q.590

Q.591

Q.592 9.18.2. Q.593

The offered eNodeB should support mobility speed > 350km/hr in open space. Coverage & Population Requirement Tenderer shall provide Buyer the detailed deployment plan to meet NCCs coverage & population require-ment.

Q.594

The network deployment plan and population coverage target per year need to be negotiated and accepted by Buyers to meet NCCs coverage requirement (i.e. 50% population coverage within five years) System Inspection Tenderer shall provide the detailed plan for preparation (i.e. > 250x eNodeB readiness) and pre-test for NCC system inspection Tenderer shall follow the inspection rule detailed in NCCs to fulfill regulatory requirement Tenderer shall support Buyers to pass CIB and NCC inspection. Tenderer shall support Buyers to get Network Construction Permit. Type Approval The offered eNodeB, user terminal and RAN related products shall pass LTE type approval verification in NCC authorized test institute of lab All the offered LTE products to Buyer need to get the national sales permit in Taiwan. The final Contractor has to provide the qualification or certificate of passing type approval to Buyer before network deployment. Lawful Interception 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. Tenderer shall provide associated Lawful Interception (LI) feature supported in RAN to fulfill CIB / MJIB re-quirement. Tenderer shall provide the document of RAN feature description to support LI 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 shall support to deliver a comprehensive LI System Construction Proposal in Chinese for NCC & CIB / MJIB inspection purpose and get approval. Tenderer shall support the implementation and integration with Core Network for LI system according to the requirement of CIB / MJIB Tenderer shall support to provide the test plan and document for CIB / MJIB s LI function inspection. Tenderer shall support the self-evaluation test and official inspection task to pass the CIB / MJIB LI function inspection. Emergency Call (EC) Tenderer shall provide the document of RAN feature to support Emergency Call. Tenderer shall support the implementation and integration with core network for Emergency Call according to the requirement of NCC. Tenderer proposed RAN shall handle the Emergency Call with highest priority, and the Tenderer shall provide the documents to describe the priority processing mechanism. Tenderer shall support to provide the test plan and document for NCCs Emergency Call function inspection. Tenderer shall support to the self-evaluation test and official inspection task to pass NCC EC function in-spection. Public Warning System (PWS) Tenderer shall provide the solution documents of E-UTRAN / UTRAN features to support Public Warning System. Tenderer shall include the PWS feature supported in E-UTRAN / UTRAN in this RFP scope Tenderer shall support the implementation and integration with core network for PWS according to the re-quirement of NCC.

9.18.3. Q.595 Q.596 Q.597 Q.598 9.18.4. Q.599 Q.600 Q.601 9.18.5. Q.602

Q.603 Q.604 Q.605

Q.606 Q.607 Q.608 Q.609 9.18.6. Q.610 Q.611 Q.612 Q.613 Q.614 9.18.7. Q.615 Q.616 Q.617

Q.618 Q.619 Q.620 Q.621 9.18.8. Q.622 Q.623 9.19. 9.19.1. Q.624

The offered solution shall support the Public warning System (PWS) as defined by the 3GPP Ts22.268 The offered solution shall support the Cell Broadcast Service (CBC) as defined by the 3GPP TS23.041 Tenderer shall support to provide the test plan and document for NCCs PWS function inspection. Tenderer shall support to self-evaluation test and official inspection task to pass the NCC PWS function in-spection. User Performance Assurance & Speed Test The final Contractor shall be obligated to assist Buyer achieved the Regulators target of User Performance Assurance & Speed Test Tenderer shall provide the methodology and solution on how to monitor User Performance and Quality. Network Integration General Requirement This chapter stipulates the requirement of future E-UTRAN / UTRAN to integrate with Buyers existing 3G network. As buyers E-UTRAN or UTRAN supplier, the contractor shall have the responsibility and capability to support buyer to complete the network integration to provide best network synergy. Tender shall cover the potential cost to resolve the MVI / IOT open issues with the Buyers existing EPC supplier. (e.g. consultant, protocol analyze, tools) Tenderer is responsible to interconnect, integrate, and perform all related tasks and tests of inter-working and interoperability to ensure a smooth inter-working between the LTE EPC. During the Contract period, in case that any of equipment with associated software or materials necessary for the integration with Buyers LTE EPC is found not listed in the Price Proposal and BOM, Tenderer shall supplement the necessary equipment with associated software or materials as a turnkey solution offered without an y additional charge to the Buyer. Interoperability Test (IOT) 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. MME contains different eNodeB (S1-MME) eNodeB integrates to other MME (S1-MME) S-GW contains different eNodeB (S1-U) eNodeB integrate to other S-GW (S1-U) Inter-Vendor intra-LTE Mobility Tests over X2 Inter-Vendor IRAT Mobility Tests between LTE and UMTS Self-Organizing Network (SON) 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. RNC contains different NodeB (lub) NodeBs integrates to other RNC (lub) SGSN contains different RNC (lu-PS) RNCs integrate to other SGSN (lu-PS) RNC connect to other RNC (lu-r) RNC connect to other LTE S-GW (S12) RNC connect to other MSC (lu-CS) LTE CSFB to U900MHz / U2100MHz

Q.625 Q.626

9.19.2. Q.627

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

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

Q.628 I. Inter-Vendor IRAT Mobility Tests between LTE and UMTS Q.628 J. U900 / U2100 integrate with Self-Organizing Network (SON) Q.629 The offered UTRAN / E-UTRAN solution shall be integrated with designated Core Network and verified in Buyers Lab or Live network before contract to ensure the Interoperability capability with other network elements. The offered UTRAN / E-UTRAN solution shall describe your End-to-End QoS solution & mapping across Core, Transport and RAN network. The offered UTRAN / E-UTRAN solution shall detail how to support and implement SON features across Core and RAN network. 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. Tenderer shall support to integrate with Buyers Public Warning System. Tender shall support to integrate with Buyers LCS system, Buyers SMS system. The offered E-UTRAN solution shall provide S1-MME interface to/and integrate with Buyers MME as speci-fied in 3GPP TS23.401, TS36.300 and TS36.413. The offered E-UTRAN solution shall support MME to delivery NAS message to/from UE as specified in 3GPP TS23.401, TS23.301. 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) The offered E-UTRAN solution shall support LPPa protocol (as specified 3GPP TS36.455) and integrate with E-SMLC via MME 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. The offered E-UTRAN solution shall support X2 handover The offered solution shall detail describe the error handling mechanism while MME node is out of service to provide service continuously. The offered RAN solution shall support the RIM (RAN Information Management) and integrate with Buyers EPC for optimize the CSFB Multi Vendor Integration (MVI) 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 provide the evidence (ex. Certificate of IOT Forum) to prove the MVI / IOT had been suc-cessfully completed. Tenderer shall state the reference site / network scenario for MVI with other vendors. Tenderer shall pass the Buyers MVI activity in Buyers LAB for the Buyers assigned EPC vendors. Tenderer shall provide the list and test detail of successful Network IOT with Tenderers E-UTRAN / UTRAN equipment Tenderer shall provide the list and test details of successful UE IOT with Tenderers E-UTRAN (or UTRAN) via Uu interface. Inter-Radio Access Technology (IRAT) 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 shall provide detailed IRAT message flow, mechanism and global reference (ex. test case, test plan and test results) regarding below IRAT scenarios

Q.630 Q.631 Q.632

Q.633 Q.634 Q.635 Q.636 Q.637

Q.638 Q.639 Q.640 Q.641 Q.642 Q.643 9.19.3. Q.644

Q.645 Q.646 Q.647 Q.648 Q.649 9.19.4. Q.650 Q.651

Q.651 A. Q.651 B. Q.652 Q.653 Q.654

IRAT E-UTRAN to UTRAN (LTE > UMTS) IRAT UTRAN to E-UTRAN (UMTS > LTE) Tenderer shall state the Voice / PS flow under IRAT mobility or handover Tenderer shall state the CSFB / SRVCC / VoLTE message flow and time consuming under IRAT mobility or handover Tenderer shall detail the feature support (Software version & Timeframe) for IRAT mobility and handover based on coverage / loading / environment / distance.

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

Acceptance Test Plan (ATP) Tenderer, under Buyers witness, shall provide & perform Acceptance Test Plan, in Lab first before in live network, with the following tests for each time of upgrade Node Acceptance Test (NAT) System Acceptance Test (SAT) User Acceptance Test (UAT, only in live network) Tenderer shall submit the ATP document to state how to proceed NAT, SAT, and UAT, which shall include the test objects and associated test cases, test methods and steps, test environment and instruments / tools re-quired, test schedule and duration, repeated times per test case, and pass / fail criteria, before the ATP is con ducted. 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. 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. The final Contractor shall be responsible to complete the aforesaid tests through passing all the test cases with the Buyers approval without any additional cost to the buyer. 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. The ATP process in illustrated as the diagram below necessary activities and reports / lists / records. 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. NAT The contractor shall perform the NAT for each and every network element / node offered as per the SA plan signed by Buyer and Contractor. 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. SAT SAT shall consist of Functionality Test and Load Test shall be carried out as follows: Contractor shall coordinate with the Buyer for commencement of the Functionality Test after completion of the Works. If the NCC & CIB/MJIB inspection is required for the Works, the Buyer will then apply for the NCC & CIB/MJIB Inspection with the Contractors support after Functionality Test. The Contractor and the Buyer shall then jointly commerce the Load Test for one week after the NCC & CIB/MJIB inspection, or directly after Func-tionality Test if NCC & CIB/MJIB inspection is not required. 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.

Q.657 Q.658 Q.659

Q.660

Q.661 Q.662 9.20.1. Q.663 Q.664

9.20.2. Q.665 Q.666

Q.667

9.20.2.1. Functionality Test Q.668 Q.669 Q.670 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.

9.20.2.2. Load Test Q.671 Q.672 The Buyer will decide and inform the Contractor of the date for the Load Test after the Functionality Test is Pass During the Load Test, real or simulated traffic shall be loaded onto the LTE-UTRAN (or UMTS UTRAN) & Core Network nodes to prove the performance of the offered LTE E-UTRAN (or UMTS UTRAN) to meet the requirement on continuous operation under traffic loaded for one week

Q.673

If major faults such as inter-working problems between the offered LTE E-UTRAN (or UMTS UTRAN) and the Buyers existing systems, other operators mobile and fixed networks are found, all of the which adversely affect the system operation, the Contractor shall repeat the Load Test for another one weeks at his expense after the faults have been cleared. The system will be deemed as having failed the Load Test unless major faults have been cured. 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. Test Tools for Field Measurement General Requirement This section includes tools for 3G and 4G Network related requirement; Tenderer shall provide tools as below, but not limit to 3G and 4G Radio Network planning tool. Field Measurement / Drive-Test Tool Miscellaneous Tool Requirement Tenderer provided tools shall have general requirement as below but not limit. Support technologies LTE FDD measurement 3G (3.5G) measurement Wi-Fi measurement Others The RAN tool shall measures service quality directly from different types of devices and provide number of tools (include Buyers Lab needs) as below: Portable tools: Smartphone (Android & iOS & others) Tablet (Android & iOS & others) Outdoor Drive Test Tool with LTE Data card & LTE Phone Modulized Outdoor Drive Test Tool with LTE Data card & LTE Phone Scanning receiver External GPS Other (i.e. accessory)

Q.674

9.21. 9.21.1. Q.675 Q.675 A. Q.675 B. Q.675 C. Q.676

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

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

Q.678

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

Q.679 Q.680 9.21.4. Q.681 Q.682 Q.683 Q.684 Q.684 A. Q.684 B. Q.684 C. Q.684 D. Q.684 E. Q.684 F.

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, The RAN tools shall include post-processing analysis system. Radio Network Planning Tool Tenderer shall provide the radio network planning tool in each region (i.e. 4 for each region and 1 in head quarter) Tenderer shall introduce and train buyer how to use the tool The radio networking planning tool shall include but not limited 3G, 4G, and beyond 4G The radio network planning tool shall include but not limit Supports Evolved UTRA (3GPP Release 10 LTE Advance) Networks Various frequency bands Scalable channel bandwidths Resource blocks per channel and sampling frequencies FDD and TDD frame structures Half-frame / Full-frame switching point periodicities for TDD

Q.684 Normal and extended cyclic prefixes G. Q.684 Downlink and uplink control channels and overheads (Downlink and uplink reference signals, P-SCH, S-SCH, PBCH, PDCCH, PUCCH, etc) H. Q.684 I. Physical cell IDs Q.684 J. Signal level based coverage planning Q.684 CINR based coverage planning K. Q.684 L. Network capacity analysis using Monte Carlo simulations Q.684 M. Q.684 N. Q.684 O. Q.684 P. Q.684 Q. Q.684 R. Q.684 S. Q.684 T. Q.684 U. Q.685 Q.686 Q.686 A. Q.686 B. Q.686 C. Q.686 D. Q.686 E. Q.686 F. 9.21.5. Scheduling and resource allocation in two-dimensional frames Multiple Input Multiple Output (MIMO) systems Transmit and Receive Diversity Single-User MIMO (Spatial Multiplexing) Adaptive MIMO Switch (AMS) Multi-User MIMO (Collaborative MIMO) in uplink Automatic allocation of neighbors, physical cell IDs, and frequencies (AFP) (optional) Network verification possible using test mobile data Tenderer shall help buyer to run the simulation based on the NCC requirement The radio planning tool shall be able to input buyer existing drive tool and output the result based on buyer requirement The planning toll have to support Multi-RAT planning and below functions in a unified GSM / UMTS / LTE network Database with site and antenna sharing. Multi-service traffic model Monte-Carlo simulator Display UMTS and LTE networks simultaneously Automatically allocate neighbors between UMTS and LTE network Support inter-technology interference analysis Field Measurement Tool

Q.687 Q.687 A. Q.687 B. Q.687 C. Q.687 D. Q.688 Q.689 Q.690 Q.691 Q.691 A. Q.692 Q.692 A. Q.692 B. Q.692 C. Q.692 D. Q.693 Q.693 A. Q.693 B. Q.693 C. Q.693 D. Q.693 E. Q.693 F. Q.693 G. Q.693 H. Q.694 Q.694 A. Q.694 B. Q.694 C. Q.695 Q.695 A. Q.695 B. Q.696 Q.696 A. Q.696 B. Q.697 Q.698

Tenderer RAN tool shall measures service quality directly from different type of devices as below but not limited: Smartphones (Android & iOS) Tablet (Android & iOS) Modulized Outdoor Drive-test Tool Non-Modulized Outdoor Drive-Test Tool (Mobile / Dongle direct connected) The RAN tool shall instantly delivery LTE and 3G QoE insight to tablet or laptop in real-time. 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. The RAN tool shall measure times and KPIs as below but not limited: Support technologies: LTE FDD / TDD measurement The RAN tools shall Support test UEs Mobile Phone Data Card Scanning Receiver External GPS The RAN tool shall Support to edit script and repeat the following test items: FTP DL / UL HTTP DL / UL for data transfer. ICMP Ping Web browsing Video Streaming (RTSP) Youtube streaming (HTTP) VoIP call (Voice Quality) IP capture The RAN tool shall Support benchmarking test. Support at least 4 operators networks benchmarking and measure 4 operators network KPI at same time. 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. Support scanning receiver test The RAN tool shall support forcing features. System lock (lock to LTE FDD / TDD) Band lock (Lock to LTE FDD / TDD specific band such as 700, 900, 1800, 2100, 2600 MHz) The RAN tool shall support outdoor (Mobility) / indoor (Stationary) measurement. Support MapInfo for outdoor map. Support BTS file into show on map. The RAN tool shall support CSFB and VoLTE test (Voice Quality) The RAN tool shall support KPIs measurement.

Q.698 A. Q.698 B.

Cell Measurement (for each cell): Band Chanel number (EARFCN) Physical cell identity RSSI RSRP RSRQ Current Cell information: Chanel number (EARFCN) Cell identity Tracking area code MCC / MNC MME group ID MME code M-TMSI RRC state Cell bandwidth Transmission mode Automatic neighbor relations (ANR) CGI reporting TDD DL / UL configuration Detected antenna port Service status CQI: Wideband CQI per codeword Subband CQI per codeword Requestdt rank. Signaling message: RRC message NAS message

Q.698 C.

Q.698 D.

Q.698 E.

Physical channel information: PDSCH throughput PDSCH BLER PUSCH throughput PUSCH TX power LTE precoding matrix indicator (PMI) SNR

Q.698 F. Link adaptation (for one modulation / PRB allocation per sample duration): PDSCH / PCSCH rank PDSCH / PCSCH modulation and MCS per codeword PDSCH / PCSCH PRB allocation PDSCH / PCSCH DTX TTIs Q.698 G. RACH parameters: RACH type RACH reason. RACH result RACH access delay RACH contention resolution failures RACH preamble count RACH preamble initial TX power RACH preamble index Cell reselection / handover / tracking area parameters: Cell reselection event Handover events (attempt / success / failure) Handover type Tracking area update events (attempt / success / failure) Tracking area update type Tracking area update failure cause Handover duration

Q.698 H.

Q.698 I. LTE measurement event Event A1 ~ A5 Event B1, B2

Q.698 J. Scanning receiver parameters RSRP RSRQ CINR Antenna port Ch / PCI Decode BCCH info (SIBs Cell id) 9.21.6. Q.699 4G Lab Requirement Tenderer shall provide one LTE RAN system including OAM and SON feature for Buyers Lab. LTE RAN Network shall include but not limited to the following elements and functions as the same with Live system: 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) NTP with GPS OSS SON Antenna & Accessory (attenuator, splitter ) MSR IRAT / CSFB 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 Buyers Lab. LTE RAN Network shall include but not limited to the following elements and functions as the same with Live system: RNC Node B (at least 2 sets for different type including Macro, Remote and SmallCell with 3 sectors). EMS or OSS Antenna & Accessory (attenuator, splitter ) MSR Tenderer shall list the required Hardware, Software and Service item in the BOM for buyers approval. 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. 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. The eNodeB shall provide the CA (Carrier Aggregation) as the same with live and support Frequency band combination and Bandwidth Combination for CA. The eNodeBs frequency and bandwidth shall be the same with live system and list as following Band 3 (1800 MHz FDD mode) for UMTS / LTE Band 8 (900 MHz FDD mode) for UMTS / LTE Band 28 (APT700 FDD mode) for LTE

Q.699 A. Q.699 B. Q.699 C. Q.699 D. Q.699 E. Q.699 F. Q.699 G. Q.700

Q.701 Q.701 A. Q.701 B. Q.701 C. Q.701 D. Q.701 E. Q.702 Q.703

Q.704 Q.705

Q.706 Q.706 A. Q.706 B. Q.706 C.

Q.706 D. Q.707 Q.707 A. Q.707 B. Q.708 Q.709 Q.710

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 The NodeBs frequency and configuration shall be the same with live system and list as following 900MHz (Band 8) for 2 + 2 + 2 configuration 2100MHz for 3 + 3 + 3 configuration Tenderer shall provide 2x2 MIMO equipment for above LTE & 3G RAN system and they are for future 4x4 reuse and expandable. Tenderer shall provide complete SON function with OSS system which is the same with live system 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 with Buyers existing lab 3rd party LTE EPC system. Tenderer shall successfully integrate the 3G RAN system with Buyers existing Lab LTE EPC system for i-RAT / CSFB capability. Tenderer shall successfully integrate the LTE RAN system with Buyers existing 3G network for i-RAT / CSFB capability and Wi-Fi system for traffic offload available. (Optional) Tenderer shall successfully integrate the 3G RAN system with Buyers existing lab 3G network and Wi-Fi system for traffic offload availability Tenderer shall include Labs acceptance as part of live network acceptance. Tenderer shall provide the Lab Project Plan including but not limited to the scope, schedule, for the Buyers approval. Tenderer shall provide the Lab engineering plan including but not limited to network architecture and MoP and shall be updated upon the changes of the plan within one week for the Buyers approval Tenderer shall provide the Lab acceptance test plan including but not limited to NAT, SAT for buyers ap-proval. 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. Technical Documentation General Requirements Documentation is defined as all necessary written and visual documentation fro the offered RAN equipment and associated training that final Contractor have to deliver to Buyers when shipping equipment. The docu-mentation shall contain sufficient details, presented clearly and concisely, to enable the Buyers personnel to operate and maintain the system in an efficient and correct manner. The documentation shall be provided both in electronic from (CD-ROM / diskette) and paper (hard copy) as needed and requested by the Buyer. The Tenderer shall provide a minimum of 5x printed copies and 10x CD-ROM of all documentation. The buyer reserves the right to copy the documentation for its own use. All text in documentation shall be typed. The timing for documentation delivery should be stated in provided Project Plan and be granted by Buyer Documentation Language

Q.711

Q.712 Q.713 Q.714

Q.715 Q.716 Q.717 Q.718

Q.719 Q.720

Q.721

9.22. 9.22.1. Q.722

Q.723 Q.724 Q.725 Q.726 Q.727 9.22.2.

Q.728 Q.729 Q.730 9.22.3.

All documentation shall be provided in English or Chinese. All terms and abbreviations shall be in accordance with international standards, when existing. The Tenderer shall provide the document in Chinese for those regulatory requirements requested by NCC or Government departments. Documentation Composition

9.22.3.1. System Survey Q.731 The system survey is the high level part of documentation and describes the main functions and components of the equipment. The system survey shall contain, among other items, survey drawings and general descriptions of the system and shall contain references to move detailed descriptions.

9.22.3.2. Installation Documentation Q.732 In additional to paper and CD-ROM copies of installation documentation, the Tenderer shall also supply electronic copies of floor plans and diagrams in Computer Aided Design (CAD) from and grant to the Buyer permission to allow architects of sites to use such CAD diagrams in their architectural design of site locations. Architects will be obliged to sign non-disclosure agreements covering such information. Installation Drawings Floor plans Assembly drawings Cabling plans / wiring drawings Cable route lists Cable connection schematics Bay connection diagram Rack connection diagram Power supply diagram Test instructions / procedures Test points with indication of normal values Recommended measuring equipment Measuring procedures

Q.732 A.

Q.732 B.

Q.732 C. Q.732 D.

9.22.3.3. Hardware Documentation Q.733 The hardware documentation shall contain diagrams, drawings, and descriptions of all hardware and It shall be easy to use. There shall be a table of contents and complete list and index of all diagrams, drawings, and figures for each set of documentation. The following shall be included in the documentation: Survey schematics and module descriptions Functional diagrams Block diagrams Logic diagrams Top-level diagram System diagram Other top-level diagrams

Q.734 Q.734 A. Q.734 B.

Q.734 C.

Q.734 Floor layout plan D. Q.734 Layout plan showing the position of the units within the racks E. 9.22.3.4. Software Documentation Q.735 The software documentation listed below shall be regarded as a minimum. The buyer reserves the right to require more detailed documentation when needed.

Q.735 A.

Software feature list with indication as follows: Basic or optional Purchased or not-purchased Enabled or not enabled Correlation with other necessary features to together fulfill specific functionality

Q.735 Provide feature description (word format) of every software feature whichever is purchased / not-purchased, enable / not-enabled, or basic / optional B. Q.735 Provide total basic and optional list (excel format) for recommended SW version and future version of feature / roadmap with two years. C. 9.22.3.5. Operations and Maintenance Documentation Q.736 Q.737 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. A complete set of documentation for system restart shall also be provided. This shall be function oriented and in alphabetical order. Documentation for operations and maintenance shall at least include: Paper and electrical manual with on-line help instructions Trouble shooting manual, standard process and necessary tools Users manual for each type of equipment monitored by the OMC or NMC Man-machine commands and functional descriptions of these Alarm printout manuals, including indications of alarm classes Fault diagnosis manuals Routines including: Operation routines Emergency routines (specified in detail)

Q.738

Q.739 Q.740 Q.740 A. Q.740 B. Q.740 C. Q.740 D. Q.740 E. Q.740 F. Q.740 G.

Q.740 Descriptions of procedures foe changing system configuration data H. Q.740 I. Description of how traffic measurements are derived and what data is presented to user Q.740 J. Description of all network supervision functions Q.741 Q.742 Q.743 Q.744 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. Tables for routing, billing and signaling shall be clearly set out and arranged in a way that makes them easy to use or change. The Tenderer shall provide: Hardware Service Unit List (SUL) The Tenderer shall provide: Spare Part List

9.22.3.6. System Dimensioning and Parameters Q.745 Documentation shall be available for dimensioning rule or principle, dimensioning or radio tuning parameters, system limitations, and procedures for changing system configuration caused by extensions of the equipment or introduction of new facilities / functions.

9.22.3.7. Training Documentation Q.746 Course documents from basic level to specialist level in hardware, software, system planning, installation, operations and maintenance, and testing shall be provided.

9.22.3.8. Documentation Delivery Time Q.747 The Contractor shall offer in a timely manner all necessary manuals and drawings for the system to be de-livered. Unless otherwise agreed upon on an individual basis, the documentation shall be delivered as described in the table that follows:

9.22.3.9. Requirements for Updating Documentation Q.748 In the event of physical or functional revisions or changes in the system, the revised document to reflect the system revisions / changes shall be supplied by the Tenderer no later than 1 month after the revisions / changes are done. The synchronization performance shall be tested and accepted by the Buyer with test result in live network Evolved Packet Core (EPC) Technical Requirement Evolved Packet System (EPS) Architecture The Tenderer shall provide the logical architecture for 3GPP access of its overall EPC solution for non-roaming and roadmap scenarios The Tenderer shall provide the logical architecture for secure interworking with trusted and un-trusted non-3GPP access with the proposed overall EPC solution.

Q.749 10 10.1. Q.750 Q.751

10.2. Q.752 Q.753 10.3. Q.754

Evolved Packet Core (EPC) Roadmap The Tenderer shall provides its software detailed product development plans fro the MME and S-GW / P-GW. The Tenderer shall provides its hardware detailed product development plans for the MME and S-GW / P-SW. Evolved Packet Core (EPC) IOT Experience The Tenderer shall provide the details successfully performed interoperability test (IOT) of 3GPP reference point.

Q.755

The Tenderer must commit to supporting initiation IOT testing for the relevant 3GPP reference points as well as long term commercial support of multi-operator, inter-operability and on-going testing required as new soft-ware versions are release by other Vendors. MME Functional Requirement 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. Hardware and Software Requirements The Tenderer shall provide a description of MME hardware platform. The Tenderer shall indicate the maximum capacity of the MME. The Tenderer shall indicate if each board is a plug-in unit for the node. The Tenderer shall describe the redundancy techniques supported by plug-in units.

10.4. Q.756 Q.757 Q.758 Q.759 Q.760 Q.761

Q.762

The Tenderer shall list single point of failure (SPOF), and will detail and explain how SPOFs are prevented. The Tenderer will also identify the impact on the user traffic. The Tenderer shall describe the dimensions of the MME chassis. The Tenderer shall explain how the high availability of MME platform is ensured. The Tenderer shall indicate how the context and session continuity are maintained after the failure of hardware component in the proposed MME equipment. The Tenderer shall list down the supported environment standards by the MME equipment. 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 which middleware / operating system is used in the MME software. The Tenderer shall present an overview description of the MME software architecture. The Tenderer will describe the main software module functions. The Tenderer shall provide the description of the minimum configuration platform. The Tenderer shall provide the description of the maximum configuration platform. The Tenderer shall explain how the scalability of its overall solution is ensured. The Tenderer will describe how 99.999% availability could be ensured with its solution. The Tenderer will provide high availability figures (MTBF, MMTR) for the MME system configuration. The Tenderer shall support the fail-over / switch-over mechanisms. The Tenderer shall describe power distribution on the chassis with DC power supply. 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 Tenderer shall provide the details of functional units which support load balancing or load sharing. The Tenderer shall support the redundancy and recovery mechanism used by the MME. The Tenderer will describe the different software failure and / or restart levels of the node The Tenderer will give the duration of service interruption in the case of a node restart. The Tenderer shall support the overload protection mechanism used in the case of overload situations. The Tenderer will detail how new user transactions are processed in case of traffic overload. The Tenderer shall specify the capacity and performance of its MME and HW flexibility. 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 proposed MME shall support S1-MME reference point toward E-UTRAN based on S1-AP / SCTP. The proposed MME shall support NAS signaling with the UE. 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. The proposed MME shall support S6a reference point towards HSS for transfer of subscription and authentication data based on Diameter / SCTP protocol. The proposed MME shall support S13 reference point towards EIR for ME identity check based on Diameter / SCTP protocol as optional.

Q.763 Q.764 Q.765 Q.766 Q.767

Q.768 Q.769 Q.770 Q.771 Q.772 Q.773 Q.774 Q.775 Q.776 Q.777

Q.778 Q.779 Q.780 Q.781 Q.782 Q.783 Q.784 Q.785 Q.786 Q.787 Q.788 Q.789 Q.790

Q.791

The proposed MME shall support S10 reference point towards another MME for relocation and MME-to-MME information transfer based on GTP-C / UDP protocol. The proposed MME shall support S11 reference point towards SGW based on GTP-C / UDP protocol. The proposed MME shall support SGs reference point towards legacy network VLR based on SGs-AP / SCTP protocol. The proposed MME shall support Sv reference point towards legacy network MSC based on GTP-C / UDP protocol. The proposed MME shall support SLg reference point towards legacy network GMLC for location based services. The proposed MME shall support SLs reference point towards legacy network E-SMLC for location based services. The proposed MME node shall support 3GPP defined standard interfaces. The proposed MME shall support non-roaming architecture. The proposed MME shall support roaming architecture for Home Routed traffic. The proposed MME shall support roaming architecture for Local Breakout. The proposed MME shall be able to inter-work with Release 7 SGSN. The proposed MME shall be able to inter-work with Release 8 SGSN. The proposed MME shall support CS Fallabck (CSFB) for SMS. The proposed MME shall support CS Fallback (CSFB) for voice. The proposed MME shall support UEs with IMS voice PS session The proposed MME shall support Sv interface for SRVCC The proposed MME shall support MOCN. The proposed MME shall support MORAN feature and describe any impact on the MME. The proposed MME shall support MME pool area. The proposed MME shall support Globally Unique MME identifier (GUMMEI) The proposed MME shall support overload procedure on S-1 interface. The Tenderer will describe how overload in the signaling-plane is prevented. The Tenderer shall describe how overload is handled if it occurs in the element. The Tenderer shall describe how overload would affect the gateway, its sessions and the interaction with other nodes. The Tenderer will detail what actions are taken toward new user transactions in case of traffic overload in the PGW. The proposed MME shall support emergency services in overload condition. The proposed MME shall support load balancing in the network by providing appropriate weight factor to the eNodeB. The proposed MME shall support the selection of a PDN-GW as specified in TS23.401. The proposed MME shall support the selection of and S-GW as specified in TS23.401. Describe the PDN-GW selection procedure supported by the MME. Describe the S-GW selection procedure supported by the MME. The proposed MME shall support the SGW selection procedure under the S1-Flex architecture with multiple S-GW in the MME pool. 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.792 Q.793 Q.794 Q.795 Q.796 Q.797 Q.798 Q.799 Q.800 Q.801 Q.802 Q.803 Q.804 Q.805 Q.806 Q.807 Q.808 Q.809 Q.810 Q.811 Q.812 Q.813 Q.814 Q.815 Q.816 Q.817 Q.818 Q.819 Q.820 Q.821 Q.822 Q.823

Q.824 Q.825

The proposed MME shall select a SGW based on network topology and Weight Factor of SGW The proposed MME shall support PDN type IPv4, IPv6 and IPv4v6 to UE.

Q.826 Q.827 Q.828

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

Q.829 Q.830 Q.831 Q.832 Q.833 Q.834 Q.835 Q.836 Q.837 Q.838 Q.839 Q.840

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 simultaneous multiple PDN connectivity to one or multiple PDNs. The maximum value shall be configurable. 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 support EPS-AKA as the authentication and key agreement procedure. The proposed MME shall support authentication and key agreement in compliance with 3GPP TS33.401. The proposed MME shall support user identity confidentiality by supporting M-TMSI. The proposed MME shall support user data and signaling confidentiality by supporting ciphering and integrity to NAS signaling. The proposed MME shall be able to select NAS Integrity Protection and Ciphering algorithm(s). The proposed MME shall support ME identity check procedure. The proposed MME shall support intra-RAT security context transfer 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.841 Q.842 Q.843 Q.844 Q.845 Q.846 Q.847 Q.848 Q.849 Q.850 Q.851 Q.852 Q.853 Q.854

The proposed MME shall support security context transfer to/from GERAN and UTRAN in compliance with 3GPP TS23.401. The proposed MME shall support the AS security mode command procedure as defined in TS33.401. The proposed MME shall support the NAS Security Mode Command procedure as defined in TS33.401. 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. The proposed MME shall support the ability to request a UE to provide its IMEI in the NAS Security Mode Complete message. If APN provided by UE corresponding to a PDN for a PDN connection is not subscribed then the proposed MME shall reject attach procedure. The proposed MME shall support GUTI allocation and reallocation. The proposed MME shall support allocation and reallocation of Tracking Area Identity list. The proposed MME shall support Tracking Area Update (TAU) Procedures with / without SGW change. The proposed MME shall support Tracking Area Update (TAU) with / without MME change. The proposed MME shall support Routing Area Update with MME interaction and with / without SGW change. The proposed MME shall release all EPS bearers corresponding to a default bearer if that default bearer is not accepted by the eNodeB. The proposed MME shall support eNodeB and MME initiated S1 release procedure. The proposed MME shall support UE-initiated detach procedure with / without ISR activated.

Q.855 Q.856 Q.857 Q.858 Q.859 Q.860 Q.861 Q.862 Q.863 Q.864 Q.865 Q.866 Q.867 Q.868

The proposed MME shall support implicit as well as explicit MME-initiated detach procedure. The proposed MME shall support SGSN-initiated detach procedure. The proposed MME shall support HSS-initiated detach procedure. The proposed MME shall deactivate all the non-emergency PDN connection in case of HSS-initiated detach procedure. The proposed MME shall support Purge Function to inform HSS about the deletion of subscription data. The proposed MME shall support for mapping between EPS and pre Release-8 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 dedicated bearer activation procedure. The proposed MME shall support PGW initiated bearer modification with & without bearer QoS update. The proposed MME shall support HSS initiated subscribed QoS modification with bearer QoS update. The proposed MME shall support PGW initiated bearer de-activation. The proposed MME shall support UE requested bearer resource modification. The proposed ME shall support restoration and recovery procedures. 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. 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. The MME shall support Lawful Interception in accordance with 3GPP TS33.107 The proposed MME shall support LI architecture for signaling and data path interception. The proposed MME shall support ENB Configuration Transfer procedure. The proposed MME shall support MME Configuration Transfer procedure. The proposed MME shall support addressing, routing and relaying functionality. The proposed MME shall be fully transparent fro Configuration Transfer procedure. The proposed MME shall support MME to 3G SGSN combined hard handover and SRNS relocation pro-cedure. The proposed MME shall support 3G SGSN to MME combined hard handover and SRNS relocation pro-cedure. The proposed MME shall support Gn / Gp SGSN to MME Tracking Area Update. The proposed MME shall support mapping between EPS and release 99 QoS parameters. The proposed MME shall support Paging for non-EPS services procedure. The proposed MME shall support Location update for non-EPS services procedure. The proposed MME shall support Non-EPS alert procedure. The proposed MME shall support Explicit IMSI detach from EPS services procedure The proposed MME shall support Explicit IMSI detach from non-EPS services procedure. The proposed MME shall support Implicit IMSI detach from non-EPS services procedure. The proposed MME shall support following procedures:

Q.869 Q.870 Q.871 Q.872 Q.873 Q.874 Q.875 Q.876 Q.877 Q.878 Q.879 Q.880 Q.881 Q.882 Q.883 Q.884 Q.885 Q.886

Q.886 A. Q.886 B. Q.886 C. Q.886 D. Q.886 E. Q.886 F. Q.887 Q.888 Q.889 10.5. 10.5.1. Q.890 Q.891

VLR failure procedure MME failure procedure HSS failure procedure MM information procedure NAS messages tunneling procedure Service request procedure 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 proposed MME shall support SBc interface for information with Cell Broadcasting Center (CBC) S/P-GW Functional Requirements General Requirement The Tenderer shall provide the logical architecture of its S/P GW product. 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 provide a description of the hardware platform used to implement its S/P-GW functionality. 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 indicate the type of external interfaces supported by S/P-GW The Tenderer will indicate if each board is a plug-in unit for the node. The Tenderer shall describe the redundancy techniques supported by plug-in units. 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. 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. The Tenderer shall describe the dimensions of the S/P-GW chassis. The Tenderer shall list down the supported environmental standards by the equipment The Tenderer will indicate which middleware / operating system is used in S/P-GW software The Tenderer will present an overview description of the S/P-GW software architecture. The Tenderer will describe the main software module functions. The Tenderer will indicate the number of boards dedicated to the administrative tasks of the node. 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 provide the description of the minimum configuration platform. The Tenderer will provide the description of the maximum configuration platform. The Tenderer will detail what are the operations to scale from minimum to maximum configuration. The Tenderer will explain how the scalability of its overall solution is ensured. The Tenderer will provide high availability figures (MTBF) for the S/P-GW node.

Q.892 Q.893

Q.894 Q.895 Q.896 Q.897

Q.898 Q.899 Q.900 Q.901 Q.902 Q.903 Q.904 Q.905 Q.906 Q.907 Q.908 Q.909

Q.910 Q.911 Q.912 Q.913

The Tenderer will describe how 99.999% availability could be ensured with its solution. The Tenderer will define the network requirements of PGW pool to perform service continuity. The Tenderer will define the network requirements of SGW pool to perform service continuity. 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 will describe the replication mechanisms that are implemented within its solution. The Tenderer shall describe power distribution on the chassis with DC power supply. 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 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. The Tenderer shall describe the redundancy and recovery mechanism used by the S/P-GW. The Tenderer will describe the different software failure and/or restart levels of the node. The Tenderer will give the duration of service interruption in the case of a node restart. The Tenderer will describe the overload protection mechanism used in the case of overload situations. The Tenderer will detail how new user transactions are processed in case of traffic overload. The Tenderer shall specify the capacity and performance of its S/P-GW and HW flexibility The Tenderer will provide what is the capacity in terms of packet per second forwarding with mean packet size? 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. The Tenderer shall state the number of rules that can simultaneously be activated for one user. The Tenderer shall state the number of filters that can be stored in the PGW. 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. The S-GW shall support GTPv2-C protocol to carry signaling messages between S-GW and S-GW over S5/S8 interface. The S-GW MAY support PMIPv6/PMIPv4 protocol between S-GW and S-GW over S5/S8 interface. The S-GW shall support GTPv2-C protocol to carry signaling messages between MME and S-GW over S11 interface. The S-GW shall support GTPv1-U protocol to carry bearer packet between SGSN and S-GW over S4 in-terface. 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. 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.914 Q.915 Q.916 Q.917 Q.918 Q.919 Q.920 Q.921 Q.922 Q.923 Q.924 Q.925 Q.926 Q.927 Q.928 Q.929 Q.930 Q.931 Q.932 Q.933

Q.934

Q.935 Q.936 Q.937 Q.938 Q.939 Q.940 Q.941

The P-GW shall support S5 and S8 interface over GTP protocols. The P-GW MAY support S8 interface over PMIPv6 protocol. The P-GW shall support S2a interface over PMIPv6 protocol for trusted non-3GPP IP access. The P-GW shall support S2b interface over PMIPv6 protocol for un-trusted non-3GPP IP access. The P-GW shall support S6b interface over Diameter or RADIUS protocol to communicate with AAA server for user authentication and IP address allocation. The P-GW shall support Gy interface over Diameter protocol for OCS. The P-GW shall support Gz interface over Diameter protocol for OFCS.

Q.942 Q.943 10.5.2. Q.944 Q.945 Q.946 10.5.3. Q.947 Q.948 Q.949 Q.950 Q.951 Q.952 Q.953 Q.954 Q.955 Q.956 Q.957 Q.958 Q.959 Q.960 Q.961 Q.962 Q.963 Q.964 Q.965 Q.966 Q.967 Q.968 Q.969 Q.970 Q.971

The P-GW shall support SGi interface over Application protocol over IP. The P-GW shall support Gn/Gp interface over GTP protocol for pre-release 8 SGSN. Physical Interface Requirement The S/P-GW shall provide Gigabit optical and electrical interfaces. The S/P-GW may provide 10 Gig optical interfaces. The S/P-GW shall provide separate physical interfaces for control traffic and data traffic. P-GW Functionality and Feature Requirements The P-GW shall support IPv4 address allocation and IPv5 parameter configuration. The P-GW shall support IPv6 / IPv4 address allocation to UE via default bearer activation. 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. The P-GW shall support IPv4 address release and renewal for a UE The P-GW shall support IPv6 address release and renewal for a particular UE. 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. The P-GW shall support allocation of static IPv4 address and/or a static IPv6 prefix based on subscription data in the HSS. The P-GW shall function as a RADIUS Client towards Radius Server if IP allocation to the UE is via RADIUS procedure. The P-GW shall function as a DIAMETER Client towards DIAMETER Server to allocate IP address to the UE is via DIAMETER procedure. The P-GW shall support static routing functionality. The P-GW shall support dynamic routing functionality, please specify which routing protocols are supported by the element. The P-GW shall support access control list (ACL) feature. The P-GW shall support MPLS / BGP feature. The P-GW shall support GTP tunnel on S5 / S8 interface. The P-GW shall support separate GTP tunnel for default bearer and for each dedicated bearer per user on S5 / S8 interface. The P-GW MAY support GRE tunnel on S8 interface. The P-GW shall support GRE tunnel on S2a interface. The P-GW shall provide GRE tunnel on S2b interface. The P-GW shall support GRE encapsulation applicable for PMIPv6. The P-GW shall support user plane tunneling and tunnel management over S5 interface. The P-GW shall support GPRS Tunneling Protocol for the control plane (GTP-C) over S5 / S8 interface. The P-GW shall support GPRS Tunneling Protocol for the user plane (GTP-U) over S5 / S8 The MTU size in P-GW shall be configurable through man-machine interface.

Q.972 Q.973 Q.974 Q.975 Q.976 Q.977 Q.978 Q.979 Q.980 Q.981 Q.982 Q.983

The configuration of MTU in P-GW shall not be service affected. 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. The P-GW shall support congestion control and congestion avoidance policies. The P-GW shall perform admission control even for non-GBR bearer. 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. The P-GW shall support providing VPN / VPLS services to enterprise operators. The P-GW shall support IPSec based enterprise VPNs. The P-GW shall support L2TP based enterprise VPNs. The P-GW shall support GRE based enterprise VPNs. The P-GW shall support MPLS based enterprise VPNs. The P-GW (PCEF) shall use the DL TFT for mapping traffic to an EPS bearer in the downlink. 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 Q.985 Q.986 Q.987 Q.988

The P-GW (PCEF) shall support Deep Packet Inspection feature. The P-GW (PCEF) shall support appropriate configuration of DPI rule sets the applicability subscrib-er-association of which can be controlled from PCRF. The P-GW shall support IPv6 DPI functions. The P-GW shall support stateful L3 L7 DPI capabilities. The P-GW (PCEF) shall provide appropriate configuration framework which allows administrator to specify customized DPI rules based on following criteria: Layer4 protocol (i.e. TCP, UDP), Layer-4 ports (list and ranges of sources and destination, ports), Layer-7 protocol, HTTP host list or URL list for HTTP-based layer-7 protocols. Please provide the list of protocols and applications which can be detected using DPI. 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. The Tenderer MUST commit to 90% detection usage in term of bandwidth, number of sessions, number of sessions / sec. The solution MUST support heuristic detection. Please explain the procedure of upgrade and the impact in term of availability. The P-GW shall provide the feature of Personal Firewall The P-GW shall act as the user plane anchor for mobility between 3GPP access and non-3GPP access. For PMIP-based S5 interface, the P-GW shall act as a LMA according to the PMIPv6 specifications. For PMIP-based S8 interface, the P-GW shall act as a LMA according to the PMIPv6 specifications. The P-GW shall support bearer tunnel establishment with multiple S-GW The P-GW shall implement PCEF functionalities as defined by 3GPP specifications. The PCEF functionalities must be triggered by an external PCRF. If the PCRF is not available, the PCEF component must support a default behavior. PCEF functions shall be applicable to IPv4, IPv6 and IPv4v6PDP contexts and bearers in the same way. PCEF functions embedded in the PDN-GW shall be applicable to all accesses.

Q.989 Q.990 Q.991 Q.992 Q.993 Q.994 Q.995 Q.996 Q.997 Q.998 Q.999 Q.1000 Q.1001 Q.1002 Q.1003

Q.1004

Each feature MUST have a priority level in order to stop the lowest priority services in case of peak of load or service unavailability. Those lists shall be configurable. The solution must support configurable static and dynamic PCC rules. The vendor is invited to explain how static PCC rules are configured in the PGW? Please describe how dynamic and static PCC rules could be associated? The vendor is invited to indicate the maximum number of simultaneous active PCC rules? Please detail the impact on solution sizing? The vendor is invited to give the limitation of the PGW in terms of number of pre-defined PCC rules? 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.1005 Q.1006 Q.1007 Q.1008 Q.1009 Q.1010 Q.1011

Q.1012 Q.1013 Q.1014

The vendor will detail his implementation regarding detection points and PCC rule definition in his PCEF. 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. 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 Q.1016 Q.1017 Q.1018 Q.1019

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. 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. The PGW shall be able to install a new pre-defined group of PCC rules when required by the PCRF. The PGW shall be able to apply IP CAN bearer modification when the PCRF provides new QoS information. The PGW shall be able to perform bandwidth-limitation/traffic-shaping for a specific service data flow de-pending on QoS information within the Charging-RuleDefinition requested by the PCRF. 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...) The PDN-GW shall be able to push information about the session towards an external AAA server, using Radius protocol. The vendor will specify how the Radius server interaction (host name can be configured in the PDN-GW (per APN, other). The vendor will indicate all session attributes that can be forwarded by the PDN-GW to an external AAA server using Radius Protocol The vendor will specify how the operator can configure Radius request types to forward to the external AAA server. 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. The PCEF shall support HTTP redirections (301, 302), based on PCEF static configuration. The P-GW shall support UE attach procedure. The P-GW shall support the Tracking Area Update procedure with S-GW change. The P-GW shall support detach procedure. The P-GW shall support X2-based handover without S-GW relocation. The P-GW shall support X2-based handover with S-GW relocation. The P-GW shall support S1-based handover with S-GW relocation. The P-GW shall support S1-based handover without S-GW relocation.

Q.1020

Q.1021 Q.1022 Q.1023 Q.1024 Q.1025

Q.1026 Q.1027 Q.1028 Q.1029 Q.1030 Q.1031 Q.1032 Q.1033

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 Q.1036 Q.1037 Q.1038 Q.1039 Q.1040 Q.1041 Q.1042 Q.1043 Q.1044 Q.1045 Q.1046

The P-GW shall support operations for non-GBR dedicated bearer. The P-GW shall support operations for GBR dedicated bearer. The P-GW shall initiate a bearer update procedure, if the PCRF response leads to an EPS bearer modifica-tion. The P-GW shall support dedicated bearer activation procedure for a GTP based S5/S8. The P-GW shall support P-GW initiated bearer modification procedure (including EPS Bearer QoS update) for a GTP based S5/S8. The P-GW shall support HSS Initiated Subscribed QoS Modification for a GTP-based S5/S8. The P-GW shall support P-GW initiated bearer modification without bearer QoS update. The P-GW shall be able to provide charging functionality for each UE. The Vendor shall indicate whether IPv4, IPv6 and IPv4andIPv6 end user addresses are supported over Gy interface? The solution shall be able to perform credit control at service level. The Vendor shall specify which network events can trigger start of the Gy session? 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. The P-GW shall be able to collect and report, accounting information per UE and per bearer for GTP-based S5/S8. The P-GW shall receive Charging Characteristics from the Serving GW through GTP-S5/S8, or through PMIP for PMIP-based S5/S8. The vendor will provide the list of the QoS parameters (including UMTS/2G specific parameters) which are supported? 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? 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. Please provide the list of QOS functionalities supported by the offered elements. The P-GW shall support IPSec to connect to remote network over SGi interface. The P-GW shall act as the user plane anchor for mobility between 3GPP access and non-3GPP access. Please describe different supported accesses. S-GW Functionality and Feature Requirements The S-GW shall support E-UTRAN initiated UE Attach procedure. The S-GW shall support UTRAN/GERAN initiated UE Attach procedure. The S-GW shall support UE, SGSN, MME, S-GW and HSS initiated UE Detach procedure. The S-GW shall support the Tracking Area Update procedure with S-GW change and without S-GW change. The S-GW shall support the Routing Area Update procedure with MME interaction and with or without S-GW change. The S-GW shall support UE triggered Service Request procedure.

Q.1047

Q.1048 Q.1049 Q.1050 Q.1051 Q.1052 Q.1053

Q.1054 Q.1055 Q.1056 10.6. Q.1057 Q.1058 Q.1059 Q.1060 Q.1061 Q.1062

Q.1063 Q.1064 Q.1065 Q.1066 Q.1067 Q.1068 Q.1069

The S-GW shall support Network triggered Service Request procedure. The S-GW shall support S1 Release procedure. The S-GW shall support HSS Initiated Subscribed QoS Modification for a GTP-based S5/S8. The S-GW shall support creation, modification and deactivation of dedicated bearer for a GTP based S5/S8 interface. The S-GW shall support creation, modification and deactivation of default bearer for a PMIP based S5/S8 interface. The S-GW shall support creation, modification and deactivation of dedicated bearer for a PMIP based S5/S8 interface. 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. The S-GW shall support X2-based handover without S-GW relocation. The S-GW shall support X2-based handover with S-GW relocation. The S-GW shall support S1-based handover without S-GW relocation. The S-GW shall support S1-based handover with S-GW relocation. The S-GW shall support E-UTRAN to UTRAN Iu mode Inter RAT handover. The S-GW shall support UTRAN Iu mode to E-UTRAN Inter RAT handover. The S-GW shall support E-UTRAN to GERAN A/Gb Inter RAT handover. The S-GW shall support GERAN A/Gb to E-UTRAN Inter RAT handover. The S-GW shall support location change reporting procedure. The local Mobility Anchor point for inter-eNodeB handover. The S-GW shall support static routing functionality. The S-GW shall support dynamic routing functionality The S-GW shall support access control list (ACL) feature. The S-GW MAY support MPLS/BGP feature. The S-GW shall support the connectivity with multiple P-GW. For a single UE with multiple tunnels, the S-GW shall be capable to establish tunnel with different P-GW. The S-GW shall be capable to allow high priority traffic and drop low priority traffic when the system is overloaded. It shall be possible to configure the overload control parameters in the S-GW based on which the system behavior can be defined. The S-GW shall support GTP tunnel on S5/S8 interface. The S-GW MAY support GRE tunnel on S8 interface. The S-GW shall support GRE encapsulation applicable for PMIPv6. The S-GW shall support GPRS Tunneling Protocol for the control plane (GTP-C) over S5/S8 interface. The S-GW shall support GPRS Tunneling Protocol for the user plane (GTPv1-U) over S5/S8 interface. Conformance to 3GPP Specifications Please specify the state of compliance of EPC products with 3GPP standards. PCRF

Q.1070 Q.1071 Q.1072 Q.1073 Q.1074 Q.1075 Q.1076 Q.1077 Q.1078 Q.1079 Q.1080 Q.1081 Q.1082 Q.1083 Q.1084 Q.1085 Q.1086 Q.1087 Q.1088 Q.1089 Q.1090 Q.1091 Q.1092 10.7. Q.1093 10.8.

Q.1094 Q.1095 Q.1096 Q.1097 Q.1098

Describe how the PCRF solution as defined by 3GPP is implemented in the solution. 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 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. The PCRF shall support all Gx Specific Diameter AVPs as described in 3GPP TS 29.212. 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 redirected to a notification server or the subscriber will view the message via a URL redirect. The Proponent PCRF must also support usage reporting and notifications to PCRF on the Gx interface as per 3GPP TS 29.212. The PCRF MUST be capable of handling quota usage based on Volume Time Volume and Time Location based (Cell_id based) How are the PCC rules provisioned on the PCRF? Please explain both for pre-defined as well as dynamic PCC rules. The Vendor shall explain how are PCC rules managed on your system? How does an operator create, find, edit, and delete rules? 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 How flexible is your counter hierarchy. How many levels can operator define? The PCRF shall be able to use User Location / Roaming Status (MNC, MCC, RAC, LAC, Cell Id) as an input for the policy decision. 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 be able to use internal Timers (start and expiry) as an input for the policy decision. 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. 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. The PCRF shall support the allocation of a pre-defined default policy in the event of unavailability of adjunct systems (such as SPR). 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%.

Q.1099

Q.1100

Q.1101 Q.1101 A. Q.1101 B. Q.1101 C. Q.1101 D. Q.1102 Q.1103 Q.1104 Q.1105 Q.1106 Q.1107 Q.1108 Q.1109 Q.1110 Q.1111 Q.1112 Q.1113 Q.1114

Q.1115 Q.1116

Q.1117

The PCRF shall support volume counting based policy decision through standard Gx interface for quota installation from PCRF to PCEF and volume reporting from PCEF to PCRF. The PCRF shall support Online Charging System Selection (OCS Host Load Sharing, pri/sec event-charging-function-name) in the policy output 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 Policy server shall have both GUI and CLI administrative console. The proposed solution shall support of geographical redundancy and load sharing. Can the PCRF support interfacing to several Subscriber Database (Sprs) for rules evaluation of one sub-scriber. 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. PCRF shall accept input for decision-making from the PCEF for dynamic policy changes 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. 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) 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. PCRF shall be able to cache information received from SPR. 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. 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. 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. Happy Hour concept where all subscribers get improved bandwidth at a certain time (e.g. global triggers) 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

Q.1118 Q.1119 Q.1119 A. Q.1119 B. Q.1119 C. Q.1119 D. Q.1119 E. Q.1119 F. Q.1119 G. Q.1120 Q.1121 Q.1122 Q.1123

Q.1124 Q.1125

Q.1126

Q.1127

Q.1128 Q.1129 Q.1130 Q.1131 Q.1132 Q.1132 A. Q.1132 B. Q.1132 C. Q.1133 Q.1133 A.

Q.1133 B. Q.1133 C.

Time of Day/Day of Week Controls including controls triggered by prayer times 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

Q.1134 Q.1135 Q.1136 Q.1137 Q.1138 Q.1139 Q.1140 Q.1141 Q.1142 Q.1143 Q.1144 Q.1145 Q.1146

Vendor shall describe all multiple PCEF scenario supported cover GGSN and DPI systems. 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. PCS shall support Volume and Quota based policies. PCS shall support location based or roaming based policies. PCS shall support Device based policies. The Proponents PCRF must offer a carrier grade solution which provides 99.999% availability. The Pro-ponent must detail the reliability and availability figures for your PCRF solution. System shall support so-called "hitless" upgrades? Proposer shall detail which redundancy models (1+1, 2n, 3n etc) are supported by Proposer solution. The proposed solution shall support of geographical redundancy and load sharing. The proposed solution shall support PCRF overload control. Proposer shall describe overload mechanisms and PCRF behavior during overload. 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 Bidders must describe how the proposed system is scalable. Vendor shall provide architectural evidence that the policy solution can scale horizontally and vertically using off the shelf hardware and software components.

Q.1147 Q.1148 Q.1149 Q.1150 Q.1151 11 11.1. Q.1152 Q.1153 Q.1153 A. Q.1153 B. Q.1153 C. Q.1153 D.

The hardware shall be universal and shall be modular extendable according to capacity demand (preferable extension via HW-card). 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 The system shall provide N+1 redundancy for internal boards/cards. However both N+1 and 1+1 redundancy shall be supported. The Bidder shall offer the system which is future proof. The system shall have the ability to be migrated to next system generation. IMS Solution IP Multimedia Subsystem (IMS) Architecture Requirement The Tenderer shall describe support of a layered architecture made up of mainly transport layer, control layer and service layer. The IMS architecture shall support Converged voice, data and video services Real time conversational services Streaming and content based services Messaging

Q.1153 E. Q.1153 F. Q.1154 Q.1154 A. Q.1154 B. Q.1154 C. Q.1154 D. Q.1155

Web based services and Other multimedia, combinational and converged Services. The proposed system must satisfy the following specifications. 3GPP IMS Release 9/10 IETF RFC GSMA VoLTE ETSI TISPAN Supplier must include support for successful interoperability testing for the access networks discussed in this section as part of their proposal. Specifically, the following types of access networks are required to be supported. UTRAN (UMTS) GSM WLAN DSL LTE The proposed system must provide all VoLTE supplementary services of GSMA. 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 Set of integrated features, e.g. Generic Address Translation, Prefix Insertion, and Service Authorization Tenderer must explain the IOTs conducted with different vendors and provide references and provide mul-tivendor references: The offered IMS solution shall be successfully pass interoperability tests with terminals. CSCF Functional Requirements In IMS Solution, state all the Call Session Control Functional Elements supported

Q.1155 A. Q.1155 B. Q.1155 C. Q.1155 D. Q.1155 E. Q.1156 Q.1157 Q.1157 A. Q.1157 B. Q.1157 C. Q.1157 D. Q.1157 E. Q.1157 F. Q.1157 G. Q.1157 H. Q.1157 I. Q.1158 Q.1159 11.2. Q.1160

Q.1161 Q.1162 Q.1163 Q.1164

In IMS scenario, Proxy Call Session Control Function (P-CSCF) shall be supported and act as entry gate for subscribers. The P-CSCF shall support Confidentiality Protection according to 3GPP TS 29.002, TS 33.204 for IMS AKA. The P-CSCF must support integrity protection on access network for Digest authentication and key agree-ment. 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. The P-CSCF must support QoS precondition signaling as specified in 3GPP TS 24.229 and detailed in 3GPP TS 24.228 The P-CSCF must support SIP signaling compression as specified in IETF RFCs 3321 and 3486. I-BCF function can be integrated in P-CSCF. 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 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.1165 Q.1166 Q.1167 Q.1168 Q.1168 A. Q.1168 B. Q.1168 C. Q.1169

Q.1170

The P-CSCF shall be able to detect emergency calls The P-CSCF shall be able to identify and correctly handle emergency calls as per 3GPP TS 24.229, and prioritize emergency calls in high priority to ensure emergency calls be served even in congestion situations. P-CSCF must suggest I-CSCF Finding scheme using domain name. If there is no subscriber information in called P-CSCF, a method of routing SIP message must be suggested. P-CSCF must provide support for Lawful Interception. 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? The vendor shall describer what P-Headers are supported by the P-CSCF. The vendor shall list all supported security algorithms on the P-CSCF. The vendor shall explain the performance sensitivity of the offered P-CSCF and detail all performance rel-evant parameters 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 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.

Q.1171 Q.1172 Q.1173 Q.1174

Q.1175

Q.1176

Q.1177 Q.1178 Q.1179 Q.1180 Q.1180 A. Q.1180 B. Q.1181 Q.1181 A.

Q.1181 B. Q.1182 Q.1183

Forwarding of SIP messages appropriately according to SIP method, registration status of the relevant subscriber, and appropriate routing mechanism. 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. 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. The IMS core must support the following RFCs. 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. IETF RFC 3345:Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) IETF RFC 3966; The Tel URI for Telephone Numbers. IETF RFC 4904; Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs). IETF RFC 4960; An Introduction to the Stream Control Transmission Protocol (SCTP). IETF RFC 3588; Diameter Base Protocol. SIP call processing must provide both domain-based routing and prefix based routing. For interworking with HSS regarding subscriber information, Shared IFC must be provided. The S-CSCF must be able to route SIP messages to the appropriate AS(s) based on initial Filter Criteria obtained from the HSS. IMS core shall provide support for the following interfaces Mj/Mg, Mw, Mx, Ic, ISC, Cx, Dx, Dh, Gm, Ic, Ml, Ma, Mk Interfaces. IMS core shall provide SCTP support on the following interfaces Mj/Mg, Mw, Mx, Ic, , Cx, Dx Interfaces. 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. The proposed system must provide 3GPP Initial Registration, Implicit Registration, Re-Registration and De-Registration. The proposed system must provide accommodation of multi domain subscribers. 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. The S-CSCF must have Load control to prevent registration flooding Provide detailed description of different authentication schemes supported. IMS Core shall support Registration Procedures according to 3GPP TS 23.228, TS 24.229. The registration expiration interval is configurable as per TS 23.228 and TS 24.229 IMS Core shall support Re-Registration Procedures according to 3GPP TS 23.228 and TS 24.229. 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. 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. If calling or called party is unregistered status, each call procedure must be provided and a related method must be suggested. The proposed system must provide both local number and global number format for Tel-URI number pro-cessing. The proposed system must provide conversion between Tel-URI and SIP-URI through ENUM interworking.

Q.1184 Q.1184 A. Q.1184 B. Q.1184 C. Q.1184 D. Q.1184 E. Q.1184 F. Q.1184 G. Q.1184 H. Q.1184 I. Q.1184 J. Q.1184 K. Q.1184 L. Q.1184 M. Q.1185 Q.1186 Q.1187 Q.1188 Q.1189 Q.1190

Q.1191

Q.1192 Q.1193 Q.1194 Q.1195 Q.1196 Q.1197 Q.1198 Q.1199 Q.1200 Q.1201 Q.1202 Q.1203 Q.1204

Q.1205 Q.1206 Q.1207

Describe detail routing scheme of Domain routing and prefix routing with distinguishing IMS and legacy network based on ENUM query results. The proposed system must provide call processing with MSISDN-based Tel-URI and SIP-URI format and Alphanumeric SIP-URI address system. 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. The proposed system must suggest a method of redirecting an incoming message to P-CSCF based on setting (subscriber prefix, terminal capability, etc.) The proposed system must provide routing control scheme depending on terminal capability registered for the requested service. IMS Core shall support SigComp according to RFC 3320 RFC 3485 RFC 4896. It shall be possible to deac-tivate SigComp. The proposed system must provide call forking in case of multi binding is required and a specific method must be suggested. IMS core shall support of forking control for RCS Provide high level call flow for IMS based Number Portability uses DNS ENUM. The E-CSCF, Emergency Call Session Control Function must support emergency call handling for both registered and unregistered subscribers. Provide detailed description of Emergency call handling and location information support. The E-CSCF must support the Ml interface toward location retrieval function (LRF). The E-CSCF must route the call to the Public safety answering point (PSAP) according to information re-ceived from routing decision function (RDF). The vendor shall describe the solution for Emergency Callback Support provided by S-CSCF. 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.1208 Q.1209 Q.1210 Q.1211 Q.1212 Q.1213 Q.1214 Q.1215 Q.1216 Q.1217 Q.1218 Q.1219

Q.1220

An emergency call usually requires location information as the SIP Control Domain needs to determine which Public Safety Answering Point (PSAP) serves the area where the UE is currently located. Furthermore, national regulations require delivering the location information of the subscriber to the PSAP. The vendor shall describe the capabilities of the offered solution to determine the correct PSAP and to deliver the location information to the PSAP. 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. TRCF must provide support for Rf interface. TRCF must provide support for Lawful Interception. VoLTE Solution The vendor shall describe VoLTE solution. VoLTE service means to provide GSMA VoLTE standard based voice call, video call and SMS/MMS. 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) 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.1221

Q.1222 Q.1223 11.3. Q.1224 Q.1225 Q.1226 Q.1226 A. Q.1226 B. Q.1226 C. Q.1226 D. Q.1226 E. Q.1226 F. Q.1226 G. Q.1227

Q.1228

Q.1229 Q.1230 Q.1230 A. Q.1230 B. Q.1230 C. Q.1230 D. Q.1230 E. 11.4. Q.1231 Q.1232 Q.1233 11.5. Q.1234 Q.1235 Q.1236 Q.1237

IMS NE shall support VoIP and VIP services prioritization in a VoLTE scenario. 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 Network element features The vendor shall describe overload protection mechanism. The vendor shall describe Load Balancing and failover mechanism. The vendor shall describe Scalability mechanism. HSS Functional Requirements The HSS shall support LTE (as defined in TS23.401) including S6a- and SWx interface. The vendor shall provide detailed information about this component (HW type, OS type, DB SW type, logical and physical function and interfaces). Describe HSS behavior in the IMS System Environment 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 vendor shall describe AuC/HSM function in HSS Protocol Stack supported in the various layers for the various interfaces shall be described. The vendor shall describe the functionalities supported by the DRA solution. The Diameter agent shall support Diameter interconnection to other networks. The DRA Solution shall be able to control Roaming Agreements The DRA solution shall be able to perform Admission Control The DRA solution shall be able to perform Load Control The vendor shall provide the strengths and advantages of the offered DRA solution. The vendor shall provide a detailed listing of supported specifications and interface requirements of the offered diameter agent solution. 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. 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. The Diameter Agent at the edge of the network would be suited best to perform message screening ac-cording to an operator-defined policy. The Agent anyhow needs to understand 3GPP-specific protocol exten-sions, and it shall be configured to accept the individual roaming partners. The Bidder shall describe the solution of roaming agreement validation.

Q.1238 Q.1239 Q.1240 Q.1241 Q.1242 Q.1243 Q.1244 Q.1245 Q.1246 Q.1247

Q.1248 Q.1248 A. Q.1248 B. Q.1248 C. Q.1249

Q.1250 Q.1251

Diameter Agent shall have robust Diameter and SCTP protocol implementations that are able to handle exceptional input and protocol syntax/format violations. 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. Diameter Agent shall support of alarming and logging in case of policy or protocol violations. The Diameter Agent shall support voice over LTE as well as internet multimedia subsystem as required in GSMA PRD IR.92. 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. 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 Rf as defined in RFC 4006, TS 32.225 & 32.299 Ro as defined in RFC 4006, TS 32.225 & 32.299 S9 as defined in TS 23.203 & 29.215 S6a as defined in TS 29.272 S6d as defined in TS 29.272 Sh interface as defined in TS 29.328 and TS 29.329 Dx interface as defined in 3GPP TS 29.228 & TS 29.229 S13 and S13bis interfaces ad defined in 3GPP TS 29.272 Subscriber Authentication The IMS shall support the SIP/HTTP Digest authentication method used for Subscriber authentication. 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. The solution must support IP address- based authentication intended for SIP/HTTP Digest Users. The IMS system shall support the Digest Authentication and Key Agreement over IPSec. The IMS solution shall support Digest authentication and Key agreement over TLS. HSS Features/HLR features HSS shall support EPS AKA Authentication retrieval from legacy HLR using MAP. Explain the interworking scenario. If vendor provide UMTS solution should also provide HLR solution for one million subscribers in this tender. HSS shall be able to retrieve the UMTS-AKA quintuplet or GSM-AKA triplet from HLR using SAI message The vendor shall describe the emergency call handling procedure with the proposed HSS. Access Authentication The IMS system shall support the Evolved Packet System AKA. The IMS Solution shall support EAP-AKA for the Evolved Packet System. The solution shall support the Bootstrapping Architecture to establish a security association between an end-user device and the Bootstrapping Server Function (BSF). Security

Q.1252 Q.1253 Q.1254

Q.1255

Q.1256 Q.1256 A. Q.1256 B. Q.1256 C. Q.1256 D. Q.1256 E. Q.1256 F. Q.1256 G. Q.1256 H. Q.1256 I. Q.1256 J. Q.1256 K. Q.1256 L. 11.6. Q.1257 Q.1258 Q.1259 Q.1260 Q.1261 11.7. Q.1262 Q.1263 Q.1264 Q.1265 11.8. Q.1266 Q.1267 Q.1268

11.9.

Q.1269 11.10. Q.1270 Q.1271 Q.1272 11.11. Q.1273 Q.1274 Q.1275 Q.1276 Q.1277 Q.1278 11.12. Q.1279 Q.1280 Q.1281 Q.1282 Q.1283 11.13. Q.1284 11.14. Q.1285 Q.1286 Q.1287 11.15. Q.1288

Authentication between IMS subscriber and IMS network shall follow IMS AKA (Authentication and Key Management) as specified in TS 33.203. Session and Service Control Functionality The IMS Solution shall support Session Control. The IMS Solution shall support Service Control. The IMS solution shall support Service Triggering with Initial Filter Criteria. Routing. The vendor shall explain the routing principles used in the HSS. The HSS shall support Realm-based Routing used when there is a Diameter relay or Proxy to support multiple HSS In the IMS configuration The HSS-FE shall also act as a Diameter Relay for HSSd Outgoing Requests The HSS shall support Evolved Packet System Access Point Name Control to control the use of access point names for subscribers using LTE access. The HSS shall support Operator-determined barring for the Evolved Packet System as specified in 3GPP TS 23.015. Explain in Detail. The HSS shall support Subscriber tracing. Charging 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. CDR shall be generated for unsuccessful call The vendor shall provide detailed description of content included in the CDRs. The vendor shall suggest a method of mutual settlement between carriers. IP Network Features The vendor shall explain the extent of your current support of IPv6 and your roadmap for future support Network Element Features The vendor shall provide detailed functionality when a site is down due to disaster. Describe how a client can connect to the geo-redundant site in case of a disaster. HSS system shall support local redundancy Capacities and Performance 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. Scalability The vendor shall describe the scability mechanism of VoLTE system. Interfaces and Protocols The vendor shall provide detailed description of S6a interface specifying your products compliance with the 3GPP requirements. The vendor shall provide detailed description of your HSS system including all data schemas as well as access interfaces and protocols. HSS Front-End system shall support Cx interface as defined in 3GPP TS 29.228 release 10 or later.

Q.1289

11.16. Q.1290 11.17. Q.1291 Q.1292 Q.1293

Q.1294 Q.1295 Q.1296 Q.1297 Q.1298 11.18. Q.1299 Q.1300 Q.1300 A. Q.1300 B. Q.1300 C. Q.1300 D. Q.1300 E. Q.1300 F. Q.1300 G. Q.1300 H. Q.1301 11.19. Q.1302 Q.1303 Q.1304 Q.1305

HSS shall support all the Diameter parameter definitions as defined in 3GPP TS 29.230 release 10 or later. HSS shall be compliant with IR.94 IMS Profile for Conversational Video Service. HSS shall be compliant with 3GPP Presence Architecture specification 23.141 rel 10. HSS Front-End shall support all IMS interfaces and behavior for HSS as defined in 3GPP TS 23.228 release 10 or later. HSS Front-End system shall support storing and recalling Service Continuity data as defined in 3GPP TS 23.237 release 10 or later. Operation, Administration and maintenance HSS will provide the alarms & OMs necessary for monitoring the status and health of the platform. 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 alarm description alarm category alarm type the NE and any subordinate resource (if applicable) previous state The NE will be capable of buffering at least 48 hours of accounting data, to ensure continuity in case where the transport to upstream systems is not available. ENUM Functional Requirements The solution must support DNS based lookup to TEL and SIP NAPTRs, please describe the information flows between operators and your solution. What additional service types and NAPTR fields do you support and advice for this implementation? The offered ENUM shall support all possible formats of Tel-URL (international, national, local format). 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. The solution must support full and incremental updates. Please give a description of your companys view on ENUM and its role in number porting for this moment and your vision on ENUM developments for the coming years. Provide high level call flow for IMS based Number Portability uses DNS ENUM. ENUM servers configure the offered shall support the following RFCs 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

Q.1306 Q.1307

Q.1308 Q.1309 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 I. Q.1309 J. Q.1309 K. Q.1309 L. Q.1309 M. Q.1309 N. Q.1309 O. Q.1309 P. Q.1309 Q. Q.1309 R. Q.1309 S. Q.1309 T. Q.1309 U. Q.1309 V. Q.1309 W. Q.1309 X. Q.1309 Y. Q.1309 Z. AA. 11.20. Q.1310 Q.1311 Q.1312 Q.1313

RFC 5067 Infrastructure ENUM Requirements RFC 5278 IANA Registration of Enum services for Voice and Video Messaging RFC 5333 IANA Registration of Enum services for Internet Calendaring RFC 5346 Operational Requirements for ENUM-Based Softswitch Use RFC 5483 ENUM Implementation Issues and Experiences RFC 5527 Combined User and Infrastructure ENUM in the e164.arpa Tree RFC 1034 Domain Names concepts and facilities RFC 1035 Domain Names concepts and facilities RFC 2535 Domain Name System Security Extensions RFC 2915 The Naming Authority Pointer (NAPTR) DNS Resource Record RFC 2916 E.164 number and DNS (actually this RFC is obsolete by RFC 3761) RFC 3401 Dynamic Delegation Discovery System (DDDS) Part One RFC 3402 Dynamic Delegation Discovery System (DDDS) Part Two RFC 3403 Dynamic Delegation Discovery System (DDDS) Part Three RFC 3404 Dynamic Delegation Discovery System (DDDS) Part Four RFC 3596 DNS Extensions to support IP Version 6 (towards network elements) RFC 3597 Handling of Unknown DNS Resource Record (RR) Types RFC 3761 The E.164 to Uniform Resource Identifiers (URI) RFC 3764 ENUM service registration for Session Initiation Protocol (SIP) address-of-record RFC 3966 The tel URI for Telephone Numbers Lawful Interception The solution shall support the LI functionality defined in 3GPP TS 33.107 and 3GPP TS 33.108. P-CSCF must provide support for Lawful Interception. The supplier shall describe all the possible proprietary fields inserted in SIP messages used to implement the Lawful Interception solution. 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: This solution shall be undetectable by the LI target. This solution shall be undetectable by the operators staff (staff not involved in LI provisioning). The supplier shall describe the LI solution in these use cases. The supplier shall detail the role of each component involved in the LI solution. In Roaming-In use case (a user of another operator uses TSCC mobile IMS network, this user is a LI target in the visited network), the supplier shall implement a Lawful Interception (LI) solution to enable interception of signaling and communication content of this roaming-in user. Un-detectability: This solution shall be undetectable by the LI target.

Q.1313 A. Q.1313 B. Q.1313 C. Q.1313 D. Q.1314

Q.1314 A.

Q.1314 B. Q.1314 C. Q.1314 D. Q.1315

This solution shall be undetectable by the operators staff (staff not involved in LI provisioning). The supplier shall describe the LI solution in Roaming-In use case. The supplier shall detail the role of each component involved in the LI solution. In Roaming-Out use case based on home routing without Optimal Media Routing (TSCC mobile IMS user in VPLMN, this Roaming-Out user is a LI target for home network), the supplier shall implement a Lawful Interception (LI) solution to enable interception of signaling and communication content of this roaming-out user. Un-detectability:

Q.1315 A. Q.1315 B. Q.1315 C. Q.1315 D. Q.1316 Q.1317 11.21. Q.1318 12 12.1. Q.1319 Q.1320 Q.1320 A. Q.1320 B. Q.1321

This solution shall be undetectable by the LI target. This solution shall be undetectable by the operators staff (staff not involved in LI provisioning). The supplier shall describe the LI solution in Roaming-Out use case (Home Routed). The supplier shall detail the role of each component involved in the LI solution. If the supplier proposes its own Mediation Function platform, LI database shall be encrypted. When reporting LI event, target identities shall be encrypted in logs of the IMS solution equipment Conformance to Standard Specifications Describe major improvement, differentiations and value added provided by your solution and implementation with respect to the 3GPP standards TAS (MMTEL, IM-SSF, MRF, MGCF/IM-MGW, BGW) Telephony Application Server The vendor shall describe the offered TAS functions. Please also elaborate on the hard- and software ar-chitecture that has been chosen. 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. 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 IETF RFC 3261 3GPP TS 23.218 3GPP TS 24.229 The AS (MMTEL AS and IM-SSF) shall support SIP header transparency. The AS (MMTEL AS and IM-SSF) shall support SDP transparency. 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 The vendor shall describe any proprietary mechanisms (protocol extensions, SIP headers). 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. The proposed solution shall support redundancy on network element level (e.g. high availability cluster, pooling, hot-standby concept). MMTEL AS; STANDARD SUPPLEMENTARY SERVICES The vendor shall describe the offered MMTel function in detail. Supplementary services must be supported as defined as in GSMA and 3GPP specifications.

Q.1321 A. Q.1321 B. Q.1321 C. Q.1322 Q.1323

Q.1324 Q.1325

Q.1326 12.2. Q.1327

Q.1328 Q.1329

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. The vendor solution shall support Originating Identification Presentation (OIP) service according to 3GPP TS 24.607.

Q.1330 Q.1331 Q.1332

The vendor solution shall support Originating Identification Restriction (OIR) service according to 3GPP TS 24.607. The vendor solution shall support OIR per call. Communication Diversion (CDIV); The MMTel AS shall support the SIP procedures as described in 3GPP TS 24.604 and GSMA IR92 recommended options. The following list of call diversion shall be supported:

Q.1332 A. Q.1332 B. Q.1332 C. Q.1332 D. Q.1332 E. Q.1333

Communication Forwarding Unconditional Communication Forwarding on Busy Communication Forwarding on not Reachable Communication Forwarding on No Reply Communication deflection The proposed MMTel AS shall use the History-Info header (RFC 4244) in conjunction with the "cause" pa-rameter (RFC 4458) and the Diversion header (IETF Draft) to carry diversion information in the forwarded INVITE. The vendor shall describe the behaviour when the number of diversions exceeds a given limit and describe behaviour for the Call Diversion to the voicemail. The vendor shall indicate if CDIV can be managed over an Ut interface using XCAP protocol as described in 3GPP TS 24.623, and the XML schema defined in 24.604, for conditions and actions listed below:

Q.1334 Q.1335

Q.1336 Q.1337 Q.1338

Communication Hold (HOLD): The MMTel AS shall support the SIP procedures as described in 3GPP TS 24.610. Communication Waiting (CW); The MMTel AS shall support the SIP procedures as described in 3GPP TS 24.615 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. 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:

Q.1339

Q.1339 A. Q.1339 B. Q.1339 C. Q.1339 D. Q.1339 E.

Barring of All Incoming Calls Barring of All Outgoing Calls Barring of Outgoing International Calls Barring of Outgoing International Calls ex Home Country Barring of Incoming Calls - When Roaming

Q.1340 Q.1341 Q.1342 Q.1343

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. 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. The proposed MRF solution is able to mix a maximum of 6 communications. 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...) The offered MMTel function shall be compliant with 3GPP TS 24.623, Release 10. 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. The vendor shall state whether its recommended to include an Authentication Proxy in the Ut interface path The vendor shall describe how MMTEL AS retrieves location information and uses it. For terminating calls, the MMTEL AS shall retrieve subscriber location and use it as necessary (for Com-munication Barring while roaming, charging...). 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. Please list down all the interfaces supported, indicate the 3GPP and RFC list of compliant standard for each interface. The proposed MMTel AS shall support Sequential ringing service. The proposed MMTel AS shall support Simultaneous ringing. 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 offered MMTel function shall support the Sh interface compliant with 3GPP TS 29.328, Release 10. MMTel AS shall be data less and shall store data in a common database repository. Also please detail your general DB schema. IM-SSF The vendor shall describe the offered IM-SSF function in detail. The offered IM-SSF function shall support the Si interface as per 3GPP TS 23.278, Release 10 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 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. 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. 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.1344 Q.1345 Q.1346 Q.1347 Q.1348 Q.1349 Q.1350

Q.1351 Q.1352 Q.1353 Q.1354

Q.1355 Q.1356 12.3. Q.1357 Q.1358 Q.1359 Q.1360 Q.1361

Q.1362

Q.1363 Q.1363 A. Q.1363 B. Q.1363 C. Q.1363 D.

Q.1364

The IM-SSF shall support the retrieval of parameters from the HLR/HSS including but not limited to MSC address, LocationInformation / VLR Number, LocationNumber, using MAP or Sh. 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 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 MRF 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) MMTEL AS MRF IM-SSF MRF The proposed MRF function shall support 3GPP TS 23.218 and 3GPP TS 24.229 requirements: TS 23.218: o 8 Functional requirements of the MRFC TS 24.219: o Application usage of SIP o Media Control

Q.1365

Q.1366 12.4. Q.1367

Q.1367 A. Q.1367 B. Q.1368 Q.1368 A. Q.1368 A.

Q.1369 Q.1370 Q.1371 Q.1372 Q.1373 Q.1373 A. Q.1373 B. Q.1373 C. Q.1373 D. Q.1374

The MRF shall support the media profile defined in GSMA IR.92 (IMS Profile for Voice and SMS), chapter 9 IMS Media. The MRF shall support the media profile defined in GSMA IR.94 (IMS Profile for conversational video service), chapter 9 IMS Media 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 The vender shall list audio and video codes, DTMF mechanisms supported by MRF solution. 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) The offered MRF solution shall support the playback of audio announcements. The vendor shall list all supported audio codecs available for announcement playback 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. The offered MRF solution shall support audio conferencing. Please describe the audio conferencing capa-bilities of the offered MRF solution. 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) ApplyCharging with PlayTone (in ReleaseIfDurationExceeded) Connect (to an announcement)

Q.1375 Q.1375 A. Q.1375 B. Q.1375 C. Q.1376 Q.1377

Q.1377 A. Q.1377 B.

Q.1378 12.5. Q.1379 Q.1380 Q.1381 Q.1382 Q.1383 Q.1384 Q.1385 Q.1386 Q.1387

The vendor shall describe supported IN operations for IM-SSF and MRF. MGCF/IM-MGW The vendor shall describe the hardware and software architecture of the proposed MGCF/IM-MGW. The vendor shall provide the supported codecs from the proposed MGCF/IM-MGW. The proposed MGCF/IM-MGW shall be compliant to the Mn interface as specified in 3GPP TS 29.332. The proposed MGCF shall support the Mg interface to the S-CSCF in accordance with 3GPP TS 24.229 The proposed MGCF shall support the Mj interface to the BGCF in accordance with 3GPP TS 24.229 The IM-MGW shall support IPv6 (RFC 2460) at the Mb interface The proposed MGCF function shall be compliant to 3GPP TS 29.163, Release 10. All noncompliances shall be listed explicitly. The proposed MGCF shall support protocol interworking between SIP specified in 3GPP TS 24.229 and BICC as specified in Q.1902.1-6 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 vendor shall explain the MGCF behavior with unsupported SIP Methods The vendor shall describe how MGCF perform codec negotiation when transcoding is required in the IM-MGW. The MGCF shall support the control of tones and announcements to be played towards a user registered in the SIP control domain The MGCF shall be able to convert an E.164 ISUP Called Party Address into a SIP based URI. The MGCF shall support SIP based on SCTP/IP The MGCF shall support SCTP multi-homing The MGCF shall support SIP over TCP The MGCF shall support M3UA/SCTP/IP for BICC and ISUP signaling The MGCF shall support ISUP signaling based on TDM The vendor shall list supported P-Headers by the proposed MGCF. The vendor shall explain how the offered MGCF determines the SIP route header for initiated SIP-INVITE messages? 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. 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 The proposed IM-MGW shall support T.38 FAX over IP and FAX interworking with the PSTN. Border Gateway The vendor shall describe the hardware and software architecture of the offered Border Gateway The vendor shall describe the hardware the defense capabilities of the offered SBC over all protocol layers The offered SBC shall be able to support IMS-ALG and Transition Gateway functionality compliant to 3GPP TS 23.228 The offered A-SBC shall support access control by means of pinholing media approved during session setup. Please describe your implementation in detail.

Q.1388 Q.1389 Q.1390 Q.1391 Q.1392 Q.1393 Q.1394 Q.1395 Q.1396 Q.1397 Q.1398 Q.1399

Q.1400 Q.1400 A. Q.1400 B. Q.1401 13 Q.1402 Q.1403 Q.1404 Q.1405

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 Q.1408 Q.1409 Q.1410 Q.1411

The vendor shall list all monitoring, statistics and reports of events provided by the offered SBC The offered SBC shall support IP version interworking between IPv4 and IPv6 The vendor shall describe the transcoding capabilities of the offered SBC and shall list all supported codecs. The vendor shall describe the redundancy concept of the offered SBC solution To increase link reliability the offered SBC shall support Bi-directional Forwarding Detection (BFD)

14 14.1. Q.1412 Q.1413 Q.1414 Q.1415 Q.1416 Q.1417 14.2. Q.1418

MSS server MSS server platform The offer MSC server should support VLR function to be able handle 200M subscriber if Buyer have UMTS 900M network. System Architecture should be distributed.(at least two node ,North and south) Explain the architecture and functional units of your system The MSC server shall be provided with embedded Service Switching Point (SSP) functionality. IN Protocol should be supported, specify the capabilities of the system. Camel Phase 4 must be supported. SS7 on IP shall be supported using M3UA. The MSS system should comply to 3GPP 29.002, Mobile Application Part Specification Features The following feature should be supported by the system

14.3. Q.1419

Geo Redundancy 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. VLR backup functionality should be supported in order to support immediate terminating service after a VLR restarts or loss of MSS UMTS Package core SGSN SGSN function 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.

Q.1420 15 15.1. 15.1.1. Q.1421

Q.1422

Q.1423 Q.1424 Q.1425 Q.1426 Q.1427

Vendor shall support centralized and distributed CGF in SGSN. Vendor shall detail to which 3GPP TS its charging solution comply. The vendor shall support HSDPA+ in 3G environments with bit rate up to 168 Mbps The vendor shall support HSUPA+ in 3G environments with bit rate up to 84 Mbps The solution shall be able to produce trend statistics and calculate KPIs for the network planning engineers and executive management. The statistics shall be available for review in a real-time monitoring and trouble-shooting tool providing detailed reports on all call attempts made in the network, as well as real-time information about your services 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. 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. 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.

Q.1428 Q.1428 (1) Q.1428 (2) Q.1428 (3) Q.1428 (4)

Q.1428 (5) Q.1428 (6) Q.1428 (7) Q.1428 (8) Q.1428 (9) Q.1428 (10) Q.1428 (11) Q.1429 Q.1430 Q.1431 Q.1432

Information on BSSGP buffer utilisation per priority class, lost BSSGP downlink data per priority class, and BSSGP packets dropped due to redundancy elimination. 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. 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 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. 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. Please list any other additional reports that are available through real-time monitoring tool and not listed above. For increased reliability, SGSN shall support interface to a redundant combination of additional elements Please explain the mechanism to protect your system from overload situation. 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. SGSN shall be able to integrate to EPC environment with 3GPP Rel.8 interfaces (S4, S3, S16, S6d, S12). Describe packet core evolution steps to introduce LTE radio access in addition to 2G and 3G radio accesses GGSN GGSN function 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. The gateway shall be optimized to support always-on terminals. The gateway shall support multi-core packet processor (MPP) technolog The GGSN deployment option shall support the GTP access protocol over the Gn and Gp interfaces for GERAN, UTRAN, HSPA, HSPA+, and EHSPA traffic The GGSN deployment option shall support flat architecture connections with Internet high-speed packet access (EHSPA) and direct tunnel (DT). The GGSN deployment option shall provide Gi interface towards packet data networks (PDN). The GGSN deployment option shall support Generic Routing Encapsulation (GRE) in the Gi interface. The GGSN deployment option shall support Radius protocol towards AAA server in the Gi interface The GGSN deployment option shall support Bp interface for off-line metering to enable on-demand transfer of charging data. The GGSN deployment option shall support X1_1, X2 and X3 interfaces towards Lawful Interception system. The GGSN deployment option shall support GTP version GTPv1. The GGSN deployment option shall provide PDP context management functions (creating, maintaining and deleting of PDP contexts)

Q.1433 Q.1434 15.2. 15.2.1. Q.1435

Q.1436 Q.1437 Q.1438 Q.1439 Q.1440 Q.1441 Q.1442 Q.1443 Q.1444 Q.1445 Q.1446 Q.1447 15.3. Q.1448 Q.1449 Q.1450 Q.1451 16

Lawful interception The vendor shall support ICE interfaces X1_1, X2 and X3 according 3GPP TS 33.106 and TS 33.107 The vendor shall support ADMF, DF2 and DF3 according 3GPP TS 33.106, TS 33.108, TS 33.108 and ETSI TS 101.671 The vendor shall support IRI and CC data The vendor shall support IMSI, IMEI and MSISDN as an interception target Number Portability System

Q.1452

The vendor should provide the NP subsystem or integrated with IMS Enum to support both circuit switch system and IMS core network to comply Taiwan Telecommunication Number Portability mechanism. Also need to take the responsibility of the integration work with Taiwans Number Portability Administration Center (NPAC) with require OSS integration effort The vendor should provide the detail call scenario/flow for TSC non-NP subscriber, NP-out users and NP-in TSCs subscriber The provide NP system should be able to support more than 50M number data without performance degrade. 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 ). OSS Solution General Requirement Please provide EMS, NMS layer architecture managing LTE, IMS and SDM network with redundancy support. 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: 3GPP standards TM Forum MTNM OSS/J Other It shall be supported to perform automatic monitoring of the NMS behavior (including all HW and SW com-ponents) through use of monitoring agents (own - or 3rd. party). Monitoring agents could communicate with a remote NMS over a DCN (Data Communication Network) by means of a management protocol, such as SNMP, EJB, XML/JMS or Web Services. Dependencies to particular product versions across value chains shall be kept to a minimum. It shall be possible to install and operate the Vendors NMS solution on a virtualized data centre infrastructure. 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. The vendor shall support VM-Ware for the virtualization of his NMS solution. The Vendor shall fulfill the same functionalities for the virtualized NMS as for his standalone NMS solution, according to the requirements in this Annex. 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. The Vendor shall provide all necessary information, (e.g. CPU load, SW versions, database version ) which is needed to virtualize the Vendors NMS solution. Every alarm, measurement, configuration, operation and maintenance data stored in the database shall be able to be accessed using external tools. Provide system schematic diagram about network management how to manage, maintain and optimize eNodeB, EPC, IMS and transmission network. The NMS shall support storing of all data in Oracle or other relational database based on SQL standard. 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). The NMS shall have a layered structure focusing on scalability, flexibility and openness. Describe Logical Structure of the Hardware Platform. Describe Software Structure of the NMS solution. Explain Overload and Congestion Control of NMS solution. What is the Power Supply and Power Consumption of the offered management solution? Please provide machine to machines local/remote (console, EMS, NMS) management method and its maximum connection figure. 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).

Q.1453 Q.1454 Q.1455

17 17.1. Q.1456 Q.1457 Q.1457 A. Q.1457 B. Q.1457 C. Q.1457 D. Q.1458

Q.1459 Q.1460 Q.1461 Q.1462 Q.1463 Q.1464 Q.1465 Q.1466 Q.1467 Q.1468 Q.1469

Q.1470 Q.1471 Q.1472 Q.1473 Q.1474 Q.1475 Q.1476

Q.1477 Q.1478 17.2. Q.1479

Please suggest additional software and hardware solution needed for manage, maintain, optimized various system. Please provide network elements, EMS, NMS full on line backup and restore (including OS & Application & data), where this operation wont impact to user service, detail execution plan. Fault Management 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. The NMS shall be possible to define alarms based on statistics. It shall be possible to search in the alarm history for certain alarms by filtering on any alarm information. It shall be possible to filter out alarms at system and userlevel. Descriptions of available alarm filtering shall be provided. The NMS shall be possible to define alarms. The NMS shall be possible to pre-define alarm thresholds. The NMS shall be possible to define different alarm categories and levels. The NMS shall be possible to activate/deactivate the different alarms. The NMS shall be possible to automatically delete alarms. 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. 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. Please provide EMS, NMS southbound Alarm Resynchronization minimum interval and needed time for Alarm Resynchronization mechanism. Please provide network elements, EMS, NMS collecting data minimum interval, generating data time and exporting to northbound time. Please provide other trouble shooting tools detail description. Performance Management 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. The NMS shall provide statistics on events in all NEs and on the related interfaces. NMS shall have performance reporting functionality and user shall be able to query to performance database using that functionality. The following performance management data shall as a minimum be supported: Performance data

Q.1480

Q.1481 Q.1482

Q.1483 Q.1484 Q.1485 Q.1486 Q.1487 Q.1488

Q.1489

Q.1490 Q.1491 Q.1492 Q.1493 17.3. Q.1494

Q.1495

Q.1496

Q.1497 Q.1498 Q.1499 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. Q.1500 Q.1501 Q.1502 Q.1503

Performance event Event statistics Counters Performance thresholds Measurements Measurement interval Load on NEs, number of service executions Network Performance Key Performance Indicator (KPI) The NMS shall be possible to activate and deactivate counters, to choose different measuring intervals and to automatically produce statistical reports. Automatic data deletion shall be possible. Describe the retention period for storing performance measurement data. 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, for each set of performance measurement counters, at what granularity the counters can be reported. The vendor shall provide a description of the performance management functionality and all performance measurement counters available The Vendor shall describe how automatic solutions and procedures for measuring the traffic with respect to quality, capacity, performance, usage and availability are supported. The NMS shall monitor its own resource requirements and raise an alarm if any of these are in danger of being breached. Provide network element PM interface to EMS, NMS architecture. Please provide network elements, EMS, NMS south bound minimum interval collection time. Configuration Management Please provide retrieving CM data mechanism and architecture. Configurations changes shall be possible to plan at any network level defined in the NMS. Preparing and activating multiple plans shall be possible independently and simultaneously. Full traceability at any configuration changes must be ensured in NMS. The NMS shall have functionality for automatic import of configuration data on a predefined format. Any configuration changes in the network must be done through an open and fully documented interface such as XML. The NMS shall maintain the configuration inventory for all changeable parameters in the network. Activating plans to the network shall be done in a transaction oriented process with both commit and rollback mechanisms. The Vendor shall list any configuration tasks that are available via CLI only The vendor shall list any configuration tasks that are available via GUI only. The network topology and object relationships shall be stored in the NMS The vendor shall list all configuration tasks that can be performed via scripts or configuration files. 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. When the operational state of a managed entity within a NE changes, the NMS shall provide notification and log. The NE entity or functionality shall allow for version control and tracking for configuration files and software load files Please provide EMS, NMS southbound CM data collecting minimum interval and needed time for collecting data. Please provide network elements, EMS, NMS collection data complete minimum interval, generate consol-idated data time, and exporting to northbound time

Q.1504 Q.1505 Q.1506 Q.1507 Q.1508 Q.1509 17.4. Q.1510 Q.1511 Q.1512 Q.1513 Q.1514 Q.1515 Q.1516 Q.1517 Q.1518 Q.1519 Q.1520 Q.1521 Q.1522 Q.1523 Q.1524 Q.1525 Q.1526

Q.1527 Q.1528 Q.1529 Q.1530 Q.1531 Q.1531 A. Q.1531 B. Q.1531 C. Q.1531 D. Q.1532 17.5. Q.1533

Please provide how system generates object software release number and hardware (Chassis/Slot/Daughter card) inventory data via CM interface. Please provide provision and change management interface and method. 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). The NMS shall support to gather and store all relevant NEs or devices information as inventory type infor-mation. 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 Please advice how to confirm immediate execution or batch execution result is correct and complete. Security Management 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. Provide network elements security access control mechanism. 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 require each user ID to have an associated password. The NMS shall require users to identify themselves with their assigned user ID and password before per-forming any actions. The NMS shall internally maintain the identity of all active users. The NMS shall disable all user IDs that have not been used for a specific period of time. 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. The NMS shall not allow any way to bypass authentication mechanisms. 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. The number of unsuccessful log-on attempts shall be limited. The NMS shall terminate or lock account such over attempted accounts. 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. An internationally accepted algorithm or method of encryption is employed for keeping of passwords con-tents (e.g. SHA-1). Software Management It shall be possible to download new software to NE. This operation shall be possible also from a remote site. The NMS shall support to maintain multiple software versions throughout the network. It shall be possible to schedule the download and installation of new software to any NE. A description of this functionality shall be provided. NMS software upgrades shall be done with a formal and predictable software upgrade mechanism. Provide EMS, NMS southbound network element minimum data collecting interval and data aggregation time. Please provide south bound and northbound interface specification, protocol and message for all the EMS/NMS (FM, CM, PM, PRM, SM, Call log, Call event, system log). Also, provide EMS, NMS (FM, CM, M, PRM, SM, Call Log, Call Event, System Log) northbound message management architecture, protocol and message. Logging

Q.1534 Q.1535

Q.1536 Q.1537 Q.1538 Q.1539 Q.1540 Q.1541 Q.1542

Q.1543 Q.1544 Q.1545 17.6. Q.1546 Q.1547 Q.1548 Q.1549 Q.1550 Q.1551

17.7.

Q.1552 Q.1552 A. Q.1552 B. Q.1552 C. Q.1552 D. Q.1553 Q.1554 Q.1555 Q.1556 Q.1557 Q.1558 17.8. Q.1559 Q.1560

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 Local logging of relevant events and operations shall be written to a non-volatile storage. For all log records in log files shall support time-stamps which shall be accurate within a second e.g. xyz.log.20011201230059 (yyyymmddhhmmss). Log-files shall support to contain all relevant error messages, e.g. status information and performance in-formation. All log-messages shall be able to be distinguished for each system categories (e.g. OS, Database, inter-faces, application). The retention period of all log files shall be configurable. Real- time logging shall be supported. Tracing How system can provide enough System log to trace command executer and execute history. 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 Call Trace and trouble-shooting function and its limitation. Provide End-to-End Trace function and user case example. 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. Self Organizing Networks (SON) Please provide LTE SON and network elements architecture and standard followed. 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 offered ANR function shall support to implement SON - Automatic Neighbor Relation for LTE. 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. SON FM, CM, PM: Please provide SON related network management function and explain FM, CM, PM functionality separately. Please provide SON northbound and southbound API interface input data format. Please provide DCN bandwidth requirement for collecting SON related data. Please provide eNodeB and EPCs Self-Configuration, self-optimization, self-healings explanation and their related use case. Please provide eNode and EPC how self-configuration retrieves data for pre-execute analysis data and setting items. Also, executed result benefit analysis. 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.1561

Q.1562 Q.1563 Q.1564

17.9. Q.1565 Q.1566

Q.1567 Q.1568

Q.1569

Q.1570 Q.1571 Q.1572 Q.1573 Q.1574 Q.1575

Q.1576 18 18.1. Q.1577 Q.1577 A. Q.1577 B. Q.1577 C. Q.1577 D. Q.1578 Q.1579 Q.1580 Q.1581 Q.1582 Q.1583 Q.1584 Q.1585

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. Subscriber Data Management Solution General Product Information 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 The supplier shall state the kind of database standard chosen for subscriber database. The supplier shall provide the description about Directory service concept. The supplier shall list the functional components of the database and explain in brief about each component. The supplier shall state all entities and the interfaces from database to other components with diagram. The supplier shall state the scalability of database in order to accommodate more users in future. The supplier would ensure highly redundancy of the database. Administrations and performance monitoring tool shall be supported. 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. 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. 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. Supplier shall support unified provisioning system and unified interface [Provisioning Gateway]. The Supplier shall describe the provisioning applications and hardware needed in detail. The Supplier shall clarify how its system allows performing the Bulk update for user profiles. 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. The supplier must provide all hardware specifications of database solution. The supplier shall describe the hardware platform used for the Database Layer. 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. Technical Requirements The supplier shall explain the architecture of the provisioning system.

Q.1586

Q.1587 Q.1587 A. Q.1587 B. Q.1588 Q.1589 Q.1590 Q.1591 Q.1592

Q.1593

Q.1594 Q.1595

18.2. Q.1596

Q.1597 Q.1598 Q.1599 Q.1600 Q.1601 Q.1602 Q.1603 Q.1604 Q.1605 Q.1606 Q.1607 Q.1608 Q.1609

The Supplier shall state the provisioning options available for subscriber provisioning. The Provisioning Front End shall support SPML interface. The supplier shall state what tools are available for analysis, extraction, manipulation and changing of sub-scriber data. The supplier shall state different types of SPML requests supported by the Provisioning interface. The supplier shall support the mechanism used, in case of errors in provisioning. The supplier shall explain how the Provisioning system can be embedded with operators existing CRM/CCC system. The Provisioning system shall be able to address subscribers via the IMSI or MSISDN. The Supplier shall state if provisioning can be done directly to the Database Layer (bulk mode). The supplier shall state different types of provisioning tasks supported in the solution for provisioning. The supplier shall state the different types of interfaces supported for subscriber and service data admin-istration. The supplier needs to specify how CRM/CCC transfers a bulk provisioning command to the database di-rectory. The supplier shall state SPML requests supported by the Provisioning interface for mass provisioning. 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 in technical details how the proposed system will be secured (all types of security shall be provided). The supplier shall explain in details the software/hardware path, and additional roadmap require-ments/features. Supported Standards The Supplier shall state the compliancy to all the relevant ETSI standards. The Supplier shall state the compliancy to IETF standards. The Supplier shall state the compliancy to ITU-T standards. The Suppliers equipment shall comply with EN 300 386-2, environment class "other than telecommuni-cation centers". Database hardware shall be complies with RoHS standards in manufacturing and deployment of equipment. Database requirements The supplier shall state the architecture of the database. The supplier shall provide the details of interfaces of the database. The supplier shall explain the authentication mechanism for client accessing the database. The supplier shall state the scalability of database in order to accommodate more users in future. The supplier shall state database open standards. The supplier shall state the Backup and restore (B&R) mechanism present in the database. The supplier shall describe what database mechanisms are used to generate a persistent back up of a real time in-memory database (e. g. a mirroring of the inmemory data base to disk as a one-to-one replica). 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. Data (subscriber) model shall be extendable in order to be used by other applications.

Q.1610 Q.1611 18.3. Q.1612 Q.1613 Q.1614 Q.1615 Q.1616 18.4. Q.1617 Q.1618 Q.1619 Q.1620 Q.1621 Q.1622 Q.1623 Q.1624 Q.1625 Q.1626

Q.1627

The subscriber database Triad shall update all instances of the same data in a synchronous or asynchronous manner such that the Front End Applications have a consistent view of the data. The database system must be robust to handle database configuration changes in real-time and meet high performance (read/write) expectation. In any update to the data entries or database, the database system must ensure the data accuracy and consistency. Protocols and Interfaces 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 compliancy of the protocols with other Components shall be described. Detailed information about LDAP shall be provided. The Database must be flexible to adapt to the rapidly growth of subscriber dynamic changing data/value (attribute growth). The Database must be flexible to support future network element interfaces and standard protocols for re-trieving data or adaptable to data virtualization. The Database system must be robust to handle data entries changes, in real-time and meet high performance (read/write) expectation. The Database system must support LDAP protocol and LDAP security standards defined in the LDAP v3 RFCs. The Database system must support secure connection for external applications. The supplier shall support secure communications protocols for all Network Element Access. Hardware information The supplier must provide all hardware specifications of database solution. The supplier shall describe the hardware platform used for the Database Layer.

Q.1628 Q.1629 18.5. Q.1630

Q.1631 Q.1632 Q.1633 Q.1634 Q.1635 Q.1636 Q.1637 Q.1638 18.6. Q.1639 Q.1640 Q.1641 Q.1642 Q.1643 Q.1644 18.7. Q.1645 Q.1646 Q.1647 Q.1648 18.8. Q.1649 Q.1650 Q.1651 Q.1652 Q.1653

The hardware must meet the highest industry standard of high availability, fault tolerance and scalability. 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 System shall be designed without any single point of failure in term of hardware, software, modules and interfaces. The Supplier shall describe the provisioning applications and hardware needed (e. g. Provisioning Gateway, etc.) in detail. Other information The supplier must identify all Operation System, Networking, Application Software and any other software licenses required. The supplier must provide the operating system details for database solution. The tenderer shall support and explain overload control mechanism. The supplier must provide tools to import and export data in different formats (LDIF, XML, CSV, ASCII, logs, etc.). Operations, Administration, Maintenance and Provisioning (OAM&P) The supplier shall explain the architecture of the provisioning system. The Supplier shall state the provisioning options available for subscriber provisioning. The Supplier shall describe his provisioning application and the hardware needed (e. g. Provisioning Gateway, etc.) in detail. The supplier shall state what tools are available for analysis, extraction, manipulation and changing of sub-scriber data. The supplier shall state different types of SPML requests supported by the Provisioning interface.

Q.1654 Q.1655 Q.1656 Q.1657 Q.1658 Q.1659 Q.1660 Q.1661 Q.1662 Q.1663 Q.1664

The supplier shall support the mechanism used, in case of errors in provisioning. The supplier shall explain how the Provisioning system can be embedded with operators existing CRM/CCC system. The supplier shall state different types of provisioning tasks supported in solution for provisioning. The supplier shall state the different types of interfaces supported for subscriber and service data admin-istration. The supplier needs to state if the provisioning application supports graphical management interface. The Provisioning Front End shall accept and process provisioning requests with commands for bulk operations. The supplier needs to specify how CRM/CCC transfers a bulk provisioning command to the database di-rectory. The supplier shall state SPML requests supported by the Provisioning interface for mass provisioning. By default in which order is the bulk order information displayed. The supplier needs to state if any other method of sorting is supported. 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. 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 specify the provisioning interface(s) type. The supplier shall describe in technical details how the proposed system will be secured (all types of security shall be provided). System Performance and quality indicators 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" Functionality for triggering of PM alarms on threshold monitoring of counters and KPIs shall be provided. Details of QoS handling end-to-end in your solution. 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. Network Interfaces and Protocols 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. Detailed information about LDAP shall be provided. The Database solution shall have logs, error handling, administration, and performance monitoring tool. The Database must be flexible to adapt to the rapidly growth of subscriber dynamic changing data/value (attribute growth). The Database must be flexible to support future network element interfaces and standard protocols for re-trieving data or adaptable to data virtualization. The Database supplier must explain the network element interfaces and the standard protocols and how these elements interface with the Database system. The Database system must be robust to handle data entries changes, in real-time and meet high performance (read/write) expectation. The Database system must be robust to handle database configuration changes in real-time and meet high performance (read/write) expectation. In any update to the data entries or database, the Database system must ensure the data accuracy and consistency. The Database system must support LDAP protocol and LDAP security standards defined in the LDAP v3 RFCs. The Database system must support secure connection for external applications. The system must support dynamic transactions (read only, write only, mixed operations, etc.) from the Ap-plications/Clients and meet the traffic volume expectation.

Q.1665 Q.1666 18.9. Q.1667

Q.1668 Q.1669 Q.1670

18.10. Q.1671

Q.1672 Q.1673 Q.1674 Q.1675 Q.1676 Q.1677 Q.1678 Q.1679 Q.1680 Q.1681 Q.1682

Q.1683 Q.1684

The supplier must provide the details about how the synchronization and data integrity is retained amongst the proposed servers. 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 supplier shall support secure communications protocols for all Network Element Access. 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. Roadmap Requirements Please specify a roadmap of subscriber database management standard basic and optional features and their timelines. 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 Supplier shall state the availability roadmap of any such products, and state any interdependencies between them. Mediation Solution LTE Support Vendor must specify mediation system compatibility with enhanced support for LTE. Vendor ability to update PGW-CDRs support via both FTP and GTP interfaces. Specify ability to support SGW-CDRs support via both FTP and GTP interfaces. Ability to integrate with 3rd party GGSN via Gy interface, Diameter Ro protocol support as per 3GPP rec-ommendation. 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. Ability to display consolidated view of status of whole product and provide clear view if the product is working properly. Active Mediation Ability to support online mediation using Diameter protocol. Ability to integrate with subscriber profiling system through XML/SOAP/LDAP/SQL interface. Ability to integrate with ISN through DCCA (Diameter credit control application). Ability to integrate with 3rd party SMSC & MMSC for real-time credit check on the south bound. Ability to integrate with SMSC & MMSC through IACC interface. Ability to integrate with SMSC on northbound using SMPP/CIMD interface. The offered system shall be able to handle convergent mediation (online and offline simultaneously). 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. Ability to support TCP/IP interface. Ability to support HTTP interface. Ability to support CORBA interface. Ability to interface with external balance holder. Ability to integrate with multiple third-party online charging systems. Event File Collection The ability to collect CDR data from MSC platform. The ability to collect CDR data from Acision SMSC platform.

Q.1685 Q.1686

18.11. Q.1687 Q.1688

Q.1689 19 19.1. Q.1690 Q.1691 Q.1692 Q.1693 Q.1694 Q.1695 19.2. Q.1696 Q.1697 Q.1698 Q.1699 Q.1700 Q.1701 Q.1702 Q.1703

Q.1704 Q.1705 Q.1706 Q.1707 Q.1708 19.3. Q.1709 Q.1710

Q.1711 Q.1712 Q.1713 Q.1714 Q.1715 Q.1716 Q.1717 Q.1718 Q.1719 Q.1720 Q.1721 Q.1722

The ability to collect CDR data from Charging Gateway. The ability to collect CDR data from MMSC. The ability to collect data directly from SGSN. The ability to collect data directly from GGSN. The ability to collect data directly from Cisco CSG. The ability to collect data files from generic source platforms using FTP and SFTP. The ability to support push delivery where the source platform delivers data files to the mediation platform. The ability to configure an unlimited number of collection sources. The ability to collect events from multiple devices simultaneously, all processes operating independently from each other. The ability to stop or disable collection of event data from any one source without effecting event collection from other sources. The ability to securely store login, password/certificate and addressing details for accessing each device. 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 log the date, time, source, size and filename of each file collected In the case of record delimited text files, the ability to count and log the number of records within the col-lected file. The ability to verify the completeness of the collected file against the original source either via file size, checksum or other method The ability to support flexible source file naming with no length or content restriction other than that specified by the underlying file system. The ability to easily configure the collectors' file naming The ability to archive on the remote (source) system, any files successfully collected (subject to capabilities of the source platform) 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. The ability to collect zero length files.

Q.1723 Q.1724 Q.1725 Q.1726 Q.1727 Q.1728 Q.1729

Q.1730

Q.1731

Q.1732

Provision for the frequency of polling to be user configurable.

Q.1733

The ability to store an unlimited number of collection plans or schedule configurations

Q.1734

The ability to be configured to allow different collection plans for different days of the week and different times of day.

Q.1735

The ability to configure filename patterns and wildcards for filename matching to enable other files to reside in the same source directories and not be effected by the file transfer mechanism. 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). A mechanism to prevent the duplicate collection of the same file (for instance, by rename or archiving of the source file after a successful transfer). The ability to not commit as collected, files on the source platform if file transfer or validation of file com-pleteness fails.

Q.1736 Q.1737 Q.1738 Q.1739

Q.1740 Q.1741 Q.1742 19.4. Q.1743 Q.1744 Q.1745 Q.1746 Q.1747 Q.1748 Q.1749 Q.1750 Q.1751

The ability to attempt re-collection of previously failed files. The ability to log all file collection failures including date/time, source, filename, reason for failure. The ability to raise an alarm on file collection failure, or after a number of repeated file collection failures. Event File Delivery The ability to deliver processed events to external systems in real-time. The ability to deliver processed events to external systems via a file-based batch mechanism. The ability to securely store login, password/certificate and addressing details for accessing each target system. The ability to deliver files to local systems (using a locally mounted file system). The ability to deliver files to remote systems using FTP, SFTP. The ability to store an unlimited number of delivery plans or schedule configurations. The ability to be configured to allow different delivery plans for different days of the week and different times of day. The ability to run an unlimited number of delivery processes in parallel. 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). The ability to disable one delivery process without effecting other delivery processes The capability of delivery processes to work independently of the event collection, and event processing processes. The ability to archive event files after successful transfer. The ability to remove event files after a successful transfer. The ability to detect, log and report delivery failures. The ability to store locally files that fail to deliver. The ability to repeatedly attempt to re-transmit files that fail delivery (based upon a configurable re-try delay). 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 transfer the same file to multiple target locations, not necessarily on the same remote systems. 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. The ability to configure different delivery schedules for different days of the week and different times of day. 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. 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.

Q.1752 Q.1753 Q.1754 Q.1755 Q.1756 Q.1757 Q.1758 Q.1759 Q.1760 Q.1761 Q.1762 Q.1763 Q.1764

Q.1765

Q.1766 Q.1767 Q.1768 Q.1769 Q.1770 Q.1771 Q.1772 Q.1773 Q.1774 Q.1775 Q.1776 Q.1777 19.5. Q.1778 Q.1779 Q.1780 Q.1781 Q.1782 Q.1783 Q.1784 Q.1785 Q.1786 Q.1787 Q.1788 Q.1789 Q.1790 Q.1791 Q.1792 Q.1793

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. The ability of the mediation component to not archive or remove the local file if the file transfer is not suc-cessful. The ability to compress the target file before or after delivery if so configured. The ability to remove the remote file in case of incomplete file transfer. The ability to detect, log and report all typical file transfer errors (file permissions, login failures etc). The ability to detect, report and recover from disk full events at the remote endpoint when transferring files. The ability to raise and alarm on file delivery failure, or after a number of repeated file delivery failures. The ability to re-transmit any files any number of times under the control of the system administrator. The ability to deliver zero length files. 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. 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. The ability to transform input filenames to different target filenames during delivery based on configurable pattern rules. Event File Processing (Input) The ability to process files in ASN.1 format. The ability to process files in NRTRDE TD.35 format. The ability to process files in TAP 3.10 format. The ability to process files in TAP 3.11 format. The ability to process GTP' CDRs. The ability to process files in plain text with a single record format. The ability to process files in plain text with multiple record formats. The ability to process files in XML format. The ability to process files in a user definable binary format. The ability to process files with user definable record terminators. The ability to process files with fixed length record formats. The ability to process files with variable length record formats. The ability to process files with user definable field delimiters. The ability to validate every event files to ensure that it is complete. 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. 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). The ability to log duplicate event files and suspend processing of that file. The ability to override the duplicate check on a source by source basis. The ability to override the duplicate check on a file by file basis.

Q.1794 Q.1795 Q.1796

Q.1797 Q.1798 Q.1799 Q.1800 Q.1801 Q.1802 Q.1803 Q.1804 Q.1805 Q.1806

The availability of an easily configurable dup-check key. 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 disable file-sequencing checks via a user parameter. The ability to process event files in an out of sequence order if so configured. The ability of the event file processing modules to be independent of the event collector processes. The ability for event files processing to continue if the event collector process is not running. The ability for event files processing to continue if the network element is not available. 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. The ability to log details of each file processed, including date and time processing starts, number of records processed and total processing time. 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 zero length files. 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). Event File Processing (Output) The ability to output files in ASN.1 format. The ability to output files in NRTRDE TD.35 format. The ability to output files in TAP 3.10 format. The ability to output files in TAP 3.11 format. The ability to output files in plain text with a single record format. The ability to output files in plain text with multiple record formats. The ability to output files in XML format. The ability to output files in a user definable binary format. The ability to create files with user definable record terminators. The ability to create files with fixed length record formats. The ability to create files with variable length record formats.

Q.1807 Q.1808 Q.1809 Q.1810 Q.1811

Q.1812 Q.1813

19.6. Q.1814 Q.1815 Q.1816 Q.1817 Q.1818 Q.1819 Q.1820 Q.1821 Q.1822 Q.1823 Q.1824

Q.1825 Q.1826 Q.1827 Q.1828 Q.1829 Q.1830 Q.1831 Q.1832 Q.1833 Q.1834 Q.1835 Q.1836 Q.1837 Q.1838 Q.1839 Q.1840 Q.1841 Q.1842 Q.1843 Q.1844 Q.1845 Q.1846 Q.1847 Q.1848 Q.1849

The ability to create files with user definable field delimiters. The ability to support user definable output file names. The ability to create output files maintaining a unique sequence number for each file created within each output stream. The ability to embed output file sequence numbers in filenames. The ability to embed the date and time of file creation in the output filenames (in a user definable format). The ability to embed any field or any part of a field from the first record in the file, in the output filename. The ability to embed portions of the input filename in the output filename. The ability to embed the input stream name or identifier in the output filename. The ability to embed the output stream name or identifier in the output filename. The ability to embed the result of a lookup operation in the output filename. The ability to create output files containing header and trailer control records with a user definable format. The ability to embed the number of records in the file within a header record. The ability to embed the number of records in the file within a trailer record. The ability to embed the filename within a header record. The ability to embed the filename within a trailer record. The ability to embed the file creation date and time (in a user definable format) within a header record. The ability to embed the file creation date and time (in a user definable format) within a trailer record. 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. The ability to define the location for the creation of an output file. Provision for the creation of an output file to optionally be able to automatically trigger a file delivery process. The ability to automatically compress an output file immediately after creation. The ability for the file output process to concatenate it's data to the end of an existing output file. The ability for the file output process to add its data to an existing archive file (i.e. tar). The ability to detect and fail gracefully on file write failures (permissions issues, directory naming etc) and disk full events during file writing. 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). 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 of the file creation process to be able to disable itself after a user configurable number of con-secutive file creation failures. The ability to generate zero length files. 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.1850

Q.1851 Q.1852 Q.1853

Q.1854 19.7. Q.1855 Q.1856

The ability to write output records directly to a local or remote Oracle table instead of creating an output file. Event Processing The ability to process events from both real-time and file based collection processes. 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 validate every event record to ensure that it is complete. The ability to validate every event record to ensure that data field values are valid. 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 correlate and aggregate records that originate in different devices. The ability to correlate and aggregate records that originate in geographically separated processes. The ability to correlate and aggregate events of different source formats. The ability to perform event correlation and aggregation in as near real-time as possible. The ability to perform event correlation and aggregation via a file based batch mechanism. The ability to detect and reject any events that are duplicates of events previously processed. The ability to log duplicate events and suspend processing of that event. The ability to override the duplicate check on a source by source basis (e.g. network device, API). 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 process event data records that have missing event parts and combine the remaining parts after a user configurable timeout period. The ability to log any events where an incomplete series of partial events are combined into a single 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. The ability to allocate a reason code, to indicate the reason for filtering, to each "dropped" event. The ability to create one "drop" file for each input file, reusing parts of the input file name to generate the drop file. The ability to define the format of the drop file records in the same way as any other output file. The ability to easily determine from a filter reason code which rule or rules were used to determine that the event shall be filtered. The ability to record all "dropped" events, configurable by the user. The ability to carry out event filtering in real time. The ability to carry out event filtering on file based event processing. The ability to create user defined rules to modify the contents of any field in any record. The ability to use any normal rule facilities and functions when modifying any event. The ability to replace the content of a field based upon a lookup. 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 take an event record and to replicate it, creating one or more additional records in different formats. The ability for replicated records (subject to any duplicate constraints) to travel down the same logic path as the original record. The ability to use rules to detect events matching certain error criteria. The ability to allocate each event in error a reason code to indicate the reason for the error. 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).

Q.1857 Q.1858 Q.1859 Q.1860 Q.1861 Q.1862 Q.1863 Q.1864 Q.1865 Q.1866 Q.1867 Q.1868

Q.1869 Q.1870 Q.1871

Q.1872 Q.1873 Q.1874 Q.1875 Q.1876 Q.1877 Q.1878 Q.1879 Q.1880 Q.1881 Q.1882 Q.1883 Q.1884 Q.1885 Q.1886 Q.1887

Q.1888

Q.1889

Ability to keep statistics relating to errors trapped including but not limited to: total count of the number of events in error, total count for each reason code, total count by collection process or network element. 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. The ability to flag events for reprocessing, both individually and in batches specified by user defined criteria. The ability to modify error or drop events, both individually and in batches specified by user defined criteria. 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 for error/drop event correction and resubmission to be via GUI or scripting. The ability to specify user definable search criteria for resubmission of events. The ability to define known error repair rules to automatically detect and correct known error patterns and to automatically resubmit those records for reprocessing. 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. Provision for resubmitted events to be processed in the same way as original events. The ability to support multiple versions of record formats from sources of the same type (where multiple sources of the same type (for example MSC's) are running different versions of software). The availability of an easily configurable number analysis component. Validation & Enrichment The ability to support lookups to flat files within the mediation platform. The ability to support lookups to database tables local to the mediation platform. The ability to support lookups to remote Oracle database tables. The ability to validate any field within an input record by use of scripting rules. The ability to validate any field within an input record via a look up to a table of allowable values. The provision of pre-build functions for validated common data items such as dates and times. 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. Reference Data Configuration The ability to place all configuration/reference data under source code control (i.e. CVS, SVN, etc). The ability to apply an internal versioning mechanism on all configuration/reference data.

Q.1890 Q.1891 Q.1892 Q.1893

Q.1894

Q.1895 Q.1896 Q.1897

Q.1898

Q.1899 Q.1900

Q.1901 19.8. Q.1902 Q.1903 Q.1904 Q.1905 Q.1906 Q.1907 Q.1908 19.9. Q.1909 Q.1910 Q.1911 Q.1912 Q.1913 Q.1914 Q.1915

The ability to export an entire configuration/reference data set (for importing to another platform i.e. test or production). The ability to import an entire configuration/reference data set from another platform. 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). The ability to assign a starting and ending date and time for all configuration records and reference data.

Q.1916 Q.1917 19.10. Q.1918 Q.1919 Q.1920 Q.1921 Q.1922 Q.1923 Q.1924 Q.1925 Q.1926 Q.1927 Q.1928 Q.1929 Q.1930 Q.1931 Q.1932

The ability to store multiple versions of the same configuration and reference data (with the same keys), but which have different start/end date/time values [i.e. records are only unique within a particular date/time period]. The ability to select the correct configuration or reference data which is/was valid at the date and time of the event record. Monitoring & Control GUI A monitoring and control GUI to allow an administrator to stop, start, pause and monitor all mediation pro-cesses. The ability to view all input and output data/file queues. 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. 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. The ability to allow the pausing of data collection from any one data source (i.e. one MSC). The ability to allow the pausing of data collection from any user defined group of data sources (i.e. all MSCs). The ability to allow the pausing of data delivery to any one delivery destination. The ability to allow the pausing of data delivery to any user defined group of delivery destinations. The ability to allow the pausing of core processing for any one data source. The ability to allow the pausing of core processing for any user defined group of data sources. 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]). The ability to view statistics of performance and data latency in terms of time to process a file/CDR from collection to distribution. 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 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 Q.1934 Q.1935

The ability to view statistics of number of events of a specific call scenario, or a set of scenarios, per file. The ability to detect file volume trends on the collectors. 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. Provision for several levels of severity for alarms such that they can be prioritized. The ability to adjust the number of severity levels. The ability to filter out alarms of a particular severity. Provision for all alarms to be logged 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. The ability to provide data for alarms to show graphically against the relevant element in the process diagram Provision for the monitor to be able to be run from remote systems (i.e. not on the mediation platform) Ability for monitoring of all functions and alarms via an industry standard web browser. 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. The ability of the device to raise alarms and send notifications via a variety of signaling devices. The ability of the device to integrate alarms to an enterprise monitoring solution, i.e. HP Openview/ITO

Q.1936 Q.1937 Q.1938 Q.1939 Q.1940

Q.1941 Q.1942 Q.1943 Q.1944 Q.1945 Q.1946

Q.1947 Q.1948

Provision for a public API to be available for other software to raise alarms to the mediation device alarm monitor. 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 limit access to certain functions within the Monitoring & Control GUI on a role basis The monitoring and control GUI shall be available in multiple languages and instantly switchable The monitoring and control GUI shall be delivered with English as the default language. The monitoring and control GUI shall be have French available as a selectable language The ability to provide data for generating user definable tables and graphs of available statistics and trending metrics The ability to provide data for creating user definable dashboards containing statistics tables, graphs, queue information and other available statistical or monitoring information Reporting & Statistics 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. 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 Statistical information retention timeframe shall be configurable (up to a maximum of 6 months of historical data) Trending & Alarming 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.1949 Q.1950 Q.1951 Q.1952 Q.1953 Q.1954 19.11. Q.1955 Q.1956 Q.1957 19.12. Q.1958

Q.1959

The ability to configure trending controls to trigger an alarm when error file levels (percentage or absolute qty of files) pass outside of user defined limits within a user defined time window, over a user defined historical period, with separate metrics available for different user definable day of the week and time of day.

Q.1960

The ability to configure trending controls to trigger an alarm when dropped event levels (percentage or ab-solute qty of records) pass outside of user defined limits within a user defined time window, over a user defined historical period, with separate metrics available for different user definable day of the week and time of day. 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.

Q.1961

Q.1962

Q.1963

Q.1964

The ability to configure trending controls to trigger an alarm when input vs. output data traffic levels (adjusted by dropped, error and duplicated records) vary by more than user defined limits, within a user defined time period, with separate metrics available for different user definable day of the week and time of day.

Q.1965 Q.1966

Q.1967

The ability to configure trending controls to trigger an alarm when aggregation statistics (percentage or ab-solute values) pass outside of user defined limits within a user defined time period, with separate metrics available for different user definable day of the week and time of day. The ability to configure trending controls to trigger an alarm when latency <from file collection to input of core processing> passes outside of user defined limits within a user defined time window, over a user defined his-torical period, with separate metrics available for different user definable day of the week and time of day. The ability to configure trending controls to trigger an alarm when latency <from start to end of core pro-cessing> passes outside of user defined limits within a user defined time window, over a user defined historical period, with separate metrics available for different user definable day of the week and time of day.

Q.1968

The ability to configure trending controls to trigger an alarm when latency <from output of core processing to delivery> passes outside of user defined limits within a user defined time window, over a user defined historical period, with separate metrics available for different user definable day of the week and time of day.

19.13. Q.1969 Q.1970 Q.1971 Q.1972 Q.1973 Q.1974 Q.1975 Q.1976 Q.1977 19.14. Q.1978

Security & Compliance 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 define and allocate specific users and roles for access to the main administration controls (starting & stopping processes, reporting, statistics etc). The ability to protect access to security related data items such as usernames, passwords and certificates (for collection and delivery processes etc). The ability to carry out one-way encryption/hashing when storing passwords. The ability to log all login events to the application. 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 to protect all log files to prevent unauthorized changes to the log file contents. The ability to protect all configuration data in a production environment to prevent accidental or intentional alteration. The ability to hold previous versions of configuration data so that reversion to integral earlier versions is possible. Performance 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). The ability for processing components to be scaled, multiplied or run multi-threaded (to allow additional processed to be created to handle increasing load). The ability to specify a minimum and maximum number of processes allowable per processing component. 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. The ability to allow the administrator to manually start and stop additional processing components within the pre-defined minimum and maximum quantities. 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). Availability The entire system shall remain operational during normal backups. 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 system shall be designed for "always on" operation, allowing it to run without the need for frequent re-starts or regular scheduled downtime. The system shall allow for configuration changes to processing components without the need to stop the entire platform. The system shall allow for script/business logic changes without the need to stop the entire platform. The ability for the platform to monitor its own processes and to automatically restart processes if they fail. The ability to produce alerts if a process fails.

Q.1979 Q.1980 Q.1981 Q.1982

Q.1983 Q.1984 Q.1985 Q.1986 Q.1987 19.15. Q.1988 Q.1989

Q.1990 Q.1991 Q.1992 Q.1993 Q.1994

19.16. Q.1995 Q.1996 20 20.1. Q.1997 Q.1998 Q.1999

Scheduler The ability to create and maintain schedules for timing of automatic process runs (for processes that are not already demonized and always running). The ability to configure schedules based on year, month, day, day of the week, hour minute and second. DNS Solution General The Seller shall state whether to deploy a standalone DNS solution, or integrate with Buyers live DNS connected in Gn network. 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. 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. The Seller shall provide DNS solution to support the LTE to LTE roaming and LTE to legacy network roaming. The DNS solution shall include functionality to allow for the retrieval or provision of additional information regarding the EPC-GW capabilities. The proposed DNS solution shall comply with the following standards. 3GPP TS23.003 3GPP TS29.303 IETF RFC 1035 IETF RFC 2181 IETF RFC 2606 Functional Requirements The DNS shall have the capability to be configured either authoritative (both primary and secondary) or caching DNS. The DNS shall support both types of query mechanism: Recursive and Forwarding. The DNS shall return EPC-GW IP address including Weight Factors. The DNS shall support A and AAAA resource record. The DNS shall support NAPTR resource record those can be prioritized using embedded order and prefer-ence values defined by the DNS administrator. 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. The DNS shall support P-GW Discovering and Selecting for 3GPP access. The DNS shall support P-GW Discovering and Selecting for non-3GPP access. The DNS shall support S-GW Discovering and Selecting in 3GPP roaming case. The DNS shall support S-GW Discovering and Selecting in 3GPP non-roaming case. The DNS shall support MME Discovering and Selecting. The DNS shall support SGSN Discovering and Selecting. The DNS shall support Gateway Selection for SIPTO. The DNS shall support MSC server Discovering and Selecting. The DNS shall support APN Operator Identifier Resolution. The DNS shall support Routing Area Resolution.

Q.2000 Q.2001 Q.2002 Q.2002 A. Q.2002 B. Q.2002 C. Q.2002 D. Q.2002 E. 20.2. Q.2003 Q.2004 Q.2005 Q.2006 Q.2007 Q.2008 Q.2009

Q.2010 Q.2011 Q.2012 Q.2013 Q.2014 Q.2015 Q.2016 Q.2017 Q.2018 Q.2019

Q.2020 20.3. Q.2021 Q.2022 Q.2023 Q.2024 20.4. Q.2025 Q.2026 21 21.1. Q.2027 Q.2028 Q.2029 Q.2030 Q.2031 Q.2032 Q.2033 Q.2034 Q.2035 21.2. Q.2036 Q.2037

The DNS shall support Tracking Area Resolution. Feature Requirements The DNS shall support IPv6. The DNS shall support IPv4v6 dual stack. The DNS shall support GRX/IPX service. The DNS shall support DNS64. Capacities and Performance The Seller shall advise how the DNS is being dimensioned. Performance management shall be provided in term of loading, and traffic statistics. CGNAT Solution NAT Functions The system shall provide IPv4 and IPv6 Dual Stack at the same time. The system shall provide NAT44 and NAT64 functions. The system shall provide Deterministic NAPT function. The system shall provide DS-lite Tunneling function. The system shall provide DNS64 function. The system shall provide the flexibility to define different NAPT timeout period based on different TCP or UDP applications. The system shall support Application Level Gateways (ALGs) for FTP, TFTP, RTSP, HTTP and SIP function. The system shall provide network security function to protect external to internal TCP, UDP and ICMP pro-tocol attack. 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 . Platform Functions For NAPT capacity and requirement expansion, the system shall support module expansion in single chassis. 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 80Gbps L4 NAT throughput in single module and at least 300Gbps L4 NAT throughput 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. Security Solution The Seller shall state compliance to 3GPP Release TS 33.102 and 33.203 for UMTS packet core. The Seller shall state compliance to 3GPP TS 33.401 and 33.210 for Evolved Packet Core and IMS. The Seller is requested to provide information on any additional security mechanisms. The tendered system shall provide User to Network security which protects the network-to-terminal ex-changes over the radio interface. The tendered system shall support provide Network domain security (NDS) which protects the interfaces between the EPS and IMS network nodes. The tendered system shall support algorithm selection and negotiation with Security mode command. 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 both Native and Mapped Security context with the operator configuration control. The tendered system shall support EPS AKA as the authentication and key agreement procedure.

Q.2038 Q.2039 22 Q.2040 Q.2041 Q.2042 Q.2043 Q.2044 Q.2045 Q.2046 Q.2047 Q.2048

Q.2049 Q.2050 Q.2051 Q.2052 Q.2053 Q.2054 Q.2055 Q.2056 Q.2057 23

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 tendered system shall support authentication and key agreement in compliance with 3GPP TS 33.401. The tendered system shall support user data and signaling confidentiality by supporting ciphering and in-tegrity to NAS signaling. The tendered system shall be able to select NAS Integrity Protection and Ciphering algorithm(s). The tendered system shall support intra-RAT security context transfer in compliance with 3GPP TS 33.401. The tendered system shall support security context transfer to/from GERAN and UTRAN in compliance with 3GPP TS 23.401. The tendered system shall support the AS security mode command procedure as defined in TS 33.401. The tendered system shall support the NAS Security Mode Command procedure as defined in TS 33.401. The proposed MME shall support the ability to request a UE to provide it's IMEI in the NAS Security Mode Complete message. IP Transport Solution

23.1. Q.2058 Q.2059

General Requirements The Seller shall build a IP MPLS Backbone that is capable of providing end-to-end transport from core to access network and fulfill LTE various service requirement The system architecture of the proposed solution shall be modular, scalable and flexible, in order to allow the future scaling of the equipment capacity in accordance with the network requirement. 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. The proposed system shall support separated data and control planes architecture. The routing engine, line cards, switching control board and power supplies shall be hot swappable or hot pluggable to minimize service disruption. The proposed equipment must be able to support QoS with intelligent traffic management. 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)

Q.2060

Q.2061

Q.2062 Q.2063 Q.2064 Q.2065 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 Q.2066 A. Q.2066 B. Q.2066 C. Q.2066 D. Q.2066 E. Q.2066 F. Q.2066 G. Q.2066 H. Q.2066 I. Q.2066 J. Q.2066 K. Q.2066 L. Q.2066 M. Q.2066 N. Q.2066 O. Q.2066 P. Q.2066 Q. Q.2066 R. Q.2066 S. Q.2067 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.

RFC 5305, IS-IS Extensions for Traffic Engineering RFC 1058, Routing Information Protocol RFC 2082, RIP-2 MD-5 Authentication RFC 2453 RIPv2 The proposed system shall support BGP routing protocol and compliance to the following RFC standards RFC 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 RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option RFC 2439, BGP Route Flap Damping RFC 2545, Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing RFC 2796, BGP Route Reflection RFC 2858, Multiprotocol Extensions for BGP-4 RFC 2918, Route Refresh Capability for BGP-4 RFC 3065, Autonomous System Confederations for BGP RFC 3107, Carrying Label Information in BGP-4 RFC 3392, Capabilities Advertisement with BGP-4 RFC 4271, A Border Gateway Protocol 4 (BGP-4) RFC 4724, Graceful Restart Mechanism for BGP RFC 4781, Graceful Restart Mechanism for BGP with MPLS RFC 4893, BGP Support for Four-octet AS Number Space The proposed system shall support IPv6 routing protocol and compliance to the following RFC standards RFC 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

Q.2067 K. Q.2067 L. Q.2067 M. Q.2067 N. Q.2067 O. Q.2067 P. Q.2067 Q. Q.2067 R. 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 Q.2068 A. Q.2068 B. Q.2068 C. Q.2068 D.

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

Q.2068 E. Q.2068 F. Q.2068 G. Q.2068 H. Q.2068 H. (I) Q.2068 H. (iI) Q.2068 H. (Iii) Q.2068 H. (Iv) Q.2069 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 Q.2070 A. Q.2070 B. Q.2070 C. Q.2070 D. Q.2070 E. 23.2.

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 The proposed system shall support QoS features 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. 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)

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

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. The proposed system shall support a variety of optical or electrical interfaces, including 100 Gigabit Ether-net,10 Gigabit Ethernet and Gigabit Ethernet. 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 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 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. RAN Aggregation Node The proposed RAN Aggregation Router platform must support at least 5Tbps system switching capacity. The proposed RAN Aggregation Router platform must be with at least 2Bpps routing forwarding rate.

Q.2076

Q.2077 Q.2078

Q.2079

Q.2080 Q.2081 Q.2081 A. Q.2081 B. Q.2081 C. Q.2081 D. Q.2081 E. Q.2082 Q.2082 A. Q.2082 B. Q.2082 C. Q.2082 D. Q.2082 E. Q.2082 F. Q.2082 G. Q.2082 H. Q.2082 I. Q.2083 23.3. Q.2084 Q.2085

Q.2086 Q.2087 Q.2088 Q.2089 Q.2090 Q.2091

The proposed RAN Aggregation Router platform must support at least 8 slots for line cards with redundant route processor configured. The proposed RAN Aggregation Router platform must support at least 240Gbps throughput per slot. 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. The proposed system shall support a variety of optical or electrical interfaces, including 100 Gigabit Ether-net,10 Gigabit Ethernet and Gigabit Ethernet. 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 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 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. SGi Border Router Node The proposed Border Router platform must support at least 5Tbps system switching capacity. The proposed Border Router platform must be with at least 2Bpps routing forwarding rate.

Q.2092

Q.2093 Q.2094 Q.2094 A. Q.2094 B. Q.2094 C. Q.2094 D. Q.2094 E. Q.2095 Q.2095 A. Q.2095 B. Q.2095 C. Q.2095 D. Q.2095 E. Q.2095 F. Q.2095 G. Q.2095 H. Q.2095 I. Q.2096 23.4. Q.2097 Q.2098

Q.2099 The proposed Border Router platform must support at least 8 slots for line cards with redundant route pro-cessor configured. Q.2100 The proposed Border Router platform must support at least 240Gbps throughput per slot. Q.2101 The proposed equipment shall support redundant route processors. Upon any failure of the primary route processor, it is expected that: Failover to the second route processor shall be automatic, no manual intervention is required. Q.2102 The proposed equipment shall have redundant switching fabric. The supplier shall indicate the number of switching fabrics adopted and working mode, either hot standby mode or load sharing mode.

Q.2103 Upon any failure of one switching fabric, the remaining switching fabrics shall be capable of continuing the forwarding of packets to all cards at wire speed. Q.2104 The proposed equipment shall have redundant power supply. In case of any failure of one power supply, it is expected that: The remaining power supply must be able to supply the power requirements of a fully loaded chassis. Removal or Insertion of power supplies can be carried out without any power interruption to the router. The supplier shall indicate the number of power suppliers and their working mode, either hot standby mode or load sharing mode. Q.2105 The proposed equipment shall have redundant fans, and upon any failure of one fan, the remaining fans shall provide sufficient airflow to cool a fully populated chassis. Q.2106 The proposed system shall support a variety of optical or electrical interfaces, including 100 Gigabit Ethernet, 10 Gigabit Ethernet and Gigabit Ethernet. Technical Specifications for Border Gateway Router Q.2107 The proposed system shall support at least the following scaling figure: Q.2107 A. Q.2107 B. Q.2107 C. Q.2107 D. Q.2107 E. Q.2108 Q.2108 A. Q.2108 B. Q.2108 C. Q.2108 D. Q.2108 E. Q.2108 F. Q.2108 G. Q.2108 H. Q.2108 I. Q.2109 23.5. 4Million route entries (RIB) 1Million forwarding entries(FIB) 250 BGP peers 250 OSPF adjacencies 1000 MPLS VRFs capacity The proposed system shall support the following GE and 10GE Interface Type 1000 Base-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 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. Technical Specifications for Border Gateway Router

Q.2110 The proposed equipment shall support redundant route processors. Upon any failure of the primary route processor, it is expected that: Failover to the second route processor shall be automatic, no manual intervention is required. Q.2111 The proposed equipment shall have redundant switching fabric. Upon any failure of one switching fabric, the remaining switching fabrics shall be capable of continuing the forwarding of packets to all cards at wire speed. Q.2112 The proposed Border Gateway platform shall have redundant power supply. Q.2113 The proposed Border Gateway platform shall have redundant fans, and upon any failure of one fan, the remaining fans shall provide sufficient airflow to cool a fully populated chassis. Q.2114 The proposed Border Gateway platform shall support BGPv4, OSPF, IS-IS routing protocol and BGP 4-byte Autonomous System Numbers (ASN). Q.2115 The proposed Border Gateway platform shall support OSPFv3 IS-IS and BGPv4 for IPv6

Q.2116 The proposed Border Gateway platform shall support GPRS Tunneling Protocol (GTP) version 0, GTP ver-sion 1 and GTP version 2. Q.2117 The proposed Border Gateway platform shall support IPSec Q.2118 The proposed Border Gateway platform shall support GRE Tunnel. Q.2119 The proposed Border Gateway platform shall support logging feature. 23.6. Operation and Maintenance (O&M)

Q.2120 The seller shall provide the OAM aggregator switch at each core site. Q.2121 The following Management access methods must be supported: Q.2121 A. Q.2121 B. Q.2121 C. Q.2122 CLI via console CLI via telnet and ssh. Out-band management via Fast Ethernet interface. The proposed system shall supports TACACS+ or Radius Authentication protocol

Q.2123 The proposed system shall support SNMP (Simple Network Management Protocol) Agent and SNMP MIB. 23.7. Environmental Conditions and Safety Standard

Q.2124 Environmental Conditions Q.2124 A. Q.2124 B. Q.2124 C. Q.2125 24 24.1. Voltage :42V to 56V Temperature: 5 ~ 40 Humidit : 20 ~ 80 % Safety and Electronic Standard: Please describe the safety and electronic standard CBC Solution General Requirement

Q.2126 The Bidder shall describe technical architecture for CBC. Q.2127 CBC solution will be responsible to broadcast messages to the Buyers subscribers on 4G (LTE) networks. Q.2128 The CBC shall be interworking with Buyers 4G (LTE) network vender. Q.2129 Cell Broadcast messages shall be distributed to mobile phones located in a certain area, as specified by authorized person in Buyer or the regulator. Q.2130 The smallest area to be addressed is a single radio cell. Q.2131 The largest area to be addressed is the complete 4G (LTE) network. Q.2132 Cell Broadcast messages shall be broadcasted up to 15 pages, each page contains 82 octets. Q.2133 Any proposed solution shall be standards based.

24.2.

Functionality Requirements Functionality; The CBC may be connected to several MMEs. The CBC may be connected to several CBEs. The CBC shall be responsible for the management of CBS messages including:

Q.2134 Allocation of serial numbers; Q.2135 Modifying or deleting CBS messages held by the MME; Q.2136 Initiating broadcast by sending fixed length CBS messages to a MME for each language provided by the cell, and where necessary padding the pages to a length of 82 octets (as per 3GPP TS 23.038); A. The proposed system shall support at least UCS-2 Coding. Q.2137 Determining the set of cells to which a CBS message shall be broadcast, and indicating within the Serial Number the geographical scope of each CBS message; Q.2138 Determining the time at which a CBS message shall commence being broadcast; Q.2139 Determining the time at which a CBS message shall cease being broadcast and subsequently instructing each MME to cease broadcast of the CBS message; Q.2140 Determining the period at which broadcast of the CBS message shall be repeated; Q.2141 Determining the cell broadcast channel in LTE, on which the CBS message shall be broadcast. Q.2142 For ETWS, when CBS transmits emergency messages, allocation of "emergency indication" to differentiate it from normal CBS messages, including the "Cell ID/Service Area ID list" , "warning type", "warning message". If "warning type" is of 'test', only UEs which are specially designed for testing purposes may display warning message. Q.2143 The architecture of the CBC system for content submission must be completely separated from the topology of the Buyers existing network. Q.2144 The architecture of the CBC network is described in CBC high-level architecture of the platform for CBC and its interfaces. Q.2145 The Bidder shall inform and briefly describe all the constituent components presented in the CBC system. Q.2146 The Bidder shall submit the list of features (features) available for any part of the CB Platform, indicating, where appropriate, the basic features, options and those that were listed and necessary for the operation of this solution. Q.2147 The Bidder must submit / inform CBC system for Traffic: A. The throughput license, support at least 3 mes-sages per minute, can be upgraded to 30 messages per minute without hardware expansion. Q.2148 The proposed solution must support at least 25 MMEs in total for 4G network in Buyer simultaneously. The maximum number of cell controller shall be expandable to 2,500 MMEs. The maximum number of radio cell shall be expandable to 500,000 cells. Q.2149 The interfaces supported, the CBC shall support at least 1 CBE connection, can be expandable up to 1000 CBEs concurrently. The CBC shall support HTTP/HTTPS interface protocol with the CBE connections. Q.2150 The CBC must guarantee availability of capacity on the air-interface to the mobile device for public warning type messages. Q.2151 The proposed solution must support 4G (LTE) connectivity according to the 3GPP TS 23.041, TS 22.268 and TS 29.168 standards Q.2152 The proposed system shall support ETWS functionality according to 3GPP standards. Q.2153 The CBC system shall support High Availability and Geographic Redundancy mechanism. The Bidder shall propose active/standby redundant architecture for the CBC in this tender. The Bidder shall detail the architecture and recovery mechanisms in case of failure of server, signalling and interface link. Q.2154 The Bidder shall detail the architecture and mechanisms to support dual node geographic redundancy at different cities as optional. 24.3. External Interfaces and Management

Q.2155 For LTE, SBc Application Part (SBc-AP) interface between the Mobility Management Entity (MME) and the Cell Broadcast Centre (CBC).

Q.2156 When a CB-message is stopped, the cell controller must report the number of broadcasts per radio cell in the statistics interface. Q.2157 The following 3GPP standards must be supported: 3GPP TS 23.041, 3GPP TS 48.049, 3GPP TS 25.419, 3GPP TS 29.168. Q.2158 The proposed system solution must support the MME interfaces of all leading network suppliers (SBc-AP). Q.2159 The following 3GPP standards must be supported: 3GPP TS 29.168. Q.2160 The mapping of geographical area information to cells must be a task of the CBC. Q.2161 The CBE interface must be able to access the functions of the CBC. Q.2162 The CBC will accept calls from CBEs and addresses cell controllers without operator intervention. Q.2163 The CBE interface will accept requests, process them and transmit error-messages or confirmations to the CBE. Q.2164 The CBE interface must support HTTP based protocols with security connection. Q.2165 The proposed system must be able to report to the CBE on the success/failure of message broadcast within 3 minutes after the message was submitted. Q.2166 The CBE and CBC interface shall support the following functions: Q.2166 A. Q.2166 B. Q.2166 C. Q.2166 D. 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. CBC Login CBC Logout Change Password Create Permissions (includes Area Manage/View; MME Manage/View; Manage/View CBC Message; Manage Emergency Message; Manage/View Cells; Execute Cell Loader; Manage/View GSMGateway; View Reports & Manage/View Security Administration). Create 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

Q.2166 M. Q.2166 N. Q.2166 O. Q.2166 P. Q.2167

Get All MMEs Get MME Gateway Status Get Cells Counters & Status Get BSC Vendors Information The proposed system allows CB messages to be sent directly or to be given a specified start time.

Q.2168 Immediate Execution: The Cell Broadcast Entity (CBE) requests without a start time will be executed as soon as possible. Q.2169 The proposed system shall support Index Messages Q.2170 The proposed CBC system must Support for priority messages. Q.2171 When a priority message is submitted, all non-priority messages that are currently being broadcast in the area where the warning message shall be willmessages be stopped temporarily. Q.2172 broadcasted, After the priority have finished, the original commercial messages will automatically be restarted. Q.2173 The system shall comply with the 3GPP standards as mentioned below: Q.2173 3GPP A. Q.2173 3GPP TS 22 268, PWS Requirements A. (i) Q.2173 3GPP TS 23.038 version 9.1.1 Alphabets and language-specific information or later. A. (ii) Q.2173 3GPP TS 23 041, Technical realization of Cell Broadcast Service (CBS) A. (iii) 3GPP TS 25 419, UTRAN Iu-BC Interface: Service Area Broadcast Protocol Q.2173 A. (iv) 3GPP TS 29 168, Cell Broadcast Centre interfaces with Evolved Packet Core Q.2173 A. (v) Q.2173 3GPP TS 48 049, Base Station Controller - Cell Broadcast Centre (BSC-CBC) interface specifi-cation A. (vi) The system shall comply with the CMAS standards as mentioned below: Q.2174 Q.2174 ATIS-0700006 - CMAS via GSM-UMTS A. Q.2174 ATIS-0700010 - CMAS via EPC B. 25 SMSC Solution 25.1. Service Feature Requirement Q.2175 The SMSC shall be able to store and forward short/long messages Q.2176 The SMSC system shall support to store and forward long SMS which have length more than 160 characters or 140 bytes. Q.2177 SMSC shall able to according the pre-defined calling /called numbers and Type of Number and Numbering Plan or global title to route to or modified the Calling/Called number and Type of Number and Numbering Plan then route to dedicated SMSC or dedicated node. Q.2178 SMSC is needed to support SMS direct delivery. Mobile-to-mobile and application-to-mobile messages will be first arrived the SMSC which try to deliver the message directly to the destination (without performing store-and-forward function immediately). If the SMS messages could not be delivered in the direct delivery, it shall be treated for store and forward delivery.

Q.2179 SMSC system shall support SIGTRAN (M3UA) for telecom interfaces towards traditional 2G/3G GSM Net-work Q.2180 Being an SMSC for LTE-IMS network, the SMSC shall also support interfacing with IMS network based on 3GPP TS24.229. Q.2181 Shall support multi-languages with standing protocol (i.e. UTF-8); Q.2182 System shall be built in a fully high available architecture, supplier shall require to state clearly how HA works in the solution proposal. Q.2183 Capacity Proposed SMSC shall support at least the following capacity Q.2183 250K Subscriber A. Q.2183 100 Message Delivery Attempt per second B. Q.2183 CDR Log Storage for at least 15 days C.

25.2.

Operation, Alarm & Monitoring

Q.2184 The platform shall provide Graphical-based centralized tools or application program interface (API) for ad-ministrative actions. Q.2185 The platform shall have the capability to provide traffic performance data on incoming and outgoing route Q.2186 Q.2187 The system shall have the capability to provide data on its hardware performance such as CPU, memory consumption, disk space, etc. Q.2188 System Alarm Indications and Automatic System Recovery.Visual alarm display is required providing fault counters for the following fault situations. Automatic recovery from the below fault situations shall be available. Q.2188 A. Q.2188 B. Q.2188 C. Q.2188 D. Q.2188 E. Q.2188 F. Q.2188 G. Q.2188 H. Q.2188 I. Connection error to external network (E1, TCP/IP, etc..) System Congestion warning General Application Flow and error situation behavior Hard disc usage size warning (over 80%) Database access error General System failure System fault report Application/internal modules failure All alarms of each component shall be sent to Operators Centralized Alarm server. There are two options for Alarm triggering: Option 1 Alarm Log To generate Alarm log in specific format Option 2 - SNMP Module It shall support SNMP and SNMP module can gather all the system or performance information for the pro-cesses and systems running on various systems. If a registered entity in the MIB file is down, then the OAM Master raises an alarm with the define criticality for the error to the operator's SNMP server Reporting

25.3.

Q.2189 Overall short message successful rate report (i.e. successful rate of 1st attempt, 2nd attempt, 3rd attempt and rest of attemps) Q.2190 Hourly Short message report of mobile originating/terminating (Attempts vs Delivery vs failed vs pending) Q.2191 Hourly Short message report of mobile originating/terminating per SMPP connection (Attempts vs Delivery vs failed vs pending) 26 Lawful Intercept Solution

Q.2192 The system must have an alarm management for operating system tasks and lawful interception tasks (for example lack of space in disk, connection failures, etc.). The alarms must be visible in a GUI and the possibility to forward them to an external alarm management system must be possible. Q.2193 Operating system and Lawful Interception Solution access must be authenticated separately. Describe the authentication methods available (local, LDAP, etc). Q.2194 The solution must support the capture and transmittal to Law Enforcement Agencies of Call Data and Call Content without the monitored individuals being aware of it. The solution must support a secure interface for activating such monitoring requirements. Q.2195 The solution must provide a capability to ensure that the telecommunications to and from a target service be provided to the exclusion of any telecommunications that do not fall within the scope of the interception authorization.

Q.2196 The solution must provide a capability for Law Enforcement Agencies to obtain data in real- time. This ca-pability must ensure there is a full-time monitoring capability for the interception of telecommunications. Call associated data shall also be provided in real-time. If call associated data cannot be made available in real time, Law Enforcement Agencies require the data to be available as soon as possible upon call termination. Q.2197 The solution must provide a capability to acquire data in a format for transmitting the intercepted communications to the monitoring facility in a generally available format. Q.2198 The solution must provide a capability to acquire data in a readable format, if the communication is encoded, compressed or encrypted, the solution must have the capability to provide intercepted communications in the required format. This is not applicable if the intercepted communication has encryption used that is outside of the control of the Bidder. Q.2199 The solution must provide a capability to ensure the interception be designed and implemented to preclude unauthorized or improper use and to safeguard the information related to the interception with the appropriate security levels and authorization levels. Q.2200 The solution must provide a capability to ensure the interception will contain the associated data and content from the target service in a way that allows for the accurate correlation of associated data with content. Q.2201 The solution must provide a capability so that neither the intercepted target nor any other unauthorized person is aware of any changes made to fulfill the interception order. The operation of the intercept on the target must appear unchanged to the interception subject so that the look and feel remains the same prior to the interception. Q.2202 The solution must provide a capability to ensure the user for software-based intercept implements intercep-tions as quickly as possible. The response requirements by the TSP to the Law Enforcement Agencies are an-ticipated to be within 2 hours. Q.2203 The solution must provide a capability to ensure the capability to support simultaneous intercepts for up to five different agencies. Multiple interceptions may be required for a single target service to allow monitoring by more than one Law Enforcement Agency. In this case, the system must ensure that the identity of the target is safeguarded and that each agency will not know that the other agency is monitoring that target. This is to ensure the confidentiality of the investigations. Q.2204 The solution must differentiate the lawful intercept tasks and access to different user roles (such as System Administrator, Users Administrator, Target Administrator). Q.2205 The solution must provide a capability to ensure that the user operating the system has the appropriate logs to conduct audits on the targets setup and who has implemented each target. These logs will also provide sufficient information to allow for the monitoring and trouble shooting of the intercepted data in the event there are issues with the interception or delivery of the interception to the appropriate law enforcement agency. The logs must be stored in an industry standard encrypted manner and must be accessible by authorized users only. Q.2206 The solution must provide a capability for the Owner to provide a target management system to allow for the targeting and de-targeting of intercepts locally and remotely by designated authorized personnel. The system must also have the capability to establish targets with a pre determined time for both the targeting and the de-targeting of the user. Bidder shall provide integration experience.

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

Explanation

Test case ID (if applicable)

Scoping(CT/SE/CSSS C/GS)
SE/GS

Owner

CT

SE/GS/CSSC/CT GS

SE/GS/CSSC/CT SE/GS/CSSC SE/CSSC GS/CT Region/R A/EPC

CT/GS/SE/CSSC

CT/GS/SE/CSSC

CT/GS/SE/CSSC

CT

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

Region/all BL

GS GS

GS

GS

GS

GS

GS

GS GS

GS GS

GS GS

GS/BM

CT

CSSC CSSC/GS

RA RA/Servic e

CSSC CSSC CSSC

RA RA RA

CSSC

RA

CSSC

RA

CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA

CSSC

RA

CSSC

RA

CSSC

RA

CSSC

RA

CSSC CSSC

RA RA

CSSC

RA

CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA

CSSC SE/CSSC

RA Region/R A

CSSC CSSC CSSC/GS

RA RA RA/Servic e

GS

Service

GS CSSC/GS CSSC CSSC CSSC CSSC CSSC CSSC CSSC

Service RA/Servic e RA RA RA RA RA RA RA

CSSC CSSC CSSC CSSC/GS CSSC CSSC CSSC CSSC GS GS GS GS GS CSSC/GS CSSC

RA RA RA RA/Servic e RA RA RA OSS Service Service Service Service Service RA/Servic e RA

CSSC CSSC CSSC

RA RA RA

CSSC CSSC CSSC

RA RA RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA RA RA RA RA RA RA

CSSC

RA

CSSC

RA

CSSC

RA

CSSC

RA

CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA

CSSC CSSC CSSC

RA RA RA

CSSC

RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA RA RA RA RA RA

CSSC CSSC CSSC

RA RA RA

CSSC

RA

CSSC

RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA RA RA RA RA RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC SE SE CSSC CSSC SE CSSC CSSC

RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA Region Region RA RA Region RA RA

CSSC CSSC CSSC CSSC

RA RA RA RA

CSSC CSSC

RA RA

CSSC CSSC CSSC CSSC CSSC GS

RA RA RA RA RA Service

GS

Service

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA

CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA RA RA RA

CSSC

RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA RA RA

CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA

CSSC CSSC CSSC

RA RA RA

CSSC

RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA

CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA RA RA RA RA RA

CSSC CSSC CSSC

RA RA RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC GS GS GS GS GS

RA RA RA RA RA RA RA RA RA RA RA RA RA Service Service Service Service Service

GS/CSSC

Service/R A Service RA RA RA RA RA RA RA RA RA RA

GS CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CSSC

RA

CSSC CSSC CSSC

RA RA RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA RA RA RA RA RA

CSSC

RA

CSSC

RA

CSSC

RA

CSSC

RA

CSSC CSSC CSSC

RA RA RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA RA RA RA RA RA

CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA

CSSC CSSC CSSC

RA RA RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC GS GS GS GS GS GS SE/GS

RA RA RA RA RA RA RA RA RA RA RA Service Service Service Service Service Service Region/Se rvice Service Service Service Region Region Region

GS GS GS SE SE SE

SE SE

Region Region

SE

Region

SE SE SE SE SE

Region Region Region Region Region

SE SE SE SE/GS SE/GS SE/GS SE/GS SE/GS SE/GS SE/GS SE/GS SE/GS

Region Region Region Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice

SE/GS

Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Region/Se rvice Service Service Service Service Service Service Service Service Service Service

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 SE/GS GS GS GS GS GS GS GS GS GS GS

GS

Service

GS GS GS GS

Service Service Service Service

GS GS GS CSSC CSSC CSSC GS GS GS GS GS GS GS GS GS GS GS GS GS GS

Service Service Service RA RA RA Service Service Service Service Service Service Service Service Service Service Service Service Service Service

GS GS GS GS GS GS

Service Service Service Service Service Service

GS GS GS GS

Service Service Service Service

GS

Service

GS

Service

GS GS GS GS GS

Service Service Service Service Service

GS GS GS

Service Service Service

GS GS GS GS

Service Service Service Service

GS GS GS GS GS GS GS GS

Service Service Service Service Service Service Service Service

GS GS

Service Service

GS

Service

GS

Service

GS GS GS GS GS GS GS GS CSSC/GS SE/CSSC SE/CSSC SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE

Service Service Service Service Service Service Service Service RA/Servic e Region/R A Region/R A Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA

CSSC CSSC CSSC CSSC

RA RA RA RA

CSSC

RA

CSSC

RA

CSSC

RA

CSSC

RA

CSSC

RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA RA RA RA RA OSS OSS

CSSC CSSC

OSS OSS

CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS

CSSC CSSC

OSS OSS

CSSC CSSC CSSC CSSC

OSS OSS OSS OSS

CSSC

OSS

CSSC CSSC CSSC

OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS

CSSC CSSC

OSS OSS

CSSC

OSS

CSSC

OSS

CSSC CSSC CSSC CSSC

OSS OSS OSS OSS

CSSC CSSC CSSC CSSC

OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS

CSSC

OSS

CSSC CSSC

OSS OSS

CSSC CSSC

OSS OSS

CSSC

OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC

OSS OSS OSS OSS

CSSC

OSS

CSSC CSSC

OSS OSS

CSSC

OSS

CSSC

OSS

CSSC CSSC

OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC

OSS OSS OSS

CSSC CSSC

OSS OSS

CSSC

OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC GS GS

OSS OSS OSS OSS OSS OSS OSS/RA OSS/RA OSS/RA OSS/RA OSS/RA OSS/RA OSS/RA OSS/RA OSS/RA Service Service

GS GS GS GS GS

Service Service Service Service Service

GS GS GS GS GS GS GS GS GS GS GS GS GS GS

Service Service Service Service Service Service Service Service Service Service Service Service Service Service

GS

Service

GS

Service

GS

Service

GS GS CSSC CSSC CSSC CSSC

Service Service RA/OSS RA/OSS RA/OSS RA/OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA/EPC RA/EPC RA/EPC RA/EPC RA/EPC RA/EPC RA/IMS

CSSC CSSC CSSC CSSC

RA/EPC RA/EPC RA RA

CSSC CSSC SE/CSSC CSSC CSSC SE/CSSC CSSC SE/CSSC RA RA/EPC/ R4/IMS/IP (Neha Aneja) RA Region/IP (Neha Aneja) EPC/R4/I MS RA

SE/CSSC CSSC SE/CSSC

Region/R A RA Region/Ab hishek Pandy (Sahil Bharara) Region/Ab hishek Region/Ab hishek Region/Ab hishek Region/Ab hishek Region/Ab hishek

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/Ab hishek Region/Ab hishek Region/Ab hishek Region/Ab hishek Pandy Region/Ab hishek Pandy Region/Ab hishek Region/Ab hishek Region/Ab hishek Pandy (Sahil Region/Ab hishek Pandy Region/Ab hishek Region/Ab hishek Region/Ab hishek Pandy (Sahil Region/Ab hishek Pandy (Sahil Region/Ab hishek Region/Ab hishek Region/Ab hishek Pandy Region/Ab hishek Region/Ab hishek Pandy Region/Ab hishek Pandy Region/Ab hishek Pandy Region/Ab hishek Pandy (Sahil Bharara) RA RA RA RA RA RA RA

CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

RA RA RA RA RA RA RA RA RA RA RA RA RA RA RA

CSSC

RA

CSSC

RA

SE/CSSC SE/CSSC SE/CSSC SE/CSSC SE/CSSC SE/CSSC

Region/R A Region/R A Region/R A Region/R A Region/R A Region/R A Region/R A Region/R A Region/R A Region/R A Region/R A Region

SE/CSSC

SE/CSSC

SE/CSSC

SE/CSSC SE/CSSC SE

SE

Region

SE SE SE SE SE SE SE SE SE SE SE

Region Region Region Region Region Region Region Region Region Region Region

SE SE SE

Region Region Region

SE SE SE SE SE/CSSC SE/CSSC SE/CSSC SE/CSSC SE SE SE/CSSC SE/CSSC SE/CSSC SE/CSSC

Region Region Region Region Region/R A Region/R A Region/E PC/R4/IM S Region/R A Region Region Region/R A Region/R A Region/R A Region/E PC

SE/CSSC SE/CSSC SE SE GS GS GS SE/CT/GS SE/CT/GS SE

Region/R A Region/R A Region Region Service Service Service

Region

CT SE Region

GS GS

Service Service

GS GS GS GS GS GS GS GS

Service Service Service Service Service Service Service Service

GS GS GS GS GS GS GS GS

Service Service Service Service Service Service Service Service

GS GS GS

Service Service Service

GS GS GS

Service Service Service

GS GS GS GS GS

Service Service Service Service Service

GS GS GS GS GS GS GS GS

Service Service Service Service Service Service Service Service

GS GS GS GS GS GS GS GS

Service Service Service Service Service Service Service Service

GS GS GS GS GS

Service Service Service Service Service

GS GS GS GS GS GS

Service Service Service Service Service Service

GS GS GS

Service Service Service

GS

Service

GS GS GS GS GS

Service Service Service Service Service

GS GS GS

Service Service Service

GS GS GS GS GS

Service Service Service Service Service

GS GS GS

Service Service Service

GS

Service

GS

Service

GS GS GS GS GS GS GS

Service Service Service Service Service Service Service

GS GS GS GS GS GS

Service Service Service Service Service Service

GS GS GS GS GS GS

Service Service Service Service Service Service

GS

Service

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

Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service

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

Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service

GS GS GS GS GS GS GS GS GS

Service Service Service Service Service Service Service Service Service

GS GS

Service Service

GS

Service

GS

Service

GS

Service

GS

Service

GS

Service

GS

Service

GS

Service

GS

Service

GS GS

Service Service

GS GS GS GS GS GS GS GS

Service Service Service Service Service Service Service Service

GS GS GS GS GS GS GS GS

Service Service Service Service Service Service Service Service

GS GS

Service Service

GS GS GS GS

Service Service Service Service

GS GS GS GS GS GS GS

Service Service Service Service Service Service Service

GS

Service

GS GS GS

Service Service Service

GS GS GS GS

Service Service Service Service

GS GS

Service Service

GS

Service

GS GS GS

Service Service Service

GS GS GS GS GS GS

Service Service Service Service Service Service

GS GS GS GS GS GS

Service Service Service Service Service Service

GS GS

Service Service

GS

Service

GS

Service

GS GS

Service Service

GS GS

Service Service

GS GS GS

Service Service Service

GS

Service

GS GS GS GS

Service Service Service Service

GS GS GS GS GS GS

Service Service Service Service Service Service

GS

Service

GS GS GS GS GS GS GS GS GS

Service Service Service Service Service Service Service Service Service

GS GS GS GS GS GS GS GS GS GS GS

Service Service Service Service Service Service Service Service Service Service Service

GS GS

Service Service

GS

Service

GS GS

Service Service

GS CSSC CSSC CSSC CSSC

Service EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC

CSSC

EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC

CSSC

EPC

CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC

CSSC

EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC

CSSC CSSC

EPC EPC

CSSC CSSC CSSC

EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC

CSSC CSSC

EPC EPC

CSSC CSSC CSSC CSSC

EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC

EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC

CSSC

EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC

CSSC

EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC

CSSC CSSC CSSC

EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC

CSSC

EPC

CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC EPC

CSSC

EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC

CSSC

EPC

CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC SE

EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC Region

SE SE SE SE SE

Region Region Region Region Region

SE

Region

SE

Region

SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE

Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region

SE SE

Region Region

SE

Region

SE SE SE SE SE SE SE SE SE SE SE SE SE

Region Region Region Region Region Region Region Region Region Region Region Region Region

SE SE

Region Region

SE

Region

SE

Region

SE SE SE SE SE SE SE

Region Region Region Region Region Region Region

SE SE SE

Region Region Region

SE SE

Region Region

CSSC SE SE SE SE SE SE SE SE SE SE SE SE

EPC Region Region Region Region Region Region Region Region Region Region Region Region

SE SE SE SE SE CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

Region Region Region Region Region IMS IMS IMS IMS IMS IMS IMS IMS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

IMS IMS IMS IMS IMS IMS IMS IMS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS

CSSC CSSC CSSC CSSC

IMS IMS IMS IMS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

IMS IMS IMS IMS IMS IMS IMS IMS

CSSC

IMS

CSSC CSSC CSSC CSSC

IMS IMS IMS IMS

CSSC

IMS

CSSC

IMS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

IMS IMS IMS IMS IMS IMS IMS IMS

CSSC CSSC CSSC

IMS IMS IMS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS

CSSC

IMS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS

CSSC CSSC CSSC

IMS IMS IMS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS

CSSC

IMS

CSSC

IMS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS

CSSC

IMS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS HSS HSS HSS HSS HSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

HSS HSS HSS HSS HSS HSS HSS HSS HSS HSS

CSSC CSSC CSSC CSSC CSSC

HSS HSS HSS HSS HSS

CSSC CSSC

HSS HSS

CSSC CSSC CSSC

HSS HSS HSS

CSSC

HSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

HSS HSS HSS HSS HSS HSS HSS HSS HSS HSS HSS HSS HSS IMS IMS IMS IMS IMS IMS HSS/HLR HSS/HLR HSS/HLR HSS/HLR HSS/HLR IMS IMS IMS IMS

CSSC

IMS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

IMS IMS IMS IMS IMS HSS HSS HSS HSS HSS HSS HSS IMS/CG IMS/CG IMS/CG IMS/CG IMS/CG IMS/CG IMS IMS IMS IMS IMS HSS IMS IMS

CSSC

IMS

CSSC CSSC CSSC CSSC CSSC CSSC

IMS IMS HSS HSS HSS HSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

HSS HSS HSS HSS HSS HSS HSS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS

CSSC CSSC

IMS IMS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

IMS IMS IMS IMS IMS IMS IMS IMS IMS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC LIMS/CSSC LIMS/CSSC LIMS/CSSC LIMS/CSSC LIMS/CSSC

IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS IMS R4/IMS R4/IMS R4/IMS R4/IMS R4/IMS

LIMS/CSSC LIMS/CSSC LIMS/CSSC LIMS/CSSC LIMS/CSSC

R4/IMS R4/IMS R4/IMS R4/IMS R4/IMS

LIMS/CSSC

R4/IMS

LIMS/CSSC LIMS/CSSC LIMS/CSSC LIMS/CSSC

R4/IMS R4/IMS R4/IMS R4/IMS

LIMS/CSSC LIMS/CSSC LIMS/CSSC LIMS/CSSC LIMS/CSSC LIMS/CSSC LIMS/CSSC LIMS/CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

R4/IMS R4/IMS R4/IMS R4/IMS R4/IMS R4/IMS R4/IMS R4/IMS R4 R4 R4 R4 R4 R4/HSS/H LR R4

CSSC CSSC CSSC CSSC CSSC

R4 R4 R4 R4 R4

CSSC CSSC

R4 R4

CSSC CSSC CSSC

R4 R4 R4

CSSC CSSC

R4 R4

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

R4 R4 R4 R4 R4 R4 R4 R4 R4 R4

CSSC CSSC

R4 R4

CSSC

R4

CSSC CSSC CSSC

R4 R4 R4

CSSC CSSC CSSC CSSC CSSC CSSC CSSC

R4 R4 R4 R4 R4 R4 R4

CSSC CSSC CSSC CSSC

R4 R4 R4 R4

CSSC CSSC CSSC CSSC CSSC CSSC CSSC

R4 R4 R4 R4 R4 R4 R4

CSSC CSSC CSSC CSSC

R4 R4 R4 R4

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

R4 R4 R4 R4 R4 R4 R4 R4

CSSC

R4

CSSC CSSC CSSC CSSC CSSC CSSC

R4 R4 R4/HSS/H LR R4 R4 R4/HSS/H LR

CSSC

R4/HSS/H LR R4

CSSC

CSSC CSSC CSSC

R4 R4 R4

CSSC CSSC CSSC CSSC

R4 R4 R4 R4

CSSC

R4

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

R4 R4 R4 R4 R4 R4 R4 R4 R4 R4

CSSC CSSC CSSC CSSC CSSC CSSC CSSC

R4 R4 R4 R4 R4 R4 R4

CSSC CSSC

R4 R4

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

R4 R4 R4 R4 R4 R4 R4 R4 R4 R4 R4

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

R4 R4 R4 R4 R4 R4 R4 R4 R4 R4 R4 R4

CSSC CSSC CSSC CSSC SE/CSSC SE/CSSC SE/CSSC SE/CSSC SE/CSSC

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

SE/CSSC

SE/CSSC SE/CSSC SE/CSSC SE/CSSC SE/CSSC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

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

CSSC

R4

CSSC

R4

CSSC

R4

CSSC

R4

CSSC

R4

CSSC CSSC

R4 R4

CSSC CSSC CSSC CSSC CSSC

R4 EPC EPC EPC EPC

CSSC

EPC

CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC

EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC EPC IMS

CSSC

IMS

CSSC CSSC CSSC

IMS IMS IMS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC

OSS OSS OSS OSS

CSSC

OSS

CSSC CSSC

OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS

CSSC

OSS

CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS

CSSC

OSS

CSSC

OSS

CSSC CSSC CSSC CSSC

OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC

OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS

CSSC

OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS

CSSC

OSS

CSSC CSSC CSSC

OSS OSS OSS

CSSC CSSC CSSC

OSS OSS OSS

CSSC CSSC

OSS OSS

CSSC

OSS

CSSC CSSC CSSC CSSC CSSC CSSC

OSS OSS OSS OSS OSS OSS

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

OSS SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM

CSSC

SDM

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

SDM SDM SDM SDM SDM SDM SDM SDM

CSSC

SDM

CSSC CSSC

SDM SDM

CSSC CSSC

SDM SDM

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM

CSSC

SDM

CSSC CSSC CSSC CSSC

SDM SDM SDM SDM

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM

CSSC CSSC CSSC CSSC

SDM SDM SDM SDM

CSSC CSSC CSSC

SDM SDM SDM

CSSC CSSC

SDM SDM

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM SDM

CSSC CSSC

SDM SDM

CSSC CSSC

SDM SDM

CSSC CSSC CSSC

SDM SDM SDM

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

SDM CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG CG CG CG

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG CG CG CG CG CG CG CG

CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG CG CG

CSSC

CG

CSSC

CG

CSSC

CG

CSSC

CG

CSSC

CG

CSSC

CG

CSSC CSSC CSSC CSSC

CG CG CG CG

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG CG CG CG CG CG CG CG CG

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG CG CG CG CG CG CG CG CG

CSSC

CG

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG

CSSC CSSC CSSC

CG CG CG

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG CG CG CG CG CG

CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG

CSSC CSSC

CG CG

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG CG CG CG CG CG CG CG

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG

CSSC

CG

CSSC CSSC CSSC

CG CG CG

CSSC CSSC CSSC CSSC

CG CG CG CG

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG CG CG CG CG CG CG CG

CSSC CSSC CSSC

CG CG CG

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG

CSSC

CG

CSSC

CG

CSSC CSSC CSSC CSSC

CG CG CG CG

CSSC

CG

CSSC CSSC CSSC

CG CG CG

CSSC

CG

CSSC CSSC

CG CG

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG CG

CSSC CSSC CSSC

CG CG CG

CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG

CSSC CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG CG

CSSC CSSC

CG CG

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG CG CG CG CG CG CG CG

CSSC

CG

CSSC

CG

CSSC

CG

CSSC

CG

CSSC

CG

CSSC

CG

CSSC CSSC

CG CG

CSSC

CG

CSSC

CG

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG CG CG CG CG CG CG CG

CSSC CSSC CSSC CSSC

CG CG CG CG

CSSC CSSC CSSC CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG CG CG CG

CSSC CSSC CSSC CSSC CSSC

CG CG CG CG CG

CSSC CSSC CSSC SE SE SE SE SE

CG CG CG Region Region Region Region Region

SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE

Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region

SE SE SE SE SE SE SE SE SE SE

Region Region Region Region Region Region Region Region Region Region

SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE

Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region

SE SE SE SE SE SE SE SE SE SE SE SE

Region Region Region Region Region Region Region Region Region Region Region Region

SE SE SE SE SE SE SE SE SE SE/CSSC

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

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 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 Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha 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 Region/IP (Neha Region/IP (Neha

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 Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha 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

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 Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Aneja) Region/IP (Neha Region/IP (Neha Region/IP (Neha

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 SE/CSSC SE/CSSC

Region/IP (Neha Region/IP (Neha Region/IP (Neha Aneja) Region/IP (Neha Aneja) Region/IP (Neha Region/IP (Neha Aneja) Region/IP (Neha Aneja) Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Aneja) Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha 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

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 Region/IP (Neha Aneja) Region/IP (Neha Region/IP (Neha

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

Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region/IP (Neha Region Region Region Region Region Region Region Region Region Region Region

SE SE

Region Region

SE SE SE

Region Region Region

SE

Region

SE SE SE SE SE

Region Region Region Region Region

SE SE SE SE

Region Region Region Region

SE

Region

SE

Region

SE

Region

SE SE SE SE

Region Region Region Region

SE SE SE

Region Region Region

SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE

Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region

SE SE SE SE SE SE SE SE SE SE SE SE SE SE

Region Region Region Region Region Region Region Region Region Region Region Region Region Region

SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE SE

Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region

SE

Region

SE SE SE SE SE SE SE SE

Region Region Region Region Region Region Region Region

SE SE SE SE SE SE

Region Region Region Region Region Region

SE SE SE SE SE SE SE SE SE SE

Region Region Region Region Region Region Region Region Region Region

SE SE SE SE LIMS/CSSC LIMS/CSSC

Region Region Region Region R4/EPC/I MS R4/EPC/I MS R4/EPC/I MS R4/EPC/I MS R4/EPC/I MS

LIMS/CSSC

LIMS/CSSC

LIMS/CSSC

LIMS/CSSC

R4/EPC/I MS

LIMS/CSSC

R4/EPC/I MS R4/EPC/I MS

LIMS/CSSC

LIMS/CSSC

R4/EPC/I MS R4/EPC/I MS R4/EPC/I MS

LIMS/CSSC

LIMS/CSSC

LIMS/CSSC

R4/EPC/I MS R4/EPC/I MS

LIMS/CSSC

LIMS/CSSC

R4/EPC/I MS R4/EPC/I MS

LIMS/CSSC

LIMS/CSSC

R4/EPC/I MS

LIMS/CSSC

R4/EPC/I MS