Brevet FR2855699A1 — publié le 20041203

Système de spécification et de mise en #uvre de protocole de communication et de transmission, procédé, spécification, dispositif de communication et programmes d'ordinateur correspondant. La présente invention se rapporte au domaine des protocoles de communications. Plus précisément, l'invention concerne la génération automatique de spécification de protocoles de communication entre un ou plusieurs émetteurs et un ou plusieurs récepteurs. Le développement de protocoles de signalisation dans le domaine des télécommunications comporte une phase de spécifications, une phase de développement des logiciels dans les entités, distantes qui communiquent en appliquant ces protocoles, suivi souvent d'une phase de test. Dans beaucoup de cas, les entités communicantes ne sont pas développées par les mêmes équipes ou entreprises (par exemple l'infrastructure fixe et les mobiles dans le cas d'un réseau de télécommunications pour mobiles). Dans ces cas, les spécifications ne sont pas, en général, rédigées par les équipes de développement, mais par des groupes composés de personnes venant de différentes entreprises, typiquement parmi celles qui vont développer les équipements, ou encore les acheter pour les mettre en #uvre. On observe en pratique un décalage important entre les méthodes et approches des groupes de spécification, comparées avec celles des équipes de développement. Au pire, la spécification d'un protocole est rédigée en langage naturel, n'est pas complète, contient des incohérences, et demande pour être comprise de nombreuses informations dispersées dans d'autres documents. A l'opposé, un logiciel une fois réalisé est une instance formelle, complète et logiquement cohérente de la spécification du protocole, et ce tout en pouvant être erroné, au sens où il ne permet pas un interfonctionnement tel que prévu par le groupe de spécification avec une entité distante paire développée indépendamment. Ce décalage, outre les risques de réalisation erronée, de problèmes de multiplicité de représentation et de problèmes d'évolution qu'il entraîne, est la source d'un important travail d'analyse et d'exégèse, et plus généralement d'efforts de compréhension de la part des équipes de développement. Ce travail de reconstruction n'apparaît pas intrinsèquement nécessaire, et est dupliqué par chaque équipe de développement. Cela est une source de coûts inutiles, et d'inefficacité de la chaîne prise dans son ensemble. Une autre source de surcoûts vient de ce que les spécifications de protocoles intéressant un même objet (par exemple, un portable GSM) ne sont pas rédigées par un seul groupe. La variété des approches rédactionnelles suivies par ces différents groupes limite fortement la possibilité d'unifier l'approche de développement. Cela est une source d'inefficacité du développement lui-même, des tests, ainsi que du volume de code généré (il est difficile de mettre en commun ce qui intrinsèquement peut l'être, simplement parce que spécifié différemment). Il apparaît donc utile d'étudier comment réduire ce travail intermédiaire, par l'introduction de méthodes formelles et unificatrices. De telles méthodes peuvent être dans un premier temps appliquées à une équipe de développement, puis, dans la mesure du possible aux spécifications elles-mêmes. On connaît dans l'état de la technique quelques méthodes publiées allant dans ce sens, notamment: ASN.l, XML, CSN.l et SDT. Ces différentes méthodes et les langages formels associés ne correspondent pas tous aux mêmes parties de la spécification d'un protocole. Il est donc nécessaire de rentrer un peu plus dans le détail de ce qu'est un protocole et sa spécification. Un protocole est essentiellement un langage permettant à deux machines distinctes et distantes d'échanger des informations en utilisant in fine un médium de transmission. En pratique ce langage est organisé en différentes parties plus ou moins indépendantes, chacune étant considérée elle-même comme un protocole. Les protocoles sont alors arrangés en couches, chaque protocole à l'exception du plus bas utilisant non pas directement le médium de transmission mais un service de transmission fourni par le protocole directement inférieur . A l'instar des langages humains, les protocoles peuvent être analysés du point de vue du vocabulaire ou lexique (liste de types de messages, listes de parties de message), de l'encodage (phonèmes et morphèmes pour les langages humains, formes d'onde et encodage numérique pour les protocoles), de la syntaxe (règles de grammaire), de la sémantique (sens des messages et des parties de message), des règles de procédure (règles régissant les dialogues entre les entités dialoguant ; c'est cette partie qu'évoque le mot protocole ), et enfin de la praxis (effet des messages). Certains de ces aspects sont bien déterminés, et apparaissent en clair dans la majorité des spécifications (le lexique, l'encodage, les règles de procédures). D'autres sont souvent mal perçus et, de ce fait, spécifiés sans méthode (sémantique et praxis). Dans une majorité de spécifications, on peut identifier deux parties distinctes : le lexique et l'encodage d'une part, et la spécification des procédures . Le lexique apparaît sous la forme de listes des messages et de parties de messages ( élément d'information ), chacun avec la grammaire et l'encodage associé. Les règles de procédure sont spécifiées comme une liste de procédures plus ou moins indépendantes, décrites comme les actions entraînées par la réception de messages venant de l'entité paire ou de commandes venant d'autres logiciels dans la même machine. Cela couvre le plus souvent aussi bien les règles de procédure (actions et réactions visibles, et donc testables, dans le flot d'information circulant entre les entités paires) que la praxis plus générale (actions internes non nécessairement visibles). La spécification de la sémantique est dispersée dans la description des éléments lexicaux, dans la description des procédures, et souvent dans d'autres documents. Les méthodes formelles qu'on peut trouver dans les publications se concentrent sur la formalisation de l'encodage et la syntaxe d'une part (ASN.l, CSN.l, XML), et sur les procédures vues comme des séquences temporelles d'action (SDT, SDL). ASN.l (Abstract Notation 1) est un langage formel spécifié par l'ISO (série X. 680 et X. 690) permettant de décrire des structures de données en distinguant une description abstraite (i.e., pouvant s'appliquer à différentes méthodes d'encodage) et des méthodes d'encodage de ces structures de données. Il est appliqué couramment à la description de la structure des messages d'un protocole, chaque message étant considéré comme une structure de donnée. Parce que formelle, une spécification écrite en ASN.l peut être traduite automatiquement en un logiciel d'encodage et de décodage de messages. ASN.l a été récemment étendu pour permettre la description formelle de méthodes d'encodage, dans le but d'appliquer ASN.l à des spécifications soit non écrite originellement en ASN.l, soit pour lesquelles les méthodes générales d'encodage spécifiées par l'ISO ne sont pas satisfaisantes pour une raison ou une autre. XML est un langage formel dont les buts sont proches de ceux d'ASN.l en ce qu'il permet de décrire des structures de données et donc des messages quand on les limite à une structure de données. Comme ASN.l, XML permet la génération automatique de logiciels d'encodage et décodage. CSN.l est un langage formel développé par l'inventeur, et utilisé dans quelques spécifications de protocoles de l'ETSI. Ce langage permet de décrire la grammaire de chaînes de bits (et s'apparente beaucoup plus aux langages de description de grammaire formelle comme la BNF, que des langages de description de données), et peut être utilisé pour décrire la structure en tant que chaîne de bits des messages de la majorité des protocoles de télécommunications. Il se distingue dans ces buts de deux manières de l' ASN.l ou de XML : il peut être utilisé a posteriori, pour décrire des messages dont l'encodage est décrit de manière quelconque dans une spécification, et il ne cherche pas à aborder même partiellement la sémantique liée à la structure. Comme dans le cas des langages précédents, une spécification en CSN.l peut être utilisée pour la génération automatique de l'encodage et du décodage de messages. Par rapport à ASN.l et XML, CSN.l présente l'avantage de s'appliquer à tout protocole, et donc de permettre une réalisation unifiée de la partie correspondante de la réalisation du protocole. En contrepartie, CSN.l ne décrit pas les messages en tant que structures de données, et cette liaison ne peut donc pas être générée automatiquement. Dans un tout autre domaine, SDT ou SDL (ainsi que d'autres méthodes apparentées) s'adressent à la formalisation des procédures vues comme séquences temporelles d'action. Ces méthodes sont centrées chacune autour d'un langage formel décrivant des événements (réception de messages ou de commandes internes) et des séquences d'action initiées par ces événements (envoi de messages ou de réponses internes, mémorisation de données, transition d'états, ...). Ces méthodes mettent l'accent principalement sur la vision des entités des protocoles comme des automates d'états, un état étant un résumé des aspects du contexte (données mémorisées) de chacune des entités paires qui interviennent dans le choix de l'action à entreprendre suite à chaque événement. Ainsi, ces méthodes permettent de formaliser principalement les règles de procédure et, dans une certaine mesure, la praxis, et enfin, indirectement, la sémantique des messages. Un inconvénient de cette technique de l'art antérieur est que les méthodes publiées jusqu'à présent souffrent de nombreuses limitations. En premier lieu elles ne permettent qu'une formalisation très partielle des spécifications de protocoles, principalement l'encodage des messages et parties de message. Une autre limitation très importante, particulièrement visible dans le cas de l'ASN.l, est qu'elles ne permettent pas en général d'intégrer dans une même approche des protocoles qui ne sont pas spécifiés initialement suivant ladite méthode. CSN.l est ici une exception. Quant à SDL et apparentées, ces méthodes ne capturent que la notion d'automate ; or les protocoles récents, à l'exemple de ceux faisant partie des spécifications de l'UMTS, sont des automates très simples, la complexité étant plutôt dans les structures de données et les algorithmes d'encodage. Un autre inconvénient des spécifications en langage formel selon l'état de l'art ne donnant pas de forme de signal est qu'elles conduisent généralement à des formes de signal inefficaces. L'invention selon ses différents aspects a notamment pour objectif de pallier ces inconvénients de l'art antérieur. Plus précisément, un objectif de l'invention est d'optimiser la spécification de protocole de communication et sa mise en #uvre concrète. Un autre objectif de l'invention est de permettre un développement rapide et efficace de piles de protocoles de communication, notamment dans le domaine des communications mobiles. L'invention a également pour objectif de permettre la génération automatique d'une partie substantielle des logiciels nécessaires à la mise en #uvre du protocole. L'invention a aussi pour objectif de limiter l'intervention humaine dans les différentes phases de mise en oeuvre d'un protocole de communication dans un émetteur et/ou un récepteur, afin notamment dans réduire la durée et de limiter les erreurs humaines pouvant entraîner un fonctionnement de l'émetteur et/ou de du récepteur non optimal. Dans ce but, l'invention propose un système de spécification et de mise en #uvre d'un protocole de gestion de communication et de transmission entre au moins un émetteur et au moins un récepteur, comprenant: - des moyens de détermination d'un contexte commun comprenant des moyens de description d'un ensemble de données gérées par le ou les émetteurs et/ou leou les récepteurs ; - des moyens d'identification des messages de protocole susceptibles d'être échangés entre le ou les émetteurs et le ou les récepteurs, l'identification étant indépendante de la ou des représentations utilisées pour les messages; - des moyens de définition de représentations de données stockées et/ou transmises par le ou les émetteurs et/ou le ou les récepteurs à partir de la détermination d'un contexte commun et de l'identification des messages, la définition de représentations permettant de déterminer des instructions d'implémentation du protocole dans au moins un des émetteurs et au moins un des récepteurs ; et - des moyens de mise en #uvre du protocole dans au moins un des émetteurs et au moins un des récepteurs à partir des instructions d'implémentation, de façon à ce que le ou les émetteurs soient aptes à communiquer avec le ou les récepteurs. On note qu'un protocole de gestion de communication s'entend ici au sens strict et ne comprend notamment pas les protocoles de synchronisation de bases de données qui ici ne sont pas considérés comme des protocoles de gestion de communication. Selon une caractéristique particulière, le système est remarquable en ce que les moyens de détermination d'un contexte commun comprennent eux-mêmes des moyens de description d'une structure du contexte, la description étant indépendante de la ou des représentations utilisées pour le stockage et/ou la transmission des données. La notion d'indépendance signifie ici qu'on peut changer et/ou modifier la représentation de stockage sans invalider la représentation abstraite. Selon une caractéristique particulière, le système est remarquable en ce que les moyens de détermination d'un contexte commun comprennent en outre des moyens d'identification et de description des types d'objets permettant d'analyser la structure du contexte, l'identification et la description des types d'objets étant indépendantes de la ou des représentations utilisées pour le stockage et/ou la transmission. Selon une caractéristique particulière, le système est remarquable en ce que tout ou partie des données gérées sont les données que le protocole vise à maintenir cohérent dans au moins un émetteur parmi le ou les émetteurs et au moins un récepteur parmi le ou les récepteurs. La notion de données cohérentes signifie ici que ces données ont une identité sémantique mais pas nécessairement une identité de représentation. Par exemple, une fréquence exprimée en MHz peut avoir la même signification qu'une fréquence exprimée en Hz alors que la représentation est différente. Selon une caractéristique particulière, le système est remarquable en ce qu'au moins une partie de l'identification des messages est effectuée en termes d'actions et/ou de ses effets sur le contexte commun. Selon une caractéristique particulière, le système est remarquable en ce qu'il comprend des moyens de liaison entre : - une description de la forme de signal effectivement transmis ; et - l'identification des messages de protocole. Selon une caractéristique particulière, le système est remarquable en ce que la forme du signal appartient au groupe comprenant : - les suites de données binaires ; - les suites d'éléments pris dans un alphabet prédéterminé ; - les suites de formes d'ondes modulées. Ainsi, le signal peut être associé à des types de symboles très divers. Selon une caractéristique particulière, le système est remarquable en ce que la liaison se fait dans un langage de spécification de données comprenant des fonctions permettant la description des données sous forme d'attributs d'objets abstraits et de fonctions s'appliquant sur des représentations concrètes. Selon une caractéristique particulière, le système est remarquable en ce que la spécification de la forme de signal se fait en langage CSN1 enrichi de fonctions permettant la description des données sous forme d'attributs d'objets abstraits et de fonctions s'appliquant sur des représentations concrètes. Selon une caractéristique particulière, le système est remarquable en ce qu'il comprend des moyens d'utilisation des données de contexte dans une description formelle d'un encodage et/ou d'un décodage. Selon une caractéristique particulière, le système est remarquable en ce que les moyens de détermination d'un contexte commun, les moyens d'identification des messages de protocole et les moyens de définition de représentations de données mettent chacun en oeuvre un langage formel permettant une détermination automatique du logiciel de mise en #uvre du protocole. Selon une caractéristique particulière, le système est remarquable en ce qu'il comprend des moyens de détermination automatique du logiciel de mise en #uvre du protocole. Selon une caractéristique particulière, le système est remarquable en ce qu'il comprend des moyens de détermination automatique de tests de dispositifs mettant en #uvre le protocole. Selon une caractéristique particulière, le système est remarquable en ce que les moyens de détermination d'un contexte commun comprennent des moyens de traduction d'un mode de représentation d'un protocole en la description d'un ensemble de données. Selon une caractéristique particulière, le système est remarquable en ce que les moyens d'identification des messages de protocoles comprennent des moyens de traduction d'un mode de représentation de protocoles. Cette caractéristique permet notamment le développement d'une description dans le formalisme de l'invention à partir d'une description existante, issue par exemple d'un comité de normalisation. Ainsi, grâce à son universalité, l'invention permet avantageusement la réutilisation des parties communes à plusieurs protocoles et notamment l'invention offre la possibilité d'avoir un noyau de protocole que l'on enrichit de spécificités pour créer d'autres protocoles ayant chacun leur spécificité. Selon une caractéristique particulière, le système est remarquable en ce qu'il comprend en outre des moyens de visualisation de la sémantique des messages de protocoles échangés entre le ou les émetteurs et/ou le ou les récepteurs. Cette étape est particulièrement utile et efficace pour tester un protocole de communication et/ou ses dispositifs de mise en #uvre. En outre, l'invention concerne un procédé de spécification et de mise en #uvre d'un protocole de gestion de communication et de transmission entre au moins un émetteur et au moins un récepteur, remarquable en ce qu'il comprend les étapes suivantes : - détermination d'un contexte commun comprenant une description d'un ensemble de données gérées par le ou les émetteurs et/ou le ou les récepteurs ; - identification des messages de protocole susceptibles d'être échangés entre le ou les émetteurs et le ou les récepteurs, l'identification étant indépendante de la ou des représentations utilisées pour les messages; - définition de représentations de données stockées et/ou transmises par le ou les émetteurs et/ou le ou les récepteurs à partir de la détermination d'un contexte commun et de l'identification des messages, la définition de représentations permettant de déterminer des instructions d'implémentation du protocole dans au moins un des émetteurs et au moins un des récepteurs ; et - mise en #uvre du protocole dans au moins un des émetteurs et au moins un des récepteurs à partir des instructions d'implémentation, de façon à ce que le ou les émetteurs soient aptes à communiquer avec le ou les récepteurs. De plus, l'invention concerne une spécification d'un protocole de communication, caractérisée en ce qu'elle est obtenue par la mise en #uvre du procédé décrit précédemment, de spécification et de mise en #uvre d'un protocole de gestion de communication et de transmission. L'invention concerne également un langage formel de description d'au moins un élément de protocole de communication, remarquable en ce qu'il est adapté à la mise en #uvre du procédé précédemment décrit, de spécification et de mise en #uvre d'un protocole de gestion de communication et de transmission. L'invention concerne aussi un dispositif de communication, remarquable en ce qu'il comprend des instructions permettant l'émission et/ou la réception de données vers ou d'un dispositif tiers un autre dispositif selon un protocole obtenu par la mise en #uvre du procédé tel que décrit précédemment. De plus, l'invention concerne un produit programme d'ordinateur comprenant des éléments de programme, enregistrés sur un support lisible par au moins un microprocesseur, caractérisé en ce que les éléments de programme contrôlent le ou les microprocesseurs pour qu'ils effectuent les étapes suivantes adaptées à la spécification de protocole de communication et de transmission entre au moins un émetteur et au moins un récepteur: - détermination d'un contexte commun comprenant une description d'un ensemble de données gérées par le ou les émetteurs et/ou le ou les récepteurs ; - identification des messages de protocole susceptibles d'être échangés entre le ou les émetteurs et le ou les récepteurs, l'identification étant indépendante de la ou des représentations utilisées pour les messages; - définition de représentations de données stockées et/ou transmises par le ou les émetteurs et/ou le ou les récepteurs à partir de la détermination d'un contexte commun et de l'identification des messages, la définition de représentations permettant de déterminer des instructions d'implémentation du protocole dans au moins un des émetteurs et au moins un des récepteurs ; et - mise en #uvre du protocole dans au moins un des émetteurs et au moins un des récepteurs à partir des instructions d'implémentation, de façon à ce que le ou les émetteurs soient aptes à communiquer avec le ou les récepteurs. L'invention concerne également un produit programme d'ordinateur, comprenant des séquences d'instructions adaptées à la mise en #uvre du procédé de spécification de protocole de communication entre au moins un émetteur et au moins un récepteur lorsque le programme est exécuté sur un ordinateur. Les avantages du langage formel, de la spécification de protocole, du dispositif et des programmes d'ordinateur sont les mêmes que ceux du procédé de spécification de protocole, ils ne sont pas détaillés plus amplement. D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels la figure 1 présente un synoptique de spécification d'un protocole conforme à l'invention selon un mode particulier de réalisation. En préliminaire de la description de la nouvelle méthode proposée, il est utile de faire un détour par les méthodes de programmation mettant l'accent sur les données, et de décrire la relation entre données et protocoles. Les deux dernières décennies ont vu un développement important de la programmation de logiciel partant des données plutôt que des algorithmes. Ces méthodes consistent à décrire d'abord les structures de données mémorisées par le logiciel, en mettant en évidence les objets et types d'objet gérés par le logiciel. Un objet, à ce sens, peut être un objet concret, selon le sens commun, comme un écran ou un clavier, mais aussi quelque chose de plus abstrait comme une zone de l'écran ou un fichier, ou même très abstrait comme une file d'attente. Le point important de cette approche est qu'un type d'objet ne décrit pas seulement ses attributs, mais aussi les actions dont l'objet peut être l'objet. Cette approche de la programmation a beaucoup d'avantages. Elle amène en particulier une modularité très efficace, centrée sur les types d'objet. Jusqu'à présent, la présentation qui est faite des structures de données dans les protocoles, sous l'influence entre autres d'ASN.l est erronée. Ce qui est décrit comme des données sont les messages et parties de message, alors que les messages sont beaucoup plus proches des actions, au sens de la programmation par les objets, que des données. A l'instar de cette approche de la programmation, il faut chercher les données d'un protocole dans ce qui est mémorisé par chacune des entités paires, plutôt que dans ce qui est transmis. Cette réflexion amène à mettre en avant la notion de contexte du protocole. Nous définissons ici le contexte d'une entité comme la structure de donnée mémorisée par cette entité et contenant les données qui interviennent dans la mise en #uvre du protocole. Ces interventions sont de différents ordres : il peut s'agir de données gérées (i.e., modifiées) par l'effet de la réception d'un message du protocole, ou de données qui influencent les actions du protocole (données d'état, dont, mais pas seulement, l'état au sens de SDL). Parmi les données apparaissant dans le contexte de chacune des entités, certaines sont identiques sémantiquement de part et d'autre, c'est-à-dire dans deux entités paires du protocole. Selon l'invention, la partie identique est appelée contexte commun . Le contexte commun peut être décrit de manière monolythique ou, au contraire, par morceaux séparés. Ces données sont les mêmes au sens qu'elles ont le même sens, et sont maintenues identiques, à l'exception de certains états transitoires. On peut présenter un protocole comme ayant pour rôle, entre autres, de maintenir l'égalité de ces données. Ainsi, une part importante de la fonction de n'importe quel protocole est la gestion de données répartie dans plusieurs dispositifs émetteurs et/ou récepteurs. On présente, en relation avec la figure 1, un procédé de spécification de protocole selon l'invention. Ce procédé est préférentiellement mis en #uvre par un micro-ordinateur. Ce procédé est divisé en étapes successives : - une première étape 1 de spécification d'encodage et du décodage ; - une seconde étape 2 de spécification du contexte ; et - une troisième étape 3 de spécification de messages. L'étape 1 de spécification de l'encodage et du décodage est effectuée en CSN.l qui est connu en soi. Le premier aspect formalisé de la spécification d'un protocole suivant la méthode décrite est la spécification formelle de la structure des chaînes de bit échangées. Il s'agit de la description du lexique selon sa forme, comme une liste de structures de messages ou d'éléments de message. Cette description spécifie des ensembles de chaînes de bit acceptables, ainsi que la structure (syntaxe) de ces chaînes. Elle permet de générer automatiquement un logiciel d'encodage et de décodage, ce dernier incluant la détection de chaînes erronées (i. e., n'appartenant pas à l'ensemble des chaînes acceptables). Cette spécification est faite en CSN.l mais en variante, tout autre langage formel permettant de décrire la syntaxe de toute chaîne de bit est applicable. L'étape 2 consiste à décrire formellement la structure des données formant le contexte de chacune des entités paires. Cette description mettra en avant la partie commune des deux contextes, c'est-à-dire les données gérées comme une base de donnée répartie. Cette description formelle peut utiliser n'importe quel langage formel de description de structure de donnée, comme ASN.l, des méthodes de description telles qu'on peut les trouver dans les langages de programmation comme C++, ou comme on peut les trouver dans les logiciels de gestion de bases de données. On utilise de manière préférentielle un langage spécialement développé à cet effet, permettant de faire aisément le pont entre les structures de données apparaissant dans les messages et les descriptions de structures de données telles qu'utilisée par les développeurs, comme celles permises par le langage de programmation C++. Au cours de l'étape 3, un message est décrit de manière abstraite (i.e., indépendamment de l'encodage utilisé effectivement pour le transport) comme une suite d'actions s'appliquant aux données du contexte commun. Ceci diffère fondamentalement des descriptions usuelles, où les messages ou parties de messages sont décrits comme des structures de données. Une description de message selon la méthode donne le sens du message, sous la forme de l'effet attendu de la réception du message par l'entité paire. Elle explicite aussi le sens des paramètres, en indiquant leur rôle dans la description de l'action attendue. Cela permet de formaliser de nombreux aspects de la spécification d'un protocole qui sont traditionnellement couverts dans les descriptions de procédures par un texte en langage naturel. L'action la plus courante est le changement d'une partie des données de contexte. Une telle action est nommée ci-après SET . Elle demande deux types de paramètres : - ceux décrivant la partie du contexte concernée ; et - ceux décrivant les nouvelles valeurs à affecter. La description traditionnelle ne fait pas la distinction entre les deux types, et omet des paramètres implicites . D'autres actions typiques sont CREATE ou ADD qui créent une partie des données (par exemple, création d'un nouveau contexte d'appel). Une description des messages ou parties de message en CSN.l n'adresse que la structure de ce qui est effectivement transmis. A l'opposé, une description abstraite d'un type message le décrit en termes sémantiques, plus liés à l'impact qu'a la réception du message qu'à la forme particulière utilisée pour la transmission. Il est possible de décrire formellement la liaison entre les deux, de manière à permettre la génération automatique du logiciel depuis la réception de la chaîne de bit jusqu'à inclusivement la modification du contexte des données communes. La description de cette liaison peut se faire de diverses manières. Une de ces manières est basée sur les principes suivants. A chaque structure de chaîne de bit sont associées des fonctions nommées retournant des valeurs selon des types abstraits. Pour chaque fonction est décrit en détail l'algorithme permettant de calculer le résultat de la fonction à partir de la chaîne de bits reçue et, quand nécessaire, de la valeur courante du contexte commun. (Ce dernier point permet de formaliser des méthodes d'encodage dépendant du contexte, comme, par exemple, l'utilisation de tables d'index transmises au préalable.) Corrélativement, des règles permettent d'associer à une description abstraite une liste de fonctions nommées correspondant exactement à tous les paramètres nécessaires pour faire les actions demandées par le message. La méthode décrite a diverses applications, dont les principales sont les suivantes : - le développement automatique des logiciels de mise en #uvre de protocoles de communication ; - le développement de protocoles spécifiés selon des méthodes différentes ; - la spécification directe de protocoles de communication ; et - le développement de test de protocoles de communication. L'un des buts principaux de l'invention est de permettre la génération automatique d'une partie substantielle des logiciels nécessaires à la mise en #uvre du protocole. Une formalisation complète du protocole selon l'invention permet la génération automatique d'un encodage et d'un décodage des messages, y compris la détection de chaînes erronées, et y compris les algorithmes d'encodage ou de décodage complexes prenant en compte des données de contexte. Selon une variante de l'invention, une formalisation complète du protocole permet également la génération automatique des aspects suivants : - données de contextes ; et/ou - actions simples des messages (par exemple, le changement de valeur des données de contexte). De plus, les aspects non générés automatiquement sont traités par ajout de blocs de programme attachés, selon l'approche de la programmation des données, aux classes de données (méthodes), éventuellement comme complément aux actions générées automatiquement. Une application de la méthode consiste à traduire des protocoles spécifiés autrement (c'est-à-dire selon des méthodes différentes) dans une description conforme à l'invention. Parmi les avantages par rapport aux méthodes traditionnelles de développement, on peut citer : - uniformisation des développements ; - réduction du code généré par mise en commun des moteurs génériques (e. g., moteurs de décodage) ; - meilleure modularisation, rendant plus aisées les modifications ultérieures. L'invention permettant la spécification directe de protocoles peut aussi être mise en #uvre par des groupes de spécification. Les descriptions formelles peuvent être utilisées pour générer directement des tests permettant de vérifier la conformité d'une réalisation avec la description. La méthode complète de spécification selon le mode de réalisation décrit met en #uvre des syntaxes de description pouvant se décomposer en cinq groupes d'éléments syntaxiques (ou sous-langages formels): a) une syntaxe de description de structure de données, pour les éléments du contexte commun ; b) une syntaxe de description de l'encodage et du décodage de chaînes de symboles ; c) une syntaxe de programmation, adaptée en liaison avec les syntaxes a) et b); d) des éléments syntaxiques permettant de lier les descriptions selon les syntaxes a) et b) ; éléments peuvent être partie intégrante soit de la syntaxe a) soit de la syntaxe b), ou même se limiter à des règles de correspondance entre les descriptions selon les syntaxes a) et b) ; e) une syntaxe de description de messages comme actions agissant sur le contexte . Selon une variante préférentielle de l'invention, la méthode de spécification met en #uvre les quatres premières syntaxes a) à d) sans utiliser la dernière syntaxe e) de description de messages. Cette technique est décrite plus en détail dans les annexes 1,2 et 3, en relation avec la figure 1, de façon à ne pas surcharger la présente discussion. Il est clair cependant que ces annexes font partie intégrante de la description. L'annexe 1 comprend des éléments de description formelle spécifiant un protocole de communication. L'annexe 2 illustre une spécification de simple mise à jour de données, L'annexe 3 illustre un cas plus complexe de spécification d'un protocole GSM ( Global System for Mobile communication ) normalisé par l'ETSI (European Télécommunication Standard Institute) de gestion de mobilité entre une station mobile (MS) et une infrastructure de réseau. Les spécifications illustrées en regard des annexes 2 et 3 utilisent les éléments de description formelle de l'annexe 1 et permettent une génération automatique de code selon l'invention. Bien entendu, l'invention n'est pas limitée aux exemples de réalisation mentionnés ci-dessus. En particulier, l'homme du métier pourra apporter toute variante dans la mise en #uvre de l'invention qui peut s'appliquer non seulement au domaine des télécommunications mobiles mais à toute conception de réseau (fixe et/ou mobile) ou de lien de communications ainsi qu'à la définition des protocoles correspondant. L'invention s'applique également à différents types d'éléments communiquant, notamment terminaux de télécommunications, éléments d'infrastructure de réseau, cartes ou composants communicants à l'intérieur d'un dispositif... L'invention peut, en outre, être mise en #uvre sur des machines ou outils de développement très variés, permettant, par exemple, la spécification de protocoles de communication, la génération de codes ou plus généralement la conception et la réalisation de protocoles de communication On notera que l'invention est mise en #uvre sous la forme d'une séquence d'instructions d'un programme informatique. Aussi, la séquence d'instructions correspondante pourra être stockée dans un moyen de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce moyen de stockage étant lisible partiellement ou totalement par un ordinateur ou un microprocesseur. ANNEXE 1. Module de description formelle de protocole Un module décrit dans l'annexe 1 comprend des éléments de description formelle spécifiant un protocole de communication associés à des entités paires. Le module comprend trois types de description : - des descriptions abstraites de types d'objet (section 3); cela correspond à une syntaxe de type a) illustrée précédemment; - des descriptions de transfert s'appliquant soit à des messages, soit à des objets en tant que partie de message (section 6) ; correspond à une syntaxe de type b); - et des descriptions abstraites d'actions (messages par exemple), section 5 (syntaxe de type e)) ou des programmations d'actions, selon une syntaxe de type c). Selon une variante de l'invention, les descriptions abstraites d'actions gérées automatiquement par un système de spécification sont remplacées avantageusement par des programmations manuelles ou semi-automatiques d'actions. A chaque type correspond un langage formel distinct. Le module est essentiellement organisé comme une liste de types d'objets. A chaque type d'objet, sont associées une description abstraite, éventuellement une ou plusieurs descriptions de transfert, et éventuellement une ou plusieurs actions. A chaque action, sont associées une description abstraite et éventuellement une ou plusieurs description de transfert. Pour des raisons pratiques, l'organisation générale d'un module permet soit de grouper les descriptions selon la logique ci-dessus, soit de séparer les éléments (par exemple pour grouper tous les messages ensemble), auquel cas les liaisons sont explicitées (par exemple la description d'un message indique alors le type d'objet auquel il est associé). 1. Syntaxe de module Le module est composé d'un en-tête, suivi d'une liste de descriptions de type d'objet, de descriptions autonomes d'actions et de descriptions autonomes de structure de transfert. 1. 1 En-tête de module L'en-tête de module comporte son nom et, éventuellement, d'autres informations. 2. Spécifications de types d'objet Une description (ou spécification) de type d'objet est constituée d'un nom suivi des caractères '::=', et terminée par un caractère ' ;'. Une description comporte : - une description abstraite, introduite par le mot clé 'abstract' ; - zéro, une ou plusieurs descriptions de transfert, introduites chacune par le mot clé 'transfer' ; - zéro, une ou plusieurs descriptions d'action, introduites chacune par le mot clé 'action'. Une description de transfert décrit une structure de chaîne de symboles (par exemple binaire ou décrite par une chaîne de caractères) qui peut représenter correctement la structure abstraite (voir le chapitre sur le sujet). Une action (message) associé au type d'objet décrit des modifications pouvant être demandées à une instance dudit type d'objet. 3. Descriptions abstraites de types d'objet Une description abstraite de type d'objet se présente usuellement comme un ensemble de composants. Chaque composant est notamment caractérisé par : - un nom de composant, - des informations de présence, et une description de type. 3. 1 Nom de composant Le nom de composant est une chaîne libre utilisant les caractères disponibles à l'exception des caractères '[', '.', 3. 2 Informations de présence Par défaut le composant n'est pas indexé. Un composant indexé (tableau) peut avoir un nombre variable de copie, distinguées par un index. Un composant indexé est indiqué par une spécification d'intervalle comprise entre '[' et ']'. Différentes spécifications sont possibles : - Nombre fixe : cela est indiqué par un entier, qui est le nombre de copies. - Nombre variable libre : cela est indiqué par un intervalle (deux entiers séparés par '..'). Un cas particulier est O..infinity qui indique un nombre quelconque de copies. - Nombre variable conditionnel : cela est indiqué par une expression de type 'iif', indiquant différents intervalles ou nombre fixes à sélectionner selon des expressions booléennes portant sur les valeurs d'autres éléments de la structure. 3. 3 Description de type Cette description indique la structure du composant lui-même. Différentes descriptions sont possibles. 3. 3.1 Composants élémentaires Une telle description est introduite par un ' :'. Cela inclus : - entiers (mot clé 'integer', suivi éventuellement d'un intervalle entre parenthèses) ; - type énuméré (mot clé 'enumerated' suivi d'une liste parenthésée d'identificateurs séparés par des virgules) ; - chaîne de bit (mot clé 'bit string', suivi éventuellement d'une taille ou d'un intervalle de taille entre parenthèses) 3. 3.2 Structure Une structure est introduite par '{', et est décrite par une succession de lignes commençant par un '+' de plus que la ligne introduisant le composant, et terminée par un '}'. 3. 3.3 Union Une union est une écriture abrégée pour un ensemble de composants de présence exclusive. 3. 3.4 Référence Une référence est introduite par un caractère :', et est le nom d'un type de donnée décrit par ailleurs. Quand le module de description du type n'est pas le module englobant, il est indiqué entre parenthèse suivant le nom de type. 3. 3.5 Index Un type index est introduit par '->', suivi d'un nom de n#ud. Un nom de n#ud est composé d'un nom de type d'objet (éventuellement vide, auquel cas il s'agit du type courant), suivi d'une suite de nom de composants séparés par des '.', telle que chaque nom de composant existe dans la structure du composant ou type qui précède. Le dernier composant doit être indexé. Un nom de n#ud donne : - L'information statique du type indexé (le type du dernier composant) ; - Un lien dynamique vers une instance particulière de la liste. Ce lien est résolu en remontant l'arborescence de l'instance jusqu'à trouver un objet du type indiqué. 4. Description d'action Une description d'action comporte le nom de l'action entre ' ', suivi de '::=' puis d'une description abstraite d'action, suivie de zéro, une ou plusieurs descriptions de transfert, chacune introduite par le mot clé 'transfer'. Une description de transfert décrit une structure de chaîne de symboles qui peut représenter correctement la structure abstraite (voir le chapitre sur le sujet). 5. Description abstraite d'action Une description abstraite d'action comporte éventuellement une liste de paramètres, et éventuellement une liste d'instructions. (Les instructions demandent en général des paramètres qui apparaissent par exemple dans la représentation de l'action. Ces paramètres ne sont pas listés dans la liste de paramètres : celle-ci ne contient les paramètres qui ne peuvent pas être décrits plus précisément comme liés à une instruction élémentaire.) La liste de paramètres est introduite par le mot clé 'parameters' et est terminée par le mot clé 'end'. La liste suit la syntaxe de la description abstraite de type d'objet. La liste d'actions est constituée d'une ou plusieurs lignes. Chaque ligne est constituée d'une éventuelle indication de condition, suivie d'une instruction parmi celles listées ci-dessous. 5.1 Indication de condition Une indication de condition est soit le mot clé 'OPTIONAL', soit une instruction IF THEN. Le mot clé OPTIONAL indique que l'instruction, ou la liste d'instructions entre '{' et '}', qui suit peut ou non être demandée. Une instruction IF THEN indique (entre les mots clé 'IF' et THEN') une condition, exprimée à partir de valeurs de paramètres, si l'instruction est à faire ou non. 5. 2 Instruction de sélection Une instruction de sélection est introduite par le mot clé 'on' suivi du nom d'un composant (typiquement une structure) sur lequel s'applique une liste d'instructions comprises entre '{'et '}'. Si le composant est indexé, une indication d'index peut suivre le nom de composant (voir section sur l'index). 5. 3 Instruction SET Une instruction SET est introduite par le mot clé 'set' suivi d'un nom de composant (éventuellement avec un index). Cette instruction demande l'affectation d'une nouvelle valeur au composant (dans son intégrité, ce qui peut être un sous-arbre assez important). Il y a plusieurs manière dont la nouvelle valeur peut être indiquée : 5. 3.1 Paramètre implicite de type implicite Dans ce cas, l'instruction ne contient rien de plus. Le message contient alors un paramètre du type du composant, tel que décrit dans la description abstraite d'objet. 5. 3.2 Paramètre implicite de type explicite Dans ce cas l'instruction est suivi du caractère :' suivi d'un nom de type d'objet. Ce type doit être compatible avec le type du composant (sous-type). 5. 3.3 Valeur explicite Dans ce cas, l'instruction est suivie du caractère :=' suivi d'une expression dont le résultat doit être compatible avec le type. 5. 3.4 Valeur calculée Dans ce cas l'instruction est suivie du caractère' :=' suivi d'une liste d'instructions entre '{'et '}'. Ces instructions portent sur le n#ud indiqué par le composant, et itémisent les actions aboutissant à l'affectation du composant (typiquement sous-composant par sous-composant). 5. 3.5 Vidage Dans ce cas, l'instruction est suivie de ' := null'. Cela ne s'applique qu'aux composants indexés (mais sans indication d'index dans l'instruction SET) et qui accepte un nombre nul de copies. L'instruction met le nombre de copies à zéro. 5. 4 Instruction ADD Une instruction ADD est introduite par le mot clé 'set' suivi d'un nom de composant indexé (sans indication d'index dans l'instruction ADD). Cette instruction demande l'ajout d'une nouvelle copie au composant (dans son intégrité, ce qui peut être un sous-arbre assez important). Il y a plusieurs manières dont la nouvelle valeur peut être indiquée, comme dans le cas de l'instruction SET (sauf le vidage). 5. 5 Instruction SEND Une instruction SEND est introduite par le mot clé 'send' suivi d'un nom de composant (éventuellement avec un index). Cette instruction indique l'inclusion d'un paramètre dont la valeur est la valeur courante du composant du côté de la source. L'action du côté du récepteur est de vérifier la cohérence, mais la conséquence d'une détection d'incohérence n'est pas précisée. 5. 6 Instruction CHOICE Une instruction CHOICE est introduite par le mot clé 'choice' suivi d'une liste d'actions entre '{' et '}' et séparées par des ','. Cela indique qu'une et une seule des actions est demandée pour chaque occurrence de l'action. 5. 7 Instruction DO Une instruction DO consiste en le mot clé 'do' suivi du nom d'une action. Cette action doit être compatible avec le type de composant courant. 5. 8 Instructions liées au retour en arrière Une modification de données peut être demandée à l'essai et refusée éventuellement par le récepteur. Ceci est géré par les instructions PREPARE, COMMIT et UNDO. 5. 8.1 L'instruction PREPARE Cette instruction indique que les modifications qui la suivent et applicables au n#ud courant peuvent être annulées. 5. 8.2 L'instruction COMMIT Cette instruction indique l'acceptation des modifications sujettes à un PREPARE sur le n#ud courant. 5. 8.3 L'instruction UNDO Cette instruction indique le refus des modifications sujettes à un PREPARE sur le n#ud courant. 6. Description de transfert La description de transfert est à la base de type langage CSN.l version 2. 2, avec les adaptations suivantes. 6. 1 En-tête Quand la description de transfert est unique pour un type d'objet, le nom de structure CSN.l peut être omis, et est alors le même que le nome de type. 6. 2 Fin de structure Le ; final est omis (la fin est détectée soit par le ; de fin d'objet, soit par un des mots clés transfer (indiquant une alternative de codage), ou action . 6. 3 Fonctions calculées de liaison avec la description abstraite L'en-tête d'une fonction calculée peut être de la forme abstract. suivi d'un identificateur d'élément abstrait. Le type n'est pas indiqué et est celui de 1 'élément abstrait ainsi que défini dans la description abstraite. Plus généralement, les règles de liaison entre une description de transfert et une description abstraite (de type d'objet ou de message) font l'objet d'un chapitre spécial. 6. 4 Références au contexte Une formule peut invoquer des valeurs d'élément de contexte. 7. Description séparée d'action Une action peut être décrite en dehors de la description du type d'objet sur laquelle elle porte. La description d'action est alors précédé d'un en-tête composé du mot clé 'on' suivi du nom de type d'objet sue lequel porte l'action. L'indication du type d'objet peut être omise dans le cas d'une description séparée d'action en suivant une autre s'appliquant au même type. 8. Description séparée de transfert Une description de transfert peut être séparée de la description abstraite à laquelle elle correspond. 9. Règles de correspondance La correspondance entre une description abstraite et une description de transfert est basée sur la correspondance entre des noms de composants abstraits et des noms de label, plus des formules de représentation. 10. Noms Un nom (d'objet ou d'action) est composé de caractères libres, avec les exceptions nécessaires pour des raisons syntaxiques. Lors de la comparaison entre deux noms, les chaînes consécutives d'espace, tabulation et fin de ligne sont considérées comme équivalentes à un seul espace, sauf au début et à la fin , où elles sont considérées comme équivalentes à la chaîne vide ; la chasse n'est pas prise en compte. ANNEXE 2 Premier exemple : spécification d'une simple mise à jour d'une donnée. Un protocole est présenté ici dans le cadre d'un protocole unidirectionnel illustratif dont le seul propos est de mettre à jour une donnée. L'application de la méthode procède comme suit : - description abstraite du contexte ; - description abstraite des messages ; - description de l'encodage et du décodage des données ; - description de l'encodage et du décodage des messages ; 1. Description abstraite du contexte commun. Cette description se fait selon un langage formel de description abstraite de données. Le langage utilisé ici n'est pas publié. ::= données gérées : type de données géré es ; ; ~~~~~~~~~ L'expression 'type de données gérées' peut représenter un type de données quelconque, par exemple : ::= entier 1 : integer , entier 2 : integer ; 2. Description abstraite des messages. Le protocole est réduit à un seul message, qui modifie le contexte dans sa totalité. La description des messages se fait selon un langage formel adapté à la description d'actions portant sur le contexte de données : on ::= CHOICE ; ::= on SET; 3. Description de l'encodage et décodage des données. Cette description se fait en CSN.l, encapsulé dans un langage plus général combinant la description abstraite et la description concrète. Seuls sont décrites les données apparaissant comme paramètre de message. ::= abstract entier 1 : integer , entier 2 : integer transfer -- la liaison avec l'abstrait se fait par l'identificateur -- l'encodage par défaut est binaire, poids fort en premier ;; ~~~~~~~~~~~~~~~~~~~~~~~~ 4. Description de l'encodage et décodage des messages. Cette description se fait en CSN.l, encapsulé dans un langage plus général combinant la description abstraite et la description concrète. ::= abstract CHOICE transfer 00 null}! -- permet d'accepter une extension future ::= abstract on SET transfer ANNEXE 3 Exemple de spécification d'un protocole réel (le protocole GSM de gestion de mobilité entre une station mobile (MS) et une infrastructure de réseau) La plupart des fonctions ci-après ont des noms tels que spécifiés dans la norme GSM ( Global System for Mobile communication ) normalisée par l'ETSI (European Télécommunication Standard Institute). Les noms ou accronymes utilisés dans les spécifications correspondent soit à des éléments de la syntaxe d'un mode particulier de réalisation de l'invention (tel que précisé en annexe 1) soit à des noms ou acronymes d'éléments spécifiés dans la norme GSM. module MM 24. 008 4.0.0 default scope : MM RIL3.Location Area Code from RIL3 24. 008 4. 0.0 RIL3.Location Area Identification from RIL3 24. 008 4. 0.0 RIL3.Mobile Station Classmark 1 from RIL3 24. 008 4. 0.0 RIL3.Mobile Station Classmark 2 delta from RIL3 24. 008 4. 0.0 RIL3.Mobile Station Classmark 3 from RIL3 24. 008 4. 0.0 RIL3.Priority Level from RIL3 24. 008 4. 0.0 RIL3.Ciphering Key Sequence Number from RIL3 24. 008 4.0.0 1 Contexte de protocole de gestion de mobilité (ou MM de l'anglais mobility management ). Il s'agit de la spécification du contexte de protocole, c'est-à-dire des données communes à l'infrastructure et à la station mobile, et gérées par le protocole. 1. 1 Description abstraite Description des éléments du contexte indépendante des représentations, que ce soit pour la mémorisation dans les entités, ou pour la transmission dans des messages de protocole. ~~~~~~ : := abstract IMSI[0..1] : IMSI Connect state : Enumerated (not connected, connected) Connection parameters[iif(Connect state = connected, 1, 0)] : + Serving cell : -> UE context.Cell list + IMEI[0..1] : IMEI + Software Version Number[iif(PRESENT (IMEI), 1, 0)] : Integer (0..99) + Mobile Station Classmark 1 : RIL3.Mobile Station Classmark 1 + Mobile Station Classmark 2 delta[0..1] : RIL3.Mobile Station Classmark 2 delta + Mobile Station Classmark 3[0..1] : RIL3.Mobile Station Classmark 3 + Has been authenticated : Boolean + Is ciphered : Boolean + Service data[0..infinité] : + + CM service type : CM Service Type + + Priority : RIL3.Priority Level Location update state : Enumerated (roaming not allowed, updated) Location parameters[iif(Location update state = updated, 1, 0)] : + LAI+TMSI[0..1] : LAI+TMSI + Registered location area : -> UE context.LA list + Detach flag : Boolean + CTS permission : Boolean + CKSN availability : Boolean + CKSN[iif(CKSN availability, 1,0)] : RIL3.Ciphering Key Séquence Number + GSM ciphering key[0..1] : Bit string (64) + UMTS security data[0..1] : + + AUTN : Authentication Parameter AUTN + + UMTS ciphering key[0..1] : Bit string (128) + + UMTS integrity key[0..1] : Bit string (128) 1.2 Actions 1. 2.1 Gestion de mobilité dans le sens descendant (ou DL MM de l'anglais downlink mobility management ) 1. 2.1.1 Description abstraite Ceci décrit abstraitement le message de protocole qui peut être transmis de l'infrastructure vers la station mobile. action DL MM ::= abstract CHOICE do LOCATION UPDATING ACCEPT , do LOCATION UPDATING REJECT , do AUTHENTICATION REJECT , do AUTHENTICATION REQUEST , do TMSI REALLOCATION COMMAND , do CM SERVICE ACCEPT ,do CM SERVICE REJECT , do CM SERVICE PROMPT , do IDENTITY REQUEST ,do ABORT , do MM STATUS DOWNLINK ,do MM INFORMATION } 1. 2.1.2 Syntaxe de transfert Ceci indique la structure binaire du message. Cela fait apparaître en particulier un champ permettant de sélectionner une action particulière dans la liste des actions possibles. transfer ::= - flow of downlink MM messages { 00 {00 0010 #00 0100 #01 0001 #01 0010 #01 1010 10 0001 10 0010 #10 0101 10 1000 #10 1001 #11 0001 DOWNLINK> #11 0010 = null> 1. 2.2 Gestion de mobilité dans le sens montant (ou UL MM de l'anglais uplink mobility management ) 1. 2.2.1 Description abstraite action UL MM ::= abstract CHOICE do AUTHENTICATION FAILURE , do AUTHENTICATION RESPONSE , do IDENTITY RESPONSE , do TMSI REALLOCATION COMPLETE , do CM SERVICE ABORT ,do CM SERVICE REQUEST SUBSEQUENT , do MM STATUS UPLINK } 1. 2.2.2 Syntaxe de transfert transfer ::= -- flow of uplink MM messages once an RR connection is established { bit*2 {01 1100 #01 0100 #01 1001 #01 1011 #10 0011 #10 0100 11 0001 UPLINK>} ! 1. 2.3 Abandon (ou abort ) 1. 2.3.1 Description abstraite action ABORT ::= abstract parameters Reject cause : MM. Reject cause end if iif (Reject cause.cause grouping = MS identification error, Reject cause. MS identification error cause = illégal ME, false) then set Location update state : = roaming not allowed 1. 2.3.2 Syntaxe de transfert transfer ::= FAILURE") 1. 2.4.1 Description abstraite action AUTHENTICATION FAILURE ::= abstract parameters Reject cause : MM. Reject cause Authentication Failure parameter[iif(iif (Reject cause.cause grouping = network related failure, Reject cause.network-related failure cause = synch. failure, false), 1,0)]: MM.Authentication Failure parameter end on Location parameters { set UMTS security data := null @ 1. 2.4.2 Syntaxe de transfert. transfer ::= REQUEST") 1. 2.6.1 Description abstraite action AUTHENTICATION REQUEST ::= abstract parameters Authentication Parameter RAND : MM.Authentication Parameter RAND Authentication Algorithm : Enumerated (UMTS, GSM) end on Location parameters { PREPARE set CKSN availability := True set CKSN set GSM ciphering key : = A8(Authentication Parameter RAND.RAND) if Authentication algorithm = UMTS then set UMTS security data := { set AUTN set UMTS ciphering key := f3 (Authentication Parameter RAND.RAND) set UMTS integrity key := f4 (Authentication Parameter RAND.RAND) }} 1. 2.6.2 Syntaxe de transfert transfer ::= Downlink) 18) # abstract. Authentication algorithm returns -- if there is any error on AUTN, the authentication Algo will be considered GSM iif (exist(Authentication parameter AUTN), UMTS, GSM) 1.2.7 Réponse d'authentification (ou "AUTHENTICATION RESPONSE") 1. 2.7.1 Description abstraite action AUTHENTICATION RESPONSE ::= abstract parameters RES : Octet string (4..16) end COMMIT on Connection parameters { set Has been authenticated : = True transfer ::= { abstract on Connection parameters { set Service data = null } 1. 2.7.2 Syntaxe de transfert transfer null 1.2.8 Abandon de connexion pour service (ou "CM SERVICE ABORT") 1. 2.8.1 Description abstraite action CM SERVICE ABORT = abstract on Connection parameters { set Service data := null } 1. 2.8.2 Syntaxe de transfert transfer null 1. 2.9 Acceptation de la demande de connexion pour service (ou "CM SERVICE ACCEPT") 1. 2.9.1 Description abstraite action CM SERVICE ACCEPT = abstract COMMIT 1. 2.9.2 Syntaxe de transfert transfer ::= null 1. 2.10 Affichage du service de gestion de connexion (ou "CM SERVICE PROMPT") 1. 2.10.1 Description abstraite action CM SERVICE PROMPT := abstract parameters PD and SAPI . RIL3.PD and SAPI end 1. 2.10.2 Syntaxe de transfert transfer ::= action CM SERVICE REJECT . = abstract parameters Reject cause : MM. Reject cause end UNDO if iif (Reject cause.cause grouping = MS identification error, Reject cause.MS identification error cause = "illegal ME" or Reject cause. MS identification error cause = "IMSI unknown in VLR", false) then set Location update state '= roaming not allowed 1. 2.11.2 Syntaxe de transfert transfer ::= 1)# 1.2.12 Demande de connexion additionnelle pour service (ou "CM SERVICE REQUEST SUBSEQUENT") 1. 2.12.1 Description abstraite action CM SERVICE REQUEST SUBSEQUENT ::= abstract parameters Mobile Identity Type : MM.Mobile Identity Type end if Mobile Identity Type = IMSI then send IMSI on Location parameters { if Mobile Identity Type = TMSI/P-TMSI then on LAI+TMSI { send TMSI } send CKSN availability if CKSN availability then send CKSN } on Connection parameters { send Mobile Station Classmark 1 send Mobile Station Classmark 2 delta PREPARE add Service data := { set CM Service Type set Priority }} 1. 2.12.2 Syntaxe de transfert : CM SERVICE REQUEST transfer ::= Uplink) 4, 4) abstract.Mobile Identity type returns Mobile identity.V.Type ofidentity.abstract abstract.IMSI returns Mobile identity.V IMSI.abstract abstract.TMSI returns Mobile identity.V.TMSI/P-TMSI.abstract abstract.IMEI returns Mobile identity.V.IMEI 1.2.13 Demande d'identité GSM (ou IDENTITY REQUEST ) 1. 2.13.1 Description abstraite action IDENTITY REQUEST ::= abstract parameters Mobile Identity Type : MM.Mobile Identity Type end 1. 2.13.2 Syntaxe de transfert transfer ::= type , 1. 2.14 Réponse d'identité (ou IDENTITY RESPONSE ) 1.2.14.1.1 Description abstraite action IDENTITY RESPONSE ::= abstract parameters Mobile Identity Type : MM.Mobile Identity Type end if Mobile Identity Type = IMSI then set IMSI if Mobile Identity Type = IMEI then on Connection parameters { set IMEI } if Mobile Identity Type = IMEISV then on Connection parameters { set IMEI set Software Version Number := Integer (0..99) } 1. 2.14.2 Syntaxe de transfert transfer ::= 1.2.15 Acceptation de mise à jour de localisation (ou "LOCATION UPDATING ACCEPT") 1. 2.15.1 Description abstraite action LOCATION UPDATING ACCEPT ::= abstract parameters TMSI allocation status : Enumerated (new TMSI, keep TMSI, erase TMSI) Follow on proceed : Boolean end set Location update state := updated on Location parameters { set Registered location area if TMSI allocation status = new TMSI then on LAI+TMSI { set Location Area Identification set TMSI } if TMSI allocation status = erase TMSI then set LAI+TMSI := null set CTS permission := Boolean } 1. 2.15.2 Syntaxe de transfert transfer ::= , keep TMSI, Mobile identity.V.TMSIIP-TMSI = 1**, erase TMSI, Mobile identity.V.TMSI/P-TMSI = bit**, new TMSI) abstract.TMSI returns Mobile identity.V.TMSI/P-TMSI.abstract 1.2.16 Rejet d'une mise à jour de localisation (ou LOCATION UPDATING REJECT ) 1. 2.16.1 Description abstraite action LOCATION UPDATING REJECT ::= abstract parameters Reject cause : MM. Reject cause end set Location update state := roaming not allowed 1. 2.16.2 Syntaxe de transfert transfer ::= INFORMATION") 1. 2.17.1 Description abstraite action MM INFORMATION::= abstract parameters Universal time[0..1] : MM.Universal Time end on Location parameters { on Registered location area { OPTIONAL set Local time zone OPTIONAL set Daylight Saving Time on PLMN{ OPTIONAL set Full name for network OPTIONAL set Short name for network }}} on Connection parameters { on Serving cell { OPTIONAL set LSA identity }} 1. 2.17.2 Syntaxe de transfert transfer ::= iif (exist (Local time zone), Local time zone, iif (exist (Universal time and local time zone), Universal time and local time zone.Local time zone, )) function Universal time returns Universal time and local time zone.Universal time 1. 2.18 Statut dans le sens descendant de la Gestion de mobilité (ou "MM STATUS DOWNLINK") 1. 2.18.1 Description abstraite action MM STATUS DOWNLINK ::= 1.2.19 Statut dans le sens montant de la Gestion de mobilité (ou "MM STATUS UPLINK") abstract parameters Reject cause - MM Rejectcause end 1. 2.18.2 Syntaxe de transfert transfer'= = downlmk, 1)# 1.2.19 Statut dans le sens montant de la Gestion de mobilité (ou "MM STATUS UPLINK") 1. 2.19.1 Description abstraite action MM STATUS UPLINK ::= abstract parameters Reject cause - MM.Reject cause end 1. 2.19.2 Syntaxe de transfert transfer '= uplink, 1) 1. 2.20 Commande de réallocation TMSI (ou "TMSI REALLOCATION COMMAND") 1. 2.20.1 Description abstraite action TMSI REALLOCATION COMMAND -= abstract on Location parameters { PREPARE set LAI+TMSI } 1. 2.20.2 Syntaxe de transfert transfer :.= Mobile identity.V.TMSI/P-TMSI.abstract 1.2.21 Réallocation TMSI effectuée (ou "TMSI REALLOCATION COMPLETE") 1. 2.21.1 Description abstraite action TMSI REALLOCATION COMPLETE:'= abstract COMMIT 1. 2.21.2 Syntaxe de transfert transfer ::= null 2 Liste de zones de localisation (ou "LA list") 2. 1 Description abstraite ::= abstract Location area description[O..infinite] : + PLMN . -> UE context PLMN list + LAC : RIL3.Location Area Code + Local time zone[0..1] : Time Zone + Network daylight saving time[0..1] : Daylight Saving Time 3 Liste de réseaux (ou PLMN list ) 3. 1 Description abstraite list> ::= abstract PLMN description[0..infinite] : + PLMN Id : PLMN Identity + Full name for network[0..1] : Network Name + Short name for network[0..1] : Network Name 4 Paramètre d'authentification AUTN (ou "Authentication Parameter AUTN") 4. 1 Description abstraite ::= abstract Sequence number xor Anonymity Key : Bit string (48) Authentication management field : Bit string (16) Message authentication code : Bit string (64) 4. 2 Syntaxe de transfert transfer ::= 5 Type service de service (ou "CM Service Type") 5. 1 Description abstraite ::= abstract service type : Enumerated (MO call or packet est, emergency call, SMS, SS, VGC, VBS, LCS) 5. 2 Syntaxe de transfert transfer ::= {00011001010100110 bit(2)}> 6 Correction d'heure d'été (ou "Daylight Saving Time") 6. 1 Description abstraite ::= abstract Daylight Saving Time adjustment : Enumerated (0, +1 hour, +2 hour) 6. 2 Syntaxe de transfert transfer ::= * 6 01 10 }> 7 IMEI 7. 1 Description abstraite ::= abstract Type Approval Code [6] : Integer (0..9) Final Assembly Code[2] : Integer (0..9) Serial Number [6] : Integer (0..9) 7. 2 Syntaxe de transfert transfer ::= 1 bit*3 iif(n=1, integer(digit one), iif(n%2 = 0, integer(pairs[n/21.digit even), integer(pairs[(n-1)/2].digit odd))) abstract.Type Approval Code[n] returns -- n from 0 to 5, MSB to LSD Digit(n+1 ) abstract.Final Assembly Code[n] returns - n from 0 to 1, MSD to LSD Digit(n+7) abstract.Serial Number[n] returns -- n from 0 to 5, MSD to LSD Digit(n+9) 8 IMSI 8. 1 Description abstraite ::= abstract MCC:MCC NMSI[3..121 : Integer (0..9) 8. 2 Syntaxe de transfert transfer ::= { bit*3 *4 iif(n=1, integer(digitone), iif(n%2 = 0, integer(pairs[n/2].digit even), integer(pairs[(n-1)/2].digit odd))) abstract.MCC returns Digit(1)*100 + Digit(2)*10+Digit(3) abstract.NMSI.size returns (exist (pairs) *2) - 4 + integer (oddeven) abstract.NMSI[n] returns - n from 0 to (size-1) Digit(n+4) 9 LAI et TMSI 9. 1 Description abstraite ::= abstract Location Area Identification : RIL3.Location Area Identification TMSI : Temporary Mobile Station Identity 10 Identifiant LSA (ou LSA Identifier ) 10. 1 Description abstraite ::= abstract LSA available : Boolean LSA ID[iif(LSA available, 1,0)]: + LSA identifier scope : Enumerated (PLMN significant, universal) + Localised service area identity : Bit string (23) 10. 2 Syntaxe de transfert transfer ::= { bit>#null} abstract. LSA available returns exist (LSA ID) abstract.LSA ID.LSA identifier scope returns iif (LSA identifier scope = 0, PLMN significant, universal) 11 MCC 11. 1 Description abstraite ::= abstract MCC value : Integer (0..999) 12 MNC 12. 1 Description abstraite ::= abstract MNC value : Integer (0..999) 13 Nom du réseau (ou "Network Name") 13. 1 Description abstraite ::= abstract Coding scheme : Enumerated (cell broadcast default alphabet, UCS2) Add country's initiais : Boolean Text string : String 13. 2 Syntaxe de transfert transfer ::= {000#001}> -- order of bits within text string ? ** ::= abstract MCC:MCC MNC:MNC 15 Identité temporaire de station mobile (ou "Temporary Mobile Station Identity", TMSI). 15. 1 Description abstraite Identity>::= abstract temporary identity : Bit string (32) 15. 2 Syntaxe de transfert transfer ::= 16 Zone horaire ( ou Time Zone ) 16. 1 Description abstraite ::= abstract Delta with GMT : Integer (-99..99) 16. 2 Syntaxe de transfert transfer ::= abstract.Delta with GMT returns - units are minutes 15 * iif (sign = 0, integer(digit 1)*10 + integer(digit 2), - integer(digit 1)*10 - integer(digit 2)) REVENDICATIONS 1. Système de spécification et de mise en #uvre d'un protocole de gestion de communication et de transmission entre au moins un émetteur et au moins un récepteur, caractérisé en ce qu'il comprend: - des moyens de détermination d'un contexte commun (2) comprenant des moyens de description d'un ensemble de données gérées par ledit ou lesdits émetteurs et/ou ledit ou lesdits récepteurs ; - des moyens d'identification des messages de protocole (3) susceptibles d'être échangés entre ledit ou lesdits émetteurs et ledit ou lesdits récepteurs, ladite identification étant indépendante de la ou des représentations utilisées pour lesdits messages; - des moyens de définition de représentations de données stockées et/ou transmises par ledit ou lesdits émetteurs et/ou ledit ou lesdits récepteurs à partir de ladite détermination d'un contexte commun et de ladite identification des messages, ladite définition de représentations permettant de déterminer des instructions d'implémentation dudit protocole dans au moins un desdits émetteurs et au moins un desdits récepteurs ; et - des moyens de mise en #uvre dudit protocole dans au moins un desdits émetteurs et au moins un desdits récepteurs à partir desdites instructions d'implémentation, de façon à ce que ledit ou lesdits émetteurs soient aptes à communiquer avec ledit ou lesdits récepteurs. 2. Système selon la revendication 1, caractérisé en ce que lesdits moyens de détermination d'un contexte commun comprennent eux-mêmes des moyens de description d'une structure du contexte, ladite description étant indépendante de la ou des représentations utilisées pour le stockage et/ou la transmission desdites données. 3. Système selon la revendication 2, caractérisé en ce que lesdits moyens de détermination d'un contexte commun comprennent en outre des moyens d'identification et de description des types d'objets permettant d'analyser ladite structure du contexte, ladite identification et ladite description des types d'objets étant indépendantes de la ou des représentations utilisées pour le stockage et/ou la transmission. 4. Système selon l'une quelconque des revendications 1 à 3, caractérisé en ce que tout ou partie desdites données gérées sont les données que ledit protocole vise à maintenir cohérent dans au moins un émetteur parmi ledit ou lesdits émetteurs et au moins un récepteur parmi ledit ou lesdits récepteurs. 5. Système selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'au moins une partie de ladite identification des messages est effectuée en termes d'actions et/ou de ses effets sur ledit contexte commun. 6. Système selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comprend des moyens de liaison entre : - une description de la forme de signal effectivement transmis ; et - ladite identification des messages de protocole. 7. Système selon la revendication 6, caractérisé en ce que ladite forme du signal appartient au groupe comprenant : - les suites de données binaires ; - les suites d'éléments pris dans un alphabet prédéterminé ; - les suites de formes d'ondes modulées. 8. Système selon l'une quelconque des revendications 6 et 7, caractérisé en ce que ladite liaison se fait dans un langage de spécification de données comprenant des fonctions permettant la description desdites données sous forme d'attributs d'objets abstraits et de fonctions s'appliquant sur des représentations concrètes. 9. Système selon l'une quelconque des revendications 6 à 8, caractérisé en ce que ladite spécification de la forme de signal se fait en langage CSN1 enrichi de fonctions permettant la description desdites données sous forme d'attributs d'objets abstraits et de fonctions s'appliquant sur des représentations concrètes. 10. Système selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il comprend des moyens d'utilisation des données de contexte dans une description formelle d'un encodage et/ou d'un décodage. 11. Système selon l'une quelconque des revendications 1 à 10, caractérisé en ce que lesdits moyens de détermination d'un contexte commun, lesdits moyens d'identification des messages de protocole et lesdits moyens de définition de représentations de données mettent chacun en oeuvre un langage formel permettant une détermination automatique du logiciel de mise en #uvre dudit protocole. 12. Système selon la revendication 11, caractérisé en ce qu'il comprend des moyens de détermination automatique du logiciel de mise en #uvre dudit protocole. 13. Système selon l'une quelconque des revendications 11et 12, caractérisé en ce qu'il comprend des moyens de détermination automatique de tests de dispositifs mettant en #uvre ledit protocole. 14. Système selon l'une quelconque des revendications 1 à 13, caractérisé en ce que lesdits moyens de détermination d'un contexte commun comprennent des moyens de traduction d'un mode de représentation d'un protocole en ladite description d'un ensemble de données. 15. Système selon l'une quelconque des revendications 1 à 14, caractérisé en ce que lesdits moyens d'identification des messages de protocoles comprennent des moyens de traduction d'un mode de représentation de protocoles. 16. Système selon l'une quelconque des revendications 1 à 15, caractérisé en ce qu'il comprend en outre des moyens de visualisation de la sémantique desdits messages de protocoles échangés entre ledit ou lesdits émetteurs et/ou ledit ou lesdits récepteurs. 17. Procédé de spécification et de mise en #uvre d'un protocole de gestion de communication et de transmission entre au moins un émetteur et au moins un récepteur, caractérisé en ce qu'il comprend les étapes suivantes : détermination d'un contexte commun (2) comprenant une description d'un ensemble de données gérées par ledit ou lesdits émetteurs et/ou ledit ou lesdits récepteurs ; - identification des messages de protocole (3) susceptibles d'être échangés entre ledit ou lesdits émetteurs et ledit ou lesdits récepteurs, ladite identification étant indépendante de la ou des représentations utilisées pour lesdits messages; définition de représentations de données stockées et/ou transmises par ledit ou lesdits émetteurs et/ou ledit ou lesdits récepteurs à partir de ladite détermination d'un contexte commun et de ladite identification des messages, ladite définition de représentations permettant de déterminer des instructions d'implémentation dudit protocole dans au moins un desdits émetteurs et au moins un desdits récepteurs ; et mise en #uvre dudit protocole dans au moins un desdits émetteurs et au moins un desdits récepteurs à partir desdites instructions d'implémentation, de façon à ce que ledit ou lesdits émetteurs soient aptes à communiquer avec ledit ou lesdits récepteurs. 18. Dispositif de communication, caractérisé en ce qu'il comprend des moyens permettant l'émission et/ou la réception de données vers ou d'un dispositif tiers un autre dispositif selon un protocole obtenu par la mise en #uvre du procédé selon la revendication 17. 19. Produit programme d'ordinateur comprenant des éléments de programme, enregistrés sur un support lisible par au moins un microprocesseur, caractérisé en ce que lesdits éléments de programme contrôlent le ou lesdits microprocesseurs pour qu'ils effectuent les étapes suivantes adaptées à la spécification de protocole de communication et de transmission entre au moins un émetteur et au moins un récepteur : - détermination d'un contexte commun (2) comprenant une description d'un ensemble de données gérées par ledit ou lesdits émetteurs et/ou ledit ou lesdits récepteurs ; identification des messages de protocole (3) susceptibles d'être échangés entre ledit ou lesdits émetteurs et ledit ou lesdits récepteurs, ladite identification étant indépendante de la ou des représentations utilisées pour lesdits messages; définition de représentations de données stockées et/ou transmises par ledit ou lesdits émetteurs et/ou ledit ou lesdits récepteurs à partir de ladite détermination d'un contexte commun et de ladite identification des messages, ladite définition de représentations permettant de déterminer des instructions d'implémentation dudit protocole dans au moins un desdits émetteurs et au moins un desdits récepteurs ; et - mise en #uvre dudit protocole dans au moins un desdits émetteurs et au moins un desdits récepteurs à partir desdites instructions d'implémentation, de façon à ce que ledit ou lesdits émetteurs soient aptes à communiquer avec ledit ou lesdits récepteurs. 20. Produit programme d'ordinateur, caractérisé en ce que ledit programme comprend des séquences d'instructions adaptées à la mise en #uvre d'un procédé de spécification de protocole de communication entre au moins un émetteur et au moins un récepteur selon la revendication 17 lorsque ledit programme est exécuté sur un ordinateur.