MajecSTIC 2009 Avignon, France, du 16 au 18 novembre 2009

Patterns architecturaux pour la conception de solutions IPTV convergentes fixe-mobile.

Vincent Feru1, 2, Alex Menai2, Gal Fromentoux2 et Yves Le Traon1 1 : Tlcom Bretagne, 2 rue de la chtaigneraie, CS 17607 35576 Cesson Svign Cedex - France. 2 : Orange Labs, 2 avenue Pierre Marzin, 22307 Lannion Cedex - France. Contacts : prenom.nom@orange-ftgroup.com prenom.nom@telecom-bretagne.ue

Rsum L'objectif de ce papier est de prsenter l'intrt des patterns comme outil de conception d'architectures tlcoms convergentes (fixe-mobile). L'approche par les patterns, telle que nous la concevons, est issue des travaux de Christopher Alexander [2,3] o chaque pattern est un lment de conception identifi, rutilisable, qui apporte une solution simple et prouve un problme rcurrent. Ce papier s'intresse aux architectures IPTV de distribution de contenus audiovisuels sur rseaux IP et plus particulirement au chantier de la commande des services de contenus (IPTV) accessibles sur accs fixes et mobiles. La commande est l'ensemble des processus permettant les interactions clients-fournisseurs mais aussi de contrler le support procur par des rseaux de transport (e.g. IP, Accs mobile, xDSL) afin d'acheminer et de dlivrer les services. La dmarche pour obtenir un pattern gnrique applicable aux cas fixe et mobile y est prsente ainsi que des perspectives d'amlioration de l'exploitation des patterns par leur association des critres mtier objectifs. Abstract The paper aims at presenting the interest of patterns as a tool for elaborating converging telecom architectures. Our understanding of patterns is based on the work of Christopher Alexander [2,3] where each pattern is a reusable concept that responds to a well identified and recurrent problem. The paper focuses on investigating IPTV control architectures for convergent fixed and mobile solutions. Control encompasses all interactions between clients and providers as well as the adaptation of transport networks to the delivery of services. The procedure to obtain the corresponding architectural pattern is shown as well as perspectives of enhancing the use of such patterns by defining objective choice criteria. Mots-cls : services IPTV, architecture rseau, patterns architecturaux, urbanisme. Keywords: IPTV services, network architecture, architectural patterns, enterprise architecture.

Vincent Feru, Alex Menai, Gal Fromentoux et Yves Le Traon

1. Introduction. Le mtier d'architecte est de plus en plus stratgique dans les domaines des tlcoms et de l'informatique. Il consiste concevoir et accompagner l'volution des architectures techniques et de l'infrastructure de l'entreprise. En effet, il faut rduire les cots d'investissement et d'exploitation tout en restant en phase avec un cosystme particulirement versatile (e.g. techniques, usages et rglementation). Ces activits sont entreprises l'occasion de l'introduction de nouveaux services et de la mutualisation de composants. Afin de rationnaliser le processus de conception d'un systme, l'approche par les patterns est souvent mise en uvre en informatique dans le logiciel [10], les systmes d'information [9,11] et dans les rseaux de tlcommunication [1,7,12]. L'approche par les patterns, telle que nous la concevons, est issue des travaux de Christopher Alexander [2,3] o chaque pattern est un lment de conception identifi, rutilisable, qui apporte une solution simple et prouve un problme rcurrent. L'informatique d'aujourd'hui s'est largement inspire de ces prmices pour parvenir un niveau de maturit permettant la ralisation de rseaux1 ou de langages de patterns [5] utiliss dans les activits de dveloppements logiciels. Le gain dune telle approche est aujourd'hui admis dans la communaut des architectes du logiciel, des systmes d'information et reste approfondir pour son application aux architectures tlcoms rseaux et services. L'objectif de ce papier est de prsenter l'intrt des patterns comme outil de conception d'architectures tlcoms convergentes (fixe-mobile). Cette mthode est ainsi applique aux services de contenus audiovisuels. En effet, ces services constituent aujourd'hui la pice matresse des chantiers d'volution de l'infrastructure chez les oprateurs tlcoms qui dveloppent les offres multi-play et reprsenteraient en 2010, 27% du trafic internet mondial avec le risque d'engorgement des rseaux associs. Ce papier s'intresse particulirement au chantier de la commande des services de contenus (IPTV) accessibles sur accs fixes et mobiles. La commande est l'ensemble des processus permettant les interactions clients-fournisseurs mais aussi de contrler le support procur par des rseaux de transport (e.g. IP, Accs mobile, xDSL) afin d'acheminer et de dlivrer les services. Elle permet de masquer les dtails du rseau support aux services ainsi qu'aux utilisateurs. La difficult principale de ce chantier d'investigation est l'intgration dans la conception de l'architecture de commande, des diffrents types de terminaux (fixes et mobiles) et des diffrents types d'accs (fibre, xDSL, 3G, Wifi) sur lesquels les services IPTV sont dlivrs. Les architectes d'un oprateur sont ainsi constamment confronts aux problmes de rutilisation et d'adaptation de solutions d'abord penses uniquement pour un rseau fixe ou au contraire un rseau mobile des problmes rcurrents pour mener leurs chantiers : d'o l'intrt des patterns. Aprs un rappel au paragraphe 2 du processus gnrique de conception d'architecture de rseaux tlcoms [12], le paragraphe 3 prcise les services IPTV viss et leur importance pour un oprateur. Nous rappelons ensuite au paragraphe 4 la dmarche d'laboration d'un pattern pour l'appliquer au paragraphe 5 au chantier de commande de services IPTV. Enfin la conclusion fait tat de l'exprimentation actuelle de cette mthodologie dans d'autres chantiers et des perspectives d'amlioration de l'exploitation des patterns par leur association des critres mtier objectifs. 2. Processus gnrique de conception d'architectures Tlcoms Tel que dcrit dans [12] la conception des architectures tlcoms comporte plusieurs vues : fonctionnelle, organique et technique. La vue fonctionnelle reprsente la dcomposition d'un systme en fonctions et points de rfrence ainsi que son comportement dynamique indpendamment des choix d'implmentation. La vue organique (ou logique) indique l'organisation relative une implmentation particulire des fonctions dans des organes (entits relles qui peuvent tre des quipements ou composants applicatifs) et l'implmentation des points de rfrence en
1

ne pas confondre avec les rseaux de tlcommunications, il s'agit d'un abus de langage de Martin Fowler [9].

Patterns architecturaux pour la conception de solutions IPTV convergentes fixe-mobile

termes de protocoles de communication ou bus applicatifs. Enfin, la vue technique illustre la distribution des organes sur linfrastructure rseau d'un oprateur tlcom. Sur ces diffrentes vues, le processus dbute par la cartographie de l'architecture existante. Cette cartographie est ensuite consolide par une confrontation aux nouvelles exigences d'volutions (par exemple ajout ou suppression d'un nouveau service) o sont identifis les lments supprimer, conserver ou ajouter. Enfin, l'architecture cible fait tat des choix finaux d'implmentation qui deviendront leur tour une architecture existante la prochaine itration2 de ce cycle de conception. L'approche par les patterns intervient dans toutes les phases : la cartographie repre les patterns existants et prouvs. La consolidation et l'laboration de l'architecture cible pure le systme des patterns obsoltes et introduit de nouveaux patterns dans le systme. 3. Les services IPTV et leur importance pour un oprateur. Comme voqu prcdemment, les services de contenus audiovisuels constituent aujourd'hui un axe de dveloppement majeur de l'infrastructure chez les acteurs tlcoms qui se projette sur les marchs de demain. Aujourd'hui les offres du fixe et du mobile sont dissocies pour des services de types contenus TV live, le contenu la demande (VoD3) ou encore la Web TV ainsi que leurs variantes prsentes sous la forme d'un catalogue de services IPTV. S'y ajoutent, la gestion de la diffusion de contenus autoproduits UGC4, l'intgration des contenus publicitaires contextuels, des services audiovisuels complmentaires du type catch-up TV5, start over6 et plus gnralement la portabilit des services IPTV dans des contextes multi-accs et multi-services. L'offre des services prcits est structurante d'un point de vue marketing qui la positionne comme un produit d'appel majeur et incontournable des offres multiplay. La fourniture de ces services remet en cause l'architecture et l'infrastructure d'un oprateur de par son dimensionnement, cots d'investissement et de fonctionnement, distribution gographique multi-sites, et impacts sur le systme d'information. Le but principal d'un oprateur est donc de concevoir des rseaux homognes notamment pour rduire les cots d'exploitation et d'volution, mais aussi pour renforcer la pntration du march. C'est pour toutes ces raisons que nous nous intressons la manire d'optimiser la conception des architectures cibles qui permettent la fois de proposer un service stable, mais galement rentable : l'approche par les patterns, qui favorise la rutilisation et la mutualisation de composants prouvs rpond cette exigence. Nous allons donc aborder le pattern du chantier d'investigation "commande de services IPTV pour fixe et mobile". 4. Rappel sur la dmarche d'laboration des patterns architecturaux Dans notre papier prcdent [7] nous avons propos une dmarche d'laboration de patterns architecturaux pour les architectures des rseaux de tlcommunication. La dmarche exige de structurer l'identification des patterns par chantiers dinvestigations (phases dattachement, dinitiation de service, de transport et livraison de contenus,...). Elle comprend trois tapes cls par chantier : 1 - Identifier un ensemble de scnarios cls permettant d'extraire le pattern partir du problme. Cest au travers de lobservation de ces scnarios, de leurs ressemblances et disparits, quune premire vision archtypale du pattern prend forme : un archtype du chantier est ainsi tabli. L'archtype contient un ensemble de fonctions (issues des rles cls) et des interfaces. Cette vision d'archtype ressemble ce qui est voqu par [4].
Prise en compte dun nouveau dossier darchitecture rseau dans le processus du cycle de conception o la cartographie de larchitecture existante devient une architecture cible qui deviendra alors une nouvelle architecture existante. 3 Video On Demand 4 User Generated Content. 5 Ou rewind TV, pour le service de rattrapage d'une mission TV Live. 6 Service de lancement de l'mission TV live avant la fin de sa diffusion, contrairement au rewind TV.
2

Vincent Feru, Alex Menai, Gal Fromentoux et Yves Le Traon

2 - Gnralement, l'archtype ainsi obtenu nest pas immdiatement exploitable car il ncessite une deuxime phase de mise en contradiction avec d'autres scnarios cls qui permettent son enrichissement et sa correction. 3 - On procde enfin une dernire tape de formalisation du pattern pour le rendre exploitable en sa qualit de forme abstraite, car il permet de reproduire lensemble des scnarios dexploitation au travers des dclinaisons du pattern. Ces dclinaisons se distinguent ensuite au sein dun mme chantier selon leur(s) critre(s) mtier. Il s'agit de rgles dingnierie permettant de favoriser le choix d'une dclinaison particulire du pattern vis--vis d'exigences d'volution ou de services cibls. On obtient en fin de dmarche, pour chaque chantier dinvestigation, une reprsentation synthtique des rsultats reprenant les vues dynamique et statique du pattern. Nous avons formalis les concepts prcits au travers du mta-modle de la Figure 1 qui reprend les lments du mta-modle de cartographie d'un rseau d'oprateur [12].

Figure 1 Mta-modle simplifi de formalisation des patterns architecturaux. Aprs ce rappel de la dmarche nous allons exposer son application l'laboration du pattern de commande des services IPTV. 5. Elaboration du pattern de commande des services IPTV. Comme expos au paragraphe prcdent, nous avons identifi pour notre chantier les scnarios cls correspondant aux processus de commande des services IPTV dans le cas du fixe et du mobile. Nous avons rassembl ces scnarios sous la forme d'changes inter-fonctionnels dans la Figure 2. Ce rsultat est la concatnation des interactions fonctionnelles identifies, soit une gnralisation partir des scnarios cls tudis.

Figure 2 Identification des scnarios cls. Nous nommons de Sc1 Sc4 les scnarios cls du chantier d'investigation afin de dcouper les squences d'changes de messages par regroupement de rles cls (futures fonctions lmentaires) et interfaces (points de rfrence) associs. Les rles cls, non reprsents ici, dcrivent litt-

Patterns architecturaux pour la conception de solutions IPTV convergentes fixe-mobile

ralement des phases rseaux gnrant des changes de messages entre entits identifies lors de lanalyse fonctionnelle. Sans rentrer dans les dtails techniques nous avons identifi avec nos experts mtiers les fonctions lmentaires suivantes : - "service_delivery_initiation" pour l'initialisation de la session de demande de service, - "Service_discovery" pour lister les choix d'offres de services l'abonn, - "Service_delivery_decision" pour valider ou non la livraison finale du service, - "Service_parameters_change" pour prendre en compte les modifications de paramtres de l'utilisateur du service, - "Service_notification" pour alerter l'abonn des services ou contenus IPTV disponibles qui peuvent lui tre autoriss ( titre gratuit, l'achat l'acte ou par souscription), - "Service_redirection" qui permet de garantir la livraison de services en cas d'indisponibilit dans le rseau et de proposer une solution alternative transparente pour l'abonn. Une fonction lmentaire peut tre une fonction cl si elle est prsente de faon permanente pour lensemble des implmentations du pattern, ou bien une fonction optionnelle si elle nexiste que pour certaines implmentations du pattern. Les scnarios Sc1 et Sc2 distinguent respectivement le mode push du mode pull. Le mode push voque une transaction initie dans le sens fournisseur de services vers le client, tandis que le mode pull implique que c'est le client qui est l'initiative de la demande du service. Sc3 reprend la squence de modification des paramtres du service de l'utilisateur et Sc4 le principe de redirection pour la livraison du service. Ces scnarios permettent ainsi d'laborer l'archtype prsent sur le bas de la Figure 3. Cette mme figure montre la mise en contradiction avec l'implmentation de ces scnarios dans le cas mobile. Afin de faciliter la comprhension de celle-ci, nous avons dcoup l'architecture tudie en partant du ct de l'utilisateur avec son rseau priv ("User Premises"), puis le rseau d'accs de l'oprateur ("Access Network"), le rseau paquet mobile pour la collecte et le cur ("Backhaul/Core Network"), puis enfin les plateformes de service du fournisseur.

Service provider servers Mobile TV Portal

User

Base Controler Station

SGSN

GGSN

WISP Mobile Content Streamers

Service_notification F()
Notify Notify

Service_discovery F()
Initiate Call-service Decide

Service_delivery_initiation F()

Service_delivery_decision F()

redirect

Change

decide

Name F() Service_redirection F()

redirect

Fonction cl Fonction optionnelle Point de rfrence Point de rfrence optionnel

Service_parameters_ change F()

Name F()
name name

Figure 3 Pattern et architecture de livraison de services IPTV mobile.

Vincent Feru, Alex Menai, Gal Fromentoux et Yves Le Traon

L'architecture mobile telle que prsente est considrer d'un point de vue gnral pour les accs de type data pour le mobile (UMTS, EDGE, GPRS,), qui permettent effectivement la livraison de services enrichis ncessaires pour l'IPTV. D'autres rseaux mobiles en tudes chez l'oprateur peuvent permettre la livraison de services IPTV tel que le DVB-H7 mais sortent du contexte de notre observation ce jour. La Figure 4 prsente la mise en contradiction de l'archtype pour les accs fixes. Le dcoupage du rseau reste le mme que dans le cas mobile et le rsultat de mise en contradiction est comparable une exception prs : le cas mobile utilise une fonction supplmentaire : "Service_notification". Cette exception n'est pas considre comme perturbant l'archtype car l'change correspondant peut tre mis en uvre optionnellement pour le fixe, mme si ce n'est pas l'usage actuel.

Figure 4 Implmentation du pattern et de commande de services IPTV pour le fixe. L'archtype peut ainsi tre promu au grade de pattern aprs l'application de la mthodologie prsente dans notre prcdent papier [7]. Il aura donc deux dclinaisons : une pour le fixe et une autre pour le mobile. Ainsi si on entreprend un autre type d'accs (par exemple DVB-H) l'architecte peut soit rutiliser en entier ou en partie le pattern (en crant une troisime dclinaison), soit le remettre en cause en l'enrichissant par de nouvelles fonctions (en aucun cas le pattern ne doit tre considr comme obstacle l'innovation ou l'adaptation de nouvelles exigences). 6. Conclusions Dans ce papier, nous avons mis lpreuve la mthodologie propose dans notre premier papier [7] pour l'laboration de patterns architecturaux. Nous nous sommes intresss aux architectures de commande de service IPTV de par la prpondrance du sujet dans les chantiers actuels d'volution des oprateurs tlcoms. Nous avons obtenu un pattern gnrique applicable aux cas fixe et mobile. D'autres chantiers sont galement en cours d'investigation dans l'objectif d'enrichir le catalogue de l'oprateur et de faciliter le mtier de ses architectes.

Digital Video Broadcasting Handheld, quivalant la TNT (DVB-T) dans le contexte des rseaux mobiles.

Patterns architecturaux pour la conception de solutions IPTV convergentes fixe-mobile

Dans un cas d'usage typique, une fois que les patterns sont identifis pour un chantier d'investigation, il faut que l'architecte puisse les rutiliser et dcider de leurs usages ou non dans les architectures au travers d'indicateurs. Il existe deux types d'indicateurs : quantifiable ou nonquantifiable. Le critre mtier associ une dclinaison est un indicateur propre au chantier (la confiance, le business model, la nature du rseau, la distance gographique,) et il n'est pas forcement partag entre les architectes. Les critres mtiers permettent de diffrencier les dclinaisons de pattern et ainsi de faire office de critre de dcision dans le choix venir d'une dclinaison de celui-ci pour une architecture cible. Afin de pouvoir objectiver la prise de dcision, les travaux d'A. Menai sur les mtriques de l'urbanisation [12] peuvent tre transposs la distance entre pattern et architecture. La diffrence symtrique entre l'ensemble des fonctions et points de rfrence d'un pattern d'une part, et d'autre part, de l'ensemble des fonctions et points de rfrence d'une architecture donne une piste de mtrique approfondir. Ces mesures ciblent la distance entre des modles dynamiques darchitecture et un modle statique de pattern. Ceci fera l'objet de notre prochain papier. Bibliographie 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. H. Abramowicz, Draft architectural framework, 4ward European project Architecture and design for the future internet, Seventh framework programme 2009. C. Alexander, S. Ishikawa, M. Jacobson, I. Fiksdahl-King, S. Angel, A pattern langage. New York, Oxford 1977. C. Alexander, The timeless way of building, New York, Oxford 1979. J. Arlow, I. Neustadt, Enterprise patterns and MDA - Building better software with archetype patterns and UML, USA, Addison Wesley 2003. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, Pattern-Oriented Software Architecture A system of patterns, England, Wiley 1996. J-M Favre, L'ingnierie dirige par les modles, au-del du MDA, Paris, Lavoisier 2006. V. Feru, Y. Le Traon, F. Menai, G. Fromentoux, Des patterns architecturaux chez un oprateur intgr, Marseille, MajecSTIC 2008. M. Fowler, K. Scott, UML Distilled second edition A brief guide to the standard objetc modeling language, USA, Addisson Wesley 1999. M. Fowler, D. Rice, M. Foemmel, E. Hieatt, R. Mee, R. Stafford, Patterns of enterprise application architecture, USA, Addisson Wesley 2003. E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns Elements of reusable objetcoriented software, USA, Addisson Wesley 1995. C. Longp, Le projet d'urbanisation du Systmes d'Information, Paris, Dunod 2001. M.F. Menai. Langage et dmarche de modlisation pour l'urbanisation des architectures tlcoms, Thse de doctorat, Orange Labs, Universit de Tchnologie de Troyes, octobre 2006. G. Tselentis, J. Domingue, A. Galis, A. Gavras, D. Hausheer, S. Krco, V. Lotz, T. Zaharidis, Towards the future Internet A European research perspective, USA, IOS Press 2009. J.A. Zachman, A framwork for information systems architecture, IBM journal vol. 26 n3 p. 276-292 1987

Nous souhaitons remercier l'ensemble des contributeurs architectes et experts Orange Labs ayant particips dans le cadre de ces travaux. Nous remercions galement Dr Jacques Simonin pour ses conseils aviss.