Institut de la Francophonie pour l'Informatique

Institut Eurcom

Mmoire de fin dtudes

Intgration du protocole MBMS dans la plateforme TD-CDMA

Ralis par: NGUYEN Huu Nghia Promotion 9 IFI Sous la responsabilit de : Mme Michelle WETTERWALD Ingnieur de recherche senior linstitut Eurcom

Sophia Antipolis, Le 20 octobre

Table des matires

Table des matires .......................................................................................................................2 Liste des figures...........................................................................................................................5 Liste des tableaux ........................................................................................................................6 Remerciements ............................................................................................................................7 Rsum ........................................................................................................................................8 Abstract........................................................................................................................................9 CHAPITRE 1 - INTRODUCTION ...........................................................................................10 1. 2. 3. 4. Problmatique..............................................................................................................10 Motivation ...................................................................................................................11 Contribution.................................................................................................................12 Environnement de stage ..............................................................................................12

CHAPITRE 2 ETAT DE LART ...........................................................................................13 1. UMTS - Les rseaux mobiles 3G ................................................................................13 1.1. Historique..................................................................................................................13 1.2. Architecture gnrale du rseau UMTS....................................................................14 1.3. Le contexte international - Recherche et normalisation pour la 3G..........................15 2. Broadcast Multicast.....................................................................................................16 2.1. 2.2. 3. Gnralit ..............................................................................................................16 Le protocole 3GPP MBMS ...................................................................................17

Projet Daidalos ............................................................................................................20 2

3.1. 3.2. 4.

Une perspective pour les rseaux post 3G.............................................................20 Broadcast et Multicast dans le contexte du projet Daidalos..................................21

Plate-forme TD-CDMA ..............................................................................................22

CHAPITRE 3 VERS UNE PLATEFORME TD-CDMA MULTICAST ..............................25 1. 2. 3. Description ..................................................................................................................25 Adaptation du MBMS pour Daidalos..........................................................................28 Mise en uvre .............................................................................................................32 3.1. 3.2. Prparation pour une couche RRC multicast.........................................................32 Mise en uvre du RRC-RG ..................................................................................33

3.2.1. Initialisation.......................................................................................................33 3.2.2. Le squenceur....................................................................................................33 3.2.3. Les signaux de sortie .........................................................................................34 3.2.4. Simulation .........................................................................................................34 3.2.5. Interaction avec le NAS ....................................................................................35 3.2.6. Interaction avec le serveur RRM.......................................................................38 3.3. Mise en uvre du RRC-UE...................................................................................38

3.3.1. Initialisation.......................................................................................................38 3.3.2. Traitement des messages MBMS sur le canal MCCH ......................................39 3.3.3. Traitement des messages MBMS sur le canal DCCH.......................................39 3.3.4. La machine tats finis .....................................................................................39 CHAPITRE 4 EVALUATION...............................................................................................41 1. 2. Critres dvaluation ...................................................................................................41 Banc de test .................................................................................................................41

3. 4.

Rsultats esprs..........................................................................................................43 Rsultats observs .......................................................................................................44

Conclusions et perspectives.......................................................................................................47 Rfrences .................................................................................................................................48 Annexe A - Termes & Abrviations..........................................................................................50 Annexe B - La machine tats finis ct UE...........................................................................52 Annexe C Document de spcification (Anglais) ....................................................................57 Annexe D Document de conception (Anglais).......................................................................80

Liste des figures

FIGURE 1. LEVOLUTION DES RESEAUX DE TELECOMMUNICATION .........................................................................14 FIGURE 2. ARCHITECTURE DU RESEAU UMTS .......................................................................................................15 FIGURE 3. ARCHITECTURE LOGIQUE DU MBMS......................................................................................................18 FIGURE 4. PHASES D'UN SERVICE MBMS BROADCAST ............................................................................................18 FIGURE 5. PHASES D'UN SERVICE MBMS MULTICAST ............................................................................................19 FIGURE 6. UNE ILLUSTRATION EXEMPLAIRE DE LA RECEPTION D'UN SERVICE MBMS MULTICAST .........................20 FIGURE 7. INTEGRATION DE BROADCAST/MULTICAST DANS DAIDALOS ..................................................................21 FIGURE 8. EVOLUTION DU STANDARD 3GPP VERS PURE-IPV6 ................................................................................22 FIGURE 9. LA PILE PROTOCOLAIRE ..........................................................................................................................23 FIGURE 10. LES COMPOSANTS LOGICIELS DE LA PLATEFORME ................................................................................24 FIGURE 11. LA PLANIFICATION GENERALE ..............................................................................................................26 FIGURE 12. LA PLANIFICATION DE LA PREMIERE PHASE ..........................................................................................27 FIGURE 13. LA PLANIFICATION DE LA DEUXIEME PHASE .........................................................................................28 FIGURE 14. UNE ADAPTATION DU MBMS POUR DAIDALOS.................................................................................29 FIGURE 15. LES PRIMITIVES DUN SERVICE DANS LE MODE CONNECTION ................................................................31 FIGURE 16. DIAGRAMME DES CLASSES : LES PRIMITIVES DES SERVICES MMBS DE LA COUCHE RRC ....................32 FIGURE 17. DIAGRAMME DE SEQUENCE: ETABLISSEMENT DUN PTM RB................................................................36 FIGURE 18. DIAGRAMME DE SEQUENCE: RELACHEMENT DUN PTM RB ..................................................................37 FIGURE 19. RESULTAT DU TEST AU MODE NATIF .....................................................................................................45 FIGURE 20. RESULTAT DU TEST AU MODE DINTEGRATION - SIMULATION ...............................................................46

Liste des tableaux

TABLEAU 1 : ORGANISMES REGIONAUX PARTICIPENT AU 3GPP ............................................................................. 16 TABLEAU 2: PROTOCOLS BROADCAST ET MULTICAST ............................................................................................. 17 TABLEAU 3: REACTIONS DU UE POUR LA PROCEDURE JOIN .................................................................................... 30 TABLEAU 4: REACTIONS DU UE POUR LA PROCEDURE LEAVE ................................................................................ 30 TABLEAU 5: BANC DE TEST ..................................................................................................................................... 42 TABLEAU 6: SCNARIO DE TEST .............................................................................................................................. 42 TABLEAU 7: RESULTATS ESPERES COTE RG............................................................................................................ 43 TABLEAU 8: RESULTATS ESPERES COTE UE............................................................................................................ 44

Remerciements

En premier lieu, je tiens exprimer ma plus grande reconnaissance envers ma responsable de stage, Madame Michelle WETTERWALD qui a accept de m'accueillir en stage avec son quipe de recherche pour m'avoir permis de mener bien ce travail par ses conseils, ses remarques et ses suggestions. Je la remercie aussi pour son soutien, lencouragement qu'elle m'a donn pour faciliter mes conditions de vie Sophia, pour me familiariser avec la vie de l'quipe. Je tiens remercier Monsieur Christian BONNET, Directeur de lunit Communications Mobiles de lEurcom, pour son encouragement et sa sympathie pendant mon stage. Je tiens exprimer toute ma reconnaissance Monsieur HO Tuong Vinh, Directeur dtudes de lIFI (Institut de la Francophonie pour lInformatique), davoir prpar mon stage. Je remercie aussi vivement Monsieur Charles Durand, Directeur de lIFI, de mavoir bien favoris au cours de mon stage. Je remercie tous les membres de lunit Communications Mobiles encouragements, leurs conseils, leurs aides et la sympathie qu'ils m'ont donne. pour leurs

Depuis le dbut de mon stage en France, j'ai reu beaucoup d'aides et d'encouragements de mes amis. Tout cela me permet de mieux complter le stage. Je les remercie. Je voudrais galement remercier mes parents et ma sur qui m'encouragent normment depuis le dbut de mon stage en France. Enfin, un grand merci toutes les personnes de lInstitut Eurcom et de lIFI de mavoir aid au cours de mon stage.

Rsum

La nouvelle gnration de rseaux post 3G doit intgrer tous les rseaux existants, c'est--dire les rseaux de donnes de type Internet, les rseaux tlphoniques, que ce soit le rseau tlphonique commut ou le rseau cur dun oprateur de mobiles, et les rseaux de vido pour effectuer de la diffusion de tlvision ou de la vido la demande. En ce qui concerne le broadcast et le multicast, pour les rseaux de tlcommunication UMTS (Universal Mobile Telecommunications System) o les ressource radio et les ressources du rseau de cur sont vraiment limites, on doit recourir au protocole MBMS (Multimedia Broadcast Multicast Service) normalis par le 3GPP (3rd Generation Partnership Project). Ce rapport vise prsenter lintgration et les exprimentations du protocole MBMS dans la platforme TD-CDMA (Time Division Code Division Multiple Access) dEurcom dans le cadre du projet DAIDALOS (Designing Advanced network Interfaces for the Delivery and Administration of Location independent, Optimised personal Services ). Le rapport se compose de 4 chapitres et 4 annexes. Dabord, le chapitre 1 prsente le problme du Broadcast et du Multicast dans DAIDALOS et lenvironnement du stage. Ensuite, dans le chapitre 2, un tat de lart dans le domaine dtude sera prsent. Le chapitre 3 prsentera les dmarches faire pour produire une couche RRC (Radio Resource Control) multicast dans la plateforme TD-CDMA avec des adaptations ncessaires au protocole MBMS. Et puis, le chapitre 4 donne une valuation sur lintgration et les exprimentations sur ces adaptations. Lannexe A vous montrera des termes et des abrviations. Lannexe B reprsentera la machine tats finis ct UE (User Equipment) modlis avec Tllogic Tau Lannexe C est le document de spcification du protocole MBMS synthtis lEurcom Lannexe D est le document de conception . Mot cls: B3G, Broadcast, Daidalos, Multicast, MBMS, TD-CDMA, UMTS, 3GPP

Abstract

The new B3G network must integrate all existing networks: Enterprises, Multimedia and Telecommunications. In regard to Broadcast and Multicast in the UMTS (Universal Mobile Telecommunications System) telecommunications network where the radio resources and network resources are really limited, we have to use the MBMS (Multimedia Broadcast Multicast Service) protocol, which is standardized by the 3GPP (3rd Generation Partnership Project). This report aims to present the integration and the experimentations of MBMS protocol in the Eurecoms TD-CDMA (Time Division Code Division Multiple Access) platform within the scope of DAIDALOS project (Designing Advanced network Interfaces for the Delivery and Administration of Location independent, Optimised personal Services ). This report is composed with 4 chapters and 4 appendixes First of all, the chapter 1 presents the broadcast and multicast problems in DAIDALOS project and the working environment. In the chapter 2, A state of the art in the domain will be presented The chapter 3 presents the process to product a RRC (Radio Resource Control) multicast layer in the TD-CDMA platform with necessary adaptations to the MBMS protocol. The chapter 4 gives an evaluation on the integration and experimentations on the adaptations. The appendix A presents a list of terms and abbreviations used in the report The appendix B presents the UEs finite state machine modeled with Telelogic Tau The appendix C is the Eurecom's specification document of the MBMS protocol The appendix D is the Eurecom's design document. Key words: B3G, Broadcast, Daidalos, Multicast, MBMS, TD-CDMA, UMTS, 3GPP

Chapitre

1
CHAPITRE 1 - INTRODUCTION
1. Problmatique
Le rseau sans fil de troisime gnration (3G), fournit une bande passante plus leve, un accs linternet plus haute vitesse. Cela favorise normment des services multimdias. Au fur et mesure que les technologies et la socit changent, il y a une prolifration de technologies et de services pour les utilisateurs mobiles. Cela cre un environnement de communications complexe non seulement pour les utilisateurs mais galement pour les oprateurs. DAIDALOS est un Projet Intgr dans le cadre du FP6 (6th Framework Program) lanc au niveau europen et regroupe un grand nombre de partenaires. Il sadresse aux problmes d'htrognit des accs. Pour le multicast, par exemple, on doit assurer une diffusion de contenu multimdia sans interruption et indpendante du type de rseau que ce soit un rseau de diffusion, un rseau de tlcommunication ou un rseau sans fil dentreprise. Parmi ses 46 partenaires industriels et acadmiques, Eurcom joue un rle actif pour remplir les objectifs avec la plateforme radio logicielle TD-CDMA qui est dveloppe au sein du dpartement Communications Mobiles. L'utilisation dune technologie de radio logicielle permet de conserver des cots dquipements raisonnables, car principalement bass sur des quipements peu chers tels que des micro-ordinateurs PC. Dautre part, cela fournit un moyen idal pour mener des exprimentations en vraie grandeur dun systme radio mobile. Enfin, ces plateformes sont utilises pour valider des avances thoriques, en particulier dans le domaine trs prometteur des rseaux sans fil post 3G [35]. A lheure actuelle, la plateforme TD-CDMA reste encore un systme unicast conforme la norme 3GPP R4 [2]. Dans un systme unicast, il sagit des connexions de type point point entre le client et le serveur. Avec une augmentation des applications consommant normment de bande passante radio, et particulirement, avec un grand nombre dutilisateurs recevant le mme service haut taux de donnes, la distribution d'information efficace devient 10

essentielle. Pour rsoudre ce problme, le Broadcast/Multicast est utilis pour communiquer simultanment avec un groupe de terminaux identifis par une adresse spcifique. L'avantage de ce principe par rapport lunicast classique devient vident quand on veut diffuser de la vido. Le paquet n'est mis qu'une seule fois, et sera rout vers toutes les machines du groupe de diffusion. Cela assure une conomie des ressources radio trs pertinente dans les systmes mobiles [33]. Pour les rseaux locaux sans fils dentreprise, on utilise IP Multicast de lIETF comme solution. Pourtant dans un rseau de tlcommunication o les ressources radio sont vraiment limites, ce protocole ne conviendra pas comme il consommera encore normment de bande passante ainsi que lnergie pour la signalisation. Le protocole MBMS (Multimdia Broadcast Multicast Service) conu par le 3GPP, pour les systmes mobiles 3G, utilise la mme philosophie one to many et est ddi aux rseaux de tlcommunications mobiles. Ce nest donc pas tonnant quil faille intgrer le protocole MBMS dans la plate-forme afin doptimiser lusage des ressources radio, de se conformer lvolution de la norme 3GPP R6 (Release 6) et de satisfaire aux objectifs initiaux de la plateforme et aux exigences du projet Daidalos. La plateforme TD-CDMA est construite sur lide dune architecture Pure-IP [1] pour conserver des cots dquipements en tenant compte du but All-IP [7] des rseaux post 3G. Il reste donc une question sur ladaptation optimise du protocole MBMS la plateforme. De plus, ce protocole est en voie de normalisation, et il faut galement des exprimentations pour valider la stabilit du protocole. Dans le cadre du stage, jtendrai la couche RRC de la plateforme TD-CDMA et la rendra RRC-multicast conformant la norme 3GPP R6 [11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 37].

2. Motivation
En choisissant le sujet, jaurai une chance de contacter avec de grandes partenaires du projet Daidalos. Dailleurs, MBMS est actuellement un sujet la pointe de la technologie. En plus, je bnficierai dune formation au mtier de recherche et de dveloppement. Jai pu acqurir des mthodes de travail ainsi quune exprience de recherche grce aux responsables de stage et les collges dans l'quipe. Enfin, je me suis habitu au processus dune normalisation dun protocole. 11

3. Contribution
Ce document est le fruit de 7 mois de travail. Pendant ce temps, jai accompli toutes les tches concernant non seulement la partie thorique mais aussi la partie pratique. Sur le plan thorique, jai matris le protocole MBMS et la couche RRC de larchitecture UMTS. En plus, jai aussi suivi les compte-rendus des runions du 3GPP sur le protocole MBMS pour ladapter aux exigences du projet DAIDALOS sous la direction de madame Michelle Wetterwald. Jai aussi synthtis toutes les informations dans les documents du 3GPP concernant le protocole MBMS de la couche RRC dans un document de spcification dEurcom. Nous avons discut pour archiver une adaptation optimale au protocole MBMS, pour prvoir linteraction entre les composants de la plate-forme TDCDMA. Sur le plan pratique, jai implment le protocole MBMS qui peut fonctionner dans le mode natif (pour le test) ou dans le mode dintgration (pour le projet DAIDALOS). Les adaptations sont bien ralises et valides.

4. Environnement de stage
Le stage se droule pendant 7 mois ( partir du 21 mars 2005) lInstitut Eurcom, Sophia Antipolis, FRANCE. Le Parc scientifique de Sophia Antipolis s'affirme aujourd'hui comme le ple d'excellence europen dans le domaine des hautes technologies. C'est aujourd'hui le site le plus convoit, notamment par les entreprises du secteur des technologies de l'information. Quant Eurcom, cest une Grande Ecole internationale dIngnieurs et un Centre de Recherche en Systmes de communication, fonde par Tlcom Paris (Ecole Nationale Suprieure des Tlcommunications) et l'EPFL (Ecole Polytechnique Fdrale de Lausanne). Ce travail est ralis sous la direction de Mme Michelle WETTERWALD lunit Communications Mobiles qui est actuellement dirige par M. le professeur Christian BONNET. Les travaux de lunit portent sur diffrents aspects d'un rseau Mobile. Les axes de Recherche du Dpartement se dclinent dans plusieurs environnements: Les rseaux mobiles de troisime gnration et au del Les rseaux locaux sans fil Les rseaux de communication courte porte (Capteurs) Les rseaux Ad Hoc Des informations plus dtailles web http://www.eurecom.fr/cm.fr.htm sur l'quipe se trouvent dans son site

12

Chapitre

2
CHAPITRE 2 ETAT DE LART
Ce chapitre est consacr un tat de lart dans le domaine dtude. Un survol sur les rseaux mobiles 3G, les technologies diffrentes pour la diffusion, et enfin, le projet Daidalos avec la convergence des rseaux mobiles ainsi que la plateforme TD-CDMA seront prsents. On considre dans ce rapport que les connaissances de base des rseaux sans fil informatiques, des rseaux sans fil de tlcommunication sont connues par le lecteur. Pour en savoir plus, voir [7, 8, 18, 19, 29].

1. UMTS - Les rseaux mobiles 3G

1.1. Historique
Les rseaux cellulaires analogiques ont t communment appels systmes de premire gnration. Quant aux rseaux numriques utiliss lheure actuelle, comme le GSM (Global System for Mobile Communications), le PDC (Personal Digital Cellular), le CdmaOne (IS-95) et lUS-TDMA (IS-136), ils sont regroups sous lappellation de systme de deuxime gnration . Ces systmes ont permis aux communications vocales de saffranchir de la traditionnelle paire de cuivre et de grer efficacement la mobilit de leurs utilisateurs. La deuxime gnration est maintenant parfaitement implante dans de nombreux pays, et la troisime est en cours de mise en place. Cependant, cette mise en place va demander un laps de temps assez long laide des rseaux de gnration deux et demie. Les raisons cela sont dune part, le besoin de repartir de zro du point de vue des infrastructures et, dautre part, un manque de capitaux de la part des oprateurs de mobiles la suite de lachat de licences [8]. Les rseaux de gnration 2,5 se caractrisent souvent, comme cest le cas dans le GPRS (General Packet Radio Service), par un double rseau cur, un rseau cur pour le transport du tlphone et un rseau cur pour le transport des donnes sous forme de paquets. 13

Les systmes dits de troisime gnration ont t conus pour les communications multimdia. Avec ces nouveaux systmes, les communications pourront tre enrichies dimages et de vido de grande quantit. Laccs aux informations et aux services, que ce soit sur des rseaux publics ou privs, sera facilit par des dbits nettement suprieurs et des fonctionnalits avances. En 1985, lUIT a commenc ses tudes des rseaux FPLMTS (Future Public Land Mobile Telephone System), renomms IMT 2000 (International Mobile Telecommunication System for the year 2000) en 1993. LETSI a entam les siennes pour lEurope en 1990 avec lUMTS (Universal Mobile Telecommunication System). LUMTS nest quune des cinq normes de la famille IMT 2000, qui inclut galement WCDMA (Wideband Code Division Multiple Access), CDMA2000, EDGE et DECT de troisime gnration [6, 8, 29]. Les systmes de tlcommunications de troisime gnration dans ce rapport seront rfrencs sous le terme UMTS. Le WCDMA en est la principale interface air. Elle sera utilise tant en Europe quen Asie (Japon et Core inclus) dans la mme bande de frquences, autour de 2GHz. Au sein du 3GPP, le WCDMA est appel UTRA (Universal Terrestrial Radio Access) FDD (Frequency Division Duplex) et TDD (Time Division Duplex). [6].

Figure 1. Lvolution des rseaux de tlcommunication [29]

1.2. Architecture gnrale du rseau UMTS

LUMTS est considr comme le pas suivant des technologies de 2G et 2.5G. Donc il ne remplace pas les technologies et ces lments de rseau mais tend larchitecture du rseau. Larchitecture fonctionnelle du rseau daccs UMTS est prsente sur la figure 2 Le sous-systme radio RNS (Radio Network Subsystem) comprend les Node B, et 14

leurs contrleurs RNC (Radio Network Controller). Cette architecture hirarchique, dans laquelle une entit contrle plusieurs entits de niveau infrieur, est similaire celle du rseau GSM. Une grande diffrence avec le systme GSM est que lUMTS introduit linterface Iur entre les entits RNC. La gestion de la macrodiversit dans le rseau est une des raisons qui a pouss dfinir cette interface. Linterface Iur sera normalise lETSI. [25]

Figure 2. Architecture du rseau UMTS [30]

1.3. Le contexte international - Recherche et normalisation pour la 3G

La dfinition des systmes mobiles de troisime gnration fait lobjet de travaux de normalisation conduits au sein des organismes rgionaux avec des contacts de plus en plus troits au fur et mesure quune certaine convergence entre les propositions se dessine (notamment entre lEurope et le Japon). A lheure actuelle, la norme UMTS est standardise par le 3GPP (Third Generation Partnership Project) tandis que la norme cdma2000 (Code Division Multiple Access 2000) est standardise par 3GPP2 (Third Generation Partnership Project 2). Les membres directs du 3GPP comprennent ETSI, TTC, ARIB, TTA, CWTS, T1. Les grands oprateurs et les autres 15

participent aux projets par lintermdiaire des organismes rgionaux. Organismes rgionaux ETSI (European Telecommunications Standards Institute) TTC (Telecommunication Technology Committee) et ARIB (Association of Radio Industries and Businesses) TTA (the Telecommunication Technology Association) CWTS (Chinese Wireless Telecommunications Standards) T1 Tableau 1 : Organismes rgionaux participent au 3GPP Chaque rgion a sa propre stratgie, fortement lie la situation de dveloppement des systmes de deuxime gnration. En Europe, il faut souligner la place occupe dans la normalisation par lexistence de groupes dintrt pour la troisime gnration (MOU GSM, UMTS Forum) dont lobjectif est de fdrer, dans la mesure du possible, les positions des oprateurs GSM et des industriels. [25] Rgions Europe Japon Core Chine Etats-Unis

2. Broadcast Multicast
2.1. Gnralit
Au fur et mesure de la convergence de linternet et du multimdia, la mthode unicast fondamentale, qui est la transmission de donnes en mode point point , a volu pour faire face de nouveaux besoins : la communication de un vers plusieurs ou plusieurs vers plusieurs. Le broadcast est un terme anglais dfinissant une diffusion de donnes un ensemble de machines connectes un rseau. En franais on utilise le terme diffusion. Quant multicast, cest une connexion rseau multipoint. Pourtant, il est au milieu de lunicast et du broadcast. Au lieu denvoyer les donnes une seule machine (unicast), ou toutes les machines dans le rseau (broadcast), il sadresse un groupe de certaines machines. La notion de transmission multipoint peut tre implmente au niveau applicatif, par exemple, lorsque l'on envoie un courrier lectronique une liste de destinataires ou que l'on poste une intervention dans un groupe de news. Mais cela devient rapidement lourd grer ds que la liste de destinataires varie. D'autre part cela peut conduire faire circuler de multiples exemplaires des mmes donnes sur un mme lien, consommant ainsi de la bande passante. Actuellement, les protocoles broadcast et multicast utiliss dans les rseaux de 16

diffusion des cblo-oprateurs, les rseaux informatiques et les rseaux de tlcommunication sont DVB-T/H, IETF Multicast et 3GPP MBMS. Le protocole MBMS du 3GPP sera prsent avec plus de dtails dans la partie qui suit. DVB Rseaux Rseaux hertziens de diffusion des cblooprateurs (multimdia) Organisation de ETSI standadisation Documents DVB-T : EN 300 744, TR 101 190 DVB-H : EN 302 304 Tableau 2: Protocols broadcast et multicast IETF IP Multicast Rseaux sans dentreprise (informatiques) IETF RFC 2710 3GPP MBMS fil Rseaux tlcommunication (Mobile) 3GPP TS 22.146, TS 22.346, TS 25.331, TS 25.346, TS 26.346, TS 29.846

de

2.2.

Le protocole 3GPP MBMS

Pour les rseaux locaux sans fils dentreprise, on utilise IP Multicast de lIETF comme solution. Dans [27], Mariann Hauge, Oyvind Kure ont prsent les approches pour exploiter le protocole IP Multicast de lIETF [34] dans les rseaux de tlcommunications UMTS (Universal Mobile Telecommunications System). Pourtant, les recherches ont galement montr que la seule utilisation de ce protocole dans un rseau UMTS nassure pas une optimisation dutilisation des ressources radios. De mme, le protocole IP Multicast se termine dans le GGSN (Gateway GPRS Support Node) qui joue le rle dune passerelle entre Internet et UMTS. Donc, bien quil puisse rduire la charge du serveur, il nconomise pas de bande passante dans le rseau UMTS. En effet, les services multimdias ncessitent beaucoup de ressources radio ainsi que de ressources du rseau de cur dans lUMTS. Dans les premires versions de lUMTS (release 99), une cellule UMTS ne fournit simultanment que 3 flux de 384 kbit/s pour les sessions multimdia. Une distribution efficace devient donc essentielle et permet aux utilisateurs de partager les ressources. Le 3GPP a donc dfini une architecture gnrale pour MBMS. Il a pour but de grer les ressources radios et les ressources du rseau de cur efficacement en exploitant au maximum linfrastructure existante [26].

17

Figure 3. Architecture logique du MBMS [26] Le protocole MBMS (Multimedia Broadcast and Multicast Service) permet des services ptm (point-to-multipoint) uni-directionels. Il y a deux modes oprationnels : Le multicast et le broadcast [15]. Dans le mode broadcast, les contenus multimedia (texte, audio, vido) sont transmis sur les canaux communs. Cela permet dune utilisation efficace des ressources. La rception d'un service MBMS broadcast est assure par certaines phases:
Service announcement Session Start MBMS notification Data transfer Session Stop

Figure 4. Phases d'un service MBMS broadcast 18

Dans le mode multicast, les contenus multimedia (texte, audio, vido) sont transmis sur les canaux communs. Cela permet dune utilisation efficace des ressources. Dans ce mode, il est possible au rseau de transmettre de faon slective les donnes aux cellules qui contiennent les membres dun groupe multicast. La rception d'un service MBMS multicast est assure par certaines phases:
Subscription Service announcement Joining Session start MBMS notification Data transfer Session Stop Leaving

Figure 5. Phases d'un service MBMS Multicast Les phases subscription, joining et leaving sont ralises pour chaque UE. Les autres sont ralises pour chaque service (pour tous les usagers intresss par ce service). Les phases subscription, joining, leaving, announcement et notification peuvent fonctionner en parallel avec les autres phases. Voici une explication brve des phases: Subscription: Etablir la relation entre l'usager et le fournisseur de service Service announcement: Fournir aux UEs des information sur les service MBMS disponible. Joining: Rendre l'usager un membre du groupe multicast Session Start: Le moment o le BM-SC (Broadcast Multicast Service Center) est prt envoyer les donnes MBMS. Les RBs seront tablis. La phase session start est indpendante de la phase joining d'un service MBMS notification: Informer l'UE de l'arrive des donnes MBMS Data transfer: Les donnes sont transmis aux UEs Session Stop: Le moment o le BM-SC dtermine qu'il n'y a plus de donnes MBMS pour une certaine priode. Les RBs seront relchs Leaving: Quitter le groupe multicast

19

Figure 6. Une illustration exemplaire de la rception d'un service MBMS multicast L'ide principale pour la conception du protocole MBMS est que le protocole MBMS fournira les mmes mcanismes du protocole IETF IP Multicast. Le protocole MBMS est dfini dans les documents du 3GPP R6: TS 22.146, TS 22.346, TS 25.331, TS 25.346, TS 26.346, TS 29.846. Je vous conseille de lire d'abord le document TS 25.346 pour une vue gnrale sur le protocole MBMS. Vous pouvez accder ces documents sur le site web du 3GPP [37]. Vous pouvez aussi consulter [4]. En effet, au moment dcrire ce rapport, la norme MBMS nest pas trs stable. Certains documents sont encore des brouillons. De plus, il manque encore de spcification pour les points daccs au service MBMS (MBMS SAP) qui sont situs la frontire entre le NAS (None Access Stratum) et la couche RRC. Les primitives pour ces MBMS SAP devront tre dfinis dans TS 23.110 par le 3GPP.

3. Projet Daidalos
3.1. Une perspective pour les rseaux post 3G

La nouvelle gnration de rseaux post 3G doit intgrer tous les rseaux existants, c'est--dire les rseaux de donnes de type Internet, les rseaux tlphoniques, que ce soit le rseau tlphonique commut ou le rseau cur dun oprateur de mobiles, et les rseaux de 20

vido pour effectuer de la diffusion de tlvision ou de la vido la demande. Pour avoir une vision plus concrte, consultez [8, 10, 31, 32, 40] La gestion de la mobilit et du nomadisme est aussi une proprit essentielle des rseaux du XXIe sicle. Dans ces rseaux, les clients veulent se dplacer tout en restant connects. Le monde IP apporte des solutions ce problme avec Mobile IP et Cellular IP, qui grent la mobilit lente aussi bien que rapide. [8, 40]

3.2.

Broadcast et Multicast dans le contexte du projet Daidalos

Dans le contexte du projet Daidalos, on tudie un rseau htrogne qui assure bien le seamless mobility. Les terminaux mobiles peuvent fonctionner dans nimporte quel rseau sans fil, que ce soit les rseaux de diffusion, les rseaux de tlcommunication ou les rseaux informatiques dentreprise. En ce qui concerne le multicast et le broadcast, il consiste supporter toutes les technologies de diffusion actuelles: DVB-T/H pour les rseaux de diffusion, MBMS pour les rseaux de tlcommunication et IP Multicast pour les rseaux sans fil dentreprise.

Figure 7. Intgration de broadcast/multicast dans Daidalos De plus, la tendance tout-IP pour les rseaux 21 post-3G est exploite. Cette

architecture se place entirement sur linterface IPv6 ou, ce qui est quivalent, transporte uniquement des paquets IP. Aux couches plus basses, on intgre des protocoles diffrents et des technologies daccs diffrentes. On peut donc introduire une vision comme suit: le contenu multimdia est diffus sur linterface IPv6, et puis, traverse un rseau htrogne qui supporte des technologies diffrentes pour arriver aux terminaux mobiles post-3G.

4. Plate-forme TD-CDMA
Dans [1], nous avons prsent larchitecture Pure-IP de la plateforme TD-CDMA dans laquelle sont court-circuites un certain nombre dentits du rseau UMTS (RNC/SGSN/GGSN), ce qui a pour consquence une diminution notable du nombre de services supports. Le RG (Radio Gateway) tel que nous le dfinissons est donc considr comme le rsultat de laddition dun Node-B et dun sous-ensemble du RNC. Ceci permet la mise en oeuvre en vraie grandeur de solutions innovantes pur-IPv6 pour des rseaux radio htrognes B3G/WLAN exprimentaux.

Figure 8. Evolution du standard 3GPP vers pure-IPv6 Cette architecture permet une interconnexion sans discontinuit des diffrents accs radio qui fonctionnent tous en relation directe avec la couche de protocole IP (par exemple, WLAN et UMTS). Une cellule TD-CDMA est donc considre comme un sous rseau dans laquelle RG devient un routeur pour les utilisateurs.

22

Figure 9. La pile protocolaire Linterconnexion directe entre lUMTS-TDD et l'IPv6 est ralise grce la pile protocolaire reprsente sur la figure 6, La couche physique est divise en deux sous-couches, la sous-couche L1L (PHY-Low) et la sous-couche L1H (PHY-High). La sous-couche L1L interface directement la carte d'acquisition matrielle et ralise le traitement du signal de premier niveau. La sous-couche L1H ralise le codage/dcodage canal et lentrelacement. La couche 2 contient les couches de contrle MAC (Medium-Access) et RLC (Radio Link Control), qui sont responsables de lordonnancement des PDUs (Packet Data Units) sur les canaux de transport, de la segmentation des paquets et des protocoles de retransmission. Elle est complte par la couche PDCP, point daccs pour le trafic des donnes vers la couche RLC. La couche 3 est conforme la norme 3GPP dans le sens o elle fournit une interconnexion directe avec un rseau IPv6. La couche 3 comprend la couche RRC et la couche dabstraction GRAAL (Generic Radio Access Abstraction Layer). La couche GRAAL fournit linterface et ladaptation entre les mcanismes IPv6 pour la signalisation et le trafic utilisateur et les mcanismes spcifiques de laccs radio du 3GPP pour le support des fonctionnalits de mobilit, admission dappel, diffusion, etc Des canaux de propagation en temps discret ont t modliss, permettant dutiliser en simulation le mme code source que le logiciel temps rel, ce qui donne la possibilit de tester rapidement de nouveaux algorithmes sur les diffrents protocoles. Dans le cas de lenvironnement de simulation, le code spcifique lquipement RF nest pas utilis. Le logiciel est alors excut dans lespace utilisateur plutt que dans lespace noyau, tout en conservant la mme structure multi-tches que le code temps rel. Des signaux sont changs entre un ensemble de RGs et un ensemble de terminaux. L'change est excut grce une 23

interface socket client/serveur TCP/IP et une troisime entit qui contrle le flux du signal, que nous appelons un Serveur de Canal (Channel Server). [2] Une fonction qui nest pas prsente dans les stations de base mais dans le RNC est le RRM (Radio Ressource Management) dont les algorithmes doivent grer les ressources radio de plusieurs cellules adjacentes. Le RRM est mis en oeuvre de faon centralise pour un groupe de RGs. Lentit RRM fournit les fonctions suivantes aux clients RGs quelle gre: 1. configuration automatique de lAccess Stratum partir des requtes de service bases sur la QdS. 2. rduction des parasites (contrle de puissance, allocation dynamique de canal) 3. gestion de la mobilit de bas niveau (par exemple, contrle du Soft Handover ) 4. gestion de ressources conjointe travers plusieurs technologies daccs diffrentes (UMTS/WLAN) 5. recueil et algorithmique du traitement des mesures. Pour en savoir plus, je vous invite de lire [2]. Alors au cas de simulation, on verra des composants logiciels suivant :

NAS ct UE

AS ct UE

NAS ct RG

AS ct RG

Serveur RRM

Server de canal

Figure 10. Les composants logiciels de la plateforme

24

Chapitre

3
CHAPITRE 3 VERS UNE PLATEFORME TD-CDMA MULTICAST
Ce chapitre est consacr la solution pour la problmatique mentionne. Un processus strict de recherche et dveloppement sera prsent. En plus, les adaptations de la norme en tenant compte des exigences et des hypothses seront prcises aussi.

1. Description
Le processus se divise en trois phases qui sont troitement lis au processus de normalisation du 3GPP. Comme la norme MBMS nest pas stable en ce moment, il faut faire attention que, en ralisant ces trois phases, on suive toujours les compte-rendus des runions du 3GPP RAN WG2.

25

Figure 11. La planification gnrale La premire phase consiste dvelopper le protocole MBMS daprs le document TS 25.331 [18]. Cette phase se fait en assurant lindpendance du RRC unicast et en vitant de modifier la couche RRC unicast. Cette phase se divise ensuite en sous-tches Suivre les runions 45, 46, 47 du 3GPP sur le document TS 25.331 Synthtiser le document TS 25.331 pour avoir un document ddi au RRC MBMS Rdiger le document de conception pour RRC MBMS Implmenter le protocole MBMS. Raliser le test unitaire avec des scnarios de test.

26

Figure 12. La planification de la premire phase La deuxime phase consiste intgrer le code rsultat du phase 1 dans la plate forme sous le mode Simulation. Cette phase se divise en plusieurs sous-tches : Mettre jour les documents et le code source pour les rendre conformes au TS 25.331 6.6.0 Exprimenter linterface NAS-AS (les primitives pour MBMS) en prvoyant la compatibilit avec les documents futurs du 3GPP Intgrer le protocole dans la plateforme en utilisant le canal sRB3 (signaling radio bearer 3) comme MCCH (MBMS point-to-multipoint Control Channel) Tester avec des scnarios.

27

Figure 13. La planification de la deuxime phase La troisime phase consiste rendre le code rsultat du phase 2 fontionnable dans le projet DAIDALOS (mode Real Time).

2. Adaptation du MBMS pour Daidalos

Pour russir implmenter le protocole MBMS qui nest pas encore parfaitement dfini, on doit dfinir certains comportements en prvoyant les futurs comportements dfinis par le 3GPP. Pour le faire, on se concentre sur lobjectif final, on suit les runions du 3GPP et utilise la mthode "trial-error" pour exprimenter. Les adaptations sont proposes en exprimentant le comportement de la plate-forme sur des scnarios prdfinis. Cela permet dassurer non seulement la compatibilit avec la future norme, dassurer lavancement du projet mais aussi de minimiser la modification du code si la norme est change. Effectivement, le protocole MBMS doit fournir les mmes mcanismes du protocole IETF IP Multicast. Nous nous concentrons ici aux procdures Join/Leave/Session Start/Session Stop. Normalement, dans la spcification du 3GPP, les procdures Join/Leave sont effectues au niveau du NAS grce aux messages MLD (Multicast Listener Discovery) d'IPv6. Le NAS du RG effectue la procdure RNC Registration pour ensuite construire les arbres dacheminement. Du ct UE, quand le service est activ, cest le NAS qui demande au RRC deffectuer la procdure MBMS Acquisition [17, 18]. A Session start ou Session stop dun service, le RG met jour la configuration pointto-multipoint qui sera envoye aux UEs dans la priode de modification qui suit. Les UEs qui ont activ ce service seront notifis par le RG. Ces procdures qui fournissent aussi des informations ncessaires pour tablir des RBs (radio bearers) sont dcrites dans [17]. 28

Figure 14. Une adaptation du MBMS pour DAIDALOS Parce que linteraction entre le NAS et le RRC nest pas encore disponible en ce moment. Nous avons dcid de faire une similitude du comportement unicast. Ici on ne doit que dfinir les primitives MBMS ct RG (la flche bleue du NAS au RRC) et on profite du message Modified Service Information (la flche bleue du RG lUE) sur le canal DCCH (Dedicated Control Channel) pour signaler RRC ct UE des services MBMS activs. Le comportement est comme suit: Les procdures Join/Leave sont effectues au niveau du NAS grce aux messages MLD (Multicast Listener Discovery) dIPv6. Du ct RG, le NAS signale le RRC, ce qui va envoyer une Notification sur le DCCH lUE correspondant pour activer le service. A Session start ou Session stop dun service, les configurations seront mises jour. Les messages MBMS Current PTM RB Information et MBMS Common PTM RB Information seront recrs et transmises sur le canal MCCH la prochaine modification priode. Ils fournissent donc aux UEs des informations ncessaires pour tablir des RBs. Comme nous utilisons le message DCCH Modified Service Information pour effectuer les fonctionnalits Join/Leave. Il faut faire attention que lon fait la projection de Join/Leave sur Mod_acquirePTM_RBInfo/Mod_releasePTM_RB dans le message DCCH Modified Service Information. Voici un tableau qui dcrit de manire exhaustive le nouveau comportement de lUE. Pour chaque service dans la notification sur le canal DCCH, lUE va dterminer laction 29

requise et la prsence de ce service dans les message MCCH Modified Services Information et MCCH Unmodified Services Information pour prendre la dcision
DCCH Notification Join Join Join Join Modified Services Information Unmodified Services Information Activated service list Decision Add (Join) Add (Join) + Activate (Start) Add (Join) + Activate (Start) Ignore = Present = Absent

1 2 3 4

Tableau 3: Ractions du UE pour la procdure Join On linterprte comme suit : si laction Join est requise pour le service et l'UE n'ai jamais reu une notification pour ce service (cas 1, 2, 3), lUE ajoute ce service dans la liste Activated Services List. Si la phase session start du service a t active sur le rseau(cas 2, 3), l'UE va immdiatement activer ce service. On ne fait rien pour tous les cas qui sont hors de ce tableau. Ensuite, dans le tableau 3, on fait une similitude pour la procdure Leave. Il faut dsactiver le service avant de l'effacer de la liste Activated Services List :
DCCH Notification 1 2 3 4 5 Leave Leave Leave Leave Leave Activated service list Modified Services Information Unmodified Services Information State Decision

Active Standby Active Standby

Deactivate (Stop) + Delete (Leave) Delete (Leave) Dectivate (Stop) + Delete (Leave) Delete (Leave) Ignore = Present = Absent

Tableau 4: Ractions du UE pour la procdure Leave Les 4 procdures Join/Leave/Session Start/Session Stop doivent fonctionner ensemble pour assurer la consistance. Donc, quand on traite les message Modified Services Informations, il faut toujours faire attention la liste Activated Services List

30

Required Action (of Modified Services Information) Mod_acquirePTM_RBInfo

Activated service list

State Standby

Decision Activate the service whenever the configuration point-to-multipoint is available Deactivate the service Ignore

2 3

Mod_releasePTM_RB

Active

Si lUE dtermine un service dans le message Modified Services Information avec action Mod_acquirePTM_RBInfo et c'est un service inactif dans la liste Activated Services Liste (cas 1), lUE va activer ce service le plus tt possible. Si lUE dtermine un service dans le message Modified Services Information avec action Mod_releasePTM_RBInfo et c'est un service actif dans la liste Activated Services Liste (cas 2), lUE va dsactiver ce service. Dans [3], nous avons donc prvu des primitives pour trois MBMS services de RRC: MBMS Session Start, MBMS Session Stop et MBMS UE Notification. La dfinition des primitives satisfait les principes recommands par ITU-T. Ces principes sont utiliss largement dans les documents du 3GPP. La figure suivante illustre les 4 primitives de service : Request, Indication, Response, Confirmation [23]:

Service User A

Service User B

Request (requestor.submit) Confirm (requestor.deliver)

Indication (acceptor.deliver) Response (acceptor.submit)

OSI-Service-Provider
TISO2530-94/d03

Figure 15. Les primitives dun service dans le mode connection

31

Figure 16. Diagramme des classes : Les primitives des services MMBS de la couche RRC

3. Mise en uvre
La mise en uvre du protocole se fait en respectant la spcification et la conception dcrites dans [3, 4, 5]. Le code est crit en C en tenant compte des contraintes de la programmation en temps rel. Les diagrammes et les modles se font avec Tllogic Tau [36].

3.1.

Prparation pour une couche RRC multicast

Effectivement, lintgration du MBMS dans la plateforme entrane encore de petites modifications dans le RRC unicast. On doit modifier certains fichiers du RRC Unicast. A cet effet, le code dintgration du MBMS dans le RRC Unicast seront entours par:

32

#ifdef ALLOW_MBMS_PROTOCOL <Code pour MBMS> #endif

3.2.

Mise en uvre du RRC-RG

Dans le document de conception [5] nous avons abord des procdures dinterface que le composant MBMS fournira au RRC Unicast. En effet, pour rendre le RRC-RG une couche RRC multicast, on doit raliser les fonctionnalits suivantes : Initialisation, interaction avec le NAS, squenceur, simulation, interaction avec le serveur RRM. 3.2.1. Initialisation Pour un fonctionnement parfait du composant MBMS. Il faut assurer quil est bien initialis. Pour le faire, on ajoute la fin de la procdure rrc_init_bs dans le fichier rrc_init.c les lignes suivantes :

#ifdef ALLOW_MBMS_PROTOCOL rrc_rg_mbms_init(); #endif

3.2.2. Le squenceur Il y a 7 messages MCCH, ce sont MBMS Access Information, MBMS Modified Services Information, MBMS Unmodified services Information, MBMS General Information, MBMS Common p-t-m rb InformatioN, MBMS Current Cell p-t-m rb Information et MBMS Neighbouring Cell p-t-m rb Information.

Ces messages sont priodiquement envoys bass sur des priodes : Repetition period, Modification period, Access Info period [4, 18]. Repetition period: Cest lintervalle o les messages MCCH (sauf MBMS ACCESS INFORMATION) sont transmis. 33



Modification period : Cest lintervalle o les messages MCCH (sauf MBMS ACCESS INFORMATION) restent non modifis. Acess Info Period: Cest lintervalle pour envoyer un message MBMS ACCESS INFORMATION.
Access Info period

Repetition period

Modification period

MCCH Comme ces messages MBMS sont priodiquement transmis sur le canal MCCH pour tous les services, du ct RG, on implmentera un squenceur qui est utilis pour dterminer le dbut de chaque priode : Modification Period, Repetition Period, Access Period et Scheduling Period. Le squenceur correspond la procdure rrc_rg_mbms_scheduling_check() du composant MBMS. Cette procdure surveille le variable frame pour dterminer les vnements de temps. Quand elle dtermine un vnement, elle invoquera le code correspondant.
3.2.3. Les signaux de sortie

Effectivement, le squenceur ct RG est tellement simple que lon ne limplmente pas sous forme une machine tats finis. Pourtant, afin dassurer la consistance du code de la couche RRC, les dernires dcisions sont implmentes sous forme des signaux de sortie dune machine tats finis. Ces codes sont mis dans le fichier rrc_rg_mbms_outputs.c. Ils fournissent des services pour contacter le serveur RRM, pour communiquer avec les couches L1 et L2, pour envoyer les messages MBMS aux UEs et les primitives MBMS au NAS. Voici les prototypes prdfinis:

//rrc_rg_mbms_outputs.c void rrc_rg_mbms_config_indication (int transaction_Id, int return_code); void RRC_RG_MBMS_O_UE_NOTIFY_CNF(); void RRC_RG_MBMS_O_GET_RB_INFORMATION(); void RRC_RG_MBMS_O_L12_CONFIGURE(); void RRC_RG_MBMS_O_SEND_DCCH_UM(int ueID, char* pmsg, int msglen); void RRC_RG_MBMS_O_SEND_MCCH(char* pmsg, int msglen); void RRC_RG_MBMS_O_SEND_MSCH(char* pmsg, int msglen);

3.2.4. Simulation

Cette fonctionnalit permet de raliser le test unitaire et le test dintgration. Avec un scnario
34

prdfini on peut vrifier le fonctionnement interne de la couche RRC. Pour la raliser, on a deux faons :

Au niveau du NAS : le NAS peut grer les primitives dfinies dans [3] et les envoie au RRC. Le RRC va ensuite traiter ces primitives. Dans ce cas, il suffit dajouter lappel nas_mbms_scenario_check() dans la procdure nas_rg_DC_Rcve_FIFO() du fichier NAS/SIM/nas_rg_control_user.c. Au niveau du RRC : le RRC peut directement simuler comme sil a reu des primitives du NAS. Dans la procdure rrc_rg_rxtx() du fichier rrc_nas_if.c, on ajoute lappel rrc_rg_mbms_scenario_check() just aprs lappel rrc_rg_mbms_scheduling_check()

3.2.5. Interaction avec le NAS

Le RRC du RG se charge aussi de traiter les primitives MBMS qui viennent du NAS. Cette fonctionnalit fournit un SAP (Service Access Point) la couche NAS. Il se charge de traiter les primitives MBMS_<PRIMITIVE_NAME>_REQ qui viennent du NAS. Les informations ne sont pas disponibles aux UEs tout de suite [4, 18]. Effectivement, ces informations seront valides la modification period qui suit. On voit par exemple dans les scnarios suivants : A session start ou session stop, le RRC du RG reoit une primitive MBMS_BEARER_ESTABLIS_REQ, il va mettre jour les message MBMS MODIFIED SERVICE INFORMATION et MBMS UNMODIFIED SERVICE INFORATION. Pourtant, ces nouveaux changements ne sont transmis aux UEs qu la prochaine modification period [4, 18].

35

Figure 17. Diagramme de squence: Etablissement dun ptm RB

36

Figure 18. Diagramme de squence: Relchement dun ptm RB Pour activer le squenceur dans le RRC-unicast du RG: Dans la procdure rrc_rg_rxtx() du fichier rrc_nas_if.c, on appelle la procdure rrc_rg_mbms_scheduling_check() avant tous les autres appels et on appelle la procdure rrc_rg_mbms_MCCH_tx() et rrc_rg_mbms_end_modification_period_check() la fin.

37



Dans la procdure rrc_rg_read_DCin_FIFO() du fichier rrc_rg_msg_decode.c, on ajoute le code qui traite la primitive MBMS_UE_NOTIFY_REQ Dans la procdure rrc_rg_read_GC_FIFO du fichier rrc_rg_msg_decode.c on ajoute le code qui traite les primitives MBMS_BEARER_ESTABLISH_REQ et MBMS_BEARER_RELEASE_REQ

3.2.6. Interaction avec le serveur RRM

En effet, quand on envoie une demande au serveur RRM, on doit attendre la rponse. Il est donc ncessaire au composant MBMS de savoir le moment o la configuration point-tomultipoint est disponible. Pour le faire, on modifie un peu la procdure rrc_process_commands(int tx_idP) dans CONTRIB/rrc_message_handler.c comme suit : Avant Aprs
rrc_config_indication(tx_idP, 0); if (tx_idP < MBMS_MIN_TRANSACTION_ID) rrc_config_indication(tx_idP, 0); else if (tx_idP >= MBMS_MIN_TRANSACTION_ID && MBMS_MAX_TRANSACTION_ID) rrc_rg_mbms_config_indication (tx_idP, 0);

tx_idP

<=

Ici je considre que toutes les transactions RRM avec id suprieur ou gal MBMS_MIN_TRANSACTION_ID et infrieur ou gale MBMS_MAX_TRANSACTION sont des transactions RRM pour MBMS.

3.3.

Mise en uvre du RRC-UE

Quant au RRC ct UE, il faut tout dabord assurer linitialisation du composant MBMS. En plus, on doit assurer la capacit de recevoir et dcoder les messages sur le canal MCCH et la notification sur le canal DCCH. Actuellement, le canal MCCH nest pas disponible dans la plateforme. Pour assurer lavancement, on doit temporairement utiliser le sRB3 qui est ddi aux messages DCCH Downlink Direct Transfer portant la signalisation NAS [18 section 6.3]. Dans le RRC ct UE, on implmentera une machine tats finis pour prendre la dcision.
3.3.1. Initialisation

Pour un fonctionnement parfait du composant MBMS, il faut assurer quil est bien initialis. Pour le faire, on ajoute la fin de la procdure rrc_init_ms() dans le fichier rrc_init.c les lignes suivantes:

#ifdef ALLOW_MBMS_PROTOCOL rrc_ue_mbms_init();

38

#endif

3.3.2. Traitement des messages MBMS sur le canal MCCH

Pour le faire, on modifie la procdure rrc_ue_srb3_decode() dans le fichier rrc_ue_mbms_decode.c. Si le sRB3 ne peut pas dcoder le message DCCH Downlink Direct Transfer, On va considrer le message (qui vient) un message MBMS. Pourtant, ce nest quune solution temporaire, et il est possible davoir un comportement non espr au cas o lentte du message MBMS est valide pour un message DCCH Downlink Direct Transfer (Bien que ceci narrive gure). Le code pseudo sera comme suit :

//------------------------------------------------------------------------void rrc_ue_srb3_decode(mem_block *sduP, int length) //------------------------------------------------------------------------{ <Traiter le message Downlink Direct Transfer sur le sRB3> <Le code erreur est stok dans la variable status> #ifdef ALLOW_MBMS_PROTOCOL if (status!=SUCCESS) { <Traiter le message MBMS sur MCCH> <Le code erreur est stok dans la variable status> } #endif }

3.3.3. Traitement des messages MBMS sur le canal DCCH La Notification envoye sur le canal DCCH-UM (le sRB1) est traite dans la procdure rrc_ue_srb1_decode(). Il suffit dajouter le code comme un cas de linstruction switch.
#ifdef ALLOW_MBMS_PROTOCOL case DL_DCCH_mbmsModifiedServicesInformation: <Traiter le message MBMS sur DCCH> break; #endif

3.3.4. La machine tats finis

Du ct UE, on implmente une machine tats finis (FSM) qui tourne pour ragir chaque vnement dentre. Normalement, ces vnements correspondent aux messages MBMS ou aux lments dinformation dans ces messages. La FSM va dterminer les 39

vnements de sortie et activer le code correspondant. Il faut faire attention que limplmentation de cette machine est influence par les adaptations. La machine tats finis est implmente dans le fichier rrc_ue_mbms_fsm.c qui contient les procdures interfaces suivantes:

void void void void void void void void void void void void

RRC_UE_MBMS_I_CONTROLING_CELL_CHANGED(); RRC_UE_MBMS_I_RETURN_FROM_LOSS_COVERAGE(); RRC_UE_MBMS_I_ACTIVATED_SERVICE_CHANGED(); RRC_UE_MBMS_I_SELECTING_CELL_MBMS(); RRC_UE_MBMS_I_MODIF_SERV_INFO(); RRC_UE_MBMS_I_MCCH_MODIF_SERV_INFO(); RRC_UE_MBMS_I_ALL_UNMODIF_PTM_SERVICES(); RRC_UE_MBMS_I_UNMODIF_SERV_INFO(); RRC_UE_MBMS_I_COMMON_CELL_RB_INFO(); RRC_UE_MBMS_I_CURRENT_CELL_RB_INFO(); RRC_UE_MBMS_I_NEIGHBOURING_CELL_RB_INFO(); RRC_UE_MBMS_I_MODIF_PERIOD_ENDED();

void rrc_ue_mbms_fsm(); void rrc_ue_mbms_fsm_reset();

Ces procdures interface comprennent des signaux dentre, la procdure rrc_ue_mbms_fsm() a pour but de faire tourner la machine. Pour chaque signal dentre, il faut faire appel cette procdure. La procdure rc_ue_mbms_fsm_reset() met la machine tat initial et efface tous les drapeaux et les signaux. En effet, on implmente cette machine en code C mais avec le modle fait et vrifi par Tllogic Tau, on peut aussi gnrer automatiquement le code avec le mme fonctionnement (Pourtant cest pas dcid en ce moment). Les diagrammes qui modlisent la FSM peuvent tre consults dans lannexe B du rapport.

40

Chapitre

4
CHAPITRE 4 EVALUATION
Ce chapitre vous montrera les rsultats de mon stage pendant 7 mois. En fait, dans le monde industriel, le protocole MBMS ne sera mis en place que dans au moins un ou deux ans. Ce seront les premires exprimentations. Il faut donc:

Valider les adaptations Vrifier que limplmentation est conforme au 3GPP R6

1. Critres dvaluation
Dans le cadre du stage, lvaluation ne sadresse pas la performance du protocole MBMS mais plutt la validit du protocole. Je me permets de mettre ici certains critres utiliss: Indpendance, Tolrance au fautes, Conformit au 3GPP, Stabilit:

Le composant MBMS doit fonctionner de faon indpendante: Il fonctionne comme une boite noire, comme un systme ractif avec des signaux dentre et des signaux de sortie. On peut le tester avant de lintgrer dans la plateforme. Le composant MBMS doit assurer la tolrance aux fautes: Il doit tre capable de ragir aux signaux inattendus sans se casser. Il est aussi important dviter les fautes de programmation (segmentation fault, broken pipe) Le composant MBMS doit assurer la conformit au 3GPP: Le code, les conventions, le fonctionnement doivent bien respecter la norme du 3GPP. Le composant MBMS doit assurer la stabilit: Il doit fonctionner long temps sans ralentir le systme, sans gaspiller les ressources du systme (Mmoire, CPU). Le RRC Multicast doit fournir le service MBMS en assurant toutes les fonctionnalits du RRC Unicast.

2. Banc de test
Le test est effectu avec Systme 41 Linux Redhat 7 - kernel 2.4.20

RAM CPU Priode de modification Priode de rptition Nombre de UE Mode

512 MB 1.7 GHz 128 16 1 (comme on ne fait pas lvaluation sur la performance du MBMS) Natif, Intgration Tableau 5: Banc de test

Pour valuer, nous devons crer des scnarios de test. On a effectu ces mmes scnarios avec les deux modes (le mode natif et le mode d'intgration). Voici un scnario exemplaire : Frame M1 0..127 M2 128..255 M3 256..383 M4 384..511 M5 512..639 M6 640..767 M7 768..895 M8 896..1023 M9 1024..1151 M10 1152..1279 M11 1280..1407 M12 1408..1525 M13 1536..1663 Start/Stop Join/Leave

[183] UE 0, service 1/join [253] service 1/start

[429] UE 0, service 1/join [542] service 2/start [640] UE 0, service 1/ join [653] UE 0, service 1/join, service 2/join [783] service 2/start [1003] service 1/stop [1043] UE 0, service 1/leave [1169] service 2/stop [1228] UE 0, service 1/leave [1343] UE 0, service 2/leave [1383] service 1/start [1515] service 1/stop [1536] end of test

Tableau 6: Scnario de test La premire colonne signifie la priode de modification, la deuxime colonne signifie 42

les messages NAS qui informe le start/stop du service. La troisime colonne signifie les messages NAS qui informe le join/leave du service. Dans ce scnario, on compte aussi des cas normaux et les cas anormaux. Par exemple, au moment 542 (la 5ime modification priode) et 783 (la 7ime modification priode), le RRC reoit les messages qui indique le start dun mme service (service 2). Dans ce cas Il faut que le RRC ignore le deuxime message.

3. Rsultats esprs
Le scnario est ralis de faon automatique. Une procdure rrc_rg_mbms_scenario_check() est utilise pour gnrer les vnements prdfinis. Il faut que le test satisfasse les tableaux de rsultats esprs suivants : Priode de Contenu du message Contenu du message (1) modification Modified Services Unmodified Services Information Information 1 2 3 1/start 1/start 4 1/start 5 6 2/start 1/start 1/start, 2/start 7 1/start, 2/start 8 9 1/stop 2/start 2/start 10 11 2/stop 12 1/start 13 1/stop 14 (2) (3) (4)

(1) Recrer le message Modified Services Information (2) Recrer le message Unmodified Services Information (3) Recrer les messages Common/Current PTM RB Information (4) Configurer L12 la fin de la priode de modification

Tableau 7: Rsultats esprs ct RG Ce tableau dcrit la raction du RG pour le scnario ci-dessus. On peut linterprter comme suit : Par exemple, au moment 542 (la 5ime priode de modification), le RG reoit une primitive de NAS qui signifie le commencement du service 2. Le RG va donc rcuprer la configuration du RRM. A la fin de cette priode de modification, le RG demande aux couches L1 et L2 de reconfigurer. Au dbut de la 6ime priode de modification, RG recre les messages Modified Services Information, et les messages Common/Current Cell PTM RB Information. 43

Le RG diffuse ces messages sur le canal MCCH. Priode de Trame modification (Frame) M1 128 183 M2 256 256 + x M3 384 429 M4 512 M5 640 653 M6 768 M7 896 M8 1024 1043 1152 1228 1280 1343 1408 1536 Action pour service Action 1 service 2 Join Activate Ignore Deactivate + Leave Join + Activate pour Les services intresss (Activated Services List) 1/stanby 1/stanby 1/stanby 1/active 1/active 1/active 1/active 1/active, 2/active 1/active, 2/active 1/active, 2/active 1/active 1/standby, 2/active 2/active 2/active 2/active 2/active 2/standby

Join + Activate

Deactivate

Leave Ignore
Deactivate Leave

M9 M10 M11 M12

Tableau 8: Rsultats esprs ct UE Ce tableau dcrit la raction de lUE pour le scnario ci-dessus. On peut linterprter comme suit: Par exemple, au moment 183, UE reoit la notification du RG. Cette notification demande lUE dajouter le service 1 (join) dans la liste Activated Services Liste. A cet effet, le service 1 est insr dans la liste mais il nest pas encore activ. Ce service reste donc ltat standby. A la 3ime priode de modification, le service 1 commence, le RG diffuse les informations sur le canal MCCH. LUE reoit ces information, la configuration et active le service 1 au moment 256 + x (le moment o l'UE reoit la configuration point-tomultipoint)

4. Rsultats observs
Voici un extrait du rsultat pour le composant MBMS au mode natif.

44

Figure 19. Rsultat du test au mode natif On peut linterprter comme suit : Du ct RG, au dbut de la 6ime priode de modification, le RG essaie de transfrer les services stables du message Modified Service Information au message Unmodified Service Information. Comme il y a un changement de la configuration dans la priode prcdente, le RG recre les messages Common PTM RB Information et Current PTM RB Information pour diffuser aux UEs. Au moment 640, RG reoit une primitive NAS qui signifie que le UE 0 ne sintresse plus au service 1. Une notification (sous forme dun message MBMS Modified Services Information) est transmise au UE 0 sur le canal DCCH. Du ct UE, au dbut de la 6ime priode, le service 1 est active. Quand lUE reoit la notification il dsactive le service 1 et efface tous les informations concernant ce service. LUE continue acqurir les messages MCCH et ragit daprs la spcification. En analysant les traces, on trouve que le composant MBMS au mode natif est tout fait conforme la spcification. Les rsultats montre aussi lindpendance et la tolrance aux fautes du composant MBMS. Ltape suivante est donc dexprimenter lintgration du composant MBMS dans la plateforme TD-CDMA.

45

Figure 20. Rsultat du test au mode dintgration - simulation Lanalyse des traces dans ce cas est plus complique. Il sagit danalyser les traces de RG-NAS, RG-AS, UE-NAS, UE-AS et serveur RRM. On considre chaque composant un systme ractif indpendant. Le rsultat est aussi trs positif. Le nouvel systme est donc conforme la norme 3GPP R6. Les adaptations assurent aussi les fonctionnalits de la couche RRC Multicast. Le composant MBMS dans le RRC Multicast satisfait tous les critres donns.

46

Conclusions et perspectives

Le problme du broadcast/multicast dans le cadre du projet DAIDALOS convenait parfaitement un stage de 7 mois. Cest un stage trs enrichissant. Dans le cadre du stage, la plate-forme TD-CDMA, le projet DAIDALOS et les documents du 3GPP (la couche RRC, le protocole MBMS,) sont bien tudis. Lobjectif principal du stage est dintgrer le protocole MBMS dans la plate-forme TD-CDMA. Nous avons synthtis des documents de spcification, des documents de conception. Nous avons aussi suivi les comptes-rendu du 3GPP pour proposer une adaptation optimale au protocole MBMS, pour prvoir linteraction NAS-AS. Nous avons analys le code source de la plate-forme TD-CDMA pour dcouvrir et rsoudre certains problmes potentiels. Nous avons aussi modlis le protocole MBMS avec Tllogic Tau. Ensuite, nous avons abord une implmentation du protocole MBMS qui peut fonctionner dans le mode natif (pour le test) ou dans le mode dintgration (pour le projet DAIDALOS). Nous avons ralis les tests pour valider les adaptations et pour vrifier limplmentation du MBMS. Les tests donnent des rsultats positifs. La couche RRC est donc conforme au 3GPP R6 (au moins pour la signalisation, la structure des messages, la fonctionalit). Comme nous lavons annonc, limplmentation se base sur certaines hypothses. Actuellement, on ne sintresse qu la validit du protocole MBMS dans le cadre du projet DAIDALOS. La couche L1 et L2 reste encore la version 3GPP R4 (unicast). Il manque des canaux MTCH, MCCH, MSCH qui sont ddis aux MBMS. Les mcanismes dtablissement et de relchement des RBs ne sont pas encore parfaits. Effectivement, la plateforme logiciel TD-CDMA est dj utilise dans plusieurs projets europens comme RHODOS, WIDENS. Maintenant, en restant conforme la norme 3GPP R6, elle est bien exploite dans le projet europen DAIDALOS. Pourtant, afin de complter ces travaux, il faudrait encore continuer des recherches et des dveloppements.

47

Rfrences
[1] Michelle Wetterwald, Christian Bonnet, Lionel Gauthier, Yan Moret, Raymond Knopp, Dominique Nussbaum, An original adaptation of the UMTS protocols for a Direct Interconnection with IPv6 Eurcom, Une plateforme radio logicielle UMTS-TDD Michelle Wetterwald, NAS Interfaces for MBMS (working document) Michelle Wetterwald, Huu Nghia Nguyen, RRC for MBMS (working document) Michelle Wetterwald, Huu Nghia Nguyen, RRC for MBMS conception document (working document) H.Holma A.Toskala , UMTS les rseaux mobiles de troisime gnration, ISBN : 27464-0370-6 Jeffrey Bannister, Paul Mather, Sebastian Coope , Convergence Technologies for 3G Networks: IP, UMTS, EGPRS and ATM, ISBN: 047086091X Guy Pujolle, Olivier Salvatori, Jacques Nozick, Les rseaux, dition 2005, ISBN : 2212114370 David R. Kosiur, IP Multicasting: the Complete Guide to Interactive Corporate Networks, ISBN: 0471243590 Alex Brand, Hamid Aghvami, Multiple access protocols for mobiles communication: GPRS, UMTS and Beyon, ISBN: 0471498777 3GPP TR 21.905, v6.7.0: "Vocabulary for 3GPP Specifications" 3GPP TR 22.146 v6.6.0: "Multimedia Broadcast/Multicast Service; Stage 1" 3GPP TR 22.946, v1.0.0: "Broadcast and multicast services" 3GPP TS 23.110, v6.0.0: "UMTS Access Stratum Services and Functions" 3GPP TS 23.246, v6.5.0: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description" 3GPP TR 23.846, v6.1.0: "Multimedia Broadcast/Multicast Service (MBMS); Stage 2" 3GPP TS 25.346, v6.4.0: "Introduction of the Multimedia Broadcast Multicast Service (MBMS) in the Radio Access Network (RAN); Stage 2" 3GPP TS 25.331, v6.5.0: "Radio Resource Control (RRC); Protocol Specification (Release 6)" 3GPP TS 25.301, v6.2.0: "Radio interface protocol architecture (Release 6)" 3GPP TR 25.931, v6.2.0: "UTRAN functions, examples on signalling procedures" 3GPP TS 26.346, v6.2.0: "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs" 3GPP TS 29.846, v6.0.0: "Multimedia Broadcast/Multicast Service (MBMS); CN1 procedure description" 48

[2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22]

[23] [24] [25] [26] [27] [28]

[29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40]

ITU-T Recommendation X.210: "Open Systems Interconnection - Basic reference model: Conventions for the definition of OSI services" RFC 1112: "Host extensions for IP multicasting" Alain Charbonnier, Les systm mobile de troisime gnration Alcatel, J. de Vriendt, I. Gmez Vinagre, A. Van Ewijk, Multimedia Broadcast and Multicast Services in 3G Mobile Networks Mariann Hauge, Oyvind Kure, Multicast in 3G Network : Employment of existing IP multicast protocols in UMTS L.Henden (ed.), N. Chuberre, L. Combelles, G. Corazza, S. Danton, T. Flo, D. Grace, T. Kourtis, H. Le-Bihan, H. Linder, A. Nordbotten, E. Pallis, T. Tjelta, A. Vanelli , Broadcast and multicast - a vision on their role in future broadband access networks Tektronix, W-CDMA/UMTS Wireless Networks: Technology Brief Tektronix, K1297 G20 Protocol Tester http://www.equitekcapital.com/Investorinfo/Webpagecontent/flarion_articles/flarioneco nomist2.htm http://www.mobilites.net/?2005/03/29/112-linternet-4g-ambiant-et-plus-tard-autonome Christian Claveleira, Diffusion unicast et multicast (http://www.netcast.be/PourApprofondir/Diffusion-unicast-et-multicast.html) IEEE working groups IEEE 802.xx, http://grouper.ieee.org/groups/802/ Eurcom, www.wireless3G4Free.com Tllogic Tau, www.telelogic.com 3GPP Website, http://www.3gpp.org IPv6 Forum Website, http://www.ipv6forum.org FP6, http://europa.eu.int/comm/research/fp6/index_en.html DAIDALOS, http://www.ist-daidalos.org

49

Annexe

A
Annexe A - Termes & Abrviations
-

Lexplication des termes dans le domaine 3G se trouve dans le document du 3GPP TR 21.915 ou sur le site: http://www.mpirical.com/companion/mpirical_companion.html Voici une liste des abrviations utilises dans le rapport 3rd Generation 3rd Generation Partnership Project Access Stratum Base Station Base Station System Designing Advanced network Interfaces for the Delivery and Administration of Location independent, Optimised personal Services Dedicated Control Channel Digital Enhanced Cordless Telecommunications Digital Video Broadcasting for Handheld Digital Video Broadcasting Terrestrial Enhanced Data for Global Evolution European Telecommunications Standards Institute Future Public Land Mobile Telephone System Finite State Machine Gateway GPRS Support Node Generic Radio Access Adaptation Layer Global System for Mobile Communications Internet Engineering Task Force International Mobile Telecommunication System Layer 1 High Layer 1 Low Medium Access Control Multimedia Broadcast Multicast Service MBMS point-to-multipoint Control Channel 50

3G 3GPP AS BS BSS DAIDALOS DCCH DECT DVB-H DVB-T EDGE ETSI FPLMTS FSM GGSN GRAAL GSM IETF IMT L1H L1L MAC MBMS MCCH

MLD NAS PDC PTM PTP RB RG RLC RNC RRC SAP SGSN sRB UE UMTS WCDMA WLAN

Multicast Listener Discovery Non Access Stratum Personal Digital Cellular Point To Multipoint Point To Point Radio Bearer Radio Gateway Radio Link Control Radio Network Controller Radio Resource Control Service Access Point Serving GPRS Support Node Signaling Radio Bearer User Equipment Universal Mobile Telecommunications System Wideband Code Division Multiple Access Wireless Local Area Network

51

Annexe

B
Annexe B - La machine tats finis ct UE
Cette annexe vous prsente comment le MBMS dans le RRC ct UE est mis en uvre. Le modle sous forme une machine tats finis est construit avec Tllogic Tau.
Architecture de la machine tats finis

52

Signaux dentre signaux de sortie

53

La machine tats finis dtaille

54

55

56

Annexe

C
Annexe C Document de spcification (Anglais)

RRC for MBMS

Working Document Printed 06/12/2005

Michelle WETTERWALD Huu Nghia NGUYEN Mobile Communication Department Institut Eurecom BP 193 F-06904 Sophia Antipolis Cedex - France Tel: 04.93.00.26.31 - Fax: 04.93.00 26.27 Email : michelle.wetterwald@eurecom.fr web : http://www.eurecom..fr/Mobile

57

1. Introduction
This part describes the RRC protocol layer for MBMS. This is a reduced version of the original working document. References used in this part are locally relative to TS 25.331. For example: [6.3] means the section 6.3 of the TS 25.331 document.

2. Signalling Radio Bearers [6.3]

The Radio Bearers (RB) available for transmission of RRC messages are defined as "signalling radio bearers" and are specified in the following. The UE and UTRAN shall select the signalling radio bearers for RRC messages using RLC-TM, RLC-UM or RLC-AM on the DCCH and CCCH, according to the following: 5. Signalling radio bearer RB0 shall be used for all messages sent on the CCCH (UL: RLC-TM, DL: RLC-UM). 6. Signalling radio bearer RB1 shall be used for all messages sent on the DCCH, when using RLC unacknowledged mode (RLC-UM). 7. Signalling radio bearer RB2 shall be used for all messages sent on the DCCH, when using RLC acknowledged mode (RLC-AM), except for the RRC messages carrying higher layer (NAS) signalling. 8. Signalling radio bearer RB3 and optionally Signalling radio bearer RB4 shall be used for the RRC messages carrying higher layer (NAS) signalling and sent on the DCCH in RLC acknowledged mode (RLC-AM), as specified in subclauses 8.1.8., 8.1.9 and 8.1.10. 9. Additionally, RBs whose identities shall be set between 5 and 32 may be used as signalling radio bearer for the RRC messages on the DCCH sent in RLC transparent mode (RLC-TM). 10. RRC messages on the MCCH are mapped on FACH using RLC-UM. The transport channel configuration for MCCH is indicated on BCCH. For this signalling radio bearer no identity is applied. 11. RRC messages on the MSCH are mapped on FACH using RLC-UM. The transport channel configuration for MSCH is indicated on MCCH. For this signalling radio bearer no identity is applied.

3. External Interfaces

58

3.1. Primitives for the interface with the NAS (To be updated by MW) 3.2. RRC Peer-to-peer - MBMS specific procedures
3.2.1. MCCH Acquisition Purpose:

The UE applies the MCCH acquisition procedure to determine the MBMS services available in the cell and to initiate reception of the services that the UE has joined. The procedure applies to all UEs supporting MBMS, irrespective of their state (idle, URA_PCH, CELL_PCH, CELL_FACH and CELL_DCH).
Associated RRC Messages: UTRAN UE MBMS MODIFIED SERVICES INFORMATION MBMS UNMODIFIED SERVICES INFORMATION MBMS ACCESS INFORMATION GENERAL INFORMATION MBMS CURRENT CELL P-T-M RB INFORMATION MBMS NEIGHBOURING CELL P-T-M RB INFORMATION RLC-SAP: UM Logical channel: MCCH 3.2.2. MBMS Notification Purpose:

The MBMS notification procedure is used by the UE to respond to a notification provided by UTRAN, indicating a change applicable for one or more MBMS services the UE has joined. The procedure applies to all UEs supporting MBMS, irrespective of their state (idle and connected mode: URA_PCH, CELL_PCH, CELL_FACH and CELL_DCH). The actual notification mechanism to be used depends on the UE state.
Associated RRC Messages: In case of notification on the DCCH UTRAN UE MBMS MODIFIED SERVICES INFORMATION RLC-SAP: UM Logical channel: DCCH UTRAN UE Updated MBMS control information (Other MBMS messages ?) RLC-SAP: UM

59

Logical channel: MCCH

3.2.3. MBMS counting message supported only Purpose:

The MBMS counting procedure is used by the UE to inform UTRAN about its interest to receive an MBMS transmission. The procedure applies to UEs supporting MBMS that are in idle mode or in connected mode, URA_PCH state.
Associated RRC Messages: UTRAN UE - MBMS ACCESS INFORMATION RLC-SAP: UM Logical channel: MCCH

3.2.4. MBMS p-t-m radio bearer configuration Purpose:

The MBMS p-t-m radio bearer configuration procedure is used by the UE to acquire the (modified) radio bearer configuration for one or more MBMS services the UE has joined. The procedure applies to all UEs supporting MBMS, irrespective of their state (idle and connected mode: URA_PCH, CELL_PCH, CELL_FACH and CELL_DCH).
Associated RRC Messages: UTRAN UE - MBMS COMMON P-T-M RB INFORMATION RLC-SAP: UM Logical channel: MCCH UTRAN UE - MBMS CURRENT CELL P-T-M RB INFORMATION RLC-SAP: UM Logical channel: MCCH UTRAN UE - MBMS NEIGHBOURING CELL P-T-M RB INFORMATION RLC-SAP: UM Logical channel: MCCH 3.2.5. MBMS modification request not supported Purpose:

The MBMS modification request procedure is used by the UE to request UTRAN to release the p-t-p radio bearers of one or more MBMS services the UE is receiving. The procedure 60

may also be used to request to be moved to a preferred frequency applicable for one or more (prioritised) MBMS services, the UE has joined. The procedure applies to all UEs supporting MBMS, that are in state CELL_DCH.
Associated RRC Messages: UE UTRAN - MBMS MODIFICATION REQUEST RLC-SAP: UM ? Logical channel: DCCH 3.2.6. MBMS service scheduling Purpose:

The MBMS service scheduling procedure is used by the UE that is receiving one or more MBMS services that the UE has joined to acquire the MBMS scheduling information for the MBMS services. The procedure applies to all UEs that are receiving an MBMS service provided via a p-t-m radio bearer, irrespective of their state (idle and connected mode: URA_PCH, CELL_PCH, CELL_FACH and CELL_DCH).
Associated RRC Messages: UTRAN UE - MBMS SCHEDULING INFORMATION RLC-SAP: UM Logical channel: MSCH

4. Internal Procedures Description-MBMS specific procedures

MBMS specific procedure include the following procedures:
MCCH acquisition: The UE applies the MCCH acquisition procedure to determine the MBMS services available in the cell and to initiate reception of the services that the UE has joined. The procedure applies to all UEs supporting MBMS, irrespective of their state (idle, URA_PCH, CELL_PCH, CELL_FACH and CELL_DCH). MBMS Notification: The MBMS notification procedure is used by the UE to respond to a notification provided by UTRAN, indicating a change applicable for one or more MBMS services the UE has joined. The procedure applies to all UEs supporting MBMS, irrespective of their state (idle and connected mode: URA_PCH, CELL_PCH, CELL_FACH and CELL_DCH). The actual notification mechanism to be used depends on the UE state. MBMS p-t-m radio bearer configuration: The MBMS p-t-m radio bearer configuration procedure is used by the UE to acquire the (modified) radio bearer configuration for one or

61

more MBMS services the UE has joined. The procedure applies to all UEs supporting MBMS, irrespective of their state (idle and connected mode: URA_PCH, CELL_PCH, CELL_FACH and CELL_DCH). MBMS service scheduling: The MBMS service scheduling procedure is used by the UE that is receiving one or more MBMS services that the UE has joined to acquire the MBMS scheduling information for the MBMS services. The procedure applies to all UEs that are receiving an MBMS service provided via a p-t-m radio bearer, irrespective of their state (idle and connected mode: URA_PCH, CELL_PCH, CELL_FACH and CELL_DCH).

4.1. Reception of MBMS control information [8.7.1]

4.1.1. General

The procedure for receiving MBMS control information is used by a UE to receive information from UTRAN concerning the way it provides MBMS services the UE has joined. The procedure applies to all UEs supporting MBMS, irrespective of its state (idle, URA_PCH, CELL_PCH, CELL_FACH and CELL_DCH). Most MBMS control information is provided on the MCCH. The information on MCCH is transmitted using a fixed schedule, which is common for all services. MCCH information other than MBMS ACCESS INFORMATION message is transmitted periodically based on a repetition period. This MCCH information is repeated a configurable number of times with exactly the same content; the period in which the content of MCCH information other than MBMS ACCESS INFORMATION message remains unchanged is called the modification period. MBMS ACCESS INFORMATION message may be transmitted more frequently, based on the Access Info period. The transmissions of MBMS ACCESS INFORMATION message within a modification period need not have exactly the same content (the value of some parameters eg. IE 'Access probability factor Idle' may change). Nevertheless, the transmissions of MBMS ACCESS INFORMATION message within a modification period should concern the same MBMS service(s), although information for a service may be removed eg. upon completion of the counting for that service. The general principles are illustrated in figure 8.7.1-1, in which different colours indicate potentially different content of the MCCH information.

62

Access Info period

Repetition period

Modification period

MCCH
Figure 8.7.1-1: Scheduling of MCCH Information

For services provided via a p-t-m radio bearer scheduling information may be provided on an MSCH mapped on the same S-CCPCH as the p-t-m radio bearer(s). For some of the services provided p-t-m this scheduling information may be provided by signalling an MBMS Scheduling INFORMATION message at every scheduling period, while for others the MBMS SCHEDULING INFORMATION message may be signalled less frequently i.e. after a multiple of the scheduling period. In general, the UE is neither required to acquire MSCH information nor to act on it. In case the UE shall acquire MCCH information that is scheduled at the same time as MSCH information, the reception of the MCCH information shall take precedence. In order to minimise the time the UE needs to read MCCH to acquire the required information, UTRAN should schedule the MCCH messages in a specific order ie. messages which content has changed compared to the previous modification period should be scheduled prior to messages which contents has not changed. More specifically, the UE may assume that UTRAN schedules the MCCH messages in the following order: MBMS MODIFIED SERVICES INFORMATION, followed by messages which content changed - in the following order: MBMS GENERAL INFORMATION, MBMS COMMON P-TM RB INFORMATION, MBMS CURRENT CELL P-T-M RB INFORMATION, one or more MBMS NEIGHBOURING CELL P-T-M RB INFORMATION, followed by messages which content did not change - in the following order: MBMS UNMODIFIED SERVICES INFORMATION, MBMS GENERAL INFORMATION, MBMS COMMON P-T-M RB INFORMATION, MBMS CURRENT CELL P-T-M RB INFORMATION, one or more MBMS NEIGHBOURING CELL P-T-M RB INFORMATION
4.1.2. Initiation

The requirements concerning which MBMS control information the UE shall acquire in the different cases is specified in other subclauses. This section specifies common requirements concerning the reception of MCCH information and MSCH information.

63

4.1.3. UE requirements on reading of MCCH information

When requested to acquire MBMS control information other than the MBMS ACCESS INFORMATION message , the UE shall: 1> if requested to start reading MCCH at the next modification period: 2> start reading MCCH at the beginning of the next modification period. 1> otherwise 2> start reading MCCH at the beginning of the next repetition period. 1> if requested to stop reading MCCH at the end of the modification period: 2> continue reading MCCH until the required MBMS control information is received or until the UE detects a TTI in which no MCCH information is transmitted, whichever is first; 2> continue reading MCCH in this manner at every subsequent repetition period, until the information is received correctly or until the end of the modification period. 1> otherwise: 2> continue reading MCCH until the required MBMS control information is received or until the UE detects a TTI in which no MCCH information is transmitted, whichever is first; 2> continue reading MCCH in this manner at every subsequent repetition period, until the information is received correctly. NOTE 1: The UE may combine information received at different repetition periods within a modification period. When requested to acquire the MBMS ACCESS INFORMATION message, the UE shall: 1> if requested to start reading MCCH at the next modification period: 2> start reading MCCH at the beginning of the next modification period. 1> otherwise: 2> start reading MCCH at the beginning of the next access info period. 1> continue reading MCCH in this manner at every subsequent access info period, until the message is received correctly or until the end of the modification period. If the UE is CELL_DCH and has a compressed mode pattern that overlaps with the period in which it needs to read MCCH, the UE may temporarily refrain from receiving MCCH unless it is capable of simultaneous operation.
4.1.4. UE requirements on reading of MSCH information

If the UE supports reception of MSCH, UE shall: 1> if the UE needs to acquire MCCH information that is transmitted at the same time as the MSCH information and the UE does not support simutaneous reception: 2> refrain from reading MSCH. If the UE supports reception of MSCH, UE should: 1> start reading MSCH at the beginning of the next scheduling period; 64

1> continue reading MSCH until the required MBMS control information is received or until the UE detects a TTI in which no MSCH information is transmitted, whichever is first.

4.2. Procedures [8.7.2 8.7.7, 8.6.9]

4.2.1. MCCH acquisition [8.7.2] 4.2.1.1. Flow

UE

UTRAN

MBMS MODIFIED SERVICES INFORMATION MBMS UNMODIFIED SERVICES INFORMATION

MBMS ACCESS INFORMATION MBMS GENERAL INFORMATION

MBMS COMMON P-T-M RB INFORMATION MBMS CURRENT CELL P-T-M RB INFORMATION MBMS NEIGHBOURING CELL P-T-M RB INFORMATION

MCCH acquisition, normal [Figure 8.7.2-1]

4.2.1.2 Initiation

The UE shall apply the MCCH acquisition procedure upon selecting (eg. upon power on) or re- selecting a cell supporting MBMS, upon change of MBMS controlling cell (eg. due to an active set update or hard handover), upon return from loss of coverage and upon receiving an indication from upper layers that the set of activated services has changed.
4.2.1.3. MCCH information to be acquired by the UE

The UE shall detect the available MBMS services by acquiring the MBMS MODIFIED SERVICES INFORMATION and the MBMS UNMODIFIED SERVICES INFORMATION 65

messages without delaying reading of MCCH until the next modification period and without stopping at the end of the modification period, in accordance with subclause 8.7.1.3. The UE shall immediately acquire the MBMS ACCESS INFORMATION and the MBMS GENERAL INFORMATION messages ie. it shall not delay reception of these messages until it has completed the acquisition of the MBMS MODIFIED SERVICES INFORMATION and the MBMS UNMODIFIED SERVICES INFORMATION messages. Likewise, the UE should immediately acquire the MBMS CURRENT CELL P-T-M RB INFORMATION and MBMS NEIGHBOURING CELL P-T-M RB INFORMATION messages. The UE shall continue acquiring the above messages until it has received a consistent set of MCCH information eg. both the MBMS MODIFIED SERVICES INFORMATION and the MBMS UNMODIFIED SERVICES INFORMATION message should be acquired in the same modification period.
4.2.1.4. Reception of the MODIFIED SERVICES INFORMATION and the MBMS UNMODIFIED SERVICES INFORMATION by the UE

Upon completing the reception of the MODIFIED SERVICES INFORMATION and the MBMS UNMODIFIED SERVICES INFORMATION messages, the UE shall 1> act as follows for each of the services included in these messages provided that the service is included in variable MBMS_ACTIVATED_SERVICES and upper layers indicate that the session has not yet been received correctly (referred to as 'applicable services'); 1> act upon all received information elements as specified in subclause 8.6, unless specified otherwise in the following; 1> perform the service prioritisation procedure as specified in subclause 8.5.26; 1> if the UE receives an MBMS service using a p-t-m radio bearer and the received messages does not contain an IE "MBMS required action" set to "Acquire PTM RB info" for that service then the UE shall: 2> stop receiving the concerned MBMS service and clear all service specific information applicable for the concerned service.
4.2.1.5. Reception of the other MBMS messages by the UE

Upon receiving the MBMS ACCESS INFORMATION message, the UE shall act as specified in subclause 8.7.4.3. Upon receiving the MBMS GENERAL INFORMATION message, the UE should store all relevant IEs included in this message. The UE shall also:

66

1> act upon all received information elements as specified in subclause 8.6, unless specified otherwise in the following. Upon receiving the MBMS CURRENT CELL P-T-M RB INFORMATION and MBMS NEIGHBOURING CELL P-T-M RB INFORMATION messages, the UE shall act as specified in subclauses 8.7.5.3 and subclause 8.7.5.4 respectively. The procedure ends.
4.2.2. MBMS Notification [8.7.3] 4.2.2.1. Flow
UE UTRAN

MCCH: MBMS MODIFIED SERVICES INFORMATION

MCCH: updated MBMS control information

MBMS notification on MCCH [Figure 8.7.3-1]

UE

UTRAN

DCCH: MBMS MODIFIED SERVICES INFORMATION

MCCH: updated MBMS control information

MBMS notification on DCCH [Figure 8.7.3-2]

4.2.2.2. Initiation

UTRAN initiates the notification procedure to inform UEs about a change applicable for one or more MBMS services available in a cell. Some types of MBMS service changes e.g. the establishment of a p-t-m radio bearer, involve a modification of MCCH messages other than the MBMS MODIFIED SERVICES INFORMATION message. NOTE 1: On MCCH, the MBMS MODIFIED SERVICES INFORMATION as well as the MBMS UNMODIFIED SERVICES INFORMATION messages are signalled even if no services are contained in the message.

67

NOTE 2: A service remains in the MBMS MODIFIED SERVICES INFORMATION message until it enters a 'steady state', upon which it moves to the MBMS UNMODIFIED SERVICES INFORMATION message. In case counting is used, the service remains in the MBMS MODIFIED SERVICES INFORMATION message through the moment UTRAN has decided the transfer mode.
4.2.2.3. Receiving the MBMS Notification information 4.2.2.3.1. Reception via MCCH [8.7.3.3.1]

The UE may: 1> if in idle mode, URA_PCH, CELL_PCH or CELL_FACH state; and 1> if not receiving an MBMS service provided via a p-t-m radio bearer: 3> acquire the MBMS MODIFIED SERVICES INFORMATION message with delaying the reading of MCCH until the next modification period and with stopping at the end of the modification period, in accordance with subclause 8.7.1.3; 3> handle the MBMS MODIFIED SERVICES INFORMATION message as specified in subclause 8.7.3.4. The UE shall: 1> if in idle mode, URA_PCH, CELL_PCH or CELL_FACH state: 3> acquire the MBMS MODIFIED SERVICES INFORMATION message from MCCH at the start of every modification period, in accordance with subclause 8.7.1.3; 3> handle the MBMS MODIFIED SERVICES INFORMATION message as specified in subclause 8.7.3.4.
4.2.2.3.2. Reception via DCCH [8.7.3.3.3]

Notification via DCCH is used to notify the UE about the start of a session for which a PL applies, to notify the UE about the establishment of a p-t-m radio bearer for a service for which a PL does not apply and to request a UE in PMM_idle state to establish a PMM connection to enable reception of a service provided via a p-t-p radio bearer. Upon receiving the MBMS MODIFIED SERVICES INFORMATION message via DCCH, a UE in CELL_DCH shall: 1> handle the MBMS MODIFIED SERVICES INFORMATION message as specified in subclause 8.7.3.4.
4.2.2.4. UE action upon receiving MBMS MODIFIED SERVICES INFORMATION message [8.7.3.4]

68

Upon receiving the MBMS MODIFIED SERVICES INFORMATION message, the UE shall act as follows for each of the services included in this messages provided that the service is included in variable MBMS_ACTIVATED_SERVICES and upper layers indicate that the session has not yet been received correctly (referred to as 'applicable services'): 1> if the IE "MBMS all unmodified p-t-m services" is included in the MBMS MODIFIED SERVICES INFORMATION messages: 2> for all services listed in the message UNMODIFIED SERVICES INFORMATION, provided that the service is included in variable MBMS_ACTIVATED_SERVICES, upper layers indicate that the session has not yet been received correctly (referred to as 'applicable services') and the IE "MBMS required UE action" in the message MBMS UNMODIFIED SERVICES INFORMATION is set to "Acquire PTM RB info": 3> continue acquiring the MBMS UNMODIFIED SERVICES INFORMATION, MBMS COMMON P-T-M RB INFORMATION, MBMS CURRENT CELL P-T-M RB INFORMATION, and the MBMS NEIGHBOURING CELL P-T-M RB INFORMATION messages without delaying reading of MCCH until the next modification period and without stopping at the end of the modification period, in accordance with subclause 8.7.1.3; 3> act upon the MBMS UNMODIFIED SERVICES INFORMATION MBMS COMMON P-T-M RB INFORMATION, MBMS CURRENT CELL P-T-M RB INFORMATION and the MBMS NEIGHBOURING CELL P-T-M RB INFORMATION message, if received, in accordance with subclause 8.7.5. 2> if the UE receives an MBMS service using a p-t-m radio bearer and the messages MBMS Unmodified services Information and MBMS MODIFIED SERVICES INFORMATION do not contain an IE "MBMS required action" set to "Acquire PTM RB info" for that service then the UE shall: 3> stop receiving the concerned MBMS service and clear all service specific information applicable for the concerned service. 1> act upon all received information elements as specified in subclause 8.6, unless specified otherwise in the following 1> perform the service prioritisation procedure as specified in subclause 8.5.26; 1> the procedure ends.
4.2.2.5. UE fails to receive MBMS Notification information

If the UE fails to receive the MBMS MODIFIED SERVICES INFORMATION message within the current modification period, the UE shall: 1> Acquire the MBMS MODIFIED SERVICES INFORMATION and the MBMS UNMODIFIED SERVICES INFORMATION messages without delaying reading of

69

MCCH until the next modification period and with stopping at the end of that modification period, in accordance with subclause 8.7.1.3; 1> act upon the received MBMS MODIFIED SERVICES INFORMATION and the MBMS UNMODIFIED SERVICES INFORMATION messages as specified in subclause 8.7.2.4.
4.2.3. MBMS counting [8.7.4] message supported only (MBMS ACCESS INFORMATION) 4.2.3.1. Flow

UE

UTRAN

MCCH: MBMS ACCESS INFORMATION

Access Info Period: 0

MCCH: MBMS ACCESS INFORMATION Access Info Period: 1

MBMS counting, normal [Figure 8.7.4-1]

4.2.3.2. Initiation

The UE initiates the MBMS counting procedure for an MBMS transmission upon receiving an MBMS MODIFIED SERVICES or MBMS UNMODIFIED SERVICES message including IE "MBMS required UE action" with the value set to 'Acquire counting info'.
4.2.3.3. Reception of the MBMS ACCESS INFORMATION

The UE shall acquire the MBMS ACCESS INFORMATION message without delaying reading of MCCH until the next modification period in accordance with subclause 8.7.1.3. The UE behaviour upon receiving an MBMS ACCESS INFORMATION message that is contained in more than one TTI is not specified. Upon receiving the MBMS ACCESS INFORMATION message including one or more MBMS service(s) it has joined, the UE shall for each service: 2> if the message triggering the MBMS counting procedure included the IE "Continue MCCH reading" with a value set to TRUE: 3> continue acquiring further MBMS ACCESS INFORMATION messages without delaying reading of MCCH until the next modification period and without stopping at the end of the modification period, in accordance with subclause 8.7.1.3. 70

2> otherwise: 3> continue acquiring further MBMS ACCESS INFORMATION messages without delaying reading of MCCH until the next modification period and with stopping at the end of the modification period, in accordance with subclause 8.7.1.3.
4.2.3.4. Termination of the MBMS counting procedure [8.7.4.4]

If the UE detects that the MBMS ACCESS INFORMATION message is not provided at an access info period; OR If the UE receives an MBMS ACCESS INFORMATION message not including an MBMS service the UE has joined, the UE shall: 1> terminate the MBMS counting procedure.
4.2.3.5. Failure of the counting response procedure [8.7.4.5]

If the counting response procedure (RRC connection establishment or Cell update) fails, the UE shall: 1> if the failure occurs in the same modification period as the one in which the UE initiated the counting response procedure; or 1> if the message triggering the MBMS counting procedure included the IE "Continue MCCH reading" with a value set to TRUE that is applicable in the modification period in which the UE detects the failure: 2> continue acquiring further MBMS ACCESS INFORMATION messages without delaying reading of MCCH until the next modification period and without stopping at the end of the modification period, in accordance with subclause 8.7.1.3. 1> otherwise: 2> the procedure ends.
4.2.4. MBMS p-t-m radio bearer configuration [8.7.5] 4.2.4.1. Flow

71

UE MBMS COMMON P-T-M RB INFORMATION MBMS CURRENT CELL P-T-M RB INFORMATION

UTRAN

MBMS NEIGHBOURING CELL P-T-M RB INFORMATION

MBMS p-t-m radio bearer modification, normal [Figure 8.7.5-1]

4.2.4.2. Initiation

The UE applies the MBMS p-t-m radio bearer configuration procedure whenever it detects that one of the services it has joined is provided by means of a p-t-m radio bearerer. This may occur as part of the MCCH acquisition or the MBMS Notification procedure.
4.2.4.3. Reception of the MBMS PTM RB information

Upon completing the reception of the MBMS COMMON P-T-M RB INFORMATION and the MBMS CURRENT CELL P-T-M RB INFORMATION messages for an MBMS service it has joined, the UE shall: 1> if the UE is already receiving an MTCH and does not have the capability to receive the new service in addition: 2> the UE behaviour is undefined. NOTE: In this case, the UE may request upper layers to prioritise the services and only receive the service(s) prioritised by upper layers. 1> act upon all received information elements as specified in subclause 8.6, unless specified otherwise in the following; 1> if the UE previously received the service by means of a p-t-m radio bearer from a cell belonging to another MBMS cell group: 2> re- establish RLC; 2> re- initialise PDCP (FFS). 1> start immediately to use the indicated configuration unless specified otherwise; 1> start or continue receiving the indicated p-t-m radio bearers depending on its UE capabilities. The UE shall continue acquiring the above messages until it has received a consistent set of MCCH information i.e. the MBMS MODIFIED SERVICES INFORMATION message, MBMS UNMODIFIED SERVICES INFORMATION message, MBMS COMMON P-T-M RB INFORMATION and the MBMS CURRENT CELL P-T-M RB INFORMATION message should be acquired in the same modification period. 72

4.2.4.4. Reception of the MBMS Neighbour Cell PTM RB information

Upon receiving the MBMS NEIGHBOURING CELL P-T-M RB INFORMATION message for an MBMS service it has joined, the UE shall 1> start immediately to use the indicated neighbouring cells and configuration, or a subset of them, for L1- or L2 combining unless specified otherwise; 1> start or continue receiving the indicated p-t-m radio bearers from the selected neighbouring cells depending on its UE capabilities, TBS. The UE shall apply MBMS NEIGHBOURING CELL P-T-M RB INFORMATION only in combination with an MBMS MODIFIED SERVICES INFORMATION message, MBMS UNMODIFIED SERVICES INFORMATION message, MBMS COMMON P-T-M RB INFORMATION and MBMS CURRENT CELL P-T-M RB INFORMATION message acquired in the same modification period. The procedure ends.
4.2.4.5. Service prioritisation [8.5.26]

The UE may perform the Service prioritisation procedure whenever it detects that it becomes incapable of receiving all services it is interested in as well as whenever there are changes concerning the subset of services that it has selected to receive. This may occur upon state transitions, service start, service stop, service reconfiguration eg. transfer mode change and preferred frequency layer changes. If the UE detects that it is incapable of receiving all services, the UE may: 1> request upper layers to prioritise the services; 1> if reception of the highest priority MBMS service is inhibited by one or more MBMS service(s) provided via a p-t-p radio bearer: 2> request UTRAN to terminate these MBMS service(s) using the MBMS MODIFICATION REQUEST message as specified in subclause 8.7.6. NOTE: The termination of MBMS services is performed by RRC procedures, while clearing of non- MBMS services is performed by upper layers.
4.2.5. Secondary CCPCH and FACH selection for MCCH reception [8.5.19a]

The UE shall select the Secondary CCPCH for acquiring MCCH information according to the following rules: 1> if System Information Block type 5 is defined and includes an S-CCPCH within the IE "Secondary CCPCH system information" including a FACH for which the IE "MCCH configuration information" is included: 2> select that S-CCPCH and FACH for receiving MCCH. 73

1> otherwise if System Information Block type 5 is defined and includes an SCCPCH within the IE "Secondary CCPCH system information MBMS" for which the IE "FACH carrying MCCH" is included: 2> select that S-CCPCH and FACH for receiving MCCH.
4.2.6. Generic action on receipt and absence of MBMS specific IEs [8.6.9]

The UE shall perform the generic actions defined in this subclause only for the information elements corresponding with services that are included in variable MBMS_ACTIVATED_SERVICES.
4.2.6.1. MBMS Required UE action [8.6.9.6]

If the IE "MBMS required UE action" is included the UE shall: 1> if the "MBMS required UE action" is set to 'None': 2> take no action with respect to this IE. 1> if the IE "MBMS required UE action" is set to 'Acquire PTM RB info': 2> continue acquiring the MBMS COMMON P-T-M RB INFORMATION, MBMS CURRENT CELL P-T-M RB INFORMATION and the MBMS NEIGHBOURING CELL P-T-M RB INFORMATION messages without delaying reading of MCCH until the next modification period and without stopping at the end of the modification period, in accordance with subclause 8.7.1.3 2> act upon the MBMS COMMON P-T-M RB INFORMATION, MBMS CURRENT CELL P-T-M RB INFORMATION and the MBMS NEIGHBOURING CELL P-T-M RB INFORMATION message, if received, in accordance with subclause 8.7.5; 1> if the IE "MBMS required UE action" is set to Release PTM RB: 2> stop receiving the concerned MBMS service; 2> clear all service specific information applicable for the concerned service.
4.2.6.2. MBMS re- acquire MCCH [8.6.9.6a]

If the UE receives the IE " MBMS re- acquire MCCH" with a value set to TRUE, the UE shall: 1> perform the MCCH acquisition procedure as specified in subclause 8.7.2.
4.2.6.3. MBMS Service transmissions info list [8.6.9.7]

If the UE receives the IE "MBMS Service transmissions info list", the UE may: 1> discontinue reception of the S-CCPCH on which the IE was received, except for the service transmissions indicated by this IE for the concerned scheduling period.
4.2.6.4. MBMS Short transmission ID [8.6.9.8]

74

If the IE "MBMS short transmission ID" is included the UE shall: 1> if the value of the "MBMS short transmission ID" is less than or equal to the number of services identified by the IE "Modified services list" included in the MBMS MODIFIED SERVICES INFORMATION message acquired in the same modification period as the one in which the "MBMS short transmission ID" is received: 2> consider the "MBMS short transmission ID" to be an index to the list of services contained in the IE "Modified services list" and apply the MBMS service identity specified for this entry. 1> otherwise: 2> compile a list of available MBMS services, as included in the MBMS MODIFIED SERVICES INFORMATION and the MBMS UNMODIFIED SERVICES INFORMATION messages acquired in the same modification period as the one in which the "MBMS short transmission ID" is received: 3> concatenate the services contained in IE "Modified services list" included in the MBMS MODIFIED SERVICES INFORMATION and the services contained in IE "Unmodified services list" included in the MBMS UNMODIFIED SERVICES INFORMATION. 2> consider the 'MBMS short transmission ID' to be the index of the entry in the list of available services and apply the MBMS service identity specified for this entry.
4.2.6.5. MBMS Transmission identity [8.6.9.9]

If the IE "MBMS transmission identity" is included the UE shall: 1> if upper layers indicate that the MBMS transmission has already been received correctly: 2> ignore the information about this MBMS transmission i.e. continue as if the information about the concerned MBMS transmission was not included in the message. 1> otherwise: 2> act upon the information about the concerned MBMS transmission as specified elsewhere.
4.2.6.6. MCCH configuration information [8.6.9.9b]

If the IE "MBMS configuration information" is included the UE shall: 1> Consider a modification period to start from the frame with the SFN value fulfilling the following equation: SFN mod 2a = 0 1> Consider a repetition period to start from the frame with the SFN value fulfilling the following equation: SFN mod 2r = 0 75

1> Consider a modification period to start from the frame with the SFN value fulfilling the following equation: SFN mod 2m = 0 1> configure the RLC entity in the UE used for receiving MCCH in accordance with 8.6.4.9; 1> configure the MAC entity in the UE, used for receiving MCCH, for receiving TCTF field unless the IE 'TCTF presence' is received;
4.2.6.7. Next scheduling period [8.6.9.10]

If the IE "Next scheduling period" is included the UE may: 1> discontinue reception of the S-CCPCH on which the IE was received for the number of scheduling periods indicated by this IE.

5. UE variables supported [13.4]

5.1. MBMS_ACTIVATED_services [13.4.11c]
This variable stores the MBMS multicast services the UE has joined as well as the MBMS broadcast services the UE is interested to receive. Whenever the list of joined multicast services and/ or interested broadcast services changes, upper layers provide an indication upon which the UE shall update the variable accordingly.
Information Element/Group name Activated service list Need OP Multi 1 to <maxMB MSServices> Enumerat ed (Multicast, Broadcast ) Type and reference Semantics description

>Service ID >Service type

MP

6. Messages per Signalling Channels [11.1]

6.1. Downlink DCCH messages
DL-DCCH-Message ::= SEQUENCE {

76

integrityCheckInfo message
}

IntegrityCheckInfo DL-DCCH-MessageType

OPTIONAL,

DL-DCCH-MessageType ::= CHOICE { cellUpdateConfirm downlinkDirectTransfer pagingType2 radioBearerRelease radioBearerSetup rrcConnectionRelease mbmsModifiedServicesInformation }

CellUpdateConfirm, DownlinkDirectTransfer, PagingType2, RadioBearerRelease, RadioBearerSetup, RRCConnectionRelease, MBMSModifiedServicesInformation

UM/srb1 AM/srb3 AM/srb2 UM/srb1 - AM/srb2 UM/srb1 - AM/srb2 UM/srb1 UM/srb1

6.2. MCCH messages

MCCH-Message ::= SEQUENCE { message } MCCH-MessageType ::= CHOICE { mbmsAccessInformation mbmsCommonPTMRBInformation mbmsCurrentCellPTMRBInformation mbmsGeneralInformation mbmsModifiedServicesInformation mbmsNeighbouringCellPTMRBInformation mbmsUnmodifiedServicesInformation MCCH-MessageType

MBMSAccessInformation, MBMSCommonPTMRBInformation, MBMSCurrentCellPTMRBInformation, MBMSGeneralInformation, MBMSModifiedServicesInformation, MBMSNeighbouringCellPTMRBInformation, MBMSUnmodifiedServicesInformation,

6.3. MSCH messages

MSCH-Message ::= SEQUENCE { message } MSCH-MessageType ::= CHOICE { mbmsSchedulingInformation } MSCH-MessageType

MBMSSchedulingInformation,

7. Summary of Information Elements per message

7.1. MBMS Access Information [10.2.16e]
[for each MBMS service] MBMS short transmission ID Access probability factor Idle MP MP MP 1..maxMBMSservCount (=4) Integer(1..32) Integer (0, 32, 64, 960 by step of 32, 1000 )

7.2. MBMS Common p-t-m rb Information [10.2.16f]

77

We will consider the content as a string of characters which has the followings elements in macroscopic view:
RB information list L1-L2Configuration MP MP Octet string Octet string

7.3. MBMS Current Cell p-t-m rb Information [10.2.16g]

We will consider the content as a string of characters which has the followings elements in macroscopic view:
L1-L2Configuration MP Octet string

7.4. MBMS General Information [10.2.16h]

MBMS timers and counters T318 Cell group identity MP MD MP Integer(250... 2000 by step of 250, 3000, 4000, 6000, 8000, 10000, 12000, 16000) Bit string (12)

7.5. MBMS Modified services Information [10.2.16j]

[For each Modified service] MBMS Transmission identity MBMS Service ID PLMN identity MBMS required UE action MBMS re- aquire MCCH End of modified MCCH information MBMS all unmodified p-t-m services OP 1..maxMBMSservModif (=16) MP MP Octet string (3 ) MP Defined in TD-CDMA unicast MP (None, Acquire PTM RB info, Release PTM RB) MP Boolean OP Integer (1..15) CV-MCCHOP Enumerated (True)

7.6. MBMS Neighbouring Cell p-t-m rb Information [10.2.16k]

Neighbouring cell identity Neighbouring cells Configuration MP MP. Integer (1..X) Octet string

7.7. MBMS Scheduling Information [10.2.16l]

[For each Service] MBMS Transmission identity MBMS Service ID PLMN identity MBMS Service transmissions info list Start Duration MP MP MP MP OP MP MP 1.. maxMBMSservSched (=16)

Octet string (3 ) Defined in TD-CDMA unicast 1..maxMBMSTransmis (=4) Integer (0..1020) by step of 4 Integer (4..1024)

78

Next scheduling period

MP

Integer (0..31)

7.8. MBMS Unmodified services Information [10.2.16m]

[For each unmodified service] MBMS Transmission identity MBMS Service ID PLMN identity MBMS required UE action PTM RB) OP MP MP MP MP 1..maxMBMSservUnmodif (=32) Octet string (3 ) Defined in TD-CDMA unicast Enumerated (None, Acquire PTM RB info, , Release

79

Annexe

D
Annexe D Document de conception (Anglais)

Design of RRC for MBMS

Working Document Printed 06/12/2005

Michelle WETTERWALD Huu Nghia NGUYEN Mobile Communication Department Institut Eurecom BP 193 F-06904 Sophia Antipolis Cedex - France Tel: 04.93.00.26.31 - Fax: 04.93.00 26.27 Email : michelle.wetterwald@eurecom.fr nguyenhn@eurecom.fr web : http://www.eurecom..fr/Mobile

80

1. Introduction
1.1. General
This document describes the design for first implementation of the RRC protocol Layer for MBMS. Hypothesis: Hypo. Description [H1] 1 frequency Results No preferred frequency No frequency layer convergence No L1 combining Default return channel (DCCH) MBMS counting procedure is not supported [H4] [H5] [H6] Always ptm No MICH, no DRX Handover is supported

[H2] [H3]

1 cell / RNC UE in cell DCH state

Message Neighboring Cell .. is supported

1.2. Definition, acronyms and abbreviations

UML Esterel Unified Modelling Language Esterel is both a programming language, dedicated to programming reactive systems, and a compiler which translates Esterel programs into finite-state machines. It is one of a family of synchronous languages, like SyncCharts, Lustre, Argos or Signal, which are particularly well-suited to programming reactive systems, including real-time systems and control automata.

Telelogic Tau FSM

Finite State Machine

1.3. References
81

[1] [2] [3] [4] [5] [6] [7] [8] [9]

RRC_MBMSv5.doc 3G TS 25.301, v6.2.0 3G TS 25.331, v6.5.0 3G TR 25.931, v6.2.0 3G TS 22.146, v6.6.0 3G TR 22.946, v1.0.0 3G TS 23.246, v6.5.0 3G TR 23.846, v6.1.0 3G TS 25.346, v6.4.0

[10] [11] [12]

3G TR 23.846, v6.1.0 3G TS 23.110, v6.0.0 3G TR 21.905, v6.7.0

RRC for MBMS (Specification) Radio interface protocol architecture Radio Resource Control (RRC) protocol specification UTRAN functions, examples on signalling procedures Multimedia Broadcast/Multicast Service (MBMS);Stage 1 Broadcast and multicast services Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description Multimedia Broadcast/Multicast Service (MBMS); Stage 2 Introduction of Multimedia Broadcast/Multicast Service (MBMS) in the Radio Access Network (RAN); Stage 2 Multimedia Broadcast/Multicast Service (MBMS); Stage 2 UMTS Access Stratum Services and Functions Vocabulary for 3GPP Specifications

2. Decisions

Language C Compiler gcc esterel ver 5_92 or Telelogic Tau IDE: KDevelop 2.1 , Eclilpse 3.1 Linux Redhat 7 - kernel 2.4.20 UML 2 State Diagram Will Use FSM for UE.

3. Architectural Design
This part defines the high level design of the new RRC MBMS.

3.1. Global Architecture

82

3.2. Architecture of sub-systems

The new sub system RRC MBMS will be constructed as an extension of the old RRC unicast. In the extension, we will regard the system in 2 points of view.
3.2.1. Functional view:

If we regard the functionalities, we can have 2 parties

The package 1: for encoding/decoding the message and interfacing with the old RRC unicast. The package 2: for controlling the inside behaviour of UE when receiving indication from NAS or MBMS message from RG. this package will be implemented as a finite state machine

3.2.2. Networking architectural view:

If we regard the networking architecture, We can also separate the subsystem RRC MBMS as

RG side: all components are named as rrc_rg_mbms. UE side: all components are named as rrc_ue_mbms.

Throughout this document, we will use the networking architectural view as the main point of view.

3.3. Interfaces between sub-systems

In the functional view

Package 1 will call to rrc_ue_mbms_fsm.c of the package 2 to generate input signal and to activate the state machine. 83



Package 2 will call functions to write to and to process messages from NAS. The whole system/old RRC unicast will invoke interfaces supported in rrc_ue_mbms_if.c and rrc_rg_mbms_if.c

As for networking architectural view, here are more detailed UML component diagrams
3.3.1. RG side

NAS

RT Fifo

RR

L2

RB

rrc_rg_mbms_MSCH_tx rrc_rg_mbms_DCCH_tx rrc_rg_mbms_MCCH_tx

Implements the interfaces and other important procedures. The function of each procedure is described in .c file, 3 interfaces are defined in .h file -------------------------------------void rrc_rg_mbms_init(); void rrc_rg_mbms_scheduling_check(); void rrc_rg_mbms_end_modification_period_check(); void rrc_rg_mbms_MCCH_tx(void); void rrc_rg_mbms_DCCH_tx(int ueID); void rrc_rg_mbms_MSCH_tx(void);

rrc_rg_mbms_if.c

void rrc_rg_mbms_end_modification_period_check( ) void rrc_rg_mbms_scheduling_check() rrc_rg_mbms_init()

void rrc_rg_mbms_MCCH_encode void rrc_rg_mbms_DCCH_encode void rrc_rg_mbms_MSCH_encode

rrc_rg_mbms_encode.c rrc_PERDec_<pdunames> rrc_PEREnc_<pdunames>

protocol_vars_extern.h

rrc_mbms_utilities.c

rrc_msg_class.h

rrc_mbms_pdus.c

rrc_bs_entity.h Control block for RRC MBMS (RG side)

rrc_mbms_pdus.h

rrc_rg_mbms_variables.h Legends: RRC MBMS files Modified RRC unicast files Original RRC unicast files

rrc_mbms_ies.h

rrc_mbms_constant.h

Figure: UML Component diagram for RG side

84

3.3.2. UE side

NAS

RT Fifo

RRC

L2

RB

Inputs: I_CONTROLING_CELL_CHANGED I_RETURN_FROM_LOSS_COVERAGE I_ACTIVATED_SERVICE_CHANGED I_SELECTING_CELL_MBMS I_MODIF_SERV_INFO I_UNMODIF_SERV_INFO I_COMMON_CELL_RB_INFO I_CURRENT_CELL_RB_INFO I_NEIGHBOURING_CELL_RB_INFO I_MODIF_PERIOD_ENDED

Outputs: O_NAS_MBMS_UE_NOTIFY_IND O_ANALYSE_UNMODIF O_CURRENT_CELL_RB_CONFIGURATION O_MCCH_NOTIFICATION O_DCCH_NOTIFICATION

Only in test mode, Will be obsoleted in phase 2 (integration)

rrc_ue_mbms_MSCH_rx rrc_ue_mbms_DCCH_rx rrc_ue_mbms_fsm rrc_ue_mbms_MCCH_rx rrc_ue_mbms_scheduling_check rrc_ue_mbms_init rrc_ue_mbms_if.c rrc_ue_mbms_destroy

RRC_UE_MBMS_<I_SIGNALS> void rrc_ue_mbms_MCCH_decode void rrc_ue_mbms_DCCH_decode rrc_ue_mbms_fsm.c void rrc_ue_mbms_MSCH_decode

rrc_ue_mbms_decode.c rrc_ue_mbms_outputs.c rrc_PERDec_<pdunames> rrc_PEREnc_<pdunames>

protocol_vars_extern.h

rrc_mbms_utilities.c

rrc_msg_class.h

rrc_mbms_pdus.c

rrc_ms_entity.h Control block for RRC MBMS (UE side)

rrc_mbms_pdus.h

rrc_ue_mbms_variables.h

Legends: RRC MBMS files Modified RRC unicast files Original RRC unicast files

rrc_mbms_ies.h

rrc_mbms_constant.h

4. Detailed Conception
4.1. Modification to the old RRC unicast

85

We will try to keep it as much stable as possible. It means that we avoid modifying the existing source code of RRC unicast. Modification is realised in 3 files:

rrc_msg_class.h: Addition of types: MCCHMessage, MSCHMessage, . rrc_ms_entity: Addition of an mbms control block for UE rrc_bs_entity: Addition of an mbms control block for RG

4.2. Encode, Decode and Interface

4.2.1. Description For this part, we will use the ASN.1 for constant, variables, timers, pdus, messages specified in the [TS 25.331#11]. To encode and decode, we need to define a control block for UE side and RG side. Here are necessary information (macroscopic view): 4.2.1.1. UE MBMS control block

Attribute T318 CellGroupIdentity unmodifiedServices[] modifiedServices[] L1L2Config RBInformationList[] reacquireMCCH accessInfoPeriodCoefficient repetitionPeriodCoefficient modificationPeriodCoefficient neigbouringCellInfoList[] Scheduling (later)

Source Default ms1000, MBMS General Information MBMS General Information MBMS Unmodified Services Information MBMS Modified Services Information Common/Current MBMS RB Information Common MBMS RB Information MBMS Modified Services Information MBMS-MCCH-ConfigurationInfo-r6 (SIB5) MBMS-MCCH-ConfigurationInfo-r6 (SIB5) MBMS-MCCH-ConfigurationInfo-r6 (SIB5) Neigboring Cell RB Information

For more details, view the definition in rrc-ue-mbms-variables.h

4.2.1.2. RG MBMS control block

Attribute T318 CellGroupIdentity unmodifiedServices[] modifiedServices[] 86

Source Default ms1000 NAS/protocol_bs NAS primitives NAS primitives

L1L2Config RBInformationList[] reacquireMCCH accessInfoPeriodCoefficient repetitionPeriodCoefficient modificationPeriodCoefficient neigbouringCellConfigs[] endOfModifiedMCCHInformation ueList[servID][] //ues interested in a service servID Scheduling (later)

protocol_bs NAS / protocol_bs NAS primitives? MBMS-MCCH-ConfigurationInfo-r6 MBMS-MCCH-ConfigurationInfo-r6 MBMS-MCCH-ConfigurationInfo-r6 NAS Self

For more details, view the definition in rrc-rg-mbms-variables.h

4.2.2. Interface

The interface of this package for the outside layer (NAS) is temporarely a static control block defined above. This package supports encoding/decoding functions to other internal packages:

rrc_PERDec_MBMSAccessInformation rrc_PERDec_MBMSCommonPTMRBInformation rrc_PERDec_MBMSCurrentCellPTMRBInformation rrc_PERDec_MBMSGeneralInformation rrc_PERDec_MBMSModifiedServicesInformation rrc_PERDec_MBMSNeighbouringCellPTMRBInformation rrc_PERDec_MBMSSchedulingInformation rrc_PERDec_MBMSUnmodifiedServicesInformation rrc_PEREnc_MBMSAccessInformation rrc_PEREnc_MBMSCommonPTMRBInformation rrc_PEREnc_MBMSCurrentCellPTMRBInformation rrc_PEREnc_MBMSGeneralInformation rrc_PEREnc_MBMSModifiedServicesInformation rrc_PEREnc_MBMSNeighbouringCellPTMRBInformation rrc_PEREnc_MBMSSchedulingInformation

4.3. Finite State Machine for controlling

87

4.3.1. Description

We try to represent the textual behaviour of RRC MBMS in [1, 2] by using UML2 state diagrams. In fact, the UML tools used is an IT modelling tool, the diagram is still a logical model with textual comments. Those diagrams will later be transformed into SyncChart in EsterelStudio (graphical) or in Telelogic Tau, which will finally be used to generate the code C. We can also directly implement those in C. In the following schemas, we use pseudo states to represent the conditions (Because the tool doesnt provide this symbol ).

= Condition
4.3.2. UE MBMS State Diagram

88

89

4.3.3. RG MBMS State diagram

This diagram represents a RG scheduler for sending MBMS messages. In fact, its so simple that we can implement it without using a FSM.

90