Voice Traffic Engineering Primer

Traffic engineering is an integral building block in voice capacity planning and in ensuring a certain level of service to users. In the traditional telecommunications world, certain terminologies and calculations are used, that now apply to the world of IP-based voice communication. Some of these terms and values are as follows:

Grade of Service: This is a probability that a call will be blocked by the voice gateway during the busiest hour. This value is expressed as the following fraction (or percentage):

[Number of Lost calls / Number of offered calls] * (100)

Erlang: An Erlang represents the average number of concurrent calls carried by a single resource (such as a trunk) in continuous use, where that average is calculated over some reasonable period of time. In practice, an hour of traffic it is used. The following example, taken from here shows how to calculate an Erlang:

If a group of user made 30 calls in one hour, and each call had an average call duration of 5 minutes, then the number of Erlangs this represents is worked out as follows:

Minutes of traffic in the hour = number of calls x duration
Minutes of traffic in the hour = 30 x 5
Minutes of traffic in the hour = 150
Hours of traffic in the hour = 150 / 60
Hours of traffic in the hour = 2.5
Traffic figure = 2.5 Erlangs

Centum Call Seconds (CCS): A CCS is a value that represents 100 call seconds, meaning a 100 second long call. The following formulas better describe a CCS:

100 call seconds = 1 CCS
3600 call-seconds = 36 CCS = 1 call-hour.
3600 call-seconds per hour = 36 CCS per hour = 1 call-hour per hour
1 call-hour per hour = 1 Erlang
Therefore, 1 CCS = 1/36 Erlangs

Busy hour: The 60-minute period in a given 24-hour period during which the maximum total traffic load occurs. This is sometimes called the peak hour.

Busy-Hour Traffic (BHT): The BHT value represents the number of hours of traffic that is transported across a trunk group in its busiest hour. This value is expressed in erlangs.

There are three most common Erlang traffic models that are used in the industry. These are:

Erlang B: The most commonly used of the three methods, Erlang B is a traffic model is a queuing mechanism used to calculate the number of lines that are required if the traffic figure is known (in erlangs) during the busiest hour. The model assumes that all blocked calls are immediately cleared. The Erlang B formula can determine the number of trunks, or lines, needed to handle a calling load during a one-hour period. However, the formula assumes that if callers get a busy signal, they will never retry, that is, all lost calls are completely cleared. This assumption means that Erlang B can underestimate the number of trunks needed.

Extended Erlang B: This model is similar to the Erlang method, but it considers the additional traffic load that is caused when blocked callers immediately try to call again. Unlike the Erlang B model, the retry percentage can be specified and therefore the problem of undersubscription or underestimation is avoided.

Erlang C: is a traffic modeling formula used in call center scheduling to calculate delays or predict waiting times for callers. Erlang C bases its formula on three factors: the number of reps providing service; the number of callers waiting; and the average amount of time it takes to serve each caller. Erlang C can also calculate the resources that will be needed to keep wait times within the call center’s target limits. This method assumes that there are no lost calls or busy signals, and therefore may overestimate the staff that is required.

Filed under: Design, Technical, erlang, erlang b, erlang c, voice design, voice engineering, voice traffic engineering

Call Control Signaling Overhead (SCCP & SIP)

Recently I was required to calculate the signaling overhead for a customer that had a centralized deployment without inter-site dialing. This would mean their signaling would travel over the WAN links, but no voice traffic. I had never thought about how much bandwidth SCCP (or SIP) uses since I assumed it would be negligible. That may be the case for most scenarios however, it can be significant for remote sites with a large number of IP phones and heavy call volume.

The formulas for calculating the bandwidth required for SCCP and SIP with and without Encryption are as listed below. It is assumed that the average call per hour per phone is 10.

Equation 1A: Recommended Bandwidth Needed for SCCP Control Traffic without Signaling Encryption.
Bandwidth (bps) = 265 ∗ (Number of IP phones and gateways in the branch)

Equation 1B: Recommended Bandwidth Needed for SIP Control Traffic without Signaling Encryption.
Bandwidth (bps) = 538 ∗ (Number of IP phones and gateways in the branch)

Equation 2A: Recommended Bandwidth Needed for SCCP Control Traffic with Signaling Encryption.
Bandwidth with signaling encryption (bps) = 415 ∗ (Number of IP phones and gateways in the
branch)

Equation 2B: Recommended Bandwidth Needed for SIP Control Traffic with Signaling Encryption.
Bandwidth with signaling encryption (bps) = 619 ∗ (Number of IP phones and gateways in the
branch)

To get a more accurate value, the average calls per hour per IP phone can be varied and the following formulas will need to be applied:

Equation 3A: Recommended Bandwidth Needed for SCCP Control Traffic for a Branch with No Signaling Encryption.
Bandwidth (bps) = (53 + 21 ∗ CH) ∗ (Number of IP phones and gateways in the branch)

Equation 3B: Recommended Bandwidth Needed for SIP Control Traffic for a Branch with No Signaling
Encryption.
Bandwidth (bps) = (138 + 40 ∗ CH) ∗ (Number of IP phones and gateways in the branch)

Equation 4A: Recommended Bandwidth Needed for SCCP Control Traffic for a Remote Branch with Signaling Encryption.
Bandwidth with signaling encryption (bps) = (73.5 + 33.9 ∗ CH) ∗ (Number of IP phones and
gateways in the branch)

Equation 4B: Recommended Bandwidth Needed for SIP Control Traffic for a Remote Branch with Signaling Encryption.
Bandwidth with signaling encryption (bps) = (159 + 46 ∗ CH) ∗ (Number of IP phones and gateways
in the branch)

This information is available on page 3-50, in the Cisco Unified Communications System Release 8.x SRND document that can be found here.

Filed under: Design, Technical, call control, sccp, Signaling, sip

CUCM Dial Plan for Pakistan

During my first CUCM implementation, I was completely lost as to where I should start creating a dial plan for Pakistan because all the documentation and books that I had read were targeted towards the North American numbering plan. This is understandable since most or all Cisco publication originated in North America. In any case, I was requested by a reader to share a dial plan for Pakistan, so I thought it would be a good idea to post that information here so that it may be helpful to others as well.

Please bear in mind that Pakistan uses a variable-length dial-plan, which may make it necessary to include a large number of route patterns, all of which I could not possibly include in this post. However, where possible, I have tried to define a general pattern that may have a considerable post-dial delay associated. This delay can be reduced in CUCM by tweaking the T.302 timer under System -> Service Parameters -> CallManager.

In my example, I have made the following assumptions:

–          The code to access an outside line is ‘9’
–          A Line/Device approach is being followed
–          The city for which the dial plan is being defined, uses 8 digit dialing.

First off, the Class of Restrictions (Calling privileges) will need to be defined by the administrator according to the client’s needs. However, I have found that most customers are happy to accept the administrator’s suggestions on the different privilege classes.

The Line CSSes will enforce the dialing restrictions. It will contain ‘Block’ partitions, which are partitions that contain Translation Patterns that will block access to the different route patterns. First, let us define the partitions and Translation Patterns that will block the route patterns. The administrator is free to choose labels of his/her choice. I have found the following configuration to be satisfactory for most clients:

Translation Pattern to Block Local Dialing (8-digits for Karachi and Lahore):

Pattern: 9.3XXXXXXX
Partition: PT-BLK-LOCAL
Check the: “Block this pattern” option

Translation Pattern to Block National Dialing:

Pattern: 9.0[^03]!
Partition: PT-BLK-NATIONAL
Check the: “Block this pattern” option

Translation Pattern to Block Mobile Dialing:

Pattern: 9.03XXXXXXXXX
Partition: PT-BLK-MOBILE
Check the: “Block this pattern” option

Translation Pattern to Block UANs:

Pattern: 9.111XXXXXX
Partition: PT-BLK-UAN
Check the: “Block this pattern” option

Translation Pattern to Block Toll-Free Numbers:

Pattern: 9.0800XXXXX
Partition: PT-BLK-TOLL-FREE
Check the: “Block this pattern” option

Translation Pattern to Block Premium Rate Numbers:

Pattern: 9.0900XXXXX
Partition: PT-BLK-PREMIUM
Check the: “Block this pattern” option

Translation Pattern to Block International Dialing:

Pattern: 9.00!
Partition: PT-BLK-INTERNATIONAL
Check the: “Block this pattern” option

Note: I have not defined blocking patterns for Service numbers since that would be too time consuming however, if desired, the administrator may do so. Service numbers are numbers such as Flight Inquiry, Sui Gas, etc.

Now let’s define the class of restrictions or the Line CSSes:

CSS-INTERNAL

PT-BLK-LOCAL, Partition to block Local Dialing
PT-BLK-NATIONAL, Partition to block National Dialing
PT-BLK-MOBILE, Partition to block Mobile Dialing
PT-BLK-UAN, Partition to block UANs
PT-BLK-TOLL-FREE, Partition to block Toll-Free numbers
PT-BLK-PREMIUM, Partition to block Premium Rate numbers
PT-BLK-INTERNATIONAL, Partition to block International Calling

CSS-LOCAL

PT-BLK-NATIONAL, Partition to block National Dialing
PT-BLK-MOBILE, Partition to block Mobile Dialing
PT-BLK-PREMIUM, Partition to block Premium Rate numbers
PT-BLK-INTERNATIONAL, Partition to block International Calling

CSS-NATIONAL

PT-BLK-MOBILE, Partition to block Mobile Dialing
PT-BLK-PREMIUM, Partition to block Premium Rate numbers
PT-BLK-INTERNATIONAL, Partition to block International Calling

CSS-MOBILE

PT-BLK-PREMIUM, Partition to block Premium Rate numbers
PT-BLK-INTERNATIONAL, Partition to block International Calling

CSS-INTERNATIONAL

PT-BLK-PREMIUM, Partition to block Premium Rate numbers

Note: Emergency numbers should not be placed in any partitions so that every extension has access to emergency dialing.

The Device CSS will allow access to all route patterns, and therefore, should contain the appropriate partitions as follows:

DEVICE-CSS (You may choose a label of your choice)

PT-INTERNAL: Partition for Internal extensions
PT-LOCAL, Partition for Local Numbers
PT-NATIONAL, Partition for National Numbers
PT-MOBILE, Partition for Mobile Numbers
PT-SERVICE-NUMBERS, Partition for Service Numbers
PT-UAN, Partition for UANs
PT-TOLL-FREE, Partition for Toll Free Numbers
PT-PREMIUM, Partition for Premium Numbers
PT-INTERNATIONAL, Partition for International Numbers

Finally, we will need to define the route patterns for all numbers:

Route Pattern for local dialing:

Pattern: 9.3XXXXXXX
Partition: PT-LOCAL
Provide outside dialtone: YES
DDI: Pre-dot

Note: For cities that use 7 digits or less, a route pattern with the appropriate number of digits may be defined.

Route Pattern for National dialing:

Pattern: 9.0[^03]!
Partition: PT-NATIONAL
Provide outside dialtone: YES
DDI: Pre-dot

Route Pattern for National dialing with #:

Pattern: 9.0[^03]!#
Partition: PT-NATIONAL
Provide outside dialtone: YES
DDI: Pre-dot + Trailing #

Route Pattern for Mobile dialing:

Pattern: 9.03XXXXXXXXX
Partition: PT-MOBILE
Provide outside dialtone: YES
DDI: Pre-dot
Route Pattern for local dialing:

Route Pattern for International dialing:

Pattern: 9.00!
Partition: PT-INTERNATIONAL
Provide outside dialtone: YES
DDI: Pre-dot

Route Pattern for International dialing with #:

Pattern: 9.00!#
Partition: PT-INTERNATIONAL
Provide outside dialtone: YES
DDI: Pre-dot + Trailing #

Route Pattern for UAN Numbers:

Pattern: 9.111XXXXXX
Partition: PT-UAN
Provide outside dialtone: YES
DDI: Pre-dot

Route Pattern for Toll-Free Numbers:

Pattern: 9.0800XXXXX
Partition: PT-TOLL-FREE
Provide outside dialtone: YES
DDI: Pre-dot

Route Pattern for Toll-Free Numbers:

Pattern: 9.0900XXXXX
Partition: PT-PREMIUM
Provide outside dialtone: YES
DDI: Pre-dot

Route Pattern for Police Department:

Pattern: 9.15
Partition: <None>
Provide outside dialtone: YES
DDI: Pre-dot

Route Pattern for Police Department without outside access code:

Pattern: 15
Partition: <None>
Provide outside dialtone: NO
DDI: None

Route Pattern for Punjab Rescue:

Pattern: 9.1122
Partition: <None>
Provide outside dialtone: YES
DDI: Pre-dot

Route Pattern for Punjab Rescue without outside access code:

Pattern: 1122
Partition: <None>
Provide outside dialtone: NO
DDI: None

Route Pattern for Flight Inquiry:

Pattern: 9.114
Partition: PT-SERVICE-NUMBERS
Provide outside dialtone: YES
DDI: Pre-dot

Route Pattern for SUI Gas:

Pattern: 9.119
Partition: PT-SERVICE-NUMBERS
Provide outside dialtone: YES
DDI: Pre-dot

Route Pattern for PTCL Inquiry number:

Pattern: 9.1217
Partition: PT-SERVICE-NUMBERS
Provide outside dialtone: YES
DDI: Pre-dot

Route Pattern for PTCL Complaint number:

Pattern: 9.1218
Partition: PT-SERVICE-NUMBERS
Provide outside dialtone: YES
DDI: Pre-dot

General Route Pattern for Service Numbers:

Pattern: 9.1!
Partition: PT-SERVICE-NUMBERS
Provide outside dialtone: YES
DDI: Pre-dot

General Route Pattern for Service Numbers with #:

Pattern: 9.1!#
Partition: PT-SERVICE-NUMBERS
Provide outside dialtone: YES
DDI: Pre-dot + Trailing #

I hope this information was helpful to the reader.

Filed under: CUCM, Technical, Calling Search Space, Class of Restriction, CSS, Dial plan, Dial Plan for Pakistan, Pakistan, Partition, Route pattern, Translation pattern

Configuring Extension Mobility in CUCM 6.x – 8.x

I was going to do a detailed post on configuring Extension Mobility in CUCM, but then I came across a blog that already has a comprehensive, step-by-step post on the subject so I thought I would simply link to it. To configure Extension Mobility in CUCM 6.x – 8.x, follow this link. Good luck!

Filed under: CUCM, EM, Extension Mobility, IP Phone Service

A little bit about ISDN Q.931

Lately I’ve been reading up on the Q.931 specification because it is important to understand the various messages involved such as the call transition messages (ALERTing, CALL PROCeeding, PROGress, SETUP, etc) and the general structure of the protocol in order to troubleshoot issues with ISDN as well as H.323 connectivity.

The first thing I’d like to do is share ITU-T’s Q.931 specification, which can be found here.

The following information has been extracted from the Cisco Voice over IP book by Kevin Wallace and includes a figure illustrating an ISDN frame:

“Two Layer 3 specifications are used for ISDN signaling: ITU-T I.450 (also known as ITU-T Q.930) and ITU-T I.451 (also known as ITU-T Q.931). Together, these protocols support user-to-user, circuit-switched (the B channels), and packet-switched (the D channel) connections. A variety of call-establishment, call-termination, information, and miscellaneous messages are specified, including SETUP, CONNECT, RELEASE, USER INFORMATION, CANCEL, STATUS, and DISCONNECT.

ISDN signaling takes place in the D channel and uses a message-oriented protocol that supports call control signaling and packet data. In its role as signal carrier for the B channels, the D channel directs the CO switch to send incoming calls to particular time slots on the Cisco access server or router.”

The following section explains the various components of the ISDN frame:

Protocol Discriminator: Specifies the signaling protocol used for the connection (e.g. PD=8 for DSS1).

The definition of DSS1 as specified on Wikipedia is as follows:

“Digital Subscriber Signalling System No. 1 (DSS1), also known as Euro-ISDN or E-DSS1 (European DSS1), is a digital signalling protocol (D channel protocol) used for the ISDN. The interface is also called NET3 for BRI and NET5 for PRI lines. Can also be called CTR4. It is defined by ITU-T I.411 (ETS 300 102). It supports Bearer Capability, Low Level Compatibility and High Level Compatibility, ANI, DNIS and redirected number signaling in both directions.”

Length of Call Reference Value: As the name suggests, this field specifies the value of the “Call Reference value.” This may be a one or two byte value.

Flag: This value is set to zero (0) if the message is sent by the party that set the Call Reference value, otherwise it is set to one (1). From the ITU-T spec:

“The call reference flag can take the values “0” or “1”. The call reference flag is used to identify which end of the layer two-logical link originated a call reference. The origination side always sets the call reference flag to “0”. The destination side always sets the call reference flag to a “1”.

Hence the call reference flag identifies who allocated the call reference value for this call, and the only purpose of the call reference flag is to resolve simultaneous attempts to allocate the same call reference value.”

Call Reference Value: This is a random tag used to identify a particular call session between the device maintaining the call and the ISDN switch. More information on this value has been extracted from ITU-T’s spec:

“The purpose of the call reference is to identify the call or facility registration/cancellation request at the local user-network interface to which the particular message applies. The call reference does not have end-to-end significance across ISDNs. The call reference is the second part of every message.

At a minimum, all networks and users must be able to support a call reference value of one octet for a basic user-network interface, and a call reference value of two octets for a primary rate interface.

Call reference values are assigned by the originating side of the interface for a call. These values are unique to the originating side only within a particular D-channel layer two logical link connection. The call reference value is assigned at the beginning of a call and remains fixed for the lifetime of a call (except in the case of call suspension). After a call ends, or, after a successful suspension, the associated call reference value may be reassigned to a later call. Two identical call reference values on the same D-channel layer two logical link connection may be used when each value pertains to a call originated at opposite ends of the link.”

Message Type: According to the CVOICE book by Kevin Wallace, this field:

“Identifies the message type (for example, SETUP) that determines what additional information is required and allowed.

From the ITU-T spec:

“The purpose of the message type is to identify the function of the message being sent. The message type is the third part of every message.”

The following table, extracted from the CVOICE book by Kevin Wallce illustrates the various Message Types used:

ISDN Information Element (IE): The IEs carry call processing related information such as called/calling party numbers, CID, etc.

The following table, extracted from the CVOICE book by Kevin Wallce illustrates the various ISDN messages and associated IEs:

There are four commonly used IEs which deserve a closer look: Cause IEs, Facility IEs, Progress IEs and Display IEs.

Cause IEs indicates a reason for the termination of a call. This information can be useful in diagnosing or troubleshooting with call connectivity issues.

Facility IEs are sent to ISDN switching devices such as a PBX to invoke supplemental services.

Progress IEs  such as ring back, busy tones and announcements are required to successfully signal voice calls. The availability of tones and announcements is indicated by ALERTING, CALL PROCEEDING, PROGRESS, CONNECT, SETUP ACKNOWLEDGE or DISCONNECT messages.

Display IE serves actions such as providing output for an LCD display by sending text. It is commonly used to pass caller name information over a PRI.

Filed under: ISDN, Technical, B Channel, BRI, D Channel, E1, PRI, Q.931, Signaling, T1