FR2857192A1 - SYSTEM FOR SPECIFYING AND IMPLEMENTING COMMUNICATION AND TRANSMISSION PROTOCOL, METHOD, SPECIFICATION, COMMUNICATION DEVICE AND CORRESPONDING COMPUTER PROGRAMS - Google Patents

Abstract

The invention relates to a specification and an implementation of a communication and transmission management protocol between at least one transmitter and at least one receiver, comprising the following steps: - determination of a common context (2); identification of the protocol messages (3); - specification of the representations of data stored and / or transmitted from the description of a common context and the description of the messages; - specification of protocol implementation instructions; and implementation of said protocol in at least one of the transmitters and at least one of the transmitters.

Description

<Desc / Clms Page number 1>

 System for specifying and implementing communication and transmission protocol, method, specification, communication device and corresponding computer programs.

 The present invention relates to the field of communications protocols.

 More specifically, 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 comprises a specification phase, a software development phase in the remote entities that communicate by applying these protocols, often followed by a test phase.

 In many cases, communicating entities are not developed by the same teams or companies (for example fixed infrastructure and mobiles in the case of a mobile telecommunications network). In these cases, the specifications are not usually written by the development teams, but by groups made up of people from different companies, typically those who will develop the equipment, or buy them to put them in # out.

 In practice, there is a significant gap between the methods and approaches of the specification groups, compared with those of the development teams. At worst, the specification of a protocol is written in natural language, is not complete, contains inconsistencies, and requires to be understood many scattered information in other documents.

 On the other hand, once a software is realized, it is a formal, complete and logically coherent instance of the protocol specification, and it can be erroneous in the sense that it does not allow interworking as provided by

<Desc / Clms Page number 2>

 the specification group with a remote entity pair developed independently.

 This discrepancy, besides the risks of erroneous realization, problems of multiplicity of representation and problems of evolution that it entails, is the source of an important work of analysis and exegesis, and more generally of efforts of understanding on the part of the development teams.

 This reconstruction work does not appear intrinsically necessary, and is duplicated by each development team. This is a source of unnecessary costs, and inefficiency of the chain as a whole.

 Another source of additional costs is that protocol specifications for a single object (for example, a GSM mobile phone) are not written by a single group. The variety of editorial approaches followed by these different groups greatly limits the possibility of unifying the development approach. This is a source of inefficiency for the development itself, tests, as well as the amount of code generated (it is difficult to share what inherently can be, simply because it is specified differently).

 It therefore seems useful to study how to reduce this intermediate work by introducing formal and unifying methods. Such methods can initially be applied to a development team and then, as far as possible, to the specifications themselves.

 In the state of the art, there are known published methods along these lines, in particular: ASN.l, XML, CSN.l and SDT. These different methods and the associated formal languages do not all correspond to the same parts of the specification of a protocol. It is therefore necessary to go into a little more detail about what a protocol and its specification.

 A protocol is essentially a language that allows two separate and remote machines to exchange information by ultimately using a transmission medium. In practice this language is organized in different parts more or less independent, each being considered itself as a protocol.

The protocols are then arranged in layers, each protocol with the exception of

<Desc / Clms Page number 3>

   lower using not directly the transmission medium but a transmission service provided by the protocol directly lower.

 Like human languages, protocols can be analyzed from the point of view of vocabulary or lexicon (list of types of messages, lists of parts of messages), of encoding (phonemes and morphemes for human languages, forms of wave and digital encoding for protocols), syntax (grammar rules), semantics (meaning of messages and message parts), rules of procedure (rules governing dialogues between dialoguing entities; this part that evokes the word protocol), and finally praxis (effect of the messages).

 Some of these aspects are well defined, and appear in the clear in the majority of the specifications (the lexicon, the encoding, the rules of procedures). Others are often badly perceived and, therefore, specified without any method (semantics and praxis).

 In a majority of specifications, two distinct parts can be identified: the lexicon and the encoding on the one hand, and the specification of the procedures. The lexicon appears in the form of lists of messages and parts of messages (information element), each with the associated grammar and encoding. The rules of procedure are specified as a list of more or less independent procedures, described as the actions caused by the receipt of messages from the peer entity or commands from other software in the same machine. This most often covers both the rules of procedure (actions and reactions visible, and therefore testable, in the flow of information circulating between the even entities) than 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.

 The formal methods that can be found in the publications focus on the formalization of the encoding and the syntax on the one hand (ASN.l,

<Desc / Clms Page number 4>

 CSN.l, XML), and the procedures seen as action time sequences (SDT, SDL).

 ASN.l (Abstract Notation 1) is a formal language specified by ISO (series X. 680 and X. 690) for describing data structures by distinguishing an abstract description (ie, which can be applied to different methods of encoding) and methods of encoding these data structures. It is commonly applied to the description of the message structure of a protocol, each message being considered as a data structure. Because formal, a specification written in ASN.l can be automatically translated into a software of encoding and decoding of messages.

 ASN.1 has recently been extended to allow the formal description of encoding methods, with the aim of applying ASN.l to specifications either unwritten originally in ASN.l, or for which the general encoding methods specified by the ISO are unsatisfactory for one reason or another.

 XML is a formal language whose goals 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 the automatic generation of encoding and decoding software.

 CSN.l is a formal language developed by the inventor, and used in some ETSI protocol specifications. This language makes it possible to describe the grammar of bit strings (and is much more similar to formal grammar description languages such as BNF, than data description languages), and can be used to describe the structure as a string. bits of messages from the majority of telecommunication protocols.

It differs for these purposes in two ways from ASN.l or XML: it can be used retrospectively to describe messages whose encoding is described in some way in a specification, and it does not attempt to address even partially the semantics linked to the structure. As in the case of previous languages, a specification in CSN.l can be used for generation

<Desc / Clms Page number 5>

 automatic encoding and decoding of messages. Compared to ASN.1 and XML, CSN.1 has the advantage of being applicable to any protocol, and thus of allowing a unified realization of the corresponding part of the realization of the protocol. In return, CSN.l does not describe the messages as data structures, so this link can not be generated automatically.

 In a completely different domain, SDT or SDL (as well as other related methods) address the formalization of the procedures seen as temporal 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, storing data, transitioning states , ...). These methods focus mainly on the view of the entities of the protocols as automatons of states, a state being a summary of the aspects of the context (stored data) of each of the paired entities which intervene in the choice of the action to be undertaken following each event. Thus, these methods make it possible to formalize mainly the rules of procedure and, to a certain extent, the praxis, and finally, indirectly, the semantics of the messages.

 A disadvantage of this prior art technique is that the methods published so far suffer from numerous limitations. Firstly, they allow only a very partial formalization of protocol specifications, mainly the encoding of messages and parts of messages.

 Another very important limitation, particularly visible in the case of ASN.l, is that they generally do not allow to integrate in the same approach protocols that are not initially specified according to said method. CSN.1 is an exception here.

 As for SDL and related, these methods only capture the notion of automaton; however, recent protocols, such as those included in the specifications of UMTS (Universal Mobile Telecommunications System or Universal Mobile Telecommunications System in French),

<Desc / Clms Page number 6>

 are very simple automata, the complexity being rather in data structures and encoding algorithms.

 Another disadvantage of state-of-the-art formal-form language specifications is that they generally lead to inefficient signal forms.

 The invention in its various aspects is intended to overcome these disadvantages of the prior art.

 More specifically, an object of the invention is to optimize the communication protocol specification and its concrete implementation.

 Another object of the invention is to enable a rapid and efficient development of communication protocol stacks, particularly 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 the 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 the human errors that can lead to operation of the transmitter and / or the non-optimal receiver.

 For this purpose, the invention proposes a system for specifying and implementing a communication management and transmission 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 for identifying protocol messages that can be exchanged between the transmitter (s) and the receiver (s), the identification being independent of the representation (s) used for the messages;

<Desc / Clms Page number 7>

 means for defining representations of data stored and / or transmitted by the transmitter (s) and / or the receiver (s) from the determination of a common context and the identification of the messages, the definition of representations allowing to determining implementation instructions for 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 or transmitters are able to communicate with the receiver or receivers.

 Note that a communication management protocol is understood here in the strict sense and does not include database synchronization protocols that are not considered here as communication management protocols.

 According to one particular characteristic, the system is remarkable in that the means for determining a common context themselves comprise means for describing a structure of the context, the description being independent of the representation or representations used for storage and / or the transmission of data.

 The notion of independence means here that one can change and / or modify the storage representation without invalidating the abstract representation.

 According to one particular characteristic, the system is remarkable in that the means for determining a common context further 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.

 According to a particular characteristic, the system is remarkable in that all or part of the data managed is the data that the protocol aims to

<Desc / Clms Page number 8>

 maintain coherence in at least one transmitter among the transmitter (s) and at least one receiver among the receiver (s).

 The notion of coherent data here means that these data have a semantic identity but not necessarily an identity of representation. For example, a frequency expressed in MHz may have the same meaning as a frequency expressed in Hz while the representation is different.

 According to a particular characteristic, the system is remarkable in that at least a part of the message identification is performed in terms of actions and / or its effects on the common context.

 According to a particular characteristic, the system is remarkable in that it comprises connection means between: a description of the form of signal actually transmitted; and - the identification of the protocol messages.

 According to a particular characteristic, the system is remarkable in that the form of the signal belongs to the group comprising: the binary data sequences; - the sequences of elements taken in a predetermined alphabet; the sequences of modulated waveforms.

 Thus, the signal can be associated with very different types of symbols.

 According to one particular characteristic, the system is remarkable in that the link is in a data specification language comprising functions for describing data in the form of attributes of abstract objects and functions applying to concrete representations. .

 According to a particular characteristic, 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.

 According to a particular characteristic, 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.

<Desc / Clms Page number 9>

 According to one particular characteristic, the system is remarkable in that the means for determining a common context, the means for identifying the protocol messages and the means for defining data representations each implement a formal language allowing a determination. automatic protocol implementation software.

 According to a particular characteristic, the system is remarkable in that it comprises means for automatically determining the software for implementing the protocol.

 According to one particular characteristic, the system is remarkable in that it comprises means for automatic determination of device tests implementing the protocol.

 According to a particular characteristic, the system is remarkable in that the means for determining a common context include means for translating a representation mode of a protocol into the description of a set of data.

 According to one particular characteristic, the system is remarkable in that the means for identifying the protocol messages comprise means for translating a protocol representation mode.

 This feature allows the development of a description in the formalism of the invention from an existing description, for example from a standardization committee.

 Thus, thanks to its universality, the invention advantageously allows the reuse of common parts to several protocols and in particular the invention offers the possibility of having a protocol core that is enriched with specificities to create other protocols each having their specificity.

 According to one particular characteristic, the system is remarkable in that it furthermore comprises means for displaying the semantics of the protocol messages exchanged between the transmitter (s) and / or the receiver (s).

<Desc / Clms Page number 10>

 This step is particularly useful and effective for testing a communication protocol and / or its implementation devices.

 In addition, the invention relates to a method for specifying and implementing a communication management and transmission protocol between at least one transmitter and at least one receiver, characterized in that it comprises the following steps: determining 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 that can 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) from 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 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 or transmitters are able to communicate with the receiver or receivers.

 In addition, 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 management protocol. communication and transmission.

 The invention also relates to a formal language for describing at least one communication protocol element, remarkable in that it is suitable for implementing the previously described method of specification and implementation of a communication and transmission management protocol.

<Desc / Clms Page number 11>

 The invention also relates to a communication device, remarkable in that it comprises instructions for the transmission and / or reception of data to or from a third-party device, another device according to a protocol obtained by the implementation of the method as described above.

 In addition, 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) to perform the steps following adapted to the specification of communication protocol and transmission between at least one transmitter and at least one receiver: - determining a common context comprising a description of a set of data managed by the issuer (s) and / or the receivers; identification of the protocol messages that can 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) from 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 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 or transmitters are able to communicate with the receiver or receivers.

 The invention also relates to a computer program product, comprising instruction sequences adapted to the implementation of the method of communication protocol specification between at least one transmitter and at least one receiver when the program is executed on a computer.

<Desc / Clms Page number 12>

 The advantages of the formal language, the protocol specification, the device and the computer programs are the same as those of the protocol specification method, they are not detailed further.

 Other features and advantages of the invention will appear more clearly on reading the following description of a preferred embodiment, given as a simple illustrative and nonlimiting example, and the appended drawings, of which FIG. a mimic of specification of a protocol according to the invention according to a particular embodiment.

 As a preliminary to the description of the proposed new method, it is useful to make a detour via programming methods that emphasize data, and to describe the relationship between data and protocols.

 The last two decades have seen an important development of software programming based on data rather than algorithms. These methods consist of first describing the data structures stored by the software, highlighting the objects and object types managed by the software.

An object, in this sense, can be a concrete object, according to common sense, as a screen or a keyboard, but also something more abstract like a screen area or a file, or even very abstract like a queue wait. The important point of this approach is that an object type not only describes its attributes, but also the actions whose object can be the object.

 This approach to programming has a lot of advantages. It brings in particular a very effective modularity, centered on the types of object.

 So far, the presentation of the data structures in the protocols, under the influence among others of ASN.l is erroneous. What is described as data are messages and parts of messages, whereas messages are much closer to actions, in the sense of programming by objects, than data.

 Like this programming approach, we have to look for the data of a protocol in what is memorized by each of the even entities,

<Desc / Clms Page number 13>

 rather than what is transmitted. This reflection leads to highlight the notion of context of the protocol.

 Here we define the context of an entity as the data structure stored by this entity and containing the data involved in the implementation of the protocol. These interventions are of different orders: they can be managed data (ie, modified) by the effect of the reception of a message of the protocol, or of data which influence the actions of the protocol (data of state, of which , but not only, the state in the sense of SDL).

 Among the data appearing in the context of each of the entities, some are semantically identical on both sides, that is to say in two even entities of the protocol. According to the invention, the identical part is called common context. The common context can be described monolithically or, on the contrary, in separate pieces. These data are the same in the sense that they have the same meaning, and are kept identical, with the exception of certain transient states. A protocol may be used to, among other things, maintain the equality of these data. Thus, an important part of the function of any protocol is the distributed data management in several sending and / or receiving devices.

 In relation to FIG. 1, a protocol specification method according to the invention is presented. This method is preferably implemented by a microcomputer.

 This method is divided into successive steps: a first step 1 of encoding specification and decoding; a second step 2 of specifying the context; and a third step 3 of specifying messages.

 Step 1 of specification of the encoding and decoding is performed 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 exchanged bit strings. This is the description of the lexicon according to its form, as a list

<Desc / Clms Page number 14>

 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 strings (i.e., not belonging to the set of acceptable strings).

 This specification is made in CSN.1 but alternatively, any other formal language for describing the syntax of any bit string is applicable.

 Step 2 consists in formally describing the structure of the data forming the context of each of the paired entities. This description will highlight the common part of the two contexts, that is, the data managed as a distributed database.

 This formal description can use any formal data structure description language, such as ASN.l, description methods such as can be found in programming languages such as C ++, or as can be found in database management software.

 A language specially developed for this purpose is preferably used, making it possible to easily bridge the data structures appearing in the messages and the data structure descriptions as used by the developers, such as those permitted by the language of the data. C ++ programming.

 In step 3, a message is abstractly described (i.e., regardless of the encoding actually used for transport) as a sequence of actions applying to the common context data. This differs fundamentally from the usual descriptions, where messages or parts of messages are described as data structures.

 A message description according to the method gives the meaning of the message, in the form of the expected effect of receiving the message by the peer 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

<Desc / Clms Page number 15>

 specification of a protocol that are traditionally covered in the procedure descriptions by a text in natural language.

 The most common action is to change some of the context data. Such an action is hereinafter called SET. It requires two types of parameters: - those describing the part of the context concerned; and - those describing the new values to be assigned.

 The traditional description does not distinguish between the two types, and omits implicit parameters.

 Other typical actions are CREATE or ADD that create some of the data (for example, creating a new call context).

 A description of the messages or parts of the message in CSN.l only addresses the structure of what is actually transmitted. In contrast, an abstract description of a message type describes it in semantic terms, more related to the impact of receiving the message than to the particular form used for transmission.

 It is possible to formally describe the link 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 for calculating the result of the function from the received bit string and, when necessary, 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 previously transmitted index tables.)

<Desc / Clms Page number 16>

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.

 The method described has various applications, the main ones of which are as follows: - the automatic development of software for implementing communication protocols; - the development of protocols specified by different methods; - the direct specification of communication protocols; and - the development of test of communication protocols.

 One of the main aims of the invention is to allow the automatic generation of a substantial part of the software necessary for the implementation of the protocol. A complete formalization of the protocol according to the invention allows the automatic generation of encoding and decoding of messages, including the detection of erroneous strings, and including complex coding or decoding algorithms taking into account data. context.

 According to a variant of the invention, a complete formalization of the protocol also allows the automatic generation of the following aspects: context data; and / or - simple actions of the messages (for example, the change of value of the context data).

 In addition, non-automatically generated aspects are processed 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 is to translate otherwise specified protocols (i.e., according to different methods) into a description according to the invention. Among the advantages over traditional methods of development are:

<Desc / Clms Page number 17>

 - standardization of developments; - reduction of the code generated by generic engines (e.g., decoding engines); - better modularization, making easier the subsequent modifications.

 The invention allowing the direct specification of protocols can also be implemented by specification groups.

 Formal descriptions can be used to directly generate tests to verify the compliance of an implementation with the description.

 The complete method of specification according to the described embodiment implements description syntaxes that can be broken down into five groups of syntactic elements (or formal sub-languages): a) a data structure description syntax, for elements of the common context; b) a syntax for describing the encoding and decoding of symbol strings; c) a programming syntax, adapted in conjunction with the syntaxes a) and b); d) syntactic elements to link the descriptions according to the syntaxes a) and b); elements may be an integral part of either the syntax (a) or the syntax (b), or even be limited to rules of correspondence between the descriptions according to the syntaxes (a) and (b); e) message description syntax as actions acting on the context.

 According to a preferred variant of the invention, the specification method implements the first four syntaxes a) to d) without using the last message description syntax e).

 This technique is described in more detail in Annexes 1 to 6, in connection with Figure 1, so as not to overburden the present discussion. It is clear however that these appendices are an integral part of the description.

<Desc / Clms Page number 18>

 Annexes 1.4 and 5 describe elements of formal description specifying a communication protocol.

 Appendix 2 illustrates a specification of a simple data update.

 Annexes 3 and 6 illustrate a more complex case of specification of a GSM (Global System for Mobile Communication) protocol standardized by the ETSI (European Telecommunication Standard Institute) for managing mobility between a mobile station (MS) and an infrastructure of network.

 The specifications illustrated with respect to the annexes 2 and 3 (respectively 6) use the elements of formal description of the appendix 1 (respectively 4) and allow an automatic generation of code according to the invention.

 Of course, the invention is not limited to the embodiments mentioned above.

 In particular, a person skilled in the art can make any variant in the implementation of the invention that can be applied not only to the field of mobile telecommunications but to any network design (fixed and / or mobile) or link as well as the definition of the corresponding protocols.

 The invention also applies to different types of communicating elements, in particular telecommunications terminals, network infrastructure elements, cards or communicating components inside a device ...

The invention can, moreover, be implemented on a variety of machines or development tools, allowing, for example, the specification of communication protocols, the generation of codes or, more generally, the design and production of communication protocols. communication
Note that the invention is implemented in the form of a sequence of instructions of a computer program. Also, the corresponding instruction sequence can be stored in a removable storage means (such as for example a diskette, a CD-ROM or a DVD-ROM) or not, this means of

<Desc / Clms Page number 19>

 storage being partially or fully readable by a computer or a microprocessor.

<Desc / Clms Page number 20>

 ANNEX 1.

Formal Protocol Description Module
A module described in Appendix 1 includes formal description elements specifying a communication protocol associated with even entities.

 The module includes three types of descriptions: - abstract descriptions of object types (section 3); this corresponds to a syntax of type a) illustrated previously; - transfer descriptions that apply to either messages or objects as part of a message (section 6); corresponds to a syntax of type b); - and abstract descriptions of actions (messages for example), section 5 (e-type syntax)) or action programming, according to a syntax of type c).

 According to a variant of the invention, the abstract descriptions of actions managed automatically by a specification system are advantageously replaced by manual or semi-automatic programming of actions.

 To each type corresponds a distinct formal language.

 The module is essentially 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.

 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 indicates the type of object with which it is associated).

<Desc / Clms Page number 21>

1. Module Syntax
The module consists of a header, followed by a list of object type descriptions, self-contained action descriptions, and autonomous structure descriptions.

1. 1 Module header
The module header has its name and possibly other information.

2. Object type specifications
An object type description (or specification) consists of a name followed by the ':: =' characters, and terminated with a ';' character.

 A description includes: - an abstract description, introduced by the keyword 'abstract'; - zero, one or more transfer descriptions, each introduced by the key word 'transfer'; - zero, one or more action descriptions, each introduced by the keyword 'action'.

 A transfer description describes a symbol string structure (for example binary or described by a string of characters) that can correctly represent the abstract structure (see 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.

3. Abstract descriptions of object types
An abstract description of object type is usually presented as a set of components. Each component is characterized in particular by:

<Desc / Clms Page number 22>

 - a component name, - presence information, and - a type description.

3. 1 Component name
The component name is a free string that uses the available characters except for the characters '[', '.',
3. 2 Presence information
By default the component is not indexed. An indexed component (array) 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: - Fixed number: this is indicated by an integer, which is the number of copies.

 - Free variable number: this is indicated by an interval (two integers separated by '..'). A special case is O..infinity which indicates any number of copies.

 - Conditional variable number: this is indicated by an expression of type 'iif', indicating different intervals or fixed numbers to be selected according to Boolean expressions relating to the values of other elements of the structure.

3. 3 Type description
This description indicates the structure of the component itself. Different descriptions are possible.

3. 3.1 Basic Components
Such a description is introduced by a ':'.

 This includes:

<Desc / Clms Page number 23>

- integer (keyword 'integer', possibly followed by an interval in parentheses); - enumerated type ('enumerated' keyword followed by a parenthesized list of comma separated identifiers); - bit string ('bit string' keyword, possibly followed by a size or size range in parentheses)
3.2 Structure
A structure is introduced by '{', and is described by a succession of lines beginning with a '+' more than the line introducing the component, and ending with a ''''.

3.3 Union
A union is an abbreviated form for a set of exclusive presence components.

3. 3.4 Reference
A reference is introduced by a character: ', and is the name of a data type described elsewhere. When the type description module is not the enclosing module, it is indicated in parenthesis according to the type name.

3. 3.5 Index
An index type is introduced by '->', followed by a name of n # ud. A n # ud name is composed of an object type name (possibly empty, in which case it is the current type), followed by a sequence of component names separated by '.', Such as each component name exists in the structure of the preceding component or type. The last component must be indexed.

 A nname name gives: - The static information of the indexed type (the type of the last component);

<Desc / Clms Page number 24>

 - 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 specified type.

4. Description of action
An action description includes the name of the action between '<' and '>', followed by ':: =' followed by an abstract description of action, followed by zero, one or more transfer descriptions, each introduced by the key word 'transfer'.

 A transfer description describes a symbol string structure that can correctly represent the abstract structure (see chapter on the subject).

5. Abstract action description
An abstract action description optionally includes a list of parameters, and possibly a list of instructions.

(The instructions generally require parameters that appear for example in the representation of the action.These parameters are not listed in the parameter list: it contains the parameters that can not be more precisely described as linked to an elementary instruction.)
The list of parameters is introduced by the keyword 'parameters' and is ended by the key word 'end'. The list follows the syntax of the abstract object type description.

 The action list consists of one or more rows. Each line consists of a possible indication of condition, followed by an instruction from those listed below.

5.1 Condition indication
A condition indication is either the 'OPTIONAL' keyword or an IF THEN statement.

<Desc / Clms Page number 25>

 The OPTIONAL keyword indicates that the statement, or the statement list between '{' and '}', that follows may or may not be requested.

 An IF THEN statement indicates (between the key words 'IF' and 'THEN') a condition, expressed from parameter values, whether the instruction is to be done or not.

5. 2 Selection Instruction
A selection statement 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 hint may follow the component name (see section on the index).

5. 3 SET instruction
A SET statement is introduced by the 'set' keyword followed by a component name (possibly with an index). This statement requests the assignment of a new value to the component (in its integrity, which can be a fairly large subtree). There are several ways that the new value can be indicated:
5. 3.1 Default implicit type parameter
In this case, the statement contains nothing more. The message then contains a parameter of the type of the component, as described in the abstract object description.

5. 3.2 Explicit type implicit parameter
In this case the statement is followed by: 'followed by an object type name. This type must be compatible with the type of component (subtype).

 5. 3.3 Explicit value

<Desc / Clms Page number 26>

In this case, the statement is followed by: = 'followed by an expression whose result must be compatible with the type.

5. 3.4 Calculated value
In this case the statement is followed by the ': =' character followed by a statement list between '{' and '}'. These instructions relate to the node indicated by the component, and they specify the actions leading to the assignment of the component (typically subcomponent by subcomponent).

5. 3.5 Emptying
In this case, the statement is followed by ': = null'. This only applies to indexed components (but with no index specified in the SET statement) and accepts a null number of copies. The instruction sets the number of copies to zero.

5. 4 ADD instruction
An ADD instruction is introduced by the 'set' keyword followed by an indexed component name (without an index specified in the ADD statement). This statement requests the addition of a new copy to the component (in its integrity, which can be a fairly large subtree). There are several ways in which the new value can be specified, as in the SET statement (except dump).

5. 5 SEND Instruction
A SEND statement is introduced by the 'send' keyword followed by a component name (possibly with an index). This statement 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 for consistency, but the consequence of an inconsistency detection is not specified.

 5. 6 CHOICE Instruction

<Desc / Clms Page number 27>

A CHOICE statement is introduced by the keyword 'choice' followed by a list of actions between '{' and '}' and separated by ','. This indicates that one and only one of the actions is requested for each occurrence of the action.

5. 7 Instruction DO
A DO statement consists of the 'do' keyword followed by the name of an action.

This action must be compatible with the current component type.

5. 8 Instructions for going back
A data modification may be requested on the test and possibly refused by the receiver. This is handled by the PREPARE, COMMIT, and UNDO instructions.

5. 8.1 The PREPARE instruction
This instruction indicates that the changes that follow it and apply to the current node can be undone.

5. 8.2 The COMMIT instruction
This instruction indicates the acceptance of modifications subject to a PREPARE on the current node.

5. 8.3 The UNDO instruction
This statement indicates the denial of PREPARE-prone changes to the current node.

6. Transfer Description
The transfer description is based on the CSN.l version 2.2 language type, with the following adaptations.

 6. 1 Header

<Desc / Clms Page number 28>

When the transfer description is unique for an object type, the CSN.l structure name can be omitted, and is then the same as the type name.

 6. 2 End of structure The; final is omitted (the end is detected either by the end of object, or by one of the key words transfer (indicating a coding alternative), or action.

6. 3 Computed functions of connection with the abstract description
The header of a computed function can be of abstract form. followed by an abstract element identifier. The type is not specified and is that of the abstract element as defined in the abstract description.

 More generally, the linking rules between a transfer description and an abstract description (of type of object or message) are the subject of a special chapter.

6. 4 References to the context
A formula can invoke context element values.

7. Separate action description
An action can be described outside the description of the type of object to which it relates. The action description is then preceded by a header consisting of the 'on' keyword followed by the object type name 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.

8. Separate transfer description
A transfer description can be separated from the abstract description to which it corresponds.

 9. Correspondence rules

<Desc / Clms Page number 29>

The correspondence between an abstract description and a transfer description is based on the correspondence between abstract component names and label names, plus representation formulas.

10. Names
A name (object or action) is composed of free characters, with the necessary exceptions for syntactical reasons. When comparing two names, the consecutive strings of space, tab, and end of line are considered equivalent to a single space, except at the beginning and at the end, where they are considered equivalent to the empty string; hunting is not taken into account.

<Desc / Clms Page number 30>

ANNEX 2
First example: specification of a simple update of a data.

A protocol is presented here as part of an illustrative unidirectional protocol whose only purpose is to update a datum. The application of the method proceeds as follows: - abstract description of the context; - abstract description of the messages; - description of the encoding and decoding of the data; - description of the encoding and decoding of messages;
The specifications illustrated with reference to Annex 2 use the formal description elements of Annex 1 and allow automatic code generation according to the invention.

 1. Abstract description of the common context.

 This description is done according to a formal language of abstract description of data. The language used here is not published.

<protocol context type> :: = managed data: managed data type; ; ~~~~~~~~~~
The expression 'type of managed data' can represent any type of data, for example: <managed data type> :: = integer 1: integer, integer 2: integer;
2. Abstract description of the messages.

<Desc / Clms Page number 31>

The protocol is reduced to a single message, which modifies the context in its entirety. The description of the messages is made according to a formal language adapted to the description of actions relating to the data context: on <protocol context type><protocol data unit> :: =
CHOICE <edit: message content edit>;<message content edit> :: = on <managed data>SET;
3. Description of the encoding and decoding of the data.

 This description is done in CSN.l, encapsulated in a more general language combining the abstract description and the concrete description. Only data that appears as a message parameter are described.

<managed data type> :: = abstract integer 1: integer, integer 2: integer transfer <integer 1: bit (4)> - the connection to the abstract is done by the identifier - the default encoding is binary, most significant first <integer 2: bit (6)>;; ~~~~~~~~~~~~~~~~~~~~~~~~
4. Description of the encoding and decoding of the messages.

 This description is done in CSN. 1, encapsulated in a more general language combining the abstract description and the concrete description.

<Desc / Clms Page number 32>

<protocol data unit> :: = abstract
CHOICE <edit: message content edit> transfer
00 <modify: <content of the message modify <extension: bit (*) = null}! - accept a future extension <message type errror: bit (*); - detection of an error of type <contents of the message modify> :: = abstract on <managed data> SET transfer <data managed.set.new data: <type of data managed;

<Desc / Clms Page number 33>

ANNEX 3
Example of Specification of a Real Protocol (the GSM Mobility Management Protocol between a Mobile Station (MS) and a Network Infrastructure)
Most of the following functions have names as specified in the GSM Standard (Global System for Mobile Communication) standardized by the European Telecommunications Standard Institute (ETSI).

The names or acronyms used in the specifications correspond either to elements of the syntax of a particular embodiment of the invention (as specified in Annex 1) or to names or acronyms of elements specified in the GSM standard. module MM 24. 008 4.0.0 default scope: MM
RIL3.Location Area Code from RIL3 24. 008 4. 0.0
RIL3.Location Area Identification from RIL3 24. 008 4. 0.0
RIL3.Mobile Station Classmark 1 from RIL3 24. 008 4. 0.0
RIL3.Mobile Station Classmark 2 delta from RIL3 24. 008 4. 0.0
RIL3.Mobile Station Classmark 3 from RIL3 24. 008 4. 0.0
RIL3.Priority Level from RIL3 24. 008 4. 0.0 RIL3.Ciphering Key Sequence Number from RIL3 24. 008 4.0.0
1 Background of mobility management protocol (or MM of mobility mobility).

 This is the specification of the protocol context, that is, data common to the infrastructure and the mobile station, and managed by the protocol.

<Desc / Clms Page number 34>

1. 1 Abstract description
The description of the elements of the context is independent of the representations, whether for the memorization in the entities, or for the transmission in protocol messages.

<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 .. infinity]: + + 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 Boolean + CKSN availability: Boolean + CKSN [iif (CKSN availability, 1, 0)]: RIL3.Ciphering Key Sequence Number + GSM ciphering key [0..1]: Bit string (64) + UMTS security data [0 ..1]: + + AUTN: Authentication Parameter AUTN + + UMTS ciphering key [0..1]: String bit (128) + + UMTS integrity key [0..1]: Bit string (128)

<Desc / Clms Page number 35>

1. 2 Actions 1. 2.1 Downlink mobility management (or DL MM) 1. 2.1.1 Abstract description
This abstractly describes the protocol message that can be transmitted from the infrastructure to the mobile station. action DL MM :: = abstract
CHOICE do LOCATION UPDATING ACCEPT, do LOCATION UPDATING REJECT, do AUTHENTICATION REJECT, do AUTHENTICATION REQUEST, do TMSI REALLOCATION COMMAND, do CM SERVICE ACCEPT, do CM SERVICE REJECT, do CM SERVICE PROMPT, do IDENTITY REQUEST, do ABORT, do MM STATUS DOWNLINK , do MM INFORMATION} 1. 2.1.2 Transfer syntax
This indicates the binary structure of the message. This shows in particular a field for selecting a particular action in the list of possible actions. transfer :: = flow of downlink MM messages {<skip indicator: 0000><protocol discriminator 0101>
00 {00 0010 <LOCATION UPDATING ACCEPT: LOCATION UPDATING ACCEPT>

<Desc / Clms Page number 36>

# 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 <SERVICE REJECT CM: SERVICE REJECT CM> 10 0101 <SERVICE PROMPT CM: SERVICE PROMPT CM># 10 1000 <IDENTITY REQUEST: IDENTITY REQUEST># 10 1001 <ABORT: ABORT> Il 0001 <MM STATUS : MM STATUS DOWNLINK> 11 0010 <MM INFORMATION: MM INFORMATION>}! <erroneous type: bit ** = <no string} <spurious extension: bit ** = null> 1. 2.2 uplink mobility management (UL MM) 1. 2.2.1 Description abstract 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 transfer syntax 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> 1010100 <AUTHENTICATION RESPONSE: AUTHENTICATION RESPONSE># 01 1001 <IDENTITY RESPONSE : IDENTITY RESPONSE>

<Desc / Clms Page number 37>

# 01 1011 <TMSI COMPLETE REALLOCATION: TMSI REALLOCATION COMPLETE> 10 0011 <CM ABORT SERVICE: CM SERVICE ABORT># 10 0100 <SERVICE REQUEST CM: SERVICE REQUEST CM> 1110001 <MM STATUS: MM STATUS UPLINK>}! <erroneous type: bit ** = <no string} <spurious extension: bit ** = null> 1. 2.3 Abort (or abort) 1. 2.3.1 Abstract description action ABORT :: = abstract parameters
Reject cause: MM. Reject cause end if iif (Reject cause.cause grouping = MS identification error, MS cause error = illegal ME, false) then set Location update state: = roaming not allowed 1. 2.3.2 Transfer transfer syntax :: = <Reject cause: <MV-IE (Reject cause downlink, 1) # 1. 2.4 Authentication failure (or "AUTHENTICATION FAILURE") 1. 2.4.1 Abstract description action AUTHENTICATION FAILURE :: = abstract parameters
Reject cause: MM. Reject cause
Authentication Failure parameter [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

<Desc / Clms Page number 38>

}
1. 2.4.2 Transfer syntax. transfer :: = <Reject Cause - <MV-IE (Reject Cause uplink, 1) <Authentication Failure parameter: <O-TLV-IE (0010 0010, Authentication Failure parameter,
16)
1. 2.5 Authentication Rejection (or "AUTHENTICATION REJECT")
1. 2.5.1 Abstract description action AUTHENTICATION REJECT :: = abstract set Update location state: = Roaming not allowed
1. 2.5.2 transfer syntax transfer :: = null
1. 2.6 Authentication Request (or "AUTHENTICATION"
REQUEST ")
1. 2.6.1 Abstract description action AUTHENTICATION REQUEST :: = abstract parameters
Authentication Parameter RAND - MM.Authentication Parameter RAND
Authentication Algorithm: Enumerated (UMTS, GSM)
PREPARE set CKSN availability = True set CKSN set GSM ciphering key: = A8 (Authentication Parameter RAND.RAND)

<Desc / Clms Page number 39>

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 Transfer syntax transfer :: = <spare half byte: {bit * 4 = 0000}><Ciphering key sequence number: <M-VD-IE (Ciphering Key Sequence number Downlink) <Authentication parameter RAND: <MV-IE (Authentication parameter RAND, 16) <Authentication parameter AUTN: <O-TLV-IE (0010 0000, Authentication parameter AUTN, 18, 18) abstract. Authentication algorithm returns - if there is any error on AUTN, the authentication Algo will be considered GSM iif (Authentication parameter AUTN), UMTS, GSM) 1. 2.7 Authentication response (or "AUTHENTICATION")
RESPONSE ") 1. 2.7.1 Abstract description action AUTHENTICATION RESPONSE :: = abstract parameters
RES: Octet string (4..16) end
COMMIT on Connection parameters {set Has been authenticated: = True transfer :: = <Authentication response parameter: <Authentication Response Parameter (<4) <Authentication response extension: <O-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

<Desc / Clms Page number 40>

2. 2.7.2 Transfer transfer syntax: = null 1. 2.8 Connection abort for service (or "CM")
SERVICE ABORT ") 1. 2.8.1 Abstract description CM action ABORT = abstract on Connection parameters {set Service data = null 1. 2.8.2 Transfer transfer syntax: = null 1. 2.9 Acceptance of the connection request for service ( or "CM
SERVICE ACCEPT ") 1. 2.9.1 Abstract description CM SERVICE ACCEPT action = abstract
COMMIT

<Desc / Clms Page number 41>

1. 2.9.2 Transfer Transfer Syntax :: = null 1. 2.10 Connection Management Service Display (or "CM SERVICE")
PROMPT ") 1. 2.10.1 Abstract description CM SERVICE PROMPT. = Abstract parameters
PD and SAPI RIL3.PD and SAPI end 1. 2.10.2 Transfer transfer syntax :: = <PD and SAPI of CM <IE-IE (PD and SAPI, 1) 1. 2.11 Rejection of the connection request for service ( or "CM
SERVICE REJECT ") 1. 2.11.1 Abstract description CM SERVICE REJECT action: = abstract parameters
Reject cause - MM.Reject cause end
UNDO if iif (Reject cause cause grouping = MS identification error, Reject cause.MS identification error cause = "illegal ME" or Reject cause.MS identification error cause = "IMSI unknown in VLR", false) then set Location update state. = roaming not allowed

<Desc / Clms Page number 42>

1. 2.11.2 Transfer transfer syntax :: = <Reject cause: <MV-IE (Reject cause downlink, 1) # 1. 2.12 Additional connection request for service (or "CM"
SERVICE REQUEST SUBSEQUENT ") 1. 2.12.1 Abstract description 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 / TMSI then on LAI + TMSI {send TMSI} send CKSK availability if CKSN availability then send CKSN} on Connection parameters {send Classmark 1 send Mobile Station Classmark 2 delta Mobile Station
PREPARE add Service data: = {set CM Service Type set Priority}} 1. 2.12.2 Transfer syntax: CM SERVICE REQUEST transfer <CM SERVICE REQUEST> :: = <Ciphering key sequence number uplink: <M-VD-IE ( Ciphering key sequence 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: <O-TVD-IE (1000, Priority raised!) ~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~

<Desc / Clms Page number 43>

abstract.Mobile Identity type returns
Mobile identity.V.Type of identity.abstract abstract.IMSI returns
Mobile identity.V.IMSI abstract abstract.TMSI returns
Mobile Identity V.TMSI / P-TMSl.abstract abstract IMEI returns
Mobile identity V.IMEI 1. 2.13 GSM identity request (or IDENTITY REQUEST) 1. 2.13.1 Abstract description action IDENTITY REQUEST .: = abstract parameters
Mobile Identity Type: MM.Mobile Identity Type end 1. 2.13.2 Transfer syntax transfer :: = <spare half byte: {bit * 4 = 0000}><Identity type - <M-VD-IE (Identity type) 1 2.14 Identity response (or IDENTITY RESPONSE) 1.2.14.1.1 Abstract description action IDENTITY RESPONSE :: = abstract parameters
Mobile Identity Type: MM.Mobile Identity Type end

<Desc / Clms Page number 44>

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 Transfer Syntax transfer :: = <Mobile Identity: <M-LV-IE (Mobile Identity, 2, 10) 1. 2.15 Localization Update Acceptance (or "LOCATION"
UPDATING ACCEPT ") 1. 2.15.1 Description abstract action LOCATION UPDATING ACCEPT :: = abstract parameters
TMSI allocation status: Enumerated (new TMSI, keep TMSI, TMSI erase)
Follow on proceed: Boolean end set Location update state: = updated on Location parameters TMSI allocation status = new TMSI then on LAI + TMSI LAI + TMSI: = null set CTS permission: = Boolean} 1. 2.15.2 transfer syntax transfer :: =

<Desc / Clms Page number 45>

<Location identification area: <MV-IE (Location area identification, 5) <Mobile identity: <O-TLV-IE (0001 0111, Mobile identity, 3, 10) <Follow on proceed: <OT-IE (1010 0001) <CTS permission: <OT-IE (1010 0010) abstract.TMSI allocation status returns switch (Mobile identity = <null>, keep TMSI,
Mobile identity.V.TMSI / P-TMSI = 1 **, TMSI erase,
Mobile identity.V.TMSI / P-TMSI = bit **, new TMSI) abstract.TMSI returns
Mobile identity.V.TMSI / P-TMSI.abstract 1. 2.16 Rejecting a Location Update (or LOCATION
UPDATING REJECT) 1. 2.16.1 Abstract description action LOCATION UPDATING REJECT :: = abstract parameters
Reject cause. Messrs. 1. 2.16.2 Transfer syntax transfer :: = <Reject cause. <MV-IE (Reject Cause Downlink, 1) # 1. 2.17 Mobility Management Information (or "MM INFORMATION") 1. 2.17.1 Abstract Description Action MM INFORMATION :: = abstract parameters
Universal time [0..1]: MM.Universal Time

<Desc / Clms Page number 46>

end on Location parameters
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}}} on Connection parameters {on Serving cell {
OPTIONAL set LSA identity}} 1. 2.17.2 Transfer syntax transfer :: = <Full name for network: <O-TLV-1E (0100 0011, Network Name, 3, 255) <Short name for network: <O- 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: <O-TV-IE (0100 0111, Time Zone and Time, 8) <LSA Identity: <O-TLV-IE (0100 1000, LSA Identifier, 2, 5) <Network Daylight Saving Time: <O-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 Downstream status of Mobility Management (or "MM STATUS DOWNLINK") 1. 2.18.1 Abstract description action MM STATUS DOWNLINK :: = abstract parameters

<Desc / Clms Page number 47>

Reject causes MM Reject cause end 1. 2.18.2 Transfer transfer syntax: = <Reject cause <MV-IE (Reject cause downlink, 1) 1. 2.19 Upstream status of Mobility Management (or "MM")
STATUS UPLINK ") 1. 2.19.1 Abstract description action MM STATUS UPLINK: = abstract parameters
Reject cause MM.Reject cause end 1. 2.19.2 Transfer transfer syntax: '= <Reject cause <MV-IE (Reject cause uplink, 1) 1. 2.20 TMSI reallocation command (or "TMSI REALLOCATION
COMMAND ") 1. 2.20.1 Description abstract action TMSI REALLOCATION COMMAND.: = Abstract on Location parameters {
PREPARE set LAI + TMSI}

<Desc / Clms Page number 48>

1. 2.20.2 Transfer syntax transfer :: = <Location area identification - <Location Location Identification, 5 <Mobile identity: <M-LV-IE (Mobile identity, 2, 9) abstract.TMSI returns
Mobile identity V.TMSI / P-TMSI abstract 1. 2.21 TMSI reallocation performed (or "TMSI REALLOCATION
COMPLETE ") 1. 2.21.1 Abstract description action TMSI REALLOCATION COMPLETE ': = abstract
COMMIT 1. 2.21.2 Transfer syntax transfer :: = null 2 List of location fields (or "LA list") 2. 1 Abstract description <LA list> :: = abstract
Location area description [0. infinite]: + PLMN: -> UE context.PLMN list + LAC. RIL3 Location Area Code + Local Time Zone [0..1]: Time Zone + Network Daylight Saving Time (0..1): Daylight Saving Time 3 List of Networks (or PLMN list)

<Desc / Clms Page number 49>

3. 1 Abstract description <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 4 Authentication Setting AUTN (or "Authentication")
Parameter AUTN ") 4. 1 Abstract Description <Authentication Parameter AUTN> = abstract
Sequence number xor Anonymity Key 'Bit string (48)
Authentication management field: Bit string (16)
Message authentication code: Bit string (64) 4. 2 Transfer syntax transfer :: = <Sequence number xor Anonymity Key: bit * 48><Authentication management field. bit * 16><Message authentication code: bit * 64> 5 Service type CM (or "CM Service Type") 5. 1 Abstract description <CM Service Type> :: = abstract service type: Enumerated (MO packet is, emergency call, SMS, SS, VGC, VBS, LCS) 5. 2 transfer syntax transfer :: =

<Desc / Clms Page number 50>

<service type: {00011001010100110 bit (2)}> 6 Daylight Saving Time (Daylight Saving Time) 6. 1 Abstract Description <Daylight Saving Time> :: = abstract
Daylight Saving Time Adjustment: Enumerated (0, + 1hour, +2 hour) 6.2 Transfer Transfer Syntax :: = <spare bit> * 6 <Daylight Saving Time Adjustment: {00 # 01 10}> 7 IMEI 7. 1 Abstract Description <IMEI> :: = abstract
Type Approval Code [6]: Integer (0..9)
Final Assembly Code [2]: Integer (0..9)
Serial Number [6]: Integer (0..9) 7. 2 Transfer syntax 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 (even [n / 2] .digit even), integer (even [(n-1) / 2] .digit odd))) abstract.Type Approval Code [n] returns - n from 0 to 5, MSB to LSD Digit (n + 1)

<Desc / Clms Page number 51>

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 Abstract Description <IMSI> :: = abstract
MCC: MCC
NMSI [3..12]: Integer (0.99)
8. 2 Transfer syntax 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))} & byte * (4..8) function Digit (n): integer returns iif (n = 1, integer (digit one), iif (n% 2 = 0, integer (even [n / 2] .digit even), integer (even [(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] n returns from 0 to (size-1)
Digit (n + 4)
9 LAI and TMSI
9. 1 Abstract description

<Desc / Clms Page number 52>

<LAI + TMSI> :: = abstract
Location Area Identification: RIL3.Location Area Identification
TMSI: Temporary Mobile Station Identity
10 LSA Identifier (or LSA Identifier)
10. 1 Abstract description <LSA Identifier> :: = abstract
LSA available: Boolean
LSA ID [iif (LSA available, 1, 0)]: + LSA Identify scope: Enumerated (PLMN significant, universal) + Localized service area identity: Bit string (23)
10. 2 Transfer syntax transfer :: = {<LSA ID: <Localized service area identity: bit (23)><LSA Identify scope: bit>} abstract.LSA Available Returns Exist (LSA ID) abstract.LSA ID.LSA identify scope returns iif (LSA identify scope = 0, PLMN significant, universal)
11 MCC
11.1 Abstract Description <MCC> :: = abstract
MCC value: Integer (0..999)
12 MNC

<Desc / Clms Page number 53>

12. 1 Abstract Description <MNC> :: = abstract
MNC value: Integer (0..999) 13 Network Name (or "Network Name") 13. 1 Abstract Description <Network Name> :: = abstract
Coding scheme: Enumerated (cell broadcast default alphabet, UCS2)
Add country's initiais: Boolean
Text string: String 13. 2 Transfer syntax transfer :: = <ext: 1 <Coding scheme: {000 # 001}><Addcountry's statement: bit><number of spare bits in last byte: bit (3)>< Text string: - order of bits within text string? <byte> ** <{0} * (number of spare bits in last byte)><bit * (8 - number of spare bits in last byte) 14 Network Identity (or PLMN Identity) 14. 1 Abstract Description <PLMN Identity> :: = abstract
MCC: MCC
MNC MNC

<Desc / Clms Page number 54>

15 Temporary Mobile Station Identity (or "Temporary")
Mobile Station Identity ", TMSI).

15. 1 Abstract description <Temporary Mobile Station Identity>: = = abstract temporary identity Bit string (32) 15. 2 Transfer transfer syntax.: = <Temporary identity: bit * 32> 16 Time zone (or Time Zone) 16. 1 Abstract description <Time Zone> :: = abstract
Delta with GMT: Integer (-99.99) 16. 2 Transfer syntax transfer = <sign 'bit><digit 1 bit (3)><bit digit (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))

<Desc / Clms Page number 55>

ANNEX 4.

Formal protocol description module according to a variant
A formal protocol description module according to a variant of the invention is described in Appendix 4 and includes elements of formal description 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 to either messages or objects as part of a message (corresponding to a syntax of type b).

 To each type corresponds a distinct formal language.

 The module is essentially 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.

 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 indicates the type of object with which it is associated).

<Desc / Clms Page number 56>

1 Syntax of module
A module consists of a header, followed by an object type description list, autonomous action descriptions, and autonomous structure descriptions.

1. 1 Module header
The module header has its name, the default scope.

2 Descriptions of object types
A description includes at least: - an abstract description; - zero, one or more transfer descriptions; - zero, one or more command descriptions.

 A transfer description describes a bit string structure that can correctly represent the abstract structure (see topic chapter).

 An action (message) associated with the object type describes modifications that can be requested to an instance of said object type.

3 Abstract descriptions of object types
An abstract description of object type is usually presented as a set of components. Each component is characterized by: - a component name, - presence information, and - a type description.

3. 1 Presence information
A component may have an index (array). By default a component has only one copy, an index allows to have a variable number of copies, distinguished by an index value. Different cases are distinguishable for the number of copies.

<Desc / Clms Page number 57>

3. 1.1 Fixed number of copies
The number of copies is specified by an integer. The default case, a single copy, is a special case of fixed number of copies.

3. 1.2 Free variable number
The number of possible copies is then typically indicated by an integer range. A special case is any number of copies (range from 0 to infinity).

3. 1.3 Conditional variable number
The number of copies, acceptable depends on the values of other elements of the structure.

3. 2 Type description
This description indicates the structure of the component itself. Different descriptions are possible.

3.2.1 Basic components
This includes at a minimum: - an integer component, in the mathematical sense of the term; - an enumerated type component: the list of possible values is given explicitly, common list of abstract symbols; and a bit string component.

3. 2.2 Structure
A structure is a list of components.

3. 2.3 Union
A union is an abbreviated form for a set of exclusive presence components, ie, at most one of the components is present in an instance of the union.

<Desc / Clms Page number 58>

3. 2.4 Reference
A reference is a structure whose content is defined by reference to another type of object.

3. 2.5 Index
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 component is defined, or a component included in a context, a single object common to the sender and the receiver.

4 Action description.

 An action description includes a command name, an abstract action description, and one or more transfer descriptions.

 A transfer description describes a bit string structure that can correctly represent the action (see topic chapter).

* 5 Abstract description of action.

An abstract description of action optionally includes a list of parameters, and possibly a list of elementary actions. (The instructions generally require parameters that appear for example in the representation of the action.These parameters are not included in the parameter list: it contains only the parameters that can not be described more precisely as linked. to a basic education.)
The action list consists of one or more elementary actions.

Each elementary action consists of a possible indication of condition, followed by an instruction from those listed below.

<Desc / Clms Page number 59>

5.1 Condition indication
By default, an instruction must be executed. A condition indication is used to indicate the conditions under which the instruction is to be executed.

 A first syntax makes it possible to describe a condition as a Boolean expression constructed from the 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., OPTIONAL keyword).

5. 2 Selection Instruction
A selection command is used to indicate a sub-part of the object on which an action sequence is carried. The term 'current node' is then used to denote the sub-part to which an instruction is concerned. By default of a select statement, the current node is an object of the type that the action is associated with. The specific object is determined implicitly.

5. 3 Assignment Instruction (SET)
An assignment statement requests the assignment of a new value to a component of the current node (in its integrity, which can be a fairly large subtree). There are several ways in which the new value can be specified: default parameter of implicit or explicit type, explicit or calculated value.

5.3.1 Default implicit type
In this case, the statement contains nothing more. The message (representation of the action) then contains a parameter of the type of the component, as described in the abstract object description.

5. 3.2 Explicit type implicit parameter
In this case the statement includes an object type name. This type must be compatible with the type of component (subtype).

<Desc / Clms Page number 60>

5. 3.3 Explicit value
In this case, the statement includes an expression whose result must be compatible with the type of component.

5. 3.4 Calculated value
In this case, the instruction includes a list of instructions. These instructions give the actions leading to the assignment of the component (typically subcomponent by subcomponent).

5. 3.5 Emptying
This only applies to indexed components (but with no index specified in the SET statement) and accepts a null number of copies.

The instruction sets the number of copies to zero.

5. 4 Add Instruction (ADD)
An add statement includes an indexed component name and a value.

This statement requests the addition of a new copy to the component, having the specified value (in its integrity, which can be a fairly large subtree). There are several ways in which the new value can be indicated, as in the case of the assignment statement.

5. 5 Sending Instruction (SEND)
A send statement 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 for consistency, but the consequence of an inconsistency detection is not specified.

5. 6 Instruction of Choice (CHOICE)
A choice statement indicates that one and only one of the actions is requested for each occurrence of the action.

<Desc / Clms Page number 61>

5. 7 Instruction for the execution of an action (DO)
An execution statement executes an action that is compatible with the current component type.

5. 8 Instructions for going back
A data modification may be requested on the test and possibly refused by the receiver. This is handled by specific instructions for preparation (PREPARE), acceptance of modifications associated with a preparation (COMMIT) and refusal of modifications (UNDO).

5. 8.1 Preparation instruction (PREPARE)
This instruction indicates that the changes that follow it and apply to the current node can be undone.

5. 8.2 The acceptance instruction (COMMIT)
This instruction indicates the acceptance of the modifications subject to a preparation (PREPARE) on the current node.

5. 8.3 The Unoperation Instruction (UNDO)
This instruction indicates the refusal of PREPARE-related changes to the current node.

6 Transfer Description
The transfer description is based on CSN.l version 2. 2, with the following adaptations.

6. 1 Header
When the transfer description is unique for an object type, the CSN.l structure name can be omitted, and is then the same as the type name.

<Desc / Clms Page number 62>

6. 2 End of structure The; final is omitted (the end is detected either by the end of object, or by one of the key words transfer (indicating a coding alternative), or action.

6. 3 Computed functions of connection with the abstract description
The header of a computed function can be of abstract form. followed by an abstract element identifier. The type is not specified and is that of the abstract element as defined in the abstract description.

 More generally, the rules of correspondence between a description of transfer and an abstract description (of type of object or message) are the subject of chapter 9.

6. 4 References to the context
A formula can invoke context element values.

7 Separate action description
An action can be described outside the description of the type of object to which it relates. The action description is then preceded by a header consisting of the 'on' keyword followed by the object type name 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.

8 Separate transfer description
A transfer description can be separated from the abstract description to which it corresponds. In this case the name of the transfer structure is mandatory.

<Desc / Clms Page number 63>

9 Correspondence rules
The correspondence between an abstract description and a transfer description is based on the correspondence between abstract component names and label names, plus representation formulas.

10 Names and scopes
The full name of an action or object type consists of a description or scope and a name in that scope. The complete writing is then the scope followed by a point followed by the name in the scope.

 The header of the module allows to give a scope by default. We can then use the local name alone (not preceded by the scope), the scope being the scope by default.

 The names of scope and object are supposed to be related to the nature of the object.

 A name (object, action or scope) is composed of free characters, with the necessary exceptions for syntactical reasons. When comparing two names, the consecutive strings of space, tab, and end of line are considered equivalent to a single space, except at the beginning and at the end, where they are considered equivalent to the empty string; the case is not taken into account (neither the color or other attributes of the same flour). In other words, in the comparison of character strings, the formatting attributes (upper / lower case / other, that is to say, the case in terms of typography, italic / bold / other, ...), or presentation (color, font, ...) do not interfere in the comparison.

<Desc / Clms Page number 64>

ANNEX 5
Example of a formal description language.

1 Specification of a formal description language
This annex describes an example of a formal description language according to Annex 4.

2 Object Classes
The notion of object class is common to many programming or specification languages, under different names like "class" or "type". In general, a class is a set of objects, these being described from characteristics common to all these objects. Within the framework of the protocols, 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 are related to an external reality), and the operations (computer treatments that may involve objects).

 The description of a class includes, first, the specification of a minimum set of features to distinguish any object from 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 includes, in general, informal indications (ie, not usable by the treatments, but intended for humans), such as attribute names or comments.

 CSN descriptions. 1 allow to specify representations by binary strings or characters, as well as implicit or explicit rules allowing to relate a representation and an element of the class according to the abstract description.

 Finally, class-specific treatments can be

<Desc / Clms Page number 65>

 included directly in the class description (methods). The body of a method (the detailed description of the processing) is described in modified C ++, the modifications allowing the coupling with the abstract description.

 The description of a class includes at the base: - an identifier This is a formal unambiguous reference to the class, in the form of a string of characters; - no or an abstract description; - none, one or more representations; and - none, one or more methods.

 Additional formal information may be provided. This is visible in the detailed description of the syntax.

 For the sake of modularity, the syntax of the language makes it possible to derive one class from another, as well as to describe parameterized classes, a way of describing at one time several classes whose differences can be captured by a small number of formal parameters. .

2. 1 Syntax The syntax is: classdecl :: = "class" id "{" classdesc "}"";"#"class" id ":""public" idlist "{" classdesc "}"";"
The second case makes it possible to define a class from one or more others (class derivation). idlist :: = id id "," idlist

<Desc / Clms Page number 66>

classdesc :: = aspectlist aspectlist :: = aspect # aspectlist appearance aspect :: = "abstract"":" abstractdesc "transfer"":" transferdesc # "parameters"":" abstractdesc # "settings"":" settingsdesc "method"":" methoddesc "action"":" methoddesc
Acceptable identification strings are described in the general section on identifiers.

 The order of appearance of the entries in the list does not matter unless otherwise stated, and there may be several entries of the same nature.

 If there are several entries giving an abstract description, the abstract description of the class is the concatenation, in the order of appearance, of the different lists of attributes.

 The same principle applies to the parameters.

2. 2 Class Derivation
A simple form of modularity consists of describing a class as the extension of one or more previously described classes. What is extended is limited to abstract description and treatments.

 The representations can not be extended.

<Desc / Clms Page number 67>

 The syntax for describing a class by derivation is the normal syntax except for the header which then mentions the class or classes whose new is derived.

 The notion of class derivation is only a textual shortcut. The class thus described is that corresponding to the description obtained by including all the aspects of the parent classes between the header and the first entry.

2. 3 Parameter classes
It happens that many classes share most of their characteristics, and that differences can be described by a limited number of parameters of elementary nature, such as Booleans or integers. For example, the lists of integers, finite, ordered and of fixed size can be described as a single meta-class differing only by a single parameter integer, the size of the list.

2. 3.1 Description of a meta-class
The list of parameters is introduced by the parameters keyword, and follows the same syntax as a list of attributes.

 The parameters can (and should) appear in the rest of the class description, in any place where a named constant can appear.

2. 3.2 Invoking a parameterized class
The name of a parameterized class can only be used with a set of parameter values. The syntax is described later.

3 Abstract description
The description of a data structure is part of many programming languages, database management programs or protocol specifications. According to the state of the art, the description mixes abstract aspects (which is specific to the structure independently of any representation) and concrete aspects (representations, whether for transmission or memorization).

 In the formal description language according to the invention, here described, the

<Desc / Clms Page number 68>

 two aspects are kept as separate as possible, and separate syntaxes are used for abstract descriptions and representations. The description syntax contains adaptations to the specific problems of protocol specification.

 An abstract structure is described in a tree-like manner. Each non-terminal node (which corresponds to a component) is associated with a list of node descriptions. At a terminal node, or leaf, is associated an elementary class.

 Each node description includes an identifier, which makes it possible to refer to it. This identifier is usually chosen to give human readers an idea of the actual semantics of the attribute.

 It happens that the list contains nodes of the same structure, and whose identifiers are distinguished only by a number (notion of table, list, collection). This leads to the idea of multiplicity, i.e., the possible values of the number of nodes in such a group.

 Thus, a list of nodes is described as a list of triplets, 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 a basic class description.

 The syntax makes it possible to add to a node additional information, for example a so-called default value, the application of which is described below.

3. 1 Syntax
An abstract structure description is a node description sequence: abstractdesc :: =

<Desc / Clms Page number 69>

complist complist :: = compdesc ";"# complist compdesc
Each node is described by a triplet identifier / multiplicity / description: compdesc :: = id "[" multipliplicitydesc "]"":" typeanddef id ":" typedesc choiceconstruct
The first syntax is the fundamental, the others can be reduced by formal rewriting.

 In the second case, the multiplicity is implicitly 1..1. The "choice" construct is an abbreviated notation for the case of an exclusive presence of a node among a list.

3. 2 Multiplicity
The 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, ie, varies from one instance to another: which must be described is the set of acceptable values for this number. Multiplicity is therefore a subset of positive or zero integers.

 The acceptable set may itself be dynamic, depending on the value of other attributes (conditional presence). The language allows a detailed description of these cases.

<Desc / Clms Page number 70>

 A classic case of conditional presence is where the total set of numbers is 0..1.

 A simplified syntax can describe such cases as a Boolean expression.

The syntax is: multiplicitydesc :: = integerset ~~~ condset
The first case corresponds to free multiplicities, ie, unconditional; the other two to conditional presences.

For free multiplicity, the syntax is as follows: integerset :: = integersetelem "," integerset integersetelem :: = expression # interval interval :: = expression ".." expression expression "..""infinity"
The integer and interval expressions must return a positive integer value or null value.

 The second interval expression must return a value greater than or equal to the value of the first one.

<Desc / Clms Page number 71>

For a conditional multiplicity, the syntax is as follows: condset :: = integerset "#" expression # expression
The set of integers must include the possible multiplicities. This information is redundant since it can be derived from the following expression; Mandatory presence improves understanding and simplifies compilation.

 The expression conddesc must return either a set of integers, an integer, or a boolean.

 By convention an integer alone is assimilated to the set reduced to its single value. A boolean is translated as follows: the value "true" corresponds to the set 1..1, the value false to the set 0..0.

3. 2.1 The CHOICE construction
This syntax makes it possible to simplify the writing of the boxes where the presence of several nodes is exclusive (at most one of them can be present), and dynamically depends on the value of a terminal node, called the discriminant.

discri: 0..2; ell [0..1 I discri=0]: typl; el4 [0..1 I discri=2]: typ4; el2 [0..1 I discri=1]: typ2; el3 [0..1 I discri=2]: typ3; peut s'écrire alternativement CHOICE discri:0..2 { 0 { eU : typl; 1 : e12 : typ2;} 2 : { el3 : typ3; For example, the following list:

discri: 0..2; ell [0..1 I discri = 0]: typl; el4 [0..1 I discri = 2]: typ4; el2 [0..1 I discri = 1]: typ2; el3 [0..1 I discri = 2]: typ3; can be written alternately CHOICE discri: 0..2 {0 {eU: typl; 1: e12: typ2;} 2: {el3: typ3;

<Desc / Clms Page number 72>

el4: typ4;} The syntax is: choiceconstruct :: = "CHOICE" id ":" typedesc "{" branchlist "}" branchlist :: = branchdesc ";"# branchlist branchdesc ";" branchdesc :: = expr ":""{" complist "}"
If the description of a node in a branch includes an explicit multiplicity, the effective multiplicity is 0 if the discriminant does not have the correct value, and the multiplicity otherwise indicated.

 Incompatibility of identifiers.

 Equivalence is accurate. In particular, neither the construction itself nor a branch is a named structure; the lists of nodes are at the same hierarchical level, that of the point where appears the key word CHOICE. Therefore, it is not allowed to have the same identifier for a node in a branch and for a node appearing at the same level as the CHOICE.

 On the other hand, it is allowed that the same node name appears in two or more branches of the same CHOICE: this corresponds to the same and unique node, the abstract structure must be the same. The multiplicity can be different.

<Desc / Clms Page number 73>

4 Node structure description 4. 1 Type descriptions.

The different possibilities are summarized by the following syntax: typedesc :: = "{" complist "}"# id I leafdesc # id "(" exprlist ")"#"*" typedesc
The first possibility is an abstract description of syntax, parenthesized.

 The second possibility is a reference to a pre-defined class, described by its identifier.

 The third possibility is a basic class description, predefined by language. The possible syntaxes and their meanings are described later.

 The fourth possibility is a reference to a parameterized class consisting of the identifier and a list of actual parameters.

 The fifth possibility is a reference to a pre-defined class, as in the first case.

 The star indicates a difference of achievement, precisely that it is a shared instance with other structures. (In practical terms, this indicates an implementation by dynamic reference (pointer) rather than by explicit value).

 Accepted elementary classes include the following classes: - strict enumerated; - boolean; character; - finite cardinal (positive or zero natural integer);

<Desc / Clms Page number 74>

 countable (extended integer of the infinite value); - differences (signed integer); undefined or "void".

The syntaxes are: leafdesc :: = enumdesc # integerdesc # chardesc # "boolean"#"void"
Each case is described separately below.

4. 1.1 Reference with parameters
The expression list following the identifier must match the number and type to the list of parameters defined for the class.

4. 1.2 Strictly enumerated
This is a finite type (ie, the possible values for an instance of the class are finite). The list of values is given explicitly and completely by a list of identifiers.

 This list is abstract, i.e., includes no other meaning than the fact that two distinct identifiers correspond to two distinct values, which guides the implementation of the test to the equality of value of two instances.

 Formal semantics is limited to this test. External semantics is generally indicated for humans by the choice of identifiers.

 Syntax stipulates by necessity an order, but that has no formal meaning.

 The syntax is as follows:

<Desc / Clms Page number 75>

enumdesc :: = "enumerated""(" valuelist ")"#"enumerated" id "(" valuelist ")" valuelist :: value = valuelist # "value value :: = id" = "number 1 id
The identifier that can appear between enumerated and the character (is an abbreviated notation to declare and invoke the class simultaneously.

4. 1.3 Finished Cardinals
This corresponds to the mathematical concept of positive integers or nulls, and has the corresponding formal semantics. The normal external semantics of this class is the count of things, and the use of this class should in all cases be limited to such cases.

 Formal semantics includes, among others, comparison and equality tests, as well as usual arithmetic operations.

 An obvious case of legitimate use is counting the number of copies of an indexed node. Thus, an effective multiplicity is a count, and a description of multiplicity is a subset of positive or zero integers.

 The syntax is included in the description of Countable Cardinals.

4. 1.4 Differences
These are negative integers, positive or zero.

<Desc / Clms Page number 76>

 The syntax is included in the description of the following case.

4. 1.5 Countable Cardinals
This is the set of positive or null integers, extended by a special value, the infinite. This class is very useful in practice, for example for an upper bound.

 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 syntax is as follows: integerdesc :: = "integer"#"integer""(" integerset ")"
The first case corresponds to positive integers or nulls (finite cardinals). integerset :: = integersetelem "," integerset integersetelem :: = expression # interval interval :: = expression ".." expression # expression "..""infinity"
No syntax element to extend negative integers to infinity

<Desc / Clms Page number 77>

Here are some examples in the context of the UMTS standard: - "TGPRC": Integer (1..511, infinity); (The number of unallocated transmission slots (or transmission gap patterns in English) among the sequence of time slots not allocated to transmission (or Transmission Gap Pattern Sequence).

 - "TGSN": Integer (0..14); (The elementary slot number of the first non-allocated slot slot in the TGCFN.

 - "TGL1": Integer (1..14); (The length of the period not allocated to the transmission in the pattern of the transmission gaps 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.

4. 1.6 Boolean
This is a particular strict enumeration that occurs as a result of Boolean operations. The formal description language follows the most usual convention of the pair (false, true) or (false, true), with semantics (formal and real) that "true" is the result of the test 1 = 1.

 The boolean class is thus predefined as: enumerated (false, true).

4. 1.7 Undefined type or void Void indicates a general, undefined type.

5 Representations
A representation captures all the attributes of an object as a string of binary symbols or characters.

 The representations are described in CSN.l.

<Desc / Clms Page number 78>

6 Correspondence rules
Matching rules allow you to relate an abstract description to a representation.

 In the formal description language, correspondence is defined from functions. A function takes an object as a parameter and returns a value. Viewed thus, a function has a name and a type of result.

 The abstract description of the class of the object makes it possible to construct a list of functions as follows. Each terminal node has 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 zero convention, i, e 0 is included), a function returns the value of the ith elements.

 The type returned by these functions is the one associated with the node.

 For the purposes of this specification, the following notations are introduced (the formal use of function names is developed within the C ++ language adaptations).

 - "id .size ()" is the attribute that returns the actual number of id nodes.

 - "id" returns the value of the node in case the multiplicity is implicitly 1..1.

 - "id [i]", where i is a natural integer returns the value of the (i + 1) th copy.

 When a node is not terminal, the dot notation recursively builds all the functions.

6. 1 Functions defined for a representation
The labels of a CSN.l description determine a list of functions, each returning either a non-instantiated string of symbols.

 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 allowing to pass

<Desc / Clms Page number 79>

 from a string of symbols to the abstract value.

By exception, the existence of a default value makes it possible to accept a 'non-instantiated' return for a node. (The value is then the default value.)
Transcoding for a terminal node is obtained either by applying default rules, or by specifying in the transfer description of a transcoding function.

6. 2 Default rules 6. 2.1 Listed
If numeric encoding values are specified in the abstract description, the decoding is that of an integer as specified in the following section, followed by the transcoding derived from the abstract description.

 If no encoding value is given, the default decoding is the decoding of an integer followed by the transcoding applying to i the (i + 1) th value of the list defined in the description of the abstract type.

6. 2.2 Integers
These rules only apply in cases where the abstract description is an unexpanded integer.

6. 2.3 Binary symbols
If the lower bound of the set of integers is positive or zero, the decoding is that of the binary numbering, the first bit of the string 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, the encoding will try to limit at best the number of 0 in the front.

 If the lower bound is strictly negative, the decoding is that of the complement code to 2, the most significant bit being the first. The decoding is complete, but not bijective (the addition to the front of a bit identical to the first bit does not change the value).

<Desc / Clms Page number 80>

6. 2.4 Characters
Decoding is that of the usual positional numbering, the first digit being the most significant one. A sign character ("+" or "-") may appear optionally before the first digit. The decoding is not complete: a character other than the digits from 0 to 9 leads to 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
This aspect of the language is not directly related to the protocol specification. The syntax is indicated here for memory.

 In the context of this language, an action is a special case of method, and is mentioned here only for the sake of memory.

7. 1 Declarative syntax
A method or action is declared as follows: methoddesc :: = "function" id "(" paramdesclist ")"":" id "{" ccode "}"

<Desc / Clms Page number 81>

ANNEX 6
An example of a real protocol specification (the GSM mobility management protocol between a mobile station (MS) and a network infrastructure) using language according to Annex 5.

 The example presented in this appendix uses the example previously described with reference to Appendix 3, in the language illustrated in Appendix 5.

1 Mobility Management Protocol Context (or MM). MM module #include "RIL3"
The RIL3 module, not shown in more detail, includes detail descriptions invoked in the following 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 Layer 3 radio interface in French).

1.1 MM context 1.1 Abstract description class "MM context" {abstract: "IMSI" [0..1]: "IMSI";"Connectstate": Enumerated ("not connected", "connected");"Connectionparameters" [0..1 "Connect state" = "connected"]: {
The part describing a conditional presence can be ignored. It avoids a loss of information.

<Desc / Clms Page number 82>

"Serving cell": * "cell" // -> UE context.Cell list "IMEI" [0..1]: "IMEI";"Software Version Number" [0..1 present ("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; "ls ciphered": Boolean; "Service data" [O..infinite]: {"CM service type": Service Type ";" Priority ": RIL3." Priority Level ";};" Location update state ": Enumerated (" roaming not allowed "," updated ");" Location parameters "[0..1 1 iif (" Location update state "=" updated ", 1, 0)]:" LAI + TMSI "[0..1]:" LAI + TMSI ";"Registered location area": * "Location area"; // UE context.LA list
According to one variant, the syntax only indicates the type, whereas the described embodiment indicates the indexed set to which the object to be pointed belongs.

 The whole is left here in comment.

}; Jj~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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. "Detach flag": Boolean; "CTS permission": Boolean;
CKSN availability: Boolean; "CKSN" [0 .1 1 iif (CKSN availability, 1, 0)]: RIL3. "Ciphering Key Sequence 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);

}; jj ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~ 1. 1.2 Commands 1. 1.2.1 DL MM 1.1.2.1.1 Abstract description
According to the embodiment described, it does not distinguish the commands (messages) objects. The following descriptions are presented as classes.

<Desc / Clms Page number 83>

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";"UPDATING REJECT RENT": "UPDATING REJECT RENT";"AUTHENTICATIONREJECT":"AUTHENTICATIONREJECT";"AUTHENTICATIONREQUEST":"AUTHENTICATIONREQUEST";"TMSI REALLOCATION COMMAND": "TMSI REALLOCATION COMMAND";"CM SERVICE ACCEPT": "CM SERVICE ACCEPT";"CM SERVICE REJECT": "CM SERVICE REJECT";"CM SERVICE PROMPT": "CM SERVICE PROMPT";"IDENTITYREQUEST":"IDENTITYREQUEST";"ABORT":"ABORT";"MM STATUS DOWNLINK": "MM STATUS DOWNLINK";"MMINFORMATION":"MMINFORMATION"; } 1.1.2.1.2 Transfer transfer syntax: - flow of downlink MM messages <DL MM> :: = {<skip indicator: 0000><protocol discriminator: 0101>
00 {00 0010 <LOCATION UPDATING ACCEPT: LOCATION UPDATING ACCEPT># 00 0100 <LOCATION UPDATING REJECT: RENT 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 REPEAT: SERVICE REJECT CM># 10 0101 <SERVICE PROMPT CM: SERVICE PROMPT CM># 10 1000 <IDENTITY REQUEST: IDENTITY REQUEST># 10 1001 <ABORT: ABORT># 11 0001 <MM STATUS: MM STATUS DOWNLINK># 11 0010 <MM INFORMATION: MM INFORMATION

<Desc / Clms Page number 84>

Jj~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 . ! <erroneous type: bit ** = <no string} <spurious extension: bit ** = null>

jj ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~
1. 1.2.2 UL MM
1.1.2.2.1 Abstract description 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 Transfer transfer syntax.

 <UM MM> = --flow of uplink MM messages ounce 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 COMPLETE REALLOCATION: TMSI REALLOCATION COMPLETE> # 10 0011 <CM SERVICE ABORT: CM SERVICE ABORT> # 10 0100 <SERVICE REQUEST CM: SERVICE REQUEST CM> # 11 0001 <MM STATUS: MM STATUS UPLINK>}! <erroneous type. bit ** = <no string} <spurious extension: bit ** = null>};

<Desc / Clms Page number 85>

1. 1.2.3 Abandonment (or abort)
1.1.2.3.1 Abstract description class "ABORT" {abstract "Reject cause": "MM.Rejectcause"; bind <ABORT> {}
The body of the command introduced by 'bind' is not included in the example. It is to be described preferentially in C ++. This applies to all commands (introduced by'bind 'or'load') in the following sections.

1.1.2.3.2 Transfer transfer syntax: <ABORT> :: = <Reject cause: <MV-IE (Reject cause downlink, 1)};
1. 1.2.4 Authentication Failure (or AUTHENTICATION
FAILURE)
1.1.2.4.1 Abstract description class "AUTHENTICATION FAILURE" {abstract: "Reject cause": "MM.Rejectcause";"Authentication Failure parameter" [0..1 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 Transfer Transfer Syntax <AUTHENTICATION FAILURE> :: = <Reject Cause: <MV-IE (Reject Cause uplink, 1) #

<Desc / Clms Page number 86>

<Authentication Failure parameter: <O-TLV-IE (0010 0010, Authentication Failure parameter,
16)};
1. 1.2.5 Authentication Rejection (or AUTHENTICATION
REJECT)
1.1.2.5.1 Abstract description class "AUTHENTICATION REJECT" {abstract: bind <AUTHENTICATION REJECT> {} 1.1.2.5.2 Transfer Transfer Syntax <AUTHENTICATION REJECT> :: = null};
1.1.2.6 Authentication Request (or AUTHENTICATION REQUEST)
1.1.2.6.1 Abstract description class "AUTHENTICATION REQUEST" {abstract: "Authentication Parameter RAND": "MM.Authentication Parameter RAND";"AuthenticationAlgorithm": Enumerated ("UMTS", "GSM"); bind <AUTHENTICATION REQUEST> {}
1.1.2.6.2 Transfer transfer syntax <AUTHENTICATION REQUEST> :: = <spare half byte: {bit * 4 = 0000}><Ciphering key sequence number: <M-VD-IE (Ciphering key sequence number Downlink) <Authentication parameter RAND: <Authentication parameter RAND, <MV-IE (16) <Authentication parameter AUTN: <O-TLV-IE (0010 0000, Authentication parameter AUTN, 18,
18) abstract Authentication algorithm returns - if there is any error on AUTN, the authentication Algo will be considered GSM

<Desc / Clms Page number 87>

iif (Authentication parameter AUTN), UMTS, GSM)};
1. 1.2.7 Authentication Response (or AUTHENTICATION RESPONSE)
1.1.2.7.1 Abstract description class "AUTHENTICATION RESPONSE" {abstract.

Jj~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 RES: Octet string (4..16); load <AUTHENTICATION RESPONSE> {} 1.1.2. 7.2 Transfer Transfer Syntax <AUTHENTICATION RESPONSE> :: = <Authentication Response Parameter: <Authentication Response Parameter (MV-IE) <Authentication Response Extension: <O-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)> null}

jj ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~ 1. 1.2.8 Connection Abandonment for Service (or CM
SERVICE ABORT) 1.1.2.8.1 Abstract description "CM SERVICE ABORT" class {abstract: bind <CM ABORT SERVICE> {} 1.1.2.8.2 Transfer transfer syntax <CM SERVICE ABORT> :: = null

<Desc / Clms Page number 88>

1. 1.2.9 Accepting the connection request for service (or CM SERVICE ACCEPT)
1.1.2.9.1 Abstract description class "CM SERVICE ACCEPT" {abstract. load <CM SERVICE REQUEST> {}
1.1.2.9.2 Transfer transfer syntax <CM SERVICE ACCEPT> = null}
1. 1.2.10 Displaying the Connection Management Service (or CM SERVICE PROMPT)
1.1.2.10.1 Abstract description "CM SERVICE PROMPT" {abstract "PD and SAPI". RIL3 "PD and SAPI",
1.1.2.10.2 Transfer Transfer Syntax <CM SERVICE PROMPT>. <PD and SAPI of CM <IE-IE (PD and SAPI, 1)};
1. 1.2.11 Rejection of the connection request for service (or CM SERVICE REJECT)
1.1.2.11.1 Abstract description class "CM SERVICE REJECT" {abstract
Reject cause MM.Reject cause, load <CM SERVICE REJECT> {}

<Desc / Clms Page number 89>

1.1.2.11.2 Transfer Transfer Syntax <CM SERVICE REJECT> :: = <Reject Cause: <MV-IE (Reject Cause downlink, 1)};
1. 1.2.12 Request for Additional Connection for Service (or CM SERVICE REQUEST SUBSEQUENT)
1.1.2.12.1 Abstract description 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";"CKSNavailability":"CKSNavailability";"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 Transfer transfer syntax: <CM SERVICE REQUEST> :: = <Ciphering key sequence uplink number: <M-VD-IE (Ciphering key sequence Uplink number) <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: <O- TVD-IE (1000, Priority Level) abstract.Mobile Identity type returns
Mobile identity.V.Type of identity.abstract abstract.IMSI returns
Mobile identity.V.IMSI.abstract abstract.TMSI returns
Mobile identity.V.TMSI / P-TMSI.abstract

<Desc / Clms Page number 90>

abstract.IMEI returns
Mobile identity.V.IMEI};
1. 1.2.13 GSM Identity Request (or IDENTITY)
REQUEST)
1.1.2.13.1 Abstract description class "IDENTITY REQUEST" {abstract: "Mobile Identity Type": "MM.Mobile Identity Type";
1.1.2.13.2 Transfer transfer syntax: <IDENTITY REQUEST> :: = <spare half byte: {bit * 4 = 0000}><Identity type. <M-VD-IE (Identity type)};
1. 1.2.14 Identity Response (or IDENTITY RESPONSE)
1.1.2.14.1 Abstract description 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 Transfer transfer syntax: <IDENTITY RESPONSE> :: = <Mobile identity: <M-LV-IE (Mobile identity, 2, 10)};

<Desc / Clms Page number 91>

1. 1.2.15 Location Update Acceptance (or LOCATION UPDATING ACCEPT)
1.1.2.15.1 Abstract description class "LOCATION UPDATING ACCEPT" {abstract: "TMSI allocation status": Enumerated ("new TMSI", "keep TMSI", "erase TMSI");"Follow on proceed": Boolean; set location location [0..1 # "TMSI allocation status" = "new TMSI"] {"Location Area Identification": "Location Area Identification";"TMSI":"TMSI"; }: "CTS permission": Boolean; bind}
1.1.2.15.2 Transfer transfer syntax: <LOCATION UPDATING ACCEPT> :: = <Location identification area: <Location location identification, 5 <Mobile identity: <O-TLV-IE (0001 0111, Mobile identity , 3, 10) <Follow-on: <OT-IE (1010 0001) <CTS permission: <OT-IE (1010 0010) abstract.TMSI allocation status returns switch (Mobile identity = <null>, keep TMSI,
Mobile identity.V.TMSI / P-TMSI = 1 **, TMSI erase,
Mobile identity.V.TMSI / P-TMSI = bit **, new TMSI) abstract.TMSI returns
Mobile identity.V.TMSI / P-TMSI.abstract};
1.1.2.16 Reject Location Update (or LOCATION UPDATING REJECT)
1.1.2.16.1 Abstract description class "LOCATION UPDATING REJECT" {abstract:

<Desc / Clms Page number 92>

"Reject cause": "MM.Reject cause"; bind <LOCATION UPDATING REQUEST> {// set update state: = roaming not allowed}
1.1.2.16.2 Transfer Transfer Syntax: {LOTION UPDATING REQUEST><Reject Cause: <MV-IE (Reject Cause Downlink, 1) #
1. 1.2.17 Mobility management information (or MM
INFORMATION)
1.1.2.17.1 Abstract description 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";"LSAidentity" [O..1]: "LSA identity";
1.1.2.17.2 Transfer transfer syntax: <MM INFORMATION> :: = <Full name for network: <O-TLV-IE (0100 0011, Network Name, 3, 255) <Short name for network: <O-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: <O-TV-IE (0100 0111 , Time Zone and Time, 8) <LSA Identity: <O-TLV-IE (0100 1000, LSA Identifier, 2, 5) <Network Daylight Saving Time: <O-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),
A! local time zone.Local time zone, <no string>))

<Desc / Clms Page number 93>

function Universal time returns
Universal time and local time zone.Universal time};
1. 1.2.18 Downstream status of mobility management (or MM STATUS DOWNLINK)
1.1.2.18.1 Abstract description class "MM STATUS DOWNLINK" {abstract: "Reject cause""" MM Reject cause ";
1.1.2.18.2 Transfer transfer syntax <MM STATUS DOWNLINK>: = <Reject cause <MV-IE (Reject cause downlink, 1)};
1. 1.2.19 Status in the upstream direction of mobility management (or MM STATUS UPLINK)
1.1.2.19.1 Abstract description class "MM STATUS UPLINK" {abstract "Reject cause""" MM Reject cause ";
1.1.2.19.2 Transfer transfer syntax: <MS STATUS UPLINK> = <Reject cause <MV-IE (Reject cause uplink, 1)};
1. 1.2.20 TMSI Reallocation Command (or TMSI)
REALLOCATION COMMAND)
1.1.2.20.1 Abstract description class "TMSI REALLOCATION COMMAND" {abstract.

<Desc / Clms Page number 94>

"LAI + TMSI": "LAI + TMSI";
1.1.2.20.2 Transfer transfer syntax: <TMSI REALLOCATION COMMAND> :: = <Location identification area: <Location location identification, 5 <Mobile identity: <M-LV-IE (Mobile identity, 2, 9) abstract.TMSI returns
Mobile identity. V.TMSI / P-TMSI.abstract};
1. 1.2.21 TMSI reallocation performed (or TMSI
COMPLETE REALLOCATION)
1.1.2.21.1 Abstract description "TMSI REALLOCATION COMPLETE" class {abstract bind <TMSI REALLOCATIO N COMPLETE> {}
1.1.2.21.2 Transfer transfer syntax: <TMSI REALLOCATION COMPLETE> :: = null};
1. 2 Lists of localization areas (or LA list)
1. 2.1 Abstract description class "LA list" {abstract:
Location area description [0 .. infinity]: {"PLMN *" 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 ";};

<Desc / Clms Page number 95>

1. 3 List of networks (or PLMN list)
1. 3.1 Abstract description class "PLMN list" {abstract: "PLMN description" [O..infinite]: {"PLMN Id": "PLMN Identity";"Full name for network" [0..1]: "Network Name";"Short name for network" [0. 1]. "Network Name"; }
1. 4 AUTH Authentication Settings (or Authentication)
Parameter AUTN)
1. 4.1 Abstract description class "Authentication Parameter AUTN" {abstract: "Sequence number xor Anonymity Key": Bitstring (48); "Authentication management field": Bitstring (16); "Message authentication code": Bitstring (64);
1. 4.2 Transfer transfer syntax: <Authentication Parameter AUTN> :: = <Sequence number xor Anonymity Key: bit * 48><Authentication management field: bit * 16><Message authentication code: bit * 64>};
1. 5 Service Type CM (or CM Service Type)
1. 5.1 Abstract description class "CM Service Type" {abstract: "service type": Enumerated ("MO call or packet is", "emergency call", "SMS", "SS", "VGC", "VBS", "LCS")

<Desc / Clms Page number 96>

1. 5.2 Transfer syntax transfer <CM Service Type> :: = <service type: {0001 # 0010 # 0100 # 10 bit (2)}>};
1. 6 Daylight Saving Time (Daylight Saving Time)
1. 6.1 Abstract description "Daylight Saving Time" class {abstract: "Daylight saving time adjustment": Enumerated (0, "+1 hour", "+2 hour")
1. 6.2 Transfer Transfer Syntax: <Dayhght Saving Time> :: = <spare bit> * 6 <Daylight Saving Time Adjustment: {00 # 01 # 10}>};
1. 7 IMEI
1. 7.1 Abstract description class "IMEI" {abstract: "Type Approval Code" [6]: Integer (0..9); "Final Assembly Code" [2]: Integer (0..9); "Serial Number" [6]: Integer (0..9);
1. 7.2 Transfer transfer syntax: <IMEI> :: = <digit one: digit> 1 bit * 3 <pairs: <digit odd: <digit even: digit * 7 function Digit (n): integer returns iif (n = 1, integer (digit one), iif (n% 2 = 0, integer (even [n / 2] .digit even), integer (even [(n-1) / 2] .digitodd)))

<Desc / Clms Page number 97>

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 Abstract description class "IMSI" {abstract: "MCC": "MCC";"NMSI" [3..12]: Integer (0..9);
1. 8.2 Transfer transfer syntax: <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))} & byte * (4..8) function Digit (n): integer returns iif (n = 1, integer (digit one), iif ( n% 2 = 0, integer (even [n / 2] .digit even), integer (even [(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)

<Desc / Clms Page number 98>

1. 9 LAI and TMSI
1. 9.1 Abstract description class "LAI + TMSI" (abstract "Location Area Identification": RIL3. "Location Area Identification";"TMSI":"Temporary Mobile Station Identity";
1. 10 LSA Identifier (or LSA Identifier)
1. 10.1 Abstract description class "LSA Identifier" {abstract: "LSA available": Boolean; "LSA ID" [0..1 # "LSA available"]: {"LSA Identify Scope": Enumerated ("PLMN significant", "universal");"Localized service area identity": Bitstring (23);
1. 10.2 Transfer transfer syntax: <LSA Identifier> :: = {<LSA ID: <Localized service area identity: bit (23)><LSA identifier scope: bit> 1 null abstract. LSA available returns exist (LSA ID) abstract. LSA ID.LSA identify scope returns iif (LSA identify scope = 0, PLMN significant, universal)};
1. 11 MCC
1. 11.1 Abstract description class "MCC" {abstract: "MCC value": Integer (0..999) ;; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

<Desc / Clms Page number 99>

};
1. 12 MNC
1. 12.1 Abstract description class "MNC" abstract: "MNC value": Integer (0..999); };
1. 13 Network Name
1. 13.1 Abstract description class "Network Name" {abstract: "Coding scheme": Enumerated ("cell broadcast default alphabet", "UCS2") "Add country's initials": Boolean; "Text string": String;
1. 13.2 Transfer transfer syntax: <Network Name><ext: 1 <Coding scheme: {000j001}><Addcountry's statement: bit><number of spare bits in last byte: bit (3)><Text string: - - order of bits within text string? <byte> ** <{0} * (number of spare bits in last byte)><bit * (8 - number of spare bits in last byte)};
1. 14 Network Identity (or PLMN Identity)
1. 14.1 Abstract description class "PLMN Identity" {abstract: "MCC": "MCC";"MNC":"MNC";

<Desc / Clms Page number 100>

};
1.15 Temporary Identity of Mobile Station (or Temporary
Mobile Station Identity)
1. 15.1 Abstract description class "Temporary Mobile Station Identity" {abstract: "temporary identity": Bitstring (32);
1. 15.2 Transfer transfer syntax: <Temporary Mobile Station Identity> :: = <tenporary identity: bit * 32>
1.

16 Time Zone (or Time Zone)
1. 16.1 Abstract description class "Time Zone" {abstract: "From ta with GMT": Integer (-99..99);
1. 16.2 Transfer transfer syntax: <Time Zone> :: = <sign: bit><dig t 1: bit (3)><dig t 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 (20)

 CLAIMS 1. System for specifying and implementing a communication management protocol and transmission between at least one transmitter and at least one receiver, characterized in that it comprises: - means for determining a common context (2) comprising means for describing a set of data managed by said one or more transmitters and / or said one or more receivers; means for identifying the protocol messages (3) that can be exchanged between the one or more transmitters and the one or more receivers, said identification being independent of the one or more representations used for said messages; means for defining representations of data stored and / or transmitted by said one or more transmitters and / or said one or more receivers from said determination of a common context and said message identification, said definition of representations making it possible to determine instructions for implementing said protocol in at least one of said transmitters and at least one of said receivers; and means for implementing said protocol in at least one of said transmitters and at least one of said receivers from said implementation instructions, so that said one or more transmitters are able to communicate with said one or more receivers. 2. System according to claim 1, characterized in that said means for determining a common context themselves comprise means for describing a structure of the context, said description being independent of the representation or representations used for storage and / or the transmission of said data. 3. System according to claim 2, characterized in that said means for determining a common context further comprise means <Desc / Clms Page number 102>  identification and description of the types of objects for analyzing said context structure, said identification and description of the object types being independent of the representation or representations used for storage and / or transmission. 4. System according to any one of claims 1 to 3, characterized in that all or part of said managed data is the data that said protocol aims to maintain consistent in at least one of said emitter or emitters and at least one of said one or more receivers. 5. System according to any one of claims 1 to 4, characterized in that at least a part of said message identification is performed in terms of actions and / or its effects on said common context. 6. System according to any one of claims 1 to 5, characterized in that it comprises connecting means between: - a description of the signal form effectively transmitted; and - said identification of the protocol messages. 7. System according to claim 6, characterized in that said form of the signal belongs to the group comprising: the binary data sequences; - the sequences of elements taken in a predetermined alphabet; the sequences of modulated waveforms. 8. System according to any one of claims 6 and 7, characterized in that said connection is in a data specification language comprising functions for the description of said data as attributes of abstract objects and functions s applying on concrete representations. 9. System according to any one of claims 6 to 8, characterized in that said specification of the signal form is done in CSN1 enriched with functions allowing the description of said data in the form of attributes of abstract objects and functions. applying to concrete representations. <Desc / Clms Page number 103>  10. System according to any one of claims 1 to 9, characterized in that it comprises means for using the context data in a formal description of an encoding and / or decoding. 11. System according to any one of claims 1 to 10, characterized in that said means for determining a common context, said means for identifying the protocol messages and said means for defining data representations each implement a formal language allowing an automatic determination of the software for implementing said protocol. 12. System according to claim 11, characterized in that it comprises means for automatically determining the software for implementing said protocol. 13. System according to any one of claims 11 and 12, characterized in that it comprises means for automatically determining device tests implementing said protocol. 14. System according to any one of claims 1 to 13, characterized in that said means for determining a common context comprises means for translating a representation mode of a protocol into said description of a set of data. 15. System according to any one of claims 1 to 14, characterized in that said means for identifying the protocol messages comprise means for translating a protocol representation mode. 16. System according to any one of claims 1 to 15, characterized in that it further comprises means for displaying the semantics of said protocol messages exchanged between said one or more transmitters and / or said one or more receivers. 17. A method for specifying and implementing a communication management and transmission protocol between at least one transmitter and at least one receiver, characterized in that it comprises the following steps: <Desc / Clms Page number 104>  determining a common context (2) comprising a description of a set of data managed by said one or more transmitters and / or said one or more receivers; identification of the protocol messages (3) that can be exchanged between the one or more transmitters and the one or more receivers, said identification being independent of the one or more representations used for said messages; defining representations of data stored and / or transmitted by said one or more transmitters and / or said one or more receivers from said determination of a common context and said message identification, said definition of representations making it possible to determine instructions for implementing said protocol in at least one of said transmitters and at least one of said receivers; and implementing said protocol in at least one of said transmitters and at least one of said receivers from said implementation instructions, so that said one or more transmitters are able to communicate with said one or more receivers. 18. Communication device, characterized in that it comprises means for transmitting and / or receiving data to or from a third-party device, another device according to a protocol obtained by implementing the method according to the claim 17. A computer program product comprising program elements, recorded on a medium readable by at least one microprocessor, characterized in that said program elements control said microprocessor (s) to perform the following steps adapted to the specification of protocol for communication and transmission between at least one transmitter and at least one receiver: - determining a common context (2) comprising a description of a set of data managed by said one or more transmitters and / or said one or more receivers; <Desc / Clms Page number 105>  identification of the protocol messages (3) that can be exchanged between the one or more transmitters and the one or more receivers, said identification being independent of the one or more representations used for said messages; defining representations of data stored and / or transmitted by said one or more transmitters and / or said one or more receivers from said determination of a common context and said message identification, said definition of representations making it possible to determine instructions for implementing said protocol in at least one of said transmitters and at least one of said receivers; and implementing said protocol in at least one of said transmitters and at least one of said receivers from said implementation instructions, so that said one or more transmitters are able to communicate with said one or more receivers. 20. Computer program product, characterized in that said program comprises instruction sequences adapted to the implementation of a method of communication protocol specification between at least one transmitter and at least one receiver according to the claim 17 when said program is run on a computer.