21-08-0201-01-0000-experimental-result_proposal
Enhance radio network connectivity and
maintain a Quality of IP service application
Proposal of extension of
IEEE 802.21
Kyocera Corporation
2008/7/16
Kyocera Yokohama 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
Yokohama R&D Center
2
Background of a research
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.
Yokohama R&D Center
3
Background of a research
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.
Yokohama R&D Center
4
Background of a research
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.
Yokohama R&D Center
5
Background of a research
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.
Yokohama R&D Center
6
Background of a research
Application1
Application2
TCP
MIP
Handover Manager
MIHF
Link Layer
802.16e
802.11
3G
Yokohama R&D Center
7
Objective of a research
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.
Yokohama R&D Center
8
Concept 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.
Yokohama R&D Center
9
Topics of previous experiment 2006
 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.0
 VoIP clients communicates via the MR without any
packet loss during the handover
Yokohama R&D Center
10
System flow
handoverd
(MIH User)
every
500ms
MIHd
(MIH Function)
iBurstd
EVDOd
Link library iBurst UTD EVDO DM port
MIH_Get_Status.request Link_Get_Parameters
.request
MIH_Get_Status.request
Link_Get_Parameters
.request
MIH_Get_Status.confirm
Link_Get_Parameters
.confirm
Link_Get_Parameters
.confirm
MIH_Get_Status.confirm
Threshold 1
MIH_Handover_Prepare
.request
Link_UP.Request
start ppp
for EVDO
Link_UP.indication
MIH_Handover_Prepare
.confirm
Threshold 2
MIH_Switch
Change
Network
MIH_Commit.request
MIH_HandoverComplete.
Request
Link_Teardown.request
MIH_HandoverComplete.
Response
Link_Teardown.
response
Yokohama R&D Center
11
Change of L2 RSSI
①
③
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).
Yokohama R&D Center
12
The VoIP trace on MNN
handover from
iBurst to EVDO
no packet loss at the VoIP traffic
RTP packet sequence error)
RTP packet arrival time (second)
The jitter became bigger
because of the bad link quality
time(second)
Yokohama R&D Center
13
Comparison with other Scenarios
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/BA+ 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
timeout.
Yokohama R&D Center
14
Experiment (Network Configuration)
IPv6
IPv4
IPv6
Kyocera Corp.
Yokohama
IP
Cloud
HRPD
Streaming
Client
Streaming
Server
Mobile Router
SoftPhone
SoftPhone
Home Agent
Keio University
iBurst
iBurst: ANSI ATIS HC-SDMA
IEEE 802.20 625k MC Mode
Yokohama R&D Center
15
Experiment (Functional Configuration)
Rate
H/O Info
Rate
MNN
Streaming
Client
Soft Phone
Rate
Control
Rate Control
Rate
H/O Thresh Rate
Buffer
Control
H/O
Information
MR
Streaming
Server
Soft Phone
Rate
Buffer
Control
Control
NEMO
Rate
Control
H/O
Information
IEEE 802.21
(MIHF)
H/O
L2
Thresh
Information
H/O
Information
Rate
IEEE 802.21 (MIHF)
Internet
HA
Handover
iBurst
HRPD
Yokohama R&D Center
16
Experiment (Protocol Stack)
NEMO /
Handover Manager
Streaming
Client
MIHF
MIHF
iBurst / EVDO
SoftPhone
MIHF
Streaming
Client
Mobile Router
SoftPhone
Yokohama R&D Center
17
Adaptive Control by Video
 Streaming
【Subject】
– Radio conditions becomes worse
→ available bandwidth decreases
→ block noise, image stiffness
Start
Goal
 【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 better
 Change to higher rate and enjoy better quality
Yokohama R&D Center
18
Process Flow
Notify Min required bandwidth for handover
NEMO
Streaming
Client
802.21
802.21
iBurst / EVDO
・Direct to notify
if threshold of
SoftPhone
available bandwidth becomes
200kbps ,300kbps
・Requestsoofon.
the current available
 Use Handover
802.21threshold
bandwidth.
Streaming
Client
Mobile Router
・ Direct to notify if threshold of
available bandwidth becomes
500kbps ,300kbps,100Kbps.
SoftPhone
Yokohama R&D Center
19
Summary of Rate control by streaming
Begin at 600kbps
Radio State
Higher than
300kbps
IEEE 802.21 Threshold
Lower than
500kbps
Info
Notify threshold event
Streaming
Client
Animation
Play Rate
Set the suitable
Rate
Animation play
start
Yokohama R&D Center
20
Adaptive Control by Soft Phone – Encode Rate Control
【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
Yokohama R&D Center
21
Adaptive Control by Soft Phone – jitter buffer Control
【Subject 2】
Internet
30ms
Delay is different every
radio network
5
2
1
4 3
→ Gap of receive packet
during handover
MNN
Soft Phone
180ms
→ Voice comes out
MR
5
4
3
2
Delay difference
150ms
1
Receive Time
【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.
Yokohama R&D Center
22
Experimental Result（Streaming Video）－Q value fix（３）
Test：Ｑ Factor=３(fix)
6
Required Time（sec）
5
4
30
25
20
3
15
2
10
1
5
0
0
Q Factor、Packet Loss
Required Time
Ｑ Control
Over Take
Packet Loss
BU
BA
Screen Noice
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:55
Time
Yokohama R&D Center
23
Experimental Result（Streaming Video）－Adaptive Control
Test：Q Factor=Adaptive
6
Required Time（sec）
5
30
25
4
20
3
15
2
10
1
5
0
0
Ｑ Factor、Packet Loss、Over Take
Required Time
Q Control
Over Take
Packet Loss
BU
BA
Screen Noice
11:19:41 11:21:07 11:22:34 11:24:00 11:25:26 11:26:53 11:28:19 11:29:46 11:31:12 11:32:38 11:34:05
Time
Yokohama R&D Center
24
Experimental Result（Soft Phone）－fixed high encode rate
1000
5
800
4
jitter
bitrate
packet loss
time [ms]
700
600
3
500
400
2
300
200
1
bitrate [10kbps] , packet loss
900
100
0
0
305
315
325
receive time [sec]
Yokohama R&D Center
335
345
25
Experimental Result（Soft Phone）－Adaptive encode rate Control
5
jitter
bitrate
packet loss
900
800
4
time [ms]
700
600
3
500
400
2
300
200
1
bitrate [10kbps] , packet loss
1000
100
0
0
285
295
305
receive time [sec]
Yokohama R&D Center
315
325
26
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.
Yokohama R&D Center
27
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.
Yokohama R&D Center
28