Presentation is loading. Please wait.

Presentation is loading. Please wait.

VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.1 VoIP Voice Stream Multiplexing VoIP Forum Honolulu, Hawaii July 16, 17 Tohru Hoshi.

Similar presentations


Presentation on theme: "VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.1 VoIP Voice Stream Multiplexing VoIP Forum Honolulu, Hawaii July 16, 17 Tohru Hoshi."— Presentation transcript:

1 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.1 VoIP Voice Stream Multiplexing VoIP Forum Honolulu, Hawaii July 16, 17 Tohru Hoshi Keiko Tanigawa Systems Development Laboratory Hitachi, Ltd.

2 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.2 Table of Contents zIssues on Voice Streaming multiplexing pointed out last meeting yAdditional delay? yAdditional packet loss? yEffectiveness of multiplexing? yArchitecture and protocol requirements xnot to have constraints on multiplexing sequence xto have H245 capabilities exchange to indicate support of multiplexing zMultiplexing Format zSummary and Future Work

3 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.3 Network Topology of IP-GWs with multiplexing PSTN Phone IP-GW PSTN Internet PSTN IP-GW Phone Multiplexed voice stream channel Single stream channel IP-GW PC (H.323)......

4 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.4 Overhead Reduction and Packet reduction zDiscussed in last Portland meeting zResults shows yPacket overhead is reduced to about 2/3 yPackets are reduced to 1/ number of multiplexing

5 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.5 Header overhead reduction (example calculation) (kbps) Number of simultaneous connections (streams) 20 120 100 80 60 40 1 2 4 8 non multiplex multiplex 8 streams Bandwidth used Option 1 Option 2 multiplex 4streams Option 1 Option 2

6 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.6 Additional delay? zOriginating side zNetwork side zTerminating side

7 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.7 Additional delay? :Originating side yCoding delay : no additional delay yAdditional multiplexing processing delay caused by multiplexing interval ymultiplexing interval is set to equal to or less than framing or packetizing interval G.723.1 framing and packetizing interval 30ms G.729 framing interval 10ms, packetizing interval 20ms yAdditional delay = multiplexing interval xless than 10s ms example of multiplexing interval: 10 ms, 20 ms, 30ms

8 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.8 Additional delay? :Network side yStore and forward delay in Router x store and forward delay = packet length/line speed xComparison in 1.5Mbps line: non multiplex mode: 0.3ms/hop 8 multiplex mode: 1.5ms/hop Additional delay is 1.2 ms/hop IP-GW Phone router Line speed 10Mbps

9 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.9 Additional delay? :Network side Transmission delay/hop (store and forward delay) 2 4 6 8 ms 128 384 768 1544 kbps 8 mux 3 mux Non- mux Additional delay Conditions G.723.1 5.3kbps framing interval 30ms packetizing interval 30ms multiplexing interval 30ms Voice 20B no silence compression IP+UDP 28B RTP 12B Mux-H 2B

10 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.10 Additional delay? :Termination side yAdditional storing delay is less than 1 ms because of 10 Mbps/100Mbps connected fast LAN speed. yNo additional delay is introduced by de- multiplexing

11 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.11 Additional delay? :Conclusion zOriginating side: ycause: multiplexing delay x 10s ms (example: 10 - 30 ms) zNetwork side: ycause:store and forward delay x1.2 ms/hop (in case of 1.5Mbps line) zTerminating side: ycause:storing delay xnegligible small zOver all yAdditional delay caused by multiplexing is several 10s ms and this is rather small compared with the internet delay of several 100s ms.

12 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.12 Additional Packet Loss? zAdditional packet loss introduced by channel bit bit error rate(BER) zAdditional packet loss introduced by packet loss in router

13 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.13 Additional Packet Loss? (cont.) zPacket Loss by BER yBER is proportional to packet length ypacket loss rate caused by BER xNon-mux :P1 =480*p x3 Mux :P2= 1008*p x8 Mux :P3= 2288*p zDiscussions yMultiplexed stream has higher packet loss rate, ybut less than the rate of n times of non-mux mode ySince BER is less than 10 -6, then packet loss introduced by BER is negligible small (compared to Internet’s packet loss of 10 -1 - 10 -2 ) Voice packet Length i bit BER:p Packet Error Rate:P P = 1 - (1-p) i = nearly 1-(1-ip) = ip 1 4 8 # of mux Comparison of P P=Pi/P1 1 4 8

14 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.14 Additional Packet Loss? (cont.) zPacket loss in nodes yLarge packet loss in the Internet seems to be introduced in routers yReason is overload burst packet traffic to the routers yOverload condition occurs based the number of packets yMultiplexing mode will reduce the number of packets to the nodes and this will improve overload condition and reduce packet loss zConclusion yPacket loss rate in multiplexing is nearly the same compared to non-multiplexed mode.

15 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.15 Effectiveness of multiplexing? zIn case of concentrated traffic on certain IP- GWs yFor the enterprise network or large VoIP traffic route in ITSP, it in no doubt that multiplexing is useful yThis is similar to VoFR environment zIn case of flat traffic on IP-GWs network yEffectiveness of multiplexing is considered

16 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.16 Effectiveness of multiplexing? -flat traffic over IP-GW network- 1 2 3 N N-1 zSimplified Model yMesh Configuration ySame traffic deviation between nodes Internet N 5 10 20 40 50 # of links 10 45 190 780 1225 calls/node 40 Total calls 100 200 400 800 1000 ave mux# 10 4.4 2.1 1.0 0.8 calls/node 100 Total calls 250 500 1000 2000 2500 ave mux# 25 11.1 5.2 2.6 2.0

17 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.17 Effectiveness of multiplexing?(cont.) -flat traffic over IP-GW network- 10 20 30 40 Number of Nodes number of multiplexing 1 10 20 simuntaneous calls/node : 40 simuntaneous calls/node :100 Multiplexing is useful for the IP-TEL NW with several 10s of IP-GWs zDegree of Multiplexing

18 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.18 Effectiveness of multiplexing?(cont.) -flat traffic over IP-GW network- 10 20 30 40 Number of Nodes Total Packets (Normalized) 0.5 1.0 w/o multiplexing w/ multiplexing simuntaneous calls/node : 40 w/ multiplexing simuntaneous calls/node :100 packets reduction zPacket Reduction

19 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.19 Multiplex Sequence variable? H1H12 1 H232 H33 3 2 1 Voice stream #3 Voice stream #2 Voice stream #1 t zOur implementation example shows “yes” shown below yVariable multiplexing sequence(FIFO base) and variable length yUse of existing port for multiplexing new calls Multiplexed stream

20 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.20 Multiplexing method: Multiplexing Layer IP UDP mux RTP Voice IP UDP New RTP profile for mux Voice RTP (a) RTP Multiplexing(b) Multiplexing in RTP (c) New multiplexing method IP UDP New Multiplexing method Voice RTP

21 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.21 Multiplexing method: Multiplexing Format IP-Header UDP Header RTP voice 1 20B8B …….. RTP Header RTP Header voice RTP voice n 12B+20B(G.723.1) (a) RTP Multiplexing (Hitachi’s proposal) IP-Header UDP Header 20B8B …….. RTP Header Voice 1 Voice n (b) Multiplexing in RTP (Lucent:Rosenberg’s new proposal) 12B RTP-MUX Header 2or4B/user

22 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.22 Multiplexing method: Comparison zRTP Multiplexing yWhile keeping RTP voice packet streams, and aggregate them into a multiplexed stream y“multiplex”profile exchange in H.245 call control required xto be defined yRTP process modification: no ySimple implementation way using current RTP voice packet format zMultiplexing in RTP yDefine new payload type and format “multiplex” in RTP y“multiplex”profile exchange: new payload type to be defined within RTP yRTP process modification: large ySeems complex in implementation zNew multiplexing method yDefine new protocol for multiplexing

23 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.23 Multiplexing: Multiplexing Format proposal to IETF zLucent: Rosenberg’s new proposal y“An RTP Payload Format for User Multiplexing” yhttp://www.ietf.org/internet-drafts/draft-ietf-avt-aggregation- 00.txt zHitachi’s proposal based on IP-GW implementation y“An RTP Simple Transfer Method for Internet Telephony Gateway” yhttp://www.ietf.org/internet-drafts/draft-tanigawa-rtp-multiplex- 00.txt

24 VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.24 Summary and Future Work zExamine additional delay and packet loss caused by multiplexing, which result in small influence to VoIP systems. Also, show the effectiveness of multiplexing. zCategorize multiplexing layer and protocol and introduce internet-draft proposals to IETF zMore discussions needed for multiplexing format and protocol


Download ppt "VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.1 VoIP Voice Stream Multiplexing VoIP Forum Honolulu, Hawaii July 16, 17 Tohru Hoshi."

Similar presentations


Ads by Google