+ All Categories
Home > Documents > VoIP Forum July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.1 VoIP Voice Stream Multiplexing...

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

Date post: 15-Dec-2015
Category:
Upload: davion-disher
View: 216 times
Download: 2 times
Share this document with a friend
Popular Tags:
24
July 16 -17 (c) 1998 All rights rese rved, Hitachi, Ltd. 1 VoIP Forum VoIP Voice Stream Multiplexing VoIP Forum Honolulu, Hawaii July 16, 17 Tohru Hoshi Keiko Tanigawa Systems Development Laboratory Hitachi, Ltd.
Transcript
Page 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

1

VoIP Forum

VoIP Voice Stream Multiplexing

VoIP ForumHonolulu, Hawaii

July 16, 17

Tohru HoshiKeiko Tanigawa

Systems Development LaboratoryHitachi, Ltd.

Page 2: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

2

VoIP Forum

Table of Contents

Issues on Voice Streaming multiplexing pointed out last meeting Additional delay? Additional packet loss? Effectiveness of multiplexing? Architecture and protocol requirements

not to have constraints on multiplexing sequenceto have H245 capabilities exchange to indicate support of

multiplexing

Multiplexing FormatSummary and Future Work

Page 3: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

3

VoIP Forum

Network Topology of IP-GWs with multiplexing

PSTN

Phone

IP-GWPSTN

Internet

PSTN

IP-GW

Phone

Multiplexed voice stream channel

Single stream channel

IP-GW

PC (H.323)

.

.

.

Page 4: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

4

VoIP Forum

Overhead Reduction and Packet reduction

Discussed in last Portland meetingResults shows

Packet overhead is reduced to about 2/3

Packets are reduced to 1/ number of multiplexing

Page 5: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

5

VoIP Forum

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

Bandw

idth

use

d

Option 1

Option 2

multiplex 4streams

Option 1

Option 2

Page 6: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

6

VoIP Forum

Additional delay?

Originating sideNetwork sideTerminating side

Page 7: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

7

VoIP Forum

Additional delay? :Originating side

Coding delay : no additional delay Additional multiplexing processing delay caused

by multiplexing interval multiplexing interval is set to equal to or less tha

n framing or packetizing interval• G.723.1 framing and packetizing interval 30ms• G.729 framing interval 10ms, packetizing interval 20ms

Additional delay = multiplexing interval less than 10s ms

• example of multiplexing interval: 10 ms, 20 ms, 30ms

Page 8: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

8

VoIP Forum

Additional delay? :Network side

Store and forward delay in Router store and forward delay = packet

length/line speedComparison 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 IP-GWPhone Phonerouter router

Line speed

10Mbps 10Mbps

Page 9: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

9

VoIP Forum

Additional delay? :Network sideTra

nsm

issi

on

dela

y/h

op

(st

ore

an

d f

orw

ard

dela

y)

2

4

6

8 m

s

128 384 768 1544 kbps

8 mux

3 mux

Non- mux

Additional delay

ConditionsG.723.1 5.3kbps framing interval 30mspacketizing interval 30msmultiplexing interval 30msVoice 20B no silence compressionIP+UDP 28BRTP 12BMux-H 2B

Page 10: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

10

VoIP Forum

Additional delay? :Termination side

Additional storing delay is less than 1 ms because of 10 Mbps/100Mbps connected fast LAN speed.

No additional delay is introduced by de-multiplexing

Page 11: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

11

VoIP Forum

Additional delay? :Conclusion

Originating side: cause: multiplexing delay

10s ms (example: 10 - 30 ms) Network side:

cause: store and forward delay1.2 ms/hop (in case of 1.5Mbps line)

Terminating side: cause: storing delay

negligible small

Over all Additional delay caused by multiplexing is several 10s ms a

nd this is rather small compared with the internet delay of several 100s ms.

Page 12: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

12

VoIP Forum

Additional Packet Loss?

Additional packet loss introduced by channel bit bit error rate(BER)

Additional packet loss introduced by packet loss in router

Page 13: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

13

VoIP Forum

Additional Packet Loss? (cont.) Packet Loss by BER

BER is proportional to packet length

packet loss rate caused by BER Non-mux :P1 =480*p 3 Mux :P2= 1008*p 8 Mux :P3= 2288*p

Discussions Multiplexed stream has higher packet loss rate, but less than the rate of n times of non-mux mode Since BER is less than 10-6, then packet loss introduced by BER is negligi

ble small (compared to Internet’s packet loss of 10-1-10-2)

Voice packet

Length i bit

BER:pPacket Error Rate:PP = 1 - (1-p)i

= nearly 1-(1-ip) = ip

1 4 8 # of mux

Com

pari

son

of P

P=

Pi/

P1

1

4

8

Page 14: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

14

VoIP Forum

Additional Packet Loss? (cont.)

Packet loss in nodes Large packet loss in the Internet seems to be introduced

in routers

Reason is overload burst packet traffic to the routers Overload condition occurs based the number of packets Multiplexing mode will reduce the number of packets to

the nodes and this will improve overload condition and reduce packet loss

Conclusion Packet loss rate in multiplexing is nearly the

same compared to non-multiplexed mode.

Page 15: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

15

VoIP Forum

Effectiveness of multiplexing?

In case of concentrated traffic on certain IP-GWs For the enterprise network or large VoIP traffic route in

ITSP, it in no doubt that multiplexing is useful This is similar to VoFR environment

In case of flat traffic on IP-GWs network Effectiveness of multiplexing is considered

Page 16: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

16

VoIP Forum

Effectiveness of multiplexing? -flat traffic over IP-GW network-

1 2

N-1

Simplified Model Mesh Configuration Same 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 1000ave mux# 10 4.4 2.1 1.0 0.8

calls/node 100Total calls 250 500 1000 2000 2500

ave mux# 25 11.1 5.2 2.6 2.0

Page 17: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

17

VoIP Forum

Effectiveness of multiplexing?(cont.) -flat traffic over IP-GW network-

10 20 30 40 Number of Nodes

n

umbe

r of

mul

tiple

xing

1

1

0

20

simuntaneous calls/node : 40

simuntaneous calls/node :100

Multiplexing is useful for the IP-TEL NW

with several 10s of IP-GWs

Degree of Multiplexing

Page 18: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

18

VoIP Forum

Effectiveness of multiplexing?(cont.) -flat traffic over IP-GW network-

10 20 30 40 Number of Nodes

T

otal

P

acke

ts (

Nor

mal

ized

)0.

5

1.

0

w/o multiplexing

w/ multiplexingsimuntaneous calls/node : 40

w/ multiplexingsimuntaneous calls/node :100

packetsreduction

Packet Reduction

Page 19: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

19

VoIP Forum

Multiplex Sequence variable?

H1H121H232H33

3 2 1

3 2 1

3 2 1 Voice stream #3

Voice stream #2

Voice stream #1

t

Our implementation example shows “yes” shown below Variable multiplexing sequence(FIFO base) and variable

length Use of existing port for multiplexing new calls

Multiplexed stream

Page 20: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

20

VoIP Forum

Multiplexing method: Multiplexing Layer

IP

UDP

mux

RTP RTP RTPRTP

Voi

ce

Voi

ce

Voi

ce

Voi

ce

IP

UDP

New RTP profile

for muxV

oice

V

oice

Voi

ce

Voi

ce

RTP

(a) RTP Multiplexing (b) Multiplexing in RTP (c) New multiplexing method

IP

UDP

NewMultiplexing

method

Voi

ce

Voi

ce

Voi

ce

Voi

ce

RTP

Page 21: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

21

VoIP Forum

Multiplexing method: Multiplexing Format

IP-Header UDPHeader

RTP voice 1

20B 8B

……..RTPHeader

RTPHeadervoice voice

RTP voice n

12B+20B(G.723.1)

(a) RTP Multiplexing (Hitachi’s proposal)

IP-HeaderUDPHeader

20B 8B

……..RTPHeader Voice

1

Voice n

(b) Multiplexing in RTP (Lucent:Rosenberg’s new proposal)

12B

RTP-MUXHeader

2or4B/user

Page 22: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

22

VoIP Forum

Multiplexing method: Comparison RTP Multiplexing

While keeping RTP voice packet streams, and aggregate them into a multiplexed stream

“multiplex”profile exchange in H.245 call control required to be defined

RTP process modification: no Simple implementation way using current RTP voice packet

format Multiplexing in RTP

Define new payload type and format “multiplex” in RTP “multiplex”profile exchange: new payload type to be defined

within RTP RTP process modification: large Seems complex in implementation

New multiplexing method Define new protocol for multiplexing

Page 23: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

23

VoIP Forum

Multiplexing: Multiplexing Format proposal to IETF

Lucent: Rosenberg’s new proposal “An RTP Payload Format for User Multiplexing” http://www.ietf.org/internet-drafts/draft-ietf-avt-aggregation-00.t

xt

Hitachi’s proposal based on IP-GW implementation “An RTP Simple Transfer Method for Internet Telephony Gateway” http://www.ietf.org/internet-drafts/draft-tanigawa-rtp-multiplex-0

0.txt

Page 24: 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.

July 16 -17 (c) 1998 All rights reserved, Hitachi, Ltd.

24

VoIP Forum

Summary and Future Work

Examine additional delay and packet loss caused by multiplexing, which result in small influence to VoIP systems. Also, show the effectiveness of multiplexing.

Categorize multiplexing layer and protocol and introduce internet-draft proposals to IETF

More discussions needed for multiplexing format and protocol


Recommended