WO2004107714A1 - Systeme de specification et de mise en oeuvre de protocole de communication et de transmission, - Google Patents

Systeme de specification et de mise en oeuvre de protocole de communication et de transmission, Download PDF

Info

Publication number
WO2004107714A1
WO2004107714A1 PCT/FR2004/001310 FR2004001310W WO2004107714A1 WO 2004107714 A1 WO2004107714 A1 WO 2004107714A1 FR 2004001310 W FR2004001310 W FR 2004001310W WO 2004107714 A1 WO2004107714 A1 WO 2004107714A1
Authority
WO
WIPO (PCT)
Prior art keywords
protocol
description
abstract
data
receiver
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/FR2004/001310
Other languages
English (en)
Inventor
Michel Mouly
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sierra Wireless SA
Original Assignee
Wavecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from FR0306368A external-priority patent/FR2855699B1/fr
Application filed by Wavecom SA filed Critical Wavecom SA
Publication of WO2004107714A1 publication Critical patent/WO2004107714A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/03—Protocol definition or specification 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities

Definitions

  • the present invention relates to the field of communication protocols.
  • the invention relates to the automatic generation of specification of communication protocols between one or more transmitters and one or more receivers.
  • the development of signaling protocols in the telecommunications field includes a specification phase, a software development phase in the remote entities which communicate by applying these protocols, often followed by a test phase.
  • a protocol is essentially a language allowing two separate and distant machines to exchange information using ultimately a transmission medium. In practice, this language is organized in different more or less independent parts, each one considered itself as a protocol. The protocols are then arranged in layers, each protocol with the exception of the “lowest” using not directly the transmission medium but a transmission service provided by the “directly lower” protocol.
  • protocols can be analyzed from the point of view of vocabulary or lexicon (list of message types, lists of message parts), encoding (phonemes and morphemes for human languages, forms of (digital wave and encoding for protocols), syntax (grammar rules), semantics (meaning of messages and parts of messages), procedural rules (rules governing dialogs between dialoging entities; this is this part evoked by the word "protocol”), and finally praxis (effect of messages).
  • the lexicon appears in the form of lists of messages and parts of messages (“information element”), each with the grammar and the associated encoding.
  • the rules of procedure are specified as a list of more or less independent procedures, described as the actions entailed by the reception of messages coming from the even entity or of commands coming from other software in the same machine. This most often covers both the procedural rules (visible actions and reactions, and therefore testable, in the flow of information flowing between the paired entities) as well as the more general "praxis” (internal actions not necessarily visible).
  • the specification of semantics is dispersed in the description of lexical elements, in the description of procedures, and often in other documents.
  • ASN.l (Abstract Notation 1) is a formal language specified by ISO (X.680 and X.690 series) allowing to describe data structures by distinguishing an abstract description (ie, which can be applied to different methods d 'encoding) and methods for encoding these data structures. It is commonly applied to the description of the structure of the messages of a protocol, each message being considered as a data structure. Because formal, a specification written in ASN. l can be automatically translated into message encoding and decoding software.
  • ASN it has recently been extended to allow the formal description of encoding methods, with the aim of applying ASN.l to specifications either not originally written in ASN.l, or for which the general encoding methods specified by ISO are unsatisfactory for one reason or another.
  • XML is a formal language whose aims are close to those of ASN.l in that it makes it possible to describe data structures and therefore messages when they are limited to a data structure. Like ASN. l, XML allows automatic generation of encoding and decoding software.
  • CSN.l is a formal language developed by the inventor, and used in some specifications of ETSI protocols. This language makes it possible to describe the grammar of bit strings (and is much more like formal grammar description languages like BNF, than data description languages), and can be used to describe the structure as a string message bits of most telecommunications protocols. It distinguishes itself for these purposes in two ways from ASN.l or XML: it can be used a posteriori, to describe messages whose encoding is described in some way in a specification, and it does not try to approach even partially the semantics linked to the structure. As in the case of the previous languages, a specification in CSN.l can be used for the automatic generation of encoding and decoding of messages.
  • CSN.l Compared to ASN.l and XML, CSN.l has the advantage of being applicable to any protocol, and therefore of allow a unified realization of the corresponding part of the realization of the protocol. In return, CSN.l does not describe messages as data structures, and this link cannot therefore be generated automatically.
  • SDT or SDL (as well as other related methods) address the formalization of procedures seen as time sequences of action. These methods are each centered around a formal language describing events (reception of messages or internal commands) and action sequences initiated by these events (sending messages or internal responses, memorization of data, transition of states , ).
  • the invention according to its various aspects aims in particular to overcome these drawbacks of the prior art.
  • an objective of the invention is to optimize the specification of the communication protocol and its practical implementation.
  • Another objective of the invention is to allow rapid and efficient development of communication protocol stacks, in particular in the field of mobile communications.
  • the invention also aims to allow the automatic generation of a substantial part of the software necessary for the implementation of the protocol.
  • the invention also aims to limit human intervention in the various phases of implementation of a communication protocol in a transmitter and / or a receiver, in particular in order to reduce the duration and to limit human errors which can cause non-optimal operation of the transmitter and / or receiver.
  • the invention provides a system for specifying and implementing a communication and transmission management protocol between at least one transmitter and at least one receiver, comprising: means for determining a common context comprising means for describing a set of data managed by the transmitter (s) and / or the receiver (s); means of identification of the protocol messages capable of being exchanged between the transmitter (s) and the receiver (s), the identification being independent of the representation (s) used for the messages; means for defining representations of data stored and / or transmitted by the transmitter (s) and / or the receiver (s) from determining a common context and identifying the messages, defining representations making it possible to determine instructions for implementing the protocol in at least one of the transmitters and at least one of the receivers; and - means for implementing the protocol in at least one of the transmitters and at least one of the receivers from the implementation instructions, so that the transmitter (s) are able to communicate with the receiver (s).
  • a communication management protocol is understood here in the strict sense and in particular does not
  • the system is remarkable in that the means for determining a common context themselves include means for describing a structure of the context, the description being independent of the representation or representations used for storage and / or data transmission.
  • the notion of independence here means that one can change and / or modify the storage representation without invalidating the abstract representation.
  • the system is remarkable in that the means for determining a common context also comprise means for identifying and describing the types of objects making it possible to analyze the structure of the context, the identification and the description of the types of objects being independent of the representation or representations used for storage and / or transmission.
  • the system is remarkable in that all or part of the data managed is the data that the protocol aims to keep coherent in at least one transmitter among the transmitter (s) and at least one receiver among the receiver (s).
  • coherent data means that these data have a semantic identity but not necessarily a representation identity. For example, a frequency expressed in MHz can have the same meaning as a frequency expressed in Hz while the representation is different.
  • the system is remarkable in that at least part of the identification of the messages is carried out in terms of actions and / or of its effects on the common context.
  • the system is remarkable in that it comprises means of connection between: - a description of the form of signal actually transmitted; and identification of protocol messages.
  • the system is remarkable in that the shape of the signal belongs to the group comprising: the sequences of binary data; - the sequences of elements taken from a predetermined alphabet; and sequences of modulated waveforms.
  • the signal can be associated with very different types of symbols.
  • the system is remarkable in that the connection is made in a data specification language comprising functions allowing the description of the data in the form of attributes of abstract objects and of functions applying to concrete representations. .
  • the system is remarkable in that the specification of the signal form is done in CSN1 language enriched with functions allowing the description of the data in the form of attributes of abstract objects and functions applying to representations. concrete.
  • the system is remarkable in that it comprises means for using the context data in a formal description of an encoding and / or a decoding.
  • the system is remarkable in that the means for determining a common context, the means for identifying protocol messages and the means for defining data representations each implement a formal language allowing automatic determination of the software for implementing the protocol. According to a particular characteristic, the system is remarkable in that it comprises means for automatically determining the software for implementing the protocol.
  • the system is remarkable in that it comprises means for automatic determination of tests of devices implementing the protocol.
  • the system is remarkable in that the means for determining a common context comprise means for translating a mode of representation of a protocol into the description of a set of data. According to a particular characteristic, the system is remarkable in that the means for identifying protocol messages include means for translating a mode of representing protocols.
  • This feature allows in particular the development of a description in the formalism of the invention from an existing description, for example from a standardization committee.
  • the invention advantageously allows the reuse of the parts common to several protocols and in particular the invention offers the possibility of having a protocol core which is enriched with specificities to create other protocols each having their specificity.
  • the system is remarkable in that it further comprises means for viewing the semantics of the protocol messages exchanged between the transmitter (s) and / or the receiver (s).
  • the invention relates to a method for specifying and implementing a communication and transmission management protocol between at least one transmitter and at least one receiver, remarkable in that it comprises the following steps: - determination of a common context comprising a description of a set of data managed by the transmitter (s) and / or the receiver (s); identification of the protocol messages likely to be exchanged between the transmitter (s) and the receiver (s), the identification being independent of the representation (s) used for the messages; definition of representations of data stored and / or transmitted by the transmitter (s) and / or the receiver (s) based on the determination of a common context and the identification of the messages, the definition of representations making it possible to determine instructions for implementation of the protocol in at least one of the transmitters and at least one of the receivers; and implementation of the protocol in at least one of the transmitters and at least one of the receivers from the implementation instructions, so that the transmitter (s) are able to communicate with the receiver
  • the invention relates to a specification of a communication protocol, characterized in that it is obtained by the implementation of the method described above, of specification and implementation of a communication management protocol and of transmission.
  • the invention also relates to a formal language for describing at least one element of a communication protocol, remarkable in that it is suitable for implementing the method described above, for specifying and implementing a protocol. communication and transmission management.
  • the invention also relates to a communication device, remarkable in that it includes instructions allowing the transmission and / or reception of data to or from a third-party device another device according to a protocol obtained by implementing the method as described above.
  • the invention relates to a computer program product comprising program elements, recorded on a medium readable by at least one microprocessor, characterized in that the program elements control the microprocessor (s) so that they perform the steps following adapted to the specification of communication and transmission protocol between at least one transmitter and at least one receiver: determination of a common context comprising a description of a set of data managed by the transmitter (s) and / or the one or more receivers; identification of the protocol messages likely to be exchanged between the transmitter (s) and the receiver (s), the identification being independent of the representation (s) used for the messages; - definition of representations of data stored and / or transmitted by the transmitter (s) and / or the receiver (s) based on the determination of a common context and the identification of the messages, the definition of representations making it possible to determine instructions implementing the protocol in at least one of the transmitters and at least one of the receivers; and implementation of the protocol in at least one of the transmitters and at least one of the receivers from the implementation instructions, so that the
  • the invention also relates to a computer program product, comprising sequences of instructions suitable for implementing the method for specifying the communication protocol between at least one transmitter and at least one receiver when the program is executed on a computer.
  • a computer program product comprising sequences of instructions suitable for implementing the method for specifying the communication protocol between at least one transmitter and at least one receiver when the program is executed on a computer.
  • FIG. 1 presents a block diagram of specification of a protocol according to the invention according to a particular embodiment.
  • An object in this sense, can be a concrete object, according to common sense, like a screen or a keyboard, but also something more abstract like a screen area or a file, or even very abstract like a file wait.
  • An object type describes not only its attributes, but also the actions of which the object can be the object.
  • This process is divided into successive stages: a first stage 1 of encoding and decoding specification; a second step 2 of specification of the context; and a third step 3 of message specification.
  • Step 1 of specifying the encoding and decoding is carried out in CSN.l which is known per se.
  • the first formalized aspect of the specification of a protocol according to the method described is the formal specification of the structure of the bit chains exchanged. This is the description of the lexicon according to its form, like a list message structures or message elements. This description specifies sets of acceptable bit strings, as well as the structure (syntax) of these strings. It automatically generates encoding and decoding software, the latter including the detection of erroneous channels (ie, not belonging to the set of acceptable channels).
  • Step 2 consists in formally describing the structure of the data forming the context of each of the even entities. This description will highlight the common part of the two contexts, that is to say the data managed as a distributed database.
  • This formal description can use any formal data structure description language, such as ASN.l, description methods as found in programming languages like C ++, or as found in database management software.
  • a language specially developed for this purpose is used, making it possible to easily make the bridge between the data structures appearing in the messages and the descriptions of data structures as used by the developers, such as those permitted by the language of C ++ programming.
  • a message description according to the method gives the meaning of the message, in the form of the expected effect of the reception of the message by the even entity. It also explains the meaning of the parameters, indicating their role in the description of the expected action. This formalizes many aspects of the specification of a protocol which are traditionally covered in the descriptions of procedures by a text in natural language.
  • connection between the two, so as to allow the automatic generation of the software from the reception of the bit string up to and including the modification of the context of the common data.
  • the description of this connection can be done in various ways. One of these ways is based on the following principles.
  • Each bit string structure is associated with named functions returning values according to abstract types. For each function is described in detail the algorithm allowing to calculate the result of the function from the bit string received and, when necessary, from the current value of the common context. (This last point makes it possible to formalize context-dependent encoding methods, such as, for example, the use of index tables transmitted beforehand.) Correlatively, rules make it possible to associate with an abstract description a list of named functions corresponding exactly to all the parameters necessary to perform the actions requested by the message.
  • aspects not automatically generated are treated by adding program blocks attached, according to the data programming approach, to the data classes (methods), possibly as a complement to the automatically generated actions.
  • One application of the method consists in translating protocols specified otherwise (that is to say according to different methods) into a description in accordance with the invention.
  • Some of the advantages over traditional development methods include: standardization of developments; reduction of the code generated by pooling generic engines (eg, decoding engines); better modularization, making subsequent modifications easier.
  • the invention allowing direct specification of protocols can also be implemented by specification groups.
  • Formal descriptions can be used to directly generate tests to verify the conformity of an achievement with the description.
  • the complete specification method implements description syntaxes which can be broken down into five groups of syntactic elements (or formal sublanguages): a) a data structure description syntax, for the elements from the common context; b) a syntax for describing the encoding and decoding of symbol strings; c) a programming syntax, adapted in conjunction with syntaxes a) and b); d) syntactic elements making it possible to link the descriptions according to syntaxes a) and b); these elements may be an integral part of either syntax a) or syntax b), or even be limited to rules for correspondence between descriptions according to syntaxes a) and b); and e) a syntax for describing messages as actions acting on the context.
  • the specification method implements the first four syntaxes a) to d) without using the last syntax e) for description of messages.
  • Annex 2 illustrates a specification for simple data update.
  • Appendices 3 and 6 illustrate a more complex case of specifying a GSM protocol (“Global System for Mobile Communication”) standardized by the ETSI (European Telecommunication Standard Institute) for mobility management between a mobile station (MS) and a network infrastructure.
  • GSM protocol Global System for Mobile Communication
  • ETSI European Telecommunication Standard Institute
  • the invention can, moreover, be implemented on very varied development machines or tools, allowing, for example, the specification of communication protocols, the generation of codes or more generally the design and implementation of communication protocols.
  • the invention is implemented in the form of a sequence of instructions from a computer program.
  • the corresponding sequence of instructions can be stored in a removable storage means (such as for example a floppy disk, a CD-ROM or a DVD-ROM) or not, this means of storage being partially or fully readable by a computer or a microprocessor.
  • a module described in appendix 1 comprises elements of formal description specifying a communication protocol associated with even entities.
  • the module includes three types of description: abstract descriptions of object types (section 3); this corresponds to a syntax of type a) illustrated previously; - transfer descriptions applying either to messages or to objects as part of a message (section 6); this corresponds to a syntax of type b); and abstract descriptions of actions (messages for example), section 5 (syntax of type e)) or programming of actions, according to syntax of type c).
  • the abstract descriptions of actions managed automatically by a specification system are advantageously replaced by manual or semi-automatic programming of actions.
  • Each type corresponds to a separate formal language.
  • the module is essentially organized as a list of types of objects.
  • Each type of object is associated with an abstract description, possibly one or more transfer descriptions, and possibly one or more actions.
  • Each action is associated with an abstract description and possibly one or more transfer descriptions.
  • module syntax For practical reasons, the general organization of a module makes it possible either to group the descriptions according to the above logic, or to separate the elements (for example to group all the messages together), in which case the links are explained (by example the description of a message then indicates the type of object with which it is associated).
  • the module consists of a header, followed by a list of object type descriptions, autonomous action descriptions, and autonomous transfer structure descriptions.
  • the module header includes its name and possibly other information.
  • a description includes: - an abstract description, introduced by the keyword 'abstract'; zero, one or more transfer descriptions, each introduced by the keyword 'transfer'; zero, one or more action descriptions, each introduced by the keyword 'action'.
  • a transfer description describes a symbol chain structure (for example binary or described by a character string) which can correctly represent the abstract structure (see the chapter on the subject).
  • An action (message) associated with the object type describes modifications that can be requested to an instance of said object type.
  • An abstract description of an object type is usually presented as a set of components.
  • Each component is notably characterized by: a component name, presence information, and a type description.
  • the component name is a free string using the available characters except the characters '[', '.',
  • An indexed component can have a variable number of copies, distinguished by an index.
  • An indexed component is indicated by an interval specification between '[' and ']'. Different specifications are possible:
  • Free variable number this is indicated by an interval (two integers separated by '..').
  • Cinfinity A special case is Cinfinity which indicates any number of copies.
  • Conditional variable number this is indicated by an expression of type 'iif, indicating different intervals or fixed number to be selected according to Boolean expressions relating to the values of other elements of the structure.
  • Such a description is introduced by a ':'. This includes: integers (keyword 'integer', possibly followed by an interval in parentheses); listed type (keyword 'enumerated' followed by a parenthesized list of identifiers separated by commas); - bit string (keyword 'bit string', possibly followed by a size or a size interval in parentheses)
  • a structure is introduced by ' ⁇ ', and is described by a succession of lines starting with a '+' more than the line introducing the component, and ending with a ' ⁇ '.
  • a union is a shorthand for a set of components of exclusive presence.
  • a reference is introduced by a character ':', and is the name of a data type described elsewhere.
  • the type description module is not the enclosing module, it is indicated in brackets following the type name.
  • An index type is introduced by '->' followed by a node name.
  • a node name is composed of an object type name (possibly empty, in which case it is the current type), followed by a series of component names separated by
  • a node name gives: - Static information of the indexed type (the type of the last component); - A dynamic link to a particular instance of the list. This link is resolved by going up the instance tree until you find an object of the type indicated.
  • a transfer description describes a symbol chain structure that can correctly represent the abstract structure (see the chapter on the subject).
  • An abstract action description optionally includes a list of parameters, and optionally a list of instructions.
  • the instructions generally ask for parameters which appear for example in the representation of the action. These parameters are not listed in the list of parameters: this does not contain the parameters which cannot be described more precisely as related to an elementary instruction.)
  • the list of parameters is introduced by the keyword 'parameters' and is terminated by the keyword 'end'. The list follows the syntax of the abstract object type description.
  • the action list consists of one or more lines. Each line consists of a possible condition indication, followed by an instruction from those listed below.
  • a condition indication is either the keyword 'OPTIONAL' or an IF THEN instruction.
  • the OPTIONAL keyword indicates that the instruction, or the list of instructions between ' ⁇ ' and ' ⁇ ', which follows may or may not be requested.
  • An IF THEN instruction indicates (between the keywords 'IF' and 'THEN') a condition, expressed from parameter values, whether the instruction is to be done or not.
  • a selection instruction is introduced by the keyword On 'followed by the name of a component (typically a structure) to which a list of instructions between' ⁇ 'and' ⁇ 'applies. If the component is indexed, an index indication can follow the component name (see section on the index).
  • a SET statement is introduced by the keyword 'set' followed by a component name (possibly with an index). This instruction requests the assignment of a new value to the component (in its integrity, which can be a fairly significant subtree). There are several ways in which the new value can be specified:
  • the instruction contains nothing more.
  • the message then contains a parameter of the type of the component, as described in the abstract description of object.
  • An ADD instruction is introduced by the keyword 'set' followed by an indexed component name (without index indication in the ADD instruction). This instruction requests the addition of a new copy to the component (in its integrity, which can be a fairly significant subtree). There are several ways in which the new value can be specified, as in the case of the SET instruction (except the dump).
  • a SEND instruction is introduced by the keyword 'send' followed by a component name (possibly with an index). This instruction indicates the inclusion of a parameter whose value is the current value of the component on the source side.
  • the action on the receiver side is to check the consistency, but the consequence of an inconsistency detection is not specified.
  • a CHOICE statement is introduced by the keyword 'choice' followed by a list of actions between ' ⁇ ' and ' ⁇ ' and separated by ','. This indicates that only one and only one of the actions is requested for each occurrence of the action.
  • a DO instruction consists of the keyword 'do' followed by the name of an action. This action must be compatible with the current type of component.
  • This instruction indicates acceptance of changes subject to PREPARE on the current node.
  • This instruction indicates the rejection of modifications subject to a PREPARE on the current node.
  • the transfer description is basically CSN.1 version 2.2 language type, with the following adaptations.
  • a formula can invoke context element values.
  • An action can be described outside of the description of the type of object to which it relates.
  • the action description is then preceded by a header composed of the keyword 'on' followed by the name of the object type on which the action is carried.
  • the indication of the type of object may be omitted in the case of a separate description of action by following another applying to the same type.
  • a transfer description can be separated from the abstract description to which it corresponds.
  • a name (object or action) is made up of free characters, with the exceptions necessary for syntactic reasons.
  • consecutive strings of space, tabulation and end of line are considered equivalent to a single space, except at the beginning and end, where they are considered equivalent to the empty string; hunting is not taken into account.
  • APPENDIX 2 First example: specification of a simple update of a data.
  • a protocol is presented here as part of an illustrative unidirectional protocol whose sole purpose is to update data.
  • the application of the method proceeds as follows: abstract description of the context; abstract description of messages; - description of data encoding and decoding; description of message encoding and decoding;
  • the specifications illustrated with respect to Annex 2 use the elements of formal description in Annex 1 and allow automatic generation of code according to the invention.
  • ⁇ type of protocol context> :: managed data: type of managed data
  • the expression 'managed data type' can represent any data type, for example:
  • ANNEX 3 Example of specification of a real protocol (the GSM protocol for mobility management between a mobile station (MS) and a network infrastructure)
  • GSM Global System for Mobile communication
  • ETSI European Telecommunication Standard Institute
  • Mobile Station Classmark 1 RIL3. Mobile Station Classmark 1
  • Action ABORT abstract parameters
  • Reject cause MM. Reject cause
  • Authentication Parameter RAND MM. Authentication Parameter RAND
  • ⁇ Authentication parameter AUTN ⁇ 0-TLV-IE (0010 0000, Authentication parameter AUTN, 18, 18) »
  • ⁇ Mobile station classmark 2 ⁇ M-LV-IE (Mobile station classmark 2, 4, 4) " ⁇ Mobile identity: ⁇ M-LV-IE (Mobile identity, 2, 9)" ⁇ Priority: ⁇ Q-TVD- IE (1000, Priority Level) " abstract.Mobile Identity type returns Mobile identity.V.Type of identity.abstract
  • Mobile Identity Type MM Mobile Identity Type end
  • TMSI allocation status Enumerated (new TMSI, keep TMSI, erase TMSI)
  • Mobility management information (or "MM INFORMATION")
  • 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
  • Local time zone returns 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, ⁇ no string>))
  • TMSI REALLOCATION COMMAND (or "TMSI REALLOCATION COMMAND")
  • TMSI REALLOCATION COMMAND action abstract on Location parameters ⁇ PREPARE set LAI + TMSI ⁇ 1.2.20.2 Transfer syntax
  • LA list List of localization zones
  • ⁇ LA Iist> abstract Location area description [0 .. infinity]: + 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
  • CM Service Type 5 CM service type (or "CM Service Type")
  • ⁇ CM Service Type> abstract service type: Enumerated (MO call or packet est, emergency call, SMS, SS, VGC, VBS, LCS)
  • ⁇ IMEI> :: abstract Type Approval Code [6]: Integer (0..9) Final Assembly Code [2]: Integer (0..9) Sériai Number [6]: Integer (0..9)
  • a formal protocol description module is described in appendix 4 and includes formal description elements specifying a communication protocol.
  • the module contains three types of description: abstract descriptions of object types (corresponding to a syntax of type a) illustrated previously); abstract descriptions of actions (messages for example) (corresponding to a syntax of type e); and transfer descriptions applying either to messages or to objects as part of a message (corresponding to a syntax of type b).
  • Each type corresponds to a separate formal language.
  • the module is basically organized as a list of object types.
  • Each type of object is associated with an abstract description, possibly one or more transfer descriptions, and possibly one or more actions.
  • Each action is associated with an abstract description and possibly one or more transfer descriptions.
  • the general organization of a module makes it possible either to group the descriptions according to the above logic, or to separate the elements (for example to group all the messages together), in which case the links are explained (by example the description of a message then indicates the type of object with which it is associated).
  • a module is composed of a header, followed by a list of description of type of object, autonomous descriptions of actions and autonomous descriptions of transfer structure.
  • the module header has its name, the default scope.
  • a description includes at least: - an abstract description; zero, one or more transfer descriptions; and zero, one or more command descriptions.
  • a transfer description describes a binary chain structure which can correctly represent the abstract structure (see the chapter on the subject).
  • An action (message) associated with the object type describes modifications that can be requested to an instance of said object type.
  • An abstract description of an object type is usually presented as a set of components.
  • Each component is characterized by: a component name, presence information, and a type description.
  • a component can be provided with an index (table).
  • an index allows to have a variable number of copies, distinguished by an index value. Different cases can be distinguished for the number of copies. 3.1.1 Fixed number of copies
  • the number of copies is specified by an integer.
  • the default case, single copy, is a special case of fixed number of copies.
  • the number of copies possible is then typically indicated by an interval of integers.
  • a special case is any number of copies (range from 0 to infinity).
  • the number of acceptable copies depends on the values of other elements of the structure.
  • a structure is presented as a list of components.
  • a union is a shorthand for a set of components of exclusive presence, ie, at most one of the components is present in an instance of the union.
  • a reference is a structure whose content is defined by reference to another type of object.
  • An index type component indicates a particular instance among a set of objects of the same type.
  • the definition of an index type component must include the reference to an indexed component of a particular object. This can be either a component included in the structure in which the index type component is defined, or a component included in a context, a single object common to the sender and the receiver.
  • a transfer description describes a binary chain structure that can correctly represent the action (see the chapter on the subject).
  • An abstract description of an action possibly includes a list of parameters, and possibly a list of elementary actions. (The instructions generally ask for parameters which appear for example in the representation of the action. These parameters are not included in the list of parameters: this list only contains the parameters which cannot be described more precisely as linked to an elementary education.)
  • the action list consists of one or more elementary actions. Each elementary action is made up of a possible condition indication, followed by an instruction from those listed below. 5.1 Indication of condition
  • a condition indication is used to indicate the conditions under which the instruction must be executed.
  • a first syntax makes it possible to describe a condition as a Boolean expression constructed from parameters.
  • a simplified syntax makes it possible to describe both the existence of a specific Boolean parameter and the execution condition corresponding to this parameter (e.g., keyword OPTIONAL).
  • a selection instruction makes it possible to indicate a sub-part of the object on which relates to a sequence of actions. We then use the term 'current node' to designate the sub-part to which an instruction relates. By default of selection instruction, the current node is an object of the type with which the action is associated. The specific object is implicitly determined.
  • the instruction includes an object type name. This type must be compatible with the type of the component (subtype). 5.3.3 Explicit value
  • the instruction includes an expression whose result must be compatible with the type of component.
  • the instruction includes a list of instructions. These instructions include the actions leading to the allocation of the component (typically subcomponent by subcomponent).
  • An add statement includes an indexed component name and a value.
  • This instruction requests the addition of a new copy to the component, having the indicated value (in its integrity, which can be a fairly important subtree). There are several ways in which the new value can be specified, as in the case of the assignment instruction.
  • a send instruction indicates the inclusion of a parameter whose value is the current value of the component on the source side.
  • the action on the receiver side is to check the consistency, but the consequence of an inconsistency detection is not specified.
  • a choice statement indicates that one and only one of the actions is requested for each occurrence of the action.
  • An execution instruction makes it possible to execute an action compatible with the type of current component.
  • a modification of data can be requested "on trial” and possibly refused by the receiver. This is managed by specific instructions for preparation (PREPARE), for acceptance of modifications associated with a preparation (COMMIT) and for refusal of modifications (UNDO).
  • This instruction indicates that the following modifications applicable to the current node can be canceled.
  • This instruction indicates acceptance of modifications subject to preparation (PREPARE) on the current node.
  • the transfer description is based on CSN.l version 2.2, with the following adaptations.
  • the header of a calculated function can be of the form “abstract.
  • the type is not indicated and is that of the abstract element as defined in the abstract description. More generally, the rules for correspondence between a transfer description and an abstract description (of object or message type) are the subject of Chapter 9.
  • An action can be described outside of the description of the type of object to which it relates.
  • the action description is then preceded by a header composed of the keyword 'on' followed by the name of the object type on which the action is carried out.
  • the indication of the type of object may be omitted in the case of a separate description of action by following another applying to the same type.
  • the full name of an action or of an object type is composed of a description or "scope" and a name in this scope.
  • the complete entry is then the scope followed by a point followed by the name in the scope.
  • the module header gives a default scope. We can then use the local name alone (not preceded by the scope), the scope then being the default scope.
  • the names of the scope and of the object are supposed to be linked to the nature of the object.
  • a name (of object, action or scope) is made up of free characters, with the exceptions necessary for syntactic reasons.
  • consecutive strings of space, tabulation and end of line are considered equivalent to a single space, except at the beginning and end, where they are considered equivalent to the empty string; the breakage is not taken into account (nor the color or other attributes of the same flour).
  • the formatting attributes (upper / lower case / other, that is to say the case in terms of typography; italic / bold / other, ...), or presentation (color, font, ...) are not involved in the comparison.
  • object class is common to many programming or specification languages, under different names such as "class” or "type".
  • class is a set of objects, these being described on the basis of characteristics common to all these objects.
  • the important shared characteristics are the representations (how to transmit the information making it possible to designate a particular object within the class), the external semantics (how the objects relate to an external reality), and the operations (computer processing which may involve objects).
  • the description of a class includes in the first place the specification of a minimum set of characteristics making it possible to distinguish any object of the class. According to the language described here, this corresponds to an abstract description of the class. This description is presented as a list of attributes, each attribute being itself an object. The description generally includes informal indications (i.e., not usable by processing, but intended for humans), such as the names of attributes or comments.
  • CSN.l descriptions make it possible to specify representations by binary or character strings, as well as the implicit or explicit rules making it possible to relate a representation and an element of the class according to the abstract description.
  • specific treatments for objects in the class can be included directly in the class description (methods).
  • the body of a method (the detailed description of the treatment) is described in modified C ++, the modifications allowing coupling with the abstract description.
  • the description of a class basically includes: - an identifier This is an unambiguous formal reference to the class, in the form of a character string; none or an abstract description; none, one or more representations; and none, one or more methods. Additional formal information can be provided. This can be seen in the detailed description of the syntax.
  • the language syntax makes it possible to derive one class from another, as well as to describe parameterized classes, a way of describing several classes at once, the differences of which can be captured by a small number of formal parameters .
  • the second case makes it possible to define a class from one or more others (class derivation).
  • aspectlist :: aspect I aspectlist aspect
  • Acceptable identification strings are described in the general section on identifiers.
  • a simple form of modularity consists in describing a class as the extension of one or more previously described classes. What is extended is limited to abstract description and processing.
  • the representations cannot be extended.
  • the syntax used to describe a class by derivation is the normal syntax with the exception of the header which then mentions the class or classes from which the new one is derived.
  • class derivation is only a textual shortcut.
  • the class thus described is that corresponding to the description obtained by including all aspects of the parent classes between the header and the first entry.
  • Each node description includes an identifier, which makes it possible to refer to it.
  • This identifier is usually chosen so as to give human readers an idea of the real semantics of the attribute.
  • a list of nodes is described as a list of triples, a triplet comprising: an identifier; - the multiplicity; and - an abstract description of structure.
  • the abstract description can be explicit, either a reference to a structure named elsewhere, or an elementary class description.
  • the syntax makes it possible to add additional information to a node, for example a so-called default value, the application of which is described below.
  • An abstract structure description is a sequence of description of nodes:
  • Each node is described by an identifier / multiplicity / description triplet:
  • the first syntax is the fundamental, the others can be brought back to it by formal rewriting.
  • the multiplicity is implicitly 1..1.
  • the construction "choice” is an abbreviated notation for the case of an exclusive presence of a node among a list.
  • multiplicity of a node is the number of nodes in an abstract structure sharing the same identifier and structure, the distinction being made by a serial number. This number is often dynamic, i.e., varies from one instance to another: what must be described is therefore the set of acceptable values for this number. Multiplicity is therefore a subset of positive or zero integers.
  • conditional presence can itself be dynamic, depending on the value of other attributes (conditional presence).
  • the language allows a detailed description of these cases.
  • a classic case of conditional presence is that where the total set of numbers is 0..1.
  • the first case corresponds to free multiplicities, i.e., unconditional; the other two have conditional presence.
  • free multiplicity the syntax is as follows:
  • integerset :: integersetelem "," integerset
  • the set of integers must include the possible multiplicities. This information is redundant since it can be derived from the following expression; its mandatory presence improves understanding and simplifies compilation.
  • the expression conddesc must return either a set of integers, an integer, or a boolean.
  • branchlist :: branchdesc “;” I branchlist ";” branchdesc “;”
  • the effective multiplicity is 0 if the discriminant does not have the adequate value, and the indicated multiplicity otherwise.
  • typedesc :: " ⁇ " complist " ⁇ ” id I leafdesc I id "(" exprlist ”)” "*" typedesc
  • the first possibility is an abstract description of syntax, parenthesized.
  • the second possibility is a reference to a predefined class, described by its identifier.
  • the third possibility is an elementary class description, predefined by the language. The possible syntaxes and their meanings are described below.
  • the fourth possibility is a reference to a parameterized class, consisting of the identifier and a list of effective parameters.
  • the fifth possibility is a reference to a predefined class, as in the first case.
  • Accepted elementary classes include the following classes: strict enumerated; Boolean; character; - finite cardinal (positive or zero natural integer); - countable (extended integer of infinite value); differences (signed integer); undefined or "void".
  • the syntaxes are:
  • leafdesc :: enumdesc I integerdesc chardesc I "boolean” I "void”
  • the list of expressions following the identifier must correspond in number and type to the list of parameters defined for the class.
  • valuelist :: value I valuelist "," value
  • the identifier that can appear between enumerated and the character "(" is a shorthand notation for declaring and invoking the class simultaneously.
  • Formal semantics include, among other things, comparison and equality tests, as well as the usual arithmetic operations.
  • Integers extended or not, are rarely used with the full range of values.
  • the syntax makes it possible to describe derived classes, limited to a finite subset of the values.
  • the first case corresponds to positive or zero integers (finite cardinals).
  • integerset :: integersetelem "," integerset
  • No syntax element can extend negative integers to -infinite
  • TGPRC Integer (1..51 1, infinity); (The number of intervals not allocated to transmission (or “transmission gap pattern” in English) among the sequence of time intervals not allocated to transmission (or “Transmission Gap Pattern Sequence” in English).
  • TGSN Integer (0..14); (the elementary time interval number of the first period not allocated to transmission (in English "slot number of the first transmission gap slot") in the TGCFN.
  • TGL1 Integer (1..14); (the length of the period not allocated to transmission in the pattern of transmission dips expressed in number of elementary time intervals. In these examples, the comments have been kept to show that it is a question of counting a value .
  • Vehicle indicates a general, undefined type.
  • a representation captures all of the attributes of an object as a string of binary symbols or characters.
  • the correspondence rules make it possible to relate an abstract description to a representation.
  • correspondence is defined on the basis of functions.
  • a function takes an object as a parameter and returns a value. Seen thus, a function has a name and a type of result.
  • Each terminal node corresponds to a list of functions, the first returns a count, the effective multiplicity of the node, that is to say the number of copies of the node. Then, for each integer i (by positive or null convention, ie 0 is included), a function returns the value of the i th elements.
  • a representation For each function defined from the abstract description, a representation must provide a corresponding function. The correspondence is based on the identity of the names, as well as, for the functions corresponding to the terminal nodes, on the existence of a transcoding rule making it possible to pass of a chain of symbols with abstract value.
  • Transcoding for a terminal node is obtained either by application of default rules, or by the specification in the transfer description of a transcoding function. 6.2 Default rules
  • numeric encoding values are specified in the abstract description, the decoding is that of an integer as specified in the next section, followed by transcoding derived from the abstract description.
  • the default decoding is the decoding of an integer followed by the transcoding applying to i the (i + l) th value of the list defined in the description of the abstract type.
  • the decoding is that of binary numbering, the first bit of the chain being the most significant bit. Decoding is complete (any string is acceptable), but not bijective (adding 0 to the front does not change the value). Typically, encoding will seek to limit the number of 0 at the front as best as possible.
  • the decoding is that of the code by complement to 2, the most significant bit being the first.
  • the decoding is complete, but not bijective (the addition at the front of a bit identical to the first bit does not change the value).
  • the decoding is that of the usual positional numbering, the first digit being that of most significant.
  • a sign character ("+" or "-") can optionally appear before the first digit.
  • Decoding is not complete: any character other than the digits from 0 to 9 causes a decoding error, as well as the use of a sign character elsewhere than in the initial position. The encoding is not bijective. 7 Methods and actions
  • a method or action is declared as follows:
  • ANNEX 6 Example of specification of a real protocol (the GSM protocol for mobility management between a mobile station (MS) and a network infrastructure) using the language according to Annex 5.
  • the RIL3 module includes detailed descriptions invoked below by identifiers starting with 'RIL3'. These descriptions are common with other protocols included in the radio layer three (RIL3 is an abbreviation of the English “Radio Interface Layer 3” or “Radio interface layer 3 in French”).
  • CM service type "CM Service Type”
  • LAI + TMSI [0..1]: "LAI + TMSI"
  • the syntax indicates only the type, while the embodiment described indicates the indexed set of which the object to be pointed out is a part. The set is left here in the comments.
  • CKSN [0..1
  • Ciphering Key Séquence Number "Ciphering Key Séquence Number"
  • GSM ciphering key [0..1]: Bitstring (64);
  • AUTN "Authentication Parameter AUTN”
  • bit ** ⁇ no string " ⁇
  • TMSI REALLOCATION COMPLETE "TMSI REALLOCATION COMPLETE"
  • CM SERVICE ABORT "CM SERVICE ABORT”
  • CM SERVICE REQUEST SUBSEQUENT "CM SERVICE REQUEST SUBSEQUENT”
  • the body of the command introduced by 'bind' is not included in the example. It should preferably be described in C ++. This applies to all commands (introduced by 'bind' or 'load') in the following sections.
  • ⁇ Reject cause ⁇ M-V-IE (Reject cause downlink, 1) "
  • PD and SAPI RIL3.
  • PD and SAPI RIL3.
  • CM SERVICE REQUEST SUBSEQUENT ⁇ abstract: "Mobile Identity Type”: "MM. Mobile Identity Type”; “IMSI” [0..1
  • “Mobile Identity Type” “IMSI”]: “IMSI”; “TMSI”: [0..1
  • “Mobile Identity Type” “TMSI / P-TMSI”]: “TMSI”; “CKSN availability”: “CKSN availability”; “CKSN” [0..1
  • Mobile Identity Type “MM.Mobile Identity Type”
  • ⁇ Mobile identity ⁇ M-LV-IE (Mobile identity, 2, 10) »Y 1.1.2.15 Acceptance of location update (or "LOCATION UPDATING ACCEPT")
  • Mobility management information (or "MM INFORMATION")
  • MM INFORMATION ⁇ abstract: Universal time [0..1]: MM. Universal Time “Local time zone” [0..1]: “Time zone”; "Network daylight Saving Time” [0..1]: “Daylight Saving Time”; "Full name for network” [0..1]: “network name”; "Short name for network” (0..1]: “network name” "LSA identity” [0..1]: “LSA identity”;
  • ⁇ MM INFORMATION> :: ⁇ Full name for network: ⁇ 0-TLV-IE (0100 0011, Network Name, 3, 255) » ⁇ Short name for network: ⁇ 0-TLV-IE (0100 0101, Network Name, 3, 255) " ⁇ Local time zone: O-TV-IE (0100 0110, Time Zone, 2)"
  • Local time zone returns 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, ⁇ no string>))
  • TMSI REALOCATION command (or "TMSI REALLOCATION COMMAND")
  • TMSI reallocation carried out or "TMSI COMPLETE REALLOCATION"
  • LA list 1.2 Lists of localization areas
  • CM Service Type CM Service Type
  • LSA Identifier 1.10 LSA Identifier (or “LSA Identifier”)

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)

Abstract

L'invention concerne une spécification et une mise en oeuvre d'un protocole de gestion de communication et de transmission entre au moins un émetteur et au moins un récepteur, comprenant les étapes suivantes : - détermination d'un contexte commun (2) ; - identification des messages de protocole (3) ; - spécification des représentations de données stockées et/ou transmises à partir de la description d'un contexte commun et de la description des messages ; - spécification d'instructions d'implémentation du protocole ; et - mise en oeuvre dudit protocole dans au moins un des émetteurs et au moins un des émetteurs.

Description

SYSTEME DE SPECIFICATION ET DE MISE EN OEUVRE DE PROTOCOLE DE COMMUNICATION ET DE TRANSMISSION
5 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.
10 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
15 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
20 é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
25 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
30 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). II 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. II 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.1 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 (de l'anglais « Uni versai Mobile Télécommunications System » ou « Système de télécommunication Mobile Universel » en français), 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é; et 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 semantiquement 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 preferentiellement 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) ; ces é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) ; et 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 à 6, 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. Les annexes 1, 4 et 5 décrivent 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.
Les annexes 3 et 6 illustrent 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 (respectivement 6) utilisent les éléments de description formelle de l'annexe 1 (respectivement 4) 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) ; cela 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 Cinfinity 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 '<' et '>', 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.1 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 nom 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 l 'é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 ; Les spécifications illustrées en regard de l'annexe 2 utilisent les éléments de description formelle de l'annexe 1 et permettent une génération automatique de code selon l'invention.
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é.
<type du contexte du protocole> ::= 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 :
<type de données gérées> ::= 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 <type du contexte du protocole> <protocol data unit> ::= CHOICE
<modifier : contenu du message modifier> ;
<contenu du message modifier> ::= on <données gérées> 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.
<type de données gérées> : ;— abstract entier 1 : integer , entier 2 : integer transfer
<entier 1 : bit(4)> la liaison avec l'abstrait se fait par l'identificateur
- l'encodage ι par défaut est binaire, poids fort en premier
<entier 2 : bit(6)> ;
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.
Figure imgf000034_0001
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
défailli 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 Séquence Number from RIL3 24.0084.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
La description des éléments du contexte est 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.
<MM context> : := 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..infinite] :
+ + 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 « do nlink 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
,dθ 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 {<skip indicator : 0000>
<protocol discriminator : 0101 >
0 0
{00 0010 <LQCATIQN UPDATING ACCEPT : LOCATION UPDATING ACCEPT> | 00 0100 <LOCATION UPDATING REJECT : LOCATION UPDATING REJECT> | 01 0001 <AUTHENTICATION REJECT : AUTHENTICATION REJECT> | 01 0010 <AUTHENTICATION REQUEST : AUTHENTICATION REQUEST> | 01 1010 <TMSI REALLOCATION COMMAND : TMSI REALLOCATION COMMAND> | 10 0001 <CM SERVICE ACCEPT : CM SERVICE ACCEPT> | 10 0010 <CM SERVICE REJECT : CM SERVICE REJECT> | 10 0101 <CM SERVICE PROMPT : CM SERVICE PROMPT> | 10 1000 <IDENTITY REQUEST : IDENTITY REQUEST> | 10 1001 <ABORT : ABORT>
| 11 0001 <MM STATUS : MM STATUS DOWNLINK> | 11 0010 <MM INFORMATION : MM INFORMATION^ ! <erroneous type : bit" = <no string»} <spurious extension : bit** = 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
{<skip indicator : 0000> <protocol discriminator : 0101 > bit*2
{01 1100 <AUTHENTICATION FAILURE : AUTHENTICATION FAILURE> | 01 0100 <AUTHENTICATION RESPONSE : AUTHENTICATION RESPONSE> | 01 1001 <IDENTITY RESPONSE : IDENTITY RESPONSE> | 01 1011 <TMSI REALLOCATION COMPLETE : TMSI REALLOCATION COMPLETE>
| 10 0011 <CM SERVICE ABORT : CM SERVICE ABORT>
| 10 0100 <CM SERVICE REQUEST : CM SERVICE REQUEST>
| 11 0001 <MM STATUS : MM STATUS UPLINK>} ! <erroneous type : bit** = <no string»} <spurious extension : bit** = null>
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 ::= <Reject cause : <M-V-IE (Reject cause downlink, 1)»
1.2.4 Echec d'authentication (ou "AUTHENTICATION 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 ::=
<Reject Cause <M-V-IE (Reject Cause uplink, 1)»
< Authentication Failure parameter : <0-TLV-IE (0010 0010, Authentication Failure parameter, 16)»
1.2.5 Rejet d'authentification (ou "AUTHENTICATION REJECT")
1.2.5.1 Description abstraite
action AUTHENTICATION REJECT ::= abstract set Location update state := Roaming not allowed
1.2.5.2 Syntaxe de transfert
transfer : null
1.2.6 Requête d'authentification (ou "AUTHENTICATION 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 ::=
<spare half octet : {bit*4 = 0000}>
<Ciphering key séquence number : <M-VD-IE (Ciphering key séquence number Downlink)»
<Authentication parameter RAND : <M-V-IE (Authentication parameter RAND, 16)»
<Authentication parameter AUTN : <0-TLV-IE (0010 0000, Authentication parameter AUTN, 18, 18)»
abstractAuthentication 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 ::=
<Authentication response parameter : <M-V-IE (Authentication Response Parameter, 4)»
<Authentication response extension : <0-TLV-IE (0010 0001 , Authentication Response Parameter extension, 3, 14»
function RES returns
<instance(Authentication response parameter. V. RES part 1)>
{<instance(Authentication response extension.V.RES part 2) action CM SERVICE ABORT ::= abstract on Connection parameters { set Service data := null
}
1.2.7.2 Syntaxe de transfert
Figure imgf000042_0001
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 ::= <PD and SAPI of CM : <M-V-IE (PD and SAPI, 1)»
1.2.11 Rejet de la demande de connexion pour service (ou "CM SERVICE REJECT")
1.2.11.1 Description abstraite
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 = "illégal 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 ::= <Reject cause : <M-V-IE (Reject cause downlink, 1)s
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 <CM SERVICE REQUEST> ::= <Ciphering key séquence number uplink : <M-VD-IE (Ciphering key séquence number Uplink)» <CM service type : <M-VD-IE (CM service type)»
<Mobile station classmark 2 : <M-LV-IE (Mobile station classmark 2, 4, 4)» <Mobile identity : <M-LV-IE (Mobile identity, 2, 9)» <Priority : <Q-TVD-IE (1000, Priority Level)» abstract.Mobile Identity type returns Mobile identity.V.Type of identity.abstract
abstract.lMSI returns Mobile identity.V.IMSI.abstract
abstract.TMSI returns Mobile identity .V.TMSI/P-TMSI.abstract
abstract.lMEl 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 ::= <spare half octet : {bit*4 = 0000}> <ldentity type : <M-VD-IE (Identity 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 ::= <Mobile identity : <M-LV-IE (Mobile identity, 2, 10)»
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 : <Location area identification : <M-V-IE (Location area identification, 5)» <Mobile identity : <0-TLV-IE (0001 0111 , Mobile identity, 3, 10)» <Follow on proceed : <0-T-IE (1010 0001)» <CTS permission : <0-T-IE (1010 0010)»
abstract.TMSI allocation status returns switch (Mobile identity = <null>, keep TMSI, Mobile identity .V.TMSI/P-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 ::= <Reject cause : <M-V-IE (Reject cause downlink, 1)
1.2.17 Information de gestion de mobilité (ou "MM 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 ::= <Full name for network : <0-TLV-IE (0100 0011 , Network Name, 3, 255)» <Short name for network : <0-TLV-IE (0100 0101 , Network Name, 3, 255)» <Local time zone : <0-TV-IE (0100 0110, Time Zone, 2)»
<Universal time and local time zone : <0-TV-IE (0100 0111 , Time Zone and Time, 8)» <LSA Identity : <0-TLV-IE (0100 1000, LSA Identifier, 2, 5)» <Network Daylight Saving Time : <0-TLV-IE (0100 1001 , Daylight Saving Time, 3, 3)»
function Local time zone returns 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, <no string>))
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 : abstract parameters Reject cause : MM. Reject cause end
1.2.18.2 Syntaxe de transfert
transfer ::= <Reject cause : <M-V-IE (Reject cause downlink, 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 ::= <Reject cause : <M-V-IE (Reject cause 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 ::=
<Location area identification : <M-V-IE (Location area identification 5)»
<Mobile identity : <M-LV-IE (Mobile identity, 2, 9)»
abstract.TMSI returns
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
<LA Iist> ::= abstract Location area description[0.. infinité] : + 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
Liste de réseaux (ou « PLMN list ») 3.1 Description abstraite
<PLMN list> ::= abstract
PLMN description[0.. infinité] :
+ 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
<Authentication Parameter AUTN> ::= abstract Séquence 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 ::=
<Sequence number xor Anonymity Key bit*48>
<Authentication management field : bit*16>
<Message authentication code : bit*64>
5 Type service CM (ou "CM Service Type")
5.1 Description abstraite
<CM Service Type> ::= abstract service type : Enumerated (MO call or packet est, emergency call, SMS, SS, VGC, VBS, LCS)
5.2 Syntaxe de transfert
Figure imgf000051_0001
<service type : {0001|0010|0100|10 bit(2)}>
6 Correction d'heure d'été (ou "Daylight Saving Time")
6.1 Description abstraite
<Daylight Saving Time> ::= abstract Daylight Saving Time adjustment : Enumerated (0, +1 hour, +2 hour)
6.2 Syntaxe de transfert
transfer ::= <spare bit> * 6 <Daylight Saving Time adjustment : {00 | 01 1 10 }>
7 IMEI
7.1 Description abstraite
<IMEI> ::= abstract Type Approval Code[6] : Integer (0..9) Final Assembly Code[2] : Integer (0..9) Sériai Number[6] : Integer (0..9)
7.2 Syntaxe de transfert
transfer ::= < digit one : digit> 1 bit*3 <pairs : <digit odd : digit> <digit even : digit»*7
function Digit(n) : integer returns iif(n=1 , integer(digit one), iif(n%2 = 0, integer(pairs[n/2] .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
<IMSI> ::= abstract MCC : CC NMSI[3..12] : Integer (0..9)
8.2 Syntaxe de transfert
transfer ::= {< digit one : digit> <oddeven : bit> bit*3 <pairs : «digit odd : digit> <digit even : digit»** <pairs : <spare bit>*4 <digit even : digit»*(1-integer(oddeven))} & octet*(4..8)
function Digit(n) : integer returns iif(n=1 , integer(digit one), 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 <LAI+TMSI> ::= abstract Location Area Identification : RIL3.Location Area Identification TMSI : Temporary Mobile Station Identity
10 Identifiant LSA (ou « LSA Identifier »)
10.1 Description abstraite
<LSA Identifier ::= 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 ::= {<LSA ID : <Localised service area identity : bit(23)> <LSA identifier scope : 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
<MCC> ::= abstract MCC value : Integer (0..999)
12 MNC 12.1 Description abstraite
<MNC> ::= abstract MNC value : Integer (0..999)
13 Nom du réseau (ou "Network Name")
13.1 Description abstraite
<Network Name> ::= abstract Coding scheme : Enumerated (cell broadcast default alphabet, UCS2) Add country's initiais : Boolean Text string : String
13.2 Syntaxe de transfert
transfer ::=
<ext : 1 >
<Coding scheme : {000|001}>
<Add country's initiais : bit>
<number of spare bits in last octet : bit(3)>
<Text string : - order of bits within text string ? <octet>**
<{0}*(number of spare bits in last octet)> <bit*(8 - number of spare bits in last octet)»
14 Identité de réseau (ou « PLMN Identity »)
14.1 Description abstraite
<PLMN ldentity> abstract MCC : MCC MNC : NC 15 Identité temporaire de station mobile (ou "Temporary Mobile Station Identity", TMSI).
15.1 Description abstraite
<Temporary Mobile Station ldentity> abstract temporary identity : Bit string (32)
15.2 Syntaxe de transfert
transfer ::= <temporary identity : bit*32>
16 Zone horaire ( ou « Time Zone »)
16.1 Description abstraite
<Time Zone> ::= abstract
Delta with GMT Integer (-99..99)
16.2 Syntaxe de transfert
transfer ::=
<sign : bit>
«digit 1 : bit(3)>
<digit 2 : bit(4)>
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)) ANNEXE 4. Module de description formelle de protocole selon une 0 variante
Un module de description formelle de protocole selon une variante de l'invention est décrit dans l'annexe 4 et comprend des éléments de description formelle spécifiant un protocole de communication. Le module contient trois types de description : des descriptions abstraites de types d'objet (correspondant à une syntaxe de type a) illustrée précédemment) ; des descriptions abstraites d'actions (messages par exemple) (correspondant à une syntaxe de type e) ; et des descriptions de transfert s'appliquant soit à des messages, soit à des objets en tant que partie de message (correspondant à une syntaxe de type b). A chaque type correspond un langage formel distinct. Le module est essentiellement organisé comme une liste de types d'objet.
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 descriptions 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
Un module est composé d'un en-tête, suivi d'une liste de description 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, le scope par défaut.
2 Descriptions de types d'objet
Une description comporte au minimum: - une description abstraite; zéro, une ou plusieurs descriptions de transfert; et zéro, une ou plusieurs descriptions de commandes. Une description de transfert décrit une structure de chaîne binaire qui peut représenter correctement la structure abstraite (voir le chapitre sur le sujet). Une action (message) associée 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 caractérisé par : un nom de composant, des informations de présence, et une description de type.
3.1 Informations de présence
Un composant peut être muni d'un index (tableau). Par défaut un composant n'a qu'une copie, un index permet d'avoir un nombre variable de copies, distinguées par une valeur d'index. Différents cas sont distinguables pour le nombre de copies. 3.1.1 Nombre fixe de copies
Le nombre de copies est spécifié par un entier. Le cas par défaut, une seule copie, est un cas particulier de nombre fixe de copies.
3.1.2 Nombre variable libre
Le nombre de copies, possible est alors typiquement indiqué par un intervalle d'entiers. Un cas particulier est un nombre quelconque de copies (intervalle de 0 à l'infini).
3.1.3 Nombre variable conditionnel
Le nombre de copies, acceptable dépend des valeurs d'autres éléments de la structure.
3.2 Description de type Cette description indique la structure du composant lui-même. Différentes descriptions sont possibles.
3.2.1 Composants élémentaires
Cela inclut au minimum: - un composant de type entier, au sens mathématique du terme; un composant de type énuméré : la liste des valeurs possibles est donnée explicitement, commune liste de symboles abstraits ; et un composant de type chaîne de bits.
3.2.2 Structure
Une structure se présente comme une liste de composants.
3.2.3 Union
Une union est une écriture abrégée pour un ensemble de composants de présence exclusive, i.e., au plus un des composants est présent dans une instance de l'union. 3.2.4 Référence
Une référence est une structure dont le contenu est défini par référence à un autre type d'objet.
3.2.5 Index
Un composant de type index indique une instance particulière parmi un ensemble d'objets de même type. La définition d'un composant de type index doit inclure la référence à un composant indexé d'un objet particulier. Cela peut être soit un composant inclus dans la structure dans laquelle est défini le composant de type index, soit un composant inclus dans un contexte, un objet unique commun à l'émetteur et le récepteur.
4 Description d'action.
Une description d'action comporte un nom de commande, une description abstraite d'action, et une ou plusieurs descriptions de transfert.
Une description de transfert décrit une structure de chaîne binaire qui peut représenter correctement l'action (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'actions élémentaires. (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 inclus dans la liste de paramètres : celle-ci ne contient que les paramètres qui ne peuvent pas être décrits plus précisément comme liés à une instruction élémentaire.)
La liste d'actions est constituée d'une ou plusieurs actions élémentaires. Chaque action élémentaire est constituée d'une éventuelle indication de condition, suivie d'une instruction parmi celles listées ci-après. 5.1 Indication de condition
Par défaut, une instruction doit être exécutée. Une indication de condition permet d'indiquer les conditions sous lesquelles l'instruction doit être exécutée.
Une première syntaxe permet de décrire une condition comme une expression booléenne construite à partir des paramètres.
Une syntaxe simplifiée permet de décrire à la fois l'existence d'un paramètre booléen spécifique et la condition d'exécution correspondant à ce paramètre (e.g., mot clé OPTIONAL).
5.2 Instruction de sélection
Une instruction de sélection permet d'indiquer une sous-partie de l'objet sur lequel porte une séquence d'actions. On utilise par la suite le terme de 'nœud courant' pour désigner la sous-partie sur laquelle porte une instruction. Par défaut d'instruction de sélection, le nœud courant est un objet du type auquel est associée l'action. L'objet spécifique est déterminé implicitement.
5.3 Instruction d'affectation (SET)
Une instruction d'affectation demande l'affectation d'une nouvelle valeur à un composant du nœud courant (dans son intégrité, ce qui peut être un sous- arbre assez important). II y a plusieurs manières dont la nouvelle valeur peut être indiquée : paramètre implicite de type implicite ou explicite, valeur explicite ou calculée.
5.3.1 Paramètre implicite de type implicite Dans ce cas, l'instruction ne contient rien de plus. Le message
(représentation de l'action) 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 inclut 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 inclut une expression dont le résultat doit être compatible avec le type de composant.
5.3.4 Valeur calculée
Dans ce cas, l'instruction inclut une liste d'instructions. Ces instructions itémisent les actions aboutissant à l'affectation du composant (typiquement sous- composant par sous-composant).
5.3.5 Vidage
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 d'ajout (ADD)
Une instruction d'ajout inclut un nom de composant indexé et une valeur.
Cette instruction demande l'ajout d'une nouvelle copie au composant, ayant la valeur indiquée (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 d'affectation.
5.5 Instruction d'envoi (SEND)
Une instruction d'envoi 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 de choix (CHOICE)
Une instruction de choix indique qu'une et une seule des actions est demandée pour chaque occurrence de l'action. 5.7 Instruction d'exécution d'une action (DO)
Une instruction d'exécution permet d'exécuter une action 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 des instructions spécifiques de préparation (PREPARE), d'acceptation de modifications associées à une préparation (COMMIT) et de refus de modifications (UNDO).
5.8.1 L'instruction de préparation (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 d'acceptation (COMMIT)
Cette instruction indique l'acceptation des modifications sujettes à une préparation (PREPARE) sur le nœud courant.
5.8.3 L'instruction de refus de modification (UNDO)
Cette instruction indique le refus des modifications sujettes à une préparation (PREPARE) sur le nœud courant. 6 Description de transfert
La description de transfert est à la base 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.1 peut être omis, et est alors le même que le nom 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 l'élément abstrait ainsi que défini dans la description abstraite. Plus généralement, les règles de correspondance entre une description de transfert et une description abstraite (de type d'objet ou de message) font l'objet du chapitre 9.
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ée 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. Dans ce cas le nom de la structure de transfert est obligatoire. 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 et « scopes »
Le nom complet d'une action ou d'un type d'objet est composé d'un descriptif ou « scope » et d'un nom dans ce scope. L'écriture complète est alors le scope suivi d'un point suivi du nom dans le scope. L' en-tête du module permet de donner un scope par défaut. On peut alors utiliser le nom local seul (non précédé du scope), le scope étant alors le scope par défaut.
Les noms du scope et de l'objet sont sensés être liés à la nature de l'objet. Un nom (d'objet, d'action ou de scope) 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 casse n'est pas prise en compte (ni la couleur ou autres attributs de même farine). En d'autres termes, dans la comparaison de chaînes de caractères, les attributs de formatage (majuscule/minuscule/autre, c'est-à-dire la casse en terme de typographie; italique/gras/autre, ...), ou de présentation (couleur, fonte, ...) n'interviennent pas dans la comparaison.
ANNEXE 5 Exemple de langage de description formelle.
1 Spécification d'un langage de description formelle
Cette annexe décrit un exemple de langage de description formelle selon l'annexe 4.
2 Classes d'objet La notion de classe d'objet est commune à de nombreux langages de programmation ou de spécification, sous des noms différents comme "classe" ou "type". En toute généralité, une classe est un ensemble d'objets, ceux-ci étant décrits à partir de caractéristiques communes à tous ces objets. Dans le cadre des protocoles, les caractéristiques partagées importantes sont les représentations (comment transmettre l'information permettant de désigner un objet particulier au sein de la classe), la sémantique externe (comment les objets se rattachent à une réalité extérieure), et les opérations (traitements informatiques pouvant impliquer les objets).
La description d'une classe inclut en premier lieu la spécification d'un ensemble minimal de caractéristiques permettant de distinguer tout objet de la classe. Selon le langage décrit ici, cela correspond à une description abstraite de la classe. Cette description se présente comme une liste d'attributs, chaque attribut étant lui-même un objet. La description comprend, en général, des indications informelles (i.e., non utilisables par les traitements, mais destinées aux humains), comme les noms des attributs ou des commentaires.
Des descriptions CSN.l permettent de spécifier des représentations par des chaînes binaires ou de caractères, ainsi que les règles implicites ou explicites permettant de mettre en relation une représentation et un élément de la classe selon la description abstraite. Finalement, des traitements spécifiques aux objets de la classe peuvent être inclus directement dans la description de la classe (méthodes). Le corps d'une méthode (la description détaillée du traitement) est décrit en C++ modifié, les modifications permettant le couplage avec la description abstraite. La description d'une classe comprend à la base: - un identificateur Ceci est une référence formelle non ambiguë à la classe, sous forme d'une chaîne de caractères; aucune ou une description abstraite ; aucune, une ou plusieurs représentations ; et aucune, une ou plusieurs méthodes. Des informations formelles supplémentaires peuvent être fournies. Ceci est visible dans la description détaillée de la syntaxe.
Par souci de modularité, la syntaxe du langage permet de dériver une classe d'une autre, ainsi que de décrire des classes paramétrées, une manière de décrire en une seule fois plusieurs classes dont les différences peuvent être capturées par un petit nombre de paramètres formels.
2.1 Syntaxe
La syntaxe est la suivante: classdecl ::=
"class" id '/" classdesc "}"
"class" id '." "public" idlist classdesc
Le deuxième cas permet de définir une classe à partir d'une ou plusieurs autres (dérivation de classe).
idlist ::= id l id "," idlist classdesc ::= aspectlist
aspectlist ::= aspect I aspectlist aspect
aspect ::= "abstract" ":" abstractdesc I "transfer" ":" transferdesc I "parameters" ":" abstractdesc "settings" ":" settingsdesc I "method" ":" methoddesc I "action" ":" methoddesc
Les chaînes d'identification acceptables sont décrites dans la section générale sur les identificateurs.
L'ordre d'apparition des entrées dans la liste n'a pas d'importance sauf mention contraire, et il peut y avoir plusieurs entrées de même nature. S'il y a plusieurs entrées donnant une description abstraite, la description abstraite de la classe est la concaténation, dans l'ordre d'apparition, des différentes listes d'attributs.
Le même principe s'applique aux paramètres.
2.2 Dérivation de classe
Une forme simple de modularité consiste à décrire une classe comme l'extension d'une ou plusieurs classes préalablement décrites. Ce qui est étendu est limité à la description abstraite et aux traitements.
Les représentations ne peuvent pas être étendues. La syntaxe permettant de décrire une classe par dérivation est la syntaxe normale à l'exception de l'en-tête qui mentionne alors la ou les classes dont la nouvelle est dérivée.
La notion de dérivation de classe n'est qu'un raccourci textuel. La classe ainsi décrite est celle correspondant à la description obtenue en incluant tous les aspects des classes parentes entre l'en-tête et la première entrée.
2.3 Classes paramétrées
Il arrive que plusieurs classes partagent la plupart de leurs caractéristiques, et que les différences peuvent être décrites par un nombre limité de paramètres de nature élémentaire, comme des booléens ou des entiers. Par exemple les listes d'entiers, finies ,ordonnées et de taille fixe peuvent être décrites comme une seule méta-classe ne différant que par un seul paramètre entier, la taille de la liste.
2.3.1 Description d'une méta-classe La liste des paramètres est introduite par le mot-clé « parameters », et suit la même syntaxe qu'une liste d'attributs.
Les paramètres peuvent (et doivent) apparaître dans le reste de la description de la classe, en toute place où une constante nommée peut apparaître.
2.3.2 Invocation d'une classe paramétrée Le nom d'une classe paramétrée ne peut être utilisé qu'accompagné d'un jeu de valeurs des paramètres. La syntaxe est décrite plus loin. 3 Description abstraite
La description d'une structure de donnée fait partie de nombreux langages de programmations, de programmes de gestion de base de données ou de spécifications de protocoles. Selon l'état de l'art, la description mélange des aspects abstraits (ce qui est spécifique à la structure indépendamment de toute représentation) et des aspects concrets (représentations, que ce soit pour la transmission ou la mémorisation).
Dans le langage de description formelle selon l'invention, ici décrit, les deux aspects sont gardés aussi séparés que possible, et des syntaxes distinctes sont utilisées pour les descriptions abstraites et les représentations. La syntaxe de description contient des adaptations aux problèmes spécifiques de la spécification des protocoles. Une structure abstraite est décrite de manière arborescente. A chaque noeud (qui correspond à un composant) non terminal, est associée une liste de descriptions de noeud. A un noeud terminal, ou feuille, est associé une classe élémentaire.
Chaque description de noeud comprend un identificateur, qui permet d'y référer. Cet identificateur est usuellement choisi de manière à donner aux lecteurs humains une idée de la sémantique réelle de l'attribut.
Il arrive que la liste contient des noeuds de même structure, et dont les identificateurs ne se distinguent que par un nombre (notion de tableau, de liste, de collection). Cela amène à l'idée de multiplicité, i.e., les valeurs possibles du nombre de noeuds dans un tel groupe.
Ainsi, une liste de noeuds est décrite comme une liste de triplets, un triplet comprenant: un identificateur; - la multiplicité; et - une description abstraite de structure.
La description abstraite peut être explicite, soit une référence à une structure nommée par ailleurs, soit une description de classe élémentaire.
La syntaxe permet d'ajouter à un noeud des informations supplémentaires, par exemple une valeur dite par défaut, dont l'application est décrite plus loin.
3.1 Syntaxe
Une description abstraite de structure est une séquence de description de noeuds:
Figure imgf000070_0001
Figure imgf000071_0001
complist ::= compdesc ";" I complist compdesc ";"
Chaque noeud est décrit par un triplet identificateur/multiplicité/description :
compdesc ::= id "[" multipliplicitydesc tt j (( " typeanddef 1 id ":" typedesc 1 choiceconstruct
La première syntaxe est la fondamentale, les autres pouvant s'y ramener par réécriture formelle.
Dans le second cas, la multiplicité est implicitement 1..1. La construction "choice" est une notation abrégée pour le cas d'une présence exclusive d'un noeud parmi une liste.
3.2 Multiplicité
La multiplicité d'un noeud est le nombre de noeuds dans une structure abstraite partageant les mêmes identificateur et structure, la distinction étant faite par un numéro d'ordre. Ce nombre est souvent dynamique, i.e., varie d'une instance à une autre: ce qui doit être décrit est donc l'ensemble des valeurs acceptables pour ce nombre. La multiplicité est donc un sous-ensemble des entiers positifs ou nuls.
L'ensemble acceptable peut être lui-même dynamique, dépendant de la valeur d'autres attributs (présence conditionnelle). Le langage permet une description en détail de ces cas. Un cas classique de présence conditionnelle est celui où l'ensemble total des nombres est 0..1.
Une syntaxe simplifiée permet de décrire de tels cas comme une expression booléenne. La syntaxe est la suivante:
multiplicitydesc ::= integerset I condset
Le premier cas correspond aux multiplicités libres, i.e., non conditionnelles; les deux autres à des présences conditionnelles. Pour la multiplicité libre, la syntaxe est la suivante:
integerset ::= integersetelem "," integerset
integersetelem expression I interval
interval ::= expression ".." expression expression ".." "infinité"
Les expressions « integersetelem » et « interval » doivent retourner une valeur entière positive ou nulle.
La deuxième expression « interval » doit retourner une valeur supérieure ou égale à celle de la première. Pour une multiplicité conditionnelle, la syntaxe est la suivante:
condset ::= integerset "I" expression expression
L'ensemble d'entiers doit inclure les multiplicités possibles. Cette information est redondante puisqu'elle peut se dériver de l'expression qui suit; sa présence obligatoire améliore la compréhension et simplifie la compilation. L'expression conddesc doit retourner soit un ensemble d'entiers, soit un entier, soit un booléen.
Par convention un entier seul est assimilé à l'ensemble réduit à sa seule valeur. Un booléen est traduit comme suit: la valeur "vrai" correspond à l'ensemble 1..1, la valeur fausse à l'ensemble 0..0.
3.2.1 La construction CHOICE
Cette syntaxe permet de simplifier l'écriture des cases où la présence de plusieurs noeuds est exclusive (au plus un d'entre eux peut être présent), et dépend dynamiquement de la valeur d'un noeud terminal, appelé le discriminant. Par exemple, la liste suivante: discri: 0..2; el l [0..1 l discri=0): typl ; el4 |O..l l discri=2|: typ4; el2 |0..1 I discri=l |: typ2; el3 L0..1 I discri=2J: typ3; peut s'écrire alternativement CHOICE discri :0..2 { 0 : { ell : typl;} 1 : { el2 : typ2;} 2 : { e!3 : typ3; el4 : typ4;}
};
La syntaxe est la suivante: choiceconstruct ::= "CHOICE" id ":" typedesc "{" branchlist "}"
branchlist ::= branchdesc ";" I branchlist ";" branchdesc ";"
branchdesc ::= expr ":" "{" complist "}"
Si la description d'un noeud dans une branche inclut une multiplicité explicite, la multiplicité effective est 0 si le discriminant n'a pas la valeur adéquate, et la multiplicité indiquée sinon.
Incompatibilité des identificateurs. L'équivalence est exacte. En particulier, ni la construction elle-même, ni une branche n'est une structure nommée; les listes de noeuds sont au même niveau hiérarchique, celui du point où apparaît le mot clé CHOICE. Par conséquence, il n'est pas autorisé d'avoir le même identificateur pour un noeud dans une branche et pour un noeud apparaissant au même niveau que le CHOICE. Par contre, il est autorisé que le même nom de noeud apparaisse dans deux ou plus branches d'un même CHOICE: cela correspond alors à un même et unique noeud, la structure abstraite devant être la même. La multiplicité peut être différente. 4 Description de structure de noeud 4.1 Descriptions de type.
Les différentes possibilités sont résumées par la syntaxe suivante:
typedesc ::= "{" complist "}" id I leafdesc I id "(" exprlist ")" "*" typedesc
La première possibilité est une description abstraite de syntaxe, parenthésée.
La seconde possibilité est une référence à une classe pré-définie, décrite par son identificateur. La troisième possibilité est une description de classe élémentaire, prédéfinie par le langage. Les syntaxes possibles et leurs significations sont décrites plus loin.
La quatrième possibilité est une référence à une classe paramétrée, constituée de l'identificateur et d'une liste de paramètres effectifs. La cinquième possibilité est une référence à une classe pré-définie, comme dans le premier cas.
L'étoile indique une différence de réalisation, précisément qu'il s'agit d'une instance partagée avec d'autres structures. (En terme pratique, cela indique une implementation par référence dynamique (pointeur) plutôt que par valeur explicite).
Les classes élémentaires acceptées comprennent les classes suivantes: énuméré strict; booléen; caractère; - cardinal fini (entier naturel positif ou nul); - dénombrable (entier étendu de la valeur infinie) ; différences (entier signé); indéfini ou "void".
Les syntaxes sont:
leafdesc ::= enumdesc I integerdesc chardesc I "boolean" I "void"
Chaque cas est décrit séparément ci-après. 4.1.1 Référence avec paramètres
La liste des expressions qui suit l'identificateur doit correspondre en nombre et en type à la liste des paramètres définis pour la classe.
4.1.2 Enuméré strict
Il s'agit d'un type fini (i.e., les valeurs possibles pour une instance de la classe sont en nombre fini). La liste des valeurs est donnée explicitement et complètement par une liste d'identificateurs.
Cette liste est abstraite, i.e., n'inclut aucune autre signification que le fait que deux identificateurs distincts correspondent à deux valeurs distinctes, ce qui guide l'implémentation du test à l'égalité de valeur de deux instances. La sémantique formelle est limitée à ce test. La sémantique externe est en général indiquée pour les humains par le choix des identificateurs.
La syntaxe stipule par nécessité un ordre, mais celui n'a pas de signification formelle.
La syntaxe est la suivante : enumdesc ::= "enumerated" "(" valuelist ")" I "enumerated" id "(" valuelist ")"
valuelist ::= value I valuelist "," value
value ::= id "=" number I id
L'identificateur qui peut apparaître entre enumerated et le caractère « ( » est une notation abrégée pour déclarer et invoquer la classe simultanément.
4.1.3 Cardinaux finis
Cela correspond au concept mathématique d'entiers positifs ou nuls, et a la sémantique formelle correspondante. La sémantique externe normal de cette classe est le décompte de choses, et l'usage de cette classe devrait en toute rigueur être limitée à de tels cas.
La sémantique formelle inclut, entre autres, les tests de comparaison et d'égalité, ainsi que les opérations arithmétiques usuelles.
Un cas évident d'usage légitime est le décompte du nombre de copies d'un noeud indexé. Ainsi, une multiplicité effective est un décompte, et une description de multiplicité est un sous-ensemble des entiers positifs ou nul.
La syntaxe est incluse dans la description des cardinaux dénombrables.
4.1.4 Différences
Il s'agit des entiers négatifs, positifs ou nul. La syntaxe est incluse dans la description du cas suivant.
4.1.5 Cardinaux dénombrables
Il s'agit de l'ensemble des entiers positifs ou nul, étendu d'une valeur spéciale, l'infini. Cette classe est très utile en pratique, par exemple pour une borne supérieure.
Les entiers, étendus ou non, sont rarement utilisés avec l'intervalle complet des valeurs. La syntaxe permet de décrire des classes dérivées, limitées à un sous- ensemble fini des valeurs.
La syntaxe est la suivante :
integerdesc ::=
"integer"
"integer" '/"" integerset
Le premier cas correspond aux entiers positifs ou nuls (cardinaux finis).
integerset ::= integersetelem "," integerset
integersetelem expression I interval
interval ::= expression ".." expression expression ".." "infinité"
Aucun élément de syntaxe permet d'étendre les entiers négatifs vers -infini
(-«)• Voici, quelques exemples dans le contexte de la norme UMTS :
- "TGPRC" : Integer (1..51 1, infinité); (Le nombre d'intervalles non alloués à la transmission (ou « transmission gap pattern » en anglais) parmi la séquence de d'intervalle de temps non alloués à la transmission (ou « Transmission Gap Pattern Séquence » en anglais).
- "TGSN" : Integer (0..14); (le numéro d'intervalle de temps élémentaire de la première période non allouée à la transmission (en anglais « slot number of the first transmission gap slot ») dans le TGCFN.
- "TGL1" : Integer (1..14); (la longueur de la période non allouée à la transmission dans le motif des creux de transmission exprimé en nombre d'intervalles de temps élémentaires. Dans ces exemples, les commentaires ont été gardés pour montrer qu'il s'agit bien de décompter une valeur.
4.1.6 Booléen
C'est un énuméré strict particulier, qui intervient comme résultat des opérations booléennes. Le langage de description formelle suit la convention la plus usuelle soit le couple (faux, vrai) ou (false, true), avec comme sémantique (formelle et réelle) que "true" est le résultat du test « 1 = 1 ». La classe boolean est donc prédéfinie comme : enumerated (false, true).
4.1.7 Type indéfini ou void
« Void » indique un type général, non défini.
5 Représentations
Une représentation capture tous les attributs d'un objet sous forme d'une chaîne de symboles binaires ou caractères.
Les représentations sont décrites en CSN.l. 6 Règles de correspondance
Les règles de correspondance permettent de mettre en relation une description abstraite et une représentation.
Dans le langage de description formelle, la correspondance est définie à partir de fonctions. Une fonction prend comme paramètre un objet et renvoie une valeur. Vu ainsi, une fonction a un nom et un type de résultat.
La description abstraite de la classe de l'objet permet de construire une liste de fonctions comme suit. A chaque noeud terminal correspond une liste de fonctions, la première renvoie un décompte, la multiplicité effective du noeud, c'est-à-dire le nombre de copies du noeud. Ensuite, pour chaque entier i (par convention positif ou nul, i.e. 0 est inclus), une fonction renvoie la valeur du ième éléments.
Le type renvoyé par ces dernières fonctions est celui associé au noeud. Pour les besoins de cette spécification, les notations suivantes sont introduites (l'usage formel des noms de fonction est développé au sein des adaptations du langage C++).
- "id .size()" est l'attribut renvoyant le nombre effectif de noeuds de id . "id" retourne la valeur du noeud dans le cas o u la multiplicité est implicitement 1..1. - "id [i\", o u i est un entier naturel retourne la valeur de la (i+l)ème copie. Quand un noeud n'est pas terminal, la notation avec point permet de construire récursivement toutes les fonctions. 6.1 Fonctions définies pour une représentation Les labels d'une description CSN.l déterminent une liste de fonctions, chacune renvoyant soit 'non instancié' soir une chaîne de symboles.
Pour chaque fonction définie à partir de la description abstraite, une représentation doit fournir une fonction correspondante. La correspondance est basée sur l'identité des noms, ainsi que, pour les fonctions correspondant aux noeuds terminaux, sur l'existence d'une règle de transcodage permettant de passer d'une chaîne de symboles à la valeur abstraite.
Par exception, l'existence d'une valeur par défaut permet d'accepter un renvoi 'non instancié' pour un noeud. (La valeur est alors la valeur par défaut.)
Le transcodage pour un noeud terminal est obtenu soit par application de règles par défaut, soit par la spécification dans la description de transfert d'une fonction de transcodage. 6.2 Règles par défaut
6.2.1 Enumérés
Si des valeurs numériques d'encodage sont spécifiées dans la description abstraite, le décodage est celui d'un entier comme spécifié dans la section suivante, suivi du transcodage dérivé de la description abstraite.
Si aucune valeur d'encodage n'est donnée, le décodage par défaut est le décodage d'un entier suivi par le transcodage appliquant à i la (i+l)ème valeur de la liste défini dans la description du type abstrait. 6.2.2 Entiers
Ces règles ne s'appliquent qu'aux cas où la description abstraite est celle d'un entier non étendu.
6.2.3 Symboles binaires
Si la borne inférieure de l'ensemble d'entiers est positive ou nulle, le décodage est celui de la numérotation binaire, le premier bit de la chaîne étant le bit de poids fort. Le décodage est complet (toute chaîne est acceptable), mais non bijectif (l'ajout de 0 à l'avant ne change pas la valeur). Typiquement, l'encodage cherchera à limiter au mieux le nombre de 0 à l'avant.
Si la borne inférieure est strictement négative, le décodage est celui du code par complément à 2, le bit de poids fort étant le premier. Le décodage est complet, mais non bijectif (l'ajout à l'avant d'un bit identique au premier bit ne change pas la valeur). 6.2.4 Caractères
Le décodage est celui de la numérotation positionnelle usuelle, le premier chiffre étant celui de poids fort. Un caractère de signe ("+" ou "-") peut apparaître optionnellement avant le premier chiffre. Le décodage n'est pas complet: tout caractère autre que les chiffres de 0 à 9 entraîne une erreur de décodage, ainsi que l'usage d'un caractère de signe ailleurs qu'en position initiale. L'encodage n'est pas bijectif. 7 Méthodes et actions
Cette aspect du langage n'est pas directement en rapport avec la spécification de protocole. La syntaxe est indiquée ici pour mémoire.
Dans le cadre de ce langage, une action est un cas particulier de méthode, et n'est citée ici que pour mémoire. 7.1 Syntaxe déclarative
Une méthode ou une action est déclarée comme suit:
methoddesc ::= "function" id "(" paramdesclist ")" ":" id "{" ccode "}"
ANNEXE 6 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) utilisant le langage selon l'annexe 5.
L'exemple présente dans cette annexe reprend l'exemple précédemment décrit en regard de l'annexe 3, selon le langage illustré dans l'annexe 5.
1 Contexte de protocole de gestion de mobilité (ou MM).
module MM #include "RIL3"
Le module RIL3, non illustré plus en détail, comprend des descriptions de détail invoquées dans la suite par des identificateurs commençant par 'RIL3'. Ces descriptions sont communes avec d'autres protocoles inclus dans la la couche trois radio (RIL3 est une abbreviation de l'anglais « Radio Interface Layer 3 » ou « Couche 3 d'interface radio » en français).
1.1 Contexte MM
1.1.1 Description abstraite
class "MM context" { abstract : "IMSI" [0..1] : "IMSI" ;
"Connect state" : Enumerated ("not connected", "connected") ; "Connection parameters" [0..1 | "Connect state" = "connected"] : { La partie décrivant une présence conditionnelle peut être ignorée. Elle permet d'éviter une perte d'information. "Serving cell" : * "cell" //-> UE context.Cell list "IMEI" [0..1] : "IMEI" ;
"Software Version Number [0..1 | présent ("IMEI")] : 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" [0..1 | iif("Location update state" = "updated", 1 , 0)] : {
"LAI+TMSI"[0..1] : "LAI+TMSI" ;
"Registered location area" : *"Location area" ;t/UE context.LA list
Selon une variante, la syntaxe n'indique que le type, alors que le mode de réalisation décrit indique l'ensemble indexé dont fait partie l'objet à pointer. L'ensemble est laissé ici en commentaire.
"Detach flag" : Boolean ;
"CTS permission" : Boolean ;
CKSN availability : Boolean ;
"CKSN" [0..1 | iif(CKSN availability, 1 , 0)] : RIL3."Ciphering Key Séquence Number" ;
"GSM ciphering key" [0..1] : Bitstring (64) ;
"UMTS security data" [0..1] : {
"AUTN" : "Authentication Parameter AUTN" ;
"UMTS ciphering key" [0..1] : Bitstring (128) ;
"UMTS integrity key" [0..1] : Bitstring (128) ;
} ;
1.1.2 Commandes
1.1.2.1 DL MM
1.1.2.1.1 Description abstraite
Selon le mode de réalisation décrit, on ne distingue pas les commandes (messages) des objets. Les descriptions qui suivent se présentent comme des classes. class "DL MM" : { abstract :
CHOICE "message type" : ( "LOCATION UPDATING ACCEPT", "LOCATION UPDATING REJECT", "AUTHENTICATION REJECT", "AUTHENTICATION REQUEST", "TMSI REALLOCATION COMMAND", "CM SERVICE ACCEPT", "CM SERVICE REJECT", "CM SERVICE PROMPT", "IDENTITY REQUEST", "ABORT ", "MM STATUS DOWNLINK", "MM INFORMATION")
{
"LOCATION UPDATING ACCEPT" : "LOCATION UPDATING ACCEPT" ; "LOCATION UPDATING REJECT" : "LOCATION UPDATING REJECT" ; "AUTHENTICATION REJECT" : "AUTHENTICATION REJECT" ; "AUTHENTICATION REQUEST" : "AUTHENTICATION REQUEST" ; "TMSI REALLOCATION COMMAND" : "TMSI REALLOCATION COMMAND" ; "CM SERVICE ACCEPT" : "CM SERVICE ACCEPT" ; "CM SERVICE REJECT" : "CM SERVICE REJECT" ; "CM SERVICE PROMPT" : "CM SERVICE PROMPT" ; "IDENTITY REQUEST" : "IDENTITY REQUEST" ; "ABORT " : "ABORT " ;
"MM STATUS DOWNLINK" : "MM STATUS DOWNLINK" ; "MM INFORMATION" : "MM INFORMATION" ; }
1.1.2.1.2 Syntaxe de transfert
Figure imgf000085_0001
! <erroneous type : bit** = <no string»}
< :spurious extension : bit** = null>
1.1.2.2 UL MM
1.1.2.2.1 Description abstraite
class "UL MM" { abstract :
CHOICE "message type" : ( "AUTHENTICATION FAILURE", "AUTHENTICATION RESPONSE" "IDENTITY RESPONSE", "TMSI REALLOCATION COMPLETE", "CM SERVICE ABORT", "CM SERVICE REQUEST SUBSEQUENT", "MM STATUS UPLINK") {
"AUTHENTICATION FAILURE" : "AUTHENTICATION FAILURE" ;
"AUTHENTICATION RESPONSE" : "AUTHENTICATION RESPONSE" ;
"IDENTITY RESPONSE" : "IDENTITY RESPONSE" ;
"TMSI REALLOCATION COMPLETE" : "TMSI REALLOCATION COMPLETE" ;
"CM SERVICE ABORT" : "CM SERVICE ABORT" ;
"CM SERVICE REQUEST SUBSEQUENT" : "CM SERVICE REQUEST SUBSEQUENT" ;
"MM STATUS UPLINK" : "MM STATUS UPLINK" ;
}
1.1.2.2.2 Syntaxe de transfert
transfer : <UM MM> ::= - flow of uplink MM messages once an RR connection is established {<skip indicator : 0000>
<protocol discriminator : 0101 > bit*2
{01 1100 <AUTHENTICATION FAILURE : AUTHENTICATION FAILURE>
| 01 0100 <AUTHENTICATION RESPONSE : AUTHENTICATION RESPONSE>
| 01 1001 <IDENTITY RESPONSE : IDENTITY RESPONSE>
| 01 1011 <TMSI REALLOCATION COMPLETE : TMSI REALLOCATION COMPLETE>
| 10 0011 <CM SERVICE ABORT : CM SERVICE ABORT>
| 10 0100 <CM SERVICE REQUEST : CM SERVICE REQUEST>
| 11 0001 <MM STATUS : MM STATUS UPLINK>} ! <erroneous type : bit** = <no string»} <spurious extension : bit** = null>
} ; 1.1.2.3 Abandon (ou « abort »)
1.1.2.3.1 Description abstraite
Figure imgf000087_0001
Le corps de la commande introduite par 'bind' n'est pas inclus dans l'exemple. Il est à décrire preferentiellement en C++. Ceci s'applique a toutes les commandes (introduites par 'bind' ou 'load') dans les sections qui suivent.
1.1.2.3.2 Syntaxe de transfert
transfer : <ABORT> ::=
<Reject cause : <M-V-IE (Reject cause downlink, 1)»
1.1.2.4 Echec d'authentification (ou « AUTHENTICATION FAILURE »)
1.1.2.4.1 Description abstraite
class "AUTHENTICATION FAILURE" { abstract :
"Reject cause" : "MM. Reject cause" ;
"Authentication Failure parameter"[0..1 | iif ("Reject cause.cause grouping" = "network related failure", "Reject cause. network-related failure cause" = "synch. failure", false)] : "MM.Authentication Failure parameter" bind <AUTHENTICATION FAILURE> { }
1.1.2.4.2 Syntaxe de transfert
transfer <AUTHENTICATION FAILURE> ::= <Reject Cause : <M-V-IE (Reject Cause uplink, 1)»
Figure imgf000088_0001
1.1.2.5 Rejet d'authentification (ou « AUTHENTICATION REJECT »)
1.1.2.5.1 Description abstraite
Figure imgf000088_0002
1.1.2.5.2 Syntaxe de transfert
transfer <AUTHENTICATION REJECT> null
1.1.2.6 Requête d'authentification (ou
« AUTHENTICATION REQUEST »)
1.1.2.6.1 Description abstraite
Figure imgf000088_0003
1.1.2.6.2 Syntaxe de transfert
transfer <AUTHENTICATION REQUEST> ::=
<spare half octet : {bit*4 = 0000}>
<Ciphering key séquence number : <M-VD-IE (Ciphering key séquence number Downlink)»
<Authentication parameter RAND : <M-V-IE (Authentication parameter RAND, 16)»
<Authentication parameter AUTN : <0-TLV-IE (00100000, Authentication parameter AUTN, 18, 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.1.2.7 Réponse d'authentification (ou
« AUTHENTICATION RESPONSE »)
1.1.2.7.1 Description abstraite
Figure imgf000089_0001
1.1.2.7.2 Syntaxe de transfert
Figure imgf000089_0002
1.1.2.8 Abandon de connexion pour service (ou « CM
SERVICE ABORT »)
1.1.2.8.1 Description abstraite
class "CM SERVICE ABORT" { abstract :
bind <CM SERVICE ABORT> { }
1.1.2.8.2 Syntaxe de transfert
transfer <CM SERVICE ABORT> null 1.1.2.9 Acceptation de la demande de connexion pour service
(ou « CM SERVICE ACCEPT »)
1.1.2.9.1 Description abstraite
Figure imgf000090_0001
1.1.2.9.2 Syntaxe de transfert
transfer <CM SERVICE ACCEPT> null
1.1.2.10 Affichage du service de gestion de connexion (ou « CM SERVICE PROMPT »)
1.1.2.10.1 Description abstraite
class "CM SERVICE PROMPT" { abstract :
"PD and SAPI" : RIL3."PD and SAPI" ;
1.1.2.10.2 Syntaxe de transfert
Figure imgf000090_0002
1.1.2.11 Rejet de la demande de connexion pour service (ou « CM SERVICE REJECT »)
1.1.2.11.1 Description abstraite
Figure imgf000090_0003
1.1.2.11.2 Syntaxe de transfert
transfer <CM SERVICE REJECT> ::= <Reject cause : <M-V-IE (Reject cause downlink, 1)»
1.1.2.12 Demande de conexion additionnelle pour service (ou « CM SERVICE REQUEST SUBSEQUENT »)
1.1.2.12.1 Description abstraite
class "CM SERVICE REQUEST SUBSEQUENT" { abstract : "Mobile Identity Type" : "MM. Mobile Identity Type" ; "IMSI" [0..1 | "Mobile Identity Type" = "IMSI"] : "IMSI" ; "TMSI" : [0..1 | "Mobile Identity Type" = "TMSI/P-TMSI"] : "TMSI" ; "CKSN availability" : "CKSN availability" ; "CKSN" [0..1 | "CKSN availability"] : CKSN ; "Mobile Station Classmark 1" : "Mobile Station Classmark 1" ; "Mobile Station Classmark 2 delta" : "Mobile Station Classmark 2 delta" "CM Service Type" : "CM Service Type" ; "Priority" : "Priority" ;
1.1.2.12.2 Syntaxe de transfert
transfer : <CM SERVICE REQUEST> ::= <Ciphering key séquence number uplink : <M-VD-IE (Ciphering key séquence number Uplink)» <CM service type : <M-VD-IE (CM service type)» <Mobile station classmark 2 : <M-LV-IE (Mobile station classmark 2, 4, 4)» <Mobile identity : <M-LV-IE (Mobile identity, 2, 9)» <Priority : <0-TVD-IE (1000, Priority Level)»
abstract.Mobile Identity type returns
Mobile identity.V.Type of identity.abstract
abstract.lMSI returns Mobile identity.V.IMSI.abstract
abstract.TMSI returns Mobile identity.V.TMSI/P-TMSI.abstract abstract.lMEl returns Mobile identity.V.IMEl
Y
1.1.2.13 Demande d'identité GSM (ou « IDENTITY REQUEST »)
1.1.2.13.1 Description abstraite
class "IDENTITY REQUEST" { abstract :
"Mobile Identity Type" : "MM.Mobile Identity Type"
1.1.2.13.2 Syntaxe de transfert
transfer : <IDENTITY REQUEST> ::= <spare half octet : {bit*4 = 0000}> <ldentity type : <M-VD-IE (Identity type)»
};
1.1.2.14 Réponse d'identité (ou « IDENTITY RESPONSE »)
1.1.2.14.1 Description abstraite
class "IDENTITY RESPONSE" { abstract :
CHOICE "Mobile Identity Type" : "MM.Mobile Identity Type" { "IMSI" : {"IMSI": "IMSI"} ; "IMEI" : {"IMEI" : "IMEI"} ; "IMEISV" : { "IMEI" : "IMEI" ; "Software Version Number" : Integer (0..99) ;
}} ;
1.1.2.14.2 Syntaxe de transfert
transfer : <IDENTITY RESPONSE> ::=
<Mobile identity : <M-LV-IE (Mobile identity, 2, 10)» Y 1.1.2.15 Acceptation de mise à jour de localisation (ou « LOCATION UPDATING ACCEPT »)
1.1.2.15.1 Description abstraite
class "LOCATION UPDATING ACCEPT" { abstract : "TMSI allocation status" : Enumerated ("new TMSI", "keep TMSI", "erase TMSI") "Follow on proceed" : Boolean ; set Registered location area [0..1 | "TMSI allocation status" = "new TMSI"] { "Location Area Identification" : "Location Area Identification" ; "TMSI" : "TMSI" ;
} :
"CTS permission" : Boolean ;
bind {
}
1.1.2.15.2 Syntaxe de transfert
transfer : <LOCATION UPDATING ACCEPT> ::= •«Location area identification : <M-V-IE (Location area identification, 5)» <Mobile identity : O-TLV-IE (0001 0111 , Mobile identity, 3, 10)» <Follow on proceed : <0-T-IE (1010 0001)» <CTS permission : <0-T-IE (1010 0010)»
abstract.TMSI allocation status returns switch (Mobile identity = <null>, keep TMSI, Mobile identity .V.TMSI/P-TMSI = 1**, erase TMSI, Mobile identity .V.TMSI/P-TMSI = bit**, new TMSI)
abstract.TMSI returns Mobile identity.V.TMSI/P-TMSI.abstract
};
1.1.2.16 Rejet d'une mise à jour de localisation ( ou « LOCATION UPDATING REJECT »)
1.1.2.16.1 Description abstraite
class "LOCATION UPDATING REJECT" { abstract : "Reject cause" : "MM. Reject cause" ;
bind <LOCATION UPDATING REQUEST> {
// set Location update state := roaming not allowed
}
1.1.2.16.2 Syntaxe de transfert
transfer : {LOACTION UPDATING REQUEST> ::= <Reject cause : <M-V-IE (Reject cause downlink, 1)»
1.1.2.17 Information de gestion de mobilité (ou « MM INFORMATION »)
1.1.2.17.1 Description abstraite
class "MM INFORMATION" { abstract : Universal time[0..1] : MM. Universal Time "Local time zone"[0..1] : "Time zone" ; "Network daylight Saving Time"[0..1] : "Daylight Saving Time" ; "Full name for network"[0..1] : "network name" ; "Short name for network"(0..1] : "network name" "LSA identity"[0..1] : "LSA identity" ;
1.1.2.17.2 Syntaxe de transfert
transfer : <MM INFORMATION> ::= <Full name for network : <0-TLV-IE (0100 0011 , Network Name, 3, 255)» <Short name for network : <0-TLV-IE (0100 0101 , Network Name, 3, 255)» <Local time zone : O-TV-IE (0100 0110, Time Zone, 2)»
<Universal time and local time zone : <0-TV-IE (0100 0111 , Time Zone and Time, 8)» <LSA Identity : <0-TLV-IE (0100 1000, LSA Identifier, 2, 5)» <Network Daylight Saving Time : <0-TLV-IE (0100 1001 , Daylight Saving Time, 3, 3)»
function Local time zone returns 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, <no string>))
Figure imgf000095_0001
1.1.2.18 Statut, dans le sens descendant, de la gestion de mobilité (ou « MM STATUS DOWNLINK »)
1.1.2.18.1 Description abstraite class "MM STATUS DOWNLINK" { abstract : "Reject cause" : "MM. Reject cause" ;
1.1.2.18.2 Syntaxe de transfert
transfer <MM STATUS DOWNLINK> ::= <Reject cause : <M-V-IE (Reject cause downlink, 1)»
};
1.1.2.19 Statut, dans le sens montant, de la gestion de mobilité (ou « MM STATUS UPLINK »)
1.1.2.19.1 Description abstraite
class "MM STATUS UPLINK" { abstract : "Reject cause" : "MM. Reject cause"
1.1.2.19.2 Syntaxe de transfert
transfer : <MS STATUS UPLINK> ::= <Reject cause : <M-V-IE (Reject cause uplink, 1 )»
};
1.1.2.20 Commande de réallocation TMSI (ou « TMSI REALLOCATION COMMAND »)
1.1.2.20.1 Description abstraite
class "TMSI REALLOCATION COMMAND" { abstract : "LAI+TMSI" : "LAI+TMSI"
1.1.2.20.2 Syntaxe de transfert
Figure imgf000096_0001
1.1.2.21 Réallocation TMSI effectuée (ou « TMSI REALLOCATION COMPLETE »)
1.1.2.21.1 Description abstraite
Figure imgf000096_0002
1.1.2.21.2 Syntaxe de transfert
transfer : <TMSI REALLOCATION COMPLETE> null Y
1.2 Listes des zones de localisation (ou « LA list »)
1.2.1 Description abstraite
Figure imgf000096_0003
1.3 Liste de réseaux (ou « PLMN list »)
1.3.1 Description abstraite
class "PLMN 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" ; }
1.4 Paramètres d'authentification AUTH (ou « Authentication Parameter AUTN »)
1.4.1 Description abstraite
class "Authentication Parameter AUTN" { abstract : "Séquence number xor Anonymity Key" : Bitstring (48) "Authentication management field" : Bitstring (16) ; "Message authentication code" : Bitstring (64) ;
1.4.2 Syntaxe de transfert
transfer : < Authentication Parameter AUTN> ::= <Sequence number xor Anonymity Key : bit*48= <Authentication management field : bit*16> <Message authentication code : bit*64> };
1.5 Type de service CM (ou « CM Service Type »)
1.5.1 Description abstraite
class "CM Service Type" { abstract :
"service type" : Enumerated ("MO call or packet est", "emergency call", "SMS" "SS", "VGC", "VBS", "LCS") 1.5.2 Syntaxe de transfert
Figure imgf000098_0001
1.6 Correction d'heure d'été (ou « Daylight Saving Time »)
1.6.1 Description abstraite
class "Daylight Saving Time" { abstract : "Daylight Saving Time adjustment" : Enumerated (0, "+1 hour", "+2 hour")
1.6.2 Syntaxe de transfert
transfer : <Daylight Saving Time> ::= <spare bit> * 6
<Daylight Saving Time adjustment : {00 | 01 | 10 }> Y
1.7 IMEI
1.7.1 Description abstraite
class "IMEI" { abstract : "Type Approval Code"[6] : Integer (0..9) ; "Final Assembly Code"[2] : Integer (0..9) "Sériai Number"[6] : Integer (0..9) ;
1.7.2 Syntaxe de transfert
transfer : <IMEI> ::= < digit one : digit> 1 bit*3 <pairs : «digit odd : digit> <digit even : digit»*7
function Digit(n) : integer returns iif(n=1 , integer(digit one), iif(n%2 = 0, integer(pairs[n/2].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)
}; 1.8 IMSI
1.8.1 Description abstraite
class "IMS " { abstract :
"MCC" "MCC
"NMSI" 3..12] : Integer (0..9) ;
1.8.2 Syntaxe de transfert
transfer : <IMSI> ::=
{< digit one : digit> <oddeven : bit> bit*3 <pairs : <digit odd : digit> «digit even : digit»** <pairs : <spare bit>*4 <digit even : digit»*(1-integer(oddeven))}
& octet*(4..8)
function Digit(n) : integer returns iif(n=1 , integer(digit one), 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) 1.9 LAI et TMSI
1.9.1 Description abstraite
class "LAI+TMSI" { abstract "Location Area Identification" : RIL3."Location Area Identification" ; "TMSI" : "Temporary Mobile Station Identity" ;
1.10 Identifiant LSA (ou « LSA Identifier »)
1.10.1 Description abstraite
class "LSA Identifier" { abstract :
"LSA available" : Boolean ;
"LSA ID"[0..1 | "LSA available"] : {
"LSA identifier scope" : Enumerated ("PLMN significant", "universal") ;
"Localised service area identity" Bitstring (23) ;
1.10.2 Syntaxe de transfert
transfer : <LSA ldentifier> ::= {<LSA ID : <Localised service area identity : bit(23)> <LSA identifier scope : bit> | null }
abstract.LSA available returns exist (LSA ID)
abstract.LSA ID.LSA identifier scope returns iif (LSA identifier scope = 0, PLMN significant, universal)
};
1.11 MCC
1.11.1 Description abstraite
class "MCC" { abstract : "MCC value" : Integer (0..999) };
1.12 MNC
1.12.1 Description abstraite
class "MNC" { abstract : "MNC value" : Integer (0..999)
1.13 Network Name
1.13.1 Description abstraite
class "Network Name" { abstract :
"Coding scheme" : Enumerated ("cell broadcast default alphabet", "UCS2")
"Add country's initiais" : Boolean ; "Text string" : String ;
1.13.2 Syntaxe de transfert
transfer : <Network Name> ::=
<ext : 1 >
<Coding scheme : {000|001}>
<Add country's initiais : bit>
<number of spare bits in last octet : bit(3)>
<Text string : - order of bits within text string ? <octet>**
<{0}*(number of spare bits in last octet)> <bit*(8 - number of spare bits in last octet)»
}; 1.14 Identité de réseau (ou « PLMN Identity »)
1.14.1 Description abstraite
class "PLMN Identity" { abstract :
"MCC" "MCC" ;
"MNC" "MNC" ; };
1.15 Identité temporaire de station mobile (ou « Temporary Mobile Station Identity »)
1.15.1 Description abstraite
class "Temporary Mobile Station Identity" { abstract : "temporary identity" : Bitstring (32) ;
1.15.2 Syntaxe de transfert
transfer : <Temporary Mobile Station ldentity> : <temporary identity : bit*32>
1.16 Zone horaire (ou « Time Zone »)
1.16.1 Description abstraite
class "Time Zone" { abstract : "Delta with GMT" : Integer (-9Θ..99)
1.16.2 Syntaxe de transfert
transfer : <Time Zone> ::=
<sign : bit>
«digit 1 : bit(3)>
«digit 2 : bit(4)>
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))
};

Claims

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é; et - 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 11 et 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.
PCT/FR2004/001310 2003-05-26 2004-05-26 Systeme de specification et de mise en oeuvre de protocole de communication et de transmission, Ceased WO2004107714A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
FR0306368A FR2855699B1 (fr) 2003-05-26 2003-05-26 Systeme de specification et de mise en oeuvre de protocole de communication et de transmission, procede, specification, dispositif de communication et programmes d'ordinateur correspondant
FR03.06368 2003-05-26
FR0402878A FR2857192B1 (fr) 2003-05-26 2004-03-19 Systeme de specification et de mise en oeuvre de protocole de communication et de transmission, procede, specification, dispositif de communication et programmes d'ordinateur correspondant
FR04.02878 2004-03-19

Publications (1)

Publication Number Publication Date
WO2004107714A1 true WO2004107714A1 (fr) 2004-12-09

Family

ID=33492215

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2004/001310 Ceased WO2004107714A1 (fr) 2003-05-26 2004-05-26 Systeme de specification et de mise en oeuvre de protocole de communication et de transmission,

Country Status (2)

Country Link
FR (1) FR2857192B1 (fr)
WO (1) WO2004107714A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5930264A (en) * 1997-02-06 1999-07-27 Telefonaktiebolaget L M Ericsson (Publ) Inter-node signaling for protocol initialization within a communications network
US20020004830A1 (en) * 2000-05-02 2002-01-10 Richard Hyatt Method and system for providing engineering analysis tools in a distributed environment

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU3223300A (en) * 1999-02-08 2000-08-25 Sabre Inc. Apparatus and method for data conversion in a computer network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5930264A (en) * 1997-02-06 1999-07-27 Telefonaktiebolaget L M Ericsson (Publ) Inter-node signaling for protocol initialization within a communications network
US20020004830A1 (en) * 2000-05-02 2002-01-10 Richard Hyatt Method and system for providing engineering analysis tools in a distributed environment

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KONING J-L: "Algorithms for translating interaction protocols into a formal description", SYSTEMS, MAN, AND CYBERNETICS, 1999. IEEE SMC '99 CONFERENCE PROCEEDINGS. 1999 IEEE INTERNATIONAL CONFERENCE ON TOKYO, JAPAN 12-15 OCT. 1999, PISCATAWAY, NJ, USA,IEEE, US, 12 October 1999 (1999-10-12), pages 810 - 815, XP010363604, ISBN: 0-7803-5731-0 *

Also Published As

Publication number Publication date
FR2857192A1 (fr) 2005-01-07
FR2857192B1 (fr) 2006-01-27

Similar Documents

Publication Publication Date Title
WO2024178302A1 (fr) Système et procédé de réduction des menaces
EP3008872B1 (fr) Procédé d&#39;authentification d&#39;un terminal par une passerelle d&#39;un réseau interne protégé par une entité de sécurisation des accès
WO2021195618A1 (fr) Système et procédé d&#39;intégration et de validation
EP1387261A1 (fr) Logiciel de generation de code d&#39;application informatique et langage de description de logiciel
CN118535135A (zh) 基于云服务的代码生成模型的训练方法和代码生成方法
US11928605B2 (en) Techniques for cyber-attack event log fabrication
EP1958089B1 (fr) Api a modele d&#39;objet de document pour donnees mime
CN110032872A (zh) 一种业务逻辑漏洞检测方法及装置
Rautenstrauch et al. Who's Breaking the Rules? Studying Conformance to the HTTP Specifications and its Security Impact
US20120054299A1 (en) System for and method of verifying packages
EP2591556A1 (fr) Procédé de détermination d&#39;au moins un paramètre d&#39;un code correcteur d&#39;erreurs mis en uvre en émission, dispositif et programme d&#39;ordinateur correspondants
FR2952258A1 (fr) Procede et dispositif pour acceder a des fonctions de maintenance d&#39;un aeronef a partir d&#39;un terminal mobile de maintenance
EP2750354B1 (fr) Procédé de définition d&#39;un module de filtrage, module de filtrage associé
US11573808B2 (en) Methods of providing an integrated interface that includes a virtual mobile device
WO2004107714A1 (fr) Systeme de specification et de mise en oeuvre de protocole de communication et de transmission,
US12505031B2 (en) Systems and methods for graph management
CN117527310A (zh) 一种面向tls协议实现的逻辑漏洞检测方法及系统
CN115114052B (zh) 一种智能提供数据库微服务的方法和装置
FR2855699A1 (fr) Systeme de specification et de mise en oeuvre de protocole de communication et de transmission, procede, specification, dispositif de communication et programmes d&#39;ordinateur correspondant
FR2793906A1 (fr) Systeme et procede de gestion d&#39;attributs dans un environnement oriente objet
CN117201601A (zh) 物联网设备接入方法、装置、设备及存储介质
CN113313584A (zh) 业务处理方法及处理装置
EP2863321A1 (fr) Procédé et système de génération automatique de documents à partir d&#39;un index
US20250209177A1 (en) Scripting transform loader
EP2284751B1 (fr) Procédé de traçabilité et d&#39;imputabilité dynamiques des échanges dans un environnement ouvert de type internet

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase