CJK test-bed study Performance measurements of RTP/RTCP based services

1. CJK test-bed study Performance measurements of RTP/RTCP based services • 15thNGN-WG2009.4.8-10 Test-bed Ad-hoc Group • Hideaki YAMADAKDDI (KDDI R&D Labs.) • hd-yamada@kddi.com • TEL: +8149 2787356, FAX: +8149 278 7510

2. Topics • Background • Preparations - Study phases (Study scenarios) - Measurement points • Performance measurement • Standardization -Y.2173:Management of Performance Measurement(MPM) -RACF and MPM communications

3. Background 2) Dynamic session controls of MoIP services in FMBC all-IP networks 1) Estimation of QoE from QoS Service platform for MoIP based on the end-to-end QoE in FMBC (Fixed Mobile & Broadcast Convergence) all-IP networks Effective utilization of network resourcesconsidering the QoE

4. Preparations - Study phases (Study scenarios)1 • Phase I: 2006 3rd/4th Quarter (Completed) • Network Connectivity • Scenario 2 and 4 only (2 CS and 2 domains) • Phase II: 2007 1st/2nd Quarter(Completed) • Scenario 1, 3 (simpler version of 2 and 4, single domain) and 5 CJK NGN Test-bed • Phase IV: 2008 3rd ~ 2009 2nd Quarter • Performance Evaluation of RTP/RTCP-based MoIP and IPTV services • Performance Monitoring Scenarios 6-3 and 6-4 • Initial RACF Interoperability testing : Scenario 7 • Testing of RACF and RTP/RTCP-based MPM Interactions • IPTV Interoperability testing

5. Preparations - Study phases (Study scenarios)2

6. Preparations -measurementpoints

7. Performance measurement 1 The E-model rating called R-value (ITU-T G.107) against the intrinsic delay for a single MPLS network. Reference : ETSI TR 101 329-7 V2.1.1, February 2002.

8. Performance measurement 2 A result of the PESQ(Perceptual Evaluation of Speech Quality) score versus the Jsd value which is a statistical factor of VoIP packets called standard deviation of jitters. The codec type is the ITU-T G.711 with no packet loss. Better quality Figure 2: PESQ scores versus Jsds (standard deviation of packets’ jitters)

9. Standardization1 Y.2173:Managementof Performance Measurement (MPM) Overall architecture for NGN performance management

10. Standardization 2 RACF and MPM communications Figure 2 ITU-T Y.2111(RACF IF(Rm, Ri, Rh) Figure1 Performance notification flow of MPMs

11. Standardization 3 RACF and MPM communications (Rec. Y.2111 Revision 2 (Version 0.1.0)) • 6.6 Resource control and scenarios for RACF and MPM communications • It is recommended to support a communication between RACF and MPM under the following situations: • In the NGN transport network, abnormal situations where such as congestion, packet loss, and delay can occur despite of bandwidth resource availability due to various reasons. The causes can be physical such as link failure and system down or due to logical network failure (.e.g., routing loop), logical like routing loop. The physical failure can be reported to the RACF so that it can take appropriate actions during the admission decision process. However, the logical failure can’t be reported to RACF under current architecture. This will results in the inefficient or even wrong admission decision because RACF depends mainly on the topology and bandwidth resource information for its decision making. Thus, some additional performance information besides bandwidth such as delay, delay variation, and packet loss will help to make more accurate admission decision when such logical failure situation occurs.. • In normal situation, in addition to bandwidth, network policy rules, and subscription information, performance information such as delay, delay variation, and packet loss may still be needed when RACF makes admission decision. • Upon receipt of an explicit request from SCF including an indication of specific performance monitoring, RACF can communicate with MPM to perform the request and receives status reports of the requested performance monitoring.

12. Thank you for your kind attentions. Q&A This work is partly supported by the National institute of Information and Communications Technology (NICT).