LTE GNG (Full) Requirements, Testing Process

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

ATT-950-010-062 IPTV : LTE GNG (Full) Requirements, Testing Process and KPI Requirements Abstract: Audience: Region(s): Center(s): Effective Date: Published :

Issue 1, 03/28/12

Expires On: Related Documents:

Reference to related documents found within the pages of this document

Issuing Department: Business Unit: Points Of Contact:

See Contact List.

Author(s): David Bhatta ATTUID db694h

AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. ©2012 AT&T Intellectual Property. All rights reserved. i

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

Table Of Contents INTRODUCTION General Reason For Current Issue 1.

About This Document 1.1. Purpose 1.2. Scope 1.3. Intended Audience 1.4. Related Documentation 1.5. Acronyms and Terms 1.6. Trademarks 1.7. Contacts 2. Scope and Goal 2.1. What is New in this Document Version? 2.2. Document Roadmap 3. Key Concepts, Requirements and Terminology 3.1. Key Terms 3.2. Other Key Terms 4. Pre-Optimization Activities 4.1. Responsibilities 4.2. Cluster Drive Route Definition and Approval Process 4.2.1. Drive Route Polygon Definition 4.2.1.1. Multiple Bands, Multiple Bandwidth Allocations, and Multiple Carrier

2 2 3 3 3 4 4 4 5 7 7 8 8 10 11 11 11 11 12

Considerations

4.2.1.2. Drawing the Drive Route Polygon 4.2.2. Drive Route Polygon Outputs 4.2.3. Cluster Drive Route Selection Requirements 4.2.4. Drive Route Outputs 4.3. IFHO Drive Route Selection requirements 4.3.1. IFHO Boundary Selection 4.3.2. IFHO Drive Route Requirements 4.3.3. IFHO Drive Route Outputs 4.4. IRAT Drive Route Selection Requirements 4.4.1. IRAT Boundary Selection AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. ©2012 AT&T Intellectual Property. All rights reserved. ii

12 17 18 19 20 21 21 21 22 23

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

4.4.2. IRAT Drive Route Requirements 4.4.3. IRAT Drive Route Outputs 4.5. Approval Process for Drive Routes, Polygons, IRAT, and IFHO Routes 4.5.1. Instructions for HQ Submission Package: 4.6. Other Prerequisites 5. GNG Cluster Drive Collection Process and Requirements 5.1. Drive Route Key Concepts and Requirements 5.2. Responsibilities 5.3. Drive Test Hardware 5.3.1. Drive Test Equipment Requirements 5.3.2. Drive Test General Guidelines 5.3.3. Drive Test Equipment Calibration Requirements 5.3.3.1. Equipment Calibration Requirements 5.3.3.2. Scanner Antenna and Cable Testing 5.3.4. Cluster GNG Drive Test Configuration 5.3.4.1. Four possible configurations are listed in the table below: 5.3.4.2. Drive Test Equipment List and Configuration: refer to GNG Full Test

23 23 24 25 27 27 27 27 28 28 28 29 30 30 31 31 31

Configuration document.

5.3.5. UE Equipment 5.3.6. Drive Test Scripts 5.4. Testing Journal Requirements 5.5. Cluster Drive Requirements 5.5.1. Driving into Adjacent LTE Clusters – When Required 5.5.2. Inaccessible Drive Routes 5.6. Log File Naming Convention 5.7. Pre and Post Drive Checks Required 5.7.1. Pre-Drive Checks 5.7.2. Post-Drive Checks 5.8. Drive Collection Job Aid 6. IFHO and IRAT Drive Collection Process and Requirements 6.1. Responsibilities 7. LTE GNG Full Testing: Commercial vs. Non-Commercial Networks 7.1. Traditional Pre-Commercial Launch GNG Full Testing 7.2. GNG/Full Testing in a Launched (Commercial) Network 8. Drive Test Data Processing and KPI Requirements AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. ©2012 AT&T Intellectual Property. All rights reserved. iii

32 33 33 34 34 34 35 35 35 36 36 36 36 36 37 37 37

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

8.1. Drive Test Processing Concepts and Key Requirements 8.2. Responsibilities 8.3. GNG Processing Software 8.4. Drive Data Log File Requirements – Maximum Measurement Window 8.5. Site/Cell Configuration Documentation 8.6. GNG Cluster Drive KPIs and Methods 8.6.1. GNG Drive Cluster KPIs 8.6.2. KPI Implementation in ActixOne Platform 8.6.3. Cell Aggregation Method 8.7. Exclusion Zones 8.8. GNG KPI Report 8.8.1. Contents of KPI Report Template 8.8.1.1. GNG KPI Report Parameter Audit 8.8.1.2. Serving Cells Audit 8.8.2. IFHO Tab 8.8.3. IRAT Tab 8.9. Uploading Drive Log Files to Server for GNG KPI Report Generation 8.10. GNG Processing Job Aid 8.11. GNG Drive Cluster Acceptance Criteria 9. Results Review and Approval Process 9.1. Responsibilities 9.2. Package Requirements to be Submitted for Review and Approval 9.3. GNG KPI Drive/Cluster Approval Requirements 9.3.1. Drive Routes & Drive Route Polygon Verification 9.3.2. Standard Cluster (10 to 30 sites) Requirements 9.3.3. Small Cluster (3 to 9 sites) Requirements 9.3.4. BAU/SSV Requirements 9.4. IFHO and IRAT Approval Requirements 9.5. Outputs and Notification of GNG KPI Approval Process 10. Incremental Sites BAU Process 10.1. Incremental Sites Process Flowchart 10.2. Pre-launch Activities 10.3. GNG Team Approval Process 10.4. Link to the PMO Organization web-based checklist 10.4.1. Sample of Web-based checklist AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. ©2012 AT&T Intellectual Property. All rights reserved. iv

37 38 38 38 39 39 39 45 45 46 46 46 46 46 47 47 47 47 47 47 48 48 48 48 49 49 49 49 49 49 49 50 51 52 52

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

11. References 12. Appendix A – Cluster Naming Convention for Polygons and Drive Routes 12.1. General Cluster Naming Convention 12.2. File Naming Convention for polygons and Drive Routes 12.3. Sub-Market Codes 13. Appendix B – 3 dB Coverage Rule Comparison 14. Appendix C – Testing Journal Template 15. Related Documents 16. Acknowledgements 17. Contact List A.1. Document Specific Acronyms A.2. Acronyms Dictionary Revision Log ACRONYMS

AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. ©2012 AT&T Intellectual Property. All rights reserved. v

53 53 54 55 56 59 61 62 62 63 63 63 63 63

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. ©2012 AT&T Intellectual Property. All rights reserved. vi

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

General All Methods and Procedures in this document adhere to AT&T’s competition policy which includes compliance with the section 272 (e)(1) parity service requirements with respect to exchange and exchange access services, and employees are reminded to consult with Legal regarding any section 272(e)(1) issues or questions. Section 272(e)(1): A Telco shall fulfill any requests from an unaffiliated entity for telephone exchange service and exchange access within a period no longer than the period in which it provides such telephone exchange service and exchange access to itself or to its affiliates.

Reason For Current Issue Issue Number

Date

Description

1

03/28/12

Published By db694h

Authors set the change indicators in documents for important changes. Not all changed information may have been selected by the author.

INTRODUCTION Document Number-TBD Rev. 1.3 draft 1 12/12/2011 Overview This document covers guidelines and requirements that form the basis for LTE Go No GO Approval process used by AT&T Radio Access Network organization. Covered within this document are pre-launch activities, steps necessary for pre-launch network optimization, cluster drive requirements, and post processing of drive data as well as the generation of GNG report. Activities deemed secondary to the main focus of this document are given a more detailed treatment in separate documents referred to herein as ‘Job Aid’. References and links to Job Aid documents are provided wherever necessary. Document Revision History This table identifies content revisions made to this document.

Date

Rev

7/19/2010

0.1

8/30/2010

1

Revision Description

Writer

Sponsor

Original

Colin Bowdery

Shane Morrison

Beta Release

Colin Bowdery

Shane Morrison

AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. 2012 AT&T Intellectual Property. All rights reserved. 1

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

Date

Rev

12/31/10

2

1/4/2011

D01

3/8/2011

Revision Description Version 1 Release

Writer

Sponsor Shane Morrison

Colin Bowdery

Draft #1 Development – restructured Craig Palmer and reorganized.

1.1D16 Added feedback from vendor

Craig Palmer

4/19/2011

1.2

Update the GNG full document based Ye chen, Craig Palmer, Shane on the internal discussion and the Morrison, Cheng Zhang testing in the commercial network

4/22/2011

1.3

Added KPI table, provided descriptions for various sub headings

11/14/11

1.3

Added Incremental Sites BAU ProcDavid Bhatta ess

Craig Palmer/David Bhatta

Orlando Davila Orlando Davila

RACI This table identifies RACI team members.

Accountable

Responsible

Consulted

Informed

Gordon Mansfield

Shane Morrison

Ye Chen, Pradeep Kunjunny, Paul Hartman, Hany Fahmy Gram Lekutai

Florian Ion

Craig Palmer

Nick Thompson

Kevin Hetrick

Orlando Davila

Erik Holmberg, Oscar Muhammad Gill, Lou Ficarra, Nico Vlok, Garcia, Julius Fodje, RobBill Weise ert Clark

1. About This Document This document outlines the RF requirements and approval process for launching AT&T’s LTE network and serves as a guideline to LTE infrastructure vendors and market RF teams in assessing the network performance and helps them reach a Go No-Go decision.

1.1. Purpose AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. 2012 AT&T Intellectual Property. All rights reserved. 2

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

The main purpose of the document is to outline the process for GNG approval of LTE cluster or super cluster and to provide guidelines and requirements for assessing the launch readiness of AT&T’s LTE network.

1.2. Scope This document outlines requirements and guidelines for LTE GNG process which will be utilized by markets and infrastructure vendors for assessing LTE clusters and/or super clusters. The document is intended for use as a guideline for LTE launches. It is not intended to be used as a contract or a detailed engineering design or optimization guideline. Detailed information as to test equipment and test procedures is left out of this document so as to keep the size of the document manageable. Furthermore, this document does not outline the end to end launch processes and must be followed in conjunction with other processes and requirements provided by NPMO organization.

1.3. Intended Audience The intended audience for this document includes:

•

Market RAN – to understand the GNG process and respective market responsibilities

•

HQ RAN – to use GNG KPI results in making approval decisions.

•

OEM Vendors – To understand the GNG process, data collection requirements and documentation, and report generation.

•

PMO - process and results tracking.

1.4. Related Documentation The following are related documents:

LTE GNG Data Analysis Process (aka “ATT LTE GNG AcLink: ActixOne Cookbook tixOne Cookbook”) LTE RF Network Design Guidelines: ND-00369

Link: ND-00369

LTE GNG Full Drive Test Configuration

Link: Test configuration document

LTE GNG full KPI implementation document titled AT&T Link: LTE GNG Metrics Description LTE GNG Metrics Description Drive Log Processing Procedure

Link: Drive Log Processing Job Aid


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

LTE Drive Route Template for HQ Submission Package

Link: Drive Route Template

Parameter audit

ALU Version (*see below)

Parameter audit

Ericsson Version (**see below)

* ALU Version RAN - ALU LTE LA3 0 Gold Standard.xlsx You may download this file from the online version of this document. Note: You must have the proper application in order to open the file. **Ericsson Version RAN - Ericsson UMTS Gold Standard.xlsx You may download this file from the online version of this document. Note: You must have the proper application in order to open the file.

1.5. Acronyms and Terms The table below includes acronyms and terms are used in this document. Please note additional GNG specific terminology are defined and explained in a later section of this document.

CM

Configuration Management

eNB

eNode B

GNG

Go-No-Go

HQ

Head Quarters

KPI

Key Performance Indicator

LTE

Long Term Evolution

PM

Performance Management

RAT

Radio Access Technology

RYG

Red, Yellow, Green

1.6. Trademarks The trademarks used in this document are the property of their respective owners.

1.7. Contacts AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. 2012 AT&T Intellectual Property. All rights reserved. 4

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

For questions or comments about this document's technical content or to request changes to the document, contact:

Orlando Davila Desk: 847-765-3601 Wireless: 847-910-8000 E-mail: [email protected]

Ye Chen Desk: 847-248-8030 Wireless: 404-213-6985 E-mail: [email protected]

2. Scope and Goal The goal and focus of this document is to present the GNG Drive Testing and KPI process (one component of “Element Acceptance”) in Attachment H of the LTE contract (See diagram below). The scope of this document is directly related to cluster GNG KPIs testing.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

Given this specific scope, the following are considered outside the scope of this document and are covered in separate processes and/or documents:

•

Pre-Launch Checklist (Formal approval on un-bar)

•

Installation Acceptance (as outlined in Attachment H)

•

Retainability and Stability Period (as outlined in Attachment H)

•

Post-Launch Support

Relationship with GNG-Lite Process and Lite-Launch Clusters: Due to competitive reasons, AT&T may choose to unbar a subset of sites in a cluster prior to the GNG KPI testing covered in this document. When this is done, a separate process, GNG-Lite, will be used to validate adequate performance of those sites prior to launch. The term, “Lite-Launch(ed) Cluster” is used to denote clusters which have one or more sites launched in under GNG-Lite. Even in clusters launched under GNG-Lite, the formal GNG KPI requirements and process outlined in this document must be performed and met before “Element Acceptance” can be considered complete for the cluster. The term, “GNG/Full,” is sometimes used to distinguish this formal GNG process vs. GNG-Lite.

NOTE: Achieving “Green GNG KPI’s” is a prerequisite for an approval to unbar and launch a cluster. Green GNG KPIs do not constitute approval to launch and unbar a cluster for commercial service. In order to launch and unbar a cluster (or multiple clusters), a separate launch approval process is utilized using a comprehensive “pre-launch AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. 2012 AT&T Intellectual Property. All rights reserved. 6

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

checklist.” The GNG KPI results and GNG KPI approval (scope of this document) is one of many inputs into the pre-launch checklist when making the decision to unbar and provide commercial service.

2.1. What is New in this Document Version? This is the initial release of this document. Version 1.2:

•

Revised Drive Route Polygon Process

•

The test methodology options for conducting LTE GNG full testing in a commercial network

•

Added KPIs for drive testing conducted in a live commercial network

•

Enhanced update on the 3dB coverage comparison and the normalization factors for LTE RSRP

•

Updates based on the internal discussion within AT&T

•

Updates based on the discussion with drive test tool vendor Anite and the post-processing vendor Actix

The latest version is 1.3 and includes the following:

•

Document overview

•

Purpose

•

Contact update

•

Scope

•

KPI Table

•

Incremental Sites BAU Process

2.2. Document Roadmap This section summarizes planned updates to this document. The next version(s) of this document are expected to include:


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

•

CSFB Requirements and KPI revision (if deemed necessary).

3. Key Concepts, Requirements and Terminology The key concepts and requirements for GNG testing are as follows:

•

GNG Cluster Drive tests will be conducted in each and every cluster and must pass GNG KPIs as part of the contractual Element Acceptance Process (see Scope and Goal section of this document).

•

GNG Cluster drives and KPI evaluations are conducted on a cluster basis, not on a super cluster basis.

•

Only the specific equipment listed in the document shall be used to conduct formal GNG testing.

•

PAYG must be disabled during GNG testing and shall not be enabled until the cluster is approved as “GNG Green”.

•

OCNS

Footnote:

The generic term “OCNS” will be used in this document which follows the terminology in Attachment H. Vendors may call their OC

must be set to 50% load for all GNG Cluster Testing.

3.1. Key Terms

Cluster

A cluster is a collection of contiguous LTE sites which is defined as part of the RF Design process. A site can only belong to one cluster and once a site is assigned to a particular cluster during the design, it shall not be assigned to another cluster. A cluster covers a contiguous geographic area. Furthermore, a cluster is composed of sites of the same LTE bandwidth and frequency band. Contractually, cluster size ranges from 10 to 30 sites with the recommended average of 20 sites.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

The cluster assignments must match what is contained in the certified LTE design. A Super Cluster is composed of a group of 2 or more contiguous clusters consisting of no more than 100 sites. The Super Cluster concept is contained in the LTE RF Engineering guidelines as a means to support more efficient RF Design KPIs. Ideally, launching commercial service is done on a super cluster basis to minimize cluster boundary re-optimization effort--but is not always practical.

Super Cluster

Super Clusters are not defined in the LTE contract. Hard KPI (Gating)

A KPI based on processing of drive data which must be met as a condition to “pass” a cluster and meet “Element Acceptance” contractual stipulations. Also known as a ”gating KPI.”

Soft KPI (Non-Gating)

A KPI based on processing of drive data which is considered non-gating and for informational purposes. These informational type of KPIs are often helpful in understanding network issues and finding other unrelated issues for research.

“Cluster Drive Test”

A drive test with purpose of determining the performance within a single cluster. The scope is generally limited to driving only within the cluster (except as other specified in these procedures). Testing of IFHO and IRAT as UEs exit the cluster are NOT included in the “Cluster Drive Test” but are done as a separate drive test.

“IFHO Drive Test”

A drive test specifically aimed to testing IFHO functionality as UE leaves a (set of) cluster(s). Sometimes this is referred to as “IFHO Exit Routes”. Depending on the overall LTE service area being deployed, IFHO may not be required. This drive test significantly differs from the “Cluster Drive Test” and is conducted separately from Cluster drives.

“IRAT Drive Test”

A drive test specifically aimed to testing IRAT functionality as UE leaves a (set of) cluster(s). Sometimes this is referred to as “IRAT Exit Routes” This drive test significantly differs from the “Cluster Drive Test” and is conducted separately from Cluster drives.

Small Cluster

A Cluster of 3 to 9 contiguous sites.

Greenfield Deployment

A “Greenfield” deployment is defined as a contiguous group of (or single) clusters which do not abut up against other LTE clusters in the same LTE band. Some describe this as an “island” of LTE coverage. For this purpose, the drive testing does not need to consider same-band handovers into adjacent clusters.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

Expansion Deployment

An “expansion” deployment is defined as a contiguous group of (or single) cluster expanding the LTE coverage footprint of an already launched (or planned to be launched) group of clusters. This can be thought of as expanding and existing LTE footprint. In this case, the drive testing needs to consider the fact that like-banded LTE handovers will occur between the expansion cluster(s) and previously launched cluster.

Dual Carrier Cluster

This describes a cluster which is being deployed (and launched) with multiple LTE carriers on the same sites. The distinguishing character is that both bands must be separately evaluated via GNG/Full testing. That is, a GNG/Full process (including report) must be conducted for 700 MHz and a separate drive and report be done for the AWS carrier.

2nd Carrier (Multi)

This describes a cluster which is being deployed with a second LTE carrier over an already launched LTE carrier. The distinguishing character is that a “first carrier” is already in commercial service.

3.2. Other Key Terms

PAYG

“Pay As You Grow” type licensing of PRBs.

GNG-Lite

A separate GNG process used to launch subsets of clusters early (Lite-Launch) to meet competitive or other business objectives. The GNG-Lite process is outside the scope of the document.

Lite-Launch(ed) Cluster

A lite-launched cluster is a (full ~ 20 site) cluster where one or more of the sites within the cluster have been unbarred for commercial service (liate-lite launches are verified and approved using the GNG-Lite process). An important distinction is it retains the formal cluster definition of all sites within the cluster. For example, …(add)

ICD

“Implementable Cluster Design” A RF Design output reflecting the site and cell configuration which is expected to be constructible for launch. This is based on C&E feedback from the PICD.

PICD

“Preliminary Initial Cluster Design”. A RF Design output reflecting the site and cell configuration based on the best possible RF design prior to C&E review for constructability.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

Element Acceptance

A contractual process as outlined in attachments relating to the delivery, installation, implementation, and rollout of LTE service and features.

4. Pre-Optimization Activities This section details the activities which should be done and completed after the RF Design phase is completed and before the tuning and optimization phase starts.

4.1. Responsibilities The OEM vendor (or party preparing the LTE cluster certificates and who will conduct the GNG drives) is responsible to generate the cluster drive route polygon, cluster drive routes, IFHO and IRAT drive routes, and submit these packages for approval.

4.2. Cluster Drive Route Definition and Approval Process The goal of the LTE cluster drive route approval process is to ensure that a) the drive routes cover the area(s) where AT&T coverage maps would show coverage (i.e. the Drive Route Polygon) and b) that the drive routes for each cluster have sufficient density and are properly defined prior to any optimization and GNG drives activity in the cluster. The drive routes are based on the ICD output of the RF design process. TIMELINE: The drive route polygons and drive routes must be submitted for approval within 4 weeks after the ICD (Implementable Cluster Design, see definitions) has been approved by the market and HQ. The RF design process is covered in the LTE RF Design Guidelines (see References). A timely submission is required due to the expected volume of approvals and actual KPI reviews.

4.2.1. Drive Route Polygon Definition A Drive Route Polygon shall be developed for each and every cluster prior to drive route development and approval. The general rules for drive route polygons:

•

The polygon boundary will be based on ATOLL RSRP signal level (outdoor) plots from the approved optimized ICD following rules which follow.

•

The polygon is defined for all sites within a cluster and must follow the same cluster definitions assigned in the ICD. That is, the clusters defined in the ICD for RF design must match the same sites in the drive cluster.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

4.2.1.1. Multiple Bands, Multiple Bandwidth Allocations, and Multiple Carrier Considerations The polygon definition process depends on if the cluster (and surrounding clusters) have multiple bands (i.e. AWS and 700 MHz), multiple bandwidth allocations, or plans to launch multi-carrier. Fortunately, most markets have a single band, bandwidth, and will launch with a single LTE carrier. Version 1 of this document will concentrate only on single and multiple bandwidth allocation rules with future updates for dual band LTE and LTE carrier addition.

Condition

Polygon Definition

All sites in cluster same carrier frequency and bandwidth allocation

Single Drive Route Polygon

Different bandwidth allocations

Two Drive Route Polygons to be defined- one for each bandwidth (i.e. one polygon for 5 MHz are, 2nd polygon for 10 MHz sites)

All other conditions

Defined in a later version of this document.

4.2.1.2. Drawing the Drive Route Polygon Each Cluster Drive Route Polygon will be drawn based strictly on the RF Design “ICD of record” using ATOLL signal level predictions for the approved design. ATOLL must be run using:

1.

ATOLL parameters for this frequency and bandwidth allocation (5 or 10 Mhz)

2.

Activate only sites in the ICD which have the same LTE carrier frequency and same bandwidth allocation.

• 3.

Prior to generating the RSRP coverage, delete any computation and focus zones. The coverage needs to be generated beyond the design polygon (computation zone) used in the ICD.

• 4.

Reminder: Different bandwidth allocations require separate drive route polygons to be generated.

Be sure to save any existing CZ first.

Generate a RSRP plot reflecting -107 dBm OUTDOOR coverage.

•

Prediction > New > Effective Signal Analysis (DL) AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. 2012 AT&T Intellectual Property. All rights reserved. 12

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

•

Configure the “Conditions Tab” as follows:

NOTE: Indoor Unchecked; MIMO UE and FTP Service. No shadowing.

•

Configure the “Display” tab as follows:


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

NOTE: “Best RSRP (RS EPRE) Level” as field, single value (-107 dBm) using gray color. • 5.

Run the prediction.

From the results of the above prediction, draw a polygon along the outer border of this -107 dBm RSRP area (also known as the “LTE Service area”). The goal of this step is to establish the outer extent of the LTE service area which will be used in a later step. An example:


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

NOTE: The red line indicates the outer extent of the LTE service area at -107 dBm RSRP. This may be drawn in ATOLL or in MapInfo® if desired.

Interior coverage holes within the outer extent are to be considered part of the LTE service area and not to be excluded from this polygon. 6.

Save this generated polygon as the New Computation Zone to be used in the next steps.

7.

Generate a new coverage best server plot (Prediction > New > Coverage By Transmitter). The “Conditions tab” should be set as follows:

NOTE:

•

Set -98 dBm as minimum signal level; Indoor coverage Unchecked; Margin set to 0 dB; “Best Signal Level” selected.

•

Run the coverage

A representative plot is shown below:


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

NOTE: This best server is now contained within the Computation Zone created in the previous step.

8.

Now determine each individual cluster drive route polygon as follows:

•

Identify the clustering of sites per each cell.

•

Each cluster has it’s own cluster drive route polygon based on the best server plot following these 2 basic rules:

i.

Where the LTE cell coverage abuts up to another LTE cell (in another LTE cluster

Footnote: The adjacent LTE cluster may be part of this ICD or part of previously designed (and possibly launched) LTE cluster.

-the drive route cluster boundary is drawn along the best server border between cells with the cluster and cells in adjacent clusters. ii.

•

Where the LTE cell coverage is at the edge of the LTE polygon--the drive route cluster boundary is drawn along the Computation Zone (-107 dBm RSRP signal level “end of LTE coverage” coverage determined above).

An example:


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

9.

The drive route polygons may be hand drawn using MapInfo (with coverage exported from ATOLL into MapInfo) or alternately, may be done in ATOLL using the Hot Spot Zone tool and exported as a MapInfo® Table File. Other considerations include:

•

The Cluster Naming Convention must be followed carefully (this is critical to processing of drive results in the processing system).

•

The full description of cluster naming convention is contained in RF Design Guidelines. However, an extract is contained in Appendix A.

The cluster drive route boundaries will be included in the Drive Route Submission form outlined later in this document (see HQ Submission Package). These boundaries, along with drive routes, must be approved by both the local market and HQ RAN as covered later.

4.2.2. Drive Route Polygon Outputs At a minimum, the drive route polygon output should have:

•

MapInfo Format (TAB preferred)

•

INCLUDE THE UNDERLAYING -107 COVERAGE IN ADDITION TO BS.

•

Snapshots of polygon with coverage levels for approval verification.

Upon approval of drive routes, the drive route polygon(s) will be uploaded to the enterprise server.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

4.2.3. Cluster Drive Route Selection Requirements After the drive route polygons are developed, the drive routes within each polygon must be determined. This section presents the requirements and process to determine drive routes. The intent of drive route selection is to:

•

Evaluate Contractual Performance against GNG KPIs for this cluster.

•

Identify any remaining poor performance areas for further optimization

•

Verify each cell of the cluster is operational,

•

Verify that sites in this cluster do not negatively impact a neighboring cluster which has already passed GNG KPIs (and may already be launched), and

•

Provide an estimate of customer experience under a specific load condition.

To meet these objectives, the specific drive route selection requirements are a follows:

•

Each and every cell in the ICD must be driven

°

If it is later found that certain drive routes are inaccessible and certain cells cannot be driven, an exception process will be used to document this condition.

•

The drive route must extend up to, or extend beyond, the cluster drive route polygon boundary.

•

Where the cluster abuts up against another LTE cluster (of the same carrier frequency), the drive routes shall extend 2 tiers into the neighboring LTE cluster to check for interaction of this cluster into the adjacent cluster.

°

NOTE: When the cluster drives start and the neighboring cluster has not yet undergone GNG testing, these extended routes into the first 2 tiers need not be driven as part of this cluster. However, for the purpose of drive route definition, assume the first 2 tiers of the adjacent cluster needs to be driven.

•

All Interstates and US Highways

•

Main Thoroughfares and all state highways

•

Select key Minor Roads as defined by the local market

•

Select key account areas (outdoor and accessible by drive vehicle) as defined by local market


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

•

Sufficient density Roads so that in urban and heavy suburban areas that minimum density of approximately ½ mile is achieved.

•

Other market requested routes, such as key suburbs, key customer accounts, etc.

•

The drive routes have sufficient drive density to adequately gauge customer experience.

•

All sites in the ICD for this cluster

The contractual, and minimum, drive time per cluster is 8 hours. Larger clusters (found in rural and light suburban area) may require additional time to meet the above requirements. Small clusters (3 to 9 sites) may have less than 8 hours of drive time as long as drive routes are selected which meet the above criteria.

4.2.4. Drive Route Outputs Drive Routes shall be in the following format:

•

Snapshots or Screen captures pasted into the submission form (discussed later)

•

MapInfo format of drive routes. (intent is to have routes on KPI report for quick auditing)

A sample screen shot of the Drive Route output is given below:


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

4.3. IFHO Drive Route Selection requirements IFHO testing is required for any LTE service areas which have multiple LTE channel allocations. This includes:

•

Areas with different bandwidth allocations (5 vs. 10 MHz)

•

Areas with different bands (AWS and 700 MHz)

•

Dual-carrier areas – covered in a later version of this document.

Note that IFHO drive routes are driven separately from the cluster drive routes Additionally, the KPIs are generated on a separate KPI report for for IFHO drives. When IFHO drives are required, the reports generated only look for successful IFHO events and do not consider performance KPIs as in cluster drives. When IFHO testing is required in an LTE area, IFHO Drive Route Selection consists of two steps outlined in the next sections of this document:


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

•

Identification of IFHO boundaries

•

Selection of Drive Routes.

4.3.1. IFHO Boundary Selection For the given LTE service area, determine the cell borders where IFHO will occur and draw these borders on a map. See the example diagram in the IFHO Drive Route Output section (4.3.3).

4.3.2. IFHO Drive Route Requirements With all IFHO borders identified from the previous step, drive routes must be developed across these borders to test IFHO performance. The general requirements for IFHO drive routes are:

•

Each drive route must exit a F1 (Frequency 1) area and drive well into the first tier of the F2 (Frequency 2) area.

•

The drive route should be bi-directional – the drive route will then be drive from F2 back into F1 (LTE multi-carrier requirements will be covered in a future version of this document)

•

Multiple drive routes are required along the IFHO border to verify all cells along the border IFHO properly.

•

All interstates, state highways, and main thoroughfares across the IFHO border shall be driven.

•

At least two exit routes per compass direction along the IFHO border per cluster. That is, at least two exit routes per north facing IFHO border, two along the east facing border, etc.

4.3.3. IFHO Drive Route Outputs IFHO Drive Routes shall be in the following format:

•


•


A sample screen shot of the IFHO Drive Route output is given below:


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

For IRAT or IFHO drive routes, AT&T expects the test team to drive 2 tiers into adjacent polygons.

4.4. IRAT Drive Route Selection Requirements IRAT testing is required along the outer edge of all LTE service areas to test and validate IRAT performance. Note that IRAT drive routes are driven separately from the cluster drive routes and are typically not done on a cluster basis. When IRAT drives are required, the reports generated only look for successful IRAT events and do not consider performance KPIs as in cluster drives. When IRAT testing is required in an LTE area, IRAT Drive Route Selection consists of two steps outlined in the next sections of this document:

•

Identification of IRAT boundaries

•

Selection of Drive Routes.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

4.4.1. IRAT Boundary Selection For the given LTE service area, determine the cell borders where IRAT will occur and draw these borders on a map. For an example of this see the IRAT drive route output example in section 4.4.3.

4.4.2. IRAT Drive Route Requirements With all IRAT borders identified from the previous step, drive routes must be developed across these borders to test IRAT performance. The general requirements for IRAT drive routes are:

•

Each drive route must exit the LTE service area and drive into the UMTS(or GSM) only service area.

•

At this point in time, UMTS to LTE IRAT testing is not required (reverse drive route). Thus, the IRAT drive routes consist of “exit only” routes out of the LTE service area.

•

Multiple drive routes are required along the IRAT border to verify all LTE cells along the border IRAT properly as the UE exits the LTE service area.

4.4.3. IRAT Drive Route Outputs IRAT Drive Routes shall be in the following format:

•


•


A sample screen shot of the IRAT Drive Route output is given below:


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

For IRAT or IFHO drive routes, AT&T expects the test team to drive 2 tiers into adjacent polygons.

4.5. Approval Process for Drive Routes, Polygons, IRAT, and IFHO Routes All drive route polygons, cluster drive routes, IFHO drive routes, and IRAT drive routes must be approved by AT&T at two levels:

•

Local market

•

HQ RAN Approver assigned to this market.

After market approval, all drive route polygons, cluster drive routes, IFHO drive routes, and IRAT drive routes must be submitted to HQ RAN for approval. Submission should be done in a timely manner as outlined in a previous section.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

The HQ submission package must include the Drive Route form which can be found at National Sharepoint . Instructions for filling this form out are given below.

4.5.1. Instructions for HQ Submission Package: Section A of the form contains the informational fields:

1.

LTE Market Name

2.

Wave # (as applicable)

3.

LTE Infrastructure Vendor

4.

Number of Cluster/This Submission

5.

Greenfield, Expansion, or Overlay

6.

Frequency Band Information

7.

ATT Market RF Lead

8.

HQ RAN Field Support Lead Name

9.

The list of all clusters contained on this submission form, including:

10.

A.

Full cluster name (MMMM_CL_SC_BAND_BW)

B.

Cluster number

C.

Super Cluster number (or NA)

D.

LTE Band

E.

LTE Bandwidth

Map identifying Cluster Boundaries and Cluster Names

Section B of the form requires an electronic image e.g. (JPEG, BMP, and MIF, cut/paste from MapInfo® etc.) of the proposed drive route, together with the following display layers:

1.

Underlay of proposed drive routes indicated in BLACK or BLUE

2.

Cluster eNode-B locations, sector orientations, and site ID’s AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. 2012 AT&T Intellectual Property. All rights reserved. 25

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

3.

Proposed cluster polygon boundary indicated in GREEN or PINK

4.

Underlying street map

Section C of the form requires a paste from ATOLL overlaying the drive route cluster boundary:

1.

-107 dBm RSRP Coverage plot from ATOLL showing the coverage from the sites in this cluster and surrounding clusters. (from 4.2.1.2)

2.

Coverage by transmitter plot (from 4.2.1.2)

3.

Drive Route Cluster Polygon for each cluster. (from 4.2.1.2)

4.

Drive Routes

5.

Underlying Roads.

6.

Section C is not required for the IRAT drive route tab.

Section D of the form requires an electronic image e.g. (JPEG, BMP, and MIF, cut/paste from MapInfo® etc.) of the proposed IRAT and/or IFHO drive routes, together with the following display layers:

1.

Underlay of proposed drive routes indicated in BLACK or BLUE

2.

Cluster eNode-B locations, sector orientations, and site ID’s

3.

Exit Drive Routes

4.

Proposed cluster polygon boundary indicated in GREEN or PINK

Final Tab: Finally, All MapInfo® Tables should be zipped and embedded in the spreadsheet within the last tab. This excel workbook should contain one tab per cluster for Section A, Section B, Section C, and Section D for the respective cluster. Submissions may contain multiple clusters for the same market. Simply create new tabs for each cluster. IFHO and IRAT exit drives must also be submitted. Useful MapInfo® hints and settings can be found the “Map Info Definition” tab of the submission spreadsheet. Once completed, forward to your National RAN contact who will review and provide approval. The market must approve routes prior to submitting to national RAN.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

4.6. Other Prerequisites Several other general (obvious) prerequisites must be in place prior to optimization, and GNG cluster testing, and testing. These are:

•

Neighbor List Relations reviewed – should be caught during optimization phase so not belong here

•

IRAT neighbor list (or other related parameters) completed.

•

Parameters set to golden parameters

5. GNG Cluster Drive Collection Process and Requirements

5.1. Drive Route Key Concepts and Requirements The following are the key concepts and key requirements for GNG Cluster Drives. Many of the concepts and requirements are further elaborated on in subsequent sections.

•

A cluster is driven a unit – all drive routes as approved must be driven.

•

Inaccessible routes must be documented

•

No exclusion areas (due to jeopardy sites, etc.) will be granted—the cluster is evaluated as a full unit.

•

Equipment (including UEs) must be periodically calibrated to insure accuracy.

•

The OEM vendor is responsible for conducting drive testing.

5.2. Responsibilities The OEM vendor (or party who will conduct the GNG drives and present GNG results for approval) is responsible to procure required test equipment and drive the cluster as outlined in this section.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

5.3. Drive Test Hardware

5.3.1. Drive Test Equipment Requirements The following table identifies the KPI test drive equipment required for GNG drives:

Footnote:

The vendor is free to select any test equipment system for optimization and tuning. However, all GNG drives must use the prescribed s

Device

Manufacturer/Model

Notes

UE1

AC313U LTE/UMTS data card with approved Long Data Call firmware.

UE2

AC313U LTE/UMTS data card with approved Short Data Call firmware.

UE3

AC313U LTE/UMTS data card with approved Latency firmware.

UE4 (Future)

TBD

Laptop

Minimum Specifications to be determined by GNG field test team.

Scanner 1

PcTel EX (Note 1) or PcTel MX supporting LTE (PcTel EX) or GSM/UMTS/LTE GSM/UMTS/LTE (option 2, if chosen, ignore (PcTel MX) Scanner 2)

Scanner 2

PcTel EX (Note 1)

CSFB

UMTS/GSM

External Scan- Minimum Specifications to be determined by Vertical Polarized Magmount 0 dBi gain ner Antenna GNG field test team. Collection SoftNemo Outdoor ware

5.3.2. Drive Test General Guidelines AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. 2012 AT&T Intellectual Property. All rights reserved. 28

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

Following are the general guidelines that vendors must follow as they configure their test equipment equipments and implement their test procedures.

•

UEs must be placed head level with minimum horizontal separation of 43cm/17in (700 MHz) when they are in the same plane. A combination of vertical and horizontal separation can be used to provide the required isolation.

•

The USB cabling to the UEs should not exceed 18 inches. It is recommended to use the extension cables provided by the device manufacturers.

•

USB hub should be given an external power supply from the power cable connected to the power inverter.

•

Minimum separation guidelines must be followed for scanner antenna and GPS placement on the Drive Test vehicle roof top.

•

Procedures outlined in this document should be followed while connecting and disconnecting equipment.

•

It is recommended to use External GPS for the GNG drives. In the event of scanner failure this will still provide valid UE data and optimization efforts can continue.

•

It is recommended to carry a backup power inverter in case of a failure.

•

Extra fuse(s) for the scanner may be kept in an event of power surge.

•

Backup GPS and UEs may be carried in case any of them fails to function during the drive tests.

•

It is recommended to have the original software required for testing.

•

Ensure Drive test vehicle is in good condition.

•

Disconnect and secure all equipment after completion of drive testing.

•

Always carry a fire-extinguisher and first aid kit.

•

Company logo on the test vehicle is recommended.

•

All the equipment including Drive Test laptop, Navigation laptop, UEs, Phone, Inverter, Table, Scanners, Extension power cords, Antennas and GPS should be immobile.

5.3.3. Drive Test Equipment Calibration Requirements All test equipment must be kept in good operating condition. Any suspected poor performing UEs, antennas, or other devices must be replaced upon AT&T’s request. In addition, periodic equipment verification and calibration, as well as weekly checks of cabling will be required as outlined in the following sections. AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. 2012 AT&T Intellectual Property. All rights reserved. 29

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

5.3.3.1. Equipment Calibration Requirements To assure accurate results of drive testing, monthly calibration and/or verification of the following equipment must be conducted:

•

UEs (validation every 2 months)

•

Antenna(s) (validation every 3 months)

•

Scanner (calibration every 6 months)

Equipment “validation” means that the equipment is evaluated in a lab facility that can verify that a) the UE is within 3GPP specifications for RSRP signal level (even if marginal, it should be replaced); and b) the antenna should be within 1 dB of gain specification. If the equipment is found to not meet these requirements (or marginal), then it should be retired and not returned to service. Equipment “calibration” shall be done at the indicated interval by a certified calibration lab.

5.3.3.2. Scanner Antenna and Cable Testing The integrity of the scanner antenna and cable is important to accurate measurements and KPI report results. The following simple in-field test process should be used to verify cable and antenna integrity:

Item

Daily

Monthly (in market) Verification Measurements

Footnote: Antenna(s)

Visual Inspection

This is in addition to quarterly lab validation.

Coax (Scanner to Antenna)

Visual Inspection

Verification Measurements

The monthly “Verification Measurements” should use a Site Master ® or similar device to measure VSWR (no worse than 1.xxxx VSWR).


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

5.3.4. Cluster GNG Drive Test Configuration

5.3.4.1. Four possible configurations are listed in the table below:

No. of USB HUB Total Number of No. of USB No. of Scanner Required( *USB USB ports Reports on Lap- Receiver AntenHub should have a quired top Required nas Required power supply)

Configuration

Description

1

One PCTEL MX scanner with the External GPS connection

8

1

4

2

2

One PCTEL MX scanner and GPS connection from the scanner

7

1

4

2

3

Two PCTEL EX Scanners and GPS connection from one External USB port

9

2

4

3

4

Two PCTEL Ex scanners and GPS connection from one of the EX scanners

8

1

4

3

For further information on these test configurations please refer to the Test Job Aid document GNG Full Test Configuration.

5.3.4.2. Drive Test Equipment List and Configuration: refer to GNG Full Test Configuration document.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

5.3.5. UE Equipment Each UE performs a particular test function as outlined below.

UE1

Long Data Call Application iPERF Test Full buffer TCP – Uplink & Downlink Purpose To ensure full buffer conditions are met for bi-directional TCP traffic testing. KPI Classes

Retainability, Service Integrity (Throughput), Mobility (Inter/Intra Frequency HO)

Test Description

TCP traffic will be sent continuously until end of testing or drop. If drop, the iPerf session will automatically restart. Testing will be bidirectional. Locked to LTE Band or Channel

Required Setting(s) Laptop TCP Window Size: 512 KB Simultaneous Sessions: 20

UE2

Short Data Call Application FTP/Downlink Test Application Specific TCP – Downlink Purpose To test downlink FTP performance for short sessions KPI Classes

Accessibility, Service Integrity (Throughput), Mobility (Inter/Intra Frequency HO) TCP traffic sent for a period of ~8 seconds with a pause of 10 seconds between cycles.. (2 MByte File Size

Test Description

Footnote: Derivation: (5 mbyte * 8) / 20 sec = 8 MBytes/Sec. Double Check.

) Requited Setting(s) Float between LTE/UMTS/GSM


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

UE3

Latency Application Ping/ICMP Test U-Plane Latency Purpose To test the user plane latency KPI Classes Service Integrity (Latency) Test Description ICMP ECHO shall be sent one per second during the entire test. Required Setting(s) Locked to LTE Band or Channel

UE4

CSFB Application Voice call setup time, Data reselect time and CS AxR Test Call setup time Purpose To test impact of CS call on data network KPI Classes Service integrity, mobility, accessibility, and retainability Test Description Both MO and MT CS calls sent over the LTE-UMTS networks

All data sessions will connect to the AT&T dedicated server within the nearest AT&T data center. The Job Aid will contain the list of IP addresses and FTP login information to be used for GNG testing.

5.3.6. Drive Test Scripts Only the latest available drive test collection script should be used for GNG data collection.

5.4. Testing Journal Requirements A Test Journals must be completed for each collection session driven (and drive type) by a given team (i.e. one for an 8 hour shift while driving the same cluster). The template can be found in the Cluster Drive Test Job Aid (under development). The test Journal includes (but is not limited to):


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

•

Cluster Naming Identification (important when using enterprise report generator)

•

Serial numbers of devices used

•

Alarm-free verification both at start of drive and during drive testing

•

Specific notes and observations by the drive team during the testing.

A separate journal sheet should be filled out for IFHO drive session and separate sheet for IRAT drive sessions. All cluster drives can be covered by a single journal sheet for a given drive shift/team.

5.5. Cluster Drive Requirements All drive routes must be driven in the cluster without regards to missing or jeopardy sites. Generally, a drive route must extend up to the drive route cluster boundary except as modified in the following subsections.

5.5.1. Driving into Adjacent LTE Clusters – When Required Any adjacent cluster (to the cluster under test) which has sites on-air must be driven into the first 2 tiers of that cluster. The drive route approval process has already included the 2 tier drive routes. This adjacent cluster should be driven (2 tiers) under the following conditions:

•

The adjacent cluster has already been GNG/Full approved as “GNG Green”

•

The adjacent cluster has been launched (or lite-launched)

5.5.2. Inaccessible Drive Routes When, during cluster drive testing, a previously approved drive route is not accessible, a formal drive route exception must be documented and presented to AT&T. The following should be done:

•

Document the reason for non-access. Include picture when appropriate and safe to take a picture

•

Documentation should be noted on the journal sheet.

•

Attempt to find an alternative nearby drive route to replace the inaccessible route.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

5.6. Log File Naming Convention Drive log files are named as: AAAA_B_C_D_E_(timestamp).F.nmf Where AAAA = submarket code B = cluster number C = super cluster number D = band indicator (“7”=700MHz, “A”=AWS) E = LTE Bandwidth (“5M”=5MHz, “10M”=10MHz) (timestamp) = Nemo logic for timestamp at the start of logging F = Device number (1, 2, 3, 4, 5 or 6)

NOTE: If the fields D and/or E are not entered correctly, the data in the report will be missing or incorrect. Note that the fields are case sensitive.

For example, a drive conducted in the Orlando submarket, cluster 9, super cluster 3, in the 700MHz band and with 10MHz bandwidth will have associated logfiles in the following format: FLOR_9_3_7_10M_11Mar16 114524.*.nmf

5.7. Pre and Post Drive Checks Required

5.7.1. Pre-Drive Checks Prior to the start of a drive shift to collect KPI drive data, the following should be verified

•

OCNS enabled on in cluster and documented in journal.

•

Coordinated such that the only sites on air in the cluster are those that have been optimized. I.e, no sites are being integrated or new un-optimized sites are on air.

•

Verified that no service affecting or impacting alarms or other known impairments exist for the sites in the cluster (and first 2 tiers of neighbors as appropriate)

•

Coordinated such that no network upgrades or other maintenance work will occur during testing window which will affect this cluster.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

•

All test drive devices are properly collecting realistic data and operating properly during a brief test.

5.7.2. Post-Drive Checks Upon completion of a drive shift, the following checks should be completed:

•

Verify that the sites in the cluster remained alarm free during the duration of the drive shift. Note this on the journal sheet.

•

Verify that the Journal sheet is completed with required information.

•

If drive routes were not accessible, document specific information on journal sheet and save any pictures as documentation.

5.8. Drive Collection Job Aid A Job aid with specific “how-to” details is under development.

6. IFHO and IRAT Drive Collection Process and Requirements

6.1. Responsibilities The OEM vendor (or party which will conduct the GNG drives and present GNG results for approval) is responsible for procuring required test equipment and drive the IFHO and IRAT drives. The overall guidelines for IFHO and IRAT drive tests are near identical with that for cluster drive and similar to UMTS case. The same UEs will be used for IFHO and IRAT drive tests as the ones used for cluster drives.

7. LTE GNG Full Testing: Commercial vs. Non-Commercial Networks The LTE GNG Full process specified in Attachment H of the LTE contract is originally defined for the pre-launch network where AT&T has the full control on the network. With the competitive business need to launch networks prior to GNG Full AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. 2012 AT&T Intellectual Property. All rights reserved. 36

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

being conducted, the GNG Full testing methodology must account for both traditional pre-launch testing and post-launch situations.

7.1. Traditional Pre-Commercial Launch GNG Full Testing The drive tests are conducted before the commercial launch and follow these scenarios:

•

Drive testing is conducted any hour of the day

•

All KPIs apply, but a higher degree of flexibility is appliced to the KPI pass/fail criteria (pre-commercial KPI requirement)

7.2. GNG/Full Testing in a Launched (Commercial) Network When GNG/Full testing is conducted after commercial launch, the following shall apply: Drive testing shall be done in maintenance window.

•

OCNS must be used as outlined in Attachment H of the LTE contract.

•

Certain “Commercial Launch” KPIs are introduced (such as “Hard KPIs”) for this measurement situation. This is covered in more detail in the next section.

8. Drive Test Data Processing and KPI Requirements This section covers the data processing requirements and the application of pass/fail criteria to the KPIs for GNG Cluster Drives as well as reports for IFHO and IRAT drives.

8.1. Drive Test Processing Concepts and Key Requirements The following are the key concepts and requirements for processing of GNG Cluster, IFHO, and IRAT drive data. Many of the concepts and requirements are further elaborated in subsequent sections.

•

AT&T will utilize the ActixOne centralized enterprise solution for all KPI reporting. AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. 2012 AT&T Intellectual Property. All rights reserved. 37

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

•

The OEM vendor is responsible for uploading drive files, but only AT&T will be able to generate the GNG report.

•

KPIs, just as for UMTS, are divided into “Hard” KPIs and “Soft KPIs”.

•

In certain Wave 1 (initial launch) markets, GNG/Full drives may be conducted in a live commercial network. In this case, the time of day that drives may be conducted will be restricted and certain KPIs will be considered “soft” instead of “hard.”

•

Cluster Drive data will be processed on a cluster by cluster basis. Each cluster will have its own unique report.

•

IFHO and IRAT drive data (when required) are generally done on a cluster basis.

•

IFHO and IRAT test drives will each have a different report. Hard and Soft KPIs do not directly apply to IFHO and IRAT reports—they are informational and used along with maps in the report to gauge customer experience.

8.2. Responsibilities The OEM vendor (or party which will conducted the GNG drives) is responsible for uploading drive log files and generating KPI, IFHO, and IRAT reports, and for deliverables as outlined in this section.

8.3. GNG Processing Software The primary platform for all GNG drive test processing is ActixOne centralized enterprise post-processing platform. The vendors are also allowed to use the Actix desktop post-processing tool such as:

•

Actix Analyzer

•

Actix Spotlight

AT&T already requires Actix to ensure the synchronization between the ActixOne platform and the desktop version in terms of the processing and test report support.

8.4. Drive Data Log File Requirements – Maximum Measurement Window All log files used to generate the GNG report must be collected within a 48 hour window (start of first drive to start of last drive) to be considered for GNG KPIs. Since a single GNG report is for a single cluster, this means that all drives for this particular cluster must meet the 48 hour window requirement.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

8.5. Site/Cell Configuration Documentation The configuration of all sites/cells which were on-air for GNG drive must be documented using the standard template. The template will also include the RF design configuration as certified in the RF design cluster certificates. The template includes:

•

Antenna Model

•

Electrical tilt

•

Mechanical tilt

•

Azimuth

•

Centerline

This “as-built” information should be requested through your local market PM. This configuration spreadsheet will be submitted along with the drive results for GNG Cluster approval.

8.6. GNG Cluster Drive KPIs and Methods This section presents the KPIs to be included in KPI template used for GNG Cluster Drive evaluation. All KPIs are calculated within the Drive Route Polygon unless otherwise specified. A single GNG Cluster Drive Report shall cover just one cluster. In cases where multiple clusters need to be reviewed at one time, multiple reports will have to be submitted to the reviewing parties.

8.6.1. GNG Drive Cluster KPIs This section presents the table of AT&T KPIs based on Contract Attachments and/or other AT&T guidelines (such as the LTE RF Design Guidelines). Note that the ACTIX template will contain additional soft KPIs above and beyond these AT&T KPIs. All KPIs are calculated within the Drive Route Polygon for the specific cluster unless otherwise specified. Tables with hard and soft KPIs are given below (note: hard KPIs are highlighted in green and red whiled soft KPI are in blue).


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

The table below provides more information on the hard and soft KPIs given above.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

8.6.2. KPI Implementation in ActixOne Platform Please refer to the ActixOne KPI implementation report titled AT&T LTE GNG Metrics Description for further details on the key KPIs (accessibility, retainability, integrity, and handover KPIs, etc) included in the test report.

8.6.3. Cell Aggregation Method Multiple UEs used for data collection are described in section Drive Test Equipment. Certain KPIs, such as throughput, must be properly aggregated together to obtain KPIs for all UEs in the drive vehicle. To determine the throughput KPI given multiple UEs in the vehicle, a cell-aggregation technique shall be used. Cell Aggregation can be described as follows:

•

Aggregation will be done on a bin by bin basis

•

Aggregation will further be done on a individual serving cell basis


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

•

Within a given bin, the throughput of all UEs served by the same cell will be summed (aggregated) together.

•

KPI processing using “Cell Aggregation” will determine statistics based on the aggregated values per each serving cell.

8.7. Exclusion Zones GNG KPI performance is to be evaluated over a “geographic area” or cluster. The intent is to provide LTE service over the entire cluster meeting KPI targets. For LTE deployments, no exclusion zones will be granted for missing sites. It is expected that “Green GNG KPIs” must be achieved over the entire geographic cluster without exclusions in order to meet and pass the GNG stipulations of “element acceptance”. It is expected that optimization around jeopardy sites be done to achieve best KPI performance.

Exception: The only exception to this requirement is missing sites on the edge of the LTE service area. With written HQ RAN and market approval, exceptions for edge sites may be granted. However, any jeopardy site within a LTE service polygon will not be granted an exception.

When KPIs cannot be met in a cluster awaiting jeopardy sites, the “lite-launch” process may be used to launch a cluster. However formal GNG testing would be done and GNG KPIs reviewed after the jeopardy sites are brought on-air.

8.8. GNG KPI Report This section covers the GNG KPI template used to report the results of GNG Cluster Drives, IFHO, and IRAT drive data.

8.8.1. Contents of KPI Report Template The template is under development based on KPI matrix.

8.8.1.1. GNG KPI Report Parameter Audit The GNG template will include a LTE only audit tab of the MIB/SIB messages decoded by the UEs and will contain a comparison to “AT&T golden parameters”. This is designed to supplement, not replace, the full parameter audit done as part of the pre-launch checklist. This is a new report feature compared to UMTS.

8.8.1.2. Serving Cells Audit AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. 2012 AT&T Intellectual Property. All rights reserved. 46

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

The GNG template will include a tab listing all cells which actively served call sessions during the drive sessions. This is envisioned to also include the time and/or data volume served by that particular call. Format details to be worked out.

8.8.2. IFHO Tab A tab (or tabs) will be included with IFHO related counters and KPIs. Details under development.

8.8.3. IRAT Tab A tab (or tabs) will be included with IRAT related counters and KPIs. Details under development. The current UMTS template will be used as a model.

8.9. Uploading Drive Log Files to Server for GNG KPI Report Generation A separate “job aid” document will be developed and provided with specific step by step requirements to upload log files and generate the GNG KPI report for a given cluster.

8.10. GNG Processing Job Aid A job aid is under development detailing the specific steps to generating the necessary GNG Drive, IFHO, and IRAT reports. A preliminary version of the job aid can be found at National RAN Sharepoint.

8.11. GNG Drive Cluster Acceptance Criteria Acceptance requirements are covered in the next section.

9. Results Review and Approval Process A GNG KPI review call will be scheduled by N-PMO to review the GNG KPI data. Approvals are done on a cluster by cluster basis. Multiple clusters can be reviewed during the same call.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

9.1. Responsibilities The OEM vendor (or party which will conduct the GNG drives and prepare the GNG results for approval) is responsible for submitting GNG related material to AT&T as outlined in this section. AT&T PMO is responsible for scheduling GNG KPI calls to review the submission with all necessary AT&T personnel. AT&T formal approver list is under development by PMO.

9.2. Package Requirements to be Submitted for Review and Approval The following items must be delivered and reviewed as part of the GNG KPI Review submission:

•

GNG Cluster Drive Report for all Clusters being reviewed (accessible on AT&T enterprise server)

•

GNG Report for IFHO testing (if required) (accessible on AT&T enterprise server)

•

GNG Report for IRAT testing (if required) (accessible on AT&T enterprise server)

•

Test Journals for all KPI drives conducted for the clusters being reviewed (from OEM)

•

Drive Route Exceptions (inaccessible drive routes) documentation and pictures. (From OEM)

•

Site/Sector configuration as driven (excel sheet) (from OEM)

The above packages must be made available or delivered to AT&T a minimum of 24 hours prior to the start of the scheduled GNG KPI call.

9.3. GNG KPI Drive/Cluster Approval Requirements

9.3.1. Drive Routes & Drive Route Polygon Verification The drive route polygon must be the same as originally submitted in an earlier step and not be modified. Exclusion zones are not permitted except for the rare case as outlined in the previous step. All drive routes must be driven as approved within the cluster. Drive routes must extend into adjacent clusters if the adjacent cluster is a) launched, b) lite-launched, c) has already passed GNG testing.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

Any inaccessible drive routes must be documented and an exception submitted.

9.3.2. Standard Cluster (10 to 30 sites) Requirements In order for a cluster to be “GNG Green” and pass this portion of element acceptance, all “hard KPIs” must be green and meet the green performance thresholds. The thresholds vary by LTE channel bandwidth.

9.3.3. Small Cluster (3 to 9 sites) Requirements In order the assure a suitable LTE customer experience, small clusters, defined as 3 to 9 contiguous sites, must pass the same GNG KPI criteria as standard clusters. Very small clusters (such as 3 sites) may have difficulty meeting all KPIs due to fewer overall samples. When small sample size is adequately shown to be the cause of not meeting a KPI in a small cluster, an exception will be granted.

9.3.4. BAU/SSV Requirements BAU/SSV requirements (1 or 2 contiguous sites) are considered outside the scope of GNG testing criteria with the BAU/ SSV process to be documented in another document.

9.4. IFHO and IRAT Approval Requirements To be added in next revision.

9.5. Outputs and Notification of GNG KPI Approval Process To be added later (next revision)

10. Incremental Sites BAU Process This section outlines the process for launching incremental sites that may need to be added to an LTE commercial launch market. The process is illustrated in a flowchart below.

10.1. Incremental Sites Process Flowchart AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. 2012 AT&T Intellectual Property. All rights reserved. 49

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

Fig 10.1 - Incremental sites process

10.2. Pre-launch Activities

1.

Notification of site readiness is sent to ??

2.

Vendor adds the site/s to its sites list and begins integration of the site. Vendor shall integrate the site during day time hours only (or at a time approved by AT&T). Site/s may only be unlocked while on site and must be locked at the conclusion of on-site testing. AT&T Proprietary (Internal Use Only) Not for use or disclosure outside the AT&T companies, except under written agreement. 2012 AT&T Intellectual Property. All rights reserved. 50

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

3.

Vendor applies Golden Parameters to the site/s and begins alarm monitoring. Vendor may unlock sites only during the maintenance window for alarm monitoring. Sites must be locked at the end of the maintenance window.

4.

Clearing alarms: vendor may conduct alarm clearing activities during day time hours with sites in reserved mode (locked). If extended test time (>3 hours) becomes necessary, market performance engineering shall be notified.

5.

Site shakedown: vendor may unlock the site/s (put them in reserve state) for site shakedown (testing) during daytime hours. Sites may only be unlocked while on site and must be locked after the test is completed. The requirement to lock the sites during the day for site shakedown or for alarm monitoring/clearing and unlock them at night is to avoid interference to the commercial network and handover from commercial sites.

6.

Parameter audits shall include Gold Standards, LAC/TAC, CSFB parameters, E911 parameters, and Femto specific settings including femto channel verification.

7.

Once the site is successfully integrated, LTE PM needs to complete the BAU checklist and submit the approval request to the regional lead representing HQ RAN.

8.

If approval is granted, vendor will then proceed with unlocking the sites for commercial operation, thus triggering the formal transfer of site operation from the vendor to AT&T. A notification to this effect must also be made to ATS and market performance engineer.

9.

Next, vendor proceeds with field optimization activities.

10.3. GNG Team Approval Process

1.

LTE PM shall submit the list of sites that are ready for launch to GNG HQ at least two days before the planned launch.

2.

GNG HQ will provide approval for item 1.3 and 1.4 in the Launch Proposal Checklist (see fig. 10.2 below). Note: vendor is well advised to resolve any issue it may have with implementation of Gold standard and/or TAC/LAC prior to submitting the checklist. In general, all questions and issues from vendor must come to GNG HQ through LTE PM.

3.

Vendor shall provide daily alarm reports for the sites to be launched to GNG HQ. Sites must be alarm free for at least 3 days prior to launch to show site is stable enough for commercial launch.

4.

Once the Launch Proposal Checklist is completed, LTE PM will email the checklist name and the file link to GNG HQ along with a request for final approval.

5.

GNG HQ will conduct a review of the checklist and provide a response to the LTE PM on the approval status within 24 hours of the request.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

6.

Final approval to “Un-Reserve” the sites will be sent out by GNG HQ team to all concerned parties (vendor, market lead, RAN market lead (RAN Director/ RAN Manager/RAN engineer), ATS, PMO, LTE Realization Team representative responsible for the market). A sample email can be found in the attachment below. RE LTE GNG Dallas GRP2B checklist copy.rtf You may download this file from the online version of this document. Note: You must have the proper application in order to open the file.

7.

A confirmation email will be sent by the vendor to everyone on the distribution list (from line 7) after the sites are “un-reserved” or “un-locked”

8.

LTE PM will be responsible for informing others in the market that need to know the launch status of the site/s (e.g., RAN Engineer responsible for MTI check (Site On-Air)

10.4. Link to the PMO Organization web-based checklist http://mesapplications.web.att.com/LTE/view/index_view.cfm The LTE PM will post the checklist at the link above and request a review from HQ representative. The GNG HQ representative will verify if the items have been completed or if further action is required. A sample page can be seen below.

10.4.1. Sample of Web-based checklist Fig. 10.2 - Web checklist


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

11. References [Anite] Anite test setup and configuration compliance document [ActixOne] Actix KPI implementation document titled AT&T LTE GNG Metrics Description

12. Appendix A – Cluster Naming Convention for Polygons and Drive Routes This appendix presents a summarized extract of the cluster naming convention covered in the LTE RF Design Guidelines (ND-369). It is intended to give enough basic information to generate the following for initial Wave 1 markets:


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

•

File Naming of Cluster Drive Route Polygons

•

File Naming for Cluster Drive Routes

•

File Naming for IFHO and IRAT drive routes.

12.1. General Cluster Naming Convention The general cluster naming convention is used as part of the drive route polygon name, the drive routes, and super cluster boundaries. In this section, the generally cluster name is covered. In the next section, the naming convention for drive route polygon and drive routes is covered. The cluster naming convention consists of all five fields separated by underscores. Each of the five fields is more formally defined in the following sections. The naming convention format is:

SMKT_Cluster#[Rev]_SuperCluster#_Band_BW

Example: DFWX_7_2_7_10M Where:

(Dallas, Cluster 7, super cluster 2, 700 MHz, 10 Mhz BW)

Field

Description

Sub-Market Identifier (SMKT)

Submarket identifier (4 characters) using the standard AT&T submarket co- 4 Characters Mandatory des (table later).

Cluster Number

Type

Cluster Number within this sub-market. Numeric, no leading zeros. See important notes on keeping this cluster number unique. Revisions to Existing Cluster Number Revision: Single Alpha Character when necessary. are covered in ND-369.

Super-Cluster

Super Cluster Number. A super cluster is composed of multiple contiguous Numeric, no leading zeros. “NA” when clusters. In cases where super cluster not applicable. is not applicable, identify as “NA”.


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

Field

Description

Type

Frequency Band

Frequency band for this cluster. Note “7” for 700 MHz that a cluster is always for a specific “A” for AWS band frequency band.

LTE Channel Bandwidth

Bandwidth (5 of 10 MHz) of this cluster. “5M” for 5 Mhz bandwidth; Note that a cluster is always for a single “10M” for 10 MHz bandwidth. bandwidth.

12.2. File Naming Convention for polygons and Drive Routes This section presents the actual file name for:

•

Drive Route Polygons (done on cluster basis)

•

Drive Routes (done on cluster basis)

•

IRAT and IFHO Drive Routes (done on a cluster basis)

The following table presents the file naming convention for various polygons and Drive Routes which are used for GNG/ Full contractual element acceptance. In this table, “(Cluster name) indicates the standard cluster name as covered in the previous section. There are covered in more detail in the GNG/Full Guidelines.

Polygon Purpose

File Naming

Examples

Notes

GNG/Full Cluster Drive Route Polygon

DRP_(Cluster_Name).*

DRP_DFWX_6_2_7_10M.* Note 1

Cluster Drive Routes

DR_(Cluster_Name).*

DR_DFWX_6_2_7_10M.*

IRAT Exit Routes

IRATDR_(Cluster_Name).*

IRATDR_DFWX_6_2_7_10 Note 3 M.*

IFHO Exit Routes

IFIFHODR_(Cluster_Name).* HODR_DFWX_6_2_7_10M. Note 4 * Note 3

Note 2

Notes to above table:


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

1) The boundary file for cluster 6 (in supercluster 2) for drive route processing of GNG/Full data. This polygon file will be used to define the extent of drives for this specific cluster as well as for ACTIX® process of GNG results as part of contractual acceptance. 2) This is file name for drive routes to be driven in cluster 6 (in supercluster 2) for GNG/Full testing. See GNG/Full guidelines for additional details. 3) Drive routes for a) IRAT, and b) IFHO exit routes. Exit routes start within cluster 6 and drive out of cluster. See GNG/ Full guidelines for additional details. General Note 1: The “.*” indicates the file type—such as “.agd” or for map info files, the “mif”, “tab”, “map”, etc.

12.3. Sub-Market Codes The following table lists all allowable sub-market codes that can be used as part of the cluster naming convention. This table follows the standard AT&T submarket codes.

SubMarket Code (SMKT)

SubMarket_Name

Region

ED_Group

AKAN

ANCHORAGE

West

PNW

AZPH

ARIZONA

West

AZ/NM

ARXX

ARKANSAS

Southwest

AR/OK

AUSX

AUSTIN

Southwest

STX

LABR

BATON ROUGE

Southeast

LA

ALBH

BIRMINGHAM

Southeast

AL/MS

CILX

CENTRAL ILLINOIS

Midwest

IL/WI

CTXX

CENTRAL TEXAS

Southwest

NTX

NCCH

CHARLOTTE

Southeast

Carolinas

TNCH

CHATTANOOGA

Southeast

TN/KY

CHIX

CHICAGO

Midwest

IL/WI

GACX

COASTAL GEORGIA

Southeast

Georgia

RMCO

COLORADO

West

RMR

SCCL

COLUMBIA

Southeast

Carolinas

NECT

CONNECTICUT

Northeast

New England

DFWX

DALLAS FT. WORTH

Southwest

NTX


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12


SubMarket_Name

Region

ED_Group

DETX

DETROIT

Midwest

MI/IN

ELPX

EL PASO

Southwest

NTX

KYEV

EVANSVILLE

Southeast

TN/KY

AKFR

FAIRBANKS

West

PNW

FLGV

GAINESVILLE

Southeast

NFL

NCGB

GREENSBORO

Southeast

Carolinas

SCGV

GREENVILLE

Southeast

Carolinas

HARY

HARLY

Northeast

EPA/SNJ/DE

HIHO

HAWAII

West

SD/LV/HI

HOUX

HOUSTON

Southwest

STX

ALHT

HUNTSVILLE

Southeast

AL/MS

RMID

IDAHO

West

RMR

INDY

INDIANAPOLIS

Midwest

MI/IN

IAXX

IOWA

Midwest

MNP

MSJK

JACKSON MS

Southeast

AL/MS

FLJK

JACKSONVILLE

Southeast

NFL

AKJU

JUNEAU

West

PNW

KSCX

KANSAS CITY

CENTRAL

MO/KS

TNKN

KNOXVILLE

Southeast

TN/KY

LALA

LAFAYETTE

Southeast

LA

NVLV

LAS VEGAS

West

SD/LV/HI

KYLX

LEXINGTON

Southeast

TN/KY

CALA

LOS ANGELES

West

Los Angeles

KYLS

LOUISVILLE

Southeast

TN/KY

NEME

MAINE

Northeast

New England

NEMA

MASSACHUSETTS

Northeast

New England

TNCR

MEMPHIS

Southeast

TN/KY


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12


SubMarket_Name

Region

ED_Group

MNXX

MINNESOTA

Midwest

MNP

ALMO

MOBILE

Southeast

AL/MS

MTXX

MONTANA

West

RMR

ALMG

MONTGOMERY

Southeast

AL/MS

TNNS

NASHVILLE

Southeast

TN/KY

NEXX

NEBRASKA

Midwest

MNP

NENH

NEW HAMPSHIRE

Northeast

New England

NMAL

NEW MEXICO

West

AZ/NM

LANO

NEW ORLEANS

Southeast

LA

NYCX

NEW YORK CITY

Northeast

NYC/NNJ

NDXX

NORTH DAKOTA

Midwest

MNP

GANX

NORTH GEORGIA

Southeast

Georgia

NMIX

NORTHERN MI

Midwest

MI/IN

NOHX

NORTHERN OH

Midwest

OH/WPA

FLOC

OCALA

Southeast

NFL

OKCX

OKLAHOMA CITY

Southwest

AR/OK

ORPL

OREGON

West

PNW

FLOR

ORLANDO

Southeast

NFL

OMIX

OUTSTATE MI

Midwest

MI/IN

PHIL

PHILADELPHIA

Northeast

EPA/SNJ/DE

PRVI

PUERTO RICO

Southeast

PR

NCRA

RALEIGH

Southeast

Carolinas

NERI

RHODE ISLAND

Northeast

New England

CASA

SACRAMENTO

West

NCAL

SAXX

SAN ANTONIO

Southwest

STX

CASD

SAN DIEGO

West

SD/LV/HI

CASF

SAN FRANCISCO

West

NCAL


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12


SubMarket_Name

Region

ED_Group

LASP

SHREVEPORT

Southeast

LA

SDXX

SOUTH DAKOTA

Midwest

MNP

FLSX

SOUTH FLORIDA

Southeast

SFL

GASX

SOUTH GEORGIA

Southeast

Georgia

SOHX

SOUTHERN OH

Midwest

OH/WPA

FLSW

SOUTHWEST FLORIDA

Southeast

NFL

MOSL

ST. LOUIS

Southwest

MO/KS

FLTC

TALLAHASSEE

Southeast

NFL

FLTA

TAMPA

Southeast

NFL

TULX

TULSA OK

Southwest

AR/OK

UPNY

UP STATE NY

Northeast

UPNY

RMUT

UTAH

West

RMR

NEVT

VERMONT

Northeast

New England

VAXX

VIRGINIA

Northeast

VA/WV

WASH

WASHINGTON

West

PNW

WABA

WASHINGTON DC-BALTIMORE Northeast

WABA

WTXX

WEST TEXAS

Southwest

NTX

WVXX

WEST VIRGINIA

Northeast

VA/WV

WPAX

WESTERN PENNSYLVANIA

Midwest

OH/WPA

WIXX

WISCONSIN

Midwest

IL/WI

WYXX

WYOMING

West

RMR

13. Appendix B – 3 dB Coverage Rule Comparison The 3 dB Coverage Comparison check contained in Attachment H will be implemented according to the following algorithms—one for 700 MHz deployment and the other for AWS band deployment:


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

B.1 – 700 MHz Algorithm:

B.2 – AWS Algorithm


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

14. Appendix C – Testing Journal Template This form will be moved to Job Aid. Needed enhancements are noted in Yellow.

Market Code

Cluster #

Super-Cluster # Band (7/A)

BW(5M/10M)


Type: Std / IRAT / FHO

AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

Scanner (LTE) Scanner (UMTS/ GSM) Scanner (GSM) LTE UE (1) LTE UE (2) Serial Numbers: Start OSS Alarm Free (Verified by)

LTE UE (3) LTE UE (4) N/a

End OSS Alarm Free during Drive Period (Verified by) DL: 50% - OCNS Loading: UL: 0% Add Inaccessible Drive Route section Add type of drive: Cluster Drive, IRAT drive, or IFHO Drive to journal Notes: Add last Calibration Date, last sweep date. Date Start Time. Test Engineer:

Jack Smith

Test Coordinator:

Sue Edge

15. Related Documents

16. Acknowledgements


AT&T

Practice

ATT-950-010-062 Issue 1, 03/28/12

17. Contact List

Name

ATTUID

Phone #

Department / Responsibility

David Bhatta

db694h

847-765-6275

HQ RAN GNG Team/ LTE & UMTS Launch Review and Approval

Orlando Davila

od2163

847-765-3601

HQ RAN GNG Team/ RAN Area Manager

Revision Log Issue Number

Date

1

03/28/12

Description

Published By db694h

Acronyms A.1. Document Specific Acronyms N/A

A.2. Acronyms Dictionary Refer to ATT-000-000-020, Acronyms Dictionary.


LTE GNG (Full) Requirements, Testing Process

Recommend Documents