The figures given in the two tables listed above must be considered either as maximum or mean values according
to the lines concerned. In order to maintain the level of performances expected in terms of OMC-R stability as well
as in terms of response time, the maximum values must not be exceeded.
Ed 01 Released
MRD HCOM8PE1.DOC v 4 3DC 20012 0010 UZZZA 9/9
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion.
1AA
000
14 0
004
(900
7)A
4
4.3 Traffic Model per Functional Area
The following paragraphs describe the O&M nominal traffic model per function.
4.3.1 Configuration Management Traffic Model
Actions performed in Equipment views:
Hardware configuration move A-bis 1 per 1000 cells per hour
replacement of BTS G2 by Evolium BTS 1 per 1000 cells per hour
add/delete TRE on a Evolium BTS G4 1 per 1000 cells per hour
move Evolium BTS 1 per 1000 cells per hour
add/delete sector on Evolium BTS 1 per 1000 cells per hour
A-ter/Gb Configuration configuration of 1/4 A-termux PCM from GPRS to CS or CS to GPRS
0.5 per 1000 cells per hour
creation/deletion of bearer channel (1/4 of 2Mb PCM)
0.5 per 1000 cells per hour
Remote inventory On request
By default: only list of modifications since the last hardware configuration is uploaded in the OMC-R.
The whole inventory description can be uploaded in case of forced option.
10% of all BTS once a week
Periodic polling once a week (triggered at 1am) (only list of modifications since the last hardware configuration is uploaded in the OMC-R).
20% of all BTS changed in retrofit period
2% of all BTS changed in normal period
Note: Remote Inventory feature is described in the document referenced [4].
• retrofit period: period during which a large number of NEs are modified
• normal period: period during which only repair actions or low number of modifications are
done on the NEs.
Ed 01 Released
MRD HCOM8PE1.DOC v 4 3DC 20012 0010 UZZZA 10/10
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion.
1AA
000
14 0
004
(900
7)A
4
Actions performed in PRC views:
Logical configuration 5% of the cells tuned per day
5 PRC created, checked, activated and accepted per day
Simultaneous PRC activation possible
The PRC can be created either manually or via A956 RNO tuning session imported into OMC-R
List of reconfiguration actions For each tuned cell:
• 5 HO creation/deletion, reselection links,
• 5 HO links parameters modifications
• creation/deletion/modification of FHS
• radio link parameters modifications
• hopping law modifications
• logical channels modifications
• GPRS radio cell parameters modifications: Max PDCH, Min PDCH, Max PDCH per TBF, N TBF per Master, N TBF per PDCH, RX qual threshold to choose CS1 or CS2, number of radio blocks allocated to PRACH, paging channel or packet radio resource.
Number of created PRC in OMC-R database Max 60 Number of simultaneous opened PRC Max 9
Number of simultaneous PRC activation Max 9
Ed 01 Released
MRD HCOM8PE1.DOC v 4 3DC 20012 0010 UZZZA 11/11
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion.
1AA
000
14 0
004
(900
7)A
4
4.3.2 Performance Management Traffic Model
There are two types of Performance Management jobs, the Permanent-Measurement-Campaign
(PMC) and the On-Demand-Measurement-Campaign (ODMC).
4.3.2.1 Permanent-Measurement-Campaign (PMC) Traffic Model
The PMC is intended to collect regularly the same performance data in the whole radio network
controlled by the OMC-R, needed for regular network monitoring and optimization activities by your
network management departments.
There is one PMC per OMC-R. In the PMC, the following standard measurement types can be
activated:
Measurement type Object observed
7: LapD per LapD link of the BSC
8 : X25 per X25 link of the BSC
9 : N7 per N7 of the BSC
18 : A interface per BSC
19 : SMS PP per Cell
25 : SCCP per N7 of the BSC
28 : SDCCH HO per Cell
29: Directed retry per Cell
30: SMS CB per BSC
31: Radio Measurement Statistics per cell, per TRX
GPRS counters per A935-MFS, BSC, cell, LapD, BC, PVC
The number of PM types per PMC depends on the reporting period on the BSS counters:
In following table, the cell scope is all cells of the BSCs.
Ed 01 Released
MRD HCOM8PE1.DOC v 4 3DC 20012 0010 UZZZA 12/12
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion.
1AA
000
14 0
004
(900
7)A
4
Function Description
Permanent-Measurement-
Campaign (PMC) Reporting Period
BSS counters - type 110 per BSC on all BSC
and
- types 18.29 and 32 per BSC on all BSC**
1/2 hour (*)
Traffic flow measurements - type 180 per BSC on all BSCs 4 hours
MFS counters All counters defined in document [3] reported automatically 1 hour
RMS (Radio Measurements
statistics)
- type 31 activated per cell or per BSC. Report per cell for all cells.
Example of typical measurement duration used during load & stress
tests: 7 hours per day.
Once per day
Result files storage duration in
OMC-R
4 days
(*) Other set of measurements or other reporting periods (by steps of 1/2 hour) can be defined by
the operator, but with no guaranteed level of performance.
(**) The listed counters are the ones required by NPA for producing the stored indicators on all
objects reported by the BSC. Other counters can be selected replacing these ones but with
possible impacts on NPA indicators computation.
Radio Measurement Statistics feature is described in the document referenced [5].
Ed 01 Released
MRD HCOM8PE1.DOC v 4 3DC 20012 0010 UZZZA 13/13
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion.
1AA
000
14 0
004
(900
7)A
4
4.3.2.2 On-Demand-Measurement-Campaign (ODMC) Traffic Model
The ODMC allows running temporary measurements with a high granularity on a part of the radio
network during office hours. In an ODMC, any measurement type from the “BSS counters campaign”
list could be activated if it is not already used by the PMC.
Function Traffic OMC-R at office hours Report Period
On-Demand-Measurement-Campaign
BSS counters campaign One campaign per day per 500 cells. The campaign scope is 20 cells per BSC excepted for types 26 and 27 where the scope is one cell only. Max. of four types per campaign among:
1: Traffic 2: Resource availability 3: Resource usage on CCCH 4: Resource usage on SDCCH 5: Resource usage on TCH 6: TCH HO 7: LapD 8: X25 9: N7 18: A interface 19 : Directed Retry 25: SCCP 26: TCH HO for a fixed serving cell (per adjacency: variable target cell) 27: TCH HO for a fixed target cell (per adjacency: variable serving cell) 28: SDCCH HO 29: directed retry 30: SMS CB 32: Change of frequency band measurements
Example: typical campaign tested during load & stress tests is made by types 1, 6, 26 and 27
15 min (minimum)
Observation One campaign per day per 500 cells. All 6 observation types per BSC can be activated simultaneously :
15 cells max without intersection per type - allowing max 75 cells for the 5 types in case the same cell is not selected for several types.
- type 11 : 1 cell per BSC
NB: since B7, because the RMS is considered as permanently activated and brings much more interesting measures than the type 11, the type 11 is no longer included in the traffic model tested during load & stress test campaign.
30 min (minimum)
Result files storage duration in OMC-R 4 days
Ed 01 Released
MRD HCOM8PE1.DOC v 4 3DC 20012 0010 UZZZA 14/14
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion.
1AA
000
14 0
004
(900
7)A
4
4.3.2.3 Counters and Indicators Browser
More than 200 Quality of Service indicators is computed from PMC raw counters after each reporting
period. These indicators give intelligible information about system performance. 10 major QoS
indicators are selected among these 200 indicators. QoS basic alerts are based on the threshold
crossing of these major indicators. Supplementary QoS alerts can be customized using the A1353-
RA optional feature: QoS alerter.
The stored counters and indicators can be displayed at the OMC-R in the form of tables or graphs.
The following table gives traffic information related to the indicators processing and display:
Function Traffic OMC-R
Computation of QoS Indicators and possible QoS alerts
generation
More than 200 indicators computed in real-time after each
reporting period. Duration < 50 minutes
Counter or Indicator evolution graphs or display table 6 views per operator per hour
QoS alerts generation Alert behaviour is equivalent to standard alarm. Thus, alerts
traffic is integrated with all other alarms in the chapter on
fault management traffic model
NPA interface 1 NPA polls the PM results from the OMC-R every 5 minutes
and store files permanent counter types 18, 29, 31, 32, 110
and 180 in its database. In case detailed counter types are
activated, result files are polled in the same way and content
stored.
Storage duration for indicators and counters in MPM
database
5 days
4.3.2.4 NPA storage duration
Overall storage duration table:
QoS month Indicators Storage up to 2 years
QoS day and week Indicators Storage up to 1 year
Raw counters Storage 5 days
1 NPA Network Performance Application is an A1353-RA optional plug-in used for PM post-processing offering
long storage database, accurate warning reports and interface to A956-RNO (Alcatel Radio Network
Optimization tool).
Ed 01 Released
MRD HCOM8PE1.DOC v 4 3DC 20012 0010 UZZZA 15/15
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion.
1AA
000
14 0
004
(900
7)A
4
The table below gives the detailed storage duration for counters and indicators, for the case of full
storage capacity allowed by V880 SUN Server types and above. The storage duration in B8 depends
on cells, TRX, GPU, BSS.
NPA and NPA embedded
MPM
Data Type Object Type
Hourly (days)
Daily (days)
Weekly (days)
Monthly (days)
Hourly (days)
Daily (days)
Weekly (days)
Monthly (days)
Adj 6 6 0 0 0
BC/BVC 6 6 0 0 0
Cell 6 6 0 0 0
Link 6 6 0 0 0
Net 6 6 0 0 0
GPU 6 6 0 0 0
TRX 6 6 0 0 0
Counters
BSC 6 6 0 0 0
Adj 16 93 13 3 6 8 0 0
BC/BVC 16 93 13 3 6 8 0 0
Cell 32 400 58 25 6 8 0 0
Link 16 93 13 3 6 8 0 0
Net 32 400 58 25 6 8 0 0
GPU 32 400 58 25 6 8 0 0
TRX 32 184 26 6 6 8 0 0
Indicators
BSC 32 400 58 25 6 8 0 0
Cell 400 58 25 8
TRX 184 26 6 8 LASER
BSC 400 58 25 8
Cell 16 RMS(vector & matrix) TRX 16
Ed 01 Released
MRD HCOM8PE1.DOC v 4 3DC 20012 0010 UZZZA 16/16
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion.
1AA
000
14 0
004
(900
7)A
4
4.3.2.5 Traces
The BSS release B6.2 introduced a new enhanced trace feature called: "BSS Radio Trace based on
IMSI, on HLR activation". This feature improves and replaces the existing Call Trace capabilities
available in the B5 BSS. (see document reference [3]). The same feature is available in B7 and B8
releases.
The following table gives traffic information related to the trace processing:
Function Nominal traffic at office
hours (per hour)
Maximum traffic at office
hours (per hour) during
one hour
Maximum number of generated radio trace files to be
processed by the OMC-R with no degradation of the QoS
(50% of BSC with active traces)
25 for Small OMC-R
50 for Standard OMC-R
100 for Large OMC-R
250 for X-Large OMC-R
(max size per file = 5 Kb)
250 for Small OMC-R
500 for Standard OMC-R
1000 for Large OMC-R
2000 for X-Large OMC-R
(max size per file = 5 Kb)
Number of simultaneous active traces per BSC 1 Up to 10
Sample measurement reports rate 1 sample every 4 measurements (1)
Trace results storage duration 5 days if 8 hours per day of Trace (10 Mbytes max. per
day)
The rational is as follow:
taking into account that:
• the average duration of a call is 1’ including 1 HO (normal call mix used for telecom load tests),
• each HO event triggers the sending of a trace file from the BSC to the OMC-R, therefore, in average, 2 trace files per minute,
• 20 Kbytes of traces are produced in 2 minutes, therefore 5 Kbytes every 30” (linear sizing)
• the average activity of a mobile is 0.04 Erlang (4% of activity per hour per mobile), meaning that a mobile is in activity during 2’24” per hour, therefore 5 trace files per hour per mobile (2’24” equals around 5 times 30”).
• the BSC cannot trace more than 10 mobiles simultaneously, therefore 50 traces files per hour and 50*5 Kbytes per hour of traces.
Considering that only half the number of BSC is making traces simultaneously, it means that the maximum
number of trace files per hour is:
• 250 for a small OMC-R
• 500 for a standard OMC-R
• 1000 for a large OMC-R
• 2000 for a X-Large OMC-R
Ed 01 Released
MRD HCOM8PE1.DOC v 4 3DC 20012 0010 UZZZA 17/17
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion.
1AA
000
14 0
004
(900
7)A
4
4.3.2.6 Usage State on Demand
This service gives on demand or by monitoring, the Usage State (idle, active and busy) of the current
traffic resources for a given BSC. An overall real-time dashboard per BSC gives availability status
and ratio of Busy / Available resource for each cell and DTC (A trunk interface) of the BSS. Detailed
information is also provided giving Time-Slot State for Cell (TRX_TS) or A-trunk (APCM_TS).
Function Traffic OMC-R at office hours
Usage State On Demand (USOD)
Overall USOD with a refreshing period of 60 s monitoring on one BSC per 1/3 of total number of operators per OMC-R
configuration:
UltraSPARC 2
For Small OMC-R: max 1 BSC
For Standard OMC-R: max 3 BSC
For Large OMC-R: max 5 BSC
For X-Large OMC-R: max 10 BSC
UltraSPARC 3
For Small OMC-R: max 1 BSC
For Standard OMC-R: max 3 BSC
For Large OMC-R: max 7 BSC
For X-Large OMC-R: max 10 BSC
Detailed USOD information Max.: 5 cells per USD view
Overall and detailed USOD cannot be used simultaneously for the same BSC.
Ed 01 Released
MRD HCOM8PE1.DOC v 4 3DC 20012 0010 UZZZA 18/18
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion.
1AA
000
14 0
004
(900
7)A
4
4.3.3 Fault Management
Definition: a fault event can be either an alarm begin or an alarm end or a state change.
The fault traffic is made of 25% of state change and 75% of alarms. BSC alerters are permanently
activated on BSC and generate alarms included in the alarm traffic defined below.
Function Traffic OMC-R
Current Fault events handling Average fault traffic:
• 0.07 fault events per TRX per hour from BSC equipment
• 0.07 fault events per TRX per hour from BSC transmission
• state changes from BSC are negligible.
• 0.07 fault events per TRX per hour from BTS
• 0.01 fault events per TRX per hour from MFS
• 0.03 state change per TRX per hour from MFS
• 0.005 per TRX per hour alarms from QoS alerters (10% of overall number of
alarms)
Storage duration: 30 days
(around 260 000 alarms stored for a Large OMC-R configuration)
Threshold for transferring alarms from the Current Alarm List (CAL) to the Historical
Alarm List (HAL):
• 2000 alarms for OMC-R configuration with less than 200 cells
• 1 alarm per cell for OMC-R configuration with more than 2000 cells
The alarms are automatically acknowledged.
The operators display 25 alarms per 1000 cells per hour.
10% of alarm begin are reserved
Historical fault events handling 5 historical searches per 1000 cells per hour
Investigation 25 displays of BTS/BSC RIT per 1000 cells per hour
1 Lock/unlock BTS/BSC RIT per 1000 cells per hour
0.25 displays inventory data per 1000 cells per hour
Export of alarms and state
changes
Automatic export of current alarm list : one export every 10 minutes
Automatic export of historical alarm list (once a day)
Automatic export of state change : permanently logged
NB: The threshold for switching an alarm from the CAL to the HAL can be customised but the
proposed values in the above table are recommended as a limit in order to avoid time-response
degradation when opening the alarm views.
Ed 01 Released
MRD HCOM8PE1.DOC v 4 3DC 20012 0010 UZZZA 19/19
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion.
1AA
000
14 0
004
(900
7)A
4
4.3.4 Q3 Mediation
Object Notification All notifications (creation/modification/deletion) are
mediated
Fault events All faults events are mediated
Get 0.1 per cell per hour; scope = 1 instance of one object
NB: In case of alarm peak, the Q3 mediation is impacted in terms of number of alarms mediated in a
period of time. From the OMC-R point of view, there is no degradation of the mediation QoS,
assuming that the NMC connected to the OMC-R is able to support the additional load due to the
peak traffic.
4.3.5 Data Export
The following data exports are automatically performed by the OMC-R according to the schedule
given in the table below. See chapter 4.1 for the schedule of these tasks along the daytime.
Supervised Configuration (for A9156 RNO) Once a day
Hardware Configuration per BSC (for NPA and A9156 RNO) Once a day
Export of AS data (for Laser) Once a day
4.3.6 Night batch processes
The following batches processes run during the night. They are scheduled by Alcatel in order to
completed before 7 am. Modification of this schedule is not allowed.
List of batch processes
Backup DLS DLS from all supervised BSC are stored on the OMC-R
once a day
Remote inventory BTS inventory data are stored in the OMC-R once a week
QoS indicator calculation (MPM) Once a day
Clean-up PM files Once a day
Incremental backup Once a day
Full backup Once a week (recommended)
Ed 01 Released
MRD HCOM8PE1.DOC v 4 3DC 20012 0010 UZZZA 20/20
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion.
1AA
000
14 0
004
(900
7)A
4
4.4 Peak Traffic
The peak traffics listed below must be considered as examples of the most frequent peak traffic
encountered on an OMC-R. Other peak activity can exist on the system but are not described here.
4.4.1 Alarm Peak Traffics
Two alarm peaks are defined, coming on top of the nominal alarm flow.
In both cases, the expected results are:
• no QoS degradation for the BSC not in peak (nominal behaviour);
• for BSC in peak, the duration for coming back to the nominal QoS must not exceed 5
minutes after the end of the peak.
4.4.1.1 Peaks for 2 hours
This peak case intends to demonstrate OMC-R stability under a high level of alarms during a
relatively short period of time.
Assumption is that a BSC under peak conditions can produce around 1000 alarms per hour,
So, the maximum number of BSC under peak conditions can be deduced from the above table.
4.4.1.2 Peak for 2 days
With this peak traffic, the aim is to simulate on one equipment a problem remaining not solved for 2
days, generating one event per second (begin or end).
This peak is the same whatever the OMC-R configuration.
Number of alarms per hour
For OMC-R with UltraSparc 2
For OMC-R with UltraSparc3
Small OMC-R 2375 2625
Standard OMC-R 2750 3250
Large 1 OMC-R 3800 5000
Large2 OMC-R 4400 5750
X-Large OMC-R 9000 12000
Ed 01 Released
MRD HCOM8PE1.DOC v 4 3DC 20012 0010 UZZZA 21/21
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion.
1AA
000
14 0
004
(900
7)A
4
4.4.2 Frequency Plan Peak Traffic
A PRC including all the cells managed by the OMC-R will be created, checked, activated and
accepted.
The same actions as listed in 4.3.1 for small PRC are applied during the frequency plan change.
The periodicity of such large modifications is highly variable. In Alcatel lab, for test purpose, one
frequency plan will be applied every week.
The production of the frequency plan can differ in Alcatel lab from the method used by customers in
the field. Nevertheless, from the OMC-R traffic model point of view, the only important thing is the
size of the PRC (i.e. number of cells involved and number of parameters modified per cell).
