ncf_fn

mtxswfn

19

1. Functional description (FN)

1.1 Feature title

Network Configuration File Definition

1.2 Feature synopsis

This feature defines a new Network Configuration File (NCF) to support theCDMA neighbor databases. This file is the input into the BSM toolcheckneighbor.exp. This updates/verifies the integrity of both the BTS Sectorand PilotDatabase Managed Objects(MO).

Both of these MOs have duplicated data whose values may becomeinconsistent (e.g. neighborlists for all sectors appear in each of those MOs, yetthe values of the neighborlists must be the same). Using checkneighborprevents skewing of the values. Also, these tools are necessary because theneighbors change quite frequently and standard Command Line Interpreter(CLI) does not provide enough support for this.

The database engineer can choose whatever frontend tool to manage/store theBase Transceiver Subsystem (BTS) information; however, it must be able toemit this data into the new format. The following goals are defined:

• Easily formatable from other tools such as Excel spreadsheets and 4GLdatabase languages.

• Provide clear migration from NBSS07 strategy to new NBSS08 commonunified configuration database.

• Readability is not as important as formatability but the user needs to beable to read the format.

• Make syntax compatible with the C preprocessor so that the databaseengineer “can” use the CPP utility for macros, include files, andconditional expansion with the following command:

cpp -P myinput.ncf > myinput_with_macros_expanded.ncf

20 Functional description (FN)

mtxswfn

This features fixes SR, DA71300 with the following enhancements:

• One flat file table is easily importable from a spreadsheet/4GL database.

• Duplicate BTS names on different BSCs

• Incrementally updating different sectors without changing all othersectors.

• Replacing thesetneighbor script with acheckneighboroption.

• Support for 800 MHz and 1900 MHz base stations with the new 6.2 MOhierarchy.

• Support for more than 4 SBS with user-definable names.

• Support for multi-carrier.

• Support for the NGHBR_CONFIG field.

• Support for user definable cell names.

• Hard handoff targets

• All fields in the Pilot Database (PDB) entry are settable from this file.

• Additional verification on the correctness of the neighbor list and otherdata attributes. This includes the following checks:

— Consistency of band and frequency among all entries in the neighborlist.

— Defining remaining sectors in the same cell in the neighbor list.

— Neighbors should be self-referential; they should appear in eachother’s neighbor lists.

— No duplicate PILOTs in the neighbor list.

— Neighbor’s PILOTs are multiple of the PILOTINCR value.

— Neighbors are on the same BSC.

— All soft handoffs into a pilot beacon are defined in the pilot beacontarget list.

— Definition of a target list for celltypes Pilot Beacon, Border, andEHHO.

— Checking for cell id and cell name consistency for all sectors in thecell.

— Defining all sectors in a tri-sector cell.

— Not defining tri-sectors and omni sectors in the same cell.

— Comparing NCF defined neighbors against those in both the SectorMO and Pilot Database entries.

Functional description (FN) 21

mtxswfn

— Comparing frequency against the BTSC MO channel list and theFrequencyAssignment ChannelList.

— Comparing NCF band against BTSC MO’s BandClass.

— Comparing NCF cellids against the BTSC MO’s cellid value.

— Comparing Pilot_PN and PilotIncr in the Sector MO against the NCFvalue.

— Comparing T_ADD, T_DROP, T_COMP, T_TDROP,SRCH_WIN_N, SRCH_WIN_R, and SRCH_WIN_A in the SectorMO.

— Comparing the entire Pilot Database entry against the NCF file entry.

— Verifying consistent BCN address across all sectors in the cell.

1.3 Functional overview

The NCF is the input into thecheckneighbortool. This tool then both updatesand queries to the Base Station Manager (BSM) through the CommandLanguage Interpreter (CLI).

The NCF is a common intermediate format to be created by any database/spreadsheet tool. The following is the information flow for the usage:


mtxswfn

Note, rounded boxes are applications, rectangles are files, and ellipses areMOs.

Thecheckneighbor tool currently provides the following support:

• Pings Base Transceiver Subsystem (BTS) (checking to see if it is NIPrunning)

• Checks PILOT_INC on the BTS sector.

• Checks the BTS extended neighbor list for correct PN offset on the BTSsector.

• Looks for sector definition in the Pilot Database MO.

• Compares the neighbor lists in both the PilotDatabase and the BTS to theNCF format.

Database Engineer

Excel

OracleDB

Emacs Editor

NCFcheckneighbor.exp

CLI

BTS Sector MO

Pilot DatabaseMO.

Tool Support Base Station Manager

checkneighbor.log


mtxswfn

Thesetneighbor script does the following:

• Pings the BTS.

• Sets the PILOT_INC in the extended neighbor list in the BTS sector.

• Updates the neighbor lists in both the Pilot DB and BTS Sector MOs.

This feature provides all of this functionality, and augments it with theenhancements defined in section 1.2 of this document. It delivers the followingexecutables into /opt/bsm/bin:

• checkneighbor

It creates an executable ncfconv inside the /opt/bsm/pbin directory.

An example of the new ncf format is in/opt/bsm/util/doc/example.ncf, and acopy of this FN is also located in/opt/bsm/util/doc/ncf_format.ps.

Lastly, this feature does not support the old formats of NCF.


mtxswfn

1.4 Feature description

The NCF contains four components: template, SBS list, updates list, and table.The template defines the layout of the table, the SBS list defines all of theSBSC Subsystems, and the table is the columnar input of data. Each row in thistable represents a sector, and each column represents attributes of the sector.

The following sections describe the file format:

• Template

• SBS List

• Updates List

• Table

• Lexical Components

• Rules enforcement

• Command line options

1.4.1 Template

The first line must begin with the following expression:

/NCFV8.0=template

The template is a comma list of keywords where each keyword represents acolumn in the table. The following are the possible keywords:

• KEY: 32 character identifier to uniquely label the sector. MANDATORY.

• CELLNAME : 32 character identifier for the cell such as MiniBTS8MANDATORY.

• CELLID : Numeric value for the logical cell id. MANDATORY.

• BAND: Enumeration of 1900, 800, AMPS or UNKNOWN.MANDATORY.

• FREQUENCY: Numeric value. MANDATORY.

• SECTOR: Enumeration of Alpha, Beta, Gamma, Omni, SECTOR[n, 4-15]. MANDATORY.

• MSCID_MKT : Numeric value describing the MSC Mkt Id.MANDATORY

• MSCID_SWNO: Numeric value describing the MSC Switch Number.MANDATORY

• BSCID: Numeric value describing the BSC. MANDATORY


mtxswfn

• PILOT_PN : Number between 0 and 511. Note, the BTSC Sector MOmust either be locked or uncoupled for this field to be changed.MANDATORY

• NEIGHBORS: Comma list of keys describing each of the neighbors.OPTIONAL

• BTS_NEIGHBORS: Comma list of keys describing each of the neighborsof the BTS. If this is column is not defined, the BTS neighbors are set bytheNEIGHBORS field. This list has three items for each neighbor: key,neighbor config value, and priority. It appears as the following with KEY1having a config value of 1 and priority of 2:

KEY1, 1,2,KEY2,3,4

The BTS neighbor list will use the NEIGHBORS column if either thiscolumn is not present or this list is empty for this entry. This field isoptional.

• BORDERTARGET : Comma list of target cells for Border handoffs.OPTIONAL

• BEACONTARGET : Comma list of pairs target cells and pilot pns forPilot Beacon handoffs. This following example has 3 targets, 2 with thePILOT_PN of 251,

251,KEY1, 200, KEY2, 251, KEY3

This is OPTIONAL.

• EHHOTARGETCELL : Comma list of target cells for EHHO.OPTIONAL

• CELLTYPE : Enumeration Standard, Pilot_Beacon, EHHO, and Border.OPTIONAL

• QUICKREPEAT : True or False for quick repeat. OPTIONAL

• FORWARDGAIN : Numeric value describing the forward gain.OPTIONAL

• BorderRefPilotRTDThresh: RTD delay to trigger border handoff.OPTIONAL

• EHHOFERMAXFWD : Trigger for EHHO. OPTIONAL

• EHHOFERMAXRVS : Trigger for EHHO. OPTIONAL

• EHHOFERMODFWD : Trigger for EHHO. OPTIONAL

• EHHOFERMODRVS : Trigger for EHHO. OPTIONAL

• EHHOTCGMAX : Trigger for EHHO. OPTIONAL

• EHHOEBNOMAX : Trigger for EHHO. OPTIONAL

• EHHOWINDOWSIZE : Size of EHHO Window. OPTIONAL


mtxswfn

• CAPACITYTHRESHOLD : Numeric value for capacity threshold.OPTIONAL

• FREQUENCYPRIORITY : Numeric value for frequency priority.OPTIONAL

• T_ADD: Numeric value for adding pilots. OPTIONAL

• T_DROP: Numeric value for dropping pilots. OPTIONAL

• T_TDROP: Numeric value for drop timer value. OPTIONAL

• T_COMP: Numeric value for comparing pilots.OPTIONAL

• T_ADD_OFFSET_A: Numeric value of add offset.OPTIONAL

• T_ADD_OFFSET_B: Numeric value of add offset. OPTIONAL

• T_DROP_OFFSET_A: Numeric value of drop offset. OPTIONAL

• T_DROP_OFFSET_B: Numeric value of drop offset. OPTIONAL

• T_TDROP_OFFSET_B: Numeric value of tdrop offset. OPTIONAL

• DELTA_3 : Numeric value for difference between strongest and third pilot.OPTIONAL

• DELTA_4 : Numeric value for difference between strongest and the fourthpilot. OPTIONAL

• DELTA_5 : Numeric value for difference between strongest and the fifthpilot. OPTIONAL

• DELTA_6 : Numeric value for difference between strongest and the sixthpilot. OPTIONAL

• SRCH_WIN_A: Numeric value for search window of activeset.OPTIONAL

• SRCH_WIN_N: Numeric value for search window of neighbor set.OPTIONAL

• SRCH_WIN_R: Numeric value for search window of remaining set.OPTIONAL

• BTS_CRM_ACNAddr : Numeric value for the CRM ACN address.OPTIONAL

• NGHBR_CONFIG : BTS Neighbor configuration numeric value.OPTIONAL

• SEARCHPRIORITY : BTS Neighbor search priority numeric value.OPTIONAL

• MultiPilotHHOEnabled : Enable multi-pilot targets, TRUE or FALSE.OPTIONAL

• PILOTINCR : Numeric value for the pilot increment in the neighbors list.OPTIONAL


mtxswfn

• PILOTGAIN : Numeric value for the pilot channel gain in the sector.OPTIONAL

• SYNCGAIN : Numeric value for the sync channel gain in the sector.OPTIONAL

• PAGINGGAIN : Numeric value for the paging channel gain. OPTIONAL

• BASE_LAT: Numeric value for the latitude in the base station.OPTIONAL

• BASE_LONG: Numeric value for the longitude in the base station.OPTIONAL

• BASE_CLASS: Numeric value for the class of base station. OPTIONAL

• NGHBR_MAX_AGE : Numeric value for the maximum age of the entriesin the neighbor list. OPTIONAL

• PWR_REP_THRESH: Numeric value for the power repeat threshold inthe BTS. OPTIONAL

• PWR_REP_FRAMES: Numeric value for the power repeat frames.OPTIONAL

• PWR_THRESH_ENABLE : Numeric value for the power thresh enablebit. OPTIONAL

• PWR_PERIOD_ENABLE : Numeric value for the power period enable.OPTIONAL

• PWR_REP_DELAY: Numeric value for the power reply delay.OPTIONAL

• RESCAN: Numeric value for rescan ability.OPTIONAL

• NUMOFOCNSCH: Numeric value for the num of ocns channel.OPTIONAL

• MCBTS: Enumeration of either BTS or MCBTS (AFTER V7.1). Defaultis BTS. OPTIONAL

Note, the presence of AMPs is to support multi- mode hard handoffs. AnAMPS entry requires the fields of MSCID_MKT, MSCID_SWNO, CELLID,and SECTOR. All of the other fields are ignored.

An example of the list would be the following:

KEY, IGNORE_LATITIU, BSCID,IGNORE_AZIMUTH, BAND, FREQUENCY, NEIGHBORS,CELLNAME,SECTOR, MSCID_MKT, MSCID_SWNO, CELLID, PILOT_PN

All except NEIGHBORLIST (Optional, the rest are mandatory) needed to bethere; however, it is order independent. The user defines the order of thecolumns. A line of input in the file is assumed to be one sector.


mtxswfn

If the user has a column to be ignored, they merely prefix an identifier with thekeywordIGNORE .

Note, no range checks are performed by these tools beyond simple typetesting. These tools are integrated with the CLI, and it is the responsibility ofthe CLI to verify complete data integrity. Replicating the same data integritychecks in both places will lead broken code as future versions are released.

The concept of Extended Base Id is referenced many times when reportinginformation about an entry inside the Pilot Database. The Extended Base Id isa value derived from the following fields:

• Band (1900 vs. 800 vs. UNKNOWN)

• Cell Id

• Frequency

• Sector

The NCF format manages this conversion; however, the Extended Base Idmust be used when reading the Pilot Database MO within the CLI. Note, theExtended Base Id is the unique key.

1.4.2 SBS List

The SBS list must be on the second line of input. This defines all the SBS thatexist for the system. The following is the syntax:

/SBS=list

The list is a comma list of identifiers where each identifier is the relative (notabsolute) name for the SBS Subsystem V5 MO. The following is an example:

/SBS=SBSCSubsystem1, SBSCSubsystem2

The /SBS list is optional in V8.0 and beyond. When the /SBS list option is notpresent, the pilot database is assumed to be the system configuration pilotdatabase MO:

O%:CBS1:SystemConfiguration1:SystemPilotDatabase1

1.4.3 Updates List

The user may provide an optional directive listing all of the sectors to update.This must follow both the template and the SBS list definitions. The syntaxbegins with the “/UPDATE=” keyword followed by a comma list ofSECTORS.


mtxswfn

/UPDATE=DALLAS_8A, DALLAS_8B, DALLAS_8G

All sectors will be updated/checked when this directive is not present.

1.4.4 Table

The table consists of rows and columns. Each column is described by thetemplate.

Each row corresponds to a sector in the CDMA environment. Each line ofinput is a row, and a lexical escape “\” immediately before the “end-of-line”may be used if the row exceeds more than one line.

The “key” is an identifier used when referencing that row in the database fromanother row. This is necessary for both NEIGHBORLIST and HARDHANDOFF support. An example is in the section 1.8.

The NCF input file may have some keys representing sector records belongingto other systems (with a different MKT_ID, SWNO and BSCID). Theseentries are necessary to represent the hard hand off targets for local systemsector records.

1.4.5 Lexical Components

The following are the lexical components in the language

• Whitespace/Delimiters: These are characters that have no meaning otherthan to separate key fields. A stream of whitespace characters is scannedto the equivalence of one character. The following are whitespacecharacters: space and tab.

• Identifiers: An identifier may be any combination of alphanumericcharacters upto 32 characters. The following characters are allowed to bein the word (case-insensitive): A-Z,0-9,@,$,%,&,_,<,>,?.

• Numbers: Any positive/negative numeric value may be expressed here. Anegative value must be preceded with a “-”. Also, a hexadecimal numbermay be used, and it begins with “0x”.

• Boolean: A boolean begins with either a “T” or “F” value. “T” stands forTRUE (e.g. Multipilot is enabled), and “F” stands for false.

• Comma Lists: A comma list is a list of one or more identifier. Eachidentifier in the list is separated by only one comma and any number ofwhitespace characters. A comma list may contain only one identifier;however, no comma is necessary.

• Empty Comma List: The “*” is used to mark a field as containing an emptylist.


mtxswfn

• End Of Line Comments: The characters “//” comment out all text until theend of line.

• Multi-Line Comments: The characters “/*” mark the start of a commentand the characters “*/” mark end of comment.

• Lexical escape: All records are read as line format. The “\” at the very endof a line is used for line continuation. Note, this is very important since thetermination of a record coincides with the termination with the line ofinput. Also, this is really a lexical escape with preserves the subsequentcharacter from having any meaning.

1.4.6 Rules Enforcement

Three types of error messages are produced to the user through “stderr”:ERROR, WARN, and INFO. When an error message is produced, allprocessing stops. When an informational message is produced, the message isdisplayed but processing continues. WARN is a more severe case of INFO. AWARN message permits the checkneighbor script to continue; however, thenature of the error probably may disrupt CALLP when datafilled.

A) The following messages are produced duringnetwork topology analysisperformed on the ncf input file

The following conditions will produce ERROR messages (messages that stopprocessing):

• Bad command line arguments. Ex missing input file

• Undefined keys used in neighbor lists and hard handoff targets.

• Duplicate keys in the /NCFX.X template and /SBS list.

• Target lists exceeding the limits (Like having more than 6 border targets)

The following conditions will produce INFO messages (message that permitprocessing to continue):

• Not defining remaining sectors of the same cell in the neighbor list.

• Neighbor should be self-referential; they should appear in each other’sneighbor lists.

• Neighbors are on the same BSC.

• Not defining all sectors in a tri-sector cell.

• Checking for cell id and cell name consistency. Two records having the cellid but different cell names.

• defining tri-sectors and omni sectors in the same cell.

• Checking for cell type and target list. Ex If a sector/cell is defined as Pilotbeacon and there are no pilot beacon targets defined.


mtxswfn

The following conditions produce a WARN message:

• Consistency of band and frequency among all entries in the neighbor list.

• No duplicate PILOTs in the neighbor list.

• Neighbor’s PILOTs are multiple of the PILOTINCR value.

• All software handoffs into a pilot beacon are defined in the pilot beacontarget list. i.e If a pilot beacon is in the neighbor list of a given cell, the cellneeds to be a reference pilot in the pilot beacon target list of the pilotbeacon cell.

• Checking for cell id and BTS_CRM_ACNADDR consistency. If two ormore records have the cell id, but different BTS_CRM_ACNADDR.

• Definition of a target list Pilot Beacon, Border, and EHHO.

The cell being in its border/beacon target list.

A) The following messages are produced duringquery phase with the BTS/PDB.

The following conditions will produce ERROR messages:

• Invalid BTS name (Processing will continue.)

• Non-pingable BTS.

• Invalid SBS name

The following conditions will produce INFO messages (message that permitprocessing to continue):

Comparing a NCF sectors record with PDB for all the attributes other thantarget lists.

The following conditions produce a WARN message:

• Comparing NCF defined neighbors against those in both the Sector MOand Pilot Database entries for size and order.

• Comparing NCF defined hard hand off targets (Beacon, Border andEHHO) against those in the Pilot database for size and order.

• A NCF record (new) not found in the PDB. This record is not added bydefault.

• Comparing frequency again the BTSC MO channel list and theFrequencyAssignment ChannelList.

• Comparing band against BTSC MO’s BandClass.

• Comparing Cellids against the BTSC MO’s cellid value.


mtxswfn

• Comparing Pilot_PN and PilotIncr in the Sector MO.

• Comparing T_ADD, T_DROP, T_COMP, T_TDROP, SRCH_WIN_N,SRCH_WIN_R, and SRCH_WIN_A etc.in the Sector MO.

An example is in the section 1.9.

1.4.7 Command Line

The following is the definition for invoking the command lines. The followingis the syntax supported by checkneighbor:

checkneighbor [-bts] [-sbs][-par] [-ping] [-noinfo] [-nolog] [-noset] [-nl] [-pdbedit x] [-mmhho]

[-add] <inputfile.ncf> <bscid> <mscid mkt> <mscid swno>

The following are the parameters:

• inputfile.ncf: This is the network configuration file.

• bscid: This is a numeric value selecting which BSC to be updating.

• mscid mkt: This is the MSCID market id.

• mscid swno: This the MSCID switch number.

The following are the switches:

• -bts: Check only the bts.

• -sbs: Check only the sbs.

• -par: Do network topology analysis only.

• -ping: Ping the BTS before getting it.

• -noinfo:Suppress info messages.

• -noset: By default, a script file is to created to set all values that aredifferent. Its name ischeckneighbor.cli, and it will be written in the localdirectory. This switch stops it from creating the checkneighbor.cli.

• -nolog: By default, a log file is to created. Its name ischeckneighbor.log,and it will be written in the local directory. This switch stops it fromcreating the checkneighbor.log.

• -nl: interrogate neighbor list only on the BTS.

• -pdbedit x: Number of records(x) for each PDB edit. This defaults to 20.

• -mmhho: The band class is masked into the upper 3 most significant bitsof the InterSystemCellId for the hard hand off (Beacon, Border andEHHO) target lists in the PDB record. This masking is done only for thePilot_beacon, Border and EHHO cells and to their target lists. Ex: For aPilot_Beacon cell, only the Pilot Beacon target list will be updated tocontain band information in the InterSystemCellId. Other target lists for


mtxswfn

that cell will not be effected by this command option. The values for theBand are CDMA1900(4), CDMA800(2), AMPS(1) and UNKNOWN(0).No updates are carried out on Standard cells. Foe more information aboutMMHHO feature, Pl refer to feature A60006011 (Multi Mode Hard HandOFF). This option should be executed to to activate MMHHO feature onan existibg PDB in 8.0 stream.

• -add: Add a new PDB record if it does not exist.

Notice, that the default behavior is to produce both the script and the log filein the default directory; however, switches are provided to override thisfunctionality. Certain combination of switches as given below are invalid

-bts -sbs

-sbs -ping

-sbs -nl

1.4.8 Steps in running the checkneighbor tool

The user should do the following steps when administering their system withthe checkneighbor tool. IMPORTANT: The tool checkneighbor is verypowerful but incorrect usage may lead to call processing outages if the datafillis applied incorrectly. Datafill is only altered during step 4.

1. Prepare the NCF file. An example is in the section 1.8.

2. Run the checkneighbor script. You must provide the BSCID, MKTID, andSWNO on the command lines. These parameters identify the homesystem.All other parameters are optional.

checkneighbor example.ncf 1 2 3

3. Verify the output. Both the checkneighbor.log and checkneighbor.cli areproduced, by default. Initiate three separate editor windows, and review the“.ncf”, “.log”, and “.cli” files, in parallel. The cli file contains the deltachanges from standard NCF input to BTS/PDB mo values.

By design, the order of information in both the “.cli” and “.log” reflects thesame order of the sectors in the “.ncf” file. This allows for easierverification. Incorrect datafill can lead to call processing disruption.

4. Create a CLI session. Then, issue the following commands:

output mylog.file; # save a copy of the session for later review

script -e checkneighbor.cli; # update the datafill

output -s; # send output back to terminal


mtxswfn

5. Support for ISSHO requires running the script several times with each ofthe different BSCs. For example, the current BSC is 1, MSC_MKT is 10and MSC_SWNO is 20. This BSC may be involved in ISSHO with thefollowing:

— BSC 2, MSC_MKT 10, MSC_SWNO 20

— BSC 1, MSC_MKT 11, MSC_SWNO 21

The operator would then issue the following commands:

checkneighbor example.ncf 1 10 20

cp checkneighbor.cli checkneighbor.cli_1

cp checkneighbor.log checkneighbor.log_1

checkneighbor -sbs example.ncf 2 10 20



checkneighbor -sbs example.ncf 1 11 21



Enter into the CLIAPP, and run each checkneighbor.cli script separately(e.g.script -e checkneighbor.cli_1). Both BTS and PDB are updated inthe first command scripts, and only the PDB is updated with the last twocommand scripts.

6. Easily usable enhancements to expedite updating the datafill are availablewithin the tool based on the operator’s needs. They are the following:

• -nl: Use this if changing neighbor and target lists only. This ignores allother changes on the BTS.

• -pdbedit: This controls the number of records in one PDB edit commandinside the checkneighbor.cli script.

• /UPDATE: This option in the NCF file updates specific sectors, and not theentire database.

1.5 Feature impact

1.5.1 Interactions

None.


mtxswfn

1.5.2 Restrictions/limitations

The following assumptions are made about the structure of the absolutepathname for both the BTS Sector MOs.

o%:cbs1:cells1:<cellname>:btsc_unit[1-2]:root1:btsc1:frequencyassignment[1-3]:sector[1-3]

The <cellname> is the name read from the NCF input. BSM V6.2 introducethe “btsc_unit” which represents a the redundant unit. Sectors 1 through 3correspond to Alpha, Beta, and Gamma, respectively.

The PilotDatabase MO must have either of the following representations:

O%:CBS1:sbss1:<sbscsubsystem>:root1:sbs1:PilotDatabase1

O%:CBS1:SystemConfiguration1:SystemPilotDatabase1

The <sbscsubsystem> is taken from the SBS list of identifiers. Also, thestructure of the hard handoff target has changed between V6.2 and V7.0.


mtxswfn

1.6 Definitions & abbreviations

AMPS - Advanced/Analog Mobile Phone System

BSC - Base Station Controller

BSM - Base Station Manager

BTS - Basestation Transceiver Subsystem

CDMA - Code Division Multiple Access

CLI - Command Line Interpreter

DB - Database

ISSHO - Intersystem Soft Handoff

MHHO - Multi-Mode Handoff

MO - Managed Object

MSC - Mobile Switching Centre

NCF - Network Configuration File

PDB - Pilot Data Base

SBS - Selector Bank Subsystem

SBSC - SBS Controller

1.7 References

None.


mtxswfn

1.8 Example

The following is an example of the NCF file.

/NCFV6.2=KEY, MSCID_MKT, MSCID_SWNO, BSCID, \ CELLTYPE, CELLNAME, BAND, CELLID, FREQUENCY, SECTOR, PILOT_PN, \ NEIGHBORLIST, BTS_NEIGHBORS, BORDERTARGET, BEACONTARGET

/SBS=foo

/************************************************************************/// This is an example of the DFW configuration//// There are 3 MSCs (MSCID_MKT=1 SWNO (1-3))//// Dallas contains 3 BTSs (8, 9, 10)// Fort Worth contains 1 BTS (9)// Dention contains 1 BTS (11)//// All of them happen to have BSCID named 1.//

//***********************************************************// Dallas

// BTS 8 at Mockingbird and Central.//// Key MSCID BSC CellType Cellname Band Frq Sect. Pilot// ---- Mkt Sw --- -------- -------- ---- --- ----- -----

Dallas8Alpha 1 1 1 Cell_Standard Mockingbrd 1900 8 325 Alpha 80 \ Dallas8Beta, Dallas8Gamma, \ Dallas9Alpha, Dallas9Beta, Dallas9Gamma, \ Dallas10Alpha, Dallas10Beta, Dallas10Gamma \ * * *

Dallas8Beta 1 1 1 Cell_Standard Mockingbrd 1900 8 325 Beta 84 \ Dallas8Alpha, Dallas8Gamma, \ Dallas9Alpha, Dallas9Beta, Dallas9Gamma, \ Dallas10Alpha, Dallas10Beta, Dallas10Gamma \ * * *

Dallas8Gamma 1 1 1 Cell_Standard Mockingbrd 1900 8 425 Gamma 88 \ Dallas8Gamma, \ Dallas9Alpha, Dallas9Beta, Dallas9Gamma, \ Dallas10Alpha, Dallas10Beta, Dallas10Gamma \ * * *

// BTS 9 at I35 and Harry Hines//Dallas9Alpha 1 1 1 Cell_Standard HarryHines 1900 9 325 Alpha 92 \ Dallas8Alpha, Dallas8Beta, Dallas8Gamma, \ Dallas9Beta, Dallas9Gamma,\ Dallas10Alpha, Dallas10Beta, Dallas10Gamma \ * * *

Dallas9Beta 1 1 1 Cell_Standard HarryHines 1900 9 325 Beta 96 \ Dallas8Alpha, Dallas8Beta, Dallas8Gamma, \ Dallas9Alpha, Dallas9Gamma, \ Dallas10Alpha, Dallas10Beta, Dallas10Gamma \ * * *


mtxswfn

Dallas9Gamma 1 1 1 Cell_Standard HarryHines 1900 9 325 Gamma 100 \ Dallas8Alpha, Dallas8Beta, Dallas8Gamma, \ Dallas9Alpha, Dallas9Beta, \ Dallas10Alpha, Dallas10Beta, Dallas10Gamma \ * * *

// BTS 10 at Valley View and LBJ//Dallas10Alpha 1 1 1 Cell_Standard ValleyView 1900 10 325 Alpha 92 \ Dallas8Alpha, Dallas8Beta, Dallas8Gamma, \ Dallas9Alpha, Dallas9Beta, Dallas9Gamma, \ Dallas10Beta, Dallas10Gamma \ * * *

Dallas10Beta 1 1 1 Cell_Pilot_Beacon ValleyView 1900 10 325 Beta 96 \ * * * \ 92, Denton11Alpha, 84, FtWorth9Beta

Dallas10Gamma 1 1 1 Cell_Border ValleyView 1900 10 325 Gamma 100 \ * * \ FtWorth9Alpha \ *

// BTS 9 Fort Worth Cowtown.//FtWorth9Alpha 1 2 1 Cell_Standard Cowtown 1900 9 325 Alpha 92 \ FtWorth9Beta, FtWorth9Gamma\ FtWorth9Gamma, 1, 2 \ * *

FtWorth9Beta 1 2 1 Cell_Standard HarryHines 1900 9 325 Beta 96 \ FtWorth9Alpha, FtWorth9Gamma\ * * *

FtWorth9Gamma 1 2 1 Cell_Standard Cowtown 1900 9 325 Gamma 100 \ FtWorth9Alpha \ * * *

// BTS 11 Denton UNTexas//Denton11Alpha 1 3 1 Cell_Standard UNTexas 1900 9 325 Alpha 92 \ Denton11Beta, Denton11Gamma\ * * *

Denton11Beta 1 3 1 Cell_Standard UNTexas 1900 9 325 Beta 96 \ Denton11Alpha, Denton11Gamma\ * * *

Denton11Gamma 1 3 1 Cell_Standard UNTexas 1900 9 325 Gamma 100 \ Denton11Alpha, Denton11Beta \ * * *

1.9 Error Messages

The following error messages were produced with the checkneighborcommand on the file in section 1.8 (checkneighbor foo.ncf 1 1 1).


mtxswfn

The following is an example of the output from the topology analyzer:

DALLAS8ALPHA (line 28) ------------------------- WARN NEIGHBORLIST DALLAS8GAMMA does not have the same frequency WARN NEIGHBORLIST DALLAS9ALPHA and DALLAS10ALPHA have the same pilot pn WARN NEIGHBORLIST DALLAS9BETA and DALLAS10BETA have the same pilot pn WARN NEIGHBORLIST DALLAS9GAMMA and DALLAS10GAMMA have the same pilot pn

DALLAS8BETA (line 34) ------------------------- WARN NEIGHBORLIST DALLAS8GAMMA does not have the same frequency WARN NEIGHBORLIST DALLAS9GAMMA and DALLAS10GAMMA have the same pilot pn WARN NEIGHBORLIST DALLAS9BETA and DALLAS10BETA have the same pilot pn WARN NEIGHBORLIST DALLAS9ALPHA and DALLAS10ALPHA have the same pilot pn

DALLAS8GAMMA (line 40) ------------------------- WARN NEIGHBORLIST DALLAS10GAMMA does not have the same frequency WARN NEIGHBORLIST DALLAS10BETA does not have the same frequency WARN NEIGHBORLIST DALLAS10ALPHA does not have the same frequency WARN NEIGHBORLIST DALLAS9GAMMA and DALLAS10GAMMA have the same pilot pn WARN NEIGHBORLIST DALLAS9GAMMA does not have the same frequency WARN NEIGHBORLIST DALLAS9BETA does not have the same frequency WARN NEIGHBORLIST DALLAS9ALPHA and DALLAS10ALPHA have the same pilot pn WARN NEIGHBORLIST DALLAS9BETA and DALLAS10BETA have the same pilot pn WARN NEIGHBORLIST DALLAS9ALPHA does not have the same frequency WARN NEIGHBORLIST DALLAS8GAMMA in its own neighbor list

INFO NEIGHBORLIST DALLAS8ALPHA (line 28) is not in list, but DALLAS8ALPHA doescontain DALLAS8GAMMA in its list INFO NEIGHBORLIST Beta sector for this cell not in list INFO NEIGHBORLIST Alpha sector for this cell not in list

INFO NEIGHBORLIST DALLAS8BETA (line 34) is not in list, but DALLAS8BETA doescontain DALLAS8GAMMA in its list

DALLAS9ALPHA (line 48) ------------------------- WARN NEIGHBORLIST DALLAS10ALPHA has the same pilot pn WARN NEIGHBORLIST DALLAS9GAMMA and DALLAS10GAMMA have the same pilot pn WARN NEIGHBORLIST DALLAS9BETA and DALLAS10BETA have the same pilot pn WARN NEIGHBORLIST DALLAS8GAMMA does not have the same frequency

DALLAS9BETA (line 54) ------------------------- WARN NEIGHBORLIST DALLAS9ALPHA and DALLAS10ALPHA have the same pilot pn WARN NEIGHBORLIST DALLAS10BETA has the same pilot pn WARN NEIGHBORLIST DALLAS8GAMMA does not have the same frequency WARN NEIGHBORLIST DALLAS9GAMMA and DALLAS10GAMMA have the same pilot pn

DALLAS9GAMMA (line 60) ------------------------- WARN NEIGHBORLIST DALLAS10GAMMA has the same pilot pn WARN NEIGHBORLIST DALLAS8GAMMA does not have the same frequency WARN NEIGHBORLIST DALLAS9ALPHA and DALLAS10ALPHA have the same pilot pn WARN NEIGHBORLIST DALLAS9BETA and DALLAS10BETA have the same pilot pn

DALLAS10ALPHA (line 69) ------------------------- WARN NEIGHBORLIST DALLAS9GAMMA and DALLAS10GAMMA have the same pilot pn WARN NEIGHBORLIST DALLAS9ALPHA has the same pilot pn WARN NEIGHBORLIST DALLAS8GAMMA does not have the same frequency WARN NEIGHBORLIST DALLAS9BETA and DALLAS10BETA have the same pilot pn

DALLAS10BETA (line 75) ------------------------- INFO NEIGHBORLIST Gamma sector for this cell not in list INFO NEIGHBORLIST Alpha sector for this cell not in list

INFO NEIGHBORLIST DALLAS9BETA (line 54) is not in list, but DALLAS9BETA doescontain DALLAS10BETA in its list

INFO NEIGHBORLIST DALLAS8BETA (line 34) is not in list, but DALLAS8BETA doescontain DALLAS10BETA in its list


mtxswfn

INFO NEIGHBORLIST DALLAS9ALPHA (line 48) is not in list, but DALLAS9ALPHA doescontain DALLAS10BETA in its list

INFO NEIGHBORLIST DALLAS9GAMMA (line 60) is not in list, but DALLAS9GAMMA doescontain DALLAS10BETA in its list

INFO NEIGHBORLIST DALLAS8GAMMA (line 40) is not in list, but DALLAS8GAMMA doescontain DALLAS10BETA in its list

INFO NEIGHBORLIST DALLAS8ALPHA (line 28) is not in list, but DALLAS8ALPHA doescontain DALLAS10BETA in its list INFO NEIGHBORLIST DALLAS10ALPHA (line 69) is not in list, but DALLAS10ALPHAdoes contain DALLAS10BETA in its list INFO BEACONTARGET PilotPN 80 not in list, DALLAS8ALPHA (line 28) could handinto it INFO BEACONTARGET PilotPN 88 not in list, DALLAS8GAMMA (line 40) could handinto it INFO BEACONTARGET PilotPN 96 not in list, DALLAS9BETA (line 54) could handinto it

INFO BEACONTARGET PilotPN 100 not in list, DALLAS9GAMMA (line 60) could handinto it

DALLAS10GAMMA (line 81) -------------------------INFO NEIGHBORLIST DALLAS8GAMMA (line 40) is not in list, but DALLAS8GAMMA does

contain DALLAS10GAMMA in its listINFO NEIGHBORLIST DALLAS9ALPHA (line 48) is not in list, but DALLAS9ALPHA does

contain DALLAS10GAMMA in its listINFO NEIGHBORLIST DALLAS9BETA (line 54) is not in list, but DALLAS9BETA does

contain DALLAS10GAMMA in its listINFO NEIGHBORLIST DALLAS9GAMMA (line 60) is not in list, but DALLAS9GAMMA does

contain DALLAS10GAMMA in its listINFO NEIGHBORLIST DALLAS8BETA (line 34) is not in list, but DALLAS8BETA does

contain DALLAS10GAMMA in its list INFO NEIGHBORLIST Beta sector for this cell not in list INFO NEIGHBORLIST Alpha sector for this cell not in list INFO NEIGHBORLIST DALLAS10ALPHA (line 69) is not in list, but DALLAS10ALPHAdoes contain DALLAS10GAMMA in its list

INFO NEIGHBORLIST DALLAS8ALPHA (line 28) is not in list, but DALLAS8ALPHA doescontain DALLAS10GAMMA in its list

FTWORTH9ALPHA (line 90) ------------------------- INFO BTS_NEIGHBORS Beta sector for this cell not in list

FTWORTH9BETA (line 95) ------------------------- INFO CELLNAME FTWORTH9ALPHA (line 90) have same cellids (9) but differentcellnames(HARRYHINES COWTOWN)

FTWORTH9GAMMA (line 99) ------------------------- INFO CELLNAME FTWORTH9BETA (line 95) have same cellids (9) but differentcellnames(COWTOWN HARRYHINES)

INFO NEIGHBORLIST FTWORTH9BETA (line 95) is not in list, but FTWORTH9BETA doescontain FTWORTH9GAMMA in its list INFO NEIGHBORLIST Beta sector for this cell not in list

Documents

ncf_fn