ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE
E1P4
3BK 11204 0564 DSZZA 1/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
Site Timisoara GSM / WiMAX Business Division
Originators Adrian STAN MFS/OMC PM FILE INTERFACE SPECIFICATION RELEASE B12
System : ALCATEL 900/BSS Sub-system : MFS Document Category : SYSTEM FUNCTIONAL BLOCKS (step 2) ABSTRACT This document defines the MFS/OMC-R performance-management (PM) file interface that will allow service providers (SPs) deploying General Packet Radio Service (GPRS) wireless services to track the ongoing performance of their Alcatel-Lucent network from end to end.
Approvals Name App.
(DPM/MFS) Noemi KIRALY (DPM/OSY) Xavier LAMBERT
REVIEW Edition 1 Proposal 1 2011-05-26 No remarks Edition 1 Proposal 2 2011-06-29 No remarks HISTORY Edition 1 Proposal 1 2011-05-26 Creation of the first proposal from B11 document, ed4rl. Update for B12 release Remove legacy MFS references as no longer supported in B12 Clarifications about GP alignment to hour boundary
Edition 1 Proposal 2 2011-06-29 Include impact of Counters for GCH traffic usage feature o Introduction of new block type: B21cellPTUTDM
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 2/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
Edition 1 Proposal 3 2011-10-02 3BKA20CBR293385 B11 NPO services description: SGSN name configured in OMC filled in MFS PM block. PM files examples in ANNEX A have been updated to include MNC/MCC fields in B41CELLNACC block for both current/previous GPU release Edition 1 Proposal 4 2012-06-12 608128 Parameters added for Boosted GP PM files examples in ANNEX A have been updated to include GP_HW_Generation and GP_Location
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 3/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
TABLE OF CONTENTS
TABLE OF CONTENTS.........................................................................................................3 INTERNAL REFERENCED DOCUMENTS .....................................................................................5 REFERENCED DOCUMENTS...................................................................................................5 RELATED DOCUMENTS .......................................................................................................5 PREFACE ........................................................................................................................5 OPEN POINTS / RESTRICTIONS..............................................................................................5 1 SCOPE........................................................................................................................6 2 BASIC PRINCIPLES .........................................................................................................8 2.1 Overview..............................................................................................................8 2.2 Transfer aspects................................................................................................... 10 2.3 Loader Transfer Directory ...................................................................................... 10 2.4 Security aspects ................................................................................................... 10 2.5 Granularity Period (GP).......................................................................................... 10 2.6 Report Period (RP)................................................................................................ 11 2.7 Counters Selection................................................................................................ 12 2.8 History............................................................................................................... 13 3 USE CASES ................................................................................................................ 14 4 FILE FORMAT............................................................................................................. 15 4.1 Files production................................................................................................... 15 4.1.1 MFS first installed in current release .................................................................. 15 4.1.2 MFS migrated from previous release to current release ............................................ 16 4.2 Files name .......................................................................................................... 16 4.3 General File format............................................................................................... 16 4.3.1 Header ....................................................................................................... 17 4.3.2 Guideline for blocks definition .......................................................................... 18 4.3.3 Blocks insertion & Logical configuration............................................................... 19 4.3.3.1 Transport Mode................................................................................... 19 4.3.3.2 PMU & PTU counters reliablity ................................................................ 20 4.3.3.3 LCS 20 4.3.3.4 Exaustive list of blocks.......................................................................... 20 4.3.3.5 Reporting order of blocks & Insertion condition ........................................... 21 4.4 Blocks definition .................................................................................................. 22 4.4.1 BSC BLOCKS ................................................................................................. 22 4.4.1.1 B30BSCCOM BLOCK .............................................................................. 22 4.4.1.2 B31BSCTDM BLOCK............................................................................... 23 4.4.2 BTS BLOCKS ................................................................................................. 25 4.4.2.1 B01BTSTDM........................................................................................ 25 4.4.2.2 B02BTSIP........................................................................................... 26 4.4.3 CELL BLOCKS................................................................................................ 27 4.4.3.1 B10cellPMUCOM BLOCK ......................................................................... 27 4.4.3.2 B11cellPMUTDM BLOCK ......................................................................... 29 4.4.3.3 B12cellPMUIP BLOCK ............................................................................ 30 4.4.3.4 B20cellPTUCOM BLOCK.......................................................................... 31
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 5/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
INTERNAL REFERENCED DOCUMENTS Not applicable REFERENCED DOCUMENTS
[1] 3BK 11203 0252 DSZZA MFS counters catalogue [2] 3BK 11203 0250 DSZZA BSS Telecom Parameter [3] 3BK 11204 0572 DSZZA MFS/OMC interface: GDMO [part 2] - Implementation Profile [4] 3BK 29376 NAAA DSZZA MFS Security and supervision enhancements Functional specification [5] 3BK 11204 0569 DSZZA BSS O&M Parameters RELATED DOCUMENTS None PREFACE This document defines the MFS/OMC-R performance-management (PM) file interface that will allow service providers (SPs) deploying General Packet Radio Service (GPRS) wireless services to track the ongoing performance of their Alcatel network from end to end. Definition of the interface includes file format, protocol and services. The list of counters supported by the MFS is not part of the document. The counter given in the ANNEX A are not guarantied, there are given as example (The reference document for the counters is document [1]).
OPEN POINTS / RESTRICTIONS None
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 6/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
1 SCOPE Terms: Current release or N release terms refers to B12 release Previous release or N-1 release terms refers to B11 release The terminology BSC is for all platforms: BSC G2 and BSC EVOLUTION (stand alone and rack shared architecture). The terminology MFS is for MFS EVOLUTION/MX (stand alone and rack shared architecture). OMCP term refers to HW board hosting the MFS O&M function The terminology GPU is for Global Processing Unit, also called GP in a MFS EVOLUTION context. The aim of this document is to provide the specification of the MFS/OMC-R performance- management (PM) file interface that will allow service providers (SPs) deploying General Packet Radio Service (GPRS) wireless services to track the ongoing performance of their Alcatel network from end to end. Definition of the interface includes file format, protocol and services. The list of counters supported by the MFS is not part of the document. The counters given in the ANNEX A are not guarantied, there are given as example (The reference document for the counters is document [3]). A current release MFS is able to handle current BSC release and previous BSC release. A release (previous or current) can be made of several MR (Maintenance Release). A MFS manage one and only one MR per release at a given time. Thus, the OMCP is able to manage, at the same time, in the same rack: previous release MRx GPs connected to a previous release MRx BSC current release MRy GPs connected to a current release MRy BSC
This edition applies to all Main Releases of the current release.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 7/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
Up to 21+1 GPs (MX) Up to 21+1 GPs (MX) Control Station
GPU rel N-1 MFS release N-1 OMC release N Control Station
GPU rel N-1 GPU rel N MFS release N BSC rel N-1 BSC rel N BSC rel N-1
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 8/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
2 BASIC PRINCIPLES 2.1 Overview The MFS implements a permanent X.738 Buffered Scanner that realizes the functions of collection per Monitored object of historical PM data, according to a collection schedule; and of PM data reporting to the OMC-R according to a reporting schedule. The Buffered scanner permits to collect per Monitored object a set of historical PM data collected at the end of each Granularity period (GP). At the end of the Report period (RP), the Buffered scanner scans all Historical data created at the end of each Granularity period, produces a Result file.
Historical Data from GP1 Historical Data from GP2 Historical Data from GP3 Historical Data from GP4 History Data for RP1 (GP1+GP2) History Data for RP1 (GP3+GP4) GP1 GP2 GP3 GP4 Example with RP value = 2 * GP value File File
At MFS, the Granularity period (GP) is equal to the Report period (RP). There is one Result file per BSS release. As the MFS handles two releases of BSS, there are two result files (one per GPU release) produced by the MFS: one for previous release GPUs, one for current release GPUs (whatever is the MR)
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 9/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
The following figure illustrates the PM data collection process:
Parser Loader Loader transfer directory Loader transfer directory OMC-R MFS Data Transfer NPR input format Parsed Data Counters collector Collection GPU GPU GPU
1 file per GPU release Control Station MUSE Counters from BSC
The parser is responsible for the formatting network performance data into a NPO format. It is implemented in the MFS network element. The NPO input format consists in a CSV/tabular structure. Data transfer: see [2.2] The loader is a configurable subsystem that maps the output of the parser onto the data model. The parser only performs syntactic transformations, so it must carry out any semantic transformations required in the data, such as mapping the performance counters onto columns defined in the data model Inputs for OBSAL (OMC-R component ) are the PM files coming from BSC and MFS and the outputs are alerters, OBSYNT and CSV files for MUSE.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 10/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
2.2 Transfer aspects The OMC-R will monitor the MFS loader transfer directory in order to attempt to load any files its encounters in that directory directly via ftp to transfer the result files. Transfer is based on a polling period at OMC-R. The selection of the GPMRES files to transfer from the MFS by the OMC-R is based on the files UNIX timestamp (last modification, date/time) at MFS. In consequence, the timezone of the MFS must be initialized. 2.3 Loader Transfer Directory A Transfer Directory is defined at the MFS. It is defined at the OMC-R/MFS interface on the aGprsManagedElementExtension managed object class by the attribute aGprsSpoolDirectory attribute (See ref [5]). This directory is used for many domains (PM result files, radio reconfiguration file). For PM, the complete path is the following: {aGprsSpoolDirectory}\gpmres
2.4 Security aspects The access to the directory omcxchg is limited to some users. At MFS installation, the user omcxchg [omcxchange] is defined by default. More details in ref [4]
2.5 Granularity Period (GP) GP value is defined in the GPMGP file at OMCP. The GP value is taken into account by the MFS only at a global restart (OMCPs and all GPU boards): First GPM starts up and reads the RP value. Then, the GP value is sent to GPU at board initialization. GPmin is the time in which GPM real time agent is able to collect all the performance measurement reports for every instances from every GPU boards, in order to provide the complete MFS results files (one per release) for a given Reporting Period. This global collect must be finished before to start the next one. Mandatory rules for these parameters are: - The maximum value of GP is 60 minutes - The minimum value of GPmin is 2 minutes
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 11/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
- GP > GPmin (if not, there is a fatal error at GPM SCIM start up) - GP is a divisor of 60 minutes. In consequence, theorically, the possible values are 3, 4, 5, 6, 10, 12, 15, 20, 30 and 60. Unit is minutes. - The Granularity Period (GP) is aligned to the hour boundary (ie from HH:00 to HH+GP:00), so all the measurements are comparable to the other systems. From a product point of view: GP is constant, whatever is the release of the MFS. GP=60 minutes. See GPRS BSS Technical Feature List document, 3BK102040458DTZZA. In fact this value is the duration in which an OMC-R is able to collect all the reports from all network elements in a large network. (*)(**) GPmin is constant for a given MFS release. This value is the duration in which a MFS is able to collect all the reports from all the Telecom boards. GPmin=3 minutes for MFS (MX). (*) Regarding MX platform, Load tests shows that all reports for 21 GP (stand alone configuration) have been collected in less than 1mn10sec. To secure the timer value, a margin of at least 30% is applied. (**) With MxBSC capacity improvements, the cells capacity of a MFS EVOLUTION increases from 3000 to 4000. 2.6 Report Period (RP) PM data reporting refers to the ability for the MFS to report PM data on a scheduled basis to the OMC-R. The frequency of the report (RP) is defined slow, the usage will be only for a statistical usage of the PM data (post processing of the results in NPO). This is in opposition to fast, when the usage is for monitoring. At MFS, the RP is defined equal to GP. So that, a file that contains history data is reported on each GP expiry. To secure the integrity of the files (an OMCP swith-over with a file opened is a critical case), the reporting files are closed at GP expiry + GPMin. So, the history data related to GPi are available, in the Transfer Directory, at GPi expiry + GPmin
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 12/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
Control Station <-- GP 1 --><-- GP 2 --><-- GP 3 --> GPU board <-- GP 1 --><-- GP 2 --><-- GP 3 --> <-> GP min <-> GP min Transfer Directory RP1 files are ready RP2 files are ready
OMC-R RP 1 files are available RP 2 files are available
2.7 Counters Selection The GPU telecom boards master the counters. The OMCP simply gets them through PM messages from GPU boards and place them with a specific format into PM file reports to be transferred to a PM server. At OMCP, all the counters are defined in the gpmcounterid.txt file, located in the /usr/mfs/etc directory at the OMCP, and are reported to the OMC-R. It is possible to filter some counters by removing them from this file, and thus they will be not put inside the file report. This is a flat file that gives the set of counters identifiers, with their associated counters name, associated class, and configuration data identifiers with their associated logical name, associated class. It does not give the relationship between the counters and the release in which they are implemented by the telecom. So, if a counter is removed from this file, it will be never reported into the PM file report, neither if it comes from a previous release GPU, nor from a current release GPU. This file is given in APPENDIX B. It is possible to reduce this set of counters by removing counters in this file. This will unselect counters to be filled in the result files. So, a counter coming from GPU board, not present in this file, will not be inserted it the PM result file. The gpmcounterid.txt file is read by the MFS (GPM) at an OMCP (re) start. If it is modified, an OMCP switch-over (or restart) is required to take into account the new one.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 13/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
This facility can be used by development and integration. MFS team delivers the reference file.
2.8 History The MFS keeps, at least, the GPUs results files that correspond to the last 3 days (72 hours). This requirement is directly taken, into account in the filename in which a suffix is added. To limit the number of result files stored in the transfer directory, the following rule to compute the index has been defined: mm = [ 00 INT( (History Period / Granularity Period) )+ 1 ]
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 14/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
3 USE CASES
The following use case illustrates the OMC-R PM data collection process. Mechanism is mainly based on timers expiration, dimensioned with a maximum value (independent of the number of GPUs, logical configuration, platform).
[1] At MFS start up, the permanent scanner is created in all GPU. It starts at next GP (GP=60mn). [2] When a (GP) period starts, Current data are updated by GPU SW. [3] When GP expired, the GPU SW swaps the two buffers (current/history): Current data becomes the history data (values are frozen) History data are reset, and becomes the current data. And starts the next (GP) period. Current data are updated by GPU SW [4] When GP expired, GPM (Global Performance Manager) at OMCP
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 15/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
Asks for all the history data from the GPU boards Starts (Gpmin) timer Starts the next (GP) period [5] GPM (Global Performance Manager) at OMCP receives history data (ReportCnf from GPUs on a class basis, with link reply) from the GPU boards and produces result files (parser function), in respect to standard format. [6] when GPmin expired, GPM closes the report files and move them into the MFS exchange directory. Thus, the result files are placed in the loader transfer directory at the MFS. [7] At OMC-R, a periodic timer (10 mn) polls the exchange directory to get the report files of the MFS. The new (based on the file timestamp) report files are collected. 4 FILE FORMAT The file format is a proprietary format. It consists in a sequence of report blocks, enclosed in braces. Two levels of block are defined. A block contains: Other blocks (the block is a container). This block contains all informations related to a full Granularity Period. This block contains a set of blocks. The content depends on the logical configuration (size not fixed). Measurements of one instance of one class (Identifier/value pairs that associate a value with a field name). The content depends on the list of defined counters (size not fixed). Line starting with the '#' character are interpreted as comments. New line characters are not recognized as significant by the loader. Files are compressed. This will be done by using gzip 1.2.4 (18 Aug 93) The file type is ASCII. 4.1 Files production As GPU boards report the counters to the OMCP: previous release GPU is reporting previous release counters results, and the current release GPU is reporting current release counters results to the OMCP. 4.1.1 MFS first installed in current release One BSS version is known at MFS: the current one. In this case, the MFS provides one file only, containing data from current release GPUs with current release counters only.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 16/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
4.1.2 MFS migrated from previous release to current release The current release MFS provides two files: one containing data from previous release GPUs with previous release counters only and one with data from current release GPUs with current release counters only. 4.2 Files name This following table gives the rules to name the PM results files:
FILE NAME Type Comments NAME PART Char (12) GPMRES<RR><yyy><mm> with: RR: ITFVERSION value always coded on 2 digits (see4.3.1) yyy: identification of the MFS, configured in the ServerFile file (handled by Q3 agent). Always coded on 3 digits. mm: index of the result file ( see 1 ). Always coded on 2 digits. For a given GP, the index of the two files (previous/current release) is identical. (1) 1 To limit the number of result files stored in the transfer directory, a following rule to compute the index has been defined: mm = [ 00 INT( (History Period / Granularity Period) )+ 1 ]
4.3 General File format Measurement Items (counters) are typically grouped according functionality. The term "measured object class" is used to identify such a group. The file format is based on the fact that the measurements are always collected in sets of one functional group. A PM file contains the sequence of measurements, values and related information, in a block- oriented structure. It includes a list of measurement types and the corresponding values, together with the date and the time stamp related to the reporting period, the MFS identifier, and the interface identifier. The following figure gives the general file format:
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 17/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
The fixed part is exactly the same whatever is the PM interface version. The variable part is the list of the possible blocks. The presence of a block is not mandatory, it depends on the configuration.
#%npr MFS # { { MFS <MFS identifier> VERSION <MFS version> ITFVERSION <ITF version> ScannerIdentity <scanner id> STARTTIME <HH:MM:SS> ENDTIME <HH:MM:SS> DATE <YYYY-MM-DD> insert here the PVC block (s) * * * insert here the BearerChannel block (s) * * * insert here the LAPD block (s) * * * insert here the SGSN_IP_NSVC block (s) * * * insert here the B30BSCCOM block (s) * * * insert here the B31BSCTDM block (s) * * * insert here the SGSN block (s) * * * insert here the B01BTSTDM block (s) * * * insert here the B02BTSIP block (s) * * * insert here the ABISBTSGROUP block (s) * * * insert here the B10cellPMUCOM block (s) * * * insert here the B11cellPMUTDM block (s) * * * insert here the B12cellPMUIP block (s) * * * insert here the B20cellPTUCOM block (s) * * * insert here the B21cellPTUTDM block (s) * * * insert here the LcsCell block (s) * * * insert here the B40BSSADJEXT block (s) * * * insert here the B41CELLNACC block (s) * * * insert here the DistCell block (s) * * * } } maximum 60 columns fixed part variable part fixed part
4.3.1 Header MFS identifier: value configured in the nServerFile file (handled by Q3 agent). VERSION: Software sub version of the MFS network element (see the document [3] for the version naming rule). It includes the generation of the MFS (i.e. MFS EVOLUTION only) and the software version of MFS (i.e. previous release or current release). Version name starts with MFSY for MFS EVOLUTION Note that the MFS SW VERSION is the one of the current release whatever the release of the GPU (previous/current release).
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 18/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
ITFVERSION: identifies the O&M/ Telecom interface version (maximum of 2 digits), ie the GPU release (previous or current release)
interface type (MFS) VERSION ITFVERSION Current release MFS current release GPU (current release all MR BSC) 8 (current release GPU) Current release MFS previous release GPU (previous release all MR BSC) AL01.01A Previous release MFS previous release GPU (previous release all MR BSC) AZ01.01A 7 (previous release GPU)
ScannerIdentity: Identity of the scanner. The permanent scanner identifier is '1'. STARTTIME and the ENDTIME are respectively the start and the stop collection times of the granularity period related to the measurements included in the block. Time stamps are given in UTC time (Coordinated Universal Time). DATE is the start date of the granularity period related to the measurements included in the block. Note: A result block is inserted in the result file only if the block is retrieved from the GPU board. Counters and reporting class are defined into document [3]. Thus, Blocks and counters are defined based on these informations. 4.3.2 Guideline for blocks definition Here are given the list of the mandatory rules for defining a block: MFS insures that eack block name starts with 3 discriminating characters A parameter is fully defined with a parameter name and a parameter value: 1. A parameter name field is defined on maximum 50 chars (e.g. PD_DL_PDCH_UNIT_ALLOC_THR_9) in upper case. It is identical to the HMI Name defined at BTP. But, the limit becomes 27 for parameter on which no indicator is mapped explicitly in indicators dictionary. This information, when relevant, is specified in internal comments field at BTP. 2. A parameter value is always reported as an integer type. The length of the parameter value is parameter value dependent. A counter is fully defined with a counter name and a counter value:
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 19/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
1. A counter name field is defined on maximum 10 chars (e.g. "P13 " for the Number of UL TBF establishment - successes.) 2. A counter value is always reported as an integer type. The length of the counter value is counter value dependent. The maximum number of bytes is given in the related document [3]. For instance, when a counter is defined with a length of 4 bytes, the value provided in the PM result file can be from "0" to " 4294967295 " (numeric format). The carriage return is used as delimiter between two successive parameters or counters. It is inserted just after the last number of the value. If some counters are suspect for a given granularity period, the suspected flag (SF) will be set at the block level. The counter list in a block depends on the GPU software Main Release The configuration data in a block depends on GPU software Main Release. It is not possible to define more than one block for one object/granularity period (e.g. For non-concentric cell specific counters will be present in the cell block with the value 0) A counter is defined on only one object (see ref [1]). In consequence, a counter cant be present in two different blocks. 4.3.3 Blocks insertion & Logical configuration From an interface point of view, the interface data model provides additional objects for additional services. For instance, a block is defined for GPRS/EDGE counters and another is defined for LCS counters. The insertion (or not) of a block into the GPMRES export file depends on the logical configuration. 4.3.3.1 Transport Mode Due to the different transport modes, in order to: - Not to use space storage on MUSE side - Allow proper spatial aggregation for indicators only valid in a certain technology - Allow proper management of the reliability It is decided to build dedicated blocks. For a certain category of counters, we can define three blocks: The set of counters valid whatever the technology (the common ones). The third digit of the blockname is always 0. The set of counters valid only in TDM mode. The third digit of the block name is always 1.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 20/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
The set of counters valid only in IP mode. The third digit of the block name is always 2. 4.3.3.2 PMU & PTU counters reliablity Moreover, with BSSoIP introduction, when the Abis transport mode is IP, the PTU SW is at BTS. But PTU counters are still collected by the PMU, in order to keep the same interface with NPO, whatever is the BTS mode. For reliability reason, counters related to these services (GPRS/EDGE) are reported into two different blocks: one (cellPMU) is for counters defined at PMU, another (cellPTU) is for counters defined at PTU. 4.3.3.3 LCS Location is introduced in B8, and was considered as a new service on top of GPRS/EDGE that is activated/desactivated via the O&M parameter EN_LCS defined at BSC level. All counters related to this service are reported into the lcsCell block, defined in 4.4.3.5 4.3.3.4 Exaustive list of blocks The resulting list of blocks is as follows: Dependency on Gb transport mode: Always valid Frame Relay mode IP mode (static and dynamic configuration type) -- -- -- -- BearerChannel -- -- pvc -- -- -- SGSN_IP_NSVC -- -- SGSN (Gb flex enabled) Dependency on BSS transport mode: Always valid TDM mode IP mode -- LapD -- B30BSCCOM B31BSCTDM -- Dependency on ABIS transport mode: Always valid TDM mode IP mode -- B01BTSTDM B02BTSIP B10cellPMUCOM B11cellPMUTDM B12cellPMUIP B20cellPTUCOM B21cellPTUTDM -- LcsCell -- -- DistCell -- -- -- -- ABISBTSGROUP B40BSSADJEXT -- --
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 21/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
B41CELLNACC -- --
4.3.3.5 Reporting order of blocks & Insertion condition There is one GPMRES file per Release. The reporting of a block depends on the creation of the instance in the GPU. If an instance is not created at GPU, no block is reported for the instance. If an instance is created at GPU, some blocks are mandatory; the others are optional (see 4.3.3.4) The MFS collects all blocks from all GPU in parallel, and inserts them in the order they are reported by the GPU. By this way, the MFS may interleave blocks from different GPUs. There is no strict order regarding the order in which the domain reports their blocks. By this way, the MFS may interleave Gb blocks and Radio blocks. There is a strict order regarding the order in which blocks related to one domain request are reported. The first and last blocks of the radio domain are always mandatory. For a given GPU, a strict order is defined for blocks related to CELL object. The last block is always present whatever are the configured services. Note that LCS blocks are inserted if LCS service is configured only, then it cannot be the last one. Blocks related to Radio domain are inserted in the following order by the MFS
Block Name Presence Condition B30BSCCOM Always present (first block of the radio domain) [B31BSCTDM] Present if GSL transport mode is TDM [B01BTSTDM] Present if ABIS transport mode is TDM [B02BTSIP] Present if ABIS transport mode is IP [ABISBTSGROUP] Present if ABIS transport mode is IP B10cellPMUCOM Always present [B11cellPMUTDM] Present if ABIS transport mode is TDM [B12cellPMUIP] Present if ABIS transport mode is IP B20cellPTUCOM Always present [B21cellPTUTDM] Present if ABIS transport mode is TDM
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 22/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
[LcsCell] Present if LCS service is activated [B40BSSADJEXT] Present if RIM_NACC is activated and if external cells have been created for the BSC at MFS [B41CELLNACC] Present if RIM_NACC feature is activated DistCell Always present (last block of the radio domain)
Blocks related to Gb domain are inserted in the following order by the MFS
Block Name Presence Condition [SGSN_IP_NSVC] Present if Gb transport mode is IP, whatever is the configuration type (Static or dynamic) [SGSN] Present if Gb flex feature is activated. Note that Gb flex feature can be activated if Gb transport mode is IP only. 4.4 Blocks definition In the following chapters, the different blocks are defined. When a block is not relevant for one GPU release only (current or previous), this is explicitly indicated. 4.4.1 BSC BLOCKS The scope of a BSC block is the GPU board. In multi-GPU by BSC, the BSC block is related to a sub-BSS (identify by BSS+Fabric identifier). There is one sub-BSS by GPU. Note that the Fabric Identifier is the logical name of the GPU, which is not impacted by the GPU switch over. 4.4.1.1 B30BSCCOM BLOCK B30BSCCOM block reports the set of counters. In multi-GPU by BSC, the BSC block is related to a sub-BSS (identified by BSS+Fabric identifier). There is one sub-BSS by GPU. The block is valid whatever the BSS transport mode (IP or TDM).
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 23/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
B30BSCCOM { BSS <Bss Function Identifier> FABRIC <Fabric identifier> <configuration data name> <value> <configuration data name> <value> . . . . . . GCSF <0/1> SF <0/1> <counter name> <value> <counter name> <value> . . . . . . }
Bss Function Identifier: "<ID>" <Fabric Identifier> The FABRIC id is the identifier of the Logical GPU. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical GPU identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a padding. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, the fabric identifier will be 01030200 Hex or "16974336 Decimal Configuration data are: - None GPU Configuration Suspected Flag (GCSF) <0/1>: This flag (NO:0, YES:1) indicates that a cell has been created or removed on the GPU during the Granularity Period. Suspected Flag: "<SF>". See chapter 4.5 GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2 JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 24/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
4.4.1.2 B31BSCTDM BLOCK B31BSCTDM block reports the set of counters. In multi-GPU by BSC, the BSC block is related to a sub-BSS (identified by BSS+Fabric identifier). There is one sub-BSS by GPU. The block is provided if the BSS transport mode is TDM only.
B31BSCTDM { BSS <Bss Function Identifier> FABRIC <Fabric identifier> <configuration data name> <value> <configuration data name> <value> . . . . . . SF <0/1> <counter name> <value> <counter name> <value> . . . . . . }
Bss Function Identifier: "<ID>" <Fabric Identifier> The FABRIC id is the identifier of the Logical GPU. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical GPU identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a padding. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, the fabric identifier will be 01030200 Hex or "16974336 Decimal No configuration data. This part is empty GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2 JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 25/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
4.4.2 BTS BLOCKS 4.4.2.1 B01BTSTDM B01BTSTDM reports the set of counters, defined on a BTS basis, valid when the ABIS transport mode is TDM. Note that a B01BTSTDM block is reported if at least one cell configured with PS is mapped onto this BTS.
B 0 1 B T S T D M { B S S < B s s F u n c t i o n I d e n t i f i e r > F A B R I C < F a b r i c i d e n t i f i e r > B T S < B T S I d e n t i f i e r > < c o n f i g u r a t i o n d a t a n a m e > < v a l u e > < c o n f i g u r a t i o n d a t a n a m e > < v a l u e > . . . . . . S F < 0 / 1 > < c o u n t e r n a m e > < v a l u e > < c o u n t e r n a m e > < v a l u e > . . . . . . }
with: Bss Function Identifier: "<ID>" <Fabric Identifier> The FABRIC id is the identifier of the Logical GPU. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical GPU identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a padding. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, the fabric identifier will be 01030200 Hex or "16974336 Decimal BTS Identifier: "<ID>" is the identifier of BTS carrying the packet. It is the BTS index at BSC side. Configuration data are: - NB_EXTRA_ABIS_TS: the number of extra Abis TSs available in the BTS. Note: Cell shared having PS on primary sector is not shown as shared at OMC/MFS interface. The value is either N_EXTRA_ABIS_TS_MAIN (number of Extra TS configured on the main sector of a cell) or N_EXTRA_ABIS_TS_SECONDARY (the number of Extra TS configured on the secondary sector of a cell in case of cell shared).
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 26/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
As the two parameters are given by the OMC-R to the MFS on a cell basis, the MFS reads the parameters from the first cell of the BTS only and applies the following rule: If N_EXTRA_ABIS_TS_SECONDARY <> 0 (cell shared) then NB_EXTRA_ABIS_TS = N_EXTRA_ABIS_TS_SECONDARY else NB_EXTRA_ABIS_TS = N_EXTRA_ABIS_TS_MAIN Suspected Flag: "<SF>". See chapter 4.5 GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2 JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z.
4.4.2.2 B02BTSIP * * * For current release GPU only (introduced with SW release supporting BSSoIP) * * * B02BTSIP reports the set of counters, defined on a BTS basis, valid when the ABIS transport mode is IP. Note that a B02BTSIP block is reported if at least one cell configured with PS is mapped onto this BTS.
B 0 2 B T S I P { B S S < B s s F u n c t i o n I d e n t i f i e r > F A B R I C < F a b r i c i d e n t i f i e r > B T S < B T S I d e n t i f i e r > < c o n f i g u r a t i o n d a t a n a m e > < v a l u e > < c o n f i g u r a t i o n d a t a n a m e > < v a l u e > . . . . . . S F < 0 / 1 > < c o u n t e r n a m e > < v a l u e > < c o u n t e r n a m e > < v a l u e > . . . . . . }
with: Bss Function Identifier: "<ID>" <Fabric Identifier>
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 27/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
The FABRIC id is the identifier of the Logical GPU. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical GPU identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a padding. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, the fabric identifier will be 01030200 Hex or "16974336 Decimal BTS Identifier: "<ID>" is the identifier of BTS carrying the packet. It is the BTS index at BSC side. No configuration data. This part is empty Suspected Flag: "<SF>". See chapter 4.5 GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2 JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z. 4.4.3 CELL BLOCKS Globally, from an O&M point of view, a cell created at MFS is necessarly GPRS/EDGE capable. In this chapter are defined the blocks related to BSC own cells. 4.4.3.1 B10cellPMUCOM BLOCK B10CellPMUCOM reports the set of counters, defined on a cell basis, valid whatever the ABIS transport mode (IP or TDM).
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 28/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
B10cellPMUCOM{ BSS <Bss Function Identifier> FABRIC <Fabric identifier> LAC <lac value> CI <ci value> BTS <BTS Identifier> <configuration data name> <value> <configuration data name> <value> . . . . . . CSSF <0/1> SF <0/1> <counter name> <value> <counter name> <value> . . . . . . }
with: Bss Function Identifier: "<ID>" <Fabric Identifier> The FABRIC id is the identifier of the Logical GPU. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical GPU identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a padding. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, the fabric identifier will be 01030200 Hex or "16974336 Decimal <lac value> is the Location Area Code value of the cell <ci value> is the cell identity value of the cell <BTS Identifier> is the identifier of BTS carrying the packet. It is the BTS index at BSC side.. Configuration data are: - BS_PBCCH_BLKS (defined in ref [2]) - BS_PRACH_BLKS (defined in ref [2]) - MAX_PDCH (defined in ref [2]) - MIN_PDCH (defined in ref [2])
* * * For current release GPU only (introduced with SW release supporting BSSoIP) * * * - BSS_TRANSPORT_MODE (defined in ref [2]) - ABIS_TRANSPORT_MODE (defined in ref [5]) Cell Shared Suspected Flag (CSSF) <0/1>: This flag (NO:0, YES:1) indicates that the PS sector of a cell shared has changed of BTS during the Granularity Period.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 29/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
Suspected Flag: "<SF>". See chapter 4.5 GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2 JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z. 4.4.3.2 B11cellPMUTDM BLOCK B11CellPMUTDM reports the set of counters, defined on a cell basis, valid when the ABIS transport mode is TDM.
with: Bss Function Identifier: "<ID>" <Fabric Identifier> The FABRIC id is the identifier of the Logical GPU. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical GPU identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a padding. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, the fabric identifier will be 01030200 Hex or "16974336 Decimal <lac value> is the Location Area Code value of the cell
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 30/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
<ci value> is the cell identity value of the cell <BTS Identifier> is the identifier of BTS carrying the packet. It is the BTS index at BSC side. Suspected Flag: "<SF>". See chapter 4.5 GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2 JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z.
4.4.3.3 B12cellPMUIP BLOCK * * * For current release GPU only (introduced with SW release supporting BSSoIP) * * * B12CellPMUIP reports the set of counters, defined on a cell basis, valid when the ABIS transport mode is IP.
with: Bss Function Identifier: "<ID>" <Fabric Identifier> The FABRIC id is the identifier of the Logical GPU. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical GPU identifier.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 31/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a padding. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, the fabric identifier will be "16974336" <lac value> is the Location Area Code value of the cell <ci value> is the cell identity value of the cell <BTS Identifier> is the identifier of BTS carrying the packet. It is the BTS index at BSC side. Suspected Flag: "<SF>". See chapter 4.5 GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2 JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z.
4.4.3.4 B20cellPTUCOM BLOCK B20CellPTUCOM reports the set of counters, defined on a cell basis, valid whatever the ABIS transport mode (IP or TDM).
with: Bss Function Identifier: "<ID>" <Fabric Identifier>
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 32/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
The FABRIC id is the identifier of the Logical GPU. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical GPU identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a padding. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, the fabric identifier will be 01030200 Hex or "16974336 Decimal <lac value> is the Location Area Code value of the cell <ci value> is the cell identity value of the cell <BTS Identifier> is the identifier of BTS carrying the packet. It is the BTS index at BSC side. Suspected Flag: "<SF>". See chapter 4.5 GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2 JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z.
4.4.3.5 B21cellPTUTDM BLOCK B21CellPTUTDM reports the set of counters, defined on a cell basis, valid when the ABIS transport mode is TDM.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 33/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
Bss Function Identifier: "<ID>" <Fabric Identifier> The FABRIC id is the identifier of the Logical GPU. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical GPU identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a padding. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, the fabric identifier will be 01030200 Hex or "16974336 Decimal <lac value> is the Location Area Code value of the cell <ci value> is the cell identity value of the cell <BTS Identifier> is the identifier of BTS carrying the packet. It is the BTS index at BSC side. Suspected Flag: "<SF>". See chapter 4.5 GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2 JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z.
4.4.3.6 LcsCell BLOCK LcsCell reports the set of counters, defined on a cell basis, valid when the LCS feature is activated. LcsCell{ BSS <Bss Function Identifier> FABRIC <Fabric identifier> LAC <lac value> CI <ci value> SF <0/1> <counter name> <value> <counter name> <value> . . . . . . }
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 34/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
with: Bss Function Identifier: "<ID>" <Fabric Identifier> The FABRIC id is the identifier of the Logical GPU. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical GPU identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a padding. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, the fabric identifier will be 01030200 Hex or "16974336 Decimal Suspected Flag: "<SF>". See chapter 4.5 GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2 JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z.
4.4.3.7 DistCell BLOCK
DistCell{ BSS <Bss Function Identifier> FABRIC <Fabric identifier> CI <ci value> LAC <lac value> <configuration data name> <value> <configuration data name> <value> . . . . . . DSF <0/1> SF <0/1> <counter name> <value> <counter name> <value> . . . . . . }
with:
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 35/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
Bss Function Identifier: "<ID>" <Fabric Identifier> The FABRIC id is the identifier of the Logical GPU. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical GPU identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a padding. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, the fabric identifier will be 01030200 Hex or "16974336 Decimal <ci value> is the cell identity value of the cell <lac value> is the Location Area Code value of the cell Configuration data are: - - PD_UL_TBF_DURATION_THR_1 - PD_UL_TBF_DURATION_THR_2 - PD_UL_TBF_DURATION_THR_3 - PD_UL_TBF_DURATION_THR_4 - PD_UL_TBF_DURATION_THR_5 - PD_UL_TBF_DURATION_THR_6 - PD_UL_TBF_DURATION_THR_7 - PD_UL_TBF_DURATION_THR_8 - PD_UL_TBF_DURATION_THR_9 - PD_UL_TBF_DURATION_THR_10
- GPRS_LLC_THROUGHPUT_THR_1 - GPRS_LLC_THROUGHPUT_THR_2 - GPRS_LLC_THROUGHPUT_THR_3 - GPRS_LLC_THROUGHPUT_THR_4 - GPRS_LLC_THROUGHPUT_THR_5 - GPRS_LLC_THROUGHPUT_THR_6 - GPRS_LLC_THROUGHPUT_THR_7 - GPRS_LLC_THROUGHPUT_THR_8 - GPRS_LLC_THROUGHPUT_THR_9 - GPRS_LLC_THROUGHPUT_THR_10 Distribution Suspected Flag <DSF>. This flag (NO:0, YES:1) indicates whether or not at least one of the packet distribution thresholds has been modified during the Granularity Period
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 37/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
(e.g. further to an O&M change). Note that the packet distribution thresholds are defined at BSC level. Chapter does not apply to this suspected flag. Suspected Flag: "<SF>". See chapter 4.5 GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2 JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z.
4.4.3.8 B41CELLNACC B41CELLNACC reports the set of counters related to a cell. In multi-GPU context, the block is related to one sub-BSS (identified by BSS+Fabric identifier). The block may be reported when the feature is activated only (EN_RIM_NACC = 1) The block is not reported if all counters are null (ie value equals to 0) * * * 3BKA20CBR241660 BEGIN * * * Note that Suspected Flag (SF) is not managed because counters must be provided even for uncomplete Granularity period. By consequence, when it is reported, the block is always relevant ie SF is always set to 0 value.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
with: <FABRIC Identifier> The FABRIC id is the identifier of the Logical GPU. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical GPU identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a padding. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, the fabric identifier will be 01030200 Hex or "16974336 Decimal <BSS identifier> identifier of the BSS <LAC value> identifier of the Location Area Code of a cell of the own BSC <CI value> identifier of the Cell Identity of a cell of the own BSC <MNC value> identifier of the Mobile Network Code of a cell of the own BSC <MCC value> identifier of the Mobile Conutry Code of a cell of the own BSC No configuration data. This part is empty. Suspected Flag: "<SF>". Always 0. GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 39/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z. * * * 3BKA20CBR241660 END * * * 4.4.4 EXTERNAL CELL BLOCK Globally, from an O&M point of view, a cell created at MFS is necessarly GPRS/EDGE capable. In this chapter are defined the blocks related to BSC external cells. 4.4.4.1 B40BSSADJEXT B40BSSADJEXT reports the set of counters related to a BSC external cell. In multi-GPU context, the block is related to one sub-BSS (identified by BSS+Fabric identifier). The block may be reported when the RIM NACC feature is activated only (EN_RIM_NACC = 1) The block is not reported if all counters are null (ie value equals to 0) Note that Suspected Flag (SF) is present but not managed because counters must be provided even for uncomplete Granularity period. By consequence, when it is reported, the block is always relevant ie the SF is always set to 0 value.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 40/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
The FABRIC id is the identifier of the Logical GPU. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical GPU identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a padding. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, the fabric identifier will be 01030200 Hex or "16974336 Decimal <BSS identifier> identifier of the BSS <LAC value> identifier of the Location Area Code of a external cell to the BSC <CI value> identifier of the Cell Identity of a external cell to the BSC <MNC value> identifier of the Mobile Network Code of a external cell to the BSC <MCC value> identifier of the Mobile Country Code of a external cell to the BSC Suspected Flag: "<SF>". Always 0. No configuration data. This part is empty GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2 JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z. 4.4.5 ABISBTSGROUP BLOCK * * * For current release GPU only (introduced with SW release supporting BSSoIP) * * * This block is relevant when ABIS transport Mode is IP only.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
with: Bss Function Identifier: "<ID>" <Fabric Identifier> The FABRIC id is the identifier of the Logical GPU. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical GPU identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a padding. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, the fabric identifier will be 01030200 Hex or "16974336 Decimal * * * 3BKA20CBR232802 BEGIN * * * ABISGROUPNUMBER: "<ID>": value of the ABIS GROUP identifier * * * 3BKA20CBR232802 END * * * no configuration data. This part is empty. Suspected Flag: "<SF>". See chapter 4.5 GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2 JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 42/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z.
4.4.6 Bearer channel BLOCK This block is relevant in Frame Relay (FR) transport Mode only. BearerChannel { TP <TTP Identifier> Bearer <bearer channel Identifier> <configuration data name> <value> <configuration data name> <value> . . . . . . SF <0/1> <counter name> <value> <counter name> <value> . . . . . . }
with: <TTP Identifier> The TTP id is the identifier of the Logical port. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical port identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a port number [0..15]. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, TP 6 the fabric identifier will be 01030206 Hex or "16974342 Decimal" Bearer Identifier: "<ID>": value of the highest timeslot of the Bearer Channel no configuration data. This part is empty. Suspected Flag: "<SF>". See chapter 4.5 GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2 JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 43/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z. 4.4.7 Pvc BLOCK This block is relevant in Frame Relay (FR) transport Mode only. pvc { TP <TTP Identifier> Bearer <bearer channel Identifier> PVC <PVC Identifier> <configuration data name> <value> <configuration data name> <value> . . . . . . SF <0/1> <counter name> <value> <counter name> <value> . . . . . . }
with: <TTP Identifier> The TTP id is the identifier of the Logical port. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical port identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a port number [0..15]. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, TP 6 the fabric identifier will be 01030206 Hex or "16974342 Decimal" bearer channel Identifier: "<ID>": value of the highest timeslot of the Bearer Channel PVC Identifier: "<DLCI>": Data Link Connection Id; this is either a Frame Relay network parameter (case Gb interface through Frame Relay), or a parameter shared with the SGSN (case direct connection). Range: 16-991 no configuration data. This part is empty. Suspected Flag: "<SF>". See chapter 4.5 GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 44/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z. 4.4.8 LapD BLOCK This block is relevant when BSS transport Mode is TDM only. LapD { BSS <Bss Function Identifier> TP <TTP Identifier> GSL <GSL Identifier> <configuration data name> <value> <configuration data name> <value> . . . . . . SF <0/1> <counter name> <value> <counter name> <value> . . . . . . }
with: Bss Function Identifier: "<ID>" <TTP Identifier> The TTP id is the identifier of the Logical port. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical port identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a port number [0..15]. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, TP 6 the fabric identifier will be 01030206 Hex or "16974342 Decimal" GSL identifier: "tei" no configuration data. This part is empty. Suspected Flag: "<SF>". See chapter 4.5 GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values:
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 45/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
JBXGP2 or JBXGPU which refers to old GP board also called GP2 JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z. 4.4.9 SGSN_IP_NSVC BLOCK This block is relevant for Gb over IP transport Mode only (Gb_Transport_Mode = 1) The block is reported whatever is the configuration mode (static or dynamic). In static configuration, SGSN_IP_NSVC define the IP endpoints used for data and signalling traffic. In dynamic configuration, SGSN_IP_NSVC defines first the pre-configured IP endpoint and then the negociated ones. The BSS uses the pre-configured IP endpoint to exchange the configuration with the SGSN. Then, the SGSN gives the list of SGSN IP endpoints to use for data and signalling traffic.
SGSN_IP_NSVC { FABRIC <Fabric Identifier> SGSNIPENDPOINT <SGSN IP END POINT Identifier> <configuration data name> <value> <configuration data name> <value> . . . . . . SF <0/1> <counter name> <value> <counter name> <value> . . . . . . }
with: <Fabric Identifier> The FABRIC id is the identifier of the Logical GPU. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical GPU identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a padding. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, the fabric identifier will be 01030200 Hex or "16974336 Decimal
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 46/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
SGSN IP END POINT identifier: "<ID>": value for the Remote IP Endpoint identifier Configuration data are: - SGSN_IP_ADDRESS: - Syntax is INTEGER (32 bits) - Coded as follow in 4 groups of 8 bits: 255.255.255.255 - Ex: the IP address 139.54.87.128 is coded 2335594368 - SGSN_UDP_PORT - PEER_NSE_SIGNALLING_WEIGHT - PEER_NSE_DATA_WEIGHT - GB_CONFIGURATION_TYPE - SGSN_NAME - SGSN_IP_NSVC_NSEI: the Logical Name of this parameter at BTP is NSEI
Suspected Flag: "<SF>". See chapter 4.5 GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2 JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z. 4.4.10 SGSN BLOCK This block is relevant for Gb flex is activated only.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 47/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
The FABRIC id is the identifier of the Logical GPU. This identifier is a fixed identifier which is independant of the localisation of the supporting GPU board, which can move following reconfigurations (ie GPU switch over). Thus, PM results are related to the logical GPU identifier. MFS EVOLUTION: is the decimal value of the concatenation of 4 bytes (8 bits each [0..255]): the rack number(1), the subrack number(3..4) and the GP position ([1..5,10..14] for shelf 3, [1..6,9..14] for shelf 4 ) and a padding. For instance, for the Fabric: rack 1, sub-rack 3, GP 2, the fabric identifier will be 01030200 Hex or "16974336 Decimal <SGSN Identifier>": value of the identifier of the SGSN (named CN_ID_PS at BTP) <SGSN NAME>: User Label of the SGSN Configuration data are: - SGSN_NSEI: the Logical Name of this parameter at BTP is NSEI Suspected Flag: "<SF>". See chapter 4.5 GP_HW_GENERATION GP_HW_GENERATION indicates the type of the GP board and can take the following values: JBXGP2 or JBXGPU which refers to old GP board also called GP2 JBXGP3 which refers to Boosted GP also called GP3 GP_LOCATION GP_LOCATION indicates the physical GPU. The value has the following format: RACK X / SUBRACK Y / SLOT Z. 4.5 Specific behaviors and impact on Suspected Flag (SF) 4.5.1 Create/Delete instance When an instance is created or deleted the block that supports these events become no more relevant. GP 1 GP 2 GP 3 GP 4 Create Delete GP 5
At the end of the GP 1, the instance result block does not exist. During GP 2, the instance is created, and therefore, the suspect flag is set to TRUE by the GPU. At the end of GP 2, the instance result block is inserted in the result file but the period is not completely relevant.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 48/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
During all GP 3, the instance exists. At the end of the GP 3, the resource result block is inserted in the result file. During GP 4, the instance result block does not exist any more. At the end of the GP 5, the instance result block does not exist. 4.5.2 LCS service activation/desactivation The flag EN_LCS flag exists for each BSC instance. When the LCS function is "stopped" on a cell, the EN_LCS flag is set to FALSE. Consequently, when EN_LCS flag is set to FALSE all objects linked at the function are deleted into GPU and, at the reverse, if EN_LCS is set to TRUE all objects linked at the function are created in GPU. Note that the LCS versus current release is completely different from the LCS versus previous release, and so the blocks are diferents. See the "4.5.1 Create/Delete instance" to know the management of the SF and existing or not of the blocks for the instances. 4.5.3 Administrative state The administrative state has no effect on the validity of the counters, i.e. neither on the positioning of the suspect flag nor on the presence/absence of the block. 4.5.4 Operational state The operational state has no effect on the validity of the counters, i.e. neither on the positioning of the suspect flag nor on the presence/absence of the block. 4.5.5 O&M Parameter change In this section, we are interested only in the configuration parameters inserted into result blocks. During a GP, the OMC-R operator can change the value of some configuration parameters. The ones that are defined with category = " Site (CAE)" into the BTP. At the MFS, the following mechanism applies: the configuration parameter values are changed at GOM, then the related GPU is aligned with the new parameter values. Then, it is up to the GPU to report the parameter values into the result blocks with the counters ones, on GPM request. So, the value of the configuration parameters is synchronized to the counter values. The configuration parameters are handled in the same way as the counters. This means two set of values: the current and the history data. Only the history data are changeable during GPU configuration alignment. The Suspected Flag (SF) is not impacted by such operation.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 49/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
4.5.6 GPU switchover / GPU reset In case of GPU switchover (or GPU reset), a deletion and creation of the instance occurs in the same GP. All the current measures that are performed on the faulty board are lost. Then, an instance block for only one Granularity Period has the Suspect Flag set to TRUE. Valid result blocks will be available from next GP. If rarely the deletion/creation occurs but on two Granularity Periods, no result block will be provided for the current GP, then an instance block for next Granularity Period has the Suspect Flag set to TRUE. Afterwards, valid result blocks will be available from next GPs. 4.5.7 OMCP (MFS EVOLUTION) switch over Most of the time, a OMCP (MFS EVOLUTION) switch over has no impact on measurement activity. However, if the switch over occurs between the beginning of a GP (i.e.GP2 in the figure) and GP+GPMin (i.e. GP2+GPMin in the figure), history result files corresponding to the previous GP (i.e. GP1 in the figure) are lost and they will not be available on the MFS.
GP 1 GP 2 GPM expiry of GP1. GP2 is armed. The counters file for GP1 is opened. GPM gets by polling the results from GP for GP1. at GP1+ GPmin, the file for GP1 is closed if a switch over occurs, file is lost ! GP 1 GP 2 GP
4.5.8 BTS Provisioning Phase Some BTS(s) that are in the provisioning phase (or out of commercial use) are not able to provide a complete commercial service for many reasons (the customer intends to do some operations on them like commissioning tests before to make them in commercial service). When these BTS(s) are declared in the OMC-R, they are supervised. When the BTS has Cells supporting the GPRS, the MFS triggers performance measurements on these cells but all counters collected from the telecom boards will be reported as suspect to the OMC-R/NPO if this BTS is out of commercial use. To identify the BTS out of commercial use, an attribute (aCmbCommercialUse) is defined and associated to each aGprsBtsSiteMananger. The commercial use attribute applies to the BTS (included) and whole its subtree (cells,...)
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 50/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
When the operator changes the value of this attribute from 'true' to false from the OMC-R, he makes a BTS out of commercial use and the PM data related to cell instances become no more relevant. At the MFS, the following mechanism applies. To limit the development cost of this feature, it will be implemented only at the OMCP side (nothing at the GPU board side). The main drawback is that the synchronization between the telecom and the O&M in case of commercialUse change is not complete. At GP expiry, GPM polls all GPU boards. When it receives PM reports, it reads the commmercialUse value. If it was set from true to false after (GP expiry) but before (GP expiry+GPU reports reception delay), the SF will be set to 1, while the period was not suspect.
GP 1 GP 2 GP 3 GP 4 false true GP 5 true
At the end of the GP 1, all cell instances result blocks are inserted in the result file (SF=0) During GP 2, the aCmbCommercialUse of the aGprsBtsSiteManager instance is set to 'false'. At the end of GP 2, the instance result blocks are inserted in the result file but the period is not completely relevant (SF=1). During all GP 3, the BTS is out of commercial use. No cell instance result block is inserted in the result file at the end of GP 3. During GP 4, the aCmbCommercialUse of the aGprsBtsSiteManager instance is set to 'true', and thus all cell instances result blocks are inserted in the result file, but the period is not completely relevant (SF=1). At the end of the GP 5, the cell instances result blocks are inserted in the result file (SF=0) Note about cell shared: if a cell is shared and the related a secondary BTS is not defined at MFS, then the aCmbCommercialUse is considered equal to True by the MFS. 4.5.9 MFS start-up and re-start The Report Period (RP) is launched automatically by the MFS at initialization time. For example, considering hypothesis below GP is equal to 60mn GPmin is equal to 3mn MFS start or re-start at 9:05
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 51/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
GP alignment at hour boundary defined in section 2.5 RP shifting compared to GP defined in section 2.6 the first GP covers period from 10:00 to 11:00 and the GPMRES file is available at 11:03. All the measurements are performed by the GPU. The OMCP authorizes the measurements in the GPU when it gives the RRM configuration to the GPU. 4.5.10 Reshuffling (cells distribution over GPUs) Recall: A BSS can be managed by several GPUs. The BSS cells are distributed by reshuffling algorithm on the GPUs. The aim of this algorithm is a good repartition of cells to avoid the lack of resource in a GPU . The reshuffling is only triggered by the operator command. Impact: The reshuffling command can move cells from a GPU to another GPU. It triggers a cell delete command on the old GPU and after a cell create command on the new GPU. When the cell is deleted the block is not sent by the GPU and when the cell is created the Suspect Flag is set to TRUE (see 4.5.1Create/Delete instance). The consequence is that just one cell block has the Suspect Flag set to TRUE but the set of cell blocks is all consecutive. Rarely if the deletion/recreation of a cell does not occur in the same GP one block can miss. Warning : in this case the fabric identifier changes for this cell. 4.5.11 Secured Single Gb When the last NS-VC of a GPU becomes disabled due to a Gb failure, the Gb traffic of all cells related to this GPU is re-directed to the other ones of the same BSC. Then, BearerChannel and PVC BLOCKS are still present but counters related to the faulty board and the ones related to the protecting ones are affected (no traffic on the first, more traffic on the others) 4.5.12 PTU counters and PMU counters PTU and PMU counters are splited into different blocks. So that, in case of failure during the PTU counters collection or restart/reset TRE during the GP, the Suspected flag of the PTU blocks are set only. The PMU blocks are not impacted.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 52/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
4.5.13 MFS software migration Before the activation of the (Vn+1), the MFS (active station) is still in (Vn) and GPM is working in (Vn). All GPU are in the same (Vn) version and thus, GPM provides one file in MFS (Vn) format. When the activation is performed, an OMCP switch over occurs. The GPM starts up in (Vn+1). It is now ready to work with GPU (Vn) and GPU (Vn+1). The MFS provides a PM file for previous release if at least one GPU is still running with previous release software The MFS provides a PM file for current release if at least one GPU is still running with current release software (whatever is the Main Release) For the availability at the MFS of the PM files: the OMCP (MFS EVOLUTION) migration is equivalent to OMCP switch-over (see 4.5.7) the GPU board migration is equivalent to a GPU switch-over (see 4.5.5) 4.5.14 IP transport activation/desactivation (GboIP) Regarding the GboIP transport, two flags have been defined: Gb_Transport_Mode (BSS) and Gb_Transport_Mode_per_NSE (NSE). When the NSE is associated to a BSS, Gb_Transport_Mode (BSS) is relevant only. In FR mode, PVC and BearerChannel blocks are relevant while SGSN_IP_NSVC block is not. And inversely, in IP mode SGSN_IP_NSVC block is relevant while PVC and BearerChannel blocks are not. When the Gb transport Mode is changed, the GPU board is reset. And thus, the MFS O&M downloads only the configuration related to the relevant Gb transport Mode. As the next period is not completely relevant (not a full observation period), SF is set to TRUE into relevant blocks. When blocks are no more relevant, they are no more reported. See the "4.5.1 Create/Delete instance" to know the management of the SF. 4.5.15 IP transport activation/desactivation (BSSoIP) Regarding the BSSoIP transport, two flags have been defined: BSS_TRANSPORT_MODE (MFS) and ABIS_TRANSPORT_MODE (MFS) 1. When the BSS_TRANSPORT_MODE (MFS) is changed, the GPU board is reset. And thus, the MFS O&M downloads only the configuration related to the relevant transport Mode. As the next period is not completely relevant (not a full observation period), SF is set to TRUE into relevant blocks. When blocks are no more relevant, they are no more reported. See the "4.5.1 Create/Delete instance" to know the management of the SF.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 53/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
2. When the ABIS_TRANSPORT_MODE (MFS) is changed, the SF of the blocks related to the previous transport Mode is set to TRUE (not a full observation period), and then, as blocks are no more relevant, they are no more reported. Regarding the blocks related to the new transport mode, the SF of the blocks is set to TRUE for the current GP (not a full observation period), then blocks are reported with SF to FALSE. 4.5.16 Gb flex activation/desactivation Regarding the Gb flex feature, the fllowing actication flag is defined: EN_GB_FLEX When Gb_Transport_Mode (BSS) is IP then the EN_GB_FLEX flag is relevant. The SGSN block is never reported if Gb_Transport_Mode (BSS) is Frame Relay. When EN_GB_FLEX is changed from (disabled to enabled), the SGSN block becomes relevant and will be reported. For the current period, SF I set to true (incomplete measures for the Granularity period). When EN_GB_FLEX is changed from (enabled to disabled), the SGSN block becomes irrelevant and is no more reported.
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 54/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
ANNEX A: MFS/OMC FILES EXAMPLE. For counters list, the reference document is document [1]. Here is only example of files. 4.6 Current release MFS / current release GPU: filename "GPMRES0800101" #%npr MFS # { { MFS 102 VERSION MFSYAL05C ITFVERSION 8 ScannerIdentity 1 STARTTIME 10:00:00 ENDTIME 11:00:00 DATE 2008-02-06
ED 1 PROPOSAL 3 MFS/OMC PM file interface specification
B12 MFS-OMC PM FILE INTERFACE E1P4
3BK 11204 0564 DSZZA 98/98
A l l
r i g h t s
r e s e r v e d .
P a s s i n g
o n
a n d
c o p y i n g
o f
t h i s
d o c u m e n t ,
u s e
a n d
c o m m u n i c a t i o n
o f
i t s
c o n t e n t s
n o t
p e r m i t t e d
w i t h o u t
w r i t t e n
a u t h o r i z a t i o n
f r o m
A l c a t e l - L u c e n t
GLOSSARY
BSC Base Station Controler BTS Base Transceiver Station DSF Distribution Suspected Flag GCSF GPU Configuration Suspected Flag GP Granularity Period GPM Global Performance Manager GPRS Global Packet Radio Service GPU GPRS Processing Unit HW HardWare MFS Multi BSS Fast Packet Server NS-VC Network Service Virtual Connection NPO Network Performance Optimization O&M Operation and Maintenance OMC-R Operation and Maintenance Centre for Radio PM Performance Management PVC Permanent Virtual Connection RP Reporting Period SF Suspected Flag SW SoftWare TPM Telecom Performance Manager