Www.mts.am
Technical Specifications (Annex 3)
1. General requirements 2
2. Requirements to the Project implementation 3
3. Project services requirements 3
4. Powering of the SYSTEM 4
5. Integration of the SYSTEM 4
6. Access to the SYSTEM 4
7. Administration of the SYSTEM 4
8. Backup of the SYSTEM 4
9. Requirements to the documentation of the SYSTEM 5
10. Performance of the SYSTEM 5
11. Supported interface types 5
12. Supported interfaces 6
13. Supported protocols 6
14. “Protocol Analyzer” 6
15. “Call Trace” 7
16. “Network Performance Monitoring” 7
17. “Roaming and interconnect” 8
18. “Reporting” 8
19. “GPRS” measurement mode 10
20. Geo location 10
21. Marketing specialized reporting 10
22. Customer Care specialized tool 11
23. Alarm reporting 14
24. Network topology 15
25. Warranty and service terms 15
26. System acceptance 16
27. Training 16
28. SYSTEM management 16
29. Fault tolerance 16
30. Security 17
31. Monitoring center implementation 17
Appendix 1: “K-Telecom” CJSC Core network topology 18
Appendix 2: Statement of Compliance (SOC) 19
Appendix 3 Interface types, quantities and load 20
Appendix 4 Basic reports for KPIs and counters 21
General requirements
– Hardware and software components of the Network Quality of Service (QoS) monitoring system (hereafter SYSTEM) are intended for monitoring of signaling and data exchange as well as radio network performance in the network of “K-Telecom” CJSC and will be accommodated in c. Yerevan;
– The core network elements are distributed between two different locations in c. Yerevan as shown in Appendix 1;
– The radio network elements are collocated with core network elements as well as in remote regional sites;
– The Contractor must ensure compatibility of the supplied system and its components with existing 2G, 3G and 4G (LTE) networks and corresponding interfaces, protocols;
– The Contractor must have at least 3 years of proven experience in the field of monitoring systems integration into mobile operator networks and sufficient expertise in mobile networks audit;
– Option of portable probes for signaling traffic capturing on remote locations should be provisioned (particularly for Abis and Iub monitoring);
– Equipment must have 19 inch form factor and be installable in standard industrial racks;
– Offered equipment for traffic capture on network element interfaces and the diagram of connections must be agreed with and approved by the Customer;
– Detailed cost table should be presented by the Contractor reflecting costs for equipment (servers, probes, ports, cables, etc.), services (implementation, training, system expansion, licenses, post-warranty support, etc.), software applications, change requests implantation, etc.
– The SYSTEM must be dimensioned with at least 30% spare capacity (including traffic capturing, processing, storage, etc.);
– Taking into account the rapid growth of data services usage and consequent need of the SYSTEM expansion to handle increased load, the Contractor should present the SYSTEM upgrade scenario. The cost of upgrade must be reflected the cost table;
– During the SYSTEM expansion and modernization, cost of the interfaces and licenses must be fixed as defined in the frame contract for equipment supply, in accordance with tender offer;
– The Contractor can suggest project implementation scenario in phases depending on the availability of hardware or software functionality (based on roadmap), or other reasonable conditions. In this case the implementation period of each phase must be presented with detailed cost information;
– The Contractor can suggest additional services or system components that can enhance the SYSTEM performance and overall network performance monitoring, reporting, analysis and troubleshooting process. The cost for enhancement implementation, services, and post-warranty terms must be specified explicitly;
– Statement of Compliance (SOC) provided in Appendix 2 must be provided by the Contractor. Compliance of the offer to each item in SOC must be specified by the Contractor in terms “Noted”, “Compliant”, “Partially Compliant”, “Not Compliant”. Comments must be provided for the “Partially Compliant” and “Not Compliant” items. If the above mentioned statements are not presented for the specific point, then “Not compliant” statement will be applied for this particular requirement. The SOC will be used during the offer evaluation and later will be attached to the contract as a separate appendix.
– All proposals presented within the frame of the current process shall include as a minimum:
• Official Technical Datasheets and Product Description information about presented solutions. It shall contain all technical information for all the elements integrating the overall solution (Hardware platforms, products, network elements, SW, etc.);
• Generic Solution Architecture Diagrams, with the maximum level of detail in terms of architecture and interfaces;
• Detailed roadmap of the solution and planned new products;
• References in terms of already operating solutions within the Industry;
• Acceptance & Testing Standard document;
• Training catalog;
• Optional Maintenance policy terms and conditions after the warranty period;
• Any other information that may be considered of relevance within the current RFP process.
Requirements to the Project implementation
Following actions should be performed by the Contractor before starting the Project implementation works:
– Develop technical requirements specification of the Project based on the technical requirements of the Customer;
– Develop and confirm with Customer the Project Implementation Plan (PIP). Following on the terms specified in the confirmed PIP is a mandatory condition. Penalties must be foreseen in the contract for the case of PIP terms violation;
– Perform site survey on the sites where the equipment will be installed;
– Appoint a responsible specialist for project management, and oblige the manager to control the follow-up on PIP terms and works implementation process as agreed with the Customer;
– The Contractor should provide responsibility matrix for the Project services, to be confirmed with the Customer;
– The Contractor provides all necessary information for the equipment installation, powering and integration including equipment components, size and weight, powering options, power consumption, heat dissipation, cooling mechanism, etc.
– The Contractor ensures delivery of all required installation materials for the whole scope of Project implementation works. All the materials should be available on sites before the start of installation works.
Project services requirements
– The implementation works duration for the SYSTEM installation, integration and configuration according to the Customer’s requirements (including configuration of KPIs, alarm thresholds, etc.) should not exceed two months from the date of equipment delivery;
– The Contractor should present initial engineering data no later than 10 weeks in prior the works completion act signing date;
– The Contractor provides the installation and integration works completion act within five days duration from the date of signing of the last Acceptance Test act;
– All the works should be performed by a company having all proper licenses of the Republic of Armenia for corresponding works performance. The licenses should be valid for not less than 30 days after the works completion data as indicated in the PIP presented by the Contractor;
– The specialists working on equipment powering should have proper certificates for operations with carriers up to 1000V;
– The Contractor must provide all required information regarding the authorized subcontractor organizations involved in the project implementation works;
– The Contractor bears all responsibility for the actions of subcontractor organization, authorized by the Contractor for the Project installation and integration works;
– All the expenses of the Contractor in the scope of Project realization works (services costs) should be included in the tender offer and reflected in the cost table;
– The Contractor guarantees system integration works implementation without any impact (outage or degradation) on the Customer’s network;
Powering of the SYSTEM
– It is preferred to use -48V DC power supply for the SYSTEM components;
– 230V AC power supply may be used upon necessity with allowed fluctuations in the range 215V…235V;
– The servers, probes and other components of the SYSTEM should have redundancy for power supply. The equipment must be capable to function without any degradation in case of loss of any one direction of power supply.
– Installation materials (power cable, cable terminals, fuses, breakers, etc.) for connection to the existing power supply system should be delivered before the start of installation works;
– Provide information on equipment power consumption (servers, probes, TAPs, etc.).
Integration of the SYSTEM
– The SYSTEM should have possibility of integration with OSS systems for Ericsson and Huawei equipment, with support of CORBA;
– Signaling information storage servers of the SYSTEM should provide possibility of signaling information provisioning to information platforms from other vendors, which can be integrated in the Customer’s network.
Access to the SYSTEM
– License for not less than 20 simultaneous users of the SYSTEM should be provided;
– All applications of the SYSTEM should support multiuser access with user rights differentiation;
– SYSTEM access control mechanism should be implemented.
Administration of the SYSTEM
– The SYSTEM should have convenient, intuitive and easy-to-use graphical interface for adjusting or changing all necessary parameters of the SYSTEM – threshold values, timers, prefixes, etc.
– Possibility to have full network view on one screen;
– Possibility to configure user groups with corresponding access rules to predefined reports, functions, etc.
Backup of the SYSTEM
– The SYSTEM should support automatic full and incremental backup of configuration data and operation system according to the configurable time table;
– The SYSTEM should support automatic backup of all indicators and KPIs according to the configurable time table;
– The SYSTEM backup copies storage time should be not less than 60 days.
Requirements to the documentation of the SYSTEM
– At the end of project realization the Contractor provides full documentation of the SYSTEM in hard and electronic formats in English language. The completeness, composition and format of the documentation should be defined by the Customer.
– The SYSTEM documentation should include:
• General description of the SYSTEM;
• Detailed description of the network part;
• Detailed description of the HW equipment part;
• Technical documentation on exploitation and configuration;
• Product description with detailed documentation on the SYSTEM structure, its logical modules, description of internal and external interfaces, configuration rules and administration of the modules and interfaces;
• Documentation on configuration and monitoring of alarm messages;
• Description of statistical information collection and analysis methods;
– Reference documentation sufficient for the SYSTEM exploitation should be integrated into the SYSTEM.
Performance of the SYSTEM
– Minimal storage time for all unprocessed data in signaling data capturing servers should be not less than seven days;
– Minimal storage time for xDRs not less than 45 days;
– Processing capacity for load up to 0,4Erl/channel and up to 1Erl/channel in busy hour on E1 interface, and up to 1Gbps on Ethernet interface;
– The SYSTEM should have practical realization on mobile operator networks with subscriber base not less than 2 000 000. Realization description and references should be provided;
– The SYSTEM should be scalable the way to enable further increasing of interfaces for data capturing and processing;
– The SYSTEM should have distributed architecture with capability to install portable probes for data capturing;
– All the relevant SYSTEM components should support centralized time synchronization for correct time stamping of xDRs;
– Possibility to export xDRs to other platforms or external media;
– Flexible configuration of exported xDR fields and parameters.
Supported interface types
– LSL/HSL on STM-1/SDH interface;
– Sigtran & VoIP Ethernet interface (100, 1000 Mbps copper and optical);
– 10 Gbps Ethernet optical interface;
– Frame Relay;
– PRI (Q.931);
– Information on interface connection type licensing (if applicabe) should be provided with corresponding costs;
– Possibility of co-location of different interfaces inside one probe must be specified;
– The cost each interface should be fixed by mutual agreement of the Parties and should not be increased during 10 years;
– Interface quantities, types and utilization are presented in the Appendix 3.
Supported interfaces
– Information on licensing for any interface (if applicable) should be provided with corresponding costs;
– Interfaces to be supported should include:
• A, C, D, E, F, Mc, Nc, Nb, Iub, IuCS, Gr, Gs, Gp.
• IuPS (Control Plane)
• Gb Frame Relay, Gb over IP
• Gn (GTP-С, GTP-U), Gi
• S1, S1AP, S6A, S10, S11, X2, SGi
• Abis over TDM, Abis over IP, Iub (Huawei, Ericsson). For Abis and Iub interfaces a solution with portable probes should be provisioned, which could be fully integrated into monitoring and statistical systems to enable full correlation of signaling messages with the measurements data from the portable probes.
Supported protocols
– Information on licensing for any protocol (if applicable) should be provided with corresponding prices;
– Protocols to be monitored should include: Sigtran (SCTP, M2UA, M3UA, IUA, M2PA, SUA), MTP, SCCP, MAP (ver. 1, 2, 3), TCAP, DTAP, CAP (Phase 1, 2, 3, 4), BSSAP, BSSMAP, RANAP, ISUP, R-ISUP, SIP, BICC, H.248, INAP (Ericsson CS 1+), DNS, DHCP, RADIUS, DIAMETER, HTTP, SMPP 3.4/5.0; BGP (GRX links);
– NBAP, LAPD.
“Protocol Analyzer”
– Supported decoding protocols: NBAP, LAPD, BSSAP, BSSMAP, CAP ph1-4, DTAP, MAP v1, v2, v3, MEGACO (H.248), H.323, BICC, MTP2, MTP3, RANAP, SCCP, SIP, SIGTRAN (SCTP, M2UA, M2PA, M3UA, IUA, SUA), TCAP, DIAMETER, BGP (GRX links), SAAL, ALCAP, DNS, DHCP, RADIUS, HTTP, SMPP 3.4/5.0, ISDN-PRIISUP, ISUP-R2000, IUP/BTNUP, MGCP, R2-Signalling, RTCP, RTSP, RTP, UDP, TCP, IP (v4, v6), ICMP, ARP, BSSGP, LDAP, S1AP, GTP-U v1, GTP-C v2, X2AP, NAS;
– Possibility to perform search in the signaling messages based on any field value (“Called Party Number”, “Calling Party Number”, “Original Calling Number”, “Redirecting Number”, A-IMSI, B-IMSI, etc.), time stamp of the signaling message, type of signaling message, protocol, etc.
– Possibility to make combinations of different filters using Boolean functions “AND”, “OR”, “NOT”;
– On-Line and Off-Line analysis modes availability;
– Support of signaling point code labels, not only OPC/DPC values;
– Possibility to save and load custom filters;
– Support of messages color coding (based on direction, protocol, etc.);
– Possibility to export data to TXT, CSV, XLS, etc. formats;
– Functionality of message correlation for any particular call or transaction;
– xDR viewing capability for any particular call;
– Delay in trace result viewing from the moment of signaling information receipt on the probes should not be more than 30 seconds;
– Possibility to switch from Protocol Analyzer view to Call Trace view;
– Possibility to use the full functionality of Protocol Analyzer by several users simultaneously;
– Interface types are presented in Appendix 2.
“Call Trace”
– Possibility to perform search in the signaling messages based on any field value (“Called Party Number”, “Calling Party Number”, “Original Calling Number”, “Redirecting Number”, A-IMSI, B-IMSI, cause, etc.), time stamp of the call attempt, call answer, disconnection, call duration, etc. Possibility to make combinations of different filters using Boolean functions “AND”, “OR”, “NOT”;
– On-Line and Off-Line analysis modes availability;
– Support of signaling point code labels, not only OPC/DPC values;
– Possibility to save and load custom filters;
– Possibility to export data to TXT, CSV, XLS, etc. formats;
– Graphical representation of the messages of a call of transaction (message flow chart);
– GIS integration for Abis and Iub signaling messages mapping, possibility of interaction with Google Earth;
– Functionality of correlation of signaling data from different interfaces relating to one call or transaction;
– Functionality of cross-protocol correlation;
– Functionality of data correlation between LTE, 2G and 3G networks;
– Possibility to switch to signaling tracing mode;
– Possibility to view messages of all logical layers above physical;
– IMSI-TMSI correspondence for the subscribers registered in the network;
– Maximum number of simultaneous call trace tasks supported by the system should be specified.
“Network Performance Monitoring”
– On-Line and Off-Line modes of network performance analysis (quantity of different messages, number of errors, rejects, success rates, etc.), statistics, monitoring of a set of signaling channels, separate channels, signaling point;
– Flexible monitoring time intervals – 5, 15, 30, 60 min.
– Viewed information filtering possibility;
– Possibility to view information in graphical as well as table formats;
– Possibility to export information;
– Possibility to perform network KPI decomposition to network elements KPI level (drill down);
– Possibility to switch to call trace or protocol analyzer modes for detailed analysis.
“Roaming and interconnect”
– On-Line and Off-Line modes of monitoring;
– Statistics for inbound and outbound roamers;
– Monitoring on the level of country and operator (prefixes, GTs, etc.);
– Statistics of events, messages and main KPIs;
– Data export functionality;
– Configurable measurements time intervals – 15 min, 60 min, 24 hr;
– Data sorting and filtering functionality;
– Graphical reporting of statistical and qualitative figures;
– Possibility to configure counters for SCCP messages for inter-operator exchange;
– Counter for inter-operator MSU exchange;
– Possibility to configure anchors for MSISDN, IMSI, IP address, SCCP GT to specific operators;
– Possibility to perform KPI decomposition to network elements KPI level (drill down);
– Possibility to switch to call trace or protocol analyzer modes for detailed analysis;
– Possibility to export data.
“Reporting”
Following reporting functionality should be supported by the SYSTEM:
– Statistics based on any field of xDR records, with possibility to apply filters and build graphs;
– xDR specification with corresponding descriptions of all fields should be provided;
– Reports based on:
• Counters (i.e. number of call attempts);
• Defined ratios (i.e. ASR);
• Statuses;
– Possibility to create custom reports using counters, KPIs and save them as templates;
– Possibility to configure KPIs aggregation (hourly, daily, weekly, monthly, etc.);
– Possibility to modify KPI formulas and add new KPIs and reports;
– Availability of logical, mathematical and date functions;
– Time interval for updating the report (15 min, 60 min, 24 hr, month) must be configurable for each report;
– GUI interface for creating custom KPIs with the use of counters and formulas;
– Possibility to integrate reference data (i.e. user equipment specifications);
– Thresholds definition for counters and KPIs (to define degradation, partial or full unavailability);
– Availability of reports for radio conditions (coverage) and capacity analysis for 2G, 3G and 4G (LTE) networks including:
• Cell neighboring relations analysis;
• Cell coverage and load analysis;
• HSDPA/HSUPA performance and mobility analysis;
• HSPA+, DC (Dual Carrier), MIMO analysis;
– Integration with geo location applications (or integrated GIS) for radio measurements and KPIs visual mapping with serving cells and sites;
– Automatic report updating and distributing (via email) functionality;
– Availability of standard reports for all data types available to a user. The list of these reports should be provided;
– Possibility to use graphical as well as table format reports;
– Possibility to create different types of graphs – linear, pie charts, histograms/bar charts in combination of 2G, 3G and 4G (LTE) data;
– Possibility to create comparative reports with graphs for different data types;
– Possibility of generating the reports using:
• Search;
• Filtering;
• Sorting;
• Grouping;
• Time (relative, absolute);
• Value filtering for including or excluding defined values;
• Parallel working (simultaneous viewing or working with several reports);
• Best and worst KPIs;
– Report planning functionality. Scheduled sending of reports to email addresses:
– Information panel – dashboard creation possibility, which will include a set of monitored KPIs with possibility of further detailing;
– Monitored KPI aggregation possibility on different levels:
• On network element level (MSC. BSC, etc.)
• Geographical, can be based on external DB or file (i.e. cells cluster, BSC/RNC clusters, etc.);
• Network level – 2G, 3G, 4G;
• Subscriber group (postpaid, prepaid, etc.);
• Terminal equipment model and type;
– Possibility to control graph axis parameters. By default X axis should be the time;
– Possibility to switch to trending view (comparison with previous reporting periods results on the same graph);
– Drill down functionality to switch from KPI reporting mode to KPI decomposition and down to call trace mode;
– All the KPIs and counters that will not be implemented in supplied software version and will be available in the future, should be provided to the Customer free of charge;
– Quality measurements should be implemented according to the ITU-T Q.752 and E.422 recommendations;
– Reporting for protocols S1AP, GTPv2;
– Configured reports for the KPIs and counters requested the Customer including the ones defined in Annex 4;
– Reporting for USSD transactions:
• Statistics on USSD requests, request codes;
• Flexible options for filtering on USSD code fields values;
• Statistics on USSD request processing results (successful, fail, error, unknown service, etc.);
• USSD response message body analysis;
– Report exporting functionality including XLS, SCV, PDF, HTML, JPEG formats;
– Access to all performance indicators used in KPI composition;
– Reference data availability for all KPIs and timers;
– Storage terms for KPIs:
• Hourly KPIs – 45 days;
• Daily KPIs – 6 months;
• Weekly KPIs – 1 year;
• Monthly KPIs – 3 years;
– Any limiting factor in the Reporting system should be specified (i.e. max number of reports created, max number of custom KPIs supported, max number of defined thresholds, max storage time, etc.).
“GPRS” measurement mode
– Possibility to perform search in the signaling messages based on any field value (MSISDN, IMSI, URL, APN, USER IP, disconnection cause, etc.), time stamp of the session activation attempt, disconnection, session duration, etc.
– Possibility to make combinations of different filters using Boolean “AND”, “OR”, “NOT” functions;
– Protocol decoding functionality on interfaces: Gb, Gr, Gs, Gn, Gi, Gp, IuPS;
– Raw signaling storage time not less than 7 days;
– On-Line and Off-Line modes availability;
– Custom filters saving and loading functionality;
– Data export functionality (TXT, CSV, XLS, HTML, etc.);
– Message correlation functionality for any given transaction or call;
– User plane monitoring and analysis on Gn interface (including RTT, retransmission rate and other related measurements);
– Analysis possibilities based on URL, APN, user agent, user application, user IP address/range, service type, etc.
Geo location
– Functionality to enable geo location of the network events using signaling information on NE interfaces;
– User position definition algorithm accuracy (in meters) must be specified;
– Full integration into monitoring and reporting system with support of drill down functionality;
– Easy switching to call trace, protocol analyzer and reporting views;
– Functionality of KPIs mapping on physical map (RSCP levels, setup inefficiency, drops, HO success rate, call density, pilot pollution, etc.);
– Possibility to apply filters on mapped data/KPIs (subscriber groups, time interval, etc.);
– Reports/maps exporting functionality.
Marketing specialized reporting
Following reporting functionality should be supported by the SYSTEM:
– Customer equipment benchmarking;
– Customer applications usage statistics;
– Customer services usage statistics;
– DPI data analysis:
• Visited URLs
• Protocols used
• Applications used
– Customer generated traffic, its composition by customer equipment, application, service, URL, etc.;
– Customer behavior in terms of device usage (analysis based on IMEI, MSISDN, IMSI);
– ADMS features:
• Device vendor, model
• Browser info
• Operating system
• Service supporting info (e.g. video call, MMS, etc.);
– Duration stats (session, call);
– Location stats (cell ID with map overlaying);
– Latency info;
– Average throughput;
– Total bandwidth utilized;
– Peak and off-peak info (voice, data);
– APNs load statistics;
– APN usage stats;
– Possibility to apply filters (date, time, duration, etc.);
– Possibility to create custom reports and save them as templates;
– Possibility to create different types of graphs – linear, pie charts, histograms/bar charts in combination of 2G, 3G and 4G (LTE) data;
– Possibility to create reports with comparative graphs for different data types;
– Possibility of report viewing with following functionality:
• Search
• Filtering
• Sorting
• Grouping
• Time (relative, absolute)
• Value filtering for including or excluding defined values;
• Parallel working (simultaneous viewing or working with several reports);
• Best and worst KPI
– Monitored KPI aggregation possibility on different levels;
– Possibility to switch to trending view (comparison with previous reporting periods results on the same graph);
– Drill down functionality to switch from KPI reporting mode to KPI decomposition view;
– Report exporting wide functionality including XLS, SCV, PDF, HTML, JPEG formats.
Customer Care specialized tool
Requirements for Voice services reporting:
– Availability of search functionality using IMSI, MSISDN, IMEI, etc.
– Customer device/phone model and type identification;
– Reference data availability for user equipment (capabilities, supported standards, modes, etc.);
– Activity start & end time, total duration in seconds;
– Traffic case name (originating or terminating);
– Called number network identification (home network or international destinations);
– Called number mobile operator identification (based on external reference data);
– Charging category description (on net calls, PSTN, etc.);
– Integration with charging/billing platform for price plan identification, charged amount definition, balance before/after processed activity;
– In case of free call/SMS reason’s visibility (hot line, from available any free airtime or bonuses, etc.);
– GSM number’s current status identification both for prepaid and postpaid;
– Transaction cell and site identification;
– Network type 2G, 3G, LTE and used service type (GPRS, EDGE, HSDPA, HSPA+, WCDMA, LTE) identification;
– Transaction/activity final status (failed, error, success);
– In case of originating SMS check & note existence of SMSIW agreement, third part carrier (based on external reference data);
– Reporting for USSD transactions:
• Statistics on USSD requests, request codes;
• Flexible options for filtering on USSD code fields values;
• Statistics on USSD request processing results (successful, fail, error, unknown service, etc.);
• USSD response message body analysis;
Requirements for Data services reporting:
– Availability of search functionality by IMSI, MSISDN, IMEI, etc.
– Customer device/phone model and type identification;
– Reference data availability for user equipment (capabilities, supported standards, modes, etc.);
– Session duration in seconds;
– Serving cell and site identification;
– Serving APN identification;
– User browser identification;
– Visited URL identification;
– IP address identification (real, dynamic, etc.);
– Activity start time & end time;
– Total traffic/UL+DL KB;
– Mean throughput on DL (Kb/S);
– Mean throughput on UL(Kb/S);
– Average Latency;
– Current Latency;
– Possibility of integration with charging/billing platforms for balance identification before/after processed activity;
– GSM number’s current status identification both for prepaid and postpaid;
– GSM number Price Plan identification;
– Serving network type 2G, 3G, LTE (GPRS, EDGE, HSDPA, HSPA+, WCDMA, LTE);
– Quality of Experience evaluation;
– Data products specific price plan (PP) details should be taken into account in order to have correct statistical data interpretation, since there are some restrictions, special requirements and privileges which are applied on monthly basis (high traffic packages, speed limitations, etc.);
Device Management:
– Identification of customer device vendor, model, IMEI, used APN, OS;
– Reference data availability for user equipment (capabilities, supported standards, modes, MMS & GPRS capable, streaming, video call, PTT capable, etc.);
– Visited web sites analysis;
– Availability of search functionality by IMEI, IMSI, MSISDN;
– Total traffic/UL+DL KB;
– Mean throughput DL(Kb/s);
– Mean throughput UL(Kb/s);
– Integration option with ADMS platform for provisionign of MMS/GPRS configuration information via this interface;
– Reports generation capability based on devices vendors, models, etc.;
VOIP services reporting:
– All options listed above for Voice services;
– Called numbers’ mobile operator and country identification;
– Dialed number formula checking (with prefix 77 or not);
– Possibility to check & indicate existence of VOIP agreement to the called direction (reference data importing interface should be foreseen);
Roaming (Inbound, Outbound):
– Availability of search functionality by IMSI number, MSISDN, IMEI;
– Device vendor and model identification;
– OS identification;
– Activity start time & end time;
– Activity duration in sec.;
– Host mobile operator indication, availability of reference data regarding theexistence of Roaming agreement with the particular operator;
– Identification of destination number network (home network or international destinations);
– Destination numbers’ mobile operator identification (based on reference data);
– Session duration in seconds;
– Used APN;
– Used browser identification;
– Requested URL identification;
– Total traffic/UL+DL KB
– Mean throughput DL (Kb/s)
– Mean throughput UL (Kb/s)
– Possibility to import references data regarding existing current roaming agreements with other operators;
– Possibility to monitor Welcome message receipt for outbound roamers (welcome messages are sent from our network);
VIP customer care
– Support of VIP customer lists/groups based on MSISDN, IMSI, IMEI;
– Special interface for constant monitoring of each VIP customer/group KPIs (voice and data separately) with alarming capability in case of KPI degradation;
– Easy navigation to other reporting tools.
Reporting
– Flexible solution for trending reports generation based on different filtering/grouping criteria – PP, equipment vendor and model, visited URLs, service type, cell ID, etc;
– Flexible report period adjustment capability – 15 min, 60 min, 24 hr, etc.;
– Report exporting capability in graphical as well as table formats;
Customization of user interface including but not limited to the monitored KPIs list, reports, graphs, lists, user interface organization should be foreseen during the SYSTEM adaptation and testing period. The term and conditions for customization services should be specified.
Alarm reporting
The SYSTEM should support following alarm representation possibilities:
– Several classes of alarms severities (minimum 3);
– Color coding of alarm messages based on alarm severity;
– Maximum delay of alarm reporting to user interface from the moment of meeting alarm triggering condition – 5 seconds;
The SYSTEM should support following possibilities of alarm messages configuration and reporting:
– Possibility to create alarm messages and triggering conditions based on any available or custom created KPI;
– Unique identifier existence for each alarm message;
– Alarm message resetting possibility in case of solving alarm triggering problem;
– Alarm message body configuration possibility;
– Functionality of alarm triggering thresholds configuration based on values set for each indicator:
• Threshold for counters values;
• Threshold for counter or indicator ratio;
• Threshold for the deviation value of a counter or indicator from defined normal behavior pattern (i.e. day/night pattern);
– Availability of standard predefined alarm messages and possibility to configure all alarm message fields;
– Possibility to create and use different threshold values for different periods, days (seasonal thresholds);
– Possibility to reflect following fields in the alarm message:
• Alarm rising time;
• Alarm clearing time;
• Alarm severity;
• Text message (including the triggering condition);
• Alarm number;
• Alarm repeat counter;
• Comments (to be filled by the user/operator);
• Handling suggestions (to be configurable by the operator or administrator);
• Each change in the alarm state should fixed and brought to the operator attention;
– Alarm short and detailed views availability;
– Possibility to initiate SMS or email sending upon triggering event (configurable);
– Alarm exporting functionality to other (umbrella) monitoring system;
– Detection and alarm generation in case of fault or loss of connection with any part (HW or SW) of the SYSTEM or detection of problems on traffic capturing ports;
– Detection and alarm generation in case of loss of a capturing port, protocol or particular NE messages (based on functional network topology);
– Alarm messages storage time in the SYSTEM should be not less than 6 months;
– Any limiting factors in Alarm reporting system should be specified (i.e. max number of stored/raised alarms, custom created alarms, configurable thresholds, etc.).
Network topology
The SYSTEM should have network topology visualization tool for network elements and corresponding connections mapping. Whereas:
– Automatic discovery and identification of new added elements based on SPC and/or IP address;
– Automatic discovery of connections/links between network elements;
– Grouping functionality of different logical elements with different SPC codes;
– Flexible updating of NE labels based on SCP and/or IP address;
– Visualization of alarm status of links and NEs;
– Network topology and links manual editing possibility;
– Reference data availability for network elements with corresponding SPCs, IP addresses, etc.
Warranty and service terms
– Warranty for all hardware and software components of the system should be not less than 3 years;
– Technical support for the SYSTEM should be available during 365 days per year, 24 hours a day. Technical problems neutralization and resolution terms will depend on the problem severity and priority and need to explicitly specified in the SLA;
– Post-warranty support of the SYSTEM (all components) should be not less than 7 years;
– Post-warranty service cost will be defined in the frame contract and is not subject to be increased later;
– Post-warranty service terms and conditions need to presented (including contract template) with detailed cost table and payment terms;
– The Contractor will supply the latest software release officially available for deployment;
– In the warranty period the Contractor will ensure delivery and installation of all new software releases and upgrades to the SYSTEM for improvement of performance, and ensures compatibility of new software with existing hardware parts;
– Provide the periodicity and approximate cost of software upgrades for post warranty period;
– In the warranty period the Contractor will bear responsibility for free of charge repair (or replacement) of the hardware equipment or its parts, software upgrades, discovered software and hardware defects elimination;
– Terms for SYSTEM change requests implementation concerning the customization or changes in the user interface and system behavior should be specified;
– The Contractor will provide the procedure for sending faulty equipment for repair and receiving the repaired ones;
– The Contractor will provide the Technical Assistance Center (TAC) contacts and interaction procedure;
– The Contractor will provide remote technical assistance through VPN connection;
– The Contractor must provide the cost of post warranty support in the costs table;
– The Contractor shall evaluate and provide the list of spare parts with corresponding quantities to ensure uninterrupted operation of SYSTEM;
– Roadmap of the products and services should be presented including future software and hardware releases, implemented protocols, applications, tools, etc.;
– Optionally annual network technical audit can be offered by the Contractor. In this case network performance assessment criteria should be specified in the offer. In the outcome following points must be included:
o Presentation of network performance audit report with description of performed measurements and methodology;
o Evaluation of results and identification of network performance degradations, bottlenecks and deviations from normal/common behavior;
o Recommendations for improvement and optimization.
System acceptance
– A fully integrated and configured system should be presented for acceptance, including KPI reports configuration specified in Appendix 4;
– Acceptance test should be performed by the Contractor representative in presence of the specialists from “K-Telecom” CJSC;
– Acceptance test cases and scenarios should be presented by the Contractor and approved by the Customer;
– Based on acceptance test results the Contractor makes a Final Acceptance act.
Training
– Available trainings catalog must be provided by the Contractor;
– Training of 4 specialists for system administration level. The Contractor will provide the list of required trainings (architecture, functional description, development, administration, exploitation servicing), suggested locations and include it in the technical and commercial offer;
– Training of 20 specialists for system operator level;
– The Contractor will bear all the expenses for the Customer specialists training (travel, accommodation, visa expenses, etc.). The cost of required training must be included in the offer.
SYSTEM management
The platform should have management system with support of following modules:
– Configuration module;
– Statistics collection module;
– Protocol analyzer module;
– Call trace module;
– Roaming module;
– System monitoring module (CPU load, memory usage, etc.);
– Alarm module with mandatory support of SNMP;
– Remote administering.
Fault tolerance
The platform should ensure the performance of main/key functions according to the following normative:
– Signaling messages capture and analysis: 99.97% of time
– Availability of the SYSTEM: 99.97% of time
Security
Security configuration options should be foreseen in the SYSTEM to limit access based not only on authentication (username/password), but also based on IP address.
Monitoring center implementation
An optional offer for video-wall set-up can be made for visualization of monitoring system’s output (dashboards, trend reports, etc.).
Appendix 1: “K-Telecom” CJSC Core network topology
[pic]
Appendix 2: Statement of Compliance (SOC)
[pic]
Appendix 3 Interface types, quantities and load
|Interface |Port type |Number of Ports |Mean load (total) |Peak load (totoal) |
|SIGTRAN (SCCP, MAP, CAP, BSSAP, BSSMAP, RANAP, ISUP, |1G electrical |4* |100 Mbps |200 Mbps |
|SIP, BICC, etc.) | | | | |
|Gn (CP+UP) |10G optical |2 |2.5 Gbps |3 Gbps |
|Gi (CP+UP) |1G electrical |2 |2.5 Gbps |3 Gbps |
| |10G optical |2 | | |
|Gb FR |STM1 optical |2 |70 Mbps |100 Mbps |
|Gb IP |1G electrical |4 |50 Mbps |90 Mbps |
|Iu-PS (CP + UP) |1G optical |18 |2.3 Gbps |3 Gbps |
|S1 |1G optical |2 |200 Mbps |1 Gbps |
|SGi |1G electrical |2 |200 Mbps |1 Gbps |
|Abis IP** |1G electrical |2 |200 Mbps |400 Mbps |
|Iub IP** |1G optical |2 |700 Mbps |1 Gbps |
|Abis TDM** |STM1 optical |2 |200 Mbps |300 Mbps |
|Iub ATM** |STM1 optical |2 |200 Mbps |300 Mbps |
* Two ports in site Yerevan 1, two ports in site Yerevan 2
** Abis and Iub information is provided for dimensioning purposes for one controller with up to 120 BTS (more than 2000 TRXs) and 120 NodeBs configured.
Appendix 4 Basic reports for KPIs and counters
2G Voice
Call Setup Success Rate 5DAV
TCH Blocking Rate BH 5DAV
Drop Call Rate 5DAV
Paging
SSS SUCCESS (Switch Subsystem Success Rate)
Unsuccessful Calls directed to international operators
Unsuccessful calls directed to local operators
Drop Call Defects Cells Rate
3G Voice
Call Setup Success Rate UTRAN
Blok Sp Rate UTRAN
Drop Sp Rate UTRAN
SSS SUCCESS (Switch Subsystem Success Rate)
Unsuccessful Calls directed to international operators
Unsuccessful calls directed to local operators
Paging
Drop Call Defects Cells Rate
Location Update success Rate
CSSR Defects Cells Rate
Block TCH Defects Cells Rate
HR Defect Cells Rate
CSSR Defects Traffic Rate
Block TCH Defects Traffic Rate
Drop Call Defects Traffic Rate
HR Defects Traffic Rate
Equipment Downtime
CSSR Video UTRAN
Blok Video Rate UTRAN
Drop Video Rate UTRAN
Roaming KPI
ROAMING ASR
FOREIGN ASR
TRANSIT ASR
ROAMING NER
FOREIGN NER
TRANSIT NER
MER
MER UL Location Update
Voice and Video Traffic
SUM LOAD BSC
TCH_Traffic_BH_5DAV
TCH_Traffic_5DAV
TRAFF_SPEECH
TRAFF_VIDEO
2G Data
PS Attach Success Rate
GPRS PDP context activation Success Rate
TBF Establishment Success Rate
TBF Drop Rate All Cause
TBF Establishment Fail Rate due to congestion
User Data Throughput TBF Average UL
User Data Throughput TBF Average DL
Detach Success Rate
Intra SGSN RAU Success Rate
Inter SGSN RAU Success Rate
2G CDR (Cells Rate non-fulfilling the requirements)
2G CDTR (Traffic Rate in cells non-fulfilling the requirements)
2G PS Setup Time
GPRS Time Delay Rate
2G Mean Throughput UL
2G Mean Throughput DL
3G Data
CSSR RRC (Connection Setup Success Rate)
Drop RRC Rate
3G PS Blok Rate
3G PS Success Rate
3G PS Attach Success Rate
3G PDP context activation Success Rate
DL Data R99 throughput at BH
DL Data HSDPA throughput at BH
3G PS Drop Data Rate
3G PS Detach Success Rate
3G Intra SGSN RAU (Routing Area Update) Success Rate
3G CDR (Cells Rate non-fulfilling the requirements)
3G CDTR (Traffic Rate in cells non-fulfilling the requirements)
IRAT HO PS OUT
HSDPA CH Success Rate
3G PS Setup Time
3G PS Mean Throughput UL
3G PS Mean Throughput DL
3G PS Mean Throughput UL HSPA
3G PS Mean Throughput DL HSPA
R99 Time Delay Rate
HSPA Time Delay Rate
HSPA Retransmission Rate
R99 Retransmission Rate
Data Traffic
Total GPRS DL Traffic
Total GPRS UL Traffic
Total 3G DL Traffic
Total 3G UL Traffic
R99 Data DL Traffic
HSPA Data DL Traffic
LTE
Control Plane KPI
Attach
Attach request
Attach accept
Attach complete
Attach success rate
Attach Accept rate
Attach completion rate
HO X2
Ho request
HO request ack
HO complete (sur X2 ue cxt release)
HO cancel preparation phase
HO failure preparation phase
HO cancel completion phase
HO Completion phase failure due to Treloc Expiry
HO preparation success rate
HO completion success rate
HO success rate
Tracking area update
TA update request
TA update request with S1 context
TA update Accept
TA Update reject
TA update fail
TA update success rate
TA update preparation Success rate
TA update Completion success rate
User Plane KPI
Services Traffic load
Service Type: "DNS", "FTP", "HTTP", "MMS-HTTP", "MMS-WAP", "Other PS", "POP3", "SMTP", "Streaming" or "WAP"
Total IP volume (DL + UL) (GB)
DL Volume (GB)
UL Volume (GB)
Traffic load (%)
URL
Number of 1st page downloads
Number of objects on 1st page
Average duration of 1st page download (sec)
Average duration of PDP activation and 1st page download (sec)
Rate of PDP activation and 1st page download over 10s
Protocol
Traffic distribution
Service Type: "DNS", "FTP", "HTTP", "MMS-HTTP", "MMS-WAP", "Other PS", "POP3", "SMTP", "Streaming" or "WAP"
Protocol name (HTTP, HTTPS, FTP, FTP-DATA, MIC-DS, NETBIOS…)
Total IP volume exchanged (UL+DL) (GB)
Radio QoS
Abis KPI
SDCCH Congestion
Immediate Assignment Efficiency
TCH Assignment Efficiency
Incoming HO Efficiency
RX Lev before call Drops
RX Qual/TA before call Drops
RX Lev before HO
RX Qual/TA before HO
Call drop causes
Cell metrics per RXlev
DL Quality per RX Lev
UL Quality per RX Lev
Link Balance per DL RX Lev
Link Balance Distribution and RxQual
Cell metrics per TA
Timing Advance Distribution
RX Level per Timing Advance
RX Level PC Compensated per Timing Advance
RX Quality per Timing Advance
Link Balance per Timing Advance
TCH/Call drops per Timing Advance
SDCCH Statistics per Access Delay
Immediate Assignment Failures per Access Delay
Location Update Failures per Access Delay
MO SMS Failures per Access Delay
MT SMS Failures per Access Delay
NEIGHBOURHOOD statistics
Neighborhood statistics
Neighborhood Optimization
Hourly statistics
SDCCH Congestion
SDCCH traffic
TCH traffic
Capture Check
Capture Consistency
RRC connection setup inefficiency
Iub indicators
RRC connection setup inefficiency
Drops of connections in CELL_DCH
Drops of connections in CELL_FACH
Drops of connections in Compressed Mode
Radio Link Synchronization problems
Radio Link Setup failure rates
Radio Link Setup failure causes
Radio Link Addition failure rates
Radio Link Addition failure causes
Synchronized Radio Link Reconfiguration failures
Radio Link Reconfiguration failure causes
Active set life duration and size
Cells characteristics statistics (Ec/No at connection request; Ec/No vs distance at connection request; RRC connection success rate vs Ec/No; Distance; SIR target; UL BLER; Transmitted code Power, etc.)
Neighbor set statistics (3G/2G HO per 3G cell; 3G/2G HO per 2G cell; 3G neighbor cells per couple; 3G candidate cells for a best server; 3G best servers for a candidate cell; 2G Neighboring per 3G/2G cells couples; 2G Neighboring for 3G cell; 3G Neighboring for 2G cell)
RLC DATA Round Trip Time
RNC RLC DATA latency
HSPA Radio Bearer Setup Efficiency
Cell_ FACH to Cell_DCH channel type switching efficiency
HSPA Mobility Efficiency
HSPA Stability
HSPA Mobility Profile
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.