Pierre Saucourt-Harmel - WiMPS

Transcript

1. Architecture logicielle et méthodologie pour une pile multistandard embarquée sur un circuit unique
2. Plan I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles des piles protocolaires 1. Approche propriétaire basée sur des RTOS généralistes 2. Approche standardisée par framework 2. Approche standardisée par framework IV. Besoins pour les terminaux multistandard 1. Diminution du nombre de puces (intégration, consommation, coût) 2. Faciliter le cycle de développement (dont intégration et mise au point) 3. Passerelles modem et utilisation de plusieurs standards en parallèle 4. Reconfiguration, mise à jour et gestion unifiée V. Architecture logicielle et méthodologie de WiMPS 1. Principaux critères d’établissement du cahier des charges 2. Décomposition fonctionnelle et principaux composants 2. Décomposition fonctionnelle et principaux composants 3. Architecture générale et exemple de mise en œuvre 4. Méthodologie de développement = environnement du framework VI. Avancement du prototype WiMPS 1. En environnement simulé 2. Sur carte électronique VII. Conclusion & questions 2 Séminaire à Supélec Rennes - 2 avril 2009 © 2009 Wi Telecoms
3. Créateur de WiMPS : Pierre Saucourt-Harmel I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Ingénieur EPITA (1991). Ingénieur EPITA (1991). 1986-1992 : Création de logiciels télématiques et vocaux. 1992-2008 : 16 années d’expérience professionnelle dans l’industrie des Télécommunications et des mobiles. Lauréat du concours national d’aide à la création d’entreprises de technologies innovantes 2008. Accompagné par l’incubateur Midi-Pyrénées d’avril Accompagné par l’incubateur Midi-Pyrénées d’avril 2008 à février 2009. Création de la structure juridique Wi Telecoms en septembre 2008. Accompagné par la CCI de Toulouse depuis mars 2009. 3 Séminaire à Supélec Rennes - 2 avril 2009 © 2009 Wi Telecoms
4. Protection de la propriété intellectuelle L’œuvre WiMPS a été protégée par son auteur : Dépôts d’enveloppes Soleau à l’Institut National de la I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Dépôts d’enveloppes Soleau à l’Institut National de la Propriété Industrielle (INPI). Dépôt des documents préparatoires à l’élaboration du logiciel, à l’Agence pour la Protection des Programmes (APP). L’architecture du framework et du noyau de WiMPS ont été brevetés par son auteur, par l’intermédiaire d’un cabinet spécialisé en brevets, auprès de l’OMPI (Organisation Mondiale de la Propriété Intellectuelle). Mondiale de la Propriété Intellectuelle). Cette présentation est sujette à droits d’auteur et droits d’exploitation. Son accessibilité publique ne permet qu’une utilisation personnelle. Toute autre utilisation (à des fins éducatives, commerciales, militaires, de recherches, …) doit être préalablement autorisée par l’entreprise Wi Telecoms. © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 4
5. I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Objectif : Objectif : Réaliser et vendre des piles protocolaires multistandard. Moyens : Effectif de 3 personnes, doublé d’ici fin 2009. Environ 60 K€ déjà engagés dans le projet. Etapes suivies : 1. Etude de marché (1ère phase achevée en janvier 2009) et 1. Etude de marché (1ère phase achevée en janvier 2009) et dépôt de brevet (en mars 2009). 2. Réalisation d’un prototype (WiMPS version alpha) en cours 3. Recherche de partenaires (laboratoires, industriels, …). 4. Financement pour le développement de produits. 5 Séminaire à Supélec Rennes - 2 avril 2009 © 2009 Wi Telecoms
6. Convergence des radiocom. Multiplicité des standards mais aussi des technologies I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Multiplicité des standards mais aussi des technologies propriétaires de radiocommunications numériques. Approche initiale : Une chaîne de traitement / technologie. Spécialisation des industriels pour une ou deux technologies. Développement fermé depuis 20 ans. Développement fermé depuis 20 ans. De plus en plus de terminaux doivent supporter plusieurs standards : Multiplicité des chaînes de traitements. Début de convergence matérielle ces dernières années. 6 Séminaire à Supélec Rennes - 2 avril 2009 © 2009 Wi Telecoms
7. Multiplication des standards I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions 7 Séminaire à Supélec Rennes - 2 avril 2009 © 2009 Wi Telecoms
8. Convergence matérielle opérationnelle I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Plateforme matérielle RF/IF RF/IF Plateforme matérielle d’un terminal mobile RF/IF RF/IF RF/IF RF/IF Radio FM Radio FM RF/IF RF/IF RF/IF RF/IF GPS GPS 8 Séminaire à Supélec Rennes - 2 avril 2009 © 2009 Wi Telecoms
9. Plateforme matérielle idéale I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Plateforme matérielle Plateforme matérielle convergente d’un terminal mobile RF RF SiP SiP RF RF SiP SiP WiMPS = Gestion centralisée des protocoles de radiocommunications Cellulaire Diffusion 9 Séminaire à Supélec Rennes - 2 avril 2009 © 2009 Wi Telecoms (ex: Architecture MXC des plateformes Freescale) RF RF SiP SiP Connectivité
10. Convergence logicielle opérationnelle, sur le processeur applicatif I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Applications orientées utilisateurs : Navigateur internet, transfert de fichiers, messageries. Lecteurs multimédia en continu (streaming). Couches protocolaires « hautes » (> niveau 3) de transmission de données du monde IP : transmission de données du monde IP : Couche application : HTTP, FTP, SMTP, POP3, … Couche de transport : TCP, UDP, RTP, … Couche de réseau : Généralement la partie haute d’IP, offrant l’interface de ses services à la couche de transport. © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 10
11. Absence de convergence logicielle opérationnelle, sur circuit bande de base Couches protocolaires « basses » (≤ niveau 3) de signalisation I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Couches protocolaires « basses » (≤ niveau 3) de signalisation Dans de nombreux cas, chaque pile protocolaire à ses propres couches de signalisation. Il est possible d’unifier leur gestion (mécanisme par lequel elles s’exécutent, sont gérées et contrôlées). Couches protocolaires « basses » (≤ niveau 3) de transmission de données du monde IP de données du monde IP Redondance de couches IP ou de sous-couches d’adaptation vers IP. Les piles possèdent une couche 2 qui leur est spécifique (même s’il existe des points communs, comme les différentes couches MAC des normes IEEE 802.11, IEEE 802.15 ou IEEE 802.16). Les couches 1 sont fortement dépendantes des protocoles et du matériel. © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 11
12. Approche propriétaire basée sur des RTOS généralistes Historiquement, les industriels ont choisi de concevoir I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Historiquement, les industriels ont choisi de concevoir leurs piles protocolaires à partir d’un environnement connu Les systèmes d’exploitation temps réel (ou RTOS : Real-Time Operating Systems). Ces RTOS sont généralistes : Tâches concurrentes disjointes (sans communication ou interaction) ou compétitives (accédant à certaines ressources partagées compétitives (accédant à certaines ressources partagées comme le temps processeur). Le découpage d’une pile protocolaire en tâches s’est fait en attribuant une couche ou sous-couche par tâche. © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 12
13. Avantages Inconvénients I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Approche propriétaire basée sur des RTOS généralistes Avantages Inconvénients Facilité d’implémentation dans une tâche. Comportement dynamique dépendant du découpage et des priorités des tâches. Facilité d’interfaçage (mémoire partagée, sémaphores, boîtes aux lettres, …). Disparité des services utilisés entre les couches d’une même pile protocolaire, et redondance de mécanismes communs qui y sont implémentés. Richesse des services utilisables. Disparité des services utilisés entre les couches d’une même pile protocolaire. Portage et adaptation assurés ou sous-traités au fournisseur du RTOS. Dépendance vis-à-vis du RTOS (changement d’environnement coûteux si aucune couche d’adaptation n’a été prévue). Dépendance vis-à-vis du fournisseur du RTOS. Répartition du temps processeur. Surcoût lié à la commutation de contexte, avec risque Répartition du temps processeur. Surcoût lié à la commutation de contexte, avec risque d’écroulement des performances sans maîtrise ni gestion de priorité des flux internes. Facilité d’organisation du travail (une équipe par couche protocolaire). Absence de règles d’utilisation de services RTOS communs et de développement de code commun. Priorités affectées par couches (ou sous-couches) et non par flux (connexion ou lien inter-couche). Absence d’architecture et services standards pour gérer les protocoles (mise à jour, qualité de service, …). © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 13
14. Approche standardisée par framework : Les STREAMS d’AT&T Premier framework industriel ouvert, indépendant des I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Premier framework industriel ouvert, indépendant des protocoles, et permettant d’implémenter des couches de niveau 2 à 5 du modèle OSI. A partir d’Unix System V release 4, les STREAMS sont implémentés dans son noyau mono-tâche. Ils ont été adaptés à plusieurs RTOS (dans une de leurs tâches). Les STREAMS possèdent : Les STREAMS possèdent : Une API (Application Programming Interface) et des services restreints pour les modules (code embarqué dans le noyau). Une API et des services pour le code utilisateur (hors noyau). Un micro-séquenceur de modules . © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 14
15. Approche standardisée par framework : Les STREAMS d’AT&T I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoin pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Architecture générale des STREAMS et des passages de messages Architecture générale des STREAMS et des passages de messages © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 15 Copyright 1994-2009 Sun Microsystems, Inc. Les STREAMS ne répondent pas aux contraintes de gestion de la qualité de service propres aux environnements sans fil. Ils imposent un modèle de contrôle (modules, devices, …) peu portable.
16. Approche standardisée par framework : DiPS+ I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions DiPS+ (Distrinet Protocol Stack) est l’un des derniers frameworks pour piles protocolaires (réf. Thèse de S. Michiels, Component Framework Technology for Adaptable and Manageable Protocol Stacks). Ecrit en Java, DiPS+ est principalement destiné aux protocoles situés au dessus des sockets (TCP ou UDP). protocoles situés au dessus des sockets (TCP ou UDP). S’adapte mal aux contraintes industrielles (couches basses en C/C++, portage sous un RTOS ou noyau, …). © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 16
17. I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Approche standardisée par framework : DiPS+ Chaîne de composants Composant DiPS+ (contenant PR – Packet Receiver, l’unité cœur – Unit, et PF – Packet Forwarder) Chaîne de composants avec un répartiteur entre deux domaines de composants parallèles. © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 17 Unit, et PF – Packet Forwarder) avec un objet police qui intercepte les paquets entrants (p). La police délègue les paquets entrants à une chaîne de modules de gestion. Schémas provenant de l’article The DiPS+ Software Architecture for Self-healing Protocol Stacks écrit par le groupe de recherche DistriNet, département informatique, Université Catholique de Leuven (Belgique)
18. Besoins pour les terminaux multistandard et convergence I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Besoins (utilisateurs ou intégrateurs) des terminaux Besoins (utilisateurs ou intégrateurs) des terminaux mobiles ne sont pas uniquement spécifiques à l’apparition du multistandard. Multiplication des flux radio, gérés par un seul circuit bande de base, incompatible avec les architectures logicielles à base de RTOS. © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 18 logicielles à base de RTOS. Approche propriétaire et fermée des piles protocolaires embarquées dans les terminaux rend leur intégration sur un seul circuit bande de base très difficile.
19. Diminution du nombre de circuits des plateformes multistandard I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Matériellement possible, comme les plateformes de l’architecture MXC (Mobile Extreme Convergence). Intégration plus poussée des terminaux multistandard. Capacités inédites pour diminuer la consommation d’énergie. © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 19 d’énergie. Diminution du coût de production des terminaux, et du coût des redevances (royalties).
20. Faciliter le cycle de développement Transfert d’une partie de la complexité matérielle vers le I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Transfert d’une partie de la complexité matérielle vers le logiciel, plus facile à mettre au point. Le développement de protocoles, à partir des spécifications, s’appuie entièrement sur le framework de WiMPS. L’intégration d’un protocole existant à l’intérieur de WiMPS Permet de la faire communiquer efficacement avec d’autres protocoles au sein d’une même pile multistandard. protocoles au sein d’une même pile multistandard. Permet d’avoir une vue uniforme du protocole, comparable aux autres protocoles fonctionnant sous WiMPS. - Demande une phase de retro-ingénierie pour respecter le framework de WiMPS. © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 20
21. Passerelles modem et multistandard simultané Un terminal (sens large) peut jouer le rôle de relai pour I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Un terminal (sens large) peut jouer le rôle de relai pour transmettre des données entre un standard et un autre Les solutions actuelles remontent jusqu’à la couche applicative, en passant par deux circuits bande de base et un processeur applicatif (mettant en œuvre des logiciels situés sur 5 processeurs). logiciels situés sur 5 processeurs). WiMPS permet de ne remonter qu’à la couche réseau, d’éviter le passage par le processeur applicatif, et de n’utiliser que 2 processeurs. © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 21
22. Passerelles modem et multistandard simultané Plateforme matérielle I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Plateforme matérielle convergente d’un terminal mobile RF RF SiP SiP RF RF SiP SiP Pile multistandard WiMPS © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 22 (ex: Architecture MXC des plateformes Freescale) RF RF SiP SiP Pile multistandard WiMPS
23. Reconfiguration La reconfiguration des protocoles permet, sous I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions La reconfiguration des protocoles permet, sous requête extérieure, de changer les paramètres d’une couche ou sous-couche protocolaire afin de modifier son fonctionnement : Paramètres de configuration de la radio (SDR : Software Defined Radio) ou de la couche physique (L1 : Layer 1). Paramètres des couches 2 et supérieures. Support dynamique de reconfiguration possible. © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 23
24. Mise à jour La mise à jour de protocoles, couches ou sous-couches I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions La mise à jour de protocoles, couches ou sous-couches protocolaires permet de changer une partie du code exécutable. Elle évite les retours des terminaux à l’usine pour changer le code des protocoles (situé en mémoire flash). Elle peut s’opérer par câble (chez le distributeur possédant le logiciel ad-hoc) ou bien à distance à travers possédant le logiciel ad-hoc) ou bien à distance à travers un protocole de transfert de fichier. Elle permet de pallier aux bogues et évolutions logicielles . © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 24
25. Gestion unifiée des protocoles, couches et sous- I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Gestion unifiée Gestion unifiée des protocoles, couches et sous- couches protocolaires pour : Leur contrôle (démarrage, arrêt, suspension, reprise). Leur comportement dynamique (qualité de service en termes de débit, de délai, de priorité et d’action sur les flux). Leur suivi statique (relevé de compteurs et de Leur suivi statique (relevé de compteurs et de statistiques). Leur suivi dynamique (traçage des données échangées, déclencheur de trace ou de relevé sur évènement, …). © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 25
26. L’ouverture avec quel modèle de revenus ? Le monde fermé et propriétaire des industriels permet de I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Le monde fermé et propriétaire des industriels permet de leur garantir des revenus par redevances. La contrepartie est l’absence d’architectures ou d’interfaces communes, sans lesquelles une réponse convergente aux besoins des terminaux multistandard est difficilement envisageable. La concentration du secteur des semi-conducteurs des La concentration du secteur des semi-conducteurs des dernières années a éliminé la plupart des « tierces parties » fournissant les piles protocolaires. Ces besoins ne peuvent trouver de réponses sans ouverture (≠ gratuité). © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 26
27. Critères pour le cahier des charges Principaux critères techniques = résultat de l’étude technique menée par le créateur + expérience du créateur I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Principaux critères techniques = résultat de l’étude technique menée par le créateur + expérience du créateur Un seul logiciel sur un seul processeur (convergence sur le MCU ou le DSP du circuit bande de base). Séquenceur spécialisé et collaboratif de couches / sous- couches protocolaires. Framework commun = ensemble d’interfaces orientées objets à hériter ou utiliser pour implémenter des protocoles. à hériter ou utiliser pour implémenter des protocoles. Tous les mécanismes communs dont ont besoin les protocoles sont pris en charge par les services de WiMPS. Langage de programmation : C++ (performance). Exclusion de toute librairie standard (pour faciliter la mise au point, l’intégration et le portage). © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 27
28. Critères pour le cahier des charges Critères « marché » = avis remontés par l’étude I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Critères « marché » = avis remontés par l’étude Réduction conso d’énergie - + - + Apport fonctionnalités - + - + Intégration Réduc. volume - + - + Réduction coûts - + - + ? ? Indépendance V-à-v matériel - + - + Intégration facilitée - + - + Simplification Dév. & MaJ log. - + - + Réduction coûts - + - + ? Avis des experts Avis des industriels de la téléphonie mobile Avis des industriels du M2M Simplification Dév. & MaJ log. - + - + Intégration facilitée - + - + Indépendance V-à-v matériel - + - + Réduction coûts - + - + © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 28 Simplification Dév. & MaJ log. - + - + ? ? Indépendance V-à-v matériel - + - + Interlocuteur unique - + - + Intégration facilitée - + - + Intégration Réduc. volume - + - + ? Réduction conso d’énergie - + - + ? Apport fonctionnalités - + - + Interlocuteur unique - + - + Réduction conso d’énergie - + - + ? Intégration Réduc. volume - + - + ? Apport fonctionnalités - + - + Interlocuteur unique - + - + Avis collectés et synthétisés par DEVELOPPEMENT & CONSEIL
29. Critères pour le cahier des charges Avis supplémentaires des experts : I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Avis supplémentaires des experts : - + - + Reconfiguration simplifiée - + - + Utilisation en parallèle Bridging • Mises à jour à distance • Adaptation à de nouveaux standards (nouvelles générations ou nouveaux lieux) sans intervention sur le hardware (changement ou flash de chipset en particulier) • Attente idéale : « intégralement configurable à distance par téléchargement sur l’interface d’une nouvelle technologie radio » • Utilisation en « modem », ex. oreillette bluetooth, convergence mobile • Fonctionnalité jugée très intéressante (travaux actuels : cf. X.Lagrange et J.Palicot) • Incertitude : « Wi Telecoms apporte-t-il réellement un gain en performance ? » © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 29 Utilisation en parallèle - + - + - + - + Switch d’un standard à l’autre • 2 communications sur 2 standards en parallèle : Ex. téléphoner + télécharger, envoi d’alarmes + communication, GPS + communication • Intérêt avéré mais incertitude sur performance de la solution • Fonctionnalité très associée à la notion de mobilité (ex. téléphone cellulaire, transports…) • Utilité ponctuelle Avis collectés et synthétisés par DEVELOPPEMENT & CONSEIL
30. Décomposition fonctionnelle Pile multistandard WiMPS Implémentation des protocoles Protocole 1 Protocole 2 Protocole N Interfaces utilisateur Noyau Services communs protocolaires Indicateurs de temps Files de messages Ordonnanceur collaboratif de traitement des évènements QoS Echéancier temporel Couches Connexions Points d’accès (SAP) Pile multistandard Unité données (PDU) Contrôle flux, débits, … Composants logiciels dynamiques Protocoles Evènements avec priorités associées Messages © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 30 Indicateurs de temps Blocs mémoire Transferts mémoire Indicateur temps réel Evènements sous IT Abstraction du matériel dynamiques Outils de débogage DMA Contrôleur IT Timers temps-réel Interface RF-IF Interface gestion d’énergie Interface RF-IF Comm. inter-contextes Messages Interface RF-IF
31. Principaux composants I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Séquenceur Gestionnaire de pile Séquenceur de Micro- traitements Ordonnanceur de canaux Canaux d’accès Entités protocolaires Gestionnaire de connexions Micro-traitements Couches d’adaptation © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 31 de connexions Profils de Qualité de Services (QdS) Connexions protocolaires Gestionnaire de temps Anneau et Table de hachage d’Alarmes temporelles
32. Principaux composants I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions N-SAP (OSI) Couche N (OSI) Couche N+1 (OSI) Entités protocolaires Canaux d’accès Flux de données protocolaires Entités protocolaires Paire de connexions Rôle du canal d’accès = point d’accès monodirectionnel (ou demi-SAP) © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 32 protocolaires (mode connecté) Canaux d’accès (mode connecté) Connexion protocolaire descendante Connexion protocolaire montante Flux de données protocolaires Paire de connexions protocolaires unidirectionnelles
33. Principaux composants I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Pr.1 Pr.1 mc 1 mc 1 mc 2 mc 2 mc 3 mc 3 mc 4 mc 4 mc 5 mc 5 mc 6 mc 6 mc 7 mc 7 mc 8 mc 8 4 a 4 a 3 a 3 a 2 a 2 a 1 a 1 a 1 b 1 b 2 b 2 b 3 b 3 b 1 c 1 c 2 c 2 c 3 c 3 c Pr.n Pr.n Canal d’accès de priorité n (Pr.2 et Pr.4 ont la même implémentation concrète) Canal d’accès de priorité n (Pr.2 et Pr.4 ont la même implémentation concrète) Traitement protocolaire b Traitement protocolaire b Traitement protocolaire a Traitement protocolaire a Traitement protocolaire c Traitement protocolaire c Entité protocolaire Entité protocolaire Pr.1 mc 1 mc 2 mc 3 mc 4 mc 5 mc 6 mc 7 mc 8 4 a 3 a 2 a 1 a 1 b 2 b 3 b 1 c 2 c 3 c Pr.n Canal d’accès de priorité n (Pr.2 et Pr.4 ont la même implémentation concrète) Traitement protocolaire b Traitement protocolaire a Traitement protocolaire c Entité protocolaire Graphes de micro- traitements appartenant à une entité protocolaire © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 33 Pr.4 Pr.4 Flux de données protocolaires Flux de données protocolaires Chaînage des références des graphes de Micro-traitements Chaînage des références des graphes de Micro-traitements Pr.2 Pr.2 Référence à un Micro-traitement Référence à un Micro-traitement implémentation concrète) implémentation concrète) Micro-traitements de l’Entité protocolaire Micro-traitements de l’Entité protocolaire Pr.4 Flux de données protocolaires Chaînage des références des graphes de Micro-traitements Pr.2 Référence à un Micro-traitement implémentation concrète) Micro-traitements de l’Entité protocolaire
34. Architecture générale Interface applicative en mode connecté Interface applicative en mode non- connecté générale © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 34 Interfaces numériques avec les circuits RF
35. Exemple de mise en œuvre Interface applicative de contrôle de téléphonie GSM/GPRS CC SS SMS Interface applicative de transfert de données en mode circuit et paquet UDP TCP en œuvre RR/GRR CC SS SMS LLC SNDCP MM/GMM IP PPP 3 standards protocolaires intégrées dans une seule pile multistandard: • GSM © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 35 Interface L1 GSM RF (mode circuit) RLC MAC Interface L1 GRPS RF LLC RLP LAPDm • GSM • GPRS • TCP-UDP/IP
36. Méthodologie de développement Encadrée par l’utilisation du framework de WiMPS I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Encadrée par l’utilisation du framework de WiMPS Le développement ou l’adaptation d’un protocole sous le framework doit utiliser les conteneurs (= classes à dériver) suivants : Entité protocolaire, Couche d’adaptation, Couche d’adaptation, Canal d’accès, Connexion (si le protocole supporte les connexions), Micro-traitement. © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 36
37. Méthodologie de développement Les traitements protocolaires sont réalisés dans I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Les traitements protocolaires sont réalisés dans l’implémentation des micro-traitements. Cette implémentation a accès aux services suivants : Service de messages (allocation, lecture, écriture, …). Service d’alarmes temporelles (armement, réveil, …). Service d’utilisation de connexion (demande d’établissement, accès à la connexion établie, …). accès à la connexion établie, …). Service d’utilisation de l’ordonnanceur de canaux (indications pour la gestion des priorités). Les services s’appuient sur l’environnement (couches d’abstraction du matériel et du système d’exploitation). © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 37
38. Avancement en environnement simulé Plusieurs composants principaux ont été réalisés et testés I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Plusieurs composants principaux ont été réalisés et testés sous Linux (environnement utilisateur) : o Composant Message. o Composant Alarme temporelle. o Composant Canal d’accès. o Composant Micro-traitement. o Composant Connexion. o Composant Connexion. En cours de réalisation : o Composant Entité. o Composant Couche d’adaptation. o Composant Qualité de Service. © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 38
39. Avancement en environnement simulé I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Premiers protocoles à être développés sous WiMPS : Suite TCP-UDP / IP o A des fins de mesure de performance. o Pour mesurer la perte liée au framework par rapport à une implémentation « en dur » comme celle de Linux. Développement de MAC 802.11g Développement de MAC 802.11g o A des fins de mesure de performance. o Testé sur un flux simulé (Simulink ou Scilos ?). © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 39
40. Prototype sur carte électronique I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Recherche en cours d’une carte électronique d’évaluation offrant un circuit bande de base : Connecté à deux puces RF-IF de standards distincts (par exemple : Wifi 802.11 a et 802.11 g ). Fournissant les couches physiques (L1) pour chaque standard, le programme de boot de la carte, et les drivers matériel. programme de boot de la carte, et les drivers matériel. Fournissant la chaîne de compilation croisée (compilateur C++, éditeur de lien et assembleur pour cible) et les outils de chargement de code et de débogage. © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 40
41. Conclusion & Questions I. Présentation générale II. Convergence matérielle & logicielle des radiocom. III. Architectures logicielles pour piles protocolaires IV. Besoins pour les terminaux multistandard V. Architecture logicielle et méthodologie de WiMPS VI. Avancement du prototype WiMPS VII. Conclusion & questions Framework et moteur bientôt réalisés (avril 2009). Prototype intégré sur carte électronique prévu à l’été 2009. Moyens pour développer les couches pour terminaux mobiles (standards GSM et 3GPP) ? Recherche à réaliser concernant la gestion de la QoS. Recherche à réaliser concernant la gestion de la QoS. Outils externes (non embarqués) de configuration / reconfiguration, contrôle et maintenance à distance, génération semi-automatique de protocoles, … à réaliser. © 2009 Wi Telecoms Séminaire à Supélec Rennes - 2 avril 2009 41