Kyocera Corporation Enhance radio network connectivity and maintain a Quality of IP service application Proposal of extension of IEEE /7/16 Kyocera Yokohama R&D Center experimental-result_proposal

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

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

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 is very useful to realize effective handover but possible without it. Background of a research

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

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

Yokohama R&D Center 7 MIHF Link Layer e G MIPHandover Manager TCP Application1Application2 Background of a research

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

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

Yokohama R&D Center 10 Keio/WIDE and Kyocera have designed and implemented a MR which is capable of NEMO + MCoA The MR performs the make-before-break handover with MCoA and triggers the handover by 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

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

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

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

Yokohama R&D Center 14 casepacket lossdelay(ms) (1) NEMO + MCoA (2) NEMO (3) NEMO + only LinkDown (4) NEMO only (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

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

Yokohama R&D Center 16 Experiment (Functional Configuration)

Yokohama R&D Center 17 Experiment (Protocol Stack)

Yokohama R&D Center 18 【 Subject 】 –Radio conditions becomes worse → available bandwidth decreases → block noise, image stiffness 【 Solution 】 Obtain available bandwidth via 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

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

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

Yokohama R&D Center 21 【 Subject 1 】 Radio State becomes worse →Available bandwidth becomes lower →Voice comes out 【 Solution 】 Obtain available bandwidth by 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

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

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

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

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

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

Yokohama R&D Center 27 Discussion of an extension of IEEE 【 What is required to widespread IEEE 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 since they can realize effective handover without IEEE and the cost of implementing IEEE is the matter. We should give IEEE 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 28 Discussion of an extension of IEEE 【 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.