CJKTest-bed

CJKTest-bed

CJK test-bed studyPerformance measurements of RTP/RTCP based services

15th NGN-WG 　 2009.4.8-10Test-bed Ad-hoc Group

Hideaki YAMADA 　 KDDI (KDDI R&D Labs.)

hd-yamada@kddi.comTEL: +81 49 278 7356, FAX: +81 49 278 7510

2

Topics

Background Preparations- Study phases (Study scenarios)- Measurement points

Performance measurementStandardization-Y.2173 :Management of Performance Measurement(MPM)-RACF and MPM communications

3

Background

1) Estimation of QoE from QoS 　　　　　　　　　

Effective utilization of network resources considering the QoE

Service platform for MoIP based on the end-to-end QoE in FMBC (Fixed Mobile & Broadcast Convergence) all-IP networks

2) Dynamic session controls of MoIP services in FMBC all-IP networks

4

CJK NGN Test-bed

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

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

Preparations - Study phases (Study scenarios) 1

5

China　(CCSA) Korea　(TTA) Japan　(TTC)

IP　Network C-K:　R&D　network C-J,　K-J:　Commercial　networks(or　R&D　network)

CPE for　Voice　over　IP

CPE　used　in　Phase　I&II　are　applicable •　Software　based　CPE　supporting　the　　RTCP　extensions　such　as　SR/RR/XR/HR

for　Video　over　IP

TBD TBD •　Hardware　based　CPE•　Support　RTCP　SR/RR/XR　video

Service　Platform Call　servers　used　in　Phase　I&II 1st　　Stage:　Call　server　emulator　(planning)2nd　　Stage:　IMS　

MPM MPM　(Software/Hardware)1st　Stage:　PC　based　MPM　provided　by　KDDI　R&D　labs.2nd　　Stage:　ATCA　based　MPM　(based　on　the　SBC　by　OKI　Electric)

RACF TBD In　preparation TBD

Preparations - Study phases (Study scenarios) 2

6

Japan (TTC)

Korea (TTA)

MPM (Router with mirror port and RTP translator)

China (CCSA)

CPE (PC with RTP/RTCP

terminal software)

CPE (RTP/RTCP terminal hardware)

MPM

SIP Server SIP Server

SIP Server

Scenario 6-3

Scenario 6-4, 7

CPE (PC with RTP/RTCP

terminal software)

CPE (RTP/RTCP terminal hardware)

CPE (PC with RTP/RTCP

terminal software)

CPE (RTP/RTCP terminal hardware)

MPM

Scenario 6-1

Scenario 6-2

RACF

RACF

RACF

Preparations - measurement points

7

Reference : ETSI TR 101 329-7 V2.1.1, February 2002.

The E-model rating called R-value (ITU-T G.107) against the intrinsic delay for a single MPLS network.

Performance measurement 1

8

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.

Figure 2: PESQ scores versus Jsds (standard deviation of packets’ jitters)

Performance measurement 2

Better quality

9

Transport stratum

Service stratum

ControlMediaManagement

ANI

Transport Control Functions

Resource　and　Admission

Control　Functions　

Network　AttachmentControl　Functions　

Network　AttachmentControl　Functions　

NNIUNI

Application Support Functions & Service Support Functions

Applications

Transport Functions

End-UserFunctions

OtherNetworks

Service ControlFunctions

Service　UserProfiles

Service　UserProfiles

Transport　User　Profiles

Transport　User　Profiles

MPM

MPMApplications

MPMIn

OtherNGNs

Overall architecture for NGN performance management

Standardization 1 Y.2173: Management of Performance Measurement (MPM)

10

Standardization 2 RACF and MPM communications

Figure1 Performance notification flow of MPMs

Figure 2 ITU-T Y.2111(RACF IF(Rm, Ri, Rh)

11

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.

Standardization 3 RACF and MPM communications (Rec. Y.2111 Revision 2 (Version 0.1.0))

12

Thank you for your kind attentions.

Q&A

This work is partly supported by the National institute of Information and Communications Technology (NICT).