CDR Based Convergent Billing and Customer Care SYSTEM _____________________________________________________________________ Prepared By IT Project Circle, BSNL November 15, 2006 CDR BASED CONVERGENT BILLING AND CUSTOMER CARE SYSTEM 1. Bharat Sanchar Nigam Limited (BSNL) is having countrywide presence with over 55 million wire line & wireless telephone subscribers and offer hosts of other services like Data communication, National long distance, International Long Distance, Internet, Leased Line, etc. The Company proposes to implement next generation State-of-Art Call Detail Record (CDR) based Customer Care and Convergent Billing System. 2. Convergent Billing shall be based on Call Detail Records (CDRs) to be obtained from different type of Network elements capable of generating billable information, using centralized Mediation System. Since all the switches do not support generation of 100% CDRs, the Billing & Mediation system shall also support meter reading based billing, which is presently in practice in addition to CDR based billing in the same billing system. 3. The project shall prepare BSNL to face new challenges due to competition by providing effective and efficient Billing & Customer Care Solutions. It envisages building of country wide intranet, reduce the cost of operation, increase revenue realization, stop leakage of revenue besides providing round-the-clock best customer care operations. 4. The ultimate aim of BSNL is to implement the CDR based Billing and customer care solution through out India with four zones and four data centers. 5. The implementation plan of this tender is indicated below: 5.1 Proof of concept Phase– Setting up of data centers at East-South Zones( CDR Project 1) and North-West zones(CDR Project 2) and implementing all the software solutions along with the networking components meant for the SSAs mentioned below. 5.2 Roll out Phase – Implementation of CDR based billing and customer care system in all the remaining SSAs. 5.3 The two phases can be summarized as below: CDR Sub Data CDR Project POC Phase Roll out Project Center Phase 1.1 South CDR Project 1 4 SSA (Hyderabad, Bangalore, 66 SSAs Thiruananthpuram, Chennai, 1.2 East CDR Project 1 8 SSA (Kolkata, Patna ,Kamrup, 64 SSAs Ranchi, Raipur, Shillong, Bhuvaneswar, Kharagpur) 2.1 North CDR Project 2 7 SSAs ( Chandigarh, Ambala, 79 Lucknow , Meerut, Shimla, Dehradun, Jammu )* 2.2 West CDR Project 2 4 SSAs (Kalyan, Ahmedabad, 101 Bhopal, Jaipur) 6. The two data centers viz. Kolkata and Hyderabad will form a pair for Disaster Recovery. Similarly data centres of North (Chandigarh) and West zone(Pune) will form pair for Disaster recovery. 7. Scope of work The following paragraphs list out the the salient features of different components that are part of the CDR based convergent billing and customer care system 8. Hardware requirement is categorized in two broad levels for all categories of applications. First category of servers is of Connection or Presentation Servers for Applications which are multi instance and scale horizontally. For such category of applications, Rack mounted Blade Servers/ Rack mounted Stand Alone Servers shall have to used. These type of servers shall be utilized as: 8.1 EMS Gateways 8.2 HTTP servers 8.3 SMTP servers 8.4 Print Servers 8.5 AAA Servers 8.6 Logical Security Elements 8.7 Network Device Management Servers 8.8 DNS Servers 8.9 IVRS 8.10 Proxies, etc. Second category is of Datacenter class Servers for the purpose of Database where persistent data is stored. Application Servers are those where business logic resides within which data is manipulated in response to a client‘s request. Here database and application can scale diagonally i.e. scales vertically to an extent and horizontally beyond that. These services can run on multiple mid range servers or on a few high end servers having multiple instances of application running. Following applications shall run on Datacentre class servers: 8.11 Billing and Accounting (Including Rating, OM (if part of Billing) and all other related functionalities). 8.12 Revenue assurance 8.13 Mediation 8.14 Provisioning 8.15 EAI 8.16 CRM (Including CHS, WSC, OM (if part of CRM) and all other related functionalities) 8.17 Directory Enquiry 8.18 EMS 8.19 IOBAS ( Optional) 8.20 FMS (Optional) 8.21 Backup 8.22 High availability 8.23 Software 8.23.1 Various software applications with functional modules shall be as under: 220.127.116.11 Data Mediation System 18.104.22.168 Billing and accounting 22.214.171.124 Service Provisioning 126.96.36.199 CRM & Web Self Care 188.8.131.52 Directory Enquiry 184.108.40.206 Revenue Assurance 220.127.116.11 Enterprise Application Integration 18.104.22.168 Enterprise Management System 22.214.171.124 Enterprise Reporting 126.96.36.199 Security System 188.8.131.52 Other Software 9. Single convergent Bill 9.1 A customer Account having multiple services with each service having multiple instance shall have option to get single Bill. It shall also be required to give single bill for multiple of such accounts arranged in hierarchy under a Corporate/individual Account. 9.2 Individual Account 9.2.1 Data consolidation for service and multi instance Customer Account, within a zone, shall be done from existing billing system. Invoice would be generated for each service, the customer has opted for. Individual invoices for a single customer shall be received from different billing system and then a single invoice shall be generated at all four zonal billing centers, after taking in to account bulk discount if any. 10. Corporate Billing 10.1 Three zonal billing centers (South, West and North) and other Billing centers meant for billing other services like GSM based Mobile Telephone, IP Billing, Intelligent Network, etc shall be connected to East Zone to support Corporate Convergent Billing, payment collection etc. In short, BSNL will have multiple Billing System considering multi service environment, which will continue to be in operation even after full commissioning of proposed system. Hence, it is of utmost requirement for the proposed solution to be able to work in conjunction with other Billing system. 10.2 East Zone shall offer Single or multiple corporate bills for all services through bill level consolidation 11. The billing system shall be able to collect processed bills from the billing system of following networks existing in BSNL: a) MLLN System b) CMTS located at 5 different locations c) NIB-II d) IN System etc 11.2 CRM system of each Data Centers shall be integrated with service specific OSS/BSS infrastructure of MLLN, IN, NIB-II, CMTS in order to deliver integrated service and product to the customers. CRM integration shall be the single interface for the CSRs and the call agents to deliver services related to these networks. Accordingly, service provisioning module of these services also needs to be integrated with CRM for flow through provisioning. 11.3 Billing of Broadband services, CLI based Internet service and other IP services on same landline shall be the scope of implementation. In this scenario usage information (rated CDRs) shall be taken from the billing system of NIB-II. 11.4 CDMA Technology presently deployed in the BSNL network shall be provisioned and billed through the proposed solution. 12 Network Country wide exclusive TCP/IP based intranet shall have to be built up for collection of CDRs and/ or meter reading and for other operational requirements. This will cover all the major exchanges having 1000 or more lines, customer care centers, major BSNL offices including SSA headquaters, major RLU/RSU installations, existing Billing centers of each SSA, etc. The CDR Billing Network solution will utilize the NIB-2 MPLS core network for carrying the data traffic of the CDR Billing network. The CDR billing network shall be configured as a distinct VPN on the NIB-2 MPLS core network. 12.1 The CDR Billing network primarily consists of four layers – (a) Exchange Routers Layer (b) Aggregation Router Layer(c) Edge routers of NIB-2 MPLS network and (c) Data Center. Each of the four components is described in detail below. 12.1.1 The Exchange Router is at the lowest layer in the hierarchy of the network. It is located at the Local Exchange (LE) node where the PSTN switch is located. The Exchange router connects to the PSTN switch for collection of CDR data and execution of service provisioning commands. The features of the Exchange Router are described below: 12.1.2 The Exchange Router is co-located with the PSTN switch at the Local Exchange of capacity more than 1000 lines. The router connects to the PSTN switch through serial interface running X.25 / RS-232 and/or Ethernet interface. There shall be two connections – one for CDR collection and another for Service Provisioning. 12.1.3 There shall be two WAN interfaces on the router for network connectivity. The WAN interfaces shall be fractional E1 with G.703 interface. To ensure optimum bandwidth utilization, the link shall be configurable for speeds from 64 kbps to full E1. 12.1.4 The exchange router, in case of switches like EWSD, 5ESS, OCB-283, AXE-10, etc., collects the CDR traffic in X.25 format and encapsulates the data in TCP/IP. This data is then transported over the NIB-2 MPLS network to the Data Center of that zone. The exchange router, in case of some switches shall collect the CDR traffic in TCP/IP format directly. 12.1.5 There are hundreds of Exchange Routers in each Zone. To reduce the number of E1 links required between the exchange routers and the NIB-2 Edge Router, all Exchange routers covered under a particular Edge Router shall be connected in a daisy chain fashion as far as possible depending upon physical and technical feasibility and only the two routers at the two end points of the chain shall be connected to the NIB-2 Edge router. Further to maintain high availability, each of these two routers will terminate on separate NIB-2 Edge Routers. This ensures availability of route in case of both (a) Edge router failure and (b) any single WAN link failure. 12.1.6 To the extent possible, each exchange router shall be connected to the nearest/adjoining exchange routers. To reduce delay and convergence time, each daisy chain shall have no more than six Exchange Routers connected. 12.2 SSAs where formation of routers in daisy chain is not feasible, the exchange routers shall be connected in star topology to an Aggregation Router. The aggregation routers shall be dual homed to two nearest edge routers of MPLS node. 12.3 The Exchange Router shall also have Ethernet connectivity for connectivity to a Local Area Network (LAN) for routing LAN traffic from connected devices like PCs. 12.4 The Local Exchange shall have an Ethernet switch for Local Area Network (LAN) connectivity for CSR workstations. The Ethernet switch shall be connected to the Exchange Router for network connectivity. 12.5 The connectivity at the Local Exchange shall be extended to RLUs/Customer Service Center via copper pair /E1 using Ethernet Extender or Remote Router. 12.6 The NIB-2 MPLS Network will function as the IP core network for the CDR Billing network. The traffic from the Exchange Routers are aggregated to this network. 12.6.1 In case the NIB-2 Edge router does not have the required number of interface ports available for connectivity, a separate Central Router shall be deployed at such nodes. In such cases the connectivity from the Exchange routers/Aggregation routers shall be aggregated to the Central Router and the Central Router shall be unlinked to the NIB-2 Edge Router using serial or Ethernet interfaces. 12.7The Billing Data center is at the top of the network hierarchy and is the node where the entire traffic from all the exchanges (i.e. Exchange routers) after being transported through the NIB-2 MPLS network, finally terminates. The features of the Data Center are described below: 12.7.1 The Billing Center contains all the servers and workstations related to billing, Authentication, Database and Network management. The network components include Backbone Routers, Data Center Router, Ethernet LAN switches, Internet Routers, Network Device Management System (NDMS) etc. 12.7.2 The Data Center shall have two Backbone Routers. The Backbone routers provide connectivity from the NIB-2 MPLS network to the Data center. Two backbone routers are provided for redundancy and each Backbone router aggregates the traffic from one of the two NIB2 Edge Router nearest to the Data Center. The Backbone Router at the back end connects to the Data Center LAN. 12.7.3 The Data Center in each zone will also be connected via the NIB-2 MPLS network to the Disaster Recovery node as described in the earlier section. This is to ensure a no- single-point-of failure topology in the event of a WAN link and/or node failure. 12.7.4 The Data Center shall have multiple Data Center Routers. These routers shall be connected to multiple CDR collectors over X.25 serial links. The CDR data transported from all the exchanges in the zone are terminated at these collectors through the Data Center Routers. The CDR collectors transport the billing information over the Ethernet LAN to the related servers. 12.7.5 Provisioning, back-office and management traffic are also terminated to the servers in the Data Center. A redundant firewall and Intrusion detection system (IDS) will be deployed for the security of the data center (which is covered in the Security requirement section). The Data Center will also house the DR infrastructure for the peer zone. 12.7.6 The Data center shall have Internet Routers which will provide connectivity to the Internet. 13 SUMMARY Exchange Router The Exchange router is the key element in the CDR billing network. It provides the data collection point for the CDRs and other inputs from the PSTN and other transmission devices at the Local Exchange. Managed Exchange Ethernet Switch The managed Exchange Ethernet Switch provides connectivity for the network elements at the all Exchanges. It provides LAN connectivity for the co-located CSR terminals and the router. Ethernet Extender The Ethernet Extender shall be used to extend the LAN connectivity at the Local exchange to the adjacent stations on copper links (Not E1s but plain copper). It shall connect to the Managed Ethernet Switch at the Local Exchange and to the Ethernet Hub at the adjacent station. CSR Ethernet Switch The Ethernet switch shall be used to provide LAN connectivity to CSRs/PCs at the distant locations. It shall be up-linked to the Managed Ethernet Switch at the Local Exchange via Ethernet Extender. At locations where computer/CSR connectivity requirement exceeds six, a managed Ethernet switch shall be provided to provide manageability. Remote Router The Remote Router shall be used to extend the LAN connectivity at the Local exchange to the adjacent Customer care Centers adjacent or RLUs via E1. It shall connect to the Exchange Router at the Local Exchange. Remote Access Server (RAS) The Remote Access Server (RAS) provides the network termination point for the remote CSRs in the CDR zone. These CSRs shall access the CDR billing network via analog/digital modem dialup or via ISDN BRI. These calls shall be terminated on the RAS and after authentication through AAA and the CSRs shall be connected over TCP/IP to the Billing center. The RAS is connected to the Firewall in the Data Center through 10/100 mbps Ethernet interface. Backbone Router The Backbone router provides the connectivity from the NIB-2 MPLS network to the Data center. The connectivity is through STM-1 or E3 WAN links from the two nearest MPLS Edge Routers. There shall be two Backbone routers at the Billing Data Center node to provide redundancy. The Backbone Routers is connected through the Firewall to the Data Center LAN. The connectivity to the Firewall is through Gigabit Ethernet ports. Data Center Routers The Data Center router is located at the Billing center and provides the termination point for all traffic in the CDR billing network. It provides the X.25 serial connectivity to the CDR collector devices located in the Data Center. The Data Center Router is connected to the dual Backbone Routers over the LAN Data Center Ethernet Switch Type 1 The Data Center Ethernet Switch Type 1 provides connectivity to the servers, Backbone routers, IDS and other critical devices at the Data Center LAN including connectivity to the multiple CDR Collectors. There shall be two numbers of Data Center Ethernet Switch Type 1 chassis to provide redundancy for LAN connectivity. Data Center Ethernet Switch Type 2 The Data Center Ethernet Switch Type 2 provides LAN connectivity to the RAS, AAA, Web Application Servers, etc. AGGREGATION ROUTER The Aggregation router provides the aggregation point in SSAs where the Exchange Routers are connected in Star topology as described earlier. It terminates the WAN links from the connected Exchange Routers. The Aggregation routers are uplinked to two NIB-2 edge routers using E3 . CENTRAL ROUTER The Central router provides the aggregation point at those NIB-2 nodes where the Edge router does not have the required number of ports. The Central router will aggregate the links from the Exchange Routers/Aggregation routers and uplink to the NIB2 Edge router. Internet Router The Internet router provides Internet connectivity from the Data center. It provides web access to certain applications for customers and other external users. It terminates E1 or E3 WAN links from the Internet. There shall be two Internet routers for each Data Center. It connects to the Firewall in the Data center through 10/100 mbps Ethernet ports. Network Device Management System (DMS) The CDR Billing network shall be fully managed through a centralized Device Management System (DMS). The DMS will interface the overall Element Management System (EMS) of the CDR Billing and Customer Care Network located at the NOC at the Billing Center. The network DMS shall manage all the networking devices in the network including routers, RAS and LAN switches. Network Access Control System (NACS) The NACS is a centralised system that controls access by administrative users to all network elements in the CDR billing network. It allows policies to be configured for permitting user level and group level access and privileges to read and modify device configurations. This provides a centralised network device access control mechanism and also secures the network from intended and unintended misuse or misconfiguration of network elements resulting in disruption of the network. 14. Billing and Accounting 14.1 The billing & accounting system shall support the following business processes within the core system for both retail and reseller customers. i. Creation and maintenance of tariff plans as per BSNL‘s requirements. ii. Management of customer and service data required for billing. iii. Ordering of services and activation of billing iv. Workflow creation and order provisioning (in case OM is the part of the Billing application). v. Usage event guiding and rating (of any type of usage event). vi. Charges, pricing and discounts application. vii. Bill calculation, formatting and despatch. viii. Maintenance of individual subscriber ledger accounts. ix. Maintenance of deposit accounts of subscriber, along with adjustments, interest calculation, ability to transfer balances from deposit heads to amount outstanding and deposit collected for one service with another service etc. The system shall also have the ability to calculate security deposit to be collected based on previous calling patterns & account for the security deposits and all other types of deposits and reports pertaining to the same. x. Adjustments like bill cancellation, discounts, rebates and other credits and reports pertaining to the same. xi. Payment noting. xii. A/R management and open-item balance management. xiii. Collections/dunning. xiv. Journal calculation and posting. xv. A portal for communication amongst the field units & data centres and shall be medium through which reports etc can be downloaded by the field units xvi. The software should take care of all cases of cheque bounce; whether the cheque is collected on-line or off-line through other agencies like Post Offices. xvii. There should be utilities for authorized officers to enable or disable certain facilities e.g., the AO in a SSA should be able to extend the pay by date for a single or for multiple bills with valid reasons recorded xviii. There should be provision for initialization of sub ledgers. This initialization process should take the closing balance of the sub ledger from the old system and take it as an opening balance in the new system. This is true for all sub ledgers required by BSNL for revenue deposits, taxes, surcharge etc. It should be possible to initialize sub ledgers SSA wise. xix. It should be possible to generate a daily list from the system at different levels like SDCA, SSA, . The daily list is a record which gives the amount received for each on- line counter for all types of payment modes i.e. cash, draft, cheque and others. The system should provide a utility to the AO of each SSA to tally the money received from each cash counter with the amounts in the data base and then close the transactions for the day for further processing by the system for accounting purposes. xx. It should be possible to stagger the pay by dates for different group of customers for different exchange areas. xxi. It should be possible to initiate the billing process for (a) all the exchanges (b) except few exchanges (c) only a few exchanges. 14.2 The system shall provide customer and account management. The customer care functions shall be integrated with the ordering and billing processes so as to provide a single view of the customer and the customer‘s accounts. 14.3 Subscriber Hierarchies: 14.3.1 It shall be possible to Add/remove Subscribers to Subscriber hierarchies to represent an organizational structure of a company and/or household. 14.4 The system shall support Contracts configuration by which the Discounts and Unit Credits can be provisioned to the customer and be valid for a pre-defined duration. 14.5 The system shall support versioning of rating plans and shall apply the version that was in effect at the time of usage .The rating plans shall be easily configurable. 14.6 The system shall support bundling usage across different categories. 14.7 The system shall support charging the called party. All calls for a particular number shall be chargeable to the account of the called customer. E.g. toll free calls 14.8 Special Calls, Frequent numbers, Friends and Family: 14.9 The system shall support different rates based on the number called. 14.10 Ability to support differential rating for CUG 14.11 It shall be possible to apply Tariff and product structures flexibly without major software engineering effort. 14.12 Ability to assign a unique tariff to each customer or same tariff to a group of customers. 14.13 Special pricing shall be available based on dates to support holiday rates. 14.14 A system for real-time alarm checking and triggering shall be available to assist in efficient usage processing (e.g. SMS, e-mail updates based on credit limit thresholds being exceeded). Corporate Billing: 14.15 Billing module shall support both business and consumer oriented accounts within a single application across multiple billing systems and multiple services and it shall support the account hierarchy. 14.16 Billing system shall provide the functionality to organize the subscribers in billing hierarchies. Billing hierarchies may have subscriber accounts that are self-paying or subordinate (non-paying), where all charges of such accounts shall be billed to the parent account. 14.18 System shall provide BSNL subscribers to access services provided by external content providers and be able to handle the revenue sharing with the content provider through Billing system. It shall allow feeds from multiple systems such as: Retail Billing usage mediation platform content gateways and payment gateways 14.19 It shall support establishment of agreements and contracts with content partners. The contracts shall support rule-based rating and revenue sharing schemes. 14.20 Ability to respond rapidly to changing market dynamics with the fast introduction of multiple services—each with appropriate pricing plans and business models for any target market 14.21 Ability to provide taxes with respect to all charge types. 14.22 Ability to produce an Ad hoc bill (Bill on Demand), 14.23 Ability to generate supplementary bill based on manual inputs 14.24 Ability to produce Bill images in the format same as that of hard copy of the bill which is sent to the customer 14.25 The system shall be flexible to allow user to change the bill formats dynamically. The bill formats shall be configurable. 14.26 The billing system shall support the concept of open items. It shall be possible to group charges into open items which are then referenced through the various financial processes. The system shall allow Account Receivables to be tracked at multiple levels. 14.27 : Different methods of discounting shall be available 14.28 Ability to compare the bill value with respect to multiple bill plans and come out with best bill plan for a given subscriber/customer based on Report generated on request. 14.29 The system shall support a configurable and comprehensive journalizing process that enables all transactions in the billing system to be posted to the respective ledger accounts of the accounting module in the system. The accounting module should be closely coupled with the billing system and the accounting module should be capable of mapping the BSNL accounting codes. 14.30 Posting of information to accounting module of the system from the billing system shall be ensured. The accounting module should be based on double entry system. 14.31 The billing system shall support mapping of the transaction types to heads of account in the financial accounting system which is to be provided in the system 14.32 The payments, receivables and journalizing functions shall be a part of the core billing system. The proposed billing system shall ensure that the these functions are pre- integrated with the billing processes and do not require use of third-party systems or customization. The following business functions shall be supported by the billing and accounting module/s of the system as per detailed specifications below : i) Payment Entry (Online and Batch) ii) Deposit Management iii) Credits, Adjustments and Refunds iv) Collections (Dunning, Scenario-based collections and write-off) v) Aging Analysis vi) A/R and Balance Management vii) Journal Creation and Posting to General Ledger 14.33 Ability to charge late payment fees. It shall be possible to automate the calculation of late payment fees at : - Bill time - Payment time The system shall support calculation based on percentages and amounts for late fees. 14.34 The system shall provide all kinds of billing and accounting reports as per the requirements of BSNL. 14.35 Tight integration between the Billing Application and a CRM application is envisaged. 15. Customer Relationship Management 15.1 The CRM system shall enable BSNL to operate in a dynamic and competitive environment and respond rapidly to change. The system shall enable complete business flows that are applicable to the telecommunications industry. It shall be possible to configure various applications in such a way that the complete process flows can be enabled, enforced (if necessary), monitored and measured. In general, the following broad flows must be addressed by the system: a) Order Fulfillment to Billing b) Customer Call to Problem Resolution c) Marketing Campaign to Order Capture 15.2The applications shall be completely integrated with a robust workflow engine, which can provide support for controlling complex business processes across multiple applications. This shall be an inbuilt feature of the system. 15.3 The system shall support the complete service related business flow shown below: Web Complaint/ Check Check Request Knowledge customer Registered Base and Profile and Direct Call , IVR Offer Contractual Solutions Entitlement (SLA) Walk In, Direct Mail, Fax Plan and Execute Manual / Auto Perform remote Record the user Field Service Allocation of testing and request and (Spares, Resources to the resolution (where complaint Resources, Service Request applicable) through Timings) based on rules integration with Provisioning System or FRS Auto Update Debrief and raise Close the Obtain other applications charges (where Request or Customer (Billing, applicable) Complaint Feedback Provisioning, Commercial etc) 15.3.1 The system shall have features and interfaces to enable the following – a) Customer service through call centre, E-Mail, SMS, FAX, Web Self Care(WSC), letter b) Change management c) Sales and ordering d) Sales management e) Market and customer analysis f) Customer retention and churn management g) Campaign planning and execution and analysis h) Outbound marketing i) Integration with Order management, billing, CTI and IVRS, Provisioning systems and with all customer related subsystems j) Configuring and managing SLAs k) Workflow l) Inventory management for storing all equipment and outdoor related data of customers. m) Integration with enterprise reporting tool n) Integration with Complaint Handling system 16 Data Mediation System 16.1The Data Mediation System (comprising of Collection, Mediation & Distribution Modules) collects raw network usage data and transforms it into rich, billable business information. It is flexible enough to accept any event/record format that the network may generate and is able to generate rich records in any format required by Operational and Business Support System (OSS&BSS). A key mediation objective is to shield the OSS & BSS systems from changes in the network elements. It shall offer the flexibility; scalability and functionality necessary to achieve this so that the Mediation system can handle present and future Network Elements both and make it ―future proof‖, resulting in significantly reduced time to market for new product and service offerings. 16.2 The functionality of Data Mediation System shall be to collect, process and distribute Call Detail Records (CDRs) in a compatible format to downstream applications including but not limited to Customer Care and Billing, Inter-Operator Billing And Accounting System (IOBAS), Fraud Management System, Traffic Analysis, Decision Support System, Data Warehouse. It shall not be possible to edit the master data collected from network elements within the Data Mediation system (The Mediation System must maintain the master data in ―as received‖ status and must prevent any attempt to edit or modify it). 16.3 Mediation systems shall be capable of polling information from multiple number of network elements on a centralized basis 16.4 The collection Module shall be able to inter-work with various wireline, wireless, Intelligent Network (IN), IP network elements (GPRS/VoIP) and with other mediation systems supplied by various vendors and able to collect CDRs of any format including but not limited to ASN.1, ASCII, Binary, Hexadecimal, TAP1, TAP2, TAP3, etc as per requirement of BSNL from a single system for various network elements presently working in BSNL network for which mediation shall have interface. Basic collection requirement is in wireline network of BSNL. Direct collection shall be limited for network elements defined in this tender. However, mediation to mediation collection shall be required in case of Billing for services like broadband, content based services, leased line services etc. This collection capability from mediation to mediation systems shall be demonstrated. 16.5 In case of Automatic Trunk Exchange, the Trunk call details shall be downloaded automatically by the mediation system for passing on to the billing system. Format of Trunk call details may be ASCII or binary format similar to normal switch. For switches which do not generate 100% CDR generation, OMR & CMR have to be collected from a centralized location. 16.6 Mediation Module shall have a set of standard processing tools as part of its core functionality. It shall be possible to integrate additional processing modules as customized tools. It shall have individual processing rules for each network element type and data format. 16.7 Mediation module shall provide a Validation check by specifying the criteria to ascertain that data records (CDRs) meet the defined logic so that invalid data records can be filtered out. 16.8 It shall have sequential processing of CDRs to know if any CDRs is missing or duplicated in the stream of CDR. 16.9 Time Gap detection functionality shall be able to check the minimum as well as maximum acceptable time gap between consequent CDRs 16.10 It shall have user configurable error detection, correction and management features. 16.11 The system shall provide the capability for generating several levels of alarm notifications 16.12 Mediation System shall have a highly flexible scheduler, allowing the user to configure and specify when Mediation System will do system functions (collection, processing and distribution). It shall support user-configurable job scheduling, both time and event driven based. 16.13 Transfer multiple streams of CDR files (or records) to any number of Bill Rendering Systems INCLUDING IOBAS, Corporate Billing system and other Downstream Applications such as fraud detection, revenue assurance, service assurance, or marketing analysis systems using different transfer protocols. 16.14 Audit log shall store information with respect to CDRs and any other data acquired by the Mediation system for a particular function. It shall maintain historical information about the processing of received CDR files. 16.15 Event log shall contain information related to job handling and events from the Mediation System background processes. It shall be able to display logs of processes including but not limited to occurrence of an event, status of job of a particular event, user associated with the event and date & time of the logged event. 16.16 Mediation System shall have the capability to log user actions and entities related to these actions. The user log function shall assist the system administrator to detect the security violations by any user. 16.17 Error and Information log shall keep the information regarding any error conditions that occurred on the system, as well as information regarding routine activities. 16.18 Other logs such as command log, data collection log, data transmission log, application log etc. 16.19 The system shall have exhaustive built in statistical and reporting capabilities with option for on-screen viewing, printing and shall have relevant software for generation of custom reports by the users. It shall have a friendly GUI so that adhoc reports, and MIS graphics can be generated easily. 16.20 The system shall support Prevention and detection of gaps or duplicate data in collection and transmission. 16.21 The system shall allow administrator to restrict physical/logical access to the system. The administrator shall also be able to restrict access for authorized users to only those information resources necessary to fulfill their assigned job functions, 17 Provisioning System 17.1 The purpose of Provisioning System is to enable process activation of new subscribers and services in the communications networks. A CSR enters the necessary subscriber information into its customer care system. Provisioning system delivers it further to the right network elements, after which the subscription and the services are activated. In present setup, interaction with network elements have to be through NE specific MML commands. The provisioning system shall provision all switches in BSNL including C-DoT switches. All service provisioning requests made from client applications such as order management or CRM made for a specific subscriber shall result in the service being activated on the network elements such as the PSTN switches (Class 5), CDMA switches ,both BSC and MSC based system. The system shall also provide a uniform interface to manage the provisioned services. 17.2 A confirmation of action or error message shall be sent back to the originating system after processing a service –provisioning request. If there is any delay in the processing, the same shall be informed to the originating system. 17.3 System shall be able to operate in centralized or de-centralized mode, i.e the provisioning shall be performed from a central location under Centralized mode requirement and if necessary the provisioning for a particular region / location can also be performed by any user from that particular region / location. 17.4 It Shall provide necessary data for reconciliation between order management, billing and switch 17.5 The system shall be configurable, customizable and based on task model 17.6 The system shall be able to support BSNL's business rules for service provisioning as per commercial requirements mentioned in TEC GR . 17.7 The system shall support immediate activation of provisioning requests 17.8 The system shall be able to support establishment of user groups, and permissions to restrict certain users to specific provisioning activities 17.9 The offered system shall send provisioning transactions to the switches in the real time 17.10 The system shall support field validations, syntax checking, drop down lists and other standard widgets. 17.11 The system shall have an average response time of less than 5 seconds, 90% of the time, on a system operating at or below 50% CPU utilization. 17.12 The system shall support the usage of MML commands for Line and Circuit testing. Line testing functionality shall be built-in with the provisioning system. 17.13 The system shall be able to isolate internal fault verses external fault in the network 17.14 Testing of all the subscriber lines of a telephone exchange shall be possible within 24 hours 17.15 The inventory Management system shall maintain exchange and network related components/data required for provisioning and FRS activities. The data that has to be maintained shall include the following but not limited to : a. Telephone numbers and the status such as allotted, free etc. b. Equipment no. c. MDF particulars like vertical/tag number d. Cabinet in and cabinet out details. e. Pillar in , pillar out details f. DP etails, etc 17.16 In case of WLL, the details may relate to g. IMEI no. h. Telephone number i. ESN no. j. IMSI no. 17.17 In case of Broadband, details such as CPE (customer premises equipment), modem details will also have to be captured. 17.18 The inventory management system shall be updated by the provisioning system and FRS module. 18. SLA requirements of the system : The system shall operate with the following performance parameters. The parameters defined in this table are meant for IT related activities and do not involve any manual operations like extension of copper pair etc. Sl. No Area SLA Level 1(L1) Level 2(L2) Level 3(L3) 1.1 Provisioning Maximum time taken to activate 80% in 1 Hour 90% in 2 100% in 4 a subscriber with all requested hours hrs services from the time of logging of customer acceptance form details to the system till the time of provisioning of all services. To be measured for provisioning orders booked in every fifteen minutes. 1.2 Provisioning Maximum time taken to execute 80% in 2 hours 90% in 4 100% in 8 requests received from internal hours hours departments like accounts section for bulk barring, unbarring,deactivation or activation of customers directly from the backend, Indicator changes from the time of receipt of request 1.3 Provisioning Bulk Requests ( More than 1000 50% sub base 100% in 12 subscribers ) if given for per SSA in 8 hrs multiple SSAs and more than hours window 100 subscribers/SSA if given period SSA wise 1.4 Provisioning Any internal requests other than 100% in 1 hr Not Not bulk as mentioned above applicable applicable 1.5 Provisioning Maximum time taken to 2 days for 3 days for 10 days for configure changes to simple change medium complex provisioning process after change receipt of request 1.6 Provisioning Maximum time taken to 3 days 5 days 10 days configure interface specifications with new NEs 1.7 Billing Error bills < 1% per bill cycle 1.8 Billing Percentage of bills that are 99% (because generated within specified date of clause 16) and time I.e. on bill cycle date 1.9 Billing Maximum time taken to < 10 seconds < 15 seconds < 20 seconds generate itemized bills from the time of receipt of request - for bills which are available on-line 1.10 Billing Maximum time taken to < 20 seconds < 30 seconds < 40 seconds generate itemized bills from the Sl. No Area SLA Level 1(L1) Level 2(L2) Level 3(L3) time of receipt of request - for bills which are available near on-line 1.11 Billing Maximum time taken to upload in 4 hour customer payment information window period to billing system from the time of entry in the Payment & Accounting System 1.12 Billing Bill format changes (not specific 2 days for 5 days for 10 days for to a Customer) simple* medium* complex* 1.13 Billing Maximum time with which same day in 4 same day in 8 12 hour billing information shall be hour window hour window window for uploaded to other IT systems for retail for retail retail such as IVRS, Database customer & 30 customer & customer & Warehouse etc. after generation minutes for 45 minutes 60 minutes of the bill corporate for corporate for corporate customers customers customers 1.14 Billing CDRs billed in a bill cycle as a > 99% percentage of total number of billable CDRs to be billed for that bill cycle 1.15 Billing Number of occurrences where < 2 in a month the bill cycle run spills over the window period assigned for billing 1.16 Billing Number of unbilled accounts <1% <2% <3% from the bill cycle 1.17 Billing Maximum time taken to post < 24 hours summary entry into GL post billing 1.18 Billing & Rating Maximum time taken to respond 1 day for 2 days for 5 days for to new tariff plan configuration simple medium complex requests received from the business, with feasibility analysis and schedule for completion of the configuration post sign off 1.19 Billing & Rating Maximum time taken to 1 day configure a tariff plan in production after receipt of signoff on UAT from business user from an IT perspective (excludes training and mktg related activities) 1.20 Billing & Rating Maximum time taken to < 1 day configure pulse matrix changes from the time of receipt of changes in a softcopy form in agreed format by IT 1.21 Billing & Rating Maximum time within which < 2 hours CDRs are rated after mediation submits the CDRs for rating Sl. No Area SLA Level 1(L1) Level 2(L2) Level 3(L3) 1.22 Billing & Rating Maximum time taken to start < 20 minutes clearing CDRs in error after receipt of instructions for the same from the business user post correction of the reject reason by the business user 1.23 Billing & Rating Error CDRs < 1% per batch 1.24 Mediation Maximum time taken by < 1 hrs for mediation to process CDRs online CDRs generated by Switch and send to For NEs that rating from the time of support time generation of CDRs at the based creation Switch of files, within 10 minutes of closure of a file 1.25 Mediation CDR rating errors due to < 1% per batch mediation as a percentage of total number of CDRs rating errors 1.26 Mediation Maximum time taken to < 5 days if configure interface industry specifications with new NEs standard protocols are used and detailed switch documentation is available 1.27 Mediation Maximum time taken to Max 24 hrs configure changes to an existing interface specifications 1.28 CRM Maximum time taken to respond 1 day for 3 days for 5 days for with feasibility and schedule, for simple* medium* complex* CRM configuration requests made by user 1.29 CRM Delay in configuring CRM <2% system as percentage of scheduled time for the configuration request 1.30 CRM Maximum time to configure 1 day for 3 days for 5 days for scripts post sign off simple* medium* complex* 1.31 CRM % age of first time/call > 70% resolution of queries/complaints 1.32 CRM Maximum time taken to 1 day for 3 days for 5 days for Configuration of new workflows simple medium complex / changes to existing workflows 1.33 CRM Screen pop-up response time < 2 seconds 1.34 CRM Configuration of new tariffs, 1 day for 3 days for 5 days for package plan, handset info etc simple* medium* complex* 1.35 CRM Maximum time taken for 80% in 1 Hour 90% in 2 100% in 4 provisioning of service hours hrs activation/ suspension/ deactivation requests Sl. No Area SLA Level 1(L1) Level 2(L2) Level 3(L3) 1.36 CRM Maximum time taken to < 3 minutes complete an order entry for a single account/ phone / simple list of services 1.37 CRM Maximum time taken for bulk 50% sub base changes to services per SSA in 8 hours window period 1.38 CRM Maximum time taken for bulk 50% sub base number changes per SSA in 8 hours window period 1.39 Applicable to all Percentage of MIS reports that 100% are generated as per agreed schedule 1.40 Applicable to all Maximum time taken to create/ 24 hrs modify user ids and rights from the time of receipt of request by IT with relevant approvals. 1.41 Applicable to all Maximum time taken to respond 2 hrs to queries raised by users on application from the time of logging of the query 1.42 Applicable to all Maximum time taken to resolve 12 hrs to queries raised by users on application from the time of logging of the query 19. Directory Enquiry 1.0 General Requirement 1.1 The DQ will provide access through TCP/IP to directory listing information via: 1.2 Directory Enquiry workstation 1.3 Web Browser 1.4 SMS message 1.1. The critical requirements are 1.1.1. Flexible and efficient database. 1.1.2. Access from Web, SMS and Workstation 1.1.3. Flexible and easy to use operator workstation 1.1.4. 0.2 second average search response time 1.1.5. Support for more than 10 million listings 1.1.6. Support for 60,000+ call requests during the busiest hour 1.1.7. Scalability of the solution, while protecting initial investment 1.1.8. Integrated support for both ‗white‘ and ‗yellow‘ pages listings 1.1.9. Integrated access to other databases in India (max 10 such integrations) 1.1.10. Ability to integrate with a variety of data sources 1.1.11. Availability and Reliability of the system. 1.2 The database will contain both ‗white‘ and ‗yellow‘ pages listings (in English), in particular: 1.2.1 Residential listings 1.2.2 Business listings and Business Categories 1.2.3 Government listings. 1.2.4 Urban / Rural listings. 1.2.5 Public Utility Services. 1.2.6 BSNL Service Directory Listing. 1.2.7 ISD / STD code listing. 1.2.7 Advertisements 1.3 Updates to the database can be done in the following ways: i) Batched updates from the Service Order System ii) Individual real time update from Service Order System (CRM) iii) Full download from the Service Order System iv) Updates by applying business rules to existing directory listings v) Manual updates vi) Emergency / immediate updates 1.4 The directory listings database can be accessed from the web with a standard web browser (MS Internet Explorer, Netscape). No additional applications shall be required with the web browser. 1.5 The database search response time shall be 0.2 second. 1.6 The database shall be able to contain a minimum of 10 million plus directory listings. The database shall be able to support a minimum of 60 thousand searches per hour. 1.7 The average time an operator shall work on a request for a directory listing is 30 seconds or less. 1.8 The system shall support CTI integration with an ability to deliver the requested information in different ways. 1.9 The inquiry application shall support softkeys. The softkeys are context sensitive and change automatically or manually. The current functions of the softkeys are displayed on the screen. 1.10 It shall provide the capability to form and print the city wise Directory of all the subscribers. 1.11 The DQ solution will provide reports on the number of searches that are performed on the database and Operator statistics and calls. 20. Enterprise Management System 20.1 Enterprise Management System (EMS) is required to manage Servers, Desktops, Database and Enterprise Event Correlation in each zone. EMS shall be deployed separately for each zone and within each zone; the deployment would be at the zonal data center to manage Hardware, Software, network and other components at Data Center location, Aggregation Locations and Downstream Locations of respective region. 20.2 The zonal data center would have the EMS server with central management console. In order to build redundancy in the EMS architecture, there shall be multiple gateway servers in the data center to manage the servers, and desktops at point of presence locations and exchange level locations. 20.2.1 EMS shall have modules to provide the following: 20.2.2 Server management 20.2.3 Event Management 20.2.4 Desktop management 20.2.5 Database Management 20.2.6 Network Management 20.2.7 Application Management. 20.2.8 Service Level Management and Reporting 21. Servers 21.1 All individual software applications (all applications on DC Class & Edge class hardware) shall have to be sized accurately to meet the desired service level/ performance criteria at the full load. In this regard SI shall furnish the sizing information and an undertaking duly authenticated and signed by respective software vendor. 21.2 All applications shall fail over on to High availability Server in separate partitions. In case of failure of any Application or Server, it shall be possible to dynamically move CPU resources from other partitions to the High Availability Partition without re- booting the system or partition 21.3 Capacity of High Availability Server shall be calculated in a such a way that in case of failure of any single application, it shall be possible to dynamically allocate same amount of CPU resources (as in production) to the HA partition. 21.4 Data Center class server shall be 64 Bit multiprocessing UNIX Servers. 21.4.1 Centre servers shall be equipped with minimum 64 cores having at least 1.5 GHz Processing speed. This capacity includes 20% Headroom for future Scalability. 21.5 These servers shall be capable to support multiple partitions (minimum 8 partitions) and Dynamic movement of CPU compute resources from one partition to another when required. This feature shall not require rebooting of server or the partition. 21.6 It shall be configured minimum with 4 GB DDR2 memory per core and shall be scalable to minimum 8 GB DDR2 memory per core in the same server. 21.6.1 Each partition shall have two numbers of Gigabit Ethernet controllers for public interconnect and two numbers of Gigabit Ethernet controller dedicated for cluster interconnect. 21.7 The Server/Partition shall have at least two numbers of 4 Gbps Fiber Channel adapter. Database partitions shall have minimum of 4 fibre channel adapter per partition. 21.8 Connection / Presentation Servers for Edge Applications shall have the following features - 21.9 32/ 64 Bit processor of 3.2/ 1.6 GHz based with multiprocessing capabilities. 21.10 Min 2 processors 21.11 Min 4 GB DDR2 ECC SDRAM 21.12 2 x 72 GB internal SCSI Hard Disk 21.13 Dual Fibre Channel Ports per shelf for public interconnect to SAN with 1+1 redundancy. 21.14 PC based Management Consoles for DC class servers and Edge servers will be connected to the servers using dedicated Ethernet switched network. 22. IVRS 22.1 It is envisaged to have IVR system installed at each of the zonal data centers to provide different services from a common platform and in different regional languages. 22.1 The following services, shall be provided through IVRS : a. Automatic Telephone Fault Booking & Clearance Service b. Automatic Bill Enquiry & Payment Reminder Service c. Automatic Changed Number Information & Bulk Changed Number Announcement Service d. Automatic Trunk Call Booking Service e. Interactive Commercial Inquiry & Special Services Inquiry f. Interactive Telephone Connection Booking And Status Enquiry Service h. Payment Registration service. 22.2 IVRS shall be connected behind the IP EPABX which in turn will be connected to one or more call centers. 22.3 It shall be possible to send & populate agents PC with Screen pop containing relevant customer data and the information about the queries he had made on the IVR. 22.4 IVRS shall be capable of integrating with multiple applications (on different Operating Systems) and Databases to cover entire range of possible services which are to be offered through IVRS. Some of the applications required to be integrated shall be CRM (including Fault Management, Help Desk), BILLING, DIRECTORY ENQUIRY, CALL CENTERS etc. 22.5 The System shall be able to capturing the CLI data & DNI and transfer the same to CRM or any other relevant application. 22.6 It shall be possible to register for activation of additional facilities in a customer account through a T-PIN After the registration/activation the details shall be transferred to the Billing system. 22.7 IVRS shall be able to get information, text/data, from databases, convert to voice, and speaks it back to the caller In relevant /desired language.Total 10% of IVRS ports at each zone shall be able to have this facility in atleast Hindi & English 22.8 IVRS shall maintain log of all services offered which can be used for audit and analysis purpose. 22.9 There shall be 99 % uptime for the IVRS. 22.10 The CTI functionality shall facilitate synchronized transfer of the call to the agent so that the agent receives the right voice call & the screen pop together.The CTI shall also pass information regarding the IP phones IP Address & port number to facilitate Call recording for IP phones in a DHCP environment. 22.11 Automatic Call Distribution application will be centrally located at the data center. This shall be able to route the call to any remote call center Agent using IP phones. 22.12 IP EPABX shall support interfaces to directly connect to the CO switch. This EPABX will be placed in the Data Center along with other IVRS components. 22.13 IP phones will be used at remote call centers. Remote IP phones will connect to LAN at remote call center. 22.14 IVRS Connectivity To Call Centers & Within Data Center Data Center LAN E1R2/E1PRI E1R2/E1PRI IP EPABX CTI Server BSNL PSTN Cloud IVRS CRM Call Transfer To Agent WAN Call Center 2 Call Center 1 23. Security System 23.1 The growth of the Internet and the move to Web-based computing has brought about new challenges to how Information technology is used by businesses. Central to this deployment of IT is the data center management. With the increase of security incidents against information technology the need to develop an Information Security Management System to ensure the security of the data centers has become imperative. An integrated approach in which security is designed into the management process will help BSNL keep itself robust and ready to handle all security and technology challenges to its Information Technology deployments. 23.2 To achieve the security goals for its integrated Customer Care & Convergent Billing System, BSNL aims to deploy a multi-layered detailed security system covering the data center‘s physical and logical systems needs. 23.2 Physical Security System There shall be a system to regulate, detect and monitor the entry/exit of personnel and to monitor the movement of authorized personnel inside the Data centre. This shall be possible through the provision of Closed circuit TV and Physical Access Control System (Biometrices Technology). BSNL will provide round the clock physical manning of entry/exit points as per the requirement. 23.3 Components of PACS a) Door Controller b) Biometric Scanner c) Electromagnetic Locks d) Electronic Rodent Management System 23.4 There shall be an arrangement to restrict entry to different areas of Data Center through layered check points. 23.5 CCTV system shall ensure effective supervision of all important areas and also to create a record for post event analysis Logical Security System 23.6 Logical Security Solution of Data Centre shall protect its individual components from outsider and insider attacks. 23.7 It shall have the following components – 23.8 Firewall 23.8.1 All critical Data Center equipment including servers and LAN devices shall be connected to the ―inside‖ or secure zone of the firewall. All non-secure and general access servers shall be connected to the de-militarized zone of the firewall. The ―outside‖ interfaces of the firewall shall be connected to the outside network containing the Backbone and Internet routers. 23.8.2 Minimum number of rules/policies supported by the firewall shall be 30000. 23.8.3 The firewall shall be appliance based and shall facilitate multi-vendor, multi- application environment and shall support third-party products. 23.8.4 The firewall shall support minimum 1,000,000 concurrent sessions 23.9 Network based IDS (Intrusion Detection System) 23.9.1 It shall be appliance based NIDS capable of monitoring multiple LAN network segments. 23.9.2 It shall act as a second level defense mechanism after the firewall in the BSNL network. 23.9.3 The NIDS shall detect unauthorized internal/external intrusion attempts into the data centers and shall be able to apply appropriate policies on the firewall so as to prevent such attacks in real time. 23.9.4 The IDS probes shall be able to monitor and secure all ethernet LAN segments to which it is connected. 23.10 Host-based intrusion detection System (HIDS) Host based Detection System (HIDS) shall provide the third level of protection in the Billing Data Center. It shall provide protection at the server level file systems. Host-based intrusion detection system should reside on all servers. 23.10.1 It shall be able to scan Operating system and application log files, for footprints of malicious behavior. 23.10.2 The file system shall be monitored to see if sensitive files are being accessed or tampered with. 23.10.3 HIDS shall monitor the system level changes (Windows Registry in Windows operating system)for any attempts to alter or delete it in any form. 23.10.4 It shall be able to protect servers, workstations, applications, file permissions and contents, file size etc. 23.11 Anti Virus Management System 23.11.1 The antivirus solution shall provide protection for desktops against Internet threats through integrated anti-virus, firewall, intrusion detection and content filtering 23.11.2 It shall have provision to scan/ detect/ remove boot sector, memory resident, macro, embedded script (Hostile Java scripts, VB scripts, Active X and other embedded scripts/controls) viruses on all servers and workstations etc. 23.11.3 It shall have a Centralized Management Console for centralized configuration, installation, deployment & policy management/distribution for anti virus, Firewall & intrusion detection functions. It shall enable Common Distribution Mechanism via push Technology for distribution of latest virus definitions and configuration files automatically to clients and servers from a central location. 23.12 Server Access Control System (SACS) 23.12.1 The SACS is a centralized system that controls access to the servers, file systems and databases in the Billing data Center. 23.12.2 The SACS shall control access to all server system (all industry standard OS) resources including applications, data files, devices, processes/daemons, and audit files. 23.12.3 It shall intercept security-sensitive events in real-time, and evaluate its validity before passing control to the OS. 23.12.4 The SACS shall provide complete file protection by intercepting every file access request and deciding if the user is authorized to access the file. 23.13 User management 23.13.1 It shall provide simple to use graphical interface to enable complete management of all user, group, resource, audit and policy settings, either centrally for an enterprise or de-centralized to departments or business units. 23.13.2 Identity management software shall be used for all types of user management. 23.13.3 Identity Management shall allow for centralized provisioning of users at the regional data center, thereby allowing users to get access to resources like operating system- AIX, Solaris, HPUX, Windows, RDBMS- Oracle, DB2 , Directory Servers (LDAP) and BSS/OSS applications. It shall integrate with the Access Management System. 23.13.4 The Access Management requirements will primarily be for Authentication, Authorization, Access and single sign-on for web based applications for the intranet user. 23.14 Access Management shall provide a centralized Authentication, authorization and Access and Single Sign-On for users requesting for accessing various applications as per their roles and policy. The applications would include the various operating systems and telecom applications deployed in the data center. 23.14.1 Access management shall have mechanism for Authentication and Authorization of users based on their roles to access hardware and application resources in the data center. 23.15 The AAA server provides Authentication, Authorization and Accounting services for network users dialing into the CDR Billing network from various nodes via the Remote Access Servers. 23.16 The DNS server shall provide DNS based routing for the X.25 Over TCP/IP(XOT) traffic from all the exchange routers. In the CDR billing network, the X.25 traffic is encapsulated in TCP/IP and routed using IP addresses. Hence for each X.121 address there will be a corresponding IP address. Since the CDR billing network is a large network consisting of hundreds of routers, manual configuration of X.25 and IP addresses on all routers is not scalable and error prone. Hence it is planned to provide a centrally managed easy-to use DNS based mechanism to simplify the X.121 to IP address management. 23.17 The DNS server shall maintain a route table containing the X.121 address to IP address mapping for all X.25 destinations in the network. 24. Web Self Care 24.1 Web self care module shall be able to provide a one-stop facility to the individual subscribers as well as corporate customers (enterprise wide access – corporate self care) with secure access to their information including but not limited to Bill viewing, unbilled usage viewing, Bill payment, complaint booking & monitoring, general enquiry & directory enquiry, applying for & buying products & services online, updating personal information, etc. using a standard Internet browser. 24.2 It shall have the following features – 24.3 Account and Service Management Features that will allow the customer to Select from the various services or service features from the menu and post a request for its activation or deactivation; View the detailed list of self provisioning features available on the web site viz. STD facility Barring/ Allowing, ISD facility Barring/ Allowing, etc. 24.4 Electronic Bill presentment and payment 24.5 Trouble Ticketing 24.6 Marketing requirements 24.7 Integration with CRM, existing web portal, GSM CRM etc. 24.8 The system shall adopt various inherent security mechanisms, such as Data encryption, Authentication, Authorisation, Account access management, Logging and monitoring all system access, Resource allocation management, User access privileges management, Carefully-designed system architecture, Secured code development methodologies, etc. 25. Disaster Recovery 25.1 Disaster will be considered as an event that makes the continuation of normal functions of a data centre impossible. 25.2 North DC will be DR for West DC 25.3 West DC will be DR for North DC 25.4 South DC will be DR for East DC 25.5 East DC will be DR for South DC 25.6 Each data centre shall have normal processing capacity to take care of business requirement of its own load. In case of any natural or man made DR instance, all critical functionality related to all applications shall switch over to the designated DR site. The degradation of performance for the applications failing over to the DR site is permitted up to 50% in case of operation of Billing, EMS and CRM etc. 25.7 Each data center shall have separate hardware for the purpose of disaster recovery. 25.8 Collection servers of mediation system shall have 100% redundancy to take care of both sites. No degradation of performance is permitted in case of collection. 25.9 It shall be possible to update the secondary by the Primary on line or at configurable intervals in steps of at least 15 minutes. During regular updates, only incremental data pertaining to the previous interval shall be transferred. 26. Electronic Stapling 26.1 One of the major requirements of Customer Care &Billing System project is to provide single bill for corporate customers as well as individual customers covering multiple services provided across different geographic locations in India. 26.2 Single bill for individual and corporate customers covering multiple services and multiple instances in a zone will be taken care of by the respective zonal billing system. Single bill for a customer having all-India presence will however be taken care of by the Kolkata billing centre. 26.3 The multi-zone single bill generated by the Kolkata billing centre will be accessed by BSNL users of other zones for all bill printing and post billing operations. This access will be done through the portal. The portal access will be through internet/ BSNL Intranet. 26.4 Creation of one bill for corporate customers with bulk discounting and any other discounting as per BSNL policies towards corporate customers. 26.5 Process one payment against the single corporate bill and do end to end accounting for all electronically stapled bills taken from other billing systems. 26.6 Payment collection & various reporting into the systems. 26.7 Payment adjustment back to individual billing system for the billed amount after suitable adjustment of bulk/corporate or any other discount. 26.8 A single portal solution to enable front office operation for enabling Customer access, Bill payment, Bill presentation, Reporting including Customer hierarchy reports etc 26.9 To provide single view of a customer of all its products & services to a CSR. 26.10 Four zonal billing center and other Billing centers meant for billing other services like GSM based Mobile Telephone, IP Billing, Leased Line Billing, Intelligent Network, etc shall be connected to East Zone to support Corporate Convergent Billing, payment collection etc. BSNL will have multiple Billing System considering multi service environment, which will continue to be in operation even after full commissioning of proposed system. Hence, requirement for the proposed solution is that it shall be able to work in conjunction with other Billing system. 26.11 Invoices will be produced on BSNL‘s existing billing systems (different systems for different services). An invoice would be generated for each service the customer has opted for. Individual invoices for a single customer will be received from different billing systems and then an invoice will be generated after calculating the new charges taking into account the discounts to be applied. 27. OTHER ITEMS Other items being procured in this project are a) Laptops b) PCs or workstations c) UPS for the data centres.
Pages to are hidden for
"More about CDR billing"Please download to view full document