CJK test-bed study Service control based ｏｎ MPM-RACF communications Test-bed Ad-hoc Group Hideaki YAMADA, Norihiro FUKUMOTO KDDI (KDDI R&D Labs.)

2 China (CATR)Korea (TTA)Japan (TTC) IP NetworkC-K: R&D networkC-J, K-J: Commercial networks (or R&D network) CPEfor Voice over IP CPE used in Phase I&II are applicable Software based CPE supporting the RTC P extensions such as SR/RR/XR/HR for Video over IP TBD Hardware based CPE Support RTCP SR/RR/XR video Service PlatformCall servers used in Phase I&IIIMS MPMMPM (Software/Hardware) PC based MPM and ATCA based MPM (by OKI) RACFTBDIn preparationTBD Performance measurement

3 Report of evaluations – Study phases CJK NGN Test-bed Phase I: rd /4 th Quarter (Completed) - Network Connectivity - Scenario 2 and 4 only (2 CS and 2 domains) Phase II: st /2 nd Quarter (Completed) - Scenario 1, 3 (simpler version of 2 and 4, single domain) and 5 Phase IV: rd ~ nd Quarter On going / In preparation - Performance Evaluation of RTP/RTCP-based MoIP and IPTV services - Performance Monitoring Scenarios 6-3 and Initial RACF Interoperability testing : Scenario 7 - Testing of RACF and RTP/RTCP-based MPM Interactions Coming Tests - IPTV Interoperability testing - Admission Control Device testing We are here

4 Report of evaluations – Improved network configuration

5 The RTP/RTCP based passive measurement Delay and delay-variation are important to ral-time applications such as VoIP and video streaming. Real time protocol, [IETF RFC 3550]) is a transport layer protocol for real-time applications. RTP is designed to be independent of transport or network layer protocols. An RTP packet has time-stamp and sequence-number fields in its header. A passive collection system which resides in either TEs or BGs can evaluate packet loss and delay variation. RTCP is an optional control protocol for RTP. Furthermore, RTCP extensions, such as the RTCP ‑ XR (RTP control protocol extended reports, [b-IETF RFC 3611]) are also optional control protocols for RTP. Participating TEs exchange RTCP and RTCP-XR packets. In a RTCP and RTCP-XR packet, performance metrics of its application services are reported. TEs also are able to evaluate rough round-trip delay with these packets. Figure Configuration of the measurement points.

6 Standardization RACF and MPM communications (Rec. Y.2111 Revision 2) A new reference point called Rm between RACF and MPM in Rec. Y.2111 was added. Several specifications of Rm are based on Rc ones. Figure Generic resource and admission control functional architecture.

7 Standardization RACF and MPM communications (Rec. Y.2111 Revision 2) Figure 2 Performance notification between TRC-FE and MPM- FE based on the communications of multiple MPMs Figure 1 Performance notification between TRC-FE and MPM-FE Performance notification between TRC-FE and MPM-FE

8 A use case for RACF-MPM communications Figure 1 Autonomous traffic control based on the MPM function Figure Autonomous traffic control based on the MPM function The RACF controls services based on the QoS/QoE notifications both of the terminal-side MPM and the network-side MPM. The MPMs between the terminal and the network node control the traffic between them and, at the same time, MPMs notify the updated terminal side QoS/QoE information to RACF.

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