EIS_RFP_Section_J_Amendment_17.docx

General Services Administration Network Services 2020 Enterprise Infrastructure Solutions

Enterprise Infrastructure Solutions (EIS) Request for Proposals

Section J List of Attachments

Issued by:

General Services Administration Office of Integrated Technology Services 1800 F St NW Washington, DC 20405

October 2015

Table of Contents

General Services Administration

EIS RFP #QTA0015THA3003 Amendment 17 Enterprise Infrastructure Solutions EIS RFP #QTA0015THA3003 Amendment 17 ii Enterprise Infrastructure Solutions Appendix A Appendix B Appendix C Appendix D Appendix E Appendix F Appendix G Appendix H Appendix I Appendix J Geographic Coverage This Attachment specifies the geographic coverage requirements. The contractor shall provide and price mandatory services as specified in the Traffic Model. Geographic coverage requirements for service may differ between domestic and non-domestic areas. The Glossary (Attachment J.12) defines domestic and non-domestic areas.

Domestic Service Coverage This section describes geographic coverage requirements for domestic areas for Core Based Statistical Area (CBSA) -based services, as defined in Table B.1.2.1.1. Non-CBSA-based services, as defined in Table B.1.2.1.1, do not have domestic coverage requirements. The contractor shall provide CBSA-based services at contractor POPs serving the locations indicated within a CBSA. Section J.1.3 describes the CBSA coverage requirements for access arrangements.

At a minimum, for each CONUS CBSA in which the contractor proposes prices, the contractor shall provide and price all mandatory CLINs for CBSA-based services to the following:

1. All NSCs in the Traffic Model[footnoteRef:1] for that CBSA. For price tables with both originating and terminating location columns, Traffic Model records must be priced where the originating and terminating country/jurisdictions are both CONUS. [1: The Traffic Model specifies a set of Network Site Codes, forms part of the minimum entry requirements, and is used for evaluation purposes.]

2. NSCs within that CBSA, beyond those contained in the Traffic Model, as requested by the government For each OCONUS CBSA or OCONUS country/jurisdiction (that does not have a CBSA), where the contractor chooses to offer services, the contractor shall:

1. Propose prices for all the mandatory CLINs in the Traffic Model in the OCONUS CBSA or OCONUS country/jurisdiction chosen, and. For price tables with both originating and terminating location columns, a Traffic Model record must be priced if the OCONUS country/jurisdiction is present in the originating country/jurisdiction column and the terminating country/jurisdiction is either CONUS or the OCONUS country/jurisdiction.

2. Propose prices for all the mandatory CLINs in the OCONUS CBSA or OCONUS country/jurisdiction chosen, except as described in Table J.1.1.1. For those services in Table J.1.1.1, the contractor is only required to price the mandatory CLINs in the bandwidth (BW) ranges specified. For those services in Table J.1.1.1, mandatory scalable, bandwidth on demand, burstable and burstable overage CLINs are not required to be priced. For example, if the contractor chooses to price VPNS in an OCONUS country/jurisdiction, then the contractor shall price all the mandatory CLINs from VN00001 through VN00015 in that OCONUS country/jurisdiction.

Table J.1.1.1: ETS, IPS, VPNS, PLS CLIN Requirements for OCONUS country/jurisdictions

* For PLS, the contractor shall, at a minimum, propose prices from CONUS to the country/jurisdiction chosen In addition, for non-CBSA based services, the contractor shall provide and price services in the Traffic Model for all mandatory CLINs.

Non-Domestic Service Coverage This section describes service coverage requirements for non-domestic areas.

Contractors may propose any CBSA-based service to a non-domestic area even if they do not propose any of the four mandatory services (VPNS, ETS, Voice, MNS) to that non-domestic area.

The Traffic Model contains specific services in non-domestic NSCs. For each country/jurisdiction where the contractor chooses to offer services, the contractor shall:

1. Propose prices for all the mandatory CLINs in the Traffic Model in the country/jurisdiction chosen, and

2. Propose prices for all the mandatory CLINs in the non-domestic country/jurisdiction chosen, except as described in Table J.1.2.A. For those services in Table J.1.2.A, the contractor is only required to price the mandatory CLINs in the bandwidth (BW) ranges specified. For those services in Table J.1.2.A, mandatory scalable, bandwidth on demand, burstable and burstable overage CLINs are not required to be priced. For example, if the contractor chooses to price VPNS in a non-domestic country/jurisdiction, then the contractor shall price all the mandatory CLINs from VN00001 through VN00015 in that country/jurisdiction.

MTIPS is exempt from the requirements of J.1.2 (1) and J.1.2 (2) immediately above. Pricing of mandatory MTIPS CLINs is optional in non-domestic country/jurisdictions.

Table J.1.2.A: ETS, IPS, VPNS, PLS CLIN Requirements for Non-Domestic Country/Jurisdictions

* For PLS, the contractor shall, at a minimum, propose prices from CONUS to the country/jurisdiction chosen Non-domestic service is not required except as defined below. Table J.1.2.1 shows countries/jurisdictions where the contractor is required to support OCONUS and non-domestic off-net voice terminations for Internet Protocol Voice Service (IPVS), Circuit Switched Voice Service (CSVS) and Wireless Service (MWS). The contractor is also required to support IPVS and CSVS mobile terminations in the non-domestic countries/jurisdictions listed in Table J.1.2.1 except for satellite locations, which are the NONDOM locations in Table B.4.2.1 with no AOW ID.

OCONUS and Non-Domestic Countries/Jurisdictions Supporting Off-Net Voice Terminations and Non-Domestic Countries/Jurisdictions Supporting Mobile Voice Terminations Table General Services Administration

EIS RFP #QTA0015THA3003 Enterprise Infrastructure Solutions EIS RFP #QTA0015THA3003 Amendment 17 8 Enterprise Infrastructure Solutions Country/Jurisdiction

Afghanistan

Albania

Algeria

Andorra

Angola

Anguilla

Antarctica

Antigua (includes Barbuda)

Argentina

Armenia

Aruba

Ascension Island

Australia

Australian External Territory

Austria

Azerbaijan

Azores

Bahamas

Bahrain

Bangladesh

Barbados

Belarus

Belgium

Belize

Benin

Bermuda

Bhutan

Bolivia

Bosnia - Herzegovina

Botswana

Brazil

British Indian Ocean Territories

British Virgin Islands

Brunei

Bulgaria

Burkina Faso

Burundi

Cambodia

Cameroon

Canada

Cape Verde Islands

Cayman Islands

Central African Republic

Chad

Chatham Island

Chile

China

Christmas Island

Cocos Islands

Colombia

Comoros

Congo, Dem. Republic Of The

Congo, Republic Of The

Cook Islands

Costa Rica

Cote d'lvoire

Croatia

Cuba

Cyprus - North

Cyprus - South

Czech Republic

Denmark

Diego Garcia

Djibouti

Domestic: Alaska

Domestic: American Samoa

Domestic: Commonwealth of Northern Marianas Islands (CNMI)

Domestic: Guam

Domestic: Hawaii

Domestic: Marshall Islands

Domestic: Micronesia

Domestic: Midway Island

Domestic: Palau

Domestic: Puerto Rico

Domestic: US Virgin Islands (USVI)

Domestic: Wake Island

Dominica

Dominican Republic

East Timor

Easter Island

Ecuador

Egypt

El Salvador

Equatorial Guinea

Eritrea

Estonia

Ethiopia

Faeroe Islands

Falkland Islands

Fiji Islands

Finland

France

French Antilles

French Guiana

French Polynesia

French Southern Territory

Gabon

Gambia

Georgia

Germany

Ghana

Gibraltar

Global Sat

Greece

Greenland

Grenada

Guadeloupe

Guantanamo Bay

Guatemala

Guinea

Guinea - Bissau

Guyana

Haiti

Honduras

Hong Kong, Special Administrative District

Hungary

Iceland

India

Indonesia

Inmarsat Aero

Inmarsat Broadband Global Area Network (BGAN) I4-Americas

Inmarsat Broadband Global Area Network (BGAN) I4-Asia Pacific

Inmarsat Broadband Global Area Network (BGAN) I4-EMEA (Europe, Middle East, Africa)

Inmarsat Fleet (Maritime) I4-Americas

Inmarsat Fleet (Maritime) I4-Asia Pacific

Inmarsat Fleet (Maritime) I4-EMEA (Europe, Middle East, Africa)

Inmarsat Global Express (GX) I5-AOR

Inmarsat Global Express (GX) I5-IOR

Inmarsat Global Express (GX) I5-POR

Inmarsat Mini-M

Inmarsat Swift (Aeronautical) Atlantic (AOR)

Inmarsat Swift (Aeronautical) Indian (IOR)

Inmarsat Swift (Aeronautical) Pacific (POR)

Iran

Iraq

Ireland

Iridium-8816

Iridium-8817

Israel

Italy

Jamaica

Japan (includes Okinawa)

Jordan

Kazakhstan

Kenya

Kiribati

Kosovo

Kuwait

Kyrgyzstan

Laos

Latvia

Lebanon

Lesotho

Liberia

Libya

Liechtenstein

Lithuania

Luxembourg

Macau, Special Administrative District

Macedonia

Madagascar

Malawi

Malaysia

Maldives

Mali

Malta

Martinique

Mauritania

Mauritius

Mayotte Island

Mexico

Moldova

Monaco

Mongolia

Montenegro

Montserrat

Morocco

Mozambique

Myanmar

Namibia

Nauru

Nepal

Netherlands

Netherlands Antilles

Nevis

New Caledonia

New Zealand

Nicaragua

Niger

Nigeria

Niue

Norfolk Island

North Korea

Norway (includes Svalbard)

Not Available

Oman

Pakistan

Palestinian Authority

Panama

Papua New Guinea

Paraguay

Peru

Philippines

Pitcairn Island

Poland

Portugal (includes Madeira)

Qatar

Reunion Island

Romania

Russia

Rwanda

Samoa

San Marino

Sao Tome

Saudi Arabia

Senegal

Serbia

Seychelles Islands

Sierra Leone

Singapore

Slovakia

Slovenia

Solomon Islands

Somalia

South Africa

South Korea

South Sudan

Spain (includes Balearic Islands, Canary Islands, Ceuta and Malilla)

Sri Lanka

St. Helena

St. Kitts

St. Lucia

St. Pierre And Miquelon

St. Vincent And The Grenadines

Sudan

Suriname

Swaziland

Sweden

Switzerland

Syria

Taiwan

Tajikistan

Tanzania

Thailand

Thuraya Sat

Togo

Tokelau

Tonga Islands

Trinidad And Tobago

Tunisia

Turkey

Turkmenistan

Turks And Caicos Islands

Tuvalu

Uganda

Ukraine

United Arab Emirates

United Kingdom

Uruguay

Uzbekistan

Vanuatu

Vatican City

Venezuela

Vietnam

Wallis And Futuna Islands

Western Sahara

Yemen

Zambia

Zanzibar (Province Of Tanzania)

Zimbabwe

Access Arrangement Coverage This section defines access coverage requirements for both domestic and non-domestic areas.

Domestic Access Arrangement Coverage This section defines access coverage requirements for domestic areas.

Access Arrangement At a minimum, the contractor shall provide access coverage and prices for the following:

1. All NSCs within a CBSA proposed as contained in the Traffic Model.

2. All NSCs within a proposed OCONUS region that are not within any CBSAs, i.e., NSCs where CBSA=1 in the Traffic Model.

3. If an NSC has a wireline access CLIN other than OC-3c, E1 or E3 associated with it in the Traffic Model, then the contractor shall price all mandatory non-ICB wireline access CLINs, except OC-3c, E1 and E3 at that NSC (see Table B.2.9.1.5 for a list of mandatory non-ICB wireline access CLINs), and may optionally price the remaining access CLINs defined in B.2.9.1.5. If the wireline access CLIN in the Traffic Model is OC-3c, then the contractor shall price all mandatory non-ICB wireline access CLINs including OC-3c and excluding E1 and E3 at that NSC and may optionally price the remaining access CLINs defined in B.2.9.1.5. If the wireline access CLIN in the Traffic Model is E1, then the contractor shall price all mandatory non-ICB wireline access CLINs including E1 and excluding E3 and OC-3c at that NSC and may optionally price the remaining access CLINs defined in B.2.9.1.5. If the wireline access CLIN in the Traffic Model is E3, then the contractor shall price all mandatory non-ICB wireline access CLINs including E3 and excluding E1 and OC-3c at that NSC and may optionally price the remaining access CLINs defined in B.2.9.1.5.

4. If an NSC has an Ethernet access CLIN associated with it in the Traffic Model, then the contractor shall price all mandatory Ethernet access CLINs at that NSC (see table B.2.9.1.5 for a list of mandatory Ethernet access CLINs), and may optionally price the remaining access CLINs defined in B.2.9.1.5.

5. Additional NSCs beyond those contained in the Traffic Model, as requested by the government.

The contractor shall provide switched access at all NSCs as necessary to provide purchased end-to-end service. The price for switched access shall be included in the transport price for Voice Service, Toll Free Service and Circuit Switched Data Service in accordance with Section B.2 Pricing Tables. Switched access shall include, at a minimum, Telcordia Feature Group B/D (on-net and off-net) or equivalent.

Non-Domestic Access Arrangement Coverage This section defines access coverage requirements for non-domestic areas.

Access Arrangements The contractor shall price mandatory access CLINs in the Traffic Model for non-domestic NSCs. Post-award, contractors shall price access as required by the underlying transport requested.

The contractor is required to provide off-net termination at no additional cost in those jurisdictions where the contractor provides service.

Traffic Model and Core Based Statistical Areas The Traffic Model will be available within the EIS AcquServe Portal. It will represent a forecast of services by location of the agencies’ expected use of the EIS contract. The Traffic Model contains information such as Service ID, CLIN, Originating NSC, Terminating NSC, Quantity, Originating CBSA, and Terminating CBSA. Prices from the contractor’s Section B price tables will be “multiplied” by the Traffic Model to determine the Total Evaluated CBSA Price (TECP) for each service within each CBSA.

A list of CBSAs, sorted in order based on the aggregated bandwidth requirements, will be available in the EIS AcquServe Portal. Table J.1.4.1 lists the top 100 CBSAs. An NSC is associated with a CBSA based on its county. For NSCs that do not fall into a CBSA naturally based on its county, the following methodology is used for the Traffic Model, and will be used post-award to associate an NSC with a CBSA.

If an NSC’s county does not fall within a CBSA, then:

Find the county within a CBSA and within the same state that is closest to the county of that NSC.

Assign the NSC to that CBSA.

Note: Non-CBSA Counties are associated with the closest CBSA County within the same State, using GPS coordinates found in the 2010 U.S. Census National Counties Gazetteer file (https://www.census.gov/geo/maps-data/data/gazetteer2010.html).

Top 100 Government Bandwidth CBSAs Table

Contractor Data Interaction Plan Introduction This section details the requirements for common operations, process flows, data exchange details, and deliverables for various management and operation functions such as ordering, billing, inventory management, and SLA Management. It provides details on data interactions between the contractor, GSA and the customers. It includes requirements for direct interaction between GSA's next-generation network solutions management system (GSA Conexus), and the contractor's Business Support System (BSS) as described in Section G.5. It also includes requirements for contractor interaction with the set of tools used by GSA to manage the contract and TOs issued under the contract (GSA Systems).

For related management and operations functional requirements, see Section G Contract Administration Data.

The diagram in Section J.2.1.1 shows the high-level process flow relating to the acquisition/TO, ordering, billing and inventory management life cycle.

EIS Management and Operations: High-Level Process Diagram

Timeframes Unless otherwise specified in the detailed requirements below, all timeframes in this Contractor Data Interaction Plan (CDIP) are in calendar days.

Common Data Interaction Requirements Relevant Contracting Officer Where permitted by the applicable section within the CDIP, exceptions to CDIP data submission requirements may be authorized, in writing, by the relevant Contracting Officer (CO). For these purposes, the relevant CO is defined as follows:

· For data submitted to GSA, the GSA CO is the relevant CO

· For data submitted to a customer, the Ordering Contracting Officer (OCO) is the relevant CO Resubmission of Incorrect Deliverables Unless specifically stated otherwise, if the contractor becomes aware of an error in a previously submitted deliverable, regardless of how it became aware of the error, the contractor shall:

1. Resubmit the deliverable within three (3) days of becoming aware of the error with the exception of billing errors identified after the government makes payment, which requires the submission of a billing adjustment as described in Section J.2.5 Billing.

2. Notify the relevant Contracting Officer’s Representative (COR) and CO via email of the error and the action taken.

Deliverable Format, Content, and Transfer Mechanism Unless otherwise specified, all contractor deliverables in the CDIP are governed by the following requirements:

· For deliverables submitted directly to GSA, including cases where GSA receives a copy of a deliverable sent to the customer, the contractor shall use the format, contents, and transfer mechanism specified herein unless an exception is authorized by the GSA CO (see also Section J.2.2.1 Relevant Contracting Officer and Section J.2.9 Data Transfer Mechanisms).

· For deliverables submitted directly to the customer, including cases where the customer receives a copy of a deliverable sent to GSA, the contractor may, with the approval of the OCO, use alternative formats, contents, and/or transfer mechanisms (see also Section J.2.2.1 Relevant Contracting Officer and Section J.2.9 Data Transfer Mechanisms). The TO may also specify alternative formats, contents, and/or transfer mechanisms for deliverables submitted to the customer.

Scope of Deliverables Unless otherwise specified, the contractor shall submit all deliverables in accordance with the following deliverable scope requirements:

· The scope of all deliverables shall be at the TO level with each deliverable covering only a single TO.

· For deliverables submitted directly to GSA, including cases where GSA receives a copy of a deliverable sent to the customer, exceptions may be authorized by the GSA CO (see also Section J.2.2.1 Relevant Contracting Officer).

· For deliverables submitted directly to the customer, including cases where the customer receives a copy of a deliverable sent to GSA, exceptions may be authorized by the OCO or captured directly in the TO (see also Section J.2.2.1 Relevant Contracting Officer).

Task Order Data Management Task Order data management consists of initial setup and ongoing maintenance of TO data in GSA Conexus and the contractor's BSS. It begins immediately after the TO is issued (See Section G.3.2 Task Orders) and extends for the life of the TO.

TO data management covers three categories of data that GSA Conexus and the contractor's BSS require to allow effective data exchange between the contractor and the government.

1. Task Order Controlled Data – This data is contained in the TO or directly tied to it and can only change via a TO modification (See Section G.3). It includes, but is not limited to:

· TO documents

· TO-defined customer officials: OCO as defined Section G.2.2.1.1

· Services specified on the TO

· TO-Unique CLINs (TUCs) and Individual Case Basis (ICB) data

· TO-unique Key Performance Indicators (KPIs) and Service Level Agreements (SLAs)

· Other customer data specified on the TO Task Order Associated Data – This data is not typically contained in the TO and can change at any time during the life of the TO. This data includes:

· Additional TO Customer Officials not defined in the TO

· Role-Based Access Control (RBAC) information System Reference Data – These are universally applicable reference tables used to ensure both GSA Conexus and the contractor's BSS are using consistent codes for common transactional data. System reference data can only be modified by GSA. Examples include:

· Technical features such as Access Circuit Type and Bandwidth

· Business features such as Agency Bureau Codes and Dispute Reasons

· Status features such as Yes/No and True/False codes Common Operational Requirements The following are common operational requirements relating to contractor account management.

GSA Systems GSA Systems is the set of tools used by GSA to manage the contract and TOs issued under the contract. The contractor shall submit data via GSA Systems as specified in Section J.2.3.2 Task Order Data Management Process.

Role-Based Access Control As specified in Section G.5, the contractor shall provide Role-Based Access Control (RBAC) to allow only authorized users with appropriate permissions access to its BSS, including but not limited to, the ability to place orders and research order, billing, inventory, and performance information.

The contractor shall capture and store the authorized users for restricted access and restrict all information so that only the authorized users have access to this information. The contractor shall add new users within seven (7) days of customer request. The contractor shall remove any user who is no longer authorized within one (1) business day of notification or sooner if the situation requires.

Task Order Data Management Process This section describes two TO data management processes for 1) System Reference Data and 2) Task Order Data. All deliverables and other data sets for these processes are further defined in Section J.2.3.3 Deliverables and Data Exchange.

System Reference Data The contractor shall follow the process described below after the contractor’s BSS has successfully completed verification and security testing as described in Section G.5 Business Support Systems and Section E.2.1 Business Support Systems Verification Testing, and as required by changes to the data. Changes may be caused by contract modifications and BSS changes approved by GSA in accordance with Section G.5. The contractor shall complete this process prior to setting up its first TO, as described in Section J.2.3.2.2 Task Order Data.

1. GSA will provide system reference data to the contractor using the data sets defined in Section J.2.3.3.1 Government-Provided Data: System Reference. GSA will provide updates to the system reference data sets on an as needed basis. A contract modification will not be issued for such updates.

The contractor shall configure its BSS to submit data based on the provided system reference data.

Task Order Data The contractor shall follow the process described below for each TO at initial TO setup prior to processing any orders for service as described in J.2.4 Ordering and as required by changes to the data. Changes may be caused by:

· Issuance of TO modifications

· New information from the customer (for data not defined in the TO)

· BSS changes approved by GSA in accordance with Section G.5

· Changes to the reference data as described in Section J.2.3.2.1 The contractor shall follow all process steps at initial setup of each TO, and shall complete this process prior to provisioning or providing any services under the TO.

Subsequent updates may omit submission of data sets where no changes have occurred unless directed otherwise by the GSA CO.

Process Steps:

1. The contractor shall submit the following deliverables to GSA:

1. TO Services Awarded / TO CLINs Awarded

1. TO Country/Jurisdiction Awarded By Service / TO Locations Awarded by Service

1. TO Officials

1. TO Customer Requirements Document Set

1. TO Financials

1. TO Key Performance Indicators The contractor shall collect from the customer the list of users and user permissions for RBAC.

The contractor shall set up or modify appropriate RBAC permissions within its BSS as described in Section G.5 Business Support Systems.

The contractor shall submit the Direct Billed Agency Setup (DBAS) to GSA.

Updates to this data will follow the same process.

Deliverables and Data Exchange Government-Provided Data: System Reference The following table lists the reference data sets the government will provide as part of this process. Detailed contents of each data set are in Section J.2.10.2 Data Set Content. For each data set, the contractor shall support all required transfer mechanisms as defined in Section J.2.9 Data Transfer Mechanisms.

Reserved Contractor-Provided Data Sets: Deliverables The following table lists the deliverables the contractor shall provide as part of this process. Detailed contents of each data set are in Section J.2.10.2 Data Set Content. For each data set, the contractor shall support all required transfer mechanisms as defined in Section J.2.9 Data Transfer Mechanisms.

Ordering As described in Section G.3 Ordering, orders for service may be 1) defined in the TO, or 2) defined separately after the issuance of the TO.

Common Operational Requirements Task Orders The TO process is described in Section G.3 Ordering. Once a TO is issued, the contractor shall follow the process described in Section J.2.2.4 Task Order Data Management.

If the TO directly includes an order for services, the requirements and processes described in the remainder of this section (J.2.4 Ordering) apply to that order for service as well as to any subsequent orders for service under the TO.

If the TO does not directly include an order for services, the requirements and processes described in the remainder of this section (J.2.4 Ordering) do not apply to the processing of the TO, but do apply to all subsequent orders for service under the TO.

Agency Hierarchy Code The Agency Hierarchy Code (AHC) is an internal government accounting code that shall be tracked for all services from order submission through disconnection. The government has the following AHC requirements for ordering:

1. An AHC is required on each line item in all orders.

1. The contractor shall validate the presence of an AHC on all order line items:

1. The government will not pay for orders processed without an AHC on each line item

1. The government does not require validation of the content of the AHCs unless specified on the TO The contractor shall support AHC changes to provisioned services without an interruption of the associated service (see J.2.4.2.3 Administrative Change Orders).

Unique Billing Identifier The Unique Billing Identifier (UBI) uniquely identifies one item or multiple items linked together for ordering, billing and inventory management purposes (see Section J.2.10.1.1.2 Unique Billing Identifier). The government has the following UBI requirements for ordering:

1. The contractor shall create the UBI as described in Section J.2.10.1.1.2.

1. The contractor shall provide the UBI as a data element in the Service Order Completion Notice (SOCN).

Agency Service Request Number The Agency Service Request Number (ASRN) is an optional internal government control number that shall be tracked for all services from order submission through disconnection if it is provided. The government may elect to assign zero, one or two ASRNs to each line item in a given order. If the government provides ASRN data element(s) as part of a Service Order (SO), the contractor shall include them on all deliverables that reference that order or the services included in that order.

Contract Line Item Number Each orderable element is identified by a Contract Line Item Number (CLIN), which may be associated with a case number. The government has the following CLIN requirements for ordering:

1. The contractor shall provide the CLIN and any associated ICB data element(s) for each line item in all ordering deliverables as required in Section J.2.4.3.2 Contractor Provided Data Sets: Deliverables.

1. The contractor shall ensure the CLINs reported on billing files match those included on the SOCN for a particular order.

Ordering Data Sets and Notices The government and the contractor exchange several data sets as part of the ordering process.

· The delivery process, frequency, timing and detailed specifications for each are captured in subsequent sections.

· The TO can override the deliverable timing provided that both:

· The notices remain in the order specified in the applicable process section under Section J.2.4.2 Ordering Process

· All required notices are delivered prior to billing The standard data sets are defined below:

· Service Order (SO): Provides the contractor with the required details of the government's order for service.

· Service Order Acknowledgement (SOA) Deliverable: Notifies the government its order for service has been received.

· Service Order Confirmation (SOC) Deliverable: Notifies the government that the order for service information is sufficient to process and has been issued.

· Service Order Rejection Notice (SORN) Deliverable: Notifies the government that the order for service information is insufficient or otherwise invalid and that the order cannot be processed.

· Firm Order Commitment Notice (FOCN) Deliverable: Notifies the government of the Firm Order Commitment (FOC) date when the contractor is committed to delivery of the ordered service.

· Service Order Completion Notice (SOCN) Deliverable: Notifies the government that service has been installed and/or activated (“turned up”). The order for service has been completed and billing starts as of the included completion date.

· Service Order Administrative Change (SOAC) Deliverable: Notifies the government that an administrative change has been completed and provides details of the change.

· Service State Change Notice (SSCN) Deliverable: Notifies the government that a UBI has changed state (e.g., an auto-sold CLIN has been activated).

Auto-Sold CLINs In accordance with Section G.3.3.1.2 Auto-Sold CLINs, the government has the following auto-sold CLIN requirements for ordering:

1. The contractor shall include any auto-sold CLINs in all notices and deliverables that require reporting CLINs

2. Unless otherwise specified in the SO or TO, the contractor shall apply the AHC listed for the base CLIN to all associated auto-sold CLINs

3. Unless otherwise specified in the SO or TO, the contractor shall apply the ASRN(s) listed for the base CLIN to all associated auto-sold CLINs

4. The contractor shall manage activation and deactivation of auto-sold CLINs in accordance with Section J.2.4.1.10 Service State and Section J.2.4.2.5 Service State Changes Order Types Each order submitted by the customer will have an overall order type and each line item will have a line item order type. Order types are defined in Section J.2.10.1.1.4.

Splitting Complex Orders into Suborders An order submitted by the customer may contain multiple line items for unrelated services, or otherwise require provisioning efforts that are not logically related. Upon confirmation of such an order, the contractor may split the order into logical suborders using its standard provisioning process with the following restrictions:

1. Services logically linked by a Service Grouping ID as described in Section J.2.10.1.1.2 Unique Billing Identifier, shall not be split across multiple suborders

2. The contractor shall not split any SO into suborders if the SO or the TO contains instructions prohibiting such splitting Service State Each provisioned service, defined by a single UBI, is always in one of the following states:

· Active:

· The UBI is active with charges accumulating

· Other than auto-sold and band-priced CLINs, most UBIs will be in this state from provisioning to disconnection

· Other than auto-sold, usage-priced CLINs are in this state if available for use

· Inactive:

· The UBI is inactive with no charges accumulating

· Does not apply to disconnected services

· Band_Name:

· Only valid for UBIs based on band-priced CLINs

· The band-priced UBI is in the band listed

· The value to be provided as the UBI state is defined by combining the Band Low and Band High values from the associated Section B table separated by a single colon. For example, if the Band Low value is 10 and the Band High value is 100, the UBI state is 10:100.

The government has the following Service State requirements:

1. The contractor shall ensure that all provisioned UBIs have a valid service state assigned at all times:

1. A UBI is not considered provisioned prior to the SOCN for its installation

1. A UBI is not considered provisioned after the SOCN for its disconnection

2. The contractor shall not change the service state of a UBI except in response to direct government action (e.g., beginning or ending the use of an auto-sold CLIN) or as required based on predefined criteria captured in the contract or the TO.

See also Section B.1.2.11 Auto-Sold CLINs and Section B.1.2.4 Price Banding Structures.

Ordering Process All deliverables and other data sets included in the processes below are defined in Section J.2.4.3 Deliverables and Data Exchange. Unless otherwise specified, the contractor shall submit all deliverables in the process below to GSA and, if requested, to the customer.

Standard Orders Standard orders, including moves, adds, changes (excluding administrative change orders), and disconnect orders, shall follow the process below (order updates are addressed in Section J.2.4.2.6):

1. The government will issue an SO.

2. The contractor shall submit an SOA within one (1) business day of SO.

3. If the contractor determines that the SO is invalid, the contractor shall submit a SORN within five (5) days of SO:

1. A SORN submitted by the contractor shall apply to the entire order (i.e., the contractor may only reject entire orders, not individual line items)

1. In the event of order rejection, the government may issue a new SO with the corrected information and restart this process

4. If the contractor determines that the SO is valid, it shall submit a SOC within five (5) days of SO.

5. The government may modify or cancel the order during the provisioning process as described in Section J.2.4.2.6 (see also Section J.2.10.1.1.4.3 and Section G.3.3.2.3).

6. If the contractor chooses to split a complex SO into suborders as described in Section J.2.4.1.9, the contractor shall follow the remainder of this process for each suborder including submitting separate deliverables for each suborder.

7. If the contractor must obtain local access services, the contractor shall submit a FOCN indicating its FOC date within one (1) business day of receiving the FOC date from the local provider.

8. If the contractor does not need to obtain local access services, the contractor shall submit a FOCN indicating its FOC date NLT the earlier of: 1) 5 days after SOC, or 2) 10 days before the FOC date.

9. Upon completion of the order, the contractor shall submit a SOCN within three (3) days of installation and testing unless otherwise specified in the TO.

10. If the government reports a problem within the acceptance period defined in Section E, Inspection and Acceptance (or as specified in the TO), the contractor shall fix, test, and submit a new SOCN.

Telecommunications Service Priority Orders If the government submits a Telecommunications Service Priority (TSP) order as described in Section G.3.3.3.1 Telecommunications Service Priority Orders, the standard process (see Section J.2.4.2.1) shall apply with the following caveats:

1. The contractor shall follow the prioritizations applicable to TSP orders as noted in Section G.3.3.3.1 Telecommunications Service Priority Orders and/or Section G.11 National Security and Emergency Preparedness.

1. The contractor shall not delay the delivery of services in any way based on the need to submit deliverables specified in this process.

Administrative Change Orders Administrative data changes to previously provisioned services, as described in Section G.3.3.2.2.4 Administrative Change Orders, shall be handled based on the restrictions and process in the subsections below.

Administrative Change Restrictions As described in Section G.3.3.2.2.4, administrative change orders may only modify inventory data points provided by the government that have no impact on service delivery or pricing. Only the following fields fall into this category by default:

· Agency Service Request Number 1

· Agency Service Request Number 2

· Agency Hierarchy Code Additional data elements can be subject to administrative change orders on a contract-wide or case-by-case basis with the mutual agreement of the contractor and the GSA CO.

Administrative Change Order Process Note: unless otherwise specified, the contractor shall submit all deliverables described in the process below to GSA and, if requested, to the customer:

1. The government will issue an Administrative Change Order specifying the inventory items to be changed and details of the change.

1. The contractor shall update its systems and submit a SOAC within seven (7) days of the Administrative Change Order.

1. Other order notices (SOA, SOC, FOCN, and SOCN) are not required.

Rapid Provisioning Certain services lend themselves to rapid provisioning as described in Section G.3.3.3.2 Rapid Provisioning Orders. In these cases, the government has streamlined its required process.

Note: this section does not apply to the activation of auto-sold CLINs (see Section J.2.4.2.5 Service State Changes).

Subject to the restrictions described in Section G.3.3.3.2, the contractor shall follow the standard process (Section J.2.4.2.1) with the following changes:

1. The SOC and the FOCN are not required.

1. If the contractor completes the provisioning process and issues a SOCN within twenty-four (24) hours of order submission, the SOA is not required.

1. If the contractor rejects an order, the SORN must be issued prior to the end of the defined provisioning interval.

1. The government’s option to modify or cancel the order during the provisioning process is subject to the restrictions noted in Section G.3.3.3.2 Rapid Provisioning Orders.

Service State Changes If a service (defined by a single UBI) changes from one state to another (as defined in J.2.4.1.10 Service State), the contractor shall issue a SSCN within 24 hours. The contractor may combine multiple notices as individual line items on a single SSCN provided all notices are submitted within 24 hours of the individual state change.

Supplements or Updates to In-Progress Orders If it is necessary to supplement or update an in-progress order as described in Section G.3.3.2.3 Updates to In-Progress Orders, the government will issue a supplement SO (see also Section J.2.10.1.1.4.3). Note: Changing data explicitly included in a TO requires a TO modification, and cannot be done via this process (see Section G.3.2.2 Task Order Modification).

In such cases, the following process shall be used:

1. The government will issue a supplement SO.

2. The contractor shall submit an SOA in response to the supplement SO within one (1) business day:

· The Contractor Service Request Number (CSRN) reported on the SOA shall be the same as that reported on the original order

· Note: TSP (Section J.2.4.2.2) and Rapid Provisioning (Section J.2.4.2.4) orders may have shorter submission times as defined in the applicable section

3. If the contractor determines that the supplement SO is invalid, the contractor shall submit a SORN in response to the supplement SO within three (3) days of the supplement SO:

· The CSRN reported on the SORN shall be the same as that reported on the original order

· Note: TSP (Section J.2.4.2.2) and Rapid Provisioning (Section J.2.4.2.4) orders may have shorter submission times as defined in the applicable section

4. The contractor shall update the original order with the new data.

5. If any changes are required to data sets already submitted in response to the original order (e.g., SOC, FOCN), the contractor shall issue updated versions of those notices.

6. The contractor shall complete the provisioning of the original order with updated information as described in the applicable order process:

· Section J.2.4.2.1 - Standard Orders

· Section J.2.4.2.2 - Telecommunications Service Priority Orders

· Section J.2.4.2.4 - Rapid Provisioning Orders Deliverables and Data Exchange Government-Provided Data Sets The following table lists the data sets the government will provide as part of this process. Detailed contents of each data set are provided in Section J.2.10.2 Data Set Content. The contractor shall support all required transfer mechanisms for each data set as defined in Section J.2.9 Data Transfer Mechanisms.

Email Other means as per the TO

Email Other means as per the TO

Contractor-Provided Data Sets The following table lists the deliverables the contractor shall provide as part of this process. Detailed contents of each data set are provided in Section J.2.10.2 Data Set Content. The contractor shall support all required transfer mechanisms for each data set as defined in Section J.2.9 Data Transfer Mechanisms.

Email (if requested by the customer) Contractor’s Web Interface Other means as agreed or required in the TO

Email (if requested by the customer) Contractor’s Web Interface Other means as agreed or required in the TO

Email (if requested by the customer) Contractor’s Web Interface Other means as agreed or required in the TO

within one (1) business day of receiving FOC date Local access subcontractor not required:

NLT the earlier of 5 days after SOC or 10 days before the FOC date Web Services Email (if requested by the customer) Contractor’s Web Interface Other means as agreed or required in the TO

Email (if requested by the customer) Contractor’s Web Interface Other means as agreed or required…