DEPARTMENT OF INFORMATION TECHNOLOGY AND TELECOMMUNICATIONS 75 Park Place, 9th Floor New York, NY 10007
Michael R. Bloomberg Mayor Gino P. Menchini Commissioner
REQUEST FOR PROPOSALS (RFP)
CITYWIDE MOBILE WIRELESS NETWORK PIN: 85804CSP0009
IT IS ILLEGAL TO ENGAGE IN PRACTICES THAT COULD UNDERMINE OR PREVENT A FAIR AWARD RELATED TO THIS SOLICITATION.
THE COMPTROLLER OF THE CITY OF NEW YORK IS CHARGED WITH THE AUDIT OF ALL NEW YORK CITY CONTRACTS. ANY CONTRACTOR WHO BELIEVES THAT THERE HAS BEEN UNFAIRNESS, FAVORITISM OR IMPROPRIETY IN THE PROPOSAL PROCESS SHOULD INFORM THE COMPTROLLER OF THE CITY OF NEW YORK, OFFICE OF CONTRACT ADMINISTRATION, ONE CENTRE STREET, ROOM 835, NEW YORK, NEW YORK 10007; TELEPHONE NUMBER 212-669-2797
AUTHORIZED AGENCY CONTACT PERSON Proposers are advised that the Authorized Agency Contact Person for all matters concerning this Request for Proposals is: Name: Mailing Address:
Telephone #: Fax #: E-Mail Address:
Ms. Anne Cody New York City Department of Information Technology and Telecommunications 75 Park Place, 9th Floor New York, NY 10007 (212) 788-6276 (212) 788-6489 (e-mail preferred)
[email protected]
All questions regarding this procurement should be submitted ONLY to the above Authorized Agency Contact Person. Straight-forward questions (e.g., travel directions to Pre-Proposal Conference location) will be answered orally. All substantive questions must be made in writing, and submitted by mail, e-mail or fax. All answers to questions, and any Addenda to this Request for Proposals, will be available to all prospective Proposers.
Appendix A, entitled “General Provisions Governing Contracts for Consultants, Professional and Technical Services,” and New York City security requirements documents are available to prospective Proposers upon request.
2
TABLE OF CONTENTS
Page SECTION I – INFORMATION AND TIMETABLE A. Release of Request for Proposals
6
B. Pre-Proposal Conference (Optional)
6
C. Last Date to Submit Written Questions
6
D. Site Visits
6
E. Proposal Due Date, Time and Location
7
F. Project Start Date – Anticipated
7
SECTION II – SUMMARY OF THE REQUEST FOR PROPOSALS A. Purpose of this RFP
8
B. Anticipated Contract(s)
9
C. Anticipated Contract Term/Timetable
9
D. The Networks
9
E. Definitions
10
F. Exclusion from Participation in Solicitation
10
SECTION III – SCOPE OF WORK A. Obligations of the Integrator
11
B. Project Management and Quality Control 1. Management
11
2. Quality Control
12
3. Project Manager and Project Team
12
C. Implementation Plan/Timetable/Acceptance Plan/Maintenance Plan 1. Implementation Plan
14
2. Project Timetable
14
3. Pre-Trial Test Data and System Acceptance Test Procedures
14
4. Network(s) Maintenance and Repair Plan
16
D. Network Features, Functional Specifications and Requirements 1. Network(s) Features and Functional Specifications
16
2. Network(s) Requirements
18
E. Additional Requirements and Specifications Applicable to Classes
20
F. Network(s) Design and Implementation
22 3
1. Spectrum/Propagation Analyses/Interference Analyses
23
a. Spectrum Availability
23
b. Propagation Analyses
23
c. Interference Analyses
25
2. Network(s) Infrastructure and “Backhaul”
25
3. Quality of Service
25
a. Network(s) Resiliency
25
b. Network(s) Security
26
G. Network(s) Software/Hardware Acquisition/Development
26
H. Network(s) Software/Hardware Installation
29
I. Acceptance Testing
30
J. Network(s) Warranty, Maintenance and Repair 1. Warranty for Deliverables/Workmanship
31
2. Maintenance
32
3. Response Time
34
4. Downtime
34
5. Reporting
34
K. Industry Trends and Software Updates/Enhancements
34
L. Network(s) Training and Documentation
35
M. Site Management and Network(s) Operations Services
39
SECTION IV – FORMAT AND CONTENT OF THE PROPOSAL A. Proposal Format
43
1. Proposal Cover Letter
43
2. Technical Proposal
43
3. Price Proposal
60
4. Acknowledgment of Addenda
63
B. Proposal Package Contents (“Checklist”)
64
SECTION V – PROPOSAL EVALUATION AND CONTRACT AWARD PROCEDURES A. Evaluation Procedures
66
B. Proposal Evaluation Criteria
67
C. Basis for Contract Award
68
D. Pilot Implementation Evaluation Criteria
68
SECTION VI – GENERAL INFORMATION TO PROPOSERS
70
4
ATTACHMENT A – PROPOSAL COVER LETTER
71
ATTACHMENT B – ACKNOWLEDGMENT OF ADDENDA FORM
72
ATTACHMENT C – WIRELESS VEHICULAR TRAFFIC CONTROL
74
ATTACHMENT D – INSTALLATION GUIDELINES
90
ATTACHMENT E – MAP OF MANHATTAN PILOT AREA
94
APPENDIX A: General Provisions Governing Contracts for Consultants, Professional and Technical Services
95
5
SECTION I – INFORMATION AND TIMETABLE
A. Release of the Request for Proposals
Date:
March 24, 2004
B. Pre-Proposal Conference:
Date:
April 12, 2004
Time:
10:00 AM – New York City (NYC) Time
Location:
N.Y.C. Fire Department Auditorium 9 MetroTech Center Brooklyn, N.Y. 11201
DoITT personnel knowledgeable regarding this project will conduct a Pre-Proposal Conference (“Conference”). Nothing stated at the Conference shall change this RFP unless the change is made in writing by the Agency Contact Person indicated on the cover sheet of this RFP. Attendance at the Conference by Proposers is optional, but is recommended by the Agency.
C. Last Date to Submit Written Questions: April 16, 2004 @ 3:00 PM (NYC Time)
Written questions may be submitted to the Agency Contact Person indicated on the cover sheet of this RFP. Questions may be submitted by mail, fax or e-mail, as long as they are received by the last date for submission of written questions indicated above. E-mail is preferred.
D. Site Visits: To be scheduled as needed (A description of City-owned facilities that may be available for this project will be provided to bona fide prospective Proposers and/or their subcontractors, subject to execution of a nondisclosure agreement. Contact the Authorized Agency Contact Person for details.)
6
E. Proposal Due Date, Time and Location:
Date:
May 25, 2004
Time:
3:00 PM – (NYC Time)
Location:
Proposals shall be submitted to Ms. Anne Cody, located at New York City Department of
Information Technology and Telecommunications, 75 Park Place, 9th Floor, New York, N.Y. 10007.
E-mailed or faxed proposals will not be accepted by DoITT.
Proposals received at this Location after the Proposal Due Date and Time are late and shall not be accepted by the agency, except as provided under the New York City’s Procurement Policy Board Rules.
The agency will consider requests made to the Authorized Agency Contact Person to extend the Proposal Due Date and Time prescribed above. However, unless the agency issues a written addendum to the RFP which extends the Proposal Due Date and Time for all Proposers, the Proposal Due Date and Time prescribed above shall remain in effect.
F. Project Start Date (Anticipated)
Date:
Fall 2004
7
SECTION II – SUMMARY OF THIS REQUEST FOR PROPOSALS A.
Purpose of this RFP
The New York City Department of Information Technology and Telecommunications (DoITT) is seeking a systems integrator (hereinafter referred to as the “Integrator”) qualified to design, construct, manage and maintain a citywide wireless network or networks (“Network(s)”) sufficiently robust to satisfy the varied and demanding requirements of New York City’s public safety agencies.
Although envisioned as a turn-key project, in which the Integrator will train qualified City employees in the skills and knowledge necessary to operate the Network(s) after acceptance, the Integrator will provide site management and Network(s) operations services to the extent necessary for the Network(s) to be adequately tested and taken over by City staff. At the option of the City, the Integrator may be required to continue to provide site management and operations services, in whole or in part, during the entire project.
Proposals submitted in response to this RFP must offer all four of the following Classes of applications (more fully described in Section III of this RFP): Class 1 – Wireless broadband public safety (high speed data and video) Class 2 – Wireless Automatic Vehicle Location (“AVL”) Class 3 – Wireless call boxes for emergency services Class 4 – Wireless traffic signal control
The scope of this project also includes provision of the communications and other equipment that would be used to access the Network(s).
The Network(s) will initially be used by public safety personnel in the City’s Police Department (“NYPD”), Fire Department (“FDNY”), Emergency Medical Services (“EMS”) and other agencies in the performance of critical first-responder, “routine” emergency and various other public safety functions, and by the City’s Department of Transportation (“DOT’) to centrally coordinate traffic signal control (i.e., Classes 1 through 4). The design of the Network(s) also must be capable of expansion to accommodate additional/increased functionalities.
8
B.
Anticipated Contract(s)
The City plans to award a contract to one or more different Proposers, for the provision of services for Phase I of this project. Phase I will be a Pilot Implementation program in which each selected Integrator will install its proposed network and applications, in one or more limited geographic area(s) in New York City and, using equipment provided by the Proposer, the City will evaluate each Proposer’s services, performance of the network, equipment and the functionality of all applications, and make a determination whether or not to proceed to Phase II of the project.
It is the City’s intention that a single Phase I contractor will proceed with Phase II of the project: Full Network(s) Implementation, including associated communications equipment to support the applications described in this RFP. The City reserves the right to purchase equipment separately. Phase II may also include preventive and remedial maintenance and, possibly, provision of site management services, implementation of increased capacity and provision of updated or additional applications material to the scope of this project. The City reserves the right to implement fewer than all four Classes in the Phase II implementation.
C. Anticipated Contract Term/Timetable
It is anticipated that the term of the contract awarded from this RFP will be five years (5 years), inclusive of the period of time needed after contract award to prepare to start and to conduct a 12-week Phase I pilot, and also inclusive of the time needed to start and finish the Phase II implementation. The contract term will also include two renewal options, of up to five (5) years each, upon the agreement of both parties. Any leasing/licensing provisions in the contract awarded from this RFP for the use of radio spectrum for the Network(s) shall run until the end of the initial contract term (even if the contract is modified in any way to discontinue some or all other services except for the licensing of the radio spectrum) and must include two renewals, of up to five (5) years each, at the sole option of the City. D.
The Network(s)
The City holds operating licenses in the 4.9 GHz spectrum, pursuant to the FCC’s order allocating fifty megahertz of spectrum in the 4.9 GHz band for fixed and mobile use to support public safety. (See In the Matter of The 4.9 GHz Band Transferred from Federal Government Use, WT Docket No. 00-32, Memorandum Opinion and Order and Third Report And Order, Adopted: April 23, 2003, Released: May 2, 2003). The City is 9
interested in exploring the suitability of this spectrum for all or part of the Network(s)’ user applications infrastructure. However, Proposers may offer other suitable spectrum, instead of, or in addition to, the 4.9 GHz frequency band.
The City will consider any reasonable solution regarding spectrum that complies with applicable security requirements, which are specified in this RFP. The City’s inclination, if using other than 4.9 GHz spectrum, or another City-licensed spectrum, is to use a third party’s licensed spectrum.
E. Definitions 1. Radio Access Node – The Radio Access Node will be used in this RFP to represent the device that handles Radio Frequency (RF) communications between the Network and the subscriber device. This term encompasses the following devices but is not limited to: radio base station, remote site, access point, remote receivers, transmitter sites, radio transmission sites and mobile transceivers as well as any subscriber devices acting as Radio Access Nodes. 2. Subscriber Devices – mobile radios, PDA’s, internal wireless modems, external wireless modems, wireless phones, push to talk devices, integrated voice/data/video devices, remote sensors, AVL devices, wireless call boxes, and traffic signal control base station equipment. 3. Operations Support Systems (OSS) – Includes but not limited to: scheduler, AAA platform and subscriber provisioning system. 4. Network Management System (NMS) – Includes network devices that provided alarm, control, management and maintenance. 5. Control Terminals – Includes terminals, computer workstations and subscriber devices used during normal operations to interact and communicate with the various subscriber devices operating on the network. This includes but is not limited to: dispatch consoles, DOT traffic control terminals and operator positions.
F.
Exclusion from Participation in Solicitation
Any contractor or consultant that advised the City in the development of this RFP shall not be allowed to participate, whether as contractor or sub-contractor, in response to this RFP, except as may be provided under New York City’s Procurement Policy Board Rules.
10
SECTION III – SCOPE OF WORK A. Obligations of the Integrator
The Integrator shall provide all the services and equipment required by this RFP for the Classes for which a contract is awarded -- including designing, constructing and maintaining a citywide wireless network(s) and applications (the Network(s)) -- in a manner that meets or exceeds the Network(s) Features, Functional Specifications and Requirements set forth in this RFP.
The Integrator shall be responsible for all phases of project management, coordination and scheduling necessary to ensure timely completion of the Network(s). The Integrator shall assume principal responsibility and liability for designing, recommending, procuring, and installing, testing and fully integrating the Network(s) and applications into live operating environments, including acquisition of off-the shelf products or integration of custom products, delivery of products, scheduling and coordination of all suppliers/subcontractors, interface with existing architecture, and providing training of the City’s employees and other end users, as defined in this RFP. At the City’s option, the Integrator may be directed to provide maintenance services upon warranty expiration and/or services/resources necessary for site management and/or to operate the Network(s). The Integrator warrants that the Network(s) and applications provided under the contract awarded from this RFP will meet the coverage, performance, inter-connection and other requirements of this RFP.
The City’s
approval or acceptance of any engineering or other plans or designs shall not serve to relieve the Integrator from fulfilling this warranty. B. Project Management and Quality Control
1. Management
The Integrator shall be solely responsible for the performance of all project management functions necessary to assure the successful performance of all phases of this project. Such functions will include, but will not be limited to, responsibility for project personnel management, project team organizational structure, controlling project activities and costs, project tracking including any applicable achievement milestones upon which progress payments should be claimed, and status reporting to DoITT and other authorized entities or personnel of the City. The tasks to be managed include, but are not limited to, Network(s) design, site engineering, site preparation, system engineering, equipment installation and testing, training, operations and maintenance.
11
2. Quality Control
The Integrator shall implement a Quality Assurance Plan, as offered in its proposal, to ensure that the Network(s) and applications are designed, manufactured and implemented in accordance with the requirements of this RFP. Quality Assurance must cover the Integrator’s project management, design and engineering, implementation, testing and operational quality controls.
3. Project Manager and Project Team
The Integrator shall establish a project management team consisting of an on-site Project Manager (team leader) and members of the Integrator’s and major subcontractor’s staff. The on-site Project Manager shall be an employee of the Integrator who shall be assigned to facilitate and oversee the complete project, and be the sole contact for DoITT for all items concerning the services under this project.
The Project Manager’s
responsibilities shall include, but not be limited to the inventory of all equipment, determination of site requirements, facilitate all site equipment installation, coordinate with DoITT personnel and City consultants on any areas that are in question during system installation and acceptance, scheduling, subcontracting, Acceptance Test Plan (ATP) administration, warranty service and, at DoITT’s option, site management, Network(s) operations and maintenance services. The Project Manager will produce and distribute monthly progress reports throughout the system installation and acceptance period.
The City retains the right of review and approval for the Project Manager and key management team members. Once assigned to this project for the duration(s) specified in the Proposal, the Integrator will not remove the Project Manager or key management team members without the approval of DoITT. The Integrator shall replace unplanned departures as soon as possible, which shall mean within one week, unless DoITT and the Integrator agree upon a different timeframe. DoITT reserves the right to direct the Integrator to promptly replace any Project Management team staff whose services DoITT deems unsatisfactory. Proposed replacement staff is subject to pre-approval by DoITT, and DoITT shall have the right to interview the candidate(s) at no cost, upon request. The proposed replacement must have skills and level of experience comparable or superior to the person being replaced. In addition, the Integrator shall not charge the City for the replacements’ learning curves, if any; and, in the event a Project Management team member is replaced in accordance with any of the foregoing provisions, then upon the request of DoITT the Integrator is required, at no additional cost to the City, to provide a reasonable overlap period (which shall be one week, unless DoITT and the Integrator agree upon a different time) when both the original and the replacement staff are working on the project together
12
The Project Manager must be on site during critical points of the installation of this system and shall perform the following tasks as a minimum to meet the requirements of this specification: •
Review all RFP specifications and familiarize himself/herself with the requirements.
•
Be the sole contact for DoITT, after the award of the contract.
•
Schedule the delivery, and keep DoITT informed at all times the delivery schedule of all equipment pertaining to this system.
•
Be responsible for coordinating any required engineering.
•
Perform all site visitations with DoITT representative as well as any installation subcontractors.
•
Coordinate all site preparation required for the successful installation of the Network(s) and applications.
•
Have full authority to perform all subcontracting functions required to complete this installation within the guidelines of this RFP.
•
Provide to DoITT all installation documentation, wiring diagrams and as-built documentation.
•
Be on site during the installation of the fixed equipment and provide any information and assistance as required by the installation personnel and/or DoITT.
•
Be available via phone or page during business hours, and return calls within four (4) hours.
•
Coordinate the entire optimization effort of this system until accepted by DoITT.
DoITT and its consultants will review the System Acceptance Test Plan (SATP). The Project Manager will also inform DoITT when this test is to be run to enable a DoITT representative to be present during the entire test.
The Project Manager will perform or coordinate with DoITT all training requirements as described within this specification. He/she will be available to DoITT until final acceptance of the System.
The Project manager shall aid DoITT in performing an audit of the System installation to ensure that the installation has been installed to the highest quality standards established for such items. He/she will have weekly meetings, during the System installation, to keep DoITT and/or its representatives up to date on the status of the installation.
13
C.
Implementation Plan/Timetable/Acceptance Plan/Maintenance Plan
The following deliverables shall be subject to the City’s acceptance:
1. Implementation Plan
The Integrator shall, within 30 days of contract award, submit to DoITT a detailed Implementation Plan consistent with the proposed implementation plan contained in its Proposal. This shall include a timetable defining delivery dates and installation schedules for all hardware and equipment. The Implementation Plan shall contain separate sections for Phases I and II of the project.
The Implementation Plan shall also include a timetable for the training of qualified City employees in the skills and knowledge required to operate the Network(s) and applications, and calling for the Integrator to provide all necessary site management services and to operate the Network(s) and applications during the Phase I Pilot, during the Phase II Full Implementation and, if directed by the City, until such functions are taken over in whole or in part during any phase of this project by City employees.
2. Project Timetable
The Integrator shall also, within 30 days of contract award, submit to DoITT a project timetable, consistent with the proposed project timetable contained in its Proposal, including the delivery schedule and installation schedule of all equipment from award of contracts to final acceptance. This project schedule must detail the installation and time line for each location. Depending upon the Integrator’s performance in the Phase I Pilot, it may or may not be directed by the City to proceed with Phase II of this project.
3. Pre-Trial Test Data and System Acceptance Test Procedures
The Integrator shall also, within 30 days of contract award, submit to DoITT and its designated consultant(s) pre-trial lab test results and a proposed System Acceptance Test Procedures document, consistent with that contained in its proposal, and covering Phases I and II of this project (including all stages thereof) individually, 14
as well as final acceptance of the System in Phase II. (“System” for this purpose shall mean the Network(s) and applications included in this project.)
The pre-trial lab test results must simulate the base line performance of the Integrator’s proposed equipment and system(s). This information will include the specifics of lab test configuration, test results, and any applicable related Federal Communications Commission (FCC) or other standards body filing(s). The Integrator will continue to make available to DoITT and or its consultants suitable lab test facilities for the purpose of validating any claimed equipment or system(s) performance or supplied test results as required by DoITT.
The Integrator shall provide a detailed System Acceptance Test Plan (SATP) detailing all tests that the Integrators will perform as part of the system acceptance. The SATP will include test of significant nature so as to demonstrate the overall capabilities of the system(s) in meeting the requirements of this RFP and their anticipated results The SATP shall include a tiered approach to the acceptance testing ranging from software functionality tests through to complete system integrated field tests.
The SATP submitted by the Integrator, at a minimum, shall include the following information: • • • • • • • •
A proposed equipment layout diagram. An outline of how each major component in the system will be demonstrated to DoITT to have performed its required function. (“Major” components are the Radio Access Nodes, Subscriber Devices, OSS, NMS and Control Terminals.) An outline of how the system performance will be demonstrated to DoITT after final installation has been completed demonstrating all operational functions. An outline of DoITT’s training requirements. The RF coverage Acceptance Test Plan as required by this RFP. Specifications relating to device and system latency for subscriber unit acquisition latency as well as system throughput latency under fully loaded network conditions. Specifications relating to devices and system throughput for subscriber devices and overall network throughput under normal fully loaded network conditions. A listing of the specification of each major RF component, platform and operational support system(s) (OSS) in the system. The Integrator will make on site measurements of these specifications. These measurements will be compared to the listed, published specifications.
The SATP shall also include a systems reliability test procedure. The procedure shall identify the tests to be conducted in order to give full assurances as to system reliability. The test should be conducted under full system and failure level modes. 15
4. Network(s) Maintenance and Repair Plan The Integrator shall also, within 30 days of contract award, submit to DoITT a proposed comprehensive support Network(s) Maintenance and Repair Plan to maintain the Citywide Wireless Network(s) and applications at optimum performance and to provide miscellaneous services to the Network(s) participants. This plan shall address the matters required by Section III.M.2 of this RFP and include written guidance for users and be applicable both to the warranty period(s) and, and the City’s option, maintenance period(s) following warranty period expiration.
D.
Network Features, Functional Specifications and Requirements 1.
Network(s) Features and Functional Specifications
Unless the Integrator proposed and the City accepted a different alternative, the Network(s) shall operate on spectrum independent of commercial wireless networks and utilize frequencies licensed directly to the City by the Federal Communications Commission (“FCC”); leased to the City by the Integrator; or leased to the City by a third-party as proposed and facilitated by the Integrator, in conformance with FCC rules. These frequencies and the operation of the Network(s) shall not interfere with, disrupt or reduce in any manner the capabilities, capacities or the operation of any existing city operated service(s), as well as any FCC licensed carriers. The Network(s) shall include sufficient capacity for all of the applications for which the City elects initially to use the Network(s), at the levels of performance required by this RFP, and will be scalable to enable both upgrades to current applications, defined as Classes1 through 4, and the addition of other applications, at the same or better levels of performance.
Continuous connectivity, at performance levels required by this RFP, must be available to vehicles in motion at high speed throughout the coverage area. To accomplish this, the system must provide seamless coverage to assure Network(s) resilience and a fully redundant design, including redundant access points.
Since the Network(s) will encompass both emergency and non-emergency uses, it must enable procedures for prioritizing transmissions.
16
The Network(s) should also provide for connectivity, via “selected access,” to the City’s existing networks (e.g.,MOSAIC, CityNet, and Siebel).
The Network(s)’s radio access nodes and backhaul facilities, either wired or wireless, shall include locations provided by the Integrator and/or City-owned buildings, traffic lights, light poles, City-owned or –franchised fiber, and where available the City’s own Dense Wavelength Division Multiplexing (“DWDM”) infrastructure. The Network(s) Features and Functional Specifications applicable to various Classes (and the applications for which it is most likely that the City will initially use the Network(s)), will include, but will not be limited to, the following: ¾ Traffic signal control to provide direct, on-line control of the traffic signals located throughout the City on a real-time basis. ¾ Simultaneous transmission of large database files, including building design, construction and floor plan information in AutoCAD format, mug shots, fingerprints and criminal records from local, City and federal databases. ¾ Simultaneous transmission of full motion (not less than 30 frames per second) streaming video on demand, on an ad-hoc basis from multiple fixed and mobile sites, throughout the Network(s) regardless of any other network activity. ¾ Continuous biological, chemical, nuclear and radiological monitoring at selected sites throughout the City. ¾ Telemetry of patient vital signs, electrocardiograms, and other biometrics to receiving hospitals. ¾ Wireless Emergency Service Call Boxes ¾ Provision of automatic vehicle location (AVL) via the Network(s) infrastructure. ¾ Continuous monitoring of water flow and purity. ¾ White boarding capability
17
¾ Voice (“VoIP”) capability, with guaranteed Quality of Service, to backup emergency radio, landline or cellular services. Following are additional Features and Functional Specifications relating to the features, technical performance, quality, and reliability of the Network(s):
(A)
Wide Area Communications Throughout the City
1. A multi-agency broadband data Network(s) accessible by Authorized City of New York personnel. 2. 99% in-street coverage throughout the City. While the overall objective is 99% in street coverage, the City is willing to entertain proposals providing for less than 99% in-street coverage, but no less than 95%. 3. Key City Facilities as outlined in this RFP (B)
Features and Functional Specifications
1. Fault-tolerant architecture 2. Seamless coverage between sites 3. The system shall be able to support full motion video (30 frames per second) or data transmission speeds in excess of 2 Mbps at anytime to any one user regardless of any other network activity. This requirement shall take into account that there will be times when many multiple uses, in close proximity, will require service. 4. Segmentation or redirection of traffic as needed to maintain throughput when traffic levels are high or when Radio Access Nodes are down and to maintain or increase coverage. 5. Over-the-air programming (OTAP) of changes to subscriber unit personality, new features and software upgrades 6. Secure encrypted communications with over the air re-keying (OTAR) capability 7. Expandability to increase capacity and coverage. 8. Dynamic bandwidth allocation and Variable QOS 9. Geo-location (e.g., AVL) using the Network(s) infrastructure/GPS 10. Interface with Public Switched Telephone Network(s) (PSTN) 11. Peer to Peer data, voice and video communication. 12. Ability to transmit slow scan video, (reduced rates i.e. 15 fps or less) when connected to the PSTN or at any other time. 13. Data broadcast capability. 14. Broadcast/simulcast capability within each Virtual Private LAN. 15. Use of existing City buildings, light poles, traffic lights and fiber infrastructure where possible. 16. Provision for growth to support additional users, capacity, and functions 17. Battery and/or solar power backup at each site and Radio Access Node sufficient to assure continuous operation at full power and functionality for a period of not less than twenty four (24) hours in the absence of utility power. 2.
Network Requirements
18
The Network(s) Requirements shall include, but will not be limited to, the following:
Requirements Specification a. In-Street Coverage
i. 99% (or minimum of 95% if specified in the contract resulting from this RFP) in car-installed mobile radio (subscriber device) coverage on roads. ii. 99% (or minimum of 95% if specified in the contract resulting from this RFP) handheld portable subscriber device in-street coverage in New York City and in certain other specified locations.
b. In-Building Coverage
i. Coverage capabilities for in-building coverage shall be as specified in the Proposal and subject to approval by the City.
c. IP Addressing
i. System must currently support implementation of V6 IP Addressing.
d. Reliability
i. In addition to meeting the manufactures specifications for reliability (MTBF), the overall network will be available to support applications and usage with predicted reliability of 99.9%. ii. Any system or network element used in the network backbone, which is used for the purpose of transporting applications and usage, shall be designed to have a predicted reliability of 99.999% as measured on a 365 rolling day basis.
e. Expandability
i. Ability to increase capacity at Radio Access Nodes as needed through allocation of bandwidth, segmentation of traffic, or other means. ii. Ability to increase coverage as needed through addition of Radio Access Nodes, modification of antenna patterns or other means.
f. Security
i. Conform with state-of-the-art security standards ii. Support of VPN tunneling iii. Support the use of all current and future U.S. encryption standards. iv. Provide access security. v. Provide physical site security. vi. FIPS2 Compliant or Equivalent
g. Interoperability
Support communication between and among any users across agencies within network(s). Dynamic reallocation of user groups.
h. Network(s) Management
Monitor and control system resources and status system(s) alarms, performance and operation.
i.
Employ protocols that most efficiently use existing bandwidth
Spectrum efficiency
19
j.
E.
Data throughput
The system shall be able to support full motion video (30 frames per second) or data transmission speeds in excess of 2 Mbps at anytime to any one user regardless of any other network activity This requirement shall take into account that there will be times that many multiple users, in close proximity, will require service. Any additional bandwidth capability may be accomplished through redirection of traffic through other Radio Access Nodes and/or subscriber devices acting as Radio Access Nodes as required or by other reliable means.
k. Broadcast Capability
There must be capability to broadcast/simulcast to all users through all access points and remote transceivers simultaneously. There must be capability for each user agency to broadcast to all of its users simultaneously wherever they are in the Network(s). The broadcast may be originated in a properly authorized mobile unit or at a fixed point. Each user agency must be able to determine on an ad hoc basis those users receiving a particular broadcast.
Additional Requirements and Specifications Applicable to Specific Classes Class 1– Wireless broadband public safety (high speed data and video):
The Integrator shall, as the City directs, provide hardware/subscriber related equipment (subscriber devices) to support the applications stated in this Class. Such subscriber devices shall include, but is not limited to, internal wireless data modems, external wireless data modems, wireless phones/push-to-talk devices, integrated voice/video/ data devices, etc. The City reserves the right to purchase equipment separately.
Class 2 – Wireless Automatic Vehicle Location (“AVL”):
The Integrator shall, if this Class is included in its contract award, as provided in the Proposal and accepted by the City, provide hardware/subscriber related equipment and software to support this Class of applications. Such equipment shall include, but is not limited to, GPS receivers, internal/external wireless data modems, vehicle control heads, integrated voice/video/ data devices, GIS mapping software, computers, etc. Depending upon the solution proposed by the Integrator, this could either be a “stand-alone” AVL solution or a solution integrated into a Citywide Computer-Aided Dispatch system. During Phase II of this project, the Network(s) may be required to provide AVL services for approximately 5,000 vehicle locations. This could subsequently be expanded to cover tens of thousands of additional vehicles on a City-wide basis. 20
Class 3 – Wireless Call Boxes for Emergency Services: The Integrator shall, if this Class is included in its contract award, provide the equipment and services necessary to implement this Class of applications. The wireless capabilities of the Network(s) shall enable the installation of equipment in public locations, such as City parks and many other locations that could be used by members of the public to summon emergency services when needed. The Network(s) should be designed to accommodate, by the time of final System acceptance in Phase II, up to one thousand (1,000) call boxes.
Such equipment
shall include, but is not limited to, call boxes, wireless data modems, environmentally safe enclosures, antenna systems, control and monitoring system(s), etc.
Following are additional requirements applicable to the Wireless Call Boxes:
Power • • •
Solar power is primary power source Battery must maintain charge up to 21 days with a minimum usage of 10 minutes per day Optional AC power source in combination with solar and back-up battery
Communications •
Must conform to the Network(s) proposed in Class 1 of the RFP.
Installation • • • •
Complete system/Unit must be of such size and weight for attachment to light-pole or stand-alone-pole Solar array placed on pole with visible display light on pole ADA compliant Braille raised lettering
Environmentally Secure Boxes The alarm call boxes must be vandal-resistant and theft-resistant. The case must have structural strength and durability sufficient to withstand environmental conditions. The alarm call boxes must have internal motion detectors able to alert the call box operations center of tilt or knockdown conditions, outer door open, alarm capable, unauthorized inner door entry, and other similar conditions such as • • • • • • •
Transceiver abnormalities Authorized and unauthorized inner door entry Open solar panel circuit Low battery Light burnout Handset circuit open Processor (bit) test 21
•
Cellular system malfunctions
Maintenance • • • •
Remote monitoring capability Provide maintenance and monitoring services to large network of street boxes Provide street-level repair services for boxes On-call maintenance response, repair time must be complete within 24 hours of notification
Class 4 – Wireless Traffic Signal Control:
The New York City Department of Transportation’s traffic management system – Traffic Signal Control System (VTCS) provides direct, on-line control of the traffic signals located throughout the City on a real-time basis. Under Phase II of this project, the City plans to provide communications to approximately 2,400 intersections spread throughout Brooklyn, Queens, and The Bronx. However the possibility of expanding or adding projects to cover up to 8,000 additional intersections throughout all five boroughs is also a possible City objective, following final System acceptance in Phase II. The Technical information and issues presented in Attachment C are intended to provide a basis for submission of a proposal to perform the initial work (up to 2,400 intersections), and the Integrator shall, if awarded a contract for this Class, provide the services and equipment required by the contract. The Integrator must provide hardware/subscriber related equipment and software to support this Class of applications.
Such equipment shall include, but is not limited to,
internal/external wireless data modems, antenna systems, control and monitoring system(s), etc. Installation Guidelines relative to this Class are set forth in Attachment D.
F.
Network(s) Design and Implementation
The Integrator shall be responsible for the design, implementation and testing of the Network(s) and applications. As described in this RFP, such responsibilities shall include, but shall not be limited to, Network(s) engineering, Network(s) installation, equipment selection, system integration, system testing, system maintenance, and other associated tasks necessary to ensure that the installed Network(s) is functional, complete, and meets or exceeds the Network(s) Features, Functional Specifications and Requirements set forth in this RFP. The Integrator shall be responsible for the quality and performance of the Network(s) it designs and implements, from the commencement of the project through the end of the warranty period. Any flaws or 22
omissions, as evidenced by poor Network(s) performance as determined solely by the City, will be the responsibility of the Integrator to correct at no additional cost to the City during the warranty period of the project and, for the applicable maintenance charges, during the remainder of the contract term. To the greatest extent practical, the Integrator shall implement a Network(s) design that makes efficient use of available bandwidth, provides for frequency re-use, and minimizes single points of failure.
1. Spectrum/Propagation Analyses/Interference Analyses
a. Spectrum availability
Unless a City licensed, i.e., 4.9 GHz or other potentially available (i.e., DTV) spectrum solution has been proposed and accepted by the City, the Integrator shall be responsible for leasing all necessary spectrum to the City, or, at the City’s discretion, arranging for a third-party to lease such spectrum to the City.
b. Propagation analyses
Radio Frequency Coverage
The Integrator shall be responsible for performance of propagation analysis of the proposed sites, identification of coverage parameters, and provision of a detailed description of the coverage analysis for the preliminary (Phase I) and final (Phase II) design. The Integrator shall be responsible for the provision of specific link budgets for each site and proposed device, and for the provision of coverage simulation plots. The coverage simulation shall provide forward and reverse link composite coverage plots (expressed in dBm), for the expected devices to be deployed.
Coverage plots must clearly represent any areas that specifically will not have radio frequency coverage or that would not operate at signal levels (uplink or downlink) that would be marginal or not at all as a result of subscriber unit, antenna or systems(s) operating and performance specifications presented as part of this RFP.
The information delivered shall be consistent with the data to be collected as part of the System Acceptance Test Procedures for a given site to allow for a comprehensive assessment by the Integrator and the DoITT of a 23
deployed sites performance versus its coverage objectives. All propagation plots shall be delivered consistent with the software and parameters identified by the Integrator for this RFP. It is anticipated that the modeling software will go through a tuning process as the system(s) are deployed and field activity takes place. As such, the Integrator shall be responsible for the routine update and documentation of the software model/parameters to be used for site analysis, as well as the dissemination of that data, with appropriate supporting documentation, to its engineering staff and the DoITT. Coverage Report
As part of the site acceptance process, a coverage report shall be developed and delivered to the DoITT for each site deployed in the system. At a minimum the coverage report shall include: site objectives, coverage plots, throughput plots, field acceptance test results, quantification of site performance versus objectives, and any site corrections required. If subsequent site changes/corrections are made, the report shall be updated and delivered to the DoITT. System Throughput
The Integrator shall be responsible for performance of a system throughput analysis of the proposed sites based on RF coverage and provision of a detailed description of the throughput analysis for the preliminary design. The Integrator shall be responsible for the provision of specific link budgets as they relate to throughput for each site and for the provision of expected user throughput plots at various network loading values (expressed as a peak burst rate and as an average throughput in kbps under each condition) ) per access point/sector and devices to be deployed. Throughput plots must clearly represent any areas that specifically will not provide for the required system(s) performance and throughput requirements or that would be marginal or not at all as a result of subscriber unit, antenna or systems(s) operating and performance specifications presented as part of this RFP. The information delivered shall be consistent with the data to be collected as part of the Acceptance Test Procedures
Some or all of these deliverables may be the same as provided in the Integrator’s Proposal and included in the contract awarded from this RFP.
24
c. Interference analyses
For Phase I and II, the Integrator shall be responsible for identifying and correcting the effects of interference on its equipment at each fixed radio site location and/or coverage area. The identification and correction process shall be documented in a comprehensive test plan and procedure resulting in a report for each fixed site in the system. Similarly, the Integrator shall provide a detailed engineering analysis of the potential interference of its proposed equipment to “co-channel” systems and/or “adjacent-channel” systems. Compatibility with any colocated wireless systems (including inter-modulation studies and receiver de-sensing, if applicable) shall be included in each site interference analysis.
Interference analysis must identify the impact on radio access node(s) and system(s) throughput and latency as a result of identified potential interference.
2. Network(s) Infrastructure and “Backhaul”
The Integrator shall provide a redundant wireless and wire line backhaul utilizing, to the fullest extent possible, existing City properties and facilities, including, but not limited to, City-owned buildings, light poles and traffic signals, as well as City-owned or leased copper, fiber and microwave facilities. The City will, where possible, make every effort to provide sufficient access and capacities to the Integrator for use of City-owned and operated facilities; however, the Integrator is responsible for providing infrastructure and backhaul to the extent it is not being provided by the City.
3. Quality of Service a. Network(s) Resiliency The Integrator shall provide and/or enable seamless coverage of sites; prioritization of Network(s) access by agency or user; logical or physical separation of traffic by authorized agencies; and the ability to operate all sites without utility power for a period of at least 24 hours.
The Network(s) must also be capable of continuing to operate, with all features specified in the Functional Requirements section of this RFP, if any radio access node fails. The failure of any critical sub-system must initiate software and/or contact closure alarm notification to a system administrator. The Network(s) must 25
provide the ability, at the discretion and direction of the City, for deployment of redundant subsystems for any subsystem that may result in a complete network failure or complete loss of any Class of service.
b. Network(s) Security The Integrator shall be responsible for development and implementation of a security plan, which shall ensure that only authorized and authenticated users will be able to connect to the Network(s), and that administrative and operational data used by agency users and systems will not be exposed to unauthorized viewers. All communications on the Network(s) will be subject, at minimum, to the security requirements of the New York City Department of Investigation, which are available upon request from the Authorized Agency Contact Person. It is understood that, as security standards and techniques evolve, the standards contained in these three Department of Investigation documents may become “outdated” before the Network(s) design is completed. Therefore, the City expects that all data security measures that are implemented will be current state-of-the-art as of the date of both Network(s) design and Network(s) construction and provide for the ability to be enhanced as required. The Network(s) must comply with FIPS2 Certification standards or equivalent.
G.
Network(s) Software/Hardware Acquisition/Development
Unless otherwise agreed by the City, the Integrator shall be responsible for acquisition of all Network(s)-related software and hardware proposed by the Integrator in response to this RFP. The City reserves the option to independently purchase any software and/or hardware. Where the City notifies the Integrator that it will independently purchase any software and/or hardware, the Integrator shall be responsible for providing the City with a delivery schedule and applicable specifications, and the Integrator shall not be relieved from any of its duties, responsibilities or obligations under the contract awarded from this RFP on account of the City exercising this right as specified.
1. Procurement Standards and Documentation The highest standard of care shall be imposed on the Integrator to secure Project products at the lowest available price to serve the best interests of the City. The Integrator’s principal duty shall be to obtain the “Best Value” for the City, which shall be entitled to all savings negotiated by the Integrator on its behalf. Best Value optimizes quality, cost, and efficiency based, whenever possible, upon objective and quantifiable analysis.
26
2. Responsibility for Coordination of Delivery with Third Party Suppliers The Integrator is responsible for the timely coordination of delivery, installation and completion of the project deliverables set forth in the RFP and its Proposal. Where the work requires delivery and/or installation of third party products or services to be furnished by or through the Integrator, the Integrator is responsible coordinating delivery and installation with third party suppliers, and shall be liable for any cost(s) of reinstating standard manufacturer’s warranty or acceptance periods which have lapsed due to untimely coordination by the Integrator. Where the City is responsible for delivery and/or installation of third party products or services, the Integrator is responsible for furnishing the delivery schedule to the City and the City is responsible for timely delivery pursuant to that schedule. 3. Responsibility for Payment/Risk of Loss with Delivery of Project Components Costs and risk of loss shall not pass to the City for project components whether tangible or intangible, until turned over to the City upon successful completion of the acceptance testing. If said materials or supplies do not meet the acceptance testing criteria for payment, the Integrator shall be responsible for securing satisfactory performance at its own expense.
4. Liability for Third Party Payments/Title Risk of Loss The Integrator shall be responsible for supplier delivery and risk loss until the acceptance criteria have been met entitling the Integrator to progress payments or to pass title and risk of loss to the City. The Integrator shall remain solely liable for payment to its third party suppliers.
5. Ownership of Copyright by the City
a.
Any reports, documents, data, photographs and/or other materials, including software,
produced pursuant to this Agreement (“Copyrightable Materials”), shall be considered “workmade-for-hire” within the meaning and purview of Section 101 of the United States Copyright Act, 17 U.S.C. §101, and the City shall be the copyright owner thereof and of all aspects, elements and components thereof in which copyright protection might subsist. To the extent that the Copyrightable Materials do not qualify as “work-made-for-hire,” the Integrator hereby irrevocably transfers, assigns and conveys exclusive copyright ownership in and to the Copyrightable Materials to the City, free and clear of any liens, claims, or other encumbrances. The Integrator shall retain no copyright or intellectual property interest in the Copyrightable Materials, and the Integrator shall use them for no other purpose without the prior written permission of the City. 27
b.
The Integrator acknowledges that the City may, in its sole discretion, register copyright in
the Copyrightable Materials with the U.S. Copyright Office or any other government agency authorized to grant copyright registrations. The Integrator shall cooperate in this effort, and agrees to provide any further documentation necessary to accomplish this.
6.
Software Escrow Account
(a)
To the extent that the contract resulting from this RFP includes software licensed to the
City (excluding “off-the-shelf” software), the Integrator represents (i) that it has entered into, and that it shall maintain in full force and effect a Source Code Escrow Agreement with an escrow agent (the “Escrow Agent”), which escrow agreement provides materially the same terms and conditions as follows, and (ii) that all source code and related documentation for the licensed software is under escrow deposit pursuant to said escrow agreement. The Integrator shall provide thirty (30) days prior written notice of a change of the Escrow Agent.
(i)
Source code must be held by the Escrow Agent in trust for the City;
(ii)
All updates must be escrowed as they are issued;
(iii)
The Escrow Agent shall verify deposit of the source code and all updates
and so notify the City;
(iv)
The City shall be permitted periodic testing of all source code held in
escrow; and
(v)
If the Integrator, its assignees or successor (a) becomes insolvent or ceases
to exist as a business entity; or (b) fails to perform its obligations under the contract resulting from this RFP and fails to cure said failure within thirty (30) days following receipt of written notification of said failure; the City shall have the right to so certify to the Escrow Agent and to direct the Escrow Agent to provide the City with a copy of the Source code and commentary for the installed release level of the product utilized by the City. All Source code materials granted under this clause shall be maintained subject to the confidentiality 28
provisions of the contract resulting from this RFP and shall be used solely for the internal business purposes of the City. Title to any source code released to the City remains the property of the Integrator.
(b)
The Integrator certifies that it has deposited and hereafter will maintain, a current copy of
all source code related to the software, including current commentary, with the Escrow Agent and agrees to adhere to obligations set forth in the agreement between the Escrow Agent and Integrator as required hereby. The Integrator shall provide to the City all information necessary for the City to comply with registration requirements, if any, of the Escrow Agent.
(c)
The escrow account provisions set forth in subdivisions (a) and (b) above shall apply with
equal force to any software licensed to the City (excluding “off-the-shelf” software) by a subcontractor.
H. Network(s) Software/Hardware Installation
Unless otherwise agreed by the City, the Integrator shall be responsible for installation of the proposed Network(s), System(s) and associated support equipment. This includes all tasks necessary to achieve the Network(s) Features, Functional Specifications and Requirements set forth in this RFP.
The Integrator shall be responsible for providing all of the radio and Network(s) control and monitoring equipment that will be necessary to enable full implementation of the features and functions set forth in this RFP. The Integrator shall be responsible for the storage of all such equipment until installation.
The Integrator shall be responsible for arranging all shipment of materials and equipment to the sites of the Work and shall consign such shipments to itself as Consignee at the project shipping address, freight fully prepaid. The Integrator shall be responsible for making agreements and settlement with carriers for their shipments.
The Integrator shall advise the City of New York in writing in advance of major shipments of materials and equipment and shall coordinate with the City of New York the arrival, unloading, and release of carrier’s
29
equipment. The Integrator shall make necessary provisions to warehouse all materials and equipment to be installed.
I.
Acceptance Testing
System/Site Acceptance by DoITT shall be based on the following conditions: •
The Integrator supplied to DoITT its suggested detailed System Acceptance Test Plan (SATP).
•
DoITT has officially accepted the format and conditions of the SATP.
•
All tests in the SATP have been successfully completed, documented by the Integrator in writing to the City.
•
Final site inspections by the Integrator’s Project Manager and DoITT representatives for all installed sites have been satisfactorily concluded. The Integrator will document these site inspections and a written report or punch list supplied to DoITT. The inspection will, at a minimum, include: o A physical inspection of all Integrator supplied and Integrator modified equipment. o A physical inspection of the power and grounding cables and junction boxes. o A physical inspection of all RF cabling and connections. o A physical inspection of all data, control, and audio cabling connections. o A physical inspection of all racks, cabinets, cable trays, and any other support hardware or devices.
•
All other contractual obligations between the Integrator and DoITT, including but not limited to the individual site coverage report, shall have been met and accepted by DoITT in writing.
System/Site Acceptance by DoITT, in Phase II, will also be based on the successful conclusion of coverage testing confirming that the installed Network(s) and applications meets the coverage requirements of this RFP and the individual site coverage goals defined in the site Coverage Report (See page 24 of this RFP).
Coverage Testing Functional Requirements:
Through the SATP, the Integrator shall perform site/system coverage testing employing, at a minimum, measurements of RF signal strengths, throughputs, latency, acquisition, and termination across various applications.
30
J. Network(s) Warranty, Maintenance and Repair
1. Warranty for Deliverables/Workmanship: The Integrator warrants and represents that full ownership, clear title free of all liens, and/or that the Integrator has obtained on behalf of the City (except as otherwise may be specified in the Proposal with regard to licensed frequency) perpetual license rights to use the products and deliverables associated with the Network(s) and applications specified in this RFP and the Proposal.
Integrator represents and warrants that the Copyrightable Materials, licensed software (excluding software licensed from third parties), and enhancements, as applicable: (a) are wholly original material not published elsewhere (except for material that is in the public domain); (b) do not violate any copyright law; (c) do not constitute defamation or invasion of the right of privacy or publicity, and (d) are not an infringement of any kind, of the rights of any third party. To the extent that the Copyrightable Materials incorporate any nonoriginal material, the Contractor represents and warrants that it has obtained all necessary permissions and clearances, in writing, for the use of such non-original material under this Agreement, copies of which shall be provided to the City upon execution of this Agreement. To the extent that the Integrator is procuring for the City’s benefit a license to use third-party software, the Contractor represents and warrants that it has obtained all necessary permissions and clearances, in writing, to provide such license, copies of which shall be provided to the City upon execution of this Agreement.
The Integrator warrants and represents that any required deliverables furnished by or through the Integrator, whether tangible or intangible, regardless of form, shall be standard new equipment or equipment warranted by the manufacturer as new, current model or most recent release of regular stock product with all parts regularly used with the type of equipment offered, with no attachment or part substituted or applied contrary to the manufacturer’s recommendations and standard commercial practice in the industry.
The Integrator warrants all equipment (including portable batteries) furnished by or through the Integrator against mechanical, electrical and workmanship defect for a period of one (1) year. In the event defects become evident within the warranty period, the Integrator shall furnish replacement parts and materials, procedures and labor as necessary to effect repairs at no cost to the City for the duration of the warranty period. The maintenance standards during the warranty period shall be the same as or better than those set forth below in paragraph 2.d of this Section III.J of this RFP. The equipment warranty period shall, unless a different time or 31
times is specified in the Proposal and agreed to by the City, for all products and deliverables furnished by or through the Integrator, commence on the date of system acceptance in Phase II.
2. Maintenance If directed by the City, the Integrator shall be required to maintain the Network(s) and applications furnished by or through the Integrator in the manner specified in this section of the RFP and its Proposal.
a. Service Personnel Each service technician used to maintain the Network(s) and applications or provide services shall be fully qualified by training and experience to perform the required services. In the event that DoITT is not satisfied with any service technician provided by the Integrator or its subcontractor for any reasonable cause, the Integrator agrees to replace said technician upon receipt of written request by DoITT.
b. Maintenance Response Obligations: How to Obtain Service The Integrator shall assign the number of dedicated on-site technician(s) (i.e., the City shall be the technician’s only account) at the sites and during the days and hours stated in the Integrator’s Proposal, or otherwise directed by DoITT at the specified rates. Such technician(s) shall provide maintenance service without regard to the nature (i.e., emergency or routine) of the service requested, by responding immediately to a service request and rendering continuous effort to remedy the failure or defect.
In addition, the Integrator shall provide 24-hour, toll-free maintenance answering call service available for the City’s benefit only and dedicated for use Citywide to request service, or to inquire about a pending service activity. Billing and payment for the toll-free number shall be the responsibility of the Integrator. This telephone number shall be in addition to any other telephone service that the Integrator may have for its other operations under this project.
Trouble calls to the toll-free number must be answered by staff (not automated,
i.e. voice mail) knowledgeable in the Integrator’s repair reporting/resolution procedures.
The Integrator shall also provide a separate, regular business line dedicated for use in the event of telephone problems with the toll-free number. This telephone number shall be in addition to any other telephone service that the Integrator may require for its operations 32
The Integrator’s service delivery procedures shall all include procedures for requesting service by e-mail. However received, the Integrator‘s procedures shall promptly confirm receipt of messages.
c. Change in Equipment
Any additions or deletions of equipment will be reflected and adjusted pro-rata on the next monthly billing, based on the rates provided by the contract resulting from this RFP.
d. Maintenance Standards for Equipment
The Integrator shall provide preventive and remedial maintenance for the equipment and operating system software so as to meet the standards set forth herein. The equipment will be maintained under these standards: (a) new manufacturer's parts or new parts of equal quality will be used; (b) the equipment will be maintained so as to be free from defects in material and workmanship, meet the manufacturers specifications therefore; (c) all maintenance work will be done by qualified personnel; (d) the Integrator will inspect and adjust the equipment periodically so as to meet these standards. The tasks for which the Integrator shall be fully responsible for performing also include, but are not limited to, the following: (e) continuous monitoring of appropriate parameters at transceiver sites and access points, including data throughput; site inspections; preventive and emergency maintenance; and ongoing technology refreshment of the Network(s) equipment and support structures.
The Integrator will furnish such materials and services as shall be necessary to correct any defects in the operation of the equipment to maintain the equipment in good working order in accordance with the specifications and functional, performance and reliability requirements for same. In the event that the equipment does not meet the requirements set forth in this RFP, the Integrator shall, at no additional charge, except for the maintenance fees provided by the contract, provide the necessary equipment, software or services required to attain the required levels or standards. If a unit of equipment fails three times in any thirty (30) day period for one (1) hour or more, or for two (2) business days, for each such failure not due to external causes, the City has the option to request replacement of such unit as soon as reasonably possible with comparable equipment or software of capacity and performance equal to or greater than the replaced unit. If the frequency and/or duration of a specific malfunction, defect, failure or nonconformity with specifications seriously impacts Customer's normal business operations, the City may request, and the Integrator shall arrange, at no charge to Customer, for a trained factory engineering specialist to visit the site in order to assist in resolving such malfunctions, to develop a plan of action to prevent their recurrence, and the Integrator shall cause the problem(s) to be remedied 33
with the highest priority.
3. Response Time
For both the warranty period(s) and, at the City’s option, during the maintenance period(s), the Integrator shall provide the remedial maintenance service within the time requirements specified in its Proposal and accepted by the City.
4. Downtime
For both the warranty period(s) and, at the City’s option, during the maintenance period(s), the Integrator shall be responsible for the liquidated damages/service credits as specified in the contract resulting from this RFP. 5. Reporting The Integrator will provide to the City, at no additional cost, monthly reports detailing, among other things, equipment and system(s) failures providing such relevant information so as to determine any chronic failure rate or sub-performing piece of equipment or platform according to the specifications provided by the Integrator’s proposal.
K. Industry Trends and Software Updates/Enhancements 1. Report on Industry Trends
At least quarterly, the Integrator shall at no additional charge be required to report to the City in writing any detailed changes in industry standards, newly emerging technologies and any other evolution of functions, features or technology that might have an impact on the state-of-the-art functionality of the Network(s) or that the Integrator feels would be beneficial to the Network(s). This would include, but not be limited to new equipment models or types, protocols/modulation techniques, algorithms, such as compression algorithms and additional frequency allocations.
34
2. Future Software Updates/Enhancements
The Integrator shall be required to install and upgrade, at no additional charge, any commercially released equipment firmware upgrades, software upgrades, versions and/or enhancements, (deployment), to the originally deployed software as they become generally available and as agreed to by the City. As part of such deployment, Integrator shall, at no additional cost to City, provide for the pre-deployment system(s) integration testing of any feature, software enhancement or change on a system of like capabilities to validate the new feature or service and the lack of impact to an operating systems. Each said deployment will be accompanied by a full method of procedure for the deployment and a “back-out” plan in the event that any service affecting problem arise as a result of the deployment. All such upgrades or changes will be at coordinated with the City and will be performed in such manner as to minimize the impact to the City’s operation(s). L.
Network(s) Training and Documentation
Training
The Integrator shall be fully responsible for developing training curricula and for providing training to Network(s) system administrators, operators and users in the areas of Network(s) systems management, operation, maintenance and the use of subscriber equipment. The Integrator also has the responsibility for providing train-the-trainer programs. During the Network(s) Engineering Design, the Integrator and the City shall mutually agree, in writing, on a Network(s) Training Plan and Schedule that reflects the timing and implementation schedule for all Network(s) training. The Network(s) Training Schedule must reflect and be consistent with the build-out schedule, conformance testing, user transition schedule, and all other training requirements. It will be the responsibility of the Integrator to complete and maintain the training schedule throughout the life of the Contract. The Integrator will also be responsible for “refresher” training in all areas as needed and as defined by the City during the contract period. Only qualified instructors shall conduct and/or present the training on any medium below. The Integrator’s responsibilities in providing Network(s) Training shall include, but not be limited to those set forth in this section of the RFP and in the Proposal.
Documentation The Integrator shall provide “as-built” documentation, including wiring and cable diagrams, system manuals, equipment manuals, security manuals and maintenance manuals. As part of this documentation, the Integrator will provide an electronic master copy of instructional Source Material and Technical Documentation, including but not limited to any equipment or manufacturing drawings, parts specifications, flow diagrams, software, and 35
firmware operating or programming specifics, in addition the Integrator will provide three (3) electronic and three (3) hard copies of all documentation to the DOITT Project Manager. The Integrator will correct promptly, by providing replacement or updates, any defects in documentation which Integrator becomes aware of and/or about which the City notifies Integrator that may result in an equipment failure, service loss or could result in a safety hazard.
The Integrator’s responsibilities in providing Network(s) Training and Documentation shall include, but not be limited to those set forth in this section of the RFP and in the Proposal.
1. Overview
Training must commence as soon as practical, but in no case later than that specified in the Acceptance Process. The Integrator is advised to take notice that completion of scheduled training is a condition precedent to the Acceptance Process. Training shall be ongoing during implementation and rollout of the Network(s). Training shall be recurring thereafter during the Contract term to accommodate technology and personnel changes that will occur. Training shall be provided through a combination of methods, e.g., distant learning sessions, trainthe-trainer programs, video tutorials, interactive CDs and/or on-line tutorials. Lesson plans and training must be submitted to the City in advance of all training sessions and/or development of training materials, e.g., videos, CDs, interactive tutorials, and may not be used without authorization by the City.
Nothing herein shall preclude the City, at its sole discretion, from conducting user training by substituting Network(s)
instructors
certified
through
the
Integrator
and,
as
applicable,
the
Equipment
Manufacturer/Developer. Curricula must be periodically updated to remain current with the Final Engineering Design, and as-built system upgrades or technology refreshments. Methods of delivering training must remain current with those being used by training and development professionals and specialists.
Following are the minimum training requirements that are required to be provided by the Integrator. The training hours stipulated represent the City’s best professional judgment of the training hours necessary to bring personnel to a level of competency consistent with their Network(s) responsibilities and job duties. It is recognized that the Integrator’s proposed technology and Network(s) design may impact training requirements. The Integrator warrants and represents the effectiveness of the resultant training to achieve a high level of employee competency consistent with their Network(s) responsibilities and job duties. The City reserves the right to modify both the number of students and/or training hours set forth, as required, with a corresponding adjustment at the per student or hourly training unit cost set forth in the Integrator’s Price Proposal, Itemized Unit Cost. 36
2. Network(s) Management Training for Network(s) Administrators
The Integrator shall provide on-site training using classroom demonstration and discussion techniques for 5 Network(s) Administrators per year. The Integrator will provide a minimum 80 hours of training that includes substantial hands-on involvement in using the Network(s) and proposed equipment. Said training will be with a sufficient number of sessions so that, upon completion, the Integrator will be able to certify (at an industry standard level) that each Network(s) Administrator has satisfactorily completed a course of training in the comprehension of wireless system management, Network(s) and backup and design, the performance of system diagnostics, and the operation of subscriber units.
This training must include components dealing with system orientation, system management, operation of all equipment, and all administrative procedures. The training schedule must integrate with the Network(s) design and implementation schedule, and the Integrator shall provide all training material and/or documentation in writing and on CD-ROM with such training material and/or documentation being customized to reflect the actual Network(s) configuration, equipment, and components installed for the Network(s). Such training material and/or documentation shall become the property of the City. The number of copies of the training material and/or documentation that the Integrator shall provide shall equal the number of class attendees at each session. Training shall include, but not be limited to the following: installation documentation; use of software; troubleshooting techniques; database development; principles of digital transmission; block diagram and circuit description for all units; trouble analysis and diagnosis to unit and board level; unit replacement procedure; operating and safety procedure; subscriber provisioning; security controls; and traffic continuity procedure.
3. Network(s) Operations Center Training
The Integrator shall provide on-site training and use classroom demonstration and discussion techniques to fifteen (15) Network(s) operators at each Network(s) Operations Center (“NOC”). The Integrator will provide a minimum of 40 hours of training that includes substantial hands-on involvement in using the Network(s) and Network(s) equipment. Said training will be of a sufficient number of session so that, upon completion, the Integrator will be able to certify (at an industry standard certification level) that each Network(s) Operator has satisfactorily completed a course of training in the comprehension of wireless system operations, Network(s) and backup design, the performance of system diagnostics, and the operation of subscriber units.
37
4. Network(s) Maintenance Training
The Integrator is responsible for performing all repairs necessary to keep all sites, facilities, and equipment associated with the Network(s) in good working order and tenable condition. In addition, the Integrator shall provide a minimum of 80 hours of on-site training that includes substantial hands-on involvement in maintenance of all Network(s) infrastructures and associated equipment for at least 10 Authorized Network(s) Entity personnel per year. Said training shall be of a sufficient number of sessions so that, upon completion, the Integrator will be able to certify (at an industry standard certification level) that each trainee has satisfactorily completed a course of training in the comprehension of the theory of operation and practical maintenance procedures for both the entire Network(s) infrastructure and all systems contained therein.
Maintenance
manuals shall be provided in hard and soft copy for all equipment and systems provided by the Integrator that shall become the property of the City. 5. End-User Training
The user training time each individual user requires may vary depending on the complexity of the equipment, equipment features, functionality of equipment, and the number of pieces of equipment such training requires. The Integrator shall be responsible for creating and providing teaching aids for Network(s) certified trainers, including, but not limited to, train-the-trainer students with video, interactive CD and/or on-line tutorials that detail specific knowledge skills and both proficiencies required for effective use and operation of the equipment listed below. Only qualified instructors shall conduct and/or present the training on such medium. The Integrator’s training program must integrate with the design and implementation build-out schedule. Such training materials or documentation shall become the property of the City.
Training shall be designed to teach the use of the Network(s) and proposed equipment and shall include adequate level of detail, be easily comprehensible, and be of adequate duration so that, upon completion, each user will be certified by the Integrator as having satisfactorily completed a course of training that demonstrates that the user can proficiently operate and use Network(s) equipment.
The number of copies of the
documentation that the Integrator shall provide shall equal the number of class attendees at each session.
The training curriculum must include a validation/test component administered by a certified trainer that shall be a requirement for satisfactory completion of training. The Integrator shall be responsible for certifying that the user is proficient in operating and has a working knowledge of how to use Network(s) equipment. Remediation through classroom or distance learning sessions and retesting must be included as a curriculum 38
component. Training shall be designed so that upon completion users will have a demonstrated working knowledge of how to use all mobile and fixed site equipment.
6. Train-The-Trainer As a way to integrate training with the overall operation of the Network(s) and to reduce overall recurring costs associated with training, the Integrator shall provide a train-the-trainer program for network and subscriber equipment including but not limited to radio access nodes, OSS, NMS, Control terminals, and all subscriber devices. Integrator shall provide training approved by the City for up to 100 students that correlates to the Network(s) implementation schedule. The Integrator shall document all training, both in writing and electronic form with such documentation being customized for certification of Network(s) employees as trainers. These documents will become the property of the City. The number of copies of the documentation that the Integrator shall provide shall equal the number of class attendees at each session. Train-the-trainer training shall be conducted on-site at each NOC or at another location as mutually agreed upon by the parties. The curriculum will employ classroom demonstration and discussion techniques. The Integrator shall provide training manuals in hard and soft copy and they shall become the property of the City. 7. Ongoing Training Updates
Over the life span of the Network(s) there will be changes in both technology and personnel. The Integrator shall propose provisions for on-going training to accommodate technology refreshment and staffing turnover.
M.
Site Management and Network(s) Operations Services
The Integrator shall, during the Phase I Pilot and, if directed by the City, during the Phase II Full Implementation provide site management and Network(s) operations services to the extent necessary for the Network(s) to be adequately tested and taken over by City staff. At the option of the City, the Integrator may be required to continue to provide the following site management and operations services, in whole or in part, during the entire project.
Such services shall be provided in accordance with the requirements contained in this section of the RFP and as set forth in the Proposal.
39
1. Unplanned & Emergency Network(s) Maintenance, Management and Repair The Integrator shall be responsible for maintaining all sites against damage. The Integrator shall notify the City immediately of the need for unplanned maintenance for any site, or any conditions that pose hazards to persons or property including the condition/deficiencies found and remediation efforts to be undertaken, and shall have the obligation to post warning and safety signs of such hazardous conditions appropriate to any use of the Site. If the damage was caused by climatic/environmental conditions or other factors beyond the parameters set forth in the Contract, projected costs of the Integrator to remediate the damage shall be specified in a Change Order.
2. Annual Maintenance Plan The Integrator shall be responsible for furnishing the City with an Annual Maintenance Plan for all sites that it is maintaining, whether a City site, an Integrator-provided site or a third party site. The initial Annual Maintenance Plan shall be furnished to the City with the Network(s) Maintenance and Repair Plan required by Section III.C.4 of this RFP) and updated to cover new or deleted sites annually thereafter on the anniversary date of the date of acceptance of this deliverable.
Under the Annual Maintenance Plan, the Integrator’s responsibilities will include the following:
Planned Maintenance Schedule
The Plan will include a schedule for physical inspection of each site being maintained by the Integrator, which schedule shall include a physical inspection by the Integrator of each site to occur at least once annually. The Integrator shall furnish a detailed planned maintenance schedule for each site including planned downtime for any reason. The Integrator is required to furnish to the City a written mitigation plan for planned maintenance that will render a site inoperable.
Physical Inspections
Physical inspection shall assess compliance of site with the site quality standards, including, at a minimum, then-current laws, codes, regulations and FCC RF emission standards.
40
Physical Inspection Report
The Integrator shall furnish to the City, in writing, within thirty (30) days of each site inspection, a detailed condition report, corrective actions taken, future remediation plans, if any, including a mitigation plan where a site will be inoperable, and associated schedule, and actual and projected remediation costs of the Integrator associated therewith.
Network(s) Downtime
The Integrator must take all reasonable efforts to minimize downtime due to planned or unplanned maintenance at any Site, time being of the essence.
3.
Annual Maintenance Report
The Integrator shall furnish the City in writing an extensive annual summary maintenance report, detailing, by site location: date of last maintenance inspection, condition/deficiencies found at each site, remediation efforts and costs which have been undertaken and completed by the Integrator, remediation efforts that are underway and incomplete, and remediation detailed on the site report which have not been undertaken. Such annual summary report shall be furnished within thirty (30) days of the anniversary date of final System acceptance.
4.
Maintenance and Repair Responsibility
The Integrator shall maintain all Network(s) sites in good working order according to industry standards and in conformance with the functional specifications required by this RFP, and in compliance with all environmental or other regulatory requirements. The Integrator shall be responsible for ensuring that all necessary repairs are done to keep all sites under its management, facilities and equipment associated with the Network(s) under its jurisdiction in good working order and tenable condition, including such maintenance, alterations, additions or improvements necessary to remain at all times and upon termination of the Contract in compliance with generally accepted industry engineering practices, all applicable FCC/FAA Rules, the NYS Uniform Fire Prevention and Building Code, all City of New York building and fire codes and all other federal, City and local laws, rules, codes and regulations.
This responsibility shall include, but not be limited to, structural
maintenance of towers, antennas, guy wires, base facilities, ground maintenance, and clear access to the sites. The Integrator is required to update at least the detailed schedule of planned preventive maintenance, costs and fixture, structure and equipment replacement itemization. 41
The Integrator’s obligation to maintain and repair any site, facility or equipment and any activities incidental thereto shall be subordinate to, shall not conflict with and shall minimize disruption to, the use and operation of the Network(s). In the event that a site or facilities requires maintenance or repair, whether planned or unplanned, the restoration of other co-location licensed uses shall be subordinate to the restoration of the interests of the Network(s), unless otherwise determined by the City in its sole discretion.
5. Support Services
The Integrator shall provide support and maintenance services for the Network(s) as set forth below.
Overall Network(s) performance shall be continuously monitored at the Primary Network(s) Operations Centers (P-NOC).
The NOC shall serve as the central service dispatch point for all service requests.
The Integrator shall staff the NOC for continuous operation – twenty-four hours per day, seven days per week, and three hundred and sixty-five days per year (24 x 7 x 365). NOCs shall be staffed with thoroughly trained and experienced technical personnel, able to effectively diagnose system alarms, and dispatch appropriate service personnel on a timely basis.
In the event that the NOC is disabled, full operations shall continue at the Alternate NOC (A-NOC). All references in this document to the P-NOC shall apply to the A-NOC.
42
SECTION IV: FORMAT AND CONTENT OF THE PROPOSAL Instructions: Proposers should provide all information required in the format below. The proposal should be typed/printed on both sides of 8 ½” X 11” paper. Pages should be consecutively numbered. The proposal will be evaluated on the basis of its content, not length.
The Technical Proposal and the Price Proposal should be prepared as described below and then placed in separate sealed packages. Proposers should submit one (1) original and seven (7) copies of the Technical Proposal in one sealed package and one (1) original and seven (7) copies of the Price Proposal in another separate sealed package. It is also highly recommended that one additional copy of the Technical Proposal should be submitted in the Technical Proposal sealed package on electronic medium in the form of a Microsoft WORD document and one copy of the Price Proposal should be submitted on electronic medium in the Price Proposal sealed package in the from of a Microsoft EXCEL spreadsheet. See Section IV.B, below, for a proposal submission checklist.
A.
Proposal Format
1. Proposal Cover Letter
The Proposal Cover Letter form (Attachment A) transmits the Proposer’s Proposal Package to the Agency (DoITT). It should be completed, signed and dated by an authorized representative of the Proposer and also include the name(s), position(s), and telephone number(s) of individual(s) to contact in the event of any questions the Evaluation Committee may have.
Append to Attachment A, a brief narrative overview of the Proposer’s technical solution. 2. Technical Proposal
The Technical Proposal is a clear and concise narrative that addresses the Proposer's overall project concept in the format prescribed below.
43
a) Proposed Approach
In a section labeled “Section A: Proposed Approach,” describe in detail how the Proposer will provide the work described in Section III of this RFP and demonstrate that the Proposer’s proposed approach will fulfill the City’s goals and objectives.
The Proposer should: 1) clearly indicate and identify which features and details of its proposal are common to all Classes of applications, and which are specific to each individual Class and 2) indicate how the common features might vary (e.g., in quantity) if fewer than all Classes are awarded.
The technical proposal should also be structured to clearly distinguish between the services and equipment that will be provided under the Phase I Pilot, under the Phase II Full Implementation and, as the City may direct, during the Phase II post-acceptance period.
Specifically address the following:
Network(s) Infrastructure
Provide an overview narrative that describes how the Proposer will provide and meet the Network(s) infrastructure requirements and implementation of both Phases I and II of the project. The Proposer should demonstrate its understanding of its specific responsibilities, as described in this RFP, for each part of the project of providing a Network(s) to the City. Identify any assumptions and constraints that affect the anticipated scope of work.
Responses for this item should include but not be limited to the following: ¾ Detail additional assets (i.e., spectrum, backhaul and other facilities) that the Proposer believes the City ought to acquire and those that the vendor would bring to support its Network(s). The City intends to make available to the Integrator various network facilities it owns or operates for the backhaul/interconnect portion of the Network(s) and expects these City facilities to be used by the Integrator in its Network(s) design. In the event that the Proposer is offering to provide for its own backhaul, the Proposer should provide detailed information regarding the impact of the overall system(s)’ capabilities when network usage peaks under full load.
44
¾ Clearly justify the proposed approach from a technical perspective if any backhaul/interconnection portion of the proposed network does not make use of City facilities.
All interface specifications and/or
requirements of the “interconnect” must be clearly defined. If the interconnection requires any additional equipment to be procured in order for the interconnection to occur, this information must be included in the Proposal.
¾ Specify the radio spectrum(s) on which the Proposer proposes to operate its Network(s). Unless a City licensed frequency is proposed (i.e., 4.9 GHz), the Proposer should describe the arrangements that it is proposing to make to lease or sell spectrum to the City. Any leasing/licensing provisions in the contract awarded from this RFP for the use of radio spectrum for the Network(s) shall run until the end of the initial contract term (even if the term is terminated ahead of schedule), and must include two renewals, of up to five (5) years each, at the sole option of the City. ¾ The City is interested in receiving proposals to provide Network(s) solution that could potentially utilize “spare” (up to 5 MHz) Digital Television (DTV) capacity of a UHF broadcaster. Any proposal to utilize “spare” Digital Television (DTV) capacity of a UHF broadcaster should describe of the amount of DTV capacity that would be required to implement the proposed solution and the Network(s) design features that would be required to prevent UHF broadcast interference to public safety operations as well as interference by the Network(s) to any co-channel and adjacent-channel broadcasters.
Functional and Technical Requirements Provide a narrative that describes how the Proposer will meet the functional and technical system requirements listed in this RFP.
The proposed functional and operational requirements response may include other
information the Proposer deems relevant in the context of the requirements set forth in this RFP. In the response, provide information relative to the operational requirements and the proposed Network(s) solution. For each system solution component, fully explain how the requirement is to be met.
Responses should include, but not be limited to, the following: ¾ A description of the proposed Network(s) functional capabilities. ¾ A diagram of the proposed Network(s) topology, identifying every remote receiver and antenna, each wired and each wireless backhaul site and any wired infrastructure employed in any part of the Network(s), 45
whether City-owned, City-leased, Integrator-owned or Integrator-leased. In the diagram, depict overlapping Radio Access Node coverage with signal strength bands as concentric circles centered on each Radio Access Node. Depict the in-street signal strengths in dBm. The types of antennas proposed for each site should be described, their dimensions provided, their radiation patterns depicted graphically. The reasons for the choice of a particular antenna at a particular site should be discussed in detail. Network(s) diagrams should be depicted by borough quadrant. Provide quadrant diagrams of the appropriate scale to depict street names and intersections. ¾ A description of all radio frequencies to be employed by all mobile devices and fixed equipment. If the proposal involves spread spectrum, specify all frequencies to be employed. Depict the channelization of each frequency or band. If the proposed spectrum is not licensed to the City, identify the licensee of each proposed frequency by corporate name and address and telephone number. Include the name of a contact officer and copy of the FCC license for each frequency. ¾ Provide details of the band plan to be implemented for each proposed spectrum. The band plan shall include, at a minimum: duplexing (FDD, TDD, etc.), channelization, control, and segmentation. For each band proposed, the Integrator shall provide a plan for the management and control of the spectrum. The Integrator shall demonstrate its current and past experience in the management and frequency coordination of spectrum including experience with the FCC and other spectrum licensees. For each band proposed, the Integrator shall demonstrate its familiarity with the FCC rules and regulations governing the use of the frequency including all necessary FCC filings required for the acquisition, subsequent use, and coordination of the spectrum
¾ Submit propagation studies, using the proposed licensed frequencies, and test measurements to confirm the validity of the propagation studies. The Integrator shall provide details of the simulation software used in the development of the coverage plots. Details shall include but not be limited to: vendor software model, specific propagation model (Okomura, Longley-Rice, etc.), terrain data source and resolution, landuse/clutter data source and resolution, building database data source and resolution (as applicable); appropriate model software parameter assumptions (power, receiver sensitivity, etc.). The integrator shall provide a detailed link budget for every proposed device in the network. The integrator shall be responsible for any propagation model “tuning” to take place as the deployment proceeds, including the update of the data sources available for the model. The Integrator shall identify a plan by which the modeling/simulation of the network is disseminated and controlled by the engineering team(s).
46
¾ Provide a detailed engineering interference analysis of the impact, potential for impact, of interference to or from its proposed equipment (radio access nodes and subscriber devices). The analysis shall include at a minimum the acceptable signal to noise ratios (SNR) of the proposed equipment as well as any frequency planning (or similar) required to meet the interference requirements of the system. The analysis shall include the system’s self-interference (co and adjacent channel) abilities and limitations. The analysis shall also include any “out of system” interference sources (“co-channel” systems and/or “adjacent-channel” systems) the Integrator is planning for, or currently exist, for each proposed band. Compatibility with any existing or anticipated co-located wireless systems (including inter-modulation studies and receiver desensing,) shall be included in each site interference analysis. The interference analysis shall be supported by propagation modeling and shall be specifically referenced to any coverage/throughput propagation study provided as part of this RFP.
¾ Describe the medium to be employed at each wired backhaul site. The maximum aggregated throughput at each individual backhaul site. The number of wired and wireless backhaul Radio Access Node required and identified by their street address, elevation, intersection and longitude and latitude. The carrier provisioning each individual wired and wireless backhaul site. The complete terms and conditions of all agreements between the responder and the carrier(s) provisioning each individual wired and wireless backhaul site. Detailed description of the manner in which site redundancy will be implemented at each individual wired and wireless backhaul site. The medium and frequencies to be employed by each individual wireless backhaul sites. ¾ Describe the Coverage specifications that the Proposer is offering to provide for the Network(s). The RFP provides that coverage is to be 99%, or as otherwise set forth in the contract resulting from this RFP. If it is practicable and cost-effective to implement 99% coverage, then that would be the City’s first preference. However, in addition to proposing 99% coverage, if 99% is practicable and cost-effective, the Proposer should also offer one or more other coverage levels, such as 97% coverage and 95% coverage. Since this is a public safety-related project, 95% is the minimum coverage that the City desires to consider. Differences in equipment and services for these different coverage levels should be indicated in the Technical Proposal, and prices corresponding to such different levels should be set forth in the Price Proposal. The Proposer should also indicate with detail the methodology under which it proposes that Coverage should be measured. Coverage requirements discussed with this RFP must include RF system fade margins for “area coverage” that will result in the defined percentage of proposed coverage.
47
¾ Identify and describe all required leased communications circuits needed to provide interconnection of all sites. The vendor shall provide all leased line specification information, including cost (however, cost should only be contained in the separate Price Proposal). The dimensioning of the leased lines will assume an N+1 redundancy. ¾ List, by type and number of units proposed, all proposed mobile and fixed radio devices (including handsets and antennas). Depict receiver specifications for each mobile and fixed radio frequency device. A hard copy of transmit spectrum analyses performed by the Proposer on a sample of every mobile and fixed radio frequency device. The following additional information for all mobile and fixed radio frequency: manufacturer; model number; date of manufacture; description; operating frequency or frequencies; modulation type; output power; maximum data throughput; dimensions; types of connectors/ interfaces ;and warranties. ¾ Describe the design architecture of the Subscriber Equipment to include modulation format, method of communicating voice and data traffic, method of providing secure transmissions, and the regulatory production status of the proposed equipment (e.g., FCC Certification, in current production, in development, etc.). All Subscriber Equipment/devices made available under this Contract shall be FCC Certified. ¾ Discuss in detail how data and physical security will be implemented at each radio access node, in each subscriber device, in the wired backbone, at the Network(s) operations centers and at any alternate Network(s) control centers or any fixed site. ¾ Fully describe all system recovery and redundancy procedures, services and equipment being offered.
¾ Provide a graphical and text description of the performance of all proposed radio frequency receiving devices, and the receiving components of transceiver devices, under various ambient noise conditions. The discussion should include receiving devices that employ spread spectrum techniques. The discussion should describe the types of interference that can degrade performance, the possible sources of such interference, and the probability of such interference occurring with each type of device at various points on the Network(s). The discussion should describe how much interference the proposed technology is expected to generate in the adjacent bands, both by the radio access nodes and by the subscriber devices. In the discussion, refer to radio access nodes and microwave backhaul and any other radio installation being employed for any purpose.
48
¾ Provide an analysis of expected throughput of each radio access node at various traffic loads. Include a description of how bandwidth may be dynamically allocated to individual subscriber devices, radio access nodes and other devices or paths in the Network(s). Also include a description of the contingency plan for when a radio access node is inoperable for various lengths of time. ¾ Comprehensively describe the Network(s) software solution including a description of each module, including its functions and capabilities, a comprehensive narrative and/or pictorial description including files and programs of the proposed packaged software should be presented. ¾ Provide detailed information regarding the operation and administrative requirements of any subsystem required for the administration of network security and user provisioning. ¾ Describe how IP addressing will be implemented and managed.. ¾ Describe how priority access will be implemented and managed
Estimated Hours of Work (including optional Post-Acceptance Site Management) ¾ Estimate the number of system programmers and application programmers required during implementation and supporting the system operations after installation. ¾ Estimate the number of hours and types of resources that will be required to be provided for all other work required by this RFP, including but not limited to operating the Network(s) and applications during Phase I and Phase II. ¾ Estimate the number of hours and types of resources that will be required, at the option of the City, to operate the Network(s) and applications, and to provide site managements services, during the Phase II Post-Acceptance Period. ¾ Describe the facilities from where programming and other goods and services will be provided.
Estimate of Required City Resources ¾ An estimate of the number and qualifications of City personnel that will be required to operate the 49
Network(s) during the progressive Phases of this project.
Implementation Plan •
The Proposal should include a detailed Implementation Plan. Include a timetable defining shipping and delivery dates, and schedules for the installation and testing of all hardware, software and equipment.
•
The Implementation Plan should detail the installation and time line for each location. As appropriate, the Implementation Plan should include time charts, project management charts, critical path charts, and other relevant information.
•
The Implementation Plan should be designed to accomplish this project in an efficient and costeffective manner.
The Implementation Plan should distinguish between Phases I and II of this project, including the services in Phase II before and after final System acceptance. The following considerations should be addressed with regard to Phase I:
1. Scope of Pilot Implementation
All services that the Integrator proposes to perform after contract award, until the actual commencement of the Phase I Pilot, should be specified.
The Technical Proposal must include an offer to participate in a Pilot Implementation of the Network(s), referred to as Phase I. Each Proposer is required to offer to conduct a 12week Pilot Implementation in the following two geographic region(s):
For Classes 1, 2 and 3: An area in downtown Manhattan (New York County) as depicted in Attachment E of this RFP. The four intersections depicted in the map are: Reade and Centre Streets (NE), Cedar and William Streets (SE), Liberty Street and western side of West Side Highway (SW), and western side of West Side Highway near the northwest corner of Washington Market Park (NW).
For Class 4: Twelve (12) intersections in Queens, N.Y. with traffic control signals, as designated by the City, from among those listed at the end of Attachment C of this RFP.
50
The Proposers should offer to install an operational System within 90 days of notification of selection. However, if they do not need this much time, or on the contrary if 90 days in an impractically short time, then the proposal should indicate the time the Proposer recommends for this step. The time should include the training of any City staff whose participation in the Pilot might be recommended; however, while the Proposers may propose such participation by City staff, their proposals should not be dependent upon such participation in order for their systems to be operated, since the City does not commit that it will be able to provide such staff.
In addition to the 12-week pilot test period and the geographic regions specified in this RFP, the Proposer may define a different geographic area in which it recommends that its network(s) should be deployed during Phase I, and for what length of time. However, Class 4 must be deployed and tested in the specified locations, as indicated above. The Proposer should demonstrate that such proposed area and duration would successfully demonstrate the Network(s)’ capabilities for implementing all applications.
The proposal should describe the methodology, software and hardware (including model numbers and quantities of user devices) that it proposes to use in the Pilot Implementation. If the Proposer desires, it can offer more than one recommended level of participation in the Phase I pilot, describing the features and relative technical merit of each level offered.
During the Phase I Pilot Implementation, the selected Proposers should expect that the City will make suggestions and recommendations for modifying various aspects of the Network(s) and applications. The Implementation Plan should provide resources and time adequate for accommodating such suggestions and recommendations.
2. Phase I Pilot: Classes of Applications
Class 1– Wireless broadband public safety (high speed data and video): The Proposer should define its method(s) and demonstrate for Phase I, such wireless applications as: database queries; simultaneous downloads of large, “static” data files to mobile devices throughout the City; simultaneous downloads of full-motion (30-frame-per-second) video to and from emergency scenes; continuous environmental monitoring and control; and continuous 51
biological, chemical, nuclear and radiological monitoring and control. Itemize the hardware/subscriber related equipment that will be required to support the applications stated in this Class, including, but not limited to, internal wireless data modems, external wireless data modems, wireless phones/push-to-talk devices, integrated voice/video/ data devices, etc.
Class 2 – Wireless Automatic Vehicle Location (“AVL”): Define the Proposer’s method(s) and, using the Network(s), demonstrate AVL for Phase I. Itemize the hardware/subscriber related equipment and software that will be required to support the applications stated in this Class, including, but not limited to, GPS receivers, internal/external wireless data modems, vehicle control heads, integrated voice/video/ data devices, GIS mapping software, computers, etc.
The City’s objective is to entertain the possibility of having centralized wireless tracking of the locations of all of the City’s police, fire and other emergency vehicles, enabling the operators of such vehicles to determine their own precise locations and the best routes to take to respond to requests for assistance. The City is willing to consider both “stand-alone” AVL solutions and those that can be integrated into a Citywide Computer Aided Dispatch system. Initially (although not necessarily in Phase I), the Network(s) should provide AVL services for approximately 5,000 vehicle locations. This could eventually be expanded to cover tens of thousands of vehicles, during Phase II (following final System acceptance) on a City-wide basis.
Class 3 – Wireless Call Boxes for Emergency Services: Define the Proposer’s method(s) and demonstrate for Phase I, the wireless call box capabilities. Itemize the hardware/subscriber related equipment and software that will be required to support the applications stated in this Class, including, but not limited to, call boxes, wireless data modems, environmentally safe enclosures, antenna systems, etc. (See Section III.E of this RFP for minimum call box specifications.)
Class 4 – Wireless Traffic Signal Control: Define the Proposer’s method(s) and demonstrate for Phase I, its capabilities of transmitting wireless VTCS information to/from the specified number of traffic control boxes to the DOT Traffic Management Center (TMC) located in Queens, N.Y. Itemize the hardware/subscriber related equipment and software that will be required to support the applications stated in this
52
Class, including, but not limited to, internal/external wireless data modems, antenna systems, etc. (See Attachment C of this RFP for additional information)
Software
The Proposal shall list all software that is being provided by the Proposer or is otherwise a necessary component of the System. For each item of software, the Proposer shall indicate if it is: a) commercially-available off-the shelf software; b) vendor-provided proprietary software (the Proposal should identify the owner and state that Proposer is authorized to provide such software to the City); c) customization of item a or item b software; d) software that is being custom designed by the Proposer for this project; or e) other (the Proposal should specify the nature of “other,” if any).
For each of categories a to e, above, the Proposal shall indicate the rights that the Proposer proposes that the City shall possess in such software. The City’s preference for custom or customized software is for the City to own such software; however, if it is being proposed that the Proposer or another party would own such software then the Proposer should indicate in the Cost Proposal whether the City is being offered any credit or price reduction in exchange for software ownership.
Whether the City owns or is licensed to use the software, the City needs to have the abilities to operate the software itself, to have a third-party (i.e., a successor vendor) operate the software for the City, and to modify the software either itself or by using the services of a qualified third-party. Therefore, for software that the City will not own, the Proposal should be specific regarding those rights as well; i.e., (1) will the City have perpetual license to use and modify the software, either (at the City’s option) itself or using the services of a third-party, and (2) will the Proposer provide the City with copies of source code and documentation (which is the City’s strong preference) or will source code and documentation be placed in escrow and made available for the City’s (third party’s) use?
Except for commercially-available software and software products that the contract resulting from this RFP states will be placed in escrow, such deliverables shall include, but not be limited to, the following:
a) Source code listing b) Documentation c) Code in executable form 53
d) Test results e) Job control streams f) Test data g) Number of copies of all User Manuals specified by the City.
Training ¾ Describe how all of the training services set forth in Section III of this RFP will be provided ¾ Specify the appropriate sessions per trainee, for all categories of training, how long each session lasts (e.g., 4 hr. to 8 hr. sessions) for each aspect of the system and quantity of documentation. ¾ Demonstrate the Proposer’s ability to employ sufficient staff to provide user-training classes on no more than fifteen (15) days notice.
Warranty •
Indicate the warranty periods that are applicable to every service and item of equipment/software included in the Proposal.
•
Indicate the level of service included in the warranties, such as response time and repair time.
•
Indicate what services the Proposer is offering to provide to coordinate the delivery of warranty services, to track problems from their initial report through resolution, and to report on its performance.
•
Indicate all service credits the Proposer is willing to agree to for failure to respond/repair within committed times, and for equipment and/or system downtime.
•
If enhanced levels of service are available during the warranty period(s) at the City’s option, then that should be indicated.
•
Indicate the point in time that the warranty period(s) will commence, and what measures the Proposer is capable of taking to cause all of the related warranty periods to commence and expire on the same date. Obviously, the City’s desire would be for warranty periods not to commence until the 54
City begins using the equipment/software in its operations, and for all warranty periods to end on the same date. •
Indicate the warranty period for subscriber equipment.
Maintenance •
Provide a comprehensive maintenance proposal for equipment/software maintenance. If different levels of service are available at the City’s option, indicate the Proposer’s recommended service levels as a base proposal (e.g., fixed equipment on-site service with a two hour response time, 24 hours a day, seven days a week), and also indicate the other service levels that are available at the City’s option.
•
Include offered response times for fixed equipment. Network(s) equipment at the following locations: • • •
Fixed equipment is defined as all
Network(s) Operations Centers (P-NOC and A-NOC), Network(s) Transmission Facilities, Microwave Sites, Fiber Optic Cable and other Network(s) transmission resources, and Sites, including traffic light installations and similar City facilities, Equipment Shelters, Enclosures, Base Stations and all associated equipment
Fixed equipment requires a prompt response time to correct service outages and impairments. The time by which restoration of fixed equipment is required depends on the criticality of the event. At a minimum the Proposer should offer the following response times: • • • • • • • •
Failure affecting entire Network(s)- response time: immediate Failure affecting more than one Radio Access Node - response time: 1 hour Failure of an Radio Access Node - Response time required: 2 hours Failure of one Subscriber Device: response time: 4 hours Failure of one non-redundant Operations Support Systems (OSS) platform or Control Terminal – response time : immediate Failure of one redundant Operations Support Systems (OSS) platform or Control Terminal – response time : 4 hours Failure of one non-redundant Network Management System (NMS) or control terminal platform – response time : immediate Failure of one redundant Network Management System (NMS) or control terminal platform – response time : 4 hours
•
Indicate all service credits the Proposer is willing to agree to for failure to respond/repair within committed times, and for equipment and/or system downtime.
•
Provide a list of all maintenance shops or resources within one (1) hour travel time within the borders of this system, which are capable of maintaining the Radio frequency equipment provided as part of this RFP. Include the name, address and phone number of the shops, the manager’s name and whether the shop is Proposer-owned or a franchised shop. 55
•
The City requires that maintenance terms and conditions shall be the same as those described for the first year of warranty and that the optional maintenance shall be broken down on a yearly basis for costs. Clearly identify items proposed to be covered under the contract awarded from this RFP.
The proposal for maintenance should also address the following: ¾ An employment plan of regionally based technicians capable of providing emergency on-site troubleshooting on no more than twenty-four hours notice. ¾ Information on where support services will be provided, how many personnel are located at each location. ¾ The identity of any sub-contractors that are proposed to be used for the provision of warranty and/or maintenance services.
Acceptance Plan ¾ Specific testing methodologies consistent with the proposed technology solution to accomplish the proposed Acceptance Process. The process must, at minimum, include field testing by either City personnel or an independent engineering consultant acceptable to the City, including precise signal measurement from vehicles and on-street. The tests must include multiple continuous drives, using at least three different vehicles, through the five boroughs, the routes to be determined by the City without prior notice to the vendor. A permanent continuous record of signal strengths, throughputs upstream and downstream, drop outs, lost connectivity and recovered connectivity must be made and maintained in each vehicle. A means of determining ambient (electronic and electrical) noise levels, degrees of interference, intermodulation and receiver de-sensing must also be made and maintained. This must also be done for every remote site used and access point accessed during the drive-tests.
Proposed System Acceptance Test Plan (SATP) Provide a detailed outline of the proposed SATP. The amount of detail in the proposed SATP is at the discretion of the Proposer. This part of the Proposal will be evaluated based on the City’s perception of the Proposer’s ability to supply a comprehensive, detailed, usable final SATP based upon the proposed SATP. The City anticipates the SATP will be based on Integrator internal, commercial, and/or military standards 56
and include provisions for new system tests, regression tests, and limited scope tests for enhancements to existing functionality and these provisions will include the full life-cycle of the project via functional, integration, recession, stress, and acceptance level tests. The City further anticipates the SATP will include aspects from a system design document; project scope supporting technical documentation including user training materials and manuals, internal Integrator test plans and results and will include necessary tracking mechanisms.
RF Coverage Acceptance Test Plan Describe the proposed methods of demonstrating coverage.
The response to this requirement will carry
significant weight in judging the overall technical excellence of a particular proposal. The City anticipates the RF Coverage Acceptance testing will take into account coverage, throughput, latency, acquisition, and termination based upon functional requirements. Pre-Trial Test Data ¾ Describe the live demonstration, if any, that the Proposer is willing to give to the RFP Evaluation Committee of its proposed network solution in connection with the proposal evaluation/rating process. Indicate what lab or field test results supporting the viability of its network solution and proof of concept it would be able to provide to the Evaluation Committee.
If the Proposer is willing to give its
presentation/demonstration to the Evaluation Committee in conjunction with an actual lab or field trial activity, then that should be indicated. Also, if the Proposer can make available to the Evaluation Committee and/or DoITT’s consultant(s) suitable lab test facilities for the purpose of validating any claimed equipment or system(s) performance or supplied results, then that should also be indicated. Note, however, that the City does not commit to fully exercise these opportunities, if offered, and that neither the City nor its agents or employees would be liable for any cost or damage to equipment from such activities, if any.
57
Other Information ¾ Include any other information the Proposer deems relevant in the context of the assumptions and requirements set forth in this RFP. However, responses should be both comprehensive and concise. (Brochures, advertisements and other literature or narratives that do not add substance to the response should not be included in the response.)
b) Qualifications and Experience
In a section labeled “Section B: Qualifications and Experience,” describe the relevant experience of the Proposer, each proposed subcontractor if any, and the proposed key staff in providing the work described in Section III of this RFP. Specifically address the following:
¾ A description of the company, its age, organization, number of full time employees, and product specialization. ¾ The Proposer's experience, programmatic, financial and managerial, with an emphasis on the provision of services similar or related to those set forth in this RFP. ¾ Attach a listing of at least three references for the Proposer for recent projects similar in scope, type and complexity to the project described in this RFP. Also provide three references for each subcontractor, if applicable. The City is particularly interested in any public safety entity that has utilized the proposed solution(s). The references should include a brief description of the project and the name and phone number of an individual whom the Evaluation Committee can contact at the referenced location. The individual identified should be of an appropriate level of responsibility. The Evaluation Committee may attempt to arrange (either directly or through the Proposer(s) a visit to one or more of the stated references, and, also, reserves the right to make arrangements to discuss or visit other installations that were not provided as references in response to this RFP. ¾ Attach for each key staff position a resume and/or description of the qualifications that will be required. In addition, provide a statement certifying that the proposed key staff will be available for the duration of the project. 58
¾ Attach a list of customers (preferably governmental organizations) who are currently utilizing the Proposer’s Network(s) solutions, and are willing to allow an on-site visit by members of the proposal evaluation committee. Answer the following for each reference:
When was the Network(s) installed at the specified location
What is the size of the organization and specific nature of the Network(s)?
Provide the name and telephone number of a person knowledgeable of the Network(s) that can be contacted as a reference.
c) Organizational Capability
In a section labeled “Section C: Organizational Capability,” demonstrate the Proposer’s organizational (i.e., technical, managerial and financial) capability to provide the work described in Section III of this RFP. Specifically address the following: ¾ Attach an organization outline or chart showing where, or an explanation of how, the proposed services will fit into the Proposer’s organization. ¾ Describe the Proposer’s ability to implement large systems integration projects in an expeditious manner. ¾ Include in this section a narrative that fully describes its ability to begin and complete the project in a timely manner. It is important that Proposers take into consideration the critical nature of the City’s need to expedite this project in terms of both commencement and achieving final acceptance and completion of the project. ¾ Attach audited financial statements for the past three (3) years or an explanation of why that is not available. ¾ Provide specific details regarding the Quality Assurance Plan the Integrator will provide, covering project management, design and engineering, implementation, testing and operational quality controls. ¾ Indicate whether or not the Proposer(s) has (have) been involved in litigation within the last five (5) years or has pending litigation arising out of contract performance.
Exclude routine interpleader action,
garnishments, and similar routine matters that do not reflect on contract performance.
Include all
information on contract terminations, defaults, debarments or performance disputes arising out of the 59
provision of related services. List all such contracts, reference numbers, contact persons and telephone numbers for the other parties, and a brief description of the facts surrounding each incident. ¾ Indicate whether or not the Proposer(s) or its principals have ever been involved in any kind of bankruptcy proceedings. Give a summary of all proceedings.
3.
Price Proposal
Proposers are encouraged to propose innovative payment structures. DoITT reserves the right to select any payment structure that is in the City’s best interest. Proposers should submit a Price Proposal that meets the standards of sub-sections 3.1 through 3.5, below.
Overview
a. Proposers should divide their Price Proposals into two sections. The first section should detail their entire price for the implementation of Phase I of the project. The second section should detail the entire price for the implementation of Phase II of the project, including Network(s) design, construction, and warranty.
The section for Phase II should also include rates for maintenance, site optional site
management, future customization and technical support. The Proposer should provide detailed pricing information for each Phase.
b. Proposal. Proposers should not include additional or repetitive technical proposal information within the Price Proposal. The Evaluation Committee will not consider such information for evaluation. Only project price information, performance outcome measures, and price guarantees should be included in the Price Proposal.
3.1 Price Proposal Detail The description of all cost items and prices should be presented in “spreadsheet-format” or columnar manner.
60
The price proposal should be “partitioned” into two identically structured sections: Phase I Pilot and a Phase II Full Implementation to cover the remainder of the City. In addition, the price proposal should include prices for optional maintenance, Network(s) operations, and site management services. The Price Proposal should include all of the prices for all of the services, equipment and software that the Proposer is offering to provide to completely implement this project in accordance with the requirements of this RFP. If the costs would be different depending upon whether the Coverage requirement is 99% or a different level (but not lower than 95%), then the Price Proposal should specify how. The Price Proposal should list the price of each and every item of required and optional equipment and software being offered by the Proposer.
If the Proposer is willing to offer to conduct/implement all or part of the Phase I Pilot Implementation at no cost to the City, then that should expressly be indicated in the Price Proposal. If the Proposer is willing to refund/rebate some or all of the costs of equipment provided to the City during the pilot if it should not be selected for the full implementation phase, then that should also be indicated in the Price Proposal.
For each of the major tasks and stages of work in the Implementation Plan, the Proposer should indicate: Services: • • • •
The total number of hours of work by job classification estimated to be necessary to perform the services required for that major task or stage of work; The unit prices (hourly rates) by job classification; The total fee by job classification for that major task or stage of work; The total fee for all services for that major task or stage of work;
Equipment/Software : • The numbers of each item of equipment/software being provided for that major task or stage of work; • The model number and unit price for each item of equipment/software; • The total fee for each item of equipment/software for that major task or stage of work; • The total fee for all equipment/software for that major stage of work.
For services/equipment/software covered by a warranty, indicate: • •
The applicable warranty period; Any additional fee for optional extended services, if any.
For services/equipment/software covered by maintenance, indicate, for each contract year up to three years following warranty expiration:
61
• •
The available levels of maintenance, if different options are offered; The fees for different levels of maintenance services, if any.
Any other fees not included in the foregoing. For example, include the cost for backhaul or other facilities if other than City facilities are being proposed. Totals for Required Services, Equipment, Software, Maintenance, and Other (if any). Any optional services/equipment/software being offered by the Proposer. Any financial incentives/disincentives. Any possible commercial use of the Network(s) infrastructure.
3.2
Method of Pricing:
The Price Proposal should indicate that method(s) of pricing being offered by the Proposer. This may include, without limitation: Time and Materials method, Time and Materials with a Cap method; Fixed Pricing, etc. The City desires to be offered the method(s) of pricing that are most appropriately designed to accomplishing this project, and the individual components of the project, in an efficient and cost-effective manner for the City, and the Proposer should explain why it is recommending the method(s) that it is offering to provide. The City’s preference is for fixed pricing or Time and Materials with a Cap, to the maximum extent appropriate. Except for maintenance services, estimated hours and unit prices of services should still be provided, for the City to assess the reasonableness of the offer.
3.3
Payment Plan/Performance Based Payment Structure
The Price Proposal should include a proposed Payment Plan. This should be directly linked to the Integrator’s success in performing the work and/or accomplishing the major milestones of this project, and should provide for the progress of payments to be slowed down if the Integrator falls behind schedule, and should further provide for the City to hold back a reasonably significant sum (such as 10% of the amount for services) until final acceptance. Payment for equipment/software can be linked to the City’s acceptance of those items, after installation and testing, without any hold-back.
62
3.4
Financial Incentives/Disincentives
Proposers are encouraged to propose measures, incentives and disincentives that they believe will most likely achieve DoITT’s goals and objectives in a cost-effective manner. Proposers may also propose more than one approach. While the Proposer’s proposed performance-based payment components may not be scored by the Evaluation Committee, they will be considered by DoITT in awarding the contract and structuring its payments to the contractor.
The City is willing to consider proposals regarding methods whereby, at the City’s option, its costs may be reduced if the Network(s) infrastructure (e.g., pole-tops, rooftops) is used, without adverse impact upon the City’s Network(s) and applications, for possible commercial applications. Any such suggestion should be proposed as an alternative pricing method, not as the Proposer’s only offer.
Proposers are encouraged to offer to certify that if more favorable pricing for any of their services or offered equipment takes effect, the City will receive the most favorable pricing being offered by the Proposer to any customer for the same or similar service/equipment.
3.5
Duration of Pricing Offer
The Price Proposal should state that the prices being offered shall remain in effect for a minimum of 180 days after the Proposal Due Date. Note: The City reserves the right to purchase, independently and/or as part of this contract, some or all of the hardware/subscriber related equipment and software that will be required to support the various Classes of application.
4.
Acknowledgment of Addenda
The Acknowledgment of Addenda form (Attachment B) serves as the Proposer’s acknowledgment of the receipt of addenda to this RFP which may have been issued by the Agency prior to the Proposal Due Date and Time, as set forth in Section I (E), above. The Proposer should complete this form as instructed on the form.
63
B.
Proposal Package Contents (“Checklist”)
The Proposal Package should contain the following materials. Proposers should utilize this section as a “checklist” to assure completeness prior to submitting their proposal to the Agency.
1. A sealed package labeled “Technical Proposal,” containing one (1) original set and seven (7) duplicate sets of the documents listed below in the following order: •
Proposal Cover Letter Form (Attachment A)
•
Technical Proposal •
Narrative (__)
•
Diagram of Proposed Network Topology (__)
•
Propagation Studies and Interference Analysis (__)
•
Proposed Radio Frequency Spectrum, Management and Band Plan (__)
•
Proposed Interconnection and Backhaul Plan (__)
•
Proposed Subscriber Devices (__)
•
Proposed System(s) Security (__)
•
Proposed System Redundancy and Survivability (__)
•
Proposed System(s) Capacities and Throughput(s) (__)
•
Proposed System(s) Software(s) (__)
•
Proposed Operation(s) and Administration System(s) (OSS) (__)
•
Proposed Network Addressing and Subscriber Management (__)
•
Proposed Implementation Plan/Timetable (__)
•
Proposed Training (__)
•
Warranty (__)
•
Maintenance (__)
•
Outline of Proposed System Acceptance Test Plan (__)
•
References for the Proposer and, if applicable, each Sub-Contractor (__)
•
Resumes and/or Description of Qualifications for Key Staff Positions (__)
•
Organizational Chart (__)
•
Audited Report for three years or Certified Financial Statements for three years or a statement as to why no report or statement is available (__)
•
Acknowledgment of Addenda Form (Attachment B) (__)
64
It is also highly recommended that one copy of the Technical Proposal should be submitted on electronic medium in the form of a Microsoft WORD document.
2. A sealed package labeled “Price Proposal,” containing one (1) original set and seven (7) duplicate sets of the Price Proposal.
It is also highly recommended that one copy of the Price Proposal should be submitted on electronic medium in the form of a Microsoft EXCEL spreadsheet.
3. Each package should have a label containing: •
The Proposer’s name and address, the Title and PIN # of this RFP and the name and telephone number of the Proposer’s Contact Person.
•
The name, title and address of the Authorized Agency Contact Person.
65
SECTION V - PROPOSAL EVALUATION AND CONTRACT AWARD PROCEDURES
A. Evaluation Procedures All proposals received on or before the Proposal Due Date and Time, at the location specified in this RFP, will be evaluated to determine whether they are responsive to the requirements set forth in this RFP. Proposals determined to be non-responsive will not be further considered.
All responsive proposals will be evaluated
and rated pursuant to the procedures and Evaluation Criteria set forth in this RFP.
The City intends to select one or more Proposers in two phases:
Phase I
The Department intends to award a contract to one or more Proposers for Phase I of the project (the Pilot Phase). The Pilot will serve as the basis to determine if it is in the best interests of the City to exercise its option to extend the Phase I contract to proceed with Phase II of the project.
The Proposer(s) selected for the Pilot Phase will be expected to deliver an operational system within 90 days of notification of selection, unless the selected Proposer(s), in their proposal(s) indicated 90 days is either longer than needed or impractically too short. If the Pilot involves any City participation in the operation of the Network(s) and applications for the Pilot to be conducted, then the selected Proposer(s) will also be accorded adequate time and opportunity to train City staff on the use of the System.
The Pilot will be conducted over a period of 12 consecutive weeks, unless a different time acceptable to the City was suggested in the selected Proposer’s(s’) proposals. The Pilot for Classes 1, 2 and 3 will, unless the selected Proposer(s), in their proposal(s), offered a better or equivalent site in Manhattan, be conducted in an area in downtown Manhattan (New York County) as depicted in Attachment E of this RFP. The Pilot for Class 4 will be conducted in twelve (12) intersections with traffic control signals in Queens, N.Y., designated by the City from among those listed at the end of Attachment C of this RFP.
During the Pilot, the selected Proposer(s) will have opportunity to make hardware and software modifications based on feedback from the City’s project manager, and Proposers should factor the possibility of such modifications into their price proposals.
66
Phase II
At the end of the Pilot, the performance of each participating system will be evaluated (See SectionV(D)). It is anticipated that the City will exercise its contractual option to extend the contract of one of the Phase I contractors to proceed to Phase II of this project, Full Implementation.
Evaluation Committee Procedures
Phase I
The Evaluation Committee will review and consider the written technical proposals, demonstrations and testing, oral interviews/presentations and price proposals, and may conduct discussions with and/or request the submission of best and final offers from one or more Proposers. A contract is expected to be awarded to one or more Proposers based on the Evaluation Criteria set forth in Section V.B of this RFP.
Phase II
The Evaluation Committee will evaluate the performance of the selected Proposer(s) in the Pilot and the City may conduct negotiations with and/or request the submission of best and final technical and price offers from one or more Proposers. The Department may then exercise its option to extend the contract of one Pilot participant to proceed with the Phase II of the project for one or more of the Classes of work, based upon the Pilot Phase Evaluation Criteria set forth in Section V.D of this RFP.
B. Proposal Evaluation Criteria • • •
Demonstrated quantity and quality of successful relevant experience. Demonstrated level of organizational capability. Quality of proposed approach.
67
40% 10% 50%
C. Basis for Contract Award
A contract will be awarded to the responsible Proposer(s) whose proposal(s) (is)(are) determined to be the most advantageous to the City, taking into consideration the price and such other factors or criteria which are set forth in this RFP. Contract award shall be subject to the timely completion of contract negotiations between the City and the selected Proposer(s).
D. Pilot Implementation Evaluation Criteria
During Phase I, the effectiveness of the implementation of the Network(s) by the selected Phase I Integrator(s) and the Network(s)’ ability to meet the requirements set forth in this RFP will be carefully examined. The pilot will serve as a basis to determine whether it is in the best interests of the City to proceed with phase II.
The Pilot will be evaluated based upon the requirements set forth in the RFP and will include, but not be limited to: • • • • • • • • • • • • • • • • • • • • • • • •
Adherence to schedule Efficient use of resources Fault-tolerance of architecture Reliability Seamless minimum 95% coverage Interoperability Full motion video and data transmission performance Overall system throughput Prioritization of traffic Expandability of system for capacity and coverage Security of the communications and physical infrastructure RF interference (received and generated) System and Network management and reporting Spectral efficiency Use of industry standards versus proprietary systems The overall robustness of system to withstand spikes in usage and locations Ease of adding additional users, capacity and functions Ability to meet proposed system capacity Operational ability in the event of utility power outages Overall system latency 24X7 operation efficacy ease of system deployment, maintenance and operation ability to interconnect with City’s wired infrastructure Cost
68
The pilot program participant whose expected services for this project, under its contract resulting from this RFP, is determined to be the most advantageous to the City, taking into consideration the price and the other factors set forth in this RFP, may be directed to proceed with Phase II of this project. If one or more of the Classes of this RFP are not being implemented in Phase II, the ratings for the omitted Class(es) will not be included in determining which contractor should proceed to implement Phase II.
69
SECTION VI - GENERAL INFORMATION TO PROPOSERS A. Complaints. The New York City Comptroller is charged with the audit of contracts in New York City. Any Proposer who believes that there has been unfairness, favoritism or impropriety in the proposal process should inform the Comptroller, Office of Contract Administration, 1 Centre Street, Room 835, New York, NY 10007; the telephone number is (212) 669-3000. In addition, the New York City Department of Investigation should be informed of such complaints at its Investigations Division, 80 Maiden Lane, New York, NY 10038; the telephone number is (212) 825-5959. B. Applicable Laws. This Request for Proposals and the resulting contract award(s), if any, unless otherwise stated, are subject to all applicable provisions of New York State Law, the New York City Administrative Code, New York City Charter and New York City Procurement Policy Board (PPB) Rules. A copy of the PPB Rules may be obtained by contacting the PPB at (212) 788-7820. C. General Contract Provisions. Contracts shall be subject to New York City’s general contract provisions, in substantially the form that they appear in “Appendix A—General Provisions Governing Contracts for Consultants, Professional and Technical Services” or, if the Agency utilizes other than the formal Appendix A, in substantially the form that they appear in the Agency’s general contract provisions. A copy of the applicable document is available through the Authorized Agency Contact Person. D. Contract Award. Contract award is subject to each of the following applicable conditions and any others that may apply: New York City Fair Share Criteria; New York City Mac Bride Principles Law; submission by the Proposer of the requisite New York City Department of Business Services/Division of Labor Services Employment Report and certification by that office; submission by the Proposer of the requisite VENDEX Questionnaires/Affidavits of No Change and review of the information contained therein by the New York City Department of Investigation; all other required oversight approvals; applicable provisions of federal, state and local laws and executive orders requiring affirmative action and equal employment opportunity; and Section 6-108.1 of the New York City Administrative Code relating to the Local Based Enterprises program and its implementation rules. E. Proposer Appeal Rights. Pursuant to New York City’s Procurement Policy Board Rules, Proposers have the right to appeal Agency nonresponsiveness determinations and Agency non-responsibility determinations and to protest an Agency’s determination regarding the solicitation or award of a contract. F. Multi-Year Contracts. Multi-year contracts are subject to modification or cancellation if adequate funds are not appropriated to the Agency to support continuation of performance in any City fiscal year succeeding the first fiscal year and/or if the contractor’s performance is not satisfactory. The Agency will notify the contractor as soon as is practicable that the funds are, or are not, available for the continuation of the multi-year contract for each succeeding City fiscal year. In the event of cancellation, the contractor will be reimbursed for those costs, if any, which are so provided for in the contract. G. Prompt Payment Policy. Pursuant to the New York City’s Procurement Policy Board Rules, it is the policy of the City to process contract payments efficiently and expeditiously. H. Prices Irrevocable. Prices proposed by the Proposer shall be irrevocable until contract award, unless the proposal is withdrawn. Proposals may only be withdrawn by submitting a written request to the Agency prior to contract award but after the expiration of 180 days after the opening of proposals. This shall not limit the discretion of the Agency to request Proposers to revise proposed prices through the submission of best and final offers and/or the conduct of negotiations. I. Confidential, Proprietary Information or Trade Secrets. Proposers should give specific attention to the identification of those portions of their proposals that they deem to be confidential, proprietary information or trade secrets and provide any justification of why such materials, upon request, should not be disclosed by the City. Such information must be easily separable from the non-confidential sections of the proposal. All information not so identified may be disclosed by the City. J. RFP Postponement/Cancellation. The Agency reserves the right to postpone or cancel this RFP, in whole or in part, and to reject all proposals. K. Proposer Costs. Proposers will not be reimbursed for any costs incurred to prepare proposals. L. Charter Section 312(a) Certification. The Agency has determined that the contract(s) to be awarded through this Request for Proposals will not directly result in the displacement of any New York City employee.
Jean Blanc
March 26, 2004
(Agency Chief Contracting Officer)
Date
70
ATTACHMENT A PROPOSAL COVER LETTER RFP TITLE: CITYWIDE MOBILE WIRELESS NETWORK PIN: 85804CSP0009
[Insert text transmitting the Proposer’s technical and cost proposals to the City] Proposer: Name:
_____________________________________________________________________________
Address:
______________________________________________________________________________ ______________________________________________________________________________
Tax Identification #:
________________________________
Proposer’s Contact Person: Name:
______________________________________________________________________________
Title:
______________________________________________________________________________
Telephone #:
_________________________________
Proposer’s Authorized Representative: Name:
____________________________________________________________________________
Title:
____________________________________________________________________________
Signature:
____________________________________________________________________________
Date:
___________________________________
71
Page 72 of 95 ATTACHMENT B ACKNOWLEDGEMENT OF ADDENDA FORM RFP TITLE: CITYWIDE MOBILE WIRELESS RADIO NETWORK___________ PIN: 85804CSP0009
Instructions: The Proposer is to complete Part I or Part II of this form, whichever is applicable, and sign and date this form. This form serves as the Proposer’s acknowledgment of the receipt of Addenda to this Request for Proposals (RFP) which may have been issued by the Contracting agency prior to the Proposal Due Date and Time. __Part I Listed below are the dates for issue of each Addendum received in connection with this RFP. Addendum # 1, dated_________________________________________________________ Addendum # 2, dated_________________________________________________________ Addendum # 3, dated_________________________________________________________ Addendum # 4, dated_________________________________________________________ Addendum # 5, dated_________________________________________________________ Addendum # 6, dated__________________________________________________________ Addendum # 7, dated__________________________________________________________ Addendum # 8, dated___________________________________________________________ Addendum # 9, dated___________________________________________________________ Addendum # 10, dated__________________________________________________________
__Part II
No Addendum was received in connection with this RFP
Page 73 of 95
Proposer Name: Proposer’s Authorized Representative: Name___________________________________________________ Title____________________________________________________ Signature________________________________________________ Date____________________________________________________
Page 74 of 95
ATTACHMENT C
Subject:
Requirements Controllers.
Section A:
Background
For
Wireless
Communications
To
The
Traffic
New York City Department of Transportation (NYCDOT) is responsible for control of more than 10,000 signalized intersections throughout Brooklyn, The Bronx, Queens, Staten Island, and Manhattan. New York City is in the process of expanding and upgrading their traffic management system with intelligent controllers at each intersection. A central system, VTCS, monitors and manages the operation of the field devices. The system will use the national standards for communications with traffic control devices, National Transportation Communications for ITS (Intelligent Transportation Systems) Protocol (NTCIP), modified to meet the specific needs of a wireless environment. The following sections describe the specific needs and assumptions for the communications infrastructure to support the traffic control application.
Section B:
IP Network
Section B.01
Fixed IP address
The wireless network must be an Internet Protocol (IP) transparent network. It is assumed that the network will transport IP packets to designated IP addresses. IP addresses of the field devices will be constructed as follows: XX.XX.AA.AA where all of the AA.AA address codes are reserved for intersection addresses. Each cabinet includes an internal diode encoded 16-bit cabinet address that will be used to form the low order 2 bytes of the IP address (Ipv4). The high order 2 bytes are configured at firmware loading time or loaded using a USB memory device by a technician in the field. The IP addresses of the intersections will be known and configured into the central database. The wireless network must support fixed IP addressing using this scheme. The XX.XX may be specified later as part of an overall network design.
Section B.02
DCHP Support
It is also possible for the traffic controllers to support DHCP where the cabinet ID will be of the form NYCDOTAAAA where AAAA is the Hex string (0-F) for the 16-bit cabinet address. Such DHCP support is not currently required. Use of the controller’s MAC address is not desired as this would require more complex coordination between the field maintenance contractor and the central computer operators. Each controller unit has an internal MAC address which is embedded in the Ethernet adapter.
Page 75 of 95
Section C:
Protocol
Communications to the traffic controller will conform to the National Transportation for ITS Communications Protocol (NTCIP – www.NTCIP.org) over an IP network. The communications will be connectionless using UDP/IP. The system will also support TCP/IP. At the application level, VTCS will use SNMP, STMP and SFMP (reference to the NTCIP standards 1103, 2301) protocols for all exchanges with the traffic controller. The traffic controller has a complex MIB (Management Information Base) and supports block data upload and download operations using special block objects (reference standards NTCIP 1201 and 1202V2).
Section D:
Environmental considerations
Field modems/transceivers/routers etc. provided must operate properly in the ambient conditions of New York City. The normal operating range for traffic control equipment is specified to be –34 C to +74 C. There is no heating or active cooling in the traffic control cabinet. All equipment is expected to run reliably without seasonal calibration or parameter changes.
Section E:
Interface and Power Requirements
The traffic controller includes an Ethernet port on the front of the unit with a typical RJ45 jack. This port is 10BaseT. The communications network is required to interface to the controller using this port. Where lightning or surge protection is required, such protection is to be provided by the communications equipment provider. Power is available within the traffic control cabinet through a typical NEMA 5-15R power receptacle without ground fault interruption.
Section F:
Cables
The City will provide the necessary cables to connect to the traffic controller where such cables are Ethernet (RJ45) and/or traditional power cords. Any special connectors and cables – including RF cables shall be provided by the communications equipment provider.
Section G:
Operation
The following sections are intended to provide an understanding of how the traffic control application works from both the central system perspective and the local traffic controller. Note that there is a traffic controller located at each intersection. This traffic controller manages the traffic signal (R-Y-G, WALK) indications and monitors traffic conditions with vehicle detection subsystems. Vehicle detection is typically road loops which monitor the presence of vehicles in the roadway, but may include more sophisticated technologies such as Video Imaging equipment, microwave detection equipment, and sonic or audio detection equipment. The vehicle detection equipment is typically connected directly to the traffic controller, but for certain locations, the detection equipment may be connected directly to the RF network.
Page 76 of 95 The central traffic management system performs the following general functions: ¾ Monitors the status of the local intersections looking for failures and anomalies ¾ Collects and monitors traffic status based on vehicle detection inputs ¾ Directs the local intersections regarding which timing plan or traffic management parameters should be used to control the traffic signal indications ¾ Synchronizes the clocks at the local intersections to ensure proper progression and coordination between intersections ¾ Manages the local database at the intersections by downloading the controller’s operational parameters including timing patterns, schedules, and hardware configuration information ¾ Logs and records major state changes such as pre-emption, plan changes, and operator intervention. The following sections describe the specific actions that require communications with the local traffic controllers.
Section G.01
Startup When intersections are classified as failed (i.e. no response) or during initial installation before the controller is available, the central system will “poll” them for general status looking for their recovery. This is typically a short SNMP GET message (28 bytes plus UDP/IP, and Ethernet overhead) with a response of a few bytes (4-8) plus the overhead of an SNMP, UDP/IP and Ethernet response. The polling rate has yet to be determined, but it is configurable; the background or failure polling rate is expected to be on the order of once per minute to once every 5 minutes for a non-metered1 network. For a metered network, this may be longer to reduce the operating cost and network loading. The polling rate is likely to be adaptive; initial failures will incur a more rapid polling rate (once per minute) and longer outages will see the rate stretch out to once per hour. Long polling rates require operator intervention at the central TMC to support maintenance activities. In summary, intersections that are not on-line will be polled by the central system at some periodicity.
Section G.02
Normal operation Traffic controllers that are on-line and under active computer control will exhibit the following operating scenarios.
1-
Download Once the central system determines that the controller has recovered from an outage or begins to respond to the polling request for status, it will check its local database. If the local database has been corrupted, is not correct for the location, needs to be updated, or if there is a local request for a download, the central system will download the controller’s database and establish all of its operating parameters. This database is on 1
Metered networks imply there is a cost associated with the amount of information exchanged with the field device. Non-metered networks imply that there is no incremental cost for the amount of data exchanged with the field device.
Page 77 of 95 the order of 48K Bytes (payload) and will be downloaded as quickly as possible by the central system. This download must be completed within 30 seconds using intermediate acknowledgements. The rate at which this can be completed depends on the controller’s ability to accept the data; current measurements indicate that no more than 30 seconds are required to download the data when large blocks are used. Blocks are acknowledged and there are a number of messages sent back to the central station during this process. Such downloads are relatively infrequent. These are on the order of one every few minutes for the entire population of controllers (10,000). This is generally done in close coordination with field maintenance operations. The reason for the need to complete them quickly (30 seconds) is that the traffic controller is in the flashing condition with a technician present during these updates. It is critical that the new database be loaded and that normal operation resume as quickly as possible. The controller and not the communications network should be the limiting factor. It is also possible for the system to establish and download new timing plans and schedules to the controllers whenever the City determines that new plans are needed. In such a circumstance, hundreds of controllers may need to have their database downloaded at the same time. Such an event will take place concurrently to all controllers and it is important that such a download event be completed within a few (15) minutes. Note that such download operations will be concurrent with normal polling (Section Section G.01), exception based reporting (as discussed below) , and periodic uploading of data as noted in Section 2 - .
2-
Status reporting Once the intersections have been configured and their database has been downloaded, they are programmed to report periodically as their status changes. The controllers may be requested to report different levels of status depending upon the needs of the central system. Each type of status is listed below. Note that intersections may report some or all of the status listed below. The level of detail is configurable on an intersection-byintersection basis. All active intersections will be reporting status under normal operation.
(i)
Periodic The traffic controllers can be programmed to transmit certain detector information (e.g. volume, speed, occupancy) on a periodic basis. This transmission uses SNMP (or SFMP)2 Traps as programmed at the traffic controller using the NTCIP standard objects (reference NTCIP standards 1103, 1201, 1202). Such information consists of a payload of approximately 32-64 bytes plus the overhead associated with SNMP and UDP/IP communications. This type of information is reported approximately once per minute and may be requested from virtually all of the traffic controllers on the network. However, it is likely that this data will only be required from 10-20% of the traffic controllers throughout the network.
2
Note that both SNMP and SFMP traps may be used; refer to NTCIP 1103. Herein after, where SNMP traps are referenced, the system will nominally use SNMP or may use SFMP Trap to reduce the size of the message overhead.
Page 78 of 95 The times at which this data will be transferred may vary on a controller-by-controller basis. Because of time synchronization, they may all attempt to report their data at the same time. The network must be able to support the simultaneous transmission of such data from all intersections at a rate of at least once per minute.
(ii)
Adaptive Control One mechanism which will be used for management of traffic timing plans is called adaptive control. For this mechanism, detector data (see Section (i)) will be sent to the central system on a once per cycle basis (every 50-120+ seconds), and a new split pattern (distribution of green times to each phase) will then be transmitted to the intersection for use while running the next cycle. This split pattern has a payload of approximately 24 bytes plus the overhead of SNMP, UDP/IP, and Ethernet communications. This type of operation will take place to a limited number of intersections at any given time. For the sake of network loading, one can assume that this will not exceed 20% of the available intersections. Such operations may be staggered or simultaneous depending upon the timing plan (sequential or simultaneous). Such data transfers must get through to the central system within 2 seconds and the data must get back to the traffic controllers within 2 seconds regardless of network routing and loading.
(iii)
Screen-line detectors
At certain locations throughout the city, there are “screen line” detectors that allow the City to capture the vehicle length, occupancy, and speed from a pair of loops installed in the roadway or using video or microwave detection devices. For each vehicle, a message is transmitted to the central system identifying the parameters for that vehicle as it leaves the detection zone. Such messages are relatively short (16-64 bytes of payload depending on the number of detection zones) plus SNMP, UDP/IP, and Ethernet overhead and are reported as the vehicles leave the down-stream detection zone. They will be reported for each vehicle. For the purpose of estimation, this networking loading will occur at up to 200 locations located throughout the City. The rate at which messages occur is dependent upon the traffic conditions, but a rate of 9001100 vehicles per hour per lane is a worst case and each location is expected to support 3-5 lanes of traffic. Such data must be reliably delivered within 1-2 seconds of the event; events may occur at rates up to 1100 per hour for all such detection zones.
(iv)
Exception based reporting This is the largest loading for the network. For basic 2-phase operation, the local traffic controllers will typically experience 10-123 changes of state as follows: Macroscopic status
3
Main Street Phase
Side Street Phase
There may be some internal state changes that do not result in a change of display.
Page 79 of 95 Microscopic status
Green Walk Initial
Green Walk Variable
Green Flashing don’t walk
Yellow Don’t Walk
All Red
Green Walk Initial
Green Walk Variable
Green Flashing don’t walk
Yellow Don’t Walk
There are two types of status information that may be requested from the traffic controllers: 1) macroscopic and 2) microscopic. Where macroscopic data is requested, only the change of phase would be reported when it occurs. Since cycle lengths are on the order of 50 to 120 seconds, for a simple 2-phase intersection, a message would be sent four times per cycle – one message indicating the start of the main street, one for the end of main street, one for the start of the side street, and one for the end of the side street. More complex intersections would require more messages. Each message would be on the order of 16-32 bytes plus the SNMP, UDP/IP and Ethernet overhead. Such messages would be sent from all intersections when they occur. When microscopic data is desired, each change of state would be transmitted from the chart shown above. Such data is used to drive detailed intersection displays showing such data as detector calls (i.e. request for service), signal head displays, etc. This would result in the transmission of 10-12 messages per cycle for a simple 2 phase intersection and more changes for more complex intersections. Such messages would be sent from all configured intersections when they occur. Each microscopic message is expected to be on the order of 16-32 bytes plus the SNMP, UDP/IP and Ethernet overhead. The central system relies on the updated status reported from the intersection based on the macroscopic level indicated above. Such data must be reliably sent from to the central station from all intersections within 1 second regardless of the network path or loading. For a selected number of intersections, the microscopic level of reporting will be required. This is estimated to be no more than 1000 intersections at any given time. Such data must be reliably sent from the intersections to the central station for all intersections within 1 second regardless of the network path or loading. Most of these messages will be sent in the form of SNMP Trap messages and will not require an acknowledgement from the central station. Thus, the messages from field to central will not result in a central to field acknowledgement of receipt.
(v)
Error and Significant Event reporting Some of the status changes are mission critical but occur very infrequently. These include cabinet failures (e.g. door open, conflict or failure flash). Such events must be reported to the central system and will also use SNMP Trap messages but will require acknowledgement from the central system. Other events such as plan changes, or operator interaction at the local level will be reported when they occur and require an acknowledgement from the central station. Such plan changes or operator intervention occurs infrequently (on the order of once per hour) from all intersections.
3-
Uploading of intersection data From time-to time, the central system may upload the controller’s complete database (see section 1 - ) for the purpose of comparing databases or verifying contents. Such operations are infrequent and generally triggered by an operator request based on a specific status report from the intersection or in coordination with maintenance activities.
All Red
Page 80 of 95 Such data transfer is of relatively low priority and will occur concurrently with the other status reporting indicated above. The communications network must be able to support such memory uploading for a selected intersection within 1 minute. No more than 10 such operations will be triggered at the same time.
4-
Command acknowledgement All of the SNMP SET4 commands sent from the central system to the intersections will require an acknowledgement from the field device. Some of the trap messages will also require an acknowledgement. This two-way traffic must be considered when developing a network design.
Section H:
Peer-to-peer communications
The controllers have the capability of exchanging data among themselves to better manage traffic conditions. Such an exchange is expected to be between adjacent intersections or within a small area. Such messages are relatively small in nature (16-32 bytes plus the SNMP, UDP/IP, and Ethernet overhead) and may originate from any intersection. The use of this capability is not planned for the initial system. However, this capability must be supported by the network. Such data transfers must not require that the data be sent through the central computer. Data is to be transmitted via the “shortest”5 path
Section I:
Simultaneity
Throughout this document, the concept of simultaneous operations is suggested. For VTCS, intersections operate using various schemes for optimization of traffic flow. One is a progression where there is an apparent green flow and the lights are synchronized in one direction. Such lights change in sequence, and hence the changes of state at the individual intersections are not simultaneous. This spreads the communications loading over time. However, there are also timing plans with simultaneous operation. For these plans, hundreds of intersections may change state at exactly the same time. Under these circumstances, all of the intersections will attempt to report their changes of state at the same time. There are also certain anomalies and failures that tend to occur at the same time such as power outages. Under these circumstances, all of the intersections will return to operation at the same time and attempt to report their status at the same time. The RF communications infrastructure must be prepared for the loading to be “lumpy” and may not assume that the communications load will be spread over time.
Section J:
Redundancy
Each traffic controller must be able to reach the central computer by more than one path. In the event of a failure of the primary path due to equipment failure, RF anomalies, or network loading, the system must automatically reconfigure itself and transmit the 4
This could also use SFMP and STMP SET commands as well. This is really intended to mean the lowest cost path – i.e. the path most likely to be able to handle the traffic with the least delay and network loading. 5
Page 81 of 95 packets of data to the central station via an alternate path without loss of information. Such redundancy and alternate routing must be transparent to the traffic controller and the central system. Re-routing must occur within ½ second for normal disruptions (failure of a single node) and must never take more than 3 seconds for a complex outage such as the failure of a wireless access point. The traffic controllers have the ability to “talk” to multiple central locations. The traffic controllers can be programmed to transmit different status information to different central systems for backup and redundancy purposes. Multiple master stations may also communicate directly to the traffic controller. The concept of multiple paths implies that the communications network is a mesh type configuration with multiple paths between the intersection and each of at least 2 wireless access points.
Section K:
Quality of Service
The traffic control application is considered mission critical. The needs of this network have been identified herein and it is critical that the wireless infrastructure support managed quality of service QoS for the various applications which may share the channel space. While the data needs of VTCS will tolerate some delays and latencies as described herein, the “messages” cannot be blocked or otherwise superseded by other applications (e.g. Voice over IP) for long periods (>2 seconds) or the central system will classify the intersection(s) as failed creating event logs and triggering operator review of the condition. As noted above, if critical intersection or adaptive control is in process, loss of detector data and the inability to download new timing parameters will reduce the effectiveness of the algorithms. The wireless service must be structured to ensure the proper flow of the traffic application data. The data flows are not large but rather are small amounts of data from many remote locations on a periodic and event driven basis. The design of the network must take these needs into account when locating the Wireless Access Points.
Section L:
Other support
The VTCS operators interact with the system through a Windows user interface. These applications include incident tracking, planned event tracking, traffic control, and will include additional features such as CCTV camera control and monitoring and variable message sign control. It is desirable to support mobile workstations connected either at the traffic controller (using an Ethernet hub or switch) or using a wireless router/mobile transceiver as part of a remote command and control center. The network traffic is difficult to quantify, but it will be TCP/IP traffic from a Windows workstation using a Windows Terminal Services interface. This can be supported at data rates of 64 Kbps or faster from a specific location. The number of remote workstations using the wireless network is expected to be relatively small. For the purposes of estimating the network traffic, a 64 Kbps load can be assumed will meet the need from up to 5 concurrent locations spread throughout the network with no more than 2 at any given location.
Section M:
Frequency Assignment
The City is making a considerable investment in the deployment of wireless devices for each intersection. It is important that such an investment cannot be compromised by RF
Page 82 of 95 interference from other services or technologies. As such, it is assumed that the proposed solution will use a licensed frequency.
Section N:
Security
The VTCS will use public key encryption to authenticate messages sent from the central system to the field devices. The network provided must include a layer of security that authenticates the devices connected to the network and triggers alarms when foreign devices or unauthorized devices are attached to the network.
Section O:
Continuous operation
The traffic control network must operate at full performance 24 hours per day 7 days a week without outages. While it is recognized that failures will occur, the concept of routine planned outages for network management and maintenance are unacceptable. The traffic control application is a mission critical system for NYCDOT and as such, it is important that the system be continuously available. There are backup schemes at the intersection level that minimize the effects of an outage, however, the inability to communicate with the field devices means slowed failure management (i.e. recognition of intersection failures) and an inability to change operation of the field devices to respond to incidents and planned events. Operation in the field must be unattended; the system and devices shall not require a manual reset or cycling of power at the intersection level to recover from any sort of transient failure. Such failure recovery must be automatic with built in watchdogs and anti-streaming electronics to prevent a single location from disrupting the entire network. Likewise, power outages and transients of any sort cannot leave the field devices in an inoperative state once power has been restored.
Section P:
Life Cycle Considerations
Traffic control devices are expected to provide long term service. It is typical for the traffic control devices (e.g. traffic controllers, signal heads) to provide 20 years of reliable operation and be fully maintainable over that life time. Wholesale replacement of the communications infrastructure every 3 to 5 years is an unacceptable solution. Any proposed solution must use stable and proven technology with a guarantee of long term support for repair and replacement. Such support shall be for a minimum of 10 years.
Section Q:
Communications Channel Characteristics
The following sections describe the specific network characteristics for the traffic control applications.
Section Q.01
Communications Delays The delays through the network (from the most distant traffic controller to the central system) must not exceed 500 milliseconds under normal network loading. As noted above, the intersections will be transmitting their data on an event driven and periodic basis to be monitored and managed at the central computer in real-time. The system uses the field data to compute timing plans, log data, and track intersection operation for failures and to drive graphic displays. Commands are sent to the intersections to change timing plans and timing parameters.
Page 83 of 95 The assumed model for this deployment is a mesh type network where intersections transmit their data through intermediate repeaters/routers to reach a wireless access point where the data is sent over a wired network to the central system. If individual controllers are all wireless routers as well, then one can envision a grid or mesh network using a wireless router at each intersection. For such a network, the data would hop from intersection to intersection to reach a wireless access point. The number of hops depends on the transmission speed, line of sight, and the network loading. The 500 millisecond limit applies to any possible string or number of hops and includes all delays under all loading.
Section Q.02
Communications Latencies The variability of the network delays can create a problem for the VTCS messages. The network latencies must be no more than 250 milliseconds for any message through the network.
Section Q.03
Reliability The reliability of the communications link over this network is important. Since the system will only transmit changes of state, a lost message will result in poor displays and may fail an intersection or increase the time required for the operators to process false failure indications. Many of the messages are transmitted from the field to the central system without acknowledgement. The microscopic and macroscopic data listed above will follow that procedure. Therefore, the network must not drop packets when the loading is severe and must ensure reliable delivery of packets throughout the RF network. The system must not drop or otherwise loose or damage more than .0001% of the packets transmitted.
Section R:
Physical options
Section R.01
Field Unit There is space available in the controller cabinet for a modem or shelf mounted unit. The space available on the shelf is shown on the attached pictures. The space available is approximately 6 inches wide by 8 inches high by 12 inches deep including all connectors and cables. The modem slot includes power connections as shown in Table 1. These may be used for a custom fabricated modem/RF module and the front panel may be used for all connections including the Ethernet and the RF cable.
Table 1 – Modem Power Supplies Power Supply
Current (max)
Max Voltage
Min Voltage
+ 5 VDC
500 ma
5.125
4.875
+12 VDC
100 ma
12.6
11.4
Ripple
<.2% rms, 1% peak-to-peak or 50
Other
Overshoot < 5%
Page 84 of 95 -12 VDC
100 ma
-12.6
-11.4
MV – whichever is greater
In addition to this slot, there is an input slot on the back of the controller (detector slot) where a card could be developed. These slots include 120 VAC and 24 VDC (@100 ma). This is a standard input file slot as defined by the NYS DOT specification. The form factor for this card is shown in figure 2. The cabinets are sealed aluminum cabinets and are typically pole mounted. Wiring is brought through 2 conduit entries at the back of the cabinet. Any antenna location will be mounted exterior to the cabinet and may not be mounted on the cabinet directly. It must be mounted well above the cabinet so that vandals cannot reach it. Further, any antenna must be approved by the various architectural control committees and must be unobtrusive etc.
Section R.02
Central Interface
It is assumed that all central connections will be made to the VTCS Ethernet LAN. This LAN is 100BaseT and connects to communications servers. Each of the communications servers is an Intel box running a real-time operating system.
Section S:
Video
The City has a desire to support streaming video using encoders. The video will be IP video and the encoders are to be determined. The video is to include camera control and the ability to manage the frame rates, image size, and resolution. The number of cameras and location is to be determined. The dedicated bandwidth is expected to be on the order of 128 Kb per image. The number of cameras supported will depend on the network architecture and limitations. It is not intended that the video requirements set the standard for the network for VTCS, rather, it will be used as part of the evaluation process to determine which system alternative provides an optimal solution for the City.
Page 85 of 95
2070 Modem Slot
Serial and Ethernet ports
Power Available
Available Shelf Space
Detector Slot
These pictures show the existing ASTC cabinet and installation
Page 86 of 95 Figure 1 - 2070 Modem dimensions
Page 87 of 95
Detector Slot Dimensions
NOT TO SCALE
28.448 mm
11.938 mm
PC BOARD
DETECTOR MODULE 90.4MM
114MM
SIDE VIEW
3.175 mm MAXIMUM 165.1 mm 174.63 mm 2.54 mm
ALL DIMENSIONS ARE (+/-) 0.508 mm EXCEPT AS NOTED Figure 2 Detector card form factor for use in the input file
List of intersections for Pilot (the City will designate 12 intersections from the following list):
1.574 mm
Page 88 of 95
1. Cross Bay Blvd
@ 165th Avenue
2. Crossbay Blvd.
@ 164th Avenue
3. Crossbay Blvd.
@ 163rd Avenue
4. Cross Bay Blvd.
@ 162nd Avenue
5. Cross Bay Blvd
@ 161st Avenue
6. Cross Bay Blvd
@ 160th Avenue
7. Cross Bay Blvd
@ 158th Avenue
8. Cross Bay Blvd
@ 157th Avenue
9. Cross Bay Blvd
@ 156th Avenue
10. Cross Bay Blvd
@ Shore Pkwy E S/R
11. Cross Bay Blvd
@ Shore Pkwy W S/R
12. Cross Bay Blvd
@ Pitkin Avenue
13. Cross Bay Blvd
@ Linden Blvd.
14. Cross Bay Blvd
@ 134th Avenue
15. Cross Bay Blvd
@ 133rd Avenue
16. Cross Bay Blvd
@ Sutter Avenue
17. Cross Bay Blvd
@ 109th Avenue
18. Cross Bay Blvd
@ 107th Avenue
19. Woodhaven Blvd
@ Liberty Avenue
20. Rockaway Blvd.
@ 94th Street
21. Woodhaven Blvd
@Rockaway Blvd
22. Woodhaven Blvd
@ 103rd Avenue
23. Woodhaven Blvd
@ 101st Avenue
24. Woodhaven Blvd
@ 97th Avenue
25. Woodhaven Blvd
@ 91st Avenue
26. Woodhaven Blvd
@ 89th Avenue
27. Woodhaven Blvd
@ Jamaica Avenue
28. Woodhaven Blvd
@ 86th Road
29. Woodhaven Blvd
@ 85th Road
Page 89 of 95 30. Woodhaven Blvd
@ Park Lane So
31. Woodhaven Blvd
@ 81st Road
32. Woodhaven Blvd
@ Forest Park Dr.
33. Woodhaven Blvd
@ Myrtle Avenue
34. Woodhaven Blvd
@ 73rd Ave
35. Woodhaven Blvd
@Metropolitan Ave
36. Woodhaven Blvd
@ 66th Avenue
37. Woodhaven Blvd
@ Furmanville Ave
38. Woodhaven Blvd
@ 64th Road
39. Woodhaven blvd
@ Penelope Ave
40. Woodhaven Blvd
@ 63rd Ave
41. Woodhaven Blvd
@ 62nd Road
42. Woodhaven Blvd
@ Dry Harbor
43. Woodhaven Blvd
@ Alderton St.
44. Woodhaven Blvd
@ Eliot Avenue
45. Woodhaven Blvd
@ Wetherole St.
Page 90 of 95
ATTACHMENT D INSTALLATION GUIDELINES Installations on buildings or other structures are subject to regulations promulgated by the New York City Department of Buildings, the New York City Fire Department, the Department of Transportation (in the case of traffic lights, over-highway signage, and light poles) and the New York City Art Commission or by any authorized agency with jurisdiction over the structure being used or the service being provided. Installations on street light poles, traffic light poles and highway sign supports must conform to the City’s requirements, as follows. (a)
Permitted Components and Size of Base Station Equipment.
Proposals for location of base stations and related facilities on street light poles (SLPs), traffic light poles (TLPs) or highway sign supports (HSSPs) shall include at least a schematic design for, and a photograph of, the equipment intended to be installed. The fullest possible design description and photographic description of the proposed installations are encouraged. Proposals may contemplate the installation of one, two or all three of the following elements to be installed on SLPs/TLPs/HSSPs, provided such elements to be installed are consistent with the following parameters: (1) One equipment housing (which may enclose, incorporate or consist of one or more than one antenna of any type, or other form of equipment) within either of the two following size parameters: (A) An equipment housing with a volume no greater than 2.8 cubic feet (i.e., 4,840 cubic inches). Equipment housings that are of a volume no greater than 2.8 cubic feet, but that are not “sub-sized housings” under subsection (B) below are referred to in this RFP as “standard housings”. Standard housings shall have a maximum width (i.e., a maximum horizontal dimension, perpendicular to the pole and parallel to the ground) of eighteen inches unless an operational need for a larger width is demonstrated to the satisfaction of DoITT and the City’s Department of City Planning (“DCP”) (B) An equipment housing with maximum dimensions of 13 inches by 9 inches by 4 inches (that is, no more than thirteen inches in its longest dimension, nine inches in its second longest dimension and four inches in its shortest dimension). Equipment housings complying with this subsection (B) are referred to in this RFP as “sub-sized housings”. (2) Up to two stick-type antennas, each no more than two inches in diameter and extending no more than thirty-six inches in length, extending vertically (either up or down) from a base either at the top of the pole or on the related equipment housing.
Page 91 of 95 (3) Wire or cable interconnecting the above elements with each other and with underground power and/or other supporting utility facilities (in areas where such utility facilities are located above ground, then such wire interconnection shall be permitted to connect to such above ground facilities), with as much of such wire or cable being located inside the SLP/TLP/HSSP, rather than externally, as practicable. (b) Permitted Weight of Base Station Equipment. All equipment to be installed on a pole must be of a weight no greater than that compatible with the capacity of the pole to safely and securely support such equipment. Calculation of such compatible weights shall as appropriate take into account snow loads or other reasonably predictable weight burdens to which equipment may be subject in the field. (c)
Permitted Location and Orientation on Pole of Base Station Equipment.
(1) Unless otherwise specifically permitted by the City, all equipment on any SLP/TLP/HSSP will be located on the vertical portion of the pole (that is, unless otherwise permitted by the City, no equipment will be located on any “arm” or horizontal portion of the SLP/TLP/HSSP) and equipment housings shall be oriented so that the largest dimension is the height. Notwithstanding the preceding sentence, however, subsized housings and equipment related thereto may be located at the top of the curved arm of an SLP with a cobra-head fixture (immediately adjacent to the luminar itself) or at the junction of the curved arm and the vertical portion of the pole (if, pursuant to this sentence, housings are located on a horizontal “arm”, such housings shall be oriented so that their largest dimension is also horizontal). (2) On TLPs with signal “arms”, housings shall be located in the “arm zone”, the “arm zone“ being defined as the portion of the pole above the curved arm and below the short cross bar carrying the tension rods supporting the “arm”. On TLPs without signal “arms”, and on SLPs, housings shall be located, except as expressly permitted by the City, not lower than fifteen feet above curb level (except that sub-sized housings may be located as described in the final sentence of the preceding subsection (1) even if such location would be inconsistent with such height requirement). (d) Permitted Visual Appearance of Base Station Equipment. (1) Each equipment housing must be painted the same color as the pole on which it is sited. (2) No writing, symbol, logo or other graphic representation that is visible from the street or sidewalk shall appear on any exterior surface of equipment housing. (e) Review Requirements for Design and Installation of Base Station Equipment. Installation of equipment on poles shall be subject to the City’s right to review and approve the final design and appearance of all equipment to
Page 92 of 95 (1) Ensure compliance with all applicable laws, rules and regulations of the City (including to the extent applicable and without limitation Landmarks Commission and Art Commission requirements), (2) Ensure public safety, the integrity of City facilities and non-interference with pedestrians and vehicular traffic, and (3) Ensure esthetic consistency with the poles to which the equipment will be attached (including signage and other items or matter that may be located on such poles) and the surrounding context. Potential Proposers should note that in some areas of the City (such as historic districts, business improvement districts or other types of areas) specially designed poles have been or may be installed in some locations. Integrators seeking to install equipment on such specially designed poles may be required to modify otherwise permitted equipment designs for consistency with special pole designs. (f) Power Supply. Each Integrator will be responsible for obtaining and paying for electrical power for its equipment. (g) Radio Frequency Energy Exposure Limits. Proposals shall include documentation showing that the radio frequency energy exposure from equipment proposed to be installed will be below the maximum permitted levels established by the Federal Communications Commission (FCC). Contracts issued pursuant to this RFP will require on-going compliance with such FCC maximum permitted levels (calculated on an aggregate basis with any other radio frequency energy emitters that may be present), and permit the City to require testing, from time to time, by independent experts, at the expense of Integrators, to ensure such compliance. (h) City Pole Management Requirements. Any facility located on any City pole will be subject to the City’s operational needs with respect to such pole. Thus, for example, if the City determines that any pole is no longer necessary or appropriate at its location then a Integrator with facilities on such pole will be required to remove such facilities or risk removal by the City, and if the City determines that it is appropriate to move or remove any pole temporarily to accommodate City or public activities (for example a parade such as the annual Macy’s Thanksgiving Day parade), then a Integrator will be required to cooperate with such temporary move or removal. LOCATION AND NUMBER OF BASE STATIONS TO BE PLACED ON LIGHT POLES. Location Requirements. No more than one base station permitted pursuant to this RFP will be permitted on any single pole.
Page 93 of 95 Base stations permitted pursuant to this RFP will only be permitted on SLPs if such SLPs are located at intersections, except that such base stations may be placed on SLPs at other than intersections upon a demonstration, to the satisfaction of DoITT and DCP, that there is an operational need for such siting at non-intersection locations (in the event of such approved location at non-intersection sites, only sub-sized housings will be placed at such non-intersection sites unless there is a further demonstration to the satisfaction of DoITT and DCP that there is an operational need for standard housings at such sites).(3) Base stations permitted pursuant to this RFP will be permitted on SLP sites at any intersection only up to the number which leaves two SLP sites at each intersection without such base stations, and thus available for future designation, except that such base stations may be permitted pursuant to this RFP at locations which reduce below two the number of SLPs at an intersection left without such base stations upon a demonstration, to the satisfaction of DoITT and DCP, that there is an operational need for such siting.(4) Base stations permitted pursuant to this RFP will only be permitted on TLPs that support a signal “arm” reaching into the roadbed, except that if at an intersection there are no TLPs with such a signal arm, then up to two TLPs without signal arms may be used for base stations at such intersection. Permission for pole use granted pursuant to this RFP will require that base stations be placed, located and operated so as not to interfere with the operation of base stations of other any authorized entity or with public safety operations or other City operations. Proposers are encouraged to include in their responses to this RFP proposed approaches to assuring such non-interference.
Page 94 of 95
ATTACHMENT E MAP OF MANHATTAN PILOT AREA
Page 95 of 95
APPENDIX A Appendix A, entitled “General Provisions Governing Contracts for Consultants, Professional and Technical Services,” is available to prospective Proposers upon request to the Authorized Agency Contact Person indicated in this RFP.
