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

1. 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 2008/7/16 Kyocera Yokohama R&D Center

2. Background of a research • Objective of a research • Concept of a research • Summary of an experiment • Discussion of an extension of IEEE 802.21

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

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

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

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

7. Background of a research Application1 Application2 TCP MIP Handover Manager MIHF Link Layer 802.16e 802.11 3G

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

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

10. 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 Topics of previous experiment 2006

11. System flow handoverd (MIH User) MIHd (MIH Function) EVDO DM port iBurst UTD Link library iBurstd EVDOd every 500ms MIH_Get_Status.request Link_Get_Parameters .request MIH_Get_Status.request Link_Get_Parameters .request Link_Get_Parameters .confirm MIH_Get_Status.confirm Link_Get_Parameters .confirm MIH_Get_Status.confirm Threshold 1 Link_UP.Request start ppp for EVDO MIH_Handover_Prepare .request Link_UP.indication MIH_Handover_Prepare .confirm Threshold 2 Change Network MIH_Switch MIH_Commit.request MIH_HandoverComplete. Request Link_Teardown.request Link_Teardown. response MIH_HandoverComplete. Response

12. 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).

13. The VoIP trace on MNN handover from iBurst to EVDO no packet loss at the VoIP traffic RTP packet arrival time (second) RTP packet sequence error) The jitter became bigger because of the bad link quality time(second)

14. Comparison with other Scenarios See the previous two slides. 0 packet loss! The case without MCoA support. The delay is caused by RTT of BU/BA. The case only with LinkDown event. The delay is about RTT of BU/BA+ Link Preparation. The simple NEMO case: Neither L2 indication nor MCoA. The MR didn’t aware of the link down before the PPP session timeout.

15. Experiment (Network Configuration) IPv6 IPv4 IPv6 iBurst: ANSI ATIS HC-SDMA IEEE 802.20 625k MC Mode

16. Experiment (Functional Configuration)

17. Experiment (Protocol Stack)

18. 【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 better Change to higher rate and enjoy better quality Adaptive Control by Video Streaming

19. Process Flow Notify Min required bandwidth for handover ・Direct to notify if threshold of available bandwidth becomes 200kbps ,300kbps so on.  Use Handover threshold ・Request of the current available bandwidth. ・ Direct to notify if threshold of available bandwidth becomes 500kbps ,300kbps,100Kbps.

20. Summary of Rate control by streaming

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

22. Adaptive Control by Soft Phone – jitter buffer 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.

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

24. Experimental Result（Streaming Video）－Adaptive Control

25. Experimental Result（Soft Phone）－fixed high encode rate

26. Experimental Result（Soft Phone）－Adaptive encode rate Control

27. 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.

28. 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.