Nortel DMS-100 Office Parameters Overview |
Introduction
Office parameters are initially set by Northern Telecom (Nortel) to meet end-of-design criteria and switch configuration. This overview is intended to assist operating company personnel responsible for administering office parameters by providing guidelines to using the available tools.
Office parameters examined in this document are located in table OFCENG (Office Engineering). These parameters allocate resources (memory) for switch activities such as call throughput and custom calling usage. These parameters are initially calculated using operating company input, high day/end-of-design criteria, and standard engineering formulas. The formulas are designed for standardization and simplified operating company and Nortel use. The formulas are constructed to cover a wide variety of applications and are considered set up for end-of-design for most applications.
An ongoing process should take place to determine if parameter settings are appropriate for each office's requirements. This process should include the monitoring of actual parameter usage compared to the parameter setting in the switch. Offices may have to adjust individual parameter settings to match the changing office requirements.
Offices not at the end-of-design could reclaim memory for a period of time by reducing office parameter settings. Caution should be used in lowering office parameters to prevent impact to switch operation during high-day operation. Some parameters are not recommended for value reduction. See the section "Office Parameters that are Not Recommended to be Modified".
Memory allocated for office parameters can be reclaimed during the software delivery by way of dump and restore if the decision is made to lower office parameters. However, office parameter changes should be safely and systematically implemented before a dump and restore.
What to Collect
The following data should be collected to determine the usage of many of the office parameters in table OFCENG:
Operational Measurements
The Operational Measurements (OM) and especially the high watermark OMs can be used as a bench mark of the levels of traffic-dependent activity in the switch during the current interval. The high watermark OMs display the highest level of simultaneous usage reached in critical office parameters for the collection period. Overflow OMs display the number of times that the parameter was required but no resources were available.
The following OM groups should be monitored:
CP2 measures Call Processing software resources such as call processing letters, call condense blocks, and wakeup blocks. EXT measures Extension Block usage such as special billing records, data extensions for operator services, and custom calling features. FTRQ measures Feature Queuing Resources for Meridian Digital Centrex (MDC) features such as call hold, last number redial, and call waiting. Refer to the Operational Measurements Reference Manual for information on the registers and corresponding office parameters measured.
An OM accumulating class made up of CP2, EXT, and FTRQ should be defined with the same collection period as office parameter OMXFR in table OFCENG. When datafilling tables OMACC and OMPRT, field WHEN set to AUTO guarantees this. The collection period and transfer period should be the same to ensure that the high watermark registers present a valid picture of peak activities. With a 1-hour collection period and a 30-minute transfer period, the peak levels are summed.
The following is an example of setting up an OM class that contains OM groups EXT, CP2, and FTRQ. The symbol ">" represents commands to be entered.
The OM class to be defined is called REALTIM3. Double precision is used.
>OMCLASS REALTIM3 DOUBLE
List table OMACC to see the tuple added.
>LIS ALL
The table is listed. Position on the newly added tuple.
>POS REALTIM3 CLASS ENABLED WHEN REALTIM3 N AUTO
Change the tuple.
>CHA ENTER Y TO CONTINUE PROCESSING OR N TO QUIT. >Y ENABLED: N >Y REP: AUTO TUPLE TO BE CHANGED: REALTIM3 Y AUTO ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT. >Y TUPLE CHANGED. WRITTEN TO JOURNAL FILE AS JF NUMBER 544 >QUIT CI:
Add OM groups to the OM class.
>OMACCGRP REALTIM3 ADD GROUP CP2 OK >OMACCGRP REALTIM3 ADD GROUP FTRQ OK >OMDUMP CLASS REALTIM3 COMMANDS OMCLASS REALTIM3 DOUBLE OMACCGRP REALTIM3 ADD GROUP CP2 OMACCGRP REALTIM3 ADD GROUP EXT OMACCGRP REALTIM3 ADD GROUP FTRQ >TABLE OMPRT TABLE: OMPRT >LIS ALL
Table OMPRT is listed. Position on an unused position. Position 228 is chosen in this example.
>POS 228
Change the tuple.
>CHA ENTER Y TO CONTINUE PROCESSING OR N TO QUIT >Y ACTIVE: N >Y SUPZERO: N > ID: ALL >ALLCLASS CLASS: >REALTIM3 REP: MONTHLY >AUTO BUFFOUT: N > OUTDEV: SINK > TUPLE TO BE CHANGED: 228 Y N ALLCLASS REALTIM3 AUTO N SINK ENTER Y TO CONFIRM. N TO REJECT OR E TO EDIT. >Y TUPLE CHANGED WRITTEN TO JOURNAL FILE AS JF NUMBER 547 >QUIT CI: >LOGUTIL LOGUTIL: >ADDREP TATSPRT OMPR 228 Note: TATSPRT is a local printer defined for this example. 1 report(s) Added >LISTROUTE DEVICE TATSPRT Device TATSPRT print classes: ADD REPORTS: OMPR 228 (OM REPORT) DELETE REPORTS: >STARTDEV TATSPRT Log device TATSPRT has been started. Number of devices started : 1 >STOPDEV TATSPRT Log device TATSPRT has been stopped. Number of devices stopped : 1
DMSMON
DMSMON is used to gather switch data as well as high watermark OMs. The switch data can be used in calculating office parameters in place of the engineering estimates used at initial load time.
DMSMON uses OM results as inputs for the DMSMON high watermark report. DMSMON itself keeps a running tab of a subset of parameter high watermarks over a 30-day period. For the parameters that are currently reported by DMSMON, this report is the easiest for the administrator to use. However, since all the high watermark OMs are not included in DMSMON, the OM groups mentioned previously should be collected. Also, parameter overflows are not reported in DMSMON output, only in the OM groups.
The following command produces the needed DMSMON information from the CI level of the MAP display:
>DMSMON >HIGHPARMS
The following DMSMON example shows a subset of actual counts of switch data and high watermarks for office parameters:
----------------------------------------------------------------------------------------- Number of nodes: 379 Number of networks: 0 Number of TM8 PMs: Insv: 3 Comm : 0 Number of MTM PMs: Insv: 53 Comm: 0 Number of LGC PMs: Insv: 12 Comm : 0 Number of LCM PMs: Insv: 48 Comm : 0 Number of DTC PMs: Insv: 13 Comm : 0 Number of DP_POTS lines: 3 Number of DGT_POTS lines: 15 Number of DP_IBN lines: 185 Number of DGT_IBN lines: 2835 Number of TOTAL_UNEQ lines: 15962 Number of TOTAL_OFFL lines: 5373 Number of PPHONE_STATION lines: 152 Number of DISPLAY_PPHONE_STATION lines: 35 Number of M3009_STATION lines: 6705 Number of M5112_STATION lines: 618 Number of M5209_STATION lines: 144 Number of M5312_STATION lines: 37 Number of DNs on keysets: 35403 Number of IBN lines with CALL WAITING FEATURE: 8 Number of IBN lines with CALL FORWARDING FEATURES: 508 Number of IBN lines with SPEED CALL FEATURE: 225 Number of KSET lines with CALL WAITING FEATURE: 4 Number of KSET lines with CALL FORWARDING FEATURE: 6613 Number of KSET lines with SPEED CALL FEATURE: 6327 Number of trunks: 4704 Number of unequipped trunks: 10655 Number of offline trunks: 554 Number of trunk groups: 715 Number of IBNTI trunks: 893 Number of IBNTO trunks: 334 Number of IBNT2 trunks: 49 Number of OP trunks: 52 Number of RCVRMF receivers: 8 Number of RCVRDGT receivers: 4 (expected:8) ***** Number of RCVRATD receivers: 32 Number of CF3 ports: 70 Number of CF6 ports: 83 Number of LTUs: 6 Number of TTUs: 5 Number of VDUs: 39 Number of customer groups: 253 Number of consoleless customer groups: 250 Number of customer subgroups: 2 Number of attendant consoles: 30 -----------------------------------------------------------------------------------------
Tables of Daily Usage for Critical Office Parameters
The following partial report shows 20 days of high watermark values with the most current one (yesterday) being printed first.
----------------------------------------------------------------------------------------- Example 1 NUMCPLETTERS NCCBS NUMCALLPROCESSES NUMOUTBUFFS NMULTIBLKS NUMCPWAKE ----------------------------------------------------------------------------------------- 13 97 4 51 2 6 12 105 4 51 3 3 17 914 4 51 13 28 18 908 4 51 16 32 16 893 5 51 14 29 14 761 5 51 11 27 13 63 4 51 2 4 12 70 4 51 3 7 12 85 4 51 3 8 12 457 4 51 7 19 18 504 4 51 9 18 11 435 4 51 8 19 12 273 4 51 5 13 12 63 4 51 3 4 12 66 3 51 2 4 12 80 4 51 3 8 12 512 4 51 9 21 14 796 5 51 12 31 23 941 5 51 15 50 16 874 5 51 13 31 ----------------------------------------------------------------------------------------- -End-
----------------------------------------------------------------------------------------- Example 2 FTRQAGENTS FTRQ0WAREAS FTRQ2WAREAS FTRQ4WAREAS FTRQ8WAREAS FTRQ16WAREAS ----------------------------------------------------------------------------------------- 9435 0 3437 6230 0 0 9437 0 3511 6179 2 1 9451 0 3862 6120 12 3 9445 0 3865 6185 11 3 9459 0 3784 6330 14 2 9451 0 3587 6360 10 2 9435 0 3334 6361 0 0 9436 0 3345 6342 0 0 9435 0 3377 6337 0 0 9443 0 3469 6359 7 2 9441 0 3458 6390 7 2 9440 0 3456 6396 6 3 9437 0 3458 6327 8 3 9430 0 3451 6283 0 0 9430 0 3454 6271 0 0 9429 0 3450 6265 0 0 9439 0 3582 6261 4 2 9435 0 3796 6174 10 3 9438 0 3935 6090 14 3 9433 0 3923 6090 16 2 ---------------------------------------------------------------------------------------- -End-
Table OFCENG
Table OFCENG lists the setting of parameter values. This table should be listed to provide the parameters to be considered and their current settings. The table can be listed with the following CI command:
>TABLE OFCENG;LIST ALL;QUIT
The following example shows a subset of table OFCENG:
----------------------------------------------------------------------------------------- Parameter Name Parameter Value ----------------------------------------------------------------------------------------- ACD_MIB_OUT_EVENT_BUFFER_SIZE 110 ACD_TOLL_DELAYED_BILLING N ACT_MAX_DURATION 255 ALL_ACD_LOGIN_IDS_VALID Y ALT_TTT_USAGE_PERCENTAGE 50 AMA_FAILURE_FREE_CALL Y AMA_LONG_DUR_AUDIT_INTERVAL 24 ATTLOG 1000 AVG_NUM_TGS_PER_OHCBQCALL 4 BELL_ANI_ALARM_ID 9 BELL_ANI_INTERCEPT_ID 9 CABLE_LOCATE_TIMEOUT 180 CABLE_SHORT_TIMEOUT 180 CC_ENGLEVEL_WARNING_THRESHOLD 77 CFD_EXT_BLOCKS 3500 CFW_EXT_BLOCKS 350 COINDISPOSAL IGNORE_COIN COMMAND_SCREEN Y COPP_RELAY_OPEN_TIME 80 CPSTATUS_SWITCHABLE Y CBLINK_ALARM_THRESHOLDS 30 60 CUSTOMER_GROUP_IBNGRP_OM_COUNT 512 DATA_COS 0 DEBUG_HUNT_SWERRS N DEFAULT_CARRIER_OR_TREAT C 288 DEFAULT_COMMANDCLASS 0 DEFAULTLANGUAGE ENGLISH DISC_TIME_BILLED Y DISCTO_TIMEOUT_VALUE 13 DM_PCM_ENCODING DM_MU_LAW DTER_AUTO_DEACTIVATION_ENABLE Y EA_CCIS6_TANDEM_BILL N EA_OCS_AND_DP_OVLP_NEEDED N EA_OCS_DIGCOL_METHOD PXFALL EA_OVERLAP_CARRIER_SELECTION Y EA_WITH_CD N EADAS24H_BUFFER_SIZE 7100 EADAS30M_BUFFER_SIZE 32000 EADAS60M_BUFFER_SIZE 7100 EBS_BUZZ_SPLASH_ON Y EBS_TO_TRUNK_TRD_TIME 50 ENHANCED_DEAD_SYSTEM_ALARM Y EXPIRED_PASSWORD_GRACE 3 ----------------------------------------------------------------------------------------- -End-
How to Interpret What is Collected
The OMs provide an indication of overflows. If there are insufficient resources for a given office parameter, the OMs indicate this with an overflow peg. Parameter usage should be monitored in all offices, not only those interested in reducing office parameters for the purpose of memory reclamation.
When examining registers FTRQHI and FTRQSEIZ of OM group FTRQ and the FTRQ entities in DMSMON HIGHWATER, it should be noted that these parameters reflect the number of blocks simultaneously in use. The corresponding FTRQ office parameters reflect the number of blocks allocated in multiples of 10. For example, a setting of 300 for office parameter FTRQAGENTS allows for a FTRQAGENTS high watermark of 3,000. This multiple of 10 factor applies only to FTRQ parameters (that is, FTRQAGENTS, FTRQAUDIT, FTRQ0WAREAS, FTRQ2WAREAS, FTRQ4WAREAS, FTRQ8WAREAS, FTRQ16AREAS, FTRQ32WAREAS, FTRQ0WPERMS, FTRQ2WPERMS, FTRQ4WPERMS, FTRQ8WPERMS, FTRQ16PERMS, and FTRQ32PERMS).
The following example shows that FTRQAGENTS is set to 1261 in table OFCENG. This setting allocates 12,610 FTRQAGENT blocks as indicated in field FTRQOM_INFO in the OM group FTRQ. For the sample period, the high watermark, field FTRQHI, indicates a maximum of 6,137 feature queue blocks in simultaneous use.
CI:
>TABLE OFCENG : POS FTRQAGENTS
TABLE: OFCENG
FTRQAGENTS 1261
>LIS 10
PARMNAME PARMVAL
FTRQAGENTS 1261
FTRQAUDIT 10
FTRQOWAREAS 1
FTRQ2WAREAS 1575
FTRQ4WAREAS 799
FTRQ8WAREAS 800
FTRQ16WAREAS 1
FXOGS_REMBSY_BITS A_OFF_B_OFF_HK
GLOBAL_CUTOFF_ON_DISCONNECT Y 80 N
GROUND_START_DELAY Y
>OMSHOW FTRQ HOLDING
FTRQ
CLASS: HOLDING
START: 1990/01/12 14:00:00 FRI:
STOP: 1990/01/12 14:15:00
SLOWSAMPLES: 9 :
FASTSAMPLES: 90 :
KEY (FTRQOM_TUPLE_KEY)
INFO (FTRQOM_INFO)
FTRQSEIZ FTRQOVFI
FTRQHI
0 FTRQAGENTS
12610
369 0 6137
1 FTRQOWAREAS
10
0 0 0
2 FTRQ3WAREAS
15750
509 0 3394
3 FTRQ4WAREAS
7880
238 0 2828
4 FTRQ8WAREAS
8000
72 0 30
5 FTRQ16WAREAS
10
0 0 0
Referring to the tables in Example 1 and Example 2, the high watermarks can be interpreted. The last 20 days of high watermarks are displayed. For FTRQ4WAREAS, 6,396 is the highest value displayed. For this office, parameter FTRQ4WAREAS in table OFCENG is set to 693. Accounting for the factor of 10, this allows for 6,930 blocks. Operating company personnel may decide to raise this parameter since the high water value is so close to the parameter setting.
For parameter NUMCPWAKE (number of call processing wakeups), 50 is the highest 20-day value. For this office, parameter NUMCPWAKE in table OFCENG is set to 425. Assuming the high day for this event is during the sample period, the operating company may decide to lower the parameter slightly to recover memory, or leave the parameter set as is.
As can be seen in the above two cases, if the value is increased or decreased, office memory is impacted. If a parameter value is increased and made active, more memory is allocated for that resource from spare or not in use pool of office memory. On the other hand, if a parameter value is reduced, made active, and taken through the dump and restore process, office memory is returned to the spare pool of memory. Complete memory reclamation cannot take place without a dump and restore.
How Often to Collect
It is imperative that the operating company monitor the actual usage regularly to account for high day busy hour for each of the critical office parameters and changing calling traffic patterns. Each of these factors should be taken into account to establish the time interval for examining OMs.
High day busy hour for each event must be considered. The high day busy hour for POTS features may be very different than that of Meridian Digital Centrex features. Based on this criterion, usage must be monitored based on the office parameters being analyzed. For example, CFW_EXT_BLOCKS allocate the number of simultaneous active call forwarded calls.
Traffic patterns can change dramatically over time, and therefore, the actual usage could fluctuate dramatically. Actual usage must be monitored on a regular basis to determine if trends are evolving. The decision to collect daily, weekly, or biweekly is the decision of the individual operating company.
How to Make a Decision
Criteria must be chosen to decide whether to lower or raise parameter values. An operating company engineer can choose criteria such as never reducing a given office parameter at all or never reducing an office parameter below three times (or more) the highest ever high watermark.
Lowering office parameter values should be carefully considered. In general, Nortel does not recommend lowering office parameter values unless office memory is in jeopardy.
Factors such as planned large office additions and office history play an important role in deciding how large a buffer to add to the office data. The operating company is responsible for determining howlarge to make the buffer above the high watermark OMs. It is strongly recommended that the office be monitored for many months before making a decision.
Most operating companies will probably decide never to reduce office parameter values, unless office memory is exhausted.
Office Parameters that are Not Recommended to be Modified
In general, the memory-allocating office parameter values in table OFCENG can be considered for lowering. However, Nortel does not recommend changes to the following parameters. Any changes are made at the operating company's discretion.
Reducing Office Parameter Values
The preferred method of implementing office parameter reductions is to gradually make changes in the existing office parameter tables, performing the necessary restarts as required during very low-traffic times. Changing two or so parameter values downward at a time, then verifying that the changes had no adverse effect is the safest way to implement reductions. Possible problem variables are kept to a minimum and a known safe fallback is available. If troubles do arise, reverting back to the old values can be done quickly. The OMs should be monitored closely to ensure proper engineering. All changes should be made at least three weeks prior to the dump and restore or One Night Process (ONP). At least three weeks is required to allow the software delivery process to capture the new values.
Memory is not reclaimed until the dump and restore is performed. At that time, the reduced values are copied from the existing load into the new office load.
If parameter reductions are required, the operating company should communicate their intentions and work with the Nortel regional software systems engineering manager.
Increasing Office Parameter Values
Increasing parameter values is a safer process than reducing them. The major issue with increasing parameter values (other than timing related parameters) is the increased memory requirements. Unlike reducing parameter values, memory is utilized immediately upon activation (usually a cold restart). Often, parameters in table OFCENG require more memory when increased. The memory requirements for parameters are in the data store area for NT40 loads, but in total office memory for SuperNode loads, where there is no distinction between data and program store.
A basic outline of when values should be increased follows:
Notifying Nortel
To ensure propagation to future software releases of decreases made to office parameters, the operating company must contact their regional software systems engineering manager with a single point of contact at the operating company. The contact should be able to approve of any changes to the office parameters for a given office.
Nortel engineers office parameters based on operating company input and standard formulas. A wide variety of applications are covered by the standard formulas. These formulas yield a safe value in nearly every office. The operating company should monitor the office parameter usage on an ongoing basis to determine if the parameter settings are appropriate for the office application.
Any changes made to the office parameters discussed in this document result in a change in the memory allocated in the switch. An increase in a setting requires more memory. A decrease in value decreases memory requirements. A decrease in a parameter value only yields an actual memory decrease if a rebuild (that is, a dump and restore) occurs.