More about CDR billing by pengxuebo

VIEWS: 36 PAGES: 28

									 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:

8.23.1.1 Data Mediation System
8.23.1.2 Billing and accounting
8.23.1.3 Service Provisioning
8.23.1.4 CRM & Web Self Care
8.23.1.5 Directory Enquiry
8.23.1.6 Revenue Assurance
8.23.1.7 Enterprise Application Integration
8.23.1.8 Enterprise Management System
8.23.1.9 Enterprise Reporting
8.23.1.10 Security System
8.23.1.11 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.

								
To top