IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-10-0019-00-bcst Title: 802.21b Proposal Date Submitted: January 13, 2010 Presented at IEEE 802.21 session #36 in San Diego (La Jolla) Authors or Source(s):  Catherine Livet (InterDigital), Juan Carlos Zuniga (InterDigital) Abstract: This document provides an overview of the different broadcast architectures for discussion purposes 21-10-0019-00-bcst

IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.21. The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf>  21-10-0019-00-bcst

8 Uses Cases (21-09-0041-04-bcst) Coverage extension Load balancing Use Case 1: Traditional broadcast scenario Use Case 2: On-demand scenario Use Case 3: Indoor coverage scenario Load balancing Use Case 4: Number of unicast subscribers justifies setting up a broadcast service to hand them over Return channel Use Case 5: Support for interactive services (Setting up a return channel when needed) Use Case 6: Handover from DO technology to bidirectional technology for video playback control Program Availability Use Case 7: HO from one technology to another where the program is available Use Case 8: Due to a predefined schedule, a program is no longer available on the specific technology, and the user wants to keep watching the particular program, e.g. extra time on a sports match. The network can provide an identifier so that this program can be continued on a different technology. 3 for coverage extension Use Case 1: Traditional broadcast scenario E.g. DVB coverage extended by using the 3GPP to get the same broadcast service Use Case 2: On-demand scenario E.g. DVB coverage extended by using the 3GPP to get the same interactive service Use Case 3: Indoor coverage scenario E.g. DVB coverage extended by using the WiFi network to get the same broadcast service in an indoors environment where DVB signals are weak 1 for load balancing Use Case 4: Number of unicast subscribers justifies setting up a broadcast service to hand them over 2 for return channel Use Case 5: Support for interactive services Setting up a return channel when needed or when the current one becomes unavailable Use Case 6: Handover from DO technology to bidirectional technology for video playback control A program is provided on the DO technology but a playback of the same program requires the use of a different radio access technology 2 for Program Availability Use Case 7: A user moves into a DO coverage area where the current program is not available anymore and handing over to a different technology is required in order to continue the program Use Case 8: Due to a predefined schedule, a program is no longer available on the specific technology, and the user wants to keep watching the particular program, e.g. extra time on a sports match. The network can provide an identifier so that this program can be continued on a different technology. 21-10-0019-00-bcst

21b Architecture MIHF Server can be co-located or not with SD or SM MIHF needs to interface with SM/SD SD and SM are considered as a New MIH Users interfacing trough MIH_SAP. MIH Protocol Messages Need to be updated to relay the SD or SM related information to the MIH Client Need to be updated to support MIH Multicast messaging 21-10-0019-00-bcst

Example of DBV-H / 3GPP MBMS HO 21-10-0019-00-bcst

OMA BCAST Architecture Source : http://www.dvb-h.org/PDF/tr_102469v010101p.pdf 21-10-0019-00-bcst

IPDC over DVB-H 21-10-0019-00-bcst Source : http://www.dvb-h.org/PDF/tr_102469v010101p.pdf 21-10-0019-00-bcst

MBMS Service Activation Source 3GPP TS 23.246 21-10-0019-00-bcst

Program Availability (1/2) Prior to HO to a new technology, the IP stream needs to be established (if not yet setup) on the destination network MIHF informs the Service Interface that program needs to be established MIHF can be either on the Client or on the Server, depending of the type of HO (Mobile Initiated or Network Initiated) It is up to the MMP to ensure proper setup If the program cannot be setup on the Dest network, MIHF has to let the Video Application know that the program is not available anymore.

Program Availability (2/2) Mobile Initiated HO Network Initiated HO 21-10-0019-00-bcst