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
3Yokohama R&D Center
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.
Background of a research
4Yokohama R&D Center
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.
Background of a research
5Yokohama R&D Center
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.
Background of a research
6Yokohama R&D Center
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.
Background of a research
7Yokohama R&D Center
MIHF
Link Layer
802.16e 802.11 3G
MIP Handover Manager
TCP
Application1 Application2
Background of a research
8Yokohama R&D Center
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
9Yokohama R&D Center
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
10Yokohama R&D Center
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
11Yokohama R&D Center
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
12Yokohama R&D Center
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
13Yokohama R&D Center
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
14Yokohama R&D Center
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
15Yokohama R&D Center
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
16Yokohama R&D Center
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)
17Yokohama R&D Center
Mobile Router
SoftPhone
StreamingClient
NEMO /Handover Manager
MIHF
iBurst / EVDO
StreamingClient
MIHF
SoftPhone
MIHF
Experiment (Protocol Stack)
18Yokohama R&D Center
【 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
19Yokohama R&D Center
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
20Yokohama R&D Center
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
21Yokohama R&D Center
【 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
22Yokohama R&D Center
【 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
23Yokohama R&D Center
Test Factor= (fix):Q 3
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 ControlQ
Over TakePacket LossBUBAScreen Noice
Experimental Result ( Streaming Video )- Q value fix (3)
24Yokohama R&D Center
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
keQ
、、
Required TimeQ ControlOver TakePacket LossBUBAScreen Noice
Experimental Result ( Streaming Video )-Adaptive Control
25Yokohama R&D Center
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
26Yokohama R&D Center
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
27Yokohama R&D Center
Discussion of an extension of IEEE 802.21
【 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.
28Yokohama R&D Center
Discussion of an extension of IEEE 802.21
【 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.
Top Related