lte gng (full) requirements, testing process

ATT-950-010-062IPTV : LTE GNG (Full) Requirements, Testing Process

and KPI RequirementsAbstract:

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 Practice ATT-950-010-062Issue 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.i

Table Of ContentsINTRODUCTIONGeneralReason For Current Issue1. About This Document 2

1.1. Purpose 21.2. Scope 31.3. Intended Audience 31.4. Related Documentation 31.5. Acronyms and Terms 41.6. Trademarks 41.7. Contacts 4

2. Scope and Goal 52.1. What is New in this Document Version? 72.2. Document Roadmap 7

3. Key Concepts, Requirements and Terminology 83.1. Key Terms 83.2. Other Key Terms 10

4. Pre-Optimization Activities 114.1. Responsibilities 114.2. Cluster Drive Route Definition and Approval Process 11

4.2.1. Drive Route Polygon Definition 114.2.1.1. Multiple Bands, Multiple Bandwidth Allocations, and Multiple Carrier

Considerations 12

4.2.1.2. Drawing the Drive Route Polygon 124.2.2. Drive Route Polygon Outputs 174.2.3. Cluster Drive Route Selection Requirements 184.2.4. Drive Route Outputs 19

4.3. IFHO Drive Route Selection requirements 204.3.1. IFHO Boundary Selection 214.3.2. IFHO Drive Route Requirements 214.3.3. IFHO Drive Route Outputs 21

4.4. IRAT Drive Route Selection Requirements 224.4.1. IRAT Boundary Selection 23



©2012 AT&T Intellectual Property. All rights reserved.ii

4.4.2. IRAT Drive Route Requirements 234.4.3. IRAT Drive Route Outputs 23

4.5. Approval Process for Drive Routes, Polygons, IRAT, and IFHO Routes 244.5.1. Instructions for HQ Submission Package: 25

4.6. Other Prerequisites 275. GNG Cluster Drive Collection Process and Requirements 27

5.1. Drive Route Key Concepts and Requirements 275.2. Responsibilities 275.3. Drive Test Hardware 28

5.3.1. Drive Test Equipment Requirements 285.3.2. Drive Test General Guidelines 285.3.3. Drive Test Equipment Calibration Requirements 29

5.3.3.1. Equipment Calibration Requirements 305.3.3.2. Scanner Antenna and Cable Testing 30

5.3.4. Cluster GNG Drive Test Configuration 315.3.4.1. Four possible configurations are listed in the table below: 315.3.4.2. Drive Test Equipment List and Configuration: refer to GNG Full Test

Configuration document. 31

5.3.5. UE Equipment 325.3.6. Drive Test Scripts 33

5.4. Testing Journal Requirements 335.5. Cluster Drive Requirements 34

5.5.1. Driving into Adjacent LTE Clusters – When Required 345.5.2. Inaccessible Drive Routes 34

5.6. Log File Naming Convention 355.7. Pre and Post Drive Checks Required 35

5.7.1. Pre-Drive Checks 355.7.2. Post-Drive Checks 36

5.8. Drive Collection Job Aid 366. IFHO and IRAT Drive Collection Process and Requirements 36

6.1. Responsibilities 367. LTE GNG Full Testing: Commercial vs. Non-Commercial Networks 36

7.1. Traditional Pre-Commercial Launch GNG Full Testing 377.2. GNG/Full Testing in a Launched (Commercial) Network 37

8. Drive Test Data Processing and KPI Requirements 37



©2012 AT&T Intellectual Property. All rights reserved.iii

8.1. Drive Test Processing Concepts and Key Requirements 378.2. Responsibilities 388.3. GNG Processing Software 388.4. Drive Data Log File Requirements – Maximum Measurement Window 388.5. Site/Cell Configuration Documentation 398.6. GNG Cluster Drive KPIs and Methods 39

8.6.1. GNG Drive Cluster KPIs 398.6.2. KPI Implementation in ActixOne Platform 458.6.3. Cell Aggregation Method 45

8.7. Exclusion Zones 468.8. GNG KPI Report 46

8.8.1. Contents of KPI Report Template 468.8.1.1. GNG KPI Report Parameter Audit 468.8.1.2. Serving Cells Audit 46

8.8.2. IFHO Tab 478.8.3. IRAT Tab 47

8.9. Uploading Drive Log Files to Server for GNG KPI Report Generation 478.10. GNG Processing Job Aid 478.11. GNG Drive Cluster Acceptance Criteria 47

9. Results Review and Approval Process 479.1. Responsibilities 489.2. Package Requirements to be Submitted for Review and Approval 489.3. GNG KPI Drive/Cluster Approval Requirements 48

9.3.1. Drive Routes & Drive Route Polygon Verification 489.3.2. Standard Cluster (10 to 30 sites) Requirements 499.3.3. Small Cluster (3 to 9 sites) Requirements 499.3.4. BAU/SSV Requirements 49

9.4. IFHO and IRAT Approval Requirements 499.5. Outputs and Notification of GNG KPI Approval Process 49

10. Incremental Sites BAU Process 4910.1. Incremental Sites Process Flowchart 4910.2. Pre-launch Activities 5010.3. GNG Team Approval Process 5110.4. Link to the PMO Organization web-based checklist 52

10.4.1. Sample of Web-based checklist 52



©2012 AT&T Intellectual Property. All rights reserved.iv

11. References 5312. Appendix A – Cluster Naming Convention for Polygons and Drive Routes 53

12.1. General Cluster Naming Convention 5412.2. File Naming Convention for polygons and Drive Routes 5512.3. Sub-Market Codes 56

13. Appendix B – 3 dB Coverage Rule Comparison 5914. Appendix C – Testing Journal Template 6115. Related Documents 6216. Acknowledgements 6217. Contact List 63

A.1. Document Specific Acronyms 63A.2. Acronyms Dictionary 63

Revision Log 63ACRONYMS 63



©2012 AT&T Intellectual Property. All rights reserved.v

General

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

Reason For Current Issue

Issue Number Date Description Published By

1 03/28/12 db694h

Authors set the change indicators in documents for important changes. Not all changed information may have beenselected 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 byAT&T Radio Access Network organization. Covered within this document are pre-launch activities, steps necessary forpre-launch network optimization, cluster drive requirements, and post processing of drive data as well as the generationof GNG report. Activities deemed secondary to the main focus of this document are given a more detailed treatment inseparate documents referred to herein as ‘Job Aid’. References and links to Job Aid documents are provided wherevernecessary.

Document Revision History

This table identifies content revisions made to this document.

Date Rev Revision Description Writer Sponsor

7/19/2010 0.1 Original Colin Bowdery Shane Morri-son

8/30/2010 1 Beta Release Colin Bowdery Shane Morri-son



2012 AT&T Intellectual Property. All rights reserved.1

Date Rev Revision Description Writer Sponsor

12/31/10 2 Version 1 Release Colin Bowdery Shane Morri-son

1/4/2011 D01 Draft #1 Development – restructuredand reorganized. Craig Palmer

3/8/2011 1.1D16 Added feedback from vendor Craig Palmer

4/19/2011 1.2Update the GNG full document basedon the internal discussion and thetesting in the commercial network

Ye chen, Craig Palmer, ShaneMorrison, Cheng Zhang

4/22/2011 1.3 Added KPI table, provided descrip-tions for various sub headings Craig Palmer/David Bhatta Orlando Davila

11/14/11 1.3 Added Incremental Sites BAU Proc-ess David Bhatta Orlando Davila

RACI

This table identifies RACI team members.

Accountable Responsible Consulted Informed

Gordon Mansfield Shane MorrisonYe Chen, Pradeep Kun-junny, Paul Hartman,Gram Lekutai

Hany Fahmy

Florian Ion Craig Palmer Nick Thompson

Kevin Hetrick Orlando DavilaErik Holmberg, OscarGarcia, Julius Fodje, Rob-ert Clark

Muhammad Gill, Lou Ficarra, Nico Vlok,Bill Weise

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

1.1. Purpose




The main purpose of the document is to outline the process for GNG approval of LTE cluster or super cluster and toprovide 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 infra-structure vendors for assessing LTE clusters and/or super clusters. The document is intended for use as a guideline forLTE 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 thedocument manageable. Furthermore, this document does not outline the end to end launch processes and must befollowed 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 reportgeneration.

• PMO - process and results tracking.

1.4. Related Documentation The following are related documents:

LTE GNG Data Analysis Process (aka “ATT LTE GNG Ac-tixOne Cookbook”) Link: ActixOne 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&TLTE GNG Metrics Description Link: LTE GNG Metrics Description

Drive Log Processing Procedure Link: Drive Log Processing Job Aid




https://operations.web.att.com/sites/GNG-HQ/LTE%20GNG%20Documents/GNG%20Full%20Documents/Suporting%20documents%20for%20LTE%20GNG%20Full%20Requirements%20and%20Guidelines%20document/ATT%20LTE%20GNG%20ActixOne%20Cookbook_V3%20.docx

https://operations.web.att.com/sites/GNG-HQ/LTE%20GNG%20Documents/GNG%20Full%20Documents/Suporting%20documents%20for%20LTE%20GNG%20Full%20Requirements%20and%20Guidelines%20document/ND-00369%20-%20LTE%20RF%20Network%20Design%20Guidelines%20-%20v1.4.pdf

https://operations.web.att.com/sites/GNG-HQ/LTE%20GNG%20Documents/GNG%20Full%20Documents/Suporting%20documents%20for%20LTE%20GNG%20Full%20Requirements%20and%20Guidelines%20document/GNG%20Full%20Drive%20Test%20Configuration.docx

https://operations.web.att.com/sites/GNG-HQ/LTE%20GNG%20Documents/GNG%20Full%20Documents/Suporting%20documents%20for%20LTE%20GNG%20Full%20Requirements%20and%20Guidelines%20document/2011.10.10%20-%20Rel6.00Rev1%20-%20GNG%20Metrics%20description.pdf

https://operations.web.att.com/sites/GNG-HQ/LTE%20GNG%20Documents/GNG%20Full%20Documents/Suporting%20documents%20for%20LTE%20GNG%20Full%20Requirements%20and%20Guidelines%20document/Drive%20Log%20Processing.docx

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.xlsxYou 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.xlsxYou 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 terminologyare 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




https://operations.web.att.com/sites/GNG-HQ/LTE%20GNG%20Documents/GNG%20Full%20Documents/Suporting%20documents%20for%20LTE%20GNG%20Full%20Requirements%20and%20Guidelines%20document/LTE%20Drive%20Route%20Template%20for%20HQ%20Submission.xlsx

/books/ATT-950-010-062/figures/RAN - ALU LTE LA3 0 Gold Standard.xlsx

/books/ATT-950-010-062/figures/RAN - Ericsson UMTS Gold Standard.xlsx

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 “ElementAcceptance”) in Attachment H of the LTE contract (See diagram below). The scope of this document is directly related tocluster GNG KPIs testing.




mailto:[email protected]

mailto:[email protected]

Given this specific scope, the following are considered outside the scope of this document and are covered in separateprocesses 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 asubset 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 underGNG-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 distinguishthis 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 KPIsdo not constitute approval to launch and unbar a cluster for commercial service. In order to launch and unbar acluster (or multiple clusters), a separate launch approval process is utilized using a comprehensive “pre-launch




checklist.” The GNG KPI results and GNG KPI approval (scope of this document) is one of many inputs into thepre-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:




• 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 thecontractual 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 OCNS feature but different names.

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 isdefined as part of the RF Design process. A site can onlybelong to one cluster and once a site is assigned to a particularcluster during the design, it shall not be assigned to anothercluster. A cluster covers a contiguous geographic area.Furthermore, a cluster is composed of sites of the same LTEbandwidth and frequency band.

Contractually, cluster size ranges from 10 to 30 sites with therecommended average of 20 sites.




The cluster assignments must match what is contained in thecertified LTE design.

Super Cluster

A Super Cluster is composed of a group of 2 or more contig-uous clusters consisting of no more than 100 sites. The SuperCluster concept is contained in the LTE RF Engineering guide-lines as a means to support more efficient RF Design KPIs.Ideally, launching commercial service is done on a supercluster basis to minimize cluster boundary re-optimizationeffort--but is not always practical.

Super Clusters are not defined in the LTE contract.

Hard KPI (Gating)A KPI based on processing of drive data which must be metas a condition to “pass” a cluster and meet “Element Accept-ance” contractual stipulations. Also known as a ”gating KPI.”

Soft KPI (Non-Gating)

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

“Cluster Drive Test”

A drive test with purpose of determining the performance with-in a single cluster. The scope is generally limited to driving onlywithin the cluster (except as other specified in these proce-dures). Testing of IFHO and IRAT as UEs exit the cluster areNOT included in the “Cluster Drive Test” but are done as aseparate drive test.

“IFHO Drive Test”

A drive test specifically aimed to testing IFHO functionality asUE leaves a (set of) cluster(s). Sometimes this is referred toas “IFHO Exit Routes”. Depending on the overall LTE servicearea being deployed, IFHO may not be required. This drive testsignificantly differs from the “Cluster Drive Test” and is con-ducted separately from Cluster drives.

“IRAT Drive Test”

A drive test specifically aimed to testing IRAT functionality asUE leaves a (set of) cluster(s). Sometimes this is referred toas “IRAT Exit Routes” This drive test significantly differs fromthe “Cluster Drive Test” and is conducted separately fromCluster 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 LTEclusters in the same LTE band. Some describe this as an “is-land” of LTE coverage. For this purpose, the drive testing doesnot need to consider same-band handovers into adjacent clus-ters.




Expansion Deployment

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

Dual Carrier Cluster

This describes a cluster which is being deployed (andlaunched) with multiple LTE carriers on the same sites. Thedistinguishing character is that both bands must be separatelyevaluated via GNG/Full testing. That is, a GNG/Full process(including report) must be conducted for 700 MHz and a sep-arate drive and report be done for the AWS carrier.

2nd Carrier (Multi)

This describes a cluster which is being deployed with a secondLTE carrier over an already launched LTE carrier. The distin-guishing character is that a “first carrier” is already in commer-cial 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 clustersearly (Lite-Launch) to meet competitive or other business ob-jectives. The GNG-Lite process is outside the scope of thedocument.

Lite-Launch(ed) Cluster

A lite-launched cluster is a (full ~ 20 site) cluster where oneor more of the sites within the cluster have been unbarred forcommercial service (liate-lite launches are verified and ap-proved using the GNG-Lite process). An important distinctionis it retains the formal cluster definition of all sites within thecluster. For example, …(add)

ICD

“Implementable Cluster Design” A RF Design output reflectingthe site and cell configuration which is expected to be con-structible for launch. This is based on C&E feedback from thePICD.

PICD“Preliminary Initial Cluster Design”. A RF Design output re-flecting the site and cell configuration based on the best pos-sible RF design prior to C&E review for constructability.




Element AcceptanceA contractual process as outlined in attachments relating tothe delivery, installation, implementation, and rollout of LTEservice 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 beforethe 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 togenerate the cluster drive route polygon, cluster drive routes, IFHO and IRAT drive routes, and submit these packagesfor 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) whereAT&T coverage maps would show coverage (i.e. the Drive Route Polygon) and b) that the drive routes for each clusterhave sufficient density and are properly defined prior to any optimization and GNG drives activity in the cluster. The driveroutes 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 iscovered in the LTE RF Design Guidelines (see References). A timely submission is required due to the expected volumeof 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. Thegeneral rules for drive route polygons:

• The polygon boundary will be based on ATOLL RSRP signal level (outdoor) plots from the approved optimized ICDfollowing 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.




4.2.1.1. Multiple Bands, Multiple Bandwidth Allocations, and Multiple CarrierConsiderations

The polygon definition process depends on if the cluster (and surrounding clusters) have multiple bands (i.e. AWS and700 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 fordual band LTE and LTE carrier addition.

Condition Polygon Definition

All sites in cluster same carrier frequency andbandwidth 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 levelpredictions 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.

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

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

• Be sure to save any existing CZ first.

4. Generate a RSRP plot reflecting -107 dBm OUTDOOR coverage.

• Prediction > New > Effective Signal Analysis (DL)




• Configure the “Conditions Tab” as follows:

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

• Configure the “Display” tab as follows:




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

• Run the prediction.

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




NOTE: The red line indicates the outer extent of the LTE service area at -107 dBm RSRP. This may be drawn inATOLL 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 beexcluded 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 SignalLevel” selected.

• Run the coverage

A representative plot is shown below:




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 basicrules:

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 andcells in adjacent clusters.

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

• An example:




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

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

• The full description of cluster naming convention is contained in RF Design Guidelines. However, an extractis 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 marketand 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.




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 sectionpresents 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 exceptionprocess 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 extend2 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, theseextended routes into the first 2 tiers need not be driven as part of this cluster. However, for the purpose of driveroute 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




• Sufficient density Roads so that in urban and heavy suburban areas that minimum density of approximately ½ mileis 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 ofdrive 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:




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 aseparate KPI report for for IFHO drives. When IFHO drives are required, the reports generated only look for successfulIFHO 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 nextsections of this document:




• 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. Seethe 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 IFHOperformance.

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-carrierrequirements 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 pernorth 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:




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 clusterbasis. When IRAT drives are required, the reports generated only look for successful IRAT events and do not considerperformance 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 nextsections of this document:

• Identification of IRAT boundaries

• Selection of Drive Routes.




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. Foran 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 IRATperformance.

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 routesconsist 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 asthe 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:




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 IFHORoutes All drive route polygons, cluster drive routes, IFHO drive routes, and IRAT drive routes must be approved by AT&T at twolevels:

• 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 besubmitted to HQ RAN for approval. Submission should be done in a timely manner as outlined in a previous section.




The HQ submission package must include the Drive Route form which can be found at National Sharepoint . Instructionsfor 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:

A. Full cluster name (MMMM_CL_SC_BAND_BW)

B. Cluster number

C. Super Cluster number (or NA)

D. LTE Band

E. LTE Bandwidth

10. 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 theproposed 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




https://operations.web.att.com/sites/GNG-HQ/LTE%20GNG%20Documents/GNG%20Full%20Documents/Suporting%20documents%20for%20LTE%20GNG%20Full%20Requirements%20and%20Guidelines%20document/LTE%20Drive%20Route%20Template%20for%20HQ%20Submission.xlsx

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 surroundingclusters. (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 theproposed 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 respec-tive cluster.

Submissions may contain multiple clusters for the same market. Simply create new tabs for each cluster. IFHO and IRATexit 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 approveroutes prior to submitting to national RAN.




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 requirementsare 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 toprocure required test equipment and drive the cluster as outlined in this section.




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 set of test equipment and test method.

Device Manufacturer/Model Notes

UE1 AC313U LTE/UMTS data card with approvedfirmware. Long Data Call

UE2 AC313U LTE/UMTS data card with approvedfirmware. Short Data Call

UE3 AC313U LTE/UMTS data card with approvedfirmware. Latency

UE4 (Future) TBD CSFB

Laptop Minimum Specifications to be determined byGNG field test team.

Scanner 1PcTel EX (Note 1) or PcTel MX supportingGSM/UMTS/LTE (option 2, if chosen, ignoreScanner 2)

LTE (PcTel EX) or GSM/UMTS/LTE(PcTel MX)

Scanner 2 PcTel EX (Note 1) UMTS/GSM

External Scan-ner Antenna

Minimum Specifications to be determined byGNG field test team. Vertical Polarized Magmount 0 dBi gain

Collection Soft-ware Nemo Outdoor

5.3.2. Drive Test General Guidelines




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

• UEs must be placed head level with minimum horizontal separation of 43cm/17in (700 MHz) when they are in thesame 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 providedby 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 vehicleroof 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 validUE 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, Extensionpower 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 otherdevices 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 outlinedin the following sections.




5.3.3.1. Equipment Calibration Requirements

To assure accurate results of drive testing, monthly calibration and/or verification of the following equipment must beconducted:

• 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 3GPPspecifications for RSRP signal level (even if marginal, it should be replaced); and b) the antenna should be within 1 dBof gain specification. If the equipment is found to not meet these requirements (or marginal), then it should be retired andnot 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 follow-ing simple in-field test process should be used to verify cable and antenna integrity:

Item Daily Monthly (in market)

Antenna(s) Visual Inspection

Verification Measurements

Footnote: 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 than1.xxxx VSWR).




5.3.4. Cluster GNG Drive Test Configuration

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

Configura-tion Description

Total Number ofUSB ports Re-

quired

No. of USB HUBRequired( *USB

Hub should have apower supply)

No. of USBports on Lap-top Required

No. of ScannerReceiver Anten-

nas Required

1One PCTEL MX scannerwith the External GPSconnection

8 1 4 2

2One PCTEL MX scannerand GPS connectionfrom the scanner

7 1 4 2

3

Two PCTEL EX Scan-ners and GPS connec-tion from one ExternalUSB port

9 2 4 3

4

Two PCTEL Ex scan-ners and GPS connec-tion from one of the EXscanners

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 TestConfiguration document.




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 FrequencyHO)

Test Description TCP traffic will be sent continuously until end of testing or drop. If drop, the iPerfsession will automatically restart. Testing will be bidirectional.

Required Setting(s)

Locked to LTE Band or Channel

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 FrequencyHO)

Test Description

TCP traffic sent for a period of ~8 seconds with a pause of 10 seconds betweencycles.. (2 MByte File Size

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

)

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




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 containthe 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 8hour 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):




• 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 clusterdrives 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 mustextend 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 exceptionmust 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.




5.6. Log File Naming Convention Drive log files are named as:

AAAA_B_C_D_E_(timestamp).F.nmf

Where

AAAA = submarket codeB = cluster numberC = super cluster numberD = band indicator (“7”=700MHz, “A”=AWS)E = LTE Bandwidth (“5M”=5MHz, “10M”=10MHz) (timestamp) = Nemo logic for timestamp at the start of loggingF = 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 thefields are case sensitive.

For example, a drive conducted in the Orlando submarket, cluster 9, super cluster 3, in the 700MHz band and with 10MHzbandwidth 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 beingintegrated 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 willaffect this cluster.




• 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 journalsheet.

• 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 asdocumentation.

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 forprocuring 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 UMTScase. 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 networkwhere AT&T has the full control on the network. With the competitive business need to launch networks prior to GNG Full




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

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 require-ment)

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 iscovered 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 ClusterDrives 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. Manyof the concepts and requirements are further elaborated in subsequent sections.

• AT&T will utilize the ActixOne centralized enterprise solution for all KPI reporting.




• 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 thiscase, the time of day that drives may be conducted will be restricted and certain KPIs will be considered “soft” insteadof “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 andIRAT 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 generatingKPI, 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. Thevendors 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 interms of the processing and test report support.

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




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 templateincludes:

• 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 Reportshall cover just one cluster. In cases where multiple clusters need to be reviewed at one time, multiple reports will haveto 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 theLTE RF Design Guidelines). Note that the ACTIX template will contain additional soft KPIs above and beyond these AT&TKPIs.

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 inblue).




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




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 onthe 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




• 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 servingcell.

8.7. Exclusion Zones GNG KPI performance is to be evaluated over a “geographic area” or cluster. The intent is to provide LTE service overthe entire cluster meeting KPI targets.

For LTE deployments, no exclusion zones will be granted for missing sites. It is expected that “Green GNG KPIs” mustbe 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 andmarket approval, exceptions for edge sites may be granted. However, any jeopardy site within a LTE service polygon willnot 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 acomparison to “AT&T golden parameters”. This is designed to supplement, not replace, the full parameter audit done aspart of the pre-launch checklist. This is a new report feature compared to UMTS.

8.8.1.2. Serving Cells Audit




The GNG template will include a tab listing all cells which actively served call sessions during the drive sessions. This isenvisioned 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 UMTStemplate will be used as a model.

8.9. Uploading Drive Log Files to Server for GNG KPI ReportGeneration A separate “job aid” document will be developed and provided with specific step by step requirements to upload log filesand 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 IRATreports. 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.




https://operations.web.att.com/sites/GNG-HQ/LTE GNG Documents/GNG Full Documents/ATT LTE GNG ActixOne Cookbook_V3 .docx

9.1. Responsibilities The OEM vendor (or party which will conduct the GNG drives and prepare the GNG results for approval) is responsiblefor 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 thescheduled 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 zonesare 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 theadjacent cluster is a) launched, b) lite-launched, c) has already passed GNG testing.




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 andmeet 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 thesame GNG KPI criteria as standard clusters. Very small clusters (such as 3 sites) may have difficulty meeting all KPIsdue to fewer overall samples. When small sample size is adequately shown to be the cause of not meeting a KPI in asmall 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 launchmarket. The process is illustrated in a flowchart below.

10.1. Incremental Sites Process Flowchart




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 daytime hours only (or at a time approved by AT&T). Site/s may only be unlocked while on site and must be locked atthe conclusion of on-site testing.




3. Vendor applies Golden Parameters to the site/s and begins alarm monitoring. Vendor may unlock sites only duringthe 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 daytimehours. Sites may only be unlocked while on site and must be locked after the test is completed. The requirement tolock the sites during the day for site shakedown or for alarm monitoring/clearing and unlock them at night is to avoidinterference to the commercial network and handover from commercial sites.

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

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

8. If approval is granted, vendor will then proceed with unlocking the sites for commercial operation, thus triggeringthe formal transfer of site operation from the vendor to AT&T. A notification to this effect must also be made to ATSand 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 plannedlaunch.

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 priorto submitting the checklist. In general, all questions and issues from vendor must come to GNG HQ through LTEPM.

3. Vendor shall provide daily alarm reports for the sites to be launched to GNG HQ. Sites must be alarm free for atleast 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 GNGHQ 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 within24 hours of the request.




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 Teamrepresentative responsible for the market). A sample email can be found in the attachment below.

RE LTE GNG Dallas GRP2B checklist copy.rtfYou 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 repre-sentative 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




/books/ATT-950-010-062/figures/RE LTE GNG Dallas GRP2B checklist copy.rtf

http://mesapplications.web.att.com/LTE/view/index_view.cfm

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 DriveRoutes 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:




• 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 clusterboundaries. In this section, the generally cluster name is covered. In the next section, the naming convention for driveroute 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 formallydefined in the following sections. The naming convention format is:

SMKT_Cluster#[Rev]_SuperCluster#_Band_BW

Example:DFWX_7_2_7_10M (Dallas, Cluster 7, super cluster 2, 700 MHz, 10 Mhz BW) Where:

Field Description Type

Sub-Market Identifier (SMKT)Submarket identifier (4 characters) us-ing the standard AT&T submarket co-des (table later).

4 Characters Mandatory

Cluster Number

Cluster Number within this sub-market.See important notes on keeping thiscluster number unique.

Revisions to Existing Cluster Numberare covered in ND-369.

Numeric, no leading zeros.

Revision: Single Alpha Character whennecessary.

Super-Cluster

Super Cluster Number. A super clusteris composed of multiple contiguousclusters. In cases where super clusteris not applicable, identify as “NA”.

Numeric, no leading zeros. “NA” whennot applicable.




Field Description Type

Frequency BandFrequency band for this cluster. Notethat a cluster is always for a specificfrequency band.

“7” for 700 MHz“A” for AWS band

LTE Channel BandwidthBandwidth (5 of 10 MHz) of this cluster.Note that a cluster is always for a singlebandwidth.

“5M” for 5 Mhz bandwidth;“10M” for 10 MHz 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 theprevious section. There are covered in more detail in the GNG/Full Guidelines.

Polygon Purpose File Naming Examples Notes

GNG/Full Cluster DriveRoute Polygon DRP_(Cluster_Name).* DRP_DFWX_6_2_7_10M.* Note 1

Cluster Drive Routes DR_(Cluster_Name).* DR_DFWX_6_2_7_10M.* Note 2

IRAT Exit Routes IRATDR_(Cluster_Name).* IRATDR_DFWX_6_2_7_10M.* Note 3

IFHO Exit Routes IFHODR_(Cluster_Name).*IF-HODR_DFWX_6_2_7_10M.* Note 3

Note 4

Notes to above table:




1) The boundary file for cluster 6 (in supercluster 2) for drive route processing of GNG/Full data. This polygon file will beused to define the extent of drives for this specific cluster as well as for ACTIX® process of GNG results as part ofcontractual acceptance.

2) This is file name for drive routes to be driven in cluster 6 (in supercluster 2) for GNG/Full testing. See GNG/Fullguidelines 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. Thistable 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





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





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





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 followingalgorithms—one for 700 MHz deployment and the other for AWS band deployment:




B.1 – 700 MHz Algorithm:

B.2 – AWS Algorithm




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




Serial Numbers:

Scanner (LTE)

Scanner (UMTS/GSM)

Scanner (GSM)

LTE UE (1)

LTE UE (2)

LTE UE (3)

Start OSS Alarm Free(Verified by) LTE UE (4) N/a

End OSS Alarm Freeduring Drive Period(Verified by)

Loading:DL: 50% - OCNS

UL: 0%

Notes:

Add Inaccessible Drive Route section

Add type of drive: Cluster Drive, IRAT drive, or IFHO Drive to journal

Add last Calibration Date, last sweep date.DateStart Time.

Test Engineer: Jack Smith

Test Coordinator: Sue Edge

15. Related Documents

16. Acknowledgements




17. Contact List

Name ATTUID Phone # Department / Responsibility

David Bhatta db694h 847-765-6275 HQ RAN GNG Team/ LTE & UMTS Launch Reviewand Approval

Orlando Davila od2163 847-765-3601 HQ RAN GNG Team/ RAN Area Manager

Revision Log

Issue Number Date Description Published By

1 03/28/12 db694h

Acronyms

A.1. Document Specific Acronyms N/A

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




http://apex.web.att.com/bookview/bookview.jsp?bookname=ATT-000-000-020&section=atdoctitle

lte gng (full) requirements, testing process

Documents

cluster drive requirements

irat drive route requirements

ifho drive route requirements

irat drive route outputs

ifho drive route outputs

drive test hardware

drive test scripts

cluster drive route