WG7-XI-XX

ISO/IEC JTC 1/SC 6 TELECOMMUNICATION AND INFORMATION

EXCHANGE BETWEEN SYSTEMS

Title: Output Document of MMC Framework (MMC-1)

Source: Editors (Maryam Roshanaei, Juyoumg Park, Seok J. Koh)

Project: JTC 1/SC 6/WG 7 WD 24793-1 | ITU-T Q.1/17 X.mmc-1

Status:

This is the output document of MMC-1 (Mobile Multicast Communications:

Framework), which has been produced in the joint meeting of the ISO/IEC JTC 1/SC

6/WG 7 and ITU-T Q.1/17, held in Xian, China, April 2007.

1

Table of Contents

1. SCOPE............................................................................................................................................................1

2. NORMATIVE REFERENCES ..............................................................................................................................1

3. DEFINITIONS ..................................................................................................................................................2

4. ABBREVIATIONS ............................................................................................................................................3

5. MOTIVATIONS................................................................................................................................................4 5.1 MARKET TRENDS .....................................................................................................................................4 5.2 NETWORK ENVIRONMENTS ......................................................................................................................4 5.3 RELATED WORKS.....................................................................................................................................5

5.3.1 IETF.............................................................................................................................................5 5.3.2 ITU-T AND ISO/IEC JTC1 ...........................................................................................................6 5.3.3 3GPP/MBMS ...............................................................................................................................7 5.3.4 3GPP2/BCMCS ...........................................................................................................................7

6. DESIGN CONSIDERATIONS .............................................................................................................................8 6.1 TARGET APPLICATIONS AND SERVICES ....................................................................................................8 6.2 DESIGN PRINCIPLES .................................................................................................................................8 6.3 NETWORK MODELS..................................................................................................................................9

6.3.1 MULTICAST NETWORKS................................................................................................................9 6.3.2 OVERLAY MULTICAST NETWORKS .............................................................................................10

6.4 FUNCTIONAL REQUIREMENTS ................................................................................................................10

7. FUNCTIONAL ARCHITECTURE ......................................................................................................................11 7.1 FUNCTIONAL ENTITIES...........................................................................................................................11

7.1.1 MOBILE NODE (MN)...................................................................................................................11 7.1.2 MULTICAST CONTENTS SERVER (MCS)......................................................................................12 7.1.3 SESSION MANAGER (SM) ...........................................................................................................12 7.1.4 MULTICAST AGENT (MA)...........................................................................................................12 7.1.5 LOCAL MOBILITY CONTROLLER (LMC) .....................................................................................12

7.2 REFERENCE CONFIGURATION OF FUNCTIONAL ENTITIES .......................................................................13 7.2.1 CONFIGURATION IN MULTICAST NETWORKS ..............................................................................13 7.2.2 CONFIGURATION IN OVERLAY MULTICAST NETWORKS..............................................................14

7.3 MMC FUNCTIONALITY ..........................................................................................................................15 7.3.1 MULTICAST DATA TRANSPORT...................................................................................................15 7.3.2 SESSION JOIN AND LEAVE...........................................................................................................15 7.3.3 TREE CONFIGURATION IN OVERLAY MULTICAST NETWORK ......................................................16 7.3.4 STATUS MONITORING .................................................................................................................17 7.3.5 MOBILITY SUPPORT ....................................................................................................................17

8. HIGH-LEVEL INFORMATION FLOWS .............................................................................................................18 8.1 SERVICES SUBSCRIPTION AND SESSION ANNOUNCEMENT......................................................................18 8.2 MULTICAST DATA TRANSPORT..............................................................................................................18 8.3 SESSION JOIN AND LEAVE ......................................................................................................................19 8.4 CONFIGURATION OF MMC AGENTS.......................................................................................................19

2

8.4.1 CONFIGURATION OF LOCAL MOBILITY CONTROLLER FOR MULTICASTING.................................19 8.4.2 TREE CONFIGURATION FOR OVERLAY MULTICASTING ...............................................................19

8.5 STATUS MONITORING ............................................................................................................................20 8.6 MOBILITY SUPPORT ...............................................................................................................................20

9. SECURITY CONSIDERATIONS ON MMC........................................................................................................21 9.1 GENERIC SECURITY REQUIREMENTS ......................................................................................................21 9.2 SECURITY REQUIREMENTS ASSOCIATED WITH MMC FUNCTIONALITY ..................................................21

APPENDIX A. FURTHER SECURITY ISSUES ON MMC...............................................................................................23

APPENDIX B. EXAMPLES OF SERVICE SCENARIOS WITH MMC ...............................................................................25

APPENDIX C. MMC CONFIGURATION IN THE WIBRO NETWORKS ..........................................................................26

BIBLIOGRAPHY .......................................................................................................................................................27

3

INTERNATIONAL STANDARD 24793-1 ITU-T RECOMMENDATION X.mmc-1f

INFORMATION TECHNOLOGY – MOBILE MULTICAST COMMUNICATIONS: FRAMEWORK

SUMMARY TBD

INTRODUCTION TBD

1. SCOPE

This Recommendation | International Standard describes Mobile Multicast Communications (MMC), which can be used to support a variety of multimedia multicasting services in the IP-based wireless mobile networks as well as the wired fixed networks. The MMC is targeted at the real-time one-to-many multicast services and applications over mobile communications networks. This implies that the MMC will focus on the multicast services rather than the broadcast services, and only the authenticated users could be allowed in the multicast session. The MMC will also consider the one-to-many multicast session, in which a single multicast sender is allowed in the session, rather than the many-to-many multicast services. In addition, the MMC will be targeted at the real-time multicast session rather the reliable multicast session, and the timely delivery of multicast data will be considered as a key factor.

This Recommendation | International Standard specifies the MMC framework (MMCF), as part of the MMC project, which describes the framework and functional architecture of the MMC. Based on this framework, the two protocols for MMC will be developed in the two parts of the MMC project: the protocol over native IP multicast networks and the protocol over overlay multicast networks.

This Recommendation | International Standard describes the followings:

a) Motivations on MMC;

b) Design considerations;

c) Functional architecture;

d) High-level information flows;

e) Security considerations on MMC.

2. NORMATIVE REFERENCES

The following ITU-T Recommendations and International Standards contain provisions that, through references in the text, constitute provisions of this Recommendation | International Standard. At the time of publication, the editions indicated were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this Recommendation | International Standard are encouraged to investigate the possibility of applying the most recent edition of the Recommendations | International Standards listed below. ISO and IEC members maintain registers of currently valid International Standards. The Telecommunication Standardization Bureau of the ITU-T maintains a list of currently valid ITU-T documents.

a) ITU-T Recommendation X.601 (2000), Multi-Peer Communications Framework

b) ITU-T Recomendation X.602 (2004) | ISO/IEC 16511: 2005, Information Technology – Group Management Protocol (GMP)

1

c) ITU-T Recommendation X.603 (2004) | ISO/IEC 16512-1: 2004, Information Technology — Relayed Multicast Protocol (RMCP): Framework

d) ITU-T Recommendation X.603.1 (2007) | ISO/IEC 16512-2 (2007), Information Technology — Relayed Multicast Protocol (RMCP): Specification for Simplex Group Applications

e) ITU-T Recommendation X.605 (1998) | ISO/IEC 13252: 1999, Information Technology – Enhanced Communications Transport Service Definition

f) ITU-T Recommendation X.606 (2001) | ISO/IEC 14476-1: 2002, Information Technology — Enhanced Communications Transport Protocol: Specification of simplex multicast transport

g) ITU-T Recommendation X.606.1 (2002) | ISO/IEC 14476-2: 2003, Information Technology — Enhanced Communications Transport Protocol: Specification of QoS Management for Simplex Multicast Transport

3. DEFINITIONS

This Recommendation | International Standard uses the terms defined in the Relayed Multicast Protocol (ITU-T Rec. X.603 | ISO/IEC 13252). In addition, the following terms are used in this Recommendation | International Standard,

a) Multicast Network

Multicast Network represents the networks in which the legacy IP multicasting schemes are enabled with the help of the multicast routing protocols, the multicast forwarding capability of the multicast routers in the networks, the link-layer multicasting of the Points of Attachment (PoA) in the network, and the multicast membership signaling in the subnet such as IGMP/MLD. The MMC services could be provisioned over Multicast Network;

b) Overlay Multicast Network

Overlay Multicast Network represents the network in which the legacy IP multicasting schemes are not fully supported. In this network, the multicast application data will be delivered using unicast transport such as TCP, UDP, or IP-in-IP tunneling schemes. In particular, the unicast delivery of the multicast data might be done in the backbone networks. In the overlay multicast network, the IP multicast transport might be used in a portion of the network. For example, as shown in the RMCP protocol (ITU-T X.603 | ISO/IEC 16512), the subnet multicasting may be used in the end subnets at which the multicast sender or receiver is located. In the overlay multicast network, the multicast data might be delivered using the unicast relay of the multicast agents and the subnet multicasting capability. The MMC services could be provisioned over overlay Multicast Network.

(Editor’s Note) some more definitions may be added, when necessary.

2

4. ABBREVIATIONS

Editor’s Note) Abbreviations will be further reviewed and updated as the works are in progress.

AAA Authentication, Authorization, and Accounting

AP Access Point

AS Authentication Server

BCMCS Broadcast Multicast Services

BWA Broadband Wireless Access

CS Contents Server

ECTP Enhanced Communications Transport Services

FMC Fixed Mobile Convergence

IGMP Internet Group Management Protocol

IP Internet Protocol

IPTV IP-based TV

LSM Local Session Manager

MBMS Multimedia Broadcast Multicast Services

MLD Multicast Listener Discovery

MMC Mobile Multicast Communications

MMCF MMC Framework

MU MMC User

NGN Next Generation Networks

RA Relay Agent

RMCP Relayed Multicast Protocol

SM Session Manager

SDO Standard Defining Organization

WLAN Wireless Local Area Network

3

5. MOTIVATIONS

This Recommendation | International Standard deals with Mobile Multicast Communications (MMC). The MMC is targeted for enabling and supporting a variety of multimedia multicast applications and services over the wireless/mobile networks as well as the wired/fixed networks.

This document describes the MMC Framework (MMCF). Based on this framework, the two or more protocols required for MMC will be developed. This section will first describe the motivations on MMC in the perspective of market trends and evolving network environments. In addition, some related works that are being done in the other SDOs will be reviewed.

5.1 MARKET TRENDS

In the market perspective, the work on MMC is motivated from the following observations:

a) Growth of the IP-based multimedia broadcast/multicast services markets

In the telecommunications markets, there are crucial needs to provide the multimedia multicasting and broadcasting services all over the world. With the help of broadband networks, efficient multimedia platforms including audio/video codec’s and IP-based network transport and application technologies, it is expected that the markets of IP-based multimedia broadcasting and multicasting services will have grown in the next generation communications networks.

Examples of these multimedia multicast/broadcast services include Internet TV (IPTV), remote education, broadcasting of special live events, and so on.

b) Increasing needs on multimedia broadcast/multicast services over wireless mobile networks

Recent trend on the mobile communications industry reflects on the increasing demands of the multimedia multicast/broadcast applications and services over the wireless/mobile networks. In fact, the IP-based multimedia broadcasting/multicasting services will be one of the primary killer applications in the perspective of the mobile services providers.

Examples of these mobile multicast applications/services include mobile IPTV, mobile commerce (m-commerce), and Digital Multimedia Broadcasting (DMB) using the mobile devices such as cellular phone, PDA, hand-held PCs, etc. It is envisioned that these mobile multicasting services could be provisioned through a variety of wireless access networks such as cdma2000, W-CDMA, Wireless LAN (WLAN) based on IEEE 802.11, Broadband Wireless Access (BWA) based on IEEE 802.16. Most of the mobile service providers are expected to provide the IP-based multimedia multicasting services over these various wireless networks.

c) MBMS and BCMCS standardizations in 3GPP and 3GPP2

With this demand on the mobile multicasting, the 3GPP and 3GPP2 are working in progress for standardization to develop the relevant protocols or schemes. In 3GPP, the ‘Multimedia Broadcast and Multicast Services (MBMS) are being made so as to support the IP-based multimedia multicasting services in its own systems. On the other hand, the 3GPP2 started to make the standardization works on the ‘Broadcast & Multicast Services (BCMCS)’ for its own cdma2000-based networks and systems.

5.2 NETWORK ENVIRONMENTS

In the next-generation communications networks, it is envisioned that there coexist a variety of heterogeneous access networks using different wireless/wired access technologies under the same administrative domain or network operator. In this environment, those heterogeneous access networks might be inter-connected each other via the IP-based core network, which will hence ensure that the identical multimedia multicast/broadcast services could be provided for the users regardless of the access network that the user is attached to.

With this trend of Fixed-Mobile Convergence (FMC), there is a crucial need to provide the multimedia multicasting services/applications over the wireless/mobile networks as well as the wired/fixed communications networks.

4

The following figure illustrates the network environment to be considered in the MMC.

Figure 1 – Network environments in MMC

As shown in the figure, the NGN environment is featured the ‘IP-based core network’ and a variety of ‘heterogeneous access networks.’ In this scenario (figure 1), the network operator (or service provider) will provide the various multimedia multicasting services/applications for the users over the IP-based core network, and each (mobile) user will benefit from those abundant services through the various access networks. Each access network could be a fixed/wired network such as the conventional PSTN, ISDN, and Internet, or a mobile/wireless network such as WLAN, BWA and 3G cellular networks. Under the FMC feature, the users shall benefit the identical multimedia multicasting services regardless of the specific access network that they are connected to.

It is also noted that the user might move around across a variety of access networks in the NGN environment. Accordingly, the issue of mobility support for the mobile users needs to be addressed in the MMC perspective, in which the seamless mobility (specifically, handover) shall be supported even when the mobile users move across those heterogeneous networks. The mobility issue on MMC shall deal with how to support seamless multicast services against the movement of users (terminals).

From these observations, it is concluded that some schemes or protocols are required for providing the seamless mobile multicasting services under the FMC and mobility environments of NGN. Those schemes or protocols shall be commonly applied for a variety of heterogeneous wireless and wired access networks, regardless of the movement of users.

5.3 RELATED WORKS

This document is purposed to design the framework of MMC. The MMCF shall be designed based on the existing works that have so far been made in the SDOs. For this purpose, this section describes the relevant works in the IETF, ITU-T, JTC1, 3GPPs.

5.3.1 IETF

The IETF is a leading SDO in the areas of IP multicasting. The IETF has so far developed the protocols required for multicast data transport, which include IGMP/MLD and multicasting routing protocols for multicast tree construction to deliver the multicast data packets in Internet.

The IGMP/MLD protocols are used for signaling between multicast routers and hosts in the network. These protocols make sure that the network routers can realize whether any multicast user (specific to the group IP address), which will in turn be used by the multicast routers to construct the multicast tree using the multicast routing protocols. Until now, the following IGMP/MLD protocols were developed:

Internet Group Management Protocol (IGMP) for IPv4: IGMPv2, IGMPv3

Multicast Listener Discovery (MLD) for IPv6: MLDv1, MLDv2

5

The multicast routing protocols are used as signaling protocols to construct a multicast tree for a specific multicast IP address, which will enforce the multicast network routers to configure the associated multicast forwarding table as the routing path for the multicast data packets. Until now, the following multicast routing protocols were developed:

Distance Vector Multicast Routing Protocol (DVBMRP)

Core Based Tree (CBT)

Protocol Independent Multicast – Dense Mode (PIM-DM)

Protocol Independent Multicast – Sparse Mode (PIM-SM)

Source Specific Multicast (SSM), which uses the IGMPv3 (IPv4) or MLDv2 (IPv6)

In the IETF, some further works are working in progress for the works on deployment of IP multicasting (e.g., IGMP snooping in the MBONED WG). Based on the discussion above, the works made in the IETF can be summarized as follows:

Table 1 – IETF protocols related to IP multicasting Technical Areas Protocols (year) Reference (RFC)

IGMP/MLD

IGMPv2 (1997) IGMPv3 (2002)

MLDv1 for IPv6 (1996) MLDv2 for IPv6 (2004)

RFC 2236 RFC 3376 RFC 2710 RFC 3810

Multicast Routing Protocols

DVMRP (1988) CBT (1997)

PIM-SM (1998) PIM-DM (2005)

SSM (2003)

RFC 1075 RFC 2189 RFC 2362 RFC 3973 RFC 3569

5.3.2 ITU-T AND ISO/IEC JTC1

The main focus that have been made in the JTC1/SC6 and ITU-T SG17 are on the protocols that can provide the reliable multicast transport and QoS management for IP multicasting in the networks, as described in the Enhanced Communications Transport Protocol (ECTP). The ECTP is a reliable multicast protocol designed to support Internet multicast applications running over multicast-capable networks. ECTP could possibly be provisioned over UDP. ECTP is designed to support tightly controlled multicast connections in simplex, duplex and N-plex applications.

The ECTP consists of the following parts:

a) ECTP-1: Simplex multicast transport (ISO/IEC 14476-1 | ITU-T X.606)

b) ECTP-2: QoS management for simple multicast transport (ISO/IEC 14476-2 | ITU-T X.606.1)

c) ECTP-3: Duplex multicast transport (ISO/IEC 14476-3 | ITU-T X.607)

d) ECTP-4: QoS management for duplex multicast transport (ISO/IEC 14476-4 | ITU-T X.607.1)

e) ECTP-5: N-plex multicast transport (ISO/IEC 14476-5 | ITU-T X.608)

f) ECTP-6: QoS management for N-plex multicast transport (ISO/IEC 14476-6 | ITU-T X.608.1)

The JTC1/SC6 and ITU-T SG17 groups are also developing the Relayed Multicast Protocol (RMCP). The RMCP is designed to ensure that the multicast applications and services can be realized over the current Internet environments in which IP multicast has not completely been deployed. The RMCP, as also known as the application-level multicast, is a multicast data transport protocol used for multicast applications, in which intermediate Multicast Agents (MA) are employed for relaying the multicast data from a sender to many receivers over unicast networks, as shown in the following figure.

6

The RMCP consists of the following parts:

a) RMCP-1: RMCP framework (ISO/IEC 16512-1 | ITU-T X.603)

b) RMCP-2: RMCP for simple group applications (ISO/IEC 16512-2 | ITU-T X.603.1)

c) RMCP-3: RMCP for N-plex group applications (ISO/IEC 16512-3 | ITU-T X.603.2)

5.3.3 3GPP/MBMS

For the purpose of provisioning the multimedia multicast and broadcast services over the wireless mobile systems, the 3GPP is developing the ‘Multimedia Broadcast and Multicast Services (MBMS),’ which can be used to support the IP-based multimedia multicasting services in its own W-CDMA access networks and systems.

For the MBMS subsystem, the 3GPP defines a new functional entity ‘Broadcast and Multicast - Service Center’ (BM-SC) and the two new interfaces: Gmb for control plane (authorization and management) and Gi for user plane (IP packet transmission). The BM-SC is responsible for managing the overall session management and multicast data transport in the 3GPP system. The MBMS of 3GPP is featured the service-oriented and security-oriented multicast framework in the 3GPP2-own networks and systems, using the legacy IP multicast protocols to the extent possible.

The 3GPP documents associated with the MBMS includes:

a) 3GPP TS 22.246, MBMS User Services,

b) 3GPP TS 23.246, MBMS Architecture

c) 3GPP TS 25.346, MBMS in RAN: Stage 2

d) 3GPP TS 26.346, MBMS Protocols and Codecs

e) 3GPP TS 33.246, Security of MBMS

5.3.4 3GPP2/BCMCS

On the other hand, the 3GPP2 started to make the standardization on the ‘Broadcast & Multicast Services (BCMCS)’ for providing the broadcast/multicast services and applications over its own cdma2000 systems.

As similar to the MBMS of the 3GPP, the BCMCS plans to design a secure multicast in the cdma2000 networks and to develop some technical specification for provisioning the multimedia multicasting services over the 3GPP2-own networks and systems, using the legacy IP multicast protocols to the extent possible. The BCMCS can be regarded as the subsystems to add the services-specific and security-oriented features to the IETF multicasting protocols.

For this purpose, the BCMCS introduces the new entities, BCMCS Controller for control purpose and BCMCS Supporting Node (BSN) for data transport purpose, together with the security framework.

The 3GPP2 documents associated with the BCMCS includes:

a) 3GPP2 S.R0030-A, Broadcast/Multicast Services – Stage 1

b) 3GPP2 S.S0083-A, Broadcast Multicast Security Framework

c) 3GPP2 X.S0022, BCMCS in cdma2000 wireless IP network

d) 3GPP2 A.S0019, Interoperability Specification for BCMCS

e) 3GPP2 C.S0054, cdma2000 High Rate BCMCS Packet Data Air Interface Specification

7

6. DESIGN CONSIDERATIONS

This Recommendation | International Standard is purposed to design the framework of MMC, which can be used to support a variety of multimedia multicast applications and services over the wireless mobile networks as well as the fixed networks in the NGN environments.

For this purpose, this section describes considerations that shall be taken in the design of MMCF.

6.1 TARGET APPLICATIONS AND SERVICES

The MMCF shall be designed to support the IP-based multimedia multicast applications with the following characteristics:

a) Multicast applications/services

The MMCF will be targeted to the multicast applications and services, rather than the broadcast applications and services. The multicast-based services will allow only the authenticated and authorized users to exploit the MMC services, whereas the broadcast applications/services might be provided for any users, without any authentication and authorization procedures.

To support the MMC services for the authenticated and authorized users only, the MMCF shall be interworking with the legacy AAA schemes. For this purpose, the MMCF shall also require appropriate steps for the users, such as ‘service subscription’ and ‘session join’.

b) One-to-many multicast applications/services

The MMCF will also be targeted to the one-to-many multicast applications, rather than the many-to-many multicast ones. The one-to-many multicast services will consist of the single data sender, as also called Contents Server (CS), and many receivers (multicast users or clients). That is, only a single sender shall be allowed in the multicast session.

It is noted that most of the commercial multicast applications and services are based on the one-to-many multicast scenario. The case of the many-to-many application is for further study.

c) Real-time multicast applications/services

The MMCF shall be designed to support the one-to-many ‘real-time’ multicast applications, rather than the non-real time and/or reliable multicast applications. It is noted that a real-time multicast application is focused on delivery of the data in the timely manner, whereas a reliable multicast application makes efforts to perform the reliability control (e.g., the error recovery by retransmission of the lost/corrupted packets), as shown in the ECTP protocol (ISO/IEC 14476 | ITU-T X.606).

The MMCF is targeted at the real-time multicast applications such as the IPTV multicasting or live broadcasting of live events, since the timely delivery is preferred to the reliable delivery for such real-time applications and services. It is assumed in the MMCF that the reliability control might be done in the application itself.

6.2 DESIGN PRINCIPLES

This document describes the design of the MMCF for MMC services and applications over wireless mobile networks as well as the fixed communications networks. Based on the MMCF, it is planned in the future to develop one or more associated control protocol for MMC.

For this purpose, the MMCF shall be designed with the following design principles:

a) Generic IP-based control schemes for MMC

The MMC shall operate on the IP-based network. Accordingly, the MMCF shall be designed to integrate the existing IP-based schemes and protocols (such as AAA, multicast routing protocols) required for realization of the MMC services.

It is noted that the MBMS and BCMCS systems are based on their own 3GPP- and 3GPP2-specific access

8

systems, rather than the generic IP-based scheme. On the other hand, the MMCF shall be designed to ensure that the MMC-related protocols could be generically and commonly used on the IP-based mobile networks, such as WLAN (IEEE 802.11) or BWA (IEEE 802.16).

b) Flexible integration of legacy multicast applications with MMCF

The MMCF is mainly targeted to develop a new ‘control’ protocol used for MMC applications over the mobile networks. Accordingly, all kinds of the existing legacy multicast applications shall be able to be used together with the MMC protocol, without any further modifications.

c) Interworking with the conventional protocols for security and authentication/authorization

For commercial deployment of mobile application services, the security is an essential issue at the service provider side. In particular, the authentication and authorization schemes (e.g., AAA servers) for the session users will be required through the session join phase. In addition, any security scheme such as IPSEC or TLS might be used for the secure MMC services. For this purpose, the associated legacy schemes/protocols shall be interworking with the MMC protocol.

6.3 NETWORK MODELS

The MMCF is designed on the multicast delivery networks, in which the multicast data transport might be realized using the IP multicast transport (with the help of IGMP/MLD) and multicast routing protocols, or using the Overlay multicast transport (with the help of the RMCP).

More specifically, the MMC considers the two types of networks for multicast data transport: multicast network and Overlay multicast network.

6.3.1 MULTICAST NETWORKS

The following figure shows the multicast transport network model using IP multicast.

Figure 2 – Multicast data transport in the MMC networks

As shown in the figure, the MMC network consists of a backbone network (administrated by the service provider) and a variety of wireless access networks. In this MMC network, the multimedia real-time data shall be delivered from Multicast Contents Server (MCS) to Mobile Nodes (MN).

9

For delivery of the multicast data, the networks will be equipped with a lot of Multicast Routers (MR) and Points of Attachment (PoAs) in the wireless access network. For the IP multicast transport, the multicast routing protocols are supported between MRs, and the IGMP/MLD protocols will be used between MR and MNs.

6.3.2 OVERLAY MULTICAST NETWORKS

In the networks in which the IP multicast has not been deployed, the Overlay Multicast might be used for delivery of multicast data in the network. For this purpose, the RMCP may be used to configure an overlay multicast tree in the networks. The following figure shows the overlay multicast.

Figure 3 – Overlay multicast data transport in the MMC networks

As shown in the figure, one or more Multicast Agents (MAs) will be deployed for overlay multicasting in the network. Each MN will receive the multicast data of the MCS from one of the MAs using the unicast or subnet multicast.

6.4 FUNCTIONAL REQUIREMENTS

As for the multicast transport over Internet, the IETF has so far developed a lot of protocols for IP multicasting, which include the IGMP/MLD and the multicast routing protocols such as DVMRP, CBT, PIM, and SSM. With the help of these protocols, the networks providers will realize the deployment of the multicast-capable networks.

Nevertheless, there are still needs on the multicast session control and management schemes required for providing the commercial multicast services, which will include the session management and status monitoring. In addition, in the case of mobile multicasting, a control scheme of the mobility support for the mobile users shall be required.

Accordingly, to support the mobile multimedia multicast applications and services over the wireless mobile networks, the MMC shall be designed based on the following functional requirements:

a) Control functionality for mobile multicast sessions

The MMC shall be realized with the help of the conventional IP multicasting protocols such as the IGMP/MLD, multicast routing protocols made in the IETF and the RMCP made in the ITU-T and JTC1. Accordingly, the MMCF shall provide the ‘control’ and ‘management’ functions for the MMC sessions, as well as the multicast data transport functionality. These control functions may include ‘session join’ for a new joining user, ‘membership monitoring’ of active users, QoS monitoring for the data packets received by

10

end users, etc.

b) Support of membership monitoring

The MMCF shall be designed to support the monitoring on active session membership of users for each multicast session. This monitored information could be used for the charging and billing by the contents providers.

a) Support of QoS monitoring for wireless environments

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 MMCF shall be designed to provide the monitoring of QoS perceived by end users. This monitored QoS information might be used by the contents servers to adjust the data transmission rate. For example, the MPEG-based trans-coding or SVC (Scalable Video Coding) techniques could be used to reflect on the QoS status of the end users. The monitored QoS information might also be used by the content providers to charge for usage of the contents/services to the end users.

b) Support of mobility of mobile terminals

The mobility of a mobile terminal is one of the key issues to be handled for the MMC services. In the mobile networks, each MN user tends to move to other networks, and hence it will change a new access point and IP address in the newly attached network. The MMCF shall be designed to support this mobility or handover for the mobile terminals during the MMC session. With the help of this handover control functionality, the mobile users could continue the multicast session in the seamless manner.

c) Support of authentication and authorization for multicast users

The MMCF shall be designed to support the AAA functionality for the multicast session. For this purpose, the MMC shall be able to be interworking with the legacy AAA servers and/or user profile databases, etc. These servers and databases might be used for authentication and authorization of the newly joining multicast user.

7. FUNCTIONAL ARCHITECTURE

7.1 FUNCTIONAL ENTITIES

In this section, a set of functional entities for MMC are described, which shall be involved with the multicast transport and control functionality required for MMC sessions.

7.1.1 MOBILE NODE (MN)

A Mobile Node (MN) represents a multicast receiving user for mobile multicast application session. An MN will receive the MMC application data services from the Multicast Contents Server (MCS) with the help of the multicast or overlay multicast transport in the networks. Each MN will join an MMC session by contacting with the Session Manager (SM).

Each MN shall perform the following operations for an MMC session:

Service subscription to the MMC services, before an MMC session is activated;

Joining and leaving an MMC session by contacting with SM;

Status reporting (membership and QoS) to the Session Manager; and

Mobility (handover) support by movement in the network.

For the MMC session, only the authenticated or pre-subscribed users will be allowed, which will be checked in the session join phase.

11

7.1.2 MULTICAST CONTENTS SERVER (MCS)

Multicast Contents Server (MCS) is a single multicast data sender in an MMC session. When an MMC session begins, the MCS starts to send the multicast data to the MNs using multicast or Overlay multicast transport.

7.1.3 SESSION MANAGER (SM)

Session Manager (SM) is a functional entity that is responsible for the overall control operations for an MMC session. The SM shall be interworking with the corresponding MCS for the MMC session. The SM may or may not be co-located with the MCS

The SM shall provide the following control operations for the MMC session:

Session creation and termination by interworking with MCS, by which the SM will keep the list of active sessions at the time;

Response to the request of session join from the MN; in this phase, the SM may perform an appropriate authentication and authorization procedures with the AAA server;

Status monitoring on active membership and perceived QoS of MNs.

The authentication and authorization step for a newly joining MN may be implemented by interworking with an appropriate AAA server, which is outside the scope of the MMC.

The SM may be implemented either on the same machine with MCS or separately on the different machine. It is noted that the SM and MCS perform the different functionality. SM manages the overall control functionality for the MMC session, whereas the MCS is the multicast sender in the data transport plane.

7.1.4 MULTICAST AGENT (MA)

This entity is used to relay the multicast data from the MCS to the MNs in the Overlay multicast network. In the Overlay multicast networks, some MAs will be deployed in the network, or dynamically configured by using the RMCP protocol mechanisms. In MMC, each MA performs the control operations (e.g., tree configuration, status monitoring) as well as the data transport operations (relaying the multicast data from the upstream MA to the downstream MAs). Details of MAs are described in the RMCP specification.

7.1.5 LOCAL MOBILITY CONTROLLER (LMC)

This entity is used in the multicast network only, not in the Overlay multicast, to control the mobility of the MNs locally in the access network. The Local Mobility Controller (LMC) is used to locally manage the session management in the access network, for enhancement of the scalability of the MMC functional operations. For this purpose, one or more LMCs may be deployed in the network. It is recommended that an LMC is deployed for each access network (one for each IP subnet).

For session management, when an MN contacts with the SM to join an MMC session, the SM may assign an appropriate LMC to the MN, after processing the session join procedure. After that (i.e., during the session), the MN will now contact with the LMC instead of the SM for all of the MMC operations.

In particular, the LMC will perform the following control operation for MMC:

Status monitoring on active membership QoS

Mobility (handover) support for the moving MNs during the session

During the session, the LMC is responsible for the control operations (status monitoring and mobility support) through interworking with the MNs. The monitored status information on the session and MNs will be delivered to the SM. It is noted that the LMCs are used for enhancing the scalability of the MMC scheme. As the number of MUs increases, the control overhead will get larger at the SM side. In particular, when the periodic messages are exchanged between SM and a large number of MSs, the control overhead will not be negligible.

12

7.2 REFERENCE CONFIGURATION OF FUNCTIONAL ENTITIES

This section provides an example reference configuration of the MMC functional entities described in the previous section. In the configuration examples, it is assumed that the MMC network is capable of the multicast data transport using IP multicast or Overlay multicast.

7.2.1 CONFIGURATION IN MULTICAST NETWORKS

The following figure shows an example network configuration of the MMC functional entities; MN, SM, MCS, and LMC. It is noted in this figure that the network entities are hidden such as multicast routers.

Mobile Backbone Network

PoA

MN

MCS

MN

SM

LMC

Interworking

Control Channel

LMC

Wireless Access Network Wireless Access Network

PoA

Handover

Multicast Data Transport Channel

MR MR

Figure 4 – Reference configuration of MMC functional entities in the multicast networks

As shown in above figure, in the multicast networks, the data transport will be done between Multicast Contents Server (MCS) and Mobile Nodes (MNs) with the help of the Multicast Routers (MRs) in the network. On the other hand, the MMC control operations, which include Session Join, Status Monitoring, and Mobility Support, are performed between Session Manager (SM), Local Mobility Controller (LMCs) and MNs. The SM shall be interworking with the MCS by using a dedicated channel for MMC operations, which is outside the scope of the MMC.

In Session Join, each MN will contact with SM, and the SM informs the MN about the corresponding LMC for the MN. The MCS will transmit the multicast data to the MNs over multicast networks. In Session Monitoring, each MN gives status report messages to the LMC, which will be aggregated and forwarded to the SM.

For mobility support, when the MN detects its movement, it will inform the LMC for mobility control. The MN’s movement types include the change of PoA (at link layer) or MR (IP layer). The information of such movement will be used to support seamless handover by the LMCs, and the LMC will interwork with the neighboring LMC for this purpose.

13

7.2.2 CONFIGURATION IN OVERLAY MULTICAST NETWORKS

Figure 5 shows an example network configuration of the MMC functional entities over overlay multicast networks, which include MCS, MA, MN, SM, and LMC. MA can be categorized by MA in wireless access network (MMA) and MA in relayed multicast backbone network. As shown in figure, one MMA can handle one or more wireless access network. It is noted in this figure that the network entities are hidden such as multicast routers and MA can be implemented as an end-system, server, or hardware set-top box; the ways of implementing MA are out of this document’s scope.

MNMNMN

Figure 5 – Reference configuration of MMC functional entities in the overlay multicast networks

As shown in the figure, in the multicast networks, the data transport will be done between Multicast Contents Server (MCS) and Mobile Nodes (MNs) with the help of the Multicast Agents (MAs) in the network.

On the other hand, the MMC control operations, which include Session Join, Status Monitoring, and Mobility Support, are performed between Session Manager (SM), Local Mobility Controller (LMCs) and MNs. The SM shall be interworking with the MCS by using a dedicated channel for MMC operations, which is outside the scope of the MMC.

In Session Join, each MN will contact with SM; for the data delivery purpose, the SM gives information for MA join to the corresponding MN, and for the control purpose the SM informs the MN about the corresponding LMC for the MN. The MCS will transmit the multicast data to the MNs over relayed multicast networks. In Session Monitoring, each MN gives status report messages to the SM or to the LMC (if any), which will be aggregated and forwarded to the SM.

For mobility support, when the MN detects its movement, it changes MMA and then it will inform the LMC for mobility control. The MN’s movement types include the change of PoA (at link layer) or MA (over IP layer). The information of such movement will be used to support seamless handover by the LMCs, and the LMC will interwork with the neighboring LMC for this purpose.

14

7.3 MMC FUNCTIONALITY

In MMC, each MN shall subscribe the specific MMC services (e.g., IPTV services). Each MMC services may include a pre-configured set of MMC sessions (or channels). That is, an MMC services may provide a group of multicast sessions and channels. For example, the IPTV services may provide several IPTV channels for the users, and each channel may also deliver a set of TV programs (sessions), depending on a pre-configured program schedule.

The information on the subscription of the individual users to the configured MMC services shall be recorded into an appropriate database (e.g., user and services profile), which shall in turn be used in the Session Join to check whether a specific MU is allowed and authorized for the use of the services or session.

In MMC, it is assumed that such information (with database) will be configured into the database and referred to by the AS in the Session Join phase. The database shall have the information on mapping between an MU and a specific session (services). The Services Subscription may be performed in the on-line or off-line manner between service provider and promising MUs, before the session starts.

The Services Subscription may include Session Announcement by way of an out-of-band signaling (e.g., via Web announcement) and an appropriate subscription step (e.g., on-line user/service registration). The more detailed mechanisms for Service Subscription and Session Announcement are outside the scope of the MMC.

The MMC will be designed to support the following functionality:

Multicast data transport;

Session Join and Leave;

Status monitoring for active membership and QoS;

Mobility support by handover of MN.

7.3.1 MULTICAST DATA TRANSPORT

When an MMC session starts, the MCS begins to transmit the multicast data to the MNs that have joined the session, as per of the pre-configured session (program) schedule, which is called ‘Session Start’. The multicast data transport will be performed using IP multicasting or Overlay multicasting. After completion of the multicast data transport may stop the session, which is called ‘Session Stop’.

In MMC, the SM shall be informed about the session-specific information (e.g., session start and stop, the schedule of the multicast data delivery) via an out-of-band channel with the MCS.

7.3.2 SESSION JOIN AND LEAVE

When an MMC session starts (i.e, the multicast data transport begins), the subscribed MNs will join the MMC session so as to receive the data (contents) from the MCS. When a session starts, an MN will join the session by sending the join request messages to the SM. The SM may accept the join request with referring to the relevant AAA server together with associated user profile database. In MMC, Session Join operation will be done only between SM and MN.

After joining the session successfully, each MN can receive the multicast data packets sent by the MCS. On the other hand, the additional MMC functional entity could be assigned to the MN: MA or LMC.

In the Overlay multicast network, an MA will be dynamically or statically assigned to the MN, which is called ‘Tree Configuration’. The MA will relay the multicast data from the MCS to the MNs. Depending on the tree configuration scheme, more than one MAs may be involved in the relay multicasting. That is, two or more tree levels could be configured along the path from the MCS to the MN.

In the multicast network, an LMC will be assigned to the MN for the purpose of status monitoring and mobility support.

It is noted that some of the MNs may leave the session before the session stops.

15

7.3.3 TREE CONFIGURATION IN OVERLAY MULTICAST NETWORK

This section describes how data delivery tree is configured and then managed in relayed multicast network.

For the first time, SM generates new session information; the information includes characteristics of media, session, authenticate and so on. In addition, SM waits for subscription from the MA and MN; MA means MA itself as well as MMA.

Each MA and MN subscribes SM; the location of SM is already informed. SM then responds to the subscription for indicating whether the requester is qualified. If the subscription is successful, it gets a list of MA from the SM. It means rather than SM’s specification for the best upstream MA, each chooses the best parent. It then connects the chosen MA as its upstream MA. Sometimes this trial of connection can be fail, because of the rack of the chosen MA’s resource.

After the successful joining, the MN can begin to receive application data from sender by invoking its data transport module. And when an MN wants to leave the session, it gives notice to its MMA.

Once a data channel has been established successfully, periodical relay request and its response will be exchanged between the two peers (MN-MMA, MA-(M)MA) periodically. This is done for fail detection and data delivery path maintenance. If an upstream peer detects that one of downstream peer is failed, the upstream peer will stop data transmission to the downstream peer.

The topology of relayed multicast tree for the first time can be changed during the time; by the failure of some MAs or connection; by the new joiner or an early leaver. The change in data delivery topology can cause path failure such as partition or path loop. Therefore, it is necessary for each MA to maintain the data delivery path. To keep the topology healthy the following fault detection mechanisms should be provided:

Loop detection & avoidance

Partitioning detection & recovering

Parent switching

Session monitoring is used for SM to monitor session status such as membership dynamics and QoS perceived by MAs. The status report request and its response are exchanged between SM and the rest (MA, MMA, and NM). The SM can ask a specific node to report its status. The functions for session monitoring are:

Report the status of data channel: data throughput, etc.

Membership gathering

Topology information gathering

For mobility support in relayed multicast the followings should be considered:

Leaf MN’s movement

MN’s fast and seamless handover

To support leaf MN’s movement, it is required to enable other entities to detect the MN’s movement. It is required to find new MMA as quickly as possible to provide continuous multicast service to the moving MN. Also because each MMA pushes multicast data stream to leaf MNs, it is required for each MN to subscribe new MMA and to leave current MMA as soon as possible. Because forwarding multicast data to empty multicast area may cause resource waste.

To communicate between MMA and MN, it is required to have wireless communicating channel between them to exchange control message between them. Some of the possible ways of communication will be mobile IP, DHCP and so on. To make each MN can attach the tree more smoothly; it is required to have efficient mechanism to enable fast tree attachment.

When an MN tries to switch MMAs (old MMA and new MMA) there can be some data loss in forwarding data. This data loss causes temporal suspension of streaming video. Therefore it is required to have efficient mechanism for seamless handover.

When an MN moves the overlapped area, where two MAs (old MA and new MA) transmit multicast data at the same time, the MN may receive duplicated data from them. The duplicated data causes temporal distortion of streaming video. Therefore it is required to have efficient mechanism for duplication avoidance.

16

7.3.4 STATUS MONITORING

After the session starts, the SM and MNs shall perform the Status Monitoring possible together with intermediate MAs or LMCs. The status information includes the active membership (i.e., a list of active MNs for the session) and the QoS status (e,g., how much data loss or throughput each active MU has experienced for the multicast data).

To collect such the status information, some control messages might be periodically exchanged between SM, MA/LMC and MN. Those status report messages will include the following information:

Membership ID of the MU;

QoS measurements such as throughput, delay, and packet loss rate, etc.

7.3.5 MOBILITY SUPPORT

Different from the conventional multicast scheme, the MMC is featured the support of mobility (handover) of the MU. In the mobile networks, each MU may move its location in the network during the MMC session, which is called ‘handover’. The MMC shall support this mobility by providing the seamless services against the movement of MUs.

The type of handover by movement is classified into Link-layer handover (L2 handover) and Network-layer handover (IP handover). The L2 handover occurs when the MN changes its PoA in the network, whereas the L3 handover is associated with the change of IP subnet (and change of the IP address of the MN). Typically, the L3 handover will include the L2 handover in the mobile networks.

The IP handover can also be divided into the following two scenarios:

a) horizontal handover within the homogeneous (same) access network (e.g., within WiBro network); and

b) vertical handover across heterogeneous (different) access networks (e.g., between WiBro and WLAN).

In the horizontal handover, when the MN is moving to another subnetwork region, it may change its physical PoA in the mobile network and/or changing its IP address. In this case, the MN is required to report this handover event to its associated MMC agents such as MA or LMC. This report message may include the information of the new PoA and IP address in the new network. It is noted that this report message could ensure that the MU does not need to perform the authentication process again after moving the new network.

In the vertical handover, the MN may have the multiple network interfaces. That is, the MN will be in the multi-homing state in the overlapping region during the handover. The MMC protocol shall be designed to support the handover of MN, which includes the L2/L2 handover and horizontal and vertical handover.

17

8. HIGH-LEVEL INFORMATION FLOWS

Based on the functional architecture of MMCF described so far, this section describes the high-level information flows between the MMC functional entities. The detailed messages and procedural flows will be described in the MMC protocol specification.

8.1 SERVICES SUBSCRIPTION AND SESSION ANNOUNCEMENT

To benefit from the MMC services, each promising user shall first subscribe the specific services provided by the service provider. The MMC services may consist of a group of MMC sessions (programs) in the form of the services package. This operation can be viewed as the services contract between the service provider and users. As per the pre-defined session schedule, the service provider shall announce the specific sessions to the users.

In the services subscription phase, the service provider shall register the subscription-specific information with the associated user/services profile database. This database will be used for authentication process in the session join phase.

As per the pre-configured session (program) schedule, the service provider shall announce the information on the specific sessions in the session announcement, which may specify the following session-specific information:

Session ID

Start/stop time of the session

IP address (and port number) of the SM that is managing the session

Others such as the specific coding scheme on the application services, etc

For example of the IPTV services, this information may be delivered to the users through the Electronic Program Guide (EPG). The detailed mechanisms for Services Subscription and Session Announcement are outside the scope of the MMC.

8.2 MULTICAST DATA TRANSPORT

The MCS will start the multicast data transport for an MMC session, as per the pre-defined program schedule. The MCS may use the IP multicast or Overlay multicast for the multicast data transport. The MCS will also stop the multicast data transport for an MMC session, as per the pre-defined program schedule.

The following figure shows the data flows for the multicast data transport.

MCS MAMR or MAMR or MA

Data

Data

Data

Data

Figure 6 – Multicast Data Transport

18

8.3 SESSION JOIN AND LEAVE

The Session Join is an operation for a promising use (MN) to join a specific session announced by the service provider. Based on the information of the session and SM, which was provided in the session announcement, the MN will try to join the session.

Figure 7 – Session Join in MMC

In Session Join, the promising MN shall first send a session join request message to the SM. It is noted that the contact information of the SM (IP address and port number) shall be announced in the session announcement phase. The join request message shall include the following information:

Session ID

User ID

On reception of the join request message from the promising MN, the SM will contact with the associated AAS service to check whether it is an authenticated and authorized user or not. The resulting response message will be sent to the promising MN by the SM, which may include the following information:

Whether the request is accepted or not;

Others specific to the session, if required.

Some of the active MNs may leave the session before the MCS stops the session.

8.4 CONFIGURATION OF MMC AGENTS

8.4.1 CONFIGURATION OF LOCAL MOBILITY CONTROLLER FOR MULTICASTING

In multicast networks, in the Session Join phase, the SM shall assign an appropriate LMC (Local Mobility Controller) to the MN. The LMC will perform the protocol operations associated with the status monitoring and mobility support for the MN.

TBD

Editor’s Note: Some more figures or texts are needed to describe the LMC configuration.

8.4.2 TREE CONFIGURATION FOR OVERLAY MULTICASTING

In relay multicast network, when the MN join the session, its parent MA shall be configured, which is called “Tree Configuration for Overlay multicasting.” The MA will relay the multicast data from the MCS to the MN, and also perform the control operations such as status monitoring, tree reconfiguration, mobility support for the MNs.

19

TBD

Editor’s Note: A more detailed description of RMCP tree management operations may be added in this section.

8.5 STATUS MONITORING

The MA/LMC shall monitor the status of the active MNs. For this purpose, some control messages might be exchanged between MA/LMC and MN. Each MA/LMC will then aggregate the status information to the SM.

The following figure shows an abstract flow of status monitoring in the MMC.

Figure 8 – Status Monitoring in MMC

This status information may typically include the following information:

MN’s ID

QoS measurements such as throughput, delay, and packet loss rate, etc.

The membership information (MN ID) may be used as the charging data by the service provider. On the other hand, the QoS information may also be used for charging by the service provider, and also for adjustment of the sending rate of the multicast data by the MCS.

8.6 MOBILITY SUPPORT

When an MN moves into the other new network region, and thus it change its PoA and IP subnet, the MMC handover operations will be done. The handover signaling operations for handover support might be performed between MN and MA (or LMC), and between the two neighboring MAs (or LMCs). The objective of the handover support is to minimize the handover latency and data losses during the handover period.

The handover request message may include the following information:

MN ID

Information on the location of the new PoA or IP subnet

The following figure shows an abstract flow of handover signaling in the MMC networks.

20

Figure 9 – Handover signaling operations in MMC

As shown in the figure, the old MA/LMC may need to communicate with the new MA/LMC to support the seamless handover, which may be helpful to ensure that the MN does not need to perform the re-authentication process in the new access network.

The handover procedures may depend on the type of the underlying network: multicast or Overlay multicast networks. The detailed operations for handover support will be described in the MMC protocol specifications.

9. SECURITY CONSIDERATIONS ON MMC

This section describes the security considerations on MMC.

Editor’s Note: The texts in this section need to be reviewed and more enhanced.

9.1 GENERIC SECURITY REQUIREMENTS

The following requirements will be considered in the mobile multicast communications.

a) Fast user authentication – The mobile user should be authenticated from a new relayed server system whenever movement.

b) Relay Management by movement – A new group key needs to be created and distributed at movement of a mobile node to other MA’s region.

c) Group Management by movement – A mobile node should be verified at joining the group by movement.

d) Location-information Concealment by movement – Location-information can be revealed by an abnormal user at movement of a normal user, it needs for the administrator to provide a management of the information

9.2 SECURITY REQUIREMENTS ASSOCIATED WITH MMC FUNCTIONALITY

Editor’s Note: The description below is given specific to the RMCP. This needs to be more generalized for MMC-2 and MMC-3.

The main functions are following these for security. Furthermore, the security procedure recommends performance-oriented design for seamless service. It assumes that the MA to be an intermediate node of RMCP tree is a dedicated MA(dMA) for its trusty. For mobility, there are some functions such as Fast Delegated

21

Authentication, Adaptive Group and Group key Management, Efficient Data En/Decryption, Tunneled Packet Management, Reliable Group key Transmission, Reliable Transport, Loss-free Source/Message authentication. The mandatory requirements of above them are as bellows;

In the MMC functionality point of view, the following requirements shall be considered:

a) Fast Membership Authentication

It recommends support of a delegated authentication mechanism for seamless data service despite movement of the receive node to another area. Also, the locating information should be not tracked by any node except the trust node. RMA delegated-authentication: When RMA moves to another dMA during play of the service, it

should be re-membership-authenticated by the new dMA. For efficient authentication, the re-authentication should be performed fast. So the fast delegated authentication procedure should be done.

b) Adaptive Group and Group key Management – The trust node should understand status of node, which moves from/to its region, or joins/leaves its group. So it should guarantee efficient group key update procedure relying on events of movement and join/leave.

Adaptive Group Management – It may need to classify member property that is static and dynamic member if a mobile node moves frequently. The static member is a fixed RMA or mobile node with no movement for a while. And the dynamic one is a mobile node with frequent movement before expire of timer.

Adaptive Group key Management – It may manage two group keys. One is a group key for the static member, another is one for the dynamic member if group member is classified into above a)

c) Reliable Group key Transmission – The group key is very important information, however the information can not be received caused by network unstable condition or mobility of the RMA. So it is required to transmit group key reliably.

Reliable Transport – this procedure may be required in case that the group key is transmitted using multicast technique, or to a moving node. When any node moves to another dMA while forwarding the new group key, the dMA needs to retransmit group key to the moved member despite TCP transmission is used.

d) Efficient Data En/Decryption – The streaming data should be confidential with no effect on playing data, especially the data should be securely transferred and played in spited of movement of the receive node.

Efficient Data en/decryption procedure – Main service contents will have big size, so it is efficient that intermediate nodes perform simple decryption and re-encryption of the contents for verification of the message, and forward them to next node. This results in transport inefficiency. So efficient contents protection procedure is required.

22

APPENDIX A. FURTHER SECURITY ISSUES ON MMC

This Appendix is purposed to describe the further security issues associated with the MMC.

Editor’s Note: The texts in this section need to be further reviewed and enhanced.

A.1 CONCEPTUAL REQUIREMENTS The requirements are categorized by two groups of which one is necessary requirement group and another is optional requirement one. The optional requirement one has b), f), h ) and k) and others belong to the necessary one.

a) Confidentiality – The important signal and data messages should be encrypted over network.

b) Integrity – A receiver should be able to verify whether the message is forged or altered.

c) Source Authentication – A receiver needs to be verified the message originality from a normal source.

d) Access Control – It needs to be controlled to access the session by one more than administrators.

e) Rekey Management – A new group member can not read messages sent before joining the group (Forward Secrecy). A leave member can not read message sent after leaving the group (Backward Secrecy).

f) Dynamic secure group management – If the group is closed group and the fact of group existence needs to be secure, the group management should be securely performed together with session advertisement of the group by one more than admitted administrators.

g) Vulnerability to Bidirectional Tunnelling of Data – If tunnelling of packet is used for a mobile user, the inner and outer tunnelled packet header information should be verified.

h) User Authentication – A new member who subscribes the group should be verified by the administrator.

A.2 FUNCTIONAL REQUIREMENTS

The requirements are categorized by two groups of which one is general and another is mobility-oriented one. The mobile specific one is from d) to i) and others belong to the necessary one.

a) Secure RMCP Tree Configuration – Since intermediate tree members are responsible for relaying data to their leaves, the nodes should be trust, and configure securely their parent and child. This process should be performed lightweight because every node subscribing the RMCP session has been authenticated by SM.

dMA tree-authentication – The parent node should verify its candidate child node if the child node requests to join the tree to its one of candidate parents. Also, the child node may verify its candidate parent.

SMA tree-authentication – SMA should be verified by SM because it is a node to be root of RMCP Tree

b) User Authentication - The security protocol should be equipped with verification ability for justifiable node that wants to subscribe the RMCP session.

dMA session-authentication – If RMA requests dMA to join a service group or SM notifies subscription of a RMCP session, the dMA should perform session-authentication procedure for sharing common security parameters between dMAs together with SMA in the RMCP session.

SMA session-authentication – A specific node that wants to provide the data such as streaming data or reliable data should be authenticated by SM. Then the SM creates a RMCP session with the SMA as a source node.

RMA session-authentication- Any node who wants to receive a service contents of a RMCP session should be verified by SM

23

c) Membership Authentication – When a receive node joins a group, the protocol needs to checks service authority and justifiability of the node for authenticity of the group. This procedure is more lightweight than session-authentication.

RMA membership-authentication- When RMA requests its dMA to join the service group, the dMA should verify authenticity of the RMA.

dMA membership-authentication- The RMA may authenticate whether dMA is authenticated node from SM.

d) Tunnelled Packet Management – If the tunnelled packet is used, it needs to consider how to support the security for inner/outer header of the packet. The integrity and confidentiality are requested for two headers and data.

Verification of Inner and Outer packet header – The inner and outer packet header may be verified if packet tunnelling is used. It authenticates packet originality and integrity as verifying two headers.

e) Loss-free source/message authentication – In case of real-time streaming data, message loss may be a sensitive problem to normally verify message originality and integrity in time. So the source/message authentication endurable packet loss may be required.

Loss-tolerant source/message authentication – The SMA creates authentication code of message to send, and the authentication procedure may be packet-loss-free. In other words even though some parts of message is not received from the SMA, the receiver is able to verify the rest of the message.

f) Security Policy – This function is commonly required like X.603.1/Draft Amd.1. The function determines which security algorithm is used, which security mechanism is applied and so on.

Security Agreement – The all entities agree security mechanisms, algorithms and following parameters to share between them in a RMCP session

Security Policy Establishment – The SM determines security strength and which security functions is applied depending on the security strength for a RMCP session

g) Administrative group-key management- The key is for administrators such as SM and dMAs in a RMCP session.

Initial key Distribution – SM sends the administrative servers the initial key materials.

Administrative-group-key Update – The administrative servers and SM updates the administrative-group-key depending on the established and agreed security policy.

h) Access Control List management- The list is used to control session access in a RMCP session. Access Control list distribution – The SM creates and distributes the access information list of

admitted users to dMA in a RMCP session.

Access Control list update – The dMA requires to updats ACL list to keep recent status of the list from SM.

24

APPENDIX B. EXAMPLES OF SERVICE SCENARIOS WITH MMC This Appendix is purposed to provide one or more examples of MMC services scenarios. Typical services examples may include the “IPTV over MMC Networks,” which is a multimedia TV multicasting services using the Electronic Program Guide (EPG). Such the IPTV services may be provisioned over wireless mobile networks as well as fixed networks. This Annex will describe how those services could be provided in the perspective of MMCF.

TBD

Editor’s Note: Relevant contributions are invited.

25

APPENDIX C. MMC CONFIGURATION IN THE WIBRO NETWORKS

This Appendix is purposed to provide a reference configuration of MMC functional entities in the WiBro (Wireless Broadband, also as known as mobile WiMax) networks, with the relationship between MMC functional entities and the Wibro network entities.

TBD

Editor’s Note: Relevant contributions are invited.

26

BIBLIOGRAPHY The following IETF RFCs could be used as reference materials that provide useful information for understanding of this Recommendation | International Standard.

a) IETF RFC 3569, Overview of Source-Specific Multicast(SSM), Informational, July 2003

b) IETF RFC 3973, Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised), Experimental, January 2005

c) IETF RFC 3228, IANA Considerations for IPv4 Internet Group Management Protocol (IGMP), BCP, February 2002

d) IETF RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) for IPv6, Standard Track, June 2004

e) IETF RFC 3171, IANA Guidelines for IPv4 Multicast Address Assignments, BCP, August 2001

f) IETF RFC 3170, IP Multicast Applications: Challenges and Solutions, Informational, September 2001

The following 3GPP Technical Specifications could be used as reference materials that provide useful information for understanding of this Recommendation | International Standard.

a) 3GPP TS 22.246, MBMS User Services, September 2004

b) 3GPP TS 23.246, MBMS Architecture, June 2005

c) 3GPP TS 25.346, MBMS in RAN: Stage 2, June 2005

d) 3GPP TS 26.346, MBMS Protocols and Codecs, June 2005

e) 3GPP TS 33.246, Security of MBMS, June 2005

The following 3GPP2 documents could be used as reference materials that provide useful information for understanding of this Recommendation | International Standard.

a) 3GPP2 S.R0030-A, Broadcast/Multicast Services – Stage 1, January 2004

b) 3GPP2 S.S0083-A, Broadcast Multicast Security Framework, August 2004

c) 3GPP2 X.S0022, BCMCS in cdma2000 wireless IP network, December 2004

d) 3GPP2 A.S0019, Interoperability Specification for BCMCS, Decmeber 2004

e) 3GPP2 C.S0054, cdma2000 High Rate BCMCS Packet Data Air Interface Specification, July 2005

27