Kyocera Corporation Enhance radio network connectivity and maintain a Quality of IP service application Proposal of extension of IEEE 802.21 2008/7/16

Kyocera Corporation

Enhance radio network connectivity and maintain a Quality of IP service application

Proposal of extension of

IEEE 802.21

2008/7/16

Kyocera Yokohama R&D Center

21-08-0201-01-0000-experimental-result_proposal

2Yokohama R&D Center

Background of a research

Objective of a research

Concept of a research

Summary of an experiment

Discussion of an extension of IEEE 802.21


Multi-mode terminal is supposed to be popular in a near future as radio network is extending. (e.g. 3G/WiFi/WiMax)– Connectivity to different radio network will

becomes important.– Maintaining a quality of IP service application

between different radio network will become important as well.

MIHF is very unique entity in terms of cross layer communication.



What is required to realize the connectivity between different radio networks?– Use network mobility protocol such as MIP.– But network mobility protocol alone can not

realize effective handover.– Handover manager is required with help of

link layer or network layer.– IEEE 802.21 is very useful to realize effective

handover but possible without it.



What is required to maintain a quality of IP service application between different radio networks?– Control parameters adaptively towards the

fluctuation of radio state.• Control Encode rate , Q factor• Handover is the most dramatic fluctuation of radio

state.

– Means to know abstracted L2 information that makes QoS conditions corresponds to L2 conditions.



MIHF is very unique entity in terms of cross layer communication.– Main role of MIHF is to mediate L2 events to

MIH user and L2 commands to link layer.– MIHF locates between IP and L2.– Upper layers such as L4 and application are

very comfortable if they get abstracted L2 information.

– MIHF has a great potentiality to connect multiple MIH users organically with link layer and themselves.



MIHF

Link Layer

802.16e 802.11 3G

MIP Handover Manager

TCP

Application1 Application2



To give IP service application or TCP abstracted L2 information and events related with handover( including MIP or NEMO signaling) by means of MIHF, and make it possible for them to enhance the connectivity to different radio networks with maintaining a quality or enhancing the performance.

Objective of a research


Choose available bandwidth (Rate) , as abstracted L2 information and delay/ jitter as QoS information.

Investigate suitable thresholds of available bandwidth for application.

Develop algorithm that converts abstracted L2 conditions to L2 conditions.Convert available bandwidth thresholds to

multiple L2 thresholds conditions.Choose Soft Phone and Video Streaming as IP

application.Application decide handover timing as part of

adaptive control to the fluctuation of radio state.

Concept of a research


Keio/WIDE and Kyocera have designed and implemented a MR which is capable of

NEMO + MCoA + 802.21

The MR performs the make-before-break handover with MCoA and triggers the handover by 802.21

We confirmed the MR works very well with iBurst and 1x EV-DO Rev.0VoIP clients communicates via the MR without any

packet loss during the handover

Topics of previous experiment 2006


handoverd(MIH User)

MIHd(MIH Function) iBurstd Link library iBurst UTD

every500ms

MIH_Get_Status.request

MIH_Get_Status.confirm

Link_Get_Parameters.request

Link_Get_Parameters.confirm

Threshold 1

Threshold 2

MIH_Handover_Prepare.request

MIH_Handover_Prepare.confirm

Link_UP.indication

EVDOd

Link_UP.Request

MIH_Switch

MIH_Commit.request

MIH_HandoverComplete.Request Link_Teardown.request

Link_Teardown.responseMIH_HandoverComplete.

Response

start pppfor EVDO

ChangeNetwork

MIH_Get_Status.requestLink_Get_Parameters

.request

EVDO DM port

Link_Get_Parameters.confirm

MIH_Get_Status.confirm

System flow


time

time

① the RSSI of iBurst goes below than Threshold 1 (-93dBm).② the NEMO path via EVDO is established③ the RSSI of iBurst goes below than Threshold 2 (-98dBm).

①

②

③

Change of L2 RSSI


time(second)

RT

P packet arrival tim

e (second)

RT

P packet sequence

error)handover from iBurst to EVDO

no packet loss at the VoIP traffic

The jitter became biggerbecause of the bad link quality

The VoIP trace on MNN


case packet loss delay(ms)

(1) NEMO + MCoA + 802.21 0 0

(2) NEMO + 802.21 33 350

(3) NEMO + only LinkDown 847 16900

(4) NEMO only 7338 142000

(1) See the previous two slides. 0 packet loss!(2) The case without MCoA support. The delay is caused by RTT of BU/

BA.(3) The case only with LinkDown event. The delay is about RTT of BU/B

A+ Link Preparation.(4) The simple NEMO case: Neither L2 indication nor MCoA. The MR didn’t aware of the link down before the PPP session time

out.

Comparison with other Scenarios


IPCloud

Mobile Router

HRPD

SoftPhone

SoftPhone

StreamingClient

iBurst

StreamingServer

Home Agent

Kyocera Corp.Yokohama

Keio University

Experiment (Network Configuration)

IPv6IPv6

IPv4

iBurst: ANSI ATIS HC-SDMA

IEEE 802.20 625k MC Mode


MR

MNNIEEE 802.21

(MIHF)

NEMO

Soft Phone Internet

IEEE 802.21 (MIHF)

HRPD

iBurst

RateControl

BufferControl

L2 Information

H/ O Information

RateH/ O

Information

Soft Phone

H/ O InfoRate

H/ OInformation

Rate

BufferControl

RateControl

H/ OThresh

StreamingServer

Rate Control

Streaming Client

Rate Control

Rate H/ O Thresh HAHandover

Rate

Experiment (Functional Configuration)


Mobile Router

SoftPhone

StreamingClient

NEMO /Handover Manager

MIHF

iBurst / EVDO

StreamingClient

MIHF

SoftPhone

MIHF

Experiment (Protocol Stack)


【 Subject 】– Radio conditions becomes worse 　 →

　 available bandwidth decreases → 　 block noise, image stiffness

【 Solution 】Obtain available bandwidth via 802.21 and control the rate.– In case that radio state becomes worse

Change to lower suitable rate to prevent from a significant quality degradation.

– In case that radio state becomes betterChange to higher rate and enjoy better quality

Start Goal

Adaptive Control by Video Streaming


Process Flow

Mobile Router

SoftPhone

StreamingClient

NEMO

802.21

iBurst / EVDO

StreamingClient

802.21

SoftPhone

802.21

Notify Min required bandwidth for handover

・ Request of the current available bandwidth.

・ Direct to notify if threshold of available bandwidth becomes 500kbps ,300kbps,100Kbps.

・ Direct to notify if threshold of available bandwidth becomes 200kbps ,300kbps so on. Use Handover threshold


Summary of Rate control by streaming

Radio State

ThresholdInfo

AnimationPlay Rate

Set the suitableRate

StreamingClient

IEEE 802.21

Begin at 600kbps

Lower than 500kbps

Higher than 300kbps

Notify threshold event

Animation playstart


【 Subject 1 】

Radio State becomes worse

→Available bandwidth becomes lower

→Voice comes out

【 Solution 】

Obtain available bandwidth by 802.21 and control encode rate based on it.

・ In case that radio state becomes worse

→Use lower encode rate and prevent voice from coming out.

・ In case that radio state becomes better

→Use higher encode rate with better quality of a call

Adaptive Control by Soft Phone – Encode Rate Control


【 Subject 2 】

Delay is different every radio network

→ Gap of receive packet during handover

→ Voice comes out

【 Solution 】Obtain the timing of Handover preparation and handover via MIHF, begin lower play during handover preparation to accumulate enough packets in jitter buffer so we prevent silence due to the gap of receive packet. In order to know how many extra packets to be accumulated , Soft Phone get Uplink/Downlink delay of two radio networks and NEMO signaling via MIHF.

Adaptive Control by Soft Phone – jitter buffer Control

MR

Internet

12

345

12

MNNSoft Phone

345Receive Time

180ms

Delay difference150ms

30ms


Test Factor= (fix)：Ｑ３

0

1

2

3

4

5

6

11:35:31 11:36:58 11:38:24 11:39:50 11:41:17 11:42:43 11:44:10 11:45:36 11:47:02 11:48:29 11:49:55Time

Req

uire

d Ti

me

sec

（）

0

5

10

15

20

25

30

Q F

acto

rPac

ket

Loss

、

Required Time ControlＱ

Over TakePacket LossBUBAScreen Noice

Experimental Result （ Streaming Video ）－ Q value fix （３）


Test Q Factor=Adaptive：

0

1

2

3

4

5

6

11:19:41 11:21:07 11:22:34 11:24:00 11:25:26 11:26:5311:28:19 11:29:46 11:31:12 11:32:38 11:34:05

Time

Req

uire

d Ti

me

sec

（）

0

5

10

15

20

25

30

Fac

tor

Pac

ket

Loss

Ove

r Ta

keＱ

、、

Required TimeQ ControlOver TakePacket LossBUBAScreen Noice

Experimental Result （ Streaming Video ）－Adaptive Control


0

100

200

300

400

500

600

700

800

900

1000

305 315 325 335 345receive time [sec]

time

[ms]

0

1

2

3

4

5

bitr

ate

[10k

bps]

, pa

cket

loss

jitterbitratepacket loss

Experimental Result （ Soft Phone ）－ fixed high encode rate


0

100

200

300

400

500

600

700

800

900

1000

285 295 305 315 325receive time [sec]

time

[ms]

0

1

2

3

4

5

bitr

ate

[10k

bps]

, pa

cket

loss

jitterbitratepacket loss

Experimental Result （ Soft Phone ）－ Adaptive encode rate Control



【 What is required to widespread IEEE 802.21 for multi-mode terminal 】

If developers still need to control link layer of each radio networks , I wonder if they are reluctant to implement IEEE 802.21 since they can realize effective handover without IEEE 802.21 and the cost of implementing IEEE 802.21 is the matter.

We should give IEEE 802.21 value added. We should bring out the potentiality of MIHF to connect multiple MIH

users organically with link layer and themselves. If MIH user like application can know the fluctuation of abstracted L2

information (uplink/downlink) such as available bandwidth, delay , jitter as well as exact timing of handover start/complete or handover preparation via MIHF , it can maintain or enhance a quality at any time rather than only during handover.

MIH user sometimes needs information concerning network mobility protocol rather than L2 information.

e.g. BU/BA signaling is notified to application via MIHF.MIH needs to do QoS control to multiple applications.



【 What we modified or extended 】 MIH User ID is added so MIHF can communicate with multiple MIH users. We defined abstracted L2 information (Available Bandwidth)

uplink/downlink respectively between MIH users and MIHF rather than QoS such as throughput , delay and jitter.

MIHF calculates each available bandwidth to multiple MIH users from multiple L2 information. (QoS control of bandwidth)

MIHF has a role to take a measurement of actual delay and jitter between peer MIHF.( ideally end-to-end )

MIHF transfers BU( Binding Update)/BA( Binding Ack) to application as exact timing of handover start/complete responding to a request from application.

MIHF also notifies discarded packets by MR or HA to application as packet loss information due to protocol.

We extended RA by which MIHF of MNN can discover MIHF of MR and register it as well as getting IPv6 address.

Documents

Kyocera Corporation Enhance radio network connectivity and maintain a Quality of IP service application Proposal of extension of IEEE 802.21 2008/7/16