- This topic has 11 replies, 1 voice, and was last updated 18 years, 10 months ago by Mike.
15th February 2002 at 00:41 #21210zyvnGuest
Any thoughts to share?21st February 2002 at 01:42 #21211RommelGuest
Are you talking cable? Docsis 1.1 brings about Unsolicited Grant Service for voip traffic.
go to the http://www.cablelabs.com21st February 2002 at 16:13 #21212John RobertsonGuest
Look at Lucent’s web site and check out iMerge.22nd February 2002 at 13:11 #21213zyvnGuest
Rommel and John, Thanks for the replies. Anybody did engineer the voice traffic over hfc before? Any results?23rd February 2002 at 00:58 #21214RommelGuest
when you say HFC…it makes me think of a physical medium. Hybrid Fiber Coaxial. What is the transport?
HFC has been carrying E1 traffic. I am sure anyone here can talk for days about traffic engineering on circuit switched networks.
Over a Packet Cable network, is a different story. I am not really big on cable technology but I believe it would have to be based on the symbol rate and stuff along those lines.24th February 2002 at 05:15 #21215zyvnGuest
I am rfrring to PacktCabl/DOCSIS 1.1 as you mntiond.26th February 2002 at 01:31 #21216RommelGuest
Its pretty much the same as you do any other voice, but there are some issues.
How many users are you aggregating to each port on the head end? How many Erl of traffic per user? ~0.3 Erl per user for residential.
We know that IP=20 bytes of header
UDP = 8 bytes and RTP = 12 bytes, payload will depend on the codec and sample period. Add in the L2 headers for DOCSIS, I dont know them so you will have to look this up. This will tell you how many bytes each sample period will take up. Multiply by the packets per second to get the KBps. Figure out how much data speed, depending on QAMS etc… then see how many flows you can shove in. divide data speed by KB per call. Then youre done. This would be a theoretical number not including any data.
After you get max number of calls, you can figure out how many users you can aggregate to each head end port.
You would have to leave some space for the signaling of each of these calls too.27th February 2002 at 00:14 #21217zyvnGuest
Do you know any online resource on this I can look at?28th February 2002 at 21:03 #21218RommelGuest
I would read the specifications at
http://www.packetcable.com/specifications.html. This should help you understand the mechanisms used.
Rommel6th March 2002 at 20:47 #21219Kevin CorcoranGuest
Your previous post said that you estimate 0.3 Erl per residential user. Other posts I search on the Telecom Design Forum indicated typical is anywhere from 0.04 – 0.08 erlangs for residential users. Your figure of 0.3 seems to be several times higher. Can you explain the discrepancy? Thanks.7th March 2002 at 00:13 #21220RommelGuest
Sorry typo…its meant to be .03 Erl. but that would still be off from your benchmark.
I usually deal with IXCs vs PTTs and LECs, so that would be where the discrepancy lies. 🙂 my knowledge19th March 2002 at 16:43 #21221MikeGuest
Prior to their buyout by Comcast, AT&T issued a Request For Information (RFI) that listed the following traffic engineering guidelines to estimate expected load for system components.
This is based on a 4-Line Broadband Telephony Interface (BTI)/Multimedia Terminal Adaptor (MTA):
· Average size of Fiber Node: 600 households passed
· Telephony take rate: 27% initially and approximately 53% thereafter
· Average number of voice lines per customers: 2.1
· Average traffic per line: 0.137 Erlangs (HDBH)
· Average call holding time in busy hours: 180 seconds
· Peak data rate for high-speed data service:
– Case 1: 128 Kbps (upstream), 128 Kbps (downstream)
– Case 2: 128 Kbps (upstream), 512 Kbps (downstream)
– Case 3: 128 Kbps (upstream), 1.5 Mbps (downstream)
– Case 4: 300 Kbps (upstream), 3 Mbps (downstream)
· Data take rate: 25% initially and approximately 50% thereafter
· At a given time 30% of the data subscribers are logged-on and 15% of the logged-on subscribers actively transfer data.
Hope this helps.