Cerebrum - 26th September 2011

(06:15 GMT)

Hi tnanor, Sezirus are not traffic, traffic is seizures multiplied by MHT (Meen holding time) Erl = Seizures*MHT/T T - observation period, the periodicity of your data (1 hour/ 15 min/ 5 min etc.)

tnanor - 22nd September 2011

(09:49 GMT)

how do i calculate network traffic, and busy hour traffic? from the networks statistical data, i get seizure values. i thought seizures represent the traffic, but anytime i present these values, the recipient of the report says they are wrong. is there a way of calculating network traffic and busy hour traffic?

Rex - 25th August 2011

(08:29 GMT)

Hi, you can use maybe the indicator sdcch requests for MOC wich tells how many percent of calls were MOC. And use that percentage for calculation of: Revenue=60*(sdcch_req_MOC% * E)* tariff. sdcch_req_MOC%=sdcch_req_MOC/(sdcch_allrequests-sdcch_imsi_detach-sdcch_LU-sdcch_smssdcch_mobile_terminated-sdcch_other). It gives you aproximate value of originated calls.

sreedhar chalumuri - 25th August 2011

(06:53 GMT)

how do you calculate sub per site? what is the formulae used? Thanks

Pix - 14th February 2011

(05:28 GMT)

There is something else : the billed miunutes are only the ones related to Mobile originated calls ! If there is roughly 40% MOC in a network, and if there is 100,000 erlang per day in this network... it means only 40,000 erlangs will be charged. --> and that's assuming the call duration for MOC and MTC is the same ! which is not true ! --> and also, you must substract the average duration of the alerting phase.. let's say 6 seconds/call, while the call lasts 60sec in average. That's -10%... In the end, the figure should be max. 36,000 and min. 25,000 erlangs per day. You can approximate and take one-third of the total erlang... Multiply this by "60* rate per min", as sheldon explained. Formula becomes: Revenues = 60*rate/min*(0.3*Erl) Does it give better results? Regards pix

dakmatt - 14th February 2011

(02:31 GMT)

Hi Sheldon, I've used your formula below and compare that with our revenue for both prepaid and postpaid. However, there are huge variance between calculated revenue using Erlang and actual revenue in billing system. I wonder,if you can give example and prove that your way of calculating estimated revenue.

sekkilar - 23rd January 2011

(11:08 GMT)

How do I calculate revenue from the traffic in Erlang. Erlang to revenue

SHELDON - 27th March 2010

Hi Portia, Thanks for the feedback.

(21:33 GMT)

Well, if you can find the total no. of call minutes generated per minute, then you can easily find the revenue by multiplying it by your tariff. Once you know the total minutes for all calls, I don't see why you need to divide it by the total no. of subscribers. Concerning the calculation with traffic, I was just answering your question, which was "how to translate erlang into financial terms". You can easily factor in data revenue (GPRS/EDGE), if you know the charging method. Anyway, I'm glad you got your answers. Regards, SHELDON

portia - 26th March 2010

(22:02 GMT)

Thanks sheldon. I iscovered that the finance use te total minutes generated per month divided by the total number of suscribers(not instant active suscribers but the estimated total number). This i believe is wrong but it does give a rough estimate of revenue per month. since this TCH traffic is data and voice only, its not the exact piture of the total revenue generated in the whole network. regards

SHELDON - 25th March 2010

Hi Portia,

(11:26 GMT)

If you're familiar with the erlang formula, then that should be easy. Let E = traffic in erlang, N =No. of calls MHT = mean holding time in minutes (avg call minutes)

Then E = N*MHT/60 To translate erlang into financial terms( aka money), you need to know the no. of calls and the mean holding time for each call. The product of these, multiplied by your tariff per minute gives you your total revenue for that hour. From the formula above, N*MHT = 60*E Thus, Revenue =60*E*tariff This gives you revenue for the hour. You can aggregate this to give you revenue per day, week, month, etc. Note that the no. of calls (N) in this case refers to answered calls. Also, this calculation will give you an approximate figure. Regards, SHELDON

portia - 25th March 2010

(09:59 GMT)

From GSM point, traffic is calculated in erlang but my finance dept are using call minutes. How do you translate erlang traffic to financial terms?

Bijoy - 19th March 2010

(09:21 GMT)

You can get this info in MSC as no. of attached sub/LAC Br\\ Bijoy

Sitha - 19th March 2010

(09:10 GMT)

I am wondering how to calculate the number of subscriber per BSC. **How to get the number of subscriber per BSC?

TomTom - 9th March 2010

(07:11 GMT)

Hello, How much Erlang is for home user and for business user?

Debasish - 24th February 2010

(10:31 GMT)

How to measure the erlang used by the subscriber and to find the revenue earning of an operator?

Valentin Georgiev - 15th January 2010

(08:54 GMT)

Hi,Singh. It depends on the coding you choose. Standart voice channel is using PCM(Pulse code modulation)

with result 64 Kbps. But with other modulations you can lower the speed to 8-9 Kbps.

J B Singh - 6th January 2010

(11:46 GMT)

hi how we can calculate IP bandwidth in kbps for 1 Erlang of voice traffic?

pix - 2nd December 2009

dennis,

(16:13 GMT)

usually, we consider only the downlink, because it is the direction in which there is the most traffic. so f the capacity is enough in DL, since it is symmetrical in DL and UL (capacity DL = capacity UL), it is plenty enough to carry the UL traffic.

Dennis Tham - 2nd December 2009

Hi Pan,

(15:18 GMT)

Thanks for your insight. Yeah, I understand now, 64kbps = 64 x 60 x 60 kbph = 230400 kbph.... Another question, do we actually consider the uplink or the downlink when we convert the Erl to kbps?

Aakash - 16th November 2009

(17:09 GMT)

What is the capacity for a BTS in erlang for a GSM and a CDMA business seperately??

Carlos - 16th July 2009

(02:38 GMT)

Hi professionals, the WCDMA system is a little different from GSM and others. In GSM, when you used to have problems with traffic demand, you really need to imply more TRXs. But in WCDMA the Transport network is very important and must be primarily verified. Suppose you have a growing traffic that is reaching the transmission BW, then the chosen QoS will be in charge of reducing this BW in order to keep loss and delay requirements. Then, my answer is that you must verify your system before start increasing HW.

Pan - 3rd March 2009

(12:19 GMT)

Hi, Dennis Tham ! It is dependent for what time period you are averaged your load. Usually in telecommunications it is one hour.

Dennis Tham - 3rd March 2009

Hi Pan,

(03:12 GMT)

I thought 1 Erl = 64kbps and not 230400kbph

Pan - 21st July 2008

Hi Rich!

(12:56 GMT)

It is very simple:) If you have a channel with 64 kbit/s (230400 kbit/h)throughput and your information source bitrate is 230400 kbit/h, then you can say that your source is creating load with 1 Erl intensity on that channel. Accordingly - 230400/2 = 0.5 Erl, 230400/4=0.25 Erl for this case.

Rich - 21st July 2008

(06:35 GMT)

Hi, Can any one explain how to caculate convert Erlangs in to kbps. Cheers!

moh - 7th April 2008

(06:38 GMT)

how can i calculate MHT but not from Traffic volume

Tungvt - 17th December 2007

(04:32 GMT)

Hi all, I just want to ask the question about BH Erlang per user for voice, CS Video 64 kbps, PS 64 kbps, PS 128 kbps, PS, 384 kbps in WCDMA network in Japan? Notes when designing Access netwokr in WCDMA. Thanks a lot!

Kur2 - 15th June 2007

(13:02 GMT)

The most important resource in W-CDMA is OVSF code tree. if there's blocking issue in your network, so you can add your carrier with one new carrier. Because OVSF code tree is represented by carrier

Pete - 14th June 2007

(10:21 GMT)

Can you be please more detailed? Im GSM, when there is a blocking issue (exist something similar in UMTS?) we are adding another trx(frequency), of course if possible. What are we adding in umts? Another scrambling code? (from secondary scrambling codes?) What does it mean an adition of another carrier in UMTS? Does this mean an addition of another frequency band, if operator owe some? Thanks in advance.

Kur2 - 14th June 2007

(09:50 GMT)

Capacity in UMTS/W-CDMA is limited by some capacity resources. They are Channel element, OVSF code tree, power, and Iu Interface So if you want to increase your traffic or capacity, you must increase WCDMA capacity resource. And it defends on your traffic model and traffic profile. 3g professionals, Can someone please explain me, how WCDMA system deals with increased traffic? Can I simply add some TRX(I'm coming from GSM) or scrambling code? How much traffic can handle one carrier? Thanks for your explanation. BR. Pete

Kurniawanto - 30th April 2007

(08:32 GMT)

Hi guys, i just wanna ask a question abaout Kbps (kilo bit per second) and kbpBH(kilo bit per Busy Our). What do they mean? is 1 Kbps equal with 1 KbpBH??

Pix - 12th April 2007

hi kurni,

(16:50 GMT)

no, i'm sorry, i don't have all this documentation... i guess you're working on the operator side ? Then it might be a good idea to ask your vendor(s) about typical values they're using.

Kurniawanto - 12th April 2007

Dear Pix, Thank's for your replay :)

(03:16 GMT)

Hmm, the problem is I don't know exactly the asumption of Busy Hour Erlang per subscriber of CS/PS 64, PS 128, 384 kbps? Would you give me the assumptions that largely used in many countries? If you don't mind, would you give me the literarure that explain the Busy Hour Erlang per subscriber for any services??

Pix - 11th April 2007

Kurniawanto,

(13:26 GMT)

It really depends on your average subscriber behaviour... for instance, for CS 12.2 kbps, in many countries, they're using 18 mErl / BH / subs (instead of 25). Just to say, you'll have to make assumptions on your own. Not many countries can provide a typical set of avg traffic values yet.

Kurniawanto - 11th April 2007

(04:53 GMT)

Hi All, I just want to ask the question about Busy Hour erlang per subscriber for voice, CS Video 64 kbps, PS 64 kbps, PS 128 kbps, PS, 384 kbps in UMTS/WCDMA network?? As I know that GSM Voice 12,2 kbps, Busy Hour Erlang per subscriber is 25 mE/subscriber Thanks a lot

Pix - 23rd March 2007

Hello Nisha,

(14:42 GMT)

"detect the revenue leakage points in telecom softwares" What do you mean ? Can you give us an example of a typical "leakage point" ? I will take a guess anyway, and tell you that you can calculate how much it costs for the operator o

loose a certain amount of traffic. For instance, if you can calculate that an operator is loosing 100 erlangs per day (due to "leakage"), then you're able to convert 100 erlangs in actual money. If one subscriber pays 10 cents per minute (in average), then the computation is simple : 100 erlangs = 100 erlangs x 24 hours/day x 60 minutes/hour x 0.10 $ /minute = 14 400 $ / day. Simple way to demonstrate that the cost of your software can be refund in few weeks. (i don't think operators loose 100 erlangs / day !!! )

nisha Luharuka - 23rd March 2007

(12:34 GMT)

HI, Can you just help me in knowing. Suppose i have developed a system which help to detect the revenue leakage points in telecom softwares then how do i calculate the cost verses benefit for it

Ayat - 20th February 2007

(07:00 GMT)

Hello Dear Cerebrum . thanks for your reply Could you explain more i did not understand your idea i know there are companies estimate the time of call by unit pulse i think that for example every 10 sec = one pulse = --- $ my way is calaculate all answer traffic (in , out) with all BSC,s and convert it to sec. then * the cost of one sec. best regards

Cerebrum - 19th February 2007

(12:03 GMT)

Hi, Ayat. If your question is - Is the answer time that I need to take into consideration to calculate the revenue? The answer is YES BUT this isn't the only money flow to your company. It may have flat rates for subscription plans, every single plan may has conversation time included in its price. Many operators starts charging with a fixed price for the first minute or so, and after that the charging is for every second. Every subscripion plan may has different charging rates and so on. But walking your way you can find are your company growing or shrinking? BR

Ayat - 19th February 2007

Dear , all

(10:22 GMT)

plz i tried to calculate the company revenue from traffic i used answer traffic or answer time . is it the right way to estimate the revrnue (to convert the traffic to money )??? thanks a lot

Ayat - 19th February 2007

(10:17 GMT)

Dear all, i try to summrise these Discussion we need to calculate traffic per sub. if we have only BHCA and MHT i think we need No. of VLR sub. because from BHCA and MHT we can calculate Traffic (ERL) BHCA In BH * MHT(sec.)In BH = total time of call (sec.) we can convert to (ERL) by divid it /3600 =(traffic(erl)) this is accordinf to what is the traffic we need to know (seziure , through connection ,or answer) traffic if we know the duration of call we can estimate traffic(erl) directly . I think all vendors define like these counters in their system. thanks a lot .

Abdel - 15th August 2006

Hello everybody,

(12:16 GMT)

I have some default values automatically calculated by the switch this values can be used to calculate Traffic in erlang, BCHA and a lot of things. They are as the following: 1. Times of call attempt 2. times of seizure 3. Times of through connection 4. Times of reply 5. Times of paging response 6. Times of called subscriber busy 7. Times of called Unreachable. 8. Times of Radio resource congestion. 9.Times of call rejection 10.Times of vacant number 11. seizure duration 12. Times of successfull call delivery. 13. Maximum of VLR count From all of this how can I calculate our whole traffic in erland

Abdel - 15th August 2006

(11:38 GMT)

How can I calculate the whole traffic in erland without having the BCHA value? is this possible.

Abdel - 15th August 2006

Hi all

(05:33 GMT)

can somebody explaind what cerebrum said here: Hi, Abdel. If you multiply BHCA x MHT = Traffic Volume (TV) in BH. And If you devide TV/Subs= Average Traffic Volume per One subscriber. In Erlangs this is: TV/((Subs)*X) X=60 - MHT in [min] X=3600 - MHT in [sec] This is in case you are looking for the average traffic per user in BH. For traffic calculations this value is needed. But if you need the average traffic per day, you must multiply TV in BH with a concentration factor. In the books the concentration of traffic in BH is about 15-20%. But in our

network the concentration is less than 12%. If you have more questions I'll be glad to help you what I want is what does it mean the concentration factor? any help please

Cerebrum - 19th January 2006

(11:00 GMT)

From your words I suppose that you have records for every call attempt. If so, on fo the attributes is Duration. If you sum all durations that will be Traffic Volume for the referenced period. This is only an assumption. I really don't know what data you have.

Abdel - 19th January 2006

(09:38 GMT)

Hi Cerebrum, Please can you explain what you mean "Can you sum all values in the busy hour", which values do you mean? Regards

Cerebrum - 17th January 2006

(14:25 GMT)

Hi,Abdel! Excuse me for my proposal but i have some doubts of the BHCA value. I wonder whether this value for BHCA is for BH or for all of call attempts made in your network? I can't imagine that BHCA can increase so rapidly, without corresponding augmentation of the subscribers. Other approach for estimating TV: From your post i understood that your DataBase have a field "TIMES OF CALL ATTEMPT". Can you sum all values in the busy hour? The result will be the Traffic Volume carried by the network or the branch that you oversee in the Busy Hour.

areeba - 17th January 2006

(13:46 GMT)

The BHCA declared in this formula is just for success call establishment attempts. Establishment failure (control ch issue) is not implicated in this formula. So the formula stipulated that your n/w is not congested (< = 0.2% GoS TCH) & (< =0.01% control channel).

Abdel - 17th January 2006

(13:43 GMT)

I think there must be a way the program used to calculate the BHCA, in a normal enviroment how does the programs calculate the BHCA in their network, using calculatins like 6-9=C*100 Regards

Abdel - 17th January 2006

(13:17 GMT)

yesterday the the busiest hour values where: Time: 17:00~18:00 BHCA:896,086 Subs:14,895 MHT:70.8 our BHCA is increasing sharply day after day.

Abdel - 17th January 2006

(13:12 GMT)

I just queried the program in my client used for performance and maintainance, the values calculated by the software is divided into two, default values wich can't be modified or deleted like TIMES OF CALL ATTEMPT, and they don't have any formula appeared, and values which can added by yourself in order to help you to find out values without calculating by you for example, powered on subscribers in your network can be find by 6-9 where 6=total subscribers registered. 9=detached subsribers. I found out that if I query one hour interval the times of call attempt will be the same as BHCA. Yes it is true, our network is very congested and some of my cells have more than 60% of congestion in one hour, the subscribers are making several call attempt in order to go through it. but I don't know so much about GOS, I am a newbie in telecom and my company is expecting a lot from me. I really appreciate your help. Regards Regards

Cerebrum - 17th January 2006

(12:49 GMT)

Hi, Abdel! I don't know the format of the data you are using. And untill I understand this format i can't help you with more specific answer.Sorry! Reading your words I suppose you calculate the BHCA - I think tahat this value must be measured from some kind of equipment or software. From my experience I don't calculate BHCA I have them measured and use them without making any effort. One of the reasons for increasing the number of call attempts is that your network is working with very high GoS and one subscriber is making several call attempts to make a conversation - I don't think that it's true. I advise you to check the method for calculating the BHCA. With the other question - Yes these times are correct, but I still think that so few subscribers cannot make so many call attempts in an hour. Check again your queries. Is the number of the subscribers corresponds to the number of the call attempts?

areeba - 17th January 2006

(12:41 GMT)

BHCA= peak traffic/(# of subscriber x MHT). # of subscriber= peak traffic/Erlang per subscriber. ...... the erlang per subscriber is standard estimated (16 to 20mErlang).

Abdel - 17th January 2006

(12:00 GMT)

Is Times of call attempts on an hour interval query equal to BHCA? I am quiet confused with it. Regards

Abdel - 17th January 2006

(11:48 GMT)

Hi Cerebrum, The formula to calculate the BHCA is not the systems one, it is setted by someone else before, therefore what is the formula to find out BHCA? Regards

areeba - 17th January 2006

hi abdel:

(06:41 GMT)

Your BHCA is toooooo high regarding the number of subscriber ==> estimated attempt per subscriber= 390/14= 28 attempts???? It is too high & too seldom occurred (may be in huge event or disaster)

Cerebrum - 16th January 2006

(19:44 GMT)

Hi, Abdel! This is quite interesting data. With these values I conclude that this is bothway traffic. But these values are still very high for mobile subscribers. I think that there is somthing wrong too. If you estimate how many calls make/receive each subscriber - the value is 27.1 calls/sub for an hour. In real situations this cannot be true only at very special events like earthquakes, tsunami, etc. I recommend you to check all your queries and methods for gathering data. I have doubts of the number of subscribers you consider. Their number doesn't correspond to the number of BHCA. Best regards.

Abdel - 16th January 2006

(16:14 GMT)

Hi Cerebrum, How can I know whether it is both way or one way (orinating), i queried my daily report and I found out MHT and BHCA with an interval of 60min, i used your formula and I got various high and low result from 0.1-800mili-erlang. I think there is something wrong with my calculation! Can you please help me Cerebrum. Let me give you an example of the busiest hour values: Hour: 18:00~19:00 MHT:58.9 BHCA:390,376 Subs:14,402.5 Result:443.6 mili-erlang. Can this result be possible?! Regards

Abdel - 16th January 2006

(15:54 GMT)

Hi Yayra, MHT means Mean Holding Time the time between the seizure of the circuit to the release of the call. Regards

Yayra - 16th January 2006

(14:12 GMT)

I have been trying to follow your interesting discussions. I just don't get one of the acronyms you are using; MHT. What does it stand for? Thank you

Cerebrum - 16th January 2006

(07:34 GMT)

Hi, again! For the previous question - What value you must use? In the ITU-T recommenadations E.xxx is said that you must take into account at least 30 records for the BH (these records must be only in one category - working days, weekends, yearly esceptional days /Christmas, Easter and so on./) The second highest value is the high load traffic, the fourth is the normal load traffic. The network must be estimated for the normal load, but must fullfil other requirements. For PSTN networks these GoS values are - 1% and 7%. Usually the second demand is harder for carrying out. Best regards.

Cerebrum - 16th January 2006

(07:15 GMT)

Hi, Abdel. 190 mErlangs traffic is possible per subscriber if you consider bothway traffic - originated and incoming for a subscriber. But if this is only the originated traffic it is a quite big value, but of course possible, if your subscribers are very active.

Abdel - 15th January 2006

(14:33 GMT)

I got more than 190 mili erlang for the average traffic per subscriber? is this possible since I was expecting about 25 -50 milierlang

colein - 15th January 2006

(13:58 GMT)

MHT in network level must be multiplied by 2, to account erlang in source & destination.

Prav - 15th January 2006

(07:55 GMT)

abdel u have to take powered on subscribers only ( MAX VLR COUNT)

Abdel - 14th January 2006

(07:30 GMT)

Thanks Cerebrum, for your quick response, I calculated and I have different values for everyday and every month therefore should I use the highest value for a month record or several month or the average of the recorded values. Also the number of subscribers, are the the powered on subscribers or all my registered subscribers? Regards

Cerebrum - 12th January 2006

(14:48 GMT)

Hi, Abdel. If you multiply BHCA x MHT = Traffic Volume (TV) in BH. And If you devide TV/Subs= Average Traffic Volume per One subscriber. In Erlangs this is: TV/((Subs)*X) X=60 - MHT in [min] X=3600 - MHT in [sec] This is in case you are looking for the average traffic per user in BH. For traffic calculations this value is needed. But if you need the average traffic per day, you must multiply TV in BH with a concentration factor. In the books the concentration of traffic in BH is about 15-20%. But in our network the concentration is less than 12%. If you have more questions I'll be glad to help you. Buy

Abdel - 12th January 2006

(07:48 GMT)

hI Mihaiz, thanks for your reply. BHCA is Busy Hour Call Attempt, it is the call attempts made in the busiest hour in your network daily,Yes MHT is calculated at network level. Regards,

MihaiZ - 11th January 2006

(23:06 GMT)

1)What is "BHCA"? is this the Busy Hour Call volume? If YES, is this for the whole network? 2)Is the MHT calculated at the network level?

Abdel - 9th January 2006

(09:16 GMT)

How can I calculate the average traffic per subscriber of our GSM network if I have: 1. BHCA 2. MHT

Calculating VOIP Bandwidth

Calculating trunk requirements in the voice world meant determining the call load during the peak hour and using Erlang formulas, or simulation models, to derive the appropriate number of trunks for a given blockage factor or grade of service. In the VOIP world, the total bandwidth required to handle peak hour calling across the IP network must be determined. This newsletter describes a calculation process that can be used to estimate the data network bandwidth required per VOIP call and for the total system. In the late 1800s and early 1900s, two mathematicians developed theories to describe the occurrence and handling of events; this would have a huge impact on telecommunications management, even to this day. Simeon Poisson was responsible for developing a model that described the occurrence of random events, which could be used to predict the number of events that would occur in a given period when these events were not dependent on one another. This is known as the Poisson distribution model and described how random events tend to occur in bunches. Predicting Trunk Requirements A few years later, Agner Kraruo (A.K.) Erlang used the Poisson distribution model to describe telephone calling demand while developing his theory for predicting the number of telephone trunks required to handle this demand. At that time, A.K. Erlang was working for the Copenhagen Telephone Company in 1908. He developed a formula, called the Erlang-B formula, which predicted the probability that a defined number of calls arriving would be greater than a defined number of available trunks to handle those calls causing blocked calls. In other words, the probability that there would be too many calls for the number of trunks. This probability of blockage formula assumed that the blocked calls went away and didnt reappear for a long time this is not completely accurate, but close enough to make the model simple and workable. The calling load, besides fitting into a Poisson distributed arrival pattern, is defined in terms of the average number of calling minutes measured over an hour. The hour selected is usually the busiest, or peak hour, as the number of trunks require to satisfy that time frame will handle all others even better. To express the load, one could use call-minutes per hour, call-seconds (CS) per hour, hundreds of call-seconds per hour (CCS), or Erlangs. An Erlang is a measure that assumes the base is an hour, or 3600 seconds; for example, 10,000 call-seconds per hour is equivalent to 2.78 Erlangs (10,000 divided by 3600). Erlangs are the input to the Erlang-B model. By running this formula using many combinations of calling traffic (Erlangs) and available trunks, one could produce

a set of tables that show the relationship of the call load, probability of blockage, and trunk utilization, as shown by the sample table. Hours First Attempt means peak hour load, with an hour of calling per peak hour being an Erlang. Hours Connected and Hours Overflow defines the traffic that got through and the traffic that did not during this hour. Lines mean the number of trunks available, beginning at two. For many years, engineers used tables like this one contained in a large book of such tables; however, computer programs are readily available today to provide this information in a variety of formats.

There are two other factors to explain in this sample table. One factor shown is called Grade of Service (GOS), a value that must be selected by the designer. GOS is the level of blockage that is acceptable for your system. It is the probability (P) of a call being blocked, expressed as a percentage. Because of the nature of the formula, a GOS level must be stated and 5% - 10% is a commonly used value when determining the number of access trunks required for a PBX, for example. A 5% GOS may also be stated as P05. The trunk utilization pattern in this table, as described by "Hours Connected Traffic On Lines", assumes that the trunk selection process starts at the first trunk and rolls over to the next trunk down the list until an available one is found. This is the reason the utilization values are distributed in the manner shown. By using the GOS factor and the trunk utilization factors, one can best select the number of trunks to install for a given load as the trunk utilization will show the actual amount of traffic carried, especially for the very last trunk in the selection process.This particular table format is a very useful one because of this utilization factor data. This formula can be used to determine the number of trunks required in a twoway system; that is, trunks carrying traffic inbound from the network as well as outbound from the office, or two-way trunks. In this case, the traffic level

considered, or Erlangs, would represent the total for both directions. This will provide a good first step of the solution; however, the actual trunk selection method used by switches at each end would have to be considered. The formula will also predict the number of T1 channels required as a T1 channel would equate to a trunk. Later on in his career, A. K. Erlang enhanced his model to show the effects of callers waiting in a queue for an operator, such as being on hold for a call center. This formula, called the Erlang-C model, can be used to determine the number of operators required and the wait time of the caller depending upon the call volume and number of operators available over the average hour being studied. To be reasonably accurate, these probability formulas assume that the call volume is substantial (not 1 or 2 an hour) and that the traffic loads arrival rate had been operating at that level for some time (not slowly ramping up to that level). The Erlang-C formula, being a queuing formula (for more information on the use of queuing theory in telecommunications see newsletter Applying Queuing Theory to Network Design), assumes that the call duration times are distributed in an exponential manner; that is, they are not constant for each caller and they are not dependent upon the duration of other calls. The message here is that these formulas are based upon certain assumptions that approximate the real world events, so their output is a good approximation of the real system. With this knowledge, they can be employed effectively while being simple to use and cheap. To obtain more accurate results, either for very large systems or for situations that are not the norm, computer simulation models should be considered. VOIP Requires an Extra Step VOIP is a different animal. The question in these systems is not how many trunks are needed to handle calls but how much data network bandwidth is required - how many T1 trunks are require? The answer to this question is more complex to determine than it seems. As we all know, the (Telco) standard way to use a digital T1 trunk for voice is to put digitized calls on one of the 24 available multiplexed channels of the T1 - one call per channel. However, VOIP traffic is defined by packets not calls and packets are not identified by channels but by their IP or other address. Lets first review how this is done and then how to calculate the needed data network capacity or bandwidth. Voice is first converted into a bit stream by a codec, or digitizing mechanism, and placed into data packets. The codec type used determines the basic data rate for the call, which is usually one defined by the ITU-Ts (International Telecommunications Union Telecommunications standards section) G.700 series standards. Which codec type to use depends on the application; for example, calls going around the office on the high-speed LAN would use a highquality 64K bps basic or broadband codec while calls going over an expensive wide area network would use a slightly lower quality 8K bps codec to keep costs down. The amount of digitized voice carried in a packet ranges

from 20 ms to 50 ms of voice content, called a sample. This selectable parameter allows the designer to choose between high resolution and high bandwidth (20 ms samples size) or lower resolution and lower bandwidth (50 ms sample size) options. Voice is a real time application, so the number of samples has to add up to one seconds worth per second. Therefore, a 20 ms sample size requires the generation of 50 packets per second and a 50 ms sample size requires generating 20 packets per second. Heres the tradeoff: a small voice sample size (20 ms) requires the transmission of more packets, the packets take less delay time to create, and if one is lost there is less impact on the resulting voice quality but a large sample size (50 ms) requires the transmission of fewer packets, takes a longer delay time to create, and if one is lost there is a bigger impact on the resulting voice quality. This translates into bandwidth required versus voice quality. Each packet generated carries protocol overhead bytes along with the voice content bytes, which must be combined to determine the total bandwidth required per call. All packets will carry the IP header (Internet Protocol) field, the UDP header (User

Datagram Protocol) field and the RTP header (Real Time Protocol) field, which combined adds 40 bytes to the packet. Additional fields added will depend upon the frame-level (Layer 2 for those who are into data communications architectures) protocols used and any adjunct control fields added. Typically, the voice packet is encapsulated in an Ethernet frame for transport around the office and PPP (Point-to-Point Protocol) frames for transmission out over a WAN link. The Ethernet frame includes 26 bytes for a typical implementation and the PPP adds 8 bytes to the packet. Therefore, the total overhead that is added to the voice content per packet is 528 bits (40 bytes plus 26 bytes times 8 bits per byte) when using Ethernet and 384 bits (40 bytes plus 8 bytes time 8 bits per byte) when using PPP. There is also inter-packet spacing time to consider, but we wont. The calculation to determine the bandwidth required per call is straight forward, as shown. Here we are assuming that the calls will be going from IP phone to IP phone over the in-house Ethernet LAN. The selected sample size, say 20 ms, determines the number of packets/frames per second that must be generated,50 per second. Each frame will carry the appropriate amount of overhead bytes - 26 using Ethernet plus 40 for other protocols for a total of 66 bytes per frame for a

total of 3300 bytes per second of overhead. Converting this to bits (8 bits per byte) yields 26,400 bits per second of bandwidth required to carry just the overhead. To this is added the codecs voice digitization coding rate (G.711 generates 64k bps) to yield the total bandwidth required of 90.4K bps (26.4k bps plus 64k bps or 90.4k bps) to handle a VOIP call in one direction.

Another common problem is the determination of the access bandwidth required to carry VOIP calls out of the office to the IP carriers network. Here the assumption might be the use of the PPP packet, 20 ms samples, and 8K bps codec. This calculation shows a capacity of 27.2K bps would be required in each direction to handle a call.

Incorporating the Erlang Formula These calculations provide the bandwidth required for a single VOIP call while it is in progress. The final step is to determine the overall bandwidth required to support all calls during the peak hour. To accomplish this, the standard Erlangtype analysis must be employed; that is, determine the total calling traffic (number of calls times the average length of a call) during the peak hour and then calculate the number of trunks required for a given grade of service, as demonstrated above. Each required trunk using the Erlang formula would

represent a continuous talk path available to handle the offered calls at the GOS specified, which in the VOIP world would be represented by the IP bandwidth required to carry a conversation as calculated previuously. For example, if 10 trunks were required to handle a certain call volume at a P05 grade of service, then the bandwidth required to support VOIP to and from the carriers IP network at that same GOS (using PPP, 20 ms samples, and 8K bps codecs) would be 272k bps (27.2k bps per call times 10 trunks or continuous paths.). This represents full-duplex bandwidth or the bandwidth required in both directions (272k in each direction). An additional load factor should be added to account for some call signaling/control traffic that may occur during the call. Optimizing the Process This should give you more than enough bandwidth to handle the VOIP traffic; however, there are some adjustments that can be made to this calculation, which depend upon other assumptions or design factors. The bandwidth requirement can be reduced somewhat by two measures. One would be an assumption for the use of silence suppression techniques if a person is not talking, no packets will be generated. This factor, conservatively, varies between a 20%-35% reduction. Furthermore, header compression could be employed, which would reduce the IP/UDP/RTP header size from 40 bytes to 2 bytes over certain links. The VOIP protocol selection can also influence the overhead and throughtput factors as well; for example, the IAX2 protocol developed for use with the open-source Asterisk IP-PBX software supports multiple call samples in a single packet. Such a technique provides more voice for the same overhead per packet. The bandwidth requirement might be increased as well. This could occur if additional overhead fields are added to the frame and flow control measures are incorporated in the network, such as to support security and quality of service techniques. Similarly, the overhead factor for the IP control field's size will have to be changed when moving from the current IP version 4 protocol to the newer IP version 6 protocol. This will add another level of complexity to the bandwidth prediction process as IP version 6 supports the use of many, optional headers, which will make this field size highly variable in the future. This calculation process also assumes that the call contains only voice content; however, it is possible that tones, music, or video content occur during the call as well. Different content will use different codecs, which can be dynamically adjusted via the signaling protocol and Real Time Control (RTP) protocol mechanisms throughout the call's duration. The Erlang models have been around for a long time, used extensively in telephone systems engineering and are also applicable as part of the tool set for VOIP systems design. The processes described above are very useful for rough capacity prediction, network cost analysis and troubleshooting and can be modified to include other events and traffic types. Further Training These types of tips and insights can be found in all training classes provided by McGuire Consulting. The high quality nature of these courses is based on the many years of work and training experience of the author, Jay D. McGuire.