This Contribution Proposes Modifying Unclear Or Inadequate Descriptions in the NGN-IMS-Based

Total Page:16

File Type:pdf, Size:1020Kb

This Contribution Proposes Modifying Unclear Or Inadequate Descriptions in the NGN-IMS-Based

INTERNATIONAL TELECOMMUNICATION UNION FOCUS GROUP ON IPTV TELECOMMUNICATION FG IPTV-C-1061 STANDARDIZATION SECTOR STUDY PERIOD 2005-2008 English only

WG(s): 1 7th FG IPTV meeting: Qawra, St Paul’s Bay, Malta, 11-18 December 2007 CONTRIBUTION Source: NTT Corporation Title: Proposal to modify NGN/IMS IPTV call flow of IPTV Architecture document Abstract This contribution proposes modifying unclear or inadequate descriptions in the NGN-IMS-based VoD service call flow in Appendix I.4.1 of the IPTV Architecture document (FG IPTV-DOC- 0148).

1 Introduction The IPTV Architecture document FG-IPTV-doc-0148, which was developed at the 6th FG-IPTV meeting (15-19 October, Tokyo, Japan), describes the call flow of an NGN IMS-based VoD service in Appendix I.4.1. This call flow has several places that need revision such as the absence of network resource reservation steps, SIP INVITE message parameters, etc.

2 Discussion In the NGN IMS-based VoD service call flow in Appendix I.4.1, the following are considered to have some problems: 1. CDCF and CD&SF are described in this flow as functional elements. This is unclear because CDCF is an internal function of CD&SF, as shown by Figure 9-6. 2. Regarding steps from 1) to 3), information about bandwidth and codec are needed for SIP INVITE. This should be described clearly. 3. Network resource reservation and allocation steps are required between Core IMS and RACF in order to reserve transport resources for content control and content delivery. This should be added. 4. Regarding steps 6) and 7), in this case the On-demand Application corresponds to B2BUA. An On-demand Application is required to send a Service Request to Core IMS after interaction with CDCF. 5. Steps 8) and 9) are inappropriate because there is no interface between an On-Demand Application and CD&SF. CD&SF should interact via Core IMS.

Contact: Hideo Imanaka Tel: +81 422-59-4011 NTT Corporation Fax: +81 422-60-7547 E-mail: [email protected] Japan Yukiyo Seki Tel: +81 422-36-7565 NTT Corporation Fax: +81 422-37-7966 Japan E-mail: [email protected] Attention: This is a document submitted to the work of ITU-T and is intended for use by the participants to the activities of ITU-T's Focus Group on IPTV, and their respective staff and collaborators in their ITU-related work. It is made publicly available for information purposes but shall not be redistributed without the prior written consent of ITU. Copyright on this document is owned by the author, unless otherwise mentioned. This document is not an ITU-T Recommendation, an ITU publication, or part thereof. - 2 - FG IPTV–C–1061

3 Proposal This contribution proposes the following modifications to improve the above issues by eliminating ambiguity and describing minimum steps for providing VoD services.

1. Remove CDCF and leave only CD&SF. 2. Describe the bandwidth and codec information in SIP INVITE. Specific proposals are to add these parameters in step 1) and remove parenthetic text or to add “etc.” to step 2) and later steps. 3. Remove steps 3) and 4) “Get current ITF location” because these steps between Core IMS and NACF are described as examples. 4. Add steps for network resource reservation and allocation between Core IMS and RACF. This process should be divided to two stages. The first is only for reservation and next is for actual allocation of network resources. This is because if these steps are done at once, problems may occur if there are not enough allocable resources. 5. Replace sequences in order to solve issues 4 and 5 of above Discussion section.

On- IPTV Core IMS Demand CD&SF RACF TF Application 1) ITF acquisition of service parameters, e.g., Content identifier, logical URL of a content item, bandwidth, codec etc.

2) Service Request

5) Resource Request Resource Reservation 6) Resource Response 7) Service Request

Service authorization, etc 8) Service Request

9) Service Request

10) Service Response 11) Service Response 12) Service Response 13) Resource Request Resource Allocation 14) Resource Response 15) Service Response 16) Establishment of content control channel and content delivery channel Delivery of media content

Figure I-13: VoD service call flows.

Pre Conditions: Provisioning and, network attachment has been completed. - 3 - FG IPTV–C–1061

1. The IPTV Terminal obtains the Content Identifier, logical URL, bandwidth, and codec information for a content item that the customer wishes to receive. It This may be achieved by interaction with the Program Guide Function, or by other means. In this step, the IPTV Terminal may establish a content control channel and obtain content delivery parameters such as bandwidth, codec, etc. by using content control messages. 2. The ITF initiates a service request with Content Identifier and logical URL to the Core IMS. and 3-4. The Core IMS determines the location of the IPTV Device, for example by querying the NACF. Note: Figure I-13 does not describe these sequences because they are examples. 5. The Core IMS sends a resource request to RACS to reserve transport resources for content control and content delivery. 6. The RACF performs transport resource reservation and sends the service response to the Core IMS. 7. The Core IMS forwards the service request to the On-Demand IPTV Application Function to perform service authorization etc with the location information, content identifier and the logical content URL to the Content Delivery Control Function. 8. The On-Demand IPTV Application Function performs service authorization. If the UE is allowed to access the content, the On-Demand IPTV Application Function forwards the service request to the Core IMS. 9. The Core IMS forwards the service request to the CD&SF. 10. The CD&SF sends the service response to the Core IMS. 11. The Core IMS forwards the service response to the On-Demand IPTV Application Function. 12. The On-Demand IPTV Application Function returns the service response to the Core IMS. 13. The Core IMS sends a resource request to the RACF to allocate transport resources. 14. The RACF performs transport resource allocation and sends the resource response to the Core IMS. 15. The Core IMS sends the service response to the IPTV Terminal. 16. The ITF connects to the identified Content Delivery& Storage FunctionCD&SF to receive the content.

______

Recommended publications