ISO/IEC 24793-2:2010

Information technology — Mobile multicast communications: Protocol over native IP multicast networks — Part 2:

ISO/IEC 24793-2:2010 specifies mobile multicast control protocol (MMCP) over native IP multicast networks for mobile multicast communications. The MMCP can be used to support a variety of multimedia multicasting services in the IP-based wireless mobile networks. The MMC is targeted at the real-time one-to-many multicast services and applications over mobile communications networks. ISO/IEC 24793-2:2010 specifies the procedures and packet formats of the MMCP protocol.

Technologies de l'information — Communications de diffusion groupée mobile: protocole sur des réseaux natifs IP de diffusion groupée — Partie 2:

General Information

• Status: Published
• Publication Date: 14-Dec-2010
• ICS: 35.100.70 - Application layer
• Technical Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Drafting Committee: ISO/IEC JTC 1/SC 6/WG 7 - Network, transport and future network
• Current Stage: 9060 - Close of review
• Start Date: 02-Sep-2027

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 24793-2
First edition
2010-12-15


Information technology — Mobile
multicast communications: Protocol over
native IP multicast networks
Technologies de l'information — Communications de diffusion groupée
mobile: protocole sur des réseaux natifs IP de diffusion groupée




Reference number
ISO/IEC 24793-2:2010(E)
©
ISO/IEC 2010

---------------------- Page: 1 ----------------------
ISO/IEC 24793-2:2010(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


COPYRIGHT PROTECTED DOCUMENT


©  ISO/IEC 2010
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published by ISO in 2011
Published in Switzerland

ii © ISO/IEC 2010 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 24793-2:2010(E)
CONTENTS
Page
Foreword .  iv
1 Scope . 1
2 Normative references . 1
3 Definitions . 1

4 Abbreviations . 1
5 Overview . 2
6 Considerations . 3
6.1 Protocol model . 3
6.2 Protocol entities . 3
6.3 Reference network configuration . 4
6.4 Messages . 5
7 Procedures . 5
7.1 Multicast data transport . 5
7.2 Session join . 5
7.3 User leave . 6
7.4 Status monitoring . 6
7.5 Handover support . 7
8 Packets . 9
8.1 Packet format and common header . 9
8.2 Parameter format . 10
8.3 Packets for session join . 12
8.4 Packets for user leave . 14
8.5 Packets for status monitoring . 14
8.6 Packets for handover support . 15
Annex A – Timers . 17
Annex B – State transition diagram . 18
Bibliography . 20



© ISO/IEC 2010 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC 24793-2:2010(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 24793-2 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 6, Telecommunications and information exchange between systems, in collaboration with
ITU-T. The identical text is published as ITU-T Rec. X.604.1 (03/2010).
ISO/IEC 24793 consists of the following parts, under the general title Information technology — Mobile
multicast communications:
⎯ Part 1: Framework
⎯ Part 2: Protocol over native IP multicast networks


iv © ISO/IEC 2010 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC 24793-2:2010 (E)
INTERNATIONAL STANDARD

RECOMMENDATION ITU-T
Information technology – Mobile multicast communications:
protocol over native IP multicast networks
1 Scope
This Recommendation | International Standard describes the specification of mobile multicast control protocol (MMCP)
over native IP multicast networks for mobile multicast communications. The MMCP can be used to support a variety of
multimedia multicasting services in the IP-based wireless mobile networks. The MMC is targeted at the real-time
one-to-many multicast services and applications over mobile communications networks. This
Recommendation | International Standard describes the procedures and packet formats of the MMCP protocol.
2 Normative references
The following Recommendations and International Standards contain provisions which, through reference in this 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 and Standards listed below. Members of IEC and ISO maintain registers of currently
valid International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of currently
valid ITU-T Recommendations.
– Recommendation ITU-T X.604 (2010) | ISO/IEC 24793-1:2010, Information technology – Mobile
multicast communications: Framework.
3 Definitions
This Recommendation | International Standard uses the terms and definitions that are defined in the MMC framework,
Rec. ITU-T X.604 | ISO/IEC 24793-1.
4 Abbreviations
For the purposes of this Recommendation | International Standard, the following abbreviations are used:
AAA Authentication, Authorization and Accounting
ACK Acknowledgement
ASR Aggregation Status Report
CTT Context Transfer Time
HCT Handover Context Transfer
HIC Handover Initiation Confirm
HIR Handover Initiation Request
HIT Handover Initiation Time
HTA Handover Transfer ACK
ID Identifier
IGMP Internet Group Management Protocol
JWT Join Waiting Time
LJC Local Join Confirm
LJR Local Join Request
LMC Local Mobility Controller
MCS Multicast Contents Server
MLD Multicast Listener Discovery
 Rec. ITU-T X.604.1 (03/2010) 1

---------------------- Page: 5 ----------------------
ISO/IEC 24793-2:2010 (E)
MMC Mobile Multicast Communications
MMCF MMC Framework
MMCP Mobile Multicast Control Protocol
MN  Mobile Node
MR Multicast Router
PoA Point of Attachment
QoS Quality of Service
SJC Session Join Confirm
SJR Session Join Request
SM Session Manager
SPT  Status Probe Time
SRT Status Report Time
TLV Type-Length-Value
ULC User Leave Confirm
ULR User Leave Request
USP User Status Probe
USR User Status Report
5 Overview
The MMCP provides the control functionality for multicast data channels: Session Join, Status Monitoring and
Handover Support. A multicast data session consists of an MCS (sender) and many MNs (receivers). The MCS will
transmit multicast data packets to many prospective receivers, according to a predetermined program schedule. To
receive the multicast data in the network, an MN will first perform the IGMP/MLD operations with the corresponding
access router in the IP subnet. The MMCP can be used for control of multicast sessions together with any multicast data
channels. The details of multicast data transport mechanisms are outside the scope of MMCP.
For Session Join, a prospective MN shall send a session join request message to the MMCP session manager (SM). The
join request message shall include the following information: Session ID and MN ID. MN ID is an identifier allocated
to the MN, which may be given a priori by a services provider. On receipt of the session join request message, the SM
shall respond to the MN with a session join confirm message. The responding confirmation message will indicate
whether the join request is accepted or not. In case that a local mobility controller (LMC) is allocated to the MN, the
session join confirm message will also contain the contact information of the associated LMC. In case that an LMC is
assigned to the MN, after receiving the join confirm message, the MN shall also join the designated LMC by sending a
local join request message. On receipt of the local join request message, the LMC shall respond to the MN with a local
join confirm message.
For User Leave, during the multicast session, an MN may want to leave the session. For this purpose, the MN may send
a user leave request message to the LMC (in case that an LMC is assigned to the MN) or to the SM (in case that no
LMC is assigned to the MN). The LMC (or SM) may respond to the MN with the user leave confirm message. It is
noted that this user leave operation is optional. That is, a certain MN may leave the session without any notice.
Status Monitoring is used by the SM to monitor the dynamics for group/session membership and the status of multicast
data channel (e.g., statistics such as total number of packets received during the session). For status monitoring, each
MN shall send a periodic status report message to its upstream LMC or SM (in case that no LMC is assigned to the
MN). Each LMC will aggregate the status information for its downstream MNs, and send a periodic aggregate status
report message to the SM. In the meantime, the status report messages may be lost in the network. In this case, the
upstream LMC or SM may solicit a status report message to the concerned MN or LMC by sending a status probe
message.
For Handover Support, after movement detection, the MN begins the handover operations by sending a handover
request message to the current LMC. The handover request message shall include the information about the new point
of attachment (PoA) such as the link-layer MAC address or ID of the PoA. On receipt of a handover request message
from the MN, the LMC will first identify which subnet the MN is going to move into. The current LMC can identify the
new LMC by using the address of the ID of the new PoA that is indicated in the handover request message. For
handover support, the current LMC shall send a handover context transfer message to the new LMC. Then, the new
LMC will perform the IGMP/MLD join operation to the new MR, instead of the MN. This will ensure that the MN can
receive the multicast data packets in the newly visited subnet as fast as possible. After that, the new LMC will respond
2 Rec. ITU-T X.604.1 (03/2010)

---------------------- Page: 6 ----------------------
ISO/IEC 24793-2:2010 (E)
to the current LMC with a handover transfer ACK message. In turn, the current LMC will send a handover confirm
message to the MN. This will complete the handover operation of the MMCP. After further movement, the MN will
complete the establishment of a new L2 and L3 connection (for a new IP address of the MN). Then, the MN performs
the local join operations with the new LMC.
6 Considerations
6.1 Protocol model
The MMCP is based on the mobile multicast communications framework (MMCF) specified in Rec. ITU-T X.604 |
ISO/IEC 24793-1. The MMCP is designed to support one-to-many real-time multicast applications running over IP
multicast-capable wireless/mobile networks. MMCP operates over IPv4/IPv6 networks with the IP multicast forwarding
capability such as the IGMP/MLD and IP multicast routing protocols. As a control protocol, the MMCP provides a
mobile user with the session join and user leave, status monitoring, and handover support for multicast data channels.
The MMCP is a control protocol that is used for control of the mobile multicast sessions over native IP multicast
mobile/wireless networks. It is assumed that the multicast data channels are provided with the help of the UDP/IP
multicasting in the network. That is, the MMCP is independent of multicast data channels, as depicted in Figure 1.
Multicast applications
MMCP
UDP
IP
X.604.1(10)_F01
Control channel Data transport channel

Figure 1 – Protocol model
A multicast data channel can use the MMCP protocol for the control of multicast sessions. For this purpose, the MMCP
provides a set of application programming interfaces (APIs) for any multicast data channels/applications. In the
protocol stack point of view, an MMCP message is encapsulated into the UDP datagram.
6.2 Protocol entities
This clause describes the protocol entities associated with the MMCP.
6.2.1 Mobile node (MN)
An MN represents an end user that receives multicast data transport services from multicast contents server. To receive
the multicast data from the network, the MN should be equipped with the multicast capability such as the IGMP/MLD
protocol. The MN is also required for the MMCP functionality. With the help of MMCP, an MN can benefit from the
control services such as session join, status monitoring, and handover support.
6.2.2 Multicast contents server (MCS)
In MMCP, an MCS represents the sender of the multicast data channel/session. The MCS will continue to transmit the
multicast data streams over the network, and a lot of MNs will receive the data packets after session join. The MCS is
associated with the multicast data channel only rather than the MMCP control channel. The MCS could exchange some
session-related information with the MMCP session manager, possibly using a dedicated communication channel,
which is outside the scope of this Specification.
6.2.3 Session manager (SM)
The SM is responsible for the overall operations of the MMCP. In Session Join, the SM will respond to the join request
of a promising MN. For authentication, the SM may contact with an AAA-related database or user profile that has been
preconfigured by services provider, which is outside the scope of the MMCP. In Status Monitoring, the SM will
monitor the overall status of the membership and session for all of the MNs. For this purpose, each MN will send
periodic control messages to the SM, possibly by way of a local mobility controller. The SM may be implemented with
the MCS on the same system, which is an implementation issue.
 Rec. ITU-T X.604.1 (03/2010) 3

---------------------- Page: 7 ----------------------
ISO/IEC 24793-2:2010 (E)
6.2.4 Local mobility controller (LMC)
The LMC is used to locally control the movement of the MN. In the mobile wireless networks, when an MN moves into
the other network region during the multicast session, the handover support is required for seamless multicast services.
The LMC is used to support the seamless handover for the MN in the wireless/mobile networks.
For handover support, the movement of the MN will be informed to the associated LMC. To provide the seamless
services, an LMC may interact with other LMCs that are newly visited in the network by the MN. With the help of the
LMC, an MN can be given seamless multicast services against handover. The LMC is also used for status monitoring of
the MNs. Each MN will send a periodic message to LMC, and the LMC aggregates the status of its downstream MNs
and forwards the aggregated status information to the SM. It is noted that an LMC acts as a network agent for MNs in
the MMCP.
It is assumed that a set of LMCs have been deployed in the wireless networks by the services provider.
6.3 Reference network configuration
Figure 2 shows a reference configuration of the MMCP entities in the network.
Interworking
SM MCS
Mobile
MR MR
backbone network
LMC
LMC
Handover
PoA PoA
MN MN
Wireless access network Wireless access network
X.604.1(10)_F02
Multicast data transport channel
Control channel

Figure 2 – Configuration of MMCP protocol entities
As shown in the figure, the multicast data channels operate between the MCS and the MNs with the help of multicast
routers (MRs) and point of attachments (PoAs) in the network. The MMCP operates independently of the data channels.
The MMCP operations are performed between the SM and the LMC, between the SM and the MN, and between the
LMC and the MN.
It is assumed that an LMC is located within the IP subnet controlled by an MR. For effective handover support, an LMC
needs to operate in the same IP subnet with the concerned MNs. In a certain case, an LMC may be implemented with an
MR over the same equipment, which is a deployment issue.
For mobility support, an MN detecting its movement will inform the LMC for mobility control. The MN's movement
types include the change of PoA (at the link layer) or MR (IP layer). The information on such movement shall be used
to support seamless handover by LMCs, in which the LMCs will interwork with each other and the new LMC interacts
with the corresponding MR.
4 Rec. ITU-T X.604.1 (03/2010)

---------------------- Page: 8 ----------------------
ISO/IEC 24793-2:2010 (E)
6.4 Messages
The protocol messages used for MMCP are summarized in Table 1.
Table 1 – Messages used in MMCP protocol
Message name Acronym Type value From To
Session Join Request SJR 0000 0001 MN SM
Session Join Confirm SJC 0000 0010 SM MN
Local Join Request LJR 0000 0011 MN LMC
Local Join Confirm LJC 0000 0100 LMC MN
User Leave Request ULR 0000 0101 MN LMC or SM
User Leave Confirm ULC 0000 0110 LMC or SM MN
User Status Report USR 0000 0111 MN LMC or SM
Aggregation Status Report ASR 0000 1000 LMC SM
LMC MN
User Status Probe USP 0000 1001
SM LMC or MN
Handover Initiation Request HIR 0000 1010 MN LMC or SM
Handover Context Transfer HCT 0000 1011 Old LMC New LMC
Handover Transfer ACK HTA 0000 1100 New LMC Old LMC
Handover Initiation Confirm HIC 0000 1101 LMC or SM MN
As described in the table, SJR and SJC are used for session join to the SM. LJR and LJC messages are used for local
join to the LMC. ULR and ULC are for user leave. The USR, ASR, and USP messages are used for status monitoring
during session. On the other hand, HIR, HCT, HTA, and HIC messages are used for handover support.
7 Procedures
7.1 Multicast data transport
The MCS will transmit multicast data packets to many prospective receivers, according to a predetermined program
schedule, as shown in the IPTV electronic program guide. The multicast data packets transmitted by an MCS will be
delivered toward many MNs over IP multicast networks with the help of the multicast routing protocols such as source
specific multicast (SSM) or protocol independent multicast (PIM), etc.
After session join, an MN can receive the multicast data packets from the MCS. The MN may be allowed to receive the
multicast data only after an appropriate authentication/authorization process with the SM, which is done in the Session
Join operation. To receive the multicast data in the network, an MN will first perform the IGMP/MLD operations with
the corresponding access router in the IP subnet.
The MMCP can be used for the control of multicast sessions together with any multicast data channel. The details of
multicast data transport mechanisms are outside the scope of MMCP.
7.2 Session join
Session join is the operation for MN to join a multicast session, as depicted in Figure 3.
MN
LMC SM AAA
Session Join Request
Authentication
(outside the scope)
Session Join Confirm
Local Join Request
Local Join Confirm
X.604.1(10)_F03

Figure 3 – Session join and local join
 Rec. ITU-T X.604.1 (03/2010) 5

---------------------- Page: 9 ----------------------
ISO/IEC 24793-2:2010 (E)
To join a session, a prospective MN shall send the SJR message to the SM. The SJR message shall include the
following information: Session ID and MN ID. It is assumed that the Session ID has already been informed to the
prospective MNs by using a different mechanism such as a web announcement. It is noted that the IP address and port
number of the SM will also be announced to the prospective MNs, which will ensure that the MN can send an SJR
message to the associated SM. The MN ID is an identifier allocated to the MN, which may be given by a services
provider associated with the multicast services. The SJR message can also include the information of the PoA attached
to the MN, which may be used for the SM to determine the best LMC for the MN.
On receipt of the SJR message, the SM shall respond to the MN with an SJC message. For this purpose, the SM may
first check whether the MN is an authenticated/authorized user by contacting with an associated AAA server, which is
outside the scope of the MMCP. The responding SJC message will indicate that the join request is accepted or not by
using a flag bit of the message. In the successful case, the SJC message shall include the information about the
corresponding multicast data channel: IP multicast address and port number. In case that an LMC is allocated to the
MN, the SJC message will also contain the IP address and port number of the associated LMC.
In the MN point of view, after sending the SJR message, the MN will wait for the responding SJC message for the join
waiting time (JWT). If the SJC message does not arrive at the MN during the JWT time, the MN concludes that the join
request has failed. The associated indication may be delivered to the upper-layer application, which is an
implementation issue.
In case that an LMC is assigned to the MN, after receiving the SJC message, the MN shall send an LJR message to the
indicated LMC. The LJR message shall include the MN ID. On receipt of the LJR message, the LMC shall respond to
the MN with an LJC message. The responding LJC message shall indicate that the local join request is accepted or not.
In the MN point of view, after sending the LJR message, the MN will wait for the responding LJC message for the join
waiting time (JWT). If the LJC message does not arrive at the MN during the JWT time, the MN concludes that the
local join request has failed. The associated indication may be delivered to the upper-layer application, which is an
implementation issue.
7.3 User leave
During the multicast session, an MN may want to leave the session. For this purpose, the MN may send a ULR message
to the LMC (in case that an LMC is assigned to the MN) or to the SM (in case that no LMC is assigned to the MN). The
LMC (or SM) may respond to the MN with the ULC message. In this case, the LMC may send an ASR message to the
SM so as to inform the changed group membership for the session. The User Leave operation is shown in Figure 4.
MN
LMC SM
User Leave Request
User Leave Confirm
Aggregation Status Report
X.604.1(10)_F04

Figure 4 – User leave
It is noted that this User Leave operation is optional. That is, a certain MN may leave the session without any notice to
its upstream LMC or SM. For example, an abnormal disconnection of the network may occur before the user leave
operation. In this case, the information of the user leave will be detected by the upstream node via the subsequent Status
Monitoring operations.
7.4 Status monitoring
Status monitoring is used to monitor the group membership of the session and the statistical status of the multicast data
channel. In Status Monitoring, each MN shall send a periodic USR message to its upstream LMC or SM (in case that no
LMC is assigned to the MN). Each LMC will aggregate the status information of its downstream MNs, and send a
periodic ASR message to the SM. Figure 5 shows the normal status monitoring operations in MMCP.
6 Rec. ITU-T X.604.1 (03/2010)

---------------------- Page: 10 ----------------------
ISO/IEC 24793-2:2010 (E)
MN
LMC SM
User Status Report
Aggregation Status Report
User Status Report
Aggregation Status Report
X.604.1(10)_F05

Figure 5 – User status report
While a session is active, each MN shall send a USR message to its upstream node for every status report time (SRT).
The SRT value may be locally configured. The USR will contain the information about the MN ID and the measured
statistics for multicast data channel such as the number of totally received packets and the elapsed time in the session.
To get the status of the data channel, the MMCP control channel may need to interact with the multicast data channel.
Such a detailed mechanism is outside the scope of the MMCP.
The LMC shall aggregate all of the status information from its downstream MNs, and it shall also send a periodic ASR
message to the SM according to its own SRT timer. The ASR message includes the status information of its
downstream MNs.
Depending on the network condition, a USR or ASR message may be lost in the network. In this case, the upstream
node will request the status report message to the concerned downstream node by sending a USP message, as shown in
Figure 6.
MN
LMC SM
User Status Report
Aggregation Status Report
User Status Probe
User Status Report
User Status Probe
Aggregation Status Report
X.604.1(10)_F06

Figure 6 – User status probe
As shown in the figure, when an upstream LMC has not received any USR message from an MN for the preconfigured
status probe time (SPT), it shall send a USP message to the concerned MN. The SPT value may typically be set to
'3 x SRT'. The MN shall respond to its upstream LMC with the USR message, as soon as it receives a USP message. In
a similar way, the SM may send a USP message to its downstream LMCs for status monitoring.
Nevertheles
...