Document de sp´ ecification du logiciel VALPO
D´ efinition du format des fichiers des sc´ enarios
TELECOM Bretagne
Projet VALPO - D´emonstrateur de protocoles GSM/UMTS
D´epartement R´eseaux, S´ecurit´e, Multim´edia
Janvier 2009 version 1.5
R´edacteurs : Xavier Lagrange Jean-Pierre Le Narzul Alexis Koalla
TELECOM Bretagne 2 rue de la Chataigneraie CS 17607
35576 Cesson-S´evign´e Cedex France
Table des mati` eres
1 Introduction 2
2 D´efinition du format 3
2.1 Pr´eambule . . . 3 2.2 Grammaire du format . . . 4
3 Description des param`etres 5
3.1 Format du d´ebut du fichier . . . 5 3.2 Format des messages . . . 5 3.3 Remarques importantes . . . 7
4 Conclusion 8
A Annexes 9
A.1 Exemple de fichier sc´enario respectant le mod`ele avec deux points de synchroni- sation T1 etT2. . . 9 A.1.1 L’en-tete du sc´enario . . . 9 A.1.2 Le corps du sc´enario . . . 10
1 Introduction
L’applet VALPO (Visualisation par AppLet de PrOtocoles) permet de mettre en sc`ene des
´echanges entre ´equipement. Il peut s’agir d’´echanges de messages GSM1 ou de n’importe quels
´echanges entre ´equipements.
Les sc´enarios sont d´efinis `a l’aide de fichiers texte qui doivent respecter un format pr´ecis.
Le pr´esent document a pour but de d´ecrire ce format.
Apr`es avoir donn´e la grammaire du format de fichier, nous donnerons un exemple de fi- chier d’´echanges protocolaires valide selon le mod`ele. Enfin, nous terminerons ce document en d´ecrivant les param`etres fondamentaux d’un sc´enario (en-tete du sc´enario et corps du message).
1Global Service for Mobile
2 D´ efinition du format
2.1 Pr´ eambule
Ce paragraphe donne des indications pour mieux comprendre le format d´ecrit plus bas.
1. Z =X signifie que le termeZ est identique au terme X.
2. Z = [X]∗signifie que le terme Z est une suite (´eventuellement vide) de termes X.
3. Z = [X]+ signifie que le terme Z est une suite non vide de termesX.
4. Z = XY signifie que le terme Z est constitu´e une s´equence d’un terme X suivi d’un terme Y (obligatoirement dans cet ordre)
5. Z =X|Y signifie que le termeZ peut prendre un terme X ou un terme Y.
6. les chaˆınes de caract`eres entre guillemets sont des termes primitifs : affich´ees telles quelles dans le fichier de sc´enario
Enfin, certaines chaines de caract`eres ne figurent pas dans la grammaire en tant que termes teminaux car cela aurait rendu l’abstraction plus difficile et complexe. Par exemple le terme
“propagThroughput” joue deux roles. Il sert a identifier soit une instruction pour le temps de propagation etre deux nœuds et du d´ebit d’un lien. Pour plus de pr´ecisions, voir le fichier exemple d´ecrit plus loin. De meme le terme “node” commence obligatoirement par le mot cl´e
“NodeNameij”.
Le paragraphe suivant donne la grammaire (description abstraite) du format des fichiers des sc´enarii selon les r`egles que nous venons de d´ecrire.
2.2 Grammaire du format
scenario= head [itemscenario]*
head= “ScenarioName” separator string retour fileName retour= ”RETOURCHARIOT”
fileName=”File” separator string | ² string= letter [ letter | digit]*
letter= A|B|..|Z|a|b|..|z
digitNonNul= 1|2|3|4|5|6|7|8|9 digit= 0—digitNonNul
separator= ” ;”
itemscenario= comment | node | propagThroughput | message comment= ”#” [string]+
node= nameId separator string img [separator]+
nameId=string separator number img=string | nil
propagThroughput= nameId separator number separator number separator number [separator]+
number= digitNonNul [digit]*
message= link separator msgBody | pause link= number separator number
msgBody= msgHead separator msgType separator data separator msgHead= string commaBegin parameters commaEnd
commaBegin= ”(“
commadEnd= ”)”
parameters= param virgule suiteParam | nil param= string
virgule= ”,”
suiteParam= param parameters nil= ² chaine vide
msgType= ”REQUEST” | “RESPONSE” | “ONEWAY”
data= length separator treatment separator dash separator step separator startTime separator syncPoint delta
length= number treatment= number dash= “full”|”semi”
step= number
startTime= time|syncPoint time=“t0”| “*” |nil
syncPoint= string | nil par convention la chaine est not´ee Ti delta= string | nil
pause= specialLink separator ackMsg specialLink=”999” separator “999”
ackMsg= string string string string Question/Reponse/image/nouveau titre sc´enario.
3 Description des param` etres
3.1 Format du d´ ebut du fichier
ScenarioName= le nom du sc´enario qui est affich´e par le d´emonstrateur juste en dessous du menu.
NodeName ; i= nom du nœud i, tous les noms sont affich´es sur une mˆeme ligne. En dessous du nom est trac´ee une barre verticale d’o`u partent et arrivent les messages. Le nombre de nœuds dans le chronogramme est d´etermin´e par le nombre de “NodeName” plac´es dans le fichier. Suivant les cas une image peut etre associ´ee `a nœud
PropagThroughput ; i ; j ; propagTime ;throughput d´esigne le d´elai de propagation (propagTime du nœud i vers le nœud j et le d´ebit throughput support´e par le lieni−→j.
3.2 Format des messages
Pour chaque message, on a le format suivant. Tous les caract`eres sont sur la mˆeme ligne(sans blanc). Voici le format g´en´erique des messages :i ;j ; name ; type ;length ;treatment ;dash ;step ;startTime
i= si i<= 20 alors c’est le num´ero du nœud d’o`u part le message (source). Par contre sii> 20 c’est un message de pause. Dans notre cas nous avons choisi le nombre 999 pour ´eviter toute ambiguit´e. j= sij<= 20 alors c’est le num´ero du nœud de destination du message. Par contre si j> 20 c’est un message de pause. Dans notre cas nous avons choisi le nombre 999 pour ´eviter toute ambiguit´e.
name=nom du message avec ´eventuellement des param`etres entre des parenth`eses. Il ne doit pas contenir de point-virgule car ce caract`ere est un s´eparator entre les diff´erents ´el´ements du sc´enario.
type= type du message :
– REQU EST d´esigne un message de type requˆete. Les requetes sont marqu´ees ROUGE dans l’illustration des sc´enarii
– RESP ONSEd´esigne un message de type r´eponse. Les r´eponses sont marqu´ees ORANGE dans l’illustration des sc´enarii
– ON EW AY d´esigne un message qui n’attend pas forc´ement une r´eponse. Ce type de massages est marqu´e VIOLET dans l’illustration des sc´enarii
length=longueur du message, en fonction du d´ebit du lien. Ce param`etre sert `a calculer l’´epaisseur du trait repr´esentant le message transmis
treatment=d´elai de traitement du message (ce d´elai apparaˆıt en trait fonc´e noir apr`es le message).
dash= type du trait `a dessiner : semi−→pointill´e et f ull −→ trait plein.
step=rang du traitement du message dans l’ex´ecution de l’algorithme. Ce param`etre est utilis´e lors du calcul des ordonn´ees des diff´erents messages.
startTime= permet de faire d´emarrer un message `a un instant t donn´e. S’il y a rien (valeur=blanc) ou s’il y a une ´etoile *, cela signifie que le message est cons´ecutif au message qui le pr´ec`ede. Sinon la valeur indique la date `a la quelle doit d´emarrer le message. Cette date est par convention not´ee t0 pour le premier message. Attention, si on d´efinit un point de synchronisation (cf. ci-dessous), il faut remplir le champ avec une ´etoile * et ne pas le laisser vide.
syncPoint : d´efinit un point de synchronisation. Il correspond `a l’instant d’arriv´ee (sans le d´elai de traitement) du message lorsque le champ suivant est vide.
delta : permet de d´efinir un d´elai sur le point de synchronisation. Si le champ est pr´esent, le point de synchronisation est d´efini comme l’instant d’arriv´ee du message plus la valeur delta. Soit m1 un message et m2 un message qui part 40 unit´es de temps apr`es l’arriv´ee du message m1. On met, dans le champ syncP oint de m1, un point de synchro- nisation not´e T1 et on met le champ delta `a 40. Ensuite on met dans le champ startime dem2 la valeurT1. La date de d´emarrage dem2 est calcul´ee dynamiquement par le programme.
pause : la pause est d´efinie dans le sc´enario et est identifi´ee par le message 999; 999;...
La premi`ere chaˆıne de caract`ere est le message `a afficher. La seconde d´esigne la r´eponse `a la question pos´ee.
La troisi`eme coresspond au nom du fichier image `a charger. Enfin la derni`ere correspond au titre `a afficher apr`es la pause.
La pause correspond donc `a l’affichage d’un message avant la pause. Un nouveau sc´enario est alors affich´e apr`es la pause et au chargement d’une nouvelle figure.Lorsque l’utilisateur appuie sur le bouton Continue la nouvelle figure est charg´ee et le nouveau titre du sc´enario s’affiche.
3.3 Remarques importantes
1. L’espace (ou blanc) est interpr´et´ee par la grammaire comme un caract`ere au mˆeme titre que les autres caract`eres. Il faut donc ´eviter d’avoir un blanc apr`es un chiffre pour ´eviter que le programme plante probl`eme deparsing;
2. Si l’on d´esire mettre un point de synchronisation et pas de startime l’on doit ´ecrire sim- plementdebutMessage ;* ;Ti o`uTi est le point de synchronisation. Notez bien l’´etoile qu’il faut mettre dans le champ startime!
3. Si l’on d´esire mettre un startime et pas de point de synchronisation l’on doit ´ecrire simplement debutMessage ;Ti o`u Ti est le point de synchronisation. On peut rajouter
´eventuellement un point-virgule `a la fin.
4. Tous les messages sont synchronis´es par rapport au premier message dont le startT ime est fix´e par convention `a t0.
5. Les messages de pause peuvent contenir des balises html de base pour permettre une meilleure pr´esentation. Ce sont essentiellement les balises < html > ... < /html > et la balise < br > pour retour `a la ligne. L’absence des ces balises dans les fichiers sc´enario que vous r´edigez peut entrainer un probl`eme d’affichage si les messages sont longs.
6. Les fichiers de sc´enarios ont une extension .csv. Ils sont lisibles par Excel s’ils ne contiennent pas de html. Ils sont lisibles dans tous les cas par le tableur Open Office.
Le point-virgule est `a interpr´eter comme un s´eparateur de champ, cela permet d’avoir les sc´enarios sous forme de tableaux qui sont plus expoitables. Attention, faire ”sauvegarder sous” en s´electionnant le contrˆole du filtre et en choisissant ; comme s´eparateur et rien comme d´elimiteur de texte.
4 Conclusion
Le format de fichier impos´e permet d’adapter le code de l’algorithme de chargement des fichiers des diff´erents sc´enarii lors de la d´emonstration. Le mod`ele tel que d´ecrit n’impose pas un ordre pour les ´el´ements du sc´enario. N´eanmoins, il est important d’´editer les fichiers sc´enario en s’appuyant sur l’exemple que nous avons donn´ee plus haut.
A Annexes
A.1 Exemple de fichier sc´ enario respectant le mod` ele avec deux points de synchronisation T
1et T
2Le fichier sc´enario se divise en deux parties. La premi`ere partie d´esigne l’en-tˆete du sc´enario et d´ecrit les nœud et leurs carat´eristiques. La deuxi`eme partie regroupe les diff´erents messages qui seront ´echang´es entre les diff´erents nœuds durant l’illustration.
A.1.1 L’en-tete du sc´enario
# Head of the scenarioexampleHead.csv
ScenarioName ;Location updating procedure between VLRs File ;firstLU.gif ; ;
NodeName ;0 ;MS ;ms.gif ; ;
NodeName ;1 ;MSC/VLR F2 ;vlr hlr.gif ; ; NodeName ;2 ;HLR F ;vlr hlr.gif ; ; ; ; NodeName ;3 ;MSC/VLR F1 ;vlr hlr.gif ;
#PropagThroughput ;sourceNode ;destinationNode ;propagationTime ;throughput Time ; PropagThroughput ;0 ;1 ;40 ;6400 ; ;
PropagThroughput ;1 ;0 ;20 ;6400 ; ; PropagThroughput ;1 ;2 ;20 ;6400 ; ; PropagThroughput ;1 ;3 ;20 ;6400 ; ; PropagThroughput ;2 ;1 ;20 ;6400 ; ; PropagThroughput ;2 ;3 ;20 ;6400 ; ; PropagThroughput ;3 ;1 ;20 ;6400 ; ; PropagThroughput ;3 ;2 ;20 ;6400 ; ;
Quelques explications : Le titre du sc´enario sera Location updating procedure between VLRs l’image associ´ee au sc´enario est contenu dans le fichier firstLU.gif ; ; Il ya 4 nœuds avec des imag´ees qui leur sont associ´e. Par exemple le lien entre le nœud 0 et le nœud 1 est caract´eris´e par un temps de propagation de 40 millisecondes et un temps et un d´ebit de 6400 bits/s. Ces valeurs permettent de donner une inclinaison aux diff´erentes fl`eches dessin´ees lors de l’illustration.
A.1.2 Le corps du sc´enario
# Messages of the scenario exampleMsg.csv
#Data from i to n ;name ;type ;length ;treatment ;dash ;step ;startTime ;synchPoint
0 ;1 ;MM LOCATION UPDATING REQUEST(TMSI,old LAI) ;REQUEST ;160 ;2 ;semi ;0 ;t0;T1 1 ;3 ;MAP SEND AUTHENTICATION INFO(IMSI MS) ;REQUEST ;240 ;2 ;semi ;4 ;T1 ;
3 ;1 ;MAP SEND AUTHENTICATION INFO(RAND,SRES,KC ) ;RESPONSE ;20 ;2 ;semi ;0 ; 1 ;0 ;MAP AUTHENTICATION REQUEST(RAND) ;REQUEST ;160 ;2 ;semi ;0 ;T1 ;
0 ;1 ;MAP AUTHENTICATION RESPONSE(SRES) ;RESPONSE ;64 ;2 ;semi ;0 ; 1 ;2 ;MAP UPDATE LOCATION(IMSI MS, MSC 2, ) ;REQUEST ;720 ;2 ;semi ;0 ; 2 ;3 ;MAP CANCEL LOCATION() ;REQUEST ;512 ;2 ;semi ;0 ;
3 ;2 ;MAP CANCEL LOCATION ACK() ;RESPONSE ;42 ;2 ;semi ;0 ;
999 ;999 ;Le message est-il acquit´e ? ;Voyons a travers la suite du sc´enario ;newVLR.gif ;Location updating procedure between VLRs
2 ;1 ;MAP INSERT SUBSCRIBER DATA(profile) ;REQUEST ;1632 ;90 ;semi ;0 ;* ;T2 ;20 1 ;2 ;MAP INSERT SUBSCRIBER DATA ACK() ;RESPONSE ;480 ;2 ;semi ;0 ;T2 ; 2 ;1 ;MAP UPDATE LOCATION ACK() ;ONEWAY ;42 ;2 ;semi ;0 ;2 ;T2 ;
1 ;0 ;MM TMSI REALLOCATION COMMAND(TMSI-new) ;REQUEST ;160 ;2 ;full ;0 ; 0 ;1 ;MM TMSI REALLOCATION COMPLETE() ;RESPONSE ;48 ;2 ;full ;0 ;
1 ;0 ;MM LOCATION UPDATING ACCEPT() ;ONEWAY ;48 ;2 ;full ;0 ;
Quelques explications :
La ligne 0 ;1 ;MM LOCATION UPDATING REQUEST(TMSI,old LAI) ;REQUEST ;160 ;2 ;semi ;0 ;t0;T1 indique que le premier message part du nœud 0 vers le nœud 1. Ce message s’appelle MM LOCATION UPDATING REQUEST et poss`ede deux param`etres : TMSI et old LAI. C’est une requete (REQUEST).
Le message a pour longueur 160 (bits) et aura un temps de traitement de 2 millisecondes sur le nœud 1 et le trait rouge(REQUEST)repr´esentant ce message est en pointill´e car c’est message d’ouverture de connection(session). La valeur du step permet de s´equencer les messages dans l’ordre de leur apparition. Ce premier message est marqu´e a pour startT ime la valeur t0 et d´efinit un point de synchronisation not´eeT1.
Les autres messages suivent le meme format. En particulier, le deuxi`eme et le quatri`eme message suivent le meme format mais `a la diff´erence que ces messages ont pour valeur de startT imela valuer T1 qui est le point de synchronisation d´efini par le premier message. Ces deux messages partent en meme temps d`es la fin du traitement du premier message. C’est la notion de point desynchronisation.
Le message commen¸cant par999 ;999 est un message de pause : L’illustrateur de protocole s’arrete.
La question pos´ee `a l’utilisateur est Le message est-il acquit´e ?. D`es que l’utilisateur `a cliquer sur le boutonContinuela r´eponseVoyons a travers la suite du sc´enarios’affiche une nouvelle image est charg´ee newVLR.gif, un nouveau titre apparait Location updating procedure between VLRs et l’illustrateur de protocole poursuit son ex´ecution.
