traffic recording/measuringread.pudn.com/downloads171/ebook/793240/shost07.pdfbe accessed by mml...

Traffic Recording/Measuring

Chapter 7

This chapter is designed to provide the student with anunderstanding of traffic recording and measuring used to collectdata for the reports needed to monitor the services provided. Itwill address the components the functions, features, andrequired specifications to perform the recording/measuringrequired.

OBJECTIVES:Upon completion of this chapter the student will be able to:

• Initiate Traffic Measurements on Routes by command

• Initiate Traffic Type Measurements by command

• Initiate Traffic Dispersion Measurements by command

• Describe other available measurement functionality that canbe accessed by MML commands.

CME 20/CMS 40 Statistics Handling

EN/LZT 123 3316 R2A

ll aa nn kkBB

iioonnaall llyy

ttnneettnnII

7 Traffic Recording/Measuring

EN/LZT 123 3316 R2A – i –


Table of Contents

Topic Page

SECTION I - TRAFFIC MEASUREMENT ON ROUTES......................73

DESCRIPTION............................................................................................................. 73

REPORT GENERATION ............................................................................................. 74

REPORT INTERPRETATION...................................................................................... 75

SECTION II - TRAFFIC TYPE MEASUREMENT.................................79

DESCRIPTION............................................................................................................. 79



SECTION III - TRAFFIC DISPERSION MEASUREMENT ...................85

DESCRIPTION............................................................................................................. 85



SECTION IV - TIME CONGESTION MEASUREMENTS .....................88

DESCRIPTION............................................................................................................. 88



SECTION V - TRAFFIC CHARACTER MEASUREMENT ...................90

DESCRIPTION............................................................................................................. 90



SECTION VI - TRAFFIC OBSERVATION MEASUREMENT ..............93

DESCRIPTION............................................................................................................. 93



SECTION VII - SERVICE QUALITY MEASUREMENTS .....................95

DESCRIPTION............................................................................................................. 95


– ii – EN/LZT 123 3316 R2A




EN/LZT 123 3316 R2A – 73 –

SECTION I - TRAFFIC MEASUREMENT ON ROUTES

DESCRIPTION

The purpose of traffic recording on routes is to get backgroundinformation for long-term planning and to check thedimensioning of the routes during a specified collection interval.The traffic may be collected for various types of routes whichare placed into the following categories based on thefunctionality of the route:

/RVV�6\VWHP�5RXWHV Trunk circuits and other trafficcarrying routes, such as BT, MBLT,MCELT and MVC devices.

4XHXH�6\VWHP�5RXWHV CSR, internal routes, and otherroutes that can be queued against.

3%;�6XEURXWHV BL phones and the associatedsubroutes used for them.

All reports are essentially the same and have only a fewdifferences as explained in this lesson.

Loss System Routes

In the Loss System, a call attempted is immediately rejectedwhen there is no idle device in the route. The routes using thismethod are called Loss System Routes, LSR.

The LSR can be used as an aid to Cell Traffic on the VoiceChannel (MBLT) Devices, Inter-System Handoff Devices(MCELT), Call Delivery (BT7) Devices, and PSTN (BT1 andBT4) Devices.

Queue System Routes

In the AXE, there are devices used only a short time in the set-up phase of a call, code senders. When all devices of this typeare busy, a new call is not rejected but is put into a queue. Assoon as an idle device is available, the call is processed. Thismethod of handling call attempts, shown in Figure 2, is called aQueue-System or Delay-Call System. The routes using thismethod are called Queue-System Routes, QSR. The QSR areused for determining the devices for CS (code sender), CR (codereceiver), KR (keyset receiver), CSR (code sender receiver),


– 74 – EN/LZT 123 3316 R2A

ASCM (Auxiliary Services Coded Announcement DeviceModules), and other internal routes.

In this type of system, calls are rejected when the queue is full orwhen the subscriber gives up. Expiration of time supervision,e.g., due to a technical fault, is another reason calls are rejected.

REPORT GENERATION

To obtain these reports, use the operational instruction, “TrafficMeasurement on Routes, Define”.

If the output is to go to a file, it will be put into a file on theIOG11 named TRARFILE. If the output is to go to an ATterminal, it will be in alphanumeric format.

Alphanumeric Report Format (AT Terminal)

Reports are generated as described above and are displayed onan AT terminal. The three possible reports are:

• Traffic Measurement on Routes Results, LSR

Printout of the traffic recording result for recording objectswith loss system. It does not include PBX routes.

• Traffic Measurement in Routes Results, PBXR

Printout of traffic recording results for PBX routes.

• Traffic Measurement on Routes Results Lost

Printout of information lost due to system restart or systemevent.

• Traffic Measurement on Routes Results, QSR

Printout of traffic recording results for recording objectswith delay system.

For more information on these reports, refer to the relevantprintout descriptions.

File Format (TRARFILE on IOG11)

If file format is requested, the raw report data will be stored inan IOG11 file, TRARFILE. The records contained in this fileare:

• ADM


EN/LZT 123 3316 R2A – 75 –

• ROUTELOSS

• ROUTEPBX

• ROUTEQUEUE

• ADM1

This data can be used as input into a post processing application.For more information refer to the printout description forTRARFILE.

REPORT INTERPRETATION

This function is used to analyze traffic on a per route basis, ortotal the traffic by route type (MBLT, MCELT, BT4, etc.). Thefollowing information can be obtained from the reports outlinedabove:

• Average BIDS per Circuit

• TRAFF per Circuit

• TRAFF per BID

• TRAFFIC per B-Answer

• Percentage of System Traffic by Route

• Number of Circuit Requests Experiencing Congestion

• Utilization

To obtain this information, certain calculations must be madeusing data from the LSR report. The formulas and their purposeare discussed in the following sections.

Average BIDS per Circuit

NBIDS / NDV = Bids per Circuit

NBIDS / (NDV - ANBLO) = BIDS per Working Circuit

These formulas calculate the number of call attempts per circuit.There should be a "normal" range for this during the busy hour.A large deviation from the norm could indicate that there areproblems with the circuits in the route. If this is suspected, thenother reports can help identify the cause of the problem such asthe following:

• Service Quality Statistics

• Seizure Quality Supervision

• Time Congestion Measurement


– 76 – EN/LZT 123 3316 R2A

• Traffic Observation

• Digital Path Supervision

• Cell Traffic Statistics

TRAFF per Circuit

TRAFF / NDV = TRAFF per Circuit

TRAFF / (NDV - ANBLO) = TRAFF per Working Circuit

This formula will provide an indication of the amount of trafficcarried by the route on a per circuit basis. The indications canlead to further reports, as previously mentioned.

This report can be converted into minutes or seconds as needed.

TRAFF per BID

TRAFF / NBIDS = TRAFF per BID

This formula shows the average traffic (TRAFF) carried by onecall attempt. The MHTIME field is also the same information.This is simply a profile of the average call length on the route.

It may be converted into minutes or seconds as needed.

TRAFFIC per B-Answer

TRAFF / NBANSW = TRAFF per B-Answer

When this field is used, the amount of traffic carried by actualanswered calls can be determined, rather than call attempts.

The following formula can also be used:

NBIDS - NBANSW = Unanswered Calls

Further investigation may be required if there are a high numberof unanswered calls. The reports that can help in the researchare:



• Traffic Dispersion Measurement

• Traffic Measurement on Routes

• Seizure Quality Supervision


EN/LZT 123 3316 R2A – 77 –

Percentage of System Traffic by Route

(TRAFF / TRAFF from Traffic Type Measurement) x 100 =Percentage

(NBIDS / NBIDS from Traffic Type Measurement) x 100 =Percentage

This calculation provides an indication of how much trafficgenerated in the system is carried by a specific route.

It is important to remember that the routing cases can have anaffect on this, particularly if Time Switching, RandomDispersion, and Branching Conditions are used. However, ifthere is reason to suspect that the routing cases are not correct,the Traffic Dispersion function can be used to provide furtherinformation.

For example, assume that the normal percentage of traffic basedon NBIDS is 20 % for the Long Distance route. The data isanalyzed for a period of time, i.e., 3 ABSBH reports and thenormal amount is now 30 %.

To find the problem, the Traffic Dispersion function can be usedto see if local traffic was re-routed to the Long Distance routesby mistake.

Another cause could be that the routing case is okay, but theroute used as first choice has several blocked devices, forcing anoverflow to the alternate routes. Use the Time Congestionfunction for more information.

If the route belongs to a cell site, the indication could lead tofaulty channel devices. Investigate further by using thefollowing functions:


• Radio Disturbance Recording

• Radio Environment Statistics

• Traffic Observation

Number of Circuit Requests Experiencing Congestion

CCONG x NBIDS = Number of Lost Bids

This formula indicates the number of circuit requestsexperiencing congestion at the route level. This does notnecessarily mean the call did not process. Alternate routing in


– 78 – EN/LZT 123 3316 R2A

the Routing Case as well as branching conditions in the EOScould have an affect on congestion.

For more information, use the following functions:

• Traffic Character Measurement



Utilization

(TRAFF / (.7 x (NDV - ANBLO)) x 100 = PercentUtilization

(TRAFF per circuit / .7) x 100 = Percent Utilization

As with the Traffic Type Measurement, this result is based on .7Erlangs per circuit. The standard set by the customer should beused for this formula. Whether .7 Erlangs per circuit is used orsome other standard, the resulting information means the samething.

When the determined capacity is reached, more circuits (orchannels) will be needed to carry the traffic. As this is on a perroute basis, the cell or trunk type that needs to be added can beeasily identified. The following functions can be used to obtainmore information:

• Traffic Character Measurement





The QSR report is self explanatory. The two primary fields tomonitor are NBIDSQ and AQL. No matter what the number ofbids reflected in the NBIDSQ, the average queue length per bidin the AQL field should always be less than 2 seconds (orwhatever the maximum time set by operating company’smanagement). A high value, 2 seconds or more, normallyindicates that more devices (code senders, code receivers, etc.)should be added to the route type in the report.

The PBXR report is not discussed in this lesson as it reports onBL phones - not mobile phones.


EN/LZT 123 3316 R2A – 79 –

SECTION II - TRAFFIC TYPE MEASUREMENT

DESCRIPTION

Traffic Type Measurement provides a view of how the CMS isperforming for overall call processing based on call types. Thismeans that data on different traffic types, such as incoming,outgoing, originating, terminating, internal and transit traffic,can be recorded. Areas that require investigation, such asincoming call problems, may be found on this report.

This report only provides a broad view of how the system isperforming. Problems occurring may not be evident in thisreport because it is a summation of all calls.

Fortunately, the AXE has a very powerful and flexible trafficand statistic collection data base. By using the propercommands and setup, areas that need further tuning can easily beidentified, whether it be for more or less circuits, or simplyadjustments to the routing of calls.

REPORT GENERATION

To generate the Traffic Type Measurement report, follow theinstructions given in the operational instruction, “Traffic TypeMeasurement, Initiate”.

When the results are output to an AT terminal, the “Traffic TypeMeasurement Result” report will be given in alphanumericformat. If the output is directed to the IOG11, the informationwill be sent to a file named TRARTFILE.

Alphanumeric Report Format (at Terminal)

For more information on the report format, refer to the printoutdescription for “Traffic Type Measurement Result”.

File Format (TRARTFILE on IOG11)

The IOG11 file, TRARTFILE, contains data that can be used asinput to a post processing application. The records contained inthis file are:

• ADM1

• ADM2


– 80 – EN/LZT 123 3316 R2A

• DEVDATA

• TRAFFCNT

• RECOVERY

For more information see the printout description forTRARTFILE.


Several things can be determined about system performance, aswell as providing some insight into those areas requiring furtherinvestigation, by using the Traffic Type Measurement Report asa starting point. The following information can be obtainedfrom the report by using a few simple formulas and reportparameters:

• Hold Time Per Call (Erlangs)

• Hold Time Per Call (Minutes or Seconds)

• Erlangs Per Circuit

• Traffic Capacity

• Percentage Capacity Used or Available

• Circuit Utilization

• Blocked Device Percentage

• Traffic Type Percentage

Hold Time Per Call (ERLANGS)

TRAFF / NBIDS = Hold Time Per Call (Erlangs)

The result of this calculation provides the average Erlangs percall type. If the average falls into a certain range consistently,then this value should be reflected in the Seizure Supervisionand Service Quality Supervision reports.

The report to be looked at when a number appears out of theordinary will be determined by what value falls out of range.What determines an ordinary number depends on the customer’sdefinition of what is "normal" for a specific value.

For example, assume that the "normal" Erlangs per OutgoingCall is approximately 1.5. A report is obtained that results in anaverage of .4 Erlangs per call. The amount of traffic generateddid not change a great deal, but the number of bids increasedsignificantly, causing the calculation to result in this figure.


EN/LZT 123 3316 R2A – 81 –

Possible reasons are: circuits causing abnormal on/off hookconditions, circuits causing subscribers to release and try again,B-Numbers that cannot process properly, routing cases that areincomplete, etc. The following reports can be used to helpidentify the cause:


• Traffic Recording on Routes

• Traffic Character Measurement on Routes



Obviously, there are several reports to look at. The mainconcept is to determine what information is wanted and whichreports will deliver this information. One or more of thesereports can help narrow down the cause of the abnormality.

Hold Time Per Call (Minutes or Seconds)

60 x Erlangs per call = Hold time per call in minutes

Hold time in minutes x 60 = Hold time per call in seconds

The above calculations give two ways of obtaining the sameinformation. Be aware that some of the reports will mention"minutes" and "seconds", so it is wise to go ahead and performthe conversion for reference purposes.

Turning the formulas around, either format can be converted tothe other as follows:

• Seconds / 60 = Minutes

• Seconds / 3600 = Erlangs

• Minutes / 60 = Erlangs

• Erlangs x 3600 = Seconds

These formulas assume that the report period is for a full hour,therefore:

1 Erlang = 1 Hour = 60 Minutes = 3600 Seconds

If the report period is different from 1 hour, then you may wishto convert the recorded traffic to 1 hour equivalents.


– 82 – EN/LZT 123 3316 R2A

For example:

RPL = 10 minutes

TRAFF = 3 Erlangs (30 minutes, because1 Erlang = 1 RPL)

Traffic in 1 Hour Erlangs = 5 Erlangs

Traffic in Minutes = 30 minutes (10 x 3, or 60 x .5)

Traffic in Seconds = 1800 (30 x 60, or .5 x 3600)

ERLANGS Per Circuit

TRAFF / (NDVO + NDVB) = Erlangs per circuit

TRAFF / ((NDVO + NDVB) - (NBLOO + NBLOB)) =Erlangs per working circuit

These calculations will provide you with the traffic carried bythe circuits available for the call type. If performed on the totalcircuits, it will show the traffic carried by each circuit if theywere all in service. If performed on the working circuits only, itwill show the traffic carried by the working circuits.

When the traffic consistently reaches a certain level, then morecircuits may be needed for the additional traffic to maintain thedesired Grade-Of-Service. More information regarding thissituation can be obtained by using the following reports:

• Traffic Measurement on Routes

• Time Congestion Measurement on Routes

• Traffic Character Measurement on Routes




The amount of traffic allowed depends on the Ericsson customer’sgoals, guidelines, and engineering practices. A good point tobegin the investigation process is when the traffic load reaches .7Erlangs per circuit in any of these reports. At this point, thecircuits are at 70% capacity, and may require additional facilitiesfor future growth.

Simple conversions can obtain traffic information per circuit inminutes or seconds.


EN/LZT 123 3316 R2A – 83 –

Traffic Capacity

(NDVO + NDVB) x .7 = Erlangs

((NDVO + NDVB) - (NBLOO + NBLOB)) x .7 = WorkingErlangs

This formula calculates the amount of traffic that can be carriedby the system. The amount of traffic that will be used for thecalculation (in our case, .7) will be determined by yourcompany’s goals and guidelines.

The reason .7 is used in the formula is because this representsthe approximate amount of traffic that can be carried withoutblockage. Use the value determined by your company in thiscalculation.

If the total amount of capacity is desired, then you need to keepin mind that the NDVB parameter is only used once, as it willshow up for IEX and OEX traffic.

By using the resulting information, it can be determined howclose to capacity the circuits are and what utilization they arereceiving. If both calculations are performed, a determination ofhow much more traffic can be handled if the blocked circuits areplaced into a working state can be made.

Percentage Capacity Used or Available

(TRAFF / Capacity) x 100 = Percentage capacity used

100 - Capacity used = Available capacity

These calculations will identify the percentage of traffic capacityavailable or used for the system.

If the amount consistently reaches 85 - 95%, then more circuitsmay be required. The Ericsson recommendation for maximumlink capacity that would warrant ordering new circuits is 70%. Ifthe amount falls well below the desired amount, then it ispossible that circuits can be removed.

Before disconnecting circuits, it is recommended that they beblocked first, and the traffic monitored based on the workingcircuits. This will help to identify whether or not the circuitscan be safely disconnected. If it turns out that the circuits areneeded, you can simply deblock them and restore the maximumcapacity.


– 84 – EN/LZT 123 3316 R2A

Circuit Utilization

(Erlangs per circuit / 0.7) x 100 = Utilization

This formula indicates the utilization percentage of individualcircuit types. It is based on the optimum amount of traffic thatcan be carried by the circuits.

Note: The value 0.7 was used in the formula, but this shouldbe replaced with your company’s defined value whenperforming these calculations when you return towork.

The 0.7 Erlangs represents about 42 minutes of traffic per hour.Obviously, it is desirable for the circuit to be used as much aspossible, but it cannot be in use constantly. Call set-up, calltear-down, circuit reset, and guard timers will have an affect onthe amount of traffic carried by the circuit.

Blocked Device Percentage

(NBLOB + NBLOO / NDVO + NDVB) x 100 = Percentage

This formula shows the relative amount of devices blocked inthe system. If there is a large amount of devices blocked, thereshould be some investigation as to why, especially if the amountdeviates from hour to hour.

Traffic Type Percentage

(TRAFF / Total Erlangs) x 100 = Percentage TRAFF by type

(NBIDS / Total BIDS) x 100 = Percentage BIDS by type

This formula will provide you with a view of what types oftraffic your system is carrying. The results of this formula overa period of time will provide you with a profile of the normalsystem call types for a certain period.

For example, you may find that more call attempts areperformed during the morning hours, but the afternoon hourshave a longer hold time. It may be that more call attempts areperformed between 4:00 and 5:00 p.m., but that more traffic isgenerated between 7:00 a.m. and 8:00 a.m.


EN/LZT 123 3316 R2A – 85 –

SECTION III - TRAFFIC DISPERSION MEASUREMENT

DESCRIPTION

The Traffic Dispersion function allows traffic to be measuredand observed for given destinations. The traffic destinations(TRD) are defined in B-Number Analysis Tables for statisticalpurposes and can be set for a variety of measurement functions.

This function allows determination of the destinations to whichtraffic on a specific route is dispersed. This function also allowsdetermination of where calls to a traffic destination came from.

REPORT GENERATION

When the report is generated, data is obtained per recordingobject. A Recording Object is the traffic destination or route ofan incoming type or an outgoing type. Routes may be arrangedinto recording groups, recording destinations, and recordingdestination groups which are all recording objects. Recordingcan be performed for specific destinations, routes todestinations, or all destinations.

Administering of the TRD codes are in B-Number Analysis.Therefore, there is a need to verify each change before placing itinto service.

To set up the function follow the operational instruction,“Traffic Dispersion Measurement, Initiate”.

If the output is to go to an AT terminal, the “Traffic DispersionMeasurement per Destination Result” or “Traffic DispersionMeasurement per Route Result” reports will be displayed.

If the output is to go to a file, then an IOG11 file, TRDIPFILE,will be used.


For more information on the report formats, refer to the relevantprintout descriptions.


– 86 – EN/LZT 123 3316 R2A

File Format (TRDIPFILE on IOG11)

The file, 75',3),/(, located on the IOG11, contains the rawdata for this measurement function. The three records containedin this file are:

• ADM

• OBJECT

• ADMLOST

For more information, refer to the printout description forTRDIPFILE.


Most of the information needed for route dimensioning andnetwork optimization has been calculated in this report. There islittle post-processing needed from the information given. If thefile format is used, information not provided in the alphaprintout can be obtained.

It is important to remember that this function is tied directly toB-Number Analysis, so the Traffic Dispersion reports aresubject to modification. Large deviations in the normal resultsshould be first analyzed to see if any B-Number changes havebeen made before investigating the traffic conditions.

Three formulas are used to calculate Rejected, Answered andUnanswered Call percentages. These formulas are explained inthe following sections.

Rejected Percentage

(NREJ / NCALLS) x 100 = Percentage

If the results from the above calculation seem to be out of whathas been determined as the normal range for the network, itcould mean one of the following:

• A fault exists in the Routing Case

If the sending program is incorrect, this can cause the call tobe rejected due to timeout, incorrect call processing, etc.


EN/LZT 123 3316 R2A – 87 –

• A fault exists in the B-Number Analysis

The Length parameter could be set wrong, causing the B-Number to fault out. The Distance Barring Analysis couldhave rejected it due to the D=X-Y being set for the wrongvalue.

In any case, the above are some things to look for when thispercentage proves to be out of a normal range. The number ofThrough Connected Calls can be used to provide someinformation for this.

If using data from the alphanumeric printout, the followingformula is used:

NCALLS - NREJ = Through Connections

(Through Connections / NCALLS) x 100 = Percent

Answered Percentage

Use the following formula to calculate the Answered CallPercentage:

(NANSW / NCALLS) x 100 = Percentage

Unanswered Percentage

Use the following formulas to calculate the Unanswered CallPercentage:

((NCALLS - (NREJ + NANSW)) / NCALLS) x 100 =Percentage

100 - (Answered Percent + Rejected Percent) = UnansweredPercent

NCALLS - (NREJ + NANSW) = Unanswered Calls

Note: It is possible that the formulas your company requiresyou use to obtain the above percentages are differentfrom the ones presented above. Always use theformulas recommended by your company over theEricsson recommended formulas when you return towork.


– 88 – EN/LZT 123 3316 R2A

SECTION IV - TIME CONGESTION MEASUREMENTS

DESCRIPTION

Time congestion is the percentage of the time when all devicesin a loss system route are occupied. In other words, timecongestion is the probability that a loss system route iscongested at an arbitrary instant of time.

The Time Congestion Measurement will provide the totalcongestion time for the route, amount of time no free device wasavailable, and total lost calls on the route.

REPORT GENERATION

To obtain the report, use the operational instruction, “TimeCongestion Measurement on Routes, Initiate”.

When the result output is to go to an AT terminal, the “TrafficMeasurement Time Congestion Measurement on Routes” resultprintout will be displayed. If the output is to go to a file, anIOG11 file, TIMCOFILE, will be used to store the reportinformation.

Alphanumeric Report format (AT Terminal)

For more information on the report format, refer to the printoutdescription for “Traffic Measurement Time CongestionMeasurement on Routes”.

File Format (TIMCOFILE on IOG11)

The IOG11 file, TIMCOFILE, contains data that can be used asinput to a post processing application. The records contained inthis file are:

• ADM

• ROUTE

• RECOVERY

For more information see the printout description forTIMCOFILE.


EN/LZT 123 3316 R2A – 89 –


This function is used to determine if more trunks are necessaryand/or if there are problems with devices on the specified route.The Traffic Measurement on Routes function gives basically thesame information as this function. The difference is that theTime Congestion function gives the congestion time percentage(TCONG), congestion time in seconds (CONGT) and number oflost bids due to congestion (NLOST).

Use the following formula to determine the blocking percentage:

(NLOST/NBIDS) x 100 = Blocking Percentage

This calculation is also performed by the Traffic Measurementon Routes function and is reflected in the CCONG counter. TheTime Congestion Measurement function displays the elementaryvalues for this formula not shown in the Traffic Measurement onRoutes reports.

If TCONG and CONGT are not 0, then an increase in trunksmay be necessary. However, if the switch is correctlydimensioned, then the number of blocked trunks and sealeddevices should be researched to determine if there are problemswith the devices. The NDV and ANBLO counters will reportthe total number of devices and the number of blocked devicesfor the specified route.

The acceptable values for all of these items are dependent on thegrade of service (GoS) a company selects as a standard.Typically, a company’s GoS is P.01 and would want theblocking ratio in the Blocking Percentage formula, above, to beless than 1% before considering adding trunks. If the company’sGoS is P.001, they would probably want the ratio to be less than.1%. The point is that the GoS and the time chosen for thereporting period (usually the busy hour) are importantconsiderations when making decisions based on theinterpretation of the “Time Congestion Measurement on Routes”report.


– 90 – EN/LZT 123 3316 R2A

SECTION V - TRAFFIC CHARACTER MEASUREMENT

DESCRIPTION

The purpose of Traffic Character Measurement is to getbackground information for dimensioning of routes carryingnon-Poisson distributed traffic, e.g., overflow routes.

This function is helpful in determining the efficiency of a route.The amount of trunks needed to service the peak busy hours canbe determined using this function.

The character of traffic on a route or group of routes isdetermined by means of registration and classification of thenumber of occupied circuits per scanning. The significantcharacter of traffic can be determined by using the histogramthat this function provides. This is a visual display of observedvalues distributed in different classes together with thecalculated values of the average and variance which is known asthe "character of traffic".

The alphanumeric printout performs the necessary calculationsand presents them in an understandable format. This report isexplained in the "Alphanumeric Report Format" section.

An operator can perform their own formulas on the raw datastored in the IOG11 file, as explained in the "File Format"section. The Neal-Wilkinson formula, discussed later in thischapter, is the recommended formula for calculating the callarrival distribution, also known as the variance-to-mean ratio(VMR).

REPORT GENERATION

This function can only be set for loss system routes. Setup iscarried out according to the operational instruction, “TrafficCharacter Measurement on Routes, Initiate”.

The report generated is available in alphanumeric format (ATterminal) and file format (IOG11 file). If the file format isselected, the printout results will go to the file TRACAFILE onthe IOG11. The difference between the two report formats isthat the alphanumeric report format gives calculated data and thefile format is unprocessed (raw) data.


EN/LZT 123 3316 R2A – 91 –


Three items must be understood before discussing the reportformat: class, lower limit and class interval.

A class is a category of the traffic intensity during eachobservance of a route. The category for each class is set up bythe combination of the lower limit (LWL) and class interval(CINT).

A lower limit (LWL) is the representation of an asterisk on thehistogram for a single observance. An observance is the numberof calls assigned to a class. The LWL default value is 1. Thelower limit represents Class 1 until the number of calls meet orexceed the category value set in another class.

A class interval is the increment value between classes startingwith Class 1. For example, if LWL=20 and CINT=4, then:

• Class 1 = 20

• Class 2 = 24

• Class 3 = 28

• Class 4 = 32

• :

• :

• Class 101 = 420

After the LWL and CINT is defined, the category value for aclass can be determined. The following formula is used toobtain the category value:

CLASS n = LWL + (CINT * (n - 1)) = Category Value

For more information on the alphanumeric printout, refer to theprintout description, “Traffic Character Measurement Result”.

File Format (TRACAFILE on IOG11)

The file oriented output is made on file TRACAFILE. If the fileoutput is requested, the printout is generated at the end of eachResult Output Period and if the recording is interrupted. Thisoutput is unprocessed (raw) data while the alphanumeric output,as mentioned earlier, gives calculated parameters. See theprintout description, TRACAFILE, for more information.


– 92 – EN/LZT 123 3316 R2A


By viewing the peaked (rough) traffic, the efficiency of trunkscan be determined. It may be that during the peak hours, thenumber of trunks currently installed are not enough, causing theinability of calls to be transmitted. This translates to loss ofrevenue for the cellular operator.

The acceptable amount of calls to be lost at peak periods mustbe determined by the cellular operator. The histogram is usefulin determining the number of trunks to be added or removed,depending on the efficiency of the trunks in the peak hours.

The Neal-Wilkinson formula is used to determine the measureof the call arrival distribution.

V = m (1 - m + A/(n + 1 + m - A))

where:

A is the offered traffic

n is the number of circuits on the direct route

m is the mean of the overflow traffic

The amount of traffic in the peak busy hours must be obtainedand the operator must determine how much of that traffic isacceptable to lose. For example, this "peaked" traffic may onlyoccur 20 times in a year, well out of the average traffic, but thismust be weighed into the decision of how many trunks anoperator wants to provide quality service to its customers. Theoperator will want to weigh the cost of installing more trunksthat will not be needed the majority of the time but will nowallow more call transmissions during the peak periods.


EN/LZT 123 3316 R2A – 93 –

SECTION VI - TRAFFIC OBSERVATION MEASUREMENT

DESCRIPTION

Some parameters concerning the quality of service cannot easilybe registered fully automatically. The Traffic Observationfunction gives the operator the ability to listen-in on randomlysampled calls to manually assess the quality of service. Oneexample is poor speech transmission and another is difficultieswith audible tones encountered in the international service.

The operator sets the criteria for the call samples to be selected.When the observation is initiated, the operator classifies the callaccording to parameters decided by the operating company. TheTraffic Observation is presented in printouts or stored on asystem defined file, OBSFILE.

Since the function will not allow you to specify the MSNB(Mobile Station Number), the Cell Traffic Recording functioncould be used.

Data Recording Per Call is a function that collects call typeinformation.

REPORT GENERATION

To set up Traffic Observation, follow the operationalinstruction, “Traffic Observation Session, Perform”.

The TOCOS and TOBSI commands are used to generate thetraffic observation reports. Selection criteria, discussed in detailbelow, is used in the report setup process while the output isrequested to go or not to go to an IOG11 dedicated file,OBSFILE.

Only one of the following selection criteria can be specified foreach observation setup.

• Originating Calls (ORG)

• Originating Calls that Terminate (ORG, TE)

• Originating Calls that go external to the system (ORG, OEX)

• Originating Calls to a Traffic Destination (ORG, TRD)

• Incoming Calls (IEX)

• Incoming Calls that Terminate (IEX, TE)


– 94 – EN/LZT 123 3316 R2A

• Incoming Calls that go external to the system (IEX, OEX)

• Incoming Calls to a Traffic Destination (IEX, TRD)

• Incoming Calls from specific routes (R1)

• Incoming Calls from specific routes that Terminate (R1, TE)

• Incoming Calls from specific routes go external (R1, OEX)

• Incoming Calls from specific routes to a Traffic Destination(R1, TRD)

• Terminating Calls (TE)

• Outgoing Calls (OEX)

• Calls to specific routes (R2)

• Calls to specific Traffic Destinations (TRD)

• Calls from PBXI routes, with the SNB(s)

• Calls to the PBXO routes, with the SNB(s)

• Outgoing International Calls

• Outgoing Long Distance Calls

The QTA (Quota for Observations) parameter sets the numberof observations to be made for the report. The valid values forthis parameter are 1 through 9999.


For more information on the alphanumeric report, see theprintout description for “Traffic Observation Results”.

File Format (OBSFILE on IOG11)

If file format is requested, raw data is stored in an IOG11 file,OBSFILE. There is only one type of record found in this file.For more information, refer to the printout description forOBSFILE.


EN/LZT 123 3316 R2A – 95 –


An example of information that can be obtained from the TrafficObservation printouts is the determination of which EOS isgenerated when a number is being dialed and is consistentlyrouted to congestion tone. The cause of a call not to beprocessed can be identified by looking at the EOS GROUP fieldon the printout.

The resulting printout can also provide the routes and devicesinvolved with the call. This can be used as an aid to routingcase testing/verification.

SECTION VII - SERVICE QUALITY MEASUREMENTS

DESCRIPTION

The events registered with the Service Quality StatisticsMeasurement function reflect the subscriber perception of theexchange and network performance as well as the subscriberbehavior. The registrations may include all originating calls,incoming external calls, calls toward selected circuit groups,etc., according to selection criteria preset by command.

This measurement function mainly permits registration of eventdata during the call set-up. For example, this function can beused as an aid to determine the amount of calls that were notcompleted. Specific failure reasons can be found, and theoverall performance of calls processed can be determined.Other service quality issues can be determined such as how longa subscriber has to wait for an answer from the time of the ring-control tone and what the normal conversation time is.

As a complement to this function, Traffic ObservationMeasurement, as discussed earlier, can be used. This functionprovides a listening-in connection to the exchange operator formanual classification of parameters concerning the quality ofservice as experienced by the subscriber. It also provides a real-time report of events and information about specified calls.


– 96 – EN/LZT 123 3316 R2A

REPORT GENERATION

To set up Service Quality Measurements, follow the operationalinstruction, “Service Quality Statistics, Recording, Initiate”.This OPI covers the necessary steps to generate the “ServiceQuality Statistics Results” report.


For more information relating to the alphanumeric report, seethe printout description “Service Quality Statistics Result”.


The “Service Quality Statistics Results” report can be used toobtain the following information about the Quality of Serviceprovided:

• Percentage of calls reaching register position

• Percentage of incomplete dialed digits

• Percentage of clear forwards

• Percentage of calls to unanswered B-numbers

• Percentage of calls to unobtainable B-numbers

• Percentage of incoming congestion

• Percentage of outgoing congestion

• Percentage of PDD1 - PDD4 calls

• Percentage of CTIME1 - CTIME2

Percentage of Calls Reaching Register Position

A low value in this area could indicate that the calls areexperiencing difficulty reaching or obtaining a register in theCP. There is the possibility that the CP load is too great, orthere may not be sufficient registers for the amount of callsattempted.

Percentage of Incomplete Dialed Digits

This could indicate that the CR/CS is having problems, theconnecting exchange or trunks are not working properly, or theB-Number Analysis may have incorrect data (L=8, where itshould be L=7).


EN/LZT 123 3316 R2A – 97 –

Percentage of Clear Forwards

This could indicate that the trunks are not functioning properly(incorrect signals on the A & B bits), DIP problems, ETCproblems, or incorrect B-Number Analysis or Routing Case. Isit possible that a modification in B-Number has removed orinserted digits and has created a problem, or the SP in a RoutingCase may be incorrect.

Percentage of Calls to Unanswered B-Numbers

This could indicate several problems, such as Paging Faults,Paging Congestion, congestion in the cells, etc.

Percentage of Calls to Unobtainable B-Numbers

This could indicate B-Number Analysis problems, or other areasin the call processing that does not allow the call to proceednormally.

Percentage of Incoming Congestion

A high number here could indicate signalling faults on thetrunk/ETC, SNT faults, Group Switch faults, CR faults, orpossibly a CP/RP/EM fault.

Percentage of Outgoing Congestion

A high number here could indicate signalling faults on thetrunk/ETC, SNT faults, Group Switch faults, CS faults,insufficient trunkage, Branching Conditions that are invalid, orpossibly a CP/RP/EM fault.

Percentage of PDD1 - PDD4 Calls

These could indicate that the CP is under too great a load. If thepercentage is too high, it is taking the CP too long to see the endof dialing and generate the proper EOS (B-Number could haveimplications in this). Note that the L=x, F=x, N=x, andBranching conditions in the Routing Case could impact this.

These numbers may need to be adjusted for a "normal" timeframe.


– 98 – EN/LZT 123 3316 R2A

Percentage of CTIME1 - CTIME2

If a low number of calls consistently fall below the rangesspecified, there could exist a problem with the cells and/ortrunks involved with the calls. Pre-mature disconnections,Signal Strength Values, incorrect Signaling Bit Status, and othersimilar items can cause this value to look abnormal. Again, thisvalue may need to be adjusted until a "normal" time is found,then the deviations can be found.

This CTIME value is independent of the CTIME set in SeizureQuality Supervision.

Once these values are found, other reports can then be looked atto aid in the identification of the problem. Obviously, ifselective criteria is used it will be easier to locate a starting pointthan using generic criteria.

Example:

If a route is specified as outgoing, the Routing Case (RC) can beidentified by printing the cases. If the RC is known, then theB-Number that uses it can be obtained.

traffic recording/measuringread.pudn.com/downloads171/ebook/793240/shost07.pdfbe accessed by mml...

Documents