Attachment_1_-_SOW.docx

Federal Communications Commission Internet-based TRS Telephone Numbering

Statement of Work Attachment 1

273FCC19R0002

1. Introduction

1.1. Internet-based Telecommunications Relay Services (Internet-based TRS, or iTRS) include the Video Relay Service (VRS) between video and voice communication, and the Internet Protocol Relay Service (IP Relay) between text and voice communication.

1.2. The TRS Numbering Directory for Internet-based TRS Users (TRS Numbering Directory) enables persons with speech or hearing disabilities to be reached and to reach other persons using geographically-appropriate 10-digit telephone numbers. For example, a hearing person using a telephone can dial a ten-digit telephone number to reach a deaf person using a video device. The voice call is routed over the telephone network based on the ten-digit number to a VRS provider where a communications assistant will be connected to the deaf user via a video link over the Internet. The communications assistant then translates the call between the hearing person’s voice communication and the deaf person’s American Sign Language communication.

1.3. The TRS Telephone Numbering Directory is the central database that supports the assignment and use of 10-digit numbers from the North American Numbering Plan (NANP) for iTRS. The Contractor will serve as the TRS Numbering Administrator and will implement and operate the TRS Numbering Directory on behalf of the Federal Communications Commission (FCC). See 47 C.F.R. § 64.613(b). The contents of the Numbering Directory are maintained and queried by FCC-authorized providers of Internet-based Telecommunications Relay Services.

1.4. Listing of Abbreviations

2. Specific Requirements

2.1. Information to be provisioned in a TRS Numbering Directory

2.1.1. The Contractor shall complete the transfer of the existing TRS Numbering Directory from the existing Contractor, such that it will be available for routing calls based on 10-digit NANP numbers to the appropriate Internet-based TRS users no later than 90 days after contract award. The Contractor shall transfer current data from the existing TRS Numbering Directory if needed 1. The Contractor shall operate the TRS Numbering Directory service for one 12- month base period and four additional 12-month option renewal periods, which will be exercised at the discretion and in the best interest of the Government. Ongoing regulatory proceedings concerning or impacting the Telecommunications Relay Service, including services provided under this contract, may result in a decision to recompete some or all the services obtained under this contract, rather than exercise options in later option years.

2.1.2. The Contractor shall comply with all Commission rules and orders that relate to the TRS Numbering Directory.2

2.1.3. The Contractor shall be a neutral third-party not affiliated with any Internet-based TRS provider.3

2.1.4. The Contractor shall implement and operate the TRS Numbering Directory, which enables iTRS providers to link each telephone number assigned to an Internet-based TRS user to an appropriate endpoint identifier. An endpoint will be identified by a Uniform Resource Identifier (URI). The URI for a VRS user will contain an Internet Protocol (IP) address and port or a telephonenumber@domain string using a h323 or sip “scheme” (protocol). An Internet Protocol address may be in Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6) format. The URI for an IP Relay user will contain a text-messaging “scheme” (protocol), username and domain.

1 The iTRS Transition Plan is available to potential offerors upon request, by contacting the Contracting Officer.

2 See generally 47 C.F.R. § 64.611 Internet-based TRS registration and § 64.613 Numbering Directory for Internet- based TRS Users. See also Telecommunications Relay Services and Speech-to-Speech Services for Individuals with Hearing and Speech Disabilities; E911 Requirements for IP-Enabled Service Providers, CG Docket No. 03-123;

WC Docket No. 05-196, Report and Order and Further Notice of Proposed Rulemaking, 23 FCC Rcd 11591, (2008), Telecommunications Relay Services and Speech-to-Speech Services for Individuals with Hearing and Speech Disabilities; E911 Requirements for IP-Enabled Service Providers, CG Docket No. 03-123, WC Docket No. 05-196, Second Report and Order and Order on Reconsideration, 24 FCC Rcd 791 (2008); Telecommunications Relay Services and Speech-to-Speech Services for Individuals with Hearing and Speech Disabilities; E911 Requirements for IP-Enabled Service Providers; Internet-Based Telecommunications Relay Service Numbering, CG Docket No.

03-123, WC Docket No. 05-196, WC Docket No. 10-191, Report and Order, 26 FCC Rcd 11779 (2011).

3 See 47 C.F.R. § 64.613(b)(1).

4 See Bradner et al., The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM), Memorandum from the Internet Engineering Task Force on Internet

2.1.5. The Contractor shall implement and enable a method to enable an iTRS provider to link a ten-digit toll free telephone number to a geographically-appropriate ten-digit telephone number. A query for the toll-free telephone number shall return the information in the Directory for the associated 10 digit number, or a reply that contains the 10 digit telephone number with an indication that the provider must re-query the TRS Numbering Directory with that 10 digit telephone number to obtain the URI.

2.1.6. The Contractor shall implement the capability to link a single telephone number to one or more URIs and to provision a single ten-digit phone number with identifiers for both VRS and IP relay in the TRS Numbering Directory.

2.1.7. The Contractor shall not enable the capability to link a single telephone number to one or more URIs and to provision a single ten-digit phone number with identifiers for both VRS and IP relay for iTRS providers until authorized by the FCC to do so. 6

2.1.8. The Contractor shall ensure that the TRS Numbering Directory will be capable of accommodating at least four million entries.

2.2. Access to the TRS Numbering Directory

2.2.1. The Contractor shall limit provisioning and querying access to the TRS Numbering Directory to Internet-based TRS providers and other entities authorized by the FCC, e.g. VTCSecure and MITRE Corporation pursuant to the Wireline Competition Bureau’s November 23, 2015 Order waiving sections 64.613(a)(4), 64.613(b)(2) and 64.623(c) of the Commission’s rules for those entities.7

2.2.2. The Contractor shall extend querying access to the Telecommunications Relay Services Fund Administrator (TRS Fund Administrator)8 and the FCC Office of Inspector General. 9

2.2.3. The Contractor shall support secure provisioning and querying access to the TRS Numbering Directory for test and operational purposes for as many as 100 Internet-based TRS provider or other authorized entities.

2.3. Means for Provisioning to the TRS Numbering Directory

2.3.1. Pursuant to the FCC’s rules, every provider of Internet-based TRS is required to offer Internet-based TRS users the capability to register with that iTRS provider as the “default

Standards Track Protocol to the Internet Community, RFC 6116 (March 2011), available at http:

http://ietfreport.isoc.org/rfc/rfc6116.txt /ietfreport.isoc.org/rfc/rfc6116.txt 5 See Hoeneisen et al., Update of Legacy IANA Registrations of Enumservices, Memorandum from the Internet Engineering Task Force on Internet Standards Track Protocol to the Internet Community, RFC 6118 (March 2011), available at http: http://ietfreport.isoc.org/rfc/rfc6118.txt /ietfreport.isoc.org/rfc/rfc6116.txt 6 See Second Report and Order at para 41.

7 See 47 C.F.R. § 64.613(a)(4) and Wireline Competition Bureau Order, November 23, 2015, DA-1349.

8 See DA-12-687 9 See 5 U.S.C. App., Inspector General act of 1978, § 6(a)(1).

iTRS provider” and provide or port for that user a NANP telephone number.10 Such registration is required to allow an Internet-based TRS provider to take steps to associate the Internet-based TRS user’s telephone number with the URI information needed for call routing and completion.

2.3.2. The Contractor shall support an iTRS Provisioning Interface and an iTRS Web Graphical User Interface (GUI) enabling the user’s default iTRS provider to enter the user’s telephone number, user type (see Section 2.10) and associated URI information into the TRS Numbering Directory over encrypted connections. The iTRS provider interface to the provisioning system shall be equivalent to, but need not be the same as the iTRS Provisioning Guide V4.0. The provider Web GUI shall equivalent to but need not be the same as the iTRS Web GUI Guide, Version 1.0.11 The FCC desires the Provisioning Interface to be a REST/json application programing interface optimized for sip protocol, proxy server (gateway) addressing now used for the majority of entries in the directory.

2.3.3. The Contractor will enforce access restrictions on the Provisioning Interface by means of IP address filtering and/or per-provider TLS certificates. Only the default provider will have permissions to create and update the TRS Numbering Directory record associated with the assigned ten-digit number.

2.4. Means of querying the TRS Numbering Directory

2.4.1. For all calls made by providers, there is a need to retrieve the routing information from the TRS Numbering Directory and to validate that the call should be completed. The Contractor shall support the capability of an iTRS provider to query the TRS Numbering Directory via the Query Interface with two ten-digit numbers (the calling and called telephone numbers), service (VRS or IP Relay) and the direction of the call (inbound or outbound) to obtain the appropriate routing information. The query shall return a unique Transaction ID for every query. The query interface shall be equivalent to, but not necessarily the same as the iTRS All Call Query described in the Query Interface document iTRS Query Guide V4.1.12 The FCC desires the Query Interface to be a REST/json application programing interface optimized for sip protocol, proxy server (gateway) addressing now used for the majority of entries in the directory.

2.4.2. The Contractor shall also support a Registered iTRS User Validation capability so that a query with an IP address, userid or screen name will return the registered telephone number if one exists in the database. When a provider queries the iTRS Numbering Directory using a userid, such as when it receives a dial-around call from a VRS device that is behind another provider’s gateway, an alternate query response will indicate simply that this is a valid IP address of a VRS gateway. This “reverse lookup” query is used to validate that a user attempting to place a call through an alternate iTRS provider is registered in the directory, and where possible provides the correct telephone number for the alternate provider to use for reports. The reverse query interface shall be equivalent to, but not necessarily the same as that found in the iTRS Query Interface document iTRS Query Guide V4.1.12 The FCC desires the Reverse Query Interface to be a REST/json application programing interface optimized for sip protocol, proxy server (gateway) addressing now used for the majority of entries in the directory.

10 See 47 C.F.R. § 64.611 Internet-based TRS Registration.

11 The iTRS Provisioning Guide and iTRS Web GUI Guide are available to potential bidders upon request, by contacting the Contracting Officer.

12 The iTRS Query Guide is available to potential bidders upon request, by contacting the Contracting Officer.

2.4.3. The Contractor shall provide no facility to download multiple records that are under the control of another iTRS provider in a single transaction.

2.4.4. The Contractor shall restrict the Query Interface access to the TRS Numbering Directory to authorized Internet-based TRS providers making queries on a call-by-call basis, to the FCC Office of Inspector General, and to the TRS Fund Administrator. Access restrictions will be enforced by Virtual Private Network (VPN) termination restrictions, IP address filtering and/or per-provider TLS certificates.

2.5. Customer Test Environment (CTE)

2.5.1. The Contractor shall make a Customer Test Environment (CTE) available to iTRS providers and other authorized entities, in addition to the production provisioning system, web GUI, and query systems. The CTE is a test system separate from the production systems, which has the same code and the same facilities as the production system. The CTE may be non-redundant and of a smaller scale sufficient to enable at least five providers to simultaneously provision and query the test systems.

2.5.2. The Contractor shall ensure that the CTE be available to iTRS providers for testing newly developed or modified provider systems prior to attempting access on the production system.

2.6. Local Number Portability

2.6.1. Pursuant to the FCC’s rules and consistent with Local Number Portability, an Internet- based TRS user may select and register with a new default provider at any time and have his ten-digit number ported to that provider.13

Number porting in the TRS Numbering Directory shall work as implemented today: The TRS Directory tracks porting of telephone numbers in the National Portability Administration Center (NPAC), and monitors the SPID, AltSPID and/or LastAltSPID fields. Providers porting numbers from another provider arrange to have their XSPID code (assigned by the NPAC) in AltSPID/LastAltSPID by their underlying carrier. A change in AltSPID/LastAltSPID to a provider’s XSPID indicates a port from one provider to another. The TRS Numbering Directory then allows the new provider to provision the number. As soon as the gaining provider first provisions the number, the losing provider loses access to the number. The TRS Numbering Directory can optionally notify the involved providers of the change in ownership of the record. The iTRS provider interface to the porting mechanism shall be equivalent to, but need not be the same as the iTRS Provisioning Guide V4.0. The FCC desires the provider interface to the porting mechanism to be a REST/json application programing interface. The Contractor shall arrange access to the NPAC to maintain this interface.

2.7. Additional Security Considerations

2.7.1. The Contractor shall provide and operate multiple geographically dispersed provisioning sites and query sites for the TRS Numbering Directory sufficient to maintain the Service Level Agreement requirements. A provisioning site and a querying site may be co-located. Each site will have fully redundant configurations such that no single failure will cause the site to not be able to process transactions. Each site will be connected to the Internet via at least two carriers.

13 See 47 C.F.R. § 52.34

2.7.2. The Contractor shall ensure both the provisioning sites and the query sites will be physically secure, and have redundant power and cooling systems, including uninterruptible power supply and backup generators. Contractor will limit site access to essential personnel and require all individuals to properly display company identification (e.g., photo ID badge or visitor badge)

2.7.3. The Contractor shall continuously monitor the TRS Numbering Directory for network- based security threats, such as Denial of Service Attacks, and deploy appropriate attack detection and mitigation tools. The Query Interface must be capable of providing adequate service in the face of a Denial of Service Attack the size of the largest documented attack at least 90 days prior to the attack on the TRS Numbering Directory. Contractor will report network-based security incidents that the Contractor judges to be exceptional to the COR

2.8. Reporting, Data Maintenance and Data Retention

2.8.1. The Contractor shall propose and shall implement monthly reports to each iTRS provider and to the FCC that contains information mutually agreed upon by Contractor and the FCC.

2.8.2. The Contractor shall propose in response to this solicitation and, with the Commission’s approval shall implement if awarded the contract, a system for reporting monthly to the FCC on summaries of provisioning and query transactions for all providers and on other measures of records management normally associated with such database operation. The Contractor shall, upon request from the FCC, provide reports on iTRS provider provisioning in batches of TNs, not more than one hundred thousand (100,000) TNs at a time, and inception of the Contractor’s system. Such batches of TNs shall be submitted by the FCC to the contractor in Comma Separated Values (.CSV) file format with one TN per row.

2.8.3. The Contractor shall retain source records for at least 180 days and archive reports for at least three years.

2.8.4. The Contractor shall document a failure of any site (see Section 2.7.1) to be not be capable of successfully processing a transaction by a provider. The document shall detail the failure, its root cause, actions taken to immediately remedy the fault and actions to be taken to avoid the same problem recurring. The document shall be included in the monthly report to the FCC if the failure occurred at least one week prior to the report, or, if the failure occurred within a week of the report, the document should be included in the next monthly report.

2.8.5. If the TRS Directory is not capable of processing either provisioning or query transactions (or both) from providers successfully from any site from any cause, the provider shall

a) notify the FCC via email within 10 minutes of such failure

b) notify the FCC via email when service is restored

c) create a report and send to the FCC, within 30 days of the incident start documenting the incident including

i) Timeline of the incident including when it actually started, how it was discovered, which providers noticed the incident and when, what intermediate steps were taken to restore service. When partial service was restored, when full service was restored and when all sites were fully operational.

ii) What the proximate and root cause were.

iii) How many transactions were affected, including specifically if any emergency calls were affected.

iv) List all actions that have been or will be taken to avoid recurrence. For future actions, provide dates for when each action will be completed.

d) Inform the FCC when all actions identified in c.iv above have been completed.

2.9. System Design and Operations Documentation Ownership

2.9.1. All system design documents, data dictionaries, technical procedures and guides, and other documents produced by the Contractor in support of the TRS Numbering Directory system are and will remain the property of the FCC. The Contractor shall ensure such documents are kept up-to-date and available to the FCC.

2.9.2. The Contractor shall ensure that all standard operational and maintenance procedure documents produced by the Contractor in support of the TRS Numbering Directory system are transferred to the FCC at the conclusion of this contract. The Contractor shall ensure such documents are kept up-to-date and available to the FCC. Copyrighting under FAR 52.227-14(c)(1) or release of data under FAR 52.227-14(d) is authorized only as allowed by this contract for contract performance or as otherwise authorized by the Contracting Officer on an individual or class basis.

2.10. Interaction with User Registration Database (URD)

2.10.1. The Contractor must provide two automated interfaces to URD Administrator to manipulate this flag, as set forth below:

a. Contractor shall develop and implement a per-TN valid operation that accepts a TN, a provider XSPID, service type (VRS, IP/Relay) and a URD-Valid boolean. When changes are made to the URD, the URD will use this interface to make corresponding changes to the Directory. If the TN does not exist in the Directory before this operation is initiated, the Directory will create a record for the TN that will include the provider XSPID and service type. Only that provider will be allowed to “Activate” the TN. This is a real time interface.

b. Contractor shall develop and implement two batch file ingest mechanisms that accept a comma separated value (“CSV”) table of TNs, service and provider XSPIDs representing the complete list of URD-valid TNs in the URD. The first mechanism is a “full file” mechanism which will contain a record for every TN in the URD. Any TN not in this URD-valid TN list will be considered invalid. The second mechanism is an incremental file which contains a flag (insert/modify or delete). A secure file transfer mechanism will be established for the URD Administrator to transfer this list to Contractor. The Contractor must be able to accept a full file every hour and an incremental file every 5 minutes with at least 500,0000 records in the full file.

c. Contractor shall provide the capability for providers to mark an iTRS Directory record with the type of user the TN belongs to. Present user types include Deaf/Hard-of-Hearing, Hearing, Public Device and Private Device. The query operation response shall be modified based on the user type (of both TNs if both .

2.10.2. Query operations by providers on the Query Interface shall be validated according to the rules defined in the current Neustar implementation, considering:

a) The information in the query (calling and called party telephone numbers, service, call direction).

b) The information from the URD (XSPID, service, user type and URD Valid flag).

c) Porting information from the NPAC (SPID and XSPID)

2.10.3. Contractor shall provide the AllCallQuery detail record in CSV format that will be transferred to the URD Administrator on a daily basis using a secure file transfer mechanism. This AllCallQuery detail record will include:

a. Timestamp

b. Provider XSPID

c. Service

d. From TN

e. To TN

f. Direction

g. Valid value returned to querying provider

h. A unique ACQ transaction ID

2.10.4. Contractor shall provide an interface to the URD Administrator that notifies the URD Administrator of changes in provider responsibility for TN records in the Directory due to porting operations. The interface will make the notifications at the same time that changes are being made in the Directory and will include:

a. Timestamp of change

b. TN

c. Original Provider XSPID

d. New Provider XSPID

e. Hearing Indicator

2.10.5. Contractor shall provide interfaces to the URD Administrator (API and a GUI) that, when queried by TN, returns the iTRS default provider and the current iTRS-valid state.

2.10.6. Monthly reports will be created that detail:

a. Invalid TNs, per provider and consolidated (for URD Administrator and FCC)

b. Changes made summary

2.10.7. It is a material assumption to Contractor’s obligations hereunder that Providers will be required by the FCC to:

a. follow the guidelines for URI creation provided by Contractor, including correctly indicating the service type in the URI;

b. use the new query interface on all calls for which compensation will be requested; and

c. update the Directory and the URD (independently) for consistent content prior to completing a compensated call.

3. Implementation Performance Milestones 14

Activity Completion

contract award

contract award

contract award

System Infrastructure implementation 45 Days After Contract Award

Customer Provisioning

All Providers connected to Test environment 60 Days After Contract Award

All Providers connected to Production environment5 85 Days After Contract Award

Provider Beta & Inter-Operability Test

Provider Beta/Turn Up Test (1:1 testing with each provider) 5 65 days after contract Award

contract award

Go Live

90 days from Contract award

4. Operational Performance Metrics

The Contractor shall meet minimum service level objectives of the following Service Level Agreements (SLAs) and shall use best efforts to meet target service level objectives of those SLAs:

14 The projected completion dates set out in Section 3 are subject to change, either earlier or later, with the exception of the Go Live date, which will occur no later than 90 days after contract award. The Contractor ‘s performance will be judged on meeting the Go Live date and not on meeting the interim dates that are provided in order that the FCC can track the Contractor’s progress in implementing the TRS Numbering Directory.

SLA 1: TRS Numbering Directory - Availability

1.1 SLA SUMMARY

Availability

1.2 SLA OVERVIEW

1.3 SLA MEASUREMENT

approved reporting tool.

1. Quantifying the total period of availability for the Production (forward facing) in comparison to the total amount of time in the contract for the selected period.

Denominator for service level calculation purposes:

a) Downtime approved by the Government, including scheduled maintenance windows

b) Downtime due to events outside Contractor control and approved as such by the Government

c) Periods of time that cannot be evaluated due to failure of monitoring tools

1.4 SLA CALCULATION

(DENOMINATOR) Total amount of time (seconds) for the monitoring period =

(RESULT) Service Level (%) Attained.

1.5 SERVICE LEVEL OBJECTIVE

SLA 2: TRS Numbering Directory – Replication to Query DB

2.1 SLA SUMMARY

Replication to Query DB

2.2 SLA OVERVIEW

2.3 SLA MEASUREMENT

1. Recording the time difference between provisioning operations of the database from the provisioning node to a potential query in each query node

2. Selecting all refresh operations where the refresh interval exceeded 5 minutes

3. Calculating the number of provisioning transactions for each refresh period that exceeded 5 minutes

4. Calculating the total number of provisioning calculations during the Measurement Interval

1. A test application provisioning new content

2. The test application attempting to query the new content

3. Cross referencing to determine if response was correct (i.e., up-to-date).

4. Recording each time Query provides a response

a) Downtime approved by the Government, including scheduled maintenance windows

b) Downtime due to events outside Contractor control and approved as such by the Government

c) Failure of Monitoring Tools

2.4 SLA CALCULATION

within 5 minutes from the prior refresh (Divided by) ÷ (DENOMINATOR) Total number of provisioning transactions during Measurement Interval (Equals) = (RESULT) Service Level (%) Attained.

(NUMERATOR) Number of times query results were found to be correct within 5 minutes or less during measurement interval ÷

(DENOMINATOR) Total number of attempts to query results from the TRS Numbering Directory during Measurement Interval =

(RESULT) Service Level (%) Attained.

2.5 SERVICE LEVEL OBJECTIVE

SLA 3: Query - Effectiveness

3.1 SLA SUMMARY

3.2 SLA OVERVIEW

3.3 SLA MEASUREMENT

approved reporting tool.

1. A test application attempting to query content

2. Recording each time Query provides a response

3. Cross referencing to determine if response was accurate

2. The authentication interval is five (5) minutes.

Denominator for service level calculation purposes:

a. Downtime due to a network outage or network performance degradation outside the control of the Contractor

b. Periods of time that cannot be evaluated due to failure of monitoring tools

3.4 SLA CALCULATION

(DENOMINATOR) Total number of attempts to query results from the iTRS Directory during Measurement Interval =

(RESULT) Service Level (%) Attained.

3.5 SERVICE LEVEL OBJECTIVE

SLA 4: Query - Timeliness

4.1 SLA SUMMARY

4.2 SLA OVERVIEW

4.3 SLA MEASUREMENT

approved reporting tool.

1. A test application attempting to query content

2. Recording each amount of time for response

3. Average the response times

2. The authentication interval is five (5) minutes.

2. Instances scheduled to occur during the following periods are excluded from the Numerator and Denominator for calculation purposes:

a) Failure of Monitoring Tools

4.4 SLA CALCULATION

100ms during measurement interval ÷

(DENOMINATOR) Total number of attempts to query results from the iTRS Directory during Measurement Interval =

(RESULT) Average Service Level (%) Attained.

If Number of times query results loaded within 500ms during Measurement Interval = 0 then !00% otherwise 0%

(RESULT) Worst Case Service Level Attained.

4.5 SERVICE LEVEL OBJECTIVE

SLA 5: Backup and Recovery - Restoration

5.1 SLA SUMMARY

5.2 SLA OVERVIEW

5.3 SLA MEASUREMENT

5.4 SLA CALCULATION

(DENOMINATOR) Total number of Incidents where contractor was asked to recover lost content =

(RESULT) Service Level (%) Attained.

5.5 SERVICE LEVEL OBJECTIVE

SLA 6: Backup and Recovery - DR Execution

6.1 SLA SUMMARY

Execution

6.2 SLA OVERVIEW

6.3 SLA MEASUREMENT

6.4 SLA CALCULATION

(DENOMINATOR) Total number of Disasters = (RESULT) Service Level (%) Attained.

6.5 SERVICE LEVEL OBJECTIVE

SLA 7: Service Desk - Customer Service

7.1 SLA SUMMARY

Customer Service

7.2 SLA OVERVIEW

7.3 SLA MEASUREMENT

a) Downtime approved by the Government

b) Downtime due to events outside Contractor control and approved as such by the Government

c) Failure of Monitoring Tools

7.4 SLA CALCULATION

(Seconds)

(DENOMINATOR) Total amount of phone calls for the monitoring period =

(RESULT) Service Level (%) Attained.

7.5 SERVICE LEVEL OBJECTIVE

SLA 8: Service Desk - Incident Response Time

8.1 SLA SUMMARY

8.2 SLA OVERVIEW

8.3 SLA MEASUREMENT

Feedback.

8.4 SLA CALCULATION

(2) hours (DENOMINATOR) Total number of Incidents = (RESULT) Service Level (%) Attained.

8.5 SERVICE LEVEL OBJECTIVE

SLA 9: Service Desk - Issue Resolution Times

9.1 SLA SUMMARY

9.2 SLA OVERVIEW

9.3 SLA MEASUREMENT

Priority 2 High: 4 hours Priority 3 Medium: 8 hours Priority 4 Cosmetic: 24 hours

a) Downtime approved by the Government, including scheduled maintenance windows

b) Downtime due to events outside Contractor control and approved as such by the Government

9.4 SLA CALCULATION

(DENOMINATOR) Total number of Issues = (RESULT) Service Level (%) Attained.

If the number or issues in the Measurement Period is five or greater.

9.5 SERVICE LEVEL OBJECTIVE

SLA10: Program - Usage Reporting/SLA Compliance

10.1 SLA SUMMARY

10.2 SLA OVERVIEW

10.3 SLA MEASUREMENT

10.4 SLA CALCULATION

(DENOMINATOR) Total Required Reports within the measurement interval

(RESULT) Service Level (%) Attained.

10.5 SERVICE LEVEL OBJECTIVE

The maintenance window for the TRS Numbering Directory shall take place as follows:

6:55 am EST.

Any planned modification to the system of any kind which has the potential to affect the ability to provision or query the TRS Numbering Directory must be completed within the maintenance window and is subject to a 30 calendar day advance notice to providers and the FCC. No planned maintenance activity is allowed outside of the maintenance window. Emergency maintenance necessary to prevent imminent system failures or to correct an outage may be performed at any time. Each Emergency maintenance incident shall be reported to the FCC within 2 hours.