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

2. 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. Yokohama R&D Center 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. Yokohama R&D Center 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. Yokohama R&D Center 5 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

6. Yokohama R&D Center 6 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

7. Yokohama R&D Center 7 MIHF Link Layer 802.16e802.113G MIPHandover Manager TCP Application1Application2 Background of a research

8. Yokohama R&D Center 8 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

9. Yokohama R&D Center 9 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

10. Yokohama R&D Center 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. Yokohama R&D Center 11 handoverd (MIH User) MIHd (MIH Function) iBurstd Link library iBurst UTD every 500ms 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. response MIH_HandoverComplete. Response start ppp for EVDO Change Network MIH_Get_Status.request Link_Get_Parameters.request EVDO DM port Link_Get_Parameters.confirm MIH_Get_Status.confirm System flow

12. Yokohama R&D Center 12 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

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

14. Yokohama R&D Center 14 casepacket lossdelay(ms) (1) NEMO + MCoA + 802.2100 (2) NEMO + 802.2133350 (3) NEMO + only LinkDown84716900 (4) NEMO only7338142000 (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. Comparison with other Scenarios

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

16. Yokohama R&D Center 16 Experiment (Functional Configuration)

17. Yokohama R&D Center 17 Experiment (Protocol Stack)

18. Yokohama R&D Center 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. Yokohama R&D Center 19 Process Flow 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

20. Yokohama R&D Center 20 Summary of Rate control by streaming

21. Yokohama R&D Center 21 【 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

22. Yokohama R&D Center 22 【 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

23. Yokohama R&D Center 23 Experimental Result （ Streaming Video ）－ Q value fix （３）

24. Yokohama R&D Center 24 Experimental Result （ Streaming Video ）－ Adaptive Control

25. Yokohama R&D Center 25 Experimental Result （ Soft Phone ）－ fixed high encode rate

26. Yokohama R&D Center 26 Experimental Result （ Soft Phone ）－ Adaptive encode rate Control

27. Yokohama R&D Center 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. Yokohama R&D Center 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.