Scope
Upcoming SlideShare
Loading in...5
×
 

Scope

on

  • 742 views

 

Statistics

Views

Total Views
742
Views on SlideShare
742
Embed Views
0

Actions

Likes
0
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Scope Scope Document Transcript

  • INTERNATIONAL TELECOMMUNICATION UNION STUDY GROUP 13 TELECOMMUNICATION STANDARDIZATION SECTOR TD 206 (WP 3/13) STUDY PERIOD 2005-2008 English only Original: English Question(s): 2/13 Geneva, 17-28 July 2006 TEMPORARY DOCUMENT Source: Rapporteur Q.2/13 Title: Provisional text of draft new ITU-T Recommendation Y.ngn-mcastsf – Kobe, 22-27 April 2006 TSB Note: the complete document is available in soft copy only Editor’s Note: This document was developed during the Q.2/13 Rapporteur group meeting in Kobe from 22 April to 27 April 2006 based on TD 171(3/13) of January 2006 SG13 meeting. This output text reflects the proposals from KOBE-Q02/13-028R1-LATE and KOBE-Q.2/13-034: KOBE-Q02/13-028R1-LATE proposing „the NGN multicast service requirements for one-to-many multicast service‟ and KOBE-Q.2/13-034 proposing „functional requirements for the interface between SCF and PD-FE at the service stratum.‟ This update has to be considered provisional as it was not reviewed for lack of meeting time. It constitutes a major input for developing the next version of this draft Recommendation. Contact: Marco Carugi Tel: +33 1 6955 7027 Nortel Networks Europe Fax: +33 1 6955 3115 UK Email marco.carugi@nortel.com Attention: This is not a publication made available to the public, but an internal ITU-T Document intended only for use by the Member States of ITU, by ITU-T Sector Members and Associates, and their respective staff and collaborators in their ITU related work. It shall not be made available to, and used by, any other persons or entities without the prior written consent of ITU-T.
  • -2- TD 206 (WP 3/13) NGN Multicast Service Framework Justification of this recommendation:  NGN should support various application services over convergence network, which consists of wired, wireless, best-effort, and QoS guaranteed network. Among the considerable NGN services, NGN multicast service is one of the important services. The examples of NGN multicast services are IPTV service, private live radio/video broadcasting service, bi- directional multimedia conference service, commercial/non-commercial advertisement service, real-time data dissemination (traffic-information, weather-broadcast) service but are not limited to.  The requirements of those services may vary according to the characteristics of each multicast services such as; the way of communication, the required QoS, the size of group and so on. To make matters worse, the network capabilities to support multicast services are greatly differ from each other. To overcome those complexity, which arises from the different service requirements and the network capabilities, a framework for NGN multicast service is highly needed to be defined.  The NGN multicast service framework will deal with the following items to guide NGN multicast services; - Terminology for NGN multicast, - NGN multicast service concept, - Multicast service definitions and reference models, - Group concept for NGN multicast service, - NGN multicast QoS, - NGN multicast service manager, - Etc.
  • -3- TD 206 (WP 3/13) Summary <Mandatory Material> Editor’s Note: To be provided Keywords <Optional> Editor’s Note: To be provided Introduction There are various emerging NGN services that require multicast capabilities in service and /or transport stratum. The transport stratum includes several network technologies such as MPLS, Ethernet, PON, Wibro etc. These different network technologies may provide different multicast related capabilities that can be used by different multicast services. Therefore, an efficient way of developing Recommendations can be using a modular approach, considering various service types and network technologies. The following figure summarizes these concepts for NGN multicast related work. NGN multicast services framework i) “NGN multicast services framework” Service stratum ii) “Requirements and service architecture for NGN multicast services” File Video Internet ... Network IPTV disseminat converence streaming games -ion Transport stratum iii) “Network capabilities for NGN multicast services” Gigabit MPLS Wibro ... PON Ethernet Figure 1 – Conceptual NGN multicast service blocks i) “NGN multicast services framework”
  • -4- TD 206 (WP 3/13) It may provide basic concepts of NGN multicast services, terminology, multicast service model, etc. It may be used to drive development of other recommendations regarding specific multicast related services as well as multicast capabilities for various network technologies. ii) “Requirements and service architecture for NGN multicast services” It may be necessary to describe requirements and service architecture for individual emerging NGN services, such as IPTV, multimedia conference, bulk file dissemination, which require multicast capabilities. Based on this approach, various recommendations can be developed according to the market requirements. Requirements and service architecture for IPTV is one possible candidate to be developed. iii) “Network capabilities for NGN multicast services” The network capabilities to provide various NGN multicast services may be identified for different network technologies. One example is the draft Y.ngn-mcast which includes NGN multicast service capabilities for MPLS with QoS support. The present document is provided as initial draft for NGN multicast services framework.
  • -5- TD 206 (WP 3/13) CONTENTS 1. Scope ............................................................................................................................................ 6 2. References .................................................................................................................................... 6 3. Definitions and abbreviations ...................................................................................................... 6 4. Terminology of NGN multicast services ..................................................................................... 6 5. Concept of Group for NGN multicast service ............................................................................. 6 5.1. Definitions of relevant group characteristics ................................................................................................... 7 5.2. Communication Phases for NGN multicast service ......................................................................................... 7 6. QoS aspects of NGN multicast services ...................................................................................... 8 6.1. Levels of QoS agreement ................................................................................................................................. 8 6.2. QoS negotiation ............................................................................................................................................... 8 7. General requirements for NGN multicast services ...................................................................... 9 7.1. Functional requirements for group management ............................................................................................. 9 7.2. Functional requirements for data delivery ....................................................................................................... 9 7.3. Functional requirements for management ..................................................................................................... 10 8. NGN multicast service architecture ........................................................................................... 10 8.1. Multicast requirements at the service stratum ............................................................................................... 11 8.2. Multicast requirements at the transport stratum ............................................................................................. 11 8.3. Multicast requirements of end-user functions................................................................................................ 12 8.4. Multicast requirements of management functions ......................................................................................... 12 9. Transport capabilities for NGN multicast services .................................................................... 13 9.1. IP multicast approach .................................................................................................................................... 13 9.2. Overlay multicast approach ........................................................................................................................... 13 9.3. Hybrid approach ............................................................................................................................................ 14 10. NGN multicast service manager function .................................................................................. 14 10.1. Multicast Capability at the Service Stratum in NGN ..................................................................................... 15 10.2. Multicast Topologies for Multicast Function at the Service Stratum in NGN ............................................... 15 10.3. Control Messages for Service Level Multicast .............................................................................................. 16 10.4. Functional Architecture for Multicast Function at the Service Stratum ........................................................ 16 10.5. Functional Requirements for the Interface between SCF and PDF for Multicast Function at the Service Stratum 19
  • -6- TD 206 (WP 3/13) 1. Scope This Recommendation defines the basic concepts of NGN multicast service, terminology, multicast service model, and relevant issues. It will be used to drive development of other recommendations regarding specific multicast related services, as well as multicast capabilities for various network technologies. Editor’s Note: Contributions are requested to progress this text. 2. References [1] ITU-T Recommendation X.605 (1998) | ISO/IEC 13252:1999, Information technology – Enhanced Communications Transport Service definition. [2] ITU-T Recommendation X.601 (2000), Information technology – Multi-peer communications framework. [3] ITU-T FGNGN Document, Functional Requirements and Architecture for Resource and Admission Control in Next Generation Network, Draft TR-RACF, FGNGN-OD-241, December 2005, London. Editor’s Note: to be completed 3. Definitions and abbreviations Editor’s Note: to be completed 4. Terminology of NGN multicast services Editor’s Note: This section will deal with terminology used to describe NGN multicast services. The terminologies will follow existing ITU-T recommendations. This Recommendation uses the following terms (Editor‟s note: to be completed). - Group: - Multicast group: - Registered group: - Enrolled group: - Active group: This Recommendation newly defines the following terms. - (to be added) 5. Concept of Group for NGN multicast service Editor’s Note: This section will describe a general concept of group, which can be applied to NGN multicast service. The concept described here will be adopted from existing ITU-T recommendation.
  • -7- TD 206 (WP 3/13) 5.1. Definitions of relevant group characteristics Editor’s Note: This section will describe the definitions of group, which is necessary to provide NGN multicast service. 5.1.1. Undefined Group A group is a set of multicast service users using NGN multicast service. 5.1.2. Defined group A multicast group is a set of multicast service users that abide by appropriate group-membership criteria, or a set of rules for belonging to a group able to utilize multicast services. 5.1.3. Registered group: A registered group is a set of multicast group members, which has expressed implicitly or explicitly to the group manager that they have the intention to be a member of enrolled-group. A group manager collects peer names and addresses of registered group members. 5.1.4. Enrolled group: An enrolled group is a set of registered group members to which a group address is assigned. An enrolled group is actually in the position to be reached by means of a group address. 5.1.5. Active group: An active group is a set of enrolled group members that has entered the multicast data transfer phase, satisfying the group-characteristics requirements. 5.2. Communication Phases for NGN multicast service Figure 2 shows the state transition diagram of a group member. Undefined Define criteria Remove criteria Defined Registration De-registration Registered Enrollment De-enrollment Enrolled Activation De-activation Activated Figure 2 – State transition diagram of a group member
  • -8- TD 206 (WP 3/13) 5.2.1. Creation phase The first operation for the multicast service is the creation of multicast-group. The multicast-group may be created by specifying the set of rules that define the future enrolled-groups membership. Before this operation, the multicast-group does not exist, and this operation will be performed by the group management facility. 5.2.2. Registration / de-registration phase After creation of a multicast-group, a multicast service user should make it known to the group manager that he intends to be a member of an enrolled-group. Registration operation can be understood as simply letting the group manager know peer names and addresses of multicast group members. Thus a registered-group is composed of members of a multicast-group that have successfully performed the registration operation. 5.2.3. Enrolment / de-enrolment phase Enrolment operation allows a service user already registered to become a member of an enrolled- group. An enrolled-group is composed of members that have successfully performed the registration and the enrolment operations. 5.2.4. Activation / deactivation phase The activation phase establishes the shared state of a specific instance of a multicast service based on information established during the enrolment phase among the participants. The successful completion of the activation phase leaves the entity in the data transfer phase. An active-group is composed of enrolled group members that have completed the activation phase. 5.2.5. Data transfer phase The data transfer phase involves the actual transfer of data among the group participants who belong to the active group. It may include functions to maintain the QoS, either in terms of error control or resource reservation. The data transfers are allowed among the participants only if the integrity condition is satisfied. If the integrity condition is no longer satisfied during the data transfer, the data transfer operation may be suspended (soft) or terminated (hard) according to the integrity condition management policy. 6. QoS aspects of NGN multicast services Editor’s Note: This section will describe the QoS issues related to NGN multicast service. Differently from the NGN one-to-one service case, handling multiple QoS requirements issued by each participant must be taken into consideration. The QoS issues will include: - The level of QoS agreement - QoS negotiation among heterogeneous environments - And so on 6.1. Levels of QoS agreement The term, level of agreement, is used to describe the agreed actions that will be taken by the service provider and/or the service users to maintain agreed levels of QoS. Three levels of agreement can be defined: best efforts, compulsory, and guaranteed. 6.2. QoS negotiation In order to meet the needs of users and applications, quality of service should be agreed among the communicating entities before entering to the data transfer phase. This QoS agreement is made
  • -9- TD 206 (WP 3/13) during connection establishment phase using the QoS negotiation procedure. Negotiation mechanisms are used to establish operating levels for QoS characteristics and to agree on the actions to be taken if these levels are not maintained. 6.2.1. Receiver diversity From the viewpoint of receivers, a classification of QoS negotiation mechanisms is led to into those for "connection-wide" negotiation, those for "receiver-specific" negotiation, and those for "receiver- selected" negotiation: - Connection-wide QoS negotiation - Receiver-specific QoS negotiation - Receiver-selected QoS negotiation 6.2.2. Sender diversity Resolution or translation capability from an ID into an address, name or another identifier From the viewpoint of senders, a classification of QoS negotiation mechanisms is led to into those for "homogeneous" and those for "heterogeneous" negotiation: - homogeneous QoS negotiation - heterogeneous QoS negotiation 7. General requirements for NGN multicast services Editor’s Note: This section will describe “general” requirements for NGN multicast services. This section will describe what is necessary to provide multicast services in NGN environment. Of course the general requirements are not limited to a specific service scenario. More detailed requirements are provided in following sections. 7.1. Functional requirements for group management Editor’s Note: This section describes “general functional requirements” for NGN multicast group: - connection setup and termination (Editor‟s note: to be clarified) - group join/leave - group membership management 7.2. Functional requirements for data delivery Editor’s Note: This section describes “general functional requirements” for NGN multicast data delivery: - data delivery with QoS support - data delivery with best effort - End-to-end multicast QoS signalling - Per-hop QoS signalling - Resource reservation (buffering, queuing, prioritizing, etc) - Multicast data forwarding - Media handling -
  • - 10 - TD 206 (WP 3/13) 7.3. Functional requirements for management Editor’s Note: This section describes “general functional requirements” for managing NGN multicast services. Items considered include: - Security management - Authentication management - Network fault management - Service/Network performance management - Billing management - Account management - Service profile management (for both session and user) - - (To be completed) 8. NGN multicast service architecture Editor’s Note: This section will present a framework architecture for NGN multicast services. According to the framework architecture and the general requirements for NGN multicast services, which are described previously, the requirements of each functional grouping are presented and defined in detail. Third Party Applications NGN multicast service architecture ANI Multicast service stratum Multicast Multicast Application Functions Service User Profile Multicast Service Control Functions Multicast Multicast Multicast Transport Control Functions Transport End-user User Profile Other Functions Networks M M m F n o n u n g n u c e e a a a c s s i t t t t l i Multicast Transport Functions Multicast transport stratum UNI Management Media Control NNI Figure 3 – Framework architecture for NGN multicast services
  • - 11 - TD 206 (WP 3/13) 8.1. Multicast requirements at the service stratum Editor’s Note: This section will describe the requirements at service stratum. The requirements at this stratum will be; - Policy control function This function is for policy control on NGN multicast services. With the function, a multicast service provider can provide more personalized multicast services to service users. The policy may depend on the contracts of NGN multicast service users’ based on their ages, expenses, and so on. - Service monitoring function This function is for monitoring NGN multicast services. With the function, a multicast service provider can monitor multicast services imposed to its users. Things monitored by this function may depend on the contract, which deals with the contents, service quality etc., between service provider and users. 8.2. Multicast requirements at the transport stratum Editor’s Note: This section will deal with the requirements at transport stratum. The requirements at this stratum will be; - Multicast QoS signalling function This function is for an end-to-end QoS negotiation and/or reservation signalling. Because NGN multicast network may consist of one or more ISPs, QoS parameters of each ISP may differ; this function can overcome the difference. - Resource reservation function This function is for realizing network resource reservation. According to the imposed QoS parameters, this function reserves NGN network resources for multicast service. Ways of reserving network resources can be by using buffering scheme, prioritizing scheme and so on. - Traffic monitoring function This function is for traffic monitoring. Things concerning may include the speed, delay, number of packet, etc. - Media handling function This function is for media handling. Because NGN network may be composed of one or more different ISPs, services may require different types of media. This function can overcome the media differences by mixing and /or translating media. - Multicast group management function This function is for join and/or leave multicast group. Each user should joins multicast group to use NGN multicast services, and then leaves multicast group. The ways of joining and leaving multicast group may differ according to the multicast capabilities provided by each network techniques. - Multicast data forwarding function
  • - 12 - TD 206 (WP 3/13) This function is to construct a multicast data path and the forward multicast data along the path. Multicast data forwarding path can be obtained by using multicast routing protocol. 8.3. Multicast requirements of end-user functions Editor’s Note: This section will deal with the requirements of end-user functions. The requirements will be; - Multicast QoS signalling function This is an end-to-end signalling function for QoS negotiation and/or reservation. - Multicast data sending/receiving function This function is to send and/or receive multicast data. - Multicast group join/leave function This function is for join and/or leave multicast group. Each user should joins multicast group to use NGN multicast services, and then leaves multicast group. 8.4. Multicast requirements of management functions Editor’s Note: This section will deal with the requirements of management functions. The requirements will be; - Authentication / authorization function This function is for authenticating and/or authorizing NGN multicast service user. Upon the contract between service provider and its user, a service provider authorizes user to use its multicast service. To authorize a user to use service, a user authentication may be accompanied. - Accounting management function This function is for managing service user’s accounts. - Membership management function This function is for managing the membership of active service participants. This function provides a means to ensure the active members. - Fault management function This function is for detecting and recovering service fault. The service fault includes the fault from the service aspect as well as from the network aspect. - Security management function
  • - 13 - TD 206 (WP 3/13) This function is for managing security of multicast service. Even though the ways of enabling secured multicast service may differ according to the underlying network capabilities, NGN multicast service provider should provide this function. - Performance management function This function is for managing service in the aspect of service performance. The degree of performance strictly depends on the contracts between service provider and its user. The degree can be acquired from the survey of user’s satisfaction on the service as well as from the traffic measurement. This function enables NGN multicast service provider to manage service performance to conform the contract. 9. End-to-end NGN multicast service connectivity Editor’s Note: This section describes “transport capabilities for NGN multicast services”. It will provide a guideline on network capabilities for NGN multicast services.Each subordinate network, which composes NGN network, may have different capabilities to support multicast services; some networks can fully support IP multicast but some are not. Therefore, it is necessary to describe scenarios for multicast service capabilities in the aspect of subordinate networks. The details are out of scope of this document. The figures from Figure 3 to Figure 5 present NGN multicast topologies where different subordinate networks are involved. 9.1. IP multicast approach Figure 3 shows where all networks can support multicast capabilities. Across the networks pure IP multicast data can be delivered. Multicast Data Multicast Data IP multicast IP multicast IP multicast Sender Receivers Multicast Multicast Multicast Network A Network B Network C Network capabilities for NGN multicast services Figure 3 – IP multicast approach for NGN multicast service 9.2. Overlay multicast approach Figure 4 shows that all networks cannot support multicast capabilities. Nevertheless, this scenario shows that it can support NGN multicast service by applying overlay multicast scheme, which can provide multicast service capabilities.
  • - 14 - TD 206 (WP 3/13) Multicast Data Multicast Data Overlay multicast Overlay multicast Overlay multicast Sender Receivers Unicast Unicast Unicast Network A Network B Network C Figure 4 – Overlay multicast approach for NGN multicast service 9.3. Hybrid approach Figure 5 shows where some networks can support multicast capabilities but others cannot. By passing the non-multicast regions with overlay multicast scheme, NGN multicast service can be served. Multicast Data Multicast Data IP multicast Overlay multicast IP multicast Sender Receivers Multicast Unicast Multicast Network A Network B Network C Network capabilities for NGN multicast services Figure 5 – Hybrid approach for NGN multicast service with IP multicast and overlay multicast scheme 10. NGN multicast service manager function Editor’s Note: This section describes the NGN multicast service manager function (based on D495 Jan 2006 SG13 meeting). Further discussion is required about the organisation of this section. Multicast feature in the network for group applications and services has been proposed in internet TV, remote education, real-time streaming applications, live broadcasting and so on. Recently there is a crucial need to develop an alternative multicast delivery scheme, multicast function at the service stratum. It makes good use of existing unicast, multicast and/or multicast tunnelling schemes. In addition, multicast function at the service stratum is designed as several separate forms to support various kinds of group service type well. Multicast function at the service stratum is expected to provide another substantial approach for group applications over NGN. The general architectural view for NGN service and networking features has been proposed at FGNGN. The section is focused on multicast capability at the service stratum, and the functional capabilities of “Service Control Functions” at the NGN functional architecture are configured. The service control functions perform a session control to provide multicast capability in NGN framework.
  • - 15 - TD 206 (WP 3/13) 10.1. Multicast Capability at the Service Stratum in NGN In order to provide multicast function at the service stratum for diverse applications in the NGN, the functions to construct and manage multicast capability are necessary at the service stratum in of NGN framework. This is because it is not sufficient to support multicast capability through only networking capability in NGN. Thus, it is necessary to define the functional capability to relay and/or multicast internet group application services information over the unicast-based network and to perform multicast function in the service and transport stratum network. Therefore, it is not sufficient to support multicast capability through only networking capability in NGN. After the session control messages for a multicast function at the service stratum are exchanged among multicast entities, and the request information to construct a multicast data delivery path(s) on the transport stratum is transferred to Transport Control Function at the transport stratum in NGN framework. While constructed by using multiple end hosts even such as personal desktop computer. Along the delivery path, real-time or reliable data transport channels are inter-connected between upstream and downstream MA (Multicast Agent)s. Only after the data delivery path and data channel are established, group applications can work as if they were in a native IP multicast network. Multicast function at the service stratum aims to support various kinds of group applications in NGN, some of which are categorized in the according to the ways of communication and the characteristics of data delivery. The functional capabilities for MA (Multicast Agent) and SM (Session Manager) are introduced and described at section 10.4. Figure 6. Functional entity for multicast capability at the service stratum in NGN 10.2. Multicast Topologies for Multicast Function at the Service Stratum in NGN Multicast feature at the service stratum in NGN is performed through two different functions for control information and data transmission. It is necessary to consider two different topologies for control information transfer and data transport connection.
  • - 16 - TD 206 (WP 3/13)  Topology for control information exchange For robust and maintenance of the logical link, the control message periodically should be exchanged among the multicast entities. As the multicast topology is included loop forwarding, quickly repair a partition regardless of repeated transmission, therefore this is suitable for exchanging the control message. Typical example of topology for control information in multicast function at the service stratum will be mesh type.  Topology for data transport connections Unlike the control message, the data transmission should be faster and should evade a repeated transmission. As the multicast topology is included partition detection and recovery mechanism, has one link both end hosts, therefore this is suitable for forwarding the data message. For creation of efficient multicast transport connections, an optimization procedure of topological multicast paths is performed at service level. Its optimal data transport topology in the transport stratum will be created according to the transport network environment. 10.3. Control Messages for Service Level Multicast The control messages for multicast function at the service stratum will include the following:  Session Join When a host joins, it contacts the source to get a random list of current group members. It then picks one of these members as its parent using the parent selection algorithm described below.  Session Leave When a host leaves, all of its descendants are disconnected from the overlay tree. For each of its descendants, this is counted as an ancestor change. Descendants then connect back to the tree by independently finding a new parent using the parent selection algorithm.  Merge One or more members are added to the group. The merge operation optimizes for massive joins to the group  Parent Selection When a host needs to find a parent, it selects a set of random hosts that are currently in the system, probes them to see if they are currently connected to the tree and have enough resources to support a new incoming child, and then ranks them based on the parent selection criteria described in the next section  Mobility Management For the mobile users that are moving to other network region, the handover support shall be provided in the multicast function at the service stratum. When the mobile terminal is moving to another network region and thus changing its access point in the mobile network and/or changing its IP address, the host should report the handover event. 10.4. Functional Architecture for Multicast Function at the Service Stratum This section describes the functional architecture requirements for multicast function at the service stratum. The function requires both service and transport stratum to support multicast service.
  • - 17 - TD 206 (WP 3/13) Figure 7. Multicast functional architecture model at service stratum in NGN For multicast over converged network platforms, (e.g., wired, wireless and broadcast networks) each Multicast Agent will handle its functionalities for multicast. 10.4.1. Session Manager (SM) SM (Session Manager) is involved in session configuration and maintenance. A single SM can handle one or multiple sessions simultaneously, and it can provide the following functionalities: − Session initialization: SM allocates SID for new session. − Session release: Session can be released as needed. − Session membership management − Session status monitoring:  report the status of data channel  data throughput  multicast protocol membership gathering  multicast protocol topology information gathering 10.4.2. Multicast Agent (MA) MA (Multicast Agent) constructs relayed multicast delivery path and forwards data along the constructed path from pMA (Parent Multicast Agent) and to cMAs (Child Multicast Agents). An MA consists of control module and data transport module. The main function of former is to establish relayed data delivery path and that of latter to setup data channel along the path constructed by control module and relay data through the channel. MA performs the control functions to exchange control messages with other entity. Its major functions are as follows.
  • - 18 - TD 206 (WP 3/13) − Session join: each MA contacts with Session Manager. − Session leave: when an MA wants leave the session, it gives notice to its pMAs and cMAs − Session maintenance: relay request and its response will be exchanged between the two MAs periodically.  Loop detection and avoidance, Partitioning detection and recovering, Parent switching − Session status reporting 10.4.3. Group Membership Management  Self-organizing for group membership The construction of the multicast function at the service stratum must take place in a fully distributed fashion and must be robust to dynamic changes in group membership.  Tree refinement for group membership The group membership has changed on group member join or release. According to this change, the tree structure that is composed group members, also have changed. Therefore, the tree should include all active members inside group.  Interplay between membership management and tree construction The data delivery structure and the membership management clusters are loosely coupled. The membership information from the clusters implicitly influences the data delivery tree. We do not enforce strict clustering on the data delivery tree. In fact, overlay nodes are free to select nodes outside their own cluster as parents if those nodes provide better performance. This simplifies performance optimizations and recovery from node failures 10.4.4. Multicast QoS  Path quality measurement The path quality measurement should need maintenance of optimized logical link in multicast function at the service stratum. According to have changed the group membership, a logical link both end hosts should change optimization. To measure the path quality, the sending information both group entities will include bandwidth, delay, etc  Considerations of wireless link characteristics It is noted that the wireless links are generically in the lower quality than the wired links. Accordingly, the mobile users may be susceptible to the quality of services for the mobile application services. In this context, the service level multicast needs to provide the monitoring of QoS perceived by end users.  Monitoring on Membership and QoS After a host joins, each host can receive the multicast data packets. At the same time, each host should send the reporting messages for active membership and QoS reporting.
  • - 19 - TD 206 (WP 3/13) 10.4.5. Multicast Security For commercial deployment of application services in multicast, the security is an essential issue at the service provider side. In particular, the authentication and authorization for the session users will be required through the Join phase. 10.5. Functional Requirements for the Interface between SCF and PD-FE for Multicast Function at the Service Stratum According to transport capabilities, the multicast control functions at service stratum will be required differently. For example, multicasting for wireless end users through wired transport network is managed differently to meet QoS and other transport requirements for application service. In order to provide end-to-end QoS and other application service requirements in multicast well, the different multicast agents at service stratum will be necessary to provide the application service features in multicast. Figure 8 introduces different MAs for wired, wireless and customer access network. Therefore, the Multicast Agent (MA) at service stratum (MA-1 for wired network, MA-2 for wireless environment and MA-3 for customer premises network environment) will have a different interactions with PD- FE to deliver/receive transport requirements at the wired, wireless and customer premises network environment. In order to provide harmonized application service feature to end user, end-to-end session management function will take an important role to manage a session for an application service user. For instance, in order to consider a negotiation and interface with PD-FE for resource reservation and QoS requirement provision at transport stratum including wired and wireless network environment well, the architectural model shown in Figure 8 will be necessary to provide multicast functions at service stratum well. Figure 8. Example of Interfaces between SCF and PD-FE for Multicast Function at the Service Stratum
  • - 20 - TD 206 (WP 3/13) 10.5.1. Functional Procedures in Multicast service request for QoS connection between SCF and PD-FE The MA-requested multicast service procedure is initiated by a multicast service request from the MA in the SCF. Figure 9 - MA-requested multicast service procedure (1) When SM is requested by CP (Contents Provider) to create a new session, SM creates new session by session profile information which includes session name, media characteristics (e.g. IPTV, Video convergence, Internet streaming, File dissemination, Network games, etc.), group address, and so on. SM creates globally unique SID (Session ID) to distinguish the session, and returns SID to CP. CP announces session information and SID using web server, e-mail etc. After the session creation, SM waits for multicast service request from MAs. (2) The MA requests the multicast service to the SM using the SM IP address and the SID. This service request contains the system information (including demand bandwidth, data profile, etc.) and the explicit QoS requirement (e.g. QoS class) for this service. (3) When SM receives the multicast service request from MA, SM checks the SID and data profile in the request, decides whether the request is acceptable and valid by the session policy and determines or derives the QoS requirement parameters (including bandwidth, delay, jitter, loss, etc.) for the media flow of a requested multicast service. It then sends a resource reservation request with the flow description and its QoS parameters to the PD-FE across reference point Rs for multicast service authorization and reservation. (4) On receipt of the resource reservation request, the PD-FE shall authorize the required multicast service for the media flow. The PD-FE checks if the flow description and the required multicast service with QoS parameters can be acceptable within transport domain
  • - 21 - TD 206 (WP 3/13) and the required multicast service are consistent with the operator policy rules held in the PD-FE. (5) The PD-FE positions and determines which access networks and core networks are involved for the media flow. The PD-FE positions and determines which access networks and core networks are involved for the media flow. If there are TRC-FE instances in an involved network, the PD-FE sends a Request to check resource availability to one of the TRC-FE instances registered in the PD-FE for checking in the involved network. If there are multiple TRC-FE instances in the involved network, they communicate with each other to determine if the required multicast service is available from edge to edge in the involved network. The TRC-FE instance which received the Request to check resource availability shall send a Respond to resource availability check back to the PD-FE. (6) The PD-FE makes the final admission decisions to the resource reservation request for multicast service based on the checking results of Step 4 and 5. If the resource reservation request from the SM is not admitted, the PD-FE sends a resource reservation response with the rejection reason back to the SM. (7) The PD-FE may send an admission installation command to install the final admission decisions in the MTF (Multicast access/core Transport Functions). (8) The MTF installs the final admission decisions sent from the PD-FE and sends an installation confirm back to the PD-FE. Note that the installed admission decisions may be enforced automatically and immediately or may wait for an activation request for gates opening and service commitment. (9) The PD-FE sends the resource reservation response back to SM. (10) Finally, the SM sends the multicast service response back to MA. This response contains MAID (If MAID is missed, SM creates MAID which is constructed by MA IP address, port number and serial number) and bootstrapping information (including neighbor list), negotiated data profile (e.g. bandwidth, etc.). 10.5.2. MA-Multicast service request procedure for additional service features [Editor‟s Note: The details of the section 9.5.2 will cover the control features to provide diverse application service features in multicast at service stratum, and it will be also considered to provide multicast transport capability accordance with application service features at service stratum. _________________